How to test criterion 4.1.2 “Name, Role, Value — For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”
- WCAG references
- 4.1.2 Name, Role, Value (A)
What this criterion says
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
Official methodology to test criterion 4.1.2
Official W3C techniques
The W3C does not publish a test procedure for this criterion. It publishes techniques instead: documented ways to meet it, and the failures that do not.
Sufficient techniques
Situation A: If using a standard user interface component in a markup language (e.g., HTML):
- ARIA14 Using aria-label to provide an accessible name where a visible label cannot be used
- ARIA16 Using aria-labelledby to provide a name for user interface controls
- G108 Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
Situation B: If using script or code to re-purpose a standard user interface component in a markup language:
- Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes
Situation C: If using a standard user interface component in a programming technology:
Situation D: If creating your own user interface component in a programming language:
Common failures
- F59 Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
- F15 Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
- F20 Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
- F42 Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
- F68 Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
- F79 Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
- F86 Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
- F89 Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link
- F111 Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name