Website Accessibility Checklist 2026: WCAG Basics Every Designer Should Know

A website can look polished, load quickly, and still be difficult for millions of people to use. Poor contrast, inaccessible navigation, unlabeled forms, and confusing interactions create barriers that visual reviews often miss. This website accessibility checklist explains the WCAG 2.2 AA requirements designers should understand in 2026, with practical examples, testing tools, and a repeatable workflow for building more inclusive websites.

Quick Answer: A complete website accessibility checklist should cover color contrast, keyboard navigation, screen reader compatibility, alternative text, readable typography, accessible forms, responsive layouts, and clear interaction states. In 2026, WCAG 2.2 Level AA is the widely adopted accessibility target for public websites. Designers should combine automated testing with manual keyboard checks and screen reader testing before launching any important website.

Why Website Accessibility Matters in 2026

Accessibility is about ensuring people can perceive, understand, navigate, and interact with digital experiences regardless of disability or assistive technology.

This includes people with visual, hearing, motor, and cognitive disabilities. It also benefits people navigating with keyboards, using mobile devices outdoors, or dealing with temporary injuries.

The problem remains widespread. According to WebAIM’s 2026 Million report, 95.9% of the one million homepages analyzed had automatically detectable WCAG failures. The study also found an average of 56.1 detected accessibility errors per homepage.

Low-contrast text appeared on 83.9% of the tested homepages, making it the most common detected issue.

These statistics illustrate why accessibility cannot be treated as a final design adjustment. It needs to influence design decisions from the first wireframe through development and quality assurance.

Accessibility also connects directly to broader UI vs UX design principles. A visually attractive interface is not successful if users cannot complete essential tasks.

Understanding WCAG 2.2 AA Requirements

The Web Content Accessibility Guidelines, developed by the World Wide Web Consortium (W3C), provide internationally recognized standards for accessible digital content.

As of October 2026, WCAG 2.2 is the current W3C recommendation. Level AA is the widely adopted conformance target for public-facing websites, although specific legal obligations vary by jurisdiction.

The official WCAG 2.2 specification organizes accessibility requirements around four principles known as POUR.

The Four Principles of Accessibility

• Perceivable: Users must be able to access information through available senses, including screen readers and visual alternatives.
• Operable: Navigation and interactions must work with keyboards and other input methods.
• Understandable: Content, instructions, and interface behavior should be clear and predictable.
• Robust: Websites should function reliably across browsers and assistive technologies.

WCAG includes three conformance levels: A, AA, and AAA. Level A establishes foundational requirements, Level AA adds important usability protections, and Level AAA introduces additional criteria that may not be achievable across all content.

For most commercial projects, designing toward WCAG 2.2 AA provides a practical starting point. Meeting AA means satisfying all applicable Level A and AA success criteria.

Website Accessibility Checklist: Essential Design Requirements

Use this checklist during wireframing, component design, and final design reviews. Each requirement should have an identifiable owner and a way to verify implementation.

1. Check Color Contrast Ratios

Readable text requires sufficient contrast against its background.

Under WCAG 2.2 AA, normal text needs a minimum contrast ratio of 4.5:1. Large text requires at least 3:1. Large text generally means 24 CSS pixels or approximately 18.7 pixels when bold, assuming the conventional CSS pixel-to-point relationship.

Important graphical objects and interface components generally need 3:1 contrast against adjacent colors under the applicable non-text contrast criterion.

Use Stark in Figma, WebAIM Contrast Checker, or accessible color tools to evaluate combinations before finalizing a design system.

A light-gray label on a white input field might appear elegant in a mockup but become unreadable for someone with low vision.

2. Make Keyboard Navigation Possible

People who cannot use a mouse depend on keyboard navigation, switches, or other assistive inputs.

Interactive elements must be reachable in a logical sequence using the Tab key. Users should activate standard buttons with Enter or Space, and escape dismissible interfaces without becoming trapped.

Visible focus indicators are equally important. WCAG 2.2 introduces additional requirements for ensuring keyboard focus is not obscured by author-created content.

For example, a sticky website header should not completely cover a focused navigation element.

3. Provide Useful Alternative Text

Images that communicate meaningful information need equivalent text alternatives.

A product image might use alternative text such as “Black wireless headphones with padded over-ear cushions.” This communicates useful visual details without repeating unrelated marketing content.

Decorative images should generally use empty alternative text so screen readers can skip them.

For charts and complex diagrams, provide the essential information through accessible descriptions, adjacent text, or an accessible data table.

4. Use Clear Typography and Readable Layouts

WCAG does not mandate a universal 16-pixel font size, but 16 pixels is often a sensible starting point for body text.

Use readable fonts, sufficient line spacing, clear heading hierarchy, and comfortable paragraph lengths. Avoid presenting essential information through extremely thin typefaces or compressed layouts.

Content should reflow at narrow viewport widths without requiring two-dimensional scrolling for ordinary reading content.

Also ensure users can increase text spacing without losing information or functionality.

5. Design Accessible Buttons and Touch Targets

Buttons need descriptive labels, distinguishable states, and sufficient interactive area.

WCAG 2.2 AA introduces a minimum pointer target size of 24 by 24 CSS pixels, subject to specific exceptions, including sufficient spacing between smaller targets.

For mobile interfaces, designers may choose more generous touch areas, such as 44 by 44 pixels, to improve usability.

Icon-only buttons also require accessible names. A magnifying-glass icon should communicate a function such as “Search” to assistive technology.

6. Make Forms Understandable

Every form control needs a clear label that remains available after someone starts typing.

Placeholder text alone is not an adequate replacement for an accessible form label.

Required fields should be identified clearly, and errors should explain what went wrong. For example, “Enter an email address in the format [email protected]” is more helpful than “Invalid input.”

Where applicable, use programmatic field relationships, input-purpose autocomplete, and error suggestions.

For authentication flows, WCAG 2.2 also addresses accessible authentication, discouraging unnecessary cognitive function tests without appropriate alternatives or assistance.

7. Avoid Motion and Cognitive Overload

Animations can clarify interface changes, but unnecessary motion may distract or discomfort some users.

Respect reduced-motion preferences and avoid automatically moving content that cannot be paused when applicable requirements demand controls.

Use clear navigation labels, consistent layouts, and concise instructions. These practices complement approaches to designing for ADHD, where predictability and manageable information density are particularly valuable.

WCAG 2.2 AA Accessibility Requirements at a Glance

This comparison table summarizes common design requirements and practical ways to test them.

Accessibility Area	Requirement or Goal	Recommended Test
Normal text contrast	Minimum 4.5:1	Stark or contrast checker
Large text contrast	Minimum 3:1	Contrast checker
Keyboard navigation	Logical and operable	Tab, Enter, Space, Escape
Pointer targets	24 × 24 CSS pixels or applicable exception	Inspect target size and spacing
Informative images	Meaningful text alternatives	Screen reader review
Forms	Labels and clear errors	Keyboard and NVDA testing
Responsive content	Reflow without lost functionality	320 CSS-pixel viewport equivalent
Focus visibility	Visible and not entirely obscured	Manual keyboard navigation

These checks are useful acceptance criteria, but passing them alone does not establish complete WCAG conformance.

Best Website Accessibility Testing Tools in 2026

No single tool can accurately evaluate every accessibility requirement. Designers should combine design-stage validation, browser-based audits, and assistive-technology testing.

Figma and Stark

Figma supports accessible design-system workflows through reusable components, shared styles, and structured design documentation.

Stark adds dedicated accessibility checks, including color-contrast evaluation and vision-related design simulations.

Use these tools when defining colors, buttons, forms, and interactive components. They help identify issues before developers begin implementation.

WAVE and axe DevTools

WAVE, developed by WebAIM, visually identifies potential accessibility errors and structural concerns within web pages.

axe DevTools, developed by Deque Systems, integrates automated accessibility analysis into browser and development workflows.

Both can identify issues such as missing labels, problematic contrast, and certain semantic markup errors.

However, automated accessibility checkers catch only part of the picture. They cannot reliably determine whether every interaction is understandable or whether the complete experience works with assistive technology.

Google Lighthouse

Lighthouse provides automated accessibility audits within Chrome DevTools alongside performance, SEO, and other quality assessments.

Its accessibility score is useful for discovering certain implementation problems and tracking automated audit results.

A perfect Lighthouse accessibility score does not prove WCAG 2.2 AA conformance.

NVDA and VoiceOver

NVDA is a widely used free Windows screen reader. Apple’s VoiceOver is integrated into macOS, iOS, and other Apple platforms.

Testing with these technologies helps expose unclear labels, incorrect reading order, inaccessible dialogs, and confusing navigation.

Designers should also evaluate full task flows, not merely whether a screen reader announces individual elements.

How to Run a Website Accessibility Audit Step by Step

A practical accessibility audit should focus on representative pages and real user journeys.

1. Choose important pages: Start with the homepage, navigation, contact form, product pages, and checkout or registration flow.
2. Run automated checks: Use WAVE, axe DevTools, and Lighthouse to identify detectable technical issues.
3. Check contrast: Validate text, controls, error states, and focus indicators against relevant WCAG thresholds.
4. Test keyboard navigation: Complete important tasks without touching the mouse. Look for keyboard traps, missing focus states, and confusing order.
5. Test assistive technology: Use NVDA or VoiceOver to navigate headings, landmarks, forms, buttons, and dynamic content.
6. Review responsive behavior: Test at narrow widths and increased zoom, ensuring essential content remains reachable and readable.
7. Document and retest: Record each issue, relevant WCAG criterion, affected component, severity, owner, and verification result.

Prioritize barriers that prevent users from completing essential tasks. An inaccessible checkout button typically deserves more urgent attention than a minor issue with secondary decorative content.

Repeat testing after fixes. A change that solves a contrast problem might introduce another issue with hover, disabled, or focus states.

Building Accessibility Into Your Design Workflow

Accessibility becomes easier to maintain when it is part of the design system rather than a separate approval stage.

Create Accessible Components From the Beginning

Define accessible color tokens, typography scales, form fields, navigation patterns, and interaction states in Figma.

Document hover, focus, active, error, disabled, and loading states. Give developers clear expectations for keyboard behavior and accessible naming.

For visually complex arrangements, including bento grid design, verify that visual arrangement does not create a confusing reading or keyboard order.

Include Accessibility in Design Handoffs

Deliver more than static mockups. Include interaction notes explaining focus behavior, dialog dismissal, validation messages, and content order.

For example, a modal design should specify where keyboard focus moves when opened, how users close it, and where focus returns afterward.

Product teams should also maintain an accessibility issue backlog. Review recurring component problems before building additional pages using the same patterns.

Most importantly, involve people with disabilities in usability testing when possible. Their feedback can reveal barriers that neither design reviews nor automated scanners reliably identify.

Common Website Accessibility Mistakes to Avoid

Many accessibility failures result from familiar design decisions rather than unusual technical problems.

• Relying on color alone: Error messages should include text or another non-color indicator.
• Removing focus outlines: Keyboard users need a visible indication of their current position.
• Using vague links: Descriptive labels communicate destinations more clearly than repeated “Click here” links.
• Replacing semantic controls: Custom clickable containers often require extra work to reproduce native button behavior.
• Assuming overlays guarantee compliance: Accessibility widgets cannot automatically repair every structural or interaction barrier.
• Testing only the homepage: Forms, menus, account flows, and dynamically updated interfaces need separate attention.

Avoid treating accessibility as a simple score optimization exercise. The objective is usable experiences, not merely fewer automated warnings.

Frequently Asked Questions

What should a website accessibility checklist include?

A website accessibility checklist should include color contrast, keyboard navigation, focus visibility, alternative text, semantic structure, accessible forms, readable content, responsive layouts, and screen reader compatibility. It should also cover meaningful error messages, understandable interactions, and motion preferences. Each requirement needs an appropriate testing method rather than relying exclusively on automated accessibility scores.

Is WCAG 2.2 AA legally required for every website?

No. WCAG 2.2 AA is a widely adopted accessibility target, but legal requirements depend on the jurisdiction, organization, and type of service. Some regulations reference earlier WCAG versions or define different obligations. Businesses should review applicable laws and contractual requirements while using WCAG 2.2 AA as a practical design and development benchmark.

Can I test website accessibility for free?

Yes. WAVE, Lighthouse, and NVDA provide useful free accessibility testing capabilities. Chrome DevTools also includes tools for inspecting accessibility information and responsive behavior. However, free automated testing alone is insufficient. You still need manual keyboard testing, screen reader reviews, and practical checks of navigation, forms, and other essential user journeys.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 builds on WCAG 2.1 by introducing additional success criteria covering areas such as focus visibility, target size, accessible authentication, and alternatives to dragging movements. WCAG 2.2 also removes the earlier 4.1.1 Parsing criterion. For new projects, teams should generally evaluate the newer criteria while maintaining all applicable existing requirements.

Does a 100 accessibility score in Lighthouse mean my website is accessible?

No. A Lighthouse accessibility score reflects the automated checks included in that audit, not complete WCAG conformance. Some problems require human judgment, including unclear instructions, confusing reading sequences, and inaccessible interaction flows. A reliable evaluation combines automated scanning, keyboard navigation, screen reader testing, and realistic user-task reviews across representative pages.

Conclusion: Make Accessibility Part of Every Design Decision

Website accessibility in 2026 requires more than choosing readable colors or installing an automated checker. Designers need to understand WCAG 2.2 AA, define accessible components, consider keyboard and screen reader interactions, and collaborate with developers throughout implementation.

Start with high-impact improvements: readable contrast, clear labels, visible focus states, predictable navigation, and functional forms. Validate them using Figma, Stark, WAVE, axe DevTools, Lighthouse, and real assistive technologies.

The most useful website accessibility checklist is one your team applies consistently, tests against real interactions, and updates as the website evolves. Accessibility should be a normal measure of design quality, not an optional finishing task.