Is each label associated with a form field relevant (except in special cases)?

A screen reader user navigates a booking form. They reach a field and hear: "Text input field". The label technically exists (criterion 11.1 is satisfied), but its content tells them nothing. They must guess. This is exactly what criterion 11.2 targets: a label present but useless.

Six mechanisms can carry a label: the <label> element, the title attribute, aria-label, aria-labelledby, and the text of an adjacent visible button. For each, the rule is the same: the content must describe the exact function of the field, unambiguously. "Email address" is relevant. "Field 3" is not.

Test 11.2.5 introduces an additional constraint for users of voice input software like Dragon NaturallySpeaking. When a visible label exists on the page, the accessible name of the field must contain it. A user who says "Last name" to activate the field targets the accessible name, not the visible text. If the two do not match, the voice command fails silently.

The question to ask for each label: if you remove everything else from the form, is this text enough to understand what the field expects?

6 tests to assess the relevance of field labels

Relevance of <label> content

  1. Identify all fields whose label is a <label> (linked via for/id or wrapping the field).
  2. For each field, read the text content of the <label>.
  3. Verify that this content precisely describes the function of the field. Values like "Field 1", "Input" or "Text area" are non-compliant.
  4. If all <label> elements are relevant, the test is validated.

Relevance of title attribute content

  1. Identify all fields whose accessible name relies on the title attribute (fields without <label>, aria-label or aria-labelledby).
  2. For each field, read the value of title.
  3. Verify that this value precisely describes the function of the field.
  4. If all title attributes used as labels are relevant, the test is validated.

Relevance of aria-label attribute content

  1. Identify all fields whose label is provided via the aria-label attribute.
  2. For each field, read the value of the attribute.
  3. Verify that this value precisely describes the function of the field. A value like aria-label="input" or aria-label="field" is non-compliant.
  4. If all aria-label attributes are relevant, the test is validated.

Relevance of text referenced by aria-labelledby

  1. Identify all fields whose label is provided via aria-labelledby.
  2. For each field, retrieve the element(s) referenced by the identifiers listed in the attribute.
  3. Concatenate their text contents in the order of the identifiers: this is the computed accessible name of the field.
  4. Verify that this name precisely describes the function of the field.
  5. If all accessible names are relevant, the test is validated.

Accessible name containing visible label

  1. Identify fields with both a visible label on the page AND an accessible name provided by <label>, title, aria-label or aria-labelledby.
  2. For each field, compare the visible label to the accessible name.
  3. Verify that the accessible name contains the words of the visible label (punctuation and case may differ).
  4. Exception: if the visible label is a functional symbol (e.g. "B" for bold, ">" for next), the accessible name must express the function, not reproduce the symbol. Mathematical expressions ("A>B") may be reproduced literally.
  5. If all conditions are satisfied, the test is validated.

Relevance of adjacent button as visible label

  1. Identify fields whose visible label relies on the text of an adjacent button (e.g. a search field followed by a "Search" button).
  2. For each field, read the visible text of the button.
  3. Verify that this text clearly describes the function of the field or the associated action. A button labeled "OK" or "Submit" without sufficient context is non-compliant.
  4. If all adjacent buttons are relevant, the test is validated.

Examples

❌ Non-compliant : Generic labels without useful information

<label for="field1">Field 1</label>
<input type="email" id="field1" name="email">
 
<label for="field2">Field 2</label>
<input type="text" id="field2" name="phone">

The labels "Field 1" and "Field 2" have no informative value. A screen reader user who navigates directly between form fields cannot know they must enter an email then a phone number. They must explore the surrounding context, which significantly slows navigation.

✅ Compliant : Descriptive and precise labels

<label for="email">Email address</label>
<input type="email" id="email" name="email">
 
<label for="phone">Phone number</label>
<input type="tel" id="phone" name="phone">

Each label precisely describes the expected data. A screen reader user, voice input user, or keyboard user immediately understands the function of each field without having to read the rest of the form.

❌ Non-compliant : Visible label and accessible name mismatch (test 11.2.5)

<p id="label-nom">Last name</p>
<input type="text" aria-label="Enter your name" id="nom" name="nom">

The visible label is "Last name", but the accessible name (provided by aria-label) is "Enter your name". A Dragon NaturallySpeaking user who says "Last name" to activate the field gets no result. The software looks for a field whose accessible name contains exactly what the user said.

✅ Compliant : Visible label included in the accessible name (test 11.2.5)

<p id="label-nom">Last name</p>
<input type="text" aria-labelledby="label-nom" id="nom" name="nom">

The accessible name is built from the referenced text passage, which matches the visible label. The voice command "Last name" works. Using aria-labelledby pointing to the visible label is the most robust solution for satisfying test 11.2.5, as it prevents any mismatch between visible text and accessible name.

Tips and pitfalls

⚠️ The aria-label that enriches the visible label but breaks voice input

This is the most common error in audits on test 11.2.5. The developer adds an aria-label="Date of birth, format DD/MM/YYYY" to help screen reader users, without realizing that the visible label is simply "Date of birth". The accessible name does not contain the visible label: the test fails. The fix: place the format instructions in an aria-describedby and let the accessible name match the visible label.

⚠️ Functional symbols: the letter "B" is not "B"

In a rich text editor, the button displaying "B" to bold text has a symbolic visible label. The accessible name must not be "B" but "Bold". RGAA distinguishes functional symbols (whose accessible name expresses the function) from mathematical expressions (whose literalness is tolerated): a field bearing the visible label "A>B" can have "A>B" as accessible name, the user adapting their voice input according to their knowledge of the tool.

💡 Punctuation and case do not matter in test 11.2.5

If the visible label is "Last name:" (with colon), the accessible name can be "last name" (lowercase, without punctuation) without the test failing. RGAA tolerates these typographic variations. Only the textual substance must match.

⚠️ Adjacent button as visible label (test 11.2.6)

A search field without <label>, with only a "Search" button next to it, can be compliant with test 11.2.6 if the button is relevant. But this pattern does not dispense with providing an accessible name to the field: criterion 11.1 applies independently. The button addresses visible relevance, not technical association.

⚠️ The placeholder creates an illusion of relevance

A field with placeholder="Your email address" and an empty or missing <label> fails criterion 11.1, not 11.2. But when the <label> exists and textually reproduces the placeholder, some auditors incorrectly validate. Verify that the label is readable even after the user has started typing in the field.

Frequently asked questions

What is the difference between RGAA criterion 11.1 and criterion 11.2?

Criterion 11.1 verifies that a label exists and is correctly associated with the field. Criterion 11.2 verifies that its content is useful. A field can have a valid <label> (11.1 compliant) whose text is "Required field" (11.2 non-compliant). The two criteria are evaluated independently.

How to audit RGAA test 11.2.5 quickly in code inspection?

Spot fields with both visible text on the page and an accessible name provided by <label>, title, aria-label or aria-labelledby. Firefox's accessibility inspector ("Accessibility" panel) or Includdy displays the computed accessible name: compare it to the visible label. The accessible name must contain the words of the visible label, minus punctuation and case differences.

How to interpret the compliance of a field with aria-label and visible <label> in RGAA?

Yes, provided the aria-label contains the visible label. <label>Postal code</label> with aria-label="Postal code, 5 digits" is compliant with test 11.2.5 because the accessible name contains "Postal code". On the other hand, aria-label="Enter the zip" would be non-compliant. When a visible <label> exists and is sufficient, avoid adding an aria-label: the risk of desynchronization is not worth it.

When does title constitute a relevant label under RGAA criterion 11.2?

The title is validated by test 11.2.2 if its content is relevant. But title is not visible by default and does not meet the visibility requirements of criterion 11.4. For a standard form, a visible <label> is always preferable. The title as the only label is acceptable only in single-field forms (search, login) where the visual context is sufficient.

How to assess the relevance of a field label in a fieldset according to RGAA?

RGAA does not explicitly require it in criterion 11.2. In a fieldset "Date of birth", the labels "Day", "Month" and "Year" are relevant given the context provided by the legend. In practice, verify that the combination of field label and group legend forms an intelligible set for the user.

References

RGAA 4.1.2: Criterion 11.2
WCAG 2.1:2.4.6 (AA)2.5.3 (A)3.3.2 (A)G82G131H44H65ARIA6ARIA9ARIA14ARIA162.4.6 (AA)2.5.3 (A)3.3.2 (A)