Should you reach for ARIA, or is native HTML usually the better answer?

Published Read 3 min read

On this page

Reach for native HTML first, and use ARIA only to fill genuine gaps that native elements cannot cover. Native elements arrive with built-in accessibility semantics, keyboard behavior, and focus handling that you would otherwise have to rebuild by hand, so the rule, often called the first rule of ARIA, is to use the native control whenever one exists and add ARIA sparingly. This is not a stylistic preference; misused ARIA can make an interface less accessible than no ARIA at all, which is why the field’s standing advice is that no ARIA is better than bad ARIA.

The reasoning is that ARIA only changes what assistive technology announces; it does not add any behavior. A <button> is focusable, fires on both Enter and Space, sits in the tab order, and announces as a button, all for free. A <div role="button"> announces as a button and tells a screen reader nothing more, but it is not focusable, does not respond to keyboard activation, and does not trigger on Space or Enter unless you write every bit of that yourself, correctly, including the tabindex and the key handlers. ARIA is a promise about semantics that you, the developer, are then responsible for keeping in behavior. Native elements keep that promise automatically.

The standing of “no ARIA is better than bad ARIA” is backed by hard data: accessibility surveys consistently find that pages using ARIA average more detectable errors than pages without it, because the most common ARIA is applied incorrectly, overriding correct native semantics, pointing at IDs that do not exist, or claiming states the code never updates. A wrong role actively lies to assistive technology, sending users down a path that does not match reality, which is worse than the honest silence of an unstyled but semantically plain element.

A concrete example: a team builds a custom dropdown out of <div>s and reaches for ARIA to make it accessible, adding role="listbox", role="option", aria-selected, and aria-expanded. Done perfectly with full keyboard support it can work, but it is a large, fragile surface to get exactly right, and done partially it announces a listbox that arrow keys do not actually drive. The native <select> element gives all of that, the role, the options, the selected state, keyboard navigation, and the platform’s own picker on mobile, with a single tag and zero ARIA. Native is not the fallback here; it is the better-engineered answer.

There is one real limit: ARIA is genuinely necessary where HTML has no native equivalent. There is no native tab interface, no native tooltip with reliable semantics, no native “this region updated” announcement, so role="tablist", aria-describedby, and aria-live regions are exactly the right tools for those gaps. Even then the discipline holds: prefer any native element that does part of the job (use a real <button> inside your tab strip rather than a div with role="tab" bolted onto a clickable box), and add ARIA only for the semantics native HTML cannot express. ARIA fills holes; it should not replace floors that already exist.

When you build a component, start by asking whether a native element already does this, and use it if one does: <button>, <a>, <select>, <input type="checkbox">, <dialog>, <details>. Reach for ARIA only where you have confirmed no native option fits, and when you do, commit to implementing every behavior the role implies and testing it with an actual screen reader. If you are adding a role to an element that has a native equivalent one tag away, you are working against the grain, and the accessible path is almost always the native one.

Related posts:

  1. How deep can a menu nest before wayfinding falls apart? A menu can nest only as deep as users can still tell where they are and how to get back, and in practice that ceiling is shallow. The honest line......
  2. How do you handle a data-heavy table on a small screen without losing the data? A dense table survives a small screen through one of four deliberate patterns, each trading completeness against readability: keep it whole and let it scroll horizontally, restructure each row into......
  3. When is a flat information architecture better than a deep hierarchy? A flat architecture is better when the site is small enough that most content sits a click or two away and findability matters more than careful categorization, while a deep......
  4. When is a full-width section right vs a contained, centered one? Choose full width when the content is meant to envelop the viewer and a contained, centered width when the content is meant to be read. That single distinction settles most......
  5. How do you keep a hero readable from phone to ultrawide? A hero stays readable across every width when you decouple the text's legibility from the background image's behavior. The mechanism is that an image and the type laid over it......
  6. Should you build a color system from one hue or several? Start from one hue and expand only when the product proves it needs more. A single-hue system, built from one color stretched across tints, shades, and a neutral ramp, reads......
  7. How much whitespace is too much before a layout feels empty instead of intentional? Whitespace becomes too much the moment it stops doing a job. The tipping point is not a pixel value, a margin token, or a percentage of the viewport. It is......
  8. When does a second typeface add hierarchy vs just add noise? A second typeface earns its place only when it draws a clear functional line, the most common one being headings against body, and it becomes noise the moment it decorates......
  9. Should dark mode be a true inversion, or designed separately? Dark mode should be designed separately, as its own deliberate theme, not produced by inverting the light one. A literal flip is tempting because it looks like a single switch,......
  10. Why can shipping one more feature make a product feel worse to use? Shipping one more feature can make a product feel worse because every feature adds interface, choices, and surface area, and that accumulation crowds the core even when the new feature......
  11. At what point does a strong hero flatten everything below it? A hero flattens the page the moment the section directly below it stops earning attention on its own. That is the line, and it is a behavioral test, not a......
  12. How do you design for the user who lands mid-flow from a deep link? You design for the deep-linked user by treating every screen as a possible front door: orient them on arrival, supply or recover the context the earlier steps would have given,......
  13. Should navigation be sticky, or does that depend on page length? The call turns on page length and how often users need to re-navigate, and it resolves cleanly: make the nav sticky on long, multi-section pages and let it scroll away......

Leave a comment

Your email address will not be published. Required fields are marked *