可访问性测试在我这几年接手的政府网站项目里已经从“加分项”变成了“硬指标”。不少同行一听到政府网站测试第一反应就是功能、性能、兼容性实际上可访问性测试才是最容易暴雷、也最容易被忽略的一环。前阵子我配合团队完成了一批政府门户网站的无障碍改造验收测试从最初的一脸懵到后来沉淀出一套能直接套用的实战框架今天把这些东西完整拆开讲一讲。无论你是刚入门软件测试的萌新还是正在研究可访问性测试的资深工程师这篇都能给你一条相对完整的执行路径。政府网站不是普通商业站点它的用户覆盖全年龄段、全设备、全能力状态的人群。老年人要用放大镜看字体视障用户要靠读屏软件逐行朗读肢障用户可能只用键盘操作。让这些人都能顺利办成事、查得到信息这才是政府网站可访问性测试的核心价值。下面我直接把整套框架拆开从标准、工具、流程到避坑一次性讲透。1. 可访问性测试到底在测什么别把“无障碍”理解窄了1.1 它和传统“兼容性测试”有本质区别很多测试同学会把可访问性测试误当成兼容性测试的延伸觉得无非是多测几个浏览器、多调几个分辨率。这个认知是错的。兼容性测试关心的是不同环境下页面“能不能正常显示”可访问性测试关心的是“任何能力状况的用户能不能用”。兼容性追求的是“一致”可访问性追求的是“平等可用”。举个最简单的例子一个按钮如果只用鼠标能点击键盘操作永远无法获得焦点在传统功能测试里它完全没问题但在可访问性测试里这就是一个致命缺陷因为大量视障用户根本不使用鼠标。政府网站的可访问性测试通常要覆盖四层能力维度感知层面即文字、图形、音频能否被所有感官获取操作层面即所有功能是否能用键盘、语音等不同输入方式完成理解层面即界面信息是否清晰、一致、可预测兼容层面即站点能否配合各类辅助技术正常工作。前三个维度对应的是 WCAG 2.1 的“可感知、可操作、可理解”三大原则第四个维度对应“健壮性”合在一起就是国际通行的 POUR 原则。1.2 标准体系从 WCAG 2.1 到国内合规要求做政府网站可访问性测试最常引用的技术基准是 WCAG 2.1 的 A 级和 AA 级成功标准。A 级是底线比如“非文本内容提供替代文本”“仅用键盘可操作”AA 级是政府网站必须重点保障的比如“对比度达到 4.5:1”“错误提示能被感知”。国内政务网站的无障碍建设要求也基本对标 WCAG 2.1 AA 级很多地区还明确了完成时限和验收规范。这里我想特别提一下测试标准的落地方式。实际测试中我们不会真把几十项标准背下来而是将 WCAG 规则映射成一张“检查清单”。例如“1.1.1 非文本内容”对应到实操就是“每张 img 都要有 alt 属性且 alt 内容能表达图片意图”“2.1.1 键盘”对应到实操就是“页面所有可交互元素都必须能用 Tab 键到达并用 Enter 或空格键激活”。这种映射是搭建测试框架的第一步后面每一轮用例设计都会用到。1.3 政府网站的高风险页面类型不是所有页面都需要投入同等的测试力度。根据我的项目经验政府网站里有几类页面必须优先覆盖首页信息密度最高、组件最复杂、办事服务页涉及用户填写表单、上传材料、支付缴费、搜索结果页动态加载、结果朗读逻辑复杂、个人中心/登录页涉及会话状态和隐私信息。这些页面一旦出问题用户可能连最基本的“在线办理”都走不通。我建议在测试计划里直接按页面风险等级排序高优先级是办事服务、在线查询、支付、登录相关流程中优先级是首页、新闻资讯、政策文件页低优先级是辅助功能页如隐私政策、网站地图。这样排的好处是即使测试时间被压缩也能保证最核心的政务办事链路被覆盖到而不是平均发力导致哪里都没测透。2. 一套可落地的测试框架从标准到流程的搭建步骤2.1 先定测试策略自动化与人工结合的“三明治”模型可访问性测试想只靠自动化工具跑一遍就出具报告基本是自欺欺人。自动化工具能发现约 30% 到 40% 的可访问性问题比如缺失的 alt 文本、错误的对比度、无效的 ARIA 属性但大量语义性、上下文相关的问题只能靠人工判断。例如一个图片按钮alt 文本是否准确描述其功能自动化工具无法判断一段内容是否让读屏用户理解歧义也需要真人都检查一遍。我实际使用的策略是“自动化扫描打底人工走查承接真实用户验证收口”。第一轮用 axe-core、WAVE 等工具全量扫描站点页面快速筛出语法级问题第二轮由测试人员用 NVDA、VoiceOver 等读屏软件对关键流程做人工走查第三轮如果条件允许找一两位真实用户尤其是老年或视障用户做任务测试。这三层叠加起来覆盖面才能接近真实使用场景。注意前两轮是必须做的第三轮如果预算或资源不足可以缩减但高风险流程至少要有一次人工读屏验证。2.2 工具选型没有All-in-One组合拳才是正解我常用的一套工具组合如下自动化扫描用 axe DevTools浏览器插件版以及配套的 axe-core适合集成到自动化测试脚本里页面整体评估用 WAVE 的网页版或插件版它能直观地在页面上覆盖一层遮罩显示各类问题对比度检测用 Colour Contrast Analyzer一款桌面工具或者 axe 内置的对比度检查屏幕阅读器测试用 Windows 平台上的 NVDA免费且实用和 macOS 上的 VoiceOver。如果有条件定期用 JAWS 做一次交叉验证毕竟国内读屏用户中 NVDA 的占比很高但 JAWS 也是海外政府网站广泛依赖的工具。选择工具时要注意版本匹配。比如 NVDA 每次更新后对网页元素朗读顺序的处理可能会有细微变化测试前最好固定环境版本否则同一个页面可能因为读屏版本不同而得出不同的结论。我在项目里会专门写一份“测试环境配置表”记录浏览器版本、读屏软件版本、操作系统版本避免后期出现“你测的和我测的不一样”的扯皮。2.3 测试流程模板从一个立项到一份报告的标准化动作我把政府网站可访问性测试的流程整理成六个阶段需求解读与标准对齐、页面清单梳理、用例设计、自动化扫描、人工走查、报告输出与复测。每个阶段都有明确产出物这样做的好处是方便排期也方便向甲方交代进度。页面清单梳理是个容易被忽略但特别重要的环节需要和开发、产品一起确认本次改动涉及哪些页面同时确定“测试基线页面”和“改动页面”两批列表。比如网站改版后首页、列表页、详情页都变了但内部搜索页没变那就不能把所有页面都押到同一轮测试里。用例设计阶段我会直接套用 WCAG 2.1 的映射清单按页面类型生成用例同时把用户最核心的任务流例如“查询某事项办事指南→在线下载申请表→返回首页”串成端到端场景。这里有个心得单个页面的可访问性测试只能证明“每个零件是好的”端到端流程测试才能证明“整条链路是通的”。读屏用户从列表页跳到详情页焦点是否被正确移动到新页面顶部这往往是单靠检查逐个页面发现不了的问题。3. 核心环节实操扫描、走查与用例编写3.1 自动化扫描的正确打开方式我用 axe DevTools 做了个示例动作打开目标页面F12 进入开发者工具在 axe 标签页点击“Scan ALL”按钮几十秒后会列出所有违反规则项每一项都给出影响级别serious/critical/minor和修复建议。但这里必须提醒不要盲目修完就认为任务结束。axe 输出的每一项都需要人工确认是否属于“误报”或“需要结合语义判断”。例如某个 color 对比度检测报出的问题如果该元素实际上只是装饰性背景图上的纯色文字就需要测试人员结合视觉结果写备注而不是直接丢给前端改色值。自动化扫描建议在页面内容相对冻结后执行不要在开发频繁改代码的中途反复全量扫描那样只会产生大量无效的临时问题记录。我一般会在提测前一天做第一轮全量扫描记录问题基线然后在修复完成后再扫一轮对比基线确认修复情况。至于是否要接入 CI/CD要看项目实际情况。如果团队有自动化测试体系把 axe-core 集成到 Playwright 或 Cypress 中并不难这样每次构建后都会自动跑一遍扫描至少能守住“不新增严重问题”的底线。3.2 读屏走查的八步法人工走查是测试框架里最考验经验的环节。拿 NVDA 举例我总结了一套八步法供大家参考打开 NVDA关闭浏览器其他干扰标签页从首页开始逐项按 F 键快速浏览页面中的表单域确认所有输入框、下拉框、按钮的可用标签都存在且描述清晰。用 Tab 键从页面顶部开始顺序遍历所有可交互元素记录焦点顺序是否符合视觉布局的阅读顺序是否有焦点被“跳过”或“困住”的情况。操作一个典型的搜索场景定位到搜索框输入关键词回车等待搜索结果加载听 NVDA 是否自动播报结果区域的标题或“结果数量”信息。操作办事服务流程逐步填写表单故意留空必填项听读屏是否准确播报错误提示、错误位置以及修改建议。进入登录页检查用户名、密码框的标签是否正确错误提示是否在焦点附近即时报出而不是只在页面顶部显示滚动条之外的消息。验证一个模态弹窗或下拉菜单组件打开后焦点是否移入弹窗关闭后焦点是否回到触发按钮读屏是否播报弹窗标题。切换页面到一个内容较多的政策文件页用 H 键在标题间跳转确认页面标题层级结构合理没有“跳级”现象例如从 H2 直接跳到 H4。最后在浏览器缩放比例调至 200% 的情况下用键盘操作一遍核心流程检查是否有横向滚动导致内容不可见的问题。以上每一步都要记录“读屏实际播报内容”和“预期播报内容”的差异这是最终缺陷报告的重要依据。比如 NVDA 对某个“关闭”按钮播报为“关闭 按钮”但实际它是个可点击的 emoji这时就要归为文本替代缺失。3.3 测试用例怎么写得既专业又不过度可访问性测试用例和普通功能用例在格式上类似但要素上有区别。每一条用例最好包含前置条件、操作路径、使用的辅助技术、预期结果、实际结果、对应 WCAG 成功标准编号。例如用例编号A11Y_Login_001前置条件已打开登录页NVDA 处于运行状态操作通过 Tab 键将焦点移动到“用户名”输入框输入内容再继续 Tab预期NVDA 播报“用户名 编辑框请输入用户名”等清晰字段描述焦点依次到达密码框、登录按钮标准WCAG 2.1.1、1.3.1我不建议把用例写成流水账式的大长串。政府网站页面多流程长最好按“每页一表、流程一表”的方式组织。页面用例卡记录静态层面的问题流程用例卡记录键盘、读屏操作下的交互缺陷。这样汇总问题的时候能快速区分“这个页面的静态结构问题”和“这条用户路径的交互障碍”方便开发团队分别指派给前端和测试。3.4 缺陷报告怎么写才能推动开发修复可访问性缺陷在开发眼中经常被看作“边缘问题”因为不影响鼠标用户也不影响功能执行。测试人员要改变这种偏见写缺陷报告时必须把影响人群和禁用场景讲清楚。我在报告里会包含五要素缺陷描述、复现路径含用到的读屏/键盘操作、WCAG 标准依据、影响用户群体、建议修复方向。下面给个示例标题首页搜索按钮无可见焦点样式键盘用户无法判断当前位置前置使用 Chrome NVDA键盘 Tab 键导航复现按 Tab 到达搜索按钮按钮没有高亮边框或背景变化影响低视力用户无法识别焦点位置容易执行错误操作依据WCAG 2.4.7 焦点可见AA建议为按钮增加 focus 外观样式不要仅依赖浏览器默认 outline这种形式的好处是开发能直接依据“建议”去改而不是拿着一个“不美观”的标题猜需求。我踩过这个坑早期写缺陷只写“页面存在可访问性问题”结果开发根本无从下手修复效率极低。后来改成一文定案式的描述开发基本能在一个迭代内清掉绝大部分严重问题。4. 常见问题与排查技巧实录我在政府网站项目中反复踩过的坑4.1 对比度问题不只在文字颜色上对比度是政府网站自动化扫描中最常见的问题类型而且经常不是出在小字号正文上而是出在“灰色占位符文字”“浅色按钮文字”“表格内嵌文字”这些边角位置。很多设计稿看起来漂亮文字和背景色对比较弱一测对比度就会被打回。这里有个实用的排查技巧用 Colour Contrast Analyzer 直接取色计算而不是靠肉眼判断。4.5:1 是 AA 级普通文字的标准3:1 适用于大号文字和界面组件图表。如果是深色底浅色字最好把前景色、背景色一起记录到缺陷报告中避免开发来回试色。4.2 表单标签缺失比想象中更致命政务网站最核心的办事功能几乎都离不开表单。常见表单问题有三类label 标签与输入框没有绑定用 placeholder 充当标签多个必填项缺少统一说明错误提示在点击提交后才出现且不在焦点附近。第一类问题尤其普遍因为很多开发图省事直接在 input 里加个 placeholder 就算完事。但对读屏用户来说placeholder 的播报兼容性很差一旦输入了内容提示文字可能消失或读不出来相当于失去字段含义。排查技巧是在 NVDA 中按 F 键循环遍历表单域播报内容里如果只有“编辑框”而没有“某某字段名”那就基本可以断定标签缺失。修复方向也很简单用 label 的 for 属性关联 id并且不要只依赖 placeholder。测试人员可以在用例中加一步“在字段中输入文字后再次用读屏获取焦点”观察字段名是否仍能读出。4.3 键盘可达性焦点顺序与焦点陷阱键盘可达性测试最烦的不是“不能操作”而是“焦点顺序混乱”和“焦点陷入陷阱”。焦点顺序混乱常见于 CSS 布局重排后DOM 顺序与视觉顺序不一致读屏用户按 Tab 时在页面上跳来跳去逻辑完全断掉。焦点陷阱则常出现在弹窗、对话框里焦点进入弹窗后Tab 无法移出到其他元素也无法通过 Esc 关闭弹窗此时用户等于被“困”在页面里。排查方法用键盘从页面顶部一步步 Tab 到最后每步截图或记录当前焦点元素。如果发现视觉上在左侧的按钮焦点却先跑到右侧就说明 DOM 顺序有问题需要调整代码结构而不是单纯调样式。遇到焦点陷阱第一件事是确认弹窗有没有“关闭”逻辑没有的话就是开发需要补 Esc 键监听和焦点循环管理。在报告这类问题时我习惯附上键盘操作的 Gif 或一段视频这种证据比文字描述更能让开发快速理解严重度。4.4 ARIA 标签滥用越“修饰”越糟ARIA 本意是增强无障碍但在实际项目里被大量误用。最典型的例子是把所有 div 加上 rolebutton却没有提供键盘事件支持或者为没有交互功能的元素加上 tabindex0导致读屏用户被一堆“可聚焦”的废元素干扰。自动化工具能扫出部分无效 ARIA 属性但无法判断这个 role 用得对不对。比如一个用 div 模拟的“热门政策”卡片开发给它加了 rolebutton实际点击区域只能鼠标触发键盘无法激活这在功能测试中根本不会被发现但在可访问性测试里是明显缺陷。排查技巧是看到任何自定义控件先追问“这个元素是否需要键盘可用”“是否能在读屏下描述其状态”。原则是优先使用原生 HTML 组件实在不行再用 ARIA 并严格对照用法。测试报告里遇到这类问题建议直接写“移除多余的 ARIA 属性或补全键盘交互”而不是只写“ARIA 使用不当”那样的描述缺乏指导性。4.5 非 HTML 内容PDF 和图片容易被放飞政府网站里有大量政策文件以 PDF 附件形式提供还有不少以图片形式展示的通知公告。这里有两个高频问题PDF 没有设置文字层读屏用户打开后只能听到“无法提取文本”图片型公告没有附带文案链接视觉受限用户完全无法获得信息。测试时需要抽样下载重点 PDF在 NVDA 环境下打开尝试读取正文。如果是扫描件就必须要求提供者补齐 OCR 文字层。图片型公告则要在页面上同时提供可复制文本或者为图片链接写清楚标题信息。这个问题的隐蔽性在于抽查比例可能十份 PDF 里只有两份有问题但如果用户恰好需要办事指南那就是百分之百的阻挡。5. 测试报告怎么输出才能既专业又有说服力5.1 报告的核心结构一份政府网站可访问性测试报告我习惯按五部分组织执行概要、标准范围、问题统计、明细清单、整改建议优先级。执行概要写给项目负责人看用两三段话说明本次测试覆盖范围、总体结论通过/有条件通过/不通过和必须优先处理的严重问题数量。问题统计部分用表格呈现问题分级严重/普通/轻微和对应数量同时按问题类型列占比如文字替代问题占 30%、焦点管理占 25%、对比度占 20% 等。明细清单则要具体到页面、截图、复现步骤、违规标准编号这部分是开发最依赖的内容。5.2 分级标准参考可以参考下面的分级规则将问题落地严重级别判定标准典型示例严重阻断核心任务完成或导致用户无法获取基本信息登录页无法用键盘完成输入办事指南 PDF 无法读屏访问普通任务可以完成但过程非常吃力存在大量附加障碍焦点顺序混乱但最终能到达目标错误提示信息不完整轻微任务可完成但体验打折或不符合规范细节某图标 alt 文本描述不够精确装饰性图片缺少空 alt严重级别和 WCAG 的 A/AA 并非完全一一对应但通常 WCAG A 级失败项我会直接标“严重”AA 级失败项标“普通”或“轻微”具体还要结合该元素是否影响用户核心任务。比如“键盘可操作”是 A 级如果登录按钮无法键盘激活那这就是严重问题。而“对比度 4.5:1”是 AA 级如果只是页脚一段不重要的灰色小字我会降为轻微虽然它依旧违反 AA 要求但优先修复那些影响用户理解的板块。5.3 推动整改的沟通技巧测试报告写出来只是起点更难的是推动开发修复。政府网站项目里经常会有“这个我们以前一直这样”“实际用户不会这么操作”这类反驳。我的经验有三条第一条永远先讲用户场景再讲技术标准比如“一位使用读屏的视障用户想在线申报这个事项他无法读取必填项提示这个申报流程就卡死在这里了”标准再来辅助论证。第二条把问题分级和修复成本对应起来多数严重问题的修复成本并不高比如补 label、加 focus 样式、调整 DOM 顺序这些都能在一个迭代内完成不要因问题数量多而心理畏惧。第三条争取在报告的每一类问题里放一个“修复前后对比”的小案例开发看见实际差异后接受度会高很多。我试过同一份报告只写问题列表和附对比案例后者的整改完成速度快了不少。6. 个人实践心得这几种情况一定要提前规避6.1 测试时间不足如何合理裁剪政府项目工期通常紧可访问性测试很容易被压缩成“扫一下 axe 输出一份问题清单”。我建议如果时间真的非常紧张至少保证两条一是首页和登录/办事流程的人工键盘走查必须做这是用户高频路径二是把 axe 扫描出来的 critical 级问题完整过一遍无论开发是否愿意修这些都要写进报告。千万不要在测试计划里省略人工走查这是自动化工具怎么堆都无法弥补的环节。6.2 避免“只测新版不看存量”网站改版时会涉及大量旧页面跳转很多测试人员只关心新页面忽略了老页面上的历史问题。这里有个真实案例某次改版后新闻列表页迁到了新模板但早年的公开文件 PDF 并没有同步处理结果用户从新页面点开旧 PDF 之后完全无法读屏访问。我后来在测试计划里专门加了一条“存量内容抽查”对每个栏目随机抽两到三份附件做读屏验证后续再没有出现这种漏网之鱼。6.3 让“可访问性”成为团队习惯而不是测试部门单独推进我逐渐意识到可访问性测试的最高境界是提前到设计和开发阶段介入。比如原型评审时就看设计稿的对比度、字号、焦点样式代码评审时提醒开发使用原生语义标签。等到页面全部开发完再测试必然有一些问题只能返工。如果团队没有这个文化测试人员也可以在每次测试报告里附一段“给下一迭代的 3 个最小改动建议”用温和的方式引导开发逐渐建立无障碍思维。这比单纯提 bug 更有效也是我个人在过去几个项目中感受最深的一点。另外最后再分享一个百试百灵的小技巧在测试政府网站的搜索功能时重点关注搜索结果页动态加载后读屏用户是否听到“结果列表已更新”这类提示。很多项目开发时只考虑了视觉用户看到列表刷新却没有给辅助技术提供任何通知这个问题在自动化工具里几乎无法暴露只能靠人工走查发现。每次能做到这一点我都有一种“这一下替用户挡了一把大坑”的满足感。 
长河君 · 2026/10/11 8:58:37 · 阅读 1.2k 政府网站可访问性测试实战：从WCAG标准到落地框架
可访问性测试在我这几年接手的政府网站项目里已经从“加分项”变成了“硬指标”。不少同行一听到政府网站测试第一反应就是功能、性能、兼容性实际上可访问性测试才是最容易暴雷、也最容易被忽略的一环。前阵子我配合团队完成了一批政府门户网站的无障碍改造验收测试从最初的一脸懵到后来沉淀出一套能直接套用的实战框架今天把这些东西完整拆开讲一讲。无论你是刚入门软件测试的萌新还是正在研究可访问性测试的资深工程师这篇都能给你一条相对完整的执行路径。政府网站不是普通商业站点它的用户覆盖全年龄段、全设备、全能力状态的人群。老年人要用放大镜看字体视障用户要靠读屏软件逐行朗读肢障用户可能只用键盘操作。让这些人都能顺利办成事、查得到信息这才是政府网站可访问性测试的核心价值。下面我直接把整套框架拆开从标准、工具、流程到避坑一次性讲透。1. 可访问性测试到底在测什么别把“无障碍”理解窄了1.1 它和传统“兼容性测试”有本质区别很多测试同学会把可访问性测试误当成兼容性测试的延伸觉得无非是多测几个浏览器、多调几个分辨率。这个认知是错的。兼容性测试关心的是不同环境下页面“能不能正常显示”可访问性测试关心的是“任何能力状况的用户能不能用”。兼容性追求的是“一致”可访问性追求的是“平等可用”。举个最简单的例子一个按钮如果只用鼠标能点击键盘操作永远无法获得焦点在传统功能测试里它完全没问题但在可访问性测试里这就是一个致命缺陷因为大量视障用户根本不使用鼠标。政府网站的可访问性测试通常要覆盖四层能力维度感知层面即文字、图形、音频能否被所有感官获取操作层面即所有功能是否能用键盘、语音等不同输入方式完成理解层面即界面信息是否清晰、一致、可预测兼容层面即站点能否配合各类辅助技术正常工作。前三个维度对应的是 WCAG 2.1 的“可感知、可操作、可理解”三大原则第四个维度对应“健壮性”合在一起就是国际通行的 POUR 原则。1.2 标准体系从 WCAG 2.1 到国内合规要求做政府网站可访问性测试最常引用的技术基准是 WCAG 2.1 的 A 级和 AA 级成功标准。A 级是底线比如“非文本内容提供替代文本”“仅用键盘可操作”AA 级是政府网站必须重点保障的比如“对比度达到 4.5:1”“错误提示能被感知”。国内政务网站的无障碍建设要求也基本对标 WCAG 2.1 AA 级很多地区还明确了完成时限和验收规范。这里我想特别提一下测试标准的落地方式。实际测试中我们不会真把几十项标准背下来而是将 WCAG 规则映射成一张“检查清单”。例如“1.1.1 非文本内容”对应到实操就是“每张 img 都要有 alt 属性且 alt 内容能表达图片意图”“2.1.1 键盘”对应到实操就是“页面所有可交互元素都必须能用 Tab 键到达并用 Enter 或空格键激活”。这种映射是搭建测试框架的第一步后面每一轮用例设计都会用到。1.3 政府网站的高风险页面类型不是所有页面都需要投入同等的测试力度。根据我的项目经验政府网站里有几类页面必须优先覆盖首页信息密度最高、组件最复杂、办事服务页涉及用户填写表单、上传材料、支付缴费、搜索结果页动态加载、结果朗读逻辑复杂、个人中心/登录页涉及会话状态和隐私信息。这些页面一旦出问题用户可能连最基本的“在线办理”都走不通。我建议在测试计划里直接按页面风险等级排序高优先级是办事服务、在线查询、支付、登录相关流程中优先级是首页、新闻资讯、政策文件页低优先级是辅助功能页如隐私政策、网站地图。这样排的好处是即使测试时间被压缩也能保证最核心的政务办事链路被覆盖到而不是平均发力导致哪里都没测透。2. 一套可落地的测试框架从标准到流程的搭建步骤2.1 先定测试策略自动化与人工结合的“三明治”模型可访问性测试想只靠自动化工具跑一遍就出具报告基本是自欺欺人。自动化工具能发现约 30% 到 40% 的可访问性问题比如缺失的 alt 文本、错误的对比度、无效的 ARIA 属性但大量语义性、上下文相关的问题只能靠人工判断。例如一个图片按钮alt 文本是否准确描述其功能自动化工具无法判断一段内容是否让读屏用户理解歧义也需要真人都检查一遍。我实际使用的策略是“自动化扫描打底人工走查承接真实用户验证收口”。第一轮用 axe-core、WAVE 等工具全量扫描站点页面快速筛出语法级问题第二轮由测试人员用 NVDA、VoiceOver 等读屏软件对关键流程做人工走查第三轮如果条件允许找一两位真实用户尤其是老年或视障用户做任务测试。这三层叠加起来覆盖面才能接近真实使用场景。注意前两轮是必须做的第三轮如果预算或资源不足可以缩减但高风险流程至少要有一次人工读屏验证。2.2 工具选型没有All-in-One组合拳才是正解我常用的一套工具组合如下自动化扫描用 axe DevTools浏览器插件版以及配套的 axe-core适合集成到自动化测试脚本里页面整体评估用 WAVE 的网页版或插件版它能直观地在页面上覆盖一层遮罩显示各类问题对比度检测用 Colour Contrast Analyzer一款桌面工具或者 axe 内置的对比度检查屏幕阅读器测试用 Windows 平台上的 NVDA免费且实用和 macOS 上的 VoiceOver。如果有条件定期用 JAWS 做一次交叉验证毕竟国内读屏用户中 NVDA 的占比很高但 JAWS 也是海外政府网站广泛依赖的工具。选择工具时要注意版本匹配。比如 NVDA 每次更新后对网页元素朗读顺序的处理可能会有细微变化测试前最好固定环境版本否则同一个页面可能因为读屏版本不同而得出不同的结论。我在项目里会专门写一份“测试环境配置表”记录浏览器版本、读屏软件版本、操作系统版本避免后期出现“你测的和我测的不一样”的扯皮。2.3 测试流程模板从一个立项到一份报告的标准化动作我把政府网站可访问性测试的流程整理成六个阶段需求解读与标准对齐、页面清单梳理、用例设计、自动化扫描、人工走查、报告输出与复测。每个阶段都有明确产出物这样做的好处是方便排期也方便向甲方交代进度。页面清单梳理是个容易被忽略但特别重要的环节需要和开发、产品一起确认本次改动涉及哪些页面同时确定“测试基线页面”和“改动页面”两批列表。比如网站改版后首页、列表页、详情页都变了但内部搜索页没变那就不能把所有页面都押到同一轮测试里。用例设计阶段我会直接套用 WCAG 2.1 的映射清单按页面类型生成用例同时把用户最核心的任务流例如“查询某事项办事指南→在线下载申请表→返回首页”串成端到端场景。这里有个心得单个页面的可访问性测试只能证明“每个零件是好的”端到端流程测试才能证明“整条链路是通的”。读屏用户从列表页跳到详情页焦点是否被正确移动到新页面顶部这往往是单靠检查逐个页面发现不了的问题。3. 核心环节实操扫描、走查与用例编写3.1 自动化扫描的正确打开方式我用 axe DevTools 做了个示例动作打开目标页面F12 进入开发者工具在 axe 标签页点击“Scan ALL”按钮几十秒后会列出所有违反规则项每一项都给出影响级别serious/critical/minor和修复建议。但这里必须提醒不要盲目修完就认为任务结束。axe 输出的每一项都需要人工确认是否属于“误报”或“需要结合语义判断”。例如某个 color 对比度检测报出的问题如果该元素实际上只是装饰性背景图上的纯色文字就需要测试人员结合视觉结果写备注而不是直接丢给前端改色值。自动化扫描建议在页面内容相对冻结后执行不要在开发频繁改代码的中途反复全量扫描那样只会产生大量无效的临时问题记录。我一般会在提测前一天做第一轮全量扫描记录问题基线然后在修复完成后再扫一轮对比基线确认修复情况。至于是否要接入 CI/CD要看项目实际情况。如果团队有自动化测试体系把 axe-core 集成到 Playwright 或 Cypress 中并不难这样每次构建后都会自动跑一遍扫描至少能守住“不新增严重问题”的底线。3.2 读屏走查的八步法人工走查是测试框架里最考验经验的环节。拿 NVDA 举例我总结了一套八步法供大家参考打开 NVDA关闭浏览器其他干扰标签页从首页开始逐项按 F 键快速浏览页面中的表单域确认所有输入框、下拉框、按钮的可用标签都存在且描述清晰。用 Tab 键从页面顶部开始顺序遍历所有可交互元素记录焦点顺序是否符合视觉布局的阅读顺序是否有焦点被“跳过”或“困住”的情况。操作一个典型的搜索场景定位到搜索框输入关键词回车等待搜索结果加载听 NVDA 是否自动播报结果区域的标题或“结果数量”信息。操作办事服务流程逐步填写表单故意留空必填项听读屏是否准确播报错误提示、错误位置以及修改建议。进入登录页检查用户名、密码框的标签是否正确错误提示是否在焦点附近即时报出而不是只在页面顶部显示滚动条之外的消息。验证一个模态弹窗或下拉菜单组件打开后焦点是否移入弹窗关闭后焦点是否回到触发按钮读屏是否播报弹窗标题。切换页面到一个内容较多的政策文件页用 H 键在标题间跳转确认页面标题层级结构合理没有“跳级”现象例如从 H2 直接跳到 H4。最后在浏览器缩放比例调至 200% 的情况下用键盘操作一遍核心流程检查是否有横向滚动导致内容不可见的问题。以上每一步都要记录“读屏实际播报内容”和“预期播报内容”的差异这是最终缺陷报告的重要依据。比如 NVDA 对某个“关闭”按钮播报为“关闭 按钮”但实际它是个可点击的 emoji这时就要归为文本替代缺失。3.3 测试用例怎么写得既专业又不过度可访问性测试用例和普通功能用例在格式上类似但要素上有区别。每一条用例最好包含前置条件、操作路径、使用的辅助技术、预期结果、实际结果、对应 WCAG 成功标准编号。例如用例编号A11Y_Login_001前置条件已打开登录页NVDA 处于运行状态操作通过 Tab 键将焦点移动到“用户名”输入框输入内容再继续 Tab预期NVDA 播报“用户名 编辑框请输入用户名”等清晰字段描述焦点依次到达密码框、登录按钮标准WCAG 2.1.1、1.3.1我不建议把用例写成流水账式的大长串。政府网站页面多流程长最好按“每页一表、流程一表”的方式组织。页面用例卡记录静态层面的问题流程用例卡记录键盘、读屏操作下的交互缺陷。这样汇总问题的时候能快速区分“这个页面的静态结构问题”和“这条用户路径的交互障碍”方便开发团队分别指派给前端和测试。3.4 缺陷报告怎么写才能推动开发修复可访问性缺陷在开发眼中经常被看作“边缘问题”因为不影响鼠标用户也不影响功能执行。测试人员要改变这种偏见写缺陷报告时必须把影响人群和禁用场景讲清楚。我在报告里会包含五要素缺陷描述、复现路径含用到的读屏/键盘操作、WCAG 标准依据、影响用户群体、建议修复方向。下面给个示例标题首页搜索按钮无可见焦点样式键盘用户无法判断当前位置前置使用 Chrome NVDA键盘 Tab 键导航复现按 Tab 到达搜索按钮按钮没有高亮边框或背景变化影响低视力用户无法识别焦点位置容易执行错误操作依据WCAG 2.4.7 焦点可见AA建议为按钮增加 focus 外观样式不要仅依赖浏览器默认 outline这种形式的好处是开发能直接依据“建议”去改而不是拿着一个“不美观”的标题猜需求。我踩过这个坑早期写缺陷只写“页面存在可访问性问题”结果开发根本无从下手修复效率极低。后来改成一文定案式的描述开发基本能在一个迭代内清掉绝大部分严重问题。4. 常见问题与排查技巧实录我在政府网站项目中反复踩过的坑4.1 对比度问题不只在文字颜色上对比度是政府网站自动化扫描中最常见的问题类型而且经常不是出在小字号正文上而是出在“灰色占位符文字”“浅色按钮文字”“表格内嵌文字”这些边角位置。很多设计稿看起来漂亮文字和背景色对比较弱一测对比度就会被打回。这里有个实用的排查技巧用 Colour Contrast Analyzer 直接取色计算而不是靠肉眼判断。4.5:1 是 AA 级普通文字的标准3:1 适用于大号文字和界面组件图表。如果是深色底浅色字最好把前景色、背景色一起记录到缺陷报告中避免开发来回试色。4.2 表单标签缺失比想象中更致命政务网站最核心的办事功能几乎都离不开表单。常见表单问题有三类label 标签与输入框没有绑定用 placeholder 充当标签多个必填项缺少统一说明错误提示在点击提交后才出现且不在焦点附近。第一类问题尤其普遍因为很多开发图省事直接在 input 里加个 placeholder 就算完事。但对读屏用户来说placeholder 的播报兼容性很差一旦输入了内容提示文字可能消失或读不出来相当于失去字段含义。排查技巧是在 NVDA 中按 F 键循环遍历表单域播报内容里如果只有“编辑框”而没有“某某字段名”那就基本可以断定标签缺失。修复方向也很简单用 label 的 for 属性关联 id并且不要只依赖 placeholder。测试人员可以在用例中加一步“在字段中输入文字后再次用读屏获取焦点”观察字段名是否仍能读出。4.3 键盘可达性焦点顺序与焦点陷阱键盘可达性测试最烦的不是“不能操作”而是“焦点顺序混乱”和“焦点陷入陷阱”。焦点顺序混乱常见于 CSS 布局重排后DOM 顺序与视觉顺序不一致读屏用户按 Tab 时在页面上跳来跳去逻辑完全断掉。焦点陷阱则常出现在弹窗、对话框里焦点进入弹窗后Tab 无法移出到其他元素也无法通过 Esc 关闭弹窗此时用户等于被“困”在页面里。排查方法用键盘从页面顶部一步步 Tab 到最后每步截图或记录当前焦点元素。如果发现视觉上在左侧的按钮焦点却先跑到右侧就说明 DOM 顺序有问题需要调整代码结构而不是单纯调样式。遇到焦点陷阱第一件事是确认弹窗有没有“关闭”逻辑没有的话就是开发需要补 Esc 键监听和焦点循环管理。在报告这类问题时我习惯附上键盘操作的 Gif 或一段视频这种证据比文字描述更能让开发快速理解严重度。4.4 ARIA 标签滥用越“修饰”越糟ARIA 本意是增强无障碍但在实际项目里被大量误用。最典型的例子是把所有 div 加上 rolebutton却没有提供键盘事件支持或者为没有交互功能的元素加上 tabindex0导致读屏用户被一堆“可聚焦”的废元素干扰。自动化工具能扫出部分无效 ARIA 属性但无法判断这个 role 用得对不对。比如一个用 div 模拟的“热门政策”卡片开发给它加了 rolebutton实际点击区域只能鼠标触发键盘无法激活这在功能测试中根本不会被发现但在可访问性测试里是明显缺陷。排查技巧是看到任何自定义控件先追问“这个元素是否需要键盘可用”“是否能在读屏下描述其状态”。原则是优先使用原生 HTML 组件实在不行再用 ARIA 并严格对照用法。测试报告里遇到这类问题建议直接写“移除多余的 ARIA 属性或补全键盘交互”而不是只写“ARIA 使用不当”那样的描述缺乏指导性。4.5 非 HTML 内容PDF 和图片容易被放飞政府网站里有大量政策文件以 PDF 附件形式提供还有不少以图片形式展示的通知公告。这里有两个高频问题PDF 没有设置文字层读屏用户打开后只能听到“无法提取文本”图片型公告没有附带文案链接视觉受限用户完全无法获得信息。测试时需要抽样下载重点 PDF在 NVDA 环境下打开尝试读取正文。如果是扫描件就必须要求提供者补齐 OCR 文字层。图片型公告则要在页面上同时提供可复制文本或者为图片链接写清楚标题信息。这个问题的隐蔽性在于抽查比例可能十份 PDF 里只有两份有问题但如果用户恰好需要办事指南那就是百分之百的阻挡。5. 测试报告怎么输出才能既专业又有说服力5.1 报告的核心结构一份政府网站可访问性测试报告我习惯按五部分组织执行概要、标准范围、问题统计、明细清单、整改建议优先级。执行概要写给项目负责人看用两三段话说明本次测试覆盖范围、总体结论通过/有条件通过/不通过和必须优先处理的严重问题数量。问题统计部分用表格呈现问题分级严重/普通/轻微和对应数量同时按问题类型列占比如文字替代问题占 30%、焦点管理占 25%、对比度占 20% 等。明细清单则要具体到页面、截图、复现步骤、违规标准编号这部分是开发最依赖的内容。5.2 分级标准参考可以参考下面的分级规则将问题落地严重级别判定标准典型示例严重阻断核心任务完成或导致用户无法获取基本信息登录页无法用键盘完成输入办事指南 PDF 无法读屏访问普通任务可以完成但过程非常吃力存在大量附加障碍焦点顺序混乱但最终能到达目标错误提示信息不完整轻微任务可完成但体验打折或不符合规范细节某图标 alt 文本描述不够精确装饰性图片缺少空 alt严重级别和 WCAG 的 A/AA 并非完全一一对应但通常 WCAG A 级失败项我会直接标“严重”AA 级失败项标“普通”或“轻微”具体还要结合该元素是否影响用户核心任务。比如“键盘可操作”是 A 级如果登录按钮无法键盘激活那这就是严重问题。而“对比度 4.5:1”是 AA 级如果只是页脚一段不重要的灰色小字我会降为轻微虽然它依旧违反 AA 要求但优先修复那些影响用户理解的板块。5.3 推动整改的沟通技巧测试报告写出来只是起点更难的是推动开发修复。政府网站项目里经常会有“这个我们以前一直这样”“实际用户不会这么操作”这类反驳。我的经验有三条第一条永远先讲用户场景再讲技术标准比如“一位使用读屏的视障用户想在线申报这个事项他无法读取必填项提示这个申报流程就卡死在这里了”标准再来辅助论证。第二条把问题分级和修复成本对应起来多数严重问题的修复成本并不高比如补 label、加 focus 样式、调整 DOM 顺序这些都能在一个迭代内完成不要因问题数量多而心理畏惧。第三条争取在报告的每一类问题里放一个“修复前后对比”的小案例开发看见实际差异后接受度会高很多。我试过同一份报告只写问题列表和附对比案例后者的整改完成速度快了不少。6. 个人实践心得这几种情况一定要提前规避6.1 测试时间不足如何合理裁剪政府项目工期通常紧可访问性测试很容易被压缩成“扫一下 axe 输出一份问题清单”。我建议如果时间真的非常紧张至少保证两条一是首页和登录/办事流程的人工键盘走查必须做这是用户高频路径二是把 axe 扫描出来的 critical 级问题完整过一遍无论开发是否愿意修这些都要写进报告。千万不要在测试计划里省略人工走查这是自动化工具怎么堆都无法弥补的环节。6.2 避免“只测新版不看存量”网站改版时会涉及大量旧页面跳转很多测试人员只关心新页面忽略了老页面上的历史问题。这里有个真实案例某次改版后新闻列表页迁到了新模板但早年的公开文件 PDF 并没有同步处理结果用户从新页面点开旧 PDF 之后完全无法读屏访问。我后来在测试计划里专门加了一条“存量内容抽查”对每个栏目随机抽两到三份附件做读屏验证后续再没有出现这种漏网之鱼。6.3 让“可访问性”成为团队习惯而不是测试部门单独推进我逐渐意识到可访问性测试的最高境界是提前到设计和开发阶段介入。比如原型评审时就看设计稿的对比度、字号、焦点样式代码评审时提醒开发使用原生语义标签。等到页面全部开发完再测试必然有一些问题只能返工。如果团队没有这个文化测试人员也可以在每次测试报告里附一段“给下一迭代的 3 个最小改动建议”用温和的方式引导开发逐渐建立无障碍思维。这比单纯提 bug 更有效也是我个人在过去几个项目中感受最深的一点。另外最后再分享一个百试百灵的小技巧在测试政府网站的搜索功能时重点关注搜索结果页动态加载后读屏用户是否听到“结果列表已更新”这类提示。很多项目开发时只考虑了视觉用户看到列表刷新却没有给辅助技术提供任何通知这个问题在自动化工具里几乎无法暴露只能靠人工走查发现。每次能做到这一点我都有一种“这一下替用户挡了一把大坑”的满足感。