axe-core duplicate-id-active violation breaks focus order

Not specified by the original author.

axe-core duplicate-id-active violation breaks focus order - how to fix it

TL;DR

Make every id unique: the rule only fires when a duplicated id is on an active (focusable or referenced) element. Search for the duplicated id, rename or scope the copies, and re-run axe. One line of why: getElementById and label and aria references resolve to the first match, so duplicates silently wire labels and focus to the wrong element.

The error, verbatim

{
  "id": "duplicate-id-active",
  "impact": "serious",
  "help": "IDs of active elements must be unique",
  "nodes": [
    { "target": ["#submit-btn"], "failureSummary": "Fix any of the following: Document has multiple active elements with the same id attribute: submit-btn" }
  ]
}

Fix it step by step

Step 1: Reproduce on one page

npx @axe-core/cli https://example.com --rules duplicate-id-active --save axe-dup.json

Expected: Violations array contains duplicate-id-active with the duplicated id in the failure summary.

Step 2: Extract every duplicated id

node -e "const r=require('./axe-dup.json'); r.violations.forEach(function(v){v.nodes.forEach(function(n){console.log(n.failureSummary.match(/same id attribute: (.+)/)[1])})})"

Expected: Prints the duplicated id values, like submit-btn.

Step 3: Find the copies in source

rg -n 'submit-btn' src --glob '*.{jsx,tsx,vue,html}' | head -20

Expected: Shows each file and line rendering the same id, usually a component rendered twice.

Step 4: Deduplicate and re-scan

npx @axe-core/cli https://example.com --rules duplicate-id-active

Expected: Exit code 0, 0 violations. Tab through the page to confirm focus lands on the right control each time.

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 duplicate-id-active, WCAG 4.1.1). Same check in axe DevTools and pa11y. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

document has multiple active elements with the same id

The failureSummary wording, same dedupe fix.

duplicate id breaks label association axe

The common downstream symptom: a label points at the wrong input because ids collided.

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

Components with hardcoded ids (submit-btn, email-input) break the moment they render twice on a page, modals, repeated cards, and portaled dialogs are the classic sources. The rule only flags active elements (focusable or referenced by aria), so purely decorative duplicates slip through while the ones that break focus and label wiring get caught. React and Vue do not warn about this, so it ships silently. 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

• Use useId or a unique-id helper in components instead of hand-writing ids, it kills the whole class of bug.
• Duplicated ids inside display none subtrees can still fail if the elements are active, hiding is not deduping.
• Third-party widgets that inject fixed ids need a wrapper that rewrites the ids after mount.
• 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/pstsOp61NnWlWWJ8u3WWIWyw

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

Thread query: axe-core duplicate-id-active violation breaks focus order

TL;DR: Make every id unique: the rule only fires when a duplicated id is on an active (focusable or referenced) element. Search for the duplicated id, rename or scope the copies, and re-run axe. One line of why: getElementById and label and aria references resolve to the first match, so duplicates silently wire labels and focus to the wrong element.

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.

Not specified by the original author.

axe-core skip-link error skip link target not focusable failed - how to fix it

TL;DR

A skip link that points at a non-focusable target fails silently: keyboard users activate it and focus stays on the link. Give the target tabindex="-1" so it can receive programmatic focus, for example [main id="main" tabindex="-1"]. Keep the skip link visually hidden until focused, and test it with a keyboard from the top of the page.

The skip link is the cheapest accessibility feature on a page and the most embarrassing to get wrong. It is also the feature most likely to be broken by third-party scripts: consent banners, chat widgets, and A/B testing tools inject focusable elements before it. Re-verify skip link behavior after every third-party addition, not just at launch.

The verbatim error looks like this:

axe-core 4.x
Rule: skip-link (moderate)
"Ensure all skip links have a focusable target"

Element: [a href="#main" class="skip-link"]Skip to main content[/a]
  Target [main id="main"] is not focusable; activating the link moves nothing.

Steps

1. Reproduce with the single rule:

npx @axe-core/cli https://example.com/ --rules skip-link

Expected: the skip link is listed because its target cannot receive focus.

2. Check the target element. [main], [div id="main"], and most landmarks are not focusable by default, which is the usual cause.
3. Make the target focusable:

[a href="#main" class="skip-link"]Skip to main content[/a]
[main id="main" tabindex="-1"]...[/main]

tabindex="-1" allows programmatic focus without adding the target to the tab order.

4. Re-run the focused scan. Expected output: 0 violations for skip-link.
5. Keyboard-test from a fresh page load: press Tab once, confirm the skip link becomes visible, activate it, and confirm focus lands at the start of the main content.
6. Audit what comes before the skip link in the final rendered DOM. View source is not enough; scripts inject content. Use devtools to inspect the first tabbable elements on a fresh load with all third-party scripts running.
7. Style the skip link to be visually hidden but not display:none, and reveal it on focus:

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 8px;
  top: 8px;
}

A skip link nobody can see when focused helps nobody.

When to use

• Axe flags skip-link on a skip navigation link.
• A page has a skip link but keyboard users report it does nothing.
• An audit lists a non-focusable skip target as a moderate violation.

When not to use

• The page has no skip link at all (add one as the first focusable element).
• The skip link points at the wrong landmark (fix the href target).
• The target is inside a modal or hidden region (restructure; the main content must exist on page load).

Why it happens

Skip links exist so keyboard users can bypass repeated navigation. When the target is not focusable, the browser may scroll visually but focus stays behind, so the next Tab press sends the user right back into the nav they tried to skip. tabindex="-1" is the standard fix because it enables focus without polluting the tab order.

Skip links date to the earliest web accessibility guidance, and every accessibility checklist mentions them, which is why pages have them and why they are often broken: they were added to satisfy a checklist, then never tested. The tabindex="-1" requirement is the detail that checklist-driven implementations miss, because the link appears to work visually (the page scrolls) while focus stays behind.

Edge cases

• Single-page apps that replace [main] on route change must re-apply tabindex="-1" to the new target or move focus to the new view's heading instead.
• The skip link itself must be the first tabbable element. Consent banners or chat widgets injected before it break the pattern.
• Do not hide the skip link with display:none; use the visually-hidden-until-focused pattern so it appears on keyboard focus.
• If the main landmark has an accessible name via aria-label, keep it; the skip target fix is independent.
• Multiple skip links (to main content, to navigation, to search) are fine; each target needs tabindex="-1".
• In SPAs, route changes should move focus to the new view's heading or main landmark. A skip link alone does not handle route-change focus.
• Do not point the skip link at an element inside a collapsed accordion or tab. The target must be visible and focusable on load.

Provenance

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

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

Thread query: axe-core skip-link error skip link target not focusable failed

TL;DR: A skip link that points at a non-focusable target fails silently: keyboard users activate it and focus stays on the link. Give the target tabindex="-1" so it can receive programmatic focus, for example [main id="main" tabindex="-1"]. Keep the skip link visually hidden until focused, and test it with a keyboard from the top of the page.