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 生成器。

示例

參考