frontend · medium

ARIA

Accessible Rich Internet Applications — attributes that describe roles and states for assistive tech.

Where you see it

You reach for ARIA when native HTML cannot express a widget’s role, name, or state — custom tabs, menus, dialogs, live regions, and complex forms. Prefer semantic elements first (`button`, `nav`, `dialog`); ARIA fills gaps and must stay in sync with keyboard behavior and visible UI.

Why it matters

Accessibility is a hiring and product requirement, not a nice-to-have. Teams that misuse ARIA create worse experiences than teams that use plain HTML. Being able to explain “no ARIA is better than bad ARIA,” name computation, and roles/states shows you can ship inclusive UI and survive accessibility audits.

Interview angle

Interviewers often ask when to use `aria-label` vs visible text, how `aria-live` works, or how you’d make a custom dropdown accessible. Walk through focus management + roles + keyboard support as one package, not attributes sprinkled on a div.

Tags: html