認知障害および学習障害のある人々にとってコンテンツを使いやすくする

4.2.1.1 ユーザーニーズ

ページの文脈および目的を知る必要がある。

関連ユーザーストーリー: 明確な目的。

4.2.1.3 どのように役立つか

これは、記憶および注意に障害のある人々、ならびに加齢に 関連する物忘れおよびAD(H)Dにより 気が散りやすい人を含む、多くの人々に役立つ。

たとえば、軽度の認知症のある人がオンラインショッピングを使用している。気が散り、 その後ふたたび画面を見ると、何をしていたかを忘れている。各ページの上部にある明確な見出しは、 そのページが何についてのものか、および自分が何をしているかを明確に示す。

別の例では、AD(H)D のあるユーザーが動画内の情報を探している。動画のタイトルによって、この動画に必要な情報があることを判断できる。

4.2.1.4 詳細

見出しは、この特定のページの目的を明確にする。

可能な場合、ユーザーがどのようにそのページに到達したかを理解する助けとなる情報を提供する。 例: メインナビゲーション上でパンくずリストを明確に示す、現在選択されているタブを強調表示する、など。

4.2.1.5 例

使用する:

1. ユーザーがどこにいるかを伝えるページ見出し。

避ける:

1. ユーザーがどこにいるかを伝える明確な見出しまたは道標のないページ。例:
   • 「Service not available」と書かれたページ見出しなど、ユーザーがどこにいるかを伝えないページ見出し。 ユーザーはそのサービスが何に関連するかを覚えておかなければならない。
   • フォーム内のステップを明確にしないページ見出し。

4.2.2.1 ユーザーニーズ

自分の選択肢および実行できるタスクを理解し、アクションを完了するために操作できるコントロールを 識別できる必要がある。（新しいインターフェイスデザイン パターンを学ぶことが難しい。）

関連ユーザーストーリー: 明確な操作。

4.2.2.3 どのように役立つか

多くのユーザーは、新しいデザインの比喩を簡単に学習し記憶することができない。これらのスキルがないと、 操作したい項目を見つけることや、その操作が何をするかを知ることが、はるかに難しく、 または不可能になる場合がある。ユーザーは迷ったり圧倒されたりすることがある。

ユーザーは、多くのサイトにわたって長期間頻繁に繰り返し使用される共通のデザイン要素を、 見つけ認識しやすい。

たとえば、軽度 認知障害または認知症のあるユーザーが、商品を購入するためにサイトへ行く。そのユーザーは、 欲しい商品の支払いをする場所を見つけられない。サイトは買い物を許可しておらず、 情報を提供しているだけだと思う場合がある。

4.2.2.4 詳細

一般的なデザイン要素、アフォーダンス、およびパターンには次が含まれる:

• 標準的なレイアウトおよび視覚的階層（重要度の順序を示すための要素の配置）。 ユーザーが期待する場所に要素を配置する。たとえば、英語の サイトでは:
  • ウェブサイトの右上隅に検索、
  • 左上隅にホームページへのリンク、
  • 上部ナビゲーション領域に「contact us」へのリンク、
  • フッター領域にサイトマップへのリンク、および
  • フォームの下部に送信ボタン。
• 次のような一般的なデザインパターン（コントロールおよびその他の要素のための繰り返し用いられるデザイン）:
  • WAI-ARIA authoring best practices [wai-aria-practices-1.2]、
  • 最も人気のあるサイトで使用されるパターン、
  • 非常に一般的なナビゲーションデザインパターンおよび一般的なアイコン、
  • ナビゲーション機構およびアイコンのための、プラットフォーム固有（オペレーティングシステム）のユーザーインターフェイスデザイン、および
  • 個人化できる適応型ユーザーインターフェイスデザイン（上記を参照）。
• 以前のバージョンからのユーザーインターフェイス（デザイン）。ユーザーがなじみのある アプリケーションの以前のバージョンへ戻せるようにする。
• リンクらしく見えるリンク、およびボタンらしく見えボタンとして動作するボタン。例:
  • ページ全体で標準的なスタイルによりリンクに下線を付ける、
  • リンクは一般に新しいページへ移動する、および
  • ボタンは一般にアクションを実行する。

4.2.2.5 始め方

1. ウェブページを設計するときは、ユーザーが期待する見た目および挙動を持つ標準コンポーネントを選択する。 次のようなレイアウトの標準的な慣習を使用する:
   • 左上隅にホームリンク、
   • 上部にナビゲーション、および
   • 右上に検索。
2. ページ内に明白な視覚的階層を作成する。

4.2.2.6 例

使用する:

1. 一般的なウェブレイアウト。

避ける:

1. なじみのないレイアウト。
2. なじみのない視覚的階層。

4.2.3.1 ユーザーニーズ

自分の選択肢および実行できるタスクを理解し、アクションを完了するために操作できるコントロールを 識別できる必要がある。

関連ユーザーストーリー: 明確な操作。

4.2.3.3 どのように役立つか

多くのユーザーは、新しいデザインを学習し要素を認識するのに長い時間がかかる。一度学習したら、 その要素はサイト全体で使用されるべきである。

たとえば、加齢に 関連する物忘れのある高齢ユーザーは、新しいデザインを学ぶのに長い時間がかかる。 サイトに来ると、最初のページを理解するのに時間がかかるが、その後は次のページで何をすべきか分かる。 次のページが最初のページと異なり、また学ぶのが難しい場合、疲れてより多くの 間違いをする。3つ目の難しいページへ移動すると、認知的負荷が大きくなりすぎ、 タスクを完了できなくなる。

4.2.3.4 詳細

これには次が含まれる:

• 見出しスタイル、フォント選択、アイコン、色、コントロール、ボタン、およびリンクの視覚的 外観を含む、一貫したデザインテーマ。
• 同じ構造レベルの見出しは、同じフォントおよび視覚的スタイルを持つ。
• 同じ機能およびロールを持つアイコン、コントロール、およびメニュー項目は、同じ見た目および スタイルを持つ。
• 類似した機能およびロールを持つ要素の状態およびフォーカスは、サイト全体で同じスタイルを持つ。
• レイアウトは、コンテンツのまとまり全体で一貫している。これには、インタラクティブ 要素およびナビゲーションコントロールの位置が含まれる。
• コンテンツの構造および情報提示のスタイルは一貫している。これには、テキスト、アイコン、 画像、および箇条書きのまとまりの構成が含まれる。

4.2.3.5 始め方

コンテンツを追加する前に、情報のためのデザインを計画する。色、フォント 選択、テキストおよび画像が表示される領域について考える。

4.2.3.6 例

使用する:

1. 同じレベルの見出しは、サイト全体で似た見た目である。
2. コントロールについて、サイト全体で一貫した見た目。例:
   • ウェブサイト内の2つの送信ボタンが、どちらも同じ見た目で同じ方法で機能する。
   • サイト上のすべての選択済みラジオボタンが同じ見た目である。
   • 項目にタブ移動すると、その項目はフォーカスを持ち、有効化できる。すべてのリンクのキーボード フォーカスインジケーター（どの要素がフォーカスを持つかを示すアウトライン）は同じ見た目である。
3. 共通機能の一貫した位置。例:
   • 検索ボックスはサイト全体で常に同じ場所にある。

避ける:

1. 類似した機能を持つ要素が異なって見えること。例:
   • 1つのページに6つの見出しレベル2がある。4つはTimes New Romanを使用してスタイル付けされ、 2つはHelveticaを使用している。
2. 類似した機能を持つ要素が異なる位置に提示されること。例:
   • 3つのページに送信ボタンがある。1つはフォームの上部にあり、1つは 下部にあり、1つはサイドバーにある。

4.2.4.1 ユーザーニーズ

気が散った後でも、ウェブサイト、アプリケーション、または 複数ステップのプロセスの構造の中で自分がどこにいるかを認識する必要がある。

関連ユーザーストーリー: 明確な目的。

4.2.4.3 どのように役立つか

このパターンは、集中を失ったり、何をしているかを忘れたり、気が散ったりしたユーザーが、 現在の活動に自分を再方向づける助けとなる。現在の場所および 進捗を明確に示すことは、集中を失った後に、大量のコンテンツを読んだり 最初からやり直したりすることなく、ユーザーが続ける助けとなる。

タスクを完了するために必要なステップについての情報を提供することは、ユーザーが タスクを成功裏に完了できるかを判断する助けとなる。これは、プロセスを完了するのが 難しいと感じることが多いユーザーにとって特に重要である。

例には次が含まれる:

• 早期認知症のある人が、タスク中に中断されたり 集中を失ったりし、その後何をしていたかを思い出せない。パンくずリストを見ることで、 自分がどこにいるかを思い出し、タスクを続けることができる。
• 注意障害のある人が気を散らされ、その後中断したところから再開する必要がある。
• 処理上の困難のある人は、このアプリケーションにステップが多すぎるかどうか、および 自分が対処できるかどうか確信がない。半分まで進んでいることを見ることで、 プロセス全体に対処できるかを判断できる。

4.2.4.4 例

使用する:

1. プロセス内の現在のステップ、重要な選択、ならびに過去および将来のステップを示すパンくずリスト。
2. コンテンツ内でユーザーが正確にどこにいるかを明確にする見出し。
3. 「ここに来た経路」ボタン。ユーザーがボタンをクリックすると、次についての方向づけ情報を受け取る:
   • ページ、
   • どのようにここに来たか、および
   • コンテンツ内のどこにいるか。

避ける:

1. 完了したステップおよび選択が見つけにくく確認しにくいこと。例:
   • 完了したステップを前のページに配置する。
   • 選択済みの選択肢を、コンテンツを隠したり表示したりするコントロール（アコーディオンなど）内に配置する。

4.2.5.1 ユーザーニーズ

自分の選択肢および実行できるタスクを理解し、アクションを完了するために操作できるコントロールを 識別できる必要がある。

関連ユーザーストーリー: 明確な操作。

4.2.5.3 どのように役立つか

コントロールは、リンク、ボタン、チェックボックスなど、何かを行うウェブページの部分である。 コントロール上の共通のスタイルおよびデザインパターンは、認識しやすく、使い方を理解しやすい。

これらのコントロールの目的は、誰かがそれらを使用できるようにすることである。ユーザーが コントロールを発見したり、使い方を理解したりする必要が生じるとすぐに、一部のユーザーは失敗する。

たとえば、加齢に 関連する物忘れのある高齢ユーザーは、新しいデザインを学ぶのに時間がかかる。そのユーザーが、 “sale”などの見出しの周りにボックスがあるeコマースサイトへ行く。また、そのサイトには “add to cart”ボタンなどのコントロールに単純で大きなテキストがある。ユーザーは見出しをクリックし、 テキストのように見える“add to cart”ボタンをクリックしない。何度か失敗した後、 自分には扱えないと思い、サイトを離れる。

一部のユーザーは、コントロールが以前使用したものと異なる見た目、色、または形である場合に問題を抱える。 たとえば、リンクに下線がなく青または紫のテキストでない場合、一部のユーザーは（フォーカスで表示される場合でも） リンクがあることを知らない。

記憶に困難がある場合、独自のコントロールを使用することはより難しくなる場合がある。 ページ上でコントロールを見つけるのにより長い時間がかかる場合がある。類似したものと少しだけ異なる動作をする場合でも、 一部のユーザーはそれを毎回使い方を学び直す必要がある場合がある。

ページ上で典型的なコントロールを使用することは、人々がそれらの使い方を知る助けとなる。より独自の コントロールを使用する場合は、従いやすい指示を含め、それらを見つけやすくする。ユーザーがページをどのように使用するか （視覚、聴覚、音声入力）にかかわらず、コントロールを識別し、理解し、使用しやすくするべきである。

4.2.5.4 始め方

標準のコントロールおよびデザインパターンを使用する。

新しいコントロールを設計している場合は、次を簡単にできるようにする:

• 識別する（それがあることを知る）、
• 理解する（それが何をするかを知る）、および
• 使用する（その使い方を知る）。

単純なスタイルを使用するか、その使用方法を説明する従いやすい指示を用意する。異なる認知 障害および学習障害のある人々とテストする。

4.2.5.5 例

使用する:

1. 標準的な青および紫のリンク色、または下線と明確なテキスト色を持つリンク （使用されるリンクテキスト色は、サイト上の静的テキストには使用されない）。
2. 標準的なボタンデザイン（3Dの長方形）を持ち、標準的なユーザーアクションをサポートし、 押されたときに明確に分かるボタン。
3. タブのように見え、選択されているときに明確なタブ。

避ける:

1. 下線のないリンク。
2. 明確なフォーカス状態があっても、サイト上の静的テキストと同じ色を持つリンク。

4.2.6.1 ユーザーニーズ

すべてのコントロールの使い方および各アクションの効果を知る必要がある。

関連ユーザーストーリー: 明確な操作。

4.2.6.3 どのように役立つか

ページ上のコントロールがページの一部にのみ作用する場合、それが何に影響し、何に影響しないかを 判断するのは難しい場合がある。ユーザーは誤ったコントロールを試す場合がある。多くのユーザーは 再試行し、正しいコントロールまたはスクロールバーを発見する。しかし、認知障害または学習障害のある多くの人々は、 何をすべきかを理解できない場合がある。他の人々は認知的過負荷を感じ、その結果として停止する。 アプリケーションが壊れている、または自分には複雑すぎると考える場合がある。これらのユーザーにとって、 アプリケーションは使用可能ではない。

ページ上の明確な境界およびグループ化は、コントロールがどの要素に影響するかを示す助けとなる。 コントロールおよび関連する節の周りに境界またはその他の視覚的手がかりを持たせることは、 それをより理解しやすくする助けとなる。認知 障害および学習障害のあるユーザーがページ上のすべての関係を明確に見つけ、 コントロールの使い方をすばやく理解することを、ユーザーテストで確認する。コントロールを それが影響する領域内に配置できない場合、テストは不可欠である。

たとえば、認知症とともに暮らすユーザーが、埋め込みのスクロール可能領域でどのスクロールバーを使用すべきか 理解しようとしている状況を考える。誤ったスクロールバーを試すと、望む効果が得られず、 コンテンツが消えたように見える場合がある。

4.2.6.4 詳細

• インタラクティブ要素を分ける。例: 2つのスクロールバーを近くに置かない。 一部のユーザーは、コンテンツの特定の節に対してどちらを使用すべきか判断することが難しい場合がある。 代わりに:
  • スクロールバーの明確な視覚的レイアウトおよび配置を使用する、
  • コンテンツを2つの別ページに分割する、または
  • ページから不要な情報を削除することを検討する。
• 要素とそのコントロールを関連付ける。スクロールバーやボタンなどのインタラクティブ要素を、 それらが影響し得るコンテンツの近くに配置する。適用されないコンテンツからはインタラクティブ要素を 離しておく。これにより、どの要素がコンテンツの各節に影響するかを識別しやすくなる。
• 区切りを使用する。明確な区切りの例には、高コントラストの境界または 余白が含まれる。背景色の変化は、コントラストが十分に強ければ明確な区切りになり得る。
• ユーザーが正しいコントロールを見つけられるように支援する。大きく明確なボタンおよびスクロール バーを使用する。

4.2.6.5 例

使用する:

1. 制御する節に明確に関連付けられたコントロール。コントロールを節内に配置し、 節の周りに明確な境界を持たせる。コントロールのラベルを節見出しと一致させる。例:
   • 図書館サイトで、サイト全体用の検索ボックスはサイトのメインナビゲーションの右上に配置されている。 2つ目の検索ボックスは図書館カタログを検索する。それは明確な境界、異なる背景色、 および“Library Catalog”という見出しを持つ節内に配置されている。goボタンには“search catalog”と書かれている。
   • ページの1つの節にスクロールバーが必要である。スクロールバーはその 節の内側にあるように見える。

避ける:

1. 各節にどのスクロールバーを使用するかが不明確な、複数のスクロール可能な節。
2. 1つの節のためのコントロールが、ページ全体または別の節に影響する可能性があるように見えること。 例: 検索ボックスはページの1つの領域に関連しており、別の領域には関連していない。 検索がどの領域のためのものか不明確である。
3. 複数の入れ子になったスクロール領域。

4.2.7.1 ユーザーニーズ

このページにどのような機能およびコンテンツがあるか、または先に進むべきかを知る必要がある。

関連ユーザーストーリー: 記号を使用する。

4.2.7.3 どのように役立つか

言語理解、学習、または読みに困難がある人々は、コンテンツを理解し、必要なコンテンツへ ナビゲートするために記号に依存する場合がある。記号は、言語および注意に苦労する人々が、 メディアを含むコンテンツをナビゲートする助けにもなる。

たとえば、失語症のある人は、概念を理解する知的能力を持つが、 言語に苦労する。情報を求めてページを閲覧するために、記号の使用に依存する場合がある。

これは、画面上で密なテキストのある散らかったページを読むのが難しいと感じる高齢者にも役立つ可能性がある。 テキストコンテンツへの道標として機能する明確な記号、アイコン、および画像は非常に役立つ場合がある。

4.2.7.4 詳細

• 見やすく拡大しやすい、明確で曖昧でないアイコンまたは記号を使用する。
• 文化的差異に注意する。
• 左から右へ書く言語では、ページに少数のアイコンまたは記号を追加する場合、画像を テキストの左側に配置する。
• 段落またはテキストの節に複数の記号を追加する場合は、記号を テキストの上に配置する。
• [personalization-semantics-1.0]のような個人化セマンティクスを使用して、 ユーザーがなじみのある記号を読み込めるように支援する。

4.2.7.5 始め方

ユーザーが理解しそうな一般的なアイコンを使用する。

重要なテキスト、見出し、メディア節、“contact us”ボタン、および "help"ボタンの隣に一般的なアイコンを提供する。

4.2.7.6 例

使用する:

1. 各箇条書きがその項目内のコンテンツに関連するアイコンで始まる、指示および重要なリスト。 たとえば、この文書の要約を参照。
2. ヘルプ、連絡先情報、および検索の隣のアイコン。
3. コールアウトボックス内のアイコン。

避ける:

1. 読者を導くアイコンまたは画像のない重要な指示。
2. ユーザーを混乱させたり圧倒したりする可能性がある、アイコンでいっぱいの散らかった密なページ。

4.3.1.1 ユーザーニーズ

必要なコンテンツと不要なコンテンツを簡単に識別できる必要がある。知る必要がある情報および重要な情報は 目立つか、最初に読むものであり、重要度の低い情報のノイズの中に埋もれない。

関連ユーザーストーリー: 見つけやすい。

4.3.1.3 どのように役立つか

損なわれた実行 機能、記憶障害、およびその他の認知 障害および学習障害のある人々は、サイト上で何ができるかを判断することが難しい場合がある。 重要なタスクおよび機能を目立たせることで、人々はそのサイトが自分のニーズを満たすかどうかを よりすばやく判断できる。

たとえば、ユーザーがチケットを購入するためにウェブサイトへ行く。多くのレビューやその他の情報は見えるが、 チケットの購入方法が見えない。そのユーザーはサイトを離れる。

4.3.1.4 詳細

重要な機能およびタスクを、視覚的にもプログラム的にも目立つようにする。The Web Content Accessibility Guidelines WCAG [WCAG22] を参照。

4.3.1.5 始め方

ユーザーにとって主要なタスクは何かを考えることから始める。

次を含める:

• ユーザーが実行したい最も一般的なタスク。
• ユーザーの健康またはウェルビーイングに影響する可能性があるタスク。

利用データは通常、最も一般的なタスクを識別できる。フォーカスグループおよび調査も、 ユーザーが望むものを識別するのに有用である。

4.3.1.6 例

使用する:

1. 最も重要なタスクがメインページ上に直接あり、視覚的に区別されるボックス内にある。たとえば、 図書館サイト上の重要なタスクには、検索、図書館カードへの登録、分館の場所確認、 会議室の予約などがある。
2. 最も使用される機能がページ上部付近にある。

避ける:

1. チームが宣伝したい項目を、ユーザーがサイトへ来る主な理由よりも目立つように配置すること。 例: 図書館ウェブサイトがメインページに今後のイベントだけを含めている。ユーザーは本を検索したり、 図書館カードに登録したり、分館を探したり、会議室を予約したりするために、 分かりにくいリンクをクリックして進む必要がある。
2. ユーザーが欲しがる可能性の高い情報を、見つけるためにスクロールまたはページ送りが必要な場所に配置すること。

4.3.2.1 ユーザーニーズ

サイト構造およびページ構造の両方を簡単に理解し、ナビゲートし、閲覧できる必要がある。

関連ユーザーストーリー: 明確なナビゲーション。

4.3.2.3 どのように役立つか

ユーザーは、サイト、メニュー、および構造の視覚的階層を理解しないとき、しばしば混乱して迷う。 明確なサブメニューおよびよく定義された構造は、サイト上に何があり、それをどのように見つけるかを ユーザーが知る助けとなる。

ユーザーはしばしば、次の場合に混乱する:

• 構成が不明確である、
• メニュー用語が理解しにくい、および
• メニューおよびサブメニューが見つけにくい。

サイトを明確で論理的な節に分割すると助けとなる。節を明確にし、下位節を見つけやすくする。 カテゴリ構造および見出しを理解しやすくする。サイト上に何があるかの要約として機能し得る アウトラインを作成する。

メニューで使用される用語は、ユーザーにとって意味が通る必要がある。ユーザーが探しているページが どのカテゴリに属するかが、ユーザーにとって明白である必要がある。ユーザーになじみのある一般的な語を 使用することは非常に重要である。

コンテンツ階層内のレベルを知覚し理解しやすくする。最小限の文字サイズ差、文字の太さの差、 または色の差は、知覚または理解されない場合がある。小さな独自のデザイン要素にのみ依存する階層は 混乱を生む。

たとえば、追加のサブメニュー項目を持つドロップダウン式アコーディオンメニューは、 小さな独自のデザイン要素によって示されるようにクリック（または「ロールオーバー」）する必要があることを 理解しなければ表示できない場合がある。

ウェブページを初めて開くとき、サブメニューは通常折りたたまれている。デザインによっては、 サブメニューがあることを知るのが難しい場合がある。認知障害のある一部のユーザーは、 サブメニューが存在すると推測できない場合がある。たとえ偶然メニューが展開されるのを見ても、 この構造がメニュー内の他の項目にも存在する可能性があると一般化できない場合がある。 サブメニュー項目があることに気づきやすくするために視覚的インジケーターを追加することで、 ユーザーがサイト全体を使用できることを確保する。

認知 障害および学習障害のある一部の人々にとって、サブメニュー項目を開くことが簡単でない場合がある。 たとえば、メニュー項目を展開するコントロールが、特定のジェスチャーまたはマウスで領域上を ロールオーバーする特定の方法に依存している場合である。エンドユーザーはサブメニューを展開する方法を 理解できず、タスクを放棄する場合がある。たとえば、メニューテキストの特定の側に マウスを移動した後にのみ展開するメニュー。

4.3.2.4 詳細

• サブメニュー項目を示す小さなデザイン要素は、ユーザーにとって常に意味があるとは限らない。 可能な場合はいつでも、多様なユーザーセットでデザインをテストし、それらが明確であることを確認する。

• ユーザーにとって理解しやすくするために、ベストプラクティスを一貫して使用する。

• 小さなデザイン要素の解釈に依存する入れ子要素の連続も混乱を招き、 ユーザーは階層を理解できない場合がある。

• テキストが隠れているとき、または隠したり表示したりできるときを明確に示す。

4.3.2.5 始め方

1. サイト内のコンテンツの種類およびコンテンツカテゴリについて考える。
2. コンテンツを明確なカテゴリに分割する。
3. 重要なカテゴリからメインナビゲーションを構築する。
4. サブメニューがある場合は、サブメニューが閉じているときと開いているときを示す明確な記号を追加する。

4.3.2.6 例

使用する:

1. 視覚的に明確で論理的なサイト階層。
2. テキストが隠れているときの明確なインジケーター。例:
   • 押すと追加情報が表示されることを示すために、“+”記号を一貫して使用する。
   • メニュー内の隠れたサブメニュー項目の隣に三角形を一貫して使用する。

避ける:

1. 各メニュー項目の下にある項目をユーザーが正しく推測できないサイト階層。
2. メニューカテゴリの不明確な論理。
3. メニュー項目の隣にサブメニュー項目の視覚的表示がないこと。例:
   • マウスでサブメニュー項目の存在を発見する唯一の方法が、サブメニュー項目上へ マウスを移動することである。
   • サブメニューを開くには、メニュー項目の一部にマウスを置く必要があり、この領域が 明確でなく、視覚的に区別されていない。

4.3.3.1 ユーザーニーズ

サイト構造およびページ構造の両方を簡単に理解し、ナビゲートし、閲覧できる必要がある。

関連ユーザーストーリー: 明確なナビゲーション。

4.3.3.3 どのように役立つか

認知 障害および学習障害のある人々は、ページ構造および関係が不明確な場合、コンテンツおよび アプリケーションを使用できない場合がある。ユーザーはタスクを完了できず、重要な情報を見落とす場合がある。 ユーザーは、使用および理解が複雑なページに戻らない場合がある。

明確でよく整理されたページレイアウトにより、ユーザーは重要な情報を簡単に見つけられる。 ページ上に何があるかを理解する代わりに、タスクに集中できる。標準的な視覚的レイアウトを使用し、 要素を一貫して配置することは、ユーザーが筋肉記憶に頼ってそれらを使用する助けとなる。 これは、問題解決スキルに影響する障害のある人、読むのが遅い人、または大量のテキストを提示されると 圧倒される人をサポートする。これには次が含まれる:

良い構造: ページコンテンツを、それぞれ明白な目的を持つ節に整理することで、 ユーザーは必要な節をより簡単に見つけ、集中できる。ページの主目的に直接関連しないコンテンツは、 明確に分離されるべきである。

グループ化に境界および網掛けを使用する: 境界または色の網掛けを使用して情報をグループ化すると、 人々がグループを識別しやすくなる。

例:

図: 網掛けおよび境界によるグループ化の例。

視覚的手がかり: 書き言葉を認識または理解したり集中したりすることに困難がある人々は、 グラフィックによる手がかりを処理しやすいと感じる場合がある。一般的なグラフィックインジケーターおよび 視覚的手がかりの例には次が含まれる:

• コンテンツの要約をグループ化する、
• 色または余白を使用したカードデザインを使用する、
• コールアウトボックスの使用など、重要な情報に印を付ける、および
• 引用を吹き出し内に配置するなど、異なる種類の情報を示す。

4.3.3.4 詳細

ページに大量のコンテンツがある場合、コンテンツがグループ化されているか、何が関連しているかが分かるかを確認する。

領域および明確なページ構造を作ることには次が含まれる:

• コンテンツカテゴリに明確なラベルを付け、なじみのある視覚的手がかりおよびアイコンを使用する。 これは記憶に頼るのではなく、認識および検索を助ける。背景色は、コントラストが十分に強ければ 明確な区切りになり得る。
• 見出し構造は、文書全体の概要として機能し得る文書のアウトラインを作成するべきである。

アイコンは一貫して使用されるべきである。グラフィックインジケーターがインターフェイスを散らかさないことも 重要である。アイコンが多すぎると、ユーザーが処理する認知的負荷が増える可能性がある。 明確な区切りの例には、高コントラストの境界または余白が含まれる。背景色の変化は、 コントラストが十分に強ければ明確な区切りになり得る。

4.3.3.5 例

使用する:

1. 十分に分離されたコンテンツの節。余白、境界、またはコールアウトが節を分離するために使用されている。
2. コンテンツの節を定義する助けとなる見出しおよびアイコン。これによりページ上の情報が整理され、 レイアウトを理解し、具体的な情報を見つけやすくなる。
3. コールアウトボックス。

避ける:

1. 余白が少ない密なテキスト。
2. 不明確なページ構造および階層。
3. 視覚的に区別された節の不足。
4. 節を定義する見出しまたはアイコンのない節。例: ウェブページに「フラットデザイン」で互いに 連続したコンテンツのまとまりがある。認知障害のある多くのユーザーは、どのまとまりが 一緒に属するかを理解することが困難または不可能だと感じる。そのため、コンテンツをまとまりにする 利点はすべて失われる。
5. 論理的でないグループおよびページ節。

4.3.4.1 ユーザーニーズ

スクロールしたり他のアクションを実行したりせずに、重要な情報および必要なコントロールに 到達する必要がある。それらは隠されておらず、画面外にもない。

関連ユーザーストーリー: 見つけやすい。

4.3.4.3 どのように役立つか

読むのが遅い人、損なわれた実行 機能、記憶障害、およびその他の認知 障害および学習障害のある人々は、ページ上の情報および機能を見つけられない場合がある。 たとえば、多くの読書を必要とするコンテンツ、またはスクロールバーやポインターホバーの使用を 必要とするコンテンツは、見つけにくい場合がある。他のユーザーは、異なる画面をページ送りする必要がある コンテンツを見つけられない場合がある

ページ（または一般的なデザインパターン）になじみのないユーザーは、重要な情報を見つけるために、 目立つ視覚的スタイルの補助に頼る場合がある。明確な見出し構造も、読む必要がある量を減らすことで、 これに役立つ。

たとえば、小学校が、記事、活動、および重要なお知らせを含む週刊ニュースレターを公開している。 重要なお知らせの1つは、ある日に学校が早く終わることである。ニュースレターには早い下校のお知らせの前に 重要度の低い情報があり、重要な情報の隣に警告記号がない。読むのが遅い保護者は、 重要な情報の前で読むのをやめる必要がある場合があり、その学校がある日に早く終わることを知ることができない。 その保護者は子どものために時間どおり家にいない。

別の例では、ユーザーがコメントを書いているが、テキスト領域にフォーカスがあるとき送信ボタンが見えない。 その結果、そのユーザーはフィードバックの送信方法が分からない。その会社は、フィードバックボタンを 見つけられないグループからフィードバックを受け取れないことになる。

4.3.4.4 詳細

スクロール前に見えるページ量は、物理デバイスのサイズおよび解像度など、幅広い要因に依存する。 可能な場合は、ユーザーが使用している技術を理解するためにサイト統計を使用する。ページを設計する際には これを念頭に置く。

最も制約のあるユーザー体験（例: 幅240pxの携帯電話）を最初に考慮し、 そこから上に向けて設計する。これにより、最も広い範囲のシナリオに対応できる。 レスポンシブ開発手法を採用することで、より多くのデバイスおよび状況に対するページの柔軟性を 向上させることができる。

4.3.4.5 始め方

ページ上の最も重要なものを見つけやすくする。デザインプロセスの早い段階で 主要コンテンツおよびその配置を識別する。

文書上部の領域は、スクロールなしでユーザーに見える可能性が最も高い。 最も幅広いユーザーに最良の体験を提供するために、主要コンテンツをページ上部に配置する。

4.3.4.6 例

使用する:

1. ページをスクロールする必要なく見える重要なコントロールおよび機能。
2. 重要度の低いリンクおよびボタンから目立つ、送信ボタンなどの重要なコントロール。
3. 強調表示され、スクロールなしで見える重要な情報（健康および安全に関する情報など）。
4. ページ上のその他の重要度の低い情報から視覚的に目立つ重要な情報。

避ける:

1. ユーザーがすぐに見つけられない重要な情報、コントロール、または機能。例: 視覚的に区別されず、ファーストビュー内にないユーザー安全に関する警告。

4.3.5.1 ユーザーニーズ

自分が望む場所へ簡単にナビゲートし、休憩を取り、内容についていけない場合や気が散った場合に 簡単に1つ前に戻れる必要がある。

関連ユーザーストーリー: メディア。

4.3.5.3 どのように役立つか

見出しを伴う明確で論理的な構造を使用すると、ユーザーは気が散ったり集中を失ったりしても、 コンテンツ内で自分の位置を把握し、簡単にナビゲートできる。これは注意障害のある人々にとって 特に重要である。

短く論理的なセグメントを提供することは、ユーザーが特定のトピックを見つけ、そこに集中する助けとなる。 ユーザーが集中を失った場合、教材内で自分の位置を見つけ、覚えている最後の地点から 再開できる。これは教育コンテンツまたは指示にとって特に重要である。

メディアをまとまりに分けることで、各セグメントに一意なURIを与えることもできる。 それにより、簡単に参照および共有できる。

例:

• 一部の動画は、自然に章またはセグメントに整理できる。
• ポッドキャストは、1時間の単一録音ではなくセグメントに分割できる。

4.3.5.4 詳細

• 6分以下: メディアは通常、長さ6分以下のセグメントに分割されるべきである。
• ナビゲート可能: 各メディアセグメントへのナビゲーションと、一意で説明的なラベルを提供する。
• 論理的順序: メディアセグメントへのリンクを論理的な順序で提示する。
• 例外: 論理的な区切り点がないメディアは、細分化する必要はない。

4.3.5.5 例

使用する:

1. 短く論理的なセグメントに分割されたメディア。各節にはラベルがあり、簡単に到達できる。 例: 30分の動画が5つの節に分割され、それぞれにその地点以降から再生するための 説明的なリンクがある。

避ける:

1. セグメントに分割されていないメディア。例: 30分の動画に下位分割または節の説明がない。 ユーザーは最初から再生するか、動画内の開始位置を推測しなければならない。
2. ラベルのないメディア節。
3. 要約または目次からリンクされていないメディア節。

4.3.6.1 ユーザーニーズ

機能およびコンテンツを容易に見つけられる必要がある。

関連ユーザーストーリー: 検索可能。

4.3.6.3 どのように役立つか

検索機能があると、ユーザーはサイトメニューを使用できない場合でも、必要なコンテンツを見つけることができる。 ユーザーは検索の使い方を学び、そのスキルを多くのサイトで再利用できる。

メニューシステムおよびほとんどのサイトナビゲーションは、ユーザーがメニューカテゴリを理解することを要求する。 損なわれた実行 機能のあるユーザーは、正しいカテゴリを識別できない場合がある。

場合によっては、ユーザーは論理ではなく記憶によって正しいカテゴリを知っている。たとえば、ほとんどの ユーザーは印刷機能がファイルメニューの下によくあることを覚えている。記憶障害のあるユーザーは、 想起に基づいてこれらのメニュー項目を見つけられない場合がある。

短期記憶に障害のあるユーザー、加齢に 関連する物忘れのあるユーザー、または気が散りやすいユーザーも、サイトをナビゲートし、 コンテンツを探すために多くのページへ移動することが難しいと感じる場合がある。時間がかかりすぎると、 集中を失い、何を探しているかを忘れる場合がある。

検索は、スペルミスを修正し、適切または関連するコンテンツを見つけ、検索語の 自動修正された候補バージョンを提供するときに最も有用である。

関連トピックから多くの結果がある場合、検索結果が適切な見出しおよびカテゴリの下に提示されると役立つ。 これにより、ユーザーは探している検索結果を見つけやすくなる。

4.3.6.4 詳細

すべてのページがメインページから2クリック以内である小規模サイトでは、検索の重要性は低い。

4.3.6.5 例

使用する:

1. スペルチェックまたは候補語を伴う検索。

避ける:

1. 元の要求との関係によってグループ化または順序付けされていない多くの結果を提示する検索。

4.4.1.1 ユーザーニーズ

語彙、構文、時制、および言語のその他の側面を含め、使用される言語を理解する必要がある。

関連ユーザーストーリー: 明確な言語。

4.4.1.3 どのように役立つか

これは、言語障害、処理上の困難、または記憶障害のある人など、多くの人々に役立つ。 一般的でない語を使用すると、テキストおよびメディアを理解しにくくする場合がある。

言語障害のある人々は、語彙が少ないことが多い。新しい用語を学ぶことは非常に遅く、難しいプロセスである。 認知症とともに暮らす人々など、他のグループにとっては、新しい用語を学ぶことは現実的でない、または 不可能である。すでに知らない一般的でない語を使用すると、コンテンツは理解不能（理解できない）かつ 使用不能になる。

たとえば、軽度認知症のある人が、ICTの暖房および空調ユニットをオンにしようとしている。 暖房または空調を選択するメニュー項目には “mode” というラベルが付いている。この1つの用語のために、 ユーザーはユニット全体を使用できない。この種のデザインは、低体温症のような緊急事態を引き起こしている。

一般的な語および用語を、その最も一般的な意味で使用することは、これらの問題を避ける助けとなる。

一般的な語および関連リソースのページについては、開発者向け リソースページを参照。

4.4.1.4 詳細

一般的でない語を使用する場合は、次によって説明を提供する:

• その隣に括弧で単純な言語の用語を追加する、
• ポップアップ定義を提供する、または
• サポートされるマークアップを使用する（easylangを参照）。 easylang は新しい個人化仕様 [personalization-semantics-help-1.0] に導入されていることに注意。公開時点では、さらなるサポートが必要である。

4.4.1.5 始め方

見出し、ラベル、ナビゲーション要素、指示、およびエラーメッセージで明確な語を使用することから始める。 これにより、大きな時間的負担なしにユーザビリティが向上する。

4.4.1.6 例

使用する:

1. 一般的で明確、かつ理解しやすい語および用語の定義。例:

   あなたの家主は法律に従わなければならない。

   • あなたの家主は、未払いの家賃（あなたが支払うべき家賃）や、あなたが壊したものの修理など、 特定のことにだけ保証金（約束のお金）を使用できる。
   • あなたの家主は、明確な日付までに保証金（約束のお金）をあなたに返さなければならない。 これは通常、あなたがアパートを出てから30日後である。

2. 略語が完全な用語より一般的である場合を除き、最初に使用されるときに説明される略語。 最初の使用後、略語はtitle付きのabbreviationタグ内にある。
3. 一般的に使用されていない頭字語は、最初に使用されるときに説明され、その後はtitle付きの acronymタグ内にある。
4. 避けられるか、説明される専門用語。

避ける:

1. 説明のない一般的でない語。例:

   家主の控除権。賃借人が賃貸物件に入居するとき、 その人は家主に保証金を支払う。管轄区域に応じて、この保証金は、賃借人が賃貸借契約または 契約のすべての条件および条項に従う限り、賃貸借期間の終了時に特定の期間内に賃借人へ 返還される。あなたの状況に関連する法律を読むには、下のリンクを選択する。

2. ユーザーが知らない可能性があり、説明されていない略語、頭字語、および専門用語。

4.4.2.1 ユーザーニーズ

語彙、構文、時制、および言語のその他の側面を含め、使用される言語を理解する必要がある。

関連ユーザーストーリー: 明確な言語。

4.4.2.3 どのように役立つか

単純な時制および態を使用することは、言語障害、ディスレクシア、または記憶障害のある人など、 多くの人々に役立つ。たとえば、“the on button should be pressed.”（受動態）よりも、 “press the on button”（現在時制および能動態）の方が、より多くの人に理解される。

能動態は、誰が行動することになっているかを明確にする。たとえば、“It must be done.” は 受動態であり、誰が行動しなければならないかを述べていない。“You must do it.” は能動態であり、 誰が行動するかを明確に述べている。

文の目的を冒頭に置くことも、英語の文を追いやすくする場合がある。地域の言語専門家は、 コンテンツを理解しやすくする追加の言語上の助言を持っている場合がある。

4.4.2.4 詳細

• 他の態または時制の方が理解しやすい、または親しみやすい場合は、それらを使用する。
• 現在時制および能動態が存在しない、または最も明確な選択肢でない言語では、 最も理解しやすい時制および態を使用する。
• 過去または未来の出来事について書く場合、現在時制を使用しない。混乱を招く。

4.4.2.5 例

使用する:

1. 単純な時制および言語。例: “Your stocks went up this month.”

避ける:

1. 複雑な言語および時制。例: “Over the last month, we saw your stocks increasing.”

4.4.3.1 ユーザーニーズ

語彙、構文、時制、および言語のその他の側面を含め、使用される言語を理解する必要がある。

関連ユーザーストーリー: 明確な言語。

4.4.3.3 どのように役立つか

単純な文構造は、言語障害、ディスレクシア、または記憶障害のある人を含む多くの人々に役立つ。 二重否定および入れ子になった節は、どちらも混乱を招く場合がある。

たとえば、“No approval of any claims can be achieved without the agency’s approval.” よりも、“You must get the agency’s approval before we can answer your claim” の方が、より多くの人に理解される。

単純な言語は、より多くの人が理解できるようにする。たとえば、早期認知症のある人は、言語が明確で理解しやすい場合、 自分の事柄を管理できる。

4.4.3.4 例

使用する:

1. 二重否定のない短いテキスト。例: “Write clearly”。

避ける:

1. 肯定に置き換えられる二重否定。例:
   • Do not write unclearly.
   • Time is not unlimited.

2. 多くのコンマおよび接続詞を含む長い文。例:
   • Usually, clauses will be separated by two commas, one before and one after or the word “or”, or the word “and”, so you could replace the sentence with a list of options or even more than one paragraph.

4.4.4.1 ユーザーニーズ

テキストの意味を理解する必要がある。冗談や比喩を誤解する可能性があるため、説明されていない、 暗示的、または曖昧な情報は望まない。

関連ユーザーストーリー: 明確な言語。

4.4.4.3 どのように役立つか

多くの人々は、非文字どおりのコンテンツを理解しない。たとえば、自閉症 の人は、冗談および直喩を理解しない場合がある。指示には、コンテンツをより親しみやすくするために、 冗談や直喩が含まれることがある。しかし、これはユーザーを混乱させ、そのユーザーは必要なように 仕事を行えなくなる。

非文字どおりの言語は、次によって説明できる:

• 比喩および直喩など、任意の非文字どおりのテキストの隣に、括弧で単純な言語の用語を追加する、
• ポップアップ定義を提供する、または
• サポートされるマークアップ（個人化セマンティクス [personalization-semantics-help-1.0] など）を使用する。

非テキストメディアでは、メディアの一部として非文字どおりのコンテンツを説明するか、 別のファイルまたはトラックに含める。ベストプラクティスを参照。

4.4.4.4 詳細

非文字どおりのテキストを文字どおりのテキストに置き換えるときに、意味が明確なままであることを確認する。 ポップアップまたはその他の代替で文字どおりのテキストを提供するときに、これを確認する。

4.4.4.5 始め方

見出し、ラベル、ナビゲーション要素、指示、エラーメッセージ、およびユーザーの権利またはウェルビーイングに 影響する可能性がある任意のコンテンツに、明確で文字どおりのテキストを置くことから始める。これにより、 書き方を変えずに、重要な場所でのユーザビリティが向上する。

4.4.4.6 例

使用する:

1. 文字どおりのテキストおよび具体的な言語。例:
   • 始める前に不安障害を経験している場合は、深呼吸し、自分ならできると自分に言い聞かせて始める。 不安には、緊張、恐れ、めまい、または息切れが含まれる場合がある。

避ける:

1. 非文字どおりのテキスト。例:
   • If you are experiencing cold feet before starting, take a deep breath and jump in.

4.4.5.1 ユーザーニーズ

語彙、構文、時制、および言語のその他の側面を含め、使用される言語を理解する必要がある。

関連ユーザーストーリー: 明確な言語。

4.4.5.3 どのように役立つか

テキストコンテンツをまとまりに分けると、読みやすく理解しやすくなる。これは、処理速度または言語に関連する 学習障害または認知障害のある人々に役立つ。記憶障害のある人や、気が散りやすい人にも役立つ。 まとまりに分けることは、マルチタスクをしている人にも役立つ。各まとまりまたは段落の冒頭に 目的または意図を置くようにする。

たとえば、AD(H)D のある大学院生は、新しいソフトウェアスキルを独学する必要がある場合がある。ソフトウェア文書が トピックごとの短い段落およびリストに分割されている。その学生は、文書を読みやすく理解しやすいと感じる。

4.4.5.4 詳細

• 短い段落とは何か? 英語では、段落が50語を超える場合、2つの段落に分けるようにする。
• 1つを超える点を持つ文を書くことをどう避けられるか? 1つを超える点を持つ文は、 通常 “and” または “but” などの接続語を複数持つ。
• 長い文が2つの短い文より明確な場合はあるか? 長い文が2つの短い文より明確かどうかを 再確認する。認知 障害および学習障害のある人々が長い文を理解しやすいと感じるかどうかを確認するために、 ユーザビリティテストを行う。
• いつリストを使用すべきか? 3つ以上のものが連続する場合、リストは非常に有用である。 項目、要件、および例外には、順序なしリスト（箇条書き）を使用することを考える。 3つ以上のステップの連続は、番号付きリストとして追いやすくなる。

4.4.5.5 例

使用する:

1. 短いテキストのまとまり。例:
   • Calgaryでは、この週末に多くの雪と雹が降る。運転しないようにする。運転しなければならない場合:
     • 安全を保つために、冬の運転ルールを使用する。
     • 出発する前に、Traveler’s Information ウェブサイトでどの道路が安全かを確認する。

避ける:

1. 長いテキストのまとまり。例:
   • DOTDはCalgary向け冬季天候旅行注意報を発表。休日の週末を通して雪および雨の可能性が 予報されていることを受け、交通開発局（DOTD）は、局の職員が冬季天候に対応する準備が できていると発表した。保守部隊は、影響を受ける橋および道路に砂と塩を散布し、 倒木を道路から除去し、必要に応じて道路を閉鎖するために待機する。暫定長官Jane Doeは、 運転者に冬季天候の脅威を真剣に受け止めるよう促している。「悪天候の場合、局は高速道路および 州間道路へのアクセスを維持するよう努める。しかし、可能な限り、雪および氷の中での移動を 避けるよう一般の運転者に促す」とDoeは述べた。

4.4.6.1 ユーザーニーズ

語を音声的に読むために必要なアクセント、文字、および発音区別符号が語に含まれる必要がある。

関連ユーザーストーリー: 明確な言語。

4.4.6.3 どのように役立つか

一部の読者にとって、語、数字、および記号の解読は自動的には起こらず、作業記憶および実行 機能に負荷がかかる場合がある。コンテンツが負荷が高すぎると感じる場合、その意味を失うリスクがある。

一部のユーザーは、コンテンツを読み上げるテキスト読み上げなど、コンテンツ理解を助ける支援技術または個人化ツールを 使用する場合がある。しかし、句読点または書式によって、スクリーンリーダーがそれを誤って読み上げる可能性が 高くなる場合がある。たとえば、ローマ数字がテキストとして読まれる場合がある。

学習障害のあるユーザーは、書式または句読点の誤りによって発生する間違いを修正するために、 文字、数字、および語を操作できない場合がある。また、そのコンテンツを使用するために、コンテンツの意味を 理解することに集中する必要もある。

たとえば、コミュニケーション障害のあるユーザーが、テキスト読み上げを使用してコンテンツを聞く場合がある。 コンテンツが正しく表現されていれば、理解できる。ときには、特に数字および記号について、コンテンツが 誤って読み上げられたりスキップされたりするのを聞き、理解できなくなる。テキスト、数字、または記号が なじみのないレイアウト内にある場合、ユーザーは混乱する可能性がある。

対照的に、コンテンツを聞いている盲目の人は、語が正しく発音されない場合でも、正しい意味を 理解できる可能性が高い。しかし、正しい意味を見つけるために必要な語の操作は、 コミュニケーションまたは言語障害のある人には達成できない。

4.4.6.4 詳細

言語タグを使用する。 言語タグは、曖昧でないテキスト書式という目標を達成するための 重要な手段である。HTML [HTML] の言語タグおよびBCP 47 Language Codesを参照。

句読点を正しく使用する。書いている言語に応じて、句読点はテキストから音声へ変換されるときの 強勢およびイントネーション（韻律として知られる）パターンの聞こえ方に影響する。たとえば英語では、 コンマおよびセミコロンは音声内に短い間を生じさせるが、ハイフン - は一般に無視される。 疑問符、感嘆符、および引用符は、声のピッチ上昇など、イントネーションの変化をもたらす場合がある。

可能な場合、テキスト内でのローマ数字およびなじみのない記号の使用を避ける。 これらは読者を混乱させ、テキスト読み上げツールによって誤って読み上げられる可能性が高い。 これらの記号が必要な場合は、追加サポートを提供するために、MathMLおよび略語展開などの技法を使用して、 正しくマークアップされていることを確保する。ローマ数字を単独で使用する場合は、 個々の文字として読まれる可能性が高いため、大文字で提示すべきである。

長い数字は、単一の数字として、または1つの数として読み上げられる場合がある。これは電話番号または 郵便番号にとって特に問題である。これらの数字がどのように読み上げられるかを正確に制御することは難しいが、 コンテンツ作成者は次によって支援できる:

• 数字の内容を表示し、HTMLセマンティクスを使用して、ユーザーおよび支援技術がその数字の目的を 認識できるようにする。加えて、次の推奨事項はテキスト読み上げのレンダリングを改善する助けとなり得る:
• 電話番号については、その電話番号の地域に合った正しいレイアウトを使用し、ユーザーが電話番号全体 （市外局番を含む）を選択できるようにする。これにより、テキスト読み上げ音声は形式を認識し、 正しく表現できる。
• Zip / 郵便番号については、番号の近くに州または住所情報を含める。これにより、音声は既知の略語 （州名など）を展開でき、聞き手は文脈を知覚できる。
• 長い数字を書くときは、読者になじみのある区切り記号が何か、およびそれがどのように読み上げられるかを 考慮する。一般に、英語圏の国では千単位の区切りにコンマを使用し、小数点としてピリオドを使用するが、 ドイツ語およびその他のヨーロッパ諸国ではその逆である。たとえば、1,245は英語では 千二百四十五を表すが、ドイツ語では一点二四五を表す。テキスト読み上げ出力は、音声の言語形式で 区切り記号が使用されていると仮定する。これがコンテンツと一致しない場合、聞き手は簡単に混乱する可能性がある。 千単位区切りを空白に置き換えることは、混乱を避けるための一般的な慣習になっているが、 長い数字が途切れ途切れに読み上げられるというテキスト読み上げ上の困難につながる。たとえば、 120 034 943は、百二十、ゼロ三四、九百四十三として読まれる場合がある。

4.4.6.5 例

使用する:

1. どの文化でも読めて理解できる日付。

   日付の書き方を考慮する。ここでもテキスト読み上げは、 音声の言語に関連付けられた形式を使用するためである。04/03/2019のような日付は、 米国英語の音声では “April 3rd 2019” と読まれ、英国英語の音声では “4th of March 2019” と読まれる。月を語で書くことで混乱を避けられる。

避ける:

1. 文化に基づいて明確でない、または異なって読まれる日付および数字。

4.4.7.1 ユーザーニーズ

語を音声的に読むために必要なアクセント、文字、および発音区別符号が語に含まれる必要がある。 これは、アラビア語やヘブライ語などの言語における音声合成および音声的リーダーでしばしば必要である。

関連ユーザーストーリー: 明確な言語。

4.4.7.3 どのように役立つか

ヘブライ語およびアラビア語などの一部の言語には、任意の母音および発音区別符号がある。 これらの符号がないと、同じ文字を持つほとんどの語には、異なる意味を持つ発音が2通り（ヘブライ語）から 7通り（アラビア語）ある。ほとんどの読者は文脈に基づいて語を読み、視覚記憶を使用して 正しい発音を推測できる。視覚記憶に障害のある人、読むのが遅い人、およびテキスト読み上げは、 誤った用語または発音を推測することが多い場合がある。

たとえば、言語障害のあるユーザーが語を音読しようとしている。意味の通るものを見つけるまで、 3つの異なる発音を推測する。残念ながら、言語障害のある多くの人々は、文脈外の語が 具体的な意味ではなく単なる考えだけを提供する場合があるため、その意味を理解できない。 テキスト読み上げは、正しい語を読み上げるためにこれらの文字をしばしば必要とする。

すべての発音区別符号が語を正しく発音するために必要であるわけではないことに注意。 曖昧でない発音に必要な文字および発音区別符号のみを含める必要がある。

4.4.7.4 詳細

語は、正しい意味を持つように解読および発音できる。

4.4.7.5 始め方

ヘブライ語では、正しい発音を可能にする追加のYud（י）およびVav（ו）を追加する。

4.4.7.6 例

使用する:

1. 正しい発音を可能にする追加の文字または発音区別符号。例:
   • He says: אֹמַר /אומר（ヘブライ語）
   • He wrote: كَتَب（アラビア語）
   • Books: كُتُبْ（アラビア語）
   • It was written: كُتِبَ（アラビア語）

避ける:

1. 必要な文字または発音区別符号がないため、ユーザーが記憶および文脈に基づいて発音を推測しなければならない語。 例:
   • אמר（ヘブライ語）
   • كتب（アラビア語）

4.4.8.1 ユーザーニーズ

長いコンテンツについて、理解しやすく短い要約、または理解しやすい 版の選択肢が必要である。

関連ユーザーストーリー: 明確な言語。

4.4.8.2 行うべきこと

長い文書およびメディアに短い要約を提供する。

重要なキーワードを強調して、人々が文書の目的および内容を理解し、 必要な情報が含まれる可能性があるかを判断できるように支援する。

要約は一般的な語、短い文を使用し、理解しやすいスタイルおよび時制で書かれるべきである。

4.4.8.3 どのように役立つか

理解しやすい要約を提供することは、多くの人々がコンテンツが自分および現在の目標に関連するかどうかを すばやく判断する助けとなる。数文または箇条書きによる高レベルのアウトラインが最も効果的である。 要旨およびエグゼクティブサマリーは、文書全体を要約するように設計されているため、 通常ははるかに長く詳細である。

メディアでは、要約は注意持続時間が短いユーザーが必要な正確なファイルを見つけ、 正しいコンテンツにジャンプする助けとなる。すべてのメディアファイルには要約説明があるべきである。

4.4.8.4 詳細

前期中等教育レベルの読解力を持つ人々に理解できるテキスト要約を提供する。

300語未満のコンテンツでは、見出しが要約として機能できる。

各セグメントの要約には、コンテンツの主な点を含めるべきである。ユーザーは要約を使用して コンテンツを一意に識別し、それに何が含まれるかを知ることができるべきである。

4.4.8.5 例

使用する:

1. 主な点を明確に述べる箇条書き付きの短い要約。

避ける:

1. 要約のない長いテキスト、文書、またはメディア。
2. 不明確な要約。例:
   • マルチメディアで、セグメントがChapter 1、part 1、Chapter 1、part 2などとして要約されている。

4.4.9.1 ユーザーニーズ

短いボックス、コンテンツのまとまり、または節が必要である

関連ユーザーストーリー: サポート。

4.4.9.2 行うべきこと

指示では、各ステップを分ける。各ステップを明確に述べる。これには次が含まれる:

• 「明白」だと思うステップも含め、すべてのステップを含める、
• 番号およびリストを使用することも助けとなる、
• 複雑な指示をif/then表で提供する。これは追いやすい場合がある、または
• 親しみやすいグラフィックを使用すると、指示が怖く感じられにくくなる。

4.4.9.3 どのように役立つか

ステップごとの指示は、言語障害、処理上の困難、または記憶障害のある人など、多くの人々に役立つ。

たとえば、作業記憶に障害のある人は、多くの情報を同時に保持できない。自分が何をしているかを覚え、 ステップを分け、何を行ったかを追跡する必要がある場合、間違いを起こす可能性が高くなる。 指示が明確に分けられ、配置されている場合、その人は間違いをせずにそれに従うことができる。

4.4.9.4 例

使用する:

1. 各ステップを分ける箇条書き。
2. 条件に基づいてステップを分けるif/then表。例:

   If	Then
   プログラミングで働きたい場合:	履歴書を作成する。 自分が書いたサンプルコードを用意する。 それらをprograming@example.comへ送信する。
   デザインで働きたい場合:	履歴書を作成する。 自分が設計したサンプルページを用意する。 それらをdesign@example.comへ送信する。

避ける:

1. 分離なしに、同じテキストのまとまり内に複数のステップがあること。例:
   • プログラミングで働きたい場合は、履歴書および自分が書いたサンプルコードを添えて、 programing@example.comへ書く。デザインで働きたい場合は、履歴書およびサンプルページを添えて、 design@example.comへ書く。

4.4.10.1 ユーザーニーズ

まとまりが明確で、ページが圧倒的にならないように、余白を適切に使用する必要がある。

関連ユーザーストーリー: 視覚的提示。

4.4.10.3 どのように役立つか

余白（ネガティブスペースまたは背景色とも呼ばれる）は、散らかりを減らし、コンテンツに輪郭を与える。 これにより、閲覧者はウェブページの明確な概要を得る。これは、ページ上のテキストおよび オブジェクトの位置を強調するためにデザイナーによって使用される。

余白を使用すると、ページ内のナビゲーションを助け、人々がページを読むことを助ける。ユーザーが ページ上の重要な要素を見つける助けになる場合がある。認知 障害および学習障害のある人々にとって、余白は読みにくさを軽減し、 コンテンツ理解を改善することが示されている。

ユーザーがウェブ拡張機能またはユーザー設定を通じて、オブジェクトおよびテキストの周囲の余白量も 調整できることを確保する。これは、ウェブページのコンテンツ内の重要な要素を識別する能力をサポートする。

4.4.10.4 詳細

文字、語、文、行、段落、およびテキストのまとまりの間に明確な間隔を使用する。

ボックス、段落見出し、およびコンテンツを含む、オブジェクトおよびテキストの周囲の余白を、 ユーザーに合い、ウェブページ全体の完全性を損なわない程度に簡単に調整できるようにする。 重要なコンテンツがスクロールなしで見えなくなるほど多くの余白を追加しない。

“white space” は背景色を意味する用語であることに注意。常に白である必要はない!

4.4.10.5 例

使用する:

1. コンテンツの別々の節の周囲の余白。

避ける:

1. 密なページ。

4.4.11.1 ユーザーニーズ

コンテンツを容易に知覚する必要がある。例:

• 背景が単純であるため、テキストが明確である。
• メディアに気を散らす背景ノイズがない。

関連ユーザーストーリー: 視覚的提示。

4.4.11.3 どのように役立つか

文を句ごとに読むことは、個々の語を読むよりも多くの意味を伝える。句は理解もしやすい。 個人が一度の視線で処理できる語が多いほど、より速く読め、書かれていることをより理解しやすくなり、 興味を保ちやすくなる。ほとんどの人は、1行全体のテキスト、またはそれ以上を一度に取り込むことができる。 多くの人にとって、理解のためには一度に多くの語に視線を固定することが必要である。読むのが遅い人は、 6から9回の視線固定を使って文をゆっくり読む場合があり、ときには1語（または語の一部）だけを 一度に取り込む。背景を追加すると、読者が視線を固定できる語の数が減る。背景を取り除くと、 ユーザーは同時により多くの語を理解できる。

また、自動的な語認識は読解のためにしばしば使用される。たとえば、英語には従来の文字音パターンに 合わない語が約200語存在する。これらの語は記憶され、自動的に認識されなければならない。 ユーザーがこれらの語を認識できない場合、テキストは理解しにくくなる。背景は、ユーザーが 語を認識するのにかかる時間を増やす可能性がある。

同様に、音声トラック内の背景ノイズは、主なコンテンツの処理および理解を難しくする可能性がある。

4.4.11.4 例

使用する:

1. 認識しやすい語、および背景から容易に区別できるコンテンツ。

避ける:

1. “語の認識および テキスト処理を難しくする、テキスト背後の背景”のような、テキストを読みにくくする可能性がある背景。

4.4.12.1 ユーザーニーズ

テキストの意味を理解する必要がある。冗談や比喩を誤解する可能性があるため、説明されていない、 暗示的、または曖昧な情報は望まない。

関連ユーザーストーリー: 視覚的提示。

4.4.12.3 どのように役立つか

暗示されたコンテンツは、意味が明確でないため、一部のユーザーにとって難しい場合がある。 これには、抽象的なコンテンツ、皮肉、または比喩が含まれる。意味は明確でなく、理解するために ユーザーが追加知識を持つことを要求する。

何かを伝える唯一の方法として、身体の身振り、感情的コミュニケーション、および表情を使用する場合、 すべてのユーザーが理解できるように、これを別の方法で含めることが重要である。これを行う1つの方法は、 補足テキストを通じてである。

たとえば、ソーシャルメディア投稿で、人の本当の感情を伝えるために画像が使用される。 一部の個人は、その画像によって示されている感情を理解できない場合がある。より多くの文脈がないと、 作者が伝えようとしている要点を見逃す。

同様に、ある研究では、自閉症 の人々に、暗示的なコンテンツが多い映画を見るよう求めた。彼らは俳優の口元を見ていたが、 皮肉などの情報は表情によって伝えられる。映画で何が起こったか尋ねられたとき、 暗示的なコミュニケーションおよび会話の要点を見逃した人もいた。

4.4.12.4 詳細

これには次が含まれる:

• 何かが重要である、または覚えられるべきであることを識別するために単独で使用されるグラフィック、
• テキスト内の皮肉、および
• 重要性を追加したり、組み合わされたテキストの文字どおりの意味に反することを伝えたりするために使用される アニメーション。

標準的な絵文字には、説明または代替テキストが付いていることが多いことに注意。

4.4.12.5 例

使用する:

1. メールおよびソーシャルメディア投稿で皮肉なコメントを書くときに、読者がコミュニケーションの意図を 理解できるようにする（皮肉）などの補足テキスト。
2. 非文字どおりのテキスト代替を追加するための個人化セマンティクス（成熟したら）。[personalization-semantics-help-1.0] を参照。

避ける:

1. 説明のない比喩および直喩。例: “You make me happy.” と言う代わりに “You are my sunshine.” と言う。

4.4.13.1 ユーザーニーズ

数字および数値概念ではなく、語が必要である。

関連ユーザーストーリー: 数学的概念。

数字および数値概念の代替を提供する。

4.4.13.3 どのように役立つか

すべての人が数字および数値概念を理解できるわけではない。

たとえば、一部の人には、数学に特に関連する学習障害である計算障害がある。 計算障害のある人々は、数字および数学的概念について重大な問題を抱えるが、 他の知的領域ではしばしば優れている。

たとえば、計算障害のあるユーザーは、温度データが数値形式のみで提示されると処理に困難がある場合がある。 しかし、非数値の代替（寒い、暖かい、暑いなど）が提供されると、コンテンツを理解できる。

数的処理の問題は、幅広い障害によって発生する可能性があり、最も重度なものは数字を読むことまたは 理解することができないことである。他の人々は、相対的な大きさまたは時間など、任意の計算に課題を抱える。

たとえば、ユーザーは90cmsという概念を長さとして理解できる場合があるが、0.9mおよび900mmが 同じ長さであるという事実に対処するのが難しいと感じる場合がある。

別の例では、列車の時刻表に、列車が毎時に出発する相対的な時刻の一覧がある。 ユーザーは、自分の場所から次の列車がいつ出発するかを計算できない。

4.4.13.4 詳細

数学の理解がこのコンテンツを使用するための主要な要件でない場合、次のいずれかを使用する:

• 数字を非数値概念で補強する。例: 非常に寒い、寒い、涼しい、穏やか、暖かい、暑い、 非常に暑い。
• 成熟したら、非数値概念を追加するために個人化セマンティクスも使用できる。[personalization-semantics-help-1.0] を参照。

他のユーザーは、長いテキストよりも数学の方が理解しやすい場合があることに注意。

一部の数学スキルがコンテンツに不可欠な場合:

• 拡張可能なデジタル数学へ移行する（画像内の数字ではない）。
• 議論されている節の強調表示を有効にする。
• 数字の節を、一緒に読める追加ヘルプへリンクする。
• これを好むユーザーのために、数学の節を語または要約に置き換えられるようにする。

4.4.13.5 例

使用する:

1. 次のような数値コンテンツの追加サポート:
   • サイズ
   • 数量
   • 距離
   • 時間
   • 日付
   • 温度
   • 正/負
   • 計算
   • 順序付け
   • パーセンテージ。

   上記について、数字が概念として何を意味するかの説明または表現がある。

避ける:

1. 追加サポートのない数値コンテンツ

4.5.1.1 ユーザーニーズ

物がどこにあるかを知る必要がある。使用中にコントロールおよびコンテンツが予期せず動かない。

関連ユーザーストーリー: 支援およびサポート。

4.5.1.3 どのように役立つか

コントロールが動くと、手と目の協調が遅いユーザー、または認知処理速度に障害のあるユーザーは、 間違ったコントロールを押してしまう場合がある。これは望まないアクションおよびエラーを引き起こす。 ユーザーは、見当識障害、混乱、またはコンテンツの誤った理解さえ経験する場合がある。

たとえば、ユーザーが動画上のボタンを押そうと移動する。ユーザーが誤ってデバイスを少し動かす。 画面の向きが横向きに変わり、コントロールが動く。ユーザーは視線追跡または手と目の協調が遅いため、 新しい動画へのリンクを押してしまう。

コントロールおよびコンテンツの移動は、認知的過負荷を引き起こし、精神的疲労を増やす場合もある。 たとえば、外傷性脳 損傷のあるユーザーがコンテンツを読んでいると、コンテンツが更新され、現在のコンテンツの上に 追加の記事が表示される。ユーザーが読んでいる記事は下へ移動する。ユーザーは見当識を失い、 アプリケーションは使用または理解が非常に難しくなる。

4.5.1.4 詳細

コントロールが予期せず動くことには次が含まれる:

• リスト内のリンクが位置を移動すること、
• 向きの変更、および
• ユーザーが完了したと思うページの読み込みが遅いこと。

4.5.1.5 例

使用する:

1. ページの読み込みまたは更新時に動き回らないコントロールおよびコンテンツ。
2. ページの読み込み中に明確に見える読み込みアイコン。コンテンツの読み込みが完了し、それ以上の動きがない場合、 アイコンは取り除かれる。
3. ユーザーが変更を開始したときにのみ動くコントロールおよびコンテンツ。

避ける:

1. ユーザーの要求なしに動くコントロールおよびコンテンツ。例: ユーザーが電話をかけるために 電話番号を選択しようとしている。ユーザーが電話番号に触れようとした瞬間に、それが下へ移動する。 ユーザーは間違った電話番号を押し、間違った人に電話する。
2. リスト内のリンクが位置を移動すること。
3. 簡単にオフにできない向きの変更。
4. ユーザーが完了したと思う、読み込みの遅いページ。

4.5.2.1 ユーザーニーズ

間違いをする前に自分がどこにいたかを正確に知ることができるように、予測可能な戻る機能または 元に戻す機能が必要である。

関連ユーザーストーリー: 元に戻す。

4.5.2.3 どのように役立つか

ユーザーが前の地点へ戻れるようにすることは、間違いを防ぐ助けとなり、間違いが起きたときに 修正しやすくする。

間違いの例には次が含まれる:

• 誤ってコントロールに触れる、
• 誤って新しいリンクを開く、および
• ユーザーが開いたままにしたかったウィンドウを閉じる。

人が簡単に間違いをしたり、頻繁に間違いをしたりする場合、作業または以前の選択が削除されることなく、 戻って変更できることが重要である。

たとえば、ユーザーが動画を見ている。音量を上げようとしたが、代わりに別のリンクに触れる。 新しい動画が読み込まれる。ユーザーは戻るボタンを押して、以前見ていた動画に戻ることができる。 これにより、音量を上げようとして間違えても、簡単に戻って再試行できることが分かる。

別の例では、戻るボタンが期待どおりに機能せず、別の場所（ホームページなど）へ移動した。 音量を変更したりコメントを追加したりしようとすると、見ていた動画を失うことが多く、戻る方法を 見つけられない。ユーザーは、メインコンテンツを再び失う恐れがあるため、ウェブサイトのどの機能も 使用できないと感じるようになる。画面を拡大したり、音量を変更したり、コメントを残したりしない。

フォームでは、ユーザーがデータを再入力するたびに、新しい間違いが発生する可能性が生じる。 データの入力および再入力は、認知 障害および学習障害のある一部の人々にとって、ストレスが多く疲れる場合がある。 これは間違いの可能性を高め、正しいデータを送信して意図したタスクを完了することを不可能にする場合がある。

不安、記憶の課題、および指示に従うことの困難がある人にとって、戻って入力した情報を確認できる能力は 非常に重要である。たとえば、一部の人にとっては、指示に従うタスクと回答を確認するタスクを 2つの別々のタスクとして行う方が最もうまくいく。指示に従うことに集中して情報を入力し、 後で戻って回答を確認できることは、その人がより効果的に行動する助けとなる。

4.5.2.4 始め方

誤って送信した場合でも、ユーザーが戻って入力したデータを確認する機会を持つ。戻るボタンは常に期待どおりに機能する。

4.5.2.5 詳細

ユーザーが戻ることをサポートする選択肢には次が含まれる:

• 明確にラベル付けされたアクションによって、ユーザージャーニー内のステップを戻る。
• クリック可能な前のステップを持ち、データの損失がない、クリック可能なパンくずリストを使用する。
• 望まないデータ損失なしに、戻る機能および元に戻す機能を使用する。
• 成熟したら、個人化セマンティクスを使用してステップを記録し、プロセス内のステップに戻ることもできる。 [personalization-semantics-1.0]を参照。
• 閉じたウィンドウまたは選択肢を再び開く。

4.5.2.6 例

使用する:

1. 戻りやすくするデザイン。例:
   • ユーザーが動画を見ている。誤ってコントロールに触れる。戻るを押すと、 同じ位置の動画へ戻ることができる。
   • ユーザーが求人応募のオンラインフォームを完了している。ユーザーが誤ってホームアイコンを押し、 フォームから離れる。戻るボタンは、データ損失なしに、元いた場所へ戻す。
   • ユーザーはまた、節を誤解したり回答を飛ばしたりしていないことを確認するために、 すべての画面を戻ることができる。ユーザーは入力を誤った任意のデータを編集できる。

避ける:

1. 戻りにくくするデザイン。例:
   • ユーザーが動画を見ている。誤ってコントロールに触れ、新しい動画へ移動する。 戻るを押すと新しい動画が小さくなるだけで、元の動画へ戻らない。
   • 求人応募のオンラインフォームを完了している。ユーザーは質問に回答し忘れていないか確認するために 画面へ戻る。戻るボタンを使用すると、以前に入力したすべてのデータが消去/削除されている。

4.5.3.1 ユーザーニーズ

開始前に必要となる情報（クレジットカード、完全な住所など）を知らせるなど、 タスクを管理するためのサポートが必要である。

関連ユーザーストーリー: 支援およびサポート。

4.5.3.3 どのように役立つか

記憶、細部への注意、または読解に困難がある認知 障害および学習障害のあるユーザーは、取引タスクの開始時に明示的に記載されない限り、 料金に気づかない場合がある。利用規約はリンクの下に置くことができるが、料金は明確に表示され、 理解しやすい 言語で利用可能でなければならない。

販売の開始時に料金を明確に識別することは、すべてのユーザーに役立つ。認知 障害および学習障害のある人々には、特に有益である。一部のグループは、料金が含まれることを 推測または予想する可能性が低いためである。ホームページや指定された料金ページなど、ユーザーフロー内の 他の場所を見るべきだと知らない場合がある。

実行 機能または記憶に障害のある人々は、情報に基づく決定を行えるように、すべての結果を 整然とした形式で提示してもらう必要がある。料金が明確でない場合、取引への同意は不明確である。

また、障害のあるユーザーが購入プロセスを進めるには、はるかに長い時間がかかる場合がある。 ある人がオンライン購入に何時間も費やした後で、それを支払えないことを知るのは、非常に困難で 動揺することである。その人は価格を理解できなかったことを自分のせいにすることが多く、自信を失う場合がある。 オンラインの日常的な活動で自分自身を信頼しなくなる場合がある。

たとえば、実行 機能に課題がある人が航空券を注文しようとしており、税金、国際手数料、手荷物料金など、 元の価格に引用されていない追加料金があることに気づかない場合がある。休日旅行の予約に何時間も費やした後で、 支払えないことを知る場合がある。あるいは、支払えないものを購入してしまうこともある。また、 過去にこのプロセスを完了していたとしても、その経験を使用して最終価格を予測できない場合がある。 その結果、ユーザーはオンラインで独立して休日旅行を購入する能力への自信を失う。支払えない借金を抱えたり、 再び試みなくなったり、雇われた専門家（例: 旅行代理店またはアシスタント）の助けがある場合にのみ試みたりする。

4.5.3.4 例

使用する:

1. 明確に述べられた料金。ユーザーは、商品を購入してショッピングカートに入れることを決めるときに、 すべての料金を認識し、情報に基づく決定を行える。
2. 可能な料金範囲の明確な記載。送料が変動する商品については、送料の範囲および料金を変える要因を、 詳細を見つけられる場所へのリンクとともに列挙する。たとえば、重量および配送速度は送料に影響する場合があり、 所在地に応じて送料は$4から$400の間になる。
3. 予期しない条件がない。

避ける:

1. 予想より高い総料金をもたらす、新しい料金または隠れた手数料を含む最終取引。
2. タスクの開始時からユーザーに明確でない購入条件を含む最終取引。
3. ユーザーが販売に多くの労力を投じるまで知らなかった料金または条件を含む取引。
4. 総費用でユーザーを驚かせる完了済み取引。

4.5.4.1 ユーザーニーズ

間違いを避ける助けとなるインターフェイスが必要である。

関連ユーザーストーリー: 支援およびサポート。

4.5.4.3 どのように役立つか

多くのエラーを起こした後、認知 障害および学習障害のある人々、ならびに加齢に 関連する物忘れのあるユーザーは、タスクを放棄し、自分には完了できないと考えることが多い。 エラーメッセージは混乱を招く場合がある。エラーの修正は、ユーザーにとってしばしば難しく苛立たしいものであり、 認知的疲労を増やす。連続したエラーを受けると、多くのユーザーは停止する必要がある。

たとえば、オンライン銀行口座の登録時に、フォームがユーザーの生年月日の入力を要求する。 必須の入力形式は、1桁には先頭ゼロを付けたxx/xx/xxxxである。入力補正なしの単一入力フィールドが 提示された場合、認知障害のあるユーザーは1/3/1996と入力し、エラー通知を引き起こす場合がある。 必須形式が01/03/1996であることは、（入力フィールドの下またはエラー通知に形式が示されていても） ユーザーに明確でない場合がある。

よく設計されたフォームは、情報を入力しやすくし、正しい日付形式を自動的に修正または提案することで、 ユーザーが間違いを起こすことを防ぐ。

ユーザーが生成するエラーを自動的に修正して最小化することは、エラー通知も最小化する。 エラー通知は疲れさせたり気を散らしたりする場合があり、タスクおよびタスク完了からフォーカスを奪う。

4.5.4.4 詳細

• 必須コンテンツを明確にマークする。
• 修正が信頼できる場合にのみ、エラーを修正する。そうでない場合、修正候補が既知であれば、 その候補をユーザーに提示する。
  • たとえば、「2月1日（01/02）を意味していますか、それとも1月2日（02/01）を意味していますか?」
• カレンダーおよび日付。
  • カレンダーは、最初の関連日を既定にするべきである。業務カレンダーは、 ユーザーのロケールの最初の営業日を既定にするべきである。
  • カレンダーベースの予約システムは、ユーザーが出発日より前の帰着日を予約することを防がなければならない。
• 温度。
  • ユーザーの所在地の既定の温度形式を使用する。

4.5.4.5 例

使用する:

間違いを起こしにくくするデザイン。例:

• 市または州の情報を含むテキストフィールドに書かれた郵便番号のエラーを修正する。
• ユーザーが不適切な日付を選択することを防ぎ、そうしようとした場合には単純な説明を提供する。

避ける:

間違いを起こしやすくするデザイン。例:

• 予約フォームが、明確なラベルおよび指示なしに2つのカレンダーを提供する。 フォームは、選択した日付が可能かどうかについて警告せずに、ユーザーが日付を選択できるようにしている。 例: 6月1日に出発 - 5月30日に帰着。
• システムが、警告なしにユーザーが不適切な日付を選択できるようにしている。カレンダーは 不適切な日付を単にグレー表示するだけで、気づかれない場合がある。警告は提供されない。

4.5.5.1 ユーザーニーズ

直前に行った作業を失うことなく、自分の作業を確認して戻る必要がある。

関連ユーザーストーリー: 元に戻す。

4.5.5.3 どのように役立つか

認知 障害および学習障害のある人々は、一般集団よりもフォーム入力で非常に多くの 間違いを起こす。間違いを簡単に修正できない場合、タスクを完了できない。

エラーを元に戻せる能力は、認知 障害および学習障害のある人々がフォームを安全に使用する助けとなり、 間違いから生じる結果を減らす。

たとえば、記憶障害のあるユーザーは、すでに商品をショッピングカートに追加したことを覚えておらず、 その商品を2回目に追加してしまう場合がある。旅行予約時に日付を混同したり、その他の間違いをしたりする場合がある。

認知 障害および学習障害のある人々が、自分の作業を確認し、間違いを簡単に修正する機会を持つことは 不可欠である。

認知 障害および学習障害のある人々にとって、間違いが理論上は元に戻せるだけでは十分でない。 多くの場合、取引を取り消すプロセスは、その人が助けなしで管理するには複雑すぎる。 その助けにアクセスできない場合があり、そうなると行ったすべての間違いを抱えて生きなければならない。 さらに、間違いを修正するプロセスが難しすぎる場合、ユーザーは停止し、取引を失うか、 望まない商品を購入してしまう可能性がある。

これが複数回起こる影響は壊滅的である。その結果、障害のある多くのユーザーは、 多くのタスクでインターネットの使用をやめる場合がある。

ユーザーがいつでもショッピングカート内の商品数を変更できるようにすることは、 間違いを大幅に減らすことができる。

最終送信前に、商品数量およびその他の費用を含む注文の要約を提供することで、 ユーザーは任意のエラーを識別し、注文を変更する機会を得る。この例では、 購入の要約により、ユーザーは数量のエラーと予想より高い注文合計の両方を確認できる。

場合によっては、ユーザーはデータの最終送信後に間違いがあったことに気づく場合がある。 取引をキャンセルする方法について単純な言語の指示を提供し、取引をキャンセルするために必要な 時間をユーザーが理解できるように支援する。これにより、詐欺に遭いやすくなることを減らす。

たとえば、注意欠如・多動症のあるユーザーがウェブサイトで旅行チケットを購入する場合、 細部に苦労し、注意持続時間に障害がある場合がある。注文の成功は、プロセス内の複数のステップで 提供される情報に依存する。請求先住所の番地または郵便番号の誤りなどのエラーがあると、 注文は通らない。最終注文を送信する前に要約が提供されない場合、ユーザーは支払い拒否の理由を 理解できず、注文を諦める場合がある。ユーザーは、修正するための明確で達成可能な方法がない場合にも 停止する可能性がある。

4.5.5.4 詳細

これには通常、次が含まれる:

• 変更: 自動的に識別されない可能性がある間違いを含め、ユーザーがすべてのデータを確認し、 間違いを修正することは単純である。ユーザーは明確にラベル付けされたアクションを通じて情報を変更し、 望まないデータ損失なしに、1つの明確にラベル付けされたアクションで元いた場所へ戻ることができる。 （変更された項目に依存する場合、一部のデータは入力し直す必要がある場合がある。）
• 確認済み: 重要な情報を送信する前に要約が提供され、ユーザーは最終情報を送信しようとしていることを 伝えられる。
• 取引をキャンセルするための時間枠および指示は明確で、従いやすい。

4.5.5.5 始め方

金銭的損失または脆弱性など、間違いが深刻な結果をもたらす可能性があるフォームから始める。

4.5.5.6 例

使用する:

• 重要な情報を送信する前に提供される要約。これにより、ユーザーは情報を修正し、 1クリックで要約へ戻ることができる。
• ユーザーが前のステップを見て、戻り、変更できるクリック可能なパンくずリスト。

避ける:

• 重要な情報を送信する前に要約が提供されるが、ユーザーが入力済みの他のデータを失うことなく 修正できない。

4.5.6.1 ユーザーニーズ

明確なラベル、ステップごとの指示、および明確なエラーメッセージが必要である。

関連ユーザーストーリー: 支援およびサポート。

4.5.6.3 どのように役立つか

ラベルがない、または不明確な場合、ユーザーはその機能が利用可能であること、またはコントロールが何であるかを 知らないことが多い。多くのユーザーはコントロールの目的を推測できるが、記憶または実行 機能に障害のある認知 障害および学習障害のあるユーザーは、デザインパターンを覚えたり、それが何であるかを理解したりする 可能性が低い。なじみのある用語を使用し、コントロールの隣に配置された明確なラベルは、 認知 障害および学習障害のある人々を助ける。

同様に、ラベルがコントロールの隣にない場合、一部のユーザーにとって混乱を招く。ラベルをコントロールの 隣に置けない場合、ラベルをコントロールと視覚的かつ曖昧でなく関連付ける明確な視覚的インジケーターが あるべきである。これが使用可能であることを確保するために、学習障害および認知 障害のあるユーザーとのユーザーテストが必要になる。

たとえば、早期認知症とともに暮らすユーザーが アプリケーションを使用している。一部のコントロールには視覚的ラベルがない。介護者がそのコントロールの目的を 示すと、そのユーザーはアプリケーションを使用できる。翌日、再び使おうとするが、そのコントロールの目的を 思い出せない。このアプリケーションはその人にとって使用可能ではない。

別の例では、フォーカスが外れるとラベルが消える。ユーザーはコントロールが何であるかを覚えられず、 それを再表示する方法も分からない。

ラベルは表示され、支援技術によって読め、ラベル付けされたコンテンツの近くにある必要がある。

4.5.6.4 詳細

認知 障害および学習障害のある多くの人々は、ウェブ拡張機能および単純なテキスト読み上げを使用する。 これらの支援技術は、多くの場合、WAI-ARIA [wai-aria-1.2]または titleを読み上げない。それが変わるまで、または拡張機能がそれらを表示するまで、ラベルは 認知 障害および学習障害のある人々のために、これらの属性に依存するべきではない。

4.5.6.5 例

使用する:

1. 単純で一般的な語を使用し、コントロールの隣にある可視ラベル。例:
   • first name ____________________

避ける:

1. 隠されたラベル、または理解しにくい一般的でない語を使用するラベル。必要なアクションが不明確である。 例:
   • given name ___________________

4.5.7.1 ユーザーニーズ

何をすべきか正確に分かるように、明確なラベル、ステップごとの指示、および明確なエラーメッセージが必要である。

関連ユーザーストーリー: 支援およびサポート。

4.5.7.3 どのように役立つか

明確な指示はユーザーエラーを防ぐ助けとなる。これは苛立ちを減らし、ユーザーの自律性および独立性を高める。 ヘルプを求めることを避けられるためである。これは認知 障害および学習障害のある多くの人々だけでなく、異なる文化の人々、新興市場の人々、 ウェブフォームになじみがない、または文化的文脈を見逃す可能性がある新しいユーザーにも役立つ。

たとえば、加齢に 関連する物忘れのある人がフォームを完了しようとしている。その人は（手紙を書くときのように） 住所全体およびzipまたは郵便番号を1行に入れる。エラーメッセージが表示される。数回のエラーメッセージの後、 その人は疲れ果て、フォームを完了できない。

4.5.7.4 詳細

単にエラーメッセージ内ではなく、プロセスの開始時に指示を提供する。

ユーザーがタスクを完了できるようにするために必要な指示を提供する。複数の形式が受け入れられる場合、 またはエラーが自動的に修正される場合、ユーザーがタスクを完了するために必要な指示は少なくなる。

指示はなじみのあるアイコンの背後に隠すことができることに注意。

4.5.7.5 始め方

よくあるエラーを持つシステムでは、最も影響の大きいエラーに最初に取り組み、必要に応じて指針を追加する。

4.5.7.6 例

使用する:

1. 明確で理解しやすい指示。例:
   • ユーザーが入力すべき番号を示すために、その番号を強調表示したパスポートの画像を提供する。
   • カレンダーコントロールで、週の開始日（例: 日曜日または月曜日）を明示的に述べる。

避ける:

1. 複雑なタスクについて明確な指示がないこと。例:
   • パスポート番号を要求するが、パスポート上のいくつかの番号のうちどれが必要かを示さない。
   • サイトが週の最初の日を明確にせず、業務週が月曜日に始まると仮定する。異なる文化のユーザーは、 業務週が日曜日に始まると仮定し、間違いをする。

4.5.8.1 ユーザーニーズ

入力が異なる形式を受け入れ、それらを間違いとして扱わない必要がある。

関連ユーザーストーリー: 支援およびサポート。

4.5.8.3 どのように役立つか

許容的なフォーム入力プロセスは、圧倒的な量のエラーなしに、ユーザーがフォームに入力する助けとなる。 エラーによって問題が生じるときに、ヘルプを求めることを避けられる。これは、ユーザーの自律性および 独立性を高めながら、苛立ちを減らす。

これは、学習障害および認知障害のある人、または加齢に 関連する物忘れのある人に役立つ。また、異なる形式に慣れている任意の人にも役立つ。

たとえば、加齢に 関連する物忘れのあるユーザーが、ハイフンを挿入して自分の電話番号を入力する。 システムがその形式を受け入れないため、エラーメッセージを受け取る。電話番号を忘れたのか、 それとも別の間違いをしたのかと不安になる。そのユーザーはフォームの使用を試みることをやめる。

4.5.8.4 例

使用する:

1. 柔軟な入力型および検証のためのプラットフォーム機能。
2. 国際的なバリエーションを含め、入力される可能性のある異なる形式の調査およびサポート。
3. 最小限の必須フィールド。
4. 異なる形式を受け入れる柔軟な入力フィールド。たとえば、次を受け入れる入力フィールド:
   • さまざまな通貨記号、
   • 空白の有無にかかわらないクレジットカード番号、
   • 任意の括弧を使用した国コード、地域コード、および番号を含む、多くの地域で書かれる電話番号、および
   • アクセント付き文字などの国際文字。

避ける:

1. 入力を恣意的な長さに制限すること。
2. 不要で無視できる場合に、特定の区切り文字にこだわること。
3. ユーザーが使用する可能性のある形式を受け入れない入力フィールド。例:
   • ユーザーの通貨でない可能性がある特定の通貨値を使用することをユーザーに強制する。
   • カードには空白付きで番号が印刷されているにもかかわらず、空白なしを要求するクレジット番号フィールド。
   • 電話番号フィールドが+コードまたは括弧を受け入れない。

4.5.9.1 ユーザーニーズ

作業を完了する時間が必要である。郵便番号や社会保障番号など、必要な情報を探している間に セッションがタイムアウトしてほしくない。

関連ユーザーストーリー: 支援およびサポート。

4.5.9.2 行うべきこと

タイムアウトを避け、ユーザーが進めながら作業を保存できるようにする。

これが不可能な場合は、ユーザーがプロセスを開始するときに次を知らせる:

• プロセスを完了するために利用可能な時間、
• タイムアウトが発生した場合に、入力済みデータが失われるかどうか。

4.5.9.3 どのように役立つか

時間制限のあるイベントは、認知 障害および学習障害のあるユーザーにとって重大な障壁となり得る。これらのユーザーは、 コンテンツを読んだり、オンラインフォームの完了などの機能を実行したりするために、より多くの時間を 必要とする場合がある。ヘルプを読んだりメモを見たりする必要がある場合もある。

認知 障害および学習障害のあるユーザーは、取引を完了するために必要な情報を調べるための 追加時間を必要とする場合がある。プロセス内の位置を失わず、すでに入力したデータを失わずに、 休憩を必要とする場合がある。

たとえば、eコマースサイトで購入を行うとき、ユーザーが必要な情報を覚えていない。 これは日付、電話番号、またはzipコードである場合があり、認知障害または学習障害のないユーザーには 覚えやすいように思える場合がある。そのユーザーはこの情報を調べる必要があり、画面から離れる時間がかかる。 その後、それをフォームに慎重にコピーする必要がある。

別の例では、ユーザーがホテルの部屋を予約し、航空券を購入するためのオンラインプロセスを完了している。 プロセスを完了するために必要な指示およびデータ入力の量に圧倒される。ユーザーは1回でプロセスを 完了できず、休憩を取る。

ユーザーの認知スキルは、疲れるにつれて低下する場合がある。その場合、その日のタスクを停止しなければならない。 データが失われないことをユーザーが知っていれば、精神的疲労から回復し、戻ってタスクを正常に完了できる。

多くの人々は「タイムアウト」通知を読む時間を必要とすることに注意することが重要である。 多くの場合、時間を延長する方法について読み終える前に、セッションが終了する。ユーザーが情報を調べている場合、 タイムアウト通知を見ることはない。

4.5.9.4 詳細

クレジットカード情報などの機密情報が入力または表示されるためにウェブサイトがタイムアウトしなければならない場合、 ウェブサイトは最後の段階で機密情報を求めるべきである。

ウェブサイトはまた、クレジットカード情報を提供した後はセッションがタイムアウトする可能性があるため、 プロセスをすばやく完了すべきであることをユーザーに警告するべきである。

4.5.9.5 例

使用する:

1. 可能な場合は無制限の時間。
2. 学習障害および認知障害のあるユーザーが簡単に避けられるタイムアウト。例: タスクの開始時に、 ユーザーはタスクを完了するために1日あることを伝えられる。より長く設定する選択肢がある。
3. タイムアウトが必要な場合:
   1. タスクの開始時のタイムアウト警告。 例: オークションでは、 ユーザーが入札を送信できる時間に制限がある。タスクの開始時に、ユーザーは時間制限と、 時間が終了するまでどれだけあるかについて警告される。
   2. 可能かつ安全な場合、ユーザーの作業は失われない。 例: 機密情報を持つ ウェブサイトは、コンピューターから離れる可能性があるユーザーを保護するために、クライアント側の 時間制限を使用する。ユーザーが再度ログインすると、すべての作業はそのまま残っている。 ユーザーは、非アクティブセッションにどれだけ時間があるかを事前に警告され、データは失われないと 伝えられる。

避ける:

1. セキュリティに必要でないシステムタイムアウト。
2. プロセスの開始時にユーザーへ警告しないシステムタイムアウト。
3. セキュリティまたはプライバシー上のリスクでないにもかかわらず、ユーザーが作業を失うシステムタイムアウト。

4.5.10.1 ユーザーニーズ

イベントが正常にトリガーされたことを示す迅速なフィードバックまたは視覚的手がかりが必要である。 たとえば、メールが送信されたことを知る必要がある。そうでなければ、ただ消えたように見える。

関連ユーザーストーリー: 支援およびサポート。

4.5.10.3 どのように役立つか

• 自分のアクションが処理されたことを理解する（例: クリックが何かを行った）、
• 結果についての不確実性または疑念を防ぐ、および
• 直前に何をしたかを思い出す。

たとえば、加齢に 関連する物忘れのあるユーザーは、インターフェイスがどのように機能したかを思い出すことに困難がある場合がある。 そのため、送信ボタンを押したときに、フォームが送信されたと確信できない場合がある。ありがとうメッセージなどの フィードバックは、送信が行われたことを伝え、プロセスに自信を持たせる。

複数ステップのタスク中、このフィードバック（ユーザーアクションフィードバック）は、注意または短期の認知 障害および学習障害のある人々が、自分が何をしているかを覚えることも支援できる。 たとえば、早期認知症のあるユーザーは、気が散って、タスク内で正確にどこにいたかを忘れる場合がある。 このユーザーアクションフィードバックは、その人の再方向づけを助ける。また、プロセス中であること、 そして現在プロセス内のどこにいるかを思い出させることで、タスクから離れることを避ける助けにもなる。

すべてのユーザーアクションに対して、容易に認識できる成功または失敗のフィードバックを提供する。 可能な場合、フィードバックは一貫した、なじみのあるデザインパターンを使用するべきである。例:

• 複数ステップのタスク内のステップが完了した後、パンくずリストがそのステップ名の隣に チェックまたはチェックマークを表示する。また、該当する場合、次のステップのタイトルまたは名前が すぐに明らかである。
• ボタンがクリックされた後、押し込まれたように見えるべきである。（トグルボタンである場合、 状態もプログラム的に判別可能であるべきであることに注意。）
• フォームが送信された後、またはメールメッセージが送信された後、“Your application was submitted, thank you” または “Your email message was sent” など、直前に起こったことを伝えるフィードバックが提供される。

4.5.10.4 詳細

ユーザーが開始したすべてのアクションの成功または失敗は、コンテンツの主要なモダリティにおいて、 視覚的、プログラム的に判別可能、かつ迅速なフィードバックによって、ユーザーに明確に示される。 音声フィードバックがサポートされる。

4.5.10.5 例

使用する:

1. 視覚的な状態フィードバック。CSSおよびWAI-ARIA [wai-aria-1.2] のaria-pressedおよびaria-selectedなどの状態を使用し、状態の変化を示す視覚的変化を与える。 例: 選択時に視覚的に明確な状態を持つボタンおよびタブ。
2. タスクが完了したかどうかをユーザーに知らせるメッセージ。例:
   • メールメッセージが正常に送信された、またはフォームが正常に送信されたときの確認メッセージ。
   • 新しいパスワードが設定されたことを示す、表示され、プログラム的に判別可能な情報。

避ける:

1. 視覚的フィードバックのない状態変化。
2. フィードバックなしにタスクが成功または失敗すること。

4.5.11.1 ユーザーニーズ

ウェブサイトを使用するとき、特に情報を提供したり他者とコミュニケーションしたりする場合に、 自分が安全かつ保護されていることを知る必要がある。

関連ユーザーストーリー: 支援およびサポート。

4.5.11.3 どのように役立つか

ユーザーは、ウェブサイトを使用するとき、特に情報を提供したり他者とコミュニケーションしたりするときに、 自分が安全かつ保護されていることを知る必要がある。

実行 機能に障害のあるユーザーは、リスクを正しく識別する可能性が低いため、潜在的なリスクを 明確に識別することは、ユーザーが安全で制御下にある状態を保つ助けとなる。 コンテンツを使用する間に安全を保つための役立つヒントを追加し、問題が発生した場合のヘルプを提供する。

リスクを識別する助けとして、認知 障害および学習障害のある人々との研究およびフォーカスグループを開催し、潜在的および既存の問題を 解決するために認知障害および学習障害のある人々と協働することを提案する。グループは、 セキュリティおよびリスク軽減に取り組むとき、学習障害および認知障害のある人々を念頭に置くべきである。

たとえば、パスワードをコピー&ペーストできない、または2段階認証コードを使用できない多くの人々は、 介護者に助けを求める。介護者はしばしば一時的な従業員にすぎないため、これはユーザーを危険にさらす。 パスワードを長くしたり、ユーザーに定期的な変更を要求したりすることは、これらの安全でない慣行を増やし、 実際にはアプリケーションの安全性を低下させる可能性がある。この種のデザインエラーは、 認知 障害および学習障害のある人々がユーザー調査および分析から除外されているときによく発生する。

4.5.11.4 例

使用する:

1. 管轄区域において機密データのために承認されたセキュリティ技法であり、学習障害または認知障害のある人々と テストされた代替ログイン選択肢。
2. リスクおよびそれが個人情報にどのように関連し得るかを理解するために、学習障害および認知障害のある 幅広い人々と話す。
3. 調査、開発、および要件フェーズにおけるCOGAペルソナおよびユースケース。
4. ユーザー情報の保存および保護に関する業界のベストプラクティス。
5. 理解しやすい 言語で書かれ、学習障害および認知障害のある人々がリスクを理解することを確保するために テストされた同意フォーム。
6. 個人情報が提供される可能性があるたびに、理解しやすい 言語でユーザーに警告する。

避ける:

1. すべてのリスクを理解しないまま、ユーザーが情報を共有すること。
2. リスクに関する隠された、混乱させる情報。
3. ユーザーが一度同意し、現在直面しているリスクを忘れること。
4. ユーザーが理解できない可能性がある同意フォーム。

4.5.12.1 ユーザーニーズ

インターフェイスは、自分が知っており、自分の地域で一般的な尺度（フィートやメートルなど）を使用する必要がある。 そうでなければ混乱する。どの尺度について話しているのか常に分かるわけではなく、 数字がおかしく見えることに気づかない場合がある。

関連ユーザーストーリー: 支援およびサポート。

4.5.12.3 どのように役立つか

ほとんどの人は、自分の場所または文化で尺度に一般的に使用される単一の単位体系になじみがある。 尺度が他の単位で示されると、それを理解するために変換を行う必要がある。電卓のようなツールでさえ 管理が難しい場合がある。単位を変更する選択肢を提供し、ユーザーの所在地に合わせて単位を既定にする。 一般的な例には、距離、重量、面積、通貨、および温度に使用される単位がある。

たとえば、ユーザーは摂氏の温度を知っている場合がある。それが華氏で示されると、 非常に暖かくなると考えてしまう。

4.5.12.4 詳細

ローカライズされた代替が利用可能な場合でも、尺度が特定の単位で一般的に示されることがある。 たとえば、テレビまたはモニターのサイズは、センチメートルが一般的な単位であっても通常インチで示される。 しかし、このような場合でも、ユーザーが示された尺度になじみがない可能性があるため、代替を提供することは 依然として有用である。

4.5.12.5 始め方

ユーザーにとってより意味のある別の尺度セットを選択する仕組みを提供するか、 テキスト内に一般的な代替を提供する

4.5.12.6 例

使用する:

1. 異なるユーザーが理解する異なる単位での尺度。例:
   • エッフェル塔は、頂部のアンテナを含めて高さ1,063フィート（324メートル）である。

避ける:

1. 尺度に1つの単位のみを使用すること。例:
   • エッフェル塔は高さ1,063フィートである。

4.6.1.1 ユーザーニーズ

タスクに気を散らすものがない必要がある。

関連ユーザーストーリー: 気を散らすもの。

4.6.1.3 どのように役立つか

中断は、記憶または注意に障害のある人々がタスクを完了することを妨げる。これには、認知症のある人、 脳卒中または脳 損傷を経験した人、および記憶または注意に影響する副作用を持つ薬を服用している人が含まれる。 特定の種類の中断、または一定数の中断により、タスクが非常に重要であっても停止してしまう場合がある。 中断には、音、視覚的に表示または変化するコンテンツ（ページ上の広告など）が含まれる場合がある。 中断は、共有オンライン文書で作業している間に新しい変更があることを知らせるテキスト通知のように単純な場合もある。

記憶または注意に課題がある人々にとって、サイトは次を備えている場合に最もよく機能する:

• 静かで単純な環境、
• 中断がまったくないこと、
• 中断および動くコンテンツを後で見られるようにする、使いやすい一時停止選択肢、または
• ユーザーがどの種類の中断をいつ管理できるかを選択できる設定。

多くのニュースサイトには、悪天候による学校閉鎖などの重要な情報を読む必要がある人々にとって 課題となる、多くの中断がある。速報テキスト、広告、およびポップアップウィンドウに遭遇する場合がある。 集中し、学校名をふるい分けることが難しい人、または確認する必要がある学校が2つまたは3つある人にとって、 これらの気を散らすものはタスクを不可能にする場合がある。ユーザーがこれらの気を散らすものを一時停止し、 理想的にはページから一時的に取り除けるようにすることで、タスクをよりよく完了できる。

一部の人々は騒音に敏感であり、刺激が多すぎると簡単に圧倒される場合がある。

場合によっては、騒音および異なる種類のコンテンツがメンタル ヘルスに悪影響を及ぼす可能性がある。たとえば、騒音、気を散らすもの、または苦痛を与えるコンテンツは、 ユーザーをより不安にしたり、心的外傷後ストレス障害（PTSD）を引き起こしたりする可能性がある。 中断が多すぎることやソーシャルメディアの使用が、抑うつおよび集中困難を悪化させる可能性があることを示唆する 研究もある。ユーザーがこのコンテンツを制御できるようにすることで、オンラインでより生産的になれる可能性がある。

気を散らすものを取り除く、または制御するための標準技法が存在する場合、それらを使用するべきである。

たとえば、外傷性脳 損傷のある人がオンラインで税金を申告している。 ソーシャルメディアアプリケーションが通知音を鳴らす。通知をオフにしようとし、次にアプリケーションを オフにしようとするが、複雑すぎる。助けなしでは税金を提出できない。

4.6.1.4 例

使用する:

1. 中断のないタスク。
2. 必要になる可能性がある中断を制御する簡単な方法。例:
   • アプリケーションは、リマインダーおよびメールについて、どのように通知されたいかをユーザーが決められるようにする。 ユーザーは、視覚的リマインダー、音、または通知なしを選択できる。ほとんどの場合に中断できる 必須連絡先としてユーザーにフラグを付けることができる。これらの設定はすべての画面から見つけやすい。 一部のユーザーにとって、通知がまったくないことは、タスクに集中し、タスク完了後にメールまたは カレンダーへ移動することを可能にする。

避ける:

1. オフにすることが難しい、またはオフにできない気を散らすコンテンツ。例:
   • 雑誌記事ページに、絶えず変化して読者の集中を妨げる広告がある。
2. ユーザーがタスクを完了することを中断するコンテンツ。例:
   • ユーザーにサイト登録を提案するポップアップ。ユーザーが続けるには、そのポップアップを閉じなければならない。

4.6.2.1 ユーザーニーズ

機能およびコンテンツを容易に見つけられる必要がある。

関連ユーザーストーリー: 気を散らすもの。

4.6.2.3 どのように役立つか

プロセスおよびワークフローを効率化することは、気を散らすもの、間違い、および精神的疲労を減らす。 短いクリティカルパスを使用することは、認知 障害および学習障害のあるユーザーが、プロセスまたはタスクを正常かつ正確に完了し、 ワークフローをナビゲートできる可能性を高める。

たとえば、早期認知症のあるユーザーが 新しい電話を購入しようとしている。支払う前に、ヘッドホンおよびその他の商品を提案するステップが追加される。 そのユーザーは圧倒され混乱する。電話を購入せずにサイトを離れる。

4.6.2.4 例

使用する:

1. 必要なステップだけを要求するプロセス。
   • 例: 映画チケットをオンラインで購入するプロセスに含まれるステップは次のとおりである:
     • 映画を選択する、
     • 日付および時刻を選択する、
     • 座席を選択する、
     • 支払う、
     • チケットを印刷または保存する。

     映画館は、ユーザーが映画の説明および評価を見たり、事前に軽食を購入したり、 慈善団体に寄付したりできるようにしている。これらのアクション、またはステップは、 映画チケットを購入するタスクをユーザーが完了するためには必須ではない。購入プロセスの一部として ユーザーにこれらを選択させるのではなく、プロセス開始前および完了後にこれらの選択肢が与えられる。

2. 主要機能への短いナビゲーション。たとえば、アプリ内で最も使用される機能について:
   • アプリを開く、
   • 最も使用される機能を実行する。

避ける:

1. 不要なステップを追加すること。たとえば、映画チケットをオンラインで購入するプロセスに含まれるステップは次のとおりである:
   • 映画を選択する、
   • 日付および時刻を選択する、
   • 座席を選択する、
   • 事前に軽食を購入する、またはオプトアウトする、
   • 慈善寄付を行う、またはオプトアウトする、
   • アカウントを作成する、
   • 支払う、
   • チケットを印刷する。

映画館は、ユーザーがチケットを支払う前に、軽食を決めて慈善寄付を行うことを強制する。 オプトアウト選択肢は利用可能だが、画面上でやや隠れており、特にモバイルデバイスでは見つけにくい。 ユーザーは支払い方法が分からないとき、しばしば停止する。

2. 最も使用される機能への長いナビゲーション。たとえば、アプリ内で最も使用される機能について:
   • アプリケーションの紹介ページへ移動し、続行を押す、
   • アプリケーションのメインページへ移動する、
   • サブページへ移動する、
   • 選択肢を選択する、
   • 別の選択肢を選択する、
   • 最も使用される機能を実行する。

4.6.3.1 ユーザーニーズ

必要なコンテンツと不要なコンテンツを簡単に識別できる必要がある。知る必要がある情報および重要な情報は 目立つか、最初に読むものであり、重要度の低い情報のノイズの中に埋もれない。

関連ユーザーストーリー: 見つけやすい。

4.6.3.3 どのように役立つか

忙しいページ、多すぎるテキスト、多すぎる画像、および多すぎるその他のコンテンツは、認知的過負荷、 不安、および集中喪失を引き起こす可能性がある。コンテンツを少数の重要な点に抑えることで、 散らかりを減らし、ユーザーを落ち着かせ、記憶を助けながら理解を改善できる。たとえば、 読むのが遅い人や注意持続時間が短い人に役立つ可能性がある。そのような人は、ページが複雑に見えると 離れてしまう場合がある。

簡略化されたコンテンツおよび一貫した単純なデザインは、認知的過負荷を減らし、ストレスおよび精神的疲労を 減少させる助けとなる。たとえば、早期 認知症のある人が医師のアプリケーションへ行く。画面には5つの選択肢がある: 予約、医師に質問する、検査結果、承認、その他。各選択肢にはアイコン、明確なテキストがあり、 余白で分離されている。2クリックで医師へ質問できる。助けを求めずに必要なものを簡単に選択できる。 左へスワイプすれば、さらに多くの選択肢も利用可能である。しかし、その人がそうする可能性は低い。

4.6.3.4 詳細

長い段落、多くの選択肢、および意味のない画像を避けることで、認知障害および学習障害のある人々が、 述べられている重要な点に集中できることを確保する。

数個の短い箇条書きに保ち、ウェブサイトまたはサービスの主題領域に関連する画像を1つまたは2つに制限することで、 ユーザーはサイトをさらに探索するかどうかを選択できる。

このパターンの意図は、不要な情報でページを散らかすことではなく、認知障害および学習障害のある人々に 役立つ重要な手がかりおよび指示を提供することである。情報または指示が多すぎることは、 少なすぎることと同じくらい妨げになり得る。目標は、過度な混乱またはナビゲーションなしに、 ユーザーがタスクを達成するために十分な情報が提供されていることを確保することである。

4.6.3.5 例

使用する:

1. 単純なインターフェイス。主要機能が他のものよりはるかに大きい。例:
   • 検索エンジンには、その名前と大きく単純な検索ボックスがある。他のすべてのコンテンツは より小さく、下の方にあり、ユーザーは追加機能を探していない限り気づかない。

避ける:

1. 不要なコンテンツがあるページ。例:
   • 多すぎるテキスト、長いメニュー、および密なテキストの長い段落の周囲に配置された画像。 メッセージが情報過多の中で失われる。

4.6.4.1 ユーザーニーズ

タスクをどのように開始するか、および何が関係するかを知る必要がある。

関連ユーザーストーリー: 気を散らすもの。

4.6.4.3 どのように役立つか

一部のユーザーは、特に気を散らすものによってタスク途中でフォーカスを切り替え、その後中断した場所へ 戻らなければならない場合、気を散らすものを難しく感じる。たとえば、ウェブサイトに“book here”リンクへの 方向を示す大きな矢印がある場合がある。その矢印は予約タスクの開始を強調し、ユーザーがタスクを 開始したことを知る助けとなる。

多くの場合、人々は中断なしに集中できるよう、自分の集中時間を管理する必要がある。 タスクにかかる時間、その複雑さ、または作業記憶への負荷について事前に助言があることで、 よりよく準備し、完了できる。タスク開始前の必要リソースのリストと、タスク完了までに残っている ステップ数は、ユーザーが失敗を避ける助けとなる。

4.6.4.4 始め方

複数ステップのタスクまたはフォームの開始時に、必要時間の余裕ある見積もりおよびすべての必要リソースの リストを提供する。タスクをステップに分ける。

4.6.4.5 例

使用する:

1. ユーザーがタスクを開始するときの視覚的手がかり。
2. かかる可能性がある時間および必要なリソースを含むプロセスの概要。例:
   • ユーザーが航空券の予約を始める前に、「航空券の予約にかかる平均時間は15〜30分です。 このプロセスを完了するには、旅行日、旅行者数、および各旅行者のパスポートが必要です。」 というメッセージが提示される。

避ける:

1. ユーザーが必要とする可能性がある重要な詳細を省略すること。例:
   • 別の航空会社は、パスポートが必要であることをユーザーに通知しない。 ユーザーがパスポート番号を探している間にプロセスがタイムアウトする。 ユーザーは最初からやり直すか、予約を放棄する必要がある。

4.7.1.1 ユーザーニーズ

パスワードおよびユーザー名を記憶したり転記したりせずにサイトを使用できる必要がある。

関連ユーザーストーリー: アクセシブルな認証。

4.7.1.3 どのように役立つか

記憶 障害のある人々は、しばしばパスワードを忘れ、ログインできない。その解決策は、 役立つ場合がある一方で、セキュリティリスクを伴うことが多い:

• テキストをフォームフィールドにコピーまたは入力するために、何度も見たり聞いたりしなければならない場合がある。
• 1つのパスワードを使い回したり、覚えられる単純で覚えやすいパスワードを使用したりする場合がある。
• パスワードを変更する必要がある場合、または複雑なパスワードを使用する必要がある場合、 他の人に見られる紙片に書くなど、安全でない方法でパスワードを保存する場合がある。

ログイン中の他のステップにも苦労する場合がある。たとえば:

• 文字を正しい順序で入力する、
• 限られた試行回数で文字を正しく入力する（結果としてロックアウトされる）、
• PINを見つける、
• パズルまたは歪んだ文字を解く、
• 別のデバイスから文字を正しくコピーする。

ユーザーは、時間制限のある手順またはデジタルセキュリティトークンの提示に苛立ち、停止する場合がある。 または、障害のために重要なサービスから締め出される場合がある。

このデザイン要件がないと、多くの人々はアプリケーションまたはコンテンツをまったく使用できない。 この問題の完全な説明、およびそれが、しばしば重要であるウェブサービスの使用をどのように妨げるかについては、 セキュリティおよびプライバシー 技術の課題文書を参照。たとえば、多くの人々は医師の予約などを自分で行うことができない。 これは、学習障害および認知障害のある人々の平均寿命が短いことに部分的に関係している可能性がある。

4.7.1.4 詳細

このデザインパターンを満たす方法は多くある:

• 典型的な認知能力に依存しない包摂的な代替をサポートするために、Web Authentication: Public Key Credentialsにアクセスするための API [webauthn-2] を使用する。たとえば、ハードウェア認証デバイス、スマートカード、またはFIDO。
• 信頼されたデバイス（ユーザーがすでに自分の身元でログインしているデバイス）の使用に基づく 自動ユーザー認証を提供する。ユーザーは文字を書き写す必要はないが、そのデバイスを持っていることを 識別するためにリンクを押す必要がある場合がある。
• 生体認証の選択肢を許可する。
• 第三者認証サービス（例: OAuthなど）を介して、ユーザーがすでにログインしているシステムを使用する。

代替ユーザー認証の要件を満たす方法には次が含まれる:

• メールアドレスまたは電話番号に送信されたリンクをクリックする。 （これは実装が容易であり、ブログへのコメントを許可するなど、最小限のセキュリティには有用な場合があることに注意。）
• 現在の口座残高の合計など、ユーザーの個人書類に存在する情報を使用してログインし、 この情報を見つける方法について説明する。

4.7.1.5 例

使用する:

1. Web Authentication: Public Key Credentialsにアクセスするための API [webauthn-2]。
2. ユーザーが1つのログインで多くのサイトにアクセスできるシングルサインオン（SSO）（フェデレーションログイン）。
3. Bluetoothリンクを伴う2段階認証（コピーなし）。
4. Quick Response Codes（QRコード）。

避ける:

1. コピーを要求する2段階認証を使用すること。
2. パスワードを使用し、フィールドへの貼り付けを許可しないこと。

4.7.2.2 どのように役立つか

単純なログインは、実行 機能または記憶に障害のある人々がアプリケーションを使用できるようにする。 これは、複数ステップのプロセスで混乱したり圧倒されたりするユーザーにとって特に重要である。 たとえば、外傷性脳 損傷のあるユーザーが、オンライン銀行のためにサイトを使用したい場合がある。 誰であるかを認証するために、指紋スキャナーに指を置いている場合がある。その他の例には、 一部の第三者ログインが含まれる。

4.7.2.3 例

使用する:

1. 選択肢としての簡単な第三者ログイン。
2. セキュリティニーズに合う単一ステップ方式を伴う、ウェブ認証プロトコル [webauthn-2]。

避ける:

1. すべてのログイン方法が複数ステップを伴うこと。

4.7.3.1 ユーザーニーズ

重度の言語障害のある人として、多くの語に依存しない、自分が使用できるログインプロセスが必要である。

関連ユーザーストーリー: アクセシブルな認証。

4.7.3.3 どのように役立つか

このパターンにより、言語およびコミュニケーション障害のある人々は、テキストのまとまりに圧倒されずにログインできる。

たとえば、重度の言語障害のある人がAAC デバイスを使用して、医師にメッセージを送りたいとする。その人は、知っているアイコンでログインを押し、 テキストを読まずにメッセージを送信できる。

4.7.3.4 例

使用する:

1. よく知られたアイコンを持つ第三者ログイン。
2. 簡単なログイン選択肢を伴うウェブ認証プロトコル [webauthn-2]。

避ける:

1. セキュリティ質問への回答を要求するログイン。
2. 単純で語を使わないログイン選択肢または代替のないログイン。

4.7.4.1 ユーザーニーズ

複雑なメニューシステムを通らずに、人によるヘルプを得る必要がある。

関連ユーザーストーリー: 音声 メニュー。

4.7.4.3 どのように役立つか

多くの人々は音声メニューシステムを使用できない。これはしばしば、人々が重要なタスクを自分で完了することを妨げる。 これには、医師の予約、健康保険の取得、社会サービスへの到達、水道の再開などが含まれる場合が多い。

人々が音声メニューを自分で管理できない場合、他の誰かに助けを求めなければならない。 これは、そのサービスが彼らにとってアクセシブルでないことを意味する。タスクが行われない場合もある。 たとえば、助けてくれる人に迷惑をかけないように、医師の予約またはその他の重要なタスクを遅らせる場合がある。 人々は必要なヘルプを得られない、または得るのが遅すぎることが多い。（これは、学習障害および認知障害のある人々の 平均寿命が短いことに部分的に関係している可能性がある。）

なぜ人々は複雑なメニューを使用できないのか?

• ユーザーがメニューの番号または用語を覚えるには、良好な短期記憶および作業記憶（数秒）が不可欠である。 これらの機能がない場合、ユーザーは間違った番号を選択する可能性が高い。
• 多くのユーザーは作業記憶に障害がある。たとえば、あなたが頭の中で同時に7つの文字または項目を 覚えられるとしても、その人たちは1つまたは2つしか覚えられない場合がある。これにより、 メニューシステムを正しく管理する可能性が低くなる。
• たとえば、電話メニューシステム（音声マークアップシステム）には、「内部サービスの場合は3を押してください」 という選択肢がある場合がある。この選択肢を使用するには、ユーザーは内部サービスが必要かどうかを判断しながら 数字3を覚えなければならない。多くの人々はこれを行えない。また、正しい数字を押すことも要求される。
• 正しい選択肢の前に関連のない情報が多く与えられると、ユーザーは認知的過負荷になって停止する場合がある。 これは、以前のすべての選択肢および情報を理解していなかった場合に特に当てはまる。
• 使用される用語を理解できない場合がある。メニューに集中しているうちに、なぜ電話しているのかを忘れる場合がある。
• ウェブメニューなどの代替経路が提供される場合があるが、それらも複雑である。そのため、役に立たない。

0の数字、“help”という語、またはその他の文化的に適切な用語は、人に到達するために予約されるべきである。 各メニューの最初の選択肢を一貫して「助けてくれる人を待つには0を押してください」に設定する。 これは、すべての人が必要なサポートに到達する助けとなる。

異なる学習障害および認知障害のある幅広いユーザーと、任意のシステムをテストする。 幅広いユーザーを関与させることで、多くの音声システムは、認知 障害および学習障害のある人々にとって補助となる程度までアクセシブルになっている。

4.7.4.4 詳細

一般的な音声 ユーザーインターフェイス（VUI）設計のベストプラクティスに従う。音声 ユーザーインターフェイスの標準的なベストプラクティスは、認知障害のあるユーザーにも適用され、従うべきである。 これらの慣行は、より多くの設計が会話型 インターフェイスに焦点を当てるにつれて改善している。一般に受け入れられている音声 ユーザーインターフェイス設計のベストプラクティスの例には次が含まれる:

• 言語および選択肢を処理する時間を確保するために、フレーズ間の一時停止は重要である。
• テキスト内の選択肢は、選択する数字、またはその選択肢を選択する指示の前に与えられるべきである。 これにより、ユーザーは用語を処理している間に数字または指示を覚える必要がなくなる。たとえば、 “press 1 for the secretary,”というプロンプトは、ユーザーが“secretary”という用語を解釈しながら 数字1を覚えることを要求する。より良いプロンプトは、“for the secretary (pause): press 1”または “ for the secretary (pause) or for more help (pause): press 1”である。
• エラー回復は単純であるべきであり、エラーが続く場合はユーザーを人間のオペレーターへつなぐべきである。 エラー応答は通話を終了したり、ユーザーをより複雑なメニューへ送ったりするべきではない。
• 広告およびその他の余分な情報は、ユーザーを混乱させ、注意を保持しにくくする可能性があるため、 読み上げるべきではない。
• 使用する用語は、できるだけ単純で専門用語のないものにするべきである。
• Tapered promptsを使用する。音声 ユーザーインターフェイス設計のベストプラクティスには、相互作用の各ポイントで複数の異なるプロンプトを 提供することが含まれる。異なるプロンプトは、ユーザーの挙動に基づいて使用される。たとえば、 ユーザーがプロンプトへの応答に長い時間をかける場合、既定ではなく、より単純またはより説明的な プロンプトを使用できる。ユーザーが期待どおりに応答しない場合に、プロンプトの詳細度を高めるために 使用されるべきである。

ユーザー設定

ユーザー固有の設定は、音声 ユーザーインターフェイス（メニューおよび選択肢など）をカスタマイズするために使用できる。 ユーザー設定の設定が難しい場合、それらは使用されないことに注意する。自然言語による設定が最も自然 （「ゆっくり話して!」）だが、現在はあまり一般的ではない。

• 追加時間は、発話速度および、ユーザーがより遅い発話またはより長い入力時間などを必要とするかを 定義する能力の両方について、ユーザー設定であるべきである。時間制限付きテキストは調整可能であるべきである （すべてのアクセシブルメディアと同様）。
• ユーザーは、自分のデバイス上のシステム既定として、タイムアウトを延長または無効化できるべきである。
• エラー回復は単純であるべきで、人間のオペレーターへつなぐべきである。エラー応答はユーザーを回線から 切断したり、より複雑なメニューへ送ったりするべきではない。望ましくは、サポートおよび人によるヘルプのために 予約済みの数字を使用するべきである。
• 広告およびその他の情報は、ユーザーを混乱させ、注意を保持しにくくする可能性があるため、 読み上げるべきではない。
• 使用する用語は、できるだけ単純にするべきである。
• 認知的負荷を減らすプロンプトを構築する方法について、例および助言を与えるべきである
  • 例1: 認知的負荷の低減: “press 1 for the secretary,”というプロンプトは、 ユーザーがsecretaryという用語を解釈しながら数字1を覚えることを要求する。 “for the secretary (pause): press 1”または“ for the secretary (pause) or for more help (pause): press 1”というプロンプトより劣る。
  • 例2: 人間のオペレーターの既定を番号0に設定する。

音声認識に関する考慮事項

• 音声認識ベースのシステムでは、多くの言語について音声コマンドの標準が存在し、 可能な場合は使用されるべきである。たとえばETSI標準 ETSI 202 076。人々に少数を超えるコマンドを学ぶことを期待することは、 ユーザーに認知的負担を課すことに注意する。
• 自然言語理解システムは、ユーザーが自分の言葉で要求を述べることを可能にする。 これは、メニュー選択肢を覚えることが難しいユーザー、または提供されたメニュー選択肢を自分の目標に 対応付けることが難しいユーザーに有用である場合がある。しかし、自然言語インターフェイスは、 発話または言語を生成することが難しいユーザーにとって使用しにくい場合がある。指示付き対話 （メニューベース）のフォールバック、またはエージェントへの転送を提供するべきである。 そのようなフォールバックは使いやすく、この文書に適合するべきである。

法令の要件に従う。

たとえば、米国Telecommunications Act Section 255 Accessibility Guidelines [Section255] の1193.41 Input, control, and mechanical functionsの段落、条項(g)、(h)、および(i)は 認知障害に適用され、機器は時間依存のコントロール、話す能力なしで操作可能であり、 限られた認知スキルを持つ人々によって操作可能であるべきであることを要求している。

完全な議論については、Voice Menu Systems 課題文書を参照。

4.7.4.5 始め方

このパターンが、健康、金融、通信、水道、および政府サービスに影響する重要なシステムに含まれることを確保する。

4.7.4.6 例

使用する:

• 最初の選択肢が人へ直接つなぐユーザー相互作用ダイアログ。例: “To reach for a person who can help you, press 0 or say help”。
• 各ポイントからのエラー回復。ユーザーがエラーを簡単に修正できるようにする。
• ユーザーは任意の時点で簡単に戻ったり、リストを繰り返したりできる。
• 任意のポイントから標準の“0”などを使用するユーザー相互作用ダイアログ。ユーザーが目標を達成するのを 支援できる人間のオペレーターへ簡単にアクセスできる。
• 発話は明確で、一時停止がある。
• 一般的な語が使用される。
• 押すキーまたは使用する用語を伝える前に、選択肢を述べる。
• 助言的技法: 後の時点で有用になる可能性がある何かを記録するようユーザーに促し、 そうする時間を与える。

避ける:

• 人を見つけにくくする長いメニューシステム。
• 不明確なエラー回復。
• 複雑な言語および一般的でない用語。
• 宣伝などの不要なコンテンツ。
• 速い発話、またはユーザーからの速い入力を期待すること。
• 異なる認知 障害および学習障害のある幅広いユーザーとテストされていないシステム。

4.7.5.1 ユーザーニーズ

記憶に依存しないナビゲーションおよびプロセスが必要である。

関連ユーザーストーリー: 前のステップ。

4.7.5.3 どのように役立つか

コンテンツには、認知 障害および学習障害のあるユーザーがステップまたはプロセスを完了することを妨げ、その結果、 達成したいことの達成を妨げる障壁がしばしばある。

購入時にセキュリティを高めるため、パズルまたは計算が要求されることがある。例: 購入を完了するために、ユーザーは数字の1番目と2番目の位置を掛けた結果を入力するよう求められる。 この種の文は、認知 障害および学習障害のある一部の人々には理解できない。セキュリティと認知アクセシビリティの両方が 保証されるべきである。

多くのユーザーは作業記憶に障害がある。同時に多くの詳細を覚えられない。しかし、ダイアログメニューなどの システムは、すべてのユーザーが選択を行うために作業記憶を使用することに依存している。 それらは、発話またはキー押下によって、ユーザーが複数の選択肢を覚え、1つの選択肢を選択することを期待する。 ユーザーは一時的な複数の情報を心の中に保持する必要がある。

実行 機能に障害のあるユーザーは、タスクを完了するためにより多くの時間を必要とする場合がある。 しかし、システム応答が遅すぎる場合にも問題が生じることがある。たとえば、一部の人々は、 “billing”、“accounts”、“sales”などの類似した選択肢を比較し、どれが必要なサービスかを判断するために より長い時間を必要とする場合がある。明確な言語を使用することも役立つ。

4.7.5.4 詳細

記憶スキルへの依存を減らす良い慣行には次が含まれる:

• プロセス内の各ステップには、ユーザーが進めるために必要な情報が含まれているべきである。 前のステップからの記憶に依存してはならない。
• 最初からやり直す必要なく戻れる単純な方法を提供する。
• ステップインジケーターなどを通じて、ユーザーがプロセス内のどこにいるかを知らせる。
• ユーザーが間違いまたはエラーをした場合、プロセスを再開するのではなく、それを修正するためのヘルプを提供する。
• 有用な場合、前のステップからの情報の要約を提供し、プロセスをたどるための簡単な仕組みを利用可能にする。

音声インターフェイスの場合:

• 各選択肢の間に一時停止を置く。
• 話すのが遅い人が応答するのを待つ。
• 声が小さい、またはためらう話し手に耳を傾ける。
• 単純な1語の応答を許可する
• 選択される番号またはコマンドの前に選択肢を述べる。
• 物忘れおよび記憶 障害をサポートする。

これは、健康、金融、通信、水道、および政府サービスなどの重要なシステムにとって不可欠であることに注意。

4.7.5.5 例

使用する:

記憶に依存しないプロセス。例:

• 最初の選択肢が「助けてくれる人を待つには0を押す、またはhelpと言う」であるユーザー相互作用ダイアログを使用する。
• 任意のポイントから標準の“help”などを使用するユーザー相互作用ダイアログを使用し、ユーザーが目標を達成するのを 支援できる人間のオペレーターへ簡単にアクセスできるようにする。
• ユーザーが任意のポイントから戻る方法を知ることができる、良いエラー回復。
• 助言的技法: 後の時点で有用になる可能性がある何かを書くようユーザーに促し、 そうする時間を与える。

避ける:

1. 記憶に依存するプロセス。例:
   • 前のステップからコードまたはカテゴリを覚えることをユーザーに要求する。
   • 人を見つけにくくする長いメニューシステム。
   • ユーザーが覚えなければならない特定の語の使用を要求するシステム。

4.8.1.1 ユーザーニーズ

人によるヘルプを得る方法を知り、そのプロセスを簡単に管理できる必要がある。

関連ユーザーストーリー: ヘルプ。

4.8.1.3 どのように役立つか

ユーザーが何らかの理由で行き詰まったり混乱したりした場合、人からヘルプを得ることは通常、 最も効果的な解決策である。現実には、多くのサイトは、複雑なシステムをナビゲートできるユーザーにのみ、 この選択肢を提供している。

複雑なシステムの例には、ユーザーが人の連絡先情報に到達するために多くのリンクをたどる必要がある プロセスが含まれる。また、人につながる前に多くの質問に答えることをユーザーに要求する電話番号である 可能性もある。複雑なシステムでは、それを最も必要とする人々が、人によるヘルプの選択肢へアクセスできない。 ユーザーは認知的過負荷になり、プロセスを完了しようとすることを停止する場合がある。 サービスまたは提供者に対して否定的な印象を持って離れる場合もある。

たとえば、知的障害のあるユーザーがクーポンを使いたいとする。オンライン購入にクーポンを適用するための 指示を見つけられず、サポート用の電話番号も見つけられない。その結果、事実上そのクーポンを使用できない。

4.8.1.4 例

使用する:

1. 電話番号。理想的には、相互運用可能な音声 ユーザーインターフェイス（VUI）仕様を介して自動的に発信する機能を伴う。
2. 人に直接つながる番号、または人によるヘルプを得るために利用可能な標準。たとえば、 音声メニューシステムで0の数字を使用する。
3. “to”および“subject”フィールドが事前入力された、“mailto”プロトコル [mailto] を使用する メールリンク。これはすべてのプラットフォームまたはメールクライアントで機能するわけではないことに注意。
4. ライブチャットまたはビデオ通話ヘルプの選択肢。注: 完全にアクセシブルであり、ライブヘルプ機能の一部として 開く新しいウィンドウを簡単に閉じられる必要がある。ライブチャットがユーザーをタスクから 気を散らさないことを確保する。

避ける:

1. 人によるヘルプを得るために、ユーザーが完全に入力しなければならない長い問い合わせフォーム。
2. ヘルプに到達するための複数ステップのメニュー。
3. サイト上の数ページからしかリンクされていない単一ページに、連絡先情報を含めること。
4. 人によるヘルプに到達するために、ユーザーに複数のステップを通ることを強制すること。

4.8.2.1 ユーザーニーズ

テキストを補足する、文脈に関連したグラフおよび画像が必要である。

関連ユーザーストーリー: ヘルプ。

4.8.2.3 どのように役立つか

複雑な情報、長い文書、および複雑なデータ形式の使用は、認知アクセシビリティのニーズがあるユーザーに 重大な障壁を提示する可能性がある。ユーザーは、可能な限りさらなる外部支援を必要とせずに、 情報を理解し、説明されたタスクを正常に完了できるべきである。

コンテンツの主題自体が複雑な場合がある。この場合、できるだけ多くのユーザーが間違い、混乱、 または支援の必要なしに理解できるよう、慎重な説明、構成、および提示が必要になる可能性が高い。

グラフ、図、または表など、情報の提示方法によって、一部のユーザーにとってより複雑になる場合がある。 ここでは、補足説明およびガイド付き解釈が、ユーザーが理解する必要がある主要な特徴を強調する。

異なる人々は、異なる種類の情報を理解しやすいと感じる。これは、認知 障害および学習障害のある人々に特に当てはまる。たとえば、数字には影響するが言語には影響しない障害が ある人もいれば、言語障害があるが数字を直感的に理解できる人もいる。ヘルプは、異なるユーザーをサポートするために、 次のようなさまざまな形式で提供できる:

• 図の説明およびヘルプを提供するテキストの“aside”。
• テキストコンテンツを明らかにする補助的な図表またはグラフ。
• タスクがステップで完了される様子を示す動画クリップ。
• 複雑でない補足表。
• キーワードのホバー時ポップアップ説明。用語集にリンクされる場合もある。
• プロセス内のステップのフローチャート。

4.8.2.4 詳細

数字および複雑な情報に関連するコンテンツの推奨技法（該当するものを使用する）。

• 複雑な情報の理解を助ける場合、図表またはグラフィックを提供する。
• 情報の理解を助ける場合、表を提供する。
• このコンテンツを使用するために数学の理解が主要な要件でない場合、次のいずれかを使用する:
  • 数字を非数値概念で補強する。例: 非常に寒い、寒い、涼しい、穏やか、暖かい、暑い、 非常に暑い。
  • 成熟したら、非数値概念を追加するために個人化セマンティクスも使用できる。 [personalization-semantics-1.0] を参照。
• 節を持つコンテンツでは、次のいずれかを使用する:
  • 節に記号を追加するためのセマンティクスを有効にする。
  • 理解を助けるために、見出し、重要な短い文および句に加えてアイコンを追加する。
  • ただし、アイコンを覚えることが難しい人もいるため、アイコンとともにテキストを使用する。
    • 見やすく拡大しやすい、明確なアイコンまたは記号を使用する。
    • 異なるユーザーに理解される画像を使用する。
    • 左から右へ書く言語では、画像をテキストの左側に配置する。
• 300語を超えるコンテンツの推奨技法
  • 一般的な用語および短いテキストのまとまりを使用して、理解しやすい要約を提供する。 300語未満のコンテンツについては、見出しが要約として機能する場合がある。
  • 情報をより管理しやすい大きさに分解し、提示される情報に構造を提供するために、 セマンティックな見出しを使用する。これは支援技術のユーザーに特に利益をもたらす。
  • コンテンツ所有者は、ユーザーの理解を助ける少なくとも2つのキーワードを識別し、 これらのキーワードはプログラム的に判別可能であり、ユーザーの好むモダリティで強調される。

4.8.2.5 始め方

現実世界のタスクを含む、タスクの正常な完了に重要な複雑な情報について、説明的なコンテンツを提供する。

4.8.2.6 例

使用する:

1. 長い文書、複数の節を持つ文書、複雑な情報、および数値情報について、上記の「詳細」節にある技法。 例:
   • 医療処置および成功率統計の説明が、追加のテキストaside、図、およびグラフの使用によって補強されている。
   • ビザ申請の複数ステップのプロセスは、常に表示される全ステップのフローチャートを追加することで、 使用しやすくなっている。フローチャート内の各ステップには追加ヘルプへのリンクがあり、 現在のステップは明確に強調表示されている。

避ける:

1. 良い構造および要約のない長い文書。
2. 追加サポートのない複雑な情報および数値情報。例:
   • 売上数値の長いテキストおよびデータ表が、コンテンツに関連する主要な特徴についての説明なしに表示されている。

4.8.3.1 ユーザーニーズ

任意の選択肢について、サポートおよび説明が必要である。利点または不利益が自分に明確であり、 自分が行うかもしれない選択の効果を理解できる。

関連ユーザーストーリー: 認知的ストレス。

4.8.3.3 どのように役立つか

各アクションおよび選択肢の利益と結果を明確に述べることは、個人が間違いを避ける助けとなる。 これは、結果を簡単に修正できない場合、安全リスクにつながる場合、または結果が決して知られない可能性がある場合に 特に重要である。

たとえば、旅行サイトのユーザーがGenevaへの旅行を予約している。良い時間の選択肢を見るが、 このチケットは別の都市行きである。ユーザーは、提示された選択肢が自分の求めた場所行きだと仮定する。 日付および時刻は確認するが、語を綴って読むことしかできないため、目的地が変更されていることに気づかない。 その結果、ホテルとは異なる場所へ連れて行かれ、脆弱なユーザーが夜に宿泊施設のない見知らぬ都市へ到着する。

別の例では、ユーザーが良い価格のノートパソコンの販売を見つける。長い説明の中にあるrefurbishedという語に 気づかない。そのノートパソコンは実際には良い価格ではない。

4.8.3.4 始め方

ユーザーに選択またはアクションを求めるときは常に、ユーザーが認識しておくべき暗示的または隠れた結果が あるかどうかを検討する。ユーザーインターフェイス内でそれらの結果を明確に示し、ユーザーがそれらを 認識していることを確認する。

4.8.3.5 例

使用する:

1. 含まれるものと含まれないものの明確な一覧。例:
   • 航空券を選ぶとき。各選択肢の隣に、何が含まれるかの明確な一覧がある。
2. 任意の変更またはリスクについての警告。例:
   • 航空券を選ぶとき、チケットの選択肢が異なる目的地行きである場合、または望ましくない可能性や リスクのある別の通常でないアクションまたは変更がある場合、ユーザーはその変更を確認するよう求められる。

避ける:

1. ユーザーが選択肢を選択するときに明確でない詳細。
   • 例: オンラインメニューの食事選択肢に楽しい名前が付いている。食事内容、 付け合わせ、アレルギー情報、および各選択肢をカスタマイズできるかどうかは、 プロセスの2ステップ後まで見えない。顧客は決定するために各項目でいくつかの画面を 下へ進まなければならない。
2. ユーザーに警告せずに、元の要求から項目を変更すること。
3. 警告なしにユーザーにリスクを与えること。

4.8.4.1 ユーザーニーズ

フォーム内の通常でないコントロールについて、自分が使いやすい説明（動画またはテキストなど）が必要である。

関連ユーザーストーリー: タスク管理。

4.8.4.3 どのように役立つか

ユーザーはしばしば、フォームおよび関連タスクをウェブサイトで最も複雑な体験だと感じる。 簡単に混乱したり、不安になったり、完全に迷ったりする可能性がある。追加ヘルプを提供することは、 タスクを正常に完了できるか、諦めるかの違いを生む場合がある。これは、フォームの任意の部分が複雑であるか、 非標準の相互作用を要求する場合に特に当てはまる。

多くの標準フォームコントロールは、サポートを自動的に提供する。たとえば、多くのフィールドは、 オートコンプリートまたは個人化セマンティクス [personalization-semantics-content-1.0] を使用して情報を自動的に入力できる。その場合、ユーザーは入力時に間違いを起こさない。

追加フィールドおよび非標準コントロールを要求すると、多くのユーザーはそれらを使用することに困難を抱える。 障害のある多くのユーザーは、情報を誤って入力したり、タスクを完了する方法を理解できなかったりする。 これはしばしば、タスクが完全に放棄される結果となる。その他の場合、ユーザーはフォームを完了したり コントロールを操作したりするために介護者に助けを求める。いずれの場合も、その障害のために タスクを完了できていない。

標準の [HTML] フォームおよびコントロールは、最大限のユーザビリティおよび アクセシビリティのために慎重に仕様化されている。通常、特にウェブの相互作用に慣れているユーザーには理解される。 しかし、標準フォームの挙動が変更されている場合、またはまったく新しいコントロールが提供される場合、 ユーザーは困難を経験する可能性が高い。新しい挙動が慎重に設計され、ユーザーテストされていると仮定しても、 ユーザーはそれらを正常に使用するためにヘルプを必要とする場合がある。

4.8.4.4 詳細

追加ヘルプを必要とする可能性が高いフォームおよびコントロールの例:

• 特定の種類の文字を入力することを要求するパスワードフィールド。
• 複雑な相互作用を持つ調査。たとえば、前の回答に応じてボタンだけが表示される場合。
• 必要な形式について曖昧さがあり得る日付入力。
• 一部の日付がグレー表示される場合がある日付ピッカーなどのカスタムコントロール。

4.8.4.5 例

使用する:

1. 標準コントロール
2. 指示またはヘルプを伴う非標準コントロールおよびフォームフィールド。例:
   • 非標準コントロールの隣にあるアクセシブルなヘルプボタン。
   • 文脈依存ヘルプのための標準的な仕組み。これには、文脈依存ヘルプのための個人化セマンティクスの使用を含めることができる。
   • 見つけやすく、明確で曖昧でない指示。

避ける:

1. 指示またはヘルプを持たない非標準コントロールおよび通常でないフォームフィールド。例:
   • フォームに、スクロールまたはタブ移動で節を有効化および無効化する複雑な仕組みがあるが、 ヘルプが提供されていない。

4.8.5.1 ユーザーニーズ

行き詰まるすべての場所から、簡単にヘルプを得てフィードバックを提供する必要がある。

関連ユーザーストーリー: ヘルプ。

4.8.5.3 どのように役立つか

ユーザーがフィードバックを提供するための簡単な方法を提供することは、人々が問題を共有し、ヘルプを求め、 提案を行い、肯定的なコメントを与えられるようにする助けとなる。ユーザーが簡単にフィードバックを提供できない場合、 サイト所有者が問題に気づかないまま、問題は存在し続ける。プロセスの任意の時点からユーザーがフィードバックを 提供できるようにすることは不可欠である。そうしないと、人々はなぜ行き詰まっているかを説明しようとして 迷ってしまう。改善のアイデアおよび肯定的なフィードバックも見逃される。

たとえば、認知障害および学習障害のあるユーザーがeコマースサイトの使用に苦労している。 そのサイトをずっと使いやすくする方法についてのアイデアがある。フィードバックを提供しようとして1時間費やし、 その後試みることをやめる。そのサイトは顧客を失い続ける。

4.8.5.4 詳細

フィードバック選択肢が次を満たすことを確保する:

• 使用が単純である、
• プロセスのすべての段階で利用可能である、
• 送信された任意のフィードバックに役立つよう応答するプロセスである、
• 完了しやすく、ユーザーに不要な情報の提供を求めない、および
• 複雑なメニューシステムに依存しない。

フィードバックを集めるために複数の方法を提供することが推奨される。 たとえば、ウェブサイトでは、ライブチャット、電話番号、ウェブフォーム、およびフィードバック用メールアドレスを含む 4つすべてのフィードバック選択肢を提供することを検討する。

チャットボットは、フィードバックプロセスを開始する以外、この特定の種類のフィードバックには 適切でない場合があることに注意する。到達しようとしている領域へ簡単にたどり着けない場合、 これらは非常に苛立たしいものになる可能性がある。

4.8.5.5 例

使用する:

1. 各画面で利用可能な単純なフィードバックの仕組み。例:
   • 銀行ウェブサイトに、一部の顧客がオンラインで請求書を支払うことを妨げる重大なアクセシビリティ問題があった。 顧客が行き詰まったページにフィードバックフォームがあった。顧客は問題を報告でき、 ヘルプデスク従業員が連絡して、請求書支払いを正常に完了できるよう支援した。 そのヘルプデスク従業員はアクセシビリティ問題もソフトウェアチームへ報告した。

2. 次のような複数のフィードバックの仕組み:
   • ウェブチャットまたはウェブ通話 - ライブチャットまたはビデオ通話を使用してフィードバックを提供する選択肢。 注: ライブチャットまたはビデオ通話機能は完全にアクセシブルでなければならない。 ウェブチャットは気を散らすものであってはならず、閉じやすいべきである。 ユーザーテストでユーザビリティを確認する。
   • 電話 - フィードバック用電話番号。理想的には、音声 ユーザーインターフェイス（VUI）を介して自動的に発信する機能を伴う。複雑な音声メニューが ないことを確認する。
   • ウェブフォーム - 必須フィールドが3つ以下の単純なサイト問い合わせフォーム。
   • メール - “to”および“subject”フィールドが事前入力された、“mailto [mailto]”プロトコルを使用するメールリンク。 これはすべてのプラットフォームまたはすべてのメールクライアントで機能するわけではないことに注意。
   • 対話型 音声応答（IVR） - IVRの最後に、電話で特定の数字を押すことでフィードバックを提供できる 自動選択肢を提供する。

避ける:

1. 複雑なフィードバックの仕組み。
2. 誰もが使用できるわけではない、フィードバックを提供する単一の方法。

4.8.6.1 ユーザーニーズ

道順およびナビゲーションを理解し使用するためのヘルプが必要である。

関連ユーザーストーリー: ヘルプ。

4.8.6.3 どのように役立つか

認知 障害および学習障害のある人々は、道案内の指示または道案内アプリケーションについて、さまざまな程度の困難を 経験する。道案内の問題に対処するために必要なヘルプは、刺激が多い屋内ナビゲーションと、 記憶への要求が多くなる可能性がある屋外とで異なる場合がある。必要なヘルプは個人によっても異なる。

道案内には多くの認知機能が必要である。設計は、他のデザインパターンでサポートされるものを含め、 幅広い認知障害および学習障害に対応するべきである。例:

• 記憶、
• 実行 機能、
• 空間的方向づけ、
• 視覚/空間的注意、知覚、および処理、
• 空間的見当識障害による不安、
• 言語処理、
• 知的、
• 注意。

一部のユーザーは、ステップごとの道順など、より詳細なヘルプを必要とする場合がある。 多くのユーザーは、たどる前に経路をプレビューする必要がある。その場合、ランドマークは認識および方向づけを 助けるだけでなく、不安を軽減できる。ユーザーの好みに合う代替の相対的方向用語および方位が最も効果的である。 たとえば、アプリケーションは“運転席側”または“東棟”を参照できる。相対距離および絶対距離を 人々が想像する助けを提供することも役立つ。たとえば、「半分まで進みました」。

個人的要件には幅広いばらつきがあるため、個人化の仕組みは非常に有用になり得る。たとえば、 距離に使用される単位。 プラットフォームまたはその他の技術は、相対方向および方位ならびに用語について、 使用できる個人化選択肢を提供することが多い。たとえば、プラットフォームのロケール設定。

変更は非常に混乱を招く可能性がある。ユーザーは、何時間もの渋滞を避けるためであれば経路変更の準備が できているかもしれないが、そのためにはガソリンスタンドに寄って新しい経路を学ぶ必要がある。 少しの渋滞を避けるためには、経路を変更したくない場合がある。ユーザーにとってうまく機能する選択肢を 見つけられるよう支援する。

たとえば、外傷性脳 損傷のある人がGlobal Positioning System（GPS）を使用している。出発前に経路を確認し、 曲がり角の写真を見る。これらの準備により、経路をたどることができるようになる。運転中、 3分の渋滞を避けるために経路が変更される。もはやその経路をたどれず、迷ってしまう。

4.8.6.4 例

使用する:

1. 左右を示すための、常に利用可能な第2の方法、またはその表示を個人化する方法。
2. ランドマークを使用する道順。たとえば、道案内中の方向づけを助けるために、地域のランドマークの画像が 提供される、または追加できる。
3. 望ましくない変更を避けるために利用可能な選択肢。
4. 利用可能な追加サポート。

避ける:

1. よく知られていないもの（例: N by NE）を含む、方位点への一貫した参照。
2. 人が期待される位置にいることを常に仮定する指示。簡単に回復する方法がない。
3. ユーザーが望まず制御していない方法で自動的に変化するコンテンツ。

4.8.7.1 ユーザーニーズ

リマインダーを自分のカレンダーに統合する必要がある。そうでなければ、予定や何かを行うべき時を忘れてしまう。 ときには、次のタスクを完了するためにウェブサイトを再訪するリマインダーが必要である。

関連ユーザーストーリー: サポート。

4.8.7.3 どのように役立つか

認知障害および学習障害のある人々は、しばしばイベントおよび時間の管理に課題を抱える。 （実際、サポートなしにイベントおよび時間を正しく管理できないことは、一部の障害グループの診断基準である。） これにより、会議を欠席したり、特定の日付までに要求を送信できなかったり、指定された期間内にフォームを 送信できなかったり、機会を逃したりする。例:

• ユーザーが情報をカレンダーにコピーするとき、日または時刻を誤ってコピーすることが多い。
• ユーザーは時間に基づく情報の処理および保持に課題を抱える。
• ユーザーは時間制限のあるイベントを順序付けることが難しい場合がある。
• ユーザーのスキルは疲れると低下し、タスクを停止しなければならないほどになる場合がある。 そのタスクを再スケジュールしたい場合がある。

ユーザーがイベントおよび締切を自分のカレンダーへ自動的に追加できるようにするカレンダー API（またはタスクマネージャー）を使用することは 役立つ。

たとえば、認知障害および学習障害のあるユーザーがオンラインで医師の予約を設定する。 その人はしばしば詳細を誤ってカレンダーにコピーする。しかし、この場合、ウェブサイトは予約を カレンダーに追加する選択肢を与え、1時間前にリマインダーを設定する。ユーザーは今、正しい場所に、 正しい時刻に、正しい書類を持って来る。

認知アクセシビリティのニーズがあるユーザーにとっての利点は、予定、締切、およびスケジュールを 独立して管理できることである。リマインダーを設定できる能力は、時間制限のあるタスクを処理するときに 関連する認知的負荷を減らすことができる。時間依存の活動は、適時に完了されることを確保するために、 ユーザーによって監視および追跡され得る。

ユーザーが中断されないように、タスクの最後に必ずリマインダーを設定する選択肢を与える。

望まないリマインダーを追加しないことは不可欠である。これによりユーザーのカレンダーがいっぱいになりすぎるためである。 それは、ユーザーがカレンダーをまったく使用できなくなることさえある。どのくらいの数のリマインダー、 どの種類のリマインダーが自分のニーズに最も合うかは、ユーザー自身が最もよく知っている。

4.8.7.4 詳細

プラットフォームまたは技術に標準的な仕組みが存在する場合、それを使用しなければならない。次を参照:

• Web Notification API
• Notifications API の使用
• Reminders and Notifications

日付および時刻に敏感なイベントとは、特定の時刻までに完了しなければならない任意のイベントである。 そのようなイベントの時間制約は、カレンダーの日付および時刻、または合計経過時間によって定義される場合がある。

考慮できる変数には次が含まれる:

• 時間 - 論理的な時刻に。
• 場所 - 適切な場所にいるときに促す。
• 文脈 - コンピューター対モバイル、特定のサイト上、など。

4.8.7.5 例

使用する:

1. イベントを自分のカレンダーに追加し、リマインダーを設定するためのユーザー向け選択肢。例:
   • 医療サイトで、地域の医療予約を設定できる。予約が設定されると、ユーザーはそれを カレンダーに（自動的に）追加し、3時間前のリマインダーを設定する選択肢を与えられる。 リマインダーを追加または編集する選択肢も与えられる。

避ける:

1. ユーザーが参加したくないイベントがユーザーのカレンダーに追加されること。
2. ユーザーが設定したばかりのイベントおよび予定を、自分のカレンダーに自動的に追加できないこと。 例:
   • 医療サイトで、地域の医療予約を設定できる。ユーザーには、それを自動的にカレンダーに追加したり リマインダーを設定したりする選択肢が与えられない。

4.9.1.1 ユーザーニーズ

物がどこにあるかを知る必要がある。使用中にコントロールおよびコンテンツが予期せず動かない。

関連ユーザーストーリー: 適応。

4.9.1.3 どのように役立つか

ユーザーの開始なしに予期せず変化する任意のコンテンツ、設定、または機能は、認知 障害および学習障害のあるユーザーに重大な問題を引き起こす可能性がある。 これらの領域の任意の予期しない変更は、フォーカスの喪失、不安、またはユーザーインターフェイス （メニュー、ボタン、デザインコンポーネントなど）の理解や使用における混乱を招く可能性がある。 例には次が含まれるが、これらに限定されない:

• 新しいウィンドウまたはポップアップの自動起動。
• 明確にラベル付けされたボタン（フォーム送信のために単純な言語を使用する）以外の仕組みによる フォームの送信。
• 新しいコンテンツまたは機能を開くこと。
• 選択肢を選択したときの予期しない変更。
• Global Positioning System（GPS）による自動的な経路変更。
• GPS内の地図の向きを変更すること。

たとえば、ユーザーには方向感覚がない、または左右が分からない場合がある。 GPSを使用する前に、何をしているかをおおよそ理解し、 自分の文脈でGPSの道順を補強し、 手がかりとしてGPSを使用できるように、 経路を学習する場合がある。GPSは小さな交通遅延のために 自動的に経路を変更する。ユーザーは完全に迷い、見当識を失い、もはやアプリケーションを 使用できなくなる。

別の例では、ユーザーが動画を見ており、“like”を押したいとする。ボタンを押そうとした瞬間に、 コントロールが移動し、“like”を押す代わりに別の動画を読み込んでしまう。コンテンツを失いたくないため、 ユーザーは“like”を押す可能性が低くなる。その結果、ユーザーの好みは考慮されない。

コンテンツがいつ変化するかをユーザーが制御できるようにすることで、認知 障害および学習障害のあるユーザーは、ウェブサイトおよびアプリケーションの動作について より多くの制御を持てる。これにより、コンテンツを使用し、タスクを完了できるようにする選択を 行う機会が得られる。

4.9.1.4 詳細

例外: 変更が不可欠な活動（例: ゲーム）の一部である場合。

経路: これは、GPS経路などの道順および流れである。

向き: 地図の方向などの視点または表示である。

容易に利用可能（または容易に利用可能なモードまたは設定）とは、次の1つ以上が真である場合である:

• 可能な限り広い範囲で一度設定できる（利用可能な場合、オペレーティングシステム（OS）の標準、 [ISO 9241-112] または [GPII] の使用など）。
• ウェブページ集合の範囲について、設定を保存または変更する選択肢がある。
• 必要となる可能性がある各画面から到達可能であり、経路およびコントロールがこの文書全体に適合する。

4.9.1.5 例

使用する:

1. コンテンツが変化するときのユーザー制御。例:
   • ユーザーは、特定量以上の時間が節約される場合に経路を変更するよう設定できる。 5分を節約するために許容できる追加の曲がり角数など、より多くの情報を追加できる。 GPSが時間を節約する新しい経路を見つけたとき、 GPSは、追加された曲がり角の数および節約される時間を 含めて変更についてユーザーに伝える。GPSは ユーザーに経路を変更したいかどうかを尋ねる。またはGPSが変更した場合、ユーザーは1回のタッチまたはコマンドで 元の経路へ戻れる。

避ける:

1. ユーザーが制御できないまま変化するコンテンツ。

4.9.2.1 ユーザーニーズ

ウィジェットまたは拡張機能から追加サポート機能を使用する必要がある。

関連ユーザーストーリー: 拡張機能および API。

4.9.2.3 どのように役立つか

認知 障害および学習障害のある人々は、しばしばアドオンまたは拡張機能を支援技術として使用している。 例:

• 頭字語の完全形の読み上げ、
• 読まれている句の同期された強調表示を伴うテキスト読み上げのサポート、
• コンテンツの簡略化、
• 見出し構造からマインドマップを作成すること、
• すでに入力されたコンテンツを保持するためのサポート、
• パスワード管理、
• スペルチェック、
• 記号またはインターフェイスの変更、
• 数字を桁から語へ、語を桁へ変更すること、
• 行、文、句、およびまとまりの間に余白を追加すること、
• 音声認識など、コンテンツを入力する代替方法、
• 画像の追加。

しかし、ウェブサイトが拡張機能および APIの動作を止めてしまう場合がある。 その結果、これらのユーザーはこのウェブサイトを使用できない。

これらのアドオンおよび APIがサポートされない場合、作者は 支援技術として使用されるアドオンのすべての機能をサポートするべきである。

たとえば、外傷性脳 損傷のあるユーザーは、次のような詳細を覚える能力に影響する実行機能および記憶 障害を持つ:

• Web of Things（WoT）インターフェイス上のアイコンまたは記号、
• 自分のユーザー名およびパスワード、
• 頭字語が何を表すか、
• 電話番号、または
• 一般的でない語の意味。

コンテンツを簡略化し、サポート（頭字語の完全形やポップアップ辞書など）を提供するアドオンの使用を サポートすることで、その人はほとんどのコンテンツを理解できるようになる。

パスワード管理ツールをサポートすることで、ユーザーは正常にログインし、安全なサイトから締め出されることを避けられる。

機密でない情報の保存およびオートコンプリートは、フォームへの入力に役立つ。 これは、人の電話番号や住所などの一般的な情報を提案する。また、間違いを避ける助けにもなる。 この情報を記憶から正確に想起したり、コピー&ペーストしたりする必要をなくす。これは、しばしば フォームを正常に使用することを妨げるタスクである。

テキストコンテンツに圧倒されるとき、その人は、必要なコンテンツを見つける助けとなる、 なじみのある記号を挿入する拡張機能を持っている。

選択肢が多すぎると、IoTデバイスとの相互作用の複雑さが増す場合がある。追加選択肢は 無視しやすく、それらが追加であること、およびそれらをスキップする方法を理解するために 多くの読書を要求しないべきである。

Internet of Things（IoT）インターフェイスは、メーターの既定の“reading”が“1”ではなく“2”に 設定されているなど、ユーザーを混乱させる場合がある。その場合、ユーザーはそれを“1”へ リセットする必要がある。

任意の提案された解決策においては、ユーザーがコンテンツに関連する機能的側面などに注意を集中できるように、 IoTとの相互作用などの操作タスクを可能な限り透過的にすることが重要である。

4.9.2.4 詳細

認知 障害および学習障害のある人々は、しばしばアドオンを支援技術として使用する。 次の場合を除き、アドオンおよび類似ツールが期待どおりに機能することは不可欠である:

1. セキュリティまたは安全性の要件により、これらの APIを無効化する必要がある。 この場合、それらは関連するフィールドについてのみ無効化されるべきである。
2. アドオンが、評価およびテストアプリケーションなど、サイトの主機能を壊す場合。

コードによってアドオンが自動的に無効化される場合、アドオンの追加機能をサポートする負担は 作者にかかる。

4.9.2.5 始め方

コンテンツは、認知 障害および学習障害のある人々をサポートする APIおよび拡張機能とともに使用できる。

コンテンツに適したいくつかの APIの使用を通じて、テストを検証する。 例:

• スペルチェッカーおよびパスワード保存アプリまたは拡張機能でテストする。
• メニュー項目（デスクトップの右クリック選択肢）に追加する拡張機能でテストする。
• 簡略化または個人化を有効にし、認知 障害および学習障害のある人々向けに設計されたツールバーでテストする。

4.9.2.6 例

使用する:

1. ブラウザー拡張機能および機能、ならびに個人化ツールバーのサポート。ユーザーは、ページのユーザビリティを 自分に合わせて改善するために、個人化ツールバーから自分の設定を適用できる。
2. 右クリックに選択肢を追加する拡張機能が期待どおりに機能する。
3. ページは、オペレーティングシステムまたはユーザーエージェント内のユーザー設定から 書式化および簡略化できる。

避ける:

1. ブラウザー拡張機能、設定および機能、ならびに個人化ツールバーの動作を妨げる設計およびコード。 例:
   • パスワード保存アプリケーションが機能しない。
   • 気を散らすものを取り除く拡張機能が機能しない。
   • スペルチェッカー拡張機能が右クリックメニューに選択肢を追加しない、またはユーザーの誤りに 下線を引かない。
   • 簡略化ツールバーによって正しい記号を追加できない。
   • ページを書式化したり余白を追加したりできない。
   • ユーザーが好みのフォントを使用できない。

4.9.3.1 ユーザーニーズ

認知的過負荷が多すぎるとまったく機能できないため、余分な選択肢や機能のない、より少ないコンテンツが必要である。

関連ユーザーストーリー: 適応。

4.9.3.3 どのように役立つか

ウェブコンテンツを読んだり使用したりすることに困難があるユーザーは、ウェブページ上の情報が多すぎると 簡単に圧倒される可能性がある。必要な重要情報だけを含むようにページを簡略化し、他のコンテンツや 機能を読んで理解することにすべてのエネルギーを費やさないようにする必要がある。 気が散りやすいユーザーにも同じことが当てはまる。

たとえば、メールプログラムには、メールを下書きするときに多くの機能および書式設定選択肢がある。 これは多くの人々にとって複雑すぎる。個人化により、ユーザーは送信およびキャンセル選択肢だけを持つ 単純な選択肢を利用できる。“to”および件名行はあるが、ccまたはbcc選択肢はない。 この設定では、明確な見出し（メールを書く）があり、ユーザーが理解するアイコンがある。

4.9.3.4 詳細

次に注意する:

• 通常、単純なアプリケーションには3から6個の機能がある。
• 完全機能版へ戻りやすいことを確保する。
• このデザインパターンは次によって満たすことができる:
  • ブラウザーからの簡略版をサポートする、
  • 領域およびコントロールでdata-simplificationを使用する、
  • 個人化セマンティクス内のその他の属性を使用する（[personalization-semantics-1.0] を参照）、
  • 簡略化ツールバーを追加する、または
  • 代替版を提供する。

4.9.3.5 始め方

重要なユーザーテスト経路内にあるコンテンツに、data-simplification="critical"を追加する。

4.9.3.6 例

使用する:

1. 利用可能で閉じやすい、簡略化された“reading”ビュー。
2. 3つの大きな機能を持つアプリケーション。その他の機能はフッターまたは“more”選択肢の下にある。
3. アプリケーションの簡略版が利用可能である。

避ける:

1. 簡略化モードに不要な追加コンテンツがある、またはサポートされていない。
2. 多くの機能を持ち、簡略化できないアプリケーション。例:
   • 忙しいメールプログラムには、タグ付け、グループタグ付け、新しいスレッドの開始など、 多くのコントロールバーおよび機能がある。ページを簡略化する簡単な方法がない。

4.9.4.1 ユーザーニーズ

認識でき、何が起こるか分かる、なじみのあるインターフェイス（の版）が必要である。

関連ユーザーストーリー: 適応。

4.9.4.3 どのように役立つか

個人化は、ユーザーのニーズを満たすようにインターフェイスを変更する。

なじみのある用語および記号を持つことは、多くのユーザーがウェブを使用できるための鍵である。 しかし、あるユーザーになじみがあるものは、別のユーザーにはなじみがなく、新しい記号を学ぶことを 要求する場合がある。セマンティクスを追加することで、個々のユーザーになじみのある拡張機能または ブラウザーによって、記号およびサポートを追加できる。

より強い例は、AAC を使用する人々である。これらのユーザーは通常、1つの記号セットだけを学ぶ。 書かれた形式でAACを 使用する他の人々と簡単にコミュニケーションできなかったり、異なるアプリケーションで使用される異なる記号を 理解することに苦労したりする場合がある。[personalization-semantics-1.0] などの 個人化を使用すると、ユーザーエージェントは個々のユーザーが理解できる記号を読み込める。 ユーザーはウェブおよび他のアプリケーションにもアクセスできる。

その他のサポートには、ユーザーがフォームに入力し、コンテンツを理解する助けとなるオートコンプリートおよび 拡張機能が含まれる。記憶または実行 機能に障害のある多くのユーザーは、情報のコピーを助けてもらったり作業を確認してもらったりするために 誰かに依頼しないと、フォームに入力できない。オートコンプリートにより、より多くのユーザーが自分でフォームを 管理できるようになる。

4.9.4.4 始め方

• すべての一般的なフィールドでHTML autocompleteタグを使用する。
• 個人化された画像を追加するツールバーを追加する。
• 個人化された画像用のツールバーと連携できるセマンティクスを追加する。

4.9.4.5 例

使用する:

1. すべての一般的なフィールドで [HTML5] autocompleteタグを使用する。
2. スタイルに関するブラウザー設定をサポートする本物のテキスト。
3. 個人化された画像を追加するツールバー。
4. 個人化された画像用のツールバー、または [personalization-semantics-1.0] と連携できるセマンティクス。

避ける:

1. [HTML5] autocompleteをサポートしないフォーム。
2. cartoonフォントまたはgothicなど、明確でない、または読みにくい既定フォント。
3. 簡単に個人化できないページ。