# axe devtools failed to analyze cross-origin iframe content - how to fix it

## TL;DR

Accept the browser boundary and audit the iframe separately: cross-origin iframes are invisible to axe DevTools by browser security design, so load the iframe's src URL directly and scan it as its own page. One line of why: the same-origin policy blocks script access across origins, and no scanner can override that.

## The error, verbatim

```text
axe DevTools: 0 elements analyzed in frame https://payments.example.net/
reason: cross-origin frame, access denied by browser

```

## Fix it step by step

### Step 1: Confirm the iframe is cross-origin

```bash
node -e "const a=new URL('https://payments.example.net/'); const b=new URL('https://example.com/'); console.log(a.origin===b.origin?'same-origin':'cross-origin')"
```

Expected: Prints cross-origin, confirming the browser boundary.

### Step 2: Get the iframe src

```bash
curl -s https://example.com/ | rg -o 'src=https?[^ ]+' | head -5
```

Expected: Lists iframe sources to audit individually.

### Step 3: Scan the iframe as its own page

```bash
npx @axe-core/cli https://payments.example.net/ --save axe-frame.json | tail -3
```

Expected: Produces a real violation report for the framed content.

### Step 4: Cover the parent page too

```bash
npx @axe-core/cli https://example.com/ --save axe-parent.json | tail -3
```

Expected: Parent page scanned; together the two reports cover the whole experience.

### Step 5: Re-run twice to rule out flakes

```bash
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

axe DevTools extension 4.x, axe-core CLI 4.8+. The cross-origin boundary is a browser security rule, not a tool bug. Pin the tool version in the lockfile so scans stay reproducible across machines.

## Variant phrasings

### axe cross origin iframe not analyzed

Same boundary, same separate-scan fix.

### axe devtools 0 elements in frame

The symptom in the DevTools panel.

### 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

Browsers deny script access to cross-origin frames via the same-origin policy, and axe (running as page script) cannot read the frame's DOM. DevTools reports the frame as unanalyzable rather than failing silently. Payment iframes, embedded videos, and third-party widgets are the usual cross-origin frames. The only complete audit is scanning the frame's URL directly as its own page, plus asking the vendor about their accessibility statement. 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

- Scanning the frame URL directly works only if the frame content renders standalone, some frames need parent context.
- Ask vendors for a VPAT or accessibility statement for framed widgets you cannot audit deeply.
- Same-origin iframes are fully analyzable, the boundary is strictly about origins differing.
- 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_0fuMZbRShCYsN6fBxhJKSg