如何测试你做的项目的可访问性

苏南

发布于 2020-12-16 10:56:05

1.8K0

发布于 2020-12-16 10:56:05

文章被收录于专栏：漫画前端

点击上方“IT平头哥联盟”，选择“置顶或者星标”

编者按：本文作者：安佳，360 搜索事业部的前端开发工程师，W3C CSS 工作组成员。

站在 Web 开发的角度，一提到网站的可访问性，可能大部分人最想知道的就是：如何评判一个网站的可访问性的好坏？是否有自动化的检测工具可用，可以很直接地指出问题所在和改进策略？

本篇文章就来聊聊这个话题，主要包括：

自动化测试工具
手动测试的方法和工具
可访问性需要覆盖的特性列表

一、自动化测试工具

比较常用的四个工具：

axe-core(https://github.com/dequelabs/axe-core) 是一个用于测试 Web UI 可访问性的引擎。可以将它合并到自动化测试套件中，在命令行中运行
浏览器扩展 aXe(https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?utm_source=chrome-ntp-icon) 或者 WAVE(https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?utm_source=chrome-ntp-icon)
Chrome 插件 Lighthouse(https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?utm_source=chrome-ntp-icon)，它内置了 axe-core，也能提供可访问性检测
Chrome 开发者工具里也内置了可访问性检测，见 Audits 面板（它内置了 Lighthouse）

我们就以 Chrome 开发者工具里的 Audits 面板为例，看看自动化检测工具都提供了哪些功能。

下图是 Audits 面板：

用它检测360课程培训(https://www.so.com/zt/training.html#/?q=%E4%BC%9A%E8%AE%A1&srcg=a11y)页面，审计结果如下：

结果涵盖了以下五个方面：

对比度
表单控件的名字和标签
需要手动检查的项目
通过的测试项
未应用到的项

1. 对比度

对比度属于可阅读范畴，检测结果显示“背景色和前景色没有足够的对比度”（点击文本元素必须与背景有足够的颜色对比度(https://dequeuniversity.com/rules/axe/3.3/color-contrast)查看更多）。

呃，修改这个...似乎有点难度，因为绿白是360搜索的主题配色。那有没有什么“曲线救国”的方式呢？答案是有的，高对比度模式。至少我们可以做到，在开启高对比度模式的时候，页面 UI 仍然是可见&可用的。比如安装了 Chrome 插件高对比度模式(https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph)，开启“增加对比度”后，页面长这个样子：

大家也可以尝试其它选项，比如翻转颜色。高对比度模式，可以开启操作系统级别的，也可以开启应用程序级别的。

2. 表单控件的名字和标签

检测结果显示“表单元素没有关联的标签”（点击 input 元素必须要有标签(https://dequeuniversity.com/rules/axe/3.3/label)查看更多）。

一般情况，表单控件需要有以下信息：

Role 角色，比如是编辑文本、单选框、复选框、还是按钮
Name/Label 名字，用来说明字段的含义。比如要输入的是“姓名”，还是“城市名”；要选择的是“性别”还是“日期”
State 状态，比如下拉框是否展开，单选框或多选框的选项是否被选中
Value 值

这些信息都会传给无障碍树，以方便辅助技术更好地“理解”页面。无障碍树类似 DOM 树，只是 DOM 树是给网页的渲染引擎用的，而无障碍树是给辅助技术用的。比如，下图就是一个简化版的无障碍树。

3. 需要手动检查的项目

自动化检测的 cases 覆盖不全可访问性的所有特性，需要我们手动测试。包括：键盘焦点的顺序是否合理、可交互元素是否易于理解、是否有键盘陷阱、自定义组件是否也易于理解和使用等等。详见下图。

机器的自动化检测有覆盖不到的情况，也不难理解，毕竟“可访问性”本身就是为了方便“人”使用。需要手动检查的项目，我们在第二小节中介绍。

4. 通过的测试项

通过的测试项，包括：按钮有可访问的名字、文档有标题、id 唯一、图片有alt属性等等。详见下图。

5. 未应用到的项

自动化工具只能检测可访问性问题的子集，因此手工测试必不可少。

二、手动测试的方法和工具

关于手动测试，重点和大家分享三点：键盘的可访问性、屏幕阅读器、缩放功能。

键盘的可访问性

重点关注页面上的所有可交互元素，须同时满足以下两点：

元素可被选中，当按Tab键时
元素可交互，当按Enter/空格/箭头键/Esc键时

我们继续以 360课程培训(https://www.so.com/zt/training.html#/?q=%E4%BC%9A%E8%AE%A1&srcg=a11y)为例，下面是手动测试的结果：

页面

可交互的元素

Tab键可被选中

可交互

说明


头部	logo	通过	通过	按Enter跳转至列表页
	input 框	通过	通过	按Enter可执行搜索
	“搜一下”按钮	通过	通过	按Enter可执行搜索
筛选区	课程	通过	不通过	1. 按Enter键，打开弹层2. 按方向键，在弹层里选择元素3. 按Esc键，关闭弹层
	形式	通过	通过 80%	按Enter可进行筛选可优化为：1. 按Tab进入下一个筛选项“级别”2. 按Tab+Shift进入上一个筛选项3. 按箭头键可在本层内的选项前后移动“不限/线上/线下”4. 按空格键可触发筛选交互
	级别/设置/周期	同上
	已选条件	通过	通过 10%	1. 按Enter键重新筛选2. 但此时，键盘焦点丢失
列表区	图像/标题/按钮	通过	通过	按Enter跳转至其它页面
翻页区	按钮	通过	通过 80%	1. 按Enter触发翻页2. 按Tab进行下一项3. 按Tab+Shift进入上一项同理，可优化成“形式”的交互

屏幕阅读器

操作系统都有自带的屏幕阅读器，我们就直接用它了。比如 Mac 上的 VoiceOver(https://webaim.org/articles/voiceover/)，在“系统偏好设置/辅助功能/VoiceOver” 中启用它。

首先简单介绍下它的键盘操作，更多信息可查看上面截图里的“使用指南”。

在运行 VoiceOver 时，普通的键盘操作保持不变。比如TAB Shift+TAB 箭头键空格键 Enter等
CMD+L 跳到地址栏，可输入URL
CTRL+Option+U：打开 Web Router，即导航面板
在打开 Web Router 的情况下：
- CTRL + Option + ← ↑ ↓ →：浏览内容
- CTRL + Option + CMD + H：逐个标题向前移动
- CTRL + Option + CMD + H + Shift：逐个标题向后移动

本次重点和大家分享下它的 Web Router，即导航面板。它主要有四种导航形式：按标题导航、按页面结构导航、按表单元素导航、按链接导航。

以下是 360课程培训(https://www.so.com/zt/training.html#/?q=%E4%BC%9A%E8%AE%A1&srcg=a11y)页面上四种导航的截图：

按标题

按页面结构

按表单控件

按链接