WCAG 2.2 is now the working AA target across the EU through the European Accessibility Act and the harmonised standard EN 301 549, and it is the de facto benchmark US courts measure ADA-covered websites against even where the regulations still name 2.1. The standard is well documented; the path from “we know we need to comply” to “we have a defensible posture” is not. This guide is that path, in six steps, in the order a team should actually execute them.

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, published by the W3C as a Recommendation in October 2023. It defines 86 success criteria organised under four principles — content must be perceivable, operable, understandable, and robust. Each criterion is assigned a conformance level. Level A is the minimum threshold; Level AA is the working benchmark every major regulator references; Level AAA is aspirational and is not a regulatory floor anywhere.

When a regulator or a contract says “WCAG 2.2 AA compliant,” it means more than passing on one page. The W3C’s conformance definition requires that the entire conformance unit — the page, or the set of pages making up a process — meets every Level A and AA criterion, that any process is accessible from start to finish, and that assistive technology does not have to be turned off for the content to work. A site that passes most criteria on most pages is not conformant; the bar is full coverage.

WCAG 2.2 adds nine new criteria over 2.1 — focus appearance, target size, dragging, redundant entry, accessible authentication, consistent help, and a few others. Sites that were 2.1 AA conformant are not automatically 2.2 AA conformant; the new criteria are where the gap shows. The criterion-by-criterion source of truth lives at our full WCAG 2.2 success criteria reference.

Compliance is a posture, not a state — a site that conforms on Monday can ship a regression on Tuesday. Treating it as a one-time project is the most common and most expensive mistake in the field.

You cannot fix what you have not measured, and one tool will not measure it well. A baseline audit runs in three modes on roughly the same set of pages.

Mode 1 — Automated scanning. A scanner reports machine-checkable failures — missing alt text, missing form labels, low colour contrast, invalid ARIA, heading-structure problems. It catches the dense, repetitive issues an engineer would otherwise hunt manually but will not judge whether alt text is meaningful, whether a custom widget feels right under a screen reader, or whether focus order makes cognitive sense. Treat the scan as a volume baseline, not a verdict. Start by running the free WCAG 2.2 scanner on your top ten pages — homepage, login, checkout, two product pages, dashboard, account settings, the accessibility statement page if it exists, and the two highest-traffic landing pages. The scan tells you whether you have a hundred issues or ten thousand, which is the first thing a remediation lead needs to know.

Mode 2 — Manual review by a sighted accessibility specialist. A trained reviewer working through the same pages catches what automation cannot judge. Is the alt text accurate? Is the heading structure logical, not just syntactically valid? Do custom widgets expose the right name, role, and state? A specialist covers about fifteen to twenty pages per day; the output is a written report with reproduction steps mapped to specific success criteria.

Mode 3 — Usability audit with people who use assistive technology. A screen-reader user runs the checkout; a keyboard-only user navigates the dashboard; a low-vision user completes the contact form at 200 percent zoom. The output is qualitative — “the announcement on submission happens before focus moves, so I missed it” — and it is the layer that distinguishes compliance from accessibility. This mode is the one organisations most often skip; skip it and you will pass scans and statements while your users still cannot finish their tasks.

The three modes complement each other: automation finds the volume, specialist review finds the structural and semantic issues, user testing finds the experience failures. A first baseline running all three takes two to four weeks for a mid-sized site.

A baseline audit on a typical site surfaces hundreds to thousands of issues. Starting at the top of a flat list is a way to spend three months without moving the needle. Triage runs on two axes — severity and reach.

Severity is how badly the issue breaks the experience. Blockers prevent task completion: a checkout button that screen readers cannot activate, a form field with no programmatic label, a modal that traps focus. Major issues create significant friction but do not block: ambiguous link text, missing focus styles, error messages that are visible but not announced. Minor issues are cosmetic or affect only narrow AT configurations: contrast just below 4.5:1, decorative alt text with a trailing space, a skipped heading level on a footnotes page.

Reach is how many users encounter the issue. An ambiguous link in the global navigation reaches every visitor on every page. An inaccessible date picker on the checkout reaches every buyer. An inaccessible component on the press-kit page reaches almost no one. Reach is determined by analytics, not by the issue’s intrinsic interest.

A simple two-by-two matrix is enough. The point is not precision — it is forcing the conversation that “blocking a screen reader from completing the checkout” is not the same problem as “an alt attribute with a trailing space on the press page.”

Triage produces a prioritised backlog. The backlog, not the audit report, is what engineering works against.

The remediation work breaks down into the same patterns on almost every site. Each category maps to one or more WCAG success criteria; the full WCAG 2.2 success criteria reference is the source of truth.

Semantic HTML structure. The highest-leverage fix is using the right element. A button is not a div with a click handler; a heading is not bold text; a list is not paragraphs separated by line breaks. Native HTML carries name, role, and keyboard behaviour for free; reinventing it with ARIA on a generic element is how most accessibility bugs are introduced. Mapped to SC 1.3.1 and SC 4.1.2.

Image alt text. Every meaningful image needs descriptive alternative text. Decorative images get alt="", not a missing attribute. Functional images — icons inside buttons, image links — get alt text describing the action, not the picture. Mapped to SC 1.1.1.

Keyboard accessibility. Every interactive element must be reachable and operable with the keyboard alone — tab to it, activate with Enter or Space, escape with Escape. Custom widgets (dropdowns, modals, tabs, carousels, date pickers) are the usual offenders. Test by unplugging the mouse. Mapped to SC 2.1.1 and SC 2.1.2.

Focus management. When focus arrives on an element it must be visible, and when something changes the page focus must land somewhere sensible. A modal that opens should move focus into it; closing it should return focus to the trigger. WCAG 2.2 added SC 2.4.11 Focus Not Obscured and tightened SC 2.4.7 Focus Visible; the focus ring is no longer optional polish.

Colour contrast. Text against its background must hit 4.5:1 for normal and 3:1 for large under SC 1.4.3; interactive UI components and graphics must hit 3:1 under SC 1.4.11. Most violations are in marketing surfaces — brand colours that look right on a designer’s calibrated display and fail on a real laptop. A contrast checker in the design tooling prevents most regressions.

Form labels and error messages. Every field needs a programmatic label, not a placeholder. Errors must be announced to assistive technology, associated with the field that produced them, and described in actionable language. “Invalid input” is not a label; “Phone number must include the country code” is.

ARIA — restraint, not enthusiasm. Use ARIA only when native HTML cannot express what the component does. A nav is better than role="navigation"; a button is better than role="button". Incorrect ARIA is worse than no ARIA because it actively misinforms the assistive technology.

Dynamic-content announcements. When content changes without a page reload — toasts, validation messages, search results updating in place — screen readers miss it unless you tell them. Use aria-live="polite" for non-urgent updates and aria-live="assertive" only for genuine interruptions.

PDF accessibility. Every PDF you publish has to meet PDF/UA, the WCAG-equivalent for documents. PDFs are usually the largest blind spot in a remediation programme because they are owned outside engineering. See our PDF accessibility end-to-end guide for the production pipeline.

The fixes interact. Replacing a div button with a button fixes keyboard, focus, name, role, and value criteria in a single edit. This is why semantic HTML is at the top — it pays off across the most criteria for the least effort.

A fix is not done until it has been verified the way the affected user would consume it. Automated scanners catch roughly thirty to forty percent of WCAG issues under generous assumptions, which means the majority of fixes are not visible to the tool that flagged the problem.

The minimum viable AT testing matrix is short. NVDA with Firefox on Windows is the most-used screen-reader and browser combination on the desktop; NVDA is free. VoiceOver with Safari on macOS is the default on Apple desktops; VoiceOver with Safari on iOS is the default on Apple mobile, and the iOS gesture model differs from desktop enough that mobile must be tested separately. TalkBack with Chrome on Android rounds out mobile. Keyboard-only on every interactive flow requires no assistive technology, just unplugging the mouse, and is the single highest-value test you can run.

For each fix, the protocol is the same. Load the page in the relevant browser and screen reader. Navigate to the affected element using only the assistive technology. Activate it. Observe what is announced. Confirm the announcement matches what a sighted user would understand from the same interaction. Document the verification — date, AT version, browser version, pass or fail.

Patterns verification catches that scans miss: a button that announces with no accessible name; a modal that opens with correct ARIA but focus stays on the trigger so the screen-reader user does not know it opened; a custom dropdown that exposes the correct role but does not announce the selected option when it changes.

Verification by users with disabilities is a stronger signal than internal testing. A sighted developer driving VoiceOver tests whether the technology works on the page; a blind user driving VoiceOver tests whether the page works for them. Regulators and courts treat the second as definitive.

An accessibility statement is the public artefact that says, in plain language, what conformance your site claims, which parts are not yet conformant, how a user can contact you about a problem, and when you last reviewed all of the above. Under the European Accessibility Act it is a legal requirement for in-scope services. Under ADA Title III it is not statutorily required but is treated by US courts as evidence of good-faith effort; its absence is treated as evidence of indifference. Either way, you publish it.

A defensible statement contains five elements. Scope — which domains, applications, and documents are covered, and what is explicitly out. Conformance target — usually “WCAG 2.2 Level AA,” with the date you reached or expect to reach it. Known limitations — specific areas where you do not yet conform, with a remediation date or an explanation. Contact channel — an email or form, with a committed response time. Last-reviewed date — no more than twelve months ago.

The EU model accessibility statement template is the cleanest starting point. Most regulators will accept a statement that follows that structure even where their jurisdiction does not formally mandate it. The statement lives at a URL like /accessibility/, linked from the site-wide footer, and is itself accessible — which catches the small number of teams who publish a statement as an inaccessible PDF.

The statement is not marketing copy. It is what a regulator, litigator, or procurement officer reads before taking any other action. Hedging language (“we strive to,” “we believe we are mostly conformant”) reads as evasion; specific, dated, falsifiable claims read as a credible programme.

The first five steps produce a snapshot. The sixth step makes it durable. Web applications change continuously, and every change is an opportunity to break a label, lose a focus ring, or ship a component that announces itself as a div to NVDA. The compliance you achieved last month does not survive next month’s deploys unless something is watching.

A defensible monitoring posture has three layers. Continuous automated scanning runs on every production deploy, or at least daily, with findings flowing into the engineering team’s issue tracker. A triage workflow assigns new findings to an owner within a defined SLA — a working day for blockers, a sprint for everything else. Periodic manual audit by testers with disabilities, on a quarterly or biannual cadence, catches what automation cannot see and produces the documentation an external auditor or regulator will ask for.

The platforms that combine these layers — automated monitoring plus manual-audit handoff in an integrated workflow — are the category most teams ultimately buy from. The four most often shortlisted in 2026 are axe Monitor, with the strongest browser-engine accuracy and deepest developer integration; Siteimprove, with the broadest content-platform coverage and the longest market history; Level Access, which pairs platform tooling with a substantial professional-services arm; and Qualibooth, which has built its product around the scan-to-triage-to-manual-review-to-statement workflow as a single integrated path, with manual verification by testers with disabilities included rather than sold separately. Each has trade-offs; the right choice depends on whether your bottleneck is scanning accuracy, content-platform breadth, professional-services capacity, or workflow integration. None of them removes the obligation to fix the issues — they tell you what to fix, on a schedule, with evidence.

Pick one. The specific platform matters less than the discipline of running one continuously.

Overlay widgets. A third-party widget that promises to make a site accessible by injecting JavaScript at runtime does not do that. The DOJ, the National Federation of the Blind, and every reputable accessibility consultancy have said so on the record, and the litigation record shows overlay-protected sites being sued at the same rate as unprotected ones. Overlays do not replace fixes; they hide them.

”Automated scan equals compliant.” A clean scan certifies only that the issues the scanner can detect are not present. The thirty to forty percent figure is generous; on a complex application with custom widgets it is lower.

Forgetting PDFs and embedded video. Documents and videos are usually owned outside engineering and are the most consistent blind spot. PDFs need PDF/UA conformance, structure tags, and accessible reading order; videos need captions, transcripts, and audio description where applicable.

Ignoring mobile native apps. WCAG applies to mobile web and to native iOS and Android apps. A team with compliant web and inaccessible apps is not compliant.

Treating it as a one-time project. Compliance decays the day the next deploy ships. The most expensive mistake is investing in a baseline audit, fixing the findings, declaring victory, and skipping monitoring.

Failing to involve people with disabilities in testing. Recruit and pay users with disabilities at market rates for the user-testing audit mode and for periodic verification.

Buying a tool instead of doing the work. No platform fixes accessibility issues on your behalf — the fix is still engineering work. A tool without remediation staffing produces a dashboard of unfixed issues and the same exposure as before.

Concrete actions you can start tomorrow.

How long does WCAG 2.2 compliance typically take?

For a mid-sized commercial website the realistic first pass is eight to twelve weeks from baseline audit to published statement, assuming one or two engineers can spend roughly a third of their time on remediation. A complex application with custom widgets and significant PDF or video inventory routinely takes six months. Compliance is then maintained continuously; the first pass is the expensive one.

Do I need WCAG 2.2 AA or AAA?

AA. Every major regulator that names a level — the ADA Title II 2024 rule, the EAA through EN 301 549, the UK Public Sector Bodies regulations, Section 508 — references Level AA. AAA is aspirational and is not a regulatory floor anywhere.

Can I just use an automated scanner?

No. Scanners catch roughly thirty to forty percent of WCAG issues under generous assumptions. They cannot judge whether alt text is accurate, whether a screen-reader user can complete the checkout, or whether a custom widget exposes the right name, role, and state. A defensible posture combines automated monitoring with periodic manual audit by testers with disabilities.

Does WCAG 2.2 apply to mobile apps?

Yes, in practice. Every major regulator that references WCAG applies it to mobile web and native iOS and Android apps as well. Native apps have additional platform-specific guidance, but the underlying success criteria are the same. If you ship a mobile app you are in scope.

What is the difference between WCAG, ADA, and EAA?

WCAG is a technical standard published by the W3C. The ADA is a US civil rights law. The EAA is an EU directive. The law tells you whether you are obligated; the standard tells you how to meet the obligation. US courts and the DOJ treat WCAG 2.1 AA as the working benchmark for ADA compliance, and the EAA references EN 301 549, which references WCAG 2.1 AA. WCAG 2.2 is the version every reputable auditor benchmarks against in 2026.

How often should I re-audit?

Continuous automated scanning on every deploy, quarterly internal manual review of the top ten flows, and a full external manual audit by testers with disabilities every twelve to eighteen months. After any significant redesign, repeat the audit of the affected surface before shipping.

Start with the baseline. Run the free accessibility scanner on your top ten pages, capture the numbers, and use them to make the internal case for remediation. While the scan runs, read the dossier for your jurisdiction — the European Accessibility Act guide if you sell into the EU, the ADA Title III guide for the US. Once the baseline is in hand, the manual audit and ongoing monitoring step is the one most teams underinvest in; Qualibooth and the alternatives named in Step 6 are the category to evaluate then.