元素？真相与最佳实践
" />
本文澄清 `
HTML 的
例如，以下代码：
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 2023”）推断出这是日期，就已满足成功标准（WCAG 1.3.1, 3.1.3）。
推荐做法：语义清晰 + 上下文强化
- 保留 （这是对机器友好的底线）：
-
在视觉和逻辑结构中强化时间语境：
- 使用
或 明确日历月份：
Februar 2023
- 为整行日期添加 aria-labelledby 指向月份标题，帮助建立层级关系。
- 使用
-
仅当存在真实理解障碍时，谨慎使用 aria-label（非发音优化，而是补充缺失语义）：
✅ 注意：此 aria-label 应完整传达日期、星期、年份和时间，而非仅修正发音。
最后，请记住：优秀的可访问性不是追求“完美朗读”，而是构建鲁棒、可预测、尊重用户控制权的信息架构。与真实视障用户共同测试你的日历组件——他们最清楚什么才是真正的问题。
