Understanding WCAG SC 4.1.2 Name, Role, Value
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. (Level A)
Note: 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
Name, Role, Value Transcript
Hello everyone. Today, we’re going to discuss the significance of providing name, role, and value. We will also talk about their importance, the benefits, good practices, failure scenarios, and how we can fix them.In every website, web application, mobile, or any application, all the UI controls, whether native or custom-built, must have a name, role, and value, which includes state, property, and value. By incorporating these attributes, we can ensure an inclusive and user-friendly experience for everyone. Each attribute plays a crucial role in shaping our digital experiences. So, let’s explore them one by one:
- Name: The name attribute represents the visible and invisible label that describes the purpose of the control, like “Sign In” or “Submit.” These names provide clear instructions and guide users toward the intent and action.
- Role: The role attribute defines the function of the UI control, like link, button, radio button, checkbox, etc. Each role serves a specific purpose. A link, for example, navigates us to another page or resource. A button triggers an action when clicked. Radio buttons and checkboxes enable us to make selections.
- Value: The value attribute represents the behavioral change of the control after the user interacts with it. Consider radio buttons and checkboxes, which can be checked or unchecked to reflect our choices. An accordion-type button expands or collapses to reveal or hide content. A toggle button switches between different states. In the case of a volume slider, the volume may represent the current volume or the volume level after adjustment.
Now, let’s take a look at some of the benefits of name, role, and value. Implementing name, role, and value attributes in UI controls brings significant benefits to users relying on assistive technologies such as screen readers and speech input software. It enhances the user experience by providing a clear name so users can quickly identify the purpose of the control, facilitating smoother navigation within the interface. It also improves functionality—accurate roles assigned to controls enable assistive technologies to understand the intended actions. This empowers users to interact effectively with the application. Finally, real-time updates through value attributes keep users notified about changes in control states or properties, ensuring they are always aware of the dynamic behavior within the interface.
Let’s look at some good practices. A website uses only HTML-specified controls according to their specification. Therefore, all the UI controls have appropriate name, role, and value by default. This ensures compatibility with assistive technologies, creating a seamless user experience.
Now, let’s look at one failure scenario. A project management application has UI controls scripted and custom-built to meet the complex nature of the application. However, the name, role, and value of these controls are not set programmatically. This makes the application unusable for screen reader users and other assistive tech users. It’s very crucial to rectify these accessibility issues.
Let’s see how we can fix them. When building websites, web apps, or mobile applications, prioritize the use of native controls that come built into the language or platform. Native controls inherently provide default accessibility features, including name, role, and value attributes, and ARIA focus. If native controls do not support the required role, property, or state, or if a visible name cannot be provided, consider utilizing ARIA (Accessible Rich Internet Applications) for custom-built controls. ARIA enables developers to enhance accessibility by specifying appropriate name, role, and value attributes.
In conclusion, implementing the principles of name, role, and value is crucial for creating inclusive and accessible digital experiences. By providing clear names, accurate roles, and meaningful values to UI controls, we empower all users to effectively navigate and interact with applications, fostering a more inclusive online environment.
This is the end of the video. Thank you for joining. If you liked the video, do like and subscribe.
The intent of this success criterion is to make sure that assistive technologies receive the necessary semantic information from all the interactive elements present on the page. Each element has an accessible name, role, value, state and property which are conveyed to assistive technologies. In turn, this information enables people with disabilities to interact with these elements.
Native HTML elements, if coded according to standards, will have all the necessary name, role, value and state by default. But there are so many custom component widgets like tabs, tree, grids etc. that need to be constructed from ground up and when need to be made accessible we rely on WAI-ARIA. These custom components need to be provided with a name, role, value, state & property manually using WAI-ARIA attributes. For example, if a div or span needs to be constructed into a button, we can use role=button. But that doesn’t provide accessible name or keyboard operability. So we use aria-label to provide name and tabindex=0 to provide keyboard operability. At the same time we also need to provide the click handlers using JavaScript to this button so that users can use enter or spacebar key to activate the button.
Doesn’t That look like lot of work? if one uses the native HTML button, element all these features are provided by default and no extra code is required. Only when some feature that cannot be coded using HTML use scripting languages to build the widget and use WAI-ARIA to provide the necessary name, role, value, state and properties.
Well explained Raghava!
Thanks for stopping & showing your appreciation through the comment Jyothi.
a good one explanation.
Does a link that activates a script that generates content (e.g. link that opens a navigation menu) have to have role=”button” in order to meet this criteria? Obviously using role=”button” is more intuitive to screen reader users, just wondering if it is a requirement to meet this criteria.
Hello,
The button role is not must to open the menu’s… if there is a link with appropriate name, role & value then it passes this SC…
Thanks