axe-core aria-required-attr error missing required aria attribute

Not specified by the original author.

axe-core aria-required-attr error missing required aria attribute - how to fix it

TL;DR

Add the required attribute the role demands: aria-valuenow on sliders and progressbars, aria-expanded on disclosure buttons, and so on. Axe names the missing attribute in the failure summary, so add exactly that. One line of why: some roles are meaningless without their required state, a slider with no value is just a div to a screen reader.

The error, verbatim

{
  "id": "aria-required-attr",
  "impact": "critical",
  "help": "Required ARIA attributes must be provided",
  "nodes": [
    { "target": [".volume-slider"], "failureSummary": "Fix any of the following: Required ARIA attribute not present: aria-valuenow" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules aria-required-attr --save axe-req.json

Expected: Violations array contains aria-required-attr with the missing attribute named per node.

Step 2: Extract the missing attributes

node -e "const r=require('./axe-req.json'); r.violations[0].nodes.forEach(function(n){console.log(n.target.join(' '), '-', n.failureSummary.match(/not present: ([\w-]+)/)[1])})"

Expected: Pairs each selector with the attribute it needs.

Step 3: Find the widgets in source

rg -n 'role=.slider|role=.progressbar' src --glob '*.{jsx,tsx,vue}' | head -20

Expected: Shows the custom widgets missing their required attributes.

Step 4: Add the attributes and re-scan

npx @axe-core/cli https://example.com --rules aria-required-attr

Expected: Exit code 0, 0 violations. The slider now announces its value as it moves.

Step 5: Gate the rule in CI

npx @axe-core/cli https://example.com --exit | tail -3

Expected: Non-zero exit while any violation remains; add this command to CI so the fix never regresses.

When to use this skill

• Your axe-core report lists this exact rule id under violations
• You are clearing automated WCAG 2.1 AA failures before a release or audit
• A CI a11y gate (pa11y-ci, lighthouse CI, cypress-axe) is red because of this rule

When NOT to use this skill

• The issue only shows up in manual screen-reader testing and axe reports zero violations for the rule
• You are doing a full manual WCAG audit, this skill covers the single automated rule only
• The page is a third-party embed you cannot edit, flag it to the vendor instead

Compatibility

axe-core 4.8+ (rule aria-required-attr, WCAG 4.1.2). Same rule in axe DevTools, pa11y, and cypress-axe. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

required aria attribute not present aria-valuenow

The failureSummary wording for sliders and progressbars.

axe custom slider missing aria attributes

The classic instance: hand-rolled range inputs.

axe DevTools flags the same rule

The browser extension runs the same rule engine; fix once and it clears in every runner.

Why it happens

Custom widgets copy the role but forget the required attributes that come with it: slider needs aria-valuenow (plus min and max), checkbox needs aria-checked, scrollbar needs its value set. Axe checks the required attribute list per role from the ARIA spec. Native inputs (input type range, input type checkbox) carry these semantics natively, which is why the rule almost always fires on custom-built widgets. The same violation usually repeats on every page built from the same template, so fix the component or template once instead of patching pages. After the fix, re-scan the whole site, not just the one page, to confirm the template-level change cleared them all.

Edge cases

• aria-valuemin and aria-valuemax have defaults (0 and 100) but aria-valuenow has no default, it must be set and updated.
• If the widget state changes, update the attribute with it, a stale aria-valuenow fails the spirit of the rule even if axe passes.
• Consider native elements first: input type range with a label needs none of this.
• Fix every instance of the rule before moving on; a half-fixed rule across templates re-fails the next full scan.

Provenance

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

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

Thread query: axe-core aria-required-attr error missing required aria attribute

TL;DR: Add the required attribute the role demands: aria-valuenow on sliders and progressbars, aria-expanded on disclosure buttons, and so on. Axe names the missing attribute in the failure summary, so add exactly that. One line of why: some roles are meaningless without their required state, a slider with no value is just a div to a screen reader.

Not specified by the original author.

axe-core aria-required-children role combobox missing error - how to fix it

TL;DR

A combobox must own a listbox (and the listbox must own options). If you built a custom dropdown, add role listbox to the popup container and role option to each item, wired with aria-owns or DOM nesting. One line of why: the ARIA spec requires combobox to contain or own a listbox, and axe fails the widget when the required child role is missing.

The error, verbatim

{
  "id": "aria-required-children",
  "impact": "critical",
  "help": "Certain ARIA roles must contain particular children",
  "nodes": [
    { "target": [".custom-select"], "failureSummary": "Fix any of the following: Required ARIA child role not present: listbox" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules aria-required-children --save axe-combo.json

Expected: Violations array contains aria-required-children with the combobox selector in nodes.

Step 2: Inspect the widget structure

node -e "const r=require('./axe-combo.json'); const n=r.violations[0].nodes[0]; console.log(n.target.join(' '), n.html.slice(0,160))"

Expected: You see the combobox element and can confirm the popup div has no listbox role.

Step 3: Confirm the owned roles are missing

rg -n --glob '*.{jsx,tsx}' 'role=.listbox|role=.option' src/components/select | head -20

Expected: No output or only partial matches, confirming the popup items lack the required roles.

Step 4: Add the roles and re-scan

npx @axe-core/cli https://example.com --rules aria-required-children

Expected: Exit code 0, 0 violations. Keyboard test: arrow keys move through options and the screen reader announces the listbox.

Step 5: Gate the rule in CI

npx @axe-core/cli https://example.com --exit | tail -3

Expected: Non-zero exit while any violation remains; add this command to CI so the fix never regresses.

When to use this skill

• Your axe-core report lists this exact rule id under violations
• You are clearing automated WCAG 2.1 AA failures before a release or audit
• A CI a11y gate (pa11y-ci, lighthouse CI, cypress-axe) is red because of this rule

When NOT to use this skill

• The issue only shows up in manual screen-reader testing and axe reports zero violations for the rule
• You are doing a full manual WCAG audit, this skill covers the single automated rule only
• The page is a third-party embed you cannot edit, flag it to the vendor instead

Compatibility

axe-core 4.8+ (rule aria-required-children, WCAG 1.3.1 / 4.1.2). Same rule runs in axe-playwright, cypress-axe, and axe DevTools. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

required aria child role not present listbox

The failureSummary wording for combobox widgets missing their popup listbox.

custom dropdown axe combobox error

Practitioner phrasing: hand-rolled select components trip this constantly.

axe DevTools flags the same rule

The browser extension runs the same rule engine; fix once and it clears in every runner.

Why it happens

ARIA defines required owned elements per role, and combobox requires listbox (or tree, grid, dialog in the 1.2 pattern). Custom dropdowns usually get the combobox role and the expanded state right but render the popup as plain divs, so the ownership chain is broken. Axe checks the computed ownership including aria-owns, so even correctly nested markup fails if an intermediate wrapper breaks the parent-child role chain. The same violation usually repeats on every page built from the same template, so fix the component or template once instead of patching pages. After the fix, re-scan the whole site, not just the one page, to confirm the template-level change cleared them all.

Edge cases

• A combobox with aria-expanded false still needs the listbox present or owned, lazy-mounting the popup only when opened fails the scan.
• If you use aria-owns to wire a portaled popup, the owned element must exist in the DOM at scan time.
• Native select elements do not need any of this, if you can use a native select, do that instead of fixing the custom one.
• Fix every instance of the rule before moving on; a half-fixed rule across templates re-fails the next full scan.

Provenance

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

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

Thread query: axe-core aria-required-children role combobox missing error

TL;DR: A combobox must own a listbox (and the listbox must own options). If you built a custom dropdown, add role listbox to the popup container and role option to each item, wired with aria-owns or DOM nesting. One line of why: the ARIA spec requires combobox to contain or own a listbox, and axe fails the widget when the required child role is missing.

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.