Sonner项目中的Toast无障碍访问问题分析与解决方案

问题背景

在Sonner项目中，Toast通知组件的WAI-ARIA实现存在一个关键缺陷，导致部分屏幕阅读器无法正确播报新出现的Toast通知。这个问题在Windows Narrator（Windows 10/11上的屏幕阅读器）以及iOS VoiceOver的旧版本中表现尤为明显。

问题根源分析

当前实现存在三个主要的技术问题：

1. 动态ARIA区域问题：Toast通知被包裹在带有role="status"的li元素中，这些元素仅在Toast显示时存在于DOM中，关闭后即被移除。根据WAI-ARIA规范，ARIA实时区域(live region)应当始终存在于DOM中，以便屏幕阅读器能够订阅其变化。

2. 不恰当的ARIA角色分配：MDN文档明确指出li元素不应被赋予status角色，这违反了HTML语义化规范。

3. 国际化问题：当前实现硬编码了英语提示"notifications alt+t"，对于非英语网站会造成WCAG可访问性违规。

技术解决方案

经过讨论，社区确定了以下改进方案：

方案一：静态ARIA区域容器

1. 在DOM中始终保持一个具有role="status"的静态容器元素
2. 将最新Toast的内容动态注入该容器
3. 优点：完全遵循ARIA实时区域的最佳实践
4. 缺点：需要较大的架构调整

方案二：优化现有结构

1. 将role="status"移至始终存在的section元素
2. 显式添加aria-relevant="additions text"属性，确保只播报新增内容
3. 添加aria-atomic="false"，避免重新读取全部Toast
4. 优点：改动较小，保持现有架构
5. 缺点：无法为不同重要级别的Toast设置不同的aria-live值

方案三：可配置ARIA属性

1. 开放ARIA属性配置接口，允许开发者自定义：
   • section元素的ARIA属性
   • ol和li元素的ARIA设置
   • 国际化文本配置
2. 优点：提供最大灵活性
3. 缺点：增加API复杂度

实施建议

基于讨论结果，推荐采用方案二进行优化，原因如下：

1. 改动范围可控，不影响现有功能
2. 解决了核心的无障碍访问问题
3. 保持了API的简洁性

对于重要程度不同的Toast，建议统一使用polite而非assertive，因为突然中断屏幕阅读器的当前播报可能会造成用户体验上的困扰。

验证与测试

改进后的方案需要重点验证以下方面：

1. Windows Narrator下的Toast播报
2. iOS VoiceOver各版本的表现
3. 键盘导航操作
4. 触摸手势操作（滑动关闭等）
5. 指针事件处理

总结

Toast通知的无障碍访问是Web应用可访问性的重要组成部分。通过将ARIA实时区域移至静态容器并优化相关属性配置，可以显著提升Sonner项目在各种屏幕阅读器环境下的表现。这一改进不仅解决了当前的技术缺陷，也为项目的国际化支持打下了良好基础。