Accessibility audits, automated checkers and overlays: what each can tell you

Ask “is our website accessible?” and you’ll be offered three very different answers: a free checker that returns a score in seconds, a website accessibility audit in which someone tests your pages against WCAG by hand, and a widget that promises compliance from a single line of code.

Only one of them tells you whether disabled visitors can actually use your site. Here’s what each finds and misses, a 30-minute self-check you can run today, and what to do with the results.

The short answer

• Automated checkers such as axe, WAVE and Lighthouse are free and fast. They catch machine-testable failures like missing alt attributes and low contrast, but much of WCAG needs human judgement, so a clean scan doesn’t mean an accessible site.
• A manual audit tests key pages and journeys against WCAG 2.2 level AA with a keyboard, screen readers and zoom. It’s the only one of the three that can tell you whether a site conforms.
• Overlay widgets add a toolbar on top of the page. They don’t repair the code, they can clash with visitors’ own assistive technology, and misleading compliance claims have drawn regulatory action.

Use checkers for triage, an audit for the real answer, and fix what it finds in the site itself.

Automated accessibility testing tools: fast, free and partial

The best-known accessibility checkers are free to start with. axe DevTools is Deque’s browser extension, built on its open-source axe-core engine. WAVE, from WebAIM, places an icon for each issue directly on the page. Lighthouse, in Chrome’s developer tools and PageSpeed Insights, uses axe-core for its accessibility checks.

What checkers catch reliably

Anything a tool can decide by reading the code: images with no alt attribute, text that fails contrast against a solid background, fields with no label, icon buttons with no accessible name, a missing page language and invalid ARIA. Most are also the failures WebAIM finds most often in its yearly scan of a million home pages, so a first scan is always worth it.

What they can’t judge

A checker can confirm that alt text exists, not that it describes the image. Nor can it tell whether:

• focus is visible and moves in a sensible order, or a keyboard user gets trapped in a pop-up
• a custom dropdown, carousel or date picker works without a mouse
• headings and link text make sense to someone listening rather than looking
• error messages explain the fix, and “Message sent” is announced
• text over a photo or gradient is readable

It also tests only the states you scan: closed menus, untriggered errors and unvisited pages go unchecked. The W3C’s guidance on selecting evaluation tools is clear: tools can assist an evaluation but can’t determine accessibility, and human judgement is required.

Read results as a to-do list

Treat errors as failures to fix and the score as a measure of progress, not a verdict. Then work through what the tool leaves for human judgement: WAVE’s alerts, axe’s “needs review” items and the manual checks Lighthouse lists beneath its score.

What a manual website accessibility audit covers

Manual accessibility testing answers the question checkers can’t: can people who rely on assistive technology get through your site? A credible audit follows a method like the W3C’s WCAG Evaluation Methodology (WCAG-EM): define the scope, explore the site, select a representative sample, evaluate it and report the findings.

Scope and sample

A good audit tests each distinct template and every key process, such as an enquiry or booking, from first step to confirmation. On a multilingual site it samples each language, because translations change text length and layout, and each version needs its page language set so screen readers pronounce it correctly. The usual target is WCAG 2.2 level AA; WCAG 2.2 explained covers what that includes.

Keyboard

The tester puts the mouse away and uses Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Every control must be reachable, focus must stay visible and not vanish behind sticky bars, and nothing may trap it. Menus, modal windows and carousels are the usual trouble spots, as our guide to accessible navigation explains.

Screen reader testing

Testers use common pairings: NVDA or JAWS on Windows, VoiceOver with Safari on a Mac or iPhone, TalkBack on Android. They listen for a sensible heading outline, landmarks, link text that makes sense out of context, labelled fields, announced errors, and buttons that report their state, such as “expanded”.

Zoom, reflow and spacing

At 200% text size nothing should be cut off. At 400% zoom in a window 1,280 pixels wide (equivalent to a 320 CSS pixel viewport), content should reflow into one column without sideways scrolling. Wider line, letter and word spacing mustn’t break the layout.

Content, media and forms

Then the judgement calls: whether alt text says what an image means in context, headings reflect the structure, captions are accurate, and contrast holds on hover and over images (colour contrast and readable text covers that). Forms get extra attention: labels, error messages, time limits and the WCAG 2.2 criteria on target size, redundant entry and accessible authentication, all covered in accessible forms.

An audit tests conformance, not ease of use; usability testing or a website UX audit answers that related question.

Accessibility overlays: why a widget can’t fix the site

An overlay is a third-party script, usually a floating icon that opens a toolbar with larger text, contrast modes or a reading guide. Many also attempt automatic repairs as the page loads, guessing field labels or generating alt text.

Why overlays fall short

• The code underneath doesn’t change. Runtime patches fix only what the script guesses correctly. A form that can’t be completed by keyboard stays broken.
• Visitors bring their own tools. People who need larger text, high contrast or speech have usually set it up on their own device already; a site’s toolbar duplicates those settings or fights them.
• The overlay can add barriers. Its own panel has to be accessible, it adds a stop to the tab order, and its changes can override what a screen reader would otherwise announce.
• It’s another script on every page. Like other third-party scripts, it adds load time and a dependency you don’t control.
• The claims don’t hold up. In 2025 the US Federal Trade Commission ordered one overlay vendor to pay $1 million over claims that its AI tool could make any website WCAG-compliant. And an installed overlay hasn’t stopped businesses being sued over inaccessible websites.

If you already have one, don’t count it as accessibility work. Test with the widget active, since that’s what visitors get, and put the budget into fixing the site itself.

How to test website accessibility in 30 minutes

It isn’t an audit, but it shows whether you have a problem worth fixing. Use a laptop and three pages: the homepage, your main service page and your enquiry form.

1. Run a checker (5 minutes)

Run WAVE or axe DevTools on each page and note the errors. Those that appear on every page usually live in the header, footer or theme, so one fix clears them everywhere.

2. Put the mouse away (10 minutes)

• You can see where focus is at every step, and it follows the reading order
• The menu and any dropdowns open and close with the keyboard
• Pop-ups and cookie banners close with the keyboard, without trapping focus
• You can submit the form, including after a deliberate mistake

3. Zoom in (5 minutes)

• At 200% zoom, no text is cut off or hidden
• At 400% zoom, with the window about 1,280 pixels wide, text reflows without sideways scrolling

4. Listen (7 minutes)

On a Mac, turn on VoiceOver (Command + F5) and use Safari. On Windows, install NVDA, a free screen reader.

• The headings form a sensible outline (VoiceOver: Control + Option + U opens the rotor, then arrow to Headings; NVDA: press H to jump between headings)
• Buttons and links have meaningful names, not just “button” or “link”
• Form fields announce their labels, and errors are read out

5. Read like a visitor (3 minutes)

• Meaningful images have alt text that says what they show
• Link text says where it goes, not just “read more”
• Videos have accurate captions, and text over photos is easy to read

If several fail, especially the keyboard and screen reader steps, you have problems no widget will fix.

What a useful audit report contains

A good report lets a developer fix each issue without a follow-up call. Every finding needs:

Around the findings, expect the scope (pages, journeys, languages), the WCAG version and level, the assistive technology used and a summary by severity. Be wary of an exported scan with a logo on it, or a compliance claim based on automated testing alone.

Prioritise, fix at the root, then retest

Prioritise by impact

1. Blockers on key journeys: anything stopping someone submitting an enquiry, booking or order.
2. Shared templates and components: header, navigation, forms and colour palette. Fix once, and every page improves.
3. Content fixes: alt text, link text, headings and captions, which editors can work through.
4. Lower-severity issues that make the site harder, but not impossible, to use.

Fix problems where they start

Patch a symptom on one page and it reappears on the next. If contrast fails, fix the palette in the theme, not individual buttons; if the menu fails, rebuild the menu component. When problems run through the theme, page builder and brand palette, patching can cost more than rebuilding, one of the signs a website needs a redesign.

Many fixes pay off twice: real headings, descriptive link text and good alt text also help search engines and AI tools understand a page, as accessibility and SEO explains.

Retest and keep checking

Retest each fix the way it was found: a keyboard issue with a keyboard, a screen reader issue with the same screen reader. Then stop it slipping back:

• Automated checks run whenever templates, plugins or widgets change, and new pop-ups and forms get a keyboard test before going live
• Key journeys are spot-checked by hand regularly, and re-audited after major changes
• Your accessibility statement records the date of the last review, as our practical guide to web accessibility describes

Frequently asked questions

Is a Lighthouse accessibility score of 100 enough?

No. It confirms the page passed Lighthouse’s automated checks, in the state tested, and nothing more. Keyboard access, screen reader behaviour, zoom and the quality of alt text still need a person.

How often should a website be tested for accessibility?

Automated checks belong in every significant release. A full manual audit makes most sense around a redesign, after major new functionality, or when a contract or tender asks for evidence.

Do we need to test with disabled users as well?

Where you can, yes. An audit shows where a site fails the standard; watching people who use assistive technology every day shows where it’s still hard work even when it passes.

Can we audit our own website?

Partly. Anyone can run the checks above and fix what they find. A conformance audit needs someone fluent in WCAG and in screen readers; otherwise a clean result may only mean nobody knew what to look for.

What to do next

The 30-minute check won’t prove your site is accessible, but it shows whether the barriers sit in content your team can fix or in the theme and code underneath. For a definitive answer, commission a manual audit against WCAG 2.2 AA with a clear scope.

If the findings point to the foundations, fix them there. A website redesign is the natural moment: accessibility is designed into the palette, components and templates rather than patched on, and tested before launch. Already holding an audit report and unsure whether to repair or rebuild? Talk to us about what your website needs.