モバイルアプリケーションでのアクセシビリティ（アクセシビリティ）の実装についてです。
簡単な背景
最近、Accessible Lifeプロジェクトを代表して、Yandexのナビゲーションアプリケーションのアクセシビリティの実装を支援し始めました。
私の視点からは、思い浮かぶことのない多くのことが明白であるという事実に直面しました。画面上の不可視要素、スクリーンリーダーAPIを使用した音声メッセージの直接出力などです。
したがって、私はこれらすべてを別の記事で述べることにしました。
一般的に行きましょう。
目に見えないアイテム
問題
マップの作業中に問題が発生しました：
地図のある画面の領域をクリックすると、アプリケーションはモードを切り替える必要があります（詳細は確かに覚えていません）。
スクリーンアクセスプログラムを使用する盲目のユーザーにとって、この一見単純なアクションは不可能になります。
実際のところ、画面アクセスプログラムは、画面上の特定のオブジェクト（ボタン、テキストブロック、入力フィールド、コントロール、リスト）のみを「参照」します。 また、Yandex.Mapsアプリケーションでは、マップのクリックはオブジェクトの選択としてではなく、画面の特定の領域のタッチとして処理されました。
解決策
解決策は非常に簡単です：フレームなし、透明な背景、表示テキストなしのボタンを画面上に作成する（ゼロフォント、プログラマーの観点からはあまり美しくない、または画面に表示せずに画面アクセスプログラム専用のテキストを表示する特別な属性）。
このアプローチはプログラマーに衝撃を与え驚かせましたが、実際にはすべてがうまくいき、アイデアはうまくいき、画面領域での直接クリックを処理する必要がある場所に積極的に導入されています。
スクリーンアクセスプログラム自体を使用した音声メッセージの直接出力
問題
もう1つの問題は、盲目のユーザーだけに追加情報を表示する必要がある場合があることです。 この場合のポップアップメッセージはデザインを台無しにし、他のメッセージに干渉します。また、そのようなメッセージが表示される別のアプリケーションモードを実装するのは面倒で非論理的です。
解決策
解決策は、目に見えないボタンほど明白ではありませんが、表面にあります。
メッセージを表示するには、スクリーンアクセスプログラム自体のAPIを使用する必要があります。 プログラムコードではかさばらず、別のモードや追加の設定などを作成するために開発者に追加の努力を強いることはありません。
ちなみに、スクリーンリーダーAPIを使用している場合は、有効になっているかどうかを確認する必要さえありません。 プログラムが実行されている場合、ユーザーが選択した音声合成装置を使用してメッセージを表示します。 そして、プログラムがオフになっている場合、何も起こりませんし、平均的なユーザーは何にも気付かないでしょう。
共有！
問題
これはライフハックというよりも推奨事項ですが、これについて言及する必要があります。
画面アクセスプログラムの画面上にはオブジェクトのみが存在することを覚えていますか？
したがって、オブジェクトのタイプも重要です。 彼女の意見では、テキストをクリックすることはできませんが、ボタンをコピーすることはできません。 つまり、設定テーブルが、それ自体のさまざまな部分をクリックする「キャッチ」する大きなテキストブロックとして実装されている場合、そのようなテーブルは画面アクセスプログラムで使用できません。 読み取られますが、相互作用は許可されません。
解決策
解決策は非常に簡単です。目的どおりに要素を使用します。
リストにする必要がある場合は、コード内でリストを記述する要素を使用する必要があります。
ボタンの場合、ボタンでなければなりません。 スライダー、何かのレギュレーターである場合、スライダーの要素であり、ドラッグ時のアニメーション付きのテキストではありません。
おわりに
結論として、Windowsの開発は必須ではありませんが、モバイルプラットフォームの開発とは異なるため、Windowsのアクセシビリティ機能はAndroid / Iosの機能とは異なります。