Ensure every form control has an accessible label
Content available in English only.
Accessibility isn’t just about avoiding violations — it’s about ensuring that everyone can use your product with confidence. This guide explains each rule’s intent, highlights common issues, and shows how to fix them according to WCAG and the European Accessibility Act (EAA).
These guidelines do not replace the official WCAG standards. They’re concise, developer-focused notes to help you identify and fix issues effectively.
Placeholders are not labels — every form field needs a real name.
Why this matters and how to fix it
Why this matters
Labels tell users what information is expected in each form field. Without an accessible label, screen readers announce only the control type (e.g., 'edit text'), leaving users unsure what to enter. This causes confusion, errors, and failed form submissions.
How to fix this issue
Associate each input, select, and textarea with a descriptive label using `<label for="id">`. If there is no visible label, provide one programmatically using `aria-label` or `aria-labelledby`.
Developer guidance
Do not rely on placeholders as labels — placeholders disappear when typing, and many users never hear them at all. In design systems, enforce that every form component requires a label or an explicit `aria-label` / `aria-labelledby`.
Code examples
Incorrect Implementation
<input type='text' placeholder='Name'>Correct Implementation
<label for='name'>Full name</label>
<input id='name' type='text'>Real-World Examples
Before
<input id="email" type="email" />
<!-- Screen reader: 'edit text' → no indication what the field is for -->After
<label for="email">Email address</label>
<input id="email" type="email" />
<!-- Screen reader: 'Email address, edit text' → clear purpose -->CSS Example (Guidance)
/* If designers want visually minimal labels, style instead of removing */
label {
font-size: 0.875rem;
color: #555;
display: block;
margin-bottom: 0.25rem;
}
/* Do NOT hide labels unless replaced with an accessible name */Manual testing
- 1. Turn on a screen reader (NVDA, VoiceOver, JAWS, or TalkBack).
- 2. Navigate through the form using Tab or Arrow keys.
- 3. Listen to the announcement for each field:
- • Expected: The label is spoken before the input type (e.g., 'Full name, edit text').
- • Failure: Screen reader announces only 'edit text', 'combobox', or 'checkbox' with no context.
- 4. Inspect elements in DevTools → Accessibility → Computed Properties → 'Name'.
- • Confirm each control has an Accessible Name and it matches the visible label.
- 5. If the label is visually hidden (rare case), ensure it uses a proper `.visually-hidden` class, not `display:none`.
Trusted by organizations across Europe working toward WCAG and EAA conformance