What is ARIA (Accessible Rich Internet Applications)?

ARIA (Accessible Rich Internet Applications), or WAI-ARIA, is a set of HTML attributes, roles, states, and properties that convey the meaning and state of dynamic, custom web components to assistive technologies like screen readers when native HTML semantics are not enough.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

Native HTML elements (button, input, nav) come with built-in accessibility semantics. But modern apps build custom widgets (tabs, modals, comboboxes, live-updating regions) where the markup does not inherently convey what the component is or its state. ARIA fills that gap: roles describe what an element is (role="tab"), states and properties describe its condition (aria-selected="true", aria-expanded, aria-hidden, aria-live for dynamic updates), and labels provide accessible names (aria-label, aria-labelledby).

A crucial principle is the "first rule of ARIA": do not use ARIA if a native HTML element can do the job, because native semantics are more reliable and ARIA used incorrectly can make accessibility worse than none at all. ARIA does not change behavior or appearance; it only changes the accessibility information exposed to assistive tech, so it must accurately match the actual visual state and be kept in sync as the component changes.

For QA, testing ARIA means verifying roles and states are correct and updated, that custom widgets are operable and announced properly with a screen reader and keyboard, and that ARIA is not misused. Automated tools catch some ARIA errors (invalid roles, missing names), but confirming a component is genuinely usable requires manual assistive-technology testing.

WHY IT MATTERS

Why interviewers ask about this.

ARIA is core to accessibility testing interviews. Knowing what ARIA does (roles, states, labels for custom widgets), the first rule of ARIA (prefer native HTML), and that correct ARIA must be verified with a screen reader, not just a scanner, shows credible, hands-on accessibility knowledge.

EXAMPLE

Example scenario.

A custom dropdown built from divs is invisible to screen readers. Adding correct ARIA, role="combobox", aria-expanded reflecting open/closed state, and aria-activedescendant for the highlighted option, plus keyboard support, makes it announce and operate correctly. QA verifies with a screen reader that the state changes are actually announced, not just present in the markup.

TIP

Interview tip.

Define ARIA as roles, states, and properties that expose custom/dynamic UI to assistive technologies when native HTML is insufficient. Cite the first rule of ARIA (prefer native HTML), note ARIA changes only exposed semantics (so it must match the real state), and stress verifying it with a screen reader, not just automated checks.

FAQ

Frequently asked questions.

What is the first rule of ARIA?

The first rule of ARIA is: if a native HTML element or attribute can provide the semantics and behavior you need, use it instead of ARIA. Native elements are more reliable and come with built-in behavior, whereas incorrect ARIA can make a component less accessible than using none at all.

How do you test ARIA?

Verify roles, states, and properties are correct and stay in sync with the visual state, then confirm with a screen reader and keyboard that custom widgets are announced and operable as intended. Automated tools catch some issues (invalid roles, missing accessible names), but genuine usability requires manual assistive-technology testing.