iOSアプリにおけるアクセシビリティの概観メモ
Posted: Updated:
iOS のアクセシビリティ
Android アプリのアクセシビリティガイドライン概観メモ ::ハブろぐ の続きです。前回、iOS のドキュメントをうまく見つけられなかったので Android だけ目を通しましたが iOS も読んでみます。
プログラミングガイド
iOSアクセシビリティプログラミングガイド は、幸い日本語が用意されてるので読みやすくて安心です。英語版は PDF でありませんが Accessibility Programming Guide for iOS と About Accessibility Verification on iOS に相当するものと思われます。
なお、英語の情報は Accessibility on iOS - Apple Developer に動画なども合わせてまとまっています。
Apple いわくアクセシビリティは正義
最初に目についたのは「なぜアプリケーションをアクセシブルにする必要があるのか」という項目でした。
以下の理由からiPhoneアプリケーションをVoiceOverユーザにとってアクセシブルにする必要があります。
- ユーザ層を拡大する。懸命に努力してすばらしいアプリケーションを作成したのです。より多くのユーザにアプリケーションを利用してもらうチャンスを逃さないでください。
- 画面を見ることなくユーザがアプリケーションを使用できるようにする。視覚障害者の方でもVoiceOverの支援によりアプリケーションを使用することができます。
- アクセシビリティガイドラインへの対応に役立つ。さまざまな政府機関がアクセシビリティのガイドラインを作成しており、iPhoneアプリケーションをVoiceOverユーザにとってアクセシブルにすることは、これらのガイドラインへの適合に役立ちます。
- 正しいことである。 iOSアクセシビリティプログラミングガイド
上から順にふんふんと読み進めた果てに 正しいことである の断言。英語では It's the right thing to do と書かれていました。この姿勢がアクセシビリティのブランディングを一部で敗北せしめた根源では...？という気がしなくもありませんが、それは別の機会に述べるとして Apple さまがおっしゃるならジャスティスです。
UI Accessibilityプログラミングインターフェイス
UIKit の上に UI Accessibility API のアクセシビリティ属性を提供し、VoiceOver がそれらを解釈することで UI はアクセシブルなものになります。主たる属性は次の5つです。
- Label - UI のラベル
- Traits - 要素の状態を示す 0〜n 個の定数指定 ( ボタン、テキストフィールド、選択中など )
- Hint - 必要に応じて設定するコントロールの短文ヒント
- Frame - 要素の画面位置とサイズを
CGRectで表す座標情報 - Value - コントロール可能な UI が示す現在の値 ( Web ならaria-valuenow )
Label と Frame が必須で、Traits や Hint、Value は必要に応じて提供されます。Frame を自分が書くコード内で更新しつづけるのはしんどそうですが、UIViewから派生したオブジェクトはデフォルトでFrame属性を含んでいるそうです。Frame が必須なのは、タップ位置に応じてそこに存在するアクセシビリティ情報を引き出すためでしょうか。
カスタムコンテナビューの内容をアクセシブルにする
ちょっと凝ったコンテナ的ビューの中にアクセスできないな、というケースはこれが適切に実装されていないケースかもしれません。
アプリケーションで、ユーザがやり取りする要素をほかに含んでいるカスタムビューを表示する場合、含まれている要素を個別にアクセシブルにする必要があります。同時に、コンテナビュー自体はアクセシブルではないことを確認する必要があります。なぜならユーザは、コンテナの中身の要素とやり取りするのであって、コンテナ自身とやり取りするわけではないからです。 これを行うには、カスタムコンテナビューにUIAccessibilityContainerプロトコルを実装する必要があります。このプロトコルは、含まれる要素を配列で入手できるようにするメソッドを定義しています。
たとえば某動画アプリの番組表は時間帯 × チャンネルの広大な表示エリアをドラッグして移動する UI ですが、その中にある個々の番組情報セルは VoiceOver を有効にした状態で読み上げることができませんでした。コンテナが中の要素の情報も責任をもって提供することが必要と考えられます。
ラベルやヒント作成のためのガイドライン
Web でもそうですが、UI コンポーネントが本来もっている読み上げ可能な情報との干渉を考慮しつつ、適度なテキスト情報を付与するには思ったよりも配慮が必要です。iOS の実装ガイドラインにはラベリングに関するアドバイスがあり、次のリストはラベルテキストに関するアドバイスです。
- 要素を非常に簡潔に説明している
- コントロールやビューのタイプを含まない（Traits から取得するので不要）
- 先頭の単語が大文字で始まる（英語の場合、抑揚の制御のため）
- ピリオドを付けない（文章ではない）
- ローカライズされている
次のリストはヒントテキストに関するアドバイスです。
- 結果を非常に簡潔に説明する
- 動詞で始め、主語を省略する
- 先頭が大文字の単語で始まり、ピリオドで終了する（英語の場合、抑揚の制御のため）
- アクションやジェスチャの名前を含まない（ジェスチャに依存するべきでない）
- コントロールやビューの名前を含まない（Label から取得するので不要）
- コントロールやビューのタイプを含まない（Traits から取得するので不要）
- ローカライズされている
個々が慎重にテストして実装すれば自然と満たせそうなルールではありますが、予め明文化されている点が参考になります。
Traits ( 特性 ) の指定
インターフェイスの Traits ( 特性 ) は次のような選択肢が用意されてあります。たとえばタップすると特定の URL を開く画像は、Image であり、Link でもあります。Traits の候補で説明可能な特性は、Traits として情報をべきで示すべきありラベルやヒントと重複するべきではありません。
- Button
- Link
- Search Field
- Keyboard Key
- Static Text
- Image
- Plays Sound
- Selected
- Summary Element
- Updates Frequently
- Not Enabled
- None
これらの特性を結合することで、UI 上の特性を VoiceOver にとっても明らかなものにしていきます。読み上げだけ考えると、柔軟に正しいテキスト情報をつければ特性とかいらんのでは？という気もしますがメタ情報として利用するには、こういう既定の区分が役に立つのでしょう。
アクセシビリティの検証
iOS アプリのアクセシビリティは、Accessibility Inspector で UI が適切なアクセシビリティ情報を提供できているか、VoiceOver による操作に不自由がないか、これら2つの観点で検証されます。最終的な使い勝手は、機械的にチェックするにも限界があるため、Android でもそうでしたが最後は自分で実際に支援技術をつかってアプリを動かしテストしましょう、という話に落ち着きます。
Accessibility Inspector によるアクセシビリティ属性の検証
Accessibility Inspector は iOS Simulator 上で実行可能なツールです。Web でいえば Chrome の Accessibility Developer Tools - Chrome Web Store における Accessibility Properties のように選択した UI がもつアクセシビリティ属性を表示します。個々の UI が適切なアクセシビリティ属性を提供しているかをチェックします。
VoiceOver によるテスト
そして VoiceOver で実際に操作できるか、テキスト情報が過不足なく適切に読み上げられるかを実際にテストします。自分が関わっているアプリを試したときは、VoiceOver を有効にして UI がナビゲーション可能なのか、読み上げ可能なのか試していました。ジェスチャのルールもかなり変わるので、アクセシビリティとか関係なく、操作の違いに面食らいます。
デザイン面のガイドライン
ここまで実装ガイドラインを見てきましたが、デザイン面についてはお馴染みの iOSヒューマンインターフェイスガイドライン: UI設計の基本事項 が実質的にデザイン面のアクセシビリティガイドラインの役割を果たしているような印象です。たとえば 色とタイポグラフィ を見てみると次のような記述があることに気づきます。
さまざまな状況を考慮し、色のコントラストに注意する。たとえば、ナビゲーションバーの背景とバーボタンのラベル部分のコントラスト（明暗比）に注意しないと、ラベルが読みにくくなってしまいます。コントラストが充分かどうか検証するためには、科学的とは言えませんが、晴れた日の屋外などさまざまな光源状況で、実際にデバイスにアプリケーションを表示してみる、という方法が簡単でしょう。 この方法は、手直しが必要な箇所を見極める上でも参考になりますが、これで代えるわけにはいかない、より実証的で信頼できる結果が得られる手法もあります。前景色と背景色の輝度を測定し、その比を調べるのです。オンラインのコントラスト比計算機を使うか、WCAG 2.0規格として確立されている式を使って、自分で計算してください。4.5:1以上の比であれば理想的です。
そのほかにも既知のとおり、ナビゲーションの構造やタップエリアのサイズなどユーザビリティ〜アクセシビリティにまたがる品質要求が延々と記述されているヒューマンインターフェースガイドラインは包括的なドキュメントになっていると捉えられます。
所感
以上、こんなところでした。
Apple 的には アクセシビリティ - iOS - Apple（日本） や iOS - アクセシビリティ。使い方のヒントとコツ。 - Apple（日本）を見ても分かるとおり、アクセシビリティ対応を訴求していますし、OS の機能としては当然のように配慮されています。だいぶ前ですが、Android よりも iOS のほうが、OS の提供するアクセシビリティ機能が高いという話も見かけた気がします。（もちろん今は Android も大きく改善しているのかもしれませんが、判別つくほど使えてないです）
しかしながら、OS の標準機能や標準アプリがいくらアクセシブルであっても、実際にユーザが大半の時間を投じるのは世界中のディベロッパーが提供する AppStore に並んだアプリたちです。これらが以降で紹介するようなポイントを抑えていなければ、アクセシブルな体験は得られません。
が、別にアクセシブルじゃなくても AppStore の審査には通ってリリースできるので、実際のところ開発者の努力次第といったところのように思います。
