Detailed explanation
ARIA stands for Accessible Rich Internet Applications. It is a specification for expressing accessibility semantics when HTML alone cannot adequately describe an interface. ARIA roles identify what an element is, while states and properties describe its condition, relationships, or purpose. Browsers expose this information through accessibility APIs, allowing assistive technologies such as screen readers to communicate controls more meaningfully. ARIA primarily changes accessibility information; it does not automatically change appearance or behaviour.
The first rule of ARIA is to prefer native semantic HTML whenever possible. A native <button> already provides button semantics, keyboard focusability, and standard activation behaviour. Adding role="button" to a <div> supplies the role but does not implement those behaviours. Developers must still handle focus, keyboard activation, and any disabled state correctly. Use ARIA to supplement native controls or implement genuinely custom widgets, such as tabs, when an appropriate native element is unavailable. Interviewers look for this distinction between describing behaviour and actually implementing it.
Common attributes include aria-label, which supplies an accessible name when suitable visible naming is unavailable; aria-labelledby, which references naming text; aria-expanded, which reports whether controlled content is expanded; and aria-controls, which identifies that content by ID. Prefer visible labels where possible, and ensure an accessible name includes the visible label. The role attribute assigns semantics, such as tab or dialog. aria-hidden="true" excludes an element and its descendants from the accessibility tree without visually hiding them; do not apply it to focusable controls or their ancestors.
In the supplied example, the button's aria-expanded value must change when the list opens or closes, and its hidden state must stay synchronised. However, role="menu" and role="menuitem" describe an application-style menu with specific keyboard and focus expectations, not an ordinary navigation list. For website navigation, a button revealing a list of links is usually more appropriate without those roles. ARIA menu roles alone do not make the list items keyboard-operable. Validate the implementation using keyboard navigation, accessibility-tree inspection, and screen-reader testing.
Key points to remember
- ARIA exposes roles, states, properties, and relationships to assistive technologies.
- Prefer native semantic HTML; ARIA does not supply keyboard behaviour or focus management.
- Keep dynamic ARIA states, such as aria-expanded, synchronised with the interface.
- Use accessible names carefully, preferably derived from visible labels.
- Reserve menu roles for application-style menus, not ordinary website navigation.
Common mistakes candidates make
- Replacing a native button with a div and assuming role="button" makes it fully accessible.
- Adding menu roles to navigation links without implementing the required keyboard and focus behaviour.
- Using aria-hidden on focusable content or leaving ARIA states inconsistent with what is displayed.
Likely follow-up questions
What is the difference between aria-label and aria-labelledby?
aria-label provides the accessible name directly as a string, while aria-labelledby references one or more elements containing naming text. Prefer referencing suitable visible text; when both attributes validly apply, aria-labelledby takes precedence.
How does aria-hidden differ from the HTML hidden attribute?
aria-hidden="true" removes content from the accessibility tree but does not visually hide it or prevent keyboard focus. The ordinary HTML hidden state normally hides content from rendering and assistive technologies.
What else must you implement for a custom ARIA menu?
You must implement the expected focus management and keyboard interactions, including arrow-key navigation and appropriate Escape behaviour. You must also provide accessible names and keep expanded states and visibility consistent with the menu's actual state.
Interview tip: Start with the native-HTML-first rule, explain that ARIA supplies semantics rather than behaviour, and demonstrate this using the expandable navigation example.