如何让 NVDA 正确朗读 元素？真相与最佳实践

元素？真相与最佳实践 "> 元素？真相与最佳实践 " />

本文澄清 `` 标签在 nvda 等主流屏幕阅读器中实际不被特殊处理的事实，解释为何强制“精准发音”反而损害可访问性，并提供符合 wcag 原则的务实解决方案。

HTML 的 元素语义明确——它用于标记机器可解析的时间日期值，便于搜索引擎、日历应用或辅助技术识别时间上下文。但需明确一个关键事实：目前没有任何主流屏幕阅读器（包括 NVDA、JAWS、VoiceOver）会主动解析 datetime 属性并据此修改语音输出内容。你所观察到的“NVDA 忽略 ”并非 bug，而是设计使然：它默认只朗读元素内的可见文本（即 "Fr. 13. 00:00 Uhr"），而完全忽略 datetime 值。

例如，以下代码：

Fr. 13. 00:00 Uhr

NVDA 会直接朗读 “Fr. thirteen dot zero zero o’clock”（甚至误读为货币“Swiss franc”），而非 ISO 时间或更自然的“Friday, February 13th at midnight”。

这引出一个根本性认知误区： 不是发音控制工具，而是语义标注工具。试图通过它“修正发音”，本质上混淆了语义层与呈现层的职责。

为什么不应强行覆盖发音？

• 破坏用户自主权：视障用户常使用自定义发音词典（如 NVDA 的 Pronunciation Dictionary）来统一修正所有网站中的歧义词（如 “Fr.”）。硬编码 aria-label="Friday, February 13" 会覆盖其个人偏好，反而降低一致性。
• 配置依赖性强：即使 aria-label 在某台 NVDA + German voice 下效果良好，换用 JAWS + English voice 或 VoiceOver + iOS 可能导致冗余、矛盾甚至错误（如重复朗读：“Friday, February 13. Fr. 13. 00:00 Uhr”）。
• 违背可访问性设计原则：W3C 明确指出，应优先保障信息可理解性（understandable content），而非“发音精确性”。只要用户能通过上下文（如日历网格、相邻标题“February 2025”）推断出这是日期，就已满足成功标准（WCAG 1.3.1, 3.1.3）。

推荐做法：语义清晰 + 上下文强化

1. 保留 ，确保 datetime 符合 ISO 8601（这是对机器友好的底线）：

   Fr. 13. 00:00 Uhr

2. 在视觉和逻辑结构中强化时间语境：
   • 使用 或

     明确日历月份：

     Februar 2025

   • 为整行日期添加 aria-labelledby 指向月份标题，帮助建立层级关系。
3. 仅当存在真实理解障碍时，谨慎使用 aria-label（非发音优化，而是补充缺失语义）：

   
   
     Fr. 13. 00:00 Uhr
   

   ✅ 注意：此 aria-label 应完整传达日期、星期、年份和时间，而非仅修正发音。

最后，请记住：优秀的可访问性不是追求“完美朗读”，而是构建鲁棒、可预测、尊重用户控制权的信息架构。与真实视障用户共同测试你的日历组件——他们最清楚什么才是真正的问题。