How to Test a Website for Accessibility Issues: 9 Free Tools and Manual Checks

Automated scanners are the fastest way to start, but they catch roughly a third of real accessibility problems. The rest, the ones that actually block people from using a site, only show up when a human puts the mouse away and starts pressing Tab. This guide walks through how to test website accessibility the way agencies and freelance designers do it in practice: run the scanners first, then run the manual checks that expose what the scanners cannot see, then package everything into a report a client can act on.

The Short Answer: A 4-Layer Testing Workflow

Testing a site properly is not about picking one tool. It is about stacking four layers, each catching what the previous one missed.

Automated scan (2 to 5 minutes per page): axe DevTools, WAVE or Lighthouse for code-level issues such as missing alt text, low contrast, unlabeled form fields.
Guided semi-automated review (15 to 30 minutes): Accessibility Insights or ANDI to walk through tab stops, headings and landmarks with visual overlays.
Manual human checks (30 to 60 minutes): keyboard-only navigation, focus order, zoom and reflow, error handling, alt text quality.
Assistive technology testing (30 minutes and up): NVDA, VoiceOver or TalkBack to hear what is actually announced.

Skip layers 3 and 4 and you will hand a client a green score on a site that a keyboard user cannot check out of.

Before You Test: Pick Your Standard and Your Sample

Choose the standard

Almost every audit today is measured against WCAG 2.2 Level AA. That is the version referenced by the European Accessibility Act (enforceable across the EU since June 2025 through EN 301 549) and the practical target for private sector work in North America. US state and local government sites are held to WCAG 2.1 AA under the DOJ’s ADA Title II rule, with the deadline for smaller public entities landing in April 2027. If your client is a public body, confirm which version their regulator names before you write a single finding.

Choose the pages

Nobody tests 400 pages by hand. Build a representative sample of 8 to 15 pages that covers every distinct template and interaction:

Home page
Main navigation landing page and a deep content page
A form: contact, signup, or checkout (test every step)
Search results and an empty results state
Any page with a data table, carousel, modal, accordion or map
Login, error pages (404), and the cookie or consent banner
Mobile viewport versions of the above

Also test the states, not just the pages: menu open, modal open, form submitted with errors, video playing.

The 9 Free Tools, What They Catch, What They Miss

1. axe DevTools (Browser Extension)

What it is: A free Chrome, Edge and Firefox extension from Deque that sits inside DevTools and scans the rendered DOM.

What it detects: Missing form labels, empty links and buttons, contrast failures, invalid ARIA attributes, duplicate IDs, missing document language, heading level skips, images without alt attributes. It is the strictest of the popular scanners on ARIA misuse.

What it misses: Whether alt text is accurate, whether focus order matches visual order, whether a custom widget behaves correctly with a keyboard, whether an error message is announced. It reports zero violations on plenty of unusable pages.

How to read the results: axe splits findings into critical, serious, moderate and minor, and it deliberately reports very few false positives. Treat every “critical” and “serious” item as a genuine defect. The free version also surfaces “needs review” items: those are prompts for you, not bugs, and each one requires a manual decision.

Best for: Single Page Applications and dynamic states, because you can scan after opening a modal or expanding a menu.

2. WAVE by WebAIM

What it is: A browser extension and online checker that overlays icons directly onto the page.

What it detects: Errors (missing alt, empty buttons, missing labels), alerts (skipped headings, redundant links, very long alt text), contrast failures, plus a structural view of headings and ARIA landmarks.

What it misses: Keyboard operability, focus visibility, dynamic content updates, anything behind a login unless you use the extension.

How to read the results: WAVE’s genius is visual. Switch to the Structure tab to see the heading outline and confirm it reads like a table of contents, and use the Order tab to compare DOM order with visual order. The “Alerts” column is not a failure list, it is a review list. Clients often panic at 40 alerts, so explain the difference in your report.

Best for: Showing non-technical stakeholders where the problems physically are on the page.

3. Lighthouse (Chrome DevTools)

What it is: Built into Chrome. Open DevTools, choose the Lighthouse panel, tick Accessibility, and run it. It uses a subset of axe rules under the hood.

What it detects: A curated set of roughly 40 to 50 checks: contrast, labels, alt text, ARIA validity, viewport zoom blocking, tabindex above zero.

What it misses: A lot. And its scoring is the biggest trap in the whole field.

How to read the results: The Lighthouse accessibility score is not a compliance percentage. A score of 100 means “no automatically detectable issues in this limited rule set were found”, nothing more. Never write “the site scores 96/100 for accessibility” in a client report without that caveat, because it is the single most misquoted number in web accessibility.

Best for: A quick baseline and for tracking regressions over time in CI.

4. Accessibility Insights for Web (Microsoft)

What it is: A free extension with three modes: FastPass (automated), Ad hoc tools (visual overlays), and Assessment (a guided manual audit covering all of WCAG 2.1 AA).

What it detects: Everything axe finds, plus the Tab Stops visualizer, which draws numbered circles and connecting lines over the page as you tab through it. It is the fastest way to prove a broken focus order to a client with a screenshot.

What it misses: The Assessment mode still relies on you to make the judgment calls, it just tells you which calls to make.

How to read the results: Run FastPass first, then the Assessment when you need a defensible, documented audit. The exported HTML report is genuinely client-presentable.

Best for: Structured audits where you need to prove coverage, not just list bugs.

5. ANDI (Accessible Name and Description Inspector)

What it is: A free bookmarklet built by the US Social Security Administration, and the tool behind the Section 508 ICT Testing Baseline.

What it detects: The accessible name computed for every interactive element, which is exactly what a screen reader will announce. It also has modules for tables, images, links, structures, colour contrast and hidden content.

What it misses: Behaviour over time, keyboard traps, timing issues.

How to read the results: Use ANDI when a button “looks labelled” but you are unsure what an assistive technology will say. If ANDI shows a link named “Read more” seven times on one page, you have a real, reportable WCAG 2.4.4 finding, even though axe will stay silent.

Best for: Verifying ARIA labels and complex data tables.

6. IBM Equal Access Accessibility Checker

What it is: A free extension for Chrome and Firefox, plus an open source Node module.

What it detects: WCAG 2.2 and EN 301 549 rules, with an unusually good explanation of why each issue matters and who it affects.

What it misses: Same blind spots as every scanner: intent, order, behaviour.

How to read the results: Its scan-level “Violations / Needs review / Recommendations” split maps neatly onto priority tiers in a report. Handy as a second opinion when a developer disputes an axe finding.

7. Pa11y CI

What it is: A free open source command line tool that runs HTML_CodeSniffer or axe across a list of URLs and fails your build when new issues appear.

What it detects: The same automated rule sets, but across hundreds of URLs at once and on every deploy.

What it misses: Everything manual, plus states it cannot reach without scripted actions.

How to read the results: Use it as a regression net, not an audit. Set a baseline after remediation, then let it block the pull request that reintroduces an unlabeled input three months later.

8. TPGi Colour Contrast Analyser and the WebAIM Contrast Checker

What they are: A free desktop eyedropper app and a free web calculator.

What they detect: Exact contrast ratios against the 4.5:1 (normal text), 3:1 (large text and UI components) thresholds.

What they miss: Nothing about contrast, but automated scanners routinely skip text over gradients, background images, video overlays, and text inside SVG or canvas. Those are exactly the cases where the eyedropper earns its keep.

How to read the results: Check the states everyone forgets: hover, focus, visited, disabled, placeholder text, and dark mode. Placeholder-only form fields fail on two counts at once.

9. NVDA, VoiceOver and TalkBack (Screen Readers)

What they are: Free screen readers. NVDA on Windows (pair with Chrome or Firefox), VoiceOver built into macOS and iOS (pair with Safari), TalkBack on Android.

What they detect: Reality. Whether the page is genuinely usable without sight.

What they miss: Nothing in principle, but they require you to learn a handful of shortcuts and to accept that different combinations behave differently. It is argued more carefully on usabilitygeek.com.

How to read the results: Do not report “NVDA read it strangely” as a bug on its own. Tie every finding to a specific WCAG success criterion and a specific element. If you cannot map it to a criterion but it clearly harms usability, list it in a separate “usability barriers” section.

Tool Comparison at a Glance

Tool	Type	Strongest at	Blind spot
axe DevTools	Extension	ARIA errors, dynamic states, low false positives	Keyboard behaviour, content quality
WAVE	Extension / online	Visual overlays, heading and landmark structure	Interaction, focus management
Lighthouse	Built into Chrome	Fast baseline, CI trend tracking	Misleading score, narrow rule set
Accessibility Insights	Extension	Tab stop visualizer, guided assessment	Still needs human judgment
ANDI	Bookmarklet	Accessible names, tables, Section 508 work	Timing, motion, keyboard traps
IBM Equal Access	Extension / Node	Clear explanations, EN 301 549 mapping	Same automated ceiling
Pa11y CI	Command line	Bulk scanning, build-time regression checks	No manual coverage at all
Colour Contrast Analyser	Desktop app	Text on images, gradients, hover states	Contrast only
NVDA / VoiceOver	Screen reader	Real announced experience	Learning curve, slower testing

The Manual Checks No Scanner Will Ever Catch

This is the part that separates a real audit from a screenshot of a scanner. Budget at least an hour per template.

Check 1: Keyboard-Only Navigation

Unplug the mouse. Seriously. Then work through the page using only Tab, Shift+Tab, Enter, Space, the arrow keys and Escape.

Can you reach every interactive element: links, buttons, form fields, custom dropdowns, carousel controls, video player controls?
Can you activate each one? Custom “buttons” built from divs usually respond to Enter but not Space, or to neither.
Is there a keyboard trap? Open a modal, a date picker, a cookie banner or an embedded iframe and try to tab out. If you cannot escape without a mouse, that is a WCAG 2.1.2 failure and it is a blocker.
Does Escape close modals and dropdowns, and does focus return to the element that opened them?
Is there a skip link? Press Tab once on page load and see if it appears.

Check 2: Focus Visibility and Focus Order

Visible focus: Can you always see where you are? A designer removing outline: none without a replacement is still the most common accessibility defect in custom themes.
Focus order: Does the sequence follow the visual reading order? CSS Flexbox and Grid ordering properties break this constantly: the layout looks right, the tab order jumps around the page.
Focus not obscured: A WCAG 2.2 addition. Sticky headers, floating chat widgets and cookie bars love to sit on top of the element that just received focus. Tab slowly down a long page and watch for it.
Focus after actions: After submitting a form with errors, after loading more results, after closing a dialog, where does focus land? If it resets to the top of the document, keyboard users have to start over.

Check 3: Screen Reader Announcements

Start with NVDA and Chrome on Windows, or VoiceOver and Safari on Mac. Learn five commands and you can do 80 percent of the work: read next item, list headings, list links, list form fields, list landmarks.

Does the heading list read like a sensible outline of the page?
Do links make sense out of context, or is it “click here, click here, read more”?
Do images convey the same information they convey visually? A scanner sees alt="image123.jpg" as present and passes it. A human catches it instantly.
Are dynamic updates announced? Add to cart, filter results, form validation errors, live search suggestions. Silence here is one of the most damaging and least detectable failures.
Are form fields announced with their label, their required state, their format hint and their error message?

Check 4: Zoom, Reflow and Text Spacing

Zoom the browser to 200%. Nothing should be cut off or overlapping.
Set the viewport to 320 CSS pixels wide (or zoom to 400% at 1280px) and check for horizontal scrolling. Content must reflow into a single column. WCAG 2.1 criterion 1.4.10.
Apply a text-spacing bookmarklet (increased line height, letter and word spacing) and confirm text does not get clipped inside fixed-height containers.
Zoom to 400% and confirm the mobile navigation is still reachable.

Check 5: Content, Media and Motion

Are videos captioned, and are the captions accurate rather than raw auto-generated text?
Does audio or video autoplay? Can it be paused?
Does any content flash more than three times per second?
Does the site respect prefers-reduced-motion? Turn on “Reduce motion” in your OS settings and reload.
Is information conveyed by colour alone? Red-only error text, colour-coded status badges and link-by-colour in body copy all fail 1.4.1.
Are touch targets at least 24 by 24 CSS pixels, per WCAG 2.2 criterion 2.5.8?

Check 6: Forms and Errors, End to End

Submit the form empty. Submit it with bad data. Then verify: errors are identified in text (not just colour), the error message explains how to fix the problem, focus moves to the error summary or the first bad field, labels stay visible while typing, and no CAPTCHA blocks non-visual users without an alternative.

How to Interpret Results Before Handing a Report to a Client

Raw scanner exports are not a deliverable. Clients receive a 300-row CSV, feel overwhelmed, and do nothing. Structure the findings instead.

Step 1: Deduplicate

One missing label in a header template that appears on 400 pages is one issue, not 400. Group by component, not by URL. This alone often cuts a report by 80 percent. Reference: https://accessibility.umich.edu.

Step 2: Separate violations from review items

Use three buckets so nobody argues about what is real:

Confirmed failures mapped to a WCAG success criterion and level.
Needs manual review, where a human has to make the call (is this alt text correct?).
Best practice recommendations that improve usability but are not conformance failures.

Step 3: Prioritise by user impact, not by tool severity

Priority	Definition	Example
P1 Blocker	Prevents task completion for a group of users	Keyboard trap in checkout, unlabeled payment field
P2 Serious	Task is possible but significantly harder	No visible focus, illogical heading structure
P3 Moderate	Friction or confusion, workaround exists	Redundant links, vague link text
P4 Minor	Polish and best practice	Long alt text, decorative image not marked as such

Step 4: Write findings a developer can actually fix

Every entry should contain: the page URL, the element selector, a screenshot or code snippet, the WCAG criterion and level, the user impact in one sentence, and a concrete suggested fix. “Improve accessibility of nav” is not a finding. “The mobile menu toggle at button.nav-toggle has no accessible name; add aria-label="Open menu" and aria-expanded reflecting state. WCAG 4.1.2 Name, Role, Value (Level A)” is.

Step 5: Set expectations about overlays

If a client asks about a one-line JavaScript accessibility widget, be clear: overlays do not fix the underlying code, they have been the subject of a large share of US web accessibility lawsuits, and they are explicitly rejected by most accessibility professionals. Remediation happens in the markup, the CSS and the components.

A Repeatable 60-Minute Test Routine

0 to 5 min: Run axe DevTools and WAVE on the page. Export both.
5 to 10 min: Run Lighthouse for the baseline number, note it, caveat it.
10 to 20 min: Accessibility Insights Tab Stops visualizer. Screenshot the tab path.
20 to 35 min: Keyboard-only pass, including every modal, menu and form state.
35 to 45 min: Zoom to 200% and 400%, check reflow and obscured focus.
45 to 60 min: Screen reader pass: headings list, links list, form fields, dynamic updates.
Afterwards: Deduplicate, prioritise, write it up.

Run this on your sample pages, add Pa11y CI to the build so nothing regresses, and re-test after every major release or redesign. Testing once a year and calling a site compliant is how clients end up with a demand letter. Much the same conclusion turns up on accessibilitychecker.org.

FAQ

How can I check if my website is accessible?

Start with a free browser extension such as WAVE or axe DevTools on your most important pages, which takes about five minutes and flags code-level problems. Then do a keyboard-only pass with the mouse unplugged and a screen reader pass with NVDA or VoiceOver. If both of those complete without blockers and your scanners are clean, you have a reasonable picture. A single URL scan on its own tells you very little.

What are the steps in accessibility testing?

Define the standard (usually WCAG 2.2 AA), select a representative page sample including forms and dynamic states, run automated scans, run guided semi-automated tools, perform manual keyboard, zoom and content checks, test with at least one screen reader, then deduplicate and prioritise findings into a remediation report.

What is the best tool for web accessibility testing?

There is no single best tool. For raw accuracy and low false positives, axe DevTools leads. For explaining problems visually to clients, WAVE is unbeatable. For structured, documented audits, Accessibility Insights. For what users actually experience, a screen reader. Most professional audits use three or four of these together.

How much can automated tools actually detect?

Independent studies and tool vendors themselves put automated detection at roughly 30 to 57 percent of WCAG issues, depending on the rule set and the page. Everything involving meaning, order, behaviour and context requires a human.

Is WCAG legally required?

WCAG is a technical standard rather than a law, but it is referenced by laws in many jurisdictions. In the EU, the European Accessibility Act applies to a wide range of digital products and services and points to EN 301 549, which is built on WCAG. In the US, the DOJ’s ADA Title II rule names WCAG 2.1 AA for state and local government bodies, and courts have repeatedly used WCAG as the benchmark in ADA claims against private businesses. In practice, targeting WCAG 2.2 AA is the safest position.

How often should a site be re-tested?

Run automated checks on every deploy through CI, do a manual spot check each time a new template or component ships, and schedule a full manual audit at least once a year or after any significant redesign.

Wrapping Up

Learning how to test website accessibility properly is mostly about discipline, not expensive software. Every tool in this guide is free. The difference between a superficial scan and a credible audit is the hour you spend with the mouse unplugged and the screen reader talking. Start with axe or WAVE this afternoon on your busiest template, then add one manual check at a time until the full routine becomes second nature.