axe-core aria-allowed-role error fallback role not supported

Not specified by the original author.

axe-core aria-allowed-role error fallback role not supported - how to fix it

TL;DR

Space-separated fallback roles are only allowed when the first role is unsupported; axe flags the pattern when the fallback itself is not a valid role for the element. Remove the fallback and use one correct role. One line of why: browsers use the first recognized role and ignore the rest, so a bad fallback list usually means the author was guessing.

The error, verbatim

{
  "id": "aria-allowed-role",
  "impact": "minor",
  "help": "ARIA roles must be appropriate for the element",
  "nodes": [
    { "target": [".card-link"], "failureSummary": "Fix any of the following: ARIA role button is not allowed for the given element" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

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

Expected: Violations array contains aria-allowed-role with the disallowed role named per node.

Step 2: Check which elements carry bad roles

node -e "const r=require('./axe-allowrole.json'); r.violations[0].nodes.forEach(function(n){console.log(n.target.join(' '))})"

Expected: Selectors for elements whose role does not fit.

Step 3: Find them in source

rg -n 'role=' src --glob '*.{jsx,tsx,vue,html}' | head -30

Expected: Shows the role assignments to correct.

Step 4: Fix the roles and re-scan

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

Expected: Exit code 0, 0 violations. Each element now exposes a role appropriate to its element type.

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

Variant phrasings

aria role not allowed for given element

The failureSummary wording, same fix.

axe role button not allowed on element

Common instance: role button on an anchor that should just be a button element.

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

HTML elements have implicit ARIA semantics, and not every role can override every element: a link cannot take role button in the allowed-role mapping axe enforces, and li elements only accept a short list. Authors add roles to fight the browser instead of using the right element. The fallback-role syntax (role="button link") is meant for forward compatibility, but axe flags it when the fallback role is itself inappropriate, which is the usual case. 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

• An anchor with an href is a link, if it acts like a button, change the element to button, not the role.
• li elements allow menuitem, option, radio, separator, tab, and treeitem among others, anything else fails.
• When the role is right but the element is wrong, fix the element, roles are a last resort, not a styling tool.
• 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_TxF6Y3YVAYoTIXJtMuMk6g

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

Thread query: axe-core aria-allowed-role error fallback role not supported

TL;DR: Space-separated fallback roles are only allowed when the first role is unsupported; axe flags the pattern when the fallback itself is not a valid role for the element. Remove the fallback and use one correct role. One line of why: browsers use the first recognized role and ignore the rest, so a bad fallback list usually means the author was guessing.

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-roles error invalid role value - how to fix it

TL;DR

Replace the invalid role with a real ARIA role (or remove it and let the element's native semantics work). Axe flags roles that do not exist in the spec, including typos like buton. One line of why: an unknown role wipes out the element's implicit semantics and assistive tech falls back to generic, so the control becomes a mystery.

The error, verbatim

{
  "id": "aria-roles",
  "impact": "critical",
  "help": "ARIA roles must be valid",
  "nodes": [
    { "target": [".nav-toggle"], "failureSummary": "Fix any of the following: ARIA role buton is not valid" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

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

Expected: Violations array contains aria-roles with the invalid role named per node.

Step 2: Extract the invalid roles

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

Expected: Lists each selector with its bogus role value.

Step 3: Find them in source

rg -n 'role=' src --glob '*.{jsx,tsx,vue,html}' | head -30

Expected: Shows every hardcoded role so you can spot the typos and invented roles.

Step 4: Fix the roles and re-scan

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

Expected: Exit code 0, 0 violations. The control now exposes a real role to assistive tech.

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

Variant phrasings

aria role buton is not valid

The failureSummary wording for a typo, fix is one character.

axe invalid aria role value

General phrasing, covers invented roles like toggle or dropdown.

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

Role values are free-form strings in HTML, so a typo like buton or an invented role like dropdown passes every build tool and only fails at scan time. Abstract roles (like widget or command) are also invalid on elements even though they exist in the spec. Axe validates against the concrete role list, so anything misspelled, abstract, or made up fails. 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

• Abstract roles (widget, composite, landmark, input) exist in the spec but are never valid on an element, use a concrete subclass.
• If the element already has the right native semantics (button, nav, main), delete the role attribute instead of fixing it.
• role presentation and role none are valid and equivalent, pick one spelling per codebase for consistency.
• 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_S8aXgDhCPPkOkGvMxFUDOw

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

Thread query: axe-core aria-roles error invalid role value

TL;DR: Replace the invalid role with a real ARIA role (or remove it and let the element's native semantics work). Axe flags roles that do not exist in the spec, including typos like buton. One line of why: an unknown role wipes out the element's implicit semantics and assistive tech falls back to generic, so the control becomes a mystery.