By Mehdi HassanHow to test website accessibility: the short version
To test website accessibility, combine automated scanning with manual checks. Scan each page template with a free tool, then try to complete the tasks that matter, like signing up or buying, using only a keyboard and then a screen reader. Finish by zooming in and narrowing the window. That routine covers the first checks an accessibility specialist would run.
You don't need special training to start. You need a browser, a free extension, the screen reader already on your computer and a list of the tasks your site exists for. This guide walks through each step. For the legal reasons testing matters, see our hub on website accessibility compliance; for the full list of criteria you're testing against, see the WCAG 2.2 checklist.
Which accessibility testing tools should you use?
The accessibility testing tools worth using are mostly free: one or two automated checkers, the screen reader built into your operating system, and your keyboard. Paid tools add monitoring across many pages and reporting, which helps larger sites, but they don't replace manual testing.
Tool | Type | Cost | Best for |
|---|---|---|---|
axe DevTools (browser extension) | Automated checker | Free tier | Clear issue lists mapped to WCAG |
WAVE (WebAIM) | Automated checker | Free extension | Visual overlay of issues on the page |
Lighthouse (in Chrome) | Automated checker | Free | Quick checks alongside performance |
Accessibility Insights (Microsoft) | Guided manual checks | Free | Step-by-step assessments, tab-stop maps |
VoiceOver | Screen reader | Built into macOS and iOS | Testing on Safari and iPhone |
NVDA | Screen reader | Free on Windows | Testing on Chrome or Firefox for Windows |
TalkBack | Screen reader | Built into Android | Mobile testing on Android |
Your keyboard | Manual testing | Free | Focus, order, traps and operability |
Pick one automated checker and one screen reader to start. Running three scanners mostly gives you the same issues three times. Be wary of tools that promise to 'fix' accessibility automatically; as we explain in do accessibility overlays work?, testing tools help you find problems, but only changes to your code fix them.
How do you run an automated accessibility scan?
Run an automated accessibility scan by opening each template in your browser, starting the extension and working through its issue list from most to least severe. It takes a few minutes per page. The goal is to clear the mechanical issues quickly so your manual testing time goes on harder problems.
- Open the page in its normal state. Close cookie banners only after scanning them too; they're a frequent source of issues.
- Run the scan with axe DevTools, WAVE or Lighthouse's accessibility audit.
- Read each issue's explanation. Good tools link to the WCAG criterion and show the failing element.
- Scan interactive states. Open menus, modals, accordions and form errors, then scan again; hidden content isn't tested until it's visible.
- Note what's repeated. If the same issue appears on every page, it lives in a shared component and one fix solves it.
Treat a clean scan as a minimum, not a pass. Scanners can tell that an image has alt text, not whether the alt text is accurate. They can see a button, not whether a screen reader user understands what it does.
What is the 15-minute manual accessibility check?
The 15-minute manual check is a routine you run on each key flow: a keyboard pass, a screen-reader pass and a zoom pass. It's fast enough to repeat before every launch and finds many of the barriers that stop people completing a task. Time each step roughly as below.
Minutes 0 to 5: keyboard only
Put the mouse aside. Press Tab from the top of the page and work through the flow. Can you see where focus is at all times? Does the order follow the layout? Can you open menus, use dropdowns, submit forms and close modals with Enter, Space, arrow keys and Escape? Can you get out of every component? Does focus hide behind a sticky header?
Minutes 5 to 11: screen reader
Turn on VoiceOver (Command plus F5 on Mac) or NVDA on Windows. Navigate by headings, then by links, then tab through the form. Does each button and field announce a clear name? Are errors and confirmations read out? Do images announce something useful or stay silent if decorative?
Minutes 11 to 13: zoom and reflow
Zoom the browser to 200%, then narrow the window to phone width. Does text get cut off, overlap or force sideways scrolling? Are buttons still reachable?
Minutes 13 to 15: color and motion
Check whether errors, required fields and links rely on color alone. Turn on reduced motion in your operating system and reload: do big animations calm down? Can carousels and auto-playing video be paused?
How do you test a website with a screen reader?
Test with a screen reader by learning a handful of commands and navigating the way regular users do: by headings, landmarks, links and form fields, not by reading top to bottom. Experienced screen reader users skim, so a page with clear headings and labels is fast to use and a page without them is slow and confusing.
- Start the screen reader. VoiceOver: Command plus F5 on Mac, or triple-click the side button on iPhone if set up. NVDA: install it free and press Control plus Alt plus N.
- Jump through headings. VoiceOver uses the rotor (Control plus Option plus U); NVDA uses the H key. Do the headings tell the story of the page?
- List the links. Do they make sense out of context, or do you hear 'learn more' six times?
- Tab through forms. Each field should announce its label, whether it's required and any error.
- Listen for updates. Adding to cart, submitting a form or filtering results should announce what happened.
Which screen reader and browser should you test with?
Each screen reader works best with certain browsers. VoiceOver is best tested in Safari on Mac and iPhone. NVDA is usually tested with Chrome or Firefox on Windows. TalkBack is tested with Chrome on Android.
If you can only test one combination, pick the one your analytics shows most visitors use: often VoiceOver with Safari for consumer and mobile-heavy sites, and NVDA with Chrome for business audiences on Windows. Professional auditors test several combinations, and your own testing can stay smaller.
How do you log and prioritize accessibility issues?
Log each accessibility issue with the page or component, what happened, the WCAG criterion if you know it, how serious it is, and who should fix it. Then prioritize by impact: anything that stops someone completing a task comes first, then anything on every page, then the rest.
Severity | Example | Fix when |
|---|---|---|
Blocker | Checkout button can't be reached by keyboard | Now |
High | Form errors shown only in red, not announced | This sprint |
Medium | Low contrast on secondary text across the site | Next design system update |
Low | Decorative image has redundant alt text | Batch with content updates |
Group issues by shared component before handing them to developers. Fixing the button, form or navigation component once is faster than fixing 40 pages. Add the 15-minute routine to your pre-launch website QA testing so new pages don't reintroduce old problems, and keep an eye on menus in particular; our guide to website navigation best practices covers accessible patterns.
When should you get an expert accessibility audit?
Get an expert audit when you need evidence for someone else, or when your own testing keeps finding problems you don't know how to fix. That usually means an enterprise questionnaire, a public-sector deal, EU consumer customers, a demand letter, or a complex product with custom widgets.
Self-testing first still pays off: you'll fix the easy issues before paying anyone, and the auditor's time goes on the hard parts. Our guide to accessibility audit cost explains how audits are priced. Once the site is in good shape, publish what you've found using our accessibility statement template.
