A WCAG 2.2 AA checklist for sites running an accessibility overlay

Sites running an accessibility overlay — accessiBe, UserWay, or similar — routinely publish an accessibility statement citing WCAG 2.2 AA conformance. That claim is testable, and the gap between the claim and the live page is exactly where legal risk concentrates. This checklist is organized by WCAG principle. For each principle it separates the checks that automated tooling can reliably make from the ones that require a human pass. Use it alongside a witness run — which gives you the automated half — and a structured manual review for the rest.

Before you start: what automated testing covers and does not#

WCAG 2.2 AA contains 50 success criteria across four principles: Perceivable, Operable, Understandable, and Robust. Automated engines like axe-core — the Deque rule set OverlayRiskWitness runs on every page — can evaluate a meaningful subset of those criteria from the rendered DOM. The rest depend on context, human judgment, or assistive-technology interaction that no headless runner can replicate. A page can return zero automated violations and still have serious WCAG failures. A clean automated result is evidence; it is not a certificate. Keep that boundary in view throughout this checklist.

Perceivable: color, contrast, and alternative text#

The Perceivable principle covers how information is presented to users. Most of the automation-friendly criteria live here: contrast ratios, missing alt attributes, and caption presence are all machine-evaluable from the DOM. The harder items — whether alt text is meaningful rather than just present, whether audio description actually describes the video action — remain manual.

• 1.1.1 Non-text content — Automated: axe-core checks for missing or empty alt attributes on images and form inputs. Manual: verify that present alt text is actually descriptive, not a filename or a placeholder like "image."
• 1.3.1 Info and relationships — Automated: axe flags heading hierarchy gaps, missing form labels, and table cells lacking header associations. Manual: confirm that visual structure conveyed through color or typography is also exposed to the accessibility tree via semantic markup.
• 1.3.3 Sensory characteristics — Manual only: check that no instruction relies solely on shape, color, size, or visual location (for example, "click the green button on the right side of the screen").
• 1.4.1 Use of color — Manual only: verify that color is never the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
• 1.4.3 and 1.4.6 Contrast (minimum and enhanced) — Automated: axe evaluates contrast ratios for text and large text against their backgrounds. A two-pass witness run is particularly useful here: overlay color-fix features may pass the criterion in the overlay-on pass while the baseline page fails it, or vice versa — the diff shows the direction.
• 1.4.4 Resize text — Manual: zoom to 200 percent in a real browser and verify that no content is lost, clipped, or requires horizontal scrolling to read.
• 1.4.10 Reflow — Manual: resize the viewport to 320 CSS pixels wide and confirm content reflows without horizontal scrolling, except for content that inherently requires two dimensions (maps, data tables).
• 1.4.12 Text spacing — Manual: apply the override bookmarklet (line-height 1.5x, letter-spacing 0.12em, word-spacing 0.16em, paragraph spacing 2x) and verify no text is clipped, truncated, or overlaps adjacent content.

Operable: keyboard access and focus management#

The Operable principle is where overlays most frequently claim impact — keyboard navigation, skip links, and focus visibility — and where the gap between the marketing claim and observed behavior is often widest. Most keyboard-related criteria require an actual keyboard session to verify. Automated checks catch a narrow class of obvious focus-trap patterns; they cannot walk a custom component tree or confirm that the tab order follows a logical reading path.

• 2.1.1 Keyboard — Mostly manual: every function available by mouse must be reachable by keyboard alone, without requiring specific timing. Automated checks catch documented focus-trap signatures; they miss incomplete keyboard paths through custom components.
• 2.1.2 No keyboard trap — Automated and manual: axe flags known focus-trap patterns. Confirm interactively that modal dialogs, date pickers, and flyout menus return focus to a sensible location on close or Escape.
• 2.4.1 Bypass blocks — Automated: axe checks that a skip-navigation link exists. Manual: tab to the skip link, activate it, and verify that focus lands at the main content region.
• 2.4.2 Page titled — Automated: axe verifies that the title element is present, non-empty, and identifies the page topic.
• 2.4.3 Focus order — Manual: tab through the page in sequence and confirm the order follows a logical reading path that preserves the meaning and operability of the content.
• 2.4.4 Link purpose in context — Manual: every link must be identifiable from its text alone, or from its immediate surrounding context, without needing to read the rest of the page.
• 2.4.7 Focus visible — Automated (partial): axe can flag zero-opacity or display:none focus outlines. Manual: tab through all interactive elements and confirm a clearly visible focus indicator appears on each one.
• 2.4.11 Focus not obscured — New in WCAG 2.2, manual: verify that focused components are not entirely hidden by a sticky header, cookie banner, or the overlay widget itself. If any part of the focused element remains visible, the criterion is technically met; if it is fully covered, it fails.
• 2.5.3 Label in name — Automated (partial): axe checks that computed accessible names contain the visible label string. Manual: confirm for custom controls and icon buttons where the visible and computed names may diverge.

Understandable: forms, error handling, and language#

The Understandable principle governs language identification, predictable behavior, and error recovery. Language attributes and form label associations are partially automatable; whether error messages are genuinely helpful to a real user, or whether a multi-step form asks for redundant information, are judgment calls that require a manual review session.

• 3.1.1 Language of page — Automated: axe checks that the html element carries a valid, non-empty lang attribute.
• 3.1.2 Language of parts — Manual: sections written in a language different from the page default must carry their own lang attribute so screen readers switch pronunciation rules correctly.
• 3.2.1 On focus — Manual: confirm that moving keyboard focus to a component does not by itself trigger a context change such as submitting a form, opening a new window, or navigating to a new page.
• 3.2.2 On input — Manual: confirm that changing a control value does not automatically trigger a context change unless the user has been informed of that behavior in advance.
• 3.3.1 Error identification — Automated (partial): axe flags form inputs associated with ARIA error roles. Manual: submit the form with each required field empty and with invalid values; confirm that each error identifies the specific field and describes what is wrong in plain text.
• 3.3.2 Labels or instructions — Automated: axe verifies that every form input has an accessible label. Manual: confirm that format requirements (date format, password complexity rules) are visible before the user submits and encounters an error.
• 3.3.7 Redundant entry — New in WCAG 2.2, manual: in multi-step processes, confirm that information already entered is not requested again unless it is essential to the process or required for security reasons.
• 3.3.8 Accessible authentication — New in WCAG 2.2, manual: verify that no authentication step requires solving a cognitive function test (recalling a password unaided, transcribing characters from an image) unless an alternative method or mechanism is available.

Robust: compatibility with assistive technology#

The Robust principle is primarily about clean markup that assistive technology can parse and interpret reliably. Automated tooling covers this principle well because most of the criteria map directly to detectable DOM properties: duplicate IDs, invalid ARIA values, and missing role-name-state triples are all surfaced by a standard axe-core run.

• 4.1.1 Parsing — Automated: axe checks for duplicate id attribute values and invalid ARIA attribute values that would cause an assistive-technology parser to skip or misread content.
• 4.1.2 Name, role, value — Automated: axe verifies that every interactive element has an accessible name, a valid role, and that its current state (checked, expanded, selected, disabled) is programmatically exposed in the accessibility tree.
• 4.1.3 Status messages — Manual: confirm that status messages such as form success banners, live cart counts, and error summaries are programmatically determined via ARIA live regions so screen readers announce them without requiring focus to move to the message.

What an overlay cannot fix on your behalf#

An overlay injects JavaScript at runtime. It operates on a rendered page it did not author. There are structural and design problems it cannot reach from that position, and knowing which ones keeps your public compliance statement honest.

• Alt text quality: an overlay can detect a missing alt attribute and inject a placeholder. It cannot know whether "product-image-7341.jpg" is a meaningful description for the specific image in context on your page. Meaningful alternative text is a content decision made during authoring.
• Keyboard path logic: tab order is determined by DOM structure and tabindex values baked into the source. An overlay can inject a skip link, but it cannot reroute a fundamentally broken keyboard path through a custom component built without keyboard semantics.
• WCAG 2.2 criteria: success criteria 2.4.11, 2.5.3, 3.3.7, and 3.3.8 are new in WCAG 2.2. Most overlays were built and third-party-certified against WCAG 2.1 AA; their remediation logic does not cover these criteria, and a site citing WCAG 2.2 AA while running a WCAG 2.1-era overlay has an immediate gap in its statement.
• Language of parts: per-element lang attributes must exist in the source markup. An overlay has no reliable way to detect which sections contain foreign-language content and add the correct attribute without human authoring.
• Accessible authentication (3.3.8): the structure of a login flow and its available alternatives is a design and engineering decision. No runtime script can add an alternative authentication path to a checkout or account system it did not build.