How to fix: Form inputs missing labels
Every text input, select, and textarea needs a programmatic label, most often a <label for="id"> tied to the field, an aria-label, or an aria-labelledby reference, so assistive tech can announce what to type.
What it is
A form label is the machine-readable name of an input. WCAG Success Criterion 1.3.1 Info and Relationships requires that the relationship between a field and its label be available in code, not just implied by visual placement. A screen reader announces this name when focus reaches the field, so the user knows whether they are in the email box, the phone box, or the search box.
There are several valid ways to provide it. The most robust is a <label> element whose for attribute matches the input's id, which also makes the label clickable. You can wrap the input inside a <label>. Or you can use aria-label (an invisible string), aria-labelledby (pointing at the id of visible text), or, as a weaker fallback, the title attribute. What does not count is a placeholder: placeholder text disappears on input and is not a reliable label.
A nearby line of visible text that just sits next to the field is not enough on its own. If it is not connected via for/id, a wrapping label, or aria, the input is still unlabeled as far as assistive technology is concerned.
Who it affects & why it matters
Screen reader users are hit hardest. An unlabeled input is often announced as just "edit text," leaving the user to guess what belongs there, which is especially damaging on checkout, login, and contact forms where a wrong guess means a failed transaction or a lost lead.
Voice-control users (who say "click email field") and people with cognitive or memory disabilities also depend on a persistent, programmatic label. Visible, properly associated labels reduce errors for everyone, since the label stays put while a placeholder vanishes the moment you start typing.
Missing form labels are a Level A failure and consistently rank among the most common issues in the WebAIM Million report. Because forms are where conversions and revenue happen, this barrier maps almost directly to lost business, not just a compliance checkbox.
It is also high on the list of issues that trigger ADA web lawsuits, alongside missing alt text and low contrast. Level AA is the benchmark courts apply, and unlabeled fields on a public-facing form (sign-up, search, contact) are an easy, screenshot-ready violation for a plaintiff to point to. The fix is usually a few lines of HTML.
How to fix it
- List every input, select, and textarea on the page (you can ignore hidden, submit, button, reset, and image inputs).
- For each one, give the field an id and add a <label for="that-id"> with clear, visible text.
- When a visible label is not possible by design (for example an icon-only search box), add aria-label or point aria-labelledby at existing visible text.
- Do not rely on placeholder text as the label; keep the placeholder for example formatting only.
- Verify each label is correctly associated by clicking the label text and confirming it focuses the field, then re-scan.
<input type="email" placeholder="Email address">
<select name="plan">
<option>Pro</option>
</select><label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com">
<label for="plan">Choose a plan</label>
<select id="plan" name="plan">
<option>Pro</option>
</select>How AccessKnight detects this
AccessKnight selects every input, select, and textarea, then excludes the types that do not need a visible label (hidden, submit, button, reset, and image). For each remaining field it checks, in order, for any one of: a <label for="id"> that matches the field's id, a <label> ancestor wrapping the field, an aria-label attribute, an aria-labelledby attribute, or a title attribute. If none of those are present, the field is flagged as missing a label. A placeholder attribute alone never satisfies the check, because placeholders are not accessible names.