SC 4.1.2 Name, Role, Value
Ensure all user interface components are programmatically identifiable and controllable by assistive technologies (AT).
- Core Requirement: For every UI component (including custom controls), the Name (purpose/label), Role (type of element), and Value/State (current status or user input) must be programmatically determinable.
- Dynamic Updates: Any changes to the state, properties, or values of a component must be communicated to AT in real-time.
- Implementation: Use native HTML/platform elements whenever possible, as they provide built-in name and role information. For custom controls, use ARIA attributes (Web) or platform-specific Accessibility APIs (Software/Mobile) to explicitly define these properties.
- Rationale: This ensures users of screen readers and other AT understand how to interact with, operate, and receive feedback from all components on the page or application.
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.
SC 4.1.2 Name, Role, Value is part of the accessibility principle Robust because it ensures that users who rely on AT are able to use each user interface component, especially those that are custom developed by code or scripting. User interface controls or elements should be coded to provide information about their names, roles, state, properties, and values.
For example, an HTML image may be coded as:
<img src="racing_car.jpg" width="500" height="400" alt="Racing Car" title="at full speed, at NASCAR">
The Name of an element (also called the “accessible name”) is a short label that provides information about the purpose of the element. For example, the name for the image above is “Racing Car,” provided by the alt attribute.
The Role of an element tells us what type of element it is. The img tag tells us that this particular element is an image. This tells other technology, such as browsers and AT, how to interact with the element.
HTML interface elements have Properties (also called “attributes”), which provide information about the element. Here, the src attribute says where to find the image. The width and height attributes tell the browser how to size the image. The alt and title attributes provide a name and description for the image. Other properties or attributes of other elements may specify whether the element is visible, can receive focus, is enabled, etc.
Developers may also provide a Description, which is a short explanation that further clarifies the nature of the element. In the image example above, the “title” attribute provides more description.
Some elements, such as text fields or slider bars, contain a Value, such as the text entered into the text fields or the current setting of the slider. The Name, Description, Value, and other properties are used by the browser and AT to compute the “text alternative” for the element.
Some properties or attributes may sometimes be referred to as States when the value of that attribute may change in response to user actions. For example, if a user checks a checkbox, we may say that the state of the checkbox is now “checked.” However, this is not an important distinction.
A related concept is the accessible name of an element. The accessible name may be derived from a visible property (e.g., the visible text on a button) or invisible property (e.g., the text alternative that describes an image or icon) of the user interface element. For example, a menu item has the name “New” is a visible property that informs users that the menu item will create a new document. But with the race car image in the example above, the accessible description is derived from properties that are not visible.
A simple example of how AT uses the accessible name and role may be illustrated by an “OK” button. The text “OK” on the button is the accessible name. When the button receives focus, AT may concatenate the platform’s role description with the accessible name. For example, a screen reader may speak “push-button OK” or “OK button.”
The intent of this SC is to ensure that all web or native software controls, especially custom-developed controls, provide enough information about their names, roles, states, and other information, as well as any changes to this information. This includes web controls, such as HTML input and form elements, and native software controls, such as Windows input and form elements. This ensures that users can use AT to understand how to use these controls, know their current statuses, and use their AT to operate these controls.
Impact of Nonconformance with SC 4.1.2 Name Role, Value
| Type of Disability | Description of Impact |
|---|---|
| 302.1 Without Vision | Users who are blind cannot use a mouse to interact with electronic content and typically use an assistive technology, such as a screen reader, to get audible or other alternative output for the information represented visually. To be able to navigate the content, understand its structure and relationships, and understand the meaning of content represented in graphics and images, the content must provide textual and programmatic cues in addition to the content presented purely visually. |
| 302.2 With Limited Vision | Users with limited vision may have widely different visual perception. Individuals with limited vision may or may not use assistive technologies. Therefore, in addition to textual and programmatic cues necessary for assistive technologies, ICT must also present content consistently and predictably. Users who view content with magnifiers may not pick up alerts, warnings, or other content if such content is presented outside of a consistent and predictable navigation pattern or if the content is not itself viewable at large magnification. Content that becomes distorted when magnified can also prevent some users with limited vision from being able to understand or interact with the content. |
| 302.7 With Limited Manipulation | Some users may not be able to perform actions that require fine motor control (clicking and dragging), path dependent gestures (pattern-based passcodes), or simultaneous actions (Ctrl + Alt + Del). Providing alternative means to perform the same actions, such as entering the size specifications in an input field to resize an object or allowing sequential key entries, can enable users with limited manipulation to interact with the same content. |
| 302.8 With Limited Reach and Strength | Some users may lack sufficient strength to perform actions such as squeezing, grasping, or depressing a hardware control. Some users, including those in wheelchairs or of shorter stature, may not be able to reach controls that are placed too high or too far away from where a user would access the device controls or interface. ICT designers and developers must consider a broad range of statures, strength and dexterity limitations, and the needs of wheelchair users in order to provide interfaces that are operable with limited reach and/or strength. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Some users require more time than average to process information while others may find complicated instructions difficult to follow. Furthermore, some ICT content can distract or overwhelm users, preventing them from being able to interact with or understand other ICT content. Designers and developers of ICT must consider a broad range of cognitive abilities in order to provide ICT that is simple and easy to use. |
Applicability of Success Criteria 4.1.2 Name, Role, Value
| Technology | Applicability of SC 4.1.2 Name, Role, Value |
|---|---|
| Web | For many types of elements, a Name can be calculated or determined from text already included within the element. For other elements, such as images, developers must generally either explicitly provide a label (e.g., via an alt attribute or aria-label) or programmatically associate the element with other descriptive text somewhere on the page. An element’s Role is generally derived from the native HTML element type (e.g., <img>, <button>, <textarea>), but it can also be defined using the ARIA “role” attribute. The ARIA “role” attribute instructs an AT user how to perceive and/or interact with an element that might be coded to take on other role-related functions or attributes that might be different from the role of the native HTML element. An element’s value might be explicitly defined or could be the result of user input. |
| Software | Software developers typically use the control property that maps to the accessibility API’s “name” property to define a control’s Name. Developers might also use other properties, such as a “description,” and/or programmatically associate other text in the software to contribute to a control’s Name. A control’s Role is typically derived from the control type if the control is a standard control. If the control is a custom control, then the control’s Role may be explicitly defined or may be derived from the control pattern assigned to the custom control. A control’s value might be explicitly defined or could be the result of user input. |
| Office documents | For most objects inserted using standard Office functions, the objects rely on the Alt property defined in the object properties to provide the object’s Name. For the same objects, the object type directly define the object’s Role. Form controls inserted from the “Developer” ribbon tab rely on the same mappings to accessibility APIs, as described in Software above. |
| PDF documents | The most common objects, including figures and images, rely on the Alt property defined in the object properties to provide the object’s Name. For the same objects, the object type directly define the object’s Role. Form controls and objects rely on the same mappings to accessibility APIs, as described in Software above. |
| Mobile Native | Mobile-native software developers typically use the control property that maps to the accessibility API’s “name” property to define a control’s Name. Developers might also use other properties, such as a “description,” and/or programmatically associate other text in the software to contribute to a control’s Name. A control’s Role is typically derived from the control type if the control is a standard control. If the control is a custom control, then the control’s Role may be explicitly defined or may be derived from the control pattern assigned to the custom control. A control’s value might be explicitly defined or could be the result of user input. |