How to test your website for accessibility (with a screen reader)

Why can’t a tool just test it for me?

Because most of accessibility is a judgment call a machine can’t make. Automated tools catch approximately 30-40% of accessibility issues, and the remaining 60-70% require human evaluation (Contentsquare, 2026). The blunt way practitioners put it: you can ship a site that passes axe with zero violations and still be unusable on a screen reader (TestGuild, 2026).

The gap is structural, not a matter of better tools. A scanner can detect that an image is missing alt text, but not whether alt="photo" actually describes the image; it can confirm elements are focusable, but not whether the tab order is logical or a focus trap exists; it can check that ARIA attributes are present, but not whether they create a coherent experience for a screen-reader user (AccessScore, 2026). This is why WebAIM is direct that a tool cannot tell you whether your content is accessible — only a human can (Upward Engine, 2026). Treat automated scanning as the floor, never the finish line — a point that underpins our pillar on whether web accessibility is the law.

Step one: the automated baseline

Automated scanning still earns its place — it catches the most common, most-sued-over issues quickly and consistently, so it’s where you start. The three free workhorses are axe DevTools, the developer standard whose axe-core engine has been downloaded over three billion times and powers most other tools; WAVE, whose visual overlay marks errors and alerts directly on the page and suits non-developers; and Lighthouse, built into Chrome DevTools with a 0-100 score (Upward Engine, 2026). In a 2026 benchmark, axe identified 78% of detectable violations and WAVE 71% — high within their scope, which is still only part of the whole (Upward Engine, 2026).

Run the scan on your critical templates rather than every page — homepage, contact and login forms, search, navigation — because fixing an issue on a template usually resolves it across every page built from it (Upward Engine, 2026). Work the report in order: findings sort into Errors (definite failures), Warnings (need human judgment) and Notices (informational), and you fix Errors first, prioritising anything that fully blocks a user (WebAbility, 2026). One gap to note: URL-based scanners often miss authenticated pages like dashboards and checkout, so test those with a browser extension while logged in (WebAbility, 2026).

Step two: the keyboard test

The first manual test costs nothing and takes minutes. Unplug your mouse and navigate the entire site with the keyboard alone — Tab and Shift+Tab to move, Enter and Space to activate, arrow keys within components (TestGuild, 2026). If you can’t reach every interactive element this way, the site has accessibility problems, full stop (TestGuild, 2026).

As you go, watch for three failures a scanner rates poorly: a focus indicator that disappears so you can’t tell where you are, a keyboard trap that won’t let you move past a component, and a tab order that jumps around illogically. These are exactly the issues our guide on keyboard accessibility and focus covers in depth — and the keyboard test is where you feel them directly rather than reading about them.

Step three: the zoom test

A quick check that catches a common failure: zoom your browser to 200% and then 400%, and watch what happens to the layout (TestGuild, 2026). Content should reflow and remain readable, without elements stacking on top of each other and without forcing horizontal scrolling to read a line of text (Upward Engine, 2026).

This matters because many users browse zoomed in or on small viewports, and a layout that only works at one size excludes them. It takes a minute and reveals problems that look fine at default zoom, which is why it belongs in every quick pass.

Step four: the screen reader test

This is the most revealing test you can run, and the one that changes how you think about your site. Turn on a screen reader — NVDA, which is free and the most-used screen reader in the world on Windows, or VoiceOver, built into every Mac with Cmd+F5 — and try to use your own site with the screen off (ADAWebPro, 2026). Can you tell what’s on the page, fill out the forms, and complete a purchase or contact the business using only what you hear? Even 30 minutes reveals issues that automated tools completely miss (12 Best, via Contentsquare, 2026).

A few NVDA settings make this bearable: slow the speech rate to 40-50%, enable the Speech Viewer to see a live transcript of what’s announced, disable your mouse so you navigate as a screen-reader user does, and press NVDA+F7 to open a list of the page’s headings, links and landmarks (Upward Engine, 2026). Listen for whether the headings form a sensible outline, whether every form field is announced with its label, whether the reading order matches the visual order, and whether interactive widgets announce their state — the checks that connect directly to our guides on alt text and when to use ARIA.

What only a human can catch

It’s worth naming exactly what the manual layers find, because it’s the difference between a technically-clean site and a usable one. A human tester judges whether alt text is genuinely descriptive rather than merely present, whether the reading order makes sense, and whether complex interactions actually work with a screen reader (ADAWebPro, 2026). Machines detect absence; humans detect meaning.

The list of judgment-only issues is long and important: whether a link labelled “More” makes sense out of context, whether captions are accurate and synchronised rather than just present, and whether the page’s cognitive load — plain language, clear instructions, consistent layout — is manageable (AccessScore, 2026). None of these can be measured by code, and all of them decide whether a real person can use your site. This is the same reason our guide on accessibility overlays concludes that no automated widget can deliver accessibility — the hard 60-70% is precisely what automation can’t reach.

Test on a schedule, not once

Accessibility isn’t a state you reach and keep — it’s a property that decays. New pages, updated content, new features and design changes can all reintroduce barriers, so a site tested clean at launch can fail within a month of normal edits (Inclusive Web, 2026). Testing only at launch is one of the most common mistakes, precisely because it treats a moving target as a fixed one.

The fix is rhythm. Run a quick automated scan plus a keyboard and screen reader spot-check after every significant update, and schedule a fuller manual review periodically (WebAbility, 2026). Developers can automate the first layer by adding a command-line tool like Pa11y to a continuous-integration pipeline, catching common regressions before they reach production (Contentsquare, 2026). The goal is to catch drift early, when it’s a one-line fix rather than a backlog.

The mistakes that make testing theatre

Three habits turn testing into a box-ticking exercise that proves nothing. The first is trusting automation completely — a clean scan feels like done, but it only ever covered 30-40% of the criteria (Inclusive Web, 2026). The second is testing only once. The third is trying to fix everything at once instead of prioritising the critical errors that fully block users over minor warnings (Inclusive Web, 2026).

A fourth belongs here too, quietly: no overlay or “accessibility widget” can substitute for this process, because the barriers that matter most are the ones only a human tester finds. Automated remediation makes a compliance claim it can’t keep, which is why both US and EU regulators reject it — the ground covered by our guides on overlays and the European Accessibility Act. Real testing is a person using the site the way an excluded user would.

Why our sites mostly confirm, not surprise

Here’s how the way a site is built changes the experience of testing it. Because we write native, semantic HTML — real buttons, real headings, labelled form controls, keyboard operability by default and almost no ARIA — the automated baseline tends to come back clean, since most common violations simply never get introduced. The keyboard test passes because native elements are focusable and operable for free. And the screen reader announces a coherent heading outline because the headings are real structural elements, not styled text.

The result is that testing our sites usually confirms what the build already did, rather than surfacing a backlog to repair. That’s the practical difference between accessibility built in and accessibility bolted on — and testing is exactly how you tell which one you have. A site that needs a long remediation list after its first screen reader pass was built without this care; a site that mostly passes was built with it. Verifying that is the last step in the discipline our WCAG 2.2 checklist lays out — build it right, then prove it works.