2 minute read

WCAG 4.1.2: Name, Role, Value (Level A)

When you click a button or select an option, you expect it to just work. For assistive technologies like screen readers, that “just works” experience relies on proper coding.

Name, Role, Value makes sure that every element on a webpage tells assistive technologies what it is, what it does, and how to interact with it.

Who this impacts

  • Screen reader users: They rely on accurate names, roles, and values to navigate websites effectively.
  • Keyboard-only users: Properly coded interactive elements ensure they can be accessed and used without frustration.
  • Developers and designers: This SC provides the blueprint for accessible interactive elements, ensuring a seamless experience.

How to meet Name, Role, Value

  1. Use the right tools for the job: Default HTML elements like <button>, <input>, and <label> already provide names, roles, and values—use them whenever possible.
  2. Leverage ARIA (when needed): When creating custom elements, use ARIA roles and attributes to define their purpose and behavior.
  3. Test, test, test: Run your site through screen readers and accessibility testing tools to catch coding gaps.

Practical example

An interactive tabbed interface uses ARIA roles like role="tab" and states like aria-selected="true" to ensure screen readers describe the selected tab and its purpose accurately.

Top tips

  • If it ain’t broke, don’t fix it: Stick with default HTML elements whenever possible—they’re already accessible.
  • Be consistent: Use clear, descriptive labels and coding patterns across your site for predictable interactions.
  • Test for usability: Check how assistive technologies interpret your elements to catch any potential issues early.

Further reading

Previous articleNext article
Back to top