A year of the EAA — does your component library's CI catch a11y violations yet?

The EAA is one year into enforcement, and most component libraries still ship without a single automated a11y check. Here is how I closed that gap in an Angular workspace, on two levels — live during development, and as a hard fail in CI.

A year in, and we are still flying blind

This week marks one year since the European Accessibility Act became enforceable on 28 June 2025. Member states started accepting complaints. Market surveillance authorities started asking questions. And a lot of teams that had been treating "we'll do an a11y pass before launch" as a strategy noticed, quietly, that there was no launch — there was a constant trickle of releases, and the a11y pass had never actually happened.

Component libraries are where this hits first. They ship dozens or hundreds of building blocks, every one of them potentially the thing that makes your product fail an audit. Ask yourself, honestly: how many components in your design system pass axe-core against WCAG 2.2 AA today? You don't know. Your CI doesn't know either.

This post is about how to fix that for an Angular library — on two layers, both wired into the same tool, and both runnable in under an hour of setup.

The two-layer model

There are two distinct moments where a11y feedback should land for a component library:

1. Dev-time. When I'm building a component variant, I want to see a11y violations as they happen, against the exact variant I'm rendering, without leaving my workflow.
2. CI-time. When a PR opens, I want every variant of every component re-audited and the build to fail loudly if the library regresses past a threshold.

These are not the same job. Dev-time is about catching cheaply. CI-time is about holding the line. You want both, and the tool I'll show — ng-prism, an Angular-native component showcase — wires both into the same workspace.

Layer 1: Live a11y in the component lab

ng-prism is a showcase tool similar in spirit to Storybook, but built around Angular's component model — I wrote about why I built it in an earlier post. You put @Showcase on a component, ng-prism scans your library, and you get a styleguide app with controls, theming, panels — and an A11y panel built into the core.

The panel runs axe-core against the rendered variant every time the variant or any input changes. It has four tabs:

• Violations — the live axe-core report, sorted by impact (critical, serious, moderate, minor), with a score ring that updates in real time.
• Keyboard — tab-order overlay, focus trap detection, missing-tabindex warnings.
• ARIA Tree — the component's accessible tree as the browser sees it, with the computed accessible names.
• Screen Reader — what a screen reader would announce, as a list or step-through player with a "screen-reader perspective" toggle that dims the canvas so you stop seeing what users don't.

You don't add a plugin to get this. It comes with @ng-prism/core. The only thing you ship into your workspace is axe-core as a peer dependency.

When a component needs a per-component override — a decorative icon that should not be audited, or a rule you know is wrong for this widget — you tag the showcase config:

@Showcase({
  title: 'Toast',
  meta: {
    a11y: {
      rules: {
        'color-contrast': { enabled: false },
      },
    },
  },
})
export class ToastComponent { /* ... */ }

This is the cheap layer. It catches the issues that would otherwise survive review because nobody pulled up DevTools and ran axe by hand. But the moment a contributor doesn't open the panel, the issue ships. That is what Layer 2 is for.

Layer 2: a CI step that fails loud

Here is the design call I want to spend a minute on: ng-prism does not ship a built-in audit CLI. I tried that, and pulled it out.

Component libraries live in different stacks. Some teams already have Playwright. Some run @axe-core/cli in a Docker step. Some have a custom headless harness for visual regression and want a11y bolted onto the same browser session. A built-in CLI would either lock teams into one of those, or balloon into a config surface that mirrors every option of all of them.

So instead of a CLI, ng-prism exposes a small contract — call it the External Audit API — and lets your team bring its own auditor. The contract has three anchors:

Anchor	What it is	Why
window.__PRISM_MANIFEST__	A global with { components: [{ className, variants: [{ name, index }] }], pages: [...] } set by the running app.	Discovery. The auditor needs to know what to audit.
?component=<className>&variant=<index>	URL params the app reads on navigation.	Drive the app to a specific variant from the outside.
[data-prism-rendered="<className>:<index>"] on .demo-wrap	An attribute on the renderer host.	Render-completion marker — wait for this to flip before injecting axe.

A working auditor against this contract is small. Here is the core loop in Playwright (adapted from the real script I run against my own library, ~250 lines total including a tiny static server and threshold checks):

await page.goto(baseUrl, { waitUntil: 'networkidle' });
await page.waitForFunction(() => globalThis.__PRISM_MANIFEST__);
const manifest = await page.evaluate(() => globalThis.__PRISM_MANIFEST__);

for (const comp of manifest.components) {
  for (const variant of comp.variants) {
    const url = new URL(baseUrl);
    url.searchParams.set('component', comp.className);
    if (variant.index > 0) url.searchParams.set('variant', String(variant.index));

    await page.goto(url.toString(), { waitUntil: 'load' });
    await page.waitForFunction(
      ([key]) =>
        document
          .querySelector('.demo-wrap')
          ?.getAttribute('data-prism-rendered')
          ?.startsWith(key),
      [`${comp.className}:`]
    );

    await page.addScriptTag({ content: axeSource });
    const { violations } = await page.evaluate(async () => {
      const target = document.querySelector('.demo-wrap');
      const r = await globalThis.axe.run(target);
      return { violations: r.violations };
    });

    results.push({ className: comp.className, variant: variant.name, violations });
  }
}

The script writes an aggregated a11y-report.json at the end. ng-prism reads that file at build time and embeds the totals into the runtime manifest, so a coloured pill (green/orange/red) appears in the styleguide header — visible to anyone reviewing a deployed PR preview.

The thresholds live in your prism config:

// ng-prism.config.ts
import { defineConfig } from '@ng-prism/core';

export default defineConfig({
  a11y: {
    reportPath: 'a11y-report.json',
    thresholds: {
      score: 85,
      critical: 0,
      serious: 0,
      moderate: 5,
    },
  },
});

If the report breaches any threshold, the build fails. Not a warning, not a soft error — the pipeline goes red, the PR cannot merge.

Putting it in CI

The three steps for a GitHub Actions job (adapt to your runner of choice):

- run: npx nx run my-lib-prism:build       # 1. build the prism app
- run: npx nx run my-lib:audit-a11y        # 2. your audit script writes a11y-report.json
- run: npx nx run my-lib-prism:build       # 3. re-build to embed the report into the manifest

Two builds, because the report is generated against the first build and embedded by the second. The header pill renders only after step 3 — useful if you deploy PR previews, because reviewers can see the a11y score next to the components without clicking through every panel.

The audit step is your own script. If you don't want to write one, the Playwright snippet above plus argument parsing and threshold checks is roughly 200–250 lines and lives in scripts/. It's yours, in your repo, in JS or TS you can edit when your CI changes.

Why this fits Angular libraries specifically

A small note on tooling fit, because Angular libraries have one constraint that bites tooling all the time: dialogs and overlays. CDK Overlay, MatDialog, anything that portals to the body — they break in iframe-based component labs. ng-prism renders components directly into the host document via ViewContainerRef.createComponent(), so overlays land where they should, and the a11y audit sees them as real DOM. That matters because most of the WCAG violations I catch are in dialogs and floating UI — exactly the surfaces other tools tend to miss.

Beyond that: signal inputs and outputs work natively, the showcase config is just a decorator on the component (no separate story file), and a11y is in the core — not behind a plugin you have to remember to install.

Try it

ng add @ng-prism/core

Then add @Showcase to a component, run the prism builder, open the A11y panel, and watch the score ring move when you change a variant. From there, the External Audit API documented in docs/guide/accessibility.md is enough to write the CI script in an afternoon.

The repo: github.com/dyingangel666/ng-prism. If this post saved your team a CI compliance scramble, a star is appreciated — and issues, PRs, and "this works / this doesn't" reports are very welcome.

A year of the EAA is enough. Stop shipping component libraries that can't tell you their own a11y score.