WCAG fix guide
How to Fix Missing Form Labels (WCAG 2.2)
Applies to: SC 1.3.1 Info and Relationships (A) · SC 3.3.2 Labels or Instructions (A) · SC 4.1.2 Name, Role, Value (A) · SC 2.5.3 Label in Name (A)
Missing form input labels were found on 51% of home pages in the WebAIM Million 2026 (detected with WebAIM's WAVE tool) (WebAIM). Newsletter sign-ups and search boxes are frequent culprits.
How to fix
- Use a visible
<label>tied to the input:
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">
- Placeholder is not a label. It disappears as the user types and often fails contrast.
- If a visible label truly isn't possible (e.g. a search box with a button): use
aria-labeloraria-labelledby, and make sure the accessible name contains any visible text (SC 2.5.3). - Group related controls (radio buttons, checkboxes) with
<fieldset>and<legend>. - Instructions and errors: link them with
aria-describedby. See also SC 3.3.1 Error Identification. - Add
autocompletefor personal-data fields (SC 1.3.5).
See the W3C forms tutorial.
CMS-specific steps
- WordPress: Most label problems come from form plugins or theme search/newsletter widgets. In the plugin's field settings, make sure "hide label" uses a screen-reader-only class rather than removing the label. Test the rendered HTML.
- Shopify: The newsletter and search inputs in themes often depend on placeholders. Check the theme code (
sections//snippets/) for a<label>(a visually hidden one is fine), or ask the theme developer. - Webflow: Form blocks include Label elements. Don't delete them; to hide one visually, use a visually-hidden class. Check the label's "For" setting matches the input ID.
- Squarespace / Wix: Use the built-in form blocks and keep field titles turned on. Third-party embeds need separate testing.
WordPress, Shopify, Webflow, Squarespace and Wix are trademarks of their respective owners. Glimscope is not affiliated with or endorsed by any of them.
What automated tools can and can't tell you: Automated checkers (including axe-core, which our monitor uses) can flag many instances of this issue, but they cannot judge everything. A human still has to check meaning and context. For scale: Deque reports that in its own sample of first-time audits, its automated tests found 57.38% of issues by volume (Deque report). That is Deque's figure for its sample, not a detection rate for any one tool, and it means a large share of issues still needs manual testing. Scanners reliably detect inputs with no accessible name. They cannot judge whether a label is clear, or whether error messages make sense. Automated tests find only some accessibility issues; manual testing is still required. Not legal advice.
Manual checklist
- Every field has a visible, descriptive label
- Clicking the label focuses the field
- Screen reader announces the label, required state, and errors
Sources
- www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html
- www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html
- www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
- www.w3.org/WAI/WCAG22/Understanding/label-in-name.html
- webaim.org/projects/million/
- www.w3.org/WAI/WCAG22/Understanding/error-identification.html
- www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html
- www.w3.org/WAI/tutorials/forms/labels/
- www.deque.com/automated-accessibility-coverage-report/
Check your own site
Run a free automated scan of one page to check it for some issues like this one.
Automated tests find only some accessibility issues; manual testing is still required. Not legal advice.