构建可访问的Web应用程序（A11Y）最佳实践

使用具有适当标题和结构元素的语义HTML，使辅助技术能够正确解释页面内容。 2.通过使所有交互式元素都可以焦点，提供可见的焦点指标，管理动态组件中的焦点以及支持逻辑导航，来确保键盘可访问性。 3。提供文本替代方案，例如使用标签元素或ARIA属性的图像和适当标签的Alt文本，并提供适当的标签，以及将错误消息与ARIA描述的相关联。 4。具有足够的颜色对比度设计（正常文本至少4.5：1），并通过补充图标或文本来避免单独通过颜色传达信息。 5。通过使用ARIA Live区域宣布更新，正确管理角色和状态，并避免过多的公告来使动态内容访问。 6.通过扮演适当的ARIA角色，管理键盘交互和焦点以及与屏幕读取器进行测试，构建可访问的自定义组件。 7.使用自动化工具（例如AX和Lighthouse），手动键盘和屏幕读取器测试的测试可访问性，并吸引残疾用户发现现实世界中的问题。可访问性是一个正在进行的过程，可确保Web应用程序可感知，可操作和可理解的每个人，包括使用键盘或屏幕读取器的应用程序。

创建可访问的Web应用程序不仅是技术要求，而且是构建包容性数字体验的基本组成部分。可访问性（通常缩写为A11Y，“ 11”代表“ A”和“ Y”之间的11个字母）确保残疾人可以感知，理解，导航，导航和与网络互动。这是构建可访问的Web应用程序时要遵循的关键最佳实践。

1。使用语义HTML

语义HTML是可访问性的基础。它为内容赋予了意义，并有助于辅助技术（例如屏幕读取器）解释您页面的结构。

• 使用适当的标题层次结构（ <h1></h1> to <h6></h6> ）以逻辑组织内容。
• 使用<nav></nav> ， <main></main> ， <section></section> ， <article></article> ， <aside></aside>和<footer></footer>定义页面区域。
• 使用<button></button>进行按钮， <a></a>进行链接，并避免使用<div>或<code><span></span>进行交互式元素。

  这是如此重要的原因：屏幕读取器依靠语义标签来导航。

  不会以按钮宣布，但是<button></button>会。

  ---

  2.确保键盘可访问性

  许多用户仅使用键盘（例如，有运动障碍的人或屏幕读取器用户）浏览网络。您的应用必须在没有鼠标的情况下完全可以操作。

  • 确保可以通过Tab与所有交互元素联系。
  • 提供可见的焦点指示器（如果不替换它，请勿删除outline ）。
  • 在需要时以编程方式管理焦点（例如，打开模式后）。
  • 支持逻辑选项卡顺序，避免陷阱焦点。

  常见的陷阱：

  • 不会陷入焦点的模态
  • 逃脱无法关闭的下拉菜单
  • 无键盘支持的自定义小部件

  ---

  3。提供文本替代品和标签

  非文本内容必须具有可访问的替代方案。

  • 使用有意义的图像使用alt属性： <img src="/static/imghw/default1.png" data-src="chart.png" class="lazy" alt="Sales increased 20% in Q2">
  • 使用空的alt=""用于装饰图像。
  • 使用<label for="id"></label>或aria-labelledby标签表单控制。
  • 当不存在可见标签时，请使用aria-label或aria-labelledby 。

  例子：

   <标签=“搜索”>搜索</label>
  <input type =“ text” id =“搜索” aria-label =“搜索网站”>

  另外，请确保使用aria-describedby以编程方式关联错误消息。

  ---

  4。具有足够的颜色对比度和视觉清晰度的设计

  颜色绝不应该传达关键信息。

  • 对于正常文本的对比度至少为4.5：1 ，大型文本保持3：1 （WCAG AA标准）。
  • 使用Webaim的对比检查器等工具测试您的设计。
  • 除了颜色之外，还要使用图标，文本或模式（例如，红色错误文本一个错误图标）。

  另外，请确保您的UI在不同的缩放水平（最高200-400％）下响应迅速且可用。

  ---

  5。使动态内容可访问

  现代Web应用程序通常会动态更新内容（例如，Ajax，React状态更改）。这些更改必须传达给辅助技术。

  • 使用Aria Live区域（ aria-live ）进行重要更新：

     <div aria live =“ parite”>添加到购物车</div>的项目

  • 当内容更改时，更新地标和角色。
  • 通知用户状态更改（例如，加载状态，表单提交结果）。

  避免过度使用aria-live - 太多的公告会淹没用户。

  ---

  6。构建可访问的自定义组件

  创建自定义UI组件（例如，下拉列表，选项卡，模式）时，必须手动实现可访问性。

  对于自定义下拉列表：

  • 使用role="button"和aria-haspopup="true"
  • 管理聚焦和键盘交互（ ArrowDown ， Enter ， Escape ）
  • 使用aria-expanded表示开放/封闭状态
  • 确保列表具有role="listbox" ，并且选项具有role="option"

  对于标签：

  • 使用role="tablist" ， role="tab"和role="tabpanel"
  • 适当地管理aria-selected和tabindex
  • 支持键盘导航（ Left/Right箭头）

  始终使用真实的屏幕读取器（例如NVDA，Voiceover，Jaws）测试。

  ---

  7。使用真实用户和工具进行测试

  自动化工具仅捕获约30-50％的可访问性问题。

  结合：

  • 自动棋子：斧头，灯塔，波浪
  • 手动键盘测试
  • 屏幕读取器测试（MacOS上的VoiceOver，Windows上的NVDA）
  • 让残疾用户参与可用性测试

  不要仅仅依靠自动化工具 - 现实世界的用法揭示了最关键的问题。

  ---

  可访问性是一个正在进行的过程，而不是一次性清单。通过将这些实践整合到您的开发工作流程（从设计到部署）中，您可以确保您的Web应用程序可供所有人使用，无论其能力如何。

  基本上，如果仅使用键盘或屏幕读取器的人可以使用，那么您就在正确的轨道上。