Form Inputs Missing Associated Labels

TL;DR: Form fields aren't properly linked to their labels, making forms unusable for screen reader and voice control users.

When a label isn't programmatically associated with its input (via for/id or wrapping), screen readers don't announce what the field is for, and voice control users can't say "click email field." Form label errors are among the most commonly cited issues in accessibility audits, and they're straightforward to fix — just add matching for and id attributes.

What Scavo checks (plain English)

Scavo inspects visible user-input controls:

• Text-like <input> fields (excluding hidden/submit/button/reset/image types)
• <select>
• <textarea>

A control is treated as labeled if Scavo can detect at least one valid signal:

• aria-label
• aria-labelledby with text
• title
• <label for="id">...
• Wrapped label (<label><input ...></label>)

How Scavo scores this check

Result behavior:

• Pass: all visible controls are labeled
• Warning: some unlabeled controls, but below fail threshold
• Fail: 3+ unlabeled controls, or unlabeled ratio >= 30%
• Info: no relevant form controls found

In your scan report, this appears under What failed / What needs attention / What is working for form_labels, followed by Recommended next steps and Technical evidence (for developers) when needed.

• Scan key: form_labels
• Category: ACCESSIBILITY

Why fixing this matters

Unlabeled fields cause completion errors, abandonment, and support friction. People may not know what to enter, especially in long forms or account flows.

From an engineering perspective, label regressions are common after CSS/component refactors where visual placeholders remain but semantic labels are removed.

Common reasons this check flags

• Placeholder text used as the only field cue.
• Labels visually hidden/removed without accessible replacement.
• for/id mismatches.
• Component libraries rendering custom fields without proper label binding.

If you are not technical

1. Ask for form-by-form evidence on signup, login, checkout, and contact flows.
2. Require each field to have one stable, explicit label.
3. Prioritize high-traffic and revenue-critical forms first.
4. Re-run Scavo and confirm unlabeled controls are gone.

Scavo flagged Form Labels (form_labels). Please ensure every visible form control has a valid accessible label association (label, aria-label, or aria-labelledby) and verify core forms with assistive-technology checks.

If you are technical

1. Enforce label bindings at component level (design system primitives).
2. Do not treat placeholder as label replacement.
3. Keep unique IDs and valid for references for labeled controls.
4. Ensure custom-select/combobox components expose proper name semantics.
5. Add unit/e2e checks for unlabeled controls in critical forms.

How to verify

• Inspect markup for every field in key forms.
• Confirm label[for] resolves to actual control IDs.
• Test with screen reader quick pass and keyboard-only flow.
• Re-run Scavo and confirm no unlabeled form controls.

What this scan cannot confirm

• It does not verify validation-message accessibility in depth.
• It does not validate complete form UX (error recovery, instructions, required state copy).
• It checks one rendered snapshot, not every conditional form state.

Owner checklist

• [ ] Assign owner for form accessibility standards.
• [ ] Add lint/test guardrails for missing label associations.
• [ ] Include accessibility smoke tests in form-release QA.
• [ ] Recheck after form-builder or component-library upgrades.

FAQ

Is aria-label enough for every field?

It can be, but native <label> remains the preferred baseline where possible.

Are hidden labels acceptable?

Yes when implemented accessibly, as long as fields still expose clear programmatic names.

Why not rely on placeholder text?

Placeholders are hints, not robust labels. They disappear on input and are often inconsistent for assistive technology.

What should we fix first?

Start with signup, checkout, and password-reset/account forms where failure cost is highest.

Sources

• W3C WAI: Forms labels
• WCAG 2.2: Labels or Instructions (3.3.2)
• W3C APG: Names and descriptions
• MDN: <label> element

Need a QA worksheet for your top forms with pass/fail criteria your PM can review? Send support your main form URLs.