a11y-dialog 焦点恢复问题的分析与修复

在开发可访问性对话框组件时，焦点管理是一个至关重要的环节。a11y-dialog 作为一款优秀的无障碍对话框库，近期在版本8中遇到了一个关于焦点恢复的有趣问题，本文将深入分析问题原因及解决方案。

问题背景

当对话框关闭时，a11y-dialog 需要将焦点恢复到触发打开对话框的元素上。然而在某些特定场景下，特别是在对话框关闭动画期间延迟移除DOM元素时，焦点恢复会出现异常，最终错误地落在body元素上。

问题复现条件

1. 使用a11y-dialog v8版本
2. 在对话框关闭时设置延迟移除DOM元素（通常是为了等待动画完成）
3. 焦点恢复逻辑与焦点保持监听器之间存在执行顺序问题

根本原因分析

问题的核心在于事件监听器的执行顺序。原代码的执行流程是：

1. 恢复焦点到先前聚焦的元素
2. 移除body上的focus事件监听器
3. 移除keydown事件监听器

这种顺序会导致一个竞态条件：当焦点被恢复到原始元素后，尚未移除的focus事件监听器（用于保持焦点在对话框内）会立即将焦点强行拉回对话框。随后当对话框DOM被移除时，焦点就落到了body上。

解决方案

通过调整执行顺序可以完美解决这个问题：

1. 首先移除所有相关的事件监听器（focus和keydown）
2. 然后再执行焦点恢复操作

这样修改后，焦点被恢复到原始元素后就不会再被任何监听器干扰，确保了预期的行为。

技术细节

在无障碍对话框的实现中，焦点管理包含两个关键部分：

1. 焦点保持：通过监听body元素的focus事件，确保焦点不会意外离开对话框
2. 焦点恢复：在对话框关闭时，将焦点返回到触发元素

这两个功能的执行顺序至关重要。如果焦点恢复先于监听器移除，就可能出现上述问题。正确的顺序应该是先解除所有可能干扰焦点恢复的机制，再执行恢复操作。

实际影响

这个问题在以下场景特别明显：

• 使用CSS过渡或动画的对话框
• 需要延迟移除对话框DOM的情况
• 复杂的单页应用环境

修复后的版本确保了在各种场景下都能正确恢复焦点，提升了用户体验和无障碍特性。

最佳实践

基于这个问题的经验，在实现类似功能时建议：

1. 总是先清理事件监听器再执行状态恢复
2. 考虑动画延迟对焦点管理的影响
3. 在复杂场景下进行充分测试

a11y-dialog 8.1.4版本已经包含了这个修复，推荐所有用户升级以获得更稳定的焦点管理行为。