Glossary / ARIA

ARIA

ARIA (Accessible Rich Internet Applications) is a set of roles, states, and properties that adds accessibility semantics to web content, especially custom widgets and dynamic interfaces. ARIA informs the accessibility tree but does not add visual styling, keyboard behavior, focus handling, validation, or event logic. The central engineering rule is “No ARIA is better than bad ARIA”: use native HTML when it provides the needed semantics, and add only the ARIA necessary to expose custom meaning and state.

What to know

• Roles describe what an element is (role="tab", role="status"). Properties describe relationships or characteristics (aria-label, aria-controls). States describe dynamic conditions (aria-expanded, aria-checked, aria-selected).
• ARIA roles can replace an element’s native role; they cannot generally be used to create invalid role combinations or override all native behavior.
• Accessible name computation has precedence rules; aria-labelledby and aria-label can override visible text. Keep spoken names aligned with visible labels, particularly for voice control (WCAG 2.5.3 Label in Name).
• aria-hidden="true" removes an element and descendants from the accessibility tree; never put it on a focusable control or an ancestor containing focusable descendants.
• aria-live, role="status", and role="alert" can expose dynamic updates. Choose politeness carefully; excessive or assertive announcements interrupt users.
• aria-describedby provides supplemental description; aria-labelledby provides a name. aria-controls expresses a relationship but does not implement it.
• ARIA in HTML defines allowed usage; APG documents common keyboard interaction patterns.

Practical method

First ask whether a native element solves the problem. If not, select a well-supported APG pattern, implement its complete keyboard model and state transitions, then add the appropriate semantics. Keep DOM state and ARIA state synchronized. Test name, role, value/state and keyboard behavior with accessibility-tree inspection and target assistive technologies. Avoid redundant or contradictory attributes such as role="button" on <button>, manually maintained state that disagrees with visible UI, and blanket aria-label additions.

Interview questions

1. Does ARIA make an element interactive? No. It exposes semantics; JavaScript and native behavior must supply interaction and keyboard support.
2. What is the first rule of ARIA? Prefer native HTML when it provides the required semantics and behavior.
3. Difference between name and description? The name identifies a control; the description adds supporting instructions or context.
4. What does aria-expanded do? It exposes whether a disclosure control or widget is expanded; the application must still show/hide the controlled content and synchronize the state.
5. Why can aria-hidden be dangerous? It can hide focused or focusable descendants from assistive technology, creating an inaccessible mismatch.

References

• WAI-ARIA 1.2
• WAI-ARIA Authoring Practices Guide
• ARIA in HTML