Accessibility
Accessibility should start before development
Fixing accessibility at the end is always more expensive. Most barriers originate in design decisions, not code.
This article is an editorial structure. Final content will be published by the editorial team.
What is the problem?
When accessibility only appears in a final audit, the team receives a list of fixes that collides with decisions already shipped — and the cost of change is at its highest.
What to decide before development
- Contrast and legibility when defining colour tokens.
- Heading hierarchy and semantic structure in wireframes.
- Focus order and keyboard navigation in flows.
- Clear error messages, bound to the right field.
- Alternatives for visual-only or audio-only content.
How to build it into the process
The most effective approach is to treat accessibility as per-component acceptance criteria inside the Design System, rather than a separate end-of-project task.
Trade-offs
It demands more rigour up front and some cross-team training. In return it reduces rework, legal risk and dependence on repeated external audits.
What should happen next
Assess critical flows with assistive technology users and define acceptance criteria for your most used components.
Key takeaway
Contrast, hierarchy, focus order, language and error states are design decisions — and they drive most of the compliance outcome.
Topics
- Accessibility
- UX
- Design System
Related service
Want to assess your product's accessibility?
NEWSLETTER
Digital product thinking, without the noise.
Get new articles on UX, product, systems and accessibility.