Does each form field have a label?
A screen reader user arrives at your contact form. Their software announces "text input field." No name. They don't know whether to enter their first name, email, or message. Without an accessible label, the field is unusable.
Each field must expose an accessible name: text that assistive technologies can read to identify what the user should enter. Criterion 11.1 accepts five methods: a <label> associated via for/id, an aria-labelledby attribute pointing to identified text on the page, an aria-label attribute, a title attribute, or an adjacent visible button paired with a hidden <label> or ARIA attribute.
The reference method remains a visible <label> linked by matching for/id attributes. It benefits all users, enlarges the clickable area of the field, and satisfies all three criterion tests. Reserve aria-label and title for cases where visual space is constrained — search bar, quantity field in an order table.
The placeholder is not a label. It disappears on input, its contrast is insufficient, and some screen readers do not render it. A field with only a placeholder fails criterion 11.1.
3 tests to ensure that each form field has a visible label
Presence of accessible label on each field
- Identify all form fields on the page (
<input>,<textarea>,<select>, etc.). - For each field, verify that at least one of the following conditions is met:
- The field has an
aria-labelledbyattribute whose value matches theidof an element present on the page. - The field has a non-empty
aria-labelattribute. - The field is associated with a
<label>having aforattribute. - The field has a
titleattribute. - An adjacent button provides a visible label, and a hidden
<label>or anaria-label,aria-labelledby, ortitleattribute provides the accessible name.
- The field has an
- If at least one condition is met for the field, the test is validated. If none is met, the field is non-conformant.
Association of <label> via for/id attributes
This test applies only to fields associated with a <label>.
- Verify that the field has an
idattribute. - Verify that the value of the
forattribute of the<label>is identical to the value of theidattribute of the field. - If both conditions are met, the test is validated. A missing
idor aforvalue different from theidmakes the field non-conformant.
Title or visible text for non-adjacent label
This test applies to fields whose label is not visible on screen or is not adjacent (hidden label via CSS, aria-label, aria-labelledby pointing to a distant element).
- For each field in question, verify that at least one of the following conditions is met:
- The field has a
titleattribute that clearly describes the nature of the expected input. - Text adjacent to the field becomes visible on focus and describes the expected input.
- Text that is visible is placed adjacent to the field and describes the expected input.
- The field has a
- If at least one condition is met, the test is validated.
Examples
❌ Non-compliant : Field without label (placeholder only)
<form>
<input type="text" name="email" placeholder="Your email address">
<button type="submit">Sign up</button>
</form>The field has no <label>, aria-label, title, or aria-labelledby. The placeholder is not recognized as a label by RGAA. A screen reader announces "text input field" without any name. The user must guess what to enter.
❌ Non-compliant : <label> poorly associated — mismatched for and id
<form>
<label for="nom">Full name</label>
<input type="text" id="full-name" name="name">
</form>The for="nom" attribute does not match id="full-name". The association is broken: the screen reader does not announce the label on field focus. Test 11.1.2 fails. Clicking the label does not activate the field either.
✅ Compliant : Explicit <label> via for/id
<form>
<label for="email">Email address</label>
<input type="text" id="email" name="email">
<button type="submit">Sign up</button>
</form>The <label> is linked to the field via matching for/id attributes. The screen reader announces "Email address, text input field." The clickable area also enlarges: clicking the label activates the field, which helps users with reduced motor control.
✅ Compliant : Search bar with aria-label
<form role="search">
<input
type="search"
id="search"
name="q"
aria-label="Search the site"
>
<button type="submit" aria-label="Launch search">
<svg aria-hidden="true" focusable="false" width="16" height="16">
<use href="#icon-search"></use>
</svg>
</button>
</form>When visual space does not allow displaying a label, aria-label provides the accessible name. The screen reader announces "Search the site, search field." This technique is acceptable for single-field forms whose function is obvious in the visual context.
Tips and pitfalls
⚠️ The placeholder is not a label
This is error number one in audits. The placeholder disappears as soon as the user starts typing — impossible to reread the instruction to correct input. Several screen readers do not render it at all. Its default contrast also fails criterion 3.2. A field with only a placeholder is non-conformant to criterion 11.1.
⚠️ The implicit <label> fails test 11.1.2
A <label> that wraps its field without a for attribute creates a semantic association recognized by most screen readers. But test 11.1.2 explicitly requires that the <label> possess a for attribute whose value matches the id of the field. In strict RGAA audit, an implicit label without for/id fails this test, even if it works technically in modern browsers.
💡 Hide a label without removing it
For constrained login forms or search bars, visually hide the <label> with a sr-only CSS class (absolute positioning, overflow hidden, clip). The field remains conformant to criterion 11.1, and criterion 11.4 (visual proximity) does not apply since the label is not visible. Avoid display:none and visibility:hidden, which also hide from screen readers.
⚠️ aria-labelledby can combine multiple text passages
aria-labelledby accepts multiple identifiers separated by spaces: aria-labelledby="label-qty label-product" produces "Quantity blue T-shirt." Useful in order tables where each row has an item and each column a label. The accessible name results from concatenating the referenced texts, in the order of the identifiers.
⚠️ The title is valid but with limited use
title satisfies criterion 11.1, but it is not displayed by default and its accessibility is weak on mobile (no tooltip on touch). On complex forms, prefer aria-label or a visible <label>. Reserve title for cases where it simultaneously serves as a tooltip for sighted users and an accessible name for screen readers.
Frequently asked questions
Why does the placeholder not replace a RGAA field label?
No, never. The placeholder is not a label within RGAA 11.1. It disappears on input, its default contrast is insufficient (criterion 3.2), and some screen readers do not read it. If you cannot display a visible label, use aria-label or a <label class="sr-only">. The placeholder can coexist with a real label to illustrate an example of the expected format.
When should you use an implicit <label> to meet RGAA criterion 11.1?
Technically, an implicit label works in most modern screen readers. But test 11.1.2 explicitly requires a <label> with for matching the id of the field. In strict RGAA audit, an implicit label without for/id fails this test. Always use explicit association to be unambiguously conformant.
How do you verify that a form field has an accessible name according to RGAA?
Two quick methods: (1) open your browser's Accessibility panel (DevTools > Accessibility) and check the "Name" field calculated for each input — if it is empty, criterion 11.1 fails. (2) Navigate with keyboard using NVDA or VoiceOver: the screen reader must announce the field name on each focus. A field announced without a name is non-conformant.
How do you use aria-label to label a <select> or <textarea>?
Yes, aria-label works on all interactive form elements, including <select> and <textarea>. However, prefer a visible <label> linked by for/id: it benefits all users — sighted, blind, cognitive — and satisfies criteria 11.1 and 11.2 at once. aria-label remains reserved for cases where displaying a visible label is technically impossible.
What is the difference between criterion 11.1 and criterion 11.2?
Criterion 11.1 verifies the presence and technical association of a label, visible or not. Criterion 11.2 verifies that the label is relevant—that it correctly describes the expected input. A field can have aria-label="field1" and pass 11.1 while failing 11.2 because the label is incomprehensible outside context.