Accessibility is a build decision, not a launch checklist
The cheapest time to make a site accessible is while it is being designed. Here is how we build WCAG 2.2 conformance into the work rather than auditing it in at the end.
- Published
- Author
- Pixel Forge Technologies · Engineering team
- Reading time
- 6 min read
- Topic
- Engineering
Retrofitting accessibility is expensive because it means revisiting decisions that were already made: colour pairs, component structure, interaction patterns. Making those decisions correctly the first time costs almost nothing.
Decide it in the design system
- Every text colour is paired with the backgrounds it may sit on, and each pair meets WCAG contrast ratios. Check this once when the tokens are defined.
- Interactive elements have a visible focus state that is designed, not left to the browser default.
- Tap targets are at least 24 by 24 CSS pixels, with 44 preferred on touch surfaces.
- Motion is treated as an enhancement. Anything that moves respects the reduced-motion preference.
Build it in the components
Use native HTML elements before reaching for ARIA. A button is a button element, a link is an anchor, and a form field has a label element. Custom components such as accordions and dialogs are built once, tested with a keyboard and a screen reader, and reused.
Test it continuously
Automated tools catch perhaps a third of real issues. Tab through every page. Turn on a screen reader for the critical journeys. Test the forms with errors present. Do this during the build, not the week before launch.
Why it matters commercially
Accessible sites are usable by more people, index better because their structure is semantic, and are less fragile because they rely on standards rather than clever workarounds. The overlap between accessibility, performance and SEO work is large enough that we treat them as one discipline.
Dealing with this on your own product?
Talk to us