What is it for?

W3C states quite clearly that:
The <label> element may be used to attach information to controls. Each <label> element is associated with exactly one form control.

The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one <label> may be associated with the same control by creating multiple references via the for attribute.

Few interesting points from the above quote for developers to understand are:

• <label> may be used which implies that strictly speaking it is not needed, although I will strongly argue that not using <label> with form elements would be very bad practice
• One <label> can only label one form control, so it is impossible to use one <label> to label many form controls
• Developers can use more than one <label> in order to label any given form control, which is potentially a very powerful construct

Appropriate uses

Generally speaking the most common scenario when using <label> element is the following type of association:

<label for="username">Username or email</label>
<input type="text" name="username" id="username" />

Each form field should have a label associated with it in order to achieve proper accessibility and usability.

Inappropriate use

Not using labels with form fields

From Google

<div class="section_error">
<input type="checkbox" onclick="GWO_updateContinueButton(this)" value="yes" name="ubac_accept"/>
<strong>Yes,</strong> I accept the above Terms and Conditions.
</div>

In the above code snippet Google exemplifies some of the worst practices in User Interface development.

Apart from using non-semantic class name of ‘section_error’ for a non-error content snippet, they are writing in-line JavaScript, which is harder to maintain and does not achieve separation of concerns.

Most importantly Google are not using any labels for the check box, hence they are damaging accessibility and usability of the code snippet as there is no explicit label associated with the check box to denote what the check box is for.

Considering that this code snippet finds itself in context of a very simple documentation page, there are no excuses why Google’s engineers should ever produce this bad quality of User Interface code.

A re-worked, appropriate, semantic solution for this code snippet would read something along these lines:

<div id="termsAndConditions">
<input type="checkbox" value="y" name="termsOptIn" id="termsOptIn" />
<label for="termsOptIn"><strong>Yes,</strong> I accept the above Terms and Conditions.</label>
</div>

If really required, JavaScript functionality associated with this snippet should be situated in an external JavaScript file which associates the functionality by hooking onto to the termsAndConditions ID attribute.

So far I have touched on the topic of emerging semantic web structure, outlining the appropriate way in which we should layer web technologies.

This approach is often refered to as ‘progressive enhancement’.

It is the development approach designed to make sure that a web page works no matter which end user client it is accessed by.

When using progressive enhancement, you should make sure you code up your (X)HTML as semantically as possible first, then style things up with CSS and at the very end add JavaScript behaviours or AJAX enhancements.

This approach ensures that a web page is fully accessible even when JavaScript is not present or not fully supported by the client accessing the web page.

Progressive enhancement is more work?

Following progressive enhancement approach, however, can prove to be much more cumbersome and time consuming, compared to not following it.

This is especially the case when building web applications, such as GMail or Google Calendar.

Web applications can often require two parallel solutions to be engineered for circumstances where JavaScript is available and for circumstances where it is not.

This is one of the reasons why GMail, for example, has an ‘HTML only’ version available as a separate link, while the main version of GMail does not work with JavaScript switched off.

Another likely reason why GMail does not work without JavaScript is the fact that Google engineers use GWT (Google Web Toolkit written in Java) to create all their interfaces with.

GWT spews out user interface code which completely breaks the above outlined good practices, yet creates code which still works cross browser.

Since Google engineers tend to think about back end logic of applications as a matter of priority, their outlook on web application development can be described as graceful degradation.

Graceful degradation

Unlike progressive enhancement, graceful degradation approach assumes all technologies are supported and ensures that users have best possible experience when they are enabled.

Once this is achieved, the considerations are given towards circumstances where certain technologies are not supported and how to deal with them.

Graceful degradation is arguably more appropriate approach in the short term, as the main business objective is to create a working interface for the main user group as soon and as cheaply as possible, while serving the minority user group if and when possible.

This is how most of the very profitable web sites have been developed.

Hard to maintain software is dead software

In the long term, however, graceful degradation approach will more than likely mean that a given application is much harder to maintain and update, as the code is not developed according to semantic standards.

This can mean that future development and progress can only be achieved by completely re-writing a solution from scratch, which can lead to long down times, difficult migration processes, massive costs of re-development, stifled innovation and many other unwanted side-effects.

An extremely good example of this is MySpace, which is one of the worst applications ever developed, which has seen very little to no improvements in the last few years. This is more than likely due to the poor quality of the initial development and extremely bad User Interface code quality.

MySpace’s poor quality user interface code also means it is very tricky to create nice skins for MySpace profile pages using CSS, as the underpinning HTML code is very poor.

This means that MySpace’s very sales pitch of enabling users to customise their profiles however they like is flawed due to the inflexibility in the coding deployed by MySpace developers.

Using graceful degradation also creates a harder environment for developers of various skill sets to work within, as within Google setup any developer working on GMail will have to be a wizard in GWT.

In semantically developed interfaces (i.e. progressively enhanced) a company can employ a relatively cheap CSS developer to develop themes for their CMS or web application without ever needing to touch HTML or JavaScript.

In this environment the company developing the solution has the ultimate flexibility and control over their toolsets.

In progressively enhanced interfaces it is also much easier to delegate work amongst developers, as one person can work on CSS, another on HTML and the third on JavaScript, without developers stepping on each other’s toes all the time.