How to fix label on Headless / Custom (I build in code)

Add a visible or programmatic label to every form input so assistive technologies can identify it for users.

Steps for Headless / Custom (I build in code)

  1. In your component or template file, ensure every `<input>`, `<select>`, and `<textarea>` has one of: (a) a `<label for='x'>` with a matching `id='x'` on the input; (b) the input wrapped inside a `<label>` element; (c) an `aria-label='...'` attribute on the input; or (d) `aria-labelledby='id-of-visible-text'` pointing to existing text.
  2. Create a reusable `<FormField>` (React), a `field` component (Vue), or a partial (any framework) that always outputs a label + input pair, making unlabelled fields structurally impossible.
  3. Add an automated accessibility test (axe-core, jest-axe, Playwright with axe) to your CI pipeline to catch regressions before deploy.
  4. Verify in a browser with the axe DevTools extension.
Official Headless / Custom (I build in code) documentation ↗

What is label?

Every form field on your site — search boxes, email sign-up fields, checkout inputs, contact forms — must have a label that describes what the field is for. A "label" in web terms is either a visible `<label>` element paired with the input, or a special accessibility attribute (like `aria-label`) that provides the same description invisibly. When a form field has no label at all, the browser and assistive technology have nothing to announce to the user about what that field is asking for. WCAG Success Criterion 4.1.2 requires all form controls to have a name that assistive technology can read out loud.

Screen-reader users — including customers with visual impairments — will hear something like "edit text, blank" when they reach an unlabelled field, with no clue what to type. This makes checkout, sign-up, and contact forms completely unusable for those customers, directly costing you sales and leads. From a legal standpoint, unlabelled form fields are one of the most frequently cited accessibility violations in ADA and WCAG-based lawsuits and demand letters targeting e-commerce stores. Google also uses accessible markup signals as a quality indicator, so fixing labelling issues supports your site's overall technical health. Fixing this is typically a quick code change that immediately improves usability for everyone, including mobile users who rely on tap-targets and auto-fill.

See the complete Label guide for every platform and the full background.

Not sure if your Headless / Custom (I build in code) store has this?

Run a free SEOLZ scan — we’ll find label and every other issue across your whole site.

Scan my site free

Fix label on another platform