The EAA, one year on: a working checklist for product teams

The European Accessibility Act has applied since 28 June 2025. A year on, the question most product teams ask us is no longer "does it apply to us?" but "what do we actually change, and in what order?" This is the list we work from.

First, the short version of the law

• What it covers: consumer-facing digital products and services sold in the EU. That includes e-commerce, banking, passenger transport, e-books, electronic communications, and self-service terminals such as ATMs, ticket machines and check-in kiosks.
• Who it covers: companies outside the EU, including in Türkiye, when they serve EU consumers. Microenterprises (fewer than 10 people and no more than €2M in turnover or balance sheet) are exempt from the service obligations.
• The standard behind it: EN 301 549. The version the Act currently points to (V3.2.1) means WCAG 2.1 Level AA for web and app content. ETSI published V4.1.1 on 2 September 2026, which moves to WCAG 2.2 AA; it becomes the reference once the Commission cites it in the Official Journal, expected around the end of 2026. We check against 2.1 AA and design new work to 2.2 AA, so it doesn't need redoing next year.
• Transition periods: services may keep running on products already in use before 28 June 2025 until 28 June 2030. Self-service terminals already in use may stay until the end of their economic life, up to 20 years.
• Enforcement: national market surveillance authorities enforce the Act, and several, including France, the Netherlands and Germany, are already acting.

The plain-language guide to the law is on our EAA page. What follows is the work itself.

1. Start in the design system, not on the screens

Most accessibility failures are repeated: the same grey text, the same unlabelled icon button, the same focus style that disappears. Fixing them screen by screen is slow and they come back. Fixing them in the design system fixes every screen that uses it.

• Colour tokens.
  • Body text needs a contrast ratio of at least 4.5:1 against its background. Large text, icons and the edges of input fields need 3:1.
  • Check every text and background pair the system allows, not just the brand colours.
• Focus. Every interactive component needs a visible focus state that passes contrast. Removing the browser outline without replacing it is one of the most common failures.
• Components with names. Icon-only buttons, toggles and tabs need an accessible name in code: "Close", not "X"; "Search", not a magnifying glass.
• Text that grows.
  • Text must still work at 200% zoom.
  • Web content must reflow at 320 CSS pixels wide without scrolling sideways.
  • On mobile, respect the system font size setting.
• Touch targets. WCAG 2.2 AA asks for at least 24 by 24 CSS pixels; we design to 44 by 44 points. A target that's too small fails people with limited dexterity long before it fails an audit.
• Focus that stays visible. Under WCAG 2.2, a focused element must not be hidden behind sticky headers, cookie banners or chat buttons. Check this in the design system, where those layers are defined.

2. Then the content

• Images: every image that carries meaning has alternative text, and decorative images are hidden from screen readers.
• Headings: headings describe the structure of the page and are marked up as headings, not only styled to look like them.
• Forms:
  • Every field has a visible label. A placeholder that disappears while typing is not a label.
  • Error messages say which field is wrong and how to fix it. Colour alone never signals the error.
• Language: the language of the page is declared, so a screen reader pronounces it correctly.
• Video: video has captions; audio-only content has a transcript.

3. Then the journeys

Users don't experience a product one component at a time. They sign up, search, pay and ask for help. Test the three or four journeys that matter most, end to end:

• with a keyboard only, checking that the focus order follows the page and nothing traps it;
• with VoiceOver on iOS and TalkBack on Android, and a desktop screen reader on the web;
• at high zoom and in landscape;
• with any time limit adjustable, and with gestures such as swipe and drag having a simple alternative.

WCAG 2.2 adds three checks that matter most in journeys: sign-in must not depend on remembering or retyping a code without help (paste and password managers must work), information already given must not be asked for again in the same process, and help must be in the same place on every screen.

Payment, identity checks and third-party widgets are where journeys usually break. They are also the parts teams assume someone else is responsible for.

4. Kiosks are a different case

A kiosk is a closed system: the user can't install their own screen reader or change its settings. The accessibility has to be built in:

• speech output;
• a way to operate it without sight;
• controls within reach from a wheelchair;
• contrast that holds up in daylight.

If you run self-service terminals, plan these with the hardware supplier early. They are much harder to add later.

5. Write it down

The Act asks service providers to explain how the service meets the accessibility requirements. In practice that means:

• an accessibility statement that names the standard;
• what is known not to work yet, and when it will be fixed;
• how people can report a problem.

Keep it honest and dated. An authority reads a statement that lists known gaps more kindly than one that claims everything is fine.

6. Keep it from coming back

• Add the checks to your definition of done, so a component isn't finished until it passes.
• Run automated checks on every release; they catch roughly a third of issues, quickly.
• Repeat a manual review of the key journeys each quarter.
• Where you can, test with people who use assistive technology every day. They find what checklists miss.

What doesn't count

• Overlay widgets. An accessibility widget adds preferences on top of a page; it doesn't fix structure, labels, focus order or contrast in the product. We offer a free one, blurple access, and we say this openly.
• A one-off audit. An audit without a fix plan and a regression process gives you a dated snapshot, not compliance.

Where we come in

• Compliance Check (from €1,900, one week): Corexi, our product experience platform, runs the automated pass. A senior designer then reviews up to three key journeys by hand with screen readers, keyboard and zoom. You get a fix plan ranked by legal risk and user impact.
• Accessible design systems: for teams that want the fixes to stay fixed.
• A11Y-RAY lite: our free first check. It's a good place to see where you stand.

We make products that meet these requirements and document how. For the legal reading, we work alongside your counsel.