公共服务网页测试，为什么需要听到辅助技术新手的反馈

一位熟练使用读屏的参与者很快完成了公共服务申请，团队便认为页面已经没有障碍。这个结论跨得太远：测试证明的是这位参与者在当时条件下的表现，还没有覆盖刚接触辅助技术的人。公共服务面向的人群越广，越需要交代测试邀请了谁。

W3C WAI关于用户参与评估的资料，将新手、一般和熟练用户的选择与目标使用者联系起来。它举公共福利申请网站为例，说明辅助技术新手也应被纳入考虑。这个例子并非规定所有项目必须采用同一人员比例，而是在提醒团队，参与者经验不能与服务对象脱节。

熟练使用者可能知道绕过障碍的方法，初学者却可能不知道下一步如何继续。同一个操作结果背后，既有网页实现，也有浏览器、辅助技术和使用经验等因素。原文在分析访问问题时列出这些不同来源，因此不能把一次困难简单归因于“用户不会用”，也不能未经核查就认定一定是网页代码错误。

设计测试任务时，可以使用实际服务中的查找、理解和提交目标，并记录参与者遇到困难的位置。这里是项目研究的组织思路，不是已经实施过的测试。本文没有招募参与者，也没有取得录像、访谈或操作数据，不会用假设情景代替真实发现。

报告中应保留使用环境、任务范围、参与者特征以及发现过程。若只测试了某类障碍和一种辅助工具，就应把其他组合写为尚未覆盖。一个问题没有在小样本中出现，不能自动转成该问题不存在；一位参与者的偏好，也不能代表同类群体的全部需要。

WAI还强调，用户参与不能单独决定网站是否可访问，应与WCAG符合性评价结合。前者帮助理解实际体验，后者有自己的标准范围和检查方法。把用户访谈做完，不等于标准检查也已经通过；反过来，一张检查清单也不能替代真实使用过程中的观察。

对公共服务团队而言，测试价值来自把未知变得具体。邀请与目标人群相符的参与者，保留新手遇到的困难，说明哪些范围还没查，能让改进工作更有依据。本文只是评估资料的整理，不对任何服务网页作合规验收，也不把少数人的顺利使用包装成所有公众都能访问的保证。