什么是可访问性测试?(示例)
⚡ 智能摘要
无障碍测试是可用性测试的一个子集,旨在确认应用程序是否可供残障人士使用,包括盲人、聋人、色盲以及有运动或认知障碍的用户。它验证应用程序是否符合 WCAG 2.2 标准和当地残疾人法律法规。
什么是可访问性测试?
无障碍测试 是一种软件测试,旨在确认应用程序是否可供残障人士使用,包括视力、听力、运动、认知和年龄相关障碍用户。它是以下测试的一个子集: 可用性测试 并验证该产品是否与这些用户每天依赖的辅助技术兼容。
辅助技术帮助残障人士操作软件产品。常见的例子包括:
- 语音识别软件 – 将口语转换为可作为计算机输入的文本。
- 屏幕阅读器软件 – 朗读屏幕上显示的文本和界面元素。
- 屏幕放大软件 – 放大显示器的部分区域,以便视力障碍用户更容易阅读。
- 专用键盘 专为运动控制困难的用户设计,以帮助他们进行 typing 更容易。
- 开关和眼睛-trac国王设备 – 允许有严重运动障碍的用户浏览和选择界面元素。
为什么要进行可访问性测试?
原因1迎合残疾人用户市场。
世界卫生组织表示,全球约有1.3亿人(约占全球人口的六分之一)患有严重残疾。
- 每十个人中就有一人患有严重残疾。
- 65岁以上的人群中,每两人就有一人能力下降。
残疾包括失明、耳聋、运动障碍、认知障碍和其他长期健康问题。一款设计上注重无障碍功能的产品可以开拓这个庞大的市场,而大多数无障碍缺陷都可以在将无障碍测试纳入常规软件测试生命周期时得到预防。
原因2遵守无障碍法规。
世界各国政府已通过立法,要求信息技术产品必须方便残障人士使用。主要例子包括:
- 美国:《美国残疾人法案》(ADA,1990 年)和《康复法案》第 508 条。
- 英国:《2010 年平等法案》(取代了《1995 年残疾歧视法案》)。
- 欧盟:《欧洲无障碍法案》,该法案于 2025 年 6 月对许多产品和服务生效,以及标准 EN 301 549。
- 澳大利亚:1992 年残疾歧视法。
- 爱尔兰:2005 年残疾人法案。
- 加拿大:《2019 年无障碍加拿大法案》。
无障碍测试对于确保您的产品在所有销售市场均符合法律规定至关重要。
原因3避免潜在的诉讼。
大型公司因其数字产品无法访问而屡遭起诉。以下是一些著名的案例:
- 全国盲人联合会(NFB)诉 Target (2006 年,2008 年解决)。
- NFB诉AOL和解案(1999年)。
- 在罗布尔斯诉达美乐披萨案(2019年)中,美国 Suprem法院维持了ADA适用于网站和移动应用程序的裁决。
- Gil诉Winn-Dixie案(2017年),是美国首例要求修复无法访问的网站的审判判决。
美国的网页无障碍诉讼案件逐年增加,自 2022 年以来,每年提起的 ADA 第三章数字案件超过 4,000 起。从一开始就打造无障碍产品可以避免这些成本并保护品牌。
需要支持哪些残疾人?
应用程序必须能够支持残疾人士,例如:
| 残疾类型 | 残疾 Description |
|---|---|
| 视力障碍 |
|
| 身体残疾 |
|
| 认知障碍 |
|
| 读写障碍 |
|
| 听力障碍 |
|
无障碍标准和指南
无障碍测试程序依赖于一套被广泛采用的标准。在编写任何测试计划之前,首先要了解哪个标准适用于您的市场。
- WCAG 2.2 由 W3C 于 2023 年 10 月发布的 Web 内容无障碍指南 2.2 是当前的全球基准。它定义了三个符合性级别:A(基本)、AA(大多数国家/地区的法律最低要求)和 AAA(最高)。
- WCAG 3.0 – 这是一份 W3C 工作草案,引入了一种基于结果的评分模型。它仍在开发中,尚未取代 WCAG 2.2。
- 第508 – 美国联邦采购规则要求联邦机构采购的电子和信息技术必须符合 WCAG 2.0 AA 级标准。
- ZHCN 301 549 – 欧洲信息通信技术无障碍协调标准,用于证明符合《欧洲无障碍法案》。
- ADA标题III – 美国民权法适用于公共场所的网站和移动应用程序;法院通常使用 WCAG 2.1 或 2.2 AA 作为基准。
大多数团队对待 WCAG 2.2 AA 级 因为它既是共同的法律基准,也是实际的工程目标,所以将其作为工作目标。
如何进行可访问性测试?
可访问性测试可以通过两种方式进行:
- 用户手册
- 自动化
对于不熟悉残障人士的测试人员来说,无障碍测试可能充满挑战。最佳做法是邀请残障人士或无障碍专家参与,以便他们描述实际应用中的挑战。以下技术涵盖了主要的残障类别。
1)视力障碍
想象一下,你完全失明,但需要访问 XYZ 网站。你唯一可行的选择是屏幕阅读器。屏幕阅读器是一种软件,它可以朗读网页上的内容,包括文本、链接、单选按钮、图像和视频,以便盲人用户能够感知界面。常用的屏幕阅读器包括: 颚, NVDA苹果 VoiceOver 和 Android 顶嘴。
启动 JAWS 后,打开浏览器,JAWS 会朗读页面标题。如果将焦点移至地址栏,JAWS 会朗读“地址栏”,然后逐个朗读您输入的字符。例如,typing google.com 会发布如下公告:
Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m. When the page finishes loading, JAWS announces "Google.com home page". When focus reaches the search field, JAWS announces "Google search, edit".
屏幕阅读器会逐字朗读文本框中的内容,将链接读作“链接”,将按钮读作“按钮”,以便盲人用户能够识别每个控件。如果网站设计不佳,屏幕阅读器可能会错误识别元素;例如,一个样式为纯文本的链接可能会被误读为内容,从而导致用户无法执行关键操作。这会给企业造成实实在在的收入损失。
2)色盲
色盲是指用户无法正确感知某些颜色。红绿色盲是最常见的类型。如果一个网站大量使用红色来传达信息,患有红绿色盲的用户可能就无法理解其中的含义。
设计团队绝不应仅使用颜色来传达信息。例如,红色错误按钮如果加上轮廓、图标和描述性文字,会更易于识别。黑白仍然是最安全的通用配色方案,而像 Stark 插件或浏览器色盲模拟器之类的工具可以帮助及早发现问题。
3)低视力
视力低下或其他视网膜疾病患者在使用本网站时需要额外帮助:
- 避免使用过小的字体。WCAG 建议使用默认的字体大小,使其无需缩放即可舒适地显示。
- 确保文本放大至 200% 时布局能够流畅重排(符合 WCAG 2.2 成功标准)。文本行不应被截断,内容不应重叠。
- 普通文本的最小对比度为 4.5:1,大文本的最小对比度为 3:1。
4)运动及其他残疾
一项重要的无障碍要求是,整个网站必须无需鼠标即可操作。所有链接、按钮、单选按钮、复选框、弹出窗口、下拉菜单和控件都应该仅通过键盘即可访问和操作。
举个例子手部活动受限的用户可能无法使用鼠标。如果无法通过 Tab 键访问复选框或链接,则用户将无法使用这些功能。
Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.
焦点必须始终可见。当用户按下 Tab 键时,高亮显示的控件应清晰可见。可见的焦点有助于视力障碍或色盲用户理解页面布局,并使所有用户的导航操作都易于预测。
听力障碍用户 通常情况下,用户可以看到网站的视觉内容,但音频和视频却会带来一些问题。每个视频都必须配有字幕,每个音频文件都必须包含文字稿或描述性文本。例如,一个关于如何预订机票的教程视频应该配有准确的字幕,以便听障用户能够跟上操作。
可访问性测试示例测试用例
以下清单用于对典型的 Web 应用程序进行无障碍测试并签字确认。您可以以此为起点,并根据产品相关的 WCAG 2.2 成功标准对其进行扩展。
- 每个鼠标操作和对话框都提供了键盘对应选项吗?
- 用户文档是否解释了如何使用辅助技术操作该应用程序?
- 标签页顺序是否合理,导航是否流畅自然?
- 主菜单是否提供快捷键?
- 该应用程序是否支持所有目标操作系统和屏幕阅读器?
- 每个屏幕或页面的响应时间是否清晰告知用户,以便用户知道需要等待多久?
- 所有标签是否都编写正确,并且是否已通过程序链接到其控件?
- 颜色选择是否灵活,并经过色盲模拟器测试?
- 图片、图标和表情符号的使用方式是否便于最终用户理解?
- 该应用程序是否会在需要时提供语音提示?
- 用户可以调节或静音音频和视频控制吗?
- 用户能否更改打印和屏幕显示文本的默认字体?
- 用户能否调整或禁用闪烁、旋转或移动的显示效果?
- 确认颜色绝不能作为传达信息的唯一手段。
- 系统颜色反转后,高亮显示是否仍然可见?通过更改对比度进行测试。
- 是否为听障用户提供音频和视频的文字稿或字幕?
- 是否为残障用户提供培训,帮助他们熟悉应用程序?
- 是否所有交互式控件都可以仅通过键盘访问、操作和关闭?
最佳可访问性测试工具
为了让您的网站更易于使用,首先要确保其易于访问。许多免费和付费的无障碍测试工具可以扫描页面是否存在违反 WCAG 标准的情况。2026 年最常用的工具包括:
以下是一些受欢迎的 可访问性测试工具:
1)波浪
WAVE 是由 WebAIM 开发的一款免费网页无障碍评估工具。它通过手动检查网页的多个无障碍方面,提供浏览器扩展、在线扫描器和 API 三种使用方式。该扩展程序无需将数据发送到远程服务器,即可检查需要登录才能访问的页面、动态生成的页面以及敏感的内网页面。它能够直接识别页面中的错误、警报和结构性问题,并支持私密、安全的无障碍报告。
访问 开始.
2) axe DevTools
Deque Systems 的 axe DevTools 是应用最广泛的辅助功能扫描器之一。它以浏览器扩展、CI/CD 库和移动测试工具包的形式提供。该引擎还为许多其他工具提供支持,包括: Google 灯塔和 Microsoft 无障碍洞察,它生成的误报率低,且与 WCAG 2.2 成功标准直接相关。
访问 开始.
3) Google Lighthouse
Lighthouse 已集成到 Chrome 开发者工具中,可在一份报告中运行可访问性、性能、SEO 和最佳实践审核。可访问性审核类别使用 axe-core 引擎,可快速检测日常开发过程中缺失的替代文本、对比度过低以及 ARIA 使用不当等问题。
访问 开始.
4)无障碍洞察
Accessibility Insights 是一款免费产品。 Microsoft 工具 Windows、网络和 Android它提供快速扫描常见 WCAG 问题的功能,并提供引导式评估,引导测试人员完成 WCAG 2.2 AA 级的所有检查。制表位可视化功能使键盘顺序的验证变得轻松便捷。
访问 开始.
5) Siteimprove
Siteimprove是一个企业级可访问性、内容和SEO平台。它可以抓取整个网站,将问题映射到WCAG 2.2成功标准,并且 tracks 会随着时间推移而改进。人工智能驱动的建议可以帮助编辑在无需深厚技术知识的情况下解决问题。
访问 开始.
6) JAWS 和 NVDA 屏幕阅读器
自动化工具大约可以检测出 30% 到 40% 的辅助功能问题;其余问题需要人工进行屏幕阅读器测试。JAWS 是一款历史悠久的商业屏幕阅读器。 Windows而 NVDA 则是一个免费的开源替代方案。两者都应该纳入严肃的无障碍设计方案中。
访问 开始.
7)WebAnywhere
WebAnywhere 是一款基于浏览器的工具,其工作方式类似于屏幕阅读器。它无需安装即可运行,当开发人员或内容编辑人员想要快速检查屏幕阅读器如何朗读页面时非常有用。
访问 开始.
人工智能如何改变无障碍测试
AI 是 reshaping 无障碍测试可通过三种实用方式进行。首先,机器学习扫描器现在结合计算机视觉模型读取渲染后的 DOM,以检测基于规则的工具无法发现的问题,例如不恰当的替代文本或在实际布局中失效的颜色组合。其次,生成式人工智能会建议易于理解的修复方案,包括更佳的替代文本、更清晰的错误信息以及自定义组件的 ARIA 属性。第三,人工智能会根据用户影响对发现的问题进行优先级排序,以便团队能够将预算投入到最重要的问题上。Deque axe AI、Evinced、UserWay 和 Siteimprove 等工具现在都包含人工智能功能。人工智能并不能取代人工屏幕阅读器测试或残障人士用户研究,但它可以大大减少人工筛选工作量,并有助于将无障碍设计提前到开发周期的早期阶段。
可访问性测试的误区
以下是关于无障碍测试的常见误解及事实:
神话: 创建一个无障碍网站成本很高。
事实: 并非如此。在设计阶段就考虑无障碍设计,并进行基本测试,与后期改造相比,可以节省资金并减少代价高昂的返工。
神话: 将一个无法访问的网站改成一个可以访问的网站既费时又费钱。
事实: 您不必一次性应用所有修复。先从对残障用户影响最大的更改入手,其余的更改将在后续版本中逐步推出。
神话: 无障碍设计平淡乏味。

事实: 页面仍然可以拥有丰富的视觉效果,并且trac在符合 WCAG 2.2 指南的前提下,提供易于访问的体验。W3C 明确不鼓励使用纯文本版本,而是提倡为所有人提供统一的无障碍体验。
神话: 无障碍功能仅面向盲人和残疾用户。
事实: 遵循无障碍指南可以提高整体可用性,使每个用户受益,包括使用移动设备、在阳光直射下或在嘈杂环境中的用户。



.jpg)


