axe-core aria-conditional-attr error: aria attribute not allowed in this state

Not specified by the original author.

axe-core aria-allowed-attr error unsupported aria attribute - how to fix it

TL;DR

Remove or replace the aria attribute the element's role does not support: check the ARIA spec for which attributes each role allows, then delete the offender or move it to an element whose role allows it. One line of why: unsupported aria attributes are ignored by assistive tech, so the information you thought you conveyed never arrives.

The error, verbatim

{
  "id": "aria-allowed-attr",
  "impact": "critical",
  "help": "ARIA attributes must be valid for the element role",
  "nodes": [
    { "target": ["[aria-checked].toggle"], "failureSummary": "Fix any of the following: ARIA attribute is not allowed: aria-checked" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

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

Expected: Violations array contains aria-allowed-attr with the attribute name in each failure summary.

Step 2: Extract the offending attribute names

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

Expected: Pairs each selector with its disallowed attribute.

Step 3: Find them in source

rg -n 'aria-checked' src --glob '*.{jsx,tsx,vue}' | head -20

Expected: Shows where the bad attribute is set, substitute your attribute name.

Step 4: Fix the attributes and re-scan

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

Expected: Exit code 0, 0 violations. The widget still announces its state because the attribute now lives on a role that supports it.

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-allowed-attr, WCAG 4.1.2). Catches typos like aria-labeledby too, which is really the aria-valid-attr sibling rule. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

aria attribute is not allowed aria-checked

The failureSummary wording, same fix.

axe unsupported aria attribute on role

General phrasing, fix is always remove, replace, or move the attribute.

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

Every ARIA role supports a defined set of states and properties, and authors routinely copy aria attributes between widgets (aria-checked from a checkbox onto a toggle button with role switch is fine, onto a plain button is not). Axe validates each attribute against the element's computed role. Custom elements and web components are frequent offenders because the role is set in shadow DOM while the attributes sit on the host. 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-checked is allowed on checkbox, radio, menuitemcheckbox, menuitemradio, and switch, not on button, move it or change the role.
• Global aria attributes (aria-label, aria-hidden, aria-describedby and friends) are allowed on every role, the rule knows the global list.
• Misspelled attributes like aria-labeledby fail the sibling rule aria-valid-attr instead, check both rules when cleaning up.
• 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_8AMQnMHsFBaF9lO28WxMTg

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

Thread query: axe-core aria-allowed-attr error unsupported aria attribute

TL;DR: Remove or replace the aria attribute the element's role does not support: check the ARIA spec for which attributes each role allows, then delete the offender or move it to an element whose role allows it. One line of why: unsupported aria attributes are ignored by assistive tech, so the information you thought you conveyed never arrives.

Not specified by the original author.

axe-core aria-prohibited-attr error: aria attribute prohibited on this role - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. An aria attribute sits on a role that forbids it, so assistive tech ignores the attribute and the intended behavior never happens. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-prohibited-attr error: aria attribute prohibited on this role

Fix it step by step

Step 1

Read the failure summary to see which attribute the role prohibits.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

Remove the prohibited attribute from the element, or change the element's role to one that allows it.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Move the lost information elsewhere: visible text, a different attribute the role allows, or a wrapper element.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe; the rule passes when the attribute is gone or the role now permits it.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Do not keep the attribute and hope screen readers honor it; prohibited means ignored.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-prohibited-attr). Check the ARIA spec for allowed attributes per role.

Variant phrasings

axe aria-prohibited-attr: attribute not allowed on this role

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

An aria attribute sits on a role that forbids it, so assistive tech ignores the attribute and the intended behavior never happens. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_19plcG4nBI97tdNnJ6-ryQ

Resolved from the public thread: https://vectle.com/posts/pst_19plcG4nBI97tdNnJ6-ryQ

Thread query: axe-core aria-prohibited-attr error: aria attribute prohibited on this role

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. An aria attribute sits on a role that forbids it, so assistive tech ignores the attribute and the intended behavior never happens. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core aria-valid-attr-value error invalid value for aria-checked - how to fix it

TL;DR

Set aria-checked to a valid value - true, false, or mixed, never yes, no, on, off, or 1 and 0. The same applies to every enumerated aria attribute, check the allowed values and fix the binding. One line of why: assistive tech only understands the spec's token list, anything else is treated as missing.

The error, verbatim

{
  "id": "aria-valid-attr-value",
  "impact": "critical",
  "help": "ARIA attributes must have valid values",
  "nodes": [
{"failureSummary":"Fix any of the following: Invalid ARIA attribute value: aria-checked="maybe"","target":[".toggle"]}
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules aria-valid-attr-value --save axe-val.json

Expected: Violations array contains aria-valid-attr-value with the bad value in each failure summary.

Step 2: Extract the bad values

node -e "const r=require('./axe-val.json'); r.violations[0].nodes.forEach(function(n){console.log(n.target.join(' '), '-', n.failureSummary.match(/Invalid ARIA attribute value: ([^\n]+)/)[1])})"

Expected: Lists each attribute with its invalid value.

Step 3: Find the bindings in source

rg -n 'aria-checked' src --glob '*.{jsx,tsx,vue}' | head -20

Expected: Shows the bindings producing the bad values, often a boolean rendered as a string.

Step 4: Correct the values and re-scan

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

Expected: Exit code 0, 0 violations. The toggle now announces checked and unchecked correctly.

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-valid-attr-value, WCAG 4.1.2). Same engine in axe DevTools and pa11y. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

invalid aria attribute value aria-checked

The failureSummary wording, same fix.

axe aria attribute must have valid values

General phrasing covering all enumerated attributes like aria-sort or aria-current.

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

Framework bindings love rendering raw values into aria attributes: a JS boolean true becomes the string true (fine), but a custom state like maybe or a 1 and 0 pair does not map to the spec's token list. For aria-checked the only valid values are true, false, and mixed. Axe validates against the ARIA value types (true/false, tristate, token lists, ids), so anything outside the type fails even if it looks sensible to a human. 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

• In JSX, aria-checked={someBoolean} renders true and false correctly, the bug is usually a string like yes coming from state.
• mixed is only valid on checkbox and menuitemcheckbox, do not use it as a third state elsewhere.
• aria-hidden takes true, false, and the string undefined, the string false is fine, omitting the attribute is not the same.
• 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_7xuDhsqjuad5ckoukyukBQ

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

Thread query: axe-core aria-valid-attr-value error invalid value for aria-checked

TL;DR: Set aria-checked to a valid value - true, false, or mixed, never yes, no, on, off, or 1 and 0. The same applies to every enumerated aria attribute, check the allowed values and fix the binding. One line of why: assistive tech only understands the spec's token list, anything else is treated as missing.