确定您的网站或应用是否可访问可能看起来是一项繁重的工作。如果您是首次接触无障碍功能，可能会因为该主题的广度而不知该从何处着手。毕竟，为了适应各种能力，就需要考虑各种各样的问题。
本文将这些问题分解为一个逻辑清晰的分步流程，以便您检查现有网站是否符合无障碍要求。
从键盘开始
对于无法或不想使用鼠标的用户，键盘导航是访问屏幕上所有内容的主要方式。此受众群体包括有动作障碍的用户（例如重复性劳损 [RSI] 或瘫痪）以及屏幕阅读器用户。
为了提供良好的键盘体验，请尽量采用合理的标签页顺序和清晰可辨的焦点样式。
首先，按 Tab 键浏览您的网站。元素获得焦点的顺序应遵循 DOM 顺序。如果您不确定哪些元素应获得焦点，请参阅“了解无障碍功能”课程中关于焦点的模块。最佳实践是，用户可以与之互动或向其提供输入的任何控件都应可获得焦点，并显示焦点指示器（例如焦点圈）。
自定义交互式控件应可聚焦。如果您使用 JavaScript 将
<div>转换为精美的下拉菜单，系统不会自动将其插入到标签页顺序中。如需使自定义控件可聚焦，请为其提供tabindex="0"。大于 0 的tabindex值会更改标签页顺序，可能会让屏幕阅读器用户感到困惑。仅让交互式内容可聚焦。向标题等非交互元素添加
tabindex会降低能够看到屏幕的键盘用户的速度，并且对屏幕阅读器用户没有帮助，因为屏幕阅读器已经知道要读出这些元素。如果您向网页添加了新内容，请先将用户的注意力引导到该内容，以便他们可以对其执行操作。如需查看示例，请参阅在网页一级管理焦点。
设计网站时，应确保用户始终可以在需要时将焦点移至下一个元素。请注意自动补全 widget 和其他可能捕获键盘焦点的上下文。当您希望用户与模态对话框（而非页面上的其余部分）互动时，可以暂时捕获焦点，但始终应提供可通过键盘访问的方法来退出模态对话框。如需查看示例，请参阅模态窗口和键盘陷阱。
使焦点控制功能可用
如果您构建了自定义控件，请让用户只需使用键盘即可使用所有控件功能。如需了解改进键盘访问体验的技巧，请参阅管理组件中的焦点。
管理屏幕外内容
很多网站都有屏幕外内容，它们存在于 DOM 中，但并不可见，例如，响应式抽屉菜单内的链接或模态窗口内尚未显示的按钮。将这些元素保留在 DOM 中可能会造成混乱的键盘体验，尤其是对于屏幕阅读器而言，它们会像对待页面内容一样读出屏幕外内容。
如需获取有关如何处理这些元素的建议，请参阅处理屏幕外内容。
使用屏幕阅读器进行测试
改进常规键盘支持为下一步奠定了基础，下一步是检查网页是否具有适当的标签和语义，以及是否存在妨碍屏幕阅读器导航的任何障碍。
如果您不熟悉辅助技术如何解读语义标记，请参阅内容结构。
- 检查所有图片，确保
alt文本正确无误。这项做法的例外情况是，图片主要用于展示目的，而不是内容的必需部分。如需指示屏幕阅读器应跳过某个图片，请将该值设置为空字符串：alt=""。 - 检查标签的所有控件。对于自定义控件，这可能需要使用
aria-label或aria-labelledby。如需查看示例，请参阅 ARIA 标签和关系。 - 检查所有自定义控件，确保其具有适当的
role和用于传达其状态的所有必需 ARIA 属性。例如，自定义复选框需要role="checkbox"和aria-checked="true|false"才能正确传达其状态。如需大致了解 ARIA 如何为自定义控件提供缺少的语义，请参阅 ARIA 简介。 - 确保信息在页面中的流动顺畅合理。由于屏幕阅读器会按 DOM 顺序浏览网页，因此它们会以无意义的顺序读出您使用 CSS 视觉上重新定位的任何元素。如果您需要某个内容在网页中显示得更早，请将其实际移到 DOM 中更靠前的位置。
- 应尽可能支持屏幕阅读器浏览页面上的所有内容。确保网站的任何部分都不会被永久隐藏或屏蔽，以免屏幕阅读器无法访问。
- 如果内容应向屏幕阅读器隐藏（例如，如果内容位于屏幕之外或仅用于呈现），请将该内容设为
aria-hidden="true"。如需更详细的说明，请参阅隐藏内容。
- 如果内容应向屏幕阅读器隐藏（例如，如果内容位于屏幕之外或仅用于呈现），请将该内容设为
熟悉屏幕阅读器
虽然屏幕阅读器看起来可能很难学，但实际上非常易用。一般来说，大多数开发者只需使用几个简单的键盘命令即可轻松上手。
如果您使用的是 Mac，请观看这个视频，了解 Mac OS 自带的屏幕阅读器 VoiceOver。如果您使用的是 PC，请观看这个介绍 NVDA 的视频。NVDA 是一款以捐款为开发资金来源、适用于 Windows 的开源屏幕阅读器。
aria-hidden 不会阻止键盘焦点
请务必注意，ARIA 只能影响元素的语义，对元素的行为没有影响。您可以使用 aria-hidden="true" 使元素对屏幕阅读器不可见，但这不会更改该元素的焦点行为。对于屏幕外互动内容，请使用 inert 属性，确保将其真正从键盘流程中移除。对于旧版浏览器，请将 aria-hidden="true" 与 tabindex="-1" 组合使用。
交互元素应指明其用途和状态
提供有关控件功能的视觉提示（即功能标示）有助于各种设备上的各种用户操作和浏览您的网站。
- 链接和按钮等交互元素应与非交互元素区分开来。如果用户无法确定某个元素是否可点击，就很难浏览网站或应用。指明交互元素的方法有很多种。一种常见做法是为链接添加下划线，以将其与周围文本区分开来。
- 与焦点要求类似，链接和按钮等互动元素需要
hover状态，以便在鼠标指针悬停在可点击的对象上时告知鼠标用户。不过，为了让其他输入法能够访问这些元素，这些元素必须在没有hover状态的情况下具有区分性。
善用标题和地标
标题和地图注点元素可为您的网页提供语义结构，并大大提高使用辅助技术的用户的浏览效率。许多屏幕阅读器用户报告说，当他们首次访问陌生网页时，通常会尝试按标题导航。
同样，屏幕阅读器还提供跳转到重要地标（例如 <main> 和 <nav>）的功能。因此，请务必考虑如何利用网页结构来引导用户体验。
- 使用
h1-h6层次结构。您可以将标题视为为网页创建大纲的工具。请勿依赖标题的内置样式。相反，请将它们视为大小相同，并针对主要内容、次要内容和辅助内容使用相应的语义级别。然后，使用 CSS 使标题与您的设计相匹配。 - 使用地图注点元素和角色，以便用户跳过重复的内容。许多辅助技术都提供了跳转到网页特定部分的快捷方式，例如由
<main>或<nav>元素定义的部分。这些元素具有隐式地图注点角色。您还可以使用 ARIArole属性来显式定义网页上的区域，如<div role="search">所示。如需查看更多示例，请参阅语义和浏览内容。 - 除非您有使用
role="application"的经验，否则请避免使用role="application"。application地图注点角色会告知辅助技术停用其快捷键，并将所有按键操作传递给网页。这意味着，屏幕阅读器用户通常用于在页面中移动的按键不再起作用，您需要自行实现所有键盘处理。
借助屏幕阅读器查看标题和地标
屏幕阅读器（例如 VoiceOver 和 NVDA）提供了一个上下文菜单，用于跳转到页面上的重要区域。在测试无障碍功能时，您可以使用这些菜单大致了解网页，并确定标题级别是否适当以及正在使用哪些地图注点。
如需了解详情，请参阅有关 VoiceOver 和 NVDA 基础知识的这些教学视频。
实现流程自动化
手动测试网站是否符合无障碍要求可能非常繁琐且容易出错。尽可能自动执行测试会很有帮助。您可以使用浏览器扩展程序和命令行无障碍测试套件。
- 网页是否通过了 aXe 或 WAVE 浏览器扩展程序的所有测试？虽然还有其他选项，但这些扩展程序对于任何手动测试流程都是有用的补充，因为它们可以发现细微的问题，例如对比度失败和缺少 ARIA 属性。
- 如果您更喜欢在命令行中工作，axe-cli 提供与 aXe 浏览器扩展程序相同的功能，但可以从终端运行。
- 为避免出现回归问题（尤其是在持续集成环境中），请将 axe-core 等库纳入自动化测试套件中。axe-core 是 aXe Chrome 扩展程序的引擎，但采用的是命令行实用程序。
- 如果您使用的是框架或库，它是否提供自己的无障碍功能工具？例如，适用于 Angular 的 protractor-accessibility-plugin。尽可能利用可用的工具。
使用 Lighthouse 测试 PWA
Lighthouse 是一款用于衡量渐进式 Web 应用 (PWA) 性能的工具。它使用 axe-core 库来执行无障碍功能测试。
如果您已在使用 Lighthouse，请在报告中查找未通过的无障碍功能测试。修正错误，以改善您网站的整体用户体验。