Level A

32.7% of home pages have elements with missing accessible names

4.1.2 Name, Role, Value

In Plain Language

Every user interface component must have an accessible name (what it is called), role (what type of control it is), and value/state (its current condition). Native HTML elements like <button> and <input> get these automatically.

Custom widgets built with <div> or <span> elements need ARIA attributes to communicate this information to assistive technologies.

Why It Matters

  • Screen readers announce the name, role, and state of every interactive element -- a button without a name is announced as just "button", leaving users guessing what it does.
  • A <div> styled to look like a button has no semantic meaning to assistive technology -- it is invisible as an interactive control.
  • Custom widgets must communicate their role and state programmatically, not just visually. A toggle switch that looks "on" must also report its state to screen readers.
  • This failure affects 30.6% of home pages, making it one of the most widespread accessibility barriers.

Examples

Do: Native button with text
Don't: div used as button
Do: Icon button with aria-label
Don't: Icon button with no name

How to Fix It

  1. Use native HTML elements first. A <button> already has a button role, keyboard support, and gets its name from text content. Only use ARIA when native elements cannot achieve the pattern you need.
  2. Add role to custom widgets. If you must use a <div> or <span> as a control, add the appropriate ARIA role (e.g., role="button", role="switch") and implement all expected keyboard interactions.
  3. Give every interactive element an accessible name. Use visible text content, aria-label, aria-labelledby, or a <label> element. Icon-only controls always need an explicit label.
  4. Communicate state changes. Use ARIA attributes like aria-expanded, aria-pressed, aria-checked, and aria-selected to convey the current state of toggles, menus, and custom controls.
  5. Follow ARIA Authoring Practices. The W3C provides design patterns for common widgets (tabs, accordions, dialogs) with the expected roles, states, and keyboard behavior.