Website Accessibility Testing Checklist: A Practical WCAG 2.2 Workflow

Accessibility affects whether people can buy, apply, request a quote, or understand what a company offers. When accessibility fails, the result can be blocked tasks, higher support demand, and legal or procurement risk.

Website accessibility testing is also a usability check. Keyboard navigation, screen-reader support, readable contrast, resilient forms, and flexible layouts help people with disabilities and often make interfaces clearer to maintain and use.

For decision makers, the goal is a repeatable testing process that can be applied to redesigns, landing pages, product releases, and ongoing maintenance. For broader context on accessible brand and web systems, see Brand Vision's guide to accessibility.

WCAG 2.2 Explained in Plain Terms

WCAG 2.2 is the latest major revision of the Web Content Accessibility Guidelines published as a W3C Recommendation. It builds on WCAG 2.1 and WCAG 2.0 and keeps the same POUR structure: Perceivable, Operable, Understandable, and Robust. Level AA is a common practical target, but legal, contractual, and policy requirements can specify a particular WCAG version and conformance level. (W3C WCAG 2.2)

If your team needs a practical way to read the standard, treat WCAG as testable requirements, not philosophical guidance. Accessibility testing for websites is simply the process of proving, with evidence, that users can perceive content, operate controls, understand flows, and reliably use the site with assistive technology.

What Changed in WCAG 2.2

WCAG 2.2 introduces additional success criteria with a strong emphasis on usability for people with low vision, mobility limitations, and cognitive considerations. Many teams find the new requirements land in familiar territory: focus indicators, tap targets, and interactions that rely on dragging. (W3C)

Several WCAG 2.2 Criteria That Often Surface in Testing

Several WCAG 2.2 additions commonly surface during a modern accessibility audit:

• Focus Not Obscured (Minimum) (2.4.11, Level AA): keyboard focus must not be entirely hidden by author-created content.
• Focus Not Obscured (Enhanced) (2.4.12, Level AAA): focused components must not be obscured by author-created content.
• Focus Appearance (2.4.13, Level AAA): adds specific size and contrast requirements for the visible focus indicator.
• Dragging Movements (2.5.7, Level AA): functionality that uses dragging needs an alternative that does not require dragging, unless an exception applies.
• Target Size (Minimum) (2.5.8, Level AA): pointer targets generally need to meet the minimum size or spacing conditions, subject to the criterion's exceptions. (W3C Understanding Target Size Minimum)
• Consistent Help (3.2.6, Level A): when specified help mechanisms are provided, they should appear in a consistent relative order.

This is not the full list of WCAG 2.2 additions, but these criteria frequently affect navigation, forms, overlays, and touch interactions.

Set Your Scope Before You Test

A common failure mode is trying to test everything at once with no clear definition of “done.” That creates long reports, slow remediation, and unclear ownership. A better approach is to define scope like you would for performance or analytics: what matters most, and what represents the true user experience.

Pick a Conformance Target

Many organizations choose Level AA as a practical target because laws, procurement requirements, contracts, and internal policies often reference it. The applicable WCAG version and level should come from the requirement governing the organization, not from a generic checklist alone.

If you operate in regulated contexts, confirm whether your requirements reference WCAG 2.1 AA or WCAG 2.2 AA. For example, the U.S. Department of Justice issued a Title II rule for state and local governments tied to WCAG 2.1 Level AA. Testing against WCAG 2.2 can still surface newer accessibility issues, but documentation should distinguish the standard you test against from the standard a specific rule requires.  (ADA.gov)

Choose Your Representative Pages and Flows

For accessibility testing for websites, prioritize what people actually use:

• Homepage and primary navigation paths
• Top acquisition landing pages
• One or two core conversion flows (lead form, booking, checkout, application)
• Account or portal flows if applicable
• Template types, not just unique pages (blog post, service page, case study, product page)

This keeps the accessibility audit tied to revenue and experience rather than a random crawl.

Decide Which Assistive Tech You Will Support

Website accessibility testing is more credible when you define representative browsers, operating systems, and assistive technologies based on your audience and product. A practical baseline may include:

• Keyboard-only navigation
• One or more widely used screen reader and browser combinations relevant to Windows and/or macOS
• Mobile screen reader behavior on iOS and/or Android when mobile flows matter
• High zoom and text-resizing behavior

If you need a reality check on how screen reader users browse, WebAIM’s survey data is a useful grounding point for prioritization. (WebAIM)

A Practical Accessibility Audit Workflow

An accessibility audit should feel like a repeatable QA process, not a one-time research project. The fastest path to results is a layered approach: automated scans for breadth, manual checks for real usability, then structured documentation so fixes are unambiguous.

Step 1: Automated Scans

Automated tools catch patterns quickly, but they cannot prove accessibility. Use them to identify issues like missing labels, contrast failures, and invalid markup. Examples include Lighthouse, axe, and WAVE. Keep the output focused on patterns you can fix at scale, not hundreds of near duplicates.

During website accessibility testing, treat automated results as a starting map, not a final answer. A clean scan does not mean the experience is accessible.

Step 2: Manual Keyboard Accessibility Checks

Keyboard accessibility is one of the highest-leverage manual checks you can perform. It also reveals focus-management problems that automated scans often miss.

Test these basics on every key page:

• You can reach all interactive elements using Tab and Shift+Tab
• You can activate controls using Enter and Space
• Focus order follows the visual and reading order
• There is no keyboard trap
• Menus, dialogs, and drawers can be opened and closed without a mouse

Keyboard testing should be a high-priority manual check because failures can prevent users from completing key tasks.

Step 3: Screen Reader Testing

Screen reader testing is where “technically valid” experiences often fail. The goal is not to become an assistive tech expert overnight. The goal is to validate that page structure, labels, and states create a coherent experience.

Run screen reader testing on:

• The homepage navigation
• One conversion flow end-to-end
• Any complex components (filters, tabs, accordions, modals)

Listen for whether headings form a usable outline, whether buttons announce what they do, and whether error messages are communicated clearly.

Step 4: Zoom, Reflow, and Contrast

Low vision support is not only about color contrast. It is also about whether layouts survive zoom, whether text overlaps, and whether the interface becomes unusable when users increase font size.

Test text resizing and reflow separately:

• Resize text to 200 percent where WCAG 1.4.4 applies and verify content and functionality remain available.
• Test reflow at the equivalent of a 320 CSS-pixel-wide viewport. On a typical 1280 CSS-pixel desktop viewport, 400 percent browser zoom is a practical way to exercise that condition. W3C Understanding Reflow
• Check increased text-size settings on mobile where the platform supports them.

Step 5: Document Findings in a Consistent Format

A strong accessibility audit produces tickets, not essays. For each issue, capture:

• The success criterion reference (for WCAG 2.2 checklist alignment)
• Steps to reproduce
• Expected behavior
• Actual behavior
• Suggested fix pattern
• Screenshot or short clip
• Affected templates or components

This format makes it easier to document conformance findings, assign ownership, and verify remediation.

WCAG 2.2 Checklist for Perceivable Content

Perceivable means users can sense and understand the content, whether through sight, sound, or assistive technology. In practice, these requirements show up in content structure, alternatives for media, and visual presentation rules.

Text Alternatives and Media

Use this WCAG 2.2 checklist to test perceivable content:

• Images that convey meaning have accurate alt text
• Decorative images have empty alt text so they are ignored by screen readers
• Icon-only buttons have accessible names that describe the action
• Video content has captions, and audio-only content has transcripts when relevant
• Embedded media controls are keyboard accessible and labeled

This is also where branding and content intersect. If your team relies on image-based text or stylized headlines as images, the site often becomes fragile for assistive tech. A better approach is semantic HTML plus visual styling that preserves the brand system. If you are building or rebuilding templates, this is a natural place to think about visual identity rules that work in code, not just in mockups.

Color, Contrast, and Visual Presentation

Contrast is one of the most visible issues in website accessibility testing, and also one of the easiest to miss during design reviews.

Check:

• Text contrast meets Level AA thresholds for normal and large text
• Icons that communicate meaning meet contrast requirements
• Focus indicators are visible against backgrounds
• Placeholder text is not used as the only label
• Error states are not communicated by color alone

Baking contrast rules into a design system can reduce rework and make accessible color combinations more consistent across marketing pages, landing pages, and product flows.

Responsive Type and Layout at High Zoom

Perceivable also means content remains readable as users zoom and adjust text.

Test:

• Text can be resized to 200 percent without loss of content or functionality where WCAG 1.4.4 applies.
• At the equivalent of a 320 CSS-pixel-wide viewport, content reflows without two-dimensional scrolling except for content that legitimately requires it.
• Text does not overlap, truncate, or disappear as the layout changes.
• Text spacing adjustments do not cause content or controls to break.
• Sticky elements do not cover essential content, controls, or the element receiving keyboard focus.

These issues often reflect layout decisions rather than isolated bugs. If your templates feel tight or brittle, it may be time for a more system driven approach to web design services that treats accessibility as part of core quality.

WCAG 2.2 Checklist for Operable Navigation

Operable means users can navigate and interact with the interface, regardless of input method. This is where keyboard accessibility, focus treatment, and tap targets directly affect conversion.

Keyboard Accessibility and Focus Management

Use this WCAG 2.2 checklist for the operable baseline:

• Every interactive element is reachable and usable without a mouse
• Focus order is logical and matches intent
• Focus is never lost in dynamic components
• Modals trap focus correctly and return focus to the trigger on close
• Skip links exist where pages have repeated navigation

Keyboard accessibility problems are rarely “small.” They block users from completing flows. They also tend to correlate with broader UI architecture issues. A disciplined UI UX design agency approach usually treats focus and keyboard states as first class design tokens, not afterthoughts.

Focus Appearance and Focus Not Obscured

WCAG 2.2 adds Focus Not Obscured (Minimum) at Level AA. Focus Appearance is a separate Level AAA criterion. Regardless of conformance target, visible and predictable focus treatment remains an important usability check.

Check:

• A visible focus indicator is present when keyboard focus moves through interactive elements.
• At Level AA, the focused component is not entirely hidden by author-created content.
• Sticky headers, cookie banners, chat widgets, and other overlays do not obscure the focused component in real layouts.
• When dialogs or overlays open, focus moves predictably and returns appropriately when they close.
• If your target includes the Level AAA Focus Appearance criterion, test its specific indicator-size and contrast requirements separately.

These problems often appear on pages with sticky navigation, consent banners, chat controls, and other persistent overlays.

Target Size and Spacing

WCAG 2.2 adds Target Size (Minimum) at Level AA. The criterion generally uses a 24 by 24 CSS-pixel minimum, with specific exceptions for spacing, inline targets, user-agent controls, essential presentation, and equivalent controls.

Check:

• Buttons and controls meet the minimum target-size condition or a documented exception.
• Icon buttons have a usable activation area.
• Form controls and checkboxes are practical to operate without precision tapping.
• Inline text links remain distinguishable and usable even where an exception applies.
• Navigation controls remain usable on mobile and at increased zoom.

Target-size failures can create both accessibility barriers and ordinary mobile usability problems.

Dragging Movements and Complex Gestures

Many modern interfaces use dragging, swiping, and gesture-driven controls. WCAG 2.2 expects alternatives.

Check:

• Drag to reorder has a non-drag method (buttons or menus)
• Sliders and carousels can be operated with keyboard controls
• Swipe-only interactions have visible controls
• Complex gestures have simpler equivalents
• Critical actions do not require fine motor precision

This area is especially important in product UI and interactive tools, but it also shows up in marketing pages with sliders and interactive comparisons.

WCAG 2.2 Checklist for Understandable Experiences

Understandable means users can predict what will happen, understand instructions, and recover from errors. It is a blend of content, interaction design, and clear messaging.

Forms, Errors, and Instructions

For website accessibility testing, forms deserve their own pass because form failures are direct conversion losses.

Check:

• Every input has a programmatic label
• Required fields are indicated clearly, not only by color
• Error messages are specific and placed where users notice them
• Errors are announced to screen readers and linked to the relevant fields
• Instructions are clear and do not rely on placeholder text alone

A practical accessibility audit also checks whether validation feedback is associated with the relevant field, remains available long enough to act on, and behaves consistently across templates.

Predictable Navigation and Consistent Help

WCAG 2.2 includes “consistent help” expectations. This often catches teams by surprise because it is not purely technical.

Check:

• Help links, chat, or support entry points appear in consistent locations when present
• Navigation patterns are consistent across pages
• Components behave predictably (accordions, tabs, menus)
• New windows or context changes are clearly indicated
• Language is consistent for repeated actions and labels

This is where accessibility overlaps with brand clarity. If labels are inconsistent, users with or without disabilities feel the friction.

WCAG 2.2 Checklist for Robust Code

Robust means the site works across assistive technologies and user agents, and remains resilient as components evolve. This is where semantic HTML and disciplined ARIA usage matter.

Semantic HTML and Landmarks

Check:

• Headings follow a logical hierarchy
• Landmark regions are used appropriately (header, nav, main, footer)
• Lists are marked up as lists
• Tables use proper headers when truly tabular
• Buttons are real buttons, not clickable divs

The more semantic the foundation, the easier screen reader testing becomes. It also makes sites easier to maintain across redesigns.

ARIA Used Correctly

ARIA is powerful and easy to misuse. During accessibility testing for websites, verify that ARIA is used to enhance semantics, not replace them.

Check:

• ARIA labels match visible labels
• ARIA roles are appropriate and not redundant
• Custom controls expose name, role, value, and state
• Hidden content is truly hidden from assistive tech
• No invalid ARIA attributes or conflicting roles

If your automated scans show heavy ARIA usage, compare it against error trends. WebAIM’s annual analysis has repeatedly highlighted how errors remain common at scale across popular sites. (WebAIM Million 2025)

Status Messages and Dynamic Updates

Modern sites use dynamic updates: inline form validation, live search, and toast notifications. Robust experiences communicate these changes.

Check:

• Status messages are announced to screen readers when appropriate
• Error summaries are available for long forms
• Loading states are clear and do not trap focus
• Autocomplete and suggestions are keyboard operable
• Route changes in single-page apps preserve focus and context

This is a frequent accessibility gap on sites built with component frameworks and dynamic interfaces.

From Findings to Fixes: Prioritization, Tickets, and QA

An accessibility audit only matters if it leads to fixes that ship. The most effective teams treat remediation like product work: clear severity, clear owners, and a retest plan.

Severity Levels That Make Sense to Leaders

Use a simple scale tied to business outcomes:

• Blocker: prevents task completion (keyboard trap, unlabeled form fields in checkout)
• High: significantly degrades usability (missing focus states, broken error handling)
• Medium: important but not flow-stopping (some contrast failures, minor labeling)
• Low: polish issues (redundant labels, minor semantic improvements)

This framing helps leadership connect accessibility findings to user impact, delivery risk, and business-critical tasks.

Fix Patterns for Product Teams

Instead of one-off fixes, prioritize patterns:

• Button, link, and input components
• Modal and drawer behavior
• Navigation patterns
• Form validation and error patterns
• Global typography and spacing rules for target size and focus

Pattern fixes make remediation more consistent across the site because the team is repairing the system, not only the page where an issue was first found.

Regression Testing After Changes

Every fix needs a retest, especially when it touches shared components.

Retest:

• Keyboard accessibility for the affected components
• Screen reader testing for the flow where the issue appeared
• Mobile behavior for target size and focus visibility
• Zoom and reflow for layout changes
• Automated scan to confirm the error is gone, not merely shifted

Teams that skip regression testing often reintroduce the same issues during content updates and design iterations.

Accessibility Testing in Design and Content Workflows

The cheapest accessibility fixes are the ones you prevent. That requires decisions in design systems, content operations, and release practices.

Design System and Component Library Rules

If your team maintains a component library, define accessibility requirements as part of the component definition:

• Keyboard accessibility is a required acceptance criterion
• Focus states are designed, not left to defaults
• Minimum target sizes are built into spacing tokens
• Error patterns are standardized
• ARIA patterns are documented for custom controls

This is where UX decisions become operational. It also reduces risk when new pages are launched quickly. For teams that need a structured review of existing flows and components, Brand Vision's UX audit services can connect accessibility findings with usability and prioritized remediation.

Content Publishing Rules That Prevent Drift

Many accessibility issues are content-driven, not development-driven.

Add publishing rules such as:

• Alt text guidelines with examples
• Heading structure rules for long pages
• Avoiding image-only text blocks
• Link text rules that avoid “click here”
• Video caption expectations

For organizations that publish frequently, these rules reduce the need for repeated accessibility testing for websites after every update.

Ongoing Monitoring Without False Confidence

Monitoring matters, but it cannot replace periodic manual checks.

A sustainable cadence should match release frequency, risk, and the importance of the affected flows. Common elements include:

• Automated scans on key templates as part of the release or QA process
• Manual keyboard reviews when shared components or important templates change
• Screen reader testing on core flows at planned intervals and after major changes
• Accessibility QA added to release checklists for significant updates

If your site is a key acquisition channel, accessibility is part of growth operations. The same teams who manage performance, analytics, and search engine optimization often benefit from treating accessibility as a measured, repeatable practice.

FAQ

What is the fastest way to start accessibility testing for websites?

Start with your top templates and one core conversion flow. Run an automated scan, then do a manual keyboard pass to confirm everything is reachable and usable. Add a quick screen reader check for headings, labels, and errors. Log issues as patterns so fixes scale.

How do I know which WCAG version to test against?

Start with the standard named in the law, contract, procurement requirement, or internal policy that applies to your organization. If that requirement cites WCAG 2.1 AA, document testing against that target. Teams can also test the additional WCAG 2.2 criteria to identify newer gaps, but the report should distinguish the required conformance target from any broader best-practice testing.

What should an accessibility audit deliverable include?

A prioritized list of issues with clear steps to reproduce and the WCAG reference for each. Include expected versus actual behavior and a recommended fix pattern. Emphasize manual findings like keyboard access, focus behavior, form errors, and screen reader output.

Which tools are best for website accessibility testing?

Use tools for coverage and manual checks for confidence. Lighthouse, axe, and WAVE are useful for labels, contrast, and markup issues. Pair them with keyboard testing and a screen reader pass on a real flow. Component checks help prevent repeats.

How often should we run accessibility testing for websites?

Match the cadence to how often the site changes and how critical the affected flows are. Automated checks can run as part of routine release QA, while keyboard and screen reader testing should be repeated after major component, template, navigation, or form changes and at planned intervals for important user journeys.

Build Accessibility Into the Way Your Site Grows

Accessibility testing for websites is most effective when it becomes part of how your team ships, not a one-time cleanup. A practical WCAG 2.2 checklist, repeatable keyboard checks, and focused screen reader testing will catch the issues that quietly hurt conversions, increase support load, and create avoidable risk. When accessibility is built into templates and components, every new landing page, campaign, and product update inherits a stronger baseline.

If your team needs help turning these checks into a prioritized remediation plan, Brand Vision can review the highest-risk templates and flows and help connect accessibility findings to design and implementation. Contact our team to discuss the scope.