Why Web Accessibility (a11y) is an Engineer's Superpower

Accessibility (often abbreviated as a11y) is frequently treated as an afterthought in software engineering — a checklist item rushed right before an audit or compliance deadline.

During my work at SurveySparrow, I took ownership of our accessibility overhaul, taking our product accessibility score from less than 50% to over 85%.

What surprised me most wasn't just how rewarding it was to build inclusive software for assistive technology users; it was how radically accessibility improved the quality and maintainability of our codebase.

#1. The Real Reason a11y Makes Code Better

When developers build components using generic <div> tags with onClick handlers:

• You have to manually re-implement keyboard focus (tabIndex={0}).
• You have to listen for Enter and Space keydown events.
• You have to manage active and disabled states manually.
• Screen readers have zero context of what the element represents.

Using native semantic HTML gives you keyboard accessibility, state management, and assistive tech support for free:

<!-- Bad: 15 lines of custom logic needed to mimic a button -->
<div class="btn" role="button" tabindex="0" onclick="handleClick()">
  Submit
</div>

<!-- Good: Native semantics, fully accessible, works everywhere out of the box -->
<button type="submit" onclick="handleClick()">
  Submit
</button>

#2. The Golden Rule: First Rule of ARIA

The W3C First Rule of ARIA states:

"If you can use a native HTML element or attribute with the semantics and behavior you require already built-in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

Many developers sprinkle aria-label, aria-hidden, and role="region" across their HTML like fairy dust, hoping it satisfies automated checkers. In fact, incorrect ARIA attributes are worse than no ARIA at all because they send misleading cues to screen readers.

#3. Essential Audit Checklist

Here is the straightforward workflow we implemented to sustain an 85%+ score:

1. Color Contrast Ratios: Ensuring all text maintains at least a 4.5:1 contrast ratio against its background (3:1 for large text).
2. Keyboard Traps & Visible Focus: Every interactive control must have an unobscured :focus-visible ring. Never set outline: none without providing an accessible alternative.
3. Form Association: Never leave inputs without <label htmlFor="..."> tags. Placeholder text is not an accessible label.
4. Automated CI Checks: Integrate @axe-core/react or axe linter into your pull request pipeline to catch 40% of accessibility issues before code merges.

Accessible engineering is empathetic engineering. When you build for accessibility, you build a faster, cleaner, and universally usable web.