Accessibility Testing Tools

Web accessibility is no longer an afterthought. With the EU Accessibility Act taking full effect in June 2025, ongoing enforcement of Section 508 in the US, and WCAG 2.2 becoming the de facto standard for compliance audits, organizations that fail to invest in accessibility testing face mounting legal and reputational risk. An estimated 1.3 billion people worldwide live with some form of disability, representing a market with over $13 trillion in annual disposable income. Building accessible products is both a legal obligation and a business opportunity.

This guide covers the full spectrum of accessibility testing tools and methodologies available in 2026. You will learn about industry-standard automated scanners, manual testing techniques, the new WCAG 2.2 success criteria that introduced real teeth to audits, and how to integrate accessibility checks into your development pipeline so issues are caught before they reach production. Whether you are a developer, QA engineer, designer, or product manager, the tools and workflows described here will help you ship more inclusive software.

Why Accessibility Matters in 2026

The legal landscape around digital accessibility has shifted dramatically. The EU Accessibility Act (Directive 2019/882), which became enforceable in June 2025, mandates that products and services including websites, mobile apps, e-books, and banking services meet specific accessibility requirements. Non-compliance can result in fines, injunctions, and reputational damage. In the United States, the Department of Justice has made clear that websites fall under Title III of the ADA, and WCAG 2.1 Level AA is the standard referenced in virtually every demand letter. The Section 508 Refresh already requires federal agencies and their contractors to conform to WCAG 2.0 Level AA, and most now target WCAG 2.2.

Beyond compliance, accessibility drives better engineering. Semantic HTML, proper heading hierarchies, well-labeled form controls, and clear focus indicators benefit every user. Accessibility improvements often correlate with better SEO, faster page loads, and lower bounce rates. The Web Content Accessibility Guidelines have evolved to reflect real-world user behavior. WCAG 2.2 introduced criteria around focus visibility, dragging movements, and accessible authentication that close longstanding gaps. Organizations that embed accessibility testing into their CI/CD pipelines ship fewer regressions, spend less on remediation, and earn trust from a user base that includes one in six people globally.

Automated Accessibility Testing Tools

Automated tools are the first line of defense in any accessibility testing strategy. They scan pages against hundreds of rule checks and surface violations in seconds. While they typically catch only about 30 percent of all accessibility issues, they excel at finding the low-hanging fruit — missing alt text, insufficient color contrast, incorrect ARIA roles, broken heading structure, and missing form labels. Here are the most widely used automated tools in 2026.

axe DevTools (by Deque Systems) is widely regarded as the gold standard for automated accessibility testing. It offers a free browser extension for Chrome, Firefox, and Edge that runs against WCAG 2.1 and 2.2 rules. The paid tiers add full-page analysis, CI integration via axe-core (runs in Node.js, Selenium, Puppeteer, and Cypress), and the ability to define custom rules. Axe intentionally avoids false positives — its rule engine is conservative, so when it flags an issue, you can be confident it is real. Axe-core integrates with nearly every testing framework and is used by Google, Microsoft, and the US federal government. The browser extension provides a clean side panel with issue summaries, fix suggestions, and the ability to highlight elements on the page. For teams, the axe Monitor dashboard tracks violations across entire sprint cycles.

WAVE (Web Accessibility Evaluation Tool, by WebAIM) is a free tool that provides a visual overlay of accessibility issues directly in the browser. The WAVE browser extension and the standalone web-based tool inject icons and color-coded markers onto the page, showing errors (red), alerts (yellow), ARIA features (green), and contrast issues (blue). WAVE is excellent for educational purposes because it teaches you what each violation looks like and where it occurs on the page. It does not flag false positives aggressively, which makes it a great second opinion alongside axe. The WAVE API allows programmatic scanning for enterprise environments, though it is less commonly used in CI pipelines than axe-core.

Lighthouse is built directly into Chrome DevTools and is also available as a Node.js CLI module and a GitHub Action. The accessibility audit runs alongside performance, SEO, and best-practice audits, producing a score from 0 to 100. Every failed audit links directly to the relevant WCAG criterion and provides guidance on remediation. Lighthouse is ideal for quick sanity checks during development — you can run it from the command line as part of a pre-commit hook or a CI build. However, Lighthouse uses a subset of the axe-core rule set, so it should not be your sole accessibility checker. It is a fast, convenient starting point, not a replacement for a dedicated tool like axe-core.

Accessibility Insights (by Microsoft) is a free, open-source tool for Windows and macOS that offers three testing modes: FastPass (a two-minute scan that checks the most common issues), Assessment (a guided, step-by-step walkthrough that combines automated and manual checks), and Ad hoc (on-demand inspection of individual elements). The Assessment mode is particularly valuable because it explicitly lists manual checks you need to perform and lets you record pass/fail results for each. Accessibility Insights also includes a Color Analyzer and a tab-stop visualizer for keyboard testing. It integrates with axe-core under the hood and exports results as HTML reports that can be shared with stakeholders.

Pa11y is an open-source command-line tool designed for CI/CD integration. Pa11y runs axe-core rules against a list of URLs and outputs JSON, CSV, or HTML reports. Pa11y CI can compare a baseline against a new build and fail the pipeline if the number of errors increases. Pa11y Dashboard provides a web interface for tracking trends over time. Because Pa11y is entirely scriptable, it fits naturally into GitHub Actions, GitLab CI, Jenkins, and CircleCI workflows. Teams that need enforcement at the pull-request level often pair Pa11y with axe-core for maximum coverage.

Manual Testing Methods and Screen Readers

Automated tools catch only about 30 percent of accessibility issues. The remaining 70 percent — including focus order confusion, confusing screen reader announcements, missing context, and illogical reading order — require human judgment. Manual testing with a screen reader is the most effective way to evaluate whether a screen reader user can actually complete a task on your site.

NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows and the most popular choice for testing. It supports all major browsers and includes a speech viewer that lets developers see exactly what text is being read aloud without needing speakers. NVDA is the standard recommendation for development teams because it is free, actively maintained, and widely used by the blind community. Testing with NVDA involves navigating your application using the Tab key, arrow keys, and screen reader shortcuts (insert + arrow keys for browse mode) to verify that all content is reachable and understandable.

VoiceOver is built into macOS and iOS at no extra cost. On macOS, you enable it from System Preferences > Accessibility > VoiceOver and use the VO key (control + option) combined with arrow keys, the Tab key, and the rotor (VO + U) to navigate. VoiceOver behaves slightly differently from NVDA — it has its own navigation model, and ARIA support varies between the two. Testing with both NVDA and VoiceOver is recommended because a pattern that works in one may break in the other. iOS VoiceOver testing is essential if you ship a mobile app or a responsive web app.

JAWS (Job Access With Speech) is the paid market leader for Windows, priced around $1,095 per license, and is the screen reader most commonly used in enterprise and government settings. JAWS has been the standard for decades and is required under many government contracts. For most web development teams, NVDA and VoiceOver provide sufficient coverage, but if your audience includes a high proportion of government or corporate users, investing in JAWS testing is worthwhile.

Screen reader testing workflow: Start by navigating the page with the Tab key alone. Are all interactive elements reachable? Can you see a visible focus indicator on every link, button, and input? Next, activate the screen reader and use browse mode (NVDA: insert + down arrow or NVDA + F7 for elements list) to review the page structure. Does the heading hierarchy make sense? Are images with meaningful content described appropriately? Are decorative images correctly hidden with alt="" or role="presentation"? Finally, attempt a critical user flow — such as a checkout or form submission — using only the keyboard and screen reader. If you get stuck, users will too.

Comparison Table: Accessibility Testing Tools

What Automated Tests Catch (and What They Miss)

Understanding the limitations of automated tools is essential to building a realistic testing strategy. Automated scanners operate by checking the DOM and computed styles against a set of rule conditions. They are excellent at detecting:

• Missing or improper alt attributes on images
• Empty links and buttons (no text content)
• Missing form labels or improper label associations
• Low color contrast ratios (foreground vs. background)
• Incorrect ARIA role usage and missing ARIA attributes
• Duplicate IDs that break label and describedby associations
• Missing document language (lang attribute on )
• Broken heading hierarchy (skipping levels, empty headings)
• Missing th scope attributes on data tables

However, automated tools cannot evaluate:

• Whether focus order is logical after dynamic content changes
• Whether screen reader announcements make sense in context
• Whether a link's purpose is clear from its text alone
• Whether custom widgets behave correctly for keyboard and screen reader users
• Whether a video has accurate captions or an audio description
• Whether a reading order is logical when CSS changes visual positioning
• Whether a form error message is actually helpful

The widely cited 30/70 rule — automated tools find roughly 30 percent of issues, manual testing finds the remaining 70 percent — holds up across numerous studies, including a 2023 WebAIM analysis of one million home pages. Do not fall into the trap of relying solely on a high Lighthouse score. A perfect automated score does not mean the site is usable for people with disabilities. It only means the DOM passes the checks the tool knows about.

WCAG 2.2: New Criteria You Cannot Ignore

WCAG 2.2 added nine new success criteria on top of WCAG 2.1, all at Level A or Level AA. These criteria target real-world accessibility gaps that automated tools struggled to address. Every accessibility testing strategy in 2026 must account for them.

2.4.11 Focus Not Obscured (Level AA): When a keyboard focus indicator is visible, it must not be entirely hidden behind another element. A sticky header, a chatbot widget, or a floating sidebar that covers the focused element violates this criterion. Testing involves tabbing through every interactive element while a fixed or sticky element is present and confirming the focus ring remains visible. Accessibility Insights' tab-stop visualizer and manual keyboard testing are the primary ways to check this.

2.4.12 Focus Not Obscured — Minimum (Level AA): A stricter sibling of 2.4.11, this requires that no part of the focus indicator is obscured. The previous criterion allowed partial obscuring; the new minimum demands the entire indicator be visible. This affects popovers, modals, and any layered UI pattern where a focused element could be partially hidden by another element. Testing requires inspecting each focus stop for visual obstruction in the browser.

2.5.7 Dragging Movements (Level AA): Any functionality that relies on dragging (drag-and-drop, sliders, map panning, reorderable lists) must have a single-pointer alternative that does not require dragging. A button to reorder items, arrow keys to adjust a slider, or click-to-move alternatives satisfy this criterion. Most automated tools cannot validate this — it requires manual interaction testing with a mouse, keyboard, and touch device.

2.5.8 Target Size Minimum (Level AA): Clickable targets must be at least 24 by 24 CSS pixels, with exceptions for inline links, targets in a sentence block, and targets that have an equivalent larger nearby. This reduces accidental clicks for users with motor impairments and on mobile devices. The Stark plugin can validate this at design time; in code, automated checks combined with manual inspection are needed.

3.3.7 Accessible Authentication (Level AA): Authentication processes cannot rely on cognitive function tests such as identifying objects, recalling a password from memory, or solving a puzzle. Copy-and-paste from a password manager, biometric authentication, OAuth single sign-on, and device-based confirmation are all compliant. Note that this criterion explicitly excludes the act of typing a password from memory (a cognitive function test is something like a CAPTCHA that asks users to identify traffic lights or store fronts). Testing requires reviewing your login, registration, and password-reset flows.

3.3.8 Accessible Authentication (No Exception) (Level AAA): The stricter AAA version removes all exceptions. Even the typing of a password from memory is considered a barrier at this level if there is no alternative. For AAA compliance, every authentication step must offer a method that does not rely on cognitive recall, transcription, or object identification.

Integrating Accessibility Into Your Development Workflow

Effective accessibility testing is not a one-time audit — it is an ongoing practice embedded into every stage of development. The earlier an issue is caught, the cheaper it is to fix. A missing alt text caught at code review costs seconds to correct. The same issue caught post-launch may require a ticket, a sprint cycle, and a regression test.

Linting: The eslint-plugin-jsx-a11y plugin for ESLint catches accessibility violations during development in React, Preact, and other JSX-based frameworks. It enforces rules such as required alt attributes on , proper htmlFor / id associations on labels, and accessible click handlers (no