Skip to main content
Digital Experience6 min read

The European Accessibility Act Is Live: A WCAG 2.2 Readiness Checklist

Obligations began applying in June 2025, and enforcement is a national matter. Here is what the law expects, what an automated scan will not tell you, and where to start.

Written by

Crispin J Fernandez

Chief Operating Officer

The European Accessibility Act moved from a distant deadline to a live obligation in June 2025, and the conversation has changed with it. A year ago the question was whether it applied. Now it is what to fix first, and how to demonstrate progress.

If you sell into the EU - products, e-commerce, banking, e-books, transport, telecoms services and more - this is likely to concern you regardless of where your company is registered. That surprises people, and it is the single most common reason organizations discover the obligation late.

What the Act Actually Requires

The EAA sets accessibility requirements for a defined list of products and services, with the aim of harmonising rules across the EU rather than leaving twenty-seven different regimes in place.

For digital services, conformance is assessed against the harmonised European standard EN 301 549, which incorporates WCAG at level AA. In practice this means WCAG conformance is the working target, and a team that achieves WCAG 2.1 or 2.2 level AA is doing the substantive work the law expects.

A few points that repeatedly catch organizations out.

  • It applies to businesses outside the EU that offer covered products or services into the EU market
  • Microenterprises providing services have exemptions, though thresholds are specific and worth checking rather than assuming
  • Transitional provisions exist for some service contracts and self-service terminals, which does not mean the obligation goes away
  • Enforcement, penalties, and complaint mechanisms are set nationally, so the consequences of non-conformance vary by market

Why Your Scan Report Is Not an Audit

This is where most readiness efforts go wrong, and it is worth being direct about.

Automated accessibility tools are genuinely useful. They reliably catch missing alt attributes, insufficient color contrast, missing form labels, and invalid ARIA. Published research consistently puts their detection rate at around a third of accessibility issues - useful, and nowhere near sufficient.

What only manual testing with assistive technology finds:

  • Alt text that exists but is meaningless. "image1.jpg" passes every automated check and tells a screen reader user nothing
  • Focus order that reaches every element in an order that makes the page incomprehensible
  • Keyboard traps - a dialog you can enter and cannot leave without a mouse
  • Dynamic updates a sighted user sees and a screen reader user is never told about
  • Custom components with the wrong semantics: a styled div that is labeled as a button and behaves like neither
  • Flows that satisfy every individual criterion and are, end to end, unusable

That last category is the important one and it is invisible to tooling. A page can pass an automated scan cleanly while remaining impossible to complete a purchase on with a keyboard.

A scanner report is where an audit starts, not what an audit is.

The same caution applies to overlay widgets promising instant compliance. They have been widely criticised by disability advocates and have not reliably prevented litigation elsewhere. Treat any product offering conformance without changing your code with considerable scepticism.

The WCAG 2.2 Criteria Sites Fail Most

WCAG 2.2 added criteria that matter disproportionately for real users and that otherwise-conformant sites routinely miss.

Focus not obscured. The focused element must remain visible - commonly broken by sticky headers and cookie banners covering exactly the element a keyboard user has just tabbed to.

Dragging movements. Any drag interaction needs a single-pointer alternative. This affects sortable lists, sliders, and drag-and-drop uploads.

Target size. Interactive targets need adequate size or spacing, which is where dense mobile interfaces most often fail.

Consistent help. Support mechanisms appear in a consistent place across pages.

Redundant entry. Do not ask users to re-enter information they have already provided in the same process.

Accessible authentication. No cognitive function test - remembering a puzzle, transcribing characters - without an alternative.

If you audited against WCAG 2.1 and stopped, these six are where your gaps most likely are.

A Readiness Checklist

Work through this in order. It is sequenced by what unblocks the most user impact soonest, not by what is easiest.

  1. Confirm whether the Act applies to your products or services, and in which markets
  2. Run an automated scan across representative templates - as a starting inventory, not a verdict
  3. Commission a manual audit of your highest-value journeys: purchase, signup, account management, support
  4. Fix keyboard operability first. Nothing else matters if a keyboard-only user cannot complete the task
  5. Address forms next - labels, error identification, error suggestion, and clear instructions
  6. Check contrast across real content, including text over images and disabled states
  7. Test with an actual screen reader on your core flows, not just with a checklist
  8. Publish an accessibility statement describing conformance status and how to report problems
  9. Add accessibility to your definition of done so new work does not reintroduce old problems
  10. Train content authors, who introduce most new issues after launch through heading misuse, vague link text, missing alt text, and inaccessible PDFs

The Argument That Unlocks Budget

The compliance case is real, and in our experience it is rarely the one that gets funding approved. Two others work better.

The market case. Roughly one in six people worldwide lives with a significant disability. Add temporary and situational limitations - a broken wrist, bright sunlight, a noisy train - and accessible design is simply design that works in more circumstances.

The findability case. Accessible markup is structurally clean markup: proper heading hierarchy, labeled controls, meaningful alt text, semantic HTML. That is precisely what search engines parse for ranking and what AI systems parse for citation. Accessibility work and findability work are largely the same work wearing different badges, and no accessibility fix has ever hurt a ranking.

That second argument tends to move budget conversations that the legal one has stalled.

Questions We Get Asked

It applies to economic operators placing covered products or services on the EU market, which can include businesses established elsewhere. Applicability depends on what you offer and where - worth confirming with counsel rather than assuming either way.

The harmonised standard EN 301 549 incorporates WCAG at level AA, so AA conformance is the practical working target. Level AAA is not generally required and is not achievable across all content in any case.

Two to four weeks for a representative sample of templates and key journeys. Remediation depends on findings volume and how your components are structured - sites built on a design system remediate dramatically faster.

Document what you have found, prioritize by user impact, publish an accessibility statement stating your current status and plan, and show demonstrable progress. A credible, evidenced remediation program is a materially better position than silence.

Share this article