可访问性API并非统一标准，而是浏览器各自实现的底层桥接机制；aria-label或role="button"能否被正确读出，取决于当前浏览器的可访问性树是否准确映射，并经操作系统AT调用，Chrome、Firefox、Safari及NVDA/JAWS等在映射逻辑、aria-hidden传播、aria-live触发、角色识别上存在显著差异，需逐环境手动验证。
可访问性 API 不是统一标准，而是浏览器各自实现的底层桥接机制；你写的 aria-label 或 role="button" 能否被正确读出，取决于它是否被当前浏览器的可访问性树（Accessibility Tree）准确映射，再经由操作系统 AT（辅助技术）调用——这个链路在 Chrome、Firefox、Safari 上差异显著，且无法靠“写对 ARIA 属性”一劳永逸解决。
Chrome 与 Firefox 的可访问性树生成逻辑差异
Chrome 基于 Blink 渲染引擎，其可访问性树构建更依赖 DOM 结构完整性：若你动态插入一个带 role="dialog" 的元素但没同步设置 aria-modal="true"，Chrome 可能仍将其纳入树中，但焦点管理失效；Firefox（Gecko）则更严格校验语义组合，漏掉 aria-labelledby 就直接降级为 generic 角色，屏幕阅读器跳过该节点。
- Chrome 对
aria-hidden="true"的传播行为更宽松：父元素设为 hidden，子元素即使显式设aria-hidden="false"也可能被忽略 - Firefox 要求所有交互控件必须有明确的
tabindex或原生可聚焦语义（如button），否则不进入可访问性树 - 两者对
display: contents的处理完全不同：Chrome 会剥离该元素的可访问性节点，Firefox 则保留其子节点并尝试重建上下文关系
Safari + VoiceOver 的 aria-live 触发延迟问题
aria-live 在 Safari 中不是“实时播报”，而是按 0.5–1.2 秒的固定间隔批量轮询 DOM 变更。如果你在单次 JS 执行中连续修改多个 aria-live 区域的内容，VoiceOver 很可能只播报最后一次——这不是 bug，是 Safari 主动 throttle 的结果，目的是避免语音洪水。
- 避免在循环中反复赋值
innerHTML或textContent到同一aria-live区域 - 改用一次性拼接字符串再写入，或使用
setTimeout(() => { ... }, 0)强制分帧 -
aria-live="polite"在 Safari 中实际响应比assertive更慢，测试时需以 assertive 为准再降级 - 不要依赖
document.getElementById().focus()触发aria-live，Safari 不保证 focus 后立即触发播报
Windows NVDA / JAWS 与 Edge 的角色映射错位
Edge（Chromium 内核）虽复用 Blink，但其可访问性 API 桥接层额外注入了 Windows 平台专属逻辑。典型问题是：当元素同时有 role="combobox" 和 contenteditable="true"，NVDA 会优先识别为 edit，而 JAWS 可能坚持读作 “combobox”，导致同一段 HTML 在不同读屏软件下播报不一致。
立即学习“前端免费学习笔记（深入）”；
- 避免混用
contenteditable与复杂role，尤其不要给div[contenteditable]加role="listbox" - 若必须自定义下拉组件，用原生
select+optgroup组合，或至少确保aria-haspopup="listbox"与aria-expanded同步更新 - JAWS 对
aria-activedescendant的响应比 NVDA 慢约 200ms，动态菜单需预留此延迟再触发焦点移动 - Edge 中
role="application"会禁用大部分键盘导航逻辑，仅建议用于 Canvas 类富交互场景，且必须配aria-roledescription
真正难的不是写对 ARIA，而是验证它在每个目标环境里是否被正确解析——没有跨浏览器的“可访问性快照”，只有逐个手动触发 VoiceOver/NVDA/JAWS，在真实操作流中监听播报内容和焦点路径。这点常被自动化测试忽略，但恰恰决定视障用户能否完成关键任务。
