The First Rule: No ARIA Beats Bad ARIA

ARIA is a set of HTML attributes that tells assistive tech what an element is and does, when the markup alone cannot say it.

Here is the catch: ARIA only changes what is announced. It never adds clicks, focus, or keyboard support on its own.

The official first rule: if a native HTML element can do the job, use it instead of recreating it with ARIA.

A real button is focusable, fires on Enter and Space, and announces its role for free. You write none of that yourself.

A wrong role actively lies to users. Bad ARIA beats no ARIA only in harm: it can hide content or describe it incorrectly.

ARIA overrides native semantics. Slap role=presentation on a heading and screen readers stop treating it as a heading at all.

ARIA gives you exactly three kinds of information: a role (what it is), states, and properties. That is the whole toolkit.

Setting aria-hidden on an element hides it from screen readers, but it stays fully visible on screen. The two layers are separate.

Reach for ARIA when no native element fits, like a tablist or a custom slider. Then use it precisely and test it.

If you must build a custom widget, ARIA plus JavaScript go together. ARIA names it, JS supplies the focus and keyboard logic.

The best accessible page often has very little ARIA. Semantic HTML first, ARIA only to fill the gaps it leaves behind.

You need a clickable Save control. What is the most accessible choice?

You learned that ARIA describes, never behaves. Prefer native HTML, add ARIA only to fill real gaps, and test it every time. 🎯