Your Accessibility Scan Found 0 Issues. That Isn't Compliance.

Why so many scans come back clean

Modern site builders are better than they used to be. Shopify, Squarespace, WordPress block themes and React frameworks generate markup that passes most automated checks by default: form fields get labels, images get an alt attribute, landmarks are present, headings nest correctly.

An automated scanner checks whether the machine-verifiable rules hold. On a modern template, they usually do. That tells you your foundation is sound. It does not tell you whether a person using a screen reader can actually complete a purchase.

What automated testing cannot see

Published estimates of automated coverage vary, but they cluster somewhere between a third and a half of WCAG success criteria. The rest need a human. Concretely, no scanner can decide:

Whether alt text is meaningful. alt="image" passes the rule and communicates nothing.
Whether reading order makes sense. CSS can reorder a page visually while the DOM order stays nonsensical to a screen reader.
Whether a custom control is operable by keyboard. A div with the right ARIA role still has to actually respond to Enter, Space and arrow keys.
Whether error messages are understandable. "Invalid input" is announced correctly and helps nobody.
Whether video captions are accurate. A caption track exists or it doesn't; whether it matches the audio is a human judgement.
Whether link text makes sense out of context. Screen reader users navigate by pulling up a list of links; fourteen of them reading "Learn more" is a failure no rule catches.

The "needs manual review" items matter

Most scanners, including axe-core which powers this one, return a third category alongside pass and fail: checks the engine could not decide. Colour contrast over a gradient or a background image is the classic example — the tool can see both colours but cannot know which pixel the text actually sits on.

These are quietly ignored by most reports. They shouldn't be. An item flagged for review is not a pass; it is a question that has not been answered.

One page is not a site

The larger issue with a clean result is usually scope. A homepage is the most designed, most tested, most looked-at page on any website. It is also the page least likely to be the subject of a complaint.

Accessibility complaints and demand letters overwhelmingly concern transactional paths: the product page, the cart, the checkout, the booking form, the PDF of the council meeting agenda. Those are the pages built later, under deadline, often by someone else.

If you scanned one page and it came back clean, you know one page is clean. On a 2,000-page store, that is a sample of 0.05%.

What to do with a clean scan

Widen it before you deepen it. Scanning ten templates beats scanning one page ten times. Cart, checkout, a product page, search results, a form, and your most-trafficked content pages.
Work through the manual-review items. They are the shortest honest to-do list you will get.
Do the five-minute keyboard test. Put the mouse away. Tab through a purchase or a form submission. If you cannot see where focus is, or you get stuck, you have found a real barrier no scanner reported.
Record that you checked, and when. Demonstrating an ongoing, documented process is worth considerably more than a single clean report.
Re-check after every deploy. Accessibility is not a state you reach; it regresses the first time somebody ships a new hero banner.

Be suspicious of tools that only reassure you

If a product tells you that you are compliant, it is selling comfort. No automated tool can determine legal compliance, and any vendor claiming a percentage score equals a legal status is making a claim it cannot support. A clean scan should be reported as exactly what it is: no automated failures detected, on the pages that were checked, on the day they were checked.

Check more than one page

Run a free scan and see how many pages on your site have never been checked.

Scan your site free