What it means
An input, select or textarea has no programmatically associated label: no <label for>, no wrapping label, no aria-label or aria-labelledby. A visible placeholder does not count, and neither does adjacent text that happens to sit next to the field visually.
Why it matters
Screen readers announce an unlabelled field as “edit text” with no indication of what belongs in it. Speech-recognition users cannot address a control that has no name. And placeholders, which are often used instead of labels, disappear the moment typing begins — so anyone who is interrupted mid-form loses the only clue about what they were entering, and the low-contrast grey they are usually rendered in fails contrast requirements anyway.
The clicking target matters too: a properly associated label extends the hit area of its field, which is why labelled forms are measurably easier to complete on a phone.
How W3Audit detects it
Every form control in the delivered HTML is resolved to its accessible name using the same algorithm assistive technology uses, so a field labelled by aria-labelledby passes and a field labelled only by proximity fails. Placeholder-only fields are reported as a distinct finding rather than lumped in, since the fix differs. The auditor then walks the primary forms — contact, search, checkout — by keyboard and screen reader to check that error messages and required states are announced, not just coloured.
How severe it is
Critical in any form on a conversion path, because it blocks task completion for some users. High elsewhere. Placeholder-as-label is high on its own: the field is nameable in some tools but the label vanishes on input for everyone.
How to fix it
Use a visible <label> tied to the field by for and id. Reserve ARIA for cases where no visible label can exist.
<!-- broken: placeholder doing a label's job --> <input type="email" placeholder="Email address" /> <!-- correct --> <label for="email">Email address</label> <input id="email" name="email" type="email" required /> <!-- acceptable where a visible label is genuinely impossible --> <input type="search" aria-label="Search the site" />
Mark required fields in text as well as colour, and associate error messages with their field using aria-describedby so they are announced when focus lands.
How to verify the fix
Inspect each control’s accessible name in your browser’s accessibility panel — every field should report a name matching its visible label. Then tab through the form with a screen reader running: you should hear the label, the type, the required state, and any error. Last check: click the label text itself. Focus should move into the field.
Where this sits in your audit
This finding belongs to the UX & accessibility category — see the UX & accessibility audit for everything else reviewed alongside it, or the methodology for how its severity and score contribution are calculated. The website audit checklist includes it as a step you can run yourself.