Developers

4.1.2 Name, Role, Value (Level A)

2 min read

For all user interface components (e.g. forms, links, scripts, controls, etc.), the name and role of those components should be coded in. Any states, properties, and values set by the user should be able to be programmatically updated so browsers and assistive technologies recognize them and reflect those changes.

What you need to know

  • A name can be a label or the assigned text to an element.
  • A role is whatever a component is stated to be–what the component is. For example, a component can be assigned a role of button, drop down list, progress bar, etc. and that role will be relayed to a screen reader.
  • Value is whatever the input is for a component. For example, value might be the slider value selected or the selection of “yes” or “no.” Not all components will have a value.
  • State is the current status of a component. For example, state might be whether a checkbox is checked or whether a component is collapsed or expanded.

What you need to do

  • Make name, role, state, and value of all components determinable.
  • Use ARIA labels when HTML labels are not available.
  • Check any code that is not HTML to make sure it’s accessible.
  • Any custom code (plugins, widgets, scripts) that is from a third party needs to be vetted for accessibility.
  • When you go beyond HTML, make sure any custom or third-party code remains accessible by making name, role, value, and/or state programmatically determinable. ARIA labels (and where applicable, iFrames) are the best way to accomplish this.

Reference

Read the full explanation of success criterion 4.1.2 on W3.org.

Related Resource

Check out “Frames and iFrames” from the U.S. Access Board for more information about this success criterion.