WCAG 3.3.2 / 1.3.1 (A)
Form fields have no associated label
What this failure is
A form field needs a label so users know what to type into it. Sighted users read the label next to the box, but a screen reader user does not scan the page visually — they tab into the field and hear the label announced by their assistive tech. If the field has no <label> tag associated with it, no aria-label, no aria-labelledby, and no wrapping <label>, the screen reader announces only "edit, blank" or "combo box", giving no clue whether this is the email box, the postcode box or the card-number box. Placeholder text (the grey hint inside the field) is not a substitute — placeholders vanish the moment the user starts typing and most screen readers do not treat them as labels.
Reference: WCAG 3.3.2 / 1.3.1 (A) — the authoritative spec.
Who it affects
- Screen reader users: Tabbing through an unlabelled checkout produces a sequence of "edit, blank" announcements; the user cannot tell postcode from phone number, abandons the cart, and the sale is lost.
- Voice-control users: Dragon and Voice Access rely on labels to build the click-by-name grammar; "click first name" fails when the field has no accessible name and users have to fall back to numbered overlays.
- Users with cognitive disabilities: Placeholder-only forms disappear the label as soon as typing starts, so anyone who loses focus (a phone notification, a distraction) has to erase what they typed to see the hint again.
- Users of browser autofill: Chrome and Safari use labels to match fields against stored addresses; unlabelled fields do not autofill, forcing manual typing that is especially painful on mobile.
How to fix it
Concrete steps for the four platforms most small e-commerce sites run on. If you use a different stack, the underlying HTML change is the same.
Shopify
The Shopify-managed checkout labels its own fields, so the scanner rarely flags checkout itself. The usual culprit is a custom contact form or a newsletter signup. The Dawn theme's sections/contact-form.liquid ships with a <label for="…"> for every input; if your theme is a custom build or a heavily modified older theme, open Online Store > Themes, click the horizontal menu icon next to your theme, choose Edit code, find the offending section or snippet, and make sure every <input> has an associated <label for="input-id">. For app-injected forms, contact the app developer — the fix has to happen upstream.
WooCommerce
Core WooCommerce checkout fields carry labels. Missing labels usually come from customisations: a Divi or Elementor form set to hide labels visually, a custom checkout field added via a snippet without a label, or a newsletter widget in the footer. In Elementor click the field and check both the Hide Label option and the Accessible Name / Accessibility settings so a label still exists in the DOM even when visually hidden. For code-added fields, register them with woocommerce_form_field() and always pass a 'label' key — the label parameter is what WooCommerce renders as the visible <label> element.
Wix
In the Wix Editor click the form, click Edit Form, select the field, and click Settings. Type the label under Field title. To keep the label as an accessible name while hiding it visually, hover the field title in the Settings panel, click the More actions icon, and use the Show field title toggle — this hides the visual label but keeps a field title in place. Do not delete the Field title text: an empty title removes the label from the accessibility tree. The Accessibility Wizard (Settings > Accessibility Wizard) flags unlabelled fields so you can find them quickly.
Squarespace
Squarespace form blocks always render a label, but the labels can be hidden by custom CSS (a common trick to fit a compact newsletter form into a narrow footer). Open the Custom CSS panel (Design > Custom CSS) and search for rules that hide the field label with display:none or visibility:hidden — replace them with a visually-hidden pattern (position:absolute; width:1px; height:1px; overflow:hidden; clip:rect(0 0 0 0)) so the label stays available to screen readers. If the form was added via Code Injection, edit that block and add <label for="…"> for each input.
Notes
"Visually hidden" labels are fine — the label just has to exist in the DOM and be associated with the input. Placeholder text is not a label. An aria-label attribute is a valid alternative when there is genuinely no room for a visible label, but a real <label> is preferred because it also expands the click target.
Check your own site
Our accessibility statement scan is free and reports findings only — we do not certify sites.