Accessibility Scannerアプリケーションは、その使用に特別な技術スキルを必要としません。特に、問題のあるインターフェイスに関するレポートを生成して開発者に送信できる一般の人々が使用することをお勧めします。 つまり、近い将来、多くのAndroid開発者は、そのような標準化された形式でアプリケーションのアクセシビリティの問題の説明を受け取り始める可能性があります。 ユーザーは、Accessibility Scannerの正確な意味を理解するだけで済みます。
技術的な観点から見ると、アクセシビリティスキャナーはいわゆるアクセシビリティサービス、つまり、バックグラウンドで動作し、障害のあるユーザー向けの追加機能を実装するためにアクセシビリティAPI OS Androidと対話するアプリケーションです。 アクセシビリティスキャナーをインストールしたら、「特別」セクションを開く必要があります。 デバイスの設定で（アクセシビリティ）を選択し、その中でアクセシビリティスキャナーを見つけてサービスを有効にし、必要な権限を付与します。 その後、アクセシビリティスキャナーボタンが画面に表示され、インターフェイス全体の上部に表示されます。
テストするインターフェイスを開いたら、このボタンをクリックします。その後、サービスは見つかったすべての問題を順番に説明し、修正するためのオプションを提供します。 1つのリストで見つかったすべての問題を表示し、受信したレポートを電子メールで送信することもできます。
レポートには、およそ次の推奨事項が含まれる場合があります。
テキストのコントラスト
com.habrahabr.example：id / label
アイテムのテキストコントラスト比は2.46です。 この比率は、推定前景色＃999999および推定背景色#EEEEEEに基づいています。 このアイテムのテキストコントラスト比を3.00以上に上げることを検討してください。
ここではすべてが明白です。開発者はテキストと背景色のコントラストを上げる必要があります。 アクセシビリティスキャナーは、少なくとも3の大きなテキストと、少なくとも4.5の大きなテキストにコントラスト比を提供することをお勧めします。 これは、平均レベルのAAコンプライアンスを備えたW3C WCAG 2.0標準に他なりません。
ただし、開発者がアクセシビリティの程度を高めたい場合は、最高レベルのAAAコンプライアンスのために、より厳しい要件を使用できます。 この場合、大きなテキストのコントラスト比は少なくとも4.5で、小さなテキストのコントラスト比は少なくとも7でなければなりません。
コントラスト比の計算方法を詳しく調べたい場合は、このテキストをクリックして、ネタバレの下の対応するフットクロスを読むことができます。
コントラスト比（CR）は、次の式を使用して計算されます。
CR =（L1 + 0.05）/（L2 + 0.05）
どこで
L1は最も明るい色の相対的な明るさです。
L2は、最も暗い色の相対的な明るさです。
sRGB色空間では、相対的な色の明るさ（L）は次の式で計算されます。
L = 0.2126 * R + 0.7152 * G + 0.0722 * B
どこで
RsRGB <= 0.03928の場合、R = RsRGB / 12.92、それ以外の場合R =（（RsRGB + 0.055）/ 1.055）^ 2.4;
GsRGB <= 0.03928の場合、G = GsRGB / 12.92、それ以外の場合G =（（GsRGB + 0.055）/ 1,055）^ 2.4;
BsRGB <= 0.03928の場合、B = BsRGB / 12.92、それ以外の場合B =（（BsRGB + 0.055）/ 1,055）^ 2.4。
RsRGB、GsRGB、BsRGBは次のように定義されます。
RsRGB = R 8ビット/ 255;
GsRGB = G 8ビット/ 255;
BsRGB = B 8ビット/ 255。
その結果、コントラスト係数の値は[1; 21]。ここで、1は最小コントラスト、たとえば白地に白、21は最大値、たとえば白地に黒です。
CR =（L1 + 0.05）/（L2 + 0.05）
どこで
L1は最も明るい色の相対的な明るさです。
L2は、最も暗い色の相対的な明るさです。
sRGB色空間では、相対的な色の明るさ（L）は次の式で計算されます。
L = 0.2126 * R + 0.7152 * G + 0.0722 * B
どこで
RsRGB <= 0.03928の場合、R = RsRGB / 12.92、それ以外の場合R =（（RsRGB + 0.055）/ 1.055）^ 2.4;
GsRGB <= 0.03928の場合、G = GsRGB / 12.92、それ以外の場合G =（（GsRGB + 0.055）/ 1,055）^ 2.4;
BsRGB <= 0.03928の場合、B = BsRGB / 12.92、それ以外の場合B =（（BsRGB + 0.055）/ 1,055）^ 2.4。
RsRGB、GsRGB、BsRGBは次のように定義されます。
RsRGB = R 8ビット/ 255;
GsRGB = G 8ビット/ 255;
BsRGB = B 8ビット/ 255。
その結果、コントラスト係数の値は[1; 21]。ここで、1は最小コントラスト、たとえば白地に白、21は最大値、たとえば白地に黒です。
アイテムラベル
com.habrahabr.example：id / button
このアイテムには、スクリーンリーダーで読み取り可能なラベルがない場合があります。
ここで、Googleの開発者は少し怠け者でした。そのようなコメントが、準備のできていない開発者にとって十分な情報になるとは考えにくいからです。 ただし、すべてが非常に簡単です。 つまり、コントロールにはグラフィカルな表現しかなく、テキストラベルはありません。 したがって、視覚ではなくスクリーンリーダーを使用してインターフェイスを操作するユーザーには、「ショートカットなしのボタン25」のような音声が聞こえます。
この問題を修正するには、android：contentDescription属性で各テキストラベルコントロールに署名する必要があります。
<Button android:id="@+id/button" android:src="@drawable/button" android:contentDescription="@string/button"/>
android：contentDescription属性の値は視覚的に表示されないことに注意してください。 これはスクリーンリーダーを対象としており、このコントロールに焦点を合わせたときに読み上げられます。 つまり、画面に合わせてテキストの長さを何らかの形で最適化する必要はありません。 ただし、android：contentDescriptionは本格的な文字列リソースであるため、ローカライズする必要もあります。 それがstrings.xmlで取り出され、他のすべてと一緒に翻訳されるべきである理由です。
また、上記のように、スクリーンリーダーは要素のタイプに関する必要なすべてのメタデータを個別に決定するため、テキストラベルでこの情報を複製する必要はありません。 つまり、「キャンセル」ボタンを書くべきではなく、「キャンセル」だけで十分です。
Android開発者がAccessibility Scannerを使用してアプリケーションのインターフェイスをテストし、見つかった基本的なアクセシビリティの問題を修正するためにもう少し時間を費やすと、視覚的な制限があるユーザーにとって製品がより使いやすくなります。 場合によっては、このような自動監査とそれに対応する一般的な修正により、アプリケーションの完全な可用性を確保できます。 ただし、より複雑な場合は、アクセシビリティスキャナーだけに頼るのではなく、可能であれば、実際のユーザーの関与を含め、手動でインターフェイスの可用性をテストしてください。 アクセシビリティスキャナーの開発者自身は、サービスの説明でこれについて警告しています。「アクセシビリティスキャナーは、手動テストに代わるものではなく、アプリのアクセシビリティを保証するものでもありません。」
残念ながら、Google自体のアプリケーションは、アクセシビリティスキャナーを介して常にテストに合格することはできないことを認めなければなりません。これは、感覚器官の木材の丸い品揃えを思い出させます。
最後にもう一度、記事の冒頭でクリックしなかった人のためのPlayストアへのリンク。