Accessible Forms – Should Every Input Have a Label?

Published: | 11 Comments

If 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?

Check boxes, text boxes and labels

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

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'

Share this page (Links open new windows/tabs)

  • Share this page on LinkedIn (opens new window)
  • Share this page on Delicious (opens new window)
  • Share this page on Digg (opens new window)
  • Share this page on Posterous (opens new window)
  • Share this page on Reddit (opens new window)

11 Responses to “Accessible Forms – Should Every Input Have a Label?”

  1. From: lavanya on August 23rd, 2011 at 6:49 am

    I hav HTML embeded in JSP files. When i add a legend to radio button question. Its reading the question twice.

  2. From: indrakiran on September 25th, 2014 at 10:55 am

    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…

  3. 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?

  4. 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?

  5. From: Graham Armfield on November 2nd, 2014 at 2:52 pm

    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.

  6. From: Graham Armfield on November 2nd, 2014 at 2:57 pm

    I’m sorry I’m not sure I understand exactly what you’re asking.

  7. From: Graham Armfield on November 2nd, 2014 at 2:59 pm

    Please could you outline in more detail the problems you are having. Which screen reader are you using? Does it enter forms mode?

  8. From: Open Letter: Gravity Forms 1.9 Placeholder and Label Settings Mean More Inaccessible Forms | Blog | MRW Web Design on January 5th, 2015 at 4:51 pm

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

  9. From: Quick Tip: Persist Checkbox Checked State after Page Reload on May 25th, 2016 at 9:15 pm

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

  10. From: Quick Tip: Persist Checkbox Checked State after Page Reload | 3bluefrogs on May 26th, 2016 at 3:31 am

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

  11. From: Quick Tip: Persist Checkbox Checked State after Page Reload - Top Best Jquery Plugins - Free Download & Demo on October 22nd, 2016 at 9:36 pm

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





Previous post:

Next post: