Automated accessibility scanners are useful, and we run them on every site we maintain. But you need to know what they can and can’t tell you. A clean automated report doesn’t mean a site is accessible. It means the site passed the checks a machine knows how to run.
That gap matters for two reasons. People using keyboards and screen readers still hit barriers on sites with spotless reports. And if a site ever gets a demand letter, “our scanner said we were fine” is not much of a defense. Here’s how we think about what the tools cover and how to cover the rest.
What scanners catch well
Tools like axe, WAVE, Lighthouse and Pa11y are good at anything that can be answered by reading the page’s code. The common catches:
- Missing alt text on images.
- Color contrast below WCAG thresholds (4.5:1 for normal text, 3:1 for large text).
- Form fields without a programmatic label.
- Empty links and buttons, like an icon-only social link with no text.
- Missing page language, duplicate IDs and skipped heading levels.
- ARIA attributes used incorrectly, such as a role that doesn’t exist.
These are mechanical checks, and machines are good at them. They’re also the issues that show up most often in demand letters, because anyone can run a free scanner against your homepage. Fixing them is the floor, not the finish line.
One practical tip: run the scanner against templates, not just pages. If your blog post template has a contrast problem in the byline, every post has it. Fix the template once and hundreds of errors disappear from the report.
What scanners can’t judge
A scanner can confirm something exists. It usually can’t tell you whether it works for a person.
- Whether alt text makes sense. A scanner sees that an image has alt text. It can’t tell that “IMG_4021” or “banner-final-v2” isn’t helpful, or that a decorative swirl should have empty alt text so screen readers skip it.
- Keyboard flow. Can someone reach every menu item, open and close the popup, pick a date and complete the form using only Tab, Shift+Tab, Enter, Space and the arrow keys? Only a person can tell.
- Focus visibility. Whether you can actually see where you are as you tab through the page. Many themes remove the browser’s focus outline because a designer thought it looked messy. WCAG 2.2 also asks that the focused item isn’t hidden behind a sticky header or cookie banner.
- Reading order. Whether a screen reader announces content in an order that makes sense. CSS can put things in one visual order while the code says something else.
- Meaningful headings and links. Whether headings describe the content beneath them, and whether link text like “Learn more” means anything when a screen reader user pulls up a list of every link on the page.
- Error handling. Whether a form tells you what went wrong, in text, near the field, and whether that message gets announced.
- Custom widgets. Date pickers, scheduling widgets, carousels, accordions and tabbed content. These are where most real-world barriers live, and they often pass automated checks because the code is technically valid.
A common failure: a date picker scans completely clean, but when you test it by keyboard, focus goes into it and can’t get back out. The fix is usually a few lines of JavaScript, but no automated tool will find it for you.
How to test by hand
You don’t need to be an expert to catch the worst problems. Pick your five or six most important pages: home, a key landing page, contact, anything with a form, and anything that books or sells.
Keyboard test
- Click in the browser’s address bar, then put the mouse away.
- Press Tab repeatedly and watch the screen. You should always be able to see which element has focus.
- Check that a “Skip to content” link appears first and works.
- Open the main menu, including dropdowns, and reach every item.
- Open any popup or modal. Focus should move into it, Escape should close it, and focus should return to where you were.
- Fill out and submit each form, including triggering an error on purpose.
Screen reader test
On a Mac, turn on VoiceOver with Command+F5 and use it in Safari. On Windows, NVDA is free and works well in Chrome or Firefox. Spend ten minutes on each key page:
- Jump through headings (H in NVDA, the rotor in VoiceOver) and see if the outline makes sense on its own.
- Listen to how images are described.
- Pull up the list of links and see if each one is understandable out of context.
- Complete a form and listen for labels, required field notices and error messages.
Write down what you find with the page URL and what you did. That list becomes your fix list, and later your evidence that the site was tested.
Zoom and reflow
Set the browser to 200% zoom and then try a narrow window around 320 pixels wide. Text should reflow without horizontal scrolling, and nothing should overlap or get cut off. Sticky headers and chat widgets are the usual offenders here.
Keep scanning on a schedule
Most accessibility regressions we see come from new content, not code. Someone uploads an image without alt text, pastes a heading from Word that skips levels, adds a PDF, or embeds a third-party widget. A site that passed in January can fail in March without a developer touching it.
What a sustainable routine looks like:
- Scheduled automated scans of the whole site, not just the homepage, at least monthly. Weekly if the site publishes a lot.
- A manual pass whenever a template, menu or form changes, and on a few key pages once or twice a year regardless.
- Editor guidance. A one-page cheat sheet for whoever publishes content: write real alt text, use heading levels in order, don’t use bold text as a heading, and check that link text makes sense.
- Third-party check-ins. Scheduling tools, chat tools and embedded forms change on their vendor’s schedule, not yours. Retest them after vendor updates.
Keep the reports. A dated history showing you found issues and fixed them is useful if anyone ever asks what you’ve done to make the site accessible.
A note on overlays
Accessibility overlay widgets promise to fix everything with one script. They don’t. They can’t rewrite a broken date picker or fix a confusing reading order, and many users with disabilities find them harder to use because they interfere with the assistive technology people already rely on. Sites running overlays still receive demand letters.
Fixing the site itself is the only approach that works. The good news is that most fixes are small once you know where they are: a label here, a focus style there, a template change that clears hundreds of errors at once.
When it makes sense to bring us in
If you’re fixing a handful of contrast and alt text issues, your own team can usually handle it with a free scanner and the tests above. It’s worth bringing in help when the problems are in templates, custom widgets or third-party embeds, or when you want documented, repeatable scanning across a large site.
We offer a scanning service built on our own crawler. A baseline scan of the full site is $800, a verification rescan after fixes is $300, and ongoing monitoring is $200 a month. Automated scans only catch part of what WCAG covers, so we pair them with manual review of key templates and flows, and we can make the fixes too. Details are on our accessibility and cookie compliance page.