认识无障碍导航
学习目标
完成本单元后，您将能够：
- 列举向用户提供导航和操作信息的策略。
- 说明在 Web 应用程序开发中管理焦点的重要性。
简介
用户应该始终知道他们在应用程序中的什么地方，他们下一步可以做什么操作。通过以下方式向用户提供导航和操作信息：
- 采用一致的导航元素。
- 应用合适的标题嵌套和顺序。
- 标记地标性区域。
- 采用合乎逻辑的选项卡排序，符合阅读顺序（在从左到右的语言中，从左到右，从上到下；在从右到左的语言中，从右到左）。
- 对于所有交互性项目，使用可见的焦点指示器。
上下文变化
说起上下文变化，请考虑下述普遍规则：
- 用户应该能够预期上下文变化，因为他们提出了这样的请求，或者向他们说明了即将发生变化。
- 变化发生后，用户应该知道他们在页面上的什么地方。
可以考虑下面 Report（报表）和 Folders（文件夹）导航图像中的 Show More（显示更多）按钮。
用户单击 Show More（显示更多）之后，您有几种选项来提醒他们已经引入的新内容。
- 您可以把焦点放在新内容的第一条上。这是最佳选项吗？也许是吧，不过按钮上的字是“显示更多”，而不是“带给我更多”。
- 您可以用一个
aria-live区域向屏幕阅读器宣告更多导航项目已经添加到页面中。 - 您可以把按钮的文字改成“Show Less（显示更少）”。这是最佳选项，因为用户的成功隐含在了按钮的新文字中：“我可以显示更少，因为现在已经显示更多了”。
现在屏幕阅读器用户的问题是，“刚才引入的‘更多’到哪里去了？”把新的内容呈现在用户面前，找到这个问题的答案就一目了然了。
在某些用例中，移动用户的焦点或使用 aria-live 区域更恰当。要想知道在特定情形下使用什么方法，需要理解用户的预期。
比如，想象一个启动模式的“编辑”按钮。
启动后，“编辑”按钮会被模式模糊化，这样把焦点留在这个按钮上就没有意义了。在这个例子中，我们把焦点移入模式自身。一条普遍规则是，除非用户明确进行了操作，否则您永远不能移动用户的焦点。在这个例子中，用户单击“编辑”后，焦点应该自动移到编辑上下文中。
当用户对某个东西做出某个操作并且那个东西消失后，要合理地移动焦点，这也很重要。继续用这个例子，当模式关闭时用户的焦点应该移动到哪里？焦点应该去某个东西上，而不只是页面顶部。在这个例子中，一个合理的选择是返回到最初启动模式的“编辑”按钮。
在下面的“资源”部分可以找到上下文变化的更多信息，包括 aria-live 区域。
焦点管理
正确管理焦点是开发无障碍网络应用程序的核心因素之一。一般来说，用户可以在页面中移动焦点，按 Tab 键向前和向下移动页面，按 Shift+Tab 向后和向上移动页面。这适用于天生接收焦点的 HTML 元素，比如锚、按钮和表单控件。
复杂组件，如交互式网格、菜单、组合框和标签集，通过箭头键浏览。这些高级交互的编程是您在使用 ARIA 角色属性时向用户做出的承诺的一部分。
我们来讨论用户的上下文变化时如何管理焦点。当他们做出如下操作时，用户的焦点应该发生什么：
- 导航到新页面？
- 打开或关闭模式对话框？
- 删除记录？
- 执行拖放操作？
这些问题以及许多其他问题的答案请见 SLDS Global Focus Guidelines（全局焦点指引）。
除了这些指引之外，请考虑下列情况：
- 残疾人用户，包括盲人在内，在与某个应用程序互动的时候通常向前、向下浏览页面。如果您的设计把新内容引入到页面，务必要把新内容添加到触发变化的项目前面。比如，当用户点击一个按钮，在页面上引入表单内联时，在 DOM 顺序中这个表单应该在按钮的后面。随着他们向前、向下浏览页面，而不是后退，用户预计会遇到表单。
- 不要在组件初始化的时候抢夺焦点，除非那是组件规范的一部分。比如，模式对话框应该在初始化的时候抢夺焦点。
- 不要制造焦点陷阱。允许用户离开您的组件。还是一样，除非这是组件的预期行为的一部分，比如带模式的时候。
- 谨慎处理无限加载。不要为了到达另一侧的内容而迫使只用键盘的用户加载和浏览整个摘要、列表或表格。比如，我们的 Chatter 摘要在摘要开头全部都有一个“跳过该摘要”的链接。
接下来，我们来看一下编写无障碍组件。
资源
Salesforce 帮助：Lightning Design System Global Focus Guidelines（Lightning Design System 全局焦点指引）
W3C Techniques for WCAG 2.0: Using ARIA role=alert or Live Regions to Identify Errors（使用 ARIA role=alert 或 Live Regions 来识别错误）
