Accessibility
Form fields are labelled
a11y.label
Why this matters
A form field without a label gives a screen reader user no indication of what to type into it. Placeholder text is not a substitute — it vanishes the moment somebody starts typing. On a contact or checkout form this is the difference between an enquiry and a visitor who leaves.
Who fixes it
You can, usually
Roughly how long
Minutes
Care needed
Low risk to change
How to fix it
Give each input a <label for="..."> matching the input's id. A placeholder is not a label — it disappears as soon as someone types.
On your platform
WordPress
Forms come from a plugin rather than from WordPress, so this is a setting in whichever one you use. WPForms and Gravity Forms both have a Label field per element and an option to hide it visually — hiding it is what usually causes this. Contact Form 7 is different: you write the markup yourself, so add the `<label>` tag around the field tag.
Shopify
The contact form lives in the theme, so Online Store → Themes → Edit code and the contact form section. Shopify's own checkout fields are labelled correctly and are not yours to change, so anything reported here is from a theme form or a form app.
Drupal
The Webform module gives every element a Title, and a Title display setting — set to Invisible, it produces exactly this. Core contact forms take the field label from the field's own settings.
Joomla
Joomla's core contact form labels its fields correctly, so this is usually a forms extension — RSForm, Breezing Forms and Convert Forms each have a per-field label and a show/hide switch in the form builder.
How we score it
Failing this check takes up to 12 points off your accessibility score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 106. Free, no account, and you see the evidence for each result.
Check my siteOther accessibility checks
- Accessibility check completedThe accessibility pass runs inside a real browser, and a few things can stop it: a content security policy that blocks our script, or a page that never finishes loading. When that happens the accessibility section is marked unchecked rather than passed, because finding no problems and being unable to look are not the same result.
- Buttons have readable labelsA button with no readable label is announced to a screen reader as nothing more than 'button'. This usually happens when the button contains only an icon. If the unlabelled one is a menu toggle or an Add to Basket, the site becomes unusable rather than merely awkward.
- Headings run in orderScreen reader users navigate by jumping between headings. When levels are skipped, that outline stops matching the page and becomes confusing to move through.
- Images have descriptions for screen readersSomeone using a screen reader hears nothing where these images are. If any of them are product photos, logos or buttons, that part of the page simply does not exist for them.
- Links have readable textA screen reader announces these as just "link", with nothing to say where they go. Icon-only links, such as social media buttons, are the usual cause.
- Page declares its languageScreen readers pick their pronunciation from this. Without it, English can be read aloud with the wrong accent and rhythm, which is hard to follow.