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

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

问题背景

当对话框关闭时，a11y-dialog 需要将焦点恢复到之前获得焦点的元素上。然而在某些特定场景下，特别是在配合动画效果使用时，焦点恢复功能会出现异常。具体表现为：

1. 焦点最终会意外地落在 body 元素上
2. 导致页面意外滚动到顶部
3. 仅在使用动画延迟移除对话框元素时出现

问题根源分析

通过调试发现，问题源于事件监听器的执行顺序。原实现中存在以下执行流程：

1. 首先尝试恢复焦点到之前记录的元素
2. 然后移除用于维持对话框内焦点的监听器
3. 最后用户代码在动画完成后移除对话框元素

这种顺序会导致一个竞态条件：当焦点被恢复到原元素后，维持焦点的监听器可能再次将焦点拉回对话框，随后对话框被移除，最终焦点落在body上。

解决方案

正确的处理顺序应该是：

1. 先移除所有影响焦点的监听器
2. 然后执行焦点恢复操作
3. 最后处理元素移除

这种顺序确保了焦点恢复操作不会被其他监听器干扰。具体代码修改为：

// 先移除焦点相关监听器
document.body.removeEventListener('focus', this.maintainFocus, true)
this.$el.removeEventListener('keydown', this.bindKeypress, true)

// 然后安全地恢复焦点
this.previouslyFocused?.focus?.()

技术启示

这个案例给我们带来了几个重要的前端开发经验：

1. 焦点管理顺序至关重要：在实现可访问性组件时，操作顺序可能直接影响功能表现
2. 动画与DOM操作的协调：当结合CSS动画操作DOM时，需要考虑时间差带来的副作用
3. 事件监听器的生命周期：监听器的移除时机可能影响其他功能的正常运行

最佳实践建议

基于此问题的解决，我们建议开发者在实现类似功能时：

1. 总是先清理可能影响目标操作的事件监听器
2. 对于有动画效果的组件，考虑使用requestAnimationFrame而非setTimeout
3. 在焦点管理代码中加入调试断言，确保预期元素获得焦点
4. 编写全面的测试用例覆盖动画场景下的焦点行为

a11y-dialog 团队迅速响应并修复了此问题，体现了对无障碍功能的高度重视，这也是该库广受好评的原因之一。