Form Labels

A form label is a text element that identifies the purpose of a form control, telling users what information they should enter or what action a control performs. In HTML, the `<label>` element is the standard way to provide labels for form controls like text inputs, checkboxes, radio buttons, select dropdowns, and textareas. Labels serve two essential functions. First, they communicate the purpose of a form control to all users, including those using screen readers. When a screen reader user focuses on a text input, the screen reader announces the associated label—for example, "Email address, text input." Without a label, the screen reader would announce simply "text input," leaving the user guessing about what to enter. Second, labels expand the clickable area of form controls. When a `<label>` element is properly associated with an input, clicking on the label text moves focus to the input. This is particularly helpful for small controls like checkboxes and radio buttons, where the clickable target is often very small. Users with motor disabilities, tremors, or reduced dexterity benefit significantly from this larger target area. Despite being one of the simplest accessibility requirements to implement, missing or improperly associated form labels remain among the most common accessibility errors on the web. The WebAIM Million survey consistently finds that missing form labels affect over 40% of home pages analyzed.

Form labels matter because forms are the primary way users interact with websites beyond reading content. Logging in, signing up, searching, making purchases, submitting applications, and contacting support all require forms. If a form is inaccessible, the user is effectively locked out of the service. For screen reader users, labels are the only way to identify form fields. Sighted users can visually associate nearby text with a form field based on proximity and layout. Screen reader users cannot make these visual associations—they rely entirely on programmatic connections between labels and inputs. An input without a programmatic label is functionally unlabeled to a screen reader user. Labels also reduce errors for all users. Clear, descriptive labels help users understand what information is expected, in what format, and whether a field is required. This is especially important for users with cognitive disabilities who may struggle with ambiguous or unclear instructions. WCAG addresses form labels in several success criteria. SC 1.3.1 (Info and Relationships, Level A) requires that form fields have programmatically determinable labels. SC 3.3.2 (Labels or Instructions, Level A) requires labels or instructions when content requires user input. SC 2.4.6 (Headings and Labels, Level AA) requires that labels describe the topic or purpose. SC 4.1.2 (Name, Role, Value, Level A) requires that all form controls have accessible names.

### Explicit Label Association The most robust method of labeling a form control is explicit association using the `for` attribute: ```html <label for="username">Username</label> <input id="username" type="text" /> ``` The `for` attribute on the `<label>` must match the `id` attribute on the input. This creates a programmatic link that: - Allows screen readers to announce the label when the input receives focus - Makes the label text a click target for the input - Works regardless of where the label appears in the DOM relative to the input ### Implicit Label Association An implicit label wraps the input inside the `<label>` element: ```html <label> Username <input type="text" /> </label> ``` This method does not require `for` and `id` attributes because the association is implied by the parent-child relationship. However, some older assistive technologies do not fully support implicit labels, so explicit association is preferred. ### ARIA Labeling When a visible `<label>` element is not practical, ARIA attributes can provide accessible names: - **`aria-label`**: Provides a label directly as a string attribute. Useful for inputs where a visible label would be redundant (e.g., a search input next to a search button). - **`aria-labelledby`**: References the ID of another element that serves as the label. Useful when the label text exists on the page but is not a `<label>` element. - **`aria-describedby`**: References supplementary descriptive text, such as format hints or instructions. This does not replace a label but adds to it. ```html <!-- aria-label example --> <input type="search" aria-label="Search articles" /> <!-- aria-labelledby example --> <h2 id="billing-heading">Billing Address</h2> <input type="text" aria-labelledby="billing-heading" /> <!-- aria-describedby for additional instructions --> <label for="phone">Phone Number</label> <input id="phone" type="tel" aria-describedby="phone-hint" /> <span id="phone-hint">Format: (555) 123-4567</span> ``` ### Labeling Grouped Controls Related controls should be grouped using `<fieldset>` and `<legend>`: ```html <fieldset> <legend>Shipping Method</legend> <label><input type="radio" name="shipping" value="standard" /> Standard (5-7 days)</label> <label><input type="radio" name="shipping" value="express" /> Express (2-3 days)</label> <label><input type="radio" name="shipping" value="overnight" /> Overnight</label> </fieldset> ``` Screen readers announce the legend text before each radio button's individual label, giving users the full context: "Shipping Method group, Standard (5-7 days), radio button." ### Common Label Mistakes - **Placeholder as label**: Placeholder text disappears on input and is not a reliable label. - **Label not associated**: A label exists visually near the input but is not connected via `for`/`id` or wrapping. - **Hidden label with no alternative**: Using `display: none` or `visibility: hidden` on a label removes it from both the visual display and the accessibility tree. Use a visually hidden technique instead if you need to hide labels visually. - **Duplicate IDs**: If multiple inputs share the same ID, label associations break.

**Example 1: Basic Contact Form** A contact form uses explicit label association for all fields: Name, Email, Subject, and Message. Each `<label>` uses a `for` attribute matching the corresponding input's `id`. The "Subject" field uses a `<select>` dropdown, which is also properly labeled. Required fields include `aria-required="true"` and visual indicators. **Example 2: Search Field with Visually Hidden Label** A search bar in the site header has a visible magnifying glass icon and a visible "Search" button, making the purpose visually obvious. However, a `<label>` is still needed for screen readers. The developer uses a visually hidden `<label>` element that is accessible to screen readers but not displayed on screen, ensuring all users understand the field's purpose. **Example 3: Multi-Part Date Field** A date entry requires three fields: month, day, and year. The developer uses a `<fieldset>` with `<legend>Date of Birth</legend>` to group the fields, and each individual field has its own label: "Month," "Day," and "Year." Screen readers announce "Date of Birth group, Month, text input" when the user focuses on the first field. **Example 4: Error Recovery with Labels** A form submission fails validation. The error messages are programmatically associated with their respective inputs using `aria-describedby`. When a screen reader user tabs to the email field that has an error, they hear: "Email address, text input, invalid entry, please enter a valid email address." The label, role, state, and error description are all announced together, giving the user complete context.