Accessibility Testing: Methods and Approaches

Automated testing tools analyze the DOM of a web page and test against a rule base. They can detect whether images have alt text, whether form fields have labels, whether color contrasts meet the threshold and whether heading hierarchy is correct. What they cannot test: whether alt text correctly describes image content, whether focus order is logical, whether dynamic content is accessible to screen readers and whether the page is cognitively understandable.

According to research by the W3C/WAI, automated tools find on average 57% (WebAIM, 2025) of accessibility problems present on a page. The remaining problems concern aspects requiring human judgment: Is link text meaningful? Is tab order sensible? Does focus management work for modals? Is dynamic content correctly announced? Only a manual tester can answer these questions.

Automated tests are nonetheless indispensable as a first testing layer and for continuous monitoring. They quickly identify obvious problems: missing alt text, contrast violations, missing labels and ARIA errors. These low-hanging fruits should be fixed before the more intensive manual testing begins. In CI/CD pipelines, automated tests prevent new barriers from entering the code.

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 ensures no new accessibility problems enter 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.

Many browser developer tools and online checkers output accessibility as a score from 0 to 100, often alongside performance, SEO and best practices. This value is based on a weighted evaluation of automatically found problems. A score of 100 does not mean the site is accessible, only that no automatically detectable problems were found.

Such scores often use the same open-source test engines as the specialized tools but supplement with their own checks. Results are less detailed than a dedicated review but offer a quick overview and are particularly useful for developers who want to check accessibility as part of their regular development workflow.

Understanding the limitations is important: an accessibility score of 100 merely means the automatically testable criteria are met. The site may still have severe barriers detectable only manually. We recommend treating the score as a hygiene factor: a low value definitely indicates problems, but a high value does not prove accessibility.

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

According to a WebAIM survey (2025), companies with CI/CD-integrated accessibility testing reduce the number of accessibility regressions by 78 percent (project experience) compared to manual review cycles. The setup effort is manageable -- in most cases, configuring an automated test engine as a test step in the existing pipeline suffices. Professional setup ensures the tests are correctly configured and deliver meaningful results.

The manual keyboard test is the single most important accessibility test. It requires no tools, just the keyboard: navigate through the page with Tab and Shift+Tab, activate elements with Enter and Space, close modals with Escape and navigate within widgets with arrow keys. Systematically check: Is every interactive element reachable? Is the order logical? Is focus always visible? Are there keyboard traps?

The keyboard test covers multiple WCAG criteria simultaneously: 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), 2.4.7 (Focus Visible) and 2.4.11 (Focus Not Obscured). These criteria cannot be automated as they concern the page's behavior during interaction. An experienced tester can complete a full keyboard test of the main page types in one to two hours.

Screen reader tests simulate website usage by blind and visually impaired people. The tester navigates with the screen reader built into Windows or macOS through the page 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. The combination of the Windows screen reader and the macOS screen reader covers the majority of users. For mobile optimization, we supplement with the screen readers built into iOS and Android.

Testing cognitive accessibility is the most difficult area to standardize. WCAG 2.2 contains several criteria addressing cognitive accessibility: 3.3.7 (Redundant Entry), 3.2.6 (Consistent Help), 3.3.8 (Accessible Authentication) and the basic understandability criteria of Guideline 3.1. Testing requires evaluating whether texts are understandably formulated, whether error messages are helpful and whether page structure is predictable.

A structured cognitive walkthrough helps systematically check these criteria: the tester goes through the website's main usage paths and evaluates at each step whether the instruction is clear, whether the user can recognize what action is needed, whether feedback is understandable and timely and whether the user can orient themselves. This method identifies barriers relevant to all users, especially people with cognitive disabilities.

Color contrasts are among the most common accessibility problems: 86 percent (WebAIM Million Analysis, 2025) of the most visited websites violate WCAG contrast requirements. 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 complete 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 (project experience) 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.

User testing with people with disabilities is the most informative form of accessibility testing. No automated tool and no expert test can replace the real user experience. Users with various disabilities use their assistive technologies in individual ways and encounter barriers that testers cannot foresee.

For meaningful user testing, we recommend involving at least five users with different disability types: screen reader users (blind users), users with visual impairments (zoom, high contrast), keyboard users (motor impairments), users with cognitive disabilities and users with hearing impairments. Tests are conducted as moderated usability tests where users complete typical tasks on the website.

Insights from user tests feed directly into the action plan and have the highest priority, as they document real usage barriers. User testing should not be conducted once but repeated regularly, especially after major redesigns or feature updates. Our training programs teach methods for organizing and conducting accessible user testing.

A professional WCAG audit combines all described 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, screen reader compatibility 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.