如何进行可访问性审查？

了解你的模块、主题或网站的可访问性水平，起初可能看起来是一项艰巨的任务。如果你是可访问性领域的新手，这个话题可能会让你不知从何入手。为了满足不同能力用户的需求，需要考虑到多种因素。本篇文档将必要的注意事项整理为一个逻辑清晰、循序渐进的可访问性检查流程，帮助你评估模块主题或网站的可访问性。

从自动化检测工具开始

许多可访问性问题都可以通过自动化检测工具发现。常用工具包括 WAVE、Tenon、Accessibility Insights、Google Lighthouse、Siteimprove 以及 Chrome 扩展 Siteimprove Accessibility Checker。部分检测也可通过 axe-core 自动完成。这些工具能帮助你快速识别常见问题，如错误的标记结构、缺少 ARIA 属性或颜色对比度不足。

键盘导航测试

键盘导航是确保所有用户能访问页面的关键方式，特别是对于无法或不愿使用鼠标的用户，包括屏幕阅读器用户和行动受限的用户（如 RSI 或瘫痪患者）。为了提供良好的键盘体验，应确保逻辑清晰的 Tab 顺序和清晰的焦点样式。同时，避免用户需要经历过多的 Tab 步骤。

检查要点

• 是否提供“跳过重复内容”的链接？

页面应提供跳转链接，让用户可以直接跳到页面主体内容，跳过重复的导航菜单。该链接应为页面的第一个 Tab 焦点，并在聚焦时可见。

• 所有交互元素是否都能通过键盘操作？

每个交互元素都应支持键盘操作，例如展开/折叠、树形视图、滑块、对话框、拖放等，或提供替代方式执行相同操作。

• 能否在两个方向上进行 Tab 导航？

有些应用允许向前 Tab 导航，但无法使用 Shift+Tab 返回，这会造成“键盘陷阱”。确保你可以在界面中双向导航。

• 是否存在键盘陷阱？

避免出现无法退出的焦点捕获情况。用户是否能仅通过键盘关闭弹窗、模态框或自动补全组件？若不能，你就创建了键盘陷阱。

• 当出现对话框时，焦点是否被限制在内部？

当对话框出现时，焦点应限定在对话框内，避免用户在未察觉的情况下将焦点切换到背景页面。

• 焦点是否始终可见？

任何可交互或可输入的元素都应可聚焦并显示焦点指示器（如轮廓或边框）。用户应始终能看到当前焦点位置。

• 是否存在“可用键盘访问但不可见”的内容？

确保被隐藏的内容不会出现在 Tab 顺序中。

• 鼠标悬停时显示的内容是否也能通过键盘访问？

如果有内容仅在鼠标悬停时可见，则应提供键盘访问的替代方式。这不仅有助于键盘用户，也对触屏用户有益。

• 是否存在不应聚焦却可聚焦的元素？

非交互元素不应可聚焦。如果某个元素能获得焦点，用户会期待它能执行某种操作，否则可能会感到困惑。不要在非交互元素上添加 tabindex="0"，这会增加无谓的 Tab 步骤。

• Tab 顺序是否自然合理？

如果修改了 tabindex 或页面布局打乱了 DOM 的自然顺序，键盘用户可能在导航时感到困惑。

检查响应式断点

完成键盘测试后，放大浏览器视图直至达到断点（如平板或手机布局），并重复测试。高倍缩放的用户可能在笔记本上使用移动端布局，因此移动断点不仅影响触控用户。

标题结构

标题是内容的基础结构。良好的标题层级如同书籍的目录，有助于屏幕阅读器用户理解页面结构。描述性标题能帮助用户快速定位内容。

检查要点

• 页面上是否只有一个 H1？

每个页面应只有一个 H1 元素，用于说明页面主题。

• 标题层级是否逻辑正确？

应按层级使用标题标签，而非仅通过字体大小区分，且不要跳过层级。

• 标题是否具有描述性？

标题应简洁明了地描述后续内容。

颜色与对比度

确保足够的颜色对比

文本与背景的颜色对比度应至少为 4.5:1。可使用颜色对比检查工具验证。

颜色不能是唯一的视觉提示

颜色可用于传达信息，但不能是唯一方式。色盲用户可能无法区分颜色。例如：

• 在红绿切换按钮旁增加文字说明“开/关”。
• 为不同状态使用形状或图标辅助区分。
• 不要仅以红色标识表单错误，应提供文字或图标提示。

例如，用红色标识必填字段并不足够，可以在字段标签后加上星号（*）。焦点状态也不应仅依赖颜色，应有额外的视觉提示，如边框。

图标使用

如果图标代表重要功能，应配有说明性文字。例如导航图标应有标签，帮助屏幕阅读器识别。不要假设所有用户都能理解图标含义。

音频与视频

若页面使用音频或视频传递信息，应提供字幕或文字稿。参考 WebAIM 关于字幕和转录的指南。

• 有声或无声的视频均应提供文字稿。
• 带声音的视频需提供隐藏字幕。
• 复杂视频应提供音频描述，说明场景或动作。
• 直播视频应为听障用户提供实时字幕。
• 直播音频应提供文字替代。

这些要求对应 WCAG 1.2 时间媒体准则。

动画与自动播放

自动播放的动画、视频或音频可能分散注意力。避免播放超过 5 秒的动画，或提供暂停与播放控制。

动态内容

JavaScript 可动态更新页面内容。屏幕阅读器用户也应被告知内容更新。可使用 Drupal.announce() API，它基于 ARIA Live Regions，可通过辅助技术播报变化。

屏幕阅读器测试

自动检测和手动测试能发现多数问题，但屏幕阅读器测试仍然必要。

检查要点

• 所有控件是否都有标签？

每个控件都应有清晰的标签描述其用途。对于复杂组件，可使用 aria-labelledby。

• 自定义控件是否具有正确的 ARIA 属性？

自定义组件应使用合适的 ARIA 角色和属性，例如滑块应使用 role="slider" 并包含 aria-valuenow、aria-valuemin 和 aria-valuemax。

• 屏幕阅读器的阅读顺序是否合理？

CSS 可能改变视觉顺序，应确保阅读顺序仍符合逻辑。

• 链接文本是否有意义？

链接应具备上下文无关的可理解性。避免使用“点击这里”、“更多信息”等模糊文本。

• 图片是否具有正确的替代文本？

所有图片应有适当的 alt 属性。若图片仅为装饰用途，alt 应留空。

屏幕阅读器手动测试

部分问题只能通过手动测试发现。常见工具包括 VoiceOver（Mac）和 NVDA（Windows）。可以通过观看 VoiceOver 基础教程 或 NVDA 教程 入门。

熟悉基本键盘命令后，尝试关闭显示器，仅使用键盘导航。掌握这种非视觉操作需要练习，因为不同的屏幕阅读器在浏览器和系统间略有差异。