Accessible Forms – Should Every Input Have a Label?
Published: | 11 Comments
Reading Time: 5 minutesIf you’re using input fields on a web page your users will need to know what they’re supposed to put in them or which ones to choose for radio buttons, checkboxes and dropdowns. Sighted users can see any accompanying text next to the text box or radio button but that’s not always possible for users who are blind or suffering from other visual impairments. How can these people know what’s expected of them?
Step forward the HTML label tag that provides an easy, accessible way of indicating what the input fields are for. It can be used alongside all of the input types on a website form – well, almost all anyway. But do you really always need to use them?
This post discusses the importance of the label tag, how to use it, and some best practices to keep in mind when designing or building web forms.
What is the label tag for?
Prompting for Input
Firstly, labels are an accessibility feature that allows screen readers (as used by blind and other users) to voice the input prompt to the user.
The label for a text box should describe in sufficient detail what input is required from the user. As well as the prompt for the input field the label should also usefully contain whether or not the field is required or optional. Where relevant it is also useful to include any valid range values or formats – this improves the usability of the form for sighted users too by minimizing the input errors that may occur.
For example:
For dropdowns, radio buttons or checkboxes the label should describe the options available to the user including suggested default options if relevant.
For example:
A Bigger Target
Another little-known purpose of the label is to increase the clickable area for the input – especially useful for sighted users with motor impairments whose mouse control may not be as precise when it come to small inputs like radio buttons. You can try this by clicking on the labels in the examples above – note how focus is given to the relevant input.
Where to put the label
The HTML specification is not 100% clear on this but web best practice states that:
- for text boxes and dropdowns (or select boxes) the label should immediately precede the input field.
- for checkboxes and radio buttons the label should follow immediately after the input field.
Labels are not required for submit buttons or other buttons in forms.
How are the label and input linked?
In the HTML the label is linked to the input field using the id attribute of the input field and the for attribute of the label. Examples:
<label for="email">Email address</label> <input id="email" name="email" type="text" /> <input id="pizza1" name="pizzasize" type="radio" /> <label for="pizza1">Small Pizza</label>
Note that the for attribute of the label and the id attribute of the input field are the same in each case. This ensures they are linked.
What happens if there is no label?
Input fields without accompanying labels can lead to accessibility issues for those who rely on screen readers. If a screen reader comes across an input field without a label it will try to find some accompanying text to use as the label. For text fields and dropdowns the screen reader will use any preceding text and for radio buttons and checkboxes the screen reader will look for any following text.
Now if the prompts for input fields are not marked up as labels but are positioned correctly then the screen reader may well read out the correct words. But in some cases the context of the input field is implied by its positioning – maybe by being placed in a table for example. The user may hear whatever is in the adjacent table cell which might relate to something completely different, or may not be sufficient information on which to make a choice.
For example (explanation beneath table):
| Select | Borrowing | Account Number | Amount Oustanding |
|---|---|---|---|
| Personal Loan | 010203 12345678 | £345.56 | |
| Personal Loan | 010203 55663344 | £876.09 | |
| Credit Card | 1234 5678 4534 2345 | £1276.34 |
The second column values will be voiced by screen readers as the prompt for the check boxes, but on their own that is not sufficient information on which to base a choice.
Another example (explanation beneath table):
| Sole/Joint Account | Provider | Balance (£) | Access/Notice |
|---|---|---|---|
This example is from a mortgage application form and is prompting the user to declare their savings. Screen reader users will get little or no sensible information from these input fields. When screen readers are within the input fields, the table column headings are not accessible very easily or at all.
Another common problem is where a series of inputs are used together – for example to enter a date:
| DD | MM | YYYY | |
| Date of Birth: |
Screen reader users will probably try to enter their date of birth in the first text box. The screen reader will voice no useful prompt for the second or third box and users may not know what they are for.
So what’s the alternative?
Hiding labels
If input fields need to be contained within a table format then the labels can be provided but hidden using the stylesheet technique outlined in a previous post: Text for Screen Readers Only. It is still vital that the label contains enough information to enable screen reader users to make their informed choice.
Alternatively with the date example the label can be partially hidden but leave the format clue visible:
Date of Birth: <label for="dobd"> <span class="screenreader">Date of Birth Day - </span>DD</label> <br /> <input id="dobd" name="dobd" size="2" type="text" />
Remember that if labels are hidden in this way only screen reader users can access them. For usability it is vital to ensure that the input required is obvious to everyone.
Using the title attribute
Another alternative is to use the title attribute of the input field itself to describe what input is required. Title attributes provide the hover-over ‘tool tips’ that are often seen on websites. Some people advocate using them instead of the label in situations like those above where a visible label may spoil the design.
Example:
<input title="Type search term here" type="text" /> <input type="submit" value="Search" />
However, although screen readers can read out the title attributes on form input fields, it is not always a default setting. For that reason I recommend the use of hidden labels which are read out by all screen readers by default
Using placeholder text
A technique that is sometimes applied to text boxes is setting the initial value of the input to a prompt for input. The prompt disappears when the user clicks on or tabs into the field.
This technique is not accessible as the prompt is lost when the input field is focussed on. Screen reader users won’t know what input is expected.
Got any questions?
If you’re not sure about any of the points mentioned here or you’ve got something else you’d like to say please leave a comment below. Alternatively you can use the form on the Contact Us page.
Other posts tagged 'Forms'
- How to Build an Accessible WordPress Theme - Apr 28th, 2019
- Accessibility Checklist - Apr 7th, 2019
- Dragon Naturally Speaking Video 9 – Internet Forms - Mar 13th, 2014
- Video: How Do I Know My WordPress Website is Accessible? - Mar 5th, 2014
- Accessible Forms – Grouping Elements Together With Fieldset - Oct 11th, 2011
- Accessible Forms – Grouping Options With Optgroup - Aug 24th, 2011
- Accessible Forms – Selects or Dropdowns - May 24th, 2011
- Accessible Forms – Checkboxes and Radio Buttons - Apr 26th, 2011
- Designing and Building Accessible Forms - Apr 12th, 2011
Share this page (Links open new windows/tabs)
11 Responses to “Accessible Forms – Should Every Input Have a Label?”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: Designing and Building Accessible Forms
Next post: Accessible Forms – Checkboxes and Radio Buttons
I hav HTML embeded in JSP files. When i add a legend to radio button question. Its reading the question twice.
I have followed the process as you said but screen reader is not reading the label text will please explain what are problems associated with it…
label of a dropdown is having for control but
the id of the select is different from the value of for
selectcombo_ is appended to the id.
if code change for the label is done for drop down then it will effect the text boxes which is working fine now.
what could be the best solution?
adding legend to radio button means
what u did?
can u place any screen shot?
I’ve also published a blog post about using the fieldset and legend tags to enhace the accessibility of radio button groupings – its’s called Accessible Forms – Grouping Elements Together With Fieldset.
Hopefully that will give you all you need.
I’m sorry I’m not sure I understand exactly what you’re asking.
Please could you outline in more detail the problems you are having. Which screen reader are you using? Does it enter forms mode?
[…] The Baymard Institute, Sarah Horton, David A. Kennedy, Jeremy Keith, Nielsen Norman Group, Coolfields Consulting, Paciello Group, Pardot, and countless other accessibility, usability, and HTML experts […]
[…] I’m using labels for the text pertaining to each of the boxes. It goes without saying that form fields should have labels anyway, but in the case of checkboxes this is particularly important, as it allows users to […]
[…] I’m using labels for the text pertaining to each of the boxes. It goes without saying that form fields should have labels anyway, but in the case of checkboxes this is particularly important, as it allows users to […]
[…] for the textual content pertaining to every of the packing containers. It goes with out saying that form fields should have labels anyway, however within the case of checkboxes that is notably essential, because it permits […]