モバイルアクセシビリティ：WCAG 2.0やその他W3C/WAIのガイドラインのモバイルへの適用

https://www.w3.org/TR/mobile-accessibility-mapping/ の抄訳。Please use it at your own risk.

なお、Editor's Draft http://w3c.github.io/Mobile-A11y-TF-Note/ により新しい版があります。内容に大きな差はありませんが、章番号がWCAG2.0と一致させてあったり、1.4 Non-Linear Screen Layoutsが追加になったりしているので、スキを見てまた訳出します。

---

W3Cの最初の公開ワーキングドラフト 2015年2月26日

（省略。概要、ドキュメントのステータス、目次。のちに訳出予定）

要旨

このドキュメント「モバイルアクセシビリティ：WCAG 2.0やその他W3C/WAIのガイドラインのモバイルへの適用」では、WCAG2.0とその原則、ガイドライン、および成功基準を、モバイルウェブコンテンツ、モバイルウェブアプリ、ネイティブアプリ、およびネイティブアプリ内部でWebコンポーネントを使用するハイブリッドアプリに適用する方法を説明します。

1.はじめに

（省略。文書の位置付け。のちに訳出予定）

1.1 WCAG 2.0およびモバイルコンテンツ/アプリケーション

「モバイル」とは、屋外を含めた多種多様な場面で持ち運びや使用が容易なワイヤレスデバイスやアプリケーションの総称です。モバイルデバイスとは、小型のハンドヘルドデバイス（例えば、フィーチャーフォン、スマートフォン）から、幾分大きいタブレットデバイスの範囲を指します。また、この用語はスマートグラス、スマートウォッチ、フィットネスバンドといった「ウェアラブル」などや、車のダッシュボード、飛行機のシートバック、および家電製品の中に埋め込まれているような他の小型のコンピューティングデバイスにも関連しています。

モバイルは、デスクトップ/ラップトップといったカテゴリから独立して扱われます。したがって、新しい別のアクセシビリティ指針を必要としそうですが、現実にはカテゴリー間の絶対的な格差はありません。

• 多くのデスクトップ/ラップトップデバイスは現在、タッチスクリーンジェスチャーコントロールを含みます。
• 多くのモバイルデバイスは、外部キーボードおよびマウスに接続することができます。
• レスポンシブなデザインを利用したウェブページがあっても、デスクトップ/ラップトップ上で「モバイル」画面サイズに移行することができます。
• モバイルOSは、ラップトップデバイスのために使用されています。

さらに、デスクトップ/ラップトップシステムのユーザインターフェイスパターン（例えば、テキスト、ハイパーリンク、表、ボタン、ポップアップメニュ、等）の大部分はモバイルにも等しく適用可能です。したがって、既に多数あるWCAG2.0の実装方法がモバイルコンテンツやアプリケーションにも適用できることは驚くべきことではありません。全体的にWCAG2.0は、Webおよび非Web両方のモバイルコンテンツやアプリケーションに対して関連性が高いのです。

とはいえ、モバイルデバイスにおいては、典型的なデスクトップ/ラップトップにおけるアクセシビリティの問題とは異なるものが入り混じってきます。

セクション「モバイル関する問題の議論」では、WCAG 2.0のコンテキストで対処できる方法や追加のベストプラクティスについて説明します。この文書に記載されているすべてのアドバイスは、モバイルWebサイト、モバイルWebアプリケーション、およびハイブリッドのWeb-ネイティブアプリケーションにも適用できます。（「モバイルアプリ」として知られている）ネイティブアプリケーションにも、アドバイスのほとんどが適用できます。

注：（省略。現時点ではモバイル関連の問題におけるテスタブルな達成基準は提供されていない。将来的には小さい画面サイズ、タッチ＆ジェスチャーインターフェース、画面の向きの変更に対する対応についてWCAG 2.0実装方法集に追加されるだろう）

1.2 モバイルに関連する他のW3C-WAIガイドライン

（省略、UAAG2.0とATAG2.0への参照。のちに訳出予定）

モバイル関する問題の議論

2. 主に「原則1：知覚可能」に関連するモバイルアクセシビリティへの配慮

2.1 小さな画面サイズ

小さな画面サイズは、モバイルデバイスの最も一般的な特徴の一つです。これらの画面の並外れた解像度は、理論的には大量の情報のレンダリングを可能にするものの、小さな表示領域の実用的な限界により（画面を拡大している視力の弱いユーザーにとっては特に）一度に見わたせる情報の数には制限があります。

小さい画面を最大限に活用してユーザーを支援するためのいくつかのベストプラクティス：

• 各ページに置かれている情報の量をデスクトップ/ラップトップ版と比べて最小化するため、モバイル版やレスポンシブデザインで提供します：
  • モバイル版は、モバイル用途に合わせたコンテンツが含まれています。例えば、より少ないモジュールや画像で構成されたコンテンツ、または重要なモバイル使用シナリオに焦点を当てたコンテンツなどです。
  • レスポンシブデザインではコンテンツは同じままですが、ビューポートの幅に応じて異なるレンダリングをCSSによって行えます。例えば、狭い画面ではユーザーがメニューボタンをタップするまでナビゲーションメニューを非表示にできます。
• 視力の弱いユーザーがズームイン・アウトする必要性を最小限にするためにコンテンツとタッチコントロールに合理的なデフォルトサイズを提供します。（「3.2 タッチターゲットのサイズと間隔」を参照）
• ビューポートの幅にリンクテキストの長さを適応させます。
• ポートレートレイアウトではフォームフィールドの横ではなく上にラベルを配置するようにします。

2.2 ズーム/拡大

小さな画面を持つモバイルデバイスにおいてユーザーはさまざまな方法でコンテンツの大きさを変更できます。プラットフォーム（OS）レベルでは、視覚障害や認知障害を持つ人々に対するアクセシビリティ機能として利用可能です。ブラウザレベルでは、幅広い一般ユーザーを助ける補助機能として提供されています。

方法は次のとおりです。

• OSレベルの機能
  • デフォルトのテキストサイズを設定（典型的には、ディスプレイ設定から制御）
    • 注：システムテキストサイズは、多くの場合、モバイルブラウザでサポートされていません。
  • 画面全体を拡大（典型的には、アクセシビリティ設定から制御）
    • 注意：この設定を使用すると、垂直方向と水平方向のスクロールをユーザに要求します。
  • ユーザの指の下に拡大ビューを表示（典型的には、アクセシビリティ設定から制御）
• ブラウザレベルの機能
  • デフォルトのテキストサイズを設定（ブラウザのビューポートでレンダリングされたテキスト）
  • リーディングモードのメインコンテンツ部分のテキストのサイズを設定
  • ブラウザのビューポートを拡大（典型的には、「ピンチズーム」）
    • 注意：この設定を使用すると、垂直方向と水平方向のスクロールをユーザに要求します。

注意：一部のブラウザでは倍率設定を変更する機能がある（例えば拡大よってリフローが発生する場合、ピンチズームの防止のために）。

ズーム/拡大に最も関連のあるWCAG 2.0達成基準は「1.4.4 テキストのサイズ変更(レベル AA)」です。SC 1.4.4 は支援技術なしでテキストのサイズを200パーセントまで変更可能であることを必要とします。この要件の内容を満たすためには、ユーザによるテキスト拡大を妨げてはなりません。

以下の方法が使用されることがあります。

• 200％にページを拡大できるようにするために、ページのmeta要素のビューポート指定によってブラウザのピンチズームがブロックされていないことを確認してください。user-scalable と maximum-scale 属性の使用は避けるべきです。
  • 注：（例えば、ブラウザのピンチズーム機能をブロックせず）ビューポート全体をズームすると、ユーザーは水平垂直の両方向のスクロールが必要です。この方法は達成基準は満たすものの、ビューポートのサイズに応じてテキストがリフローするテキストサイズ変更機能よりは使いにくくなります。水平方向のスクロールを必要としない形でテキストサイズ変更をサポートする技術を使用することをお勧めします。
• プラットフォーム（OS）レベルでのテキストサイズのユーザー設定に従うシステムフォントをサポートします。
• ページ上にテキストサイズを変更するコントロールを提供します。

特定の障害を持つ人々に向けたアクセシビリティ機能は、WCAGで採択された「支援技術」の定義に該当するため、達成基準を満たすために依存することはできません。たとえば、プラットフォーム（OS）レベルのズーム機能は、特に低視力を持つ人々をサポートするための機能として、プラットフォーム（OS）すべてのコンテンツを拡大するため、おそらく支援技術と考えられます。

2.3 コントラスト

モバイルデバイスはデスクトップ/ラップトップ・デバイスよりもアウトドアなどの様々な環境で使用する可能性が高く、太陽や他の強い光源からのまぶしさが生じる可能性も高くなります。この考え方は、弱視のユーザーがモバイルデバイス上の貧弱なコントラストでコンテンツにアクセスするときの課題も合わせ、すべてのユーザーのための良好なコントラストを使用することの重要性を高めることができます。

コントラストの問題に関連したWCAG 2.0の達成基準は、次のとおりです。

• 1.4.3 コントラスト (最低限) (レベル AA) : テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 （大きな文字: 少なくとも 3:1）のコントラスト比がある。
• 1.4.6 コントラスト (高度) (レベル AAA): テキスト及び文字画像の視覚的提示には、少なくとも 7:1 （大きな文字: 少なくとも 4.5:1）のコントラスト比がある。

SC 1.4.3 では大きな文字において異なるコントラスト比を許しています。大きな文字であれば広い文字ストロークによって低いコントラストでも読みやすくなります。デザイナーはタイトルなどの大きい文字に対するコントラストにゆとりを持たせることができます。SC 1.4.3の記載では、15インチモニター、1024×768の解像度、24インチの視距離において、18ポイントの文字または14ポイントの太字が、コントラスト比を下げた基準とするのに十分な大きさであると判断されました。モバイルデバイスのコンテンツは、小さな画面上で閲覧されていること、それほど大きな文字は少ないことなど、異なる条件であるため、大きな文字に対するコントラストの軽減措置については、特にモバイルアプリでは注意深く考慮しなければなりません。

例えば、モバイルプラットフォームのデフォルトのポイントサイズは、非モバイルデバイスで使用されるデフォルトのポイントサイズよりも大きくなる可能性があります。達成基準に従うようにコントラスト比を決定するときは、デフォルトのプラットフォームのサイズから1.2倍で太字または1.5倍（120％太字または150％）であることを開発者が確認するように努力すべきです。ただし、モバイルプラットフォーム上のデフォルトの1.5倍のテキストを使用すれば弱視の人でもテキストが読めるようになることを意味するものではありませんので、注意してください。弱視の人は、モバイルコンテンツにアクセスするために、このようなテキストサイズ変更やズーム機能などの使用に加えて、プラットフォーム・レベルのアクセシビリティ機能と支援技術をおそらく必要とします。

3. 主に「原則2：操作可能」に関連するモバイルアクセシビリティへの配慮

3.1 タッチスクリーンデバイス用のキーボードコントロール

モバイルデバイスのデザインは、タッチスクリーン面積を最大化するため、ビルトインの物理キーボード（例えば、固定型やスライド型）から離れる方向で進化し、ユーザーがテキスト入力を受け付けるユーザーインターフェースコントロール（例：テキストボックス）を選択した場合のみオンスクリーンキーボードを表示するようになりました。

しかし、ほとんどの主要なモバイルOSはキーボードインタフェースを含んでおり、モバイルデバイスでは外部の物理的なキーボード（例えば、ブルートゥースを介して接続されたキーボード、USBオンザゴー）や代替オンスクリーンキーボード（例えば、オンスクリーンキーボードのスキャン）によっても操作可能であるため、キーボードのアクセシビリティはこれまでと同様に重要なままです。

これらのキーボードインターフェースをサポートすることは、障害を持ついくつかのグループに利益をもたらします：

• 視覚障害を持つ人々：タッチスクリーンキーボードよりも、物理的なキーボードのいくつかの特徴（例えば、明確に分離されたキー、キーの刻印、より予測しやすいキーレイアウト）から利益を得られます。
• 運動機能に障害を持つ人々：間違い入力を最小限に抑えるために最適化されたキーボード（例えば異なる形状、間隔、キーガード）またはキーボード入力をエミュレートする特殊な入力方法から利益を得られます。
• オンスクリーンキーボードの動的な性質により混乱してしまう人々：物理的なキーボードの一貫性から利益を得られます。

いくつかのWCAG 2.0の達成基準は、効果的なキーボード制御に関連しています。

• 2.1.1 キーボード（レベル A）
• 2.1.2 キーボードトラップなし（レベル A）
• 2.4.3 フォーカス順序（レベル A）
• 2.4.7 フォーカスの可視化（レベル AA）

3.2 タッチターゲットのサイズと間隔

モバイルデバイスの高解像度は、多くのインタラクティブ要素を小さな画面上に同時に表示できることを意味します。しかし、これらの要素が問題なくタッチできるターゲットであるためには、十分な大きさと、互いから十分な距離を保っている必要があります。

タッチターゲットサイズのためのベストプラクティスは、以下のものが挙げられます：

• タッチターゲットを少なくとも9mm✕9mm以上にします。
• 一番小さいタッチターゲットの周りにはいくらかの非アクティブ領域（※訳注：マージン）を設けるようにします。

注：このサイズは、画面サイズ、デバイスや解像度に依存しません（※指のサイズに依存している）。画面を拡大すると垂直水平の両方向にスクロールが必要になり、ユーザビリティが低下するため、画面を拡大してサイズを得るものではありません。

3.3 タッチスクリーンジェスチャー

多くのモバイルデバイスは、タッチスクリーン上のジェスチャーで操作するように設計されています。これらのジェスチャーは、1本の指でタップするシンプルなものから、複数の指、複数のタップ、図形を描くなどの非常に複雑なものまであります。

（すべてではありませんが）いくつかのモバイルOSは、画面上のメニューをタップするだけでジェスチャーをシミュレートするという回避策を提供しています。

タッチスクリーンジェスチャーを決定するいくつかのベストプラクティスは、次のものがあります。

• 可能な限り簡単なジェスチャーにする必要があります。これは、スクリーンリーダー利用時は、直接のタッチ操作を「フォーカス→実行」という2段階のステップに置き換えることになるからです。また、運動機能障害により、ヘッドポインタを使っている、スタイラスに依存しているなど、マルチタッチジェスチャーを行うことが困難または不可能な場合もあります。インターフェースの設計者は、アクションを実装するやりかたとしてさまざまな手段を持っています。複雑なジェスチャーを必要とするウィジェットは、スクリーンリーダーのユーザーが使用することは困難または不可能です。通常は代替案として、単純なタップやスワイプジェスチャーを経由する形に設定できるよう設計します。
• 要素のアクションを実行する際はmouseupまたはtouchendイベントを経由するようにします。アクションをトリガーするためにmouseupまたはtouchendイベントを使用すると、マウスやタッチでのインタラクション中の意図しない操作を防ぐことができます。マウスのユーザーがアクション要素（リンク、ボタン、サブミット）をクリックした際、イベントがトリガされることを防止するために、要素の外にカーソルを移動する機会を持つべきです。これにより、ユーザーはアクションによって実行を強制されることなく、考えを変更することができます。同様に、タッチインタラクションを介して（例えば、ナビゲーション、サブミットなどの）要素にアクセスする際は、一般的にはtouchendイベントが発生したときだけトリガする必要があります（つまり、次のすべてが該当する場合：ユーザーが画面から最後に指を持ち上げた指の位置は、アクション要素内で、touchstartの位置に等しい）。

タッチスクリーンジェスチャーにおけるもうひとつの問題は、そのジェスチャーをいつどのように使えばよいかをユーザーが画面上から想起するための目印が欠けているかもしれないということです。たとえば、画面の左側からでスワイプでメニューが開くことは、目印やヘルプなしでは発見できません。詳しくは4.6 Provide instructions for custom touchscreen and device manipulation gesturesを参照してください。

3.4 機器操作のジェスチャー

タッチスクリーンのジェスチャーに加えて、多くのモバイルOSは、物理的にデバイスを操作する（例えば、振る、または傾ける）ことによってトリガーされる制御オプションを開発者に提供します。機器操作のジェスチャーによって開発者は革新的なユーザーインターフェイスを作成することができ、モバイルデバイスをホールドし続けることが困難だったり不可能だったりする人々のために挑戦することもできます。

（すべてではありませんが）いくつかのモバイルOSは、画面上のメニューをタップするだけでデバイスを振ったり傾けたりという操作をシミュレートするという回避策を提供しています。

このため、機器操作のジェスチャーが提供されている場合でも、開発者は代わりにタッチとキーボードでも操作可能にする必要があります。

• 2.1.1 キーボード（レベルA）

機器操作のジェスチャーにおけるもうひとつの問題は、そのジェスチャーをいつどのように使えばよいかをユーザーが画面上から想起するための目印が欠けているかもしれないということです。詳しくは4.6 Provide instructions for custom touchscreen and device manipulation gesturesを参照してください。

3.5 ボタンにアクセスしやすい配置

モバイルサイトやアプリケーションは、デバイスを異なる位置でホールドしているときでも、インタラクティブな要素に簡単に到達できるよう配置する必要があります。

モバイルWebコンテンツやアプリケーションを設計する際に、多くの開発者は、片手での使用に最適化することを試みます。

これは片手のみを利用可能な障害を持つ人々にはメリットがあります。しかし、開発者はまた、一部のユーザーのための使いやすいボタン配置は他のユーザーにとっては操作が難しくなることも考慮する必要があります（例えば左利きと右利きがそれぞれ片手で操作する場合においては、親指の運動範囲が異なります）。そのため、常に柔軟に使用できることを目標にしなければなりません。

（すべてではありませんが）いくつかのモバイルOSは、ユーザーが片手操作を容易にするために、一時的に画面を下や横にスライドさせるという回避策を提供しています。

4. 主に「原則3：理解可能」に関連したモバイルアクセシビリティへの配慮

4.1 画面の向きの変更（縦/横）

一部のモバイルアプリケーションは自動的に特定の表示方向（横または縦）に画面を設定し、ユーザー自身がモバイルデバイスを回転して表示とデバイスの向きを一致させることを期待しています。しかし、一部のユーザーのモバイルデバイスは、（電動車椅子のアーム上などに）固定の向きで取り付けられています。

そのため、モバイルアプリケーション開発者は両方の向きをサポートするようにしてください。両方の向きをサポートできない場合、開発者は、すべてのユーザーが容易に画面の向きを変更できるよう、デバイスの向きがサポートされるポイントに戻れることを確認すべきです。

スクリーンリーダーなどの支援技術による検出を確実にするために、向きの変更をプログラムで検出可能にしなければなりません。たとえば、向きが変更されたことをスクリーンリーダーのユーザーが認識していない場合、ユーザーが間違ったナビゲーションコマンドを実行してしまう可能性があります。

4.2 レイアウトの一貫性

複数のページにわたって繰り返されているコンポーネントは、一貫性のあるレイアウトで提示されるべきです。レスポンシブWebデザインではコンポーネントはデバイスのサイズと画面の向きに基づいて配置されており、（サイズと向きが）特定のビュー内のウェブページにおいて、繰り返しのコンポーネントやナビゲーションのコンポーネントの配置は一貫していなければなりません。画面サイズや向きが異なるビューとの間の一貫性は、WCAG 2.0 の要件ではありません。

例えば：

• Webサイトには、各ページの上部に、ロゴ、タイトル、検索フォーム、ナビゲーションバーを併設しています。これらは繰り返され、各ページ上での相対的な順序は同様になるよう表示されます。あるページでは検索フォームが欠落していますが、他の項目は、同じ順序で残っています。Webサイトを小さな画面のポートレートモードで見た場合、ナビゲーションバー1つのアイコン内にドロップダウンリストとして折りたたまれており、アイコンをアクティブ化するとは相対的な順序はまだ同様なまま表示されます。
• 異なる画面サイズ、異なる向きで見たときに、Webサイトのいくつかのコンポーネントは非表示になったり、異なる順序で表示されます。しかし、任意の画面サイズや向きでの表示においては、コンポーネントは一貫性を維持しています。

一貫性の問題に最も関連しているWCAG 2.0の達成基準は、次のとおりです。

• 3.2.3 一貫したナビゲーション（レベル AA）
• 3.2.4 一貫した識別性（レベル AA）

4.3 重要な要素をファーストビューに配置

多くのモバイルデバイス上の小さな画面サイズはスクロールなしで表示できるコンテンツの量を制限します。

重要な情報をスクロールせずに見えるように配置することで、弱視のユーザーと認知障害のユーザーを支援できます。

弱視のユーザーが画面を拡大しているとき、与えられた時間内に見ることができるのはページの小さな部分だけです。ページスクロールの前に重要な要素を配置すると、画面を拡大しているユーザーが、拡大エリアをスクロールと共に移動させずに、重要な情報を見つけられます。ページのスクロールの前に重要な要素を配置すれば、インタラクションなしでコンテンツを見つけられます。これは、短期記憶障害などの認知障害を持つユーザーを支援となります。ページスクロールの前に重要な要素を配置することは、要素や配置の一貫性を確認するのに役立ちます。要素が一貫していることと予測可能な場所に配置されていることは、弱視や認知障害を持つユーザーの支援となります。

4.4 同じアクションを実行する要素のグループ化

複数の要素が同じアクションを実行したり、（例えばリンクテキストとリンクアイコンが）同じリンク先に行くとき、これらは同じアクション要素内に含まれるべきです。タッチターゲットサイズが大きくなり、器用さの障害を持つユーザーをはじめ、すべてのユーザーに利益をもたらします。また、冗長なフォーカスターゲットの数を減らすことができ、スクリーンリーダーやキーボード/スイッチコントロールを使用しているユーザーに利益をもたらします。

要素のグループ化に関連しているWCAG 2.0達成基準は、次のとおりです。

• 2.4.4 リンクの目的 (コンテキスト内)（レベル A）
• 2.4.9 リンクの目的 (リンクのみ)（レベル AA）

操作可能な要素のグループ化の詳細については、H2: Combining adjacent image and text links for the same resourceを参照してください。

4.5 アクションを起こす要素であることの明確な指示を提供

変化を起こす要素はそうでない要素（コンテンツ、ステータス情報など）と明確に区別できるようにすべきです。

ウェブやネイティブモバイルアプリケーションにおいて、ボタンやリンクなど、アクションを起こす要素であることの明確な指示は（タッチとマウスを利用する前提において）一般には視覚的に提供されます。またインタラクティブな要素は（例えば、スクリーンリーダーユーザーのために）プログラムからアクセシブルネームを検出可能でなければなりません。

（例えば、マウス、タッチパッド、ジョイスティックといった）タッチまたは視覚的なカーソルを使用してコンテンツを操作するユーザーは、明らかにリンクやボタンなどのアクション要素を区別できるはずです。既存のインタフェース設計規則は、これらの要素がアクションを持つものであることを視覚的に示すことを目的としています。冗長性をもったコーディングの原理によれば、複数の視覚的な特徴によってアクションを持つ要素として表示されることが保証されます。これらの規則に従うことで、すべてのユーザー、特に視覚障害を持つユーザーに利益をもたらします。

アクションを起こす要素を他と区別する視覚的な特徴には、形状と色、スタイル、配置、アクションのテキストラベル、慣例的なアイコンが含まれます。

特徴の例としては：

• 慣例的な形状：ボタンの形状（丸みを帯びたコーナー、ドロップシャドウ）、チェックボックス、下向きの矢印で選択した矩形
• アイコン：従来の視覚的なアイコン（疑問符、ホームアイコン、メニューのためのハンバーガーのアイコン、セーブためのフロッピーディスク、戻る矢印など）
• カラーの差：ページの背景から要素を区別するための異なる背景色と形状、異なるテキストの色
• 慣例的なスタイル：下線付きテキストリンク、リンクカラー
• 慣例的な配置：左上のバックボタンの（iOS版）のような一般的に使用される配置、ナビゲーションのためのドロップダウンメニューにおけるリスト内メニュー項目の左揃え

アクションを持つ要素を明白にする視覚的な特徴について、WCAG 2.0の達成基準は直接結びついていませんが、関連しているものは次の通りです。

• 3.2.3 一貫したナビゲーション（レベル AA）
• 3.2.4 一貫した識別性（レベル AA）

4.6 カスタムタッチスクリーンや機器操作ジェスチャーのための指示を提供

カスタムタッチスクリーンや機器操作ジェスチャーを介したコントロールによって、開発者は優れた新しいインターフェイスを作成することができます。しかし多くの人々にとって、カスタムジェスチャを発見し、実行し、覚えておくようにすることは、チャレンジでもあります。

従って、（例えば、オーバーレイ、ツールチップ、チュートリアルなどの）指定されたインターフェースにおけるジェスチャーのインストラクションにおいて、他の方法での呼び出し方法も説明されるべきです。インストラクションが有効であるために、それ自体が簡単に発見でき、アクセス可能でなければなりません。インストラクションは初めて使用するときにハイライトされるだけでなく、別の仕組みによって必要なときはいつでも利用可能であるべきです。

これらのWCAG 2.0の達成基準は、ジェスチャーのための指示を提供することに関連しています。

• 3.3.2 ラベル又は説明（レベル A）
• 3.3.5 ヘルプ（レベル AAA）

5. 主に「原則4：堅牢」に関連したモバイルアクセシビリティへの配慮

5.1 データ入力の種類に応じた仮想キーボードの設定

一部のモバイルデバイスでは、標準的なキーボードはデバイスの設定でカスタマイズでき、追加のカスタムキーボードもインストールできます。一部のモバイルデバイスは、データ入力の種類に応じて異なる仮想キーボードを提供します。これは、ユーザによって設定されるか、または特定のキーボードに設定できます。例えば、HTML5のフォームフィールドに異なるコントロールを使用すると（Method Editor APIを参照）、ユーザーがそのフィールドに情報を入力しているときに、ウェブサイト上では自動的に別のキーボードが表示されます。キーボードの種類を設定すると、エラーを防ぐことができますし、フォーマットの正しさが保証されますが、スクリーンリーダーのユーザーはキーボードの微妙な変化によって混乱することがあります。

5.2 データ入力のための簡単な方法を提供

ユーザーは、オンスクリーンキーボード、Bluetoothキーボード、タッチ、音声などの複数の方法でモバイルデバイス上に情報を入力できます。
直接のテキスト入力は、特定の状況において時間がかかったり困難になります。セレクトメニュー、ラジオボタン、チェックボックスを提供したり、自動的に既知の情報（例えば、日付、時間、場所）を入力しておくことで、テキスト入力が必要な量を減らします。

5.3 プラットフォームの特性をサポート

モバイルデバイスは、障害を持つユーザーのコンテンツ利用を支援する多くの機能を提供します。これらには、ズーム、大きめのフォント、およびキャプションなど、プラットフォームの特性を含みます。利用可能な機能は、デバイスやOSのバージョンによって異なります。たとえば、ほとんどのプラットフォームでは大きいフォントを設定する機能を持っていますが、すべてのアプリケーションのすべてのテキストがそれを尊重しているわけではありません。また、一部のアプリケーションでは、フォントサイズを大きくするものの、テキストを折り返えさず、水平方向のスクロールを引き起こす可能性があります。

（以下略。A. WCAG Techniques that apply to mobile、B. UAAG 2.0 Success Criteria that apply to mobile、C. Acknowledgments、D. References。のちに訳出予定）