接到政府门户网站无障碍测试任务的那天我的第一反应跟大多数软件测试从业者一样这不就是在页面上跑一遍功能测试吗直到第一次在Windows上启动NVDA屏幕阅读器听它把首页从导航到正文一行行读出来我才意识到之前所有页面能点能看的验证逻辑在这里几乎全部失效。无障碍测试Accessibility Testing验证的不是功能有没有而是内容能不能被所有人感知和操作它面向的是视障、听障、行动障碍以及老年用户而政府门户网站恰恰是这样一类用户群体覆盖最广、服务链路最长、对可访问性要求最高的Web场景。这篇文章是以我实际主导过的政府门户无障碍测试项目为主线写成的覆盖标准拆解、框架设计、工具选型、高频缺陷复现、问题分级到整改验收的完整环节适合正在带测试项目、或者想给自己增加一门差异化技能的软件测试从业者直接参考。1. 政府门户无障碍测试到底在测什么1.1 为什么政府门户是最容易翻车的无障碍场景政府门户和普通企业官网最大的不同在于它的用户画像约等于全体公民——包括视力障碍用户、听力障碍用户、精细动作受限的老年人、以及暂时处于环境限制下的正常人比如在嘈杂环境中无法听清视频声音、在阳光下看不清屏幕的人。这意味着它的信息发布、在线办事、互动交流三大类功能必须在最广泛的设备、浏览器和辅助技术组合下可用。但实际项目里翻车点非常集中我总结下来主要是三个来源。第一个是模板问题大多数站点的内容是运维人员在CMS里填的模板里图片的alt属性要么写死为空要么填了图片两个字正文编辑者根本没有入口去补充有意义的替代文本。第二个是前端框架问题现在政府门户基本都改成了Vue、React这类组件化开发组件库自带的弹窗、下拉、日期选择器往往会忽略焦点管理键盘走到一半就卡死在一个div上。第三个是内容运营问题运维上传的PDF、Word附件、在线视频几乎没有任何无障碍处理痕迹。这三个来源叠加在一起结果就是功能测试全绿无障碍走查满屏红。1.2 无障碍测试和功能测试的本质差异很多测试新手会把无障碍测试当成功能测试的一个子模块这是误区。两种测试的验证对象完全不同。功能测试验证的是系统的功能行为是否符合预期登录能不能成功、列表能不能加载、表单能不能提交。它用的是显式断言有明确的预期结果。无障碍测试验证的是任意用户能否独立完成同样的任务它的预期结果往往是开放式的比如图片的替代文本