Accessibility as Process
Accessibility is not a one-time audit — it is a continuous practice embedded in every design, development, and testing phase of a project.
A single accessibility audit fixes the issues found on that day. A process embeds accessibility into every decision, so problems are caught before they are built — not after.
Why audits alone fail
An audit at the end of a project reveals failures after the fact. Those failures are expensive to fix — the structural decisions that caused them are already baked in. Changing a heading hierarchy, replacing <div> buttons, or redesigning a colour palette after implementation takes far more effort than making the correct decision at the start. The audit model treats accessibility as a final check rather than a continuous property of the system.
Design phase
Accessibility decisions made in design prevent the largest class of failures. Define your contrast-checked colour palette in the design system. Specify accessible text sizes and spacing. Annotate components with their heading levels, ARIA roles, keyboard behaviour, and focus states. Write alt text for every image in the design handoff. These annotations become acceptance criteria, not afterthoughts.
Development phase
During development, use semantic HTML by default. Run an automated accessibility checker — axe, Lighthouse, or a CI integration — on every pull request. Automated checks catch approximately 30–40% of WCAG failures. They are not sufficient alone, but they catch the mechanical errors — missing alt attributes, duplicate IDs, invalid ARIA usage — that would otherwise reach production.
Testing phase
Manual testing covers what automation cannot: keyboard-only navigation, screen reader interaction, logical reading order, and cognitive usability. Test with real assistive technologies — VoiceOver on macOS/iOS, NVDA on Windows, TalkBack on Android. Include users with disabilities in usability testing where possible. Their experience of the interface surfaces failures that no automated tool will catch.
The iterative commitment
Accessibility degrades over time when it is not maintained. New components, new content types, and new design patterns all introduce new failure points. Accessibility must be part of every sprint review, every design critique, and every code review. The question “is this accessible?” should be as automatic as “does this work on mobile?”
The takeaway
Build accessibility into your process at every phase. Use design annotations, automated checks, manual keyboard testing, and screen reader verification as standard practice — not as a response to a complaint or an audit. The goal is an interface that works for everyone from the first commit, not one that is retrofitted after the fact.