ARIA Basics: When to Use It and When Not To

ARIA stands for Accessible Rich Internet Applications. It's a set of attributes that give assistive technology extra information about elements, especially custom components that plain HTML can't describe. It's powerful, and easy to misuse. The guiding advice is that no ARIA is better than bad ARIA.

The first rule

If a native HTML element already does what you need, use it instead of adding ARIA. A real button already has the right role, keyboard behavior, and focus handling. A div with role="button" needs you to add all of that yourself, and it's easy to get wrong.

So:

• Use button for actions and a for links
• Use nav, main, header, footer for landmarks. See skip links and landmarks
• Use label for form fields. See accessible forms
• Use real lists, tables, and headings

What ARIA can do

ARIA can:

• Name things: aria-label and aria-labeledby give an accessible name
• Describe things: aria-describedby connects extra hint or error text to a field
• Expose state: aria-expanded, aria-pressed, aria-selected, and aria-current tell users whether a menu is open, a button is toggled, or which page is current
• Define roles for custom widgets that lack a native equivalent
• Hide things: aria-hidden="true" removes decorative content from the accessibility tree
• Announce updates: live regions can tell screen reader users about changes such as a "Message sent" status

Common examples that work well

An icon-only button: give it a name, for example aria-label="Open menu".

A menu toggle: a real button with aria-expanded set to true or false and aria-controls pointing to the menu.

The current page in navigation: aria-current="page" on the matching link.

A form error: link the message to the field with aria-describedby, and mark the field invalid.

What ARIA does not do

• It doesn't add keyboard behavior. If you give something a button role, you still must make it focusable and respond to Enter and Space
• It doesn't change appearance
• It doesn't fix poor structure
• It doesn't override native semantics well, so avoid contradicting them

Common mistakes

• Redundant ARIA, such as role="button" on a button
• aria-hidden="true" on focusable elements, which hides something keyboard users can still reach
• Labels that don't match visible text, causing trouble for voice-control users
• Invalid or misspelled attributes
• Using aria-label on elements where it isn't supported
• Treating ARIA as a quick accessibility fix to bolt on at the end

Where to learn more

The W3C's ARIA Authoring Practices Guide shows recommended patterns for tabs, dialogs, menus, and more. Follow tested patterns rather than inventing your own.

Test it

Check with a keyboard and a screen reader. See keyboard navigation and how to test with a screen reader. Also see screen readers explained.

The bottom line

Prefer native HTML, and add ARIA only to fill gaps. A few well-chosen attributes help. A pile of unnecessary ones hurts.