Accessibility Testing Checklist: WCAG 2.2 Compliance in 30 Steps

WCAG 2.2 is the current baseline for web accessibility compliance. It is referenced by accessibility legislation in the US, UK, EU, Canada, and Australia. If your application fails its criteria, you are excluding users with disabilities and — depending on your jurisdiction and user base — potentially exposing your organization to legal risk.

But compliance is not just a legal checkbox. Accessible applications are better applications. Keyboard navigation benefits power users. Descriptive error messages help everyone. Logical heading structures improve readability for sighted and non-sighted users alike. Accessibility work and usability work overlap more than most teams realize.

This checklist covers 30 specific accessibility checks organized across the four WCAG principles: Perceivable, Operable, Understandable, and Robust. It also incorporates the new success criteria introduced in WCAG 2.2. Use it as a structured testing guide for your next release cycle — or run it now against your existing product to find out where you stand.

How to Use This Checklist

Each item maps to one or more WCAG 2.2 success criteria and has a conformance level — A (minimum), AA (standard legal requirement), or AAA (enhanced). Most regulations require AA conformance as the target.

Tools you will need:

A keyboard (no mouse)
A screen reader: NVDA or JAWS on Windows, VoiceOver on macOS/iOS, TalkBack on Android
A browser extension for color contrast checking (e.g., axe DevTools, Colour Contrast Analyser)
Your browser's built-in DevTools for inspecting DOM structure and ARIA attributes

Work through each section methodically. Document failures with the specific WCAG criterion, the affected component, and reproduction steps.

Principle 1: Perceivable

Information and UI components must be presentable to users in ways they can perceive. Content that only works visually, or only works with sound, fails this principle.

Check 1 — Text alternatives for images (WCAG 1.1.1, Level A)

Every non-decorative image must have an alt attribute that describes its content or function. Decorative images that add no information should have alt="" so screen readers skip them. Test by disabling images in your browser and verifying that all meaningful content is still communicated through alt text. A photo of a product should describe the product. An icon button without a visible label needs alt text that names its action.

All informative images have descriptive alt text
Decorative images use alt=""
Icon buttons have text alternatives (via alt, aria-label, or visually hidden text)
Charts and infographics have either descriptive alt text or a text equivalent nearby

Check 2 — Captions for video and audio (WCAG 1.2.2 / 1.2.3, Level A)

Pre-recorded video with audio must have synchronized captions. Pre-recorded audio-only content must have a text transcript. This affects tutorial videos, onboarding walkthroughs, product demos, and any embedded media.

Pre-recorded video has synchronized captions
Pre-recorded audio-only content has a text transcript
Captions are accurate — auto-generated captions that have not been reviewed do not meet this criterion

Check 3 — Color is not the only means of conveying information (WCAG 1.4.1, Level A)

Color alone cannot be used to convey meaning. A red form field border communicates an error only to users who can perceive that color. The same field must also include a text label or icon to communicate the error state.

Form validation errors use text labels or icons in addition to color
Required fields are not marked only by color (e.g., a red asterisk needs a text explanation)
Status indicators (active, inactive, pending) use text or pattern in addition to color
Links within body text are distinguishable from surrounding text by something other than color alone (underline is the standard)

Check 4 — Contrast ratio for text (WCAG 1.4.3, Level AA)

Normal text (under 18pt / 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Large text must meet 3:1. Use a contrast checker on every text color and background combination in your design system, not just the primary body text.

Body text meets 4.5:1 against its background
Large text (18pt+ or 14pt+ bold) meets 3:1
Placeholder text in form fields meets contrast requirements
Text over images or gradients meets contrast requirements at all viewport sizes
Disabled element text is explicitly excluded from this requirement — verify that excluded elements are genuinely non-functional

Check 5 — Non-text contrast for UI components (WCAG 1.4.11, Level AA)

WCAG 2.1 extended contrast requirements beyond text to UI components and graphical objects. Form field borders, checkbox outlines, focus indicators, and informational icons must all meet 3:1 against adjacent colors.

Form field borders meet 3:1 contrast against the page background
Checkbox and radio button boundaries are visible at 3:1
Focus indicator outlines meet 3:1 against adjacent colors
Informational icons (not decorative) meet 3:1

Check 6 — Text resize without loss of content (WCAG 1.4.4, Level AA)

Text must be resizable up to 200% without loss of content or functionality. Use your browser's text zoom (not page zoom) and verify that nothing breaks.

Text resized to 200% does not overflow its container
No content becomes hidden or obscured at 200% text size
Functionality is preserved — buttons remain clickable, forms remain submittable

Check 7 — Reflow at 320px viewport width (WCAG 1.4.10, Level AA)

Content must reflow to a single column at a viewport width equivalent to 320 CSS pixels so users who need to zoom in on mobile devices do not have to scroll horizontally. This is one of the more commonly failed criteria on applications that were not designed mobile-first.

Page content displays without horizontal scrolling at 320px viewport width
Data tables that cannot reflow provide a horizontal scroll container (this is an explicit exception)
No content is lost or truncated at 320px

Check 8 — Content on hover or focus (WCAG 1.4.13, Level AA)

Tooltips and other content that appears on hover or focus must be dismissible, hoverable, and persistent. A tooltip that disappears the moment you move your cursor toward it is a WCAG 2.1 failure that carried into 2.2.

Hover/focus-triggered content can be dismissed with Escape without moving focus
The user can hover over the tooltip content itself without it disappearing
The tooltip remains visible until the user moves focus away or dismisses it

Principle 2: Operable

UI components and navigation must be operable. If a feature can only be used with a mouse or a touchscreen, it fails this principle.

Check 9 — Keyboard accessibility for all functionality (WCAG 2.1.1, Level A)

Every action available with a mouse must be available with a keyboard. This is the single most common accessibility failure in modern applications. Custom components — date pickers, dropdowns, sliders, carousels, drag-and-drop interfaces — need explicit keyboard support.

All interactive elements are reachable by Tab key
Custom dropdown menus open and navigate with keyboard (arrow keys to move, Enter to select, Escape to close)
Date pickers are keyboard-operable
Drag-and-drop functionality has a keyboard alternative
Carousels advance and retreat with keyboard controls
Modal dialogs can be opened and dismissed with keyboard alone

Check 10 — No keyboard trap (WCAG 2.1.2, Level A)

Users must always be able to move focus away from any component using standard keys. If a component captures Tab and never releases it, keyboard users are stuck.

Tabbing through the page never leaves focus trapped in a component (unless the component is a modal with intentional focus trapping)
Any component that traps focus (modals, drawers) provides a documented way to exit — typically Escape
iframes do not trap keyboard focus

Check 11 — Focus order is logical (WCAG 2.4.3, Level A)

Focus must move in a sequence that preserves meaning and operability. On a left-to-right layout, that typically means top-to-bottom, left-to-right. Focus order that jumps around the page creates disorientation for keyboard and screen reader users.

Tab order follows the visual reading order
Injected content (modals, notifications, dynamic panels) receives focus at the appropriate moment, not buried at the end of the DOM
tabindex values above 0 are not used — they override natural DOM order and create unpredictable tab sequences

Check 12 — Visible focus indicator (WCAG 2.4.7, Level AA)

The focused element must always be visually identifiable. Many applications suppress the browser's default focus ring with outline: none and replace it with nothing. WCAG 2.2 strengthened this in success criterion 2.4.11 and 2.4.12 (Focus Appearance), which set minimum size and contrast requirements for focus indicators.

Every interactive element has a visible focus state
Focus indicators meet minimum contrast (3:1 against adjacent colors per WCAG 1.4.11)
Focus indicators are not suppressed by global outline: none rules without a custom replacement
WCAG 2.2 new: Focus indicators enclose the focused element and meet minimum area requirements (2.4.11, Level AA)

Check 13 — Skip navigation link (WCAG 2.4.1, Level A)

Pages with repeated navigation blocks must provide a mechanism to skip to the main content. Without it, keyboard users must Tab through every nav link on every page load.

A "Skip to main content" link is the first focusable element on every page
The skip link is visible on focus (it may be visually hidden when not focused)
Activating the skip link moves focus to the main content area, not just scrolls to it

Check 14 — Descriptive page titles (WCAG 2.4.2, Level A)

Every page must have a <title> that describes its purpose. Screen reader users rely on page titles to orient themselves when switching tabs or returning to a page after navigating away. Single-page applications must update the document title on route changes.

Every page has a unique, descriptive <title>
The title identifies both the page ("Account Settings") and the site ("Crosscheck")
SPAs update document.title on route change

Check 15 — Link purpose is clear from context (WCAG 2.4.4, Level A)

Link text must describe the destination or action. "Click here" and "Read more" are failures when the surrounding context does not clarify the destination. Screen reader users often navigate by pulling up a list of all links on a page — in that context, "Read more" is meaningless.

No links use text like "click here," "here," "read more," or "learn more" in isolation
Links with identical visible text that go to different destinations have aria-label attributes that differentiate them
Icon-only links have aria-label or visually hidden text describing the destination

Check 16 — Pointer gestures have single-pointer alternatives (WCAG 2.5.1, Level A)

Functionality that requires multipoint or path-based gestures (pinch-to-zoom, swipe, drag) must also be operable with a single pointer — tap, click, or long press.

Swipeable carousels or galleries have previous/next buttons
Map zooming (if applicable) has button controls in addition to pinch-to-zoom
No functionality is exclusively available through a gesture with no single-pointer alternative

Check 17 — Target size for pointer inputs (WCAG 2.5.8, Level AA — new in WCAG 2.2)

WCAG 2.2 introduced a minimum target size of 24x24 CSS pixels for interactive elements, with an exception if adequate spacing separates the target from neighboring targets.

Buttons, links, and form controls meet the 24x24 CSS pixel minimum target size (or are spaced such that the surrounding offset meets the threshold)
Close buttons on modals and notification banners are large enough to tap accurately on touch devices
Inline links in dense text are the explicit exception — they do not need to meet the 24px threshold

Check 18 — No timing requirements (WCAG 2.2.1, Level A)

If time limits exist, users must be able to turn them off, extend them, or the limit must be at least 20 hours. Sessions that expire should warn the user in advance and allow them to extend.

Session timeout warnings appear with enough notice to allow the user to respond
The user can extend the session without losing their data
Auto-advancing carousels or slideshows can be paused
No time limits exist on completing forms or workflows unless strictly necessary (e.g., a security-required timeout)

Check 19 — No content that flashes more than three times per second (WCAG 2.3.1, Level A)

Content that flashes more than three times per second can trigger seizures in users with photosensitive epilepsy. This is a safety criterion, not just a usability one.

No animations, video, or UI transitions flash more than three times per second
Loading spinners and progress indicators do not flash at a hazardous rate

Principle 3: Understandable

Information and the operation of the UI must be understandable. Users must be able to comprehend both the content and how to interact with it.

Check 20 — Language of page is set (WCAG 3.1.1, Level A)

The lang attribute on the <html> element tells screen readers which language to use for text-to-speech synthesis. Without it, a screen reader may read English content with the wrong pronunciation engine.

<html lang="en"> (or the appropriate language code) is set on every page
If a page contains passages in a different language, those passages use lang attributes on the containing element

Check 21 — On focus, no unexpected context change (WCAG 3.2.1, Level A)

Moving focus to a component must not automatically trigger a navigation or form submission. Dropdowns that navigate to a new page when an option is focused — before the user confirms — fail this criterion.

Focusing a form element does not submit the form
Focusing a select element does not navigate to a new page
No automatic page refresh occurs when a field receives focus

Check 22 — On input, no unexpected context change (WCAG 3.2.2, Level A)

Changing a setting or entering data must not automatically cause a major change unless the user has been warned in advance. Auto-submitting forms on a radio button change is the classic failure here.

Changing a <select> value does not automatically navigate away from the page without warning
Checking a checkbox does not submit a form without an explicit submit action
If an input change does trigger an automatic action, the user has been informed in advance

Check 23 — Error identification and description (WCAG 3.3.1 / 3.3.3, Level A / AA)

When an error is detected, the item in error must be identified and the error described to the user in text. Error messages must be specific enough to help the user correct the problem.

Form errors are identified in text — not just highlighted in red
Error messages explain what went wrong and how to fix it (not just "Invalid input")
Error messages are associated with the specific field via aria-describedby or adjacent placement
Errors are announced to screen readers — either by moving focus to the error message or via an aria-live region

Check 24 — Labels for all form fields (WCAG 3.3.2, Level A)

Every form input must have a programmatically associated label. Placeholder text is not a substitute for a label — it disappears when the user types and is often not read by older screen readers.

Every <input>, <select>, and <textarea> has a <label> associated via for/id, or an aria-label, or an aria-labelledby
Placeholder text is used as a hint, not as the only label
Groups of related inputs (radio buttons, checkboxes) are wrapped in a <fieldset> with a <legend>

Check 25 — Accessible authentication (WCAG 3.3.8, Level AA — new in WCAG 2.2)

WCAG 2.2 added requirements around authentication. Cognitive function tests (puzzles, memory tasks, transcribing distorted text) cannot be required to complete authentication unless an alternative is provided or a mechanism is offered to assist.

Login forms support browser autofill and password managers — autocomplete attributes are set correctly
CAPTCHAs have an accessible alternative (audio CAPTCHA, or a support contact option)
Copy-paste is not disabled on username/password fields
Authentication does not require the user to memorize or transcribe arbitrary strings

Check 26 — Redundant entry is not required (WCAG 3.3.7, Level A — new in WCAG 2.2)

Users should not be required to enter the same information twice in the same session unless re-entry is essential for security or the information has expired.

Multi-step forms do not ask for the same information twice (e.g., email address collected on step 1 is not asked again on step 3)
Previously entered data is auto-populated where appropriate on subsequent steps
Review screens on checkout flows allow the user to confirm previously entered data rather than re-enter it

Principle 4: Robust

Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies. This principle focuses on the quality of the underlying code.

Check 27 — Valid, well-structured HTML (WCAG 4.1.1, Level A)

HTML with duplicate IDs, incorrectly nested elements, or missing required attributes causes unpredictable behavior in assistive technologies. Run your markup through a validator.

No duplicate id attributes exist on the same page
All HTML tags are properly nested and closed
No required attributes are missing from elements (e.g., <img> without alt, <input> without type)
Run the page through the W3C HTML Validator and resolve any errors

Check 28 — Name, role, and value for all UI components (WCAG 4.1.2, Level A)

Every UI component must have an accessible name (what it is called), a role (what type of element it is), and a value (its current state) that are all exposed to assistive technologies. Custom components built from <div> and <span> elements do not have native roles and require explicit ARIA.

Custom toggle switches expose role="switch" and aria-checked
Custom tabs use role="tablist", role="tab", and role="tabpanel" with appropriate aria-selected and aria-controls
Expandable sections (accordions) use aria-expanded on the trigger button
Dialog modals use role="dialog" and aria-labelledby pointing to the dialog title
Progress indicators expose their current value via aria-valuenow, aria-valuemin, and aria-valuemax

Check 29 — Status messages are communicated to assistive technologies (WCAG 4.1.3, Level AA)

When a status message appears — a form success confirmation, a loading complete notice, a count of search results — it must be communicated to screen readers without requiring focus to move to the message. aria-live regions are the standard mechanism.

Form submission success messages are read by screen readers without requiring a focus change
Error summaries at the top of a form are announced via aria-live or focus is moved to them
"Loading" spinners announce completion when the operation finishes
Toast notifications and snackbars use role="status" or aria-live="polite"
Shopping cart item counts or notification badge counts are surfaced to screen readers

Check 30 — ARIA is used correctly and not overused (Supporting WCAG 4.1.2)

First rule of ARIA: do not use ARIA if you can use a native HTML element instead. A <button> is better than a <div role="button">. ARIA misuse — incorrect roles, redundant attributes, conflicting states — actively breaks assistive technology behavior.

Native HTML elements are used wherever possible (<button>, <a>, <input>, <select>, <nav>, <main>, <header>, <footer>)
ARIA roles are only applied to custom components that have no native equivalent
aria-hidden="true" is not applied to elements that contain focusable children
aria-label overrides are accurate — they should match or closely describe what the element does visually
Landmark regions are used to structure the page: <main>, <nav>, <header>, <footer>, <aside> (only one <main> per page)

Documenting Accessibility Failures

Accessibility testing produces a specific type of bug report. A good accessibility bug includes:

The WCAG success criterion and level (e.g., "WCAG 2.4.7, Level AA")
The affected component and its location on the page
The failure: what was expected vs. what was observed
The assistive technology and browser used when the failure was encountered
Reproduction steps, including keyboard navigation path if relevant

Accessibility bugs are often harder to reproduce than functional bugs because the failure depends on the interaction between the assistive technology, the browser, and the DOM state at a specific moment. A screen recorder that captures not just the screen but also the browser's console state and DOM at the moment of failure is significantly more useful than a screenshot.

Incorporating Accessibility Testing into Your QA Workflow

Accessibility testing should not be a one-time audit. It should be part of every sprint cycle, applied to new and modified components before they merge. A few structural practices that help:

Shift left. Include accessibility acceptance criteria in your user stories. "The modal is accessible" is not an acceptance criterion. "The modal traps focus, is dismissed by Escape, and announces its title to screen readers via aria-labelledby" is.

Use automated scanning as a first pass. Tools like axe, Lighthouse, and WAVE catch roughly 30–40% of WCAG failures automatically. They are not a substitute for manual testing but they eliminate the obvious issues before a human tester touches the product.

Test with real assistive technology. Automated tools cannot tell you whether a screen reader announces a dynamic update at the right moment, or whether the reading order of a custom component makes sense when navigated linearly. Manual testing with NVDA on Windows and VoiceOver on macOS covers the majority of real-world screen reader usage.

Document findings with full technical context. When a screen reader does not announce a status message, the developer fixing the bug needs to see the exact DOM structure at that moment — not just a description. Network request logs, console output, and a replay of the interaction reduce the back-and-forth between QA and engineering.

Capture Accessibility Bugs with Full Context

Accessibility bugs are reproducibility-sensitive. A screen reader behavior that manifests in one browser-AT combination may not reproduce in another. When you are working through this checklist and find a failure, the report you file needs to capture the exact conditions.

Crosscheck is a browser extension built for QA teams that captures everything at the moment you find a bug: a screenshot or full session replay, the complete console log, every network request, and your environment details — browser version, OS, viewport size. For accessibility testing, that context is critical. When the developer picks up an accessibility bug, they are not guessing at the DOM state or the sequence of interactions that caused the failure. They watch the replay.

When you are running a structured checklist like this one across 30 checks, across multiple browsers and screen reader combinations, the difference between a well-documented and poorly documented bug report can be the difference between a same-day fix and a two-week back-and-forth. Crosscheck eliminates that gap.

Try Crosscheck free and see how much faster accessibility issues move from discovery to resolution when every report comes with full technical context attached.