Accessibility is a product decision, not a final check
An audit at the end can catch broken markup. It cannot fix a journey that was never designed for the person using it.
Filed under Accessible design / a guidance note, kept current rather than dated
01Most barriers are built in early
An accessibility audit will find missing labels and broken focus order, and it should. But many barriers are created much earlier: in the choice of workflow, the amount of information a form demands, the vocabulary a service uses, and the assumptions it makes about attention, memory, confidence and devices.
If a journey expects someone to hold unfamiliar terms in their head across five steps and recover from errors without help, valid markup will not rescue it.
02Design the task before the interface
The stronger starting point is the task itself: what is this person trying to do, and what could make it hard for them today? That reframes the work from adding accessibility features to removing barriers.
- Can the task be split into short stages that make sense on their own?
- Is context available at the moment it is needed, not three screens earlier?
- Are errors explained in plain words, with a clear way back?
- Does everything still work with a keyboard, at 200 per cent zoom, and with motion reduced?
03Compliance is the floor
Standards such as WCAG give teams a shared baseline and a way to test what they shipped. We treat them as the floor. The ceiling is set by how well the product understands the people and pressures around the task.
That understanding has to sit inside product strategy, content and engineering from the first week. Bolting it on at the end costs more and helps less.
Working on something this note describes? Tell us about it.