编写无障碍组件

学习目标

完成本单元后，您将能够：

认识 Lightning 组件框架所包含的组件集合。
列出创建无障碍组件的步骤。
列出构建自定义 Web 组件的步骤。

简介

Lightning 组件框架提供一套功能齐全的组件供您使用。这些组件全部基于最新的 SLDS 组件蓝图，符合相关的无障碍指引。尽可能使用这些现成的组件。它们已通过无障碍审查，可以为您省去大量额外的工作。您可以在 Component Reference（组件引用）中了解这些组件。

使用组件

Component Reference（组件引用）包含两个不同的组件集合的信息，Aura 组件和 Lightning web 组件。列示的 Aura 组件属于许多不同的命名空间。ui 和 force 命名空间中的组件是为了符合旧版的 ARIA 规范而开发的，不再是可用的最无障碍的组件。

Lightning Web 组件 (LWC) 是构建 Salesforce UI 的首选方式。前往 Migrate from Aura to Lightning Web Components（从 Aura 迁移到 Lightning Web 组件）模块，了解如何使用 LWC 以及如何符合当前的 Web 标准。如果需要了解有关 Aura 的更多信息，请访问 Lightning Aura Components Developer Guide（Lightning Aura 组件开发人员指南）或 Aura Components documentation（Aura 组件文档）。

前缀是 lightning- 的 Lightning Web 组件按照最新的 ARIA 标准而写，符合最新的 SLDS 组件蓝图。尽可能使用这些组件，而不是对应的旧版。

当您在使用 Lightning 组件时，还是要时刻牢记无障碍。比如，当您用 <lightning-icon> 放置一个信息图标时，您还是需要指定一个合理的 alternative-text 值，这样用户会知道这个图标的用途。当您使用 <lightning-input> 时，您还是需要指定一个 label，从程序上把由此产生的 <input> 与它的 <label> 关联起来。设定 required=“true”，这样必填的输入是无障碍风格的。

“Input label（输入标签）”和占位符文本，显示错误提示“This field is required（此字段必填）”。

许多 Lightning 组件也有设置 ARIA 属性的属性。虽然对于这些未必有无障碍要求，但如果您需要设置这些值，我们会把它们包含在内。

创建组件

如果在我们的组件引用中找不到您需要的组件，您可能需要构建您自己的 Lightning 组件。如果是这样，请遵循以下步骤确保它是无障碍的。

总是从 SLDS 组件蓝图开始。认真研究标记以及 ARIA 角色、状态和属性。留意任何必填属性以及随着用户与组件互动而变化的属性。
实施键盘交互。记住 ARIA 角色是对用户的承诺。这种承诺包括对于您指定的角色，提供用户预期的键盘功能。我们的组件蓝图包括键盘导航说明。

提示：不要留意按 Tab 键的事件。而是要留意焦点。屏幕阅读器用户很少用 Tab 键来浏览页面。

管理用户焦点。请参考我们的 Global Focus Guidelines（全局焦点指引），确保交互式元素可以有焦点。
编写自动化并且手动测试您的组件。
1. 编写集成测试，测试键盘交互。测试键盘交互唯一可靠的方法是使用一个真正的浏览器。不要依赖手动 DOM 检查来抓取回归。编写测试，确保标记的准确性，包括：
  - 正确节点上的正确语义。
  - 正确节点上设置正确的属性。
  - 组件生命周期中更新的正确属性值。
2. 按照 SLDS 规范，只使用键盘，手动完成端对端功能测试。确保所有事情都可以通过键盘完成。

Web Components

Web 组件是一个浏览器功能，为 Web 提供一个标准组件模型，由不同地方维护的若干片段组成：shadow DOM、自定义元素、HTML 模板和 CSS 改动（来源）。实际上，Web Components 的根是一个自定义元素。这些自定义元素没有语义值，但是可能会给辅助技术造成直接派生问题。

直接派生问题

如果您创建一个无序的列表 <ul>，带 Web 组件列表项目 <lightning-example-list-item>，您的标记看起来是这样的：

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

不过，这不是无障碍的，因为 <ul> 的每个子项都必须是一个 <li> 元素。屏幕阅读器不能识别这是一个含三个项目的列表。这里，最好依赖 ARIA 角色而不是语义元素。

不是用 <ul>，而是用另一个含 role=“list”的 Web 组件。于是我们的列表项目 Web 组件将需要 role=“listitem”，我们不使用 <li> 元素。使用下面列示的代码，屏幕阅读器可以正确识别这是一个含三个项目的列表。

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

全局 HTML 属性

不要用全局 HTML 属性在内部元素上设置属性。当您在带 Lighting Web 组件的主机上设置一个全局 HTML 属性时，我们的框架会假定您想让它存在于这个主机上，即使您也把它传递下去了。比如，如果您把一个输入 Web 组件上的 aria-describedby 属性用作 API 来设定子项的属性，那么您会无意中设置两遍。

<lightning-example-input aria-describedby="foo">

这样来处理：

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

相反，用驼峰式大小写处理您的 Web 组件的 API 名称，如下所示：

<lightning-example-input ariaDescribedby="foo">

这样处理是正确的：

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

欲知属性名称的更多信息，包括驼峰式大小写的运用，请见“资源”部分。

Shadow DOM

启用 Shadow DOM 的 Web Components 制造了额外的无障碍问题。网络无障碍的许多方面依赖连接网页上不同元素的组件 ID 引用。一个简单的例子涉及标记表单输入。

<label for="foo">First Name</label>
<input type="text" id="foo" />

在上文中的代码例子中，ID “foo”将标签“First Name”与文本输入关联起来。如果由于 Shadow DOM 该标签和输入后来被放入不同的 Web 组件中，那么这个关系在浏览器的无障碍树中不复存在。

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

在这种情况下，该标签和输入不再互相关联，该表单不再是无障碍的。这里的解决方案是，需要 ID 引用关系的时候，不要把元素分属于不同自定义元素。

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

在构建您自己的自定义 Web 组件时，请学习 SLDS 蓝图和 ARIA 设计规范。认识依赖 ID 引用的 HTML 和 ARIA 属性，绝不要把那些元素分属于不同的影子根。

W3C 的一个小组正在开发 Accessibility Object Model，其方针是提供方法来分配角色和属性、更新状态、创建关系，无需依赖 HTML 属性和 ID 引用。尽管该模型还在起草阶段，但一旦被浏览器、辅助技术以及开发界采用，它将增强对 Web 组件无障碍的控制。

大功告成！

已经向您介绍了构建无障碍用户界面的基础。当您准备开始无障碍设计和测试的时候，请在 Trailhead 中寻找更多资源，加深认识。另外，通过 Salesforce Trailblazer Community 加入我们庞大的管理员和开发人员社区，分享想法、加入小组、阅读成功故事等。

资源

文档：W3C Standards and Drafts（W3C 标准和草案）
Salesforce 开发人员参考：Lightning Web Components（Lightning Web 组件）
Salesforce 开发人员参考：属性和属性名称
文档：Accessibility Object Model
Salesforce 帮助：Component Blueprints（组件蓝图）
文档：W3C Web Components Specifications（W3C Web Components 规范）