使视觉障碍者可以使用屏幕阅读器访问非本机应用程序

Question

我创建的应用程序脱离了任何本机框架。所有渲染均在 OpenGL 中进行，并由 GLFW 提供上下文，全部采用 C 语言，无需依赖任何框架来提供兼容性。因此，像 NVDA 这样的标准屏幕阅读器没有机会获取信息（不包括 OCR），而我的应用程序是一个可访问性黑洞。如何为屏幕阅读器提供一个可以使用的界面？我认为这是每个操作系统的事情......这在 Windows、Linux、BSD 甚至 Android 上怎么可能呢？在 *NIX 世界中，我认为这取决于桌面环境...我找到了很多关于此的信息，以框架为起点，但很难找到有关如何从头开始执行此操作的资源。

我完全意识到这远远超出了单个开发人员的能力，并且知道通过忽略本机接口来编写程序是一个常见的可访问性漏洞，建议您避免这种情况。

然而，我很难找到资源和切入点来探索这个主题。有人能指出我正确的方向吗？

TL;DR：如何从头开始提供屏幕阅读器兼容性。不是详细的——而是概念上的。

Answer 1

正如您已经清楚地认识到的那样，您的应用程序是一个可访问性黑洞，因为您正在使用渲染引擎。<canvas>对于 OpenGL、SDL、网络或任何在没有特定辅助功能支持的情况下渲染某些内容的库来说，它基本上是相同的。

我们可以讨论几种可能性：

1. 成为无障碍服务器。在 Windows 下，这意味着执行必要的操作，以便您的应用程序根据 UIA / IAccessible2 接口的需求提供可访问的组件。
2. 使用具有辅助功能支持的知名 GUI 工具包及其提供的辅助功能 API 来制作您的应用程序。
3. 通过各自的 API 直接与屏幕阅读器对话，以便让他们在连接的盲文显示器上说出某些内容和/或显示某些内容。
4. 执行特定的屏幕阅读器脚本

然而，它并不止于此。支持屏幕阅读器不足以使您的应用程序真正易于访问。您还必须考虑许多其他事情。

1. 辅助功能服务器、UIA、IAccessible2

这个选项当然是最好的，因为如果您正确地完成工作，辅助技术的用户（不仅仅是屏幕阅读器）通常会对完全可访问的应用程序感到宾至如归。然而，这也是迄今为止最难的，因为你必须重新发明一切。您必须将界面分解为组件，告诉每个组件属于哪个类别（更通常称为角色），进行回调以获取值和描述等。

如果您正在进行 Web 开发，请将其与您必须在任何地方使用 ARIA 进行比较，因为没有默认值、没有标题、没有段落、没有输入字段、没有按钮等。这是一项艰巨的工作！但如果你做得很好，你的应用程序将很容易访问。

您可以通过查看开源 GUI 工具包或浏览器来获得有关如何执行此操作的代码和想法。

当然，每个操作系统使用的 API 都不同。UIA 和 IAccessible2 适用于 Windows，但 MacOS 和一些 Linux 桌面也具有基于相同根原理的特定于操作系统的辅助功能 API。

关于术语的注意事项：辅助功能服务器或提供程序是您正在使用的应用程序或 GUI 工具包，而辅助功能客户端或消费者是屏幕阅读器（或其他辅助工具）。

2. 使用具有良好辅助功能支持的 GUI 工具包

碰巧的是，您当然没有义务重新发明轮子！许多人完成了上述第 1 点的工作，并产生了通常称为 GUI 工具包的库。

其中一些众所周知通常会生成易于访问的应用程序，而另一些则众所周知会生成完全无法访问的应用程序。QT、WXWidgets 和 Java SWT 是其中三个具有相当好的辅助功能支持的工具。因此，您只需使用其中之一及其关联的辅助功能 API，就可以大大简化工作。您将不必直接与 UIA/IAccessible2 和其他平台上的类似 API 的操作系统进行对话。

但要小心，这并不像看起来那么容易：GUI 工具包提供的所有组件不一定都能在所有平台上访问。有些组件可能可以直接访问，其他一些组件需要配置和/或您这边的一些特定代码，而有些组件无论如何都无法访问。有些可以在 Windows 下访问，但不能在 MacOS 下访问，反之亦然。例如，GTK 是 GNOME 下 Linux 下制作可访问应用程序的首选，但 Windows 下 GTK 的结果却很差。另一个例子：wxWidgets 的 DataView 控件在 MacOS 下众所周知，但它是在 Windows 下模拟的，因此更难访问。如有疑问，最好是在您打算支持的所有操作系统和屏幕阅读器组合下进行测试。

遗憾的是，对于游戏来说，使用 GUI 工具包可能不是一个可行的选择，即使存在能够显示 3D 场景的 OpenGL 组件。第三种可能性来了。

3. 直接与屏幕阅读器交谈

一些屏幕阅读器提供 API 来让它们说话、调整某些设置和/或在盲文显示器上显示某些内容。如果您不能或不想使用 GUI 工具包，这可能是一个解决方案。Jaws 附带一个名为 FSAPI、NVDA 的 API 和 NVDA 控制器客户端。Apple 还允许以编程方式控制 VoiceOver 的多个方面。

但仍然存在一些缺点：

• 您专门针对某些屏幕阅读器。使用屏幕阅读器以外的其他工具或其他辅助工具（例如屏幕放大镜）的人都无法使用 luc。或者，您可以为不同平台上的不同产品增加对大量不同 API 的支持。
• 所有这些屏幕阅读器特定的 API 都支持其他人可能不支持的不同内容。这里根本没有标准。

考虑 WCAG 以及如何将其转移到桌面应用程序，实际上您正在绕过大多数最佳实践，这些最佳实践首先建议使用众所周知的标准组件，并且仅在真正必要时进行自定义。因此，当且仅当不可能使用良好的 GUI 工具包，或者所使用的 GUI 工具包的可访问性不够时，才应该理想地使用第三种可能性。

我是 UniversalSpeech 的作者，这是一个小型库，试图统一与多个屏幕阅读器的直接对话。如果您有兴趣的话可以看一下。

4. 屏幕阅读器脚本

如果您的应用程序无法单独访问，您可以将屏幕阅读器特定的脚本分发给用户。可以指示这些脚本获取信息以提供给用户、添加额外的键盘快捷键和其他一些内容。Jaws 有自己的脚本语言，而 NVDA 脚本是用 Python 开发的。据我所知，MacOS 下的 VoiceOver 还具有脚本编写功能。

我向您提供了第四点供您参考，但由于您是从一个完全无法访问的应用程序开始的，所以我不建议您这样做。为了使脚本能够做有用的事情，您必须有一个可用的可访问基础。脚本可以帮助解决小的可访问性问题，但仅使用脚本将完全不可访问的应用程序变成可访问的应用程序几乎是不可能的。此外，您必须将这些脚本与您的应用程序分开分发，并且用户必须安装它们。对于某些人来说这可能会很困难，具体取决于您的目标受众。

超越屏幕阅读器支持

屏幕阅读器支持并不是一切。这超出了你的问题，所以我不会详细介绍，但如果你真的想制作一个易于访问的应用程序，它不仅易于访问，而且对于屏幕阅读器用户来说使用起来也很舒适，你不应该忘记以下几点。这根本不是需要注意的其他事项的详尽列表。

• 键盘导航：大多数盲人和许多视力障碍者对鼠标和/或触摸屏感到不舒服。您必须提供仅通过键盘使用应用程序的完整且一致的方式，或者在移动设备上仅通过屏幕阅读器支持的标准触摸手势来使用您的应用程序。导航应该尽可能简单，并且应该尽可能符合用户偏好和一般操作系统约定（即制表符、空格键、回车键等功能）。这反过来意味着要有良好的组件结构。
• 游戏手柄、运动传感器和其他输入：除非因为这是您的核心概念而绝对强制，否则不要强迫使用它们，并始终允许键盘回退
• 视觉外观：您应该尽可能使用操作系统级别定义的设置/首选项来配置、颜色、对比度、字体、文本大小、深色模式、高对比度模式等，而不是使用您自己的设置/首选项
• 音频：如果用户无法合理地期望任何内容，则不要输出任何内容，确保可以随时轻松更改音量，并且如果可能的话，如果不违反您的核心概念，请始终允许其暂停，恢复、停止和静音。相同的反射可以应用于其他输出，例如振动，您应该始终能够禁用它。