面向 Web 开发者的无障碍功能

改进无障碍功能可提升您的网站对所有用户的易用性。

Addy Osmani
Addy Osmani
X GitHub

构建包容且人人都能访问的网站非常重要。 您可以针对以下至少 6 个关键的残障情况进行优化： 视觉、听觉、行动不便、认知、语音和神经。 很多工具和资源都可以在这里提供帮助 即使您对 Web 无障碍功能一无所知。

超过 10 亿人 患有某种形式的残疾

网站需要能在多部设备上正常运行 屏幕尺寸和输入类型（例如屏幕阅读器）不同。 此外，网站应该可供最广泛的用户群体使用， 包括残障人士。

以下是您的用户可能有的一些残疾：

Vision 听力 行动不便
  • 低视力
  • 盲人
  • 色盲
  • 白内障
  • 眩光
  • 听障
  • 失聪
  • 噪音
  • 耳部感染
  • 脊髓损伤
  • 精细动作失灵
  • 腾出双手
认知 语音 神经元
  • 学习障碍
  • 嗜睡或分心
  • 偏头痛
  • 孤独症
  • 发作
  • 环境噪声
  • 咽喉痛
  • 语言障碍
  • 无法说话
  • 忧郁症
  • PTSD
  • 躁郁症
  • 焦虑

视觉问题包括无法分辨颜色和完全视力不等。

  • 确保文字内容符合最低要求 对比度阈值。
  • 避免传递信息 只使用颜色 并确保所有文字 resizable。
  • 确保所有界面组件都能与辅助技术搭配使用 例如屏幕阅读器、放大镜和盲文显示屏。 这需要确保为界面组件添加标记， 以便无障碍功能 API 能够以编程方式 任何元素的 role、state、value 和 title。
。

Chrome 开发者工具检查元素提示的屏幕截图。

我个人的视力很弱，经常把各种内容放大 其开发者工具和终端。 虽然支持缩放功能是开发者待办事项清单 而这对像我这样的用户大有裨益。

听力问题表示用户可能无法听到网页发出的声音。

ChromeVox 屏幕阅读器的屏幕截图。

移动问题可能包括无法操作鼠标、键盘或 触摸屏。

  • 制作界面组件的内容 可通过键盘使用相应功能 否则需要使用鼠标来完成任何操作。
  • 确保已针对辅助技术（包括 屏幕阅读器、语音控制软件和物理开关控件， 往往使用相同的 API

认知问题意味着用户可能需要使用辅助技术 帮助他们朗读文字，因此请务必确保存在替代文字。

  • 使用动画时要小心。避免使用存在以下情况的视频和动画： 重复 这可能会导致问题 对部分用户来说

    prefers-reduced-motion 借助 CSS 媒体查询，您可以限制动画 以及自动播放视频（适合喜欢减少动态场景的用户）：

    /*
If the user expresses a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}

  • 避免 基于时间。

这似乎有相当多的依据需要介绍 但我们将逐步介绍 然后改进界面组件的无障碍功能。

为了提供额外的视觉支持，GOV.UK 无障碍团队设计了一系列 数字海报的无障碍注意事项， 您可以借此与团队分享最佳实践

展示无障碍注意事项的数字海报。
六张海报，列出了无障碍功能最佳实践。阅读 全文。

测量界面组件的无障碍功能

审核页面界面组件的无障碍功能时，请考虑以下问题：

  • 能否只通过键盘使用界面组件？

    组件是否管理焦点并避免焦点陷阱？ 它可以响应相应的键盘事件吗？

  • 能否借助屏幕阅读器使用界面组件？

    您是否为可视化呈现的信息提供了替代文本？ 您是否使用 ARIA 添加了语义信息？

  • 您的界面组件能否在没有声音的情况下运行？

    关闭扬声器，并查看用例。

  • 您的界面组件能否在没有颜色的情况下运行？

    确保界面组件可供看不到颜色的人使用。 一个用于模拟色盲的有用工具是 Chrome 扩展程序， 色盲。 （尝试全部四种形式的色盲模拟。） 您可能还对以下内容感兴趣： Daltonize 同样有用。

  • 在启用高对比度模式的情况下，您的界面组件是否可以工作？

    所有现代操作系统都支持高对比度模式。 高对比度 Chrome 扩展程序可为您提供帮助。

标准化控件（例如 <button> 和 <select>）可供使用 。可使用 Tab 键聚焦它们； 它们会响应键盘事件（如 Enter、Space 和箭头键）； 并且具有无障碍工具使用的语义角色、状态和属性。 其默认样式也应满足所列的无障碍功能要求。

自定义界面组件（扩展标准界面的组件除外） 元素（例如 <button>）没有任何内置功能，包括 因此您需要提供它建议你从何处入手 将组件与类似的标准组件进行比较 元素（或多个标准元素的组合，具体取决于 ）。

大多数浏览器开发者工具都支持检查网页的无障碍树。 在 Chrome 开发者工具中，您可以在 Elements 面板的无障碍标签页中找到此选项。

Chrome 开发者工具中无障碍功能树状视图的屏幕截图。

Firefox 还有一个辅助功能面板。

FireFox 开发者工具中无障碍功能树状视图的屏幕截图。

Safari 会在元素面板的节点标签页中提供无障碍功能信息。

下面列出了您在尝试使界面组件使用起来更没有障碍时可以问自己的问题。

改进键盘焦点

理想情况下，请确保界面组件中的所有功能均可访问 和键盘。在设计用户体验时 请思考如何单独使用键盘来使用元素 确定一组一致的键盘交互方式。

首先，确保每个组件都有合理的焦点目标。 例如，像菜单这样的复杂组件可能是 但应在其内部管理焦点，以便活动菜单项 始终保持焦点

需要焦点管理的菜单和子菜单的屏幕截图。
管理复杂元素中的焦点。

使用 tabindex

您可以使用 tabindex 为元素和界面组件添加键盘焦点 属性。仅键盘和辅助技术用户需要能够放置 使用键盘将焦点置于元素上，以便与其互动。

内置互动元素（如 <button>）可隐式聚焦，因此 它们不需要 tabindex 属性，除非您需要更改其位置 按 Tab 键顺序。

tabindex 值有三种类型：

  • tabindex="0" 最为常见，它会将相应元素放在自然标签页中 order（由 DOM 顺序定义）。
  • 如果 tabindex 值等于 -1，系统会以程序化方式对该元素进行编程 可聚焦，但不按 Tab 键顺序。
  • 如果 tabindex 值大于 0，系统会将元素手动按 Tab 键顺序排列。 该网页中 tabindex 为正值的所有元素的访问时间 数字顺序，在自然 Tab 键顺序中的元素前面。
。

在文章中查找 tabindex 的一些用例 使用 tabindex。

确保焦点始终可见（无论是否使用默认焦点环） 样式，或应用可识别的自定义焦点样式。切记不要陷阱 键盘用户 - 他们应该能够将焦点从元素移开 只需使用键盘即可。

使用自动对焦功能

HTML autofocus 属性让作者能够指定特定的 元素应自动获得焦点 。 已在以下设备上支持autofocus： 所有网络表单控件、 包括按钮 如需自动对焦您自己的自定义界面组件中的元素， 调用 focus() 方法， 支持所有可以获得焦点的 HTML 元素 （例如 document.querySelector('myButton').focus()）。

添加键盘互动方式

界面组件可聚焦后，请提供合理的键盘互动故事 通过处理相应的键盘事件对组件进行聚焦时触发。 例如，允许用户使用箭头键选择菜单选项 按 Space 或 Enter 键可激活按钮。 ARIA 设计模式指南 这里提供了一些指导。

最后，请确保您的键盘快捷键易于发现。 常见做法是创建键盘快捷键图例（屏幕上的文字） 以告知用户存在快捷方式。例如，“按 ?用于键盘 快捷方式。”或者，也可以使用提示（例如提示）来告知用户 快捷方式

管理焦点的重要性再重要不过了。一个重要的例子是 一个抽屉式导航栏如果向页面添加界面组件 您需要将焦点对准其中的某个元素； 否则，用户可能需要按 Tab 键浏览整个页面才能转到该页面。 这可能会令人沮丧 因此请务必测试网页中所有键盘可导航组件的焦点。

WalkMe 状态切换测试。 
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

确保成功使用屏幕阅读器

大约 1% 到 2% 的用户会使用屏幕阅读器。你能理解所有重要的吗 使用屏幕阅读器和键盘与组件交互 ？

以下问题可帮助您解决屏幕阅读器无障碍功能方面的问题。

是否所有组件和图片都有有意义的替代文本？

所有与名称或用途相关的信息 互动式组件的设计理念 提供易于理解的替代文本。

例如，如果您的 <fancy-menu> 界面组件仅显示齿轮图标 表明这是一个设置菜单 它需要一个易于使用的替代文本，例如“settings” 传达同样的信息。 根据具体情况 您可以使用 alt 属性提供替代文本， aria-label 属性、aria-labelledby 属性 或纯文本。 您可以在 WebAIM 快速参考中找到常规技术提示。

任何显示图片的界面组件都应提供一种机制 用于为该图片提供替代文本，类似于 alt 属性。

您的组件是否提供语义信息？

辅助技术可以传达语义信息，而这些信息 通过格式、光标样式或位置等视觉提示来判断视力正常的用户。 标准化元素包含这种语义信息，由浏览器内置， 但对于自定义组件，您需要使用 ARIA 来添加信息。

一般来说，任何监听鼠标点击或悬停事件的组件 应具有某种键盘事件监听器和 ARIA 角色（可能是 ARIA 状态和属性。

例如，自定义 <fancy-slider> 界面组件可能具有滑块的 ARIA 角色， 它有一些相关的 ARIA 属性：aria-valuenow、aria-valuemin 和 aria-valuemax。 通过将这些属性绑定到自定义组件上的相关属性， 您可以允许使用辅助技术的用户与该元素互动， 甚至会相应地改变元素的视觉呈现效果。

滑块的屏幕截图。
范围滑块组件。
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

用户能否在不依赖颜色的情况下理解所有内容？

颜色不应用作传达信息的唯一方式， 指示状态、提示用户做出响应或直观呈现数据。 例如，如果您有一个饼图，请为每个切片提供标签和值 以便视障用户能够理解其中的信息 即使用户看不到切片的开始和结束位置：

包含标签和值的饼图，以确保可访问性。
易于访问的饼图。（来自 W3C 网络无障碍计划）。

对比度是否足够高？

组件中显示的任何文本内容均应符合 最低 WCAG AA 级对比度阈值。 考虑提供一个高对比度主题， 更高的 AAA 阈值 并确保您可以将用户代理样式表 如果用户需要自定义对比度或不同的颜色。 您可以使用此色彩对比度检查工具 以帮助您设计组件

移动或闪烁的内容是否可以停止并且安全？

用户应该能够暂停、停止或隐藏移动、滚动或 闪烁 5 秒以上。一般情况下，请避免闪烁内容。

如果必须闪光灯，请确保每秒闪烁不超过三次。

无障碍工具和测试

Google Cloud 提供了 100 多种工具， 评估网站的可访问性 及其组件。有些工具是自动化的，有些则需要手动测试。

以下是几点注意事项：

  • Axe 提供自动无障碍功能 测试适用于所选框架或浏览器的测试。 斧头木偶师 可用于编写自动化无障碍功能测试。

  • Lighthouse 无障碍功能 审核为发现常见的无障碍功能问题提供了有用的数据洞见。 无障碍功能得分是所有无障碍功能审核的加权平均值 基于 Axe 用户影响评估。 如需了解如何通过持续集成监控可访问性，请参阅 Lighthouse CI。

    Lighthouse 无障碍功能审核的屏幕截图。

  • Tenon.io 对于测试常见的无障碍功能问题非常有用。 Tenon 在构建工具、浏览器（通过 甚至是文本编辑器。

  • 有很多特定于库和框架的工具可以突出显示 组件的无障碍功能问题例如，使用 eslint-plugin-jsx-a11y 在您的编辑器中突出显示 React 组件的无障碍功能问题。

    存在由 eslint-plugin-jsx-a11y 标记出的无障碍功能问题的代码编辑器的屏幕截图。

    如果您使用的是 Angular，请codelyzer 此外，它还提供编辑器中的无障碍功能审核：

    存在由 codelyzer 标记出的无障碍功能问题的代码编辑器的屏幕截图。

使用辅助技术

在改进网络无障碍功能方面，我们任重道远。 根据 Web 年历：

  • 每 5 个网站中就有 4 个包含与背景融为一体的文字， 使它们难以阅读
  • 49.91% 的网页仍然无法为其部分图片提供 alt 属性。
  • 在使用按钮或链接的网页中，只有 24% 包含标签。
  • 只有 22.33% 的网页为其所有表单输入提供了标签。

我们可以做很多事情来打造更方便 所有人。