Accessibility Testing: Ensuring Inclusivity

Syed Zohaib ur RehmanLast Updated on November 4, 2026

9-10 Min Read TimeAdd as preferred on Google

Key Takeaways

Accessibility testing checks a product against WCAG using automated scans, manual checks and users with disabilities, and most teams should target Level AA.

• Most teams should target WCAG Level AA.
• Laws in the US, UK and EU usually reference WCAG Level AA, and legal counsel should confirm which rules apply.
• Testing covers six areas, including keyboard navigation, color contrast and screen readers.
• axe-core finds on average 57% of WCAG issues automatically, according to its maintainers, and W3C guidance says such tools can only assist.
• Manual keyboard and screen reader passes cover judgments tools cannot make, such as whether alt text describes an image accurately.
• Users with disabilities can reveal issues testers may miss.
• A practical start is running axe or WAVE on the three highest-traffic flows, such as sign-up, search and checkout, then adding keyboard and screen reader passes.

Log each issue against the WCAG criterion it fails and retest the same flows on every release.

Many websites and apps pass functional QA and still stop people who use a keyboard, a screen reader or browser zoom from finishing basic tasks such as signing up or paying. That gap carries legal risk. Rules in the US, UK and EU usually point to WCAG Level AA as the standard.

Accessibility testing finds those gaps before customers do. It checks a product against WCAG through automated scans, manual checks and sessions with people with disabilities, and the sections below cover what to check, the four WCAG principles, the conformance levels and where a team can sensibly start.

What Is Accessibility Testing?

Accessibility (A11y) testing checks whether people with disabilities, including people who use assistive technology such as screen readers, can perceive, operate and understand a website, app or other digital content. It covers whether users can move through pages, forms and controls without a mouse or without full sight. The usual yardstick is the Web Content Accessibility Guidelines (WCAG).

WCAG has limits, and the guidelines say so themselves. Following them will not address every need of people with disabilities. Legal duties also vary by jurisdiction and sector, and EU rules exempt the smallest service businesses.

Why Does Accessibility Testing Matter?

Accessibility testing helps a company meet legal requirements, reach more users and make its product easier for everyone to use. Teams that sell online also treat accessibility as a key to business success.

Legal Requirements for Digital Accessibility

As of October 2026, laws in the US, UK and EU require many organizations to make websites and apps accessible, usually measured against WCAG Level AA.

The US ADA Title II rule sets WCAG 2.1 Level AA for state and local government websites and mobile apps. UK public sector websites and apps must meet WCAG 2.2 AA unless exempt. The EU's European Accessibility Act applies to products and services placed on the market after June 28, 2025, such as online shops and banking services, though service businesses with fewer than 10 employees and under EUR 2 million turnover are exempt.

Testing is how a team proves conformance. Legal counsel should confirm which rules apply to each sector and market.

Reaching Users with Disabilities

The World Health Organization's disability fact sheet (2023) estimates that 1.3 billion people, or 1 in 6 people worldwide, experience significant disability. A product that fails keyboard, screen reader or contrast checks shuts many of them out, and testing is how a company finds those failures and starts serving this audience properly.

Commitment to Equal Access

Saying a company values equal access is easy. An accessible product lets customers check that claim for themselves, and a published accessibility statement backed by steady fixes to reported issues gives it a public record.

Better Usability for Every User

The fixes help everyone. Clearer headings and structure, buttons with descriptive labels and predictable navigation all come out of the issues accessibility testing finds, and they make life easier for anyone scanning a page in a hurry or squinting at a small screen.

What to Check in Accessibility Testing

Most accessibility testing covers six areas, each tied to WCAG requirements, and together they work as a starting checklist for an accessible website.

Testing Across Devices and Platforms

Content and functions should work the same way on desktop browsers and on Android and iOS devices, so testers repeat the main user flows on each platform. Small screens count too.

Keyboard Navigation Testing

Many users never touch a mouse. Testers press Tab through every link, button and field and confirm that focus moves in a logical order, which matters for people with motor disabilities and for screen reader users. WCAG's Focus Visible criterion (Level AA) also requires a visible keyboard focus indicator.

Color Contrast Testing

People with low vision need enough contrast between text and its background. WCAG's Contrast (Minimum) criterion, a Level AA requirement, sets a contrast ratio of at least 4.5:1 for normal-size text and 3:1 for large text.

Screen Reader Testing with VoiceOver, NVDA and JAWS

Testers check that headings, link text, button names, image alt text and form labels are announced correctly and in the same reading order a sighted user would follow on the page. An unlabeled icon button fails here.

Testing Time Limits and Timed Content

Session timeouts and timed checkout forms can lock out users who need more time. Under WCAG's Timing Adjustable criterion (Level A), two accepted options are letting users turn off a time limit before reaching it, or warning them before it expires and giving at least 20 seconds to extend it with a simple action. Testers trigger each timeout on purpose.

Form and Input Field Accessibility

Forms are where many users get stuck. Each field needs a label that screen readers announce, with instructions placed before the field. When a submission fails, the error should be described in text that names the field and explains the fix, because a red border alone tells a screen reader user nothing.

The Four WCAG Principles (POUR)

WCAG 2.2 is built on four principles, usually shortened to POUR. Content has to be perceivable, operable and understandable, and the R covers content that keeps working with browsers and assistive technologies such as screen readers. Testers use the four to group their checks.

Perceivable

Content and UI components are presented in ways every user can perceive, for example through text alternatives for images and sufficient color contrast.

Operable

Every function works by keyboard, and users get enough time to read and act on content.

Understandable

Components behave consistently, and forms and controls come with clear instructions.

Robust

Content is structured so that assistive technologies such as screen readers can interpret it correctly.

A separate Arbisoft post covers the WCAG guidelines under each principle.

WCAG Conformance Levels A, AA and AAA

The W3C's Web Content Accessibility Guidelines (WCAG) 2.2, a W3C Recommendation published in 2024, defines three conformance levels: A (lowest), AA and AAA (highest). All WCAG 2 success criteria are written to be testable, and checking conformance combines automated testing with human evaluation.

Level A (Basic)

Level A is the minimum level of conformance. Its checks include letting users reach every element with a keyboard and giving images alternative text, along with a rule that information, structure and relationships conveyed through presentation must be programmatically determinable or available in text.

Level AA (Mid-Range)

A Level AA page satisfies all Level A and AA criteria, such as a contrast ratio of at least 4.5:1 for normal-size text and a visible keyboard focus indicator. AA is also the level laws usually reference, with WCAG 2.1 AA under the US ADA Title II rule for state and local government websites and mobile apps, and WCAG 2.2 AA for UK public sector websites and apps. For most products, AA is the right target.

Level AAA (High-Level/Most Advanced)

Level AAA requires every Level A and AA criterion plus a set of stricter additional criteria.

Best Practices for Implementing Accessibility Testing

No single method catches everything. Automated tools, manual checks and real users each find different problems, so the programs that hold up use all three throughout development.

Test Accessibility Early in Development

Testing should begin as early as design and code review. Issues caught at that stage, such as a missing label in a mockup or an unlabeled icon button in a pull request, are easier to fix than the same issues found after release, when they may already be repeated across many pages.

Use Axe, WAVE and Lighthouse for Automated Checks

Automated tools speed up testing and catch common issues such as insufficient color contrast or missing alt text for images. axe-core is an accessibility testing engine that its maintainers say finds on average 57% of WCAG issues automatically. WAVE, a suite of evaluation tools, can identify many WCAG errors, while Lighthouse produces an accessibility score that is a weighted average of the pass/fail accessibility audits it runs on each page.

Scores still need context. W3C WAI's guide Selecting Web Accessibility Evaluation Tools says such tools cannot determine accessibility and can only assist. Our post on why automated scanners catch only a fraction of issues covers the gaps.

Add Manual Keyboard and Screen Reader Testing

Tools cannot judge meaning. Human judgement is required for checks no tool can run, such as whether alt text describes an image accurately or whether a complex widget makes sense when operated without a mouse. Testers should move through each flow using only a keyboard, check it with a screen reader and confirm that content is structured logically.

Test with Users with Disabilities

Real users with disabilities belong in the process. Their firsthand feedback shows how well a product meets their needs, and it is one of the most important steps in accessibility testing, because sessions with them reveal issues that may not be apparent to developers or testers at all.

Monitor Accessibility Continuously

Accessibility is never a one-time job. Every new piece of content, feature or design update can introduce a barrier that the last round of testing never saw, which means monitoring and testing have to keep running as the product changes. Regular audits keep the product in line with accessibility standards and keep improving the experience over time.

Train Designers and Developers

Designers and developers need regular accessibility training. A team that understands what people with disabilities actually need designs and builds more inclusive products from the start, and recurring sessions on accessibility standards and guidelines keep everyone current on best practices and on where the field is heading.

Where to Start with Accessibility Testing

WCAG 2.2 AA is the sensible target for most teams. Getting there takes automated scans plus manual keyboard and screen reader passes and sessions with users with disabilities, because WCAG conformance alone will not address every user need.

A practical first step is to pick the three highest-traffic user flows, for example sign-up, search and checkout, and run axe or WAVE on them. A keyboard-only pass and a screen reader pass come next. Each issue gets logged against the WCAG criterion it fails, and the same flows are retested on every release so that fixed problems stay fixed.

Teams that want an outside review can ask Arbisoft's QA team for an accessibility audit against WCAG 2.2 AA.

Frequently Asked Questions About Accessibility Testing

Which WCAG level should we test against?

Level AA, for most teams. It is the level the US ADA Title II rule references for state and local government websites and apps (WCAG 2.1 AA), and the level UK public sector websites and apps must meet (WCAG 2.2 AA). Level AAA adds stricter criteria on top of AA.

Can automated tools handle all accessibility testing?

No. axe-core finds on average 57% of WCAG issues automatically, according to its maintainers, and W3C guidance says evaluation tools cannot determine accessibility on their own and can only assist. Keyboard, screen reader and user testing cover the rest.

How often should we run accessibility tests?

Our view is that automated checks belong on every build or pull request, manual keyboard and screen reader passes belong before any release that changes the UI, and a full audit makes sense whenever a product is redesigned. That cadence catches regressions early.

Do mobile apps need accessibility testing too?

Yes. The ADA Title II rule covers state and local government mobile apps, and the UK rules cover public sector apps. Testing should use VoiceOver on iOS and TalkBack on Android and follow the same sign-up, search and checkout flows that the team already checks on the website.