ARIA (Accessible Rich Internet Applications)

Accessibilityadvanced

// Definition

A W3C specification that adds roles, states, and properties to HTML elements to expose semantics to assistive technologies when native HTML alone is insufficient. The first rule of ARIA is: do not use ARIA — prefer native HTML elements (button, input, nav) that carry the correct semantics implicitly. Incorrect ARIA can make an interface less accessible than no ARIA at all. QA testers check that ARIA roles match the component's actual behaviour, required states (aria-expanded, aria-selected, aria-checked) update dynamically, and aria-label or aria-labelledby provides meaningful names for elements that lack visible text.

// Why it matters

ARIA adds roles, states, and properties so assistive tech can understand custom widgets that native HTML can't express. The QA twist: the first rule of ARIA is don't use ARIA if a native element works. Bad ARIA is worse than none — it actively lies to screen-reader users. So testing is as much "is this ARIA wrong?" as "is it present?".

// How to test

// Verify roles/states reflect actual UI state
cy.get('[data-cy=menu-toggle]').should('have.attr', 'aria-expanded', 'false')
cy.get('[data-cy=menu-toggle]').click()
cy.get('[data-cy=menu-toggle]').should('have.attr', 'aria-expanded', 'true')
cy.get('[data-cy=menu]').should('have.attr', 'role', 'menu')
// And confirm a real screen reader announces it (manual — axe can't hear)

// Common mistakes

  • Adding ARIA to elements that already have native semantics (redundant or conflicting)
  • aria-expanded/aria-checked that never updates when state changes
  • role without the keyboard interaction the role implies (a role=button div that ignores Enter/Space)

// Related terms