safari 中 display: contents 会剥离语义，导致 voiceover 忽略 aria-label、role 等属性，即使 dom 和 aria 值存在；应改用 flex/grid 或上提语义替代。

display: contents 在 Safari 中的可访问性问题不是“Bug”，而是实现差异——它会让部分屏幕阅读器跳过父节点语义，即使 DOM 和 ARIA 属性仍在。

为什么 Safari 下 aria-label 或 role 突然“读不到”

这不是样式失效，而是 Safari（尤其是 iOS 15–16）对 display: contents 的语义处理更激进：某些读屏器（如 VoiceOver）会直接忽略该元素及其所有语义信息，哪怕你写了 role="list" 或 aria-labelledby。DOM 节点还在，el.getAttribute('aria-label') 也能取到值，但语义树里已断开。

• 最典型表现：<ul style="display: contents"> <li>A</li> <li>B</li> </ul> → VoiceOver 不再播报“列表，2项”，而是把 A、B 当作两个孤立段落读
• <div role="group" aria-label="筛选条件"> <input><button></button> </div> 加了 display: contents 后，aria-label 彻底静音
• 问题在 Safari 15.4+ 依然存在，不是旧版本特有；macOS 和 iOS 行为基本一致

哪些 role 组合在 Safari 中风险最高

不是所有语义都会失效，但以下三类在 Safari 中被跳过的概率显著升高：

Plan Dubai Travel — Flights, Hotels, Burj Khalifa, Desert Safari, Malls & Itineraries

规划您的迪拜之旅 — 哈利法塔观景、沙漠探险、迪拜购物中心购物、棕榈岛度假村及黄金市场砍价。还提供支持...

下载

• role="list" / role="listitem"：列表计数中断、嵌套层级丢失，尤其当父 <ul></ul> 或 <ol></ol> 设了 display: contents
• role="group" / role="region"：若内部含可聚焦元素（如 <input>），VoiceOver 可能无法将它们归入同一语义区域，导致键盘导航断裂
• role="table" / role="row"：表格语义链断裂比视觉错位更隐蔽，开发者工具里看不到报错，但读屏器完全不识别行列关系

绕过 Safari 无障碍缺陷的实操方案

没有 JS 补丁能修复这个渲染层语义剥离，只能换策略。核心原则是：**保留语义容器，仅用 CSS “视觉打平”**。

• 用 display: flex 或 display: grid 替代 display: contents 打平嵌套：例如把 <div class="wrapper"> <span>A</span><span>B</span> </div> 改为 .wrapper { display: flex; gap: 8px; }，既保持 div 的语义锚点，又消除盒模型干扰
• 对必须用 display: contents 的场景（如 SSR 注入 wrapper），加一层 aria-hidden="true" 的空 wrapper 包住它，并把关键语义上提到真实存在的父级元素上 —— 例如把 aria-label 移到 <section></section> 上，而不是依赖中间 <div> <li>避免在 <code><label></label>、<legend></legend>、<caption></caption> 等隐式语义强的标签上使用 display: contents，Safari 对这些节点的语义降级更彻底

如何快速验证 Safari 中是否真的“读不到”

别只看 DevTools 的 Accessibility 面板——它显示的是语义树快照，不是 VoiceOver 实际行为。真测得用真机 + VoiceOver：

• 打开 iOS 设置 → 辅助功能 → VoiceOver，开启后双指旋转屏幕启用朗读
• 聚焦目标区域，听是否播报预期角色和 label；特别注意列表项之间是否有“第1项”“第2项”提示
• 用 document.getElementById('x').getAttribute('role') 和 computedRole（通过 Accessibility Inspector）对比，若后者返回 none，说明 Safari 已剥离语义
• 不要依赖 Chrome 的 axe 或 Lighthouse 检测结果——它们模拟的是 Chromium 语义树，和 Safari 不同

真正难调试的是“DOM 存在、样式消失、语义断连”三者并存的状态；Safari 不报错、不警告，只安静地让读屏器跳过你精心写的 aria-describedby。动手前先问一句：这个 wrapper 真的需要从布局流中消失，还是只需要视觉上不占空间？答案往往指向更稳妥的替代方案。