How to Make Your Website WCAG 2.2 Compliant

Making your website WCAG 2.2 compliant is a process, not a one-time fix. Compliance is the outcome of a repeatable workflow: understand the standard, measure where you stand, fix the right things in the right order, validate with real assistive technology and real users, document the result, and keep it from regressing. This guide turns that workflow into a concrete, step-by-step roadmap your team can start using today — without resorting to accessibility “overlays,” which mask problems in the DOM rather than fixing them and have repeatedly been named in lawsuits.

Step 1: Understand what WCAG 2.2 actually requires

Before you audit anything, get clear on the target. The Web Content Accessibility Guidelines are organized around four principles, summarized by the acronym POUR:

• Perceivable — users must be able to perceive the content. Think text alternatives for images, captions and transcripts for media, and sufficient color contrast.
• Operable — every function must work without a mouse. Full keyboard operability, visible focus indicators, and no keyboard traps are core requirements.
• Understandable — content and behavior must be predictable. Clear labels, consistent navigation, helpful error messages, and readable language all live here.
• Robust — the markup must be parseable by current and future assistive technology, which in practice means valid HTML and correct use of ARIA names, roles, and values.

Each principle breaks down into testable success criteria, and each criterion is assigned a conformance level: A (essential), AA (the legal and practical baseline most organizations target), and AAA (enhanced). When people say “WCAG 2.2 AA,” they mean conforming to every Level A and Level AA success criterion. WCAG 2.2 adds nine new criteria over 2.1 — including Focus Not Obscured, Dragging Movements, Target Size (Minimum), and Accessible Authentication — most of which improve the experience for keyboard, low-vision, and motor-impaired users.

It helps to know why this is the target. AA conformance is referenced by the laws and regulations that most likely apply to you: read up on WCAG compliance as the technical standard, then see how it maps to the European Accessibility Act, the ADA for private and public US entities, and Section 508 for US federal agencies and their vendors. If terminology trips you up along the way, keep our accessibility glossary open in a tab.

Two more concepts shape any honest conformance claim. The first is conformance scope: WCAG conformance applies to full pages, not isolated components, and to complete processes (e.g., an entire checkout flow) — you can’t claim a page is conformant if one step in a multi-step task fails. The second is accessibility-supported technology: you may only rely on ways of using a feature that are actually supported by the assistive technology your users have. In practice this means testing with current screen readers and browsers rather than assuming that valid markup alone guarantees a usable result. Keep both in mind as you scope your work in the steps below; they determine what you can defensibly say you’ve achieved.

Step 2: Run an automated baseline scan

You can’t fix what you can’t measure, so establish a baseline. Automated testing is fast, repeatable, and excellent at catching the high-volume, mechanical failures that plague most sites: missing alternative text, low color contrast, empty links and buttons, unlabeled form fields, missing document language, and duplicate IDs.

Tools built on the open-source axe-core engine — including QualiBooth’s accessibility scanning software — produce a prioritized list of issues in minutes. If you just want a quick read on where you stand, start with a free accessibility scan of a few key pages.

A few rules to keep your baseline honest:

1. Scan representative templates, not your whole site. Test your home page, a content/article template, a product or category page, a form (sign-up, checkout, contact), and any authenticated dashboard. Fixing one template usually fixes hundreds of pages.
2. Test real states, not just the initial load. Open menus, expand accordions, trigger modals, and submit forms with errors. Many violations only appear in interactive states.
3. Record the numbers. Capture issue counts by severity and by success criterion. This is your before/after benchmark and the foundation of your remediation backlog.

Be honest about the ceiling: automated tools reliably detect only 30–40% of WCAG issues. A clean automated scan is necessary, but it is never sufficient for a real conformance claim.

Step 3: Complement automation with a manual audit

The remaining 60–70% of WCAG criteria require human judgment. Does this alt text actually convey the meaning of the image, or just describe pixels? Is the reading and focus order logical? Do error messages tell the user how to recover? Is a custom dropdown announced correctly, and can you reach and operate it with only a keyboard? No engine can answer these reliably.

A structured manual audit typically covers:

• Keyboard-only operation — tab through every interactive element; confirm a visible focus indicator, logical order, no traps, and that everything you can do with a mouse you can do without one.
• Semantic structure — headings in a meaningful hierarchy, landmarks, lists marked up as lists, tables with proper headers.
• Forms — programmatic labels, grouped fields, clear required-field indication, and error messages tied to the inputs they describe.
• Dynamic content — modals that trap and restore focus correctly, live regions that announce updates, and ARIA used only where native HTML can’t do the job.
• Content quality — meaningful link text, sufficient contrast in real contexts, and content that doesn’t rely on color or shape alone.

Our manual accessibility audits guide walks through the full methodology, and the common accessibility issues to avoid is a fast checklist of the failures auditors find most often. If you’d rather have it done for you, QualiBooth’s accessibility consulting team runs expert manual audits against the WCAG 2.2 AA criteria.

Step 4: Prioritize and remediate

A long list of violations is overwhelming until you sequence it. Triage by combining user impact and reach:

1. Blockers first. Anything that makes a task impossible for a group of users — keyboard traps, an inaccessible checkout, an unlabeled login form — goes to the top regardless of how many instances exist.
2. Then high-frequency, site-wide issues. A contrast or focus problem in your header, footer, or design system component multiplies across every page. Fixing it once delivers the biggest return.
3. Then page-specific and content issues. Individual missing alt text, a single mislabeled control, or a one-off heading gap.

When you remediate, fix the source, not the symptom. Prefer native HTML elements over ARIA-patched <div>s; correct the design-system component rather than each page that uses it; and address root causes in templates and shared components so the fix scales. Re-scan after each batch so you can see counts fall and avoid introducing regressions. This is also the right moment to bake accessibility into your design tokens — set contrast-safe colors, a minimum 24×24 px target size, and visible focus styles as defaults so new work starts compliant.

A few remediation patterns recur often enough to call out explicitly:

• Use the platform. A native <button>, <a href>, <input>, <select>, and <dialog> come with keyboard behavior, focus management, and a correct accessible name for free. Reach for ARIA only to fill genuine gaps — and remember the first rule of ARIA: don’t use ARIA if a native element will do.
• Name things programmatically. Every control needs an accessible name from a <label>, aria-label, or aria-labelledby — not just nearby visual text. Icon-only buttons are the most common offender.
• Manage focus deliberately. When a modal opens, move focus into it, trap it while open, and return it to the trigger on close. When content updates without a navigation, use a live region so screen-reader users hear what changed.
• Don’t encode meaning in color or shape alone. Pair color with text, icons, or patterns so the information survives for colorblind and low-vision users.

Track remediation in your normal issue tracker, tagged by success criterion, so accessibility work is visible alongside everything else rather than living in a separate spreadsheet that goes stale.

Step 5: Test with assistive technology and people with disabilities

Conformance is ultimately about whether real people can use your site. Two layers of validation matter here, and they are not interchangeable.

Screen reader testing. Verify your fixes against the assistive technology people actually use: NVDA or JAWS with Chrome/Firefox on Windows, and VoiceOver with Safari on macOS and iOS. Listen for accurate names, correct roles, announced state changes, and a sensible reading order. A screen reader evaluation gives you a professional pass across the major combinations if your team lacks the experience.

Usability testing with disabled users. Passing every success criterion is the floor, not the ceiling — a site can be technically conformant and still be frustrating to use. The most reliable signal comes from audits by people with disabilities, who test with their own assistive technology and habits and surface barriers that checklists miss. This is the difference between meeting the letter of the standard and delivering true digital accessibility.

Step 6: Document conformance (statement and VPAT/ACR)

Once you’ve remediated and validated, capture the result. Documentation is what turns “we tried” into a defensible, communicable claim.

• Accessibility statement. A public page that states your conformance target (e.g., WCAG 2.2 AA), describes what you’ve done, lists any known limitations, and gives users a way to report problems. Many regulations, including the EAA, expect one.
• VPAT / Accessibility Conformance Report. A Voluntary Product Accessibility Template, completed, becomes an ACR — the standard artifact procurement teams and enterprise buyers request as evidence. Our what is a VPAT/ACR guide explains the document, and the VPAT reports service produces an accurate, audit-backed report you can hand to customers and legal teams.

Write these against evidence from your actual audit results, not aspirations. A VPAT that overstates conformance is a liability, not an asset.

Step 7: Maintain compliance over time

Accessibility regresses the moment a site changes — a new component, a redesigned form, a third-party widget, or a content edit can quietly reintroduce barriers. Compliance is a state you maintain, not a milestone you pass once.

Build accessibility into your software lifecycle:

1. Shift left. Add automated checks to your pipeline with CI/CD accessibility integration so violations are caught on pull requests, before they ship — the cheapest possible place to fix them.
2. Monitor production. Schedule recurring accessibility audits to catch regressions and content drift that pre-release checks won’t see.
3. Empower your team. Equip designers, developers, and content authors with an accessibility toolkit and shared standards so accessibility is everyone’s default, not a specialist’s afterthought.
4. Govern at scale. For large or multi-site organizations, a platform like Agora centralizes tracking, reporting, and remediation across teams.

Mistakes that derail compliance efforts

Teams that stall usually do so for predictable reasons. Watch for these:

• Trusting automation alone. A green automated report covers only a third of the criteria. Treating it as proof of conformance is the single most common — and most legally risky — mistake.
• Buying an overlay. Overlays and “accessibility widgets” promise instant compliance by injecting JavaScript that overrides the page. They don’t fix the underlying code, frequently interfere with users’ own assistive technology, and have been named in a growing number of complaints. They are a shortcut to risk, not to compliance.
• Fixing pages instead of systems. Remediating individual pages while leaving the design system broken means every new page reintroduces the same defects. Fix shared components and templates first.
• Treating it as a one-off project. Without CI/CD checks and recurring audits, a compliant site drifts out of conformance within a few release cycles.
• Skipping real users. Technical conformance without usability testing can still leave disabled users unable to complete core tasks.

Avoiding these keeps your investment from leaking away the moment the project “ships.”

Putting it all together

A realistic path to WCAG 2.2 AA looks like this: learn the POUR principles and the AA target, run an automated baseline, layer on a manual audit, remediate by impact and reach, validate with screen readers and disabled users, document your conformance in a statement and VPAT, and then keep it healthy with CI/CD checks and recurring audits. Each step compounds the last — and none of it depends on an overlay that papers over the real code.

Start small and build momentum: scan a handful of templates this week, fix your design system’s contrast and focus styles, and put one automated check in your pipeline. From there, the roadmap above takes you the rest of the way. When you’re ready to accelerate, explore our pricing, request a demo, or talk to an expert about a remediation plan tailored to your stack.