Interactive widgets & ARIA

When the control you need exists in HTML — a button, a checkbox, a <select>, a <details> — the browser gives you its role, its keyboard behaviour, its focus handling, and its states for free, and assistive technology already knows how to speak it. ARIA exists for the cases that HTML can’t express: a tab list, a tree, a custom combobox. It’s a vocabulary for telling assistive technology what a piece of UI is and what state it’s in. But ARIA only changes how something is announced — it adds no keyboard behaviour and no focus management on its own. That’s why the first rule of ARIA is the most important one: if a native HTML element does the job, use it instead of recreating it with ARIA.

Who this affects

  • Screen reader users hear a control’s role and state to know what it is and what it’ll do — “button”, “tab, selected”, “expanded”. A <div> wearing an onclick is announced as nothing at all; a toggle with no aria-pressed never tells them whether it’s on or off; an aria-labelledby pointing at a missing id leaves the control unnamed.
  • Keyboard users need to reach and operate every control with Tab, Enter, Space, and the arrow keys. ARIA adds none of that — a fake button built from a <div> isn’t focusable or operable until you wire it up by hand, and aria-hidden on focusable content drops them onto controls they can’t see.

Standards covered

The lessons in this category map custom-widget accessibility to the success criteria and laws that require it. The same fixes satisfy all of them at once.

WCAG 4.1.2 WCAG 1.3.1 WCAG 4.1.3 EN 301 549 Section 508 ADA

Lessons

Native first, ARIA second

These two lessons pair up: Accessible names makes sure each control says what it is, and ARIA & custom widgets makes sure it has the right role and state behind that name. No ARIA at all beats wrong ARIA — reach for a native element before you build a custom one.