Use ARIA to explain behavior, not replace it

By Gyata Tabiri · Revised October 30, 2026

When a control changes state, the change needs to make sense beyond its appearance. I want the name, behavior, and exposed state to agree, so the interface can be understood through different ways of using it.

Start with native HTML

A native button already has useful keyboard behavior. Giving a div role="button" does not supply that behavior. Use a native control where it fits, then add ARIA when an accessible name, relationship, or changing state needs to be expressed.

Keep state accurate

A disclosure button can use aria-expanded to describe whether its content is open. The value needs to change with the visible state. A label or attribute that contradicts the interface can be more confusing than an absent decoration.

Use dynamic announcements with care

A status message can help communicate an update without moving focus. Choose the announcement behavior for the importance and timing of the change, and test it. Repeated or unnecessary announcements can interrupt the person trying to finish the task.

Test behavior as well as attributes

Inspect accessible names, follow focus, and use the keyboard and appropriate assistive technology. ARIA does not fix missing interaction, poor wording, or an unusable reading order. A smaller, well-understood control is often easier to verify and maintain than a complicated custom substitute.

The team gains a control whose behavior can be inspected and tested, rather than one that only looks complete. That is a useful standard for accepting a custom interaction into a shared interface.

Accessible form decisions · Discuss a role or project

Reference: ARIA Authoring Practices.