我最早接触可访问性测试是在一个政务类项目的测试方案评审会上。当时开发负责人说了句让我印象很深的话无障碍嘛你们拿工具扫一遍把红色的修完不就完了。后来我真的拿工具扫了三个页面红色的确实不少但他不知道的是真正严重的几个问题工具一条都没报出来。从那时起我就意识到可访问性测试这件事如果只当它是一个“标准动作”那多半做不透如果当成一个普通的测试专项来设计反而能做出真正可落地的框架。这篇文章想写给那些刚接手政务网站测试、或者打算把可访问性测试引入团队的人。不会讲太多漂在空中的理论重点是把这套活儿拆成几个层面、用什么工具、按什么顺序做以及我在实际项目里踩过的坑。1. 可访问性测试到底在测什么先分清这套活儿的真实范围1.1 三个误区听上去合理做起来全错可访问性测试最容易走进的第一个误区就是把它窄化成“残障用户专属测试”。测试经理一说“这个功能要做无障碍”大家脑子里立刻想到屏幕阅读器、盲人用户。但真实世界里的障碍远比这复杂一个用户可能在大太阳底下看不清屏幕可能因为手臂受伤只能用一只手操作手机可能只是年纪大了字小了看不清楚。这些都属于“情境性障碍”。可访问性测试的本质是保证所有人都能在不同场景下完成业务目标而不是只给某类特定人群开一条特殊通道。第二个误区是“工具扫完没报错就通过了”。工具只能判断它能用规则机械判定的东西比如某个 img 有没有 alt 属性某个按钮颜色对比度是不是低于阈值。它判断不了“这段链接文字放到读屏里听用户是否明白它指向哪里”也判断不了“一个流程在键盘下面能不能走通”。我见过太多项目把自动化扫描结果当成可访问性测试的全部最后上线之前手工一测关键表单根本没法用键盘提交。第三个误区是“这活应该在测试阶段做”。如果需求阶段没有可访问性验收标准测试阶段只能发现问题、提缺陷、等开发返工改一轮还可能带出新问题。政务类网站页面多、交互散、历史包袱重尤其经不起这种返工。正确做法是从需求评审开始就把可访问性要求写清楚后面所有测试工作才有依据。1.2 政务网站为什么比普通商业网站更需要扎实的可访问性测试政务网站是典型的“用户不能选”的产品。商业网站体验不好用户最多流失影响的是转化率政务类系统不一样用户为了办一件事必须走完特定路径没有替代入口也没法绕路。这决定了可访问性缺陷带来的后果不是“少几个访问量”而是一部分用户可能根本做不成事。更麻烦的是用户群体极度分散。有天天用手机的重度用户也有难得用一次电脑的老年人有视力正常的也有依赖读屏软件的视障用户有鼠标键盘都顺手的也有只能靠键盘或者语音输入的。这么多不同类型的用户要在同一套系统里完成同一条业务测试范围自然比普通内容型网站要宽得多。我做过一个对比同一套自动化规则跑普通营销页面能扫出的有效问题占比很高但落到政务办事流程页面上还得额外查焦点顺序、读屏朗读顺序、错误提示、表单可回退性这些根本不是扫描工具能一键解决的。所以我一直觉得政务网站的可访问性测试必须把“关键任务流程”当成第一测试对象而不是把“页面数量多不多”当成判定测试范围的标准。1.3 把四大原则翻译成可执行的测试动作可访问性领域提到最多的就是 WCAG 的四大原则可感知、可操作、可理解、健壮性。名字听起来抽象落到测试动作上其实相当具体。可感知信息必须能通过多种方式被接收。对应测试动作是检查图片替代文本、检查视频字幕、检查正文和背景的对比度。可操作用户必须能用各种方式操作界面。对应键盘焦点、可点击区域大小、操作时限、防止误触。可理解内容和界面不能让人困惑。对应页面语言标记、错误提示、导航一致性、表单输入提示。健壮性代码要能兼容不同辅助技术。对应语义化标签、ARIA 属性是否合法、自定义组件能否被读屏理解。这四个原则不是并列的四条清单而是组合关系。一个按钮即使对比度合格键盘用户也可能根本触达不了即使能触达读屏朗读出的名称含糊用户还是不知道要不要点。所以我做测试的时候习惯把四大原则拆成“通用检查项”和“流程级检查项”通用项用工具批量扫流程级必须靠手工场景一步步走。这个分工后面会详细展开。2. 标准与工具选型先用WCAG 2.1 AA打底别什么新追什么2.1 标准基线怎么定别让团队在一个模糊的“最新版”上打转很多团队一上来就问你们支持最新版的 WCAG 吗好像越新越专业。这里我想泼点冷水对存量政务网站来说最务实的基线是WCAG 2.1 AA。WCAG 2.0 是早期系统的常用参考但它缺少对移动端、手势操作、目标尺寸、文本间距这些场景的覆盖WCAG 2.1 在 2.0 基础上补了这些内容而且大部分自动化工具默认就支持WCAG 2.2 又加了一些新规则但它里面少数条目对设计约束比较大更适合新项目或后续迭代去追。测试团队真正要做的是和产品确认一个明确基线然后所有报告、缺陷、验收都围绕这个基线说话。不要一边按 2.0 核对一边把 2.2 的建议混进缺陷单项目一定会乱。我给团队的建议是核心流程按 WCAG 2.1 AA 来AAA 级别的标准只在确实容易做到的页面里顺手做不强求。你不是在给项目背书“绝对无障碍”而是在建立一套可执行、可度量的质量基线。2.2 自动化工具能做什么、不能做什么自动化可访问性测试工具不少但别指望一个工具解决所有问题。根据我的经验自动化能比较可靠地覆盖 WCAG A/AA 里大概三到四成的判断项其余必须靠人工。工具擅长的是“存在性、语法、结构性”问题图片缺少替代文本表单控件没有 label颜色对比度低于阈值页面缺少 lang 属性aria 属性拼写错误或者用在不合法的元素上工具不擅长的是“语义理解”类问题一段链接文字读起来是否清晰、读屏逐句听下来顺序是否合理、错误提示是否真的让用户明白下一步做什么、交互流程在键盘下是否完整。这些差异决定了选型策略多个工具搭配解决的是广度工具加人工解决的才是深度。2.3 常用工具怎么选一张对照表加一套组合建议下面这组工具是我在政务项目中实际用过的按适用场景列了一张表工具定位输出形式适合场景axe-core规则引擎代码级检查JSON / HTML集成到组件测试、CIpa11y页面级批量扫描底层是 axeJSON / HTML / CSV多页面回归、趋势跟踪Lighthouse综合审计含可访问性HTML / JSON整体基线和性能一起看WAVE浏览器插件可视化标注页面内标记快速演示、给开发看现场NVDA / VoiceOver手工验证工具无 / 人工键盘和读屏真实体验选型建议就一句话自动化层面别贪多。资源充足就用 axe-core 加 pa11y一个管组件和代码一个管页面和回归暂时搭不起自动化环境的团队先用 WAVE 插件把页面跑一遍再手工过键盘和读屏。商业工具通常有更漂亮的报表和团队协同功能但如果目标是先把测试引入项目开源组合足够起步。3. 自动化扫描落地从“扫一次首页”到“全流程回归”3.1 起步用 pa11y 批量扫一组核心页面最基础的做法是单页扫描npm install -g pa11y pa11y https://example.gov.cn/guide --reporter html guide.html这适合临时验证不适合长期回归。我建议从第一天就把页面清单固化成配置文件比如在项目里创建一个 urls 数组写一个简单的 Node 脚本去跑const pa11y require(pa11y); const urls [ https://example.gov.cn/, https://example.gov.cn/guide, https://example.gov.cn/search?qexample ]; async function run() { for (const url of urls) { const result await pa11y(url); const errors result.issues.filter((item) item.type error); console.log(url, , errors.length, errors); } } run();这里的 URL 要换成你自己的测试环境地址。跑之前先把情绪稳住很少有人第一次跑就是绿色报告。这个阶段的目标不是清零而是建立基线知道问题集中在哪些规则上、哪些页面最严重。固定页面清单的意义在于后续能对比趋势而不是随便扫几个页面给自己看。3.2 登录态和动态页面只扫首页等于白扫政务网站的核心业务大多在登录之后如果一个自动化项目只覆盖登录页和首页那基本说明这个自动化还没进入真正的业务。解决登录态有两种常见姿势。第一种是把浏览器登录后的 Cookie 保存下来在 pa11y 配置里带上 Cookie第二种更稳用 Puppeteer 先做登录再对目标页面运行 axe。示例代码如下const puppeteer require(puppeteer); const { AxePuppeteer } require(axe-core/puppeteer); (async () { const browser await puppeteer.launch({ headless: true }); const page await browser.newPage(); await page.goto(https://example.gov.cn/login); await page.type(#username, test-user); await page.type(#password, test-pass); await Promise.all([ page.waitForNavigation(), page.click(#login-btn) ]); await page.goto(https://example.gov.cn/apply-form); const results await new AxePuppeteer(page).analyze(); console.log(results.violations.map((v) v.id)); await browser.close(); })();这段代码里的选择器要按项目实际情况调整。跑动态页面时有个容易被忽略的坑页面里如果有 Tabs、手风琴、弹窗工具默认只扫当前可见区域很多藏在折叠区域里的缺陷会漏掉。所以扫描脚本里要先手动展开这些区域再执行 analyze否则报告看着挺干净但实际覆盖范围根本不够。3.3 组件级扫描让问题在设计阶段就被发现页面级扫描最大的缺点是定位慢。一百个页面里五十个报同一个按钮对比度问题数量虽多根因可能只在一个公共组件里。与其逐页提单不如把精力花在组件级扫描上。如果项目有 Storybook 这类组件库直接对组件渲染页跑 axe没有组件库就在测试仓库里准备一份“高频组件页面”把按钮、输入框、下拉、表格、分页、弹窗这些通用组件集中渲染统一扫描。这样做有两个好处一是问题定位精准报错能直接对应到组件源码二是修复收益大组件改一次全站受益。注意不要为了搞组件扫描先搭一套组件库那是本末倒置。你只需要把当前页面里高频使用的组件挑出来渲染到一个 HTML 里跑一次自动检查就能看出哪些公共组件欠着可访问性的债。3.4 报告去噪别让建议级问题淹没真正的严重缺陷我见过不少团队自动化报告一跑就是两三百个问题开发看到第一眼就放弃治疗。其实里面相当一部分是 best practice 级别的建议比如“建议给这个链接加下划线”。不是说不对而是优先级低不该和严重缺陷混在一起。比较合理的做法是把 serious 和 critical 级别的问题设为 CI 拦截条件把 moderate 和 best practice 单独归档整理成改进项。pa11y 配置示例{ standard: WCAG2AA, ignore: [], includeNotices: false, includeWarnings: false }ignore 数组要克制使用尤其不要因为某一页报了一堆误报就整体忽略某条规则。如果确实属于误报应该在注释或说明文档里写清楚理由否则三个月后没人知道这条路为什么被堵上问题又会悄悄回来。3.5 自动化误报和漏报的真实案例这里分享几个我在政务项目里实际遇到的坑。第一个是对比度误报。当文字背景是渐变或半透明图片时axe 的 color-contrast 计算依赖背景颜色经常给出一个看似严重、实际并不准确的结果。遇到这种情况要手动用取色器取文字和实际背景色算一下真实对比度再决定是否提交缺陷。第二个是 label 误报。有些自定义选择框内部已经用了 aria-labelledby 指向一个隐藏的说明容器读屏实际朗读正常但工具会报“表单控件没有标签”。这种问题不需要改代码正确做法是确认读屏输出后再按条目忽略并写清楚理由。第三个是动态区域漏报。前面说过 Tabs 和弹窗内容自动化默认扫不到解决的办法是扫描前主动展开所有可展开区域。自动化报告的价值在于“快”不在于“绝对准”这一点一定得在团队里说明白否则后面所有基于工具结论的争执都会消耗精力。4. 手工测试键盘、读屏、对比度之外更要测任务能不能完成4.1 键盘遍历用 Tab 走完一条业务主线手工可访问性测试性价比最高的起点是放下鼠标用键盘走一条真实业务线。以“在线提交申请”为例我的固定步骤是Tab 从地址栏进入页面看焦点落到哪里依次走完搜索、筛选、进入详情、填写表单、上传附件、提交每一步都关注焦点是否可见、顺序是否合理、有没有被莫名吸进某个弹窗。政务用户体验里比较典型的问题是打开弹窗后焦点还停留在页面最后用户完全不知道弹窗已打开关闭弹窗后焦点没有回到触发按钮读屏用户要从头再找一遍。代码层面通常是弹窗用了 display 切换但完全没有焦点管理。注意不要为了解决焦点问题给所有 div 加 tabindex那样只会制造更多操作障碍。正确的做法是给真正可交互的控件维护可见焦点弹窗类组件打开时把焦点移到弹窗标题或第一个控件关闭时归还焦点到触发按钮。4.2 屏幕阅读器测试先学会听再追求操作熟练读屏测试最大的门槛不是工具本身而是测试人员不习惯“听页面”。我建议新手不要一上来就背快捷键先用 NVDA 加 Chrome或者 VoiceOver 加 Safari打开一个页面按 Tab 或上下箭头听一遍。听的时候只回答三个问题它能告诉我现在在哪个区域吗它能告诉我正在操作什么控件吗它能告诉我当前状态吗政务网站常见的读屏问题包括页面顶部没有跳过导航的链接读屏用户每次都要从导航开始听表单输入框的 label 和输入框在 DOM 里离得太远读屏无法建立关联图片虽然有 alt但 alt 写的是“图片”两个字等于没写。这里有个很深的经验ARIA 用错了比不用更糟。比如在普通按钮上强行加 rolebutton读屏可能会忽略原生按钮已有的键盘支持反而让按钮变得不可操作。所以遇到读屏问题先检查能不能用原生语义完成再用 ARIA 去补缺口而不是反过来。4.3 颜色对比度只是及格线颜色不能成为唯一的信息通道对比度测试是最容易被自动化覆盖的但对比度通过不代表色觉相关的可访问性通过。举个例子表单里有一项必填前端用红色星号提示提交时校验失败又把边框标红。对红绿色弱用户来说很可能分不清哪些字段有问题。正确的做法是错误信息同时用文字描述“请填写姓名”必填项同时用星号和“必填”文字链接如果只用颜色区分至少加上下划线。政务网站里的“材料清单”和“下载按钮”经常大量依赖图标和颜色区分我遇到过一个页面三个按钮图标颜色不同、功能不同但文字和结构完全一样读屏用户点开根本分不清哪个是上传、哪个是下载。这类问题只能靠手工测试。操作上可以使用 DevTools 的 Rendering 面板开启模拟色觉障碍比如红色盲、绿色盲快速过一遍页面截图效率非常高。4.4 移动端、字体缩放和触控目标很多人以为可访问性测试只针对桌面端但政务网站现在的实际用户里有大量手机用户。移动端测试我重点关注四件事。一是页面是否允许浏览器缩放如果 viewport 里设置了 maximum-scale1 或者 user-scalableno等于主动关掉了视觉障碍用户放大的能力这类问题直接按严重缺陷提。二是把系统字体放大到 200% 后的页面表现。文字截断、控件重叠、弹窗内容溢出都非常常见。三是按钮和链接的点击目标尺寸WCAG 2.1 里对目标大小有建议政务表单里常见的问题是单选按钮和复选框的可点击区域做得太小用户点不准。四是横屏和竖屏方向要不要锁定除非业务有明确要求否则不要锁定方向。移动端可访问性检查不要和“响应式好看”混在一起。页面上看起来美观的组件放大后可能完全不可用这两件事必须分开对待。5. 缺陷定级与推动修复让可访问性问题不再排在“有空再说”5.1 先给缺陷建立统一的定级标准可访问性缺陷如果不定级开发收到的就是一个大杂烩谁看了都头疼。我在项目中习惯把级别和业务影响绑在一起严重P1核心业务路径不可用。比如关键按钮无法用键盘触达、读屏无法填写必填字段、没有替代文本导致图像信息完全不可读。中等P2核心路径可用但存在明显障碍。比如焦点顺序混乱、页面标题不清晰、对比度不足、弹窗焦点不管理。轻微P3不影响任务完成但体验不佳。比如与业务无关的装饰性图片没有 alt、部分 best practice 建议。举例来说“提交申请”按钮在键盘遍历中焦点不可见属于 P1因为业务根本无法操作而页脚里一组旧年份数据对比度偏低只要不是核心入口可以定 P2 或者 P3。政务网站缺陷定级时我还会叠加一个因素这个缺陷是否影响后续步骤的正常完成。比如某个选择控件读屏朗读错误用户选了 A 实际提交 B这就是 P1因为已经造成错误操作。5.2 缺陷单的写法可复现带标准给建议普通功能缺陷写“标题加复现步骤加截图”基本就够可访问性缺陷不够。我用的模板是这样的环境浏览器版本、操作系统、读屏工具版本操作路径用键盘或读屏的完整操作过程实际表现焦点卡在哪、读屏朗读了什么、视觉上少了什么预期表现焦点应该去哪、读屏应该朗读什么、图标应该伴随什么文字标准引用对应 WCAG 2.1 的成功准则编号修复建议指出大概的代码方向举个例子“个人中心页面按 Tab 到‘材料上传’按钮按空格打开文件选择对话框后焦点被重置到页面顶部读屏没有提示弹窗打开。预期焦点进入弹窗标题按 Esc 可关闭弹窗关闭后焦点回到‘材料上传’按钮。对应 2.4.3 焦点顺序和 4.1.2 名称与角色。建议打开弹窗时把焦点移到弹窗标题标题设置 tabindex-1关闭时手动归还焦点到触发按钮。”这样的单子开发不用猜直接照着做就行。5.3 推动修复的协作技巧让开发听一次比发十份报告有用自动化报告堆在缺陷库里没有意义真正能让可访问性问题被修掉的往往是团队意识的转变。我的做法是组织一次“读屏演示会议”不用准备太多挑两三个已经存在的严重问题现场打开读屏让开发跟着听一遍页面。视觉导向的程序员看文字报告很难受但听到读屏把导航从头到尾读一遍、焦点莫名其妙跳到页尾他的感受是直观的。另外一次迭代不要抛太多缺陷。约定 P1 全部修复P2 修优先级最高的五条就足够形成正向循环。每轮回归后在测试周报里对比上轮“P1 已修复数量”能让团队看到进展。记住不要在报告里表现出“我提了一堆问题你赶紧改”的对立姿态而是站在“我们一起把这几个关键流程打通”的角度。可访问性缺陷的修复不是测试赢开发输而是用户赢。5.4 修复后的回归验收自动化通过不等于验收通过可访问性缺陷的修复验收要按类型分开。改一个 aria 属性或者 alt 文本自动化扫描通过后再用读屏抽查一次真实朗读效果改焦点管理和弹窗交互必须人工用键盘把流程走一遍改对比度和颜色除了工具复测还要人工确认不同色觉模拟下的可读性。我习惯在每个功能测试用例里增加两列键盘可达性、读屏可达性。功能测试跑完的时候顺手把这两列也勾了。这样可访问性测试就不是独立于功能测试之外的额外负担而是功能测试的一部分。6. 把可访问性测试嵌进交付流程别让它成为版本末尾的救火动作6.1 需求阶段就把可访问性要求写成可测的验收标准可访问性测试如果要稳定落地需求阶段就要有东西可测。我在需求评审里看到最多的话是“保证无障碍”这话没法测。可测的验收标准应该写成条目比如所有表单输入控件都必须有程序化标签核心流程所有步骤均可通过键盘完成页面必须有正确的标题结构和跳转链接错误提示不能只依赖颜色必须同时有文字描述这些条目不仅能指导测试用例也能反向推动产品在原型设计阶段就考虑可访问性。政务网站的功能需求往往变化快但可访问性条目相对稳定。把可访问性条目写进老页面的验收条件虽然比写在需求初期晚了一步但也远好过等系统上线之后再补。6.2 在 CI 里跑自动化扫描最便宜的一道防线自动化扫描嵌入 CI 是最有效的防回归手段。最小配置用 GitHub Actions 或者任何现有 CI 都可以核心是固定一组 URL 清单在每次构建或每日构建时跑一遍页面级扫描。一个最小的 YAML 示例name: a11y-scan on: push: branches: [ main ] jobs: a11y: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 - run: npm ci - run: npm run test:a11yCI 里扫描的坑是稳定性。页面加载慢、动态内容未完全渲染、缺少登录态都会导致误报或漏报。所以刚开始接入时可以先跑但不拦截连续观察一周确认问题类别稳定后再打开拦截规则。只拦截 critical 和 serious不要把全部建议级规则都设成失败条件。CI 这条防线是为了防止新代码把已有的可访问性水平拉低它不能替代手工测试。6.3 分层回归策略提交、构建、迭代各跑什么可访问性测试的回归不能只靠一个轮次。我习惯把它分成四层每次提交组件级 axe 扫描覆盖高频公共组件问题出现时定位到组件最快。每次构建或每日页面级 pa11y 扫描核心页面清单看趋势和新增问题。每个迭代手工键盘和读屏走一遍 Top 3 业务流程重点看焦点和读屏语义。每季度对整站做一次较完整的 WCAG 2.1 AA 抽查覆盖新老页面。层与层之间是漏斗关系。组件级先挡住一批语法和结构缺陷页面级暴露组合问题手工级解决需要理解的任务问题季度抽查补漏。没有组件库的项目可以跳过第一层但至少要有页面级和手工级两层。6.4 汇报给项目组的正确姿势数据和用户故事一起讲可访问性测试的汇报不能只有数字。给项目组汇报时我会准备两样东西一是趋势数据包括问题总数、严重问题数、核心流程通过率二是一个具体的用户故事比如打开读屏从某页搜索到提交材料把读屏实际朗读的声音录下来放给团队听。数据解决的是“有没有变好”的问题用户故事解决的是“为什么值得做”的问题。政务网站的可访问性往往涉及大量真实用户的日常使用不要把它汇报成一项负担而要让它回归成本来就属于它的位置用户到底能不能把事情办成。7. 从零开始的落地顺序如果只能投入有限时间先把这三件事做透7.1 第一件事固定核心页面清单和基础工具链如果团队没有余力全面铺开我建议先花一周时间做三件事选出 10 个核心页面搭好 pa11y 加 axe-core 的最小工具链让自动化扫描以固定节奏跑起来。选页面的标准是访问量最大、覆盖主要交互组件、包含关键业务流程。这 10 个页面不要贪多。我见过一个项目把两百多个页面都纳入扫描结果每月光处理报告就耗掉大量时间最后自动化形同虚设。扫描范围小报告才有机会被真正处理。7.2 第二件事手工测试只覆盖 Top 3 业务流程手工键盘和读屏测试最怕摊大饼。选 Top 3 流程时优先选用户量最大、失败代价最高、跨页面最多的业务线比如在线申请、材料上传、结果查询。每个流程用键盘完整走一遍再用读屏完整走一遍把问题按 P1、P2、P3 记录。一个流程走三小时很正常不要觉得慢因为你在代替一类真实用户做日常操作。政务网站测试如果每年手工可访问性测试只能覆盖三条流程那也比覆盖五十个页面但每条流程只测两分钟有价值。7.3 第三件事从下一个迭代开始写可访问性验收标准可访问性验收标准不需要写得很重。每个涉及表单、搜索、导航、弹窗的需求加一条“可测标准”列出一两句话即可。比如搜索功能新增时写“搜索框必须有程序化标签键盘 Tab 应能到达并进入搜索结果区域有标题并提示结果数量”弹窗组件新增时写“打开弹窗焦点进入Esc 可关闭关闭后焦点回到触发按钮”。这些条目积累起来就是团队自己的可访问性测试资产远好过贴一份外部标准在眼前却不知道怎么做。等下一轮需求评审的时候这些标准会让所有人自然地开始讨论可访问性而不是等到测试阶段才突然提出来。7.4 一句个人体会放在最后我做了这些年测试最深的体会是可访问性测试最难的从来不是工具也不是标准而是让团队相信这件事值得做。改变这个认知最有效的方式不是发标准文档而是当着开发的面打开读屏让他听一遍自己写的页面。一旦他听过再往后你提的任何可访问性缺陷他都会当一回事。如果你所在的团队刚开始做这件事被几十条问题淹没是正常的。先修完 P1再固定基线再逐步扩大范围。你会发现可访问性测试不是一个独立项目而是和功能测试、回归测试融在一起的常规动作。它和性能优化一样前期投入看不到立竿见影的效果但一旦形成基线后面每个版本都会省下大量返工时间。希望这篇框架能帮你少走几步弯路。