LWN：重构GNOME古老的无障碍访问功能！

关注了就能看到更多这么棒的文章哦～

The archaeology of GNOME accessibility

By Jonathan Corbet
July 23, 2020
GUADEC
https://lwn.net/Articles/826738/
DeepL assisted translation.

世界上有很多人需要依赖某种无障碍支持（accessibility support），就无法使用他们的电脑。不过，开发者们总是忘了考虑这些无障碍功能，甚至通常都意识不到这些功能。在 2020 年 GUADEC 虚拟会议上的一次演讲中，Emmanuele Bassi 讨论了对无障碍功能的需求、它们在 GNOME 中的历史、以及他重新思考 GNOME 如何支持辅助技术的努力。

他首先将 "无障碍（accessibility） "定义为残障人士的可用性。这种可用性通常是通过使用某种辅助技术提供的。当人们想到谁会从无障碍环境中受益时，很自然地就会想到像霍金这样的人，他显然需要很多辅助技术。但这并不是最常见的辅助技术消费者的样子，相反，其实很多人的父母就需要这些帮助，他们是 60 多岁的活跃者，懂电脑，但年龄越来越大，需要比以前更多的帮助了。

他说，问题的关键是，我们都会在生命的某个阶段从无障碍环境中受益。他今年 39 岁，已经不得不为应对老龄化做出一些妥协。他说，我们都不会再重新年轻了，所以我们都是下一批无障碍软件的消费者。我们有责任为自己，也有责任为其他所有人，让无障碍功能发挥作用。

GNOME 项目第一次获得无障碍支持是在 GTK 1.3 和 2.0 版本之间的开发周期内，也就是大约 18 年前。这项工作是由 Sun 的无障碍团队完成的，作为其公司在自己的工作站上发布 GNOME 2 的工作的一部分。这个实现方案是围绕着三个独立的组件建立的。

• ATK 工具包，它实现了一套抽象的无障碍功能接口。

• AT-SPI，这是应用程序与辅助技术通信的接口。

• GAIL，是 GTK 的 ATK 接口的实现。

Bassi 明确表示，他对这种设计印象不是很好。如果尽力去理解这个设计的由来的话，很可是因为 Sun 公司已经为 Java 提供了这种 API，所以按照类似的思路来做 GNOME 了的工作。实际上，没有人知道为什么 Java 的实现是这么个方式，但复制它比改变它更容易。

更为复杂的是，当时的 GNOME 是基于 CORBA 对象请求代理（object-request broker）的。对于有幸不了解 CORBA 的年轻听众，他建议想象一下任何现代进程间通信机制的企业版——然后把它变得更加企业化。它有一些设计特性，比如一个集中的权威机构，为所有用户分配名字。他说很久以前所有的 GNOME 都是这样工作的，这就是 GNOME 名字中 "object model "一词的来源。

大部分的可访问性实现是在 GTK 源代码树之外维护的，这也带来了自己的问题。这导致 GNOME 的无障碍支持从来都不怎么好用。但它足以让管理者勾选 "无障碍 "框了，这也是许多管理者想要达到的目的了。不幸的是，无障碍性并不仅仅是一个可以勾选框而已，它是一个必须不断更新的过程。但 GNOME 项目最后大多都忘记了它。

在这几年中，世界已经发生了变化。例如 CORBA 已经被 D-Bus 所取代。对源码树之外的 module，大家已经越来越不愿意支持了。向 Wayland 的迁移给现有的辅助技术带来了新问题，就像越来越多地被用于 GNOME 应用程序的沙盒一样。

AT-SPI 已经被移植到了 D-Bus 上，但整个无障碍子系统的架构是一样的。它仍然是在 X11 的内部实现，每个应用程序都希望能够访问整个系统。这个设计是来自早些年可以确认出各个应用程序都是由可信的管理员来安装的，并且是可信 application 的时代。如果是从互联网上随机的地方获得的，这肯定不合适了。

现在世界已经大大改变了，所以 GNOME 中的无障碍支持也需要随之改变。这个系统需要重新设计。但这很难，因为与其他桌面功能的情况不同，不可能要求辅助技术的用户做出贡献。很多时候他们根本无法感知到这些自己没有机会使用的东西，所以甚至很难要求他们发现系统中出现的质量回退并报告出来。

首先需要做的是把各个部分整合起来，其中许多都已经多年未曾动过。一些新的功能被添加了进来，主要是为了配合浏览器提供的新功能，但作为一个整体，GNOME 的无障碍支持并没有真正发挥作用。抽象层并没有真正抽象出任何东西，所以通常要在很多地方进行修改。工具箱（toolkit）需要简化；就目前的情况而言，应用程序开发者希望 GTK 能够解决所有问题，但事实并非如此。此外还需要资金，这项工作不是小事，指望由志愿者来完成是不合理的。

他说，今年，GNOME 基金会（他受雇于该基金会）指示他为即将发布的 GTK 4 版本解决这个问题；他在过去的半年里一直在做这个工作。为了了解这一切，涉及到很多 "考古学（archaeology） "的工作。他一直在努力将很多抽象出去的东西拉回 GTK 中。这样开发者将不必再去看 ATK 参考手册，因为根本就不存在这个手册了。他还一直在研究可移植性，GTK 中的可访问性支持目前还不能在 Windows 等晦涩的系统上使用。

他认为仍然需要一些抽象，但它应该基于概念而不是代码。GNOME 的绘图 API 越来越多地使用层叠样式表（CSS），所以自然我们可以看看 web 在可访问性方面在做什么。W3C 有一个名为 WAI-ARIA 的标准，定义了许多无障碍性所需的抽象概念。

• element 元素是用户界面的可访问部分。

• 每个 elemnt 都有一个 role 角色，描述它的作用：复选框、滑块等。

• attributes 描述了 element 所拥有的东西：properties 属性、visibility 可见性、label 标签、state 状态、与其他元素的关系等。

Bassi 正在围绕这些概念进行一个无障碍功能的实现。他简单地描述了一下，但这时他被告知时间不多了。由此导致的演示速度不得不加快，使得介绍里面跳过了许多东西。

他说，应用开发者需要遵循 WAI-ARIA 规则，以确保其系统的无障碍性。这意味着要使用它提供的无障碍 element，而不是开发自己的 element，例如。widget 的语义不应被改变。任何可以用鼠标指针访问的 widget 也应该可以用键盘访问。widget 需要一个可访问的 label 标签。诸如此类。

他正在使用 gtk-builder-tool 做一些工作，以确保在需要的界面上添加可访问性信息。还有一个新的 assert 机制，可以在界面 element 发生变化时，验证无障碍信息是否发生了变化，希望可以防止无障碍性功能的质量回退。

目前的状态是，new accessibility API 几乎已经定型，只剩下一些小细节。GTK widget 正在被移植到这个新的 API 上。他正在为这个 API 编写一个新的测试套件，文档也在编写中。他还在努力实现 AT-SPI 后端与辅助系统（assistive system）的交流——这是必要工作，如果没有它，其他的工作实际上什么效果都没有。

Bassi 最后对任何愿意帮助这项工作的人提出了一些建议。他希望看到人们编写更多的测试和文档。移植到 Windows 和 macOS 的工作需要完成。沙盒应用程序的可访问性需要改进，它们需要访问信息和辅助技术，但不应该访问整个桌面。自然，也欢迎有资金投入进来推动这项工作。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～