Design systems often earn their accessibility reputation one audit at a time, well after the interface is built. When that timing shifts, the criteria come into play with the earliest decisions, before there's anything left to correct.
A decision at that level doesn't stay where it's made. As contributors extend the work, what they add tends to mirror whatever precedent is already in place. Accessibility in a digital product spans several layers, from the interface itself to content, engineering, third-party tools, and its own features, and much of what reaches users passes through shared components. This piece focuses on the design system, where a single early decision sets the precedent for everything that follows, including how the product absorbs evolving regulatory requirements and new product extensions. At Acid Tango, that is also where we start.
The further a defect travels, the more resources its fix tends to draw. Contrast checks and assistive-technology passes are often postponed until components are built, so the first signal tends to be a QA finding or a ticket from a user who relies on a screen reader or a similar aid. By that point the component is usually in use across several views, and each instance carries the defect. Because the people who fix it are rarely the ones who built it, part of the cost goes into reconstructing why it was built that way. A system already in production is in this position, but a fix to a shared component or style can reach every screen that inherits it, an advantage over fixing screen by screen.
Both approaches can leave the interface looking alike on day one; they differ in where the effort lands across a release cycle:
The right-hand column depends on catching a defect before it reaches everything that reuses it, and that is decided by where accessibility is defined.
Design tokens are the named values, such as a color or a spacing unit, that the whole system reads from a single place. At the level of tokens and the base components built on them, accessibility comes down to a list of defaults that hold regardless of who builds on top of them:
Contrast pairs, defined once as semantic tokens (text on surface, icon on surface) and validated against the target level of the chosen standard, so each theme can inherit a passing combination. Level AA of the Web Content Accessibility Guidelines (WCAG) 2.2 (the W3C's international standard, graded in levels A, AA, and AAA, with AA the usual legal reference) sets 4.5:1 for body text and 3:1 for large text and interface components [1].
Focus-visible styles, so keyboard navigation doesn't depend on an individual author adding it.
Minimum touch-target sizes, set as a fixed constraint; level AA asks for at least 24 by 24 CSS pixels, with a few exceptions [1].
Motion tokens with a reduced-motion variant, so animation respects the system setting that asks for less motion.
Keyboard behavior, semantic markup, and ARIA patterns (the code that tells assistive technology what a component is and how it behaves, used when native HTML falls short [2]), documented alongside the visual spec in the same file. Screen readers, which convert on-screen content to speech or braille, depend on that markup to interpret a component, and one without it risks being skipped or misdescribed.
With keyboard and ARIA behavior documented next to the visual spec, there's no need for a separate spec. A component earns its place in the shared library only once it satisfies accessibility, appearance, and interaction criteria together, in the same review. Teams building on the library start from defaults that already hold, with no extra step to remember for what it covers. Heading structure, focus order across a flow, alt text, and error messages remain the responsibility of whoever builds the screen; annotations in the design handoff can carry the first three.
The people who sign off on what enters the library control what reaches users, so accessibility belongs at that checkpoint. When it runs on a parallel track, it competes for attention and can stop counting toward what makes a component "done."
As contributors join who weren't there when the original tokens were written, regressions become more likely, and the question is how strict the review should be. Two positions recur, each with its own cost attached:
A strict upfront review gate helps keep accessibility consistent, though it slows delivery.
A looser gate lets components through sooner, but small inconsistencies accumulate quietly until they turn into a larger cleanup later.
A split fits both positions: a strict gate for tokens and base components, which everything else inherits, and a looser one for composite patterns (assembled from base ones), with automated checks on every change as the floor for both. The right balance between the two depends on how fast the system needs to grow. Among the reviewers, governance rests with a named owner (one person or a small team), who applies the gate and answers for regressions.
The European Accessibility Act (EAA), formally Directive (EU) 2019/882, was adopted by the European Parliament and Council on April 17, 2019. It has applied to covered digital products and services, including e-commerce and consumer banking services, since June 28, 2025 [3].
The directive complements an earlier one that covered only public-sector websites and apps, extending equivalent requirements to private-sector products and services throughout the EU for the first time [3]. Before it, digital accessibility in the private sector was governed by a patchwork of national rules with no shared enforcement mechanism. Under the EAA, the requirement applies in every member state regardless of a company's own priorities, and public procurement is conditioned on meeting it [4].
The Commission has already requested accessibility standards covering non-digital information, customer service, and emergency communications [4]. Enforcement also reaches beyond national borders, since the other member states must follow a market-withdrawal decision taken by one of them [4].
The EAA states what must be accessible, not how to build it. That technical detail comes from EN 301 549, the European standard for the accessibility of digital products and services, which incorporates WCAG. Its September 2026 update aligns it with WCAG 2.2 level AA [5], which makes that level a reasonable target to define at the token.
When accessibility is handed off numerous times, requirements can lose detail at each step. The alternative is one sequence in which the standard established at setup carries through the checks and tests that follow:
Discovery. Research includes people with permanent, temporary, and situational accessibility needs, a spectrum described in Microsoft's Inclusive Design guidance [6]. The findings shape the information architecture and identify which features the product should include, before a single screen exists.
Setup. The team sets which accessibility standard the product will be held to, and at what level (such as WCAG 2.2 at level AA), and defines who owns each layer and the automated testing tooling that will check for it.
Design and development. The automated checks defined during setup (axe-core in continuous integration and Storybook's accessibility addon, for example) run on every change, so many defects surface in the sprint that introduces them. Passing them is part of a component's definition of done.
Pre-launch. People who use assistive technology (screen readers such as VoiceOver, NVDA, and TalkBack, screen magnifiers, and voice control software, among others) test the product ahead of launch, and they reveal friction that automated checks cannot reliably detect.
Tokens, components, governance, and the project sequence add up to one operating model, with accessibility as a property of the system. The regulatory shift across the EU reinforces that model from outside. What used to be a design choice has become a market-entry condition for covered products and services.
Day-to-day, designers and engineers keep their usual tools; the review process covers accessibility, and pre-launch testing adds assistive-technology users. What moves is where a team makes the decision and how often, which becomes once, at the token.
A system built this way can lower the amount of rework a team absorbs later in a product's life, though how much depends on how closely teams adhere to the system. Foundations give a system its internal order, and that is what keeps consistency and governance workable as more teams build on it.
If your product has compliance or accessibility gaps, our product design team can help you close them at the system level, in a new design system or one already in production. To set up a discovery call get in touch at product.design@acidtango.com.
No. Encoding accessibility in tokens typically reduces the separate remediation pass that follows a late-stage audit, while manual testing with real assistive-technology users still surfaces what automated checks and token-level rules cannot reliably see, so a passing automated scan is not proof of compliance.
Typically a named person or small team, embedded in the same review that approves new components. With the decision in one place, reviews stay consistent as contributors change, since reviewers work from documented criteria.
It can, depending on the gate. A stricter one protects consistency and gives up some speed. A looser one delivers faster, at the risk of small inconsistencies building up unnoticed until they need a cleanup pass. That trade-off may soften when the stricter review applies where reuse is highest, at tokens and base components, and the rest of the library gets the looser one.
Often not. Starting from the tokens and base components lets one fix reach everything that inherits them, and the rest of the library can follow in order of reuse. A rebuild may still make sense when a component's structure itself blocks keyboard or screen reader support.
Not on its own. It is the level the updated EN 301 549 aligns with, so it is the practical reference for the interface. Once that standard is cited in the Official Journal of the European Union, meeting that standard gives a presumption of conformity with the matching requirements of the Act. The Act also asks service providers to explain how their services meet the requirements, so meeting AA addresses the interface but not the full set of obligations.
[1] W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," December 12, 2024. https://www.w3.org/TR/WCAG22/
[2] W3C WAI, "Read Me First" (ARIA Authoring Practices Guide), accessed October 23, 2026. https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
[3] EUR-Lex, "Directive (EU) 2019/882 on the accessibility requirements for products and services," April 17, 2019. https://eur-lex.europa.eu/eli/dir/2019/882/oj
[4] European Disability Forum, "European Accessibility Act: products and services required to be accessible!," June 27, 2025. https://www.edf-feph.org/accessibility-act-enters-into-force-products-and-services-must-be-accessible/
[5] ETSI, "EN 301 549 V4.1.1: Accessibility requirements for ICT products and services," September 2026. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf
[6] Microsoft, "Inclusive 101," accessed October 23, 2026. https://inclusive.microsoft.design/articles/inclusive-101-guidebook
