DEV Community

Kenneth Larsen
Kenneth Larsen

Posted on • Originally published at blog.prototypr.io on

Five Minute Accessibility: Input and Labels

Photo: Christopher Gower

It seems that a lot of frontend developers either don’t know about coding for accessibility or they don’t care. Of course, it can be hard to implement in organizations with no focus on accessibility. But it’s always a developer’s (and designer’s) responsibility to develop an inclusive web.

In the series Five Minute Accessibility I will introduce one simple thing you can do to improve accessibility in your projects. In this post you’ll learn about how to use input and labels.

Even though you’ve been creating input forms for years it might be the case that none of them are accessible. Thankfully, it’s very simple to change this starting today.

To create accessible input fields you have to beware of labels. Creating a label which is uniquely tied to an input field is necessary to create accessible forms. Note that labels are referring to an id of the input. Screen readers do not support multiple labels associated with the same form element.

So you might normally see an input field like this:

<label>Name:</label>
<input type=”text” name=”textfield”>
Enter fullscreen mode Exit fullscreen mode

As you might expect this works great for users of non-assistive technologies and this is a very common way of developing forms. However, this will be non-inclusive. So by simply wiring the label and the input we now have an accessible input field:

<label for=”name” >Name:</label>
<input id=”name” type=”text” name=”textfield”>
Enter fullscreen mode Exit fullscreen mode

By adding for=”name” to the label we link this label uniquely to the id of the input. This is now accessible and also has some other nice features included. The user can now click on the label itself to set focus to the form element. This is useful to some with motor disabilities, particularly when selecting small checkboxes and radio buttons.

The good thing is that this is useable for other types of inputs as well. Let’s have a look at check boxes:

<fieldset>
<legend>Select your pizza toppings:</legend>
<input id=”ham” type=”checkbox” name=”toppings” value=”ham”>
<label for=”ham”>Ham</label><br>
<input id=”pepperoni” type=”checkbox” name=”toppings” value=”pepperoni”>
<label for=”pepperoni”>Pepperoni</label><br>
<input id=”mushrooms” type=”checkbox” name=”toppings” value=”mushrooms”>
<label for=”mushrooms”>Mushrooms</label><br>
<input id=”olives” type=”checkbox” name=”toppings” value=”olives”>
<label for=”olives”>Olives</label>
</fieldset>
Enter fullscreen mode Exit fullscreen mode

Notice that each check box has an id which is matched by the label. By adding these few lines you have accessible forms — so why not start doing it today?


Check out my fail log or subscribe to my Fail Mail newsletter

You can also follow me on Twitter.


Oldest comments (2)

Collapse
 
nbau21 profile image
Noel Bautista

I wish stuff like these were more the norm. Apps should work with accessibility in mind. frameworks already enable us to build accessibility friendly apps. feature planners and developers should be more aware how easy it is to make an accessible app IF it were a higher priority.

Collapse
 
kennethlarsen profile image
Kenneth Larsen

You're absolutely right. There's no excuse not to make it accessible by default. Especially when you get so far by using standard HTML elements. But developer habits are hard to change...