ARIA (Accessible Rich Internet Applications) isn’t a quick fix for inaccessible code. It’s a specialized tool designed to enhance well-written HTML when building complex interfaces that HTML alone can’t handle.

I like to think of ARIA as the premium trim package on a car that’s already built well. It won’t fix a broken engine, but it does enhance the driver’s experience.

The W3C established five rules that make this clear:

  1. Don’t use ARIA. If native HTML works, use it. A real <button> beats a <div role="button"> every time because HTML includes built-in keyboard functionality, focus management, and browser support that you’d otherwise need to code yourself.
  2. Don’t change native semantics. Don’t strip meaning from elements that already have it. Putting role="presentation" on a heading removes its structure from screen readers, breaking navigation for assistive technology users.
  3. All interactive ARIA elements must be keyboard accessible. ARIA tells assistive tech what something is, but doesn’t make it work. If you create a custom dropdown with ARIA roles, you still need to write the JavaScript for keyboard controls.
  4. Don’t hide focusable elements. Never use aria-hidden="true" or role="presentation" on anything that can receive keyboard focus. This creates invisible traps that confuse keyboard users.
  5. Interactive elements need accessible names. Every button, link, and form field needs descriptive text that screen readers can announce. Use aria-label or aria-labelledby when HTML labels aren’t sufficient.

Notice the pattern? Each of these rules assumes you’re starting with proper HTML structure and semantic elements.

When not to use ARIA

You can skip ARIA if native HTML solves your problem. Don’t use it to patch issues within your HTML. ARIA fills gaps for complex components that HTML alone can’t handle (e.g. accordions, sliders, live updates to content). However, it only works when layered onto semantic, well-structured HTML.

Fix your HTML first. Then add ARIA where needed.

Don’t Miss Out

Get practical accessibility tips in your inbox every week.

Matt Litzinger headshot

Matt Litzinger

Matt is a web developer who builds tools that help organizations better engage with customers and improve website accessibility.