Skip to content

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