accessibility
ARIA
What is ARIA, and when should you use it?
ARIA (Accessible Rich Internet Applications) is a set of HTML attributes - roles, states and properties - that tell assistive technology what a custom element is and what it's doing when native HTML can't. It adds an accessibility layer on top of the markup: this div is a switch, it's currently on, this region is live. Powerful, and easy to get wrong.
Also known as: aria, wai-aria, aria roles, accessible rich internet applications
Prefer to watch?
Watch the recap 0:56
The demo
The same custom switch, built two ways. Flip ARIA on and off, toggle the switch, and read what a screen reader would announce each time.
What this demo shows (text version)
A custom on/off switch for "Notifications" is shown built two ways. Without ARIA, it's effectively a styled div: a screen reader announces something like "clickable" with no name and no idea of its on/off state - useless by ear. With ARIA (a switch role, an accessible name, and aria-checked kept in sync), the same widget announces "Notifications, switch, on" or "off", so it's fully usable. Toggling the switch updates the announced state.
ARIA adds the meaning native HTML couldn't here. But it only changes what's announced, not behaviour - you still wire up focus and keyboard yourself - and a native control would have been simpler and safer. The rules: prefer native HTML, use ARIA only for what it can't express, keep states accurate, and test with a real screen reader. Wrong ARIA is worse than none.
ARIA describes custom widgets to assistive tech - role (what it is), state (aria-checked, aria-expanded), and properties (aria-label, aria-describedby) - so a div-built control can announce like a real one. But the first rule of ARIA is don't use ARIA when native HTML will do, and the second is that ARIA changes only what's announced, never behaviour - you still wire up the keyboard yourself. Bad ARIA is worse than none.
Without ARIA, the custom toggle announced as a meaningless "clickable" with no name and no state - a screen-reader user couldn't tell what it was or whether it was on. Add role, name and aria-checked and it announced "Notifications, switch, on" - suddenly usable by ear. ARIA didn't change a pixel; it changed what assistive tech was told.
ARIA comes in three parts: roles say what an element is (switch, tab, dialog, alert), states say what's happening now and change (aria-checked, aria-expanded, aria-selected), and properties describe it (aria-label, aria-describedby, aria-required). Together they let assistive tech announce a custom widget as if it were a native control.
But ARIA only affects the accessibility layer - what's announced - never the behaviour. role="button" on a div makes it sound like a button; it doesn't make it focusable or respond to Enter and Space. You have to add tabindex and key handling yourself. ARIA describes; it does not implement. Forgetting this produces controls that announce correctly and then don't work.
So the rules: don't use ARIA when a native element will do (a real