Accessible Forms – Should Every Input Have a Label?

Reading Time: 5minutesIf 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:

Donation (up to £50 – optional)

For dropdowns, radio buttons or checkboxes the label should describe the options available to the user including suggested default options if relevant.

For example:

Small Pizza

Medium Pizza (Recommended)

Large Pizza

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:

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 which borrowing you wish to repay

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):

Tell us about your savings

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:

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.

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.

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…

From: 123 on October 29th, 2014 at 7:51 am

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?

From: 123 on October 29th, 2014 at 7:52 am

adding legend to radio button means what u did? can u place any screen shot?

[…] 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 […]

Like to leave a comment?

Please note: All comments are moderated before they will appear on this site.

We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we’ll assume that you are happy to receive all cookies on the Coolfields Consulting website. However, if you would like to, you can change your cookie settings at any time. Read our privacy policy.