现代操作系统需要支持广泛的辅助功能,使计算机系统能够被残疾人灵活操作。屏幕上的内容必须大声朗读给看不见的人。如果有人不能触摸控件,则必须通过外部开关或语音命令来操作控件。听觉语音必须转换为文本字幕,供听不见的人使用。例如,苹果的iOS和iPadOS包含了50多种辅助功能,这些功能改变了用于控制用户界面的输入和用于感知用户界面的输出,以适应不同能力的人。
为了使计算系统能够如此灵活地运行,需要在整个平台进行深入的技术工作。这项工作可以分为以下几类:
我们将这些组件统称为系统级辅助功能。这种方法在操作系统级别进行架构设计,以支持可在系统上运行的每个应用程序中的各种不同辅助功能。这减少了支持每个新辅助功能所需的专门工作,并最终意味着该平台对更多人来说更易于访问。
本文通过我们在iPhone上使用VoiceOver屏幕阅读器实现非视觉使用的工作,来说明系统级辅助功能。我们重新构想了触摸屏输入的非视觉使用,引入了适用于控制屏幕阅读器的新手势,并且对于输出,我们添加了对合成语音和可刷新的盲文显示器(输出触觉盲文字符的硬件设备)的支持。我们添加了新的辅助功能API,应用程序可以采用这些API,并使我们的用户界面框架默认包含它们。最后,我们添加了一个辅助功能服务,以桥接这些新的输入和输出以及应用程序。由于我们在系统级别实现了对VoiceOver的支持,因此我们此后发布未来的辅助功能可以直接利用这项工作来提供一致的用户体验。
人与计算系统的界面包括人向系统提供的输入和从系统接收的输出。辅助功能的一个关键技术挑战是构建操作系统的替代方法,以便人们可以使用不同的能力进行输入和输出。作为新模式的早期采用者,辅助功能在扩展计算机的使用方式方面处于领先地位。
许多种输入和输出已被用于操作计算机,从使用物理开关进行输入和灯光进行输出的早期计算系统,到使用键盘和鼠标进行输入以及高分辨率图形显示器进行输出的现代桌面计算机。新类型的输入和输出通过自定义软件以及现有硬件或新的外部硬件的组合来实现。外部硬件设备通常使用USB和蓝牙等协议与现有计算系统通信,注册为人体接口设备 (HID),或使用特定的设备驱动程序。可刷新的盲文显示器是辅助功能的常见硬件设备,它结合了替代输入(通过六个或八个键的弦式盲文输入)和可刷新的盲文字符输出显示器(通常为 40 或 80 个线性盲文字符)。键盘,就像在钢琴上弹奏的和弦,允许用户同时按下多个键。例如,CTRL+C 是标准键盘上的一个“和弦”。
调整现有硬件以支持替代输入和输出机制通常是首选,因为它允许人们使用广泛可用的计算机。这项工作通常在新计算设备推出时发生。例如,当苹果推出iPhone时,多点触控屏幕最初需要视觉才能使用,因为触摸输入和视觉输出是如此紧密地联系在一起——你需要看到触摸的位置才能有效地使用该设备。为了使iPhone能够被视力障碍人士使用,解决方案是将触摸屏输入与屏幕上显示的视觉内容分离。为此,我们引入了可以在不看屏幕内容的情况下使用的新交互手势,并像桌面屏幕阅读器一样使用设备上的语音合成来输出内容,以便没有视力的人可以感知到内容。
为了实现这些新手势,我们首先拦截了触摸事件并改变了它们的解释方式。在iOS上,触摸事件是通过固件级框架生成的,该框架将传感器数据转换为离散的触摸、移动和抬起事件流。我们重新利用了其中一些事件来支持非视觉使用——例如,触摸事件在软件中被更改,以使手指下方的内容被宣布而不是被触发。连续的第二次触摸会触发目标。这种设计更改允许盲人探索屏幕内容,而不会意外触发目标。
其他手势需要被发明和使用多个触摸事件来实现。例如,我们引入了转子手势,用户可以在显示屏上的任何位置“旋转”虚拟旋钮来更改屏幕阅读器设置(例如,语速)。在研究人们如何自然地执行转子手势时,我们发现了用户之间的差异。有些人使用拇指和食指;有些人使用两个靠得很近的拇指,水平移动;另一些人使用两个食指垂直移动。因此,我们构建了一个灵活的手势解释器,通过在触摸序列的持续时间内跟踪每个手指在 30 个事件窗口内的方向性和速度来处理各种情况。因此,触发转子手势需要每个手指在此期间保持相对于彼此的预期运动,但不要求手指之间的固定距离或在屏幕的特定位置操作。
最后,在某些情况下,我们用一组离散的自定义辅助功能操作替换了难以非视觉执行的手势。拖动目标然后将其放置在界面上的其他位置需要高度灵巧的运动,并与屏幕的视觉上下文协调,这对于非视觉操作来说是困难的。相反,我们的 API 允许响应一系列更容易非视觉执行的离散操作来调用适当的功能。拖动目标可以替换为首先选择目标,然后指示预期操作是拖动,然后最终选择应放置的位置。
override var accessibilityCustomActions
[AccessibilityCustomAction]? {
get {
return [
AccessibilityCustomAction(name: "Drop", actionHandler: {_ in performDrop() })]
}
}
这个 iOS VoiceOver 示例为使设备可访问提供了一个初始解决方案,但辅助功能工作也必须与系统的其余部分保持同步。随着后续版本中添加新的交互,需要提供可访问的替代方案。例如,当 iOS 引入剪切/复制/粘贴时,我们需要创建一个可访问的方式来执行此功能。因此,辅助功能的工作需要与平台其余部分的开发同步进行。
为了使人们能够使用各种输入和输出方法访问应用程序,需要以编程方式提供应用程序内容和交互。这意味着应用程序应该能够将其内容转换为计算机可读格式(例如,已知数据结构中的文本和元数据),并且它们应该可以使用不直接绑定到任何特定输入方式的 API 进行操作。
作为一个例子,考虑一个命令行用户界面。输入是一系列字符,这些字符可以直接由键盘生成,也可以由计算机程序(例如,shell 脚本)提供。输出是发出命令后产生的一系列字符。因此,命令行应用程序的辅助功能 API 将接受一系列字符作为输入,并返回产生的一系列字符。API 的抽象意味着命令行应用程序本身不需要做任何特殊的事情来支持各种输入和输出。
对于输入,人们可以直接使用键盘,将听觉语音转换为文本,使用眼睛注视驱动的屏幕键盘,或应用任何其他可以将用户输入转换为一系列字符的方法。对于输出,人们可以阅读屏幕上的文本,使用文本到语音合成收听输出,通过连接的盲文显示器触摸阅读,或使用任何其他已开发出的可以将一系列字符转换为可以感知的东西的方法。
尽管命令行用户界面很简单,但当系统的输出没有完全使用 API 表示时,它也带来了辅助功能挑战。许多命令行程序通过操作字符缓冲区来创建视觉效果(例如,进度条)来直观地表示内容。这种主要视觉表示在朗读时可能难以理解,用户需要知道返回手动检查进度条的更新。人们在使用有限的模式来实现有趣的界面方面也很有独创性——考虑 ASCII 艺术,即排列规则的文本字符行以形成图像的视觉效果。
图形用户界面 (GUI) 中也出现了类似的挑战,聪明的开发人员使用各种方法来实现他们创建的界面的视觉外观,但通常不使用可用的 API 来使这些界面可访问。开发可访问的 GUI 需要通过 API 提供视觉界面的内容、状态和结构。
在最低级别,这意味着使用 API 公开每个用户界面元素(例如,按钮、复选框或文本字段)的内容。按钮实现需要 API 传达其标签(例如“登录”)和类型(“按钮”)。有时,元素也会有相关的状态。按钮可能被禁用以指示当前无法按下,或者复选框可能被选中或未选中。最后,API 需要捕获视觉结构。例如,标签需要与它们标记的元素相关联,以便屏幕阅读器可以将它们一起读取。
因此,系统级辅助功能的一个重要组成部分是提供用户界面元素使其自身可访问所需的 API。在现代用户界面工具包(SwiftUI、HTML 等)中,使用标准元素通常意味着开发人员无需额外工作即可获得辅助功能。工具包为已知类型的元素提供适当的元数据。例如,以标准方式创建的按钮可以提供其标签和状态。由于各种原因,开发人员可能希望扩展到标准组件之外,并且需要 API 来支持在他们这样做时使元素可访问。
列表 2 使 SwiftUI 视图成为辅助功能 API 公开的元素。在原始代码(没有两个加粗行)中,视图协议使用两个彼此相邻的垂直线直观地表示“暂停”状态。添加修饰符 .accessibilityElement()
表明这不仅仅是一个视觉分组或效果,而是一个包含内容的元素。.accessibilityLabel("Pause")
修饰符为无法看到垂直条的用户提供了描述其内容的描述。
var body: some View {
HStack(alignment: .center, spacing: 0.4) {
Image("VerticalLine")
Image("VerticalLine")
}
.accessibilityElement()
.accessibilityLabel("Pause")
}
如列表 2 所示,现代 UI 工具包通常允许使用最少的代码使用户界面组件可访问。然而,辅助功能差距通常仍然存在。由于开发人员通常不是辅助功能的主要用户,因此他们可能很难测试他们的实现。为了帮助测试和调试,大多数平台都提供辅助功能测试工具。不幸的是,这些工具无法自动发现所有问题,原因与它们无法自动修复所有问题的原因相同,因此开发人员需要付出一些努力来理解这些 API、它们的工作方式以及正确使用它们的含义。
为了解决开发人员没有正确实现辅助功能 API 的情况,VoiceOver 用户可以使用按需计算机视觉功能(称为屏幕识别)来解释 GUI 的像素。此功能使以不公开辅助功能信息的第三方用户界面工具包编码的应用程序可用。1 由于每个界面元素都有一组可识别的像素,因此该功能可以标记 VoiceOver 可以使用的每个元素。虽然计算机视觉是一种很有前途的工具,但目前仍需要熟练的开发人员才能使应用程序完全可访问。
实现系统级辅助功能的最后一步是在新输入和输出(在我们的示例中为 VoiceOver)与每个正在运行的应用程序的辅助功能 API 之间创建一个可用的软件桥梁。VoiceOver 需要与每个应用程序的辅助功能 API 实现进行通信,以便它可以访问当前屏幕上显示的内容,可以以编程方式控制每个应用程序,并接收来自每个应用程序的重要事件通知,这些事件将影响 VoiceOver 对每个应用程序状态的反映。这个通信层是辅助功能服务的最重要功能。
扩展我们的示例:将 GUI 转换为可与屏幕阅读器一起使用的信息需要将用户输入连接到屏幕上显示的适当用户界面元素。对于 iOS,VoiceOver 将屏幕上的点击解释为用户请求说出用户手指下的界面元素。为了实现这一点,VoiceOver 将触摸坐标发送到目标应用程序,请求这些坐标处的辅助功能元素。辅助功能服务将请求路由到相应的应用程序,并将答案返回给 VoiceOver。结果是一个辅助功能对象,可以进一步查询更具体的信息,例如元素的标签、值或特征。
在 iOS 中,一个低级框架为辅助功能服务的进程间通信 (IPC) 机制提供支持,用于查询应用程序有关项目的信息。具体来说,Mach 服务器通过允许消息和共享内存在进程之间传递来连接辅助功能服务和每个应用程序。(Mach 是基于 Darwin 的平台上的 IPC 原语的名称,Darwin 平台是 Apple 平台的基础 Unix 平台。)每个应用程序都将自己注册为可访问的服务器,因此辅助功能服务只需要知道应用程序的进程标识符 (pid) 即可向其发送消息。消息传递系统允许每个查询引用一个元素,包括正在查询的属性和任何参数。在应用程序端,当收到查询时,元素引用被解码以指向可以回答查询的真实对象,前提是它正确实现了辅助功能 API。
性能是辅助功能服务中的首要考虑因素,因为用户可以轻松感受到交互中的任何延迟。为了感觉响应迅速,音频输出应在用户手指触摸屏幕后不到 0.4 秒开始。从用户触摸到合成语音开始的事件顺序如下:(1)接收和解释触摸事件;(2)向系统发出查询以获取当前应用程序;(3)查询应用程序以获取触摸位置的元素;(4)查询元素的标签;(5)最后生成并输出标签的合成语音。因此,性能要求与交互约束密切相关。
除了 IPC 层之外,辅助功能服务层的另一个重要作用是提供所有其他有助于实现辅助技术的 API 和服务——语音识别、语音合成以及调整整个系统行为的辅助功能,例如缩放、动态类型、颜色滤镜和触摸。
辅助功能服务通常被重用于自动化用户界面,这已变得越来越流行,作为自动化测试的一部分以及在构建可以在用户界面上完成任务的代理时。因此,自动化测试和自动化代理通常对正确的辅助功能实现具有类似的依赖性。
本文介绍了系统级辅助功能,我们将其称为使整个系统能够被残疾人使用的架构支持。实现这一点需要大量的技术努力——数十种辅助技术、数百种设置以及跨应用程序的无数自定义设置。这些是当今用户需要和期望的基本条件。这项开发工作范围从低级消息传递到硬件连接,再到提供控制底层系统手段的用户界面。如果做得正确,它将为许多原本会被排除在计算之外的人提供改变生活的技术访问。
1. Zhang, X., et al. 2021. 屏幕识别:从像素为移动应用程序创建辅助功能元数据。机器学习研究; https://machinelearning.apple.com/research/creating-accessibility-metadata。
克里斯·弗莱扎克是苹果公司的移动辅助功能经理,他帮助确保 iPhone、iPad、Apple Watch、Apple TV、Apple Vision Pro 等对所有用户都可访问。他与苹果公司的许多人和团队一起帮助创建了 VoiceOver、AssistiveTouch、Switch Control、made for iPhone (MFi) 助听器支持、Assistive Access 等。
杰弗里·P·比格姆是苹果公司以人为本的机器学习主管,也是卡内基梅隆大学计算机科学学院人机交互和语言技术研究所的副教授。他的研究和产品工作已将机器学习应用于辅助功能方面的难题。
版权所有 © 2024 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 22, no. 5—
在 数字图书馆 中评论本文
文尼·多纳蒂 - 推动组织辅助功能
在本文中,我们将探讨微软如何在整个组织中推动辅助功能,并将仔细研究促进包容性文化的基本框架和实践。通过考察意识建设、战略发展、辅助功能成熟度建模等方面,我们旨在为开始辅助功能之旅的组织提供指南。我们的想法是分享我们学到的东西,希望您可以将其应用,调整以适应您公司的宗旨,并在您的文化中培养辅助功能,使其不仅仅是一项复选框活动,而是真正融入到您的文化中。
沙塔布·瓦希德 - 设计系统是辅助功能交付工具
设计系统是为消费者(设计师和开发人员)构建的基础设施,他们致力于应用程序。一个成功的设计系统允许组织中的消费者快速扩展跨应用程序的设计和开发,提高生产力并建立一致性。然而,许多消费者没有准备好为辅助功能构建。组织是否可以使应用程序的辅助功能支持的构建具有可扩展性、生产力和一致性?本文探讨了设计系统如何成为支持辅助功能的重要工具。
胡安米·斯宾塞 - 移动应用程序的辅助功能考虑因素
在创建移动应用程序时,考虑辅助功能至关重要,以确保它们对于尽可能广泛的受众来说都是可用且令人愉悦的。与桌面体验相比,移动辅助功能具有独特的考虑因素,但它为那些在日常活动中依赖移动设备的用户提供了巨大的价值。通过牢记这些考虑因素,移动产品开发团队可以更好地支持和改善所有用户的生活。本文探讨了移动应用程序的一些关键辅助功能考虑因素,并重点介绍了彭博社 Connects 应用程序如何在产品和流程中支持辅助功能。
斯泰西·M·布兰纳姆、沙塔布·瓦希德、谢里·伯恩-哈伯、贾马尔·马祖里、卡洛斯·蒙查拉兹、卡尔·迈希尔 - 数字辅助功能的现状
如果您是数字辅助功能的新手,即使您不是,也很难跟上大局,而科技行业发展迅速。因此,我们请一组专家为我们介绍最新情况。他们不仅有涉及数字辅助功能的日常工作,而且还有残疾的生活经验。我们向他们提出了以下问题:辅助功能的现状如何?主要挑战是什么?我们为什么需要可访问的软件?我们如何为辅助功能辩护?谁在带头?我们接下来该何去何从?