WCAG 2.2 AA compliance and the European Accessibility Act: what sites must do

Start with scope, not with a scanner

The usual sequence is that somebody runs a free accessibility checker, gets a red score, and forwards it to whoever owns the website. That is the wrong first move, because a scanner cannot tell you the two things that determine what you have to do: which law reaches your organisation, and which version of the technical standard that law points at.

Answer those first. A plan built without them is either an expensive over-delivery or a confident under-delivery that fails an audit two years later. Specific obligations are also easier to budget against, and much harder for a vendor to inflate — which matters in a field long sold on vague fear.

Who the European Accessibility Act actually applies to

Directive (EU) 2019/882, the European Accessibility Act, is why accessibility moved from a public sector concern to a private sector one. Member states had to bring it into national law by June 2022, and it started to bite on 28 June 2025.

Scope is defined by product and service category, not by company size or sector. The European Commission’s list covers computers and operating systems, smartphones, TV equipment for digital television services, telephony services, audio-visual media services, air, bus, rail and waterborne passenger transport services, banking services, e-books, ATMs and ticketing machines — and e-commerce, the entry that pulls in an enormous number of ordinary businesses.

The obligation attaches to services provided to consumers in the EU rather than to where the provider is incorporated, so a UK or US retailer shipping to Dublin and pricing in euros is running an EU e-commerce service.

Three qualifications get misrepresented in both directions.

Microenterprises providing services are exempt from the service obligations — at EU level, fewer than ten people and turnover below a set threshold. It is a genuine carve-out, and it does not extend to microenterprises manufacturing or distributing covered products.

Disproportionate burden is a defence, not a checkbox. The argument has to be assessed and documented. GOV.UK’s guidance on the equivalent UK public sector provision shows how seriously that is meant to be taken: a formal assessment, disclosed in the accessibility statement.

Business-to-business selling is a grey area. The directive is framed around consumers, so a pure procurement portal is arguably outside it and a shop selling to both is not. That is a legal question; ask a lawyer rather than treating an agency’s reading of a directive as advice.

Which standard binds you: WCAG 2.1, WCAG 2.2 and EN 301 549

Law rarely names WCAG directly. It names a standard, and the standard names WCAG. That indirection is where the confusion lives.

In the EU the technical criteria sit in the harmonised European standard EN 301 549. The European Commission’s digital policy page states that the legal requirements “are underpinned by technical criteria specified in the harmonised European standard EN 301 549 v3.2.1”, and that version points at WCAG 2.1 Level AA for web content. Conforming to the cited harmonised standard gives you a presumption of conformity with the law, which is its practical value. In the UK the position for public sector bodies is blunter and more current: GOV.UK states they must meet WCAG 2.2 AA.

The United States has two regimes. For state and local government the Department of Justice adopted WCAG 2.1 Level AA, with compliance required by 26 April 2027 for entities serving 50,000 people or more and 26 April 2028 for smaller entities and special district governments. Federal agencies fall under Section 508, whose standards harmonise with WCAG 2.0. For private business the DOJ says the ADA’s requirements “apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web”, while acknowledging it “does not have a regulation setting out detailed standards”.

Three regimes, four referenced WCAG versions, a moving target. The sane response is to build to WCAG 2.2 AA and stop tracking the delta: versions are backwards compatible, so the higher bar satisfies every regime above and absorbs the next update without a second project.

The four principles, and what each one really constrains

WCAG organises everything under four principles. Perceivable — can the information reach the person’s senses at all? Text alternatives, captions, sufficient contrast, text that resizes. Operable — can they drive it? Keyboard access to everything, enough time, sane navigation, input methods beyond a mouse. Understandable — is it comprehensible and predictable? Readable language, consistent behaviour, errors that explain how to recover. Robust — will it survive assistive technology, including tools that do not exist yet? Valid markup, correct roles and names.

The taxonomy earns its keep because the four fail for different reasons. Perceivable failures are usually design decisions — a palette chosen for a logo, then used for body text. Operable failures are engineering decisions, a div with a click handler instead of a button. Understandable failures are content decisions, robust failures framework decisions. Knowing the bucket tells you whose backlog a finding belongs in.

What WCAG 2.2 added, and which of it binds at AA

WCAG 2.2 added nine success criteria and removed one. Six of the nine bind at Level A or AA, which is the level almost every law and procurement document specifies.

Criterion	Level	What it demands in practice
2.4.11 Focus Not Obscured (Minimum)	AA	A focused component must not be entirely hidden by author-created content. Sticky headers, cookie banners and floating chat widgets are the usual offenders.
2.5.7 Dragging Movements	AA	Anything operable by dragging needs a single-pointer alternative unless dragging is essential. Sliders, sortable lists, map panning, drag-and-drop uploads.
2.5.8 Target Size (Minimum)	AA	Pointer targets at least 24 by 24 CSS pixels, with exceptions for spacing, inline links, equivalent controls, user-agent-controlled sizing and essential presentation.
3.2.6 Consistent Help	A	A help mechanism repeated across pages appears in the same relative order each time.
3.3.7 Redundant Entry	A	Do not make someone re-enter information they already gave you in the same process.
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive function test in a login step unless an alternative, a mechanism to help, object recognition or personal content identification is offered.
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused component may be hidden.
2.4.13 Focus Appearance	AAA	Minimum size and contrast for the focus indicator itself.
3.3.9 Accessible Authentication (Enhanced)	AAA	As 3.3.8, but object recognition and personal content no longer count as exceptions.

Two deserve more than a table row.

Target Size (Minimum) surprises design teams because its exceptions are more generous than the headline. A 16-pixel icon button passes under the Spacing exception if a 24-pixel circle centred on it does not intersect another target’s circle, and inline links are exempt outright. The criterion is less about enlarging every button than about not placing three tiny icons in a row — the pattern that fails on a phone anyway. It is also a token-level fix if you maintain a component library and a hundred-file fix if you do not, which is the practical case for a design system rather than a set of brand guidelines.

Accessible Authentication (Minimum) has real product consequences: a login must not require someone to remember, transcribe or solve something unless you offer a way out. The most common accidental failure is not a puzzle CAPTCHA — it is blocking paste on a password or one-time-code field. W3C’s guidance is explicit that copy and paste can be relied on to avoid transcription, and that a page preventing password managers from filling authentication fields fails unless an alternative exists. The “security” measure your team added years ago is now a conformance failure.

One removal matters too: 4.1.1 Parsing is obsolete and removed from WCAG 2.2. Duplicate IDs and unclosed tags remain bad practice but no longer count as a conformance failure in their own right.

The failures that show up on almost every site

WebAIM’s annual automated analysis of one million home pages is the best available picture of the baseline. The February 2026 edition found detected WCAG 2 failures on 95.9% of them, averaging 56.1 errors per home page — both worse than the year before. The distribution matters more than the headline:

• Low contrast text: 83.9% of pages
• Missing alternative text for images: 53.1%
• Missing form input labels: 51%
• Empty links: 46.3%
• Empty buttons: 30.6%
• Missing document language: 13.5%

WebAIM notes that 96% of all detected errors fall into those six categories. Every one is cheap to fix and cheaper still never to introduce.

Those are also, precisely, the failures a machine can decide without judgement. The ones it cannot — is this alt text useful, is the heading structure honest, does focus order follow visual order, can checkout be completed with a keyboard — never appear in the statistics, and that is where the genuinely blocking problems live. Those findings repeat with depressing consistency:

1. Custom controls with no accessible name — an icon-only button rendered as a div with a click handler, invisible to a screen reader and unreachable by keyboard.
2. Focus indicators removed for aesthetics — someone set outline: none in a reset and never replaced it, and the site is now unusable without a mouse.
3. Modals that do not trap focus — open a dialog, press Tab, and focus wanders behind it onto a page you cannot see.
4. Errors conveyed by a red border alone — no text, no programmatic association with the field, nothing announced.
5. Headings chosen for size — an h4 because the designer wanted smaller text, breaking the outline screen reader users navigate by.

Why overlay widgets are not compliance

An accessibility overlay is a script you add to your page that claims to fix accessibility at runtime, usually behind a floating icon offering toggles for contrast and font size.

The European Commission’s position is stated plainly on its web accessibility policy page: overlays “do not ensure the website itself meets the detailed criteria of the standard” and “are not an appropriate solution”. That is about as direct as EU policy prose gets.

The mechanical reason is simple. An overlay operates on the rendered DOM after the fact. It can guess an image’s alt text but not the editorial intent behind it. It cannot restructure a heading hierarchy that is semantically wrong, and it cannot give a drag-only interaction a single-pointer alternative, because that is new functionality rather than a patch. The widget is also itself an interface element that must be keyboard-operable and correctly announced, so a badly built one adds failures of its own.

There is a narrow honest use: a stopgap on a badly broken site while real remediation runs. Even then, do not call it compliance, do not cite it in the accessibility statement, and do not let it become the reason remediation is deprioritised — which is what usually happens.

Testing: what a machine can decide, and what it cannot

W3C’s guidance on evaluation tools is unambiguous. They “can not determine accessibility, they can only assist in doing so”, human judgement is required, and they can produce false or misleading results.

You will see a figure quoted for how much of WCAG automated tooling covers, usually between a quarter and a half. We will not quote one: the credible sources for those numbers are vendor blog posts, and the answer depends entirely on whether you count criteria or defects. The mechanism is the useful part. A rule can be automated when conformance is decidable from the markup alone. Contrast ratio, yes. Presence of an alt attribute, yes. Usefulness of its contents, no.

A routine that works has four layers, in increasing cost.

1. Automated scanning in CI. axe-core, Lighthouse or Pa11y wired into the build so a regression fails a pull request. Catching a contrast failure at review costs minutes; catching it after a redesign ships costs a sprint.
2. Keyboard-only traversal of every key journey. Unplug the mouse. Tab through navigation, forms, modals, filters and checkout, watching for focus that disappears, focus order that does not match visual order, and anything reachable by mouse but not by keyboard. This one exercise finds more real blockers than any scanner.
3. A screen reader pass. NVDA with Firefox or Chrome on Windows, VoiceOver with Safari on macOS and iOS. You need not be an expert user; you need to hear controls announced as “clickable” with no name, images read as filenames, and fields whose label is never spoken.
4. Testing with disabled people. The only method that surfaces problems the guidelines do not describe, and the only one that changes how a team thinks about the work.

Zoom to 400 percent deserves a mention of its own, being both a conformance requirement and a proxy for build quality: a layout that survives it without horizontal scrolling or content loss is almost certainly built on relative units and a sane grid. This is part of why we treat accessibility as interface design rather than a QA phase.

The accessibility statement, and how to write one that helps

W3C guidance says a statement should carry a commitment to accessibility for people with disabilities, the standard applied, and contact details for anyone who hits a problem. It advises also naming known limitations, the steps taken, technical prerequisites such as compatible browsers, and links to the relevant national law. EU public sector bodies have a harder requirement under the Web Accessibility Directive: a statement for each site and app naming non-accessible content and alternatives, plus a feedback mechanism so users can flag problems or request an accessible version.

Most published statements are useless because they assert full conformance and stop. A useful one does the opposite: which standard and level you target, which parts do not yet meet it and why, the alternative route meanwhile, when you expect to fix it, and how to reach a human today. That is more defensible than a blanket claim and considerably more respectful of the person reading it, who is usually reading it because something has just failed them. Review it whenever the site changes materially; a statement dated two redesigns ago is evidence of neglect rather than diligence.

Designing it in costs less than bolting it on

The economics are not subtle, and they are the strongest argument you have internally.

Contrast is decided once, in a palette. Fix it while the palette is being chosen and it costs a conversation. Fix it after two hundred pages have been built on that palette and it is a site-wide regression test. Focus states are the same: define them once in a component library and every button inherits them.

That is why we set accessibility as a constraint during web design rather than as a phase after it — contrast pairs measured when the palette is chosen, focus and error states drawn when components are drawn, heading structure specified in wireframes. The engineering team then receives an annotated design rather than a picture. The same discipline makes future work safer, since a site built on semantic markup and a documented component set can be re-skinned without re-auditing every interaction — worth remembering when planning a redesign that must not break what already works.

A remediation plan in priority order

Given an existing site and a real audit report, the order below removes the most harm per unit of effort. It is deliberately not the order a scanner lists findings in, because a scanner sorts by rule rather than by consequence.

1. Restore visible focus everywhere. Usually one CSS change. It converts a site that is unusable without a mouse into one that is merely imperfect.
2. Fix anything that blocks a transaction. Checkout, login, contact, booking, account recovery. A blocked purchase is both the largest harm and the largest commercial cost, and if a storefront is in scope this overlaps directly with e-commerce work.
3. Give every control an accessible name. Icon-only buttons, links that read “read more”, fields whose only label is a placeholder.
4. Fix contrast at the token level, not per page. If one failing pair appears ninety times, you have one fix, not ninety.
5. Repair heading structure and landmarks. This is how screen reader users navigate, and it is usually wrong in a consistent way, which makes it cheaper than the audit implies.
6. Associate errors with their fields, in text — programmatic association, a message, and an explanation of how to correct the input.
7. Work through the WCAG 2.2 additions. Target sizes, dragging alternatives, focus obscured by sticky elements, paste-blocking on authentication.
8. Write alt text properly. Slower than it looks, because it needs judgement per image. Decorative images get an empty alt attribute; informative ones get a description of the information, not of the picture.

Two process notes: fix the component rather than the instance, or you will do this again next year, and add the CI check at step one so the fixes stay fixed.

Apps, PDFs and third-party embeds

Three areas sit outside “the website” and are routinely missed in scoping.

Native mobile apps. EN 301 549 covers mobile applications, and the DOJ rule for US state and local government covers them explicitly alongside web content. The platforms supply the machinery — accessibility labels, traits, Dynamic Type, TalkBack — but only if the app uses standard controls or declares custom ones properly. An app built from custom-drawn views with no labels is as opaque as a page full of unlabelled divs, so budget for it inside mobile app development rather than discovering it at submission.

PDFs. A scanned document is an image of text, inaccessible by definition until tagged, and tagging a large back catalogue is genuinely expensive — one of the few places a disproportionate burden argument is regularly legitimate. The cheaper strategy is to stop producing new PDFs for content that should be HTML. Most policy documents, price lists and guides are better as web pages anyway.

Third-party embeds. Payment widgets, booking engines, chat, review carousels, consent banners. You are responsible for your service as delivered, including the parts you rented. The consent banner is the most consistently guilty: it appears first, traps focus badly, and often covers the focused element, which is now a named WCAG 2.2 failure. Ask vendors for conformance documentation before you integrate, and expect the answer to be a marketing page rather than a report.

When to get help, and when not to

If your failures are the six that automated tools detect, you probably do not need an agency. Buy a scanner licence, fix contrast in the theme, add labels and alt text, and put a check in the pipeline. That work is well documented and within reach of any competent front-end developer.

Get help when the problems are structural rather than cosmetic: an interface built from custom components carrying no semantics, a checkout that cannot be completed by keyboard, a legal deadline with no baseline, or a need for an audit that will survive scrutiny rather than a scan you ran yourself. If you want a view on which of those you are in, tell us what you are working with.