Why a clean scanner report isn’t the same as accessible

Automated scanners are useful and worth running, but they only catch what can be tested mechanically: missing alt text, insufficient colour contrast, missing form labels, and a handful of other structural markers. Depending on the tool, that’s roughly a third of the actual WCAG 2.1 success criteria. The rest, whether a screen reader user can actually complete a donation, whether keyboard focus moves somewhere sensible after a modal closes, whether an error message is announced at all, needs a person to actually use the site the way someone with a disability would.

I’ve reviewed sites with a spotless automated score that were genuinely unusable with a screen reader. The scanner isn’t wrong about what it checks. It’s just checking a small part of the picture.

A walkthrough of what actually gets tested

Keyboard navigation

Can every interactive element, menus, forms, modals, be reached and operated using only a keyboard, in a logical order, with a visible focus indicator at every step? This alone surfaces a large share of real-world issues, because it’s exactly how many assistive technology users navigate.

Screen reader behaviour

Does the page make sense read aloud, in the order it’s read? Are images given meaningful alt text rather than filenames or nothing at all? Are form fields properly labelled so a screen reader user knows what they’re filling in, and are error messages actually announced rather than just appearing visually?

Colour and contrast

Beyond the basic contrast ratio check a scanner runs, does the site rely on colour alone to convey information, a red error state with no icon or text, for instance, that a colourblind user would miss entirely?

Heading structure and page semantics

Do headings follow a logical hierarchy that a screen reader user can navigate by jumping between them, or is the visual heading style applied to text that isn’t actually marked up as a heading?

Forms and error handling

This is where donation and contact forms most often fail. Labels, instructions, and error messages all need to be programmatically associated with their fields, not just placed nearby visually.

The failures that show up again and again

• Donation forms where an error appears visually but is never announced to a screen reader
• Modals and pop-ups that trap keyboard focus, or don’t return focus anywhere sensible on close
• Decorative images given verbose alt text, and meaningful images given none
• Colour-only indicators, required fields marked in red text alone, with no icon or label
• Custom-styled buttons and menus built from generic elements with no keyboard or screen reader support

What a useful audit report actually looks like

A report that lists every WCAG success criterion with a pass or fail mark is comprehensive and largely useless to a board. A useful report groups findings by the actual user impact, keyboard access, screen reader access, cognitive load, and ranks them by how many people they affect and how hard they are to fix. It should read as a prioritised plan a non-technical board member can approve, not a specification only a developer can parse.

What happens after the audit

The audit itself doesn’t fix anything. What it should give you is a sequenced list: what to fix immediately because it blocks people from using the site, what to fix soon because it degrades the experience significantly, and what to monitor because it’s a smaller issue or affects fewer people. Most organisations don’t need to fix everything at once. They need to know what actually matters first.

Frequently asked questions