Web accessibility means building pages that people using screen readers, keyboard-only navigation, or other assistive technology can actually use. It isn't a separate feature you bolt on at the end — the choices you make in your HTML either support it by default or actively work against it. ARIA (Accessible Rich Internet Applications) attributes are a toolkit for filling in the gaps, but they're meant to supplement semantic HTML, not replace it.

Semantic HTML Is the First Line of Defense

A surprising amount of accessibility comes for free just from using the right native elements. A <button> is automatically keyboard-focusable, triggers on both Enter and Space, and is announced as "button" by screen readers — all with zero extra code. Recreate that same button out of a styled <div> with a click handler, and none of that comes for free; you'd have to manually add tabindex, keyboard event handlers, and ARIA roles just to match what <button> already does.

<!-- Accessible by default -->
<button>Submit</button>

<!-- Needs extra work to reach the same level -->
<div onclick="submitForm()">Submit</div>

Both can look identical with CSS, but only the first one is usable without a mouse. The golden rule: before reaching for ARIA, check whether a native semantic element already solves the problem.

When ARIA Attributes Actually Help

ARIA earns its place when there's no native element for what you're building, or when extra context genuinely helps. A common, legitimate example is labeling an icon-only button:

<button aria-label="Close dialog">
  <svg><!-- an X icon, no visible text --></svg>
</button>

Visually this button just shows an X icon, which is fine for sighted users who recognize the symbol — but a screen reader has nothing to announce without aria-label, since there's no actual text inside the button. With it, the screen reader announces "Close dialog, button" instead of just "button."

role is another common ARIA attribute, used to tell assistive technology what a custom-built widget behaves like — for example role="alert" on a dynamically-inserted error message tells screen readers to announce it immediately, which a plain <div> wouldn't do on its own.

The First Rule of ARIA

The official accessibility guidance has a memorable rule: "No ARIA is better than bad ARIA." Adding the wrong role or an incorrect attribute can actively make a page less accessible than using no ARIA at all, because it overrides the correct behavior a native element would otherwise provide. If you're tempted to add role="button" to a div, stop and ask whether you could just use a real <button> instead — in almost every case, you can.

A Quick Accessibility Checklist

Use real semantic elements wherever one exists for what you're building. Give every image meaningful alt text. Label every form input. Make sure interactive elements are reachable and operable with the keyboard alone (try tabbing through your own page). Only reach for ARIA to fill a genuine gap, and test it with a real screen reader if you can — the behavior often differs from what you'd expect just reading the attribute name.