给 Web 开发人员的可访问性建议结论

2025-05-24

面向 Web 开发人员的可访问性提示

结论

构建包容性强、人人可访问的网站真是太棒了。我们可以针对至少六个关键的残障领域进行优化：视觉、听觉、行动、认知、言语和神经。即使您是网页无障碍方面的新手，许多工具和资源也能为您提供帮助。

全球有超过10亿人患有某种形式的残疾。你可能曾经身处喧闹的房间，努力听清周围的谈话，或者在昏暗的光线下摸索着寻找东西。你还记得当时那种沮丧的感受吗？现在，想象一下，如果这种暂时的残疾变成了永久性的残疾，你的网络体验会有什么不同？

为了实现无障碍访问，网站需要能够在多种设备上流畅运行，这些设备需要具备不同的屏幕尺寸和不同的输入方式，例如屏幕阅读器。此外，网站还应方便最广泛的用户群体使用，包括残障人士。以下列举了一些用户可能遇到的残障情况：

想象 听力 移动性
- 视力低下
- 失明
- 色盲
- 白内障
- 太阳眩光		 - 听力障碍
- 耳聋
- 噪音
- 耳部感染		 - 手臂骨折
- 脊髓损伤
- 灵活性有限
- 双手拿东西
认知的 演讲 神经
- 学习障碍
- 嗜睡或注意力不集中
- 偏头痛
- 自闭症
- 癫痫		 - 环境噪音
- 喉咙痛
- 言语障碍
- 无法说话		 - 抑郁症
- 创伤后应激障碍
- 躁郁症
- 焦虑症

视觉问题包括无法辨别颜色到完全看不见。

  • 确保文本内容满足最低对比度阈值。

  • 避免仅使用颜色来传达信息，并确保所有文本均可调整大小。

  • 确保所有用户界面组件均可与辅助技术（例如屏幕阅读器、放大镜和盲文显示器）配合使用。这需要确保 UI 组件已进行标记，以便无障碍 API 能够以编程方式确定任何元素的角色、状态、值和标题。

提示：Chrome、Edge 和 Firefox DevTools 中的检查元素会显示 CSS 属性的工具提示，其中包括对颜色对比度的快速检查。

将鼠标悬停在您正在检查的元素上将显示包括颜色对比度在内的摘要

我个人视力不好，说起来也挺不好意思的，我就是那种总是放大网站、开发者工具和终端的人。虽然支持缩放功能几乎从来都不是任何人的首要任务，但为视力不佳的用户进行优化总是值得赞赏的……🤓

听力问题意味着用户可能无法听到页面发出的声音。

Mac 版 VoiceOver 用于在 Safari 中导航 dev.to

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

  • 使 UI 组件的内容可以通过键盘进行功能访问，以便执行任何原本需要使用鼠标进行的操作。

  • 确保页面正确标记辅助技术；这些用户可能会使用语音控制软件和物理开关控制等技术，这些技术往往使用与屏幕阅读器等其他辅助技术相同的 API。

认知问题意味着用户可能需要辅助技术来帮助他们阅读文本，因此确保存在文本替代非常重要。

CSS 媒体查询prefers-reduced-motion允许您为喜欢减少动作的用户限制动画和自动播放视频。

/*
If the user expressed a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}
Enter fullscreen mode Exit fullscreen mode
  • 避免基于时间的互动。

这似乎需要涵盖很多基础知识，但我们将逐步介绍评估并改进 UI 组件可访问性的过程。

提示： Gov.uk 无障碍团队提供了一些关于无障碍设施的注意事项数字海报，用于在您的团队中传播最佳实践的意识：

无障碍海报缩略图

您的 UI 组件可以访问吗？

摘要（tl;dr）

在审核页面的 UI 组件的可访问性时，请问自己：

  • 你的 UI 组件能只通过键盘使用吗？它能成功聚焦并避免焦点陷阱吗？它能响应相应的键盘事件吗？

  • 你的 UI 组件可以与屏幕阅读器配合使用吗？你是否为任何以视觉形式呈现的信息提供了文本替代？你是否使用 ARIA 添加了语义信息？

  • 你的 UI 组件可以在没有声音的情况下工作吗？关掉扬声器，然后仔细检查你的用例。

  • 没有颜色也能工作吗？确保你的 UI 组件能够被色盲人士使用。Chrome 扩展程序SEE是一个模拟色盲的实用工具（可以尝试所有四种可用的色盲模拟方式）。你可能也会对Daltonize扩展程序感兴趣，它同样实用。

  • 您的 UI 组件在启用高对比度模式后还能正常工作吗？所有现代操作系统都支持高对比度模式。High Contrast是一款 Chrome 扩展程序，可以帮您实现这一点。

原生控件（例如<button>和<select>）具有浏览器内置的无障碍功能。它们可以通过 Tab 键获取焦点，响应键盘事件（例如 Enter、空格和箭头键），并具有无障碍工具使用的语义角色、状态和属性。默认样式也应满足上面列出的无障碍要求。

自定义 UI 组件（除了像 这样的扩展原生元素的组件<button>）不具备任何内置功能，包括无障碍功能，因此需要您自行提供。实现无障碍功能的一个好方法是将您的组件与类似的原生元素（或多个原生元素的组合，具体取决于组件的复杂程度）进行比较。

提示：大多数浏览器的 DevTools 都支持检查页面的无障碍树。在 Chrome 中，可以通过“元素”面板中的“无障碍”选项卡进行操作。

元素面板中显示的 Chrome DevTools 可访问性树

在“辅助功能”面板中打开辅助功能时显示的 FireFox DevTools 辅助功能树

Firefox 也具有辅助功能面板，而 Safari 在元素面板的节点选项卡中显示此信息。

以下是您在尝试使 UI 组件更易于访问时可以问自己的问题列表。

你的 UI 组件可以单独与键盘一起使用吗？

理想情况下，确保 UI 组件中的所有功能都可以通过键盘访问。在用户体验设计过程中，请思考如何单独使用键盘来操作元素，并设计一套一致的键盘交互方式。

首先，确保每个组件都有一个合理的焦点目标。例如，像菜单这样的复杂组件可能只是页面中的一个焦点目标，但它应该管理自身内部的焦点，以确保活动菜单项始终获得焦点。

管理复杂元素内的焦点

管理复杂元素内的焦点

使用 tabindex

该tabindex属性允许使用键盘将元素/UI 组件置于焦点上。纯键盘用户和辅助技术用户都需要能够将键盘焦点置于元素上才能与其交互。原生交互元素是隐式可聚焦的，因此除非我们希望更改其在 Tab 键顺序中的位置，否则它们不需要 tabindex 属性。

tabindex 值有三种类型：

  • tabindex="0"是最常见的，它会将元素放置在“自然”的 Tab 键顺序中（由 DOM 顺序定义）。

  • tabindex 值大于 0会将元素置于手动Tab 键顺序中 - 页面中具有正 tabindex 值的所有元素将在自然 Tab 键顺序中的元素之前按数字顺序进行访问。

  • tabindex 值等于 -1将导致元素以编程方式获得焦点，但不按 Tab 顺序获得焦点。

对于自定义 UI 组件，请始终使用tabindex0 或 -1 的值，因为您无法提前确定特定页面上元素的顺序——即使我们能够确定，这些顺序也可能会发生变化。tabindex如上所述，-1 值对于管理复杂组件中的焦点特别有用。

还要确保焦点始终可见，无论是通过允许默认的焦点环样式，还是应用可辨别的焦点样式。切记不要困住键盘用户——焦点应该能够仅使用键盘就从元素上移开。

您可能还对MDN上介绍的移动tabindex或方法感兴趣。aria-activedescendant

使用自动对焦

HTMLautofocus属性允许开发者指定特定元素在页面加载时自动获得焦点。所有 Web 表单控件均已支持此功能，包括 。对于autofocus您自定义的 UI 组件中的元素，请调用所有可获得焦点的 HTML 元素（例如 ）支持的focus()document.querySelector('myButton').focus()方法。

添加键盘交互

一旦你的 UI 组件可聚焦，请尝试通过处理适当的键盘事件来提供良好的键盘交互体验，例如，允许用户使用箭头键选择菜单选项，并使用空格键或 Enter 键激活按钮。ARIA设计模式指南提供了一些指导。

最后，确保您的键盘快捷键易于发现。例如，一种常见的做法是使用键盘快捷键图例（屏幕文本）来告知用户快捷键的存在。例如，“按 ? 键即可使用键盘快捷键”。或者，也可以使用诸如工具提示之类的提示来告知用户快捷键的存在。

焦点管理的重要性不容低估。例如，抽屉式导航栏。如果在页面上添加 UI 组件，您需要将焦点指向其中的某个元素，否则用户可能需要浏览整个页面才能到达那里。这可能会带来令人沮丧的体验，因此请务必对页面中所有可通过键盘导航的组件进行焦点测试。

提示：您可以使用Puppeteer自动运行键盘可访问性测试来切换 UI 状态。WalkMe Engineering有一个很棒的指南，我推荐您阅读。

使用空格键展开和折叠类别

// Example for expanding and collapsing a category with the spacebar 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 press space
await page.keyboard.press('Space');

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

您可以将 UI 组件与屏幕阅读器一起使用吗？

大约 1-2% 的用户会使用屏幕阅读器。您能仅使用屏幕阅读器和键盘就能确定所有重要信息并与组件进行交互吗？

以下问题应该有助于指导您解决屏幕阅读器的可访问性问题：

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

无论何时以视觉方式传达有关交互式组件的名称或目的的信息，都需要提供可访问的替代文本。

例如，如果您的<fancy-menu>UI 组件仅显示一个图标（例如“设置”菜单图标）来指示它是设置菜单，则它需要一个可访问的替代文本（例如“settings”）来传达相同的信息。根据上下文，这可能会使用 alt 属性、aria-label 属性、aria-labelledby 属性或 Shadow DOM 中的纯文本。您可以在WebAIM 快速参考中找到常规技术技巧。

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

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

辅助技术能够传达语义信息，而这些信息通常通过格式、光标样式或位置等视觉提示向视力正常的用户传达。原生元素已由浏览器内置了此类语义信息，但对于自定义组件，您需要使用ARIA来添加此信息。

根据经验法则，任何监听鼠标点击或悬停事件的组件不仅应该具有某种键盘事件监听器，还应该具有 ARIA 角色和潜在的 ARIA 状态和属性。

例如，自定义<fancy-slider>UI 组件可能采用滑块的 ARIA 角色，该角色具有一些相关的 ARIA 属性：aria-valuenow、aria-valuemin 和 aria-valuemax。通过将这些属性绑定到自定义组件上的相关属性，您可以允许辅助技术用户与元素交互并更改其值，甚至使元素的视觉呈现也随之改变。

范围滑块组件

范围滑块组件

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" 
aria-valuenow="2.5"></fancy-slider>
Enter fullscreen mode Exit fullscreen mode

用户是否不依赖颜色就能理解所有内容？

颜色不应被用作传达信息的唯一手段，例如指示状态、提示响应或区分可视化自定义组件。例如，如果您创建了一个<fancy-map>使用颜色区分高流量、中等流量和低流量的组件，则还应提供另一种区分流量级别的方法：一种解决方案可能是将鼠标悬停在元素上以在工具提示中显示信息。

文本/图像和背景之间是否有足够的对比度？

组件中显示的任何文本内容都应满足最低 (AA) 对比度条。请考虑提供符合更高 (AAA) 条的高对比度主题，并确保在用户需要极端对比度或不同颜色时，可以应用用户代理样式表。您可以使用此颜色对比度检查器作为设计方面的辅助工具。

您的组件中移动或闪烁的内容是否可以停止且安全？

任何持续超过 5 秒的移动、滚动或闪烁内容都应该能够暂停、停止或隐藏。一般情况下，每秒闪烁次数应不超过三次。

无障碍工具

有许多工具可用于帮助调试可视化组件的可访问性。

  • Axe为您选择的框架或浏览器提供自动化的可访问性测试。Axe Puppeteer可用于编写自动化的可访问性测试。

  • Lighthouse可访问性审核为发现常见的可访问性问题提供了实用的见解。可访问性评分是所有可访问性审核的加权平均值，基于Axe 用户影响评估。有关通过持续集成监控可访问性的信息，请参阅Lighthouse CI。

灯塔可访问性审计

  • Tenon.io非常适合测试常见的可访问性问题。Tenon 拥有强大的集成支持，可与构建工具、浏览器（通过扩展程序）甚至文本编辑器进行集成。

  • 有许多特定于库和框架的工具可用于突出显示组件的可访问性问题。例如，web.dev介绍使用eslint-plugin-jsx-a11y在编辑器中突出显示 React 组件的可访问性问题：

ESLint 可访问性检查从编辑器内部运行的 JSX

如果您使用 Angular，codelyzer也提供编辑器内可访问性审核：

Codelyzer 突出显示 Angular 应用程序中的可访问性问题

  • 您可以使用辅助功能检查器(Mac) 或Windows 自动化 API 测试工具和AccProbe (Windows)来检查辅助技术查看网页内容的方式。此外，您还可以通过导航至chrome://accessibility来查看 Chrome 创建的完整辅助功能树。

  • 在 Mac 上测试屏幕阅读器支持情况的最佳方法是使用 VoiceOver 实用程序。您可以使用 ⌘F5 启用/禁用，使用 Ctrl+Option ←→ 在页面中移动，以及使用 Ctrl+Shift+Option + ↑↓ 在树状结构中上下移动。有关更详细的说明，请参阅VoiceOver 命令完整列表和VoiceOver Web 命令列表。

  • tota11y是由可汗学院开发的一款实用的辅助技术问题可视化工具。它是一个脚本，会在您的文档中添加一个按钮，该按钮会触发多个插件，用于注释对比度不足和其他 a11y 违规问题。

  • 在 Windows 上，NVDA是一款免费的开源屏幕阅读器，功能齐全，并且迅速普及。然而，需要注意的是，对于视力正常的用户来说，它的学习难度比 VoiceOver 要大得多。

  • ChromeLens 致力于为视障人士提供开发服务。它还对可视化键盘导航路径提供了强大的支持。http://chromelens.xyz/

ChromeLens Chrome 扩展程序显示键盘可访问性的导航路径

  • ChromeVox是一款屏幕阅读器，可作为 Chrome 扩展程序使用，并内置于 ChromeOS 设备中。

结论

在提升网络可访问性方面，我们还有很长的路要走。根据《网络年鉴》：

  • 每 5 个网站中就有 4 个的文本很容易与背景融合，从而难以阅读。
  • 49.91% 的页面仍然未能为部分图片提供 alt 属性
  • 只有 24% 使用按钮或链接的页面包含带有这些控件的文本标签。
  • 只有 22.33% 的页面为所有表单输入提供标签。

如需了解更多关于无障碍基础知识，以帮助我们改进上述内容，我推荐您阅读 web.dev 上的“无障碍访问”文档。我们可以做很多事情来打造更具包容性的用户体验。

web.dev

文章来源：https://dev.to/addyosmani/accessibility-tips-for-web-developers-4cn0
Devto 翻译
PREV
使用 JavaScript 和网络信息 API 的自适应服务
NEXT
C# 中的基本数据结构和算法