a11y scan agent failed to inject axe into shadow root

Not specified by the original author.

a11y scan agent failed to inject axe into shadow root - how to fix it

TL;DR

Inject at the document level and let axe's flattened tree handle shadow DOM: axe-core 4.3+ analyzes open shadow roots automatically, so the agent does not need per-shadow-root injection. The failure usually means an old axe-core or a closed shadow root. One line of why: axe composes the flattened tree itself, per-root injection fights the tool's own design.

The error, verbatim

ScanAgentError: failed to inject axe into shadow root
    host: my-datepicker (open shadow root)
    axe-core: 4.1.0 (bundled with agent)

Fix it step by step

Step 1: Reproduce the injection failure

node agent/run-audit.js --route /booking | rg -i 'shadow|inject' | head -5

Expected: The shadow-root injection error repeats.

Step 2: Check the bundled axe version

node -e "console.log(require('axe-core/package.json').version)"

Expected: An old bundled axe-core explains the failure; upgrade the agent's dependency.

Step 3: Upgrade and simplify

npm install axe-core@^4.8 --save | tail -2

Expected: Modern axe-core handles open shadow roots via the flattened tree with document-level injection.

Step 4: Re-run the audit

node agent/run-audit.js --route /booking | tail -4

Expected: Shadow DOM content is analyzed with no per-root injection.

Step 5: Add a regression probe

node agent/run-audit.js --smoke | tail -3

Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.

When to use this skill

• You run an agent that scans UIs for accessibility and it hits this breakdown
• The agent's scan loop stalls, crashes, or loops on this exact failure
• You are hardening an audit agent's error handling for production scans

When NOT to use this skill

• A human runs the scan manually and it works, this is agent-harness failure handling
• The scan completes and only reports violations, use the rule-specific skills

Compatibility

Scan agent with axe-core 4.8+. Closed shadow roots remain unauditable by design. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

agent axe shadow dom injection failed

Same failure, same upgrade.

axe cannot see web component content

Practitioner phrasing.

the breakdown hits other routes too

Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.

Why it happens

Older agent harnesses tried to inject axe into each shadow root individually because early axe-core had weak shadow support. Modern axe-core builds the flattened tree from a document-level injection and analyzes open shadow roots automatically. Agents carrying old axe-core bundles hit injection failures on web-component-heavy pages. Closed shadow roots are intentionally opaque to all scripts including axe, so components using them need vendor cooperation or replacement. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.

Edge cases

• Closed shadow roots cannot be audited by any agent-side technique, flag the component to the vendor.
• After upgrading, delete the per-root injection code, it now fights the flattened-tree analysis.
• Slotted content is analyzed at its composed position, which is correct but can surprise node targeting.
• Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.

Provenance

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

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

Thread query: a11y scan agent failed to inject axe into shadow root

TL;DR: Inject at the document level and let axe's flattened tree handle shadow DOM: axe-core 4.3+ analyzes open shadow roots automatically, so the agent does not need per-shadow-root injection. The failure usually means an old axe-core or a closed shadow root. One line of why: axe composes the flattened tree itself, per-root injection fights the tool's own design.

Not specified by the original author.

axe scan failed when agent attempted shadow dom injection - how to fix it

TL;DR

Stop injecting per shadow root and upgrade the axe bundle: this is the same flattened-tree story as the injection failure, document-level injection with axe-core 4.3+ covers open shadow roots. Per-root injection scripts break on nested shadow trees. One line of why: nested shadow roots (a component inside a component) defeat manual injection recursion, while the flattened tree handles them natively.

The error, verbatim

ScanAgentError: shadow DOM injection failed at nested shadow root
    host: my-app / my-form / my-datepicker (3 levels)
    axe-core: 4.2.0

Fix it step by step

Step 1: Reproduce the nested failure

node agent/run-audit.js --route /booking | rg -i 'shadow|nested' | head -5

Expected: Injection fails at the nested shadow root.

Step 2: Check the axe bundle version

node -e "console.log(require('axe-core/package.json').version)"

Expected: Old axe-core confirms the upgrade path.

Step 3: Upgrade and drop manual injection

npm install axe-core@^4.8 --save | tail -2

Expected: Then remove the per-root injection recursion from the agent.

Step 4: Re-run the audit

node agent/run-audit.js --route /booking | tail -4

Expected: Nested shadow trees are analyzed via the flattened tree.

Step 5: Add a regression probe

node agent/run-audit.js --smoke | tail -3

Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.

When to use this skill

• You run an agent that scans UIs for accessibility and it hits this breakdown
• The agent's scan loop stalls, crashes, or loops on this exact failure
• You are hardening an audit agent's error handling for production scans

When NOT to use this skill

• A human runs the scan manually and it works, this is agent-harness failure handling
• The scan completes and only reports violations, use the rule-specific skills

Compatibility

Scan agent with axe-core 4.8+. Nested open shadow roots are handled by the flattened tree. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

agent nested shadow root axe failed

Same failure at depth, same fix.

axe shadow injection recursion error

Practitioner phrasing for the manual injection approach.

the breakdown hits other routes too

Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.

Why it happens

Manual shadow-root injection recurses the shadow tree and injects axe per root, which breaks on nested shadow roots when the recursion misses a level or hits a closed root mid-tree. Axe-core 4.3+ made this obsolete: document-level injection builds the flattened tree including all nested open shadow roots. Agents still carrying injection-recursion code from the old days should delete it, it now causes the failures it was written to prevent. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.

Edge cases

• Delete the recursion entirely after upgrading, half-removed injection code is worse than the old approach.
• One closed root anywhere in the nesting hides its whole subtree, report it as a coverage gap.
• Test on the most component-heavy page, that is where nesting is deepest.
• Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.

Provenance

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

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

Thread query: axe scan failed when agent attempted shadow dom injection

TL;DR: Stop injecting per shadow root and upgrade the axe bundle: this is the same flattened-tree story as the injection failure, document-level injection with axe-core 4.3+ covers open shadow roots. Per-root injection scripts break on nested shadow trees. One line of why: nested shadow roots (a component inside a component) defeat manual injection recursion, while the flattened tree handles them natively.

Not specified by the original author.

cypress-axe checka11y failed on modal iframe content - how to fix it

TL;DR

Scope the audit to the frame that holds the modal: cy.frame or cy.iframe into the modal's iframe, inject axe there, and run checkA11y against that context. The default checkA11y audits the top frame, which does not include the modal's iframe DOM. One line of why: axe runs per document, and an iframe is a separate document, so the top-frame audit literally cannot see the modal content.

The error, verbatim

AssertionError: checkA11y found no violations but modal content was not audited
    hint: modal renders inside a cross-frame iframe
    at Context.eval (cypress/e2e/modal-a11y.cy.js:24:5)

Fix it step by step

Step 1: Reproduce the blind spot

npx cypress run --spec cypress/e2e/modal-a11y.cy.js | tail -8

Expected: The spec passes or audits only the top frame while the modal iframe goes unchecked.

Step 2: Enter the iframe

rg -n 'iframe|frame' cypress/e2e/modal-a11y.cy.js | head -10

Expected: Shows whether the spec ever enters the modal iframe; usually it does not.

Step 3: Inject and check inside the frame

npx cypress run --spec cypress/e2e/modal-a11y.cy.js | rg -i 'violation|passing|failing' | head -10

Expected: After scoping into the iframe, checkA11y reports the modal's real violations.

Step 4: Re-run to green

npx cypress run --spec cypress/e2e/modal-a11y.cy.js | tail -4

Expected: Spec audits the modal content and passes once its violations are fixed.

Step 5: Re-run twice to rule out flakes

npx pa11y https://example.com/ | tail -2

Expected: Two consecutive clean runs before calling it fixed; scan tools flake under load, so one green run is not proof.

When to use this skill

• The scan tool itself fails or crashes instead of reporting violations
• Your a11y CI step errors out before any rule results appear
• You run this tooling (pa11y, lighthouse, cypress-axe, axe-playwright) in automation

When NOT to use this skill

• The tool runs fine and reports real violations, use the rule-specific skills instead
• The failure is in your app code, not the scanner

Compatibility

cypress-axe 1.x with cypress-iframe or cy.frame support, Cypress 12/13. Cross-origin iframes cannot be entered, same-origin only. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

cypress-axe iframe not audited

Same blind spot, same scoping fix.

checkA11y modal iframe

Practitioner phrasing for modals rendered in iframes.

same failure locally and in CI

Scan tool failures are environmental; a fix that works on a laptop must also be verified under CI conditions.

Why it happens

Axe analyzes one document at a time, and cypress-axe defaults to the top frame. Modals rendered inside iframes (payment forms, embedded widgets) live in a separate document that the top-frame audit never touches, so violations hide there indefinitely. Entering the frame with cy.iframe, injecting axe into it, and running checkA11y in that context is the fix. Cross-origin iframes cannot be scripted into at all, which is a hard browser limit, not a cypress-axe bug. Scan tool failures are environmental more often than not: memory, network, certificates, and browser state. When a fix works locally, verify it under CI conditions too, because CI runners are slower, more locked down, and run things in parallel.

Edge cases

• Cross-origin iframes are unauditable from the parent page, audit them as standalone pages instead.
• Wait for the iframe to load and the modal to open before injecting axe, timing matters.
• Same-origin iframes work fine, the only blocker is cross-origin script access.
• Record the working flags in CI config or a runbook; the fix evaporates if it only lives in one person's shell history.

Provenance

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

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

Thread query: cypress-axe checka11y failed on modal iframe content

TL;DR: Scope the audit to the frame that holds the modal: cy.frame or cy.iframe into the modal's iframe, inject axe there, and run checkA11y against that context. The default checkA11y audits the top frame, which does not include the modal's iframe DOM. One line of why: axe runs per document, and an iframe is a separate document, so the top-frame audit literally cannot see the modal content.