We shipped an FAQ accordion that looked correct in every browser we checked it in and scored 0 on Lighthouse's agent-accessibility-tree audit — part of the newer Agentic Browsing category — and failed two ordinary Accessibility-category audits at the same time. One bug, three failing audits, and it was on our own site, which exists to tell other people about exactly this kind of problem.
The bug
Our FAQ component rendered a <details> element — for a collapsible accordion, no JavaScript required — nested directly inside a <dl>:
<!-- Before -->
<dl>
<details>
<summary>
<dt>What is CrawlPod?</dt>
</summary>
<dd>CrawlPod is...</dd>
</details>
</dl>
That's invalid. <dl> only permits <dt>/<dd> groups, <div>, <script>, or <template> as direct children — <details> isn't one of them, and <dt>/<dd> nested inside a <summary>/<details> aren't direct children of <dl> either way, regardless of the outer wrapper. Every browser we tested rendered it fine anyway, because browsers are extremely forgiving of invalid HTML. Lighthouse's accessibility-tree audits are not.
Three audits, one root cause
Running Lighthouse against the page surfaced:
definition-list(Accessibility) — faildlitem(Accessibility) — failagent-accessibility-tree(Agentic Browsing) — fail, with this exact explanation in the audit output: "<dl>elements must only directly contain properly-ordered<dt>and<dd>groups,<script>,<template>or<div>elements."
Accessibility went from 88 to 100 and Agentic Browsing from 2/3 (67%) to 3/3 (100%) after one fix — not three separate fixes. That's the pattern worth internalizing: Agentic Browsing and Accessibility both walk the same underlying accessibility tree. A structural HTML bug tends to fail both categories simultaneously, because they're not really testing different things — they're reading the same tree from two different angles.
The fix
Drop <dl>/<dt>/<dd> entirely. The visible markup doesn't need list-definition semantics to be accessible — native <details>/<summary> already has correct disclosure semantics (expanded/collapsed state, correct role) without them, and the page's FAQPage JSON-LD already carries the actual question-and-answer structure for anything that needs to parse it programmatically:
<!-- After -->
<div>
<details>
<summary>What is CrawlPod?</summary>
<p>CrawlPod is...</p>
</details>
</div>
We were trying to satisfy two different jobs — visible accordion behavior and semantic list markup — with one element, and the combination was invalid. Splitting them (structured data does the semantic job, <details> does the interactive job) fixed all three audits at once.
Why this is worth publishing
The honest reason to write this up isn't that the fix was clever — it wasn't, it was one component rewrite. It's that the failure was completely invisible without running the actual audit. Nothing about the broken version looked wrong in a browser, a code review, or a screenshot. A tool that claims to help with AI visibility and doesn't audit its own accessibility tree has a credibility problem, not a marketing problem — so we ran the audit against ourselves, found a real bug, and are publishing the real before-and-after rather than a sanitized version of the story.
Check your own site
The agentic-readiness check in the free scanner looks for exactly this class of problem — accessible names on interactive elements, form labels, landmark structure — using static HTML analysis, the same signals Lighthouse's audit checks. See /built-with for this site's own current, live result.