Accessibility

Accessibility: what gets checked, and what a scan cannot see

Accessibility means the site still works for someone using a keyboard, a screen reader, a phone in bright sunlight, or a browser zoomed to twice its size. Here is what the audit measures, and the part no automated tool can measure for you.

Who this is actually about

Not a small group. It covers anyone who cannot use a mouse, anyone reading with the text enlarged, anyone whose eyesight has changed with age, and anyone squinting at a phone outdoors. The fixes are the same for all of them: text that stands out from its background, buttons big enough to hit, labels that say what a field is for.

It is also a legal question, not only a courtesy. In the UK, the Equality Act 2010 places a duty on service providers to make reasonable adjustments, and public sector bodies carry a separate, stricter duty under the 2018 accessibility regulations. In the US, the Department of Justice's 2024 rule under Title II of the ADA requires state and local government web content to meet WCAG 2.1 Level AA; for private businesses the department has set no technical standard, and claims are argued case by case. We are not lawyers and this is not advice. It is the reason WCAG 2.1 AA is the yardstick the audit uses.

The checks run on the page a visitor sees, not the file the server sent

The audit opens your site in a real headless Chrome, waits for the JavaScript to finish, and then runs axe-core against the rendered page, restricted to the WCAG 2.0 and 2.1 A and AA rules. That ordering matters more than it sounds. Run the same checks against the raw HTML of a modern JavaScript site and you get a page with no headings, no text and no navigation, because none of it exists yet. When this engine was built that way it reported fourteen findings on one ordinary site, and all fourteen were false.

Each violation axe reports carries its own impact rating, and the report ranks by it: critical and serious become critical findings, moderate becomes a warning, minor becomes information. The number of affected elements comes with it, so one bad element and ninety bad elements do not read the same.

Contrast and tap targets, and where those numbers come from

Contrast is measured, not guessed at. WCAG success criterion 1.4.3 sets 4.5:1 for normal text against its background, and the browser pass computes the real ratio from the colours as rendered. The static pass separately flags inline styles that put light text on a light background, but that is only a hint. The browser measurement is the one that counts.

Tap target size is the check most tools get wrong. WCAG 2.2 added criterion 2.5.8, which asks for at least 24 by 24 CSS pixels at AA, with a genuine exception for links inside a sentence. A link in a paragraph is not meant to be counted, and counting it is the checker being wrong rather than your page. Our measurement uses the stricter 44 by 44 figure and reports it as a proportion, not a raw count: more than half the targets undersized is a warning about the whole page, a fifth is noted as awkward on a phone, and below that nothing is reported, because at that level it is almost always inline links in body text being swept up.

What a scan cannot tell you

An automated pass finds the failures a machine can see. It cannot tell you whether alt text describes the picture or just repeats the file name, whether the tab order follows the visual order, whether an error message explains how to fix the problem, or whether a screen reader announces your menu in a way anyone could follow. A report that hands you a perfect accessibility score on automation alone is overclaiming, and axe-core's own documentation is clear that automated rules do not catch everything.

The other half of that rule is what happens when a check cannot run at all. If the headless browser cannot load the page, the Accessibility, Functional and Responsive categories are dropped out of the overall score and listed with the reason it failed. They are never scored zero. A check that did not happen is not a defect, and counting one as a failure invents a problem you do not have.

What the engine checks here

Each of these is a rule in the code, not a category heading.

Text contrast against its backgroundaxe-core computes the real contrast ratio from the rendered colours and flags anything below the WCAG 1.4.3 threshold of 4.5:1 for normal text. The static pass separately flags inline styles that set light text on a light background, or dark on dark.
Images with no alt attributeCounted separately from images with an empty alt. An empty alt is a deliberate instruction to skip a decorative image, so it is recorded as decorative rather than as an error. Only a missing attribute is reported.
Form fields with no labelA form with no <label> element is reported as a warning. Screen readers and browser autofill both read the label; without one the field is announced as nothing, and the visitor guesses.
The language of the pageA missing lang attribute on the <html> element is reported. It is what tells a screen reader to read English as English rather than in the wrong voice, and it is one attribute to fix.
Landmarks and the skip linkMissing <main>, <nav>, <header> and <footer> are each reported. Without <main>, reader modes and screen readers cannot jump past the navigation, so every visit restarts at the top of the menu. Links reading 'skip' or 'main content' are checked for separately.
Heading structureNo h1 is a warning. An h1 with no h2 beneath it is noted, and so is a page carrying more than one heading per two paragraphs, which usually means headings are being used as styling rather than structure.
Tap target size, as a proportionEvery link, button, input, select, textarea and role=button on the rendered page is measured at its real size. Under 44 by 44 pixels counts as small. Reported as a warning above 50 per cent, as information above 20 per cent, and not at all below that.
Zoom, reflow and motionHorizontal scrolling is tested at 375, 640, 768 and 1280 pixels wide, the 640 case standing in for 200 per cent zoom, and more than 4 pixels of overflow is reported. Stylesheets are also checked for a prefers-reduced-motion rule, the switch that turns animation off for people it makes ill.

Questions

Does my small business legally have to be accessible?

It depends where you trade and what kind of organisation you are. In the UK the Equality Act 2010 places a reasonable-adjustments duty on service providers, and public sector bodies have a separate duty under the 2018 accessibility regulations. In the US the Department of Justice's 2024 rule sets WCAG 2.1 AA for state and local government web content, while for private businesses no technical standard has been set and claims are argued case by case. We are not lawyers, so take that as context rather than advice. What we can say is that WCAG 2.1 AA is the standard everyone measures against, which is why the audit uses it.

A free tool gave my site 100 for accessibility. Is that good?

It means no machine-detectable failure was found on the page that was scanned. That is a floor, not proof. Alt text that says 'IMG_4021', a checkout you cannot reach without a mouse and a menu a screen reader reads as a wall of links can all sit behind a clean automated score. The honest reading is 'nothing automated is failing here', and any report claiming more than that from a scan alone is overstating what it did.

Do you fix these, or only find them?

We find them. The report names the page each finding sits on, shows the measurement behind it, and puts the fix in plain English so you or your developer can act on it without translating anything first. An audit is a survey, not the building work.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.