为什么文本格式化功能可能成为键盘用户的陷阱？

在数字产品中，对文本进行格式化是一种基础的体验：创建段落、添加列表或突出某些单词或短语。所有这些都丰富了读者的阅读体验，有助于他们更好地理解内容。对于作者来说，有几种已有的方式可以用来选择和格式化文本。

但是当文本格式化的一部分是缩进时，作者的写作体验会怎样呢？

这是一项设计师需要了解的重要事项，因为对于键盘用户而言，缩进总是通过 Tab 键来实现的。但这个键对于无障碍访问来说，扮演着更重要的角色：它是这些用户主要的导航工具来导航数字产品。一旦在文本格式化体验中启用了缩进功能，这就会引发一个关键问题：

用户还能正常导航产品吗？

这实际上非常重要到“在使用键盘时不会被卡住”是 Web 内容无障碍指南 (WCAG) 的一项基本要求。但这也引发了一些实际疑问。如果不允许存在键盘陷阱，具体来说……

这些情况通常是如何解决的？用户又是如何发现现有方法的？

这就开始有点复杂了。

随着该行业在过去几十年中变得更加成熟，许多产品采取了不同的方法来应对这一挑战。其中一个重要的结果是，业内还没有达成关于正确解决方案的统一意见。

已有的一种方法是使用 F6 键作为导航的替代方式。但这种方法在不同应用和操作系统中的使用并不一致。例如，某些浏览器使用此键在主要地标之间导航（如 Firefox、Chrome、Edge 等），而其他浏览器（如 Safari、Arc 等）则不使用。同时，F6 键也可能执行其他功能，例如在非地标元素之间循环或重复用户的上一个操作。这种不一致的一个重要后果是，用户发现退出方法会变得困难。另外，这种不一致还让用户感到更加困惑。

当我们仔细研究[成功标准 (2.1.2)]时，并没有明确定义什么是标准的退出方式。这样一来，我们就无法确定何时或如何通知用户有关非标准方法的信息。

我认为该指南确实透露出其整体意图，即退出方法应该既可访问又容易被发现。但为了更清楚地说明这对用户的影响，让我们来看一个 Google Docs 中的常见情况。

卡在Google文档里
当用户打开一个Google文档时，焦点会立刻（巧妙地）跳转到主要的编辑区域。如果用户希望切换到应用的其他部分——比如工具栏，他们可以使用F6键或自定义快捷键跳出文本编辑区。不过，这两种办法都有一个小问题。

由于 F6 键的功能不一致，无法满足这一成功标准，用户只能依赖自定义的快捷键。不幸的是，这些自定义的快捷键也没有直接告知用户，用户唯一能用键盘逃离该文本区域的方法就是随机摸索。

从用户的角度来看，这样的结果显然令人感到沮丧。然而，由于准则的措辞，可以说谷歌遵守了该指南，因为应用程序确实从技术上“通知了用户”——只是不是直接说明。

考虑到这一点，我们能做点什么来解决这个问题吧？

当谈到文本格式化，特别是涉及到缩进的时候，用户会遇到两种情况。

最常见的情况是，缩进仅被允许用于特定的格式设置选项。在这种情况下，通常系统会更加宽容，用户总能找到一种方法摆脱这个“陷阱”，返回导航。

例如，这有一个例子，即 Slack 主要的消息组件。当用户在其文本中添加列表格式时，并且（1）光标也位于列表项的开头，或者（2）选择了列表项中的任何文本时，按下 Tab 键将用于控制缩进。要退出这些情况并恢复正常导航也很简单。

相比之下，更难处理的情况是当缩进总是被启用时，因为在这种情况下，你无法在文本中的任何位置恢复Tab键的默认行为。这种情况最需要帮助。

带缩进的文本格式化会影响用户如何与产品互动和导航。我想提出几点调整建议，这些调整不仅可以更清楚地说明如何解决此问题，还可以让用户获得更一致的体验。

F6键和WCAG
首先，将 F6 确立为WCAG中的地标导航键，并且只能用于此功能而不能用于其他功能。这不仅为键盘用户提供了可靠的退出方法，还能提高产品的地标导航能力。这还是一个不错的额外好处。

然而需要注意的是，并非所有使用切换功能的工具都会包含F功能键（比如说大约60%到65%的键盘就没有）。

改进成功标准
另一个可以改进的地方是在成功标准 (2.1.2) 中明确界定什么是“标准退出方式”，什么是“让用户知道”，以及这个指南是否主要为了提高易发现性。

一致的本地互动方式
最后，调整这些体验的互动模式将是帮助用户最实际的方法。实际上只需要做一些小小的调整。

最有意义的改动是扩展 Escape 键的功能，使其能够在启用或禁用编辑器状态之间切换。这将提供一种一致的方式来退出此组件，使其更加方便。此外，一些额外的行为——例如，逐步清除临时功能或记住光标最后的位置——也将提升整体用户体验。

还有更大的好处。因为它提供了一种一致的组件级模型，适用于任何包含这种格式化体验的产品。这会大大增加它被发现的机会——不论是 Google 文档、Obsidian，还是 VSCode 等代码编辑器，或其他许多现有的文本编辑器。

无论是一个因为行动不便而使用键盘的人，还是一个希望更一致地导航环境的人，这些变化都会在他们使用这些具有缩进功能的文本格式化方面产生积极影响。这确实是一个有点冗长的概念。

我在w3c/silver上提出了一些建议，注意：要求澄清没有键盘陷阱的问题。如果您认为还有其他可以改进的地方，欢迎加入讨论。