Appt 无障碍辅助功能手册 (中文版)

无障碍辅助功能手册 （Appt 基金会 出版, 张赐荣 翻译）

致谢

Appt 基金会是一家致力于让所有应用实现无障碍访问的非营利组织。我们通过分享免费知识与开源代码来实现这一目标。

在此，我们向所有合作伙伴、资助方及译者致以诚挚的谢意。

本手册第一版的出版，得益于 Logius 的 Kristian Mul 与 BZK 的 Raph de Rooij 的大力支持。

第二版的问世，则离不开无障碍基金会（Accessibility Foundation）的 Arja Boer、Sandra Visser 和 Leonie Steggink 的贡献。他们将在其“课程中的无障碍”（Accessibility in Curriculum）教育项目中采用本手册。

本手册中的大量信息由我们的合作伙伴 Abra 与 Q42 提供。

感谢 SIDN 基金、Bartiméus 基金与 GO 基金为我们项目提供的资金支持。

此外，我们还要特别感谢以下大使：

Jeroen de Vrind、Quintin Balsdon、Chris McMeeking 与 Ben Ogilvie。

最后，感谢所有为本手册提供反馈意见的参与者。

如需下载本手册的数字版本，请访问：

【appt.li/handbook】

目录

致谢 1

前言 4

1. 简介 8

2. 残障类型 9

3. 辅助功能 12

4. 法律法规 15

5. 指南 17

可感知 18

可操作 31

可理解 44

稳健性 53

6. 实施方法 56

设计 57

开发 59

测试 61

7. 结语 64

前言

我们周围的世界正变得越来越数字化。每个人都享有平等参与社会的权利，而移动应用的使用已成为其中不可或缺的一部分。因此，确保应用对所有人都能无障碍访问至关重要。

缺乏无障碍设计的应用会将大量人群拒之门外。在数字世界中，遇到困难时往往难以获得及时帮助。全球范围内，超过 10 亿残障人士将从无障碍应用中受益。

本手册提供了切实可行的工具与方法，帮助政府、企业及应用开发者实现应用无障碍，避免重复造轮子。

我们的知识库（【appt.org】）与官方应用（【appt.li/app】）收录了数百篇深度技术文章。

我们共同致力于打造一个所有应用皆可实现无障碍访问的未来。希望本手册不仅能为您带来有价值的见解与知识，更能激发您着手优化应用无障碍体验的动力！

Appt 基金会

Jan Jaap de Groot、Paul van Workum 与 Johan Huijkman

“无障碍设计，人人受益”

“仅在荷兰，就有数百万人患有某种形式的残障。这包括先天性障碍以及后天形成的障碍，如（色）盲、耳聋或肌肉痉挛。此外，老年群体规模不断扩大，他们普遍面临视力或听力衰退等问题。

确保包括这些人群在内的所有人都能够持续参与日益数字化的社会至关重要。他们应当能够通过移动应用等数字平台保持独立生活能力。因此，应用开发者必须充分考虑这些目标群体的多样化需求。

起初，这或许是一项挑战。这些需求具体是什么？实现应用无障碍需要考虑哪些因素？为解答这些问题，业界已制定了一系列指南。本手册正是为此提供解决方案，并以通俗易懂的语言对这些指南进行解读。

实现应用无障碍的美妙之处在于，应用的整体可理解性与易用性将随之提升，惠及所有用户。例如，良好的色彩对比度在阳光直射手机屏幕时同样大有裨益；视频字幕在无法开启声音的场景下也极为实用。

从今天开始打造无障碍应用吧，让这一潜在的新用户群体成为您品牌的忠实传播者！”

Jeroen de Vrind

高级 iOS 开发者

“无障碍即优质商业实践”

“无障碍不仅对商业有利，更重要的是它本身就是一种卓越的商业实践。它为无数用户敞开大门，赋能他们充分发挥潜能。无障碍指南为构建高质量应用提供了清晰的路线图，明确界定了让软件惠及所有人的核心要素。

Android 正成为全球最主流的操作系统之一。它不仅应用于手机，还广泛搭载于汽车、自助终端甚至音乐设备中。让这些工具实现无障碍，将邀请更多人融入公共领域并蓬勃发展。我们或许正在为下一位斯蒂芬·霍金、弗里达·卡罗或海伦·凯勒铺平道路。

Android 的开源特性使像我这样的开发者能够打造诸如‘Android Ally Plugin’等增强型工具。该工具利用 Android 屏幕阅读器的源代码，大幅降低了无障碍应用的开发门槛。

此外，无障碍设计还能激发下一代数字体验的灵感。诸如语音控制（Voice Control）和 TalkBack 等应用是强大的工具，它们打破了数字世界中的使用限制，提供了免提操作或键盘导航等新特性，可广泛应用于驾驶模式或远程控制等新场景。

拥抱无障碍，我们构建的不仅是应用，更是一个更具赋能性的未来。让我们携手打破壁垒，释放每个人的潜能。”

Quintin Balsdon

高级 Android 开发者

“对未来的专业人士而言，无障碍应是理所当然”

“无障碍基金会的使命是构建一个包容且对所有人开放的社会。无障碍网站与应用是其中不可或缺的一环。

我们与 Appt 基金会及其他机构携手，鼓励并协助各类组织落实无障碍设计。让所有网站和应用实现无障碍是一项浩大工程，仅凭一己之力无法完成。世界亟需更多具备无障碍专业知识的专业人士。解决方案之一，便是确保未来的专业人才在求学阶段便掌握无障碍理念。

通过‘课程中的无障碍’项目，我们致力于让所有学生在学习期间了解无障碍知识。我们将无障碍理念纳入国家教育项目的学习目标，并与教师合作将其融入现有课程体系。本手册正是此类课程的重要基石之一。

感谢 Bartiméus 基金与 SIDN 基金为‘课程中的无障碍’项目提供资金支持。感谢 Appt 基金会编纂并发布本手册。唯有携手同行，我们才能让‘对未来的专业人士而言，无障碍应是理所当然’这一愿景成为现实。”

Arja Boer

“课程中的无障碍”项目经理

1. 简介

本手册共分为三个部分。

1. 残障类型与辅助功能

详解人们可能面临的各类残障，以及用于操作应用的辅助功能信息。

2. 法律法规与指南

梳理相关法律法规，并以简明的方式解读指南，帮助您理解应用何时符合无障碍标准。

3. 实施方法

提供打造无障碍应用的实践路径，涵盖面向设计师、开发者与测试人员的具体指导。

免责声明

本手册作者深知提供尽可能可靠出版物的责任。尽管如此，作者对本书中可能出现的任何不准确之处不承担法律责任。部分内容可能存在语境缺失，或解释未能完全契合原始出处。如需深入理解，请务必直接查阅官方原始文献。

2. 残障类型

当某项任务与个人能力不匹配时，便会产生障碍。这可能源于个人生理特征或环境因素。

部分残障是永久性的，如失明或失聪；部分为暂时性，如手指骨折；此外还有情境性障碍，例如在某些场合播放声音是不被允许的。

据估计，全球约有 13 亿永久性残障人士，占全球人口的 16%，且该比例预计将持续上升。近半数 60 岁以上人群患有一种或多种残障。

所有人均享有平等使用应用的权利。无障碍并非可随意开启或关闭的附加功能，而应深度融入设计、开发与测试的每一个环节。

坚定承诺构建无障碍应用。这不仅是为了那些确有需要的用户，也是为了未来的自己——因为每个人都可能面临功能障碍。

“我并非残障，是世界让我变得残障。”

Darice de Cuba

听力障碍

聋人与听障人士

全球有 4.3 亿人存在听力损失，其中 7000 万人为聋人。他们难以感知声音，高度依赖字幕等替代方案。

认知障碍

阅读障碍、多动症（ADHD）与记忆力衰退

认知障碍人群在记忆、专注或阅读方面存在困难。ADHD 患者更容易分心；阅读障碍患者则难以顺畅阅读。全球约有 2.4 亿人患有阅读障碍。

运动障碍

截肢、瘫痪、痉挛或风湿性疾病

多种生理与运动障碍会影响应用的使用。触控输入并非总是可行，往往需要借助物理按键或键盘等替代输入方式。

视力障碍

盲人与视障人士

全球有 2.95 亿人患有严重的视力障碍，难以感知应用中的视觉内容。其中 4300 万人为全盲，完全无法获取视觉信息。

言语障碍

口吃、构音障碍、失语症

全球约有 1900 万人存在言语障碍，如口吃或发音不清。他们可能难以准确执行语音指令。

年龄相关障碍

听力、认知、运动、视力与言语功能衰退

全球有 4.42 亿人因衰老导致功能衰退。听力与视力下降、学习速度减缓及运动能力退化较为常见。该群体规模预计将显著增长。

如需了解更多残障类型信息，请访问：

【appt.li/disabilities】

3. 辅助功能

系统提供多种辅助功能，支持以不同的替代手段操作应用。对部分残障人士而言，这些功能不可或缺；对其他人而言，也能有效降低使用门槛。

常用辅助功能包括：文本缩放、深色模式、屏幕阅读器、语音控制、开关控制与外接键盘。

文本缩放

适用人群：视障人士

高达四分之一的用户选择了更大的文本字体尺寸。视障人士可能难以阅读小字号。应用内的文本必须支持至少 200% 的缩放。所有字符需同步缩放且保持完整可见。因此，每个界面均需包含滚动容器（ScrollView）以支持内容滚动。

深色模式

适用人群：对闪光敏感的人群

支持深色模式可使用户在暗色背景下使用应用。约 30% 的用户偏好深色模式。亮色背景甚至可能引发光敏人群的不适。此外，脑震荡患者也能从中受益。

读屏器

适用人群：视障人士

读屏软件会朗读屏幕上显示的所有内容。即使失明或视力低下，用户亦可借此操作应用。通过手势即可在应用中导航并执行操作：左滑跳转至上一个元素，右滑跳转至下一个元素，双击激活元素。屏幕阅读器是发现多数无障碍问题的核心工具。

学习使用屏幕阅读器：【screenreader.app】

语音控制

适用人群：运动障碍人士

借助语音控制，用户可通过语音指令操作应用。这对运动障碍用户至关重要。系统可显示标签或编号，便于用户控制界面元素。例如，说出“点击返回”、“显示标签”或“我能说什么”即可操控应用。需注意，语音控制目前尚未支持所有语言。

开关控制

适用人群：重度运动障碍人士

重度运动障碍用户通过开关控制操作应用。该功能支持内置或外置开关。内置开关例如设备摄像头；外置开关则为物理辅助设备，如实体按钮或摇杆。操作方式可包括眨眼或按压按钮等。

外接键盘

适用人群：运动障碍人士

通过外接键盘可全面控制设备。对运动障碍用户而言，使用触摸屏操作应用可能困难甚至无法实现。此外，盲人用户也可借助键盘更高效地导航与输入。外接键盘是测试应用无障碍性的重要工具。请确保应用完全支持外接键盘操作，此举也将同步提升开关控制与语音控制等功能的兼容性。

如需了解更多辅助功能信息，请访问：

【appt.li/features】

4. 法律法规

各国均制定了相应的无障碍法律法规。在许多国家，这些法规均引用了《网页内容无障碍指南》（WCAG）。

联合国《残疾人权利公约》

残疾人权利公约

13 亿残障人士

全球绝大多数国家已签署联合国《残疾人权利公约》。该公约旨在促进、保护并确保残障人士的人权与基本自由。

欧洲

8000 万残障人士

在欧洲，《网页无障碍指令》（WAD）适用于政府机构，《欧盟无障碍法案》（EAA）适用于企业。两者均引用 《EN 301 549》 标准。该标准包含专门针对软件（含移动应用）的章节。EN 301 549 第 3.2.1 版引用了 WCAG 2.1 的 44 项成功标准。欧洲超过 8000 万残障人士将由此受益。

美国

6000 万残障人士

在美国，适用《第 508 条》（Section 508）与《美国残疾人法案》（ADA）。第 508 条要求联邦政府使其移动应用实现无障碍。ADA 适用于除联邦政府外的所有实体、组织、公共及私营与非营利机构，要求平等获取所有商品、服务、信息与通信。最新法规明确引用《网页内容无障碍指南》（WCAG）。

如需了解更多法律法规信息，请访问：

【appt.li/legislation】

5. 指南

数字无障碍的国际标准为《网页内容无障碍指南》（WCAG）。该指南最初针对网站编写，但同样完全适用于移动应用。

当前版本 WCAG 2.2 包含 4 项原则、13 条指南与 86 项成功标准。成功标准分为三个等级：A、AA 与 AAA。通常，组织以满足 A 级与 AA 级为目标。

本文后续内容将针对 A 级与 AA 级的每项原则、指南及成功标准提供简明解读。

如需了解更多指南信息，请访问：

【appt.li/guidelines】

文本替代方案

指南 1.1

所有内容均需提供文本描述。文本可通过视觉、听觉或盲文呈现。这使得用户能够将信息转换为最适合其需求的形式。

非文本内容

成功标准 1.1.1 • A级

确保所有非文本内容均提供替代文本。这包括图片、图标与图表。请简要描述该内容的实际含义。盲人用户将借助屏幕阅读器朗读此描述。替代文本同样有助于任何对非文本内容含义存疑的用户。

了解更多：【appt.li/1.1.1】

时序媒体

指南 1.2

所有人都应能访问音频与视频等媒体内容。听障人士无法听见语音，视障人士无法看见画面。通过提供文字稿、字幕和/或音频描述，任何人都应当能感知媒体内容。

纯音频和纯视频（预录）

成功标准 1.2.1 • A级

当信息仅通过音频或画面传递时，需提供文字稿。例如播客仅通过音频传递信息，听障人士无法获取；动画片通常仅通过画面传递信息，视障人士无法观看。

了解更多：【appt.li/1.2.1】

字幕（预录）

成功标准 1.2.2 • A级

确保所有带声音的视频均提供字幕。听障、聋人或聋盲人士依赖字幕理解语音内容。字幕同样适用于暂时无法收听声音的场景（如静音区）。

了解更多：【appt.li/1.2.2】

音频描述或媒体替代方案（预录）

成功标准 1.2.3 • A级

对于画面中包含无法通过声音获取的重要信息的视频，需提供文字稿或音频描述。用户可通过阅读文字稿或收听音频描述获取内容。
了解更多：【appt.li/1.2.3】

字幕（直播）

成功标准 1.2.4 • AA级

确保所有带音频的直播视频提供实时字幕。这使得需要字幕的用户能够直接获取语音信息。

了解更多：【appt.li/1.2.4】

音频描述（预录）

成功标准 1.2.5 • AA级

当视频包含无法通过声音获取的重要画面信息时，需提供音频描述。可通过提供额外音轨实现。这使得盲人或难以处理视觉信息的用户也能理解内容。

了解更多：【appt.li/1.2.5】

适应性

指南 1.3

屏幕内容必须能够适应用户需求。通过向辅助技术暴露内容结构与信息，内容可以不同方式呈现。例如，标题不仅在视觉上突出，也需为屏幕阅读器用户进行语义标记。

信息与关系

成功标准 1.3.1 • A级

确保屏幕上的信息与关系不仅通过视觉传达。

屏幕信息必须传递给辅助技术。例如，确保标题不仅加粗，还在代码中标记为标题层级。

屏幕上的关系必须向辅助技术标明。列表元素需支持逐项导航；表格元素需支持按行与列导航。

了解更多：【appt.li/1.3.1】

有意义的序列

成功标准 1.3.2 • A级

确保辅助技术遵循的阅读顺序准确反映内容含义。相关联的元素必须集中呈现，否则可能导致用户误解内容。
了解更多：【appt.li/1.3.2】

感官特征

成功标准 1.3.3 • A级

确保操作说明对所有人均可理解。仅依赖形状、尺寸、位置、方向或声音的说明并非人人可懂。例如，盲人无法看见形状。请结合多种属性进行说明，确保普适性。
了解更多：【appt.li/1.3.3】

屏幕方向

成功标准 1.3.4 • AA级

确保屏幕内容随设备方向旋转。应用的所有界面均需支持任意方向使用。轮椅用户有时会将设备固定在特定位置。横屏模式可容纳更多文字，对使用大字号的用户尤为实用。

了解更多：【appt.li/1.3.4】

识别输入目的

成功标准 1.3.5 • AA级

确保输入框明确提示用户需填写的信息类型。设置正确的输入类型以启用自动填充（如电子邮箱）。这不仅能提升所有人的输入效率，还能降低残障用户的出错率。

了解更多：【appt.li/1.3.5】

可辨别性

指南 1.4

内容必须易于区分。首要的是前景与背景需清晰可辨。文本需具备足够对比度、支持缩放，且不得在任何位置被省略或截断。用户应能随时停止干扰性音频。

颜色的使用

成功标准 1.4.1 • A级

确保颜色不是传递信息的唯一手段。并非所有人都能感知颜色。例如，在说明中结合形状（如绿色对勾或红色叉号）。在地图图例中，除颜色外请使用数字编号，以便色盲用户准确查找。

了解更多：【appt.li/1.4.1】

音频控制

成功标准 1.4.2 • A级

确保播放超过 3 秒的音频可暂停或停止。这对注意力难以集中的人群至关重要。此外，背景音频播放时会严重干扰屏幕阅读器的使用。
了解更多：【appt.li/1.4.2】

对比度（最低）

成功标准 1.4.3 • AA级

确保文本颜色与背景颜色的对比度至少为 4.5:1。对于加粗或大字号文本，3:1 的对比度即可。维持此比例通常可使视障与色盲用户顺畅阅读。此外，这也能提升所有用户在强光环境（如户外阳光下）下的使用体验。
了解更多：【appt.li/1.4.3】

文本缩放

成功标准 1.4.4 • AA级

确保文本支持缩放。用户在系统设置中设定偏好字号。这对视障用户尤为关键，否则他们可能无法阅读。此外，缩放后的文本不得被截断、重叠或导致内容不可达。
了解更多：【appt.li/1.4.4】

文本图像

成功标准 1.4.5 • AA级

确保不使用图片来展示文本。图片中的文本通常无法缩放或缩放受限。请使用纯文本，以便文本能根据用户偏好动态缩放。
了解更多：【appt.li/1.4.5】

重排

成功标准 1.4.10 • AA级

确保内容无需同时双向滚动即可访问。双向滚动易使用户迷失方向。允许在同一屏幕提供水平与垂直滚动内容，但每次仅允许单方向滚动。

了解更多：【appt.li/1.4.10】

非文本对比度

成功标准 1.4.11 • AA级

确保屏幕内容的对比度至少为 3:1。这包括图标、输入框与焦点指示器等图形元素。同时确保选中状态清晰可辨。视障与色盲用户需借此区分内容。此举同样提升所有用户在户外强光下的使用体验。
了解更多：【appt.li/1.4.11】

文本间距

成功标准 1.4.12 • AA级

确保段落、字母与单词之间留有充足间距。这有助于阅读障碍用户提升阅读速度，也便于视障用户更轻松地阅读。留白还能帮助认知障碍用户区分内容模块。

了解更多：【appt.li/1.4.12】

悬停或焦点内容

成功标准 1.4.13 • AA级

确保悬停或聚焦后显示的内容可被隐藏。内容需保持可见，直至触发悬停或焦点的原因消失。此外，用户必须能够主动关闭该内容。

了解更多：【appt.li/1.4.13】

键盘可访问性

指南 2.1

用户必须能够通过键盘接口操作应用的所有功能。使用辅助技术时不应存在任何“卡死”区域。这涵盖屏幕阅读器、语音控制、开关控制与外接键盘。

键盘

成功标准 2.1.1 • A级

确保应用的所有功能均可通过键盘接口操作。包括外接键盘、屏幕阅读器、开关控制与语音控制。视障人士使用屏幕阅读器；运动障碍人士使用开关控制与语音控制。

了解更多：【appt.li/2.1.1】

无键盘陷阱

成功标准 2.1.2 • A级

确保键盘接口用户不会陷入操作死循环。用户可能无法关闭弹窗、菜单与遮罩层。许多辅助技术不支持点击元素外部区域关闭。必须提供辅助技术可激活的关闭按钮。

了解更多：【appt.li/2.1.2】

字符键快捷键

成功标准 2.1.4 • A级

确保使用辅助技术时不会误触快捷键。许多辅助技术通过模拟按键执行操作，用户可能意外激活快捷键。需提供修改或禁用快捷键的选项。

了解更多：【appt.li/2.1.4】

充足时间

指南 2.2

用户必须能在其所需时间内完成任务。残障用户或辅助技术使用者通常需要更长时间。使用开关控制填写数据耗时更长；视障用户阅读需更多时间。因此，必须支持延长时间限制并暂停干扰性内容。

时间可调

成功标准 2.2.1 • A级

确保所有人均有充足时间完成任务。残障人士可能需要更长时间浏览界面。使用辅助技术操作应用通常比触控更慢。学习障碍、阅读障碍与认知障碍用户也可能需要更多时间。若存在时间限制，用户必须能够调整该限制。最佳实践是尽量避免设置时间限制。

了解更多：【appt.li/2.2.1】

暂停、停止、隐藏

成功标准 2.2.2 • A级

确保可暂停、停止或隐藏屏幕上的动态元素。动态元素可能干扰用户操作。例如，闪烁内容会使注意力障碍用户难以保持专注。

了解更多：【appt.li/2.2.2】

癫痫与生理反应

指南 2.3

应用必须确保所有人的使用安全。部分人群可能因闪烁画面诱发癫痫。许多人往往在首次发作后才意识到自身患有此症。

三次闪烁或低于阈值

成功标准 2.3.1 • A级

确保应用任何区域每秒闪烁次数不超过三次。否则可能诱发癫痫。触发警告常被忽略，尤其是不识字的人群（如儿童）。

了解更多：【appt.li/2.3.1】

可导航性

指南 2.4

用户必须能够导航至所需信息。当前位置与可跳转路径需清晰明了。标题对理解界面结构至关重要。避免使用非常规功能，以免造成困惑。

跳过块

成功标准 2.4.1 • A级

确保多屏重复出现的内容可被跳过。这对辅助技术用户尤为重要。使用辅助技术通常需逐元素导航，若每屏都需遍历完整菜单将极度耗时。

了解更多：【appt.li/2.4.1】

页面标题

成功标准 2.4.2 A级

确保每个界面均有清晰标题。标题告知用户当前所处位置及可执行操作。该信息对所有用户均有价值，对认知障碍用户尤为关键。

了解更多：【appt.li/2.4.2】

焦点顺序

成功标准 2.4.3 • A级

确保辅助技术导航时采用合乎逻辑的焦点顺序。界面导航顺序通常为从左至右、从上至下。请确保辅助技术遵循等效的焦点顺序。

了解更多：【appt.li/2.4.3】

链接目的（上下文中）

成功标准 2.4.4 • A级

确保每个链接的目的清晰明确。用户可请求链接列表。链接及其周边文本应明确指示跳转目标。清晰的链接对所有人有益，对辅助技术用户尤为关键。

了解更多：【appt.li/2.4.4】

多种途径

成功标准 2.4.5 AA级

确保用户可通过多种方式访问应用界面。例如，引导页通常在首次启动时显示，应在应用其他位置提供入口以便再次查看。搜索功能也有助于快速跳转至特定界面。
了解更多：【appt.li/2.4.5】

标题和标签

成功标准 2.4.6 • AA级

确保标题与标签具有描述性。

描述性标题对理解内容结构至关重要。盲人用户可借助屏幕阅读器按标题导航。

描述性标签帮助用户识别内容。语音控制用户通过朗读标签执行操作。

了解更多：【appt.li/2.4.6】

焦点可见

成功标准 2.4.7 AA级

确保辅助技术聚焦的元素有明确指示。开发者或许无法直接修改焦点框颜色，但可在元素获得焦点时为其设置不同的背景色。
了解更多：【appt.li/2.4.7】

焦点不被遮挡（最低）

成功标准 2.4.11 • AA级

确保键盘聚焦时元素至少部分可见。若用户无法看见聚焦元素，可能不知如何继续操作。聚焦元素不得被其他内容完全覆盖。

了解更多：【appt.li/2.4.11】

输入方式

指南 2.5

确保所有输入形式均兼容辅助技术。语音控制无法执行某些手势；部分用户生理上无法摇晃设备。此类功能必须提供替代操作方式。

指针手势

成功标准 2.5.1 • A级

确保手势触发的操作提供替代方案。并非所有人都能双指张开或滑动。请提供替代方案（如按钮），使用户能执行相同操作。

了解更多：【appt.li/2.5.1】

指针取消

成功标准 2.5.2 • A级

确保触控操作可被取消。按钮应仅在点击（抬起）时激活，而非按下时激活。这赋予用户取消操作的机会。
了解更多：【appt.li/2.5.2】

名称包含标签

成功标准 2.5.3 • A级

确保可操作元素的技术名称包含其视觉标签。用户应能通过“登录”这一名称激活显示“登录”的按钮。若技术名称不同则无法实现。此外，若屏幕阅读器朗读的名称与屏幕显示不符，将造成用户困惑。

了解更多：【appt.li/2.5.3】

运动触发

成功标准 2.5.4 • A级

确保为运动触发的操作提供替代方案，并支持禁用该功能。手部功能受限的用户可能无法摇晃设备；而痉挛患者可能意外触发操作。

了解更多：【appt.li/2.5.4】

拖拽操作

成功标准 2.5.7 • AA级

确保拖拽操作提供等效的单指针替代方案（如点击或长按）。运动障碍用户或辅助技术使用者可能无法拖拽元素。可使用按钮替代拖放功能。
了解更多：【appt.li/2.5.7】

目标尺寸（最小）

成功标准 2.5.8 • AA级

确保交互目标足够大且间距充足，便于用户准确激活。肢体障碍用户可能难以点击小目标。最小尺寸应为 24x24 像素。
了解更多：【appt.li/2.5.8】

可读性

指南 3.1

内容必须对辅助技术可读。这对将文本转换为语音的辅助技术尤为关键。正确设置语言后，内容方可被清晰朗读。

页面语言

成功标准 3.1.1 • A级

确保设置应用语言。部分辅助技术会朗读屏幕文本。单词发音取决于所选语言。

语言设置错误或缺失将导致发音混乱。
了解更多：【appt.li/3.1.1】

部分语言

成功标准 3.1.2 • AA级

确保为文本片段设置对应语言。有时部分内容使用其他语言编写。请设置语言属性以确保文本被正确朗读。

了解更多：【appt.li/3.1.2】

可预测性

指南 3.2

确保操作后的结果可预测。防止焦点或输入时界面突然跳转，以免造成困惑。导航栏应在各屏保持一致位置。确保各屏图标功能一致。使用户明确导航路径与预期结果。

获得焦点时

成功标准 3.2.1 • A级

确保用户移至某元素时的行为可预测。元素获得焦点时不应意外激活。可预测的焦点行为便于残障人士使用应用。

了解更多：【appt.li/3.2.1】

输入时

成功标准 3.2.2 • A级

确保输入数据时的行为可预测。若输入后焦点自动转移，必须提前告知。避免在输入框与复选框等组件中使用此行为。意外操作极易使视障或认知障碍用户困惑。
了解更多：【appt.li/3.2.2】

一致的导航

成功标准 3.2.3 • AA级

确保导航始终位于相同位置。例如，将返回按钮固定于左上角。一致的导航对辅助技术用户尤为实用。
了解更多：【appt.li/3.2.3】

一致的标识

成功标准 3.2.4 • AA级

确保图标功能始终保持一致。例如，放大镜图标仅用于搜索，不可用于放大。这使用户明确该图标的预期功能。

了解更多：【appt.li/3.2.4】

一致的帮助

成功标准 3.2.6 • A级

确保用户可从固定位置获取帮助。若找不到帮助入口，用户可能放弃操作、产生错误或依赖他人。一致的帮助入口对所有人有益，对残障人士尤为关键。

了解更多：【appt.li/3.2.6】

输入辅助

指南 3.3

简化数据输入流程。残障用户与辅助技术使用者更易发生输入错误，且更难发现错误位置。请清晰标示错误并提供修正建议。

错误识别

成功标准 3.3.1 • A级

确保用户输入错误数据后收到清晰的错误提示。明确标示哪项输入有误及原因。错误提示必须对辅助技术用户同样清晰。因此，请同时以文本形式标示错误，确保所有人可感知。

了解更多：【appt.li/3.3.1】

标签或说明

成功标准 3.3.2 • A级

确保要求用户输入数据时提供清晰说明。为输入框添加标签（如“名字”）。标明字段为必填或选填。若数据需特定格式（如日期与电话号码），请明确提示。清晰的说明帮助所有用户，尤其惠及认知障碍用户。

了解更多：【appt.li/3.3.2】

错误建议

成功标准 3.3.3 • AA级

确保为用户提供修正错误的建议。例如，若日期格式错误，请提示日、月、年的预期格式。年-月-日顺序的格式应为 yyyy-mm-dd。清晰的建议尤其有助于认知障碍用户。

了解更多：【appt.li/3.3.3】

错误预防（法律、财务、数据）

成功标准 3.3.4 • AA级

确保用户有意提交数据。允许用户撤销、更正或确认提交。对于产生法律义务、财务交易或数据丢失的提交，至少提供上述选项之一。我们建议对其他类型提交也提供这些选项。
了解更多：【appt.li/3.3.4】

冗余输入

成功标准 3.3.7 • A级

确保不重复要求用户输入已填信息。认知障碍用户可能难以回忆此前输入的内容。已填信息应自动填充或供用户选择。

了解更多：【appt.li/3.3.7】

无障碍身份验证（最低）

成功标准 3.3.8 • AA级

确保登录流程简便。用户应能使用密码管理器，或支持复制粘贴密码。认知障碍用户可能难以记忆密码。

了解更多：【appt.li/3.3.8】

兼容性

指南 4.1

应用应尽可能兼容各类设备。避免源代码错误。为所有元素设置名称、角色与值。确保状态消息同步传递至辅助技术。

解析

成功标准 4.1.1 • A级

确保应用源代码无错误且未使用已弃用函数。当代码不符合现代标准时，辅助技术可能无法按预期运行。
了解更多：【appt.li/4.1.1】

名称、角色、值

成功标准 4.1.2 • A级

确保所有交互元素均设置正确的名称、角色与值。

名称帮助用户识别元素。屏幕阅读器朗读名称，语音控制使用名称执行操作。

角色让用户知晓预期行为。“按钮”角色表明激活后将执行的操作。

值向用户传递状态信息。包括状态（禁用）、属性（选中）与数值（50%）。

例如，为标签页设置名称“首页”、角色“tab”、属性“selected”与值“1/4”。
了解更多：【appt.li/4.1.2】

状态消息

成功标准 4.1.3 • AA级

确保状态消息同步传递至辅助技术。盲人用户无法看见屏幕上新出现的信息。这包括输入时的错误提示或网络连接中断提示。

了解更多：【appt.li/4.1.3】

6. 实施方法

无障碍是一项团队工程。需要多学科人员协同合作，方能打造并持续维护无障碍的应用。

您可借助 W3C 的《无障碍成熟度模型》评估组织的无障碍水平。该模型包含七个维度：

1. 沟通：组织无障碍信息传达与对外沟通的情况。

2. 知识与技能：您的组织内部对无障碍理念的理解深度。

3. 支持：为残障员工与客户提供的协助质量。

4. 开发流程：无障碍在开发流程中的融入程度。

5. 人员：员工多样性与包容性员工群体的建设。

6. 采购：寻找并采购对所有人无障碍的产品（如软件与设备）。

7. 文化：组织对无障碍的态度，包括决策机制。

了解更多：【appt.li/maturity】

后续章节将聚焦开发流程的三个阶段：设计、开发与测试。

设计

许多无障碍问题可在设计阶段预防。越早发现问题，修复成本越低。此即业界所称的“左移”（Shift Left）理念。

对比度

文本与图形元素必须具备充足对比度。对比度越高，可见性越好。

文本对比度至少应为 4.5:1。输入框中的占位符文本同样适用此标准。

以下两种情况 3.0:1 的对比度即可：

1. 加粗文本（至少 18.5px，字重至少 700）

2. 大字号文本（至少 24px）

图形元素对比度至少应为 3.0:1。包括图标与图表。

计算对比度：【appt.li/contrast】

文本缩放

许多用户偏好更大文本。请设计双倍与三倍字号的布局，并确保所有内容保持可读。文本不得在屏幕任何位置重叠或截断。

这可能意味着需调整部分设计。为文本扩展预留充足空间。移除或调整行数限制，确保文本完整显示。

屏幕方向

应用必须支持竖屏与横屏模式。横屏模式下垂直像素减少，通常需启用滚动。

支持横屏可显著提升整体用户体验。对无法独立旋转设备的用户而言，横屏支持更是必不可少。

结构

确保界面结构简洁、清晰且一致。将相关元素分组（如列表项）大有裨益。在设计稿中标注分组元素，以便开发者按预期实现。

分组元素使屏幕阅读器用户能一次性获取所有相关信息。此外，分组元素拥有更大的触控目标，更易于激活。

语言

使用简洁明了、人人易懂的语言。避免复杂术语与长句。保持简短易读。

精心斟酌标题用语至关重要。标题通常充当路标，引导用户在应用中导航。

确保输入框正确标注并包含清晰说明。同时考虑错误输入场景。确保错误提示清晰、具描述性，且以所有用户易于理解的方式呈现。

开发

接下来，开发者将落实无障碍设计。选择具备良好无障碍支持的框架并规避常见无障碍陷阱至关重要。

框架

构建应用有多种方式，如原生、混合或跨平台框架。原生框架提供最佳的无障碍支持。使用混合或跨平台框架时，可能无法充分调用某些无障碍特性。若需开发完全无障碍的应用，原生通常是最佳选择。
了解更多：【appt.li/frameworks】

名称、角色与值

所有交互元素均应设置名称、角色与值。辅助技术用户依赖这些信息操作应用。尤其在构建自定义组件时，设置名称、角色与值常被忽略。

• 名称：帮助用户识别元素。

• 角色：让用户知晓激活后的预期行为。

• 值：告知用户当前数值与状态。

动态界面

由于文本缩放与屏幕方向变化，必须确保界面具备动态适应性。元素不应设置固定宽高，以便按需扩展尺寸。

尽量避免在屏幕顶部与底部使用粘性（Sticky）元素。这会占用横屏模式下的宝贵空间。文本缩放时内容可能被遮挡。虚拟键盘弹出时也可能引发布局问题。

焦点顺序

应用中的焦点顺序应遵循从左至右、从上至下。这确保屏幕阅读器用户以合乎逻辑的方式导航。可能需在代码中手动调整焦点顺序。

替代文本

替代文本对视障用户不可或缺。它提供图片的文本描述，可由屏幕阅读器朗读或转换为盲文。确保所有图片均含替代文本，纯装饰性图片除外。

标题

在应用中标记标题有助于用户导航。当标题在代码中正确语义化后，辅助技术用户可在标题间快速跳转。这使他们更高效地使用应用并理解内容结构。

测试

应用的可访问性应在开发过程中及完成后进行测试。应用可针对特定符合性目标（如 WCAG AA级）进行测试。本文将说明如何进行手动与自动测试。

符合性测试

W3C 制定了《网站无障碍符合性评估方法》（WCAG-EM）用于评估网站无障碍性。其中许多定义专用于网站（如 URL 与网页）。

由于应用与网站存在差异，Appt 基金会牵头开发了《Appt 评估方法》（Appt-EM）。借助 Appt-EM，组织可精准评估应用的无障碍水平。
了解更多：【appt.li/appt-em】

自动化测试

除手动测试外，还可对应用进行无障碍自动化测试。我们整理了可用工具清单（含免费与付费）。建议开发团队根据需求与预算选择最合适的工具。

Android 与 iOS 应用存在多种自动化无障碍测试方案。涵盖平台专属、跨平台及框架特定的测试工具。

了解更多：【appt.li/automated-testing】

手动测试

您无需精通无障碍知识即可开始自行测试。以下为检查应用无障碍性的核心问题。您很可能以 20% 的精力发现 80% 的问题。

免责声明：这些问题仅供初步评估。如需全面评估（含所有细节与例外情况），请联系无障碍专家。

不使用辅助技术的测试

在不启用辅助技术的情况下，您可直观测试以下项目：

• 1.2.2 - 视频是否提供字幕？

• 1.2.3 - 视频是否提供文字稿或音频描述？

• 1.3.4 - 旋转设备时屏幕内容是否同步旋转？

• 1.4.1 - 不依赖颜色时，屏幕所有信息是否依然清晰？

• 3.3.2 - 表单中是否明确标示必填项及预期输入格式？

文本缩放

文本缩放对许多老年用户与视障用户至关重要。您可在系统设置中调整偏好字号。

• 1.4.4 - 文本在 200% 缩放时是否正常显示？

对比度

许多视障用户依赖充足对比度。确保文本与元素对比度达标。截取屏幕截图并使用对比度检测工具测试文本与元素对比度。

• 1.4.3 - 普通文本对比度是否至少 4.5:1？大号与加粗文本是否至少 3.0:1？

• 1.4.11 - 非文本内容对比度是否至少 3.0:1？

屏幕阅读器

屏幕阅读器朗读屏幕显示内容。使用户可在无视觉情况下操作应用。屏幕阅读器是测试多项要求的核心工具。

• 1.1.1 - 非文本内容是否提供替代文本？

• 1.3.1 - 使用辅助技术时界面布局是否清晰？

• 2.1.1 - 能否完全通过辅助技术操作应用？

• 2.1.2 - 应用中是否存在辅助技术无法退出的“死胡同”？

• 2.4.3 - 辅助技术是否按逻辑顺序导航界面？

• 4.1.2 - 交互元素是否设置正确的名称、角色与值？

了解更多：【appt.li/manual-testing】

7. 结语

恭喜您完整阅读本手册！希望本书能激发您打造无障碍应用的动力。

Appt 基金会通过分享免费知识与开源代码推动无障碍普及。我们诚邀所有人共同扩大这一影响力。

加入我们的社区：【appt.li/community】

联系我们：【info@appt.org】

关于作者

Jan Jaap de Groot 与 Paul van Workum 致力于在全球范围内推动应用无障碍。在荷兰，他们是倡导应用无障碍的领军人物。

两人均任职于 Abra——Appt 基金会的核心推动力量及本手册的赞助方。

Abra 协助各类组织实现应用无障碍。欢迎参加免费入门培训：【abra.id/kick-off】

Abra 还提供应用无障碍自动化测试软件，欢迎试用：【abra.id/testing】。

许可协议

本作品采用知识共享署名-相同方式共享 4.0 国际许可协议（CC BY-SA 4.0）进行授权。您可自由复制、分发与传播本手册的任何内容，前提是注明作者姓名与 Appt 基金会。

原文

《appt-accessibility-handbook.pdf》

---

译者

张赐荣，视障者，信息无障碍解决方案研发专家。

多年来，深耕于Web/PC/移动端可访问性优化工作，对跨平台无障碍解决方案拥有深刻的理论研究和丰富的实战经验。

精通障碍用户软件交互设计体验，致力于用专业的能力改善、提升产品可访问性。