WCAG 2.2 AA Checklist: Audit & Remediate for 2026 Compliance

WebAIM's 2026 analysis of one million homepages found that 96.3% contain detectable WCAG failures, and six issue types account for 78% of all detected errors, according to this WCAG compliance statistics summary. That's why a WCAG 2.2 AA checklist matters in practice. It gives teams a shared remediation map instead of a vague promise to “be accessible.”

TL;DR

• WCAG 2.2 AA means meeting 55 success criteria total, including inherited criteria from 2.1 plus the six new Level AA additions, as summarized in this WCAG 2.2 AA overview.
• WCAG 2.2 was released on May 5, 2023, adding nine new success criteria overall, with six at Level AA, according to Level Access's WCAG 2.2 AA summary.
• The biggest 2.2 AA changes for most teams are focus visibility with sticky UI, drag alternatives, target size, consistent help, redundant entry, and accessible authentication.
• Target size now has a concrete AA threshold of 24×24 CSS pixels, including padding, as explained in this WCAG 2.2 target size guide.
• Automation alone won't get you there. Automated tools detect only part of the problem space, so you need scanning, manual review, assistive technology testing, and user validation. If your team needs the canonical audit path, start with the WCAG compliance checklist, then layer in an accessibility audit and ongoing accessibility monitoring.
• If you sell or serve in Europe, you should also achieve European Accessibility Act compliance as part of the same remediation program.

A good checklist also helps conversion rate optimization. Clear labels reduce form abandonment. Larger targets reduce mis-taps on mobile. Better focus handling improves checkout and account flows for keyboard and switch users. Strong accessibility work doesn't just lower compliance risk. It removes friction from your highest-value pages.

1. The Four POUR Principles

The best way to use a WCAG 2.2 AA checklist is to stop treating it like a pile of disconnected rules. WCAG organizes requirements under four principles: Perceivable, Operable, Understandable, and Compatible. That structure is the fastest way to turn audit findings into owned work across design, engineering, QA, and content.

For teams managing large sites, POUR also improves communication. A front-end lead understands “Operable issue in keyboard flow” faster than a raw criterion number. A content strategist can act on “Understandable issue in form instructions” without needing to decode technical specs. That's one reason many organizations anchor internal documentation to the web accessibility guidelines (WCAG).

How POUR works in real delivery

An e-commerce team might assign image, video, and contrast defects to design and content under Perceivable. The same team might assign keyboard traps, missing focus indicators, and drag-only interactions to front-end under Operable. Support content, form guidance, and account flows usually sit under Understandable. Semantic markup, ARIA behavior, and status message exposure fit under the principle of broad compatibility.

That division matters because accessibility projects stall when nobody owns the fix. They move when ownership follows the type of failure.

Practical rule: Group findings by POUR first, then by template or user journey second. That keeps executive reporting simple and remediation practical.

A simple ownership model

• Perceivable: Content and design own text alternatives, captions, contrast, and reading order.
• Operable: Front-end owns keyboard support, focus behavior, timing, gestures, and navigation consistency.
• Understandable: UX, product, and content own labels, instructions, error handling, authentication flow, and redundant entry.
• Compatible: Engineering and QA own semantic HTML, accessibility tree exposure, status messages, and component behavior in assistive tech.

If your team wants a checklist that gets used, POUR is the structure that keeps it operational instead of theoretical.

2. All 55 Level AA Success Criteria

WCAG 2.2 Level AA requires satisfying exactly 55 success criteria total, including inherited requirements plus the new 2.2 additions, according to this overview of digital accessibility policy guidelines. That number matters because teams often audit only the new items and miss inherited failures that still block conformance.

A reference-grade WCAG 2.2 AA checklist should turn every criterion into a plain-English test with a pass or fail signal. That's the format developers, QA analysts, and content editors can use in tickets and release reviews.

Perceivable and Operable criteria

Perceivable

• 1.1.1 Non-text Content: Every meaningful image or control has a text alternative. Pass if a screen reader gets the equivalent meaning.
• 1.2.1 Audio-only and Video-only (Prerecorded): Audio-only has a transcript, video-only has an equivalent alternative. Pass if users can access the content without the missing modality.
• 1.2.2 Captions (Prerecorded): Prerecorded video with audio includes captions. Pass if spoken content is captioned.
• 1.2.3 Audio Description or Media Alternative (Prerecorded): Important visual-only information is also available. Pass if key visuals aren't lost.
• 1.2.4 Captions (Live): Live audio in video is captioned. Pass if live viewers get synchronized text.
• 1.2.5 Audio Description (Prerecorded): Important visual details are narrated. Pass if users who can't see the video still get the missing context.
• 1.3.1 Info and Relationships: Structure is coded, not just styled. Pass if headings, lists, labels, and tables expose relationships.
• 1.3.2 Meaningful Sequence: Reading order makes sense. Pass if DOM order supports the intended sequence.
• 1.3.3 Sensory Characteristics: Instructions don't rely only on shape, size, or position. Pass if wording works without visual cues.
• 1.3.4 Orientation: Content works in portrait and different screen orientations unless essential otherwise. Pass if rotation doesn't break access.
• 1.3.5 Identify Input Purpose: Common form purposes are programmatically identified. Pass if fields support autofill semantics.
• 1.4.1 Use of Color: Color isn't the only cue. Pass if meaning survives without color perception.
• 1.4.2 Audio Control: Auto-playing audio can be stopped or controlled. Pass if users can silence it quickly.
• 1.4.3 Contrast (Minimum): Text contrast is sufficient. Pass if text remains readable against its background.
• 1.4.4 Resize Text: Text can scale without loss. Pass if zoomed text stays usable.
• 1.4.5 Images of Text: Real text is used instead of baked-in text where possible. Pass if users can resize and restyle content.
• 1.4.10 Reflow: Content reflows without two-dimensional scrolling at supported widths. Pass if users can read and operate with zoom.
• 1.4.11 Non-text Contrast: UI components and graphics have enough contrast. Pass if controls and focus indicators remain visible.
• 1.4.12 Text Spacing: Custom text spacing doesn't break content. Pass if nothing overlaps or disappears.
• 1.4.13 Content on Hover or Focus: Hover or focus content is dismissible, hoverable, and persistent. Pass if tooltips don't trap users.

Operable

• 2.1.1 Keyboard: All functionality works from a keyboard. Pass if mouse-free use is possible.
• 2.1.2 No Keyboard Trap: Users can move focus away from every component. Pass if keyboard users can always exit.
• 2.1.4 Character Key Shortcuts: Single-key shortcuts can be turned off or remapped when needed. Pass if accidental activation is prevented.
• 2.2.1 Timing Adjustable: Time limits can be adjusted when required. Pass if users can extend needed time.
• 2.2.2 Pause, Stop, Hide: Moving or auto-updating content can be controlled. Pass if users can stop distractions.
• 2.3.1 Three Flashes or Below Threshold: Content doesn't flash dangerously. Pass if flashing stays below threshold.
• 2.4.1 Bypass Blocks: Users can skip repeated blocks. Pass if a skip link or equivalent works.
• 2.4.2 Page Titled: Each page has a clear title. Pass if the title identifies purpose.
• 2.4.3 Focus Order: Tabbing follows a logical order. Pass if focus supports task completion.
• 2.4.4 Link Purpose (In Context): Link destination is clear from text or context. Pass if “click here” ambiguity is avoided.
• 2.4.5 Multiple Ways: More than one way exists to find pages. Pass if users can access pages by menu, search, sitemap, or equivalent.
• 2.4.6 Headings and Labels: Labels and headings describe topic or purpose. Pass if scanability improves.
• 2.4.7 Focus Visible: Keyboard focus is visible. Pass if users can track where they are.

A useful media workflow often overlaps with compliance and engagement. Teams that need stronger multimedia access should also improve video accessibility with captions.

Understandable and Robust criteria

Operable continued

• 2.4.11 Focus Not Obscured (Minimum): Focused elements aren't completely hidden by overlays or sticky UI. Pass if some portion remains visible.
• 2.5.1 Pointer Gestures: Complex gestures have a simple alternative. Pass if one-pointer operation works.
• 2.5.2 Pointer Cancellation: Users can avoid accidental pointer activation. Pass if activation isn't locked too early.
• 2.5.3 Label in Name: Accessible names include the visible label text. Pass if speech input users can match what they see.
• 2.5.4 Motion Actuation: Motion-triggered actions have alternatives. Pass if shaking or tilting isn't required.
• 2.5.7 Dragging Movements: Dragging has a non-drag alternative. Pass if click or tap can replace drag.
• 2.5.8 Target Size (Minimum): Targets meet minimum size or allowed exceptions. Pass if users can activate controls reliably.

Understandable

• 3.1.1 Language of Page: Page language is set. Pass if assistive tech announces it correctly.
• 3.1.2 Language of Parts: Language changes inside content are identified where needed. Pass if pronunciation switches correctly.
• 3.2.1 On Focus: Focus alone doesn't trigger unexpected context changes. Pass if tabbing stays predictable.
• 3.2.2 On Input: Input changes don't surprise users without warning. Pass if forms behave predictably.
• 3.2.3 Consistent Navigation: Repeated navigation appears consistently. Pass if patterns stay familiar.
• 3.2.4 Consistent Identification: Components with the same function are identified consistently. Pass if repeated controls keep the same naming.
• 3.2.6 Consistent Help: Help appears in a consistent place when provided. Pass if support options don't move around.
• 3.3.1 Error Identification: Errors are clearly identified. Pass if users know what went wrong.
• 3.3.2 Labels or Instructions: Inputs have labels or instructions. Pass if users know what to enter.
• 3.3.3 Error Suggestion: Fix guidance is offered when possible. Pass if users know how to recover.
• 3.3.4 Error Prevention (Legal, Financial, Data): Sensitive submissions are reversible, reviewable, or confirmed. Pass if costly mistakes are prevented.
• 3.3.7 Redundant Entry: Previously entered information doesn't need re-entry unless necessary. Pass if users aren't forced through duplicate effort.
• 3.3.8 Accessible Authentication (Minimum): Login doesn't depend on memory, transcription, or puzzle-solving without an alternative. Pass if users can authenticate without that barrier.

Strong

• 4.1.2 Name, Role, Value: Custom controls expose proper semantics and state. Pass if assistive tech announces them correctly.
• 4.1.3 Status Messages: Important updates are announced without moving focus. Pass if screen readers receive alerts like “item added to cart.”

3. WCAG 2.2 New Additions And What Changed From 2.1

WCAG 2.2 changes the audit scope in ways teams feel quickly. A site that passed WCAG 2.1 AA can still fail 2.2 on mobile checkout, account recovery, or any flow with sticky UI, drag actions, or small tap targets. That is why this 2026 checklist merges every inherited 2.1 AA requirement with the new 2.2 additions, instead of treating 2.2 as a short add-on.

The practical shift is straightforward. WCAG 2.2 closes gaps that showed up in real products, especially for keyboard users, touch users, and people with cognitive or memory-related access needs. The W3C's overview of what is new in WCAG 2.2 is useful for confirming the scope, but audits still need implementation judgment.

The six new Level AA criteria that change audit work

For AA conformance, these six additions are the ones that change remediation plans:

• 2.4.11 Focus Not Obscured (Minimum): Keyboard focus must remain visible and cannot sit behind sticky headers, consent banners, or floating UI.
• 2.5.7 Dragging Movements: Any function that uses dragging also needs a simple pointer alternative.
• 2.5.8 Target Size (Minimum): Interactive controls need enough hit area for touch and motor access.
• 3.2.6 Consistent Help: Help mechanisms need to appear in a consistent location across a set of pages.
• 3.3.7 Redundant Entry: Users should not have to re-enter information the system already collected.
• 3.3.8 Accessible Authentication (Minimum): Login and verification cannot depend on memorization, transcription, or solving a cognitive test unless an accessible alternative is available.

A side-by-side summary helps teams sort migration work faster. Key differences WCAG 2.1 vs 2.2 is a good reference for that comparison.

The three other new criteria people often mix into 2.2 planning

WCAG 2.2 also adds three criteria outside the AA set covered by this checklist:

• 2.4.12 Focus Not Obscured (Enhanced), Level AAA
• 2.4.13 Focus Appearance, Level AAA
• 3.3.9 Accessible Authentication (Enhanced), Level AAA

This distinction matters in audits. Teams often overstate the count of “new AA items” by mixing AAA into remediation tracking. For a 2026 AA checklist, keep the six new AA criteria in scope while still flagging the AAA items as design maturity targets if your organization wants to go beyond minimum conformance.

In practice, the defects users notice first are usually focus visibility, target size, and authentication. A sticky cart drawer can cover the focused button in a checkout flow. A close icon can be large visually but still fail target size because only the SVG path is clickable. A login flow can fail accessible authentication even with strong security if it forces users to copy a code from one device to another by memory or manual transcription.

Authentication is where trade-offs get real. Security teams may prefer friction that proves “human effort,” but WCAG 2.2 requires a path that does not depend on recall, puzzle solving, or precise transcription. Password managers, passkeys, magic links, paste-enabled one-time codes, and support-assisted fallback paths are common fixes that improve access without weakening account protection.

The net change from 2.1 to 2.2 is smaller in count than it is in impact. These additions hit common production patterns, and they expose failures that older checklists missed.

4. Removed Criterion 4.1.1 Parsing

One of the easiest migration mistakes is carrying old parsing findings into a WCAG 2.2 report. WCAG 2.2 explicitly removes criterion 4.1.1 Parsing because modern browser engines handle malformed HTML more gracefully, as explained in this summary of WCAG 2.2 new success criteria. That doesn't mean markup quality stopped mattering. It means conformance focus moved away from validation purity and toward user-impacting semantics.

A duplicate ID in a template is no longer a standalone WCAG 2.2 failure under 4.1.1. But if that same duplicate breaks aria-labelledby, the problem still fails under Name, Role, Value. That's the practical distinction teams need to understand.

What changed in real audits

Under WCAG 2.1, some reports were cluttered with validator-style issues that didn't map cleanly to a broken user experience. In 2.2, stronger audits drop those legacy parsing findings and keep issues that affect reading order, labels, announcements, state exposure, and interactive behavior.

Here's the difference in plain terms:

• Old parsing mindset: “The markup is invalid, so it fails.”
• Current accessibility mindset: “The user can't identify, operate, or understand this component, so it fails.”

What to keep fixing anyway

You should still write semantic HTML. Native buttons still beat clickable div elements. Proper heading structure still beats visually styled paragraphs. Explicit form labels still beat placeholder-only patterns.

Field note: Removing 4.1.1 doesn't give developers permission to ship sloppy code. It removes a reporting distraction so audits can focus on failures users actually encounter.

A legacy CMS is a good example. It may generate messy markup that no longer triggers a parsing failure by itself. But if it produces fake buttons that don't work from a keyboard, or headings that flatten the page into an unreadable structure, you still have WCAG failures to remediate. The standard changed where you count the failure, not whether the user is blocked.

5. Audit Workflow For Sustainable Compliance

A WCAG 2.2 AA checklist only works when it sits inside a repeatable audit workflow. Market monitoring tied to European Accessibility Act enforcement shows only 45% to 55% of sampled sites in the EU 27 met the standard, and automated tools detect only 70-80% of violations, according to this EAA first-year enforcement report. That's why checklist culture alone fails. Teams need layered verification.

The practical sequence is simple. Scan first. Review manually second. Validate with assistive technology third. Then test critical journeys with disabled users. If your organization needs a formal process, a WCAG compliance audit then becomes operational rather than aspirational.

What each testing layer should cover

• Automated scanning: Catch missing alt text, empty links, low contrast candidates, missing labels, and obvious code-level defects across templates.
• Manual testing: Check reading order, meaningful alt text quality, error guidance, consistent help placement, redundant entry, and focus visibility in sticky layouts.
• Assistive technology testing: Validate screen reader announcements, keyboard traversal, state changes, modal behavior, and status messages with tools like NVDA, VoiceOver, and TalkBack.
• User testing: Validate whether real tasks are completable, especially checkout, account recovery, application flows, and support journeys.

How to map testing to criteria

An example helps. On a product page, automation can tell you an img has alt text. It can't tell you if the alt says “image123” or repeats adjacent text uselessly. A screen reader test can confirm whether variant selectors announce state. User testing can reveal whether a sticky promo bar hides focus during tabbing on a small screen.

The same pattern applies to forms. Automation finds a missing label. Manual review checks whether instructions make sense. Assistive tech testing confirms whether errors announce. User testing shows whether the recovery path is understandable under pressure.

That layered model also improves CRO on priority pages. When login, checkout, pricing, demo request, and support pages are tested at all four layers, users hit less friction and teams catch regressions before they affect revenue paths.

6. Common Failure Patterns And Code Examples

Most remediation programs don't fail because WCAG is too large. They fail because the same defects reappear in new releases. The homepage statistics at the start of this article point to a concentration problem, not just a compliance problem. Teams keep shipping low contrast, missing labels, empty links, weak button semantics, and broken language settings because those patterns are baked into components, CMS workflows, or rushed QA.

That's good news from an implementation standpoint. If you fix the patterns at system level, you improve hundreds of pages at once.

What teams miss repeatedly

A seasoned accessibility review usually finds these recurring categories:

• Content defects: Missing alt text, vague alt text, images of text, skipped headings, placeholder-only form cues.
• Design system defects: Weak contrast tokens, hidden focus styles, tiny icon buttons, touch targets that are visually large but not clickable.
• Interaction defects: Keyboard traps, drag-only actions, inaccessible modals, custom selects that don't expose state.
• Semantic defects: Clickable div elements, incorrect ARIA, duplicate announcements, status updates that never reach assistive tech.
• Mobile-specific defects: Focus hidden behind sticky UI, cramped hit areas, and gesture-only controls.

Build once, fix many times

The best remediation lever is almost always the component library. Fix the shared button, field, modal, tooltip, accordion, and alert patterns first. Then work outward into page-specific content.

Strong accessibility programs don't rely on heroic manual cleanup. They move defects upstream into design tokens, linting, component APIs, CMS guardrails, and release criteria.

Managed accessibility, monitoring, and accessibility tooling integrate effectively. Continuous scanning catches regressions. Widgets and user controls can support visitor personalization. Expert review handles the harder edge cases that automation and overlays alone don't interpret. The strongest programs usually combine those layers instead of pretending one method solves everything.

7. Failure Patterns For Alt Text Form Labels And Color Contrast

These three issues are common because they're easy to create and easy to overlook in fast-moving content pipelines. They also hit conversion-critical moments. Product cards, category filters, search, signup, checkout, and lead forms all depend on them.

If you want quick wins, start here.

Alt text that helps instead of decorates

Failing pattern:

<img src="blue-running-shoe.jpg" alt="shoe image"> 

Better pattern:

<img src="blue-running-shoe.jpg" alt="Blue running shoe with white sole"> 

Decorative images should be hidden from assistive tech:

<img src="divider-flourish.svg" alt=""> 

Good alt text answers one question: what would a non-visual user miss if this image were removed? On a product card, that may be model, color, or visible variation. On a decorative flourish, the answer is nothing.

Labels that survive autofill, zoom, and memory load

Failing pattern:

<input type="email" placeholder="Enter your email"> 

Better pattern:

<label for="email">Email address</label> <input id="email" type="email" autocomplete="email"> 

Visible labels reduce hesitation on forms and help returning users confirm what each field expects. They also age better than placeholder-only interfaces, especially in high-stakes flows like account access and billing.

Contrast that passes in the real interface

Failing pattern:

.button-secondary { color: #9aa0a6; background: #ffffff; } 

Safer pattern:

.button-secondary { color: #1f2937; background: #ffffff; border: 1px solid #1f2937; } 

The biggest contrast mistakes happen in secondary buttons, placeholder text, disabled-looking states, sale labels, and text over images. Teams should test both default and interactive states, then monitor them continuously. If contrast drift is a recurring issue in your design system, it helps to monitor contrast ratio guidelines alongside token updates and visual QA.

8. Failure Patterns For Focus Images Of Text Modals ARIA And Keyboard Traps

Interactive defects are where teams often discover the difference between “technically present” and “effectively usable.” A button can exist and still be impossible to find with a keyboard. A modal can look polished and still trap or lose focus. A custom component can expose ARIA attributes and still announce the wrong thing.

Focus and images of text

Failing focus pattern:

:focus { outline: none; } 

Better pattern:

:focus-visible { outline: 3px solid #005fcc; outline-offset: 2px; } 

Teams often remove focus rings to match a visual style, then forget to replace them. That breaks task flow immediately for keyboard users.

Images of text are another common shortcut:

<img src="sale-banner-text.png" alt="Summer sale now live"> 

Better pattern:

<section class="sale-banner"> <h2>Summer sale now live</h2> </section> 

Real text scales, translates, reflows, and responds to user settings. Rasterized text doesn't.

Modals ARIA and keyboard traps

Failing modal trigger and container:

<div onclick="openModal()">Open details</div> <div class="modal">...</div> 

Stronger approach:

<button type="button" aria-haspopup="dialog" aria-controls="details-modal"> Open details </button> <div id="details-modal" role="dialog" aria-modal="true" aria-labelledby="dialog-title" hidden> <h2 id="dialog-title">Product details</h2> <button type="button">Close</button> </div> 

A working dialog also needs focus management. Focus should move into the modal when it opens, stay constrained while it's active, and return to the trigger when it closes.

Bad ARIA often looks like this:

<div role="button">Save</div> 

If you use ARIA to imitate a native element, you inherit all the keyboard and state behavior you now have to recreate. A real button is still the better tool:

<button type="submit">Save</button> 

Keyboard traps usually come from custom widgets, off-canvas menus, and script-heavy carousels. Test with only the keyboard. If you can tab in but not out, or if focus disappears, the component isn't ready for release.

WCAG 2.2 AA: 8-Item Comparison Matrix

Start Your 2026 Accessibility Audit Today

A WCAG 2.2 AA checklist is only useful if it helps your team move from theory to release-ready fixes. That means one checklist that merges inherited Level AA requirements with the new 2.2 additions, one audit workflow that combines automation and human review, and one remediation process that ties findings to templates, components, and business-critical journeys.

The checklist itself should be reference-grade. It should tell a content editor what to verify on a landing page, a front-end developer what to test in a modal or drag interface, a QA analyst what requires keyboard and screen reader validation, and a product owner what has to be fixed before a checkout or login flow goes live. Anything less becomes shelfware.

The implementation order is often straightforward for development teams. Start with high-traffic, high-conversion pages. That usually means homepage, navigation, pricing, product detail, cart, checkout, signup, login, account recovery, and support. Then fix shared components in the design system so those improvements spread across the rest of the site. After that, put monitoring in place so resolved issues do not resurface in the next sprint.

That approach also aligns with E-E-A-T in practice. Experience comes from testing real journeys, not only reading specs. Expertise comes from knowing which failures block users and how to remediate them cleanly. Authoritativeness comes from using a criterion-level checklist instead of vague statements about inclusion. Trust comes from publishing clear standards, documenting findings, and sustaining accessibility over time.

Don't treat accessibility as a side project detached from growth work. It touches conversion, retention, support cost, brand trust, and market reach. Larger tap targets reduce mobile friction. Better focus handling improves keyboard completion. Clear labels and error guidance reduce abandonment. Accessible authentication removes one of the most frustrating blockers in account access. Those gains show up first on the pages that matter most to revenue and customer satisfaction.

If your current documents still center on WCAG 2.1, update them now. WCAG 2.2 changed the scope in practical ways, and old checklists won't catch hidden focus, drag-only actions, inconsistent help, redundant entry, or cognitive barriers in authentication. It also removed parsing as a criterion, which should change how you write findings and prioritize fixes.

The cleanest next step is to download the canonical WCAG compliance checklist, use it to baseline your site, and then run a structured accessibility audit against your highest-priority templates and user journeys. Once remediation starts, add continuous accessibility monitoring so regressions surface early instead of months later.

If WebAbility.io fits your stack, it's one relevant option for combining scanning, workflow tracking, and broader accessibility support in one platform. What matters most is the operating model: checklist, audit, remediation, validation, and monitoring. That's how teams achieve compliance and keep it.

If you want a practical path from checklist to remediation, WebAbility.io can help you baseline WCAG 2.2 AA coverage, monitor recurring issues, and support ongoing accessibility work across templates, releases, and user journeys.