Issue guide
Missing form labels
Placeholder text is not a substitute for labels.
Inputs without a proper name force users to guess what to enter—screen readers and voice control cannot associate the field with its purpose.
See this on your site
Run a scan, then match rule names in your report to the sections below.
At a glance
Instructional
No associated label
Placeholder is not a replacement for a label.
Label linked to field
Screen readers announce the label; placeholders alone are fragile.
Why this matters
- Screen readers may only announce “edit text” with no hint what belongs there.
- Autocomplete and error recovery break when fields are not programmatically labeled.
- Keyboard users cannot correlate errors with fields without aria-describedby.
Where this shows up
Use this list to spot the same pattern on your templates and key URLs.
Forms
- Email and password fields
- Search inputs
- Checkout address blocks
- Custom selects and comboboxes
Filters
- “Filter by” fields with icon-only affordance
Fix priority — address first
- Login, signup, checkout, and payment fields.
- Required fields that show validation errors.
Fix priority — can follow
- Hidden or visually minimal fields that still expose aria-label correctly.
Who is affected
Screen reader users, keyboard-only users, and people who rely on clear errors and labels.
Fix this in your platform
Stack-specific steps, pitfalls, and verification. Core issues link under /wordpress, /shopify, /react, or /nextjs; all issues also have /fix/… URLs.
What this issue is
Every input needs an accessible name, usually via `<label for>` wrapping, or `aria-label` when design constraints require it.
Fixes
Prefer visible labels. If space is tight, use persistent labels or aria-labelledby pointing to visible text.
Examples (bad vs good)
Bad
`placeholder="Email"` with no `<label>` or aria.
Good
`<label for="email">Email</label><input id="email" type="email" autocomplete="email">`.
How to fix
- Find each unlabeled control in the failing node list.
- Add a visible `<label for="id">` or `aria-labelledby` to visible text.
- If design forbids visible labels, add a concise `aria-label` and document why.
- Wire `aria-describedby` to error text; rescan.
Platform-specific notes
Where this often comes from on common stacks—and what to change.
- WordPress
- Contact Form 7 and Gravity Forms need correct field settings; avoid placeholder-only UX.
- React
- Floating labels still need a programmatic name; test with the accessibility tree.
Common mistakes
- Using placeholder text as the only label.
- Wrapping label incorrectly so `for`/`id` do not match.
- Relying on placeholder color that disappears on focus.
How to verify the fix
- Click the label and confirm focus moves to the input.
- Use the accessibility tree to read the accessible name.
- Submit empty required fields and confirm errors are announced and linked.
Related: 3.3.2 Labels or Instructions.
FAQ
- Search boxes?
- Add a label or aria-label; icons alone are not enough.
Related guides
Run another scan
After you ship a fix, rescan the same URL and keep both report links to compare.
Broader topics
Principles on these pages overlap with HTML issues: PDFs for documents and downloads, mobile for touch, contrast, and small screens.
Related issues
Next steps
Keep the scan, fix, rescan loop going
Ship a fix, then run another scan on the same URL. Each run gets its own report link so you can compare before and after.
Open scan