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