Accessibility

How to audit accessibility

An accessibility audit tests what a real person can do with keyboard, screen reader and zoom. Here is the order to run it, and what automation misses.

Key points

  • An audit measures completed tasks, not an automated score.
  • The order is keyboard, screen reader, zoom, contrast, motion.
  • Only 4 of 1,556 blocks in the catalogue mention accessibility in their metadata.

An accessibility audit checks what a person can actually do with the keyboard, a screen reader and 200% zoom, not the score that appears in an automated report.

The order of the checks

Five steps, from cheapest to most expensive. If the first one fails, the others do not matter yet.

  1. Keyboard: does Tab reach every control, and is the focus always visible?
  2. Screen reader: does every control announce name, role and state?
  3. Zoom at 200% and 400%: does the text stay readable without sideways scrolling?
  4. Contrast: 4.5:1 on body text, 3:1 on large text and on control borders.
  5. Motion: does the animation stop when prefers-reduced-motion is active?

The command

axe-core is Deque's engine under the MPL-2.0 licence, and its CLI runs the rules against a page that is already serving.

npx @axe-core/cli http://localhost:3000 --exit

The --exit flag fails the pipeline when it finds a violation. The automated test covers part of the criteria; the order above covers the rest.

Where the automated test stops

axe finds a missing label, not a wrong one. Three cases pass the test and still block a person: a focus order that skips the content, a button labelled “click here”, an error message that is never announced.

Three records to inspect

shadcn/ui navigation menu is MIT, Berlix UI checkbox and Efferd popover show three different contracts; for the last two the licence is whatever the publisher declares on the record.

The limitation

A manual audit measures one person, one browser and one screen reader at a time. No audit covers every combination: four blocks out of 1,556 that mention accessibility say how little the topic is documented, not how accessible the code is.

Where to continue

The working checklist is in accessible React components; the most common labelling mistake is in aria-label used badly; the comparison of measured React libraries is in React UI libraries 2026.

Frequently asked questions

How long does an accessibility audit take?

From half a day for one page to two weeks for a product with several flows. Duration depends on the number of tasks you test, not on the number of pages.

Is an automated test enough for compliance?

No. Automated tools cover part of the WCAG criteria and cannot judge whether a label makes sense. Use them as a first net, not as final proof.

Which WCAG level should I claim?

AA is the level most regulations and public tenders require. AAA stays a goal for parts of the product, not for the whole site.

Who should join an audit?

Whoever writes the code, whoever designs the flows and at least one person who uses the product with assistive technology. Without that person, the audit measures guesses.

How do I check keyboard accessibility?

Put the mouse away and complete the main task. If you cannot, the problem is real and no automated report compensates for it.