Web Accessibility: How to Audit and Fix Your Site to WCAG 2.2 AA
95.9% of the most visited home pages on the web fail at least one automated accessibility check, and Europe just moved the bar to WCAG 2.2 AA. The fix is not a tool: it is a three-layer web accessibility audit.
Why September 2026 Moved the Bar
Accessibility stopped being a goodwill recommendation and became a technical obligation with dates attached. Within a few weeks, a European standards change, a US extension and an industry report landed together, and the report confirms the worst: the web is not improving, it is getting worse.
EN 301 549 v4.1.1: Europe Swaps WCAG 2.1 for WCAG 2.2 AA (and What It Takes to Become the Legal Reference)
On September 2, 2026, version 4.1.1 of the European standard EN 301 549 was published, adopting WCAG 2.2 as the technical reference for websites, software and digital documents instead of WCAG 2.1. It is the standard used to demonstrate conformance with the European Accessibility Act, in force since June 28, 2025.
The nuance matters: a harmonized technical standard is not law by itself. Its full legal effect arrives when it is cited in the Official Journal of the European Union, so today the previous version is still the legal reference while the transition completes. For a team planning a year ahead, the direction is already set: audit against WCAG 2.2 AA, not 2.1.
Read also
The Other Clock: ADA Title II and the 2027 and 2028 Deadlines
In the United States, the 2024 Department of Justice rule requires WCAG 2.1 AA for state and local government entities. In April 2026 the DOJ published an interim final rule that pushed the deadlines by one year: entities with a population of 50,000 or more have until April 26, 2027, and smaller entities and special district governments until April 26, 2028. An extension does not change what needs to be done, only when.
The Uncomfortable Number: the WebAIM Million 2026 Says We Are Getting Worse
WebAIM's annual analysis of one million home pages found detectable failures on 95.9% of them, up from 94.8% in 2025. The average rose to 56.1 errors per page, 10.1% more than the 51 found the year before, with more than 56 million distinct errors overall. Low-contrast text appeared on 83.9% of the pages. These are failures detected automatically on home pages, not a verdict that those sites are unusable, but the trend leaves no room for optimism.
What WCAG 2.2 AA Actually Requires
W3C guidelines are organized around four principles: content must be perceivable, operable, understandable and robust. Every success criterion carries a level: A, AA or AAA. The legal frameworks above ask for AA, because it balances real impact on users with a reasonable implementation effort. Targeting AAA everywhere is not the goal; covering AA consistently is.
The 9 New Success Criteria in WCAG 2.2 (and the One That Was Removed)
WCAG 2.2, a W3C Recommendation since October 2023, adds nine criteria over 2.1 and retires one. The new ones, with their level:
- 2.4.11 Focus Not Obscured (Minimum) — AA.
- 2.4.12 Focus Not Obscured (Enhanced) — AAA.
- 2.4.13 Focus Appearance — AAA.
- 2.5.7 Dragging Movements — AA.
- 2.5.8 Target Size (Minimum) — AA.
- 3.2.6 Consistent Help — A.
- 3.3.7 Redundant Entry — A.
- 3.3.8 Accessible Authentication (Minimum) — AA.
- 3.3.9 Accessible Authentication (Enhanced) — AAA.
The retired criterion is 4.1.1 Parsing: modern browsers no longer depend on perfectly nested markup, so the requirement was removed rather than improved.
The 6 Failures That Show Up in Almost Every Audit
Fix only these and you cover most of what any report flags:
- Images with no alternative text, or with a useless
alt. - Text contrast below 4.5:1.
- Form fields with no associated label.
- Headings out of order, or sized rather than ranked.
- Buttons and links with no accessible name.
- Keyboard focus that is invisible or removed with CSS.
Layer 1: The Automated Audit
The first layer reads the DOM and checks objective rules. It is fast, cheap and repeatable, which is why it is the only layer that makes sense to keep running continuously on its own. It is also the most misleading when treated as the whole truth: it covers part of the criteria, not all of them.
What axe-core Catches and What It Misses
axe-core, Deque's open-source rule engine, powers many extensions and tools. It is good at the mechanical: a missing alt, a contrast ratio calculable between two solid colors, a label not tied to any field, ARIA attributes prohibited for a role. It misses what depends on intent: whether tab order makes sense, whether an error message is understandable, or whether a component announced as a menu actually behaves like one.
Lighthouse and Chrome DevTools: How to Read the Report Without Trusting It
Lighthouse ships an accessibility section inside Chrome DevTools. Its score weights automated rules and does not measure total coverage, so a 100 in the report means "no automated problems were detected", not "this is accessible". Use it as a first filter and as starting evidence, never as a certificate.
Running It in CI with pa11y: Thresholds, Routes and Failing the Build
The way to keep errors from coming back is to turn the automated layer into a test that breaks continuous integration. Tools like pa11y let you point at your main routes and set a failure threshold: if the number of issues rises, the pipeline stops. The exact syntax changes between versions, so pin it against the project's official docs instead of copying it from a blog. Start with the critical routes — homepage, listing, detail page and contact form — and expand later.
Layer 2: Manual Testing, No Screen Reader
The second layer is done by a person, with a keyboard and a browser. This is where failures that break the real experience show up, the ones no machine can judge.
A Full Keyboard-Only Run: Visible Focus, Logical Order and Traps
Navigate the whole page without touching the mouse, using Tab, Shift+Tab, Enter and space. Check three things: focus is always visible (never remove it with outline: none), tab order follows the visual and logical order, and you can leave every component. A dropdown that traps focus and will not close from the keyboard is a serious failure. The correct pattern for skipping navigation is a "skip to content" link that becomes visible when it receives focus.
200% Zoom, 320px Reflow and Text Spacing
Zoom the page to 200%: content must keep working without losing information or forcing horizontal scrolling. Shrink the window to 320 pixels wide: the layout must reflow to a single column without clipping. Increase line, paragraph and letter spacing with a user extension: text must not overlap or disappear.
Contrast and Target Size: Measure, Don't Guess
Level AA requires a 4.5:1 contrast ratio for normal text, 3:1 for large text (criterion 1.4.3) and 3:1 for user interface components and graphical objects (1.4.11). Use a contrast checker with the exact values, not your eye. In WCAG 2.2, criterion 2.5.8 Target Size (Minimum) requires targets of at least 24 by 24 CSS pixels, with exceptions for spacing, inline equivalence, essentiality or user-agent control. Tiny buttons packed together fail here.
Layer 3: Screen Reader and Semantics
The third layer closes the loop on semantics: someone navigates the site with a screen reader and hears what gets announced. It is the dimension the other two do not see, because it depends on interpreted structure.
What NVDA and VoiceOver Announce, and What They Miss
NVDA is free on Windows; VoiceOver ships with macOS and iOS; JAWS is the commercial option. Running through a page with them surfaces failures automated tools do not flag: headings nested out of order that break the rotor's index, a button that only says "click", a table read as a list of numbers. Test heading navigation with the rotor or heading list to confirm the order makes sense.
Semantic HTML Before ARIA: the Fixes That Solve the Most Failures
The rule that saves the most work is simple: use the right element before reaching for ARIA. A <button> is already a button, it takes focus and activates from the keyboard. A <div> with onclick is none of that, and adding role="button" without handling the keyboard does not fix it. The same goes for <nav>, <main> and <label>. ARIA is for what HTML cannot express, not a patch for poor markup.
Forms, Error Messages and Dynamic Content
Tie every field to its label with for and id. Show errors with text, not just a border color: "the email address is not in a valid format" is useful, a red border is not. When a block of content changes without a page reload, wrap it in a container with aria-live="polite" so the screen reader announces it. And never mark required fields with a visual asterisk alone: signal it with text or the proper attribute too.
What an Accessibility Overlay Will Not Fix
Widgets and automated overlays promise conformance with a single line of code. They do not deliver it. Conformance is proven with technical evidence — accessible code, documented testing, a statement — not with a script installed on top. An overlay can hide some visible symptoms while leaving the cause intact: the underlying markup is still the same. If a vendor sells you "guaranteed accessibility with a widget", that is the moment to ask for the evidence, not the badge.
The Accessibility Statement: the Document You Will Be Asked For
The European framework requires publishing an accessibility statement, and audits ask for it as evidence. It is a short document: the level of conformance reached, the known problems and the parts that are not accessible, the contact channel for reporting barriers, and the date of the last review. Writing it honestly forces you to have the results of all three layers, so treat it as the output of the process, not the final decoration.
Conclusion
A web accessibility audit is not a list of 87 criteria: it is a three-layer process where each layer sees what the others cannot. The machine reads the code and catches the mechanical; the keyboard and zoom verify behavior; the screen reader judges the announced structure. Fixing the foundation patterns — semantics, focus, contrast, forms — pays off more than chasing individual criteria, and keeping the automated layer in continuous integration stops the same errors from returning with every change.
If this approach was useful, the blog has more foundational HTML and CSS guides: keep going with Laravel 13 technical SEO, with page transitions using the View Transitions API and with scroll-linked animations in pure CSS, which apply the same idea: understand the mechanism before writing the code.
