Is it good practice to use <label> for non-input/non-interactive elements?

Question

When labeling a non-input element with no interactivity, such as a preview <img>, is it better (or correct) to use <span> instead of <label>?

e.g.:

<span>Image preview:</span>
<img id="preview">

or this:

<label for="preview">Image preview:</label>
<img id="preview">

Rod

Answer 1

The <label> tag defines a label for an <input> element.

So use <span>instead.

The for attribute associates the label with a control element, as defined in the description of label in the HTML 4.01 spec. This implies, among other things, that when the label element receives focus (e.g. by being clicked on), it passes the focus on to its associated control. The association between a label and a control may also be used by speech-based user agents, which may give the user a way to ask what the associated label is, when dealing with a control. (The association may not be as obvious as in visual rendering.

HTML specifications do not make it mandatory to associate labels with controls, but Web Content Accessibility Guidelines (WCAG) 2.0 do. This is described in the technical document H44: Using label elements to associate text labels with form controls, which also explains that the implicit association (by nesting e.g. input inside label) is not as widely supported as the explicit association via for and id attributes,

Fusilier

Figure / figcaption might be better than span, but you're write in that using a label is entirely wrong (to the point of being invalid since the HTML spec requires that it be associated with a form control (although textareas and selects are fine, it doesn't have to be an input)). – Schismatic

I hadn't heard before that implicit association of labels isn't as well supported as explicit, so I decided to follow up on this. I think you're referring to the User Agent Support Notes for H44. The notes describe that this was tested on Windows XP with IE 6.0. That's pretty outdated. I'd be interested to see if there's more up-to-date info on this. – Boyle

Just checked the Paciello AT test file for labels using NVDA in IE 11 on Windows 10: inputs nested in labels are supported. – Boyle

The <label> tag defines a label for an <input> element. It can also label a select or textarea element. – Rictus

> "HTML specifications do not make it mandatory to associate labels with controls, but Web Content Accessibility Guidelines (WCAG) 2.0 do." Imo that linked document mainly says that when you have a form control, it should also always have an associated label, but it doesn't mention anything about the reverse case of having a <label> element without an associated form control so vice versa is not automatically required. Form control requiring a label does not mean that a label always requires a form control. – Elation

html.spec.whatwg.org/multipage/forms.html#the-label-element "The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element's labeled control, either using the for attribute, or by putting the form control inside the label element itself. Except where otherwise specified by the following rules, a label element has no labeled control." – Elation

What about semantic markup? How is using a span better than using a label element when providing text on the screen (without an associated control). I agree with some of the comments here, the spec indicates that a label can be associated with an input via the for attribute but I don't think it implies that a label HAS to have an associated input control. Wish WAVE saw it the same way. The way their rule is written is causing us all kinds of grief. – Marrowfat

Answer 2

It is entirely acceptable to use <label> elements as captions for non-input tags.

The HTML Living Standard

Per the label element section of the HTML Living Standard, label elements may optionally be associated with a form control, but this is not required.

The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element's labeled control, either using the for attribute, or by putting the form control inside the label element itself.

Except where otherwise specified by the following rules, a label element has no labeled control.

Note, specifically, that in addition to stating that the caption "can be associated with a ... form control" (rather than "must be"), the docs also explicitly state that:

Except where otherwise specified by the following rules, a label element has no [specific form control associated with the caption].

Which only seems to make sense if the element is intended to be used with or without an associated input. This makes sense in light of label's semantic meaning as a caption for content– more than just inputs can have and benefit from captions.

The WCAG H44 Objection

Sources which indicate that label elements should only be used on inputs frequently reference WCAG 2+'s requirement that inputs have labels, along with WCAG Technique H44: Using label elements to associate text labels with form controls, which presents an example pattern that meets the spec.

This is not a mandate for the usage of label elements, and interpreting it as such is a misreading.

WCAG itself notes that techniques are non-normative on their About Techniques page:

Techniques are not required

Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.1 is the success criteria from the WCAG 2.1 standard—not the techniques.

The aim of the H44 Technique is to fulfill or help fulfill four WCAG 2+ success criteria relating to:

• Text alternatives for non-text content (SC 1.1.1)
• Providing textual equivalents for information conveyed visually (SC 1.3.1)
• Providing labels or instructions for user inputs (SC 3.3.2)
• Providing assistive technologies with the ability to track and manipulate user input controls (SC 4.1.2)

Ultimately, the above technique and criteria is designed to aid accessibility– not to dictate that label elements only be used for user inputs alone.

Sauternes

This should be the accepted answer IMHO. The accepted answer seems to be blatantly and empirically incorrect. – Frankforter

Answer 3

I know this is old and has been answered and accepted - and my solution is the same as one of the comments (@Quentin) - but for the sake of increasing awareness and educating codes to use the semantically correct element - the figure and associated figcaption is the best tool for the job as described here.

Here is a link to documentation and the fugure elements is fully supported as a html5 element across all browesers (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure).

All parts of the figure element can be styled - and the figcaption can either be the first-child or the last-child of hte figure elements (- placing it before or after the image)

figure {
  text-align: center;
}

figcaption {
  margin-bottom: 4px;
  color: blue;
  font-weight: bold
}

figure img {
  border: solid 1px blue;
  border-radius: 8px;
}

<figure>
  <figcaption>Image preview:</figcaption>
  <img id="preview" src="https://i.pinimg.com/originals/3e/6b/cd/3e6bcdc46881f5355163f9783c44a985.jpg" alt="fluffy-kitten" height="100" />
</figure>

Ginaginder