WCAG 2.1中的新功能：名称标签

WCAG 2.1于2018年发布，引入了几个新的成功标准，从而增强了Web可访问性。本文重点介绍“名称标签”（2.5.3），这是标记用户界面组件的关键方面。我们将探讨常见的陷阱，解决方案和最佳实践。

了解成功标准

成功标准是一个可检验的，技术不足的陈述，定义可访问性的合规性。 “名称标签”评估组件的视觉标签是否匹配其程序化名称。它是WCAG 2.1的“可操作”类别的一部分，专门针对输入方式。重要的是，WCAG 2.1与WCAG 2.0向后兼容。

名称标签：Visual vs.编程

WCAG 2.5.3（级别A）指出：“对于带有文本或文本图像的标签的用户界面组件，该名称包含视觉上呈现的文本。”

这样可以确保视觉上呈现的标签与组件的程序化名称（可访问名称）之间的一致性。这种一致性对于诸如屏幕阅读器和语音识别软件之类的辅助技术的用户至关重要。视觉和程序化名称不需要相同，但必须共享一个共同的相关术语（例如，“提交”和“提交表单”）。差异会造成混乱并阻碍可访问性。

辅助技术的影响

考虑HTML触点表格。使用语音识别的用户可能会遇到一个带有视觉文本“发送”的按钮，但是“提交”的编程名称。这种不匹配是失败的。用户依赖于视觉标签，无法使用语音命令激活按钮。匹配视觉和程序化名称（在两种情况下“发送”）都可以解决此问题。如果aria-label不增加任何值，则将其删除是可取的。

屏幕读取器用户还可以从一致的标签中受益。听到与他们看到的类似的文字可增强可用性。相反，不匹配的标签可能会导致通过语音输入或混淆通过屏幕读取器导航的用户意外激活控件。该标准不适用于缺乏视觉标签的组件。

代码示例：故障状态和更正

本文介绍了三个失败方案：

1. 口语和视觉标签之间的断开连接。
2. 标签不匹配由于“可访问的隐藏”跨度，在口语标签中添加了额外的文本。
3. 带有aria-labelledby标签的输入，该输入未能在口语和视觉标签之间建立相关性。

这些示例突出了常见错误。然后，本文为每种情况提供了更正的代码段。

一项2020年的WebAIM研究表明，在420万种表格投入中，有55％的标签不正确。

使用适当的标签输入配对<label></label>元素至关重要，但是通过aria-label程序化名称（可访问的名称）同样重要。之间的不一致<label></label>文本和aria-label为认知障碍和语音输入用户的用户创建认知超负荷。

标签位置和文本特异性

本文阐明，如果象征性地而不是字面意思，则文本不被视为视觉标签。经常将图像用作文本的丰富文本编辑器举例说明了这一点。

为了保持一致性，视觉上的标签应视为标签文本。最佳放置指南包括：

• 文本输入和下拉列表的左侧。
• 复选框和无线电按钮的权利。
• 内部按钮或选项卡，或下方图标按钮。

如果不是象征性的，标点符号和资本化的微小变化是可以接受的。

没有视觉标签的组件被排除在此成功标准之外。

适当标签的好处

一致的标签允许语音输入用户无缝激活控件，从而消除了猜测。包容性设计使所有用户受益，创造更愉快，更容易获得的体验。

结论和测试

本文总结了WCAG 2.5.3，尽管看起来很简单，但仍强调了其重要性。它突出显示了A级的合规性要求：确保编程名称包含视觉上呈现的文本。

可以使用浏览器开发人员工具（Chrome DevTools，Firefox开发人员工具）或Wave和AX（例如Wave和AX）进行测试。遵守此标准，尽管看似很小，但可显着提高所有用户的可访问性。

以上是WCAG 2.1中的新功能：名称标签的详细内容。更多信息请关注PHP中文网其他相关文章！