axe-core presentation-role-conflict error focusable content bug

Not specified by the original author.

axe-core presentation-role-conflict error focusable content bug - how to fix it

TL;DR

An element with role presentation or none must not contain focusable content: either remove the presentational role or move the focusable children out. One line of why: presentation tells assistive tech to ignore the element's semantics, but a focusable child still needs semantics, and the two instructions contradict each other.

The error, verbatim

{
  "id": "presentation-role-conflict",
  "impact": "minor",
  "help": "Elements with presentation role must not have focusable content",
  "nodes": [
    { "target": [".icon-list[role=presentation]"], "failureSummary": "Fix any of the following: Element has focusable content" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules presentation-role-conflict --save axe-pres.json

Expected: Violations array contains presentation-role-conflict with the presentational containers.

Step 2: See what is focusable inside

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

Expected: Selectors for the conflicting containers.

Step 3: Find them in source

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

Expected: Shows each presentational role usage to triage.

Step 4: Resolve the conflict and re-scan

npx @axe-core/cli https://example.com --rules presentation-role-conflict

Expected: Exit code 0, 0 violations. The list semantics are either properly exposed or the container is truly presentational with no focusable children.

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

Variant phrasings

element has focusable content presentation role

The failureSummary wording, same fix.

axe role none contains focusable element

Same conflict with the none spelling.

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

Authors put role presentation on lists and tables used for layout, then later add links or buttons inside them, creating the conflict. The role was meant to strip redundant semantics from layout tables, but once interactive content lives inside, the semantics are not redundant anymore. Axe flags any focusable descendant of a presentational element because browsers resolve the conflict inconsistently. 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

• If the list is real content, drop role presentation entirely instead of fighting it.
• role none and role presentation are equivalent, the rule treats them the same.
• A presentational wrapper around a single focusable icon button is a sign the wrapper should not exist.
• 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_vfLywCUgXbN7Jdpz-2PoJg

Resolved from the public thread: https://vectle.com/posts/pst_vfLywCUgXbN7Jdpz-2PoJg

Thread query: axe-core presentation-role-conflict error focusable content bug

TL;DR: An element with role presentation or none must not contain focusable content: either remove the presentational role or move the focusable children out. One line of why: presentation tells assistive tech to ignore the element's semantics, but a focusable child still needs semantics, and the two instructions contradict each other.

Not specified by the original author.

axe-core nested-interactive error button inside link - how to fix it

TL;DR

Un-nest the controls: a button inside a link (or a link inside a button) must become siblings, or one of them must stop being interactive. Restructure the card so the link wraps only the title text and the button sits beside it. One line of why: nested interactives create ambiguous keyboard and screen reader behavior, focus can only land on the outer one and the inner one becomes unreachable or double-announced.

The error, verbatim

{
  "id": "nested-interactive",
  "impact": "serious",
  "help": "Interactive controls must not be nested",
  "nodes": [
    { "target": ["a.card button.save"], "failureSummary": "Fix any of the following: Element has focusable descendants" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules nested-interactive --save axe-nest.json

Expected: Violations array contains nested-interactive with the nested control selectors.

Step 2: List the nested pairs

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

Expected: Selectors showing the outer and inner interactive elements.

Step 3: Find the card components in source

rg -n --glob '*.{jsx,tsx,vue}' 'card' src/components | head -20

Expected: Points at the card or tile components with the nested structure.

Step 4: Un-nest and re-scan

npx @axe-core/cli https://example.com --rules nested-interactive

Expected: Exit code 0, 0 violations. Keyboard test: tab reaches both the link and the button independently.

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

Variant phrasings

element has focusable descendants axe

The failureSummary wording, same un-nesting fix.

button nested inside anchor tag

The classic card pattern: whole card is a link with a button inside.

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

Clickable cards make the whole card an anchor for mouse users, then add a real button inside for actions like save or dismiss. HTML forbids interactive content inside anchors and buttons, and browsers handle the nesting inconsistently: the inner control may be unfocusable or may trigger both actions. Axe flags any focusable descendant of a link or button. 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

• The stretched-link pattern (link covering the card via CSS, button as a sibling above it) is the standard accessible fix.
• If the inner action navigates, make it a second link as a sibling, not a button inside the link.
• Divs with click handlers nested inside links also fail, the rule covers role-based interactives too.
• 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_jopU-QHzsCLIJwzbDKUJww

Resolved from the public thread: https://vectle.com/posts/pst_jopU-QHzsCLIJwzbDKUJww

Thread query: axe-core nested-interactive error button inside link

TL;DR: Un-nest the controls: a button inside a link (or a link inside a button) must become siblings, or one of them must stop being interactive. Restructure the card so the link wraps only the title text and the button sits beside it. One line of why: nested interactives create ambiguous keyboard and screen reader behavior, focus can only land on the outer one and the inner one becomes unreachable or double-announced.

Not specified by the original author.

axe-core focus-order-semantics error tab trap bug - how to fix it

TL;DR

Put interactive elements in a DOM order that matches the visual order, and give focusable widgets roles that match what they do. If tabbing jumps around or gets stuck, reorder the DOM or fix the roles, then re-run axe. One line of why: keyboard users navigate in DOM order, so CSS that visually reorders content without moving the DOM creates a focus path that makes no sense.

The error, verbatim

{
  "id": "focus-order-semantics",
  "impact": "minor",
  "help": "Elements in the focus order should have an appropriate role",
  "nodes": [
    { "target": [".card[tabindex]"], "failureSummary": "Fix any of the following: Element has a tabindex greater than 0 or an inappropriate role for its position in the focus order" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules focus-order-semantics --save axe-focus.json

Expected: Violations array contains focus-order-semantics with the offending selectors.

Step 2: Tab through the page manually

npx playwright test --headed || echo 'manual: press Tab from the address bar and note the jump order'

Expected: You observe focus jumping visually out of order or landing on elements with wrong roles.

Step 3: Find positive tabindex and role mismatches

rg -n 'tabindex=.?[1-9]' src --glob '*.{jsx,tsx,vue,html}' | head -20

Expected: Lists elements with positive tabindex, the most common trigger.

Step 4: Fix order and roles, then re-scan

npx @axe-core/cli https://example.com --rules focus-order-semantics

Expected: Exit code 0, 0 violations. A full keyboard pass now moves focus in visual order with no traps.

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 focus-order-semantics, WCAG 2.4.3). Experimental rule, off in some configs, enable explicitly when testing tab order. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

element has tabindex greater than 0 axe

The most common trigger phrasing, fix is tabindex 0 or -1 plus DOM order.

keyboard tab order jumps around page

The user-visible symptom this rule tries to catch.

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

Positive tabindex values pull elements out of natural DOM order into an explicit sequence that rarely matches the visual layout, and generic divs with click handlers and tabindex 0 get focus without a role that tells the user what they are. Axe flags elements whose role does not fit their position in the focus order. CSS grid and flex visual reordering without DOM reordering is the other big source: sighted mouse users see one order, keyboard users get another. 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

• Never use positive tabindex to fix order, reorder the DOM instead, positive values are almost always the bug.
• Modal dialogs need a real focus trap (focus stays inside while open), which is correct behavior, not what this rule flags.
• This rule is marked experimental, pair it with a manual keyboard pass before calling the page fixed.
• 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/pstivm-4krvyohZ9_VtoJmgQ

Resolved from the public thread: https://vectle.com/posts/pstivm-4krvyohZ9_VtoJmgQ

Thread query: axe-core focus-order-semantics error tab trap bug

TL;DR: Put interactive elements in a DOM order that matches the visual order, and give focusable widgets roles that match what they do. If tabbing jumps around or gets stuck, reorder the DOM or fix the roles, then re-run axe. One line of why: keyboard users navigate in DOM order, so CSS that visually reorders content without moving the DOM creates a focus path that makes no sense.