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.
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