WCAG 2.2, WCAG 3.0 and the European Accessibility Act: A Readiness Plan for 2026
Accessibility stopped being a design preference and became market-access law. Here is how to build an auditable programme around WCAG 2.2 AA while preparing for what WCAG 3.0 changes.
Accessibility used to be argued on ethics and, when that failed, on the size of the disabled market. In 2026 the argument is simpler: in the European Union, inaccessible digital products are products you are not legally allowed to sell. The European Accessibility Act converted a design principle into a market-access condition, and the organisations struggling right now are the ones who treated accessibility as a QA checklist rather than an architectural property.
This guide sets out what to conform to, what to ignore, and how to build a programme that produces evidence rather than good intentions.
The three standards that matter, and how they relate
Teams get paralysed because they hear three different version numbers. Here is the honest hierarchy.
WCAG 2.2 AA — your auditable baseline
WCAG 2.2 Level AA is the conformance target every regulator, procurement form and courtroom currently recognises. It added success criteria around focus appearance, dragging alternatives, target size and reducing cognitive load in authentication — all of which disproportionately affect real users on real devices. If someone asks "are we compliant?", they are asking about 2.2 AA.
EN 301 549 — the European procurement translation
EN 301 549 is the European harmonised standard that wraps WCAG and extends it to hardware, documents and real-time communication. In practice, if you conform to WCAG 2.2 AA and can produce documentation, you satisfy most of what EN 301 549 asks of a web product.
WCAG 3.0 — a direction, not a deadline
WCAG 3.0 (previously "Silver") proposes a fundamentally different model: outcomes scored across bronze, silver and gold rather than binary pass/fail criteria. It is still a draft and will not be a legal reference for years. Do not plan a programme around it. Do borrow its philosophy — that a page can technically pass every checkbox and still be unusable.
Why most accessibility programmes fail
The failure pattern is remarkably consistent across the enterprises we audit.
- Audit-and-forget. An agency delivers a 180-page PDF listing 400 issues across 20 templates. Nobody owns it. Six months later, 40 issues are fixed and 60 new ones exist.
- Fixing pages instead of components. If your date picker is inaccessible and appears on 90 pages, an audit reports 90 issues. There is one issue.
- Overlay widgets. The plugin that promises one-line compliance does not repair semantics, focus order or name/role/value. It frequently interferes with screen readers that users have already tuned. Regulators and litigants have stopped accepting it.
- Automated-only testing. Automated tools reliably catch roughly a third of issues. They cannot tell you whether your error message makes sense, whether your focus order matches reading order, or whether your custom combobox is operable by keyboard.
A readiness plan that produces evidence
Phase 1 — Establish the baseline (weeks 1–4)
Inventory templates and components, not URLs. Run automated scanning across representative pages, then manual testing on your top ten user journeys with keyboard-only navigation, a screen reader (NVDA and VoiceOver at minimum), 400% zoom and reflow at 320 CSS pixels. Produce a component-level defect register with severity mapped to user impact, not to WCAG numbering.
Phase 2 — Fix at the source (weeks 4–16)
Remediate in the design system first: focus indicators, target sizes, form error patterns, modal focus trapping, skip links, heading hierarchy, and accessible names on every interactive element. Every fix here removes dozens of page-level defects. Only then move to bespoke page code.
Phase 3 — Prevent regression (ongoing)
Add automated accessibility checks to CI on component libraries, make keyboard operability part of the definition of done, and require an accessibility annotation layer in design handoff (focus order, landmark structure, alternative text intent). Regression prevention is where the cost curve bends.
Phase 4 — Documentation and procurement
Publish an accessibility statement with a genuine known-issues list and a remediation timeline, maintain an Accessibility Conformance Report, and put conformance clauses into vendor contracts. A third-party chat widget or payment iframe can break your compliance without touching your codebase.
The commercial case nobody bothers to make
| Investment area | Accessibility outcome | Commercial side effect |
|---|---|---|
| Semantic markup and headings | Screen reader navigability | Cleaner content extraction for AI answer engines |
| Form error clarity | Cognitive accessibility | Measurably lower checkout abandonment |
| Keyboard operability | Motor accessibility | Faster power-user workflows in internal tools |
| Reflow and zoom support | Low-vision accessibility | Genuine small-screen resilience |
| Captions and transcripts | Deaf and hard-of-hearing access | Indexable text from video assets |
This is why we place accessibility inside the design system rather than inside QA. The same work that satisfies a regulator makes your product faster to use and easier for machines to read.
What to do in the next 30 days
- Name one accountable owner with budget, sitting in platform or design system — not in QA.
- Run a manual keyboard and screen reader pass on your five highest-revenue journeys. This alone tells you whether you have a small problem or a structural one.
- Audit your third parties. List every embedded widget, and ask each vendor for a conformance report.
- Publish an honest accessibility statement. A statement with a real issues list and dates is a far better legal position than silence or an unverifiable claim of full compliance.
Accessibility maturity is not measured by how few issues your last audit found. It is measured by how quickly a newly introduced issue is caught and how rarely one reaches production at all.
Frequently Asked Questions
When does the European Accessibility Act actually apply to my website?
The Act applies to products and services placed on the EU market, including e-commerce, banking, transport and ebooks. If you sell or serve EU customers digitally, you are in scope regardless of where your company is registered. Enforcement runs through national authorities, which means complaints and penalties arrive locally rather than centrally.
Is WCAG 2.2 AA enough, or should we target WCAG 3.0 now?
Target WCAG 2.2 AA today. WCAG 3.0 is still a working draft and will not be a legal reference point for years. What you can do now is adopt 3.0's mindset — outcome-based testing with real users — while conforming to 2.2 AA as your auditable baseline.
Can an accessibility overlay widget make us compliant?
No. Overlays do not fix the underlying markup, focus order, or semantics, and courts and regulators have repeatedly rejected them as a defence. They also frequently break assistive technology that users have already configured. Fix the code.
How much does accessibility remediation typically cost?
For a mid-size content or commerce site, expect an audit plus remediation programme rather than a one-off fix. The cost driver is almost never the audit — it is the number of bespoke components with no accessible pattern behind them. Design-system-led organisations remediate far more cheaply because one fix propagates everywhere.
Who should own accessibility internally?
Ownership belongs with the design system and platform team, with legal and procurement enforcing gates. If accessibility sits only with QA, it becomes a release-blocking argument instead of a build-time default.