浏览器解析时会自动修正非法嵌套，使<p>内的<div>被移出并闭合<p>，导致DOM结构与源码不一致，屏幕阅读器按修正后DOM遍历，造成语义断裂、ARIA失效及焦点管理异常。
为什么 screen reader 会跳过 p 里的 div
浏览器解析时根本不会让 <div> 进入 <code><p></p> —— 遇到就立刻闭合当前 <p></p>，把 <div> 插到后面，再补一个空 <code><p></p>。结果是：你写的 <p>文字</p>
<div>操作按钮</div>，实际 DOM 变成 <p>文字</p>
<div>操作按钮</div>
<p></p>。
屏幕阅读器按真实 DOM 遍历，<div>操作按钮</div> 已经脱离 <p></p> 的语义上下文，既没被读作“段落内的操作”，也不在段落流中；那个空 <p></p> 还可能触发无意义的停顿或静音跳过。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 常见现象：键盘 Tab 到按钮时，阅读器只报“按钮”，不提前面那句导语
- 更隐蔽的问题：aria-labelledby 指向的
<p></p>节点里查不到目标子元素，ID 绑定直接失效 - SSR + hydration 场景下，客户端重建时因结构不一致，按钮可能丢失焦点管理逻辑
document.querySelector('p > div') 总是 null 的真正原因
这不是选择器写错了，是 DOM 根本不存在这个结构。浏览器在 HTML 解析阶段就完成了修正，JS 执行时看到的已经是“修复后”的树。
验证方法很简单，在控制台跑这行：
document.querySelectorAll('p > *').forEach(el => console.log(el.tagName))
如果输出里有 DIV 或 H2，说明你正看着浏览器自动补全的结果，不是原始源码。
- 别信编辑器高亮或缩进——它们只渲染源码字符串，不反映真实 DOM
-
querySelector和getElementById都基于最终 DOM，和你写的 HTML 字符串无关 - 用 Lighthouse 的 “Accessibility” 报告看 “ARIA attributes do not have valid values”，常指向这类结构断裂
重构时最容易忽略的 aria 上下文迁移
很多人把 <p aria-live="polite"></p> 拆掉后，只换了容器，却忘了把 aria-live 移到新父级上。结果是：动态更新的内容不再被阅读器捕获。
- 原
<p aria-live="polite"><span>加载中</span></p> <div class="spinner"></div>→ 必须迁移到<section aria-live="polite"></section>或<div role="region" aria-live="polite"> <li>如果用了 <code>aria-labelledby关联标题，新容器必须仍能被正确引用（ID 不变，但父级变了，需确认引用路径没断） - 用
role="group"替代<p></p>时，要加aria-label，否则屏幕阅读器只报“组”，不说明用途 - 它不能解决 SSR 结构不一致问题：服务端吐出非法结构，客户端 hydration 仍可能失败
- Safari 直到 15.4 才支持，旧版 iOS WebView 会退化为默认块级表现
- DevTools Elements 面板里仍能看到被“切开”的 DOM，无障碍树也照常断裂
- 真正该做的，是把内容语义拆清楚：
<p></p>只放纯文本节点和 phrasing content，块级结构交给<section></section>、<article></article>或带 role 的<div> <p>最麻烦的不是改标签，而是团队里没人觉得这是个问题——它不报错、不警告、样式看起来还一样。等 QA 发现阅读器跳丢了三行说明文字，或者 SEO 抓取到一堆空 <code><p></p>节点，往往已经上线好几周了。
用 display: contents 救急但别当主力
display: contents 让父容器不生成盒模型，视觉上像“透明包裹”，但它不改变 HTML 合法性检查——<p></p>
<div></div>
