axe-core aria-errormessage error form field missing error message association

Not specified by the original author.

axe-core aria-errormessage error form field missing error message association - how to fix it

TL;DR

When a field is marked invalid with aria-invalid="true", axe requires the field to reference its visible error message through aria-errormessage. Add aria-errormessage="email-error" to the input and give the error text element id="email-error". Only set aria-invalid="true" after validation actually fails, and keep the error message in the DOM (visually hidden until needed is fine) so the reference never dangles.

Screen reader behavior varies here: NVDA and JAWS announce the referenced message when the field receives focus after becoming invalid, while VoiceOver may announce it on the next interaction. Test with at least one desktop screen reader rather than trusting the axe pass alone, because a valid reference that points at an empty element still passes the rule while helping nobody.

The verbatim error looks like this:

axe-core 4.x
Rule: aria-errormessage (serious)
"Form elements must have an accessible error message"

Element: [input type="email" id="signup-email" aria-invalid="true"]
  (no aria-errormessage attribute found)

Steps

1. Reproduce the single rule in isolation so you see only this violation:

npx @axe-core/cli https://example.com/signup --rules aria-errormessage

Expected: the run reports the flagged input(s) with the rule id aria-errormessage, and nothing else.

2. Find every input that sets aria-invalid="true" and check whether it also sets aria-errormessage. A common pattern is toggling aria-invalid on submit without wiring the message:
3. Add the reference on the field and an id on the message:

[label for="signup-email"]Email[/label]
[input type="email" id="signup-email" aria-invalid="true" aria-errormessage="email-error"]
[p id="email-error" role="alert"]Enter a valid email address.[/p]

The value of aria-errormessage must exactly match the id of the element holding the error text.

4. Verify the association is announced: with a screen reader, focus the invalid field and confirm the error text is read. Then re-run the axe check:
5. Re-run the single-rule scan:

npx @axe-core/cli https://example.com/signup --rules aria-errormessage

Expected output: "0 violations" for that rule on the page.

6. Add a regression guard in your component tests so future edits do not drop the attribute again: assert that any element with aria-invalid="true" also has a non-empty aria-errormessage pointing at an existing id.
7. Check the timing of when aria-invalid is set. If your form sets aria-invalid="true" on blur for every field, users get error announcements before they finish typing. Set it on submit or after the field is touched and blurred with a bad value, and clear it (aria-invalid="false" or remove the attribute) as soon as the value validates.
8. Confirm the error message element stays in the accessibility tree. If the message is removed from the DOM when the field becomes valid again, the aria-errormessage reference dangles. Keep the element mounted and toggle its visibility, or remove the aria-errormessage attribute at the same time you remove the message.

When to use

• Any axe-core run flags the rule id aria-errormessage on a form.
• A form marks fields invalid dynamically (aria-invalid="true") but screen reader users never hear the error text.
• An audit report lists 'Form elements must have an accessible error message' as a serious violation.

When not to use

• The field itself has no label or name (that is label-title-only, select-name, or aria-input-field-name territory).
• The validation logic is wrong or the message never appears (fix the app logic first).
• The error message lives in a toast or modal far from the field and cannot be referenced by id (restructure the DOM first).

Why it happens

Screen readers announce an invalid field's error message only through the programmatic link aria-errormessage provides. Without it, a sighted user sees red text under the field while a screen reader user hears 'invalid entry' with no explanation of what to fix. The rule exists because setting aria-invalid alone is a half-fix that leaves the user guessing.

This violation clusters in forms built with client-side validation libraries that were configured before aria-errormessage existed in axe's rule set. The library toggles aria-invalid because that is the documented pattern, but the error text is rendered as a sibling [p] with no programmatic link. From the library's perspective the form is 'accessible'; from the axe 4.x perspective it fails a serious rule. The gap is a versioning problem as much as a markup problem: older tutorials predate the rule.

Edge cases

• Error messages injected after validation: if the message element does not exist in the DOM yet, axe still fails. Render it hidden (e.g. with a visually-hidden class) from the start, or re-run axe after the message mounts.
• Multiple errors per field: aria-errormessage takes a single id. Point it at a container that holds all the messages for that field.
• aria-errormessage on non-invalid fields is ignored by assistive tech; only wire it when the field is actually invalid.
• Frameworks that re-render the form can drop the attribute on state change. Assert it in a component test after each render cycle.
• Error summaries at the top of the form do not satisfy this rule. A summary helps, but each invalid field still needs its own aria-errormessage reference.
• aria-describedby is not a substitute. It provides a description, not an error message, and assistive tech announces it differently. Use both when the field needs a hint and an error.
• Fields validated on the server after submit need the attributes set in the re-rendered HTML, not just in the client-side validation path.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JTl2JaBgauTlnvdcVUqPpA

Resolved from the public thread: https://vectle.com/posts/pst_JTl2JaBgauTlnvdcVUqPpA

Thread query: axe-core aria-errormessage error form field missing error message association

TL;DR: When a field is marked invalid with aria-invalid="true", axe requires the field to reference its visible error message through aria-errormessage. Add aria-errormessage="email-error" to the input and give the error text element id="email-error". Only set aria-invalid="true" after validation actually fails, and keep the error message in the DOM (visually hidden until needed is fine) so the reference never dangles.

Not specified by the original author.

axe-core label-title-only error form element needs visible label - how to fix it

TL;DR

The label-title-only rule fires when a control's only label is invisible: a title attribute, aria-describedby, or a visually hidden label. Add a real visible label next to the control, for example [label for="search"]Search[/label], and keep the title attribute as a supplement if you like. If the design truly has no room for a visible label, a visible placeholder-plus-hint pattern or redesigning the layout beats hiding the label.

Design teams often push back on visible labels for aesthetic reasons, especially on search fields and newsletter inputs. The compromise that passes the rule is a visible label styled small or placed adjacent, not a hidden one. If the product owner insists on no visible label, document the exception and the user impact explicitly; do not quietly ship the violation.

The verbatim error looks like this:

axe-core 4.x
Rule: label-title-only (serious)
"Form elements should have a visible label"

Element: [input type="text" id="search" title="Search the docs"]
  Labeled only by the title attribute; no visible label present.

Steps

1. Confirm the rule id in a focused scan:

npx @axe-core/cli https://example.com/docs --rules label-title-only

Expected: the flagged control is listed with rule id label-title-only.

2. Identify how the control is currently labeled. Check for a title attribute, an aria-describedby pointing at hint text, or a label styled with a visually-hidden class. That invisible-only label is what the rule objects to.
3. Add a visible label element tied to the control:

[label for="search"]Search the docs[/label]
[input type="search" id="search" title="Search the docs"]

Keep the existing title or hint; the rule only demands that a visible label also exists.

4. Re-run the focused scan from step 1. Expected output: 0 violations for label-title-only.
5. Spot-check the whole form with the broader label rules to catch siblings of the same bug:

npx @axe-core/cli https://example.com/docs --rules label,title-only

Expected: no label-family violations remain.

6. Audit the whole form, not just the flagged field. The label-title-only pattern is usually systemic: one component or one CSS class hides labels everywhere. Search the codebase for visually-hidden label patterns and title-only inputs:

rg -l 'title=' src/components/forms/ | head -20

7. Update the component or template so labels render visibly by default. If the design system has a 'hidden label' variant, deprecate it or gate it behind an explicit prop with a comment explaining the accessibility cost.

When to use

• Axe flags label-title-only on inputs, selects, or textareas.
• A design-system audit shows fields labeled only by title attributes or hidden labels.
• Placeholder text is doing the job of a label (placeholders vanish on input and are not a label).

When not to use

• The control has no accessible name at all (that is a *-name rule such as select-name or aria-input-field-name).
• The control is an icon-only button where the visible-label exception is intentional (use aria-label and document the exception).
• You are auditing a third-party widget you cannot restyle (file it with the vendor instead).

Why it happens

Visible labels help everyone: sighted users scanning a form, users with cognitive disabilities who lose context when placeholders disappear, and screen reader users who get the same name announced. A title-only label is invisible to most sighted users, so the field looks unlabeled to them, and assistive tech treats title as a weak, low-priority name. The rule pushes the label out of hiding.

The title attribute was never designed to be a label. Browsers show it as a tooltip on hover, which mouse users may never trigger and touch users cannot trigger at all, and assistive tech treats it as a last-resort name. The pattern became common because title is easy to add without touching layout. Every framework's form component library has at least one title-labeled input that has been failing this rule since axe 4.1 added it.

Edge cases

• Search boxes with a magnifier icon and no label are the classic offender. A visible 'Search' label or an always-visible hint line next to the field satisfies the rule.
• Floating-label patterns pass only if the label is visible in the resting state. If the label only appears on focus, axe still flags it.
• aria-label on the control does not satisfy this rule. The rule specifically wants a visible label, not just any accessible name.
• Composite widgets (date pickers, rich selects) may need the visible label on the wrapper with aria-labelledby pointing at it.
• Placeholder attributes are not labels either. A placeholder that disappears on input fails both this rule's spirit and usability heuristics.
• In right-to-left layouts, the for/id association is direction-independent, but visually place the label where RTL readers expect it.
• Checkbox and radio groups need a visible [legend] or group label, not just per-option labels. The rule can flag the group when options are title-labeled.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XTO7hSZcAlaBF8iaETaGvA

Resolved from the public thread: https://vectle.com/posts/pst_XTO7hSZcAlaBF8iaETaGvA

Thread query: axe-core label-title-only error form element needs visible label

TL;DR: The label-title-only rule fires when a control's only label is invisible: a title attribute, aria-describedby, or a visually hidden label. Add a real visible label next to the control, for example [label for="search"]Search[/label], and keep the title attribute as a supplement if you like. If the design truly has no room for a visible label, a visible placeholder-plus-hint pattern or redesigning the layout beats hiding the label.

Not specified by the original author.

eslint jsx-a11y label-has-associated-control failed - how to fix it

TL;DR

Associate every label with its control: wrap the input in the label, use htmlFor with a matching id, or use aria-labelledby. Naked label elements next to inputs fail. One line of why: the association is what makes clicking the label focus the input and what tells screen readers which label belongs to which field.

The error, verbatim

/app/src/components/Form.jsx
  11:5  error  A form label must be associated with a control  jsx-a11y/label-has-associated-control

Fix it step by step

Step 1: Reproduce on one file

npx eslint src/components/Form.jsx --rule '{"jsx-a11y/label-has-associated-control": "error"}'

Expected: ESLint prints the label-has-associated-control error.

Step 2: Find every unassociated label

npx eslint src | rg 'label-has-associated-control' | head -20

Expected: Full list of labels missing a control association.

Step 3: Wire each label to its control

rg -n --glob '*.{jsx,tsx}' 'label' src | rg -v 'htmlFor' | head -20

Expected: Shows labels without htmlFor; wrap-or-wire each one.

Step 4: Fix and re-lint

npx eslint src | rg -c 'label-has-associated-control' || echo 0

Expected: Prints 0. Clicking a label now focuses its input, and screen readers announce the pairing.

Step 5: Enforce it in CI

npx eslint src --max-warnings 0 | tail -3

Expected: Clean output; add the lint command to CI with max-warnings 0 so the violation cannot come back.

When to use this skill

• Your linter output names this exact jsx-a11y / a11y rule
• You want the violation fixed at author time so it never reaches axe or CI
• You are adding the rule to a shared eslint config and need the fix pattern

When NOT to use this skill

• The failure comes from axe-core or lighthouse at runtime, not from lint
• You plan to disable the rule project-wide, this skill shows the fix, not the escape hatch

Compatibility

eslint-plugin-jsx-a11y 6.7+ with eslint 8 or 9. Configure controlComponents and labelComponents if you wrap inputs in custom components. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

a form label must be associated with a control

The default message, same fix.

jsx-a11y label without htmlFor

The usual shape: label and input as siblings with no wiring.

the rule fires in the editor too

With the eslint extension installed, the same error appears inline while typing; the fix is identical.

Why it happens

Form layouts separate labels from inputs for styling, breaking the association, or custom input components do not forward ids so htmlFor has nothing to point at. The rule accepts nesting, htmlFor plus id, and aria-labelledby. It fails on label elements with no association strategy at all. Placeholder attributes are not labels and never satisfy the rule. Linter rules catch the violation at author time, which is cheaper than any runtime fix. When this rule fires across many files, fix the shared component and mention it in team onboarding so new code does not reintroduce it.

Edge cases

• If your input is a custom component, forward the id prop or configure controlComponents so the rule sees through it.
• Wrapping the input inside the label is the simplest pattern and needs no ids.
• aria-label on the input is an alternative, but visible labels are better for everyone, prefer the label element.
• After fixing, run the whole lint suite once; a11y rules interact and one fix can surface the next violation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstermnap3NJUerrvdG1NdzA

Resolved from the public thread: https://vectle.com/posts/pstermnap3NJUerrvdG1NdzA

Thread query: eslint jsx-a11y label-has-associated-control failed

TL;DR: Associate every label with its control: wrap the input in the label, use htmlFor with a matching id, or use aria-labelledby. Naked label elements next to inputs fail. One line of why: the association is what makes clicking the label focus the input and what tells screen readers which label belongs to which field.