Label

What it is

Every form field on your website — such as a search box, email signup, checkout address field, or contact form — needs a label that clearly describes what information belongs there. A "label" is either a visible text description linked to the input, or a special code attribute (like `aria-label`) that screen readers can announce. When a form field has no label at all, assistive technology users hear something unhelpful like "edit text" with no context about what to type. WCAG Success Criterion 4.1.2 requires all interactive elements, including form inputs, to have a name that can be determined programmatically.

Why it matters

Unlabeled form fields directly block customers who use screen readers, voice-control software (like Dragon NaturallySpeaking), or keyboard-only navigation — they simply cannot use your checkout, contact, or signup forms. This is a recognized WCAG 2.1 Level A failure, meaning it is among the most serious accessibility violations and creates real legal exposure under the ADA (US), AODA (Canada), EAA (EU), and similar laws — several major retailers have faced lawsuits citing exactly this issue. Beyond legal risk, it also damages conversions: any customer who cannot complete a form cannot buy from you. Additionally, Google uses accessibility signals as part of its overall quality assessment, so fixing these issues supports your SEO health too.

How to fix it

1. Identify every unlabeled form input — use your browser's developer tools (Inspect Element) or an accessibility scanner to find all <input>, <select>, and <textarea> elements that lack a linked label.
2. For each input, add a visible <label> element with a 'for' attribute matching the input's 'id' attribute (e.g., <label for="email">Email address</label> paired with <input id="email" type="email">). This is the preferred, most accessible approach.
3. If a visible label is not feasible due to design constraints (e.g., a lone search bar), add an aria-label attribute directly on the input element (e.g., <input type="search" aria-label="Search products">), or use aria-labelledby pointing to another visible element's id.
4. Never use placeholder text as the only label — placeholders disappear when a user starts typing and are not reliably announced by all screen readers.
5. After making changes, retest with an automated scanner (axe DevTools browser extension) and manually tab through your forms with a screen reader (NVDA on Windows or VoiceOver on Mac/iOS) to confirm each field is announced with a meaningful name.
6. Apply the fix to ALL forms site-wide: checkout, login, registration, search, newsletter signup, contact, and any custom forms — not just the one page where the issue was first found.

<label for="customer-email">Email address</label>
<input id="customer-email" type="email" name="email" autocomplete="email">

<!-- OR, when a visible label is not possible: -->
<input type="search" aria-label="Search products" name="q">

Fix it on your platform

Pick your platform for the exact steps.

Frequently asked questions

Authoritative references

• How to fix this specific rule — Deque/axe (rule reference)
• WCAG 2 overview — W3C WAI
• Forms tutorial — W3C WAI
• ARIA basics — MDN