认识无障碍导航

学习目标

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

用户应该始终知道他们在应用程序中的什么地方，他们下一步可以做什么操作。通过以下方式向用户提供导航和操作信息：

说起上下文变化，请考虑下述普遍规则：

可以考虑下面 Report（报表）和 Folders（文件夹）导航图像中的 Show More（显示更多）按钮。

报表导航，突出显示 Recent（最近）和标记为 Show More（显示更多）的按钮。

用户单击 Show More（显示更多）之后，您有几种选项来提醒他们已经引入的新内容。

报表导航，突出显示 Recent（最近）和标记为 Show Less（显示更少）的按钮，下面列示多个选项。

现在屏幕阅读器用户的问题是，“刚才引入的‘更多’到哪里去了？”把新的内容呈现在用户面前，找到这个问题的答案就一目了然了。

在某些用例中，移动用户的焦点或使用 aria-live 区域更恰当。要想知道在特定情形下使用什么方法，需要理解用户的预期。

比如，想象一个启动模式的“编辑”按钮。

带焦点的“编辑”按钮。

启动后，“编辑”按钮会被模式模糊化，这样把焦点留在这个按钮上就没有意义了。在这个例子中，我们把焦点移入模式自身。一条普遍规则是，除非用户明确进行了操作，否则您永远不能移动用户的焦点。在这个例子中，用户单击“编辑”后，焦点应该自动移到编辑上下文中。

当用户对某个东西做出某个操作并且那个东西消失后，要合理地移动焦点，这也很重要。继续用这个例子，当模式关闭时用户的焦点应该移动到哪里？焦点应该去某个东西上，而不只是页面顶部。在这个例子中，一个合理的选择是返回到最初启动模式的“编辑”按钮。

在下面的“资源”部分可以找到上下文变化的更多信息，包括 aria-live 区域。

正确管理焦点是开发无障碍网络应用程序的核心因素之一。一般来说，用户可以在页面中移动焦点，按 Tab 键向前和向下移动页面，按 Shift+Tab 向后和向上移动页面。这适用于天生接收焦点的 HTML 元素，比如锚、按钮和表单控件。

复杂组件，如交互式网格、菜单、组合框和标签集，通过箭头键浏览。这些高级交互的编程是您在使用 ARIA 角色属性时向用户做出的承诺的一部分。

我们来讨论用户的上下文变化时如何管理焦点。当他们做出如下操作时，用户的焦点应该发生什么：

这些问题以及许多其他问题的答案请见 SLDS Global Focus Guidelines（全局焦点指引）。

除了这些指引之外，请考虑下列情况：

残疾人用户，包括盲人在内，在与某个应用程序互动的时候通常向前、向下浏览页面。如果您的设计把新内容引入到页面，务必要把新内容添加到触发变化的项目前面。比如，当用户点击一个按钮，在页面上引入表单内联时，在 DOM 顺序中这个表单应该在按钮的后面。随着他们向前、向下浏览页面，而不是后退，用户预计会遇到表单。
不要在组件初始化的时候抢夺焦点，除非那是组件规范的一部分。比如，模式对话框应该在初始化的时候抢夺焦点。
不要制造焦点陷阱。允许用户离开您的组件。还是一样，除非这是组件的预期行为的一部分，比如带模式的时候。
谨慎处理无限加载。不要为了到达另一侧的内容而迫使只用键盘的用户加载和浏览整个摘要、列表或表格。比如，我们的 Chatter 摘要在摘要开头全部都有一个“跳过该摘要”的链接。

接下来，我们来看一下编写无障碍组件。