App Store Connectヘルプ
「VoiceOver」のアクセシビリティ評価基準
説明
AppleのVoiceOverスクリーンリーダーを使用すると、ユーザは画面を見ることなくアプリのインターフェイスを操作できます。視覚に障がいのある方やロービジョンの方の多くが、VoiceOverを活用してアプリを理解したりコントロールしたりしています。
目標
障がいがあるかどうかに関係なく、すべてのユーザがアプリを使用できるようにする必要があります。マウスやタッチスクリーンジェスチャーを使ってアプリ内で何かをタップ、クリック、ドラッグできる場合は、VoiceOverでも同様の操作を可能にするよう努めてください。画面に重要な項目が表示される場合は、VoiceOverユーザが音声や点字で認識できるようなラベルや説明をアプリに採用する必要があります。
注: VoiceOverユーザに対するアプリのアクセシビリティを高めるために行う作業の大半は、音声コントロール、スイッチコントロール、ホバーしたテキストの拡大のようなほかの支援技術のユーザに対するアクセシビリティを高めることにもつながります。このため、音声コントロールのテストに進む前に、VoiceOverでのアクセシビリティ評価を開始することをお勧めします。
以下のセクションでは、アプリがVoiceOverに適切に対応しているかどうかを判断する方法について詳しく説明します。目標は、障がいのあるユーザがアプリの一般的なタスクをすべて行えるようにすることです。以下の評価を実施することで、アプリがVoiceOver対応であることをApp Storeで記載すべきかどうかを判断できます。
テストの始め方
このラベルの評価を正確に行うためには、十分に習熟した状態で、アプリが対応しているすべてのデバイスでVoiceOverを使用してアプリのテストを行う必要があります。VoiceOverのテストに習熟するため、ある程度の時間をかけて以下のリソースを確認してください。
-
iPhoneについては、「How to Navigate your iPhone or iPad with VoiceOver」を視聴した上で、「iPhoneでVoiceOverをオンにして練習する」、「iPhoneでVoiceOverジェスチャを使用する」、「VoiceOverがオンのときにiPhoneを操作する」を参照してください。
-
iPadについては、「How to Navigate your iPhone or iPad with VoiceOver」を視聴した上で、「iPadでVoiceOverをオンにして練習する」、「iPadでVoiceOverジェスチャを使用する」、「VoiceOverがオンのときにiPadを操作する」を参照してください。
-
Macについては、「MacでVoiceOverを学習する/練習する」を参照した上で、「macOS用VoiceOverユーザガイド」でその他のトピックを確認してください。
-
Apple TVについては、「Apple TVでVoiceOverを使う」を参照してください。
-
Apple Vision Proについては、「Apple Vision ProでVoiceOverジェスチャを学ぶ」と「Apple Vision ProでVoiceOverをオンにして練習する」を参照してください。
-
Apple Watchについては、「Apple WatchでVoiceOverを使って設定する」を参照してください。
VoiceOverの基本を学んだら、テストを開始しましょう。ただし、ユーザがVoiceOverを使う際により優れた体験を得られるよう、ユーザガイドを詳しく読んで、経験豊富なVoiceOverユーザが利用する可能性のある高度な機能について学んでおくことをお勧めします。
「VoiceOver」への対応の記載
ユーザがVoiceOverのみを使用して視覚的要素(テキスト、メディア、ボタン、コントロールなど)の移動や操作を行える場合、アプリがVoiceOverに対応していることを記載できます。ユーザは、ジェスチャーやキーボードコマンドを使用してUIの各部分にフォーカスを当て、それが何なのかを音声で聞き、有効化することができる必要があります。ユーザが目の見える人の介助なしで、VoiceOverのみを使用してアプリの一般的なタスクすべてを完了できるようにしてください。
すべてのコントロールに簡潔で正確なラベルを付ける必要があります。
ラベルは「代替テキスト」とも呼ばれます。これにより、VoiceOverユーザは、各コントロール要素やインターフェイス要素の目的をすばやく理解できます。
-
ボタン、アイコン、フォームコントロール、その他すべての要素に簡潔なラベルを付け、VoiceOverユーザに同等のテキストを提供する必要があります。インタラクティブなテキストフィールドや類似のフォームコントロールには、選択またはコンテンツのテキスト値(「555-555-1212」など)に加えてラベル(「電話番号」など)を付ける必要があります。
-
ラベルは簡潔にする必要があります。これにより、インターフェイスが冗長になることを避けることができ、ユーザがすばやく移動したり理解したりできるようになります。たとえば、新しいメッセージを作成するためのボタンに付けるラベルは、「新規メッセージを作成するためには、このボタンを押してください」のような冗長なものではなく、「新規メッセージ」にする必要があります。
-
ラベルは、補足説明がなくても理解できるものにしてください。VoiceOverユーザは特定の要素にさまざまな経路でたどり着く可能性があります。そのため、「ここをクリック」や「詳しくはこちら」などのあいまいなラベルは避けてください。なぜなら、ユーザがその項目を直線的ではない順序で閲覧した場合に、意味が不明瞭になるからです。ショッピングカード内の「削除」のように、複数のアクション要素に同じラベルが付けられている場合、ラベルのテキストによってそのアクションの内容を明確にする必要があります。特に取り返しのつかないアクションを行う場合には、十分に留意してください。たとえば、カートのどの項目が削除されるのか明記するなどの対策を行ってください。
-
ラベルには、「チェックボックス」などのコントロールタイプや「チェック済み」などの状態を表すテキストを含めないでください。そうしないと、VoiceOverが「登録を解除するチェックボックス、チェックボックス」のように、ユーザに対して不要な情報を読み上げてしまいます。代わりに、このような情報は、デバイスに適した類似のAPIを介して特性としてアプリに実装してください。
-
ほとんどの画像には、適切な説明か代替テキストを含める必要があります。画像が単に装飾的なものの場合は、VoiceOverによって完全に無視されるようにしてください。
-
画像などのメディアをユーザがアップロードする機能をアプリで提供している場合は、ユーザがユーザ生成コンテンツにラベルや説明を含める方法を確保することで、VoiceOverユーザが当該メディアに出くわしたときにこの説明を音声で聞けるようにしてください。
-
グラフやその他のデータ視覚化には、より具体的なグラフAPIを介してアクセシビリティ情報を含めるか、少なくとも、合理的に十分なテキストによる代替を含める必要があります。
-
アプリの一般的なタスクにおいて、サードパーティまたはユーザが作成したコンテンツが必要な場合は、「アクセシビリティラベルの概要」を参照してサードパーティのコンテンツに関する詳細なガイドをご覧ください。
-
その他のアイデアについては、「優れたアクセシビリティラベルを作成する」や「App内のチャートへのアクセシビリティの導入」を視聴してください。
VoiceOverユーザが要素のタイプ、コントロールのステータスまたは値に気づけるようにする必要があります。
VoiceOverを利用している人は、多くの場合、ラベルやテキストコンテンツだけでなく、より多くの情報を音声で聞く必要があります。なぜなら、ステータスや値は、チェックボックスがオンになっているなど、視覚的な方法でしか伝わらないことがあるためです。このような情報は、デバイスに適した類似のAPIを介して特性としてアプリに実装してください。
-
VoiceOverユーザがある項目にたどり着いたとき、VoiceOverがラベルやテキストコンテンツに加えて要素のタイプも読み上げるようにする必要があります。たとえば、「すべてのメールの登録を解除する、チェックボックス」などです。
-
ユーザがコントロールの状態と値を理解できるようにする必要があります。チェックボックスが「オフ」になっている状態のように、デフォルトの状態は、明示的に書かれないため、VoiceOverによって読み上げられない可能性があることに注意してください。たとえば、「すべてのメールの登録を解除する、チェックボックス」などです。また、コントロールの状態と値に関して、APIを更新するように留意してください。たとえば、ユーザがチェックボックスをオンにしたら、VoiceOverは「すべてのメールの登録を解除する、オンになっているチェックボックス」のように新しい状態を含めて説明するようにします。
アプリ内で表示されるすべてのテキストをVoiceOverが読み上げることができ、テキストの入力方法すべてをVoiceOverユーザが操作できるようにする必要があります。
Appleフレームワークを採用すると、ほとんどの表示テキストのアクセシビリティが自動的にサポートされます。ただし、アプリに別のフレームワークやカスタムのテキスト入力方法を採用している場合は、追加の作業が必要になることがあります。たとえば、AppleにはUnityベースのアプリに対応したオープンソースのアクセシビリティプラグインがあります。
-
アプリ内で表示されるすべてのテキストは、VoiceOverなどの支援技術に対応している必要があります。段落などのプレーンテキスト要素には個別のラベルは必要ありませんが、VoiceOverがそのテキストコンテンツを読み上げられるようにする必要があります。
-
カスタムのキーボードやテキスト入力方法(カスタムキーボードやPINコード入力ウィジェットなど)は、VoiceOverで操作できるようにする必要があります。また、テキストの入力や選択を正確に行えるだけでなく、ユーザに対して正しい音声や点字を出力する必要があります。
-
一時的なステータスバナーや重要なアプリ内アラートが、タイムリーかつ中断のないようにVoiceOverユーザに伝わるようにする必要があります。これは多くの場合、AccessibilityNotificationで実現できます。
VoiceOverのナビゲーションとグループ化が、一貫性があり、完全で、論理的な順序に従うようにする必要があります。
VoiceOverユーザが、VoiceOverローターなどの機能を使って、ページ順に進んだり、画面の特定の部分に直接移動したりできるようにする必要があります。
-
VoiceOverユーザが、ほとんどのプラットフォームで、項目を順番に選択する(右スワイプ、VO + 右など)、またはローターやタッチナビゲーションを使用して、表示されている任意の要素に移動できるようにする必要があります。
-
VoiceOverユーザが、ほとんどのプラットフォームで、次の項目に進む、前の項目に戻る(左スワイプ、VO + 左など)、ローターやタッチナビゲーションを使用して、現在の要素から別の要素に移動できるようにする必要があります。
-
複数の要素やアクションがグループとして提示される場合、VoiceOverユーザが、グループ内の各アイテムに移動したり、カスタムアクションのような機能を介してグループ化された動作(返信、転送、削除など)を使って操作したりできるようにする必要があります。
-
VoiceOverユーザが、項目をスキップしたり、同じ項目を繰り返しループバックしたりすることなく、各要素に進めるようにする必要があります。すべてのコンテンツを順方向に移動した後、すべてのコンテンツを逆方向に移動してみてください。また、すべてのローター項目を順方向と逆方向にループしてみてください。
-
コンテンツがバックグラウンドで再読み込みされた場合や更新されたときに、VoiceOverユーザの読み上げ位置が不用意にリセットされないようにする必要があります。たとえば、VoiceOverユーザの読み上げ位置がコンテンツフィードの一番下付近にいるときに、アプリがコンテンツをさらに読み込んだ場合、VoiceOverのカーソルが意図せずリストの一番上にリセットされることがないようにする必要があります。
-
画面が変化したときやモーダルダイアログが表示されたときに、VoiceOverのカーソルが理にかなった方法で新しいコンテンツエリアに動くようにする必要があります。VoiceOverは、非表示のコンテンツ、オフスクリーンのコンテンツ、背景のコンテンツに移動できないようにする必要があります。
すべてのインタラクティブな要素とコントロールが、VoiceOverを使って発見でき、操作でき、一貫した形で機能するようにする必要があります。
念のために繰り返しますが、マウスやタッチスクリーンジェスチャーを使ってアプリ内で何かをタップ、クリック、ドラッグできる場合は、VoiceOverでも操作できるようにする必要があります。
-
VoiceOverの有効化ジェスチャー(選択してからダブルタップ)とキーボードコマンド(VO + スペース)が、標準的なタップやクリックと同じ動作を引き起こすようにする必要があります。
-
標準的なキーボード操作(矢印キーなど)やキーボードの修飾ショートカットは、VoiceOverがアクティブなときも引き続き機能する必要があります。また、VoiceOverのカーソルが、Tabキーや矢印キーなどの標準的なキーボード操作によって引き起こされる変化に従うようにする必要があります。
-
アプリのコントロールによってコンテキストメニューが提供される場合、長押しがオーバーロードされる場合、その他のデフォルトではない動作が提供される場合は、VoiceOverのアクションローターまたは同等の「コンテキストメニューの表示」キーボードコマンド(VO + Shift + M)を使用して、同じ動作をカスタムアクションとして提供することを検討してください。
-
VoiceOverは、ダイアログのようなモーダルビューに対応している必要があります。モーダルビューの背後にある非アクティブなコンテンツに対して、コンテンツが非アクティブである間は、VoiceOverがアクセスできないようにアプリを開発する必要があります。また、VoiceOverユーザが、エスケープキーやaccessibilityPerformEscapeアクションを使用して、ダイアログを閉じるように、モーダルビューを閉じることができるようにアプリを開発する必要があります。
-
ドラッグ&ドロップやマルチタッチジェスチャーなど、アプリの複雑な動作は、カスタムローターやカスタムアクションなどを介して、アクセスしやすく見つけやすい方法で提供される必要があります。実装の複雑さを緩和するため、可能な限りAppleが提供するネイティブAPIを使用してください。
-
アプリや組み込まれているフレームワークでカスタム要素を使用する場合は、AppleのUIKit、AppKit、SwiftUIフレームワークで提供されるネイティブ要素と同等のアクセシビリティを提供する必要があります。たとえば、カスタムボタン、タブバー、スライダーは、VoiceOverで操作でき、同等の標準APIを使用するコントロールと同等の情報を伝えるようにする必要があります。
アプリの一般的なタスクについてVoiceOver対応であることを記載できるようになった後でも、アプリのアクセシビリティをさらに改善できる場合があります。アプリをアップデートする際は、その都度、アプリがVoiceOverに対応しているかどうかを評価し直すようにしてください。アプリのリリースごとに、アクセシビリティを高め、より多くのユーザがアプリを利用できるようにすることを目指しましょう。
ヒューマンインターフェイスガイドライン > アクセシビリティ
「データリッチなAppにおけるVoiceOver体験の最適化」を視聴する 「カスタムローターを使ったVoiceOverの効率性」を視聴する