Glossary · Accessibility term
Name, Role, Value
Name, role and value are the facts assistive technology needs about a control, and the shorthand quietly drops one. What the rule asks is that the name and the role can be read by software. Then that any state or value the user can change can also be set by software. Then that changes get announced to whatever is listening. The settable half is what makes a slider usable by voice control rather than merely readable, and it is the half nobody quotes. Native HTML gets you further than anything else and not all the way. Use a real button and the button role and its states come free. The name still has to come from somewhere. That is why an empty button element has a role and no name, and why an input with no label is announced by whatever the browser can scrape together. Build the same control out of a div and you start with none of it, and one piece has to be in place before another can work. A div's implicit role is one of the eleven ARIA forbids you to name, so a label on a roleless div is a label ARIA says not to write. The real role has to be there for the name to mean anything.
In practice
Ask three questions of every custom control and a fourth people forget. What is it called, what kind of thing is it, what state is it in, and can that state be changed by something other than a mouse? A toggle that reports itself correctly and can only be flipped by clicking has answered three and failed the fourth.
Native elements are the cheap answer and the reason is worth stating. The criterion's own note says standard HTML controls already meet it when used according to specification, and that qualifier is doing real work rather than being a formality. Used according to specification means the button has content or a label, and the input is named by one of the routes HTML supports, whether that is a label element pointing at it or a label wrapped around it. It also means nobody has hung a click handler on a div and called it done.
One dependency runs the other way once you reach for ARIA. Eleven roles are name-prohibited in ARIA 1.2, and the generic role a plain div or span carries is one of them, so an aria-label on a roleless div is not merely ineffective. ARIA says authors must not do it, and a browser is entitled to throw it away. It is not that you type the role first. It is that a real role has to be there at all, or there is nothing the name is allowed to attach to.
Make the accessible name contain the visible label while you are in there. Somebody using voice control says the words they can see, so a control labelled Search on screen and named something else in the code is unlikely to answer to "click Search". Containing rather than matching is what the rule asks, so Search for products is fine and submit-btn is not.
Why it matters
It is the rule that explains why a control working with a mouse is not enough, and it accounts for a large share of what actually breaks. Two of the six most detected errors on the web are failures of it, with missing form labels on 51% of home pages and empty buttons on 30.6%. Empty links at 46.3% usually are as well. It is also the criterion where automated testing looks most convincing and helps least, which is the argument our page on the rule itself makes with the evidence attached. Read that page next.
Three of the four, and still broken
A custom volume slider built from divs, wired up with the slider role, a real accessible name, and a value that updates as you drag. It announces perfectly. Nothing but a mouse can move it, so somebody using voice control or a screen reader's own controls can hear exactly where the volume is and cannot change it. That is a failure of the half of the rule the shorthand leaves out.
Where this shows up on the site
Related terms
- Accessible nameThe accessible name is what assistive technology announces an element as, the words a screen reader speaks when it lands on a button or a link.
- RoleA role is what kind of thing an element is, as reported to assistive technology.
- ARIAARIA is a set of attributes that tell assistive technology what a custom control is and what state it is in.
- Accessibility treeThe accessibility tree is a second structure the browser builds alongside the DOM, holding one object for every part of your page that has to be exposed to assistive technology.
- RobustRobust is the fourth of WCAG's four principles, and it asks that content be built well enough for a wide variety of user agents, including assistive technology, to interpret it.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.