• A component passed automated tests but remained inaccessible to screen readers due to an unnecessary ARIA role. • Removing the ARIA role restored native keyboard behavior, proving semantic HTML already provided the needed accessibility. • The experience highlighted that ARIA is easy to abuse when used as a shortcut instead of a supplement. • Developers should start with minimal markup, test with keyboard and NVDA, and only add ARIA when native elements fall short. • Automated audits can miss real-world interaction issues; hands‑on testing reveals hidden accessibility gaps. • The first rule of ARIA: use it only when native semantics cannot deliver the required functionality.
Article Summaries:
- Some time ago, I shipped a component that felt accessible by every measure I could test. Keyboard navigation worked. ARIA roles were correctly applied. Automated audits passed without a single complaint. And yet, a screen reader user couldn’t figure out how to trigger it. When I tested it myself with keyboard-only navigation and NVDA, I saw the same thing: the interaction simply didn’t behave the way I expected. Nothing on the checklist flagged an error. Technically, everything was “right.” But in practice, the component wasn’t predictable. Here’s a simplified version of the component that cau
Sources: