What can be tested automatically for accessibility, what cannot, and what is the architectural dimension?
Show the full answer Hide the answer
What can be tested automatically
A meaningful but limited share — commonly cited as around a third of accessibility criteria:
- Missing alternative text, form labels and accessible names.
- Colour contrast ratios.
- Heading structure and landmark regions.
- Keyboard focusability and visible focus indicators.
- Duplicate or missing identifiers, invalid ARIA usage.
- Language attributes.
These belong in the pipeline, blocking, because they are deterministic and cheap.
What cannot be tested automatically
- Whether alternative text is meaningful, as opposed to present.
- Whether the keyboard order matches the visual and logical order.
- Whether a screen reader experience is coherent, which requires using one.
- Whether error messages are understandable and associated correctly.
- Whether complex interactions — drag and drop, canvas editing, live regions — work with assistive technology.
- Whether the experience is usable, which is a different question from whether it is compliant.
These require manual testing and, ideally, testing with people who use assistive technology.
The architectural dimension
Accessibility is largely determined by the component library. If the design system's components are accessible — correct semantics, keyboard behaviour, focus management, announcements — then most product code inherits it, and the automated checks mostly verify that teams used the components.
If the components are not accessible, every team reimplements the problem and no amount of per-feature testing scales.
This makes it a platform investment rather than a per-team testing burden — which is the same reasoning that makes curated base images and service templates worth building.
For a canvas-heavy product
The hardest cases are the ones a component library cannot solve: a visual editing surface has no natural semantic structure. These need designed alternatives — keyboard-operable equivalents, structured navigation of the document model, announcements of state changes — which are architectural decisions about the editing model rather than testing decisions.
Testing finds what is broken; the component library and the interaction model determine what is possible.