スクリーンリーダー

グラフィカルユーザーインターフェース（GUI ）の登場により、状況はより複雑になった。GUIでは、文字やグラフィックが画面上の特定の位置に描画されるため、ディスプレイのグラフィックコンテンツを純粋にテキストで表現することはできない。そのため、スクリーンリーダーは、オペレーティングシステムからメッセージを収集し、それらを使用して「オフスクリーンモデル」、つまり必要なテキストコンテンツが格納されているディスプレイの表現を構築するという、新しい低レベルの技術を採用せざるを得なくなった。^{[ 14 ]}

例えば、オペレーティングシステムはコマンドボタンとそのキャプションを描画するためのメッセージを送信する場合があります。これらのメッセージは傍受され、オフスクリーンモデルの構築に使用されます。ユーザーは画面上で使用可能なコントロール（ボタンなど）を切り替えることができ、キャプションとコントロールの内容は音声で読み上げられたり、リフレッシュ可能な点字ディスプレイに表示されたりします。

スクリーンリーダーは、メニュー、コントロール、その他の視覚的な構成要素に関する情報を伝えることで、視覚障害のあるユーザーがこれらの構成要素を操作できるようにすることもできます。しかし、画面外モデルを維持することは技術的に大きな課題であり、低レベルのメッセージをフックすることと正確なモデルを維持することはどちらも困難な作業です。

オペレーティングシステムとアプリケーションの設計者は、スクリーンリーダーがオフスクリーンモデルを維持することなくディスプレイコンテンツにアクセスできるようにすることで、これらの問題に対処しようとしてきました。これには、API を介してアクセスできる、画面に表示されている内容の代替的でアクセシブルな表現の提供が含まれます。既存のAPIには、次のものがあります。

• Androidアクセシビリティフレームワーク^{[ 15 ]}
• AppleアクセシビリティAPI ^{[ 16 ]}
• AT-SPI
• IAccessible2
• Microsoft Active Accessibility ( MSAA )
• Microsoft UI オートメーション
• Javaアクセスブリッジ^{[ 17 ]}

スクリーンリーダーは、オペレーティングシステムやアプリケーションに現在表示されている内容を問い合わせ、表示内容が変更されたときに更新情報を受け取ることができます。たとえば、スクリーンリーダーは、現在フォーカスがボタンにあること、そしてそのボタンのキャプションをユーザーに伝える必要があることを知ることができます。この方法はスクリーンリーダーの開発者にとって非常に簡単ですが、アプリケーションがアクセシビリティAPIに準拠していない場合は機能しません。アクセシビリティAPIが不十分な場合の1つのアプローチは、利用可能なオペレーティングシステムメッセージとアプリケーションオブジェクトモデルを使用してアクセシビリティAPIを補完することです。

スクリーンリーダーは、本質的にアクセス不可能なコンテンツを除き、すべての表示コンテンツにアクセスできると想定されます。ウェブブラウザ、ワープロソフト、アイコンやウィンドウ、メールプログラムなどは、スクリーンリーダーユーザーが問題なく使用しているアプリケーションのほんの一例です。しかし、一部のユーザーによると、スクリーンリーダーの使用はGUIの使用よりもはるかに難しく、多くのアプリケーションは、アプリケーションの性質（アニメーションなど）やプラットフォームのアクセシビリティ基準への不準拠に起因する特有の問題を抱えています。