Accessibility Testing: Methods and Approaches

Automated testing tools come as browser extensions, as modules built into the browser developer tools, and as command-line tools for the pipeline. What they have in common is that they test the current page against a WCAG rule base. Results are typically grouped by severity (critical, serious, moderate, minor) and contain descriptions of the problem, the affected element and a solution hint. To turn these findings into a sound assessment, we consolidate them in our WCAG audit.

Many of these test engines are available as open-source libraries and can be integrated into automated test pipelines. Combined with testing frameworks, the checks can be run on every build or pull request. This helps keep new, automatically detectable accessibility problems out of production code. For existing projects, we recommend a baseline scan documenting the current state, followed by gradual error reduction.

Some tools extend the pure automated scan with guided manual tests that lead the tester through criteria that cannot be automated. Such guided tests combine automated detection with manual confirmation, covering a larger portion of WCAG criteria than a purely automated run – yet do not replace a full expert review.

Automated accessibility tests deliver the greatest value when integrated into the CI/CD pipeline. With every code commit, an automated test engine checks the rendered pages for automatically detectable WCAG violations. Such violations are caught before they reach the production environment. The testing tools fit into build processes and block deployments when critical accessibility errors are found.

The setup effort is usually manageable – often, configuring an automated test engine as a test step in the existing pipeline suffices. Professional setup helps configure the tests correctly so that they deliver meaningful results.

Screen reader tests simulate website usage by blind and visually impaired people. The tester navigates through the page with a screen reader on Windows or macOS and checks whether all content is accessible. Are landmarks correctly recognized? Are headings hierarchically correct? Do all images have alt text? Are forms correctly labeled? Are dynamic contents announced via live regions?

Screen reader testing uncovers problems that neither automated tools nor keyboard tests detect: meaningless alt text that is present but does not describe image content, ARIA attributes that are set but have incorrect values, live regions that do not function, and semantic structures confusing for screen readers.

We recommend testing with at least two different screen readers, as each interprets ARIA attributes and HTML semantics slightly differently. A sensible combination is a screen reader widely used on Windows plus the screen reader built into macOS. For mobile use, additional tests with the screen readers built into iOS and Android are advisable.

Color contrasts are among the most common accessibility problems: low-contrast text was found on 81 percent (WebAIM Million Report, 2024) of the home pages of the top one million websites. Testing is comparatively simple: the WCAG contrast minimum is 4.5:1 for normal text and 3:1 for large text (from 18pt or 14pt bold). Automated contrast testing tools calculate the contrast ratio for any color combination and immediately show whether the requirement is met.

Beyond the pure contrast ratio, specialized tools test readability under different vision conditions: simulations for color blindness (protanopia, deuteranopia, tritanopia), reduced visual acuity and cataracts show how content appears to affected users. These simulations reveal problems invisible in pure contrast measurement – for example, two colors with sufficient contrast that become indistinguishable with red-green deficiency. A professional accessibility audit combines automated contrast testing with visual simulations for a more accurate picture.

Typography testing complements color testing: beyond contrast, font size, line height and character spacing significantly affect readability. WCAG 2.2 requires that users can enlarge text to 200 percent without content being clipped or functionality suffering. Responsive designs working exclusively with viewport units often fail this requirement because font size is tied to screen width rather than user settings.

A professional WCAG audit combines automated and manual testing methods into a comprehensive review. The typical process begins with selecting representative pages: homepage, category page, product detail page, checkout process, contact form, login area and at least one content page. This sample covers the most important page types and interaction patterns.

Each selected page is tested against all relevant WCAG 2.2 AA criteria. Automated scans identify obvious problems. Manual tests check keyboard navigation, the screen reader output and cognitive understandability. Results are summarized in a prioritized action plan: critical problems (block access), serious problems (significant impairment), moderate problems (annoying but workaround exists) and minor problems (improvement potential).

The action plan contains for each problem a description, the affected page and element, the violated WCAG criterion, the priority and a specific solution suggestion. Based on the plan, implementation can proceed systematically and progress can be tracked. A re-audit after implementation validates corrections and identifies any new problems.

Audit documentation is as important as execution: a professional WCAG audit report not only lists found issues but prioritizes them by severity, affected user group and remediation effort. Critical barriers that completely block access (e.g., inoperable forms, missing alternative texts for central content) rank highest. Medium issues impair user experience but do not prevent access. Low priorities are optimization opportunities that improve accessibility but do not violate mandatory requirements. This prioritization enables a phased accessibility implementation with the greatest benefit first.