【ITニュース解説】Part 3: Green Builds, Blind Spots: Testing Compose Accessibility Layer by Layer

アクセシビリティ（利用しやすさ）は、アプリ開発において非常に重要な要素だ。全ての人がアプリを快適に使えるようにするための工夫を指し、特に視覚や聴覚、身体機能に障がいを持つ人々にとって不可欠な機能となる。しかし、アクセシビリティの問題は、アプリがクラッシュするわけでも、画面の見た目が変わるわけでも、既存の一般的なテストが失敗するわけでもないため、見過ごされがちだ。通常のテストは画面のピクセルやアプリの動作を確認するが、スクリーンリーダーのような支援技術は「セマンティクスツリー」というアプリの持つ意味構造を読み取るため、それに対応したテストが必要となる。この記事では、Composeを使ったAndroidアプリのアクセシビリティを確実にするために、5つの異なるテストレイヤーを順に適用する方法を解説する。

まず、アクセシビリティのデグレ（機能の劣化）がどのように発生するかを具体的な例で見てみよう。例えば、アプリ内のアイコンボタンを新しい共通コンポーネントに置き換える作業を考えてみる。見た目は変わらず、既存のコードや画面表示、通常の単体テストも問題なくパスする。しかし、三週間後、スクリーンリーダーを使っているユーザーから「共有」「保存」「削除」のボタンが全て「ラベルなし、ボタン」と読み上げられるという報告が届くかもしれない。これは、新しいアイコンボタンにスクリーンリーダーが読み取るべき「意味情報（contentDescription）」が設定されていなかったためだ。このような事態を防ぐには、アクセシビリティ専用のテストが不可欠となる。

アクセシビリティテストの第一歩は、「ターゲットを絞ったセマンティクスのアサーション」を行うことだ。これは、アプリの主要な操作ボタンやカスタムコンポーネントなど、アクセシビリティ上のリスクが高い要素に対して、個別に意味情報が正しく設定されているかを確認する方法だ。Compose UIテストでは、スクリーンリーダーと同じように「セマンティクス」を使ってノード（UI要素）を検索し、その意味情報を検証する。テストコード内で表示される文字列を直接記述せず、アプリ本体と同じようにリソースファイルから文字列を読み込むことが重要だ。これにより、テキストが変更されてもテストが壊れず、多言語対応も容易になる。例えば、保存ボタンであれば「レシピを保存」といった意味情報が正しく設定され、クリック動作が可能であるかを確認する。特に、カスタムの評価スターのようなコンポーネントでは、現在の状態、範囲、操作（例：評価を上げる）がスクリーンリーダーに適切に伝わるかを細かく検証する。これにより、UIの状態変更がスクリーンリーダーに正確に反映されるか、またその操作が期待通りに機能するかを確認できる。

次に、「一括アサーション」というテストレイヤーがある。これは、個別の要素ではなく、特定のグループに属する多数の要素に対してまとめてアクセシビリティ情報を検証する方法だ。例えば、商品一覧のグリッドに表示される全ての画像に、適切な代替テキスト（contentDescription）が設定されているかを確認する際に役立つ。特定のタグを使って要素のグループを選択し、それら全てが「意味のあるcontentDescription」を持っているかを検証するカスタムマッチャーを使う。単に「contentDescriptionが存在するか」だけでなく、「空ではないか」「”画像”や”アイコン”のような一般的なプレースホルダーではないか」といった、より実践的なチェックを行うことで、形だけのアクセシビリティ情報を排除する。この際、テスト対象の要素が実際に存在し、かつその数が期待値を満たしていることを先に確認することが重要だ。また、リストのように一部の要素しか画面に表示されない「遅延レイアウト」では、表示されていない要素をテストするにはスクロール操作をシミュレートする必要がある点に注意が必要だ。

第三のレイヤーは「タッチサイズチェック」だ。これは、ボタンなどの操作可能なUI要素のタッチ領域が、ユーザーが指で簡単に押せる十分な大きさ（推奨は48dp以上）を確保しているかを確認するテストだ。Compose UIテストフレームワークには、要素のタッチ幅とタッチ高が最小要件を満たしているかを検証するアサーションが組み込まれている。UI要素の実際の見た目のサイズと、スクリーンリーダーなどのアクセシビリティサービスに報告されるタッチ領域のサイズが異なる場合があるため、両方のサイズを確認し、より厳格な方を基準に修正することが望ましい。

第四のレイヤーは「自動化されたフレームワークチェック（ATF）」だ。これはGoogleが提供するアクセシビリティテストフレームワークであり、Accessibility Scannerアプリの基盤にもなっている。開発者が明示的にテストケースを記述しなくても、アプリのアクセシビリティツリーに対して多様なルールに基づいて自動的に監査を実行する。Compose 1.8以降では、別途ライブラリを追加することでComposeテストにATFを組み込むことができる。一度有効にすれば、既存のUI操作テスト（例：クリック操作）を実行するたびに自動的にアクセシビリティ監査が実行されるため、追加のコストなしで広範囲なチェックが可能になる。ATFは、ラベルの欠如、小さすぎるタッチターゲット、重複した説明、低いコントラスト、重なり合う要素などを効率的に検出できる。ただし、ラベルの内容が「意味のあるものか」や、読み上げ順序が適切か、カスタムコントロールが本当に操作可能か、といった「意味合い」に関わる部分は判断できないという限界がある。

最後の第五のレイヤーは「手動テスト」だ。自動化されたテストは基本的な問題を網羅的に検出できるが、実際のユーザー体験を評価することはできない。最終的には、人間がアプリを操作し、アクセシビリティの品質を判断する必要がある。これは、リリースごとに短い時間（例えば10分程度）を設け、重要なユーザーフローに絞って実行する。スクリーンリーダー（TalkBackなど）を使って、アプリ内を順にスワイプして「ラベルなし」といった読み上げがないか、意味不明なフレーズがないかを確認する。次に、カスタムコントロールをスクリーンリーダーのジェスチャーやアクションメニューのみで操作し、正しく機能するかを検証する。さらに、エラーメッセージや読み込み状態が発生した際に、それらがスクリーンリーダーに適切に伝えられるかを確認する。最後に、最大フォントサイズやディスプレイサイズを設定し、テキストの途切れやUIの重なりがないかを視覚的に確認する。定期的に、実際にスクリーンリーダーやスイッチアクセスなどの支援技術を日常的に利用しているユーザーに協力を仰ぎ、フィードバックを得ることは、内部テストでは得られない貴重な知見をもたらす。

これらのテストレイヤーは、コストに応じて継続的インテグレーション（CI）環境に組み込むことが推奨される。レイヤー1から3のような高速で実行できるセマンティクスやタッチサイズの検証は、プルリクエストごとに実行する。レイヤー4のATFによる自動監査は、より時間がかかるため、マージ時や夜間ビルドでエミュレーター上で実行する。そして、レイヤー5の手動テストは、リリース前の最終確認として人間が行い、リリースチェックリストで承認する。テストを安定させるためには、アニメーションを無効にし、フォントスケールやロケール、ディスプレイサイズを固定して実行することが重要だ。テストが失敗した場合は、「デグレ（即座に修正してマージをブロック）」「既知の問題（一時的に抑制し、タスクとして管理）」「誤検知（理由をコメントで明確にして抑制）」のいずれかに分類して対応する。自動テストがパスしたからといって、アクセシビリティが保証されたわけではない。手動テストは決して省略できない重要なステップだ。

まとめると、Composeアプリのアクセシビリティテストは、見た目の変化がないデグレを見つけるために、セマンティクスツリーに着目した多層的なアプローチが必要だ。個別の意味検証から、グループでの検証、タッチ領域の確認、自動監査、そして最終的な人間による手動確認まで、それぞれのレイヤーが前のレイヤーでは見つけられない問題を発見し、アプリの利用しやすさを高める。これらのテストを開発ワークフローに組み込むことで、全てのユーザーが快適に利用できる、高品質なアプリを開発できる。