Android アプリのアクセシビリティガイドライン概観メモ
Posted: Updated:
ネイティブアプリとアクセシビリティの関係
Web が専門ではありますが、アクセシビリティを通した品質向上を考え始めると、Web だけでは社内のプロダクトの半分あるいはそれ以下程度のカバレッジしかありません。
そこで今回はネイティブアプリ、特に Android のガイドラインについて目を通したメモ。
プラットフォームのガイドライン
ネイティブアプリの筆頭たる iOS と Android においては、WCAG 2.0 ほどは詳細化されてこそいないものの、各プラットフォームでガイドラインが提供されています。
とはいえ、この2つ見比べてみると iOS のドキュメントはそれほど充実していないような印象です。どうも Apple の開発ドキュメント漁るの苦手なんですよね...。
Android のアクセシビリティドキュメント
発見できた iOS のドキュメントがイマイチ貧相なので、今回は Android のアクセシビリティに関するドキュメントを読み進めていきます。
実装のガイドラインは Web と大差ない
Developing Accessible Applications | Android Developers によれば、アクセシブルなアプリケーションを開発するためのポイントとして、次の4点が挙げられています。
android:contentDescriptionを設定すること- フォーカスありきのナビゲーションをデザインすること
- アクセシビリティイベントを発生させること
- アプリケーションをテストすること
マシンリーダブルなテキスト情報を付与して、キーボード操作と同様にフォーカスを前提のナビゲーションに対応した UI 設計になっていて、WAI-ARIA のように UI の変化を支援技術が捉えられるようにし、ちゃんとテストしろよ、という話でした。
予想はしていましたが、基本的な考え方は Web となんら変わりありません。WCAG 2.0 には認知しやすく一貫性のあるナビゲーションや、目に優しいコントラストなど他にも多彩な項目がありますが、こと「実装」にのみフォーカスしてしまえば、このあたりの話が主となるはずです。
デザインのガイドラインも Web と大差ない
実装上のポイントを前述しましたが、Accessibility | Android Developers はデザインガイドラインの立場からアクセシビリティに触れています。
- 直感的に分かるナビゲーションにする
- タッチ可能な領域を十分なサイズにする
- ビジュアル的な UI （アイコンとか）に意味のあるラベリングをする
- タイムアウトに依存する機能の代替手段のアフォーダンスを提供する（？）
- 標準のコントロールを使うか、カスタムコントロールを Talkback に対応させる
- 自分でちゃんと試してみる
実装ガイドラインと内容が重複してそうな項目もありますが、マシンリーダビリティとナビゲーションの整理、そして自分でちゃんとテストするのが大事だよ、という趣です。 なお、？が付いてるのは言いたいことは分かるが適切な訳ができなかったやつです。
Material Design としても Accessibility - Usability - Google design guidelines にドキュメントが用意されています。Material Design ドキュメントの特徴でもありますが、こちらのほうがより具体的な事柄（色、レイアウトなど）について、アクセシビリティの観点から望ましい対応が明示されています。
Android の実装チェックリストにおける最低＆推奨要件
最後に Accessibility Testing Checklist から、アクセシビリティの最低要件と推奨要件のチェックリストを見てみました。開発者（実装者）向けのドキュメントとして提供されている為、デザイン面のチェック項目はありません。
最低要件
総じて「Talkback が有効な状態でアプリを利用できる」というのを満たすための要件が並んでいます。
- タッチスクリーンを使わなくてもキーボード等のみで主要な操作が可能であること
- Talkback が読み上げるためのディスクリプションを提供できていること
- タッチ可能なコントロールを発見するための情報を提供できていること
- タッチ可能なコントロールであるために 48 dp以上の大きさであること
- Talkback が有効なときでもジェスチャ操作できる、または代替手段が提供されていること
- 音声のみでフィードバックしている箇所をつくらないこと
わりと簡潔な要件にですが、これらが大体守られていればアクセシブルなアプリケーションを提供できていると考えて良さそうです。
推奨要件
推奨要件は Talkback による読み上げ時に、音声として読み上げられるにふさわしいテキスト情報が提供されることを主に求めています。
- 同じ音声読み上げ情報が、無意味に繰り返されないこと
- あるコントロールに関連する音声読み上げ情報に過多・過小がないこと
雑な理解ですが、前者は alt 属性と caption 的な要素のテキストが重複して指定されている状態と類似していると捉えられます。後者は、フォームコントロールの周辺説明が長すぎたり音声ですべて読み上げると冗長になるような状態と同じでしょう。
アプリの場合のアクセシビリティ
以上のようなアプリに関連するアクセシビリティのドキュメントに目を通しつつ、実際に VoiceOver や Talkback を有効にしていくつかのアプリを触ってみたところ、次のような所感を得ました。
- HTML のようなテキスト実装に根ざしていないので、UI を説明する属性値の付与が必須
- VoiceOver/Talkback のような支援技術が読み取るのは、とにかくテキスト
- マシンリーダブルな付加情報を HTML よりも意識して加える必要がありそう
- ジェスチャーやナビゲーションのルールが変わるのでその対応も必要
- Web サイトと違って無尽蔵にページや実装が増殖するわけではないので、要所は抑えやすそう
- iOS アプリよりも Android アプリのほうがノーガードな実装でもマシになりやすいぽい？
今回の所感を参考に、社内の品質管理プロセスでどうこうできるところがないか調整してみようかと思います。
おわり
今回眺めたのはプラットフォームのガイドラインでしたが、これらネイティブアプリのアクセシビリティに関する具体的な実装情報は、少なくとも日本語圏だとあまり出回っていないようです。
Web アクセシビリティといえば Web Content Accessibility Guidelines (WCAG) 2.0 をはじめとして、W3C が提供する豊富な資料に加え、界隈のノウハウは十分すぎるほど出回っています。それでも、Techniques for WCAG 2.0 を凝視したくなるシーンがあるように、現実を前にしてどのような実装を施すべきか判断に迷うことが多々あります。
自分が知ってる市井のガイドラインだと BBC Mobile Accessibility Prototype : Developers が最も有力なように思います。各項目について、考え方とどのように実装すればよいのかという具体的な指針が Android、iOS、HTML の3種類にわたって紹介されているので参考になります。
このようなガイドラインや実戦的な情報について、もうちょい情報収集せねばと思いを新たにするのでありました。 Talkback と VoiceOver の使いこなしも出来ていないので、次回はそのへん調べ直して書こうかな...。
