Web Accessibility Checklist 2026: WCAG 2.2 Compliance Guide

Home » Articles » Web Accessibility Checklist 2026: WCAG 2.2 Compliance Guide

Line25 is reader supported. At no cost to you a commission from sponsors may be earned when a purchase is made via links on the site. Learn more

In 2024 alone, over 4,000 ADA-related web accessibility lawsuits were filed in U.S. federal courts, a number that has grown every year for the past decade. But the legal risk is only the most obvious reason to care about web accessibility. The stronger argument is that accessible design is simply better design. High-contrast text is easier to read for everyone. Keyboard navigation helps power users. Captions on video serve people in noisy environments as much as those with hearing loss. When you design for the full range of human ability, you improve the experience for everyone.

In 2026, WCAG 2.2 is the current and enforceable standard for web accessibility. It supersedes WCAG 2.1 and introduces new success criteria that address gaps, particularly around mobile usability and cognitive accessibility. This checklist gives you everything you need to audit, fix, and maintain accessibility across your web projects. Pairing accessibility knowledge with the right AI design tools can help automate parts of the accessibility review process and catch issues earlier in the design phase. Additionally, staying current with web design trends helps you understand how accessibility and aesthetics can evolve together rather than compete.

WCAG 2.2 Overview: What Changed from 2.1

WCAG 2.2 became a W3C Recommendation in October 2023 and represents the current legal and technical benchmark for web accessibility. Understanding what changed from 2.1 is essential for teams that previously audited against the older standard.

New Success Criteria in WCAG 2.2

• 2.4.11 Focus Not Obscured (Minimum) – Level AA: When a UI component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers or cookie banners. This is now a Level AA requirement, meaning it is required for legal compliance in most jurisdictions.
• 2.4.12 Focus Not Obscured (Enhanced) – Level AAA: A stricter version requiring the focused component to be fully visible, not just partially visible.
• 2.4.13 Focus Appearance – Level AA: The keyboard focus indicator must meet minimum size and contrast requirements. Specifically, the focus indicator area must be at least as large as the perimeter of the unfocused component, and the contrast ratio between focused and unfocused states must be at least 3:1.
• 2.5.7 Dragging Movements – Level AA: Any functionality that uses dragging must also be achievable through a single pointer action without dragging. This addresses the barrier that drag-and-drop interfaces create for users with motor impairments.
• 2.5.8 Target Size (Minimum) – Level AA: Touch targets must be at least 24×24 CSS pixels, or have sufficient spacing between targets. This is a formal codification of the mobile usability best practice that good designers have followed for years.
• 3.2.6 Consistent Help – Level A: If a website offers human contact information, a help mechanism, or a self-help option, it must appear in the same relative position across all pages.
• 3.3.7 Redundant Entry – Level A: Information that a user has already entered in a form should not need to be re-entered in the same session unless re-entering is essential or for security purposes.
• 3.3.8 Accessible Authentication (Minimum) – Level AA: Authentication processes must not require the user to solve a cognitive function test such as a CAPTCHA, unless an alternative method is provided. This is a significant change that affects most sites using CAPTCHA for form protection.
• 3.3.9 Accessible Authentication (Enhanced) – Level AAA: No cognitive function test is allowed in any authentication process.

Removed Criterion

WCAG 2.2 removed 4.1.1 Parsing, which required valid HTML parsing. Modern browsers handle malformed HTML gracefully and assistive technologies no longer depend on strict parsing, making this criterion effectively obsolete.

The Web Accessibility Checklist

This checklist is organized around the POUR framework: Perceivable, Operable, Understandable, and Robust. This framework underpins all of WCAG. Each section includes the most important checkpoints for achieving WCAG 2.2 Level AA compliance.

Perceivable

Perceivable means that all information and user interface components must be presentable to users in ways they can perceive. Nothing should be invisible to all of their senses.

• Text alternatives for non-text content (1.1.1): Every image, icon, and graphic that conveys information must have a descriptive alt attribute. Decorative images should have an empty alt attribute so screen readers skip them. Images of text should be avoided; if used, the alt text must contain the same words.
• Captions for video (1.2.2): All pre-recorded video with audio must have synchronized captions. Auto-generated captions are not sufficient for compliance as they must be reviewed and corrected for accuracy.
• Audio descriptions for video (1.2.5): Pre-recorded video must include audio descriptions of visual content that is not conveyed through the audio track alone. A character’s facial expression, on-screen text, and action sequences all require audio description.
• Use of color (1.4.1): Color must not be the only visual means of conveying information. Error messages that appear only in red, or links distinguished from body text only by color, fail this criterion. Use color plus an icon, underline, or other visual indicator.
• Contrast ratio for text (1.4.3): Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) requires a minimum 3:1 ratio. This applies to text in images as well as HTML text.
• Text resize (1.4.4): Text must be resizable up to 200% without loss of content or functionality. Avoid fixed pixel heights on containers that hold text.
• Images of text (1.4.5): Use actual text rather than images of text wherever possible. Logos are a permitted exception.
• Contrast for non-text UI components (1.4.11): UI components such as form input borders, focus indicators, and icons must have a contrast ratio of at least 3:1 against adjacent colors.
• Reflow (1.4.10): Content must be presentable without horizontal scrolling at a viewport width of 320 CSS pixels. This ensures usability for users who zoom in to 400% on a standard 1280px monitor.
• Text spacing (1.4.12): No content or functionality should be lost when users apply specific text spacing overrides including increased line height, letter spacing, word spacing, and paragraph spacing.

Operable

Operable means that all user interface components and navigation must be operable. Users must be able to operate the interface.

• Keyboard accessibility (2.1.1): All functionality must be available via keyboard alone. This includes menus, modals, carousels, date pickers, and drag-and-drop interfaces. No keyboard traps are permitted.
• No keyboard trap (2.1.2): If keyboard focus moves to a component, the user must be able to move focus away using only the keyboard. Modal dialogs are a common failure point.
• Skip navigation (2.4.1): A mechanism to skip repetitive navigation must be available. A “Skip to main content” link that appears on keyboard focus is the standard implementation.
• Page titles (2.4.2): Each page must have a descriptive title that identifies the site and the page. “Dashboard | Acme App” is better than “Acme App” alone.
• Focus order (2.4.3): Keyboard focus must follow a logical reading order. Components that appear visually in a certain order should receive focus in that same order.
• Link purpose (2.4.4): The purpose of each link must be determinable from the link text alone or from the link text combined with its context. “Click here” and “Read more” fail this criterion unless the surrounding context makes the destination unambiguous.
• Focus visible (2.4.7): Any keyboard-operable interface must have a visible focus indicator. The browser default focus ring meets the minimum requirement but custom focus styles should be thoughtfully designed.
• Focus not obscured (2.4.11 – new in 2.2): When any UI component receives keyboard focus, it must not be entirely obscured by other content. Sticky headers and chat widgets are common offenders.
• Focus appearance (2.4.13 – new in 2.2): Focus indicators must meet minimum size and contrast requirements.
• Pointer gestures (2.5.1): Functionality that uses multi-point or path-based gestures must also be achievable through single-pointer alternatives.
• Dragging movements (2.5.7 – new in 2.2): All drag-and-drop functionality must have a single-pointer alternative that does not require dragging.
• Target size (2.5.8 – new in 2.2): Interactive targets must be at least 24×24 CSS pixels, or have sufficient offset spacing from adjacent targets.
• Timing adjustable (2.2.1): If content has a time limit, the user must be able to turn off, adjust, or extend it. Session timeouts must warn users with enough time to request an extension.
• Pause, stop, hide (2.2.2): Any moving, blinking, or auto-updating content that lasts more than 5 seconds must have a mechanism to pause, stop, or hide it.
• Three flashes (2.3.1): Pages must not contain anything that flashes more than three times per second. This prevents seizures in users with photosensitive epilepsy.

Understandable

Understandable means that information and the operation of the user interface must be understandable.

• Language of page (3.1.1): The default human language of each page must be programmatically determined. Set the lang attribute on the html element.
• Language of parts (3.1.2): When a page contains content in a different language from the page default, that content must be marked with the appropriate lang attribute.
• On focus (3.2.1): When any component receives focus, it must not initiate a change of context. Dropdown menus that navigate to a new page immediately on selection fail this criterion.
• On input (3.2.2): Changing the setting of any user interface component must not automatically cause a change of context unless the user has been advised of this behavior.
• Consistent navigation (3.2.3): Navigation mechanisms that repeat across pages must appear in the same relative order each time they appear.
• Consistent help (3.2.6 – new in 2.2): Help mechanisms such as contact information, live chat, and FAQs must appear in the same relative position across all pages where they are present.
• Error identification (3.3.1): If a form error is detected automatically, the item in error must be identified and the error described to the user in text. Highlighting a field in red is not sufficient without a text description of the error.
• Labels or instructions (3.3.2): Labels or instructions must be provided when content requires user input. Placeholder text alone does not meet this requirement because it disappears when typing begins.
• Error suggestion (3.3.3): If an error is detected and suggestions for correction are known, the suggestions must be provided to the user unless doing so would jeopardize security.
• Redundant entry (3.3.7 – new in 2.2): Information previously entered by the user must be auto-populated or available for selection in subsequent steps of the same process.
• Accessible authentication (3.3.8 – new in 2.2): Authentication must not require solving a cognitive function test such as transcribing text from an image CAPTCHA. Acceptable alternatives include email magic links, passkeys, or CAPTCHA with an audio alternative.

Robust

Robust means that content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

• Name, role, value (4.1.2): For all user interface components, the name, role, and value must be programmatically determinable. Custom interactive widgets built with div elements must use ARIA roles, states, and properties to expose their semantics to assistive technologies. Prefer native HTML elements over custom ARIA implementations wherever possible.
• Status messages (4.1.3): Status messages that appear without receiving focus, such as form submission confirmations, cart updates, or search result counts, must be programmatically determinable through role or property. Use role=”status” or role=”alert” as appropriate.

Accessibility Testing Tools

No single tool catches all accessibility issues. A comprehensive audit combines automated scanning, manual keyboard testing, and screen reader testing.

Free Tools

• axe DevTools (browser extension): The most widely used automated accessibility testing extension, available for Chrome and Firefox. Catches approximately 57% of WCAG issues automatically and provides clear, actionable guidance for each finding. The free version is sufficient for most testing needs.
• WAVE (Web Accessibility Evaluation Tool): WebAIM’s WAVE tool provides visual overlays on the page showing accessibility errors, alerts, and structural elements. Particularly useful for evaluating page structure and ARIA usage.
• Chrome Lighthouse: Google’s built-in Lighthouse audit in Chrome DevTools includes an accessibility score and identifies common issues. Best used as an initial scan rather than a comprehensive audit.
• NVDA (Windows): NonVisual Desktop Access is the most widely used free screen reader on Windows. Testing with NVDA and Firefox is a reliable proxy for how screen reader users will experience your site.
• VoiceOver (macOS and iOS): Apple’s built-in screen reader is essential for testing on Safari, which is the dominant browser for screen reader users on iOS. Activate with Cmd+F5 on macOS.
• Colour Contrast Analyser (by TPGi): A desktop application that lets you sample colors from anywhere on screen and check their contrast ratio against WCAG thresholds. Invaluable for auditing custom design systems.

Paid and Professional Tools

• axe DevTools Pro: The paid version of axe adds guided testing workflows, intelligent guided tests for issues that cannot be fully automated, and team reporting features.
• Deque WorldSpace Attest: An enterprise accessibility management platform that integrates automated scanning into CI/CD pipelines and tracks remediation progress over time.
• Siteimprove Accessibility: A SaaS platform that crawls entire websites for accessibility issues and tracks compliance progress, suitable for large organizations managing multiple properties.

Common Accessibility Mistakes Web Designers Make

These are the accessibility failures that appear most frequently in audits and are most preventable at the design stage.

• Removing focus styles: The single most common accessibility failure. Designers disable the browser default focus ring because it looks ugly without replacing it with a custom focus indicator. Every interactive element needs a visible focus style. Design beautiful ones and do not remove them.
• Insufficient color contrast: Light gray text on white backgrounds, light blue links on white, and white text on light brand colors are all common contrast failures. Use a contrast checker during design, not as an afterthought during QA.
• Icon-only buttons without labels: A button with only a magnifying glass icon, a trash can icon, or a hamburger icon has no accessible name. Add a visually hidden label using CSS that is still readable by screen readers.
• Placeholder text as labels: Using placeholder text instead of visible labels fails users who need to reference the label while typing, and fails all users when they cannot remember what a field asked for after entering something.
• Non-semantic HTML: Using div elements for buttons, span elements for links, and table elements for visual layout creates an experience that is navigable visually but invisible to assistive technologies. Use native HTML elements for their intended purpose.
• Auto-playing media: Auto-playing video or audio is disorienting for screen reader users because it competes with audio feedback, and cognitively disruptive for everyone. Never auto-play. If you must, provide an immediately visible pause control.
• PDF accessibility: PDFs shared as primary content sources are frequently inaccessible. Tagged PDFs with proper reading order, alt text for images, and form fields with labels are required for accessibility. Where possible, prefer HTML content over PDFs.
• Carousel and slider abuse: Auto-advancing carousels fail multiple WCAG criteria simultaneously: moving content without pause controls, focus management issues, and touch target problems on mobile. If you must use a carousel, disable auto-advance by default.

How to Implement Accessibility in Your Workflow

Accessibility is cheapest to fix during design and most expensive to fix after launch. Integrating accessibility into your process at every stage prevents the accumulation of technical debt.

Design Phase

Use a color system that documents contrast ratios for all text and UI combinations. Annotate designs for developers with accessibility notes: which elements are interactive, what ARIA labels are needed for icon-only buttons, and what the reading order should be for complex layouts. Use Figma’s built-in accessibility annotations plugin to communicate intent. Test your designs against WCAG color contrast requirements before any code is written.

Development Phase

Establish automated accessibility linting in your IDE and CI pipeline using tools like eslint-plugin-jsx-a11y for React projects. Run axe-core in your test suite to catch regressions automatically. Write accessibility-specific unit tests for interactive components covering tab order, ARIA state changes, and focus management after modal open and close.

QA Phase

Conduct manual keyboard testing on every interactive page: navigate the entire page using only Tab, Shift+Tab, Enter, Space, and arrow keys. Verify that all functionality is reachable and operable. Test with at least one screen reader on the most critical user flows such as account creation, checkout, and core product actions.

Ongoing Monitoring

Integrate automated accessibility scanning into your deployment pipeline so that new accessibility regressions are caught before they reach production. Establish a process for users to report accessibility barriers through a dedicated email address or feedback form, and commit to responding within a defined service level agreement.

Conclusion

Web accessibility in 2026 is not an optional enhancement or a compliance checkbox. It is a fundamental quality requirement for any professional web project. WCAG 2.2 has raised the bar with new criteria around focus visibility, touch targets, and cognitive accessibility, but meeting these requirements is entirely achievable with the right knowledge and workflow integration.

Use this checklist as a living document. Audit your existing projects against it, integrate it into your design and development process, and revisit it when WCAG 2.3 and beyond are published. The best time to fix an accessibility barrier is before any user encounters it. Combining this framework with modern AI design tools that surface accessibility issues during the design phase will keep you ahead of the curve and ensure your work is usable by the widest possible audience.

WCAG 2.2 Compliance Checklist by Priority Level

WCAG 2.2 success criteria are organized into three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Most organizations aim for AA compliance. Here’s your complete checklist:

Criterion	Level	Requirement	How to Test
1.1.1 Non-text Content	A	All images have descriptive alt text	Screen reader or browser dev tools
1.3.1 Info and Relationships	A	Structure conveyed through semantic HTML	Validate with WAVE or axe
1.4.3 Contrast (Minimum)	AA	4.5:1 ratio for normal text, 3:1 for large	WebAIM Contrast Checker
1.4.11 Non-text Contrast	AA	3:1 for UI components and graphics	Manual check or Figma Contrast plugin
2.1.1 Keyboard	A	All functionality available via keyboard	Tab through the entire page
2.4.7 Focus Visible	AA	Keyboard focus indicator always visible	Remove mouse, tab through UI
2.5.3 Label in Name	A	Button text matches accessible name	Inspect with accessibility tree
3.1.1 Language of Page	A	HTML lang attribute set correctly	Check page source
3.3.1 Error Identification	A	Form errors described in text	Test form validation
4.1.3 Status Messages	AA	Status messages programmatically determinable	Test with screen reader

Accessibility Testing Tools: Which to Use and When

Tool	Type	What It Catches	Cost
axe DevTools	Browser extension	Auto-detectable WCAG issues	Free (basic) + paid
WAVE	Browser extension + web	Visual accessibility errors	Free
Lighthouse	Built into Chrome DevTools	Performance + accessibility audit	Free
NVDA	Screen reader (Windows)	Real-world screen reader testing	Free
VoiceOver	Screen reader (Mac/iOS)	Apple ecosystem testing	Built into macOS/iOS
Color Contrast Analyzer	Desktop app	Precise contrast ratios	Free
Sa11y	CMS plugin	Content-level accessibility	Free (open source)
Deque University	Training + scanner	Comprehensive audit	Paid

Accessibility Improvements and Their Business Impact

Improvement	Who Benefits	Secondary Benefits
High contrast text	Low vision, elderly users	Better readability for all in bright light
Keyboard navigation	Motor-impaired users, power users	Better UX for keyboard-heavy workflows
Descriptive alt text	Screen reader users	SEO boost from image indexing
Closed captions on video	Deaf/hard-of-hearing users	Helps users in noisy environments
Clear error messages	Cognitive disabilities	Reduces support tickets for all users
Consistent navigation	Cognitive, memory impairments	Reduces bounce rate for all users
Sufficient tap target size	Motor impairments, mobile users	Better mobile UX across the board