AccessKit

跨平台和编程语言的UI无障碍基础设施

动机

目前存在众多UI工具包，且新的工具包不断涌现。迄今为止，只有少数拥有企业支持的大型UI工具包项目实现了无障碍功能，以满足需要辅助技术的用户，如使用屏幕阅读器的盲人。如果要让长尾的UI工具包都实现完全无障碍，我们必须尽可能地在这些工具包之间共享所需的工作。许多工具包都是跨平台的，但每个平台都有自己的无障碍API。这些工具包还使用了多种不同的编程语言，因此共享的基础设施必须能够跨语言使用。

项目组件

数据模式

常言道，数据结构比代码更重要。对AccessKit而言，这句话尤其贴切。AccessKit的核心是一个定义了使UI对屏幕阅读器和其他辅助技术无障碍所需的所有数据的模式。这个模式表示一个树状结构，其中每个节点要么是一个UI元素（如按钮或文本框），要么是元素的分组（如文档、窗格或窗口）。每个节点都有一个整数ID、一个角色（如按钮或窗口）和各种可选属性。该模式还定义了辅助技术可以请求的操作，如移动键盘焦点、触发按钮或选择文本。这个模式主要基于Chromium的跨平台无障碍抽象。

该模式的规范定义使用Rust编程语言。选择Rust是因为它兼具效率和富有表现力的类型系统。

当工具包和平台适配器（见下文）都使用Rust或其他可以高效调用Rust定义函数的语言（如C或C++）编写时，模式中定义的数据可以来回传递，无需序列化开销。在其他情况下，需要序列化以最小化语言互操作性的开销。由于该模式支持serde，每种语言绑定都可以选择自己的序列化格式。

模式定义在accesskit crate中的common目录。虽然尚未稳定，但已相当完整。目前只有一个已知问题：模式还未定义任何事件。虽然平台无障碍API中的某些事件（如焦点变化和属性变化）可以从树更新中推断出来，但其他事件（如针对屏幕阅读器用户的临时公告）则无法推断。

平台适配器

这些是实现平台无障碍API的库。目前已实现以下平台适配器：

Windows适配器，实现UI Automation API，可在accesskit_windows crate中获得，位于platforms/windows目录。它尚未支持所有可能的小部件类型，但现在可用于使真实、非平凡的应用程序无障碍。特别是，它支持单行和多行文本编辑控件，但尚不支持富文本。
macOS适配器，实现Cocoa NSAccessibility协议，可在accesskit_macos crate中获得，位于platforms/macos目录。它在功能上与Windows适配器大致相当，包括对文本编辑控件的支持。
Unix适配器，实现基于D-Bus的AT-SPI协议，可在accesskit_unix crate中获得，位于platforms/unix目录。该适配器也支持文本编辑控件。由于键盘输入处理问题，它尚未能与Orca屏幕阅读器完全兼容，我们正与相关GNOME开发团队合作解决这个问题。

计划开发以下适配器：

Android
iOS/tvOS
Web（创建隐藏的HTML DOM）提供方(工具包或应用程序)和平台适配器之间的交互也受到 Chromium 的启发。由于 Chromium 采用多进程架构,不允许从浏览器进程到沙盒化的渲染进程进行同步 IPC,因此浏览器进程无法按需从渲染器获取辅助功能信息。相反,渲染进程会主动向浏览器进程推送数据。渲染进程最初推送完整的辅助功能树,然后推送增量更新。只有当辅助技术请求上述操作之一时,浏览器进程才需要向渲染进程发送请求。在 AccessKit 中,平台适配器类似于 Chromium 浏览器进程,而 UI 工具包类似于 Chromium 渲染进程,不同之处在于两个组件在同一进程中运行,通过普通函数调用而非 IPC 进行通信。

这种设计的一个显著结果是,只有平台适配器需要在内存中保留完整的辅助功能树。这意味着该设计适用于即时模式 GUI 工具包,只要它们能为每个 UI 元素提供稳定的 ID。

平台适配器主要用 Rust 编写。我们选择 Rust 是因为它兼具可靠性和效率,包括安全的并发性,这在现代软件中尤为重要。一些未来的适配器可能需要部分用其他语言编写,例如 Android 适配器可能需要使用 Java 或 Kotlin。

消费者库

平台适配器所需的一些代码是平台无关的。这些代码位于 accesskit_consumer crate 中,在 consumer 目录下。除了平台适配器,这个库对于实现嵌入式辅助技术也可能有用,比如直接在应用程序内运行的屏幕阅读器,适用于尚未有 AccessKit 平台适配器的平台,或者完全没有平台级辅助功能支持的设备,如游戏主机和家电。

跨平台窗口层适配器

在 Rust 生态系统中,winit crate 是一个流行的跨平台窗口和用户输入抽象。accesskit_winit crate 位于 platforms/winit 目录中,为基于 winit 的工具包和应用程序提供了一种跨平台的 AccessKit 集成方式。AccessKit 也直接集成到了类似的 glazier crate 中。我们以后可能会为其他跨平台抽象(如 GLFW 和 SDL)实现类似的适配器。

GUI 工具包集成

虽然我们预期 GUI 工具包开发者最终会将 AccessKit 集成到他们自己的项目中,但在项目的这个阶段,我们正直接进行一些 GUI 工具包的集成工作,以便在真实环境中测试我们的 AccessKit 工作。到目前为止,我们已经将 AccessKit 集成到了 Rust 的 egui 工具包中。我们还有一个与 Unity 游戏引擎的概念验证集成,展示了将 AccessKit 暴露给 Rust 以外的语言的能力。

语言绑定

仅想使用 AccessKit 的 UI 工具包开发者不应被要求直接使用 Rust。

AccessKit 提供了一个 C API,涵盖了核心数据结构和所有平台适配器。这个 C API 可以从多种语言中使用。C 绑定的 Rust 源代码位于 accesskit-c 仓库中。AccessKit 项目还为 C API 提供了预构建包,包括头文件、动态和静态库以及示例代码,因此工具包开发者完全不需要处理 Rust。最新的预构建包可以在 accesskit-c GitHub 发布页面找到。

Python 编程语言的绑定也可用。Rust 源代码位于 accesskit-python 仓库中。发布版本可以在 PyPI 上找到,并可以使用 pip 包含在你的项目中。

虽然许多语言可以使用 C API,但我们还计划提供库,使得从 Rust 和 C 以外的语言安全地使用 AccessKit 变得更容易。特别是,我们计划为 Java 和其他基于 JVM 的语言提供这样的库。