Accessibility: what it actually checks

Accessibility is thought of as a ramp: worthwhile, expensive, done at the end if time allows. Which is why it is not done.

It helps to see it differently. Accessibility checks that a page is built rather than drawn. A screen reader, a keyboard and a search crawler all read the same thing: headings by level, links with text, fields with labels, focus order. If the reader cannot make sense of it, neither can the crawler, and the person with a mouse merely got lucky.

Four things that break most often

**Headings as size, not as level.** An `h1` is chosen because it is big, not because it is the subject of the page. A document with three `h1`s and no `h2` is a document without a table of contents, and both the reader and search feel their way through it.

**A link with no text.** An arrow icon with no label reads as "link". Where to is unknown. A screen reader offers the list of links on the page, and it contains twelve identical words.

**Contrast by eye.** Grey on white looks tasteful and measures as unreadable. It is the one part of accessibility that can be computed in advance, and the part most often not computed.

**Focus you cannot see.** The outline around the active element is the first thing removed for spoiling the look. After that the site cannot be used from a keyboard: a person presses Tab and has no idea where they are.

What the template does about it

The ink-on-surface pair and the label on a button are computed rather than chosen: fail, and the check fails. Headings are placed by level rather than by size, and every page has exactly one first level. Logical properties instead of left and right — which is why an Arabic locale flips completely rather than halfway.

None of this makes a site accessible on its own; it does not replace a person with a keyboard. But everything computable is computed before the page ships.