Accessibility Testing for Websites: A Practical WCAG 2.2 Checklist

Accessibility is no longer a “nice to have” line item. It shapes who can buy, who can apply, who can request a quote, and who can even understand what your company offers. When accessibility fails, the cost shows up as abandoned flows, higher support load, and legal or procurement risk.

Accessibility testing for websites is also a direct usability upgrade. Most fixes that support screen readers, keyboard navigation, and low vision users also improve clarity for everyone else. That means fewer friction points between interest and conversion, and a cleaner experience for the teams maintaining the site.

For decision makers, website accessibility testing is best viewed as operational hygiene. It reduces avoidable risk, improves reach, and creates a standard your team can repeat across redesigns, new landing pages, and product launches.

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, with updates maintained by W3C. It builds on WCAG 2.1 and WCAG 2.0, and keeps the same core structure under the POUR principles: Perceivable, Operable, Understandable, Robust. For most organizations, “WCAG 2.2 compliance” is shorthand for aligning experiences to WCAG Level AA as the practical baseline. (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)

The New WCAG 2.2 Success Criteria to Know

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

• Focus Appearance (2.4.11): focus indicators need to be clearly visible, not subtle.
• Focus Not Obscured (2.4.12 and 2.4.13): focus should not disappear behind sticky headers, chat widgets, or overlays.
• Dragging Movements (2.5.7): actions that rely on dragging need a simpler alternative.
• Target Size Minimum (2.5.8): small tap targets create real error rates on touch devices. (W3C Understanding Target Size Minimum)
• Consistent Help (3.2.6): Help mechanisms should be consistently placed when present.

If you run website accessibility testing today, these are the spots where many otherwise polished websites still stumble.

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

Most teams aim for WCAG Level AA because it is widely referenced in procurement, public sector expectations, and policy language. It is also the level where the checklist becomes meaningfully user centered rather than minimal. Treat “WCAG 2.2 checklist” items as your working definition of acceptable quality.

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. That does not diminish the practical value of WCAG 2.2 compliance, but it does change how you document conformance.  (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 a baseline set of environments. A practical set often includes:

• Keyboard only navigation
• One screen reader on Windows and one on macOS
• Mobile screen reader behavior on iOS or Android
• 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)

The Accessibility Audit Workflow That Actually Works

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 checks you can perform. It also reveals focus management problems that are directly tied to WCAG 2.2 compliance.

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

If you only do one thing in your accessibility testing for websites, do this. It finds issues that directly block conversions.

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 at:

• 200 percent zoom on desktop
• 400 percent zoom on desktop for reflow expectations
• Increased text size settings on mobile

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 prove and maintain WCAG 2.2 compliance.

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

If you want a faster workflow, bake contrast rules into a design system. That reduces rework, improves consistency, and makes WCAG 2.2 compliance easier 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:

• No horizontal scrolling at typical breakpoints when zoomed to 200 percent
• Content reflows logically at 400 percent zoom
• Text does not overlap, truncate, or disappear
• Line height and spacing remain readable
• Sticky elements do not cover essential content or form fields

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 raised expectations for focus visibility. This is a major operational change for teams who previously relied on subtle outlines or browser defaults.

Check:

• Focus indicator is clearly visible and not too thin
• Focus has sufficient contrast against surrounding UI
• Focus is not covered by sticky headers, cookie banners, or chat widgets
• When overlays appear, focus moves predictably and returns correctly
• “Focus not obscured” holds true in real layouts, not only in isolation

This is one of the most common fails during accessibility testing for websites with heavy marketing overlays.

Target Size and Spacing

Small targets increase error rates on touch and for users with motor limitations. WCAG 2.2 compliance brings this into clearer focus.

Check:

• Buttons and controls meet minimum size or spacing expectations
• Inline links are not packed too tightly
• Icon buttons have sufficient touch area
• Form controls and checkboxes are not tiny
• Navigation elements are usable on mobile without precision taps

If your conversions happen on mobile, target size is not a compliance detail. It is a funnel detail.

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 messages are timed, dismissible, and consistent 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 gap in WCAG 2.2 compliance for sites built with component frameworks.

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 understand why accessibility testing for websites is not just compliance work. It is conversion protection.

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 create faster WCAG 2.2 compliance across the site because you are repairing the system, not only the page.

Regression Testing After Changes

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

Re test:

• 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. If you are formalizing how teams build and publish, a focused marketing consultation and audit can help connect accessibility to governance, analytics, and conversion goals without turning it into a separate program.

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 model is:

• Scheduled automated scans on key templates
• Quarterly manual keyboard accessibility reviews
• Screen reader testing on at least one core flow per quarter
• Accessibility QA added to release checklists for major changes

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 whether we need WCAG 2.2 compliance or WCAG 2.1?

Follow whatever your contracts or policies require first, since many still cite WCAG 2.1 AA. Then use the WCAG 2.2 checklist to address newer gaps like focus visibility, target size, and dragging alternatives. This keeps documentation clean while improving real usability.

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?

Run automated scans weekly or with each release on key templates. Do manual keyboard testing before major launches and template changes. Re-test quarterly with a screen reader on a full conversion flow to catch regressions.

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 you want help turning these checks into a sustainable workflow, Brand Vision can support the full path from audit to remediation. That includes aligning your design system, templates, and conversion flows so accessibility improvements stay consistent as the site evolves. Start a conversation with our team through Brand Vision or explore our web design services and UI/UX practice to map out a clear, implementation-ready plan.

‍