Accessibility gets treated as a nice-to-have add-on, usually scheduled for “later,” even though the practical and legal reasons to build it in from the start keep getting stronger.
It’s not just about screen readers
Accessible design also helps users with motor impairments who navigate by keyboard, users with low vision who need sufficient color contrast, and users with cognitive differences who benefit from clear, consistent layouts. The audience affected is larger and more varied than the “screen reader users” shorthand suggests.
The basics that cover most of the gap
- Semantic HTML — real headings, real buttons, real form labels — rather than divs styled to look like interactive elements
- Keyboard navigability for every interactive element, with a visible focus state
- Color contrast that meets WCAG minimums, checked, not assumed
- Alt text on meaningful images, and empty alt attributes on purely decorative ones
Why retrofitting it is harder than building it in
Accessibility issues baked into the component structure — a custom dropdown with no keyboard support, a modal that traps focus incorrectly — are far more expensive to fix after the fact than to build correctly the first time, because fixing them properly often means rebuilding the component, not patching it.
The legal and business reality
Accessibility lawsuits against inaccessible websites have become common in several markets, and an accessible site is also simply a better-built site — the same semantic structure and clear navigation that helps assistive technology also helps every other user and search engine crawlers.