Hey everyone. Josh here with Online ADA. In this video, we’re covering 4.1.2–Name, Role and Value. This is a level A requirement, and I’ll jump into the description.
“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.”
There’s a note here. “Note one: this success criterion is primarily for web authors who developed or script their own user interface components, for example, Standard HTML controls already meet the success criterion when used according to specification.”
What this says is that whenever you’re using standard, native HTML–like a Nav element or a table or a button element–they’re gonna have their appropriate names, roles, and values already programmatically determined, assuming you’re using them the way they’re supposed to be used. If instead, however, you’re trying to use a div element and you’re trying to make it act like a button, then in that case, this applies. We’re gonna make sure that we have the correct name available to the assistive technology, –that’s an accessible name, by the way–the correct value can be determined for whatever it is, if it has contents inside of it, like a link if you have a div or a span that you’re trying to make work like a link, then you have all the relevant information for it and that includes the role of link. This is to ensure that the assistive technology knows exactly what it’s interacting with when it approaches that element.
So if you have, actually, a really good example of this would be when you have form inputs and you have labels that need to be associated to them or tied to them in some way. There’s two ways to approach a label and an input and making them work together correctly. You can either have the label be completely, separately removed from the input, but the input has an ID on it and the label has a four attribute that points to an ID–that would be one way. Or, you could have the label open tag and close tag and the input stuck inside of there–that would be another way. And what that does is when the user agent or the browser or assistive technology comes to an input, it knows that that label is associated and it will read the label for that input.
That’s just one example. There’s many, many, many examples and this is, again, just going to be specifically directed towards web authors who are creating their own interface controls.
This actually happens a lot and it’s not really feasible to make a website entirely built out of just native HTML, or at least native interface components. So you can’t just use inputs. Sometimes you need out of the box functionality–you gotta make that yourself in those cases. You need to make sure that you’re providing the correct role, states and properties.
If you have a button that opens a menu, for instance, then you’re gonna wanna use ARIA dash “pressed” equals “true,” if it’s been clicked on. If you have a tab list, you have the correct role of “tab list” and then all the elements that open the various stages of the content are going to have role of “tab” or role of “tab content” and you’re going to have ARIA controls and all those different attributes, which can be found on the website.
And the W3.org website has a lot of examples and tutorials on how to correctly, programmatically associate these things. But it’s important that they’re all there and that they’re implemented correctly so that we know what we’re interacting with when we reach it. This is to help everyone with every kind of disability who needs the assistance of assistive technology, okay?
Thank you so much for joining me. That’s all there is in this one and I’ll see you in the next video