The accessibility problems you can't see on screen

The site looks fine. Half of what breaks a screen reader is invisible to the person who built it.

The problem

Your client's site looks clean. Then a demand letter arrives, or a customer writes in that they can't complete checkout with a keyboard.

You open the site, click around, and everything works — for you. That's the part that makes this hard: most accessibility failures are invisible to someone using a mouse and a working pair of eyes.

A button with an icon and no label reads as "button" to a screen reader. A form field whose label isn't connected reads as nothing. A carousel that traps keyboard focus is a wall.

Why the usual checks miss it

Two reasons.

The first is that most tools read the HTML the server sent, not the page that actually exists in the browser. Modern sites build half the interface with JavaScript — modals, dropdowns, tabs, dynamic ARIA. A tool that never runs the JavaScript never sees any of it.

The second is that it's genuinely tedious. Checking contrast on every state, tabbing through every flow, verifying every accessible name — nobody does that by hand on every deploy, and nobody should have to.

What we check, and what we don't

SiteMerit runs two layers.

The sample checks five accessibility signals in the HTML the server sent: image alternatives, declared language, semantic landmarks, ARIA markup, and accessible names for fields, links and buttons. The paid audit adds text color contrast and redirect chains. These checks are what the accessibility score is based on.

The paid audit adds a second layer: we open the page in a real browser, let the JavaScript run, and judge those checks on the page as it actually exists, with axe-core among the instruments. Beyond the checks, you also get the other axe-core findings: the rule that was violated, its impact level, and how many nodes it affected.

⚠️ Those extra findings take no points, and the report says so. They're there to tell you what to look at, not to grade you.

What this does not do

We don't certify compliance, and no automated tool honestly can. Automated checks catch a meaningful share of failures — the mechanical ones. They cannot tell you whether your page makes sense when read aloud, whether the reading order is logical, or whether a workaround is usable.

Automated checking does not replace testing with a real screen reader, by a person. Anyone who tells you otherwise is selling certainty that doesn't exist.

What automated checking is good for is the same thing a linter is good for: finding the mechanical failures fast, on every page, every time, so the human hours go to the parts that actually need judgment.