Summary

Correctly labelled form controls ensure that your forms are usable to the widest possible audience. Explicitly labelling form controls is beneficial for people using assistive technology, and correctly positioning form prompts can benefit visitors with mobility and cognitive difficulties.

The HTML Techniques for WCAG 2.0 currently proposes a technique to ensure that the prompt for form controls is positioned appropriately, but there is a proposal to deprecate the technique. I think it would be a mistake to deprecate this technique, as correctly positioned form prompts help people who are not fortunate enough, or don't require assistive technology.

Author: Gez Lemon

Contents

Accessibility and Usability

The differences between accessibility and usability are often blurred. Usability is concerned with ensuring that documents are perceivable and understandable. Visitors can easily comprehend websites that follow usability principles, because the pages will look and feel how they expect, particularly with user interface components in forms. Accessibility is purely concerned with ensuring that documents are usable by people with disabilities. As cognitive disabilities are included in accessibility, it follows that usability and accessibility are intertwined, as usability guidelines help people with cognitive problems.

[Back to the contents]

Positioning Prompts for Form Controls

Generally, prompts for form controls should be placed immediately to the left of the associated control, or immediately above the associated control. The positioning of prompts for form controls has its roots in Human-Computer Interaction (HCI), an area of computer science that studies the relationship between user interfaces, and their usability. HCI is based on results from cognitive psychologists' findings into perception, memory, and learning, and applying it to interfaces used in computer applications. A major part of HCI is choosing the appropriate control for the task, but the layout of forms is also an important part of the cognition process.

Forms that are laid out vertically with the prompts to the left of the form control have the advantage that the user can quickly scan down the left-hand side to determine what type of information they are required to provide. This is generally the best approach, although not always practical. For example, in languages such as German where some words are a lot longer than others, it can create a situation where some prompts may be a long way from their associated form control, which obviously has an impact on usability. In these circumstances, positioning the prompt above the form control may be more appropriate.

In HTML, prompts are usually marked up with the label element. The reason for this is that it provides an explicit association to the form control for assistive technologies. For example, a screen reader will read the associated label for a particular form element if it has been marked up with a label. 

<label for="surname">Surname</label>
<input type="text" size="20" name="surname" id="surname"/>

Strictly speaking, the associated text for a radio button or a checkbox isn't the prompt, but part of the control itself. Radio buttons and checkboxes are used to toggle between states, and in the case of radio buttons, may be grouped by giving each radio button the same name, so that the choice is mutually exclusive from a set of options. For this reason, the associated text should be marked up with a label, and positioned to the right of the control, to create a button-like control with a larger target area. If a prompt is required for checkboxes or radio buttons, the prompt should be positioned to the left or above the group, as they are with other controls, except the prompt wouldn't be marked up as a label. Marking up the associated text for radio buttons and checkboxes in a label increases the target area for people with mobility problems, and obviously helps people with cognitive problems through consistency. 

<input type="checkbox" id="updates" name="updates" value="Receive Updates"/>
<label for="updates">Receive regular updates?</label>

[Back to the contents]

Deprecating Label Positioning

The HTML Techniques for WCAG 2.0 currently has a technique for label positioning. There is a proposal to deprecate this technique, with the rationale that positioning shouldn't matter if the labels are explicitly associated with the appropriate control. I think the positioning of prompts is important for accessibility, as in the case of radio buttons and checkboxes, it increases the target area for people with mobility difficulties, and clearly laid out forms helps people with cognitive problems. Explicitly labelled prompts are useful to people using assistive technology, but only a small percentage of people with accessibility requirements use assistive technology, mainly due to the cost. It also adds weight to those who feel that accessibility guidelines are geared to people with visual impairments, as two major groups could be left out if the proposal to deprecate the technique is upheld.

I also think that the wording for the technique as it stands is misleading:

The label must immediately precede its control on the same line (allowing more than one control/label per line) or be in the line preceding the control (with only one label and one control per line).

As I mentioned earlier, prompts should be placed either immediately before, or immediately above the control. The language in the technique uses the word "label", which is an element in HTML. With checkboxes and radio buttons, the label is part of the control, and should be positioned to the right of the control, and if a prompt is necessary, the prompt should be positioned immediately to the left or above the group; not the label.

[Back to the contents]

Category: Accessibility.

Comments

  1. [label-positioning.php#comment1]

    I've wondered about this issue for some time. I agree that the label should go around the text in checkboxes and radiobuttons, but what of the overall label, or "prompt" as you call it?

    From a design perspective, forms will generally go in a table (go ahead and gasp) with the label to the left and the input to the right. In my experience when there's a checkbox or radio group, there's still some sort of prompt on the left acting as a label (if for no other reason than consistent layout).

    The problem for me is that the prompt should still look like a label. To do it without a label creates the need to have a special class that would then clutter up an otherwise straight forward layout.

    Also, in my opinion, the prompt is still a label (in a semantic sort of way). But to what should such a label be assigned?

    Am I making sense here?

    Posted by Roman on

  2. [label-positioning.php#comment2]

    From a design perspective, forms will generally go in a table (go ahead and gasp) with the label to the left and the input to the right. In my experience when there's a checkbox or radio group, there's still some sort of prompt on the left acting as a label (if for no other reason than consistent layout).

    Yes, that would be good because people will look down the left-hand side and know what they're expected to fill in. For example, if you were collecting gender information, you may have Gender as a prompt on the left-hand side, and radio buttons on the right for the gender options, with their associated text marked up as a label and positioned to the right of the appropriate radio button.

    The problem for me is that the prompt should still look like a label. To do it without a label creates the need to have a special class that would then clutter up an otherwise straight forward layout.

    I'm sorry, I didn't follow this part. Why would you need an extra class?

    Also, in my opinion, the prompt is still a label (in a semantic sort of way). But to what should such a label be assigned?

    For controls other than radio buttons and checkboxes, the prompt would be marked up with a label. For radio buttons and checkboxes, the prompt shouldn't be marked up as a label with an explicit association, as the prompt isn't associated with a particular control. Radio buttons and checkboxes are button-like in nature, and the associated text should be part of the target area. As each button is independent, the prompt has no specific relationship. I suppose you could markup the prompt in the label element, and not provide an explicit association with a control, as it's semantically a label: <label>Gender</label>

    Posted by Gez on

  3. [label-positioning.php#comment3]

    I'm a bit lost on this, wouldn't you mark up a radio button group like this: 

    
<fieldset>
<legend>Gender</legend>
<input type="radio" value="g" id="radio1">
<label for="radio1">male</label>
<input type="radio" value="g" id="radio2">
<label for="radio2">female</label>
</fieldset>

    so that prompt "gender" is associated with all radio buttons within the group?

    Posted by steve faulkner on

  4. [label-positioning.php#comment4]

    Hi Steve,

    Yes, that's a better example as the radio buttons would be grouped together using an appropriate container. The radio buttons would need a name, and the value would probably be something that uniquely identified the selection, but using a fieldset and legend would be the best way to group the controls together.

    Posted by Gez on

  5. [label-positioning.php#comment5]

    Steve is right in that fieldset would be the most appropriate way to markup that group. The whole problem I have is in satisfying my designer.

    99% of the time we'll have something like what Gez was proposing: a prompt in the left column saying gender, with a radio button and label for each option to the right.

    Unfortunately I can't put the legend of a fieldset on the left because that would create invalidly nested tags.

    Ultimately what I've been doing is using an extra label for the prompt in the left column with the radio buttons and their actual labels on the right.

    I just feel like the label for the prompt should be associated to something (using the for attribute) so that I'm not abusing the label tag just to make all the prompts look the same. But if I don't use label, that's when a class has to be created to make the non-lable prompts look like the rest.

    I guess in a perfect world the legend tag could be associated to the fieldset from elsewhere in the markup using the for attribute. For now I suppose I'll just keep doing what I'm doing.

    Posted by Roman on

  6. [label-positioning.php#comment6]

    I've been searching for nearly a year why the label for a checkbox and radio button is placed on the right and have never been able to find a reason. My colleagues have also tried searching and none of us have found the reason. No website explains why it goes to the right. We can find plenty of other people asking the question but never an answer. Seeing the answer it seems obvious and I am grateful you explained it. Thank you!

    Posted by Dennis Whitehouse on

  7. [label-positioning.php#comment7]

    I think of checkbox and radio button controls as being like a list, say in an quiz or a test. Generally, as in the paper metaphor, these sorts of options are grouped (label, or prompt) by a question or statement, followed by the choices as a list. As in "have a number 2 pencil and check all that apply" or "which one of these best fits you?" I've never seen a paper form that has the boxes anywhere except the left of each item in the list. It's convention (at least in LTR languages like English).

    As to the comment about using tables to layout forms, perhaps this is off-topic, but I for one sorely miss using them.

    Posted by Douglas Clifton on

  8. [label-positioning.php#comment8]

    I've never seen a paper form that has the boxes anywhere except the left of each item in the list. It's convention.

    I think there is one exception when we have only one checkbox and have 2 coloumns form layout. In this case it apropriate to put checkbox after label.
    Check this examples:
    http://public.fotki.com/FaT32/journal/journal/form_example_1.html
    http://public.fotki.com/FaT32/journal/journal/form_example_2.html
    Pay attention on "Remember me" layout differences.
    Gez, thank you for good article!

    Posted by Andrey Petrov on

  9. [label-positioning.php#comment9]

    I've been labelling inputs by putting the input control inside the label. 

    <form action="test.html" method="post">
	<fieldset>
		<legend>Example</legend>

		<label for="i1">
			<span>LabelText</span>
			<input type="text" name="i1" id="i1">
		</label>

		<label for="i2">
			<span>LabelText</span>
			<input type="text" name="i2" id="i2">
		</label>

		<label for="i3">
			<span>LabelText</span>
			<input type="text" name="i3" id="i3">
		</label>

		<fieldset>
			<legend>RadioCollection</legend>

			<label for="r1">
				<span>LabelText</span>
				<input type="radio" name="r1" id="r1">
			</label>
			<label for="r2">
				<span>LabelText</span>
				<input type="radio" name="r2" id="r2">
			</label>
			<label for="r3">
				<span>LabelText</span>
				<input type="radio" name="r3" id="r3">
			</label>

		</fieldset>
	</fieldset>
</form>

    and then use css to position and style the form elements ?

    any arguements for this approach ? ?

    Posted by loggin on

  10. [label-positioning.php#comment10]

    any arguements for this approach ? ?

    There's nothing wrong with implicit labels, except they don't work in Internet Explorer. Your version won't suffer from that, as you also have an explicit association that will make it work as expected in IE, as well as all other modern user agents. There's no need for an implicit label, and some designers may find it too restrictive, particularly if the label is in a different element from the form control.

    There are two other general problems with your form. Firstly, radio buttons are used for mutually exclusive options. To make a set of radio buttons mutually exclusive is simply a case of giving each radio button in the collection the same name. You have different names for each radio button, meaning the visitor can select all of them, but can't turn any of them off should they accidentally select one. If each option is allowed to be selected and de-selected, then a checkbox would be a better choice of form control, otherwise they should be grouped appropriately.

    Secondly, the label is positioned incorrectly. The label for radio buttons and checkboxes should be positioned to the right of the form control, and all other form controls should be labelled immediately to the left of the associated form control, or immediately above the associated form control. Choosing the wrong position is confusing to users, particularly when they're laid out horizontally.

    Posted by Gez on

  11. [label-positioning.php#comment11]

    Ok it was a bit hashed in the rush, and I made a mistake the radio buttons naming but if you were listening to me the positioning of elements is controlled via css, although it might present a problem when read in source order.

    Posted by loggin on

  12. [label-positioning.php#comment12]

    but if you were listening to me the positioning of elements is controlled via CSS, although it might present a problem when read in source order.

    I was listening to you, and source order is important. You asked for arguments for the approach, and I can't think of any.

    In an article about accessibility and label positioning, the position of the label is likely to be considered relatively important for the discussion. Positioning the label incorrectly and relying on CSS to fix it is not an acceptable approach.

    WCAG 1.0 Checkpoint 6.1
    Organize documents so they may be read without style sheets. [Priority 1]

    I'm sorry if this isn't what you wanted to hear.

    Posted by Gez on

  13. [label-positioning.php#comment13]

    I just heard (via podcast) of an interesting example where the "text prompt" should not be located near the input field: Derek Featherstone's accessible crossword puzzle. I haven't seen it yet...but he mentions it toward the very end of his podcast from <a href="http://we05.com/podcast/">Web Essentials</a>

    I know...I know, this is a unique game situation...but I couldn't resist adding this thought for you to ponder.

    Posted by goodwitch on

Comments are closed for this entry.