The European Accessibility Act became enforceable on 28 June 2025 and applies to consumer services including online shops and banking, with EN 301 549 as the harmonised standard referencing WCAG level AA. A team with 11 applications proposes moving accessibility into its design system rather than fixing each application. What does that buy, what does it pay, and where does it stop working?

What is gained, quantified

Roughly half of a typical audit's findings are component-level and identical across applications: unlabelled controls, contrast below the required ratio, non-focusable custom widgets, inputs without programmatic labels, icon buttons with no accessible name. Fixing those once in a shared component library fixes them in every application that upgrades, which converts 11 remediation projects into 1 plus 11 upgrades.

The second gain is durability. A component that is accessible by construction stays accessible unless someone overrides it, whereas an application fixed by audit regresses on the next feature, because nothing prevents the regression.

What is paid

• The upgrade becomes the critical path. The fix is worthless until every application is on the new version, so the programme's schedule is now the slowest team's schedule. This is the cost teams underestimate, and it is why the design system work must be paired with a push to get applications current before the deadline matters.
• Overrides defeat it silently. Any system that allows custom styling allows contrast to be broken from outside, and any component that accepts arbitrary children allows an inaccessible child. The library can only guarantee what it fully controls.
• Component ownership becomes conformance ownership, which is a different skill and a real staffing cost: someone must understand the standard, test with assistive technology, and say no to product requests that break a pattern.

Where it stops working

Roughly half the findings are not component-level at all, and no design system can fix them:

• Page structure and heading order, which is a composition decision made per page.
• Focus management across navigation, owned by the router.
• Reading order and keyboard order, which follow the DOM the application produces.
• Error handling and form flows, where the semantics live in the copy and the sequence.
• Alternative text and media captions, which are content, produced by whoever authors the content.
• Accessible names that depend on context, where the same component needs a different label on two pages.

That split is the useful planning number: a design system is about half the work, and the other half is application and content work that starts at the same time or the deadline is missed.

The gate that makes it stick

The change that survives the programme is not a fixed component; it is an automated check in the pipeline plus a manual test on the routes that matter. Automated tooling reliably catches contrast, missing labels and invalid ARIA — a genuine minority of real-world barriers, commonly put at around a third — so the remaining coverage comes from a keyboard-only pass and a screen-reader pass on the critical journeys, per release. Naming those journeys is the architectural decision: sign-up, sign-in, search, checkout, and account recovery, not all 400 screens.

When this is the wrong answer

If one application carries 90% of the affected traffic, fix that application first and build the shared components out of what you learn. A design-system-first programme in that situation spends six months before any user is better off, and regulators and users both look at the service, not the library. The design system is the right vehicle when the estate is broad and each application is small, which is exactly the 11-application case in the question, and the wrong one when the estate is one large product with a long tail.