无障碍性表单

揭秘屏幕阅读器：无障碍表单与最佳实践

Chris DeMars 发表于 2024 年 5 月 17 日

这是我们关于表单无障碍性的系列文章中的第三篇。如果您错过了第二篇文章，请查看 “使用 :focus-visible 管理用户焦点”。在这篇文章中，我们将研究如何在导航表单时使用屏幕阅读器，以及一些最佳实践。

编者注： 我们对文中的一些最佳实践和代码示例进行了编辑。如果您对这篇文章有任何想法和反馈，请告诉我们！

您可能在浏览网页时听说过“屏幕阅读器”一词。您现在甚至可能正在使用屏幕阅读器对您正在构建的体验进行手动辅助功能测试。屏幕阅读器是一种辅助技术 (AT)。

屏幕阅读器将数字文本转换为合成语音或盲文输出，通常与盲文阅读器一起使用。

A user using a braille machine with a computer. — https://do.co/3vQTmoW

在本例中，我将使用 Mac VO。 Mac VO（VoiceOver）内置于所有 Mac 设备中；iOS、iPadOS 和 macOS 系统。根据您运行 macOS 的设备类型，打开 VO 的方式可能有所不同。我正在撰写本文的运行 VO 的 Macbook Pro 没有触控栏，因此我将根据硬件使用快捷键。

在 macOS 上启动 VO

如果您使用的是更新的 Macbook Pro，则机器上的键盘将类似于下图。

您首先按住 cmd 键，然后快速按下触控 ID 三次。

MacBook Pro Keyboard with steps on how to start mac voiceover.

如果您使用的是带有触控栏的 MBP（MacBook Pro），则可以使用快捷键 cmd+fn+f5 打开 VO。如果您在台式机或笔记本电脑上使用传统键盘，则按键应该相同，或者您必须在“辅助功能”设置中打开 VO。打开 VO 后，您会看到此对话框以及 VO 的语音介绍。

Welcome to VoiceOver dialog when opening up voiceover.

如果您单击“使用 VoiceOver”按钮，则可以使用 VO 测试您的网站和应用程序。需要注意的是，VO 针对 Safari 进行了优化。也就是说，在运行屏幕阅读器测试时，请确保 Safari 是您正在使用的浏览器。iPhone 和 iPad 也是如此。

从一开始，您就可以通过两种主要方式使用 VO。我个人使用它的方式是导航到一个网站，并结合使用 tab、control、option、shift 和箭头键，我可以仅使用这些键就可以有效地在体验中导航。

另一种常见的导航体验方式是使用 VoiceOver 转盘。转盘是一项功能，旨在直接导航到您想要体验的位置。通过使用转盘，您无需遍历整个网站，将其视为“选择您自己的冒险”。

修饰键

修饰键是您使用 VO 中不同功能的方式。默认修饰键或 VO 是 control + option，但您可以将其更改为大写锁定或选择这两个选项以互换使用。

VoiceOver utility to change the modifier keys.

使用转盘

要使用转盘，您必须同时使用修饰键和字母“U”。对我来说，我的修饰键是 caps lock。我按下 caps lock + U，转盘就会出现。转盘出现后，我可以使用左右箭头导航到体验中的任何部分。

VoiceOver rotor feature showing the Headings navigation.

在 VoiceOver 中使用转盘

按标题级别导航

另一种浏览体验的巧妙方法是按标题级别。如果您使用修饰键 + cmd + H 的组合键，则可以根据标题级别遍历文档结构。您还可以通过在序列中按 shift 来向上移动文档，例如，修饰键 + shift + cmd + H。

使用 VoiceOver 的标题级别快捷方式

历史与最佳实践

表单是我们在 HTML 中拥有的最强大的原生元素之一。无论您是在页面上搜索内容、提交表单以购买商品还是提交调查。表单是网络的基石，并且是将交互性引入我们体验的催化剂。

Web 表单的历史可以追溯到 1995 年 9 月，当时它是在 HTML 2.0 规范中引入的。有些人说网络的黄金时代，至少我是这么说的。Stephanie Stimac 在 Smashing Magazine 上写了一篇很棒的文章，标题为“标准化选择及其他：原生 HTML 表单控件的过去、现在和未来”。

在我看来，以下是在为网络构建无障碍表单时应遵循的一些最佳实践。

隐式标记是完全可以的。查看 https://www.w3.org/WAI/tutorials/forms/labels/ 文章。如果表单作者不知道 ID，则可以隐式标记。我个人更喜欢显式的方式。

<!-- Implicit Label -->

<label>
  First Name:
  <input type="text" name="firstname">
</label>

<!-- Explicit Label -->

<label for="name">Name:</label>
<input type="text" id="name" name="name" required/>

如果需要某个字段才能完成表单，请使用 required 属性。确保也有一个直观的指示表明某个字段是必需的，因为非屏幕阅读器用户也需要知道某个字段是必需的。

<input type="text" id="name" name="name" required />

button 用于调用操作，例如提交表单。用它！不要使用 div 创建按钮。 div 本身是一个没有语义的容器。

演示

使用 VoiceOver 导航 Web 表单

如果您想查看代码，请导航至 VoiceOver 演示 GitHub 存储库。如果您想使用您选择的屏幕阅读器试用上面的演示，请查看 使用 VoiceOver 导航 Web 表单。

以下列出了您可以在给定操作系统上使用的各种类型的屏幕阅读器软件。如果 Mac 不是您选择的机器，则 Windows 和 Linux 以及 Android 设备都有相应的选项。

NVDA

NVDA 是 NV Access 提供的一款屏幕阅读器。它目前仅在运行 Microsoft Windows 7 SP1 及更高版本的 PC 上受支持。如需了解更多信息，请访问 NV Access 网站上的 NVDA 2024.1 版本下载页面！

JAWS

“我们需要更好的屏幕阅读器”
— 匿名

如果您理解了上面的说法，那么您并不孤单。根据 JAWS 网站，简而言之，它就是：

“JAWS（Job Access With Speech，带语音的作业访问）是全球最受欢迎的屏幕阅读器，专为视力障碍、无法看到屏幕内容或使用鼠标导航的计算机用户而开发。JAWS 为您 PC 上最常用的计算机应用程序提供语音和盲文输出。您将能够从您的办公室、远程桌面或家中浏览互联网、编写文档、阅读电子邮件和创建演示文稿。”
— JAWS 网站

亲自体验 JAWS，如果该解决方案符合您的需求，请务必试一试！

讲述人

讲述人是 Windows 11 附带的内置屏幕阅读器解决方案。如果您选择使用它作为您的首选屏幕阅读器，以下链接提供有关其使用的支持文档。

讲述人完整指南

Orca

Orca 是一款可以在运行 GNOME 的不同 Linux 发行版上使用的屏幕阅读器。

“Orca 是一款免费、开源、灵活且可扩展的屏幕阅读器，可通过语音和可刷新盲文提供对图形桌面的访问。

Orca 可与支持辅助技术服务提供程序接口 (AT-SPI) 的应用程序和工具包配合使用，该接口是 Linux 和 Solaris 的主要辅助技术基础架构。支持 AT-SPI 的应用程序和工具包包括 GNOME Gtk+ 工具包、Java 平台的 Swing 工具包、LibreOffice、Gecko 和 WebKitGtk。目前正在努力为 KDE Qt 工具包提供 AT-SPI 支持。”
— Orca 网站

TalkBack

Google TalkBack 是 Android 设备上使用的屏幕阅读器。有关打开和使用它的更多信息，请查看 Android 无障碍功能支持网站上的这篇文章。

浏览器支持

如果您正在寻找对 HTML 元素和 ARIA（无障碍富互联网应用程序）属性的实际浏览器支持，我建议您访问 caniuse.com 了解 HTML 和辅助功能支持了解 ARIA，以获取有关浏览器支持的最新 4-1-1 信息。请记住，如果浏览器不支持该技术，那么屏幕阅读器可能也不支持。

DigitalA11Y 可以通过他们的文章屏幕阅读器和浏览器！哪种组合最适合无障碍测试？帮助总结浏览器和屏幕阅读器的信息。

谢谢！

感谢 Adrian Roselli、Karl Groves、Todd Libby、Scott O'Hara、Kev Bonnett 等人为澄清和反馈提供的帮助！

链接

评论

SoraWithAnS

评论的永久链接# 2024 年 4 月 21 日

我认为目前的建议是，如果使用 required，则不应使用 aria-required？也就是说，两者只能选其一？

回复
- Chris DeMars
  
  评论的永久链接# 2024 年 4 月 22 日
  
  使用 required 是正确的方法。对于造成的困惑，我深表歉意。帖子已更新。
- Kev Bonett
  
  评论的永久链接# 2024 年 4 月 23 日
  
  据我所知，当然没有必要两者都使用。屏幕阅读器对原生 required 的支持非常好。
  
  如果您在谷歌上搜索，会发现多年来有很多（相互矛盾的）建议。
  
  我个人更喜欢使用 required 来提供原生 HTML5 验证，然后使用 JS 进行渐进增强…使用 novalidate 属性关闭原生验证，并利用约束验证 API 在表单提交时提供错误反馈。
  
  示例如下：https://basher.github.io/Web-UI-Boilerplate/?path=/docs/web-components-or-custom-elements-webui-form-validate–docs
- Chris DeMars
  
  评论的永久链接# 2024 年 4 月 25 日
  
  感谢您的反馈，Kev。帖子已更新。
- Luke
  
  评论的永久链接# 2024 年 4 月 24 日
  
  是的，您不应该这样做，aria-required 仅对非语义标记有用。在输入中完全是多余的。required 属性已经为辅助技术提供了必要的信息。
- Konnor Rogers
  
  评论的永久链接# 2024 年 4 月 25 日
  
  <input aria-required> 在这里实际上什么也不做。
  
  它需要是 <input aria-required="true">
  
  aria 属性是字符串，而不是典型的布尔值。
  
  建议也是错误的。像 VoiceOver 这样的屏幕阅读器能够通过提供 required 属性来正确读出表单元素是必需的。我刚刚测试过。它读得很好。
  
  摘自 MDN 文章“aria-required”
  
  当语义 HTML 、或必须具有值时，应为其应用 required 属性。HTML required 属性禁用提交表单，除非必需的表单控件具有有效值，同时确保借助辅助技术导航的用户了解哪些语义表单控件需要有效内容。
  
  当使用非语义元素创建表单控件时，例如
  
  <
  
  具有复选框角色的 div>，应包含 aria-required 属性，其值为 true，以向辅助技术指示元素上需要用户输入才能提交表单。aria-required 属性可以与 HTML 表单元素一起使用；它不限于分配了 ARIA 角色的元素。
  
  基本上，aria-required="true" 用于非语义元素。即：<div role="checkbox" aria-required="true">
  
  https://mdn.org.cn/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required
Adrian Roselli

评论的永久链接# 2024 年 4 月 23 日

读者应该记住，macOS 上的 VoiceOver 占桌面屏幕阅读器用户的比例不到 10%（根据 2024 年 WebAIM 调查）。理想情况下，应首先在 JAWS 和 NVDA 中进行测试。

至于 5 个最佳实践断言…

默认情况下，<form> 元素如何更易于访问？使用它是否为屏幕阅读器提供了某些特定优势？
for/id 是否在某种程度上优于将文本包装在 <label> 中？
读者应该访问必需属性要求以更好地理解 required 和 aria-required。
我不明白这些焦点样式是如何特别有利于屏幕阅读器用户的（这是本文的范围）。我们知道并非所有屏幕阅读器用户都是盲人，但您是否建议这些用户可以从这些样式中获得额外的益处？
根据定义，<div> 元素不是分隔符。您可能想到了 <hr>。就屏幕阅读器而言，以及通过平台辅助功能 API 传达的信息而言，<div> 是一个通用元素。

回复
- Chris DeMars
  
  评论的永久链接# 2024 年 4 月 25 日
  
  感谢您的反馈，Adrian。form 元素确实为屏幕阅读器提供了上下文，表明它是一个表单，这就是我在示例中使用它的原因。焦点样式之所以存在，是因为我之前已经介绍过它们。我只是想大致展示一下它们。div 是页面中的一个分区，“divider”（分隔线）可能用词不当。
Jan

评论的永久链接# 2024 年 4 月 25 日

required 提供验证功能，aria-required 向辅助技术宣布它是必需的。

根据 Required 属性的要求，required 属性会向屏幕阅读器用户宣布表单元素为“必需”。

此外，文章中链接的 MDN 页面指出，aria-required 应该在“使用非语义元素创建表单控件时”使用。否则，优先使用 required 属性。（另请参阅该页面上的示例。）

您是否有任何资源/测试支持您的说法，即两者可以（或者甚至应该，正如本文暗示的那样）结合使用？

回复
Galeel Bhasha

评论的永久链接# 2024 年 7 月 15 日

我认为我们应该考虑使用 fieldset 和 legend 标签将“配料”下的复选框和“酱汁”下的单选按钮分组，这更具语义性和可访问性。

请参阅本文中的示例 #2 和 #3 –
https://www.w3.org/TR/WCAG20-TECHS/H71.html

回复

发表评论取消回复