How to Test Web Accessibility: Automated Tools, Manual Testing, and Screen Readers

<p>The numbers are hard to ignore. According to the 2026 WebAIM Million report, automated scans across one million homepages detected over 56 million distinct accessibility errors — an average of 56.1 errors per page, up more than 10% from the previous year. And because automated tools can only catch roughly 30–40% of potential WCAG violations, the true scale of the problem is significantly larger. If your accessibility testing strategy begins and ends with a single browser extension scan, you are seeing only a fraction of the barriers your users face every day.</p> <h2>Why a Multi-Layer Testing Strategy Is Non-Negotiable</h2> <p>Web accessibility testing is not a single event — it is a discipline that spans tools, human judgment, and lived experience. The Web Content Accessibility Guidelines (WCAG) are built on four foundational principles, commonly called POUR: content must be <strong>Perceivable</strong>, <strong>Operable</strong>, <strong>Understandable</strong>, and <strong>Robust</strong>. Automated tools can verify that an image <em>has</em> an alt attribute, but they cannot judge whether that alt text actually describes the image meaningfully. A script can confirm that a button has a label, but it cannot tell you whether a screen reader user would understand what pressing it does in context.</p> <p>This is why every serious accessibility program layers three distinct approaches: automated scanning to catch systemic, repeatable violations at scale; manual testing to evaluate judgment-dependent criteria that require a human brain; and assistive technology testing — particularly screen readers — to validate the real-world experience of users who depend on these tools daily. Each layer compensates for the blind spots of the others. Skipping any one of them leaves gaps that will eventually surface as user complaints, audit failures, or legal exposure.</p> <p>WCAG 2.2, the current W3C standard as of late 2023, places greater emphasis on usability for keyboard navigation, touch interactions, and cognitive accessibility, while retaining all existing WCAG 2.1 requirements. Testing against it is not optional for most organizations — it is increasingly mandated by regulation, from the ADA in the United States to the European Accessibility Act, which entered enforcement in June 2025. Understanding <em>how</em> to test is the practical foundation that makes compliance achievable.</p> <h2>Automated Testing: Your First Line of Defense</h2> <p>Automated tools accelerate the testing process and integrate seamlessly into CI/CD pipelines, helping teams catch and correct accessibility errors early and often. They are best understood as a filter — they will not catch everything, but they will catch the most common, most measurable violations reliably and at a speed no human reviewer can match. Think of them as a spell-checker: essential, but not a substitute for a skilled editor.</p> <p>The most common categories of issues automated tools reliably detect include missing or empty alt text on images, insufficient color contrast ratios, form fields without associated labels, empty link or button text, missing page language declarations, and duplicate or missing heading structures. According to the WebAIM Million data, 96.4% of detected errors fall into just six categories — meaning automated tools, applied consistently, can make a substantial dent in your violation count before any human reviewer touches the interface.</p> <h3>Key Automated Testing Tools</h3> <p><strong>axe-core / axe DevTools</strong> (Deque Systems) is arguably the most widely adopted accessibility testing engine in the industry. Its open-source core is embedded in dozens of other tools and testing frameworks. The browser extension works in Chrome, Firefox, and Edge, giving developers instant feedback on the rendered DOM. For engineering teams, axe-core integrates with Cypress, Playwright, Selenium, and Jest, making it straightforward to embed accessibility checks directly into your existing test suite.</p> <p><strong>WAVE</strong> (WebAIM) is a browser extension and online evaluation tool that provides visual, in-page feedback using color-coded icons overlaid directly on your content. It is particularly well-suited for content editors and non-technical stakeholders who need to understand accessibility issues without reading code. WAVE highlights errors, alerts, structural elements, and ARIA roles in a way that makes the relationship between markup and user experience immediately visible.</p> <p><strong>Google Lighthouse</strong> is built directly into Chrome DevTools and runs accessibility audits alongside performance, SEO, and best-practice checks. It is excellent for quick front-end audits during development and can be run via the command line for CI integration. Its accessibility score is powered by axe-core under the hood, so it covers overlapping but not identical ground.</p> <p><strong>Pa11y</strong> is a command-line tool and Node.js library designed for pipeline integration. It supports both axe and the HTML_CodeSniffer engine, can test multiple URLs from a configuration file, and outputs machine-readable reports suitable for dashboards or ticketing systems. It is particularly useful for monitoring large sites or for organizations that need to audit URLs in bulk on a scheduled basis.</p> <h3>Integrating axe into Your CI/CD Pipeline</h3> <p>The most effective way to prevent accessibility regressions is to treat them like any other bug — catch them before they reach production. Integrating axe-core into your CI pipeline means every pull request is automatically scanned, and builds can be configured to fail when violations exceed acceptable thresholds. Here is a minimal example using Playwright and the <code>@axe-core/playwright</code> package:</p> <pre><code>import { test, expect } from '@playwright/test'; import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => { test('should have no automatically detectable WCAG violations', async ({ page }) => { await page.goto('https://your-site.com/'); const results = await new AxeBuilder({ page }) .withTags(['wcag2a', 'wcag2aa', 'wcag21aa']) .analyze(); expect(results.violations).toEqual([]); }); });</code></pre>

<p>This test navigates to your application, runs axe-core against the rendered page scoped to WCAG 2.x Level A and AA rules, and fails if any violations are returned. You can wire this into a GitHub Actions workflow so it runs on every push to <code>main</code> or on every pull request. Keep in mind that when you first add automated accessibility tests to a mature project, you may discover dozens of pre-existing issues. Rather than blocking all deployments immediately, configure a baseline violation count and tighten the threshold incrementally as you remediate.</p> <blockquote><strong>Important limitation:</strong> Automated tools catch approximately 30–40% of WCAG violations. They are necessary but not sufficient. Manual testing is imperative for uncovering the full scope of accessibility barriers.</blockquote> <h2>Manual Testing: What Machines Cannot Judge</h2> <p>Manual testing fills the gaps that automated tools structurally cannot. It requires a tester — ideally someone trained in WCAG and familiar with assistive technologies — to work through pages and interactions using a defined methodology. The goal is not to re-verify what the automated scanner already found, but to evaluate the criteria that require human judgment: Is the reading order logical? Does focus management make sense after a modal opens? Is the error message genuinely helpful, or does it just say "invalid input"?</p> <p>A practical manual testing session covers several distinct areas. The first is <strong>keyboard-only navigation</strong>. Disconnect your mouse and navigate your entire interface using only Tab, Shift+Tab, Enter, Space, and arrow keys. Every interactive element — links, buttons, form fields, dropdown menus, date pickers, modals, tabs — must be reachable and operable without a mouse. Focus must never become trapped (unless intentionally, as in a modal that should hold focus). The visible focus indicator must be clear enough to follow. WCAG 2.2 added Success Criterion 2.4.11 Focus Appearance, which sets a minimum size and contrast requirement for focus indicators — this is almost always a manual check.</p> <p>The second area is <strong>content and structure review</strong>. Read through the page with a critical eye toward heading hierarchy. Headings should convey the page's outline — <code>&lt;h1&gt;</code> for the page title, <code>&lt;h2&gt;</code> for major sections, <code>&lt;h3&gt;</code> for subsections — without skipping levels. Verify that link text is descriptive in isolation ("Download the 2025 Annual Report" is good; "click here" is not). Check that images with meaningful content have accurate alt text, and that decorative images have empty alt attributes (<code>alt=''</code>). Review form labels: every input should have a programmatically associated label, not just a placeholder.</p> <p>The third area is <strong>dynamic interactions and ARIA</strong>. JavaScript-heavy interfaces — single-page applications, modals, live search results, carousels, accordions — create accessibility challenges that static scanners regularly miss. When a modal opens, does focus move into it? When it closes, does focus return to the triggering element? When a live region updates (a search results count, a form validation message), is it announced to assistive technologies? Misused ARIA is one of the most common sources of accessibility regressions. The WebAIM Million data consistently shows that pages using ARIA attributes average significantly more errors than those without — not because ARIA is bad, but because it is frequently implemented incorrectly.</p> <h3>A Practical Manual Testing Checklist</h3> <ul> <li><strong>Keyboard navigation:</strong> Tab through every interactive element; confirm logical order, no focus traps, and visible focus indicators that meet WCAG 2.2 SC 2.4.11.</li> <li><strong>Heading structure:</strong> Verify a logical, non-skipping hierarchy using a browser extension like HeadingsMap or the WAVE toolbar.</li> <li><strong>Link and button text:</strong> Confirm all interactive elements have descriptive, unique accessible names — not "click here" or "learn more" repeated dozens of times.</li> <li><strong>Form accessibility:</strong> Check that every field has an explicit label, error messages are specific and programmatically associated, and required fields are indicated in a way assistive technologies can convey.</li> <li><strong>Color and contrast:</strong> Manually check any text or UI components that automated tools flagged as uncertain. Low contrast text was found on 83.9% of homepages in the 2026 WebAIM Million report — it is the single most common accessibility failure.</li> <li><strong>Touch target size:</strong> WCAG 2.2 SC 2.5.8 requires interactive targets to be at least 24×24 CSS pixels (with recommended best practice at 44×44 pixels). Inspect small buttons, icon-only links, and mobile navigation elements.</li> <li><strong>Zoom and reflow:</strong> Test at 200% and 400% browser zoom. Content should reflow without horizontal scrolling at 400% (WCAG SC 1.4.10).</li> </ul> <h2>Screen Reader Testing: The Closest Proxy to Real User Experience</h2> <p>Screen reader testing is the most demanding part of an accessibility program, and also the most revealing. A screen reader user experiences a web page as a linear stream of text and semantic information — the visual layout is irrelevant. Headings, landmarks, lists, tables, form labels, and ARIA roles are the navigational skeleton. If that skeleton is broken or missing, the page becomes unusable regardless of how well it passes automated checks.</p> <p>According to the WebAIM Screen Reader User Survey conducted in late 2023 and early 2024, JAWS remains the most commonly cited primary desktop screen reader at 40.5% of respondents, with NVDA close behind at 37.7%. VoiceOver holds 9.7% of the primary desktop market but is by far the dominant screen reader on mobile devices, with 70.6% of mobile screen reader users relying on it. This means a comprehensive testing program should cover at minimum: NVDA with Chrome on Windows, JAWS with Chrome on Windows, and VoiceOver with Safari on iOS.</p> <h3>The Major Screen Readers at a Glance</h3> <p><strong>JAWS</strong> (Job Access With Speech), developed by Freedom Scientific, has been the gold standard in enterprise environments for decades. It offers deep integration with Microsoft Office, advanced scripting for non-standard applications, and AI-powered image description. JAWS requires a paid license (approximately $1,000 for a standard license, or $95/year for a home subscription), which makes it less accessible for casual testing but essential for validating that enterprise-grade workflows work for professional screen reader users.</p> <p><strong>NVDA</strong> (NonVisual Desktop Access) is free, open-source, and trusted by millions. Its feature set has grown to match JAWS for the vast majority of everyday web tasks, and its portability — it can run from a USB drive on any Windows machine — makes it the practical choice for most development teams beginning screen reader testing. NVDA with Chrome is the second most common screen reader and browser combination in real-world use.</p> <p><strong>VoiceOver</strong> is built into every macOS and iOS device, requiring no installation. On desktop, it pairs best with Safari. On iPhone and iPad, it is the dominant screen reader by a wide margin. If your site has significant mobile traffic — and most do — VoiceOver on iOS is a mandatory part of your test matrix. Its gesture-based navigation model on touchscreens is meaningfully different from keyboard navigation on desktop, which means mobile-specific accessibility issues can only be found by testing on a real iOS device.</p> <p><strong>TalkBack</strong> is Google's screen reader for Android and is used by roughly 35% of mobile screen reader users. If your audience includes Android users, TalkBack testing should be part of your mobile accessibility program.</p> <h3>How to Conduct an Effective Screen Reader Test</h3> <p>Start by turning off your monitor or closing your eyes. The goal is to simulate the experience of someone who cannot see the screen. Navigate the page using screen reader commands alone. For NVDA and JAWS, the most important navigation patterns to exercise are: reading through the page linearly with the arrow keys or read-all command; jumping between headings using H; navigating by landmarks using D (NVDA) or ; (JAWS) to jump between main, navigation, and footer regions; tabbing through interactive elements only; and using the forms mode to interact with input fields.</p> <p>As you navigate, ask yourself: Is the reading order logical? Does the page title make sense when announced? Are images described meaningfully, or does the screen reader announce "image" with no context? Do form fields announce their label, type, and current value? When you submit a form with errors, are the error messages announced and easy to locate? When dynamic content updates — a notification banner, a loading state, a search results count — is the update announced without requiring the user to navigate back to find it?</p> <blockquote>Screen readers allow users to interact in different modes — reading mode, forms mode, and application mode — and can produce very different results in each. An element that works correctly in one mode may fail silently in another. Always test the same interaction in multiple navigation modes.</blockquote> <p>One of the most common and most damaging failures in modern web applications is broken focus management. When a modal dialog opens, focus must move into it; when it closes, focus must return to the element that triggered it. When a single-page application transitions to a new view, the page title and main heading must be announced. When an error occurs during form submission, focus should move to the error summary or the first invalid field. These patterns cannot be validated by any automated tool — they require a tester with a screen reader open.</p> <h2>Building an Accessibility Testing Program That Lasts</h2> <p>The most common mistake organizations make is treating accessibility testing as a one-time audit. A site that passes today will develop new violations tomorrow as content is published, features are shipped, and third-party scripts are updated. Accessibility needs to be embedded in the development lifecycle as a continuous practice, not a periodic checkbox.</p> <p>A sustainable program has three layers running in parallel. The automated layer runs on every code commit, catching regressions before they reach production. The manual layer runs on a sprint-by-sprint basis as new features are developed — not as a gate at the end, but as a check during development. The assistive technology layer runs as part of acceptance testing for any feature that involves significant interaction patterns: forms, navigation changes, modals, dynamic content, and user flows. For most teams, that means at least NVDA with Chrome and VoiceOver on iOS.</p> <p>Prioritization matters. If your audit surfaces fifty issues, not all of them carry equal weight. WCAG violations are categorized by impact — critical issues that make content completely inaccessible to some users should be fixed before serious issues, which in turn take precedence over moderate and minor ones. Focus first on the patterns that affect entire page types: if your navigation is broken for keyboard users, fix the navigation template and you fix it everywhere at once. If your form error handling is inaccessible, fixing the pattern fixes every form.</p> <p>Documentation is not optional for compliance managers. Maintain an accessibility testing log that records which pages were tested, which tools and assistive technologies were used, which violations were found, and what remediation was applied and when. This documentation becomes invaluable during accessibility audits or legal proceedings, demonstrating an ongoing good-faith effort to achieve and maintain conformance.</p> <h2>The Role of Overlay Widgets in Your Testing Strategy</h2> <p>Accessibility overlay widgets, like the Accsible SDK, play a meaningful role in a layered accessibility strategy — particularly for organizations that need to provide immediate improvements to existing content while deeper remediation work is underway. A well-implemented overlay can surface assistive tools for users, such as text resizing, contrast adjustment, and keyboard navigation enhancements, that address common barriers without requiring a full site rebuild.</p> <p>However, overlays are not a substitute for testing. They complement a testing program rather than replace it. The most effective approach is to use an overlay to address the surface-level, presentation-layer issues that can be handled programmatically, while using automated scanning, manual testing, and screen reader validation to identify and remediate the structural issues — broken semantics, missing ARIA roles, inaccessible custom widgets — that require code-level fixes. Overlays work best when the underlying codebase has been tested and the remaining gaps are in user-preference territory rather than fundamental interaction barriers.</p> <p>When evaluating any accessibility tool, overlay or otherwise, ask whether it has been tested with real screen readers. A widget that creates a visible accessibility toolbar but introduces focus traps or ARIA conflicts into the page has made things worse, not better. The testing methodologies in this guide apply to accessibility tooling itself, not just to the sites it runs on.</p> <h2>Key Takeaways</h2> <ul> <li><strong>No single tool is enough.</strong> Automated scanners catch only 30–40% of WCAG violations. A complete program requires automated testing, manual review, and real assistive technology testing working together as complementary layers.</li> <li><strong>Shift accessibility left.</strong> Integrating axe-core or Pa11y into your CI/CD pipeline means violations are caught before they reach production, where fixing them costs exponentially more in time, reputation, and legal risk.</li> <li><strong>Test with the screen readers your users actually use.</strong> NVDA with Chrome and JAWS with Chrome dominate desktop usage; VoiceOver on iOS dominates mobile. Cover these combinations at minimum, and test dynamic interactions — modals, form errors, SPA route changes — which automated tools will never catch.</li> <li><strong>Fix patterns, not just instances.</strong> If your heading structure is broken, fix the template. If your form error handling is inaccessible, fix the component. Systematic fixes deliver exponentially more value than one-off patches.</li> <li><strong>Make accessibility testing continuous, not periodic.</strong> A site that passes an audit today will drift. Embed testing into your development lifecycle — automated on every commit, manual on every sprint, assistive technology testing on every significant feature — and accessibility becomes a maintained property of your product rather than a remediation project.</li> </ul>