Accessibility tests
Accessibility fails as a late audit and works as a constraint on the contracts. That is the whole argument, and everything below is its mechanics.
The audit fails for a structural reason, not a cultural one: by the time it runs, the only fixes that fit the budget are cosmetic. Contrast can be adjusted. A keyboard model that was never designed cannot be retrofitted into a component that eleven screens already use.
Three places it is decided
Section titled “Three places it is decided”| Where | What is decided there | Cost of getting it wrong |
|---|---|---|
| Design system | Contrast per role pairing, focus ring, target size, heading and landmark structure, reduced motion | One change, everywhere |
| Component library | Role, name, keyboard model, announcements, state expression | One component, everywhere it is used |
| The screen | Composition: heading order, landmark nesting, focus after navigation, form grouping | This screen only |
Almost everything lands in the first two rows, and both are decided once. That is the leverage: a guarantee attached to a contract is inherited by every screen; a guarantee written in a policy document is inherited by nobody.
What an automated scan catches
Section titled “What an automated scan catches”Run axe over every story and at every meaningful state of every journey test. It is effectively free once wired, and it reliably catches:
- missing or empty accessible names
- insufficient contrast between text and its background
- form controls with no associated label
- invalid ARIA — roles that require children they do not have, states on elements that cannot carry them
- duplicate or missing landmarks, and some heading-order problems
- images with no alternative text, and decorative images that are not marked as such
That is a real and useful set. Wire it in first, before anything else on this page, because it is the cheapest defect-per-hour available in this whole hub.
What it does not catch
Section titled “What it does not catch”The honest number is that automated scanning finds roughly a third of the barriers real users hit. The rest are judgements, and they are the ones that matter most:
- an alternative text that exists and describes the wrong thing
- a keyboard path that works and takes forty tabs
- a focus order that is technically sequential and follows no visual logic
- an error announced once, before the person had reached the field
- a live region that announces so often it becomes unusable
- an interaction that requires a drag with no alternative
- a “skip to content” link that skips to the wrong content
- a modal that traps focus correctly and is opened by a control focus never returns to
None of these fail a scan. All of them make the product unusable for someone.
The manual pass
Section titled “The manual pass”Small, repeatable, and worth doing per feature rather than per release:
- Unplug the mouse. Complete the journey. Note anything you cannot reach, anything you reach in a strange order, and anywhere the focus ring disappears.
- Turn on a screen reader and complete it again. You are not simulating a user — you are checking that the words spoken match what is on screen and that nothing important is silent.
- Zoom to 200% and to 400%. Reflow, not horizontal scrolling. This one finds layout assumptions nothing else does.
- Turn on reduced motion. Everything still works, nothing important was only communicated by an animation.
Four passes, about twenty minutes for a typical journey, and they find the class of problem the scan structurally cannot.
Testing with users
Section titled “Testing with users”The manual pass is a smoke test performed by people who are not the users in question. It does not replace testing with people who actually use assistive technology daily, and no amount of tooling does.
If that is not currently possible, say so rather than implying coverage. “We scan every story and do a keyboard and screen-reader pass; we have not tested with users of assistive technology” is an honest and actionable position. A green dashboard implying more than that is not.
Practically, this is usability testing with participants who use assistive technology — same method, same five participants, same tasks. It is not a separate discipline requiring a separate budget, and treating it as one is how it stays permanently unscheduled.
Where it connects
Section titled “Where it connects”- axe is the scanner.
- Interaction tests are where a component’s announcements are asserted.
- Journey tests run the scan in composition, where a different class of violation lives.
- Example mapping is where the announcement requirements get written down as rules in the first place.