前端怎样进行读屏器和辅助技术的实际验收？

简答

• 无障碍验收从用户能否完成关键任务出发，自动化检查没有违规不等于可用。
• 先列出关键任务和产品支持的设备与辅助技术组合，再确定测试范围。
• 第一层是关闭鼠标用键盘走完整流程，检查焦点顺序、焦点可见性和焦点恢复。
• 键盘流程通过后还要用读屏器检查名称、角色、状态和动态通知的播报。

一个表单可能通过 axe 检查，却让读屏用户听不到字段错误；一个弹窗可能有正确的 role="dialog"，但关闭后焦点丢到页面顶部。自动化工具能发现结构问题，不能替用户完成一次真实任务。

无障碍验收应从“用户能否完成关键任务”出发，再用不同层级的工具寻找原因。不要把“没有自动化违规”写成“所有辅助技术都可用”。

先定义真实任务和支持范围

登录、搜索、表单提交、打开弹窗、筛选表格和提交支付各有不同的焦点、状态和错误路径。先列出任务的起点、成功条件、失败恢复和需要听到的信息，再决定测试哪些页面和状态。

辅助技术组合要与产品支持范围对应。桌面网站可能需要键盘加一个主流桌面读屏器，移动页面还要覆盖触摸与系统读屏器；不同浏览器、操作系统和读屏器组合的行为并不完全相同。无法覆盖的组合应记录为限制，而不是假定它们都等价。

第一层是不用鼠标完成完整流程

关闭鼠标，用键盘完成打开页面、跳过导航、进入搜索、填写字段、提交、处理错误、打开弹窗、选择列表项和退出。检查 Tab 顺序是否符合视觉和任务顺序，焦点是否始终可见，是否被 display:none 或弹层遮挡。

重点记录：

• 进入组件后是否知道当前位置和下一步；
• Tab 是否进入了不该进入的装饰节点或隐藏内容；
• Escape、Enter、空格、方向键在当前控件中是否有明确含义；
• 错误出现后焦点是否仍在可修复的位置；
• 弹窗关闭、页面切换和删除节点后焦点回到哪里。

document.activeElement 只能告诉脚本 DOM 焦点所在元素，不等于读屏器已经正确播报名称和状态。键盘流程通过后仍要进入下一层验证。

第二层查看可访问性树和计算名称

浏览器开发者工具的 Accessibility 面板可以查看元素的 role、computed name、description、状态和部分关系。检查名称来自哪里，aria-labelledby 是否指向存在且唯一的节点，错误和帮助文字是否通过 aria-describedby 关联。

对组合框、树、表格和对话框要检查动态状态：展开、收起、选中、禁用、忙碌、错误、当前项和层级。节点被虚拟化或重建后，aria-activedescendant 不能指向已经卸载的元素。

可访问性树是浏览器提供给辅助技术的中间表示，不是读屏器最终一定会朗读的录音。它能帮助定位结构问题，但不能替代真实任务。

第三层用读屏器按用户路径操作

不要只把读屏器打开后按 Tab 一遍。先用标题、地标、链接、表单控件和表格导航快捷键理解页面，再回到业务流程。这样可以发现页面视觉顺序与辅助技术导航顺序不一致的问题。

以表单为例，读屏用户应能听到字段名称、类型、必填状态、帮助信息和错误原因；以弹窗为例，应能知道对话框名称、初始焦点、可用操作和关闭后的返回位置；以异步搜索为例，结果数量和失败状态应在合适时机通知，但不能每次输入都打断当前朗读。

测试动态内容时，要分别验证初次加载、加载中、空结果、错误和更新完成。一个 role="status" 出现在 DOM 中，不代表它的文本更新时机和优先级适合真实使用。

自动化工具适合发现重复结构问题

axe、Lighthouse 或 Playwright 的无障碍规则适合在 CI 中检查缺少名称、重复 ID、部分对比度和 ARIA 结构错误。扫描前要把页面带到真实状态：打开弹窗、触发表单错误、展开树或加载结果，再进行局部和整页检查。

自动检查无法判断文案是否易懂、表格标题是否真的帮助理解、焦点是否抢得太早、读屏器是否按正确顺序播报，也无法覆盖所有浏览器和辅助技术组合。不要为了让报告变绿而关闭规则、排除整个区域或添加无意义的 ARIA。

记录问题时要保留可复现条件

无障碍缺陷报告至少应包含浏览器、操作系统、辅助技术版本、键盘或触摸操作步骤、期望结果、实际听到或看到的结果、页面状态和严重程度。把“读屏不好用”改写成“在某组合中打开编辑弹窗后，焦点仍停留在触发按钮，用户无法到达标题和错误提示”才便于修复和回归。

组件库应为共享交互模式建立固定验收场景，并在组件升级时重跑。单独测试一个页面通过，不代表其他页面使用的同一组合框、表格或弹窗都没有问题；反过来，一个组件的已知例外也不应默默扩散到所有业务。

处理平台差异而不是追求虚假的一致

浏览器和读屏器对 ARIA、焦点、表格和实时区域的支持细节可能不同。优先使用原生 HTML，减少不必要的自定义控件；遇到差异时，在产品支持矩阵中记录实际行为，并选择对目标用户最可靠的实现。

强制颜色模式、文字放大、缩放、窄视口、减少动画和输入法也要纳入验收。读屏器能朗读并不代表视觉焦点、布局和触摸目标同时可用。

一份可信的无障碍结论应说明：自动化规则覆盖了什么、键盘走过哪些任务、哪些浏览器和辅助技术组合已验证、哪些风险仍待确认。这样测试结果才能指导修复，而不是用一个绿色分数代替用户体验。