ARIA - Accessible Rich Internet Applications

What ARIA Can Do

• Add roles to define what an element is
  (e.g., role="dialog", role="tablist")
• Add states and properties 
  (e.g., aria-expanded, aria-hidden)
• Provide labels and descriptions 
  (aria-label, aria-labelledby, aria-describedby)

General Practices for ARIA

Use native HTML first. 

Only use ARIA when there’s no accessible native element.

Always add keyboard support. 

ARIA only describes elements—it doesn’t make them interactive.

Keep ARIA states updated. 

For example, when a dropdown opens, set aria-expanded="true".

Use appropriate roles. 

Don’t guess—check the WAI-ARIA specification.

Label interactive elements. 

Use aria-label, aria-labelledby, or native <label> elements.

Test with a screen reader. 

ARIA can behave differently across devices and browsers.

Avoid These Common Mistakes

Using ARIA when HTML already works

Example: <div role="button"> instead of <button>
→ This removes native keyboard and screen reader behavior.

Incorrect roles

Using role="navigation" on non-navigation content will confuse users, or using a role="menu" to indicate a navigation menu instead of an application menu.

Forgetting focus management

Dialogs and menus need focus traps and to return focus when closed. Conversely, ensure there are no focus traps in main page content.