Understanding 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

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.

Points to Ponder

• Use native HTML elements wherever possible
• USE WAI-ARIA attributes while constructing custom component widgets
• Make sure custom widgets are keyboard operable using spacebar or enter keys
• Provide tabindex=0 for custom widgets so that they receive tab focus
• Make it a practice to read ARIA specifications to understand the implications and the consequences of ARIA roles, states and properties before using them

References

Understanding Success Criterion 4.1.2