为自适应网络工具打造更好的用户体验

互动的工具

对于依靠自适应网络工具浏览互联网的人来说，内容的构建和呈现方式至关重要。世界上最先进的辅助技术也无法读取、播报或操作以非无障碍形式存在的内容。一个实际上是带样式的 <div> 的按钮、一张没有文本替代的图片，或一个不支持键盘操作的自定义下拉菜单，对于每天依赖这些工具的人来说，根本就是不可见的——或者更糟，是一条死路。

QualiBooth 帮助你同时理解两件事：用户的工具究竟如何解读你的内容，以及哪些内容或结构是缺失、损坏或含糊不清的。正是这种结合，区分了一个仅仅在技术上能加载的网站和一个真正对所有人都有效的网站。

本指南将介绍辅助技术和自适应技术的主要类别、每一种类别期望网站如何运作，以及你可以采取的实际步骤，从而与这些工具协作而非与之对抗。它还在真正的辅助技术与无障碍浮层之间划出了清晰的界限——因为这两者经常被混淆，而这种混淆会给真实用户带来真实的后果。

“自适应网络工具”究竟意味着什么

自适应网络工具——更常被称为辅助技术（AT）——是改变一个人感知或操作数字界面方式的软件和硬件。它们不是你网站的附加组件；它们是用户自己的环境，根据用户的需求进行配置，并且常常每天数小时地在数千个网站上使用。

主要类别包括：

• 屏幕阅读器，将屏幕上的内容转换为合成语音或可刷新的盲文。
• 屏幕放大，放大并重排部分或整个显示内容。
• 开关访问设备，供无法使用标准键盘或鼠标的人使用。
• 语音控制，完全通过口头命令来驱动界面。
• 浏览器和操作系统的内置功能，例如高对比度模式、减少动效和阅读工具。
• 阅读和理解辅助工具，对文本进行简化、朗读或重组。

所有这些都依赖于同一个基础：一个结构良好、语义化、可用键盘操作并遵循既定标准的页面。当你按照 WCAG 2.2 进行构建时，你就建立起了每一种这类工具所依赖的契约。

屏幕阅读器：结构就是界面

屏幕阅读器是最为人熟知的辅助技术，对许多团队而言也是最难设计的——恰恰是因为你所看到的视觉布局几乎无法告诉你屏幕阅读器会播报什么。

使用最广泛的屏幕阅读器是 Windows 上的 NVDA 和 JAWS、macOS 和 iOS 上的 VoiceOver，以及 Android 上的 TalkBack。它们并不”看见”你的页面；它们从无障碍树中构建一个模型，而无障碍树则源自你的 HTML 语义以及你在其上添加的任何 ARIA。

屏幕阅读器对你的要求

• 真正的语义元素。 按照其本来用途使用 <button>、<a>、<nav>、<main>、<h1>–<h6> 和 <table>。标题必须是标题，用户才能在各部分之间跳转；链接必须是链接，它才会出现在链接列表中。
• 有意义的文本替代。 每张信息性图片都需要一个描述其用途的 alt 属性。装饰性图片应使用空的 alt=""，以便被跳过而不是作为噪音被播报。
• 为控件提供程序化标签。 表单字段需要关联的 <label> 元素；仅有图标的按钮需要通过 aria-label 或视觉上隐藏的文本提供可访问名称。
• 合乎逻辑的标题层级。 标题是屏幕阅读器用户浏览页面的主要方式。跳过层级或仅为视觉大小而使用标题会破坏这种导航。
• 正确的 ARIA——并且仅在需要时使用。 ARIA 可以传达状态（展开、选中、禁用）以及自定义小部件的角色，但糟糕的 ARIA 比没有 ARIA 更糟。ARIA 的第一条规则是：只要可能，就使用原生 HTML。

一个常见的混淆点是屏幕阅读器与普通文本转语音之间的区别。阅读工具朗读文本；屏幕阅读器则呈现并操作整个界面，包括控件、状态和导航。我们在文本转语音与屏幕阅读器对比中深入探讨了这一区别。

由于自动化工具只能捕捉到屏幕阅读器问题的一小部分，了解你的网站听起来如何的唯一可靠方法，就是像用户那样测试它。我们的屏幕阅读器测试指南介绍了实际的工作流程，而专门的屏幕阅读器评估则由经验丰富的测试人员对你最重要的用户旅程进行这一流程。

屏幕放大：为放大后的视图而设计

低视力人群常常将屏幕放大 200% 到 800% 甚至更多，一次只能看到页面的一小部分。有些人使用操作系统的放大镜；另一些人则依赖浏览器缩放或专业软件。

在高倍放大下，那些你从不考虑的布局决策变得至关重要：

• 重排（Reflow）。 在 400% 缩放时，内容必须重排为单列（WCAG 2.2 成功标准 1.4.10），这样用户就无需在两个方向上滚动才能读完一句话。
• 相关元素的邻近性。 如果错误消息出现在它所描述的字段很远的地方，放大视图的用户可能永远不会在同一视口中看到它们。请把标签、输入框和反馈放在一起。
• 可见的焦点。 清晰、高对比度的焦点指示器能让放大视图的用户在视图跳转后找到自己所在的位置。
• 不丢失内容或功能。 当文本放大到 200% 时，任何内容都不应被裁剪、重叠或变得无法操作（成功标准 1.4.4）。

放大会奖励干净、响应式的布局，而惩罚固定像素的设计以及依赖悬停的内容。

开关访问与键盘可操作性

开关设备让人们能够用一两个简单的输入来操作计算机——一个按钮、一个吹吸装置或一次头部动作——通常是逐个扫描交互元素。开关访问建立在键盘支持之上：如果你的网站完全可以通过键盘使用，那么它几乎肯定也能配合开关使用。

这使得完整的键盘可操作性成为你能做对的最具杠杆效应的事情之一：

• 一切皆可触达。 每个交互元素都必须能够在没有鼠标的情况下获得焦点并被操作——链接、按钮、表单控件、菜单、模态框、轮播图和自定义小部件皆是如此。
• 可见且合乎逻辑的焦点顺序。 焦点应按照与视觉和阅读流程相符的顺序在页面中移动，并且获得焦点的元素必须始终被清晰地标示出来。
• 没有键盘陷阱。 用户必须能够将焦点移出任何组件，包括嵌入的媒体和对话框。
• 跳过链接。 一个”跳到主内容”的链接让人们能够绕过重复的导航，而不必在每个页面上都逐个浏览。

如果客户正在填写表单，他们能否用 Tab 键浏览每个字段、触发下拉菜单、选择产品并提交——全程不碰鼠标？浏览器的自动填充会配合你的标记吗？无论你是否提出这些问题，开关和键盘用户都会针对你的网站给出答案。

语音控制：名称与可见标签很重要

诸如 Dragon、Voice Control 和 Voice Access 等语音控制工具让用户能够说出”点击提交”或”向下滚动”等命令。要让这些命令奏效，控件的可见标签必须与其可访问名称相匹配。这是 WCAG 2.2 成功标准 2.5.3”名称中包含标签”的基础。

实用指引：

• 可访问名称应包含可见文本。如果一个按钮显示”发送消息”，不要给它一个”提交表单”的 aria-label——说出”点击发送消息”的用户将被忽略。
• 避免使用没有文本的纯图标控件，或者给它们一个与可能的口头命令相匹配的可访问名称。
• 让可点击的目标足够大，以便能够可靠地选中，这同时也满足了 WCAG 2.2 中的目标尺寸标准。

浏览器和操作系统的无障碍功能

并非所有自适应工具都是独立产品。现代浏览器和操作系统内置了强大的功能，用户会在系统范围内开启它们，而你的网站应当自动尊重它们：

• 减少动效。 遵循 prefers-reduced-motion 媒体查询，为那些因运动而感到恶心或分心的用户禁用或减弱动画。
• 暗色模式和高对比度。 支持 prefers-color-scheme 以及 Windows High Contrast / Forced Colors，使你的界面保持可读，而不必与用户的设置作对。
• 文本缩放和缩放。 使用相对单位，让浏览器的文本缩放生效，而不是用像素锁定尺寸。
• 阅读模式和阅读工具。 浏览器的阅读视图以及 Immersive Reader 等工具会将页面精简到其核心内容——当你的 HTML 语义化且没有杂乱内容时，效果会好得多。

这些功能对用户而言不需要额外花费，对你而言成本也极低，但它们能显著提升广大受众的舒适度，包括那些没有确诊残障的人。

阅读和理解工具

阅读工具服务于有阅读障碍、ADHD、认知障碍或对页面语言识字能力有限的人群。它们包括文本转语音的朗读器、阅读标尺、单词高亮、摘要工具和翻译工具。

为了与它们良好配合：

• 使用简明、组织良好的语言，配以描述性标题和简短段落。
• 为页面添加标记，使主内容清晰可辨且阅读顺序正确。
• 避免仅通过颜色、布局或图片来传达含义——请提供文本等价物。
• 确保声明了页面语言（lang 属性），以便朗读和翻译使用正确的发音和规则。

良好的内容结构能同时帮助本文中的所有工具，因为它们都从同一套底层标记中获取信息。

真正的辅助技术与无障碍浮层

这是最重要的区别，也是许多组织出错的地方。

真正的辅助技术——屏幕阅读器、放大器、开关访问、语音控制——运行在用户的设备上，由用户控制，并通过你的网站的语义和键盘支持来操作它。用户花了数年时间来配置它。你的工作只是构建一个这些工具能够理解的页面。

无障碍浮层是你添加到自己网站上的第三方脚本，承诺自动”使其变得无障碍”，通常通过一个浮动小部件实现。它们不是辅助技术的替代品，也不是修复一个不可访问网站的办法。原因如下：

• 它们无法修复底层代码。 浮层位于页面之上；它们无法可靠地编造出缺失的替代文本、修复损坏的标题结构，或让一个 <div> 在每个屏幕阅读器中都表现得像一个真正的按钮。
• 它们经常与真正的 AT 冲突。 许多屏幕阅读器用户反映，浮层会干扰他们已经依赖的工具，有时让网站更难使用，而非更容易。
• 它们制造了一种虚假的合规感。 安装一个小部件并不能满足 WCAG 2.2、EAA 或 ADA。已经有针对使用浮层的网站提起的诉讼，恰恰是因为底层的障碍依然存在。
• 它们无法反映真实的体验。 无障碍最终要由每天使用 AT 的人来评判——这就是为什么我们开展由残障人士进行的审计，而不是依赖脚本的说辞。

可靠的途径是在代码中修复无障碍问题，并通过自动化测试和人工测试加以验证。我们在什么是真正的数字无障碍中更全面地阐述了这一理念。

使用自适应工具进行构建的实用工作流程

为辅助技术而构建并不是一次性项目；它是一个融入你现有软件交付方式的过程。一种可持续的方法通常结合四件事：

1. 尽早且频繁地进行自动化扫描。 诸如无障碍扫描软件等工具能在大量代码层面的问题——缺失的标签、对比度失败、损坏的 ARIA——到达生产环境之前就将其捕获。自动化检查快速且可重复，但它们只覆盖了全貌的一部分。
2. 人工测试和辅助技术测试。 那些最影响真实用户的问题——令人困惑的焦点顺序、含糊不清的播报、无法使用的自定义小部件——需要人来发现。我们的人工无障碍审计指南介绍了这如何对自动化形成补充。
3. 将无障碍融入你的团队。 将无障碍视为一项持续性的工作，并以无障碍流程改进为支撑，可以防止当修复仅是一次性举措时所发生的缓慢倒退。
4. 为你的技术栈选择合适的工具。 QualiBooth 的无障碍工具包将扫描、监控和报告汇于一处，而 Agora 和我们的 community edition 则为处于不同成熟阶段的团队提供了入门途径。

如果你对本文中的术语还不熟悉，无障碍术语表在你落实这些实践时会是一个有用的伴侣。

QualiBooth 的定位

QualiBooth 能识别你现有网站上的问题，也能在页面上线之前进行扫描，从而让使用任何自适应工具的客户都获得无缝的体验，提升可用性和品牌忠诚度。我们将自动化检测与经验丰富的测试人员和残障人士的评估相结合，然后帮助你的团队将发现转化为持久的修复——绝不是一个掩盖问题的浮层。

目标很明确：一个能够与你的用户已经信赖的工具协作的网站，按他们的方式，在他们每次访问时都如此。

准备好看看你的网站在真正的辅助技术下表现如何了吗？运行一次免费无障碍扫描来发现唾手可得的改进，申请演示以了解 QualiBooth 的实际运作，或与我们的团队交流，开展量身定制的无障碍咨询合作。