WCAG 2.1 新特性：名称中的标签

WCAG 2.1 建议 于 2018 年发布。现在已经过去几年了，有一些新的成功标准。在本文中，我将讨论 名称中的标签，这是我们如何以视觉方式标记组件。我们将了解一些失败状态的样子、如何修复它们以及如何正确执行它们的示例。

你让我在成功标准上迷茫了……

成功标准是一个可测试的陈述，它与技术无关。它是我们确定工作是否“无障碍”的基线。在这种情况下，“名称中的标签”是正在评估的事物，它属于一大堆其他标准。WCAG 2.1 是规范的当前版本，“名称中的标签”是项目 2.5.3，表示它属于第二类（“可操作”）标准，位于该类别的第五部分（“输入模式”）下，标记为该部分中的第三项。

WCAG 2.1 与 WCAG 2.0 向后兼容，这意味着它是 WCAG 2.0 的扩展。此外，WCAG 2.1 和 2.2 的发布是相互关联的，它们共同起作用。

名称中的标签

所以，回到正题，2.5.3 名称中的标签（级别 A）是 WCAG 2.1 成功标准中新增的定义。以下是它的描述

对于包含文本或文本图像的标签的用户界面组件，名称包含以视觉方式呈现的文本。

此成功标准 (SC) 的目的是确保 **标签在组件上以视觉方式显示的词语也包含在以编程方式与组件关联的词语中。** 这有助于确保任何人，无论是在使用语音识别软件还是视觉健全的人，都可以依靠标签来描述组件的意图或如何与之交互。视觉文本标签和 **编程名称** 不必完全相同，但它们应该包含将它们关联在一起的常用词语（例如，“提交”与“立即提交”）。

重点是由于差异，读取的内容和看到的内容之间不会产生混淆。

辅助技术在行动

让我们以 HTML 联系表单为例。用户可以使用语音识别软件填写表单，并来到表单提交和发送表单的最后一步。

假设按钮的标签和按钮中的视觉文本不一致

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button aria-label="Submit">Send</button>
</form>

在上面的示例中，**按钮对于辅助技术无法正常工作**。按钮包含文本“发送”，但其 aria-label 是“提交”。这就是失败之处。视觉标签（“发送”）与编程名称（“提交”）不一致，两者之间没有关联。

当这些标签匹配或具有共同术语时，语音识别软件的用户可以通过说出链接、按钮和菜单等组件的可见文本标签来进行导航。在这种情况下，我们可以通过匹配标签和文本来解决问题。但由于 aria-label 没有任何附加值，因此完全删除它是一个更好的解决方案

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button>Send</button>
</form>

如果他们听到的文本与他们在屏幕上看到的文本相似，使用屏幕阅读器的有视力用户也会有更好的体验。

当标签和视觉文本不匹配时，尝试使用可见文本标签作为导航手段（例如，“移动到姓氏”）或选择的语音输入用户将陷入困境，因为用户说出的可见标签与启用为语音输入命令一部分的辅助名称不匹配或不是其一部分。

此外，当辅助名称与可见标签不同时，它可能作为隐藏命令发挥作用，语音输入用户可能会 *意外地* 激活它。如果组件不存在可见文本标签，则 SC 不适用。

代码在行动

以下是三种不同的失败状态。

• 一个有问题的 <button> 元素，其中口语标签和视觉标签没有关联。
• 标签不匹配，其中口语文本读取的内容比视觉标签多，因为存在一个“辅助隐藏”的跨度。
• 一个 带有口语标签的输入 通过 aria-labelledby，无法在口语标签和视觉标签之间建立关联。

同样，根据 2.5.3 名称中的标签 SC，这些都是不良实践的例子。

在 2020 年，WebAIM 百万项目 评估了 420 万个表单输入，发现 55% 的表单输入未正确标记，无论是通过 <label>， aria-label 还是 aria-labelledby。

在使用表单时，我们大多数人习惯于将 <label> 与 <input> 或其他一些表单控件配对。这很棒，是指示控件作用的绝佳方法，但控件还具有 **编程名称**，也称为使用 aria-label 的“辅助名称”。

当 <label> 的名称可以与 aria-label 中的编程（或辅助）名称相关联时，我们可以获得更好的用户体验。例如，如果我们使用“姓氏”作为输入的 <label>，那么我们可能希望 aria-label 也为“姓氏”或类似的东西。**无法在编程名称和可见标签之间建立关联会导致认知障碍的用户遇到更多挑战。** 对于必须记住说出与他们看到的控件上的可见标签不同的语音命令的语音输入用户来说，这需要额外的认知负荷。对于需要吸收和理解无法与可见标签联系起来的语音输出的文本转语音用户来说，也会产生额外的认知负荷。这些表单将提交，但它会对无障碍性和残疾用户造成代价。

以下是上面三个修复过的示例！

标签中的文本细节

根据 WCAG SC，如果文本以象征性的方式使用而不是直接用人类语言表达，则不应将其视为可见标签。富文本编辑器就是一个很好的例子，因为编辑器可能会使用图像作为文本（这包含在 1.4.5 文本图像 中）。

为了将标签文本和辅助名称相互匹配，确定 *哪些* 文本应被视为任何给定控件的任何组件的标签很重要。用户界面中通常存在 *多个* 与控件相关的文本字符串。 有一些原因 说明为什么应该将 **最接近的标签** 视为文本标签。这与为与组件交互的用户建立可预测性模式有关。这些原因表明，可见标签应放置在

• 文本输入、下拉框和其他小部件或组件的左侧。
• 复选框和单选按钮的右侧。
• 按钮或选项卡内部或充当按钮的图标下方。

如果标点符号和大小写以象征性的方式使用，也可以认为是可选的。例如，“姓氏”就可以了，而不是“姓氏：”，而“下一步”也就可以了，而不是“下一步…”，等等。

还要考虑的一件事是：没有可见标签的组件不会被 WCAG SC 考虑。

正确的标签有其好处

将组件的标签与其相应的可访问名称匹配的核心益处是，它使语音输入用户能够激活页面上的控件，而无需更改焦点或在两个不同的术语之间进行猜测。

最终，在视觉显示和语音朗读之间使用清晰一致的术语，可以提供更愉快的用户体验——对所有人都是如此——因为辅助技术读取的标签与可见的标签相匹配，这些标签也可以看到和阅读。这就是我们谈论包容性设计的地方——每个人都获益，没有人被落下。

总结

我们刚刚分解了 WCAG 2.5.3 成功准则中关于名称标签的一些细微之处。听起来很简单，但正如我们所见，有些情况下并不那么明确。

当然，遵守此准则的目标是使我们的工作对所有人来说都是可访问和包容的。WCAG 帮助我们了解是否成功，不仅通过提供指南，还通过设置合规等级（A、AA、AAA，其中 AAA 是最高等级）。标签中的文本属于 A 级，意味着它是基本的合规级别。为了获得该等级，WCAG 需要

[…] 用户界面组件，其 标签 包含 文本 或 文本图像，其 名称 包含视觉呈现的文本。

我们可以通过查看站点的源代码、使用浏览器的 DevTools（例如 Chrome 或 Firefox）或使用诸如 WAVE 浏览器扩展（Chrome 和 Firefox）和 Deque Systems 的 Axe（Chrome）之类的工具运行可访问性审核来测试并确保我们的代码完整且正确。

简而言之，在玻璃的另一边有真实的人，我们可以通过我们的代码和设计来帮助他们享受与我们制作的组件的互动。标签中的文本只是 WCAG 中概述的众多准则之一，虽然它可能看起来像是一个很小的细节，但遵守它可以对我们的用户产生重大影响。