Web Accessibility in Practice: What Client Projects Actually Need
Accessibility gets treated as an audit checklist at the end of a project. The teams that ship genuinely accessible sites build it in from the first component.
Tanjil Ahmed
Lead Software Engineer · Notionhive
Accessibility retrofitted at the end of a project after a compliance audit is expensive, incomplete, and usually produces exactly enough compliance to pass the audit without producing a site that's actually usable with a screen reader. The projects that get this right treat it as a component-level default, not a final pass.
- Semantic HTML first — a `<button>` with correct ARIA is still worse than a native `<button>` that needed none.
- Keyboard navigation tested on every interactive component, not just tabbed through once at the end.
- Color contrast checked against the actual design tokens in the build system, not spot-checked on a few screens.
- Screen reader testing (VoiceOver or NVDA) on the actual critical user flows — checkout, sign-up — not just the homepage.
The cost difference between building accessibly from the start and retrofitting it later isn't small — it's roughly the difference between a design system decision and a full audit-driven rewrite of every interactive component in the app.
Accessibility built into the component library costs a design decision. Accessibility bolted on after launch costs a rewrite.