DEV Community: Bojan

Letting Product Teams Own SVG Icons (Without Code Changes)

Bojan — Tue, 14 Apr 2026 13:41:19 +0000

At Subito (Italy's leading classifieds platform), we recently introduced a smart way to load and dynamically color SVG icons, one that solves a product need, not just a technical one.

You might think: "SVGs? Nothing new there." And you'd be almost right. The twist is why we built it this way.

The Problem: Decoupling Icons from the Dev Team

We were building a new feature: User Badges, visual icons displayed on the user profile and on the ad details page, to highlight seller qualities (e.g. fast responder, top seller, verified).

The requirement was clear: the product marketing and marketing teams needed to own and update these badge icons independently, without involving the dev team every time a new badge was introduced or an existing one changed.

On top of that, the icons couldn't just be static, they also needed to adapt their color dynamically.
At Subito, each category has its own brand color (e.g. motors is blue, phones is yellow), and the same badge could appear in different category contexts.
The icon had to match the surrounding palette automatically.

So the question became: how do you load an SVG dynamically and color it at runtime?

The solution: CSS `mask-image`

Step 1: host SVGs on S3

The first part is straightforward: upload the SVG files to an S3 bucket with public access.
This gives product teams a simple upload interface to swap icons anytime they want.

Step 2: color them dynamically with `mask-image`

Here's the smart bit: instead of loading the SVG as an <img> (which can't be styled) or inlining it (which couples it to the codebase), we use the CSS mask-image directive.

mask-image lets you use an image (including an SVG) as a transparency mask over an element. Only the shape of the SVG is visible, you control the fill via background-color.
Since we set that to currentColor, the icon inherits the color of its surrounding context automatically.

const maskStyle = (file: string): React.CSSProperties => ({
  maskImage: `url(${ASSETS}/static/icons/badges/${file}.svg)`,
});

export const SvgIcon = ({ iconName, className }: Props) => (
  <span
    className={classNames(styles.maskIcon, className)}
    style={maskStyle(iconName)}
    aria-hidden="true"
  />
);

And the CSS module:

.maskIcon {
  background-color: currentColor;
  mask-repeat: no-repeat;
  mask-position: center;
  mask-size: contain;
}

That's it!

Change color on a parent element and the icon follows. The product team uploads a new SVG to S3, and it's live, no code changes, no deploys.

You can play with this yourself on CodePen: https://codepen.io/ale-grosselle/pen/ogzapXa

And here's the result in production:

Is this our standard for all SVGs?

Not exactly. This approach is our standard for updated icons owned and managed directly by product teams.

For everything else, we still use the classic approach: static SVG files committed to the repo, imported directly as React components.

These icons don't change often, don't need external ownership, and are better off living directly in the codebase as React components.
Bundling them avoids unnecessary HTTP requests and the latency of fetching assets from an external bucket; they're just there, instantly.

We use SVGR to automate the conversion; under the hood, it runs SVGO to optimize the SVG before generating the component, stripping unnecessary attributes and reducing file size.

A single script in package.json handles everything:

"generate:icons": "svgr --out-dir generated svg"

Drop an SVG into svg/, run the script, and a ready-to-use React component appears in generated/.

If you want to explore the code, here's the GitHub repo: https://github.com/Subito-it/articles-code/tree/main/icons

Conclusion

Our approach to loading SVGs depends on the use case:

Icons that need frequent updates by non-developers: S3 bucket + CSS mask-image for dynamic coloring
All other icons: Static files in the repo, converted to React components with SVGR

There is rarely a single "right" solution in engineering; the best answer depends on the use case. That's exactly why at Subito we ended up with two coexisting approaches for loading SVGs: not out of inconsistency, but out of pragmatism. Each one is the right tool for its specific job.

How We Automate Accessibility Testing with Playwright and Axe

Bojan — Wed, 10 Dec 2025 13:18:44 +0000

At Subito, accessibility (a11y) is an important requirement for ensuring all users, regardless of their abilities or disabilities, can use our platform effectively. An accessible website improves the user experience for everyone, including those using assistive technologies like screen readers or alternative input devices.

In this article, we'll show you how we use Playwright combined with Axe (@axe-core/playwright) to automatically catch accessibility issues and integrate them into our CI pipeline.

Our Toolkit: Axe + Playwright

We chose Axe, an open-source library from Deque Systems, as our accessibility testing engine. It's well-regarded, easy to use, and provides a JavaScript API to run tests directly in the browser. The @axe-core/playwright package makes integration seamless.

And since we already rely on Playwright for visual regression testing and our end-to-end suite, adding accessibility checks right on top of that felt like the obvious next step.
No new tools to learn, just extending a setup we know well with Axe’s engine running inside the same Playwright workflows.

Configuration

First, we created a helper to get a pre-configured Axe instance. Our configuration focuses on WCAG 2.1 Level A and AA criteria.

What is WCAG? The Web Content Accessibility Guidelines (WCAG are developed by the W3C to make web content more accessible.

Level A: The minimum level of conformance.

Level AA: The mid-range level we (and many others) target, as it addresses more advanced barriers.

Level AAA: The highest, most stringent level.

We also explicitly exclude certain elements that are outside our direct control, such as third-party advertisements positions, to avoid false positives.

// From /test/utils/axe.ts
import { Page } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const getAxeInstance = (page: Page) => {
  return new AxeBuilder({ page })
    // We decided to target WCAG 2.1 A and AA success criteria
    .withTags(['wcag2a', 'wcag2aa'])
    // We exclude elements we don't control, like ads
    .exclude('[id^="google_ads_iframe_"]')
    .exclude('#skinadvtop2')
    .exclude('#subito_skin_id');
};

Implementation: Generating and Saving Reports

Next, we implemented another helper function, generateAxeReport, to run the analysis and save the results.

// From /test/utils/axe.ts
import { Page } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
import { Result } from 'axe-core';
import * as fs from 'fs';
import * as path from 'path';

// ... getAxeInstance code from above ...

export const generateAxeReport = async (
  name: string,
  page: Page,
  isMobile: boolean,
  includeSelector?: string
) => {
  let axe = getAxeInstance(page);

  // Optionally scope the analysis to a specific selector
  if (includeSelector) {
    axe = axe.include(includeSelector);
  }

  const results = await axe.analyze();
  const violations = results.violations;

  // Save the results to a JSON file
  await saveAccessibilityResults(name, violations, isMobile);

  return violations;
};

async function saveAccessibilityResults(
    fileName: string,
    violations: Array<Result>,
    isMobile: boolean
) {
    const outputDir = 'test/a11y/output';

    if (!fs.existsSync(outputDir)) {
        fs.mkdirSync(outputDir, { recursive: true }); // Create directory if it doesn't exist
    }

    const filePath = path.join(
        outputDir,
        `${fileName}-${isMobile ? 'mobile' : 'desktop'}.json`
    );

    // We map the violations to a clean object for serialization
    const escapedViolations = violations.map((violation) => {
        return {
            id: violation.id,
            impact: violation.impact,
            description: violation.description,
            help: violation.help,
            helpUrl: violation.helpUrl,
            nodes: violation.nodes, // The specific elements that failed
        };
    });

    fs.writeFileSync(filePath, JSON.stringify(escapedViolations, null, 2));
    console.log(`Accessibility results saved to ${filePath}`);
}

The A11y test

With these helpers in place, adding an accessibility check to any Playwright test is incredibly simple.

// From /test/a11y/example.spec.ts
import { test } from '@playwright/test';
import { generateAxeReport } from '../utils/axe';

test('check Login page', async ({ page }) => {
  await page.goto('/login_form');
  await page.waitForLoadState('domcontentloaded');

  // Just call our helper!
  await generateAxeReport('login-page', page, false);
});

It generates a JSON report for the login-page, essentially, each test run produces a structured JSON output with all the accessibility findings:

Integration with Continuous Integration (CI)

Our workflow is triggered every time our staging environment is updated. The action performs the following steps:

Runs the accessibility tests against a predefined list of critical pages.
Generates the JSON reports.
Updates or creates a dedicated GitHub Issue with the results whenever violations are detected.

Here's what the automated report looks like when posted to our GitHub Issue:

And here is the detail of the violations found:

Why a GitHub Issue? (And Not a Failing Build)

This is a key difference from our visual regression tests, which automatically open a PR and send a Slack notification to the engineer who introduced the visual change.

Since we’ve only recently introduced automated a11y checks, there’s naturally a lot of work to catch up on. We’re fixing issues progressively, but until the overall accessibility debt gets closer to zero, blocking or slowing down the pipeline wouldn’t be sustainable.

At the same time, using a GitHub Issue, we create a persistent record of the accessibility debt; the repo owner is then responsible for triaging these issues, assessing their priority, and scheduling the fixes.

Below is an example of a pull request where we address a record previously logged in the GitHub Issue:

What Automation Really Finds

We had high hopes for catching complex navigation issues, but the reality is that automated tests are best at finding basic problems.

What our tests do catch:

Missing alternative text for images (alt attributes)
Color contrast problems
Semantic HTML errors (e.g., improper heading structure)

What our tests don't catch:

Complex keyboard navigability issues
Clarity or comprehensibility of content

These more complex issues still require manual testing and review by accessibility experts (for now).

What's Next?

We plan to add Slack notifications to our GitHub Action; this notification will fire only when new violations are introduced.
While the GitHub Issue tracks our overall a11y debt, a new problem introduced by a recent deployment to staging needs to be fixed immediately.

Conclusion

Automating accessibility testing with Playwright and Axe doesn’t find every a11y problem, but it gives us a baseline that runs on every PR and helps us catch the obvious issues before they ever reach production.

There’s still plenty we want to explore, but this already feels like a solid step forward.

Check Out Our Code

Example Test: github.com/Subito-it/articles-code/blob/main/a11y-example/test/a11y/example.spec.ts
Axe Utilities: github.com/Subito-it/articles-code/blob/main/a11y-example/test/utils/axe.ts
GitHub Action: https://github.com/Subito-it/articles-code/blob/main/.github/workflows/a11y.yml

DEV Community: Bojan

Letting Product Teams Own SVG Icons (Without Code Changes)

The Problem: Decoupling Icons from the Dev Team

The solution: CSS mask-image

Step 1: host SVGs on S3

Step 2: color them dynamically with mask-image

Is this our standard for all SVGs?

Conclusion

How We Automate Accessibility Testing with Playwright and Axe

Our Toolkit: Axe + Playwright

Configuration

Implementation: Generating and Saving Reports

The A11y test

Integration with Continuous Integration (CI)

Why a GitHub Issue? (And Not a Failing Build)

What Automation Really Finds

What's Next?

Conclusion

Check Out Our Code

The solution: CSS `mask-image`

Step 2: color them dynamically with `mask-image`