Aros/开发者/文档/设备/朗读器

从理论上讲，方法是为 IntuiText 设置函数，但这只是一个理论... 我认为这会很混乱，因为输出最终会变得非常混乱，或者你需要做很多工作来重建它们在屏幕上放置的顺序，以确保它有意义。但我认为这是我们无法获得更多上下文的情况下出现的“最坏情况”。最大的挑战是弄清楚如何让应用程序以一种体面的方式让屏幕阅读器访问文本内容，以及如何决定要阅读什么。你对其他平台的辅助功能 API 有任何了解吗？嗯，是的，通常可以检查窗口，如果其中一个窗口位于顶部，并且如果点位于该窗口内，或者如果该窗口不在顶部，如果该窗口在该部分可见。

Emacs 可以 100% 通过键盘操作，我知道有盲人开发者使用 Emacspeak 操作它。在 Windows 上，我通常使用 TextPad - 它非常易于访问，虽然我在有视力时在 Amiga 上工作时使用过 GoldEd。

通常需要创建几个屏幕外模型...

屏幕上所有属于任何窗口的文本 - IntuiText 捕获在这里对我来说很好。
特定控件中的文本，例如按钮、列表等。这应该针对任何类型的 GUI 生成接口单独完成，例如 GadTools、ReAction\ClassAct、MUI、BGUI 等等。我认为我们可以做得更好，通过添加一个 API 供应用程序提供有关它们自己的 API 的更多结构化语义信息，但我认为从挂钩到我们所拥有的内容开始，看看需要改进什么才能使其可用将是一个不错的开始。这个想法真的很棒，但我希望了解是否可以不破坏 AmigaOS API - 也许可以为 AmigaOS 制作一个屏幕阅读器，而无需修改它...

毫无疑问，对于 GadTools 和 MUI，可以简单地设置函数并获取内部信息，但我对 ReAction 和 BGUI 的内部结构并不熟悉。也许从我使用 AmigaOS 的时候起就出现了新的接口...

许多应用程序不支持在控件之间使用标准的 Tab 键操作 - 我认为这将是一个真正的问题，也是一个非常难修复的事情。

如果有时间，我很乐意查看一个简单的兼容 FLite 的 narrator.device 包装器。FLite 是基于声道的，与原始 narrator.device 相似，因此应该可以实现一些相同的参数类型（设置音调等以获得不同的声音）... 限制因素是时间。或者，如果您或其他人有时间查看它，我很乐意提供帮助。实际上，我已经在 AROS 下编译了它（带有 wav 文件输出的命令行，而不是直接到音频），但我需要弄清楚一些错误，因为我无法在任何地方播放生成的 wav 文件... 希望这是一个简单的错误 - 一旦 wav 输出工作，那么从它创建一个设备应该相对简单。

屏幕阅读器 API 最好作为一个单独的库创建，可以提供给需要它的应用程序。AmigaOS 版本可以依赖于 SetFunction() 等来访问必要的其他库，而在 AROS 中，在正确集成它方面会有更大的灵活性。你可以通过通用方法支持旧应用程序，但仍然可以为新应用程序添加一个 API 来提供更多信息以使其工作得更好。

Windows 屏幕阅读器通常依赖于 Windows 应用程序中的键盘和 Tab 键顺序，但 iOS 屏幕阅读器 VoiceOver 的工作方式完全不同 - 它会在你将手指悬停在其上时宣布你可以操作的底层对象，并且当你在继续按住手指悬停在对象上的同时双击屏幕的另一部分时，该对象就会被激活。这两种方法都可以在这里结合起来，如果应用程序允许使用 Tab 键顺序，则可以使用更高效的 Windows 方法，但如果不是，则可以将鼠标悬停在屏幕上或将手指悬停在触控板上并以 VoiceOver 方式操作。

嗯，我有以下想法

一个名为 Accessibility.library 的特殊库由我开发。
此库的结构与 datatypes.library 非常相似，例如，它具有 MUI.accessibility、BGUI.accessibility 等等模块，它们爬行到适当的 GUI 模块内部，获取所有必要的内部信息，并将其提供给中央模块 - accessibility.library。
最终的应用程序不需要考虑差异，只需拥有与库的标准接口。
GUI 开发者可以开发相应的模块，如果他们愿意，可以支持他们的 GUI 生成器。

示例

参考