There is a dangerous misconception in modern web development that accessibility (a11y) is a checklist item to be addressed during the QA phase. The thinking goes: "We'll build the app first, then we'll add the ARIA labels and alt tags before launch."
This approach is fundamentally flawed. It treats accessibility as a cosmetic layer, rather than a structural imperative.
When accessibility is an afterthought, the result is almost always a fragile, "patchwork" interface.
You end up with div elements pretending to be buttons, requiring massive amounts of
JavaScript to handle keyboard events that a native button would have handled for free.
"If you find yourself manually adding tabindex='0' to a div, you have
likely made an architectural mistake, not a styling choice."
Semantic HTML is 90% of the Battle
The browser gives us an incredible amount of accessibility functionality out of the box. Headers
(h1-h6) create a navigable outline for screen readers. Buttons
(button) and links (a) are automatically focusable and triggerable via
keyboard.
The moment a developer decides to use a div with an onClick handler
instead of a button, they have opted out of the browser's built-in accessibility suite. They now
have to manually reimplement focus states, Enter key support, and Spacebar support.
Accessibility starts with the architecture of the DOM. It requires developers to ask "What is this element?" before they ask "What does this element look like?"
The Curb-Cut Effect
There is a phenomenon in urban planning called the "Curb-Cut Effect." When cities cut curbs to allow wheelchairs to move easily from sidewalk to street, they found that it also benefited parents with strollers, travelers with luggage, and cyclists.
The same is true for digital products.
- A high-contrast UI helps visually impaired users, but it also helps someone looking at their phone in bright sunlight.
- Clear focus states help users with motor impairments, but they also help power users who prefer to navigate quickly via keyboard shortcuts.
Designing for the margins improves the experience for the center.
Compliance vs. Usability
Finally, we must distinguish between compliance and usability.
It is possible to build a site that technically passes an automated accessibility audit (WCAG AA) but is still a nightmare to use with a screen reader. Automated tools can check if an image has an alt tag, but they cannot tell you if the alt tag description is helpful.
True accessibility requires empathy. It requires testing your product with a keyboard only. It requires listening to your site with a screen reader. It requires treating disabled users not as edge cases to be handled, but as core users to be served.