4.1.2 Name, Role, Value

This information relates to criterion 4.1.2 Name, role, value, which states:

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.

This criterion has a note attached to it, which says:

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.

According to the specification

I'm mainly going to focus on HTML components for now, and how this criterion can be failed by not sticking to the specification. Most of the name, role, value fails I see in my daily work are actually due to incorrect coding. So I'm going to explain some of the common errors I see.

Orphaned Inputs

Orphaned inputs occur in a form, when the label and the input are not properly connected. This results in the input not being read out correctly by a screen reader and not being activated by voice recognition software. Let's look at an example:

Here is the code for that:

<form>
	<label>Name:</label>
	<input type="text">
</form>

Visually, it looks perfect. Nobody would know that there is a problem with this... until you use a screen reader or voice recognition software with it.

Using a screen reader, everything is fine if you use the down arrow key to read through the whole page. It will read out the label as it gets to it and then the edit field (but without a name). However many screen reader users navigate forms by tabbing through the components. When you tab to this field, the label is not announced, so the user doesn't know what to type.

With voice recognition software, when you say, "Click name," nothing happens. The command isn't recognised.

Automated accessibility checkers pick up this issue quite well. This example is from WAVE.

WAVE results showing a missing form label and an orphaned form label.

To fix this issue is really easy. The label and the input need to be connected. This is done by matching the for and id attributes, as in the following code:

<form>
	<label for="name">Name:</label>
	<input type="text" id="name">
</form>

It doesn't matter what you call the for and id. The important thing is that they are both there and they match. Visually, this looks no different, but it now works with assistive software.

Missing fieldset and legend

This one tends to affect things like radio buttons, checkboxes and date fields. It is when you have a group of inputs, each with their own label but all connected to one common question. Let's look at an example:

Do you like chocolate?

Here is the code for that:

<form>
	<p>Do you like chocolate?</p>
	<div>
		<input type="radio id="yes" name="chocolate" value="yes">
		<label for="yes">Yes</label>
	</div>
	<div>
		<input type="radio id="no" name="chocolate" value="no">
		<label for="no">No</label>
	</div>
</form>

In this example, the labels and inputs have their matching for and id attributes, so the radio buttons correctly read out as Yes and No. Again, if a screen reader user reads the whole page, that will be okay. However, if they tab to the radio buttons, all they will hear is Yes or No and not the question... which is a bit useless!

To fix this issue, we need a fieldset and a legend. This actually can be used to make a visual difference too, but the main thing is that it connects the question to the inputs.

Do you like chocolate? 
<form>
	<fieldset>
	<legend>Do you like chocolate?</legend>
		<div>
			<input type="radio id="chocolate-yes" name="chocolate" value="yes">
			<label for="chocolate-yes">Yes</label>
		</div>
		<div>
			<input type="radio id="chocolate-no" name="chocolate" value="no">
			<label for="chocolate-no">No</label>
		</div>
	</fieldset>
</form>

When I tested this with JAWS, it read out the question as well as the radio button label for each one. This is the correct behaviour. It can also be seen in the JAWS radio button list. The following screenshot shows both sets of radio buttons on this page. The first has no fieldset and legend, so the user has no way of knowing what the question is. The second has a fieldset and legend and this shows the question as well as the answer options.

Radio buttons list showing both sets on this page. The second set has the question as well as the answers.

Summary

In theory, if you stick to using HTML and don't create custom widgets, you should be safe with this criterion. However, in reality, developers sometimes fail it by not coding form fields correctly - according to the specification.

For orphaned inputs, if you use WAVE, Axe DevTools or ARC toolkit to test the page, all three will pick up the error. However, none of them picked up the missing fieldset and legend issue. If you have a fieldset without a legend, it will pick it up but it is easy for this one to get missed.

The best way to test for this criterion, is to use a screen reader and tab through all the interactive components. It should always read out the label and for groups of inputs, such as radio buttons, it should read out the question too. You can also test with voice recognition software, ensuring that say what you see works for all inputs.

Clicky