无障碍树在Chrome DevTools中称为Accessibility标签页，位于Elements面板右侧，需手动点击展开并选中元素后查看。

无障碍树在Chrome DevTools里叫什么

Chrome DevTools 中的无障碍树（Accessibility Tree）不叫“无障碍树”，而是在 Elements 面板右侧的 Accessibility 标签页里。它不是默认展开的，得手动点开——很多人卡在这一步，以为没加载或功能被禁用了。

• 必须先选中一个 DOM 元素（点击 Elements 面板里的节点，或用 Ctrl+Shift+C（Win/Linux）/Cmd+Shift+C（Mac）吸管选取）
• 然后在右侧面板切换到 Accessibility 选项卡（不是 Styles 或 Computed）
• 如果没看到这个标签页，说明当前 Chrome 版本支持但该页面未启用辅助技术上下文（比如没触发屏幕阅读器逻辑），可尝试在页面加 role="application" 或聚焦一个 input 再试

为什么有些元素在无障碍树里完全不出现

不是所有 HTML 元素都会进入无障碍树。Chrome 只把有语义、可交互、或显式声明了无障碍属性的节点纳入其中。纯装饰性 div、span（无 role、aria-*、焦点属性）会被跳过。

• 默认被忽略：空的 div、span、img（无 alt）、section（无标题或 aria-label）
• 强制进入：加 role="region"、aria-hidden="false"（注意不是默认值）、tabindex="0"
• 特别注意：display: none 或 visibility: hidden 的元素一定不会出现在无障碍树中，哪怕写了 aria-live

如何验证 aria-label 和 aria-labelledby 是否生效

aria-label 和 aria-labelledby 的值是否被正确读出，不能只看 HTML 属性，得看无障碍树里 Name 字段的实际计算结果。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 在 Accessibility 面板中，找到对应节点，展开查看 Name 行 —— 它显示的是最终暴露给辅助技术的名称，不是源码写的字符串
• aria-labelledby 会拼接多个 ID 对应元素的文本内容（包括 alt、value、可见文本），中间用空格连；如果 ID 找不到，整个属性就失效，Name 回退到其他来源（如 aria-label 或元素自身文本）
• 常见错误：ID 大小写不一致、ID 值含空格或特殊字符（必须严格匹配 id 属性）、目标元素本身 aria-hidden="true"

无障碍树和实际屏幕阅读器行为不一致怎么办

DevTools 的无障碍树是快照式渲染，它反映的是当前 DOM + ARIA 状态下的静态计算结果，但真实屏幕阅读器（如 NVDA、VoiceOver）还依赖运行时上下文：焦点状态、用户操作模式（浏览/表单模式）、系统级辅助设置。

立即学习“前端免费学习笔记（深入）”；

• DevTools 不模拟焦点链或 aria-live 的动态更新，要测实时反馈得真用屏幕阅读器手动触发
• 某些 role（如 menu、combobox）需要完整键盘交互逻辑支撑，光有结构不会让无障碍树“变活”
• 最小验证闭环：在 DevTools 看 Name 和 Role 正确 → 用 Chrome 自带的 Ctrl+Option+Z（Mac）或开关 ChromeVox（实验性）粗略听读 → 最终以 JAWS/NVDA 实测为准

无障碍树不是调试终点，而是第一个可信的语义校验点；真正难的，是让那个“Name”在各种上下文中都稳定、准确、不意外。