ARIA States and Properties

ARIA states and properties communicate accessibility semantics and dynamic UI state to assistive technologies when native HTML semantics do not fully describe an interface. They are expressed through `aria-*` attributes and should complement, not replace, appropriate native HTML.

ARIA attributes add information to the accessibility tree, such as whether a disclosure is expanded, whether a control is checked, or which element provides its accessible name. This information can help screen readers and other assistive technologies interpret custom or dynamic interfaces.

States generally describe a value that can change during interaction, such as `aria-expanded`, `aria-checked`, `aria-selected`, and `aria-disabled`. Properties generally describe relationships or characteristics, such as `aria-label`, `aria-describedby`, `aria-controls`, and `aria-haspopup`. In practice, developers often refer to both collectively as ARIA attributes.

ARIA does not automatically implement keyboard interaction, focus management, or visual behavior. For example, setting `aria-expanded="true"` does not make an element expandable; JavaScript and appropriate interaction handling must keep the attribute synchronized with the actual UI state.

Prefer native HTML semantics whenever they provide the required behavior and accessibility information. A native `<button>` already has button semantics and keyboard behavior, whereas a generic element given `role="button"` may require additional keyboard and focus handling. ARIA is most useful when native HTML cannot adequately represent the interface pattern.

Dynamic states must remain synchronized with what users see and what the application actually does. If a disclosure is visibly open, for example, its corresponding `aria-expanded` value should communicate that same state to assistive technologies.

Key points

• Use ARIA when native HTML cannot adequately express the required semantics.
• States such as `aria-expanded` and `aria-checked` communicate dynamic UI conditions.
• Properties such as `aria-label`, `aria-describedby`, and `aria-controls` describe names, relationships, or characteristics.
• ARIA does not provide interaction behavior, keyboard handling, or focus management by itself.
• Keep ARIA state synchronized with the actual visual and functional state of the UI.
• Prefer native HTML controls over recreating their semantics with ARIA.

Interview questions

What are ARIA states and properties, and why are they used?

ARIA states and properties are `aria-*` attributes that add accessibility information to elements. They can describe things such as an element's accessible name, relationships to other elements, or dynamic state. They are particularly useful for custom widgets and UI patterns that native HTML does not fully express. They should generally supplement native HTML rather than replace it.

What is the difference between an ARIA state and an ARIA property?

A state usually represents a condition that can change as the user interacts with a component, such as expanded, checked, or selected. A property generally describes a characteristic or relationship, such as an accessible label or the element controlled by another element. The distinction is useful conceptually, although developers commonly refer to both as ARIA attributes. The important point is to expose the correct semantic information and keep dynamic values synchronized.

Does `aria-expanded="true"` make a menu or disclosure functional?

No. It communicates the expanded state to assistive technologies, but it does not implement the interaction itself. The application still needs to handle activation, update the actual content visibility, and manage focus or keyboard behavior as required by the widget pattern. The ARIA value should always match the component's real state.

Why is a native `<button>` usually preferable to a `<div role="button">`?

A native button already exposes appropriate semantics and comes with expected browser interaction behavior, including keyboard activation. A generic element with `role="button"` mainly changes its semantic exposure; the developer still has to implement appropriate focusability and keyboard interaction. Using native HTML therefore reduces the amount of accessibility behavior that must be recreated and maintained.

How should you keep ARIA state synchronized in a component?

The component should have a clear source of truth for its actual UI state and derive the relevant ARIA attributes from that state. When the state changes, the DOM, visual presentation, and accessibility semantics should update together rather than through unrelated code paths. For example, an expanded state can drive both panel visibility and `aria-expanded`. Automated accessibility checks and keyboard-focused testing can then help detect mismatches.