アクセシブルなコンテンツ（WCAG 2.1 適合）の作成

この Web コンテンツアクセシビリティガイドライン (WCAG)2.1（によって作成） World Wide Web Consortium の作業グループは、障碍のあるユーザーが Web コンテンツにアクセスして利用できるようにするための、テクノロジーに依存しない一連のガイドラインおよび達成基準で構成されます。

手順の説明に、コンソーシアムは一連のセクションとサポートドキュメントを提供しています。

さらに、詳細は次を参照してください。

ガイドラインは 3 つの適合レベル（レベル A（最低）、レベル AA、レベル AAA（最高））に分けられます。各レベルの簡単な定義を次に示します。

  • レベル A：​サイトのアクセシビリティ基本的な最低レベルに達しています。このレベルに達するには、レベル A の達成基準をすべて満たしている必要があります。
  • レベル AA：​理想的なレベルのアクセシビリティです。ほとんどの状況で、ほとんどのテクノロジーを使用して、ほとんどのユーザーがアクセスできるように、サイトのアクセシビリティの基盤が整備されています。このレベルに達するには、レベル A とレベル AA の達成基準をすべて満たしている必要があります。
  • レベル AAA：​サイトのアクセシビリティが非常に高いレベルに達しています。このレベルに達するには、レベル A、レベル AA およびレベル AAA の達成基準をすべて満たしている必要があります。

サイトを作成する際は、サイトが準拠する全体的なレベルを決めておく必要があります。

次の節では、WCAG 2.1 ガイドラインのレイヤーおよび適合レベル A と AA の関連する達成基準を示します。

メモ

このドキュメントでは、次のものを使用します。

原則 1：知覚可能

原則 1：知覚可能 - 情報およびユーザーインターフェイスコンポーネントは、ユーザーが知覚できる方法でユーザーに提示可能でなければならない。

代替テキスト（1.1）

ガイドライン 1.1 代替テキスト：テキスト以外のコンテンツにはすべて、拡大印刷、点字、音声、シンボル、平易な言葉などの人物が必要とする形式に変換できるように、代替テキストを提供すること。

テキスト以外のコンテンツ (1.1.1)

  • 達成基準 1.1.1
  • レベル A
  • テキスト以外のコンテンツ：ユーザーに提示されるすべてのテキスト以外のコンテンツには、同等の目的を果たす代替テキストが提供されます。ただし、次の場合は除きます。

目的 - テキスト以外のコンテンツ（1.1.1）

Web ページの情報は、画像、ビデオ、アニメーション、グラフ、グラフなど、様々な非テキスト形式で提供できます。視覚障碍や重度の視覚障碍を持つユーザーは、テキスト以外のコンテンツを表示できません。 ただし、テキストコンテンツにアクセスするには、テキストコンテンツをスクリーンリーダーで読み取るか、点字表示装置で触覚形式で提示します。 したがって、グラフィカルな形式のコンテンツに代わるテキストを提供することで、グラフィカルなコンテンツを見ることのできないユーザーは、コンテンツが提供する同等のバージョンの情報にアクセスできます。

他の利点として、代替テキストを使用すると、検索エンジン技術によってテキスト以外のコンテンツのインデックスを作成できるという利点もあります。

達成方法 — テキスト以外のコンテンツ (1.1.1)

静的なグラフィックの場合、そのグラフィックと同等の代替テキストを指定することが基本的な要件です。これは、 代替テキスト フィールドに入力します。例えば、コアコンポーネントを参照してください。 画像.

メモ

標準搭載のコアコンポーネントには、個々の画像に代替テキスト記述を追加するための「代替テキスト」フィールドが用意されていないもの（カルーセル​など）もありますが、「ラベル」フィールド（「アクセシビリティ」タブ）は全コンポーネントにあります。

AEM インスタンスにこれらのバージョンを実装する場合は、作成者がコンテンツに追加できるように、開発チームは alt 属性をサポートするようにこれらのコンポーネントを設定する必要があります（追加の HTML 要素および属性のサポートの追加を参照）。

AEM では、デフォルトで入力される「代替テキスト」フィールドが必要です。画像が単なる装飾用で代替テキストが不要な場合は、「画像は装飾画像」オプションをチェックできます。

適切な代替テキストの作成

テキスト以外のコンテンツには様々な形式があるので、代替テキストの値は、Web ページにおけるグラフィックの役割に応じて異なります。従う必要のある一般的な手法を次に示します。

  • 代替テキストは、簡潔に、テキスト以外のコンテンツが提供する重要な情報を明確に示す必要があります。
  • 過度に長い説明（100 文字を超える）は避ける必要があります。 代替テキストの詳細が必要な場合：
    • 代替テキストで短い説明を提示する
    • 同じページの別の場所、または別の Web ページに長い説明をテキストで含める。 画像をリンクにするか、画像の横にテキストリンクを配置することで、この個別の説明へのリンクを設定します。
  • 代替テキストは、同じページの近くにあるテキストフォームで提供されたコンテンツを複製しないでください。 画像の多くは、ページのテキストで既にカバーされているポイントの図なので、詳細な代替テキストが存在する場合があります。
  • テキスト以外のコンテンツが別のページまたはドキュメントへのリンクであり、同じリンクの他のテキスト構成部分がない場合は、画像の代替テキストがリンク先を示す必要があります。 画像の説明を含めることはできません。
  • テキスト以外のコンテンツがボタン要素に含まれ、同じボタンのテキスト構成部分がない場合、画像の代替テキストはボタンの機能を示す必要があります。 画像の説明を含めることはできません。
  • 画像に空 (null) の代替テキストを指定することは完全に可能ですが、その代替テキストが画像に必要ない場合に限られます。 例えば、純粋な装飾用のグラフィックであるか、同等のテキストがページテキスト内に存在する場合です。

代替テキストが必要な、テキスト以外のコンテンツには、以下のようなタイプがあります。

  • 説明写真： 人、物、場所の画像です。 支援テクノロジーによって要素のタイプ ( 例えば、 graphic または image);使用を明確にすることができます screenshot または illustration 代替テキストの説明では、これはコンテキストによって異なります。 一貫性は重要な要素です。オーサリングチーム全体で一貫性を決定し、ユーザーエクスペリエンス全体で適用する必要があります。
  • アイコン：特定の情報を伝える小さい絵文字です。ページおよびサイト全体で一貫して使用する必要があります。1 つのページまたはサイト上の同じアイコンにはすべて、短く簡潔な同じ代替テキストを含める必要があります。ただし、そうすることにより、隣接するテキストと不要な重複が発生する場合を除きます。
  • グラフとグラフ：これらは通常、数値データを表します。したがって、代替テキストを指定する 1 つの方法は、グラフや図に示す主なトレンドの簡単な概要を含めることです。必要に応じて、 説明 フィールド 詳細 「画像のプロパティ」タブ また、ページやサイトの別の場所で、ソースデータを表形式で提供することもできます。
  • 地図、図、フローチャート：空間データを提供するグラフィックの場合（例：オブジェクト間の関係やプロセスの説明をサポートする場合）は、主要なメッセージをテキスト形式で提供し、このテキスト情報を各関連データポイントの近くに配置します。地図の場合、完全に同等なテキストを提供することは困難な場合が多いものの、特定の場所への行き方を見つける手段として地図が提供されている場合は、地図画像の代替テキストで「X の地図」と簡単に示し、ページ内の別の場所または​画像​コンポーネントの「詳細」タブの「説明」フィールドで、目的の場所への道案内を提供します。
  • CAPTCHA:CAPTCHA は コンピュータと人間を分かち合うための完全に自動化された公開チューリングテスト.これは、悪意のあるソフトウェアと人間を区別するために Web ページで使用されるセキュリティチェックですが、アクセシビリティの問題を引き起こす可能性があります。 セキュリティテストに合格するためにユーザーが何を見たかを説明する必要がある画像です。 画像の代替テキストを指定することはできません。代わりに、グラフィック以外の代替ソリューションを検討する必要があります。 W3C は、次のような提案をいくつか提供します。
    • 論理パズル
    • 画像の代わりにサウンド出力を使用する
    • アカウントおよびスパムフィルターの使用制限
  • 背景画像：HTML ではなくカスケーディングスタイルシート（CSS）を使用します。つまり、代替テキスト値の指定は不可能ということです。したがって、背景画像では重要なテキスト情報を提供しないでください。提供する場合は、同じ情報をページのテキストでも提供する必要があります。ただし、画像を表示できないときに代替の背景を表示することは重要です。
メモ

背景と前景テキストの間には、適切なレベルのコントラストが必要です。詳しくは、 コントラスト（最低限）(1.4.3).

詳細情報 — テキスト以外のコンテンツ (1.1.1)

時間依存メディア (1.2)

ガイドライン 1.2 時間依存メディア：時間依存メディアには代替コンテンツを提供すること。

ここでは、時間依存​の Web コンテンツについて扱います。これには、ユーザーが再生可能なコンテンツ（映像、音声、アニメーションなど）や、収録済みのコンテンツ、ライブストリームなどが含まれます。

音声のみおよび映像のみ（収録済み）（1.2.1）

  • 達成基準 1.2.1
  • レベル A
  • 音声のみおよび映像のみ（収録済み）:収録済みの音声のみおよび収録済みの映像のみのメディアの場合、次の点が当てはまります。ただし、音声または映像がテキストの代替メディアで、次のように明確にラベル付けされている場合を除きます。
    • 収録済み音声のみ：収録済み音声のみのコンテンツに対して同等の情報を提示する時間ベースのメディアの代替手段を提供する。
    • 収録済みビデオのみ：時間ベースのメディアの代替手段、または収録済みの映像専用コンテンツと同等の情報を示すオーディオトラックが提供されます。

目的 - 音声のみおよび映像のみ（収録済み）（1.2.1）

ビデオおよびオーディオのアクセシビリティの問題は、次の方法で発生する場合があります。

  • 視覚障碍のあるユーザー（音声がまったくない場合や、映像またはアニメーションの内容が音声で十分に伝えられていない場合）
  • 聴覚障碍のある人、または聴覚障碍のある人（音声を聞くことができない人）
  • 音声を聞くことはできるが、内容を理解できないユーザー（理解できない言語が使用されている場合など）

また、AdobeFlashなど、特定のメディア形式でのコンテンツの再生をサポートしていないブラウザーやデバイスを使用しているユーザーは、ビデオやオーディオを使用できない場合があります。

この情報を別の形式 ( テキスト（音声なしのビデオの場合は音声）など ) で提供すると、元のコンテンツにアクセスできないユーザーがアクセスできるようになります。

達成方法 - 音声のみおよび映像のみ（収録済み）（1.2.1）

  • 映像なしの収録済み音声コンテンツ（ポッドキャストなど）の場合：
    • コンテンツの直前または直後に、オーディオコンテンツのテキストトランスクリプトへのリンクを提供します。トランスクリプトは、すべての話し声と重要でない内容と同等のテキストを含むHTMLページで、誰が話しているか、設定の説明、声の表情、その他の重要な音声の説明を含むページである必要があります。
  • 音声なしのアニメーションまたは収録済み映像コンテンツの場合：
    • コンテンツの直前または直後に、ビデオから提供される情報に関する同等のテキスト説明へのリンクを提供します
    • または、MP3 などの一般的に使用されるオーディオ形式の同等のオーディオ説明。
メモ

同じ Web ページ上に別の形式で存在するコンテンツの代替としてオーディオまたはビデオコンテンツが提供される場合は、別の代替手段が不要な場合があります。

詳しくは、WCAG 1.2.1 の理解をガイドラインとして参照してください。

マルチメディアを AEM web ページに挿入することは、画像の挿入と似ています。ただし、マルチメディアコンテンツは静止画よりもはるかに多いので、マルチメディアの再生方法を制御するための様々な設定やオプションがあります。

メモ

情報提供のためのコンテンツでマルチメディアを使用する場合は、代替のリンクも作成する必要があります。例えば、字幕を含めるには、字幕を表示するための HTML ページを作成してから、音声コンテンツの横または下にリンクを追加します。

詳細情報 - 音声のみおよび映像のみ（収録済み）（1.2.1）

キャプション（収録済み）（1.2.2）

  • 達成基準 1.2.2
  • レベル A
  • キャプション（収録済み）：同期されたメディアに含まれるすべての収録済み音声コンテンツに対してキャプションが提供されます。ただし、そのメディアがテキストの代替メディアであり、その旨の明確なラベルが付けられている場合を除きます。

目的 - キャプション（収録済み）（1.2.2）

聴覚障碍のあるユーザーは、音声コンテンツにアクセスできないか、アクセスが非常に困難になります。キャプションは、音声で話されている内容と話されていない内容に相当するテキストであり、映像再生中に適時画面に表示されます。これにより、音声を聞くことのできないユーザーが内容を理解できます。

達成方法 - キャプション（収録済み）（1.2.2）

キャプションは、次のいずれかの状態に設定できます。

  • オープン：映像再生時に常に表示
  • クローズド：ユーザーがキャプションのオン、オフを切り替え可能

可能な限りクローズドキャプションを使用して、キャプションを表示するかどうかをユーザーが選択できるようにします。

クローズドキャプションの場合は、適切な形式 ( SMIL) をビデオファイルと一緒に ( これの方法の詳細はこのガイドの範囲外ですが、以下のいくつかのチュートリアルへのリンクが用意されています。 詳細情報 — キャプション（収録済み）(1.2.2)) をクリックします。 映像でキャプションを利用できることをユーザーに知らせるために、注意書きを表示するか、ビデオプレーヤーのキャプション機能を有効にしてください。

オープンキャプションを使用する必要がある場合は、映像トラック内にテキストを埋め込みます。これを行うには、映像にタイトルをオーバーレイできるビデオ編集アプリケーションを使用します。

詳細情報 - キャプション（収録済み）（1.2.2）

音声解説または代替メディア（収録済み）（1.2.3）

  • 達成基準 1.2.3
  • レベル A
  • 音声解説または代替メディア（収録済み）:時間に基づくメディアまたは音声でのビデオコンテンツの説明の代替手段は、同期されたメディアに提供されます。ただし、メディアがテキストの代替メディアであり、明確にラベル付けされる場合を除きます。

目的 - 音声解説または代替メディア（収録済み）（1.2.3）

映像やアニメーションの情報が視覚的にのみ提供されている場合や、内容を視覚的に理解するのに十分な情報が音声で提供されていない場合は、視覚障碍のあるユーザーにアクセシビリティの問題が発生します。

達成方法 - 音声解説または代替メディア（収録済み）（1.2.3）

この達成基準を満たすには、2 つの方法を採用できます。 次のいずれかを指定できます。

  1. ビデオコンテンツの追加の音声解説を含めます。 これを行うには、次の 3 つのうちいずれかの方法を使用します。
    • 既存のボイスの休止部分で、既存の音声トラックでは提示されていないシーンの変化に関する情報を提供します。
    • 元の音声を含み、さらにシーンの変化に関する追加の音声情報も含む新しい追加のオプション音声トラックを提供します。
      • ユーザーは既存のオーディオトラック ( 次の値と等しくない 音声解説を含む ) と新しい音声トラック ( は には、音声の説明が含まれています )。
      • これにより、追加の説明を必要としないユーザーの混乱を防ぐことができます。
    • ビデオコンテンツの 2 つ目のバージョンを作成して、拡張オーディオの説明を許可します。 これにより、適切な時点で音声と映像を一時的に休止して既存のボイスの合間に詳細な音声解説を提供することに関連する困難な作業を軽減できます。その結果、アクションが再び開始する前に、より長い音声解説を指定できます。 前の例と同様に、これはオプションの追加のオーディオトラックとして提供され、追加の説明を必要としないユーザーの中断を防ぐのに最適です。
  2. ビデオやアニメーションのオーディオやビジュアル要素に相当する適切なテキストのトランスクリプトを提供します。 これには、誰が話しているかを示す表示、設定の説明、視覚的に提示されるイベントや情報、声の表現などが必要です。 長さに応じて、トランスクリプトをビデオやアニメーションと同じページに配置したり、別のページに配置したりできます。後者のオプションを選択する場合は、ビデオまたはアニメーションの横にあるトランスクリプトへのリンクを指定します。

音声解説付きビデオの作成方法の正確な詳細については、このガイドの範囲外です。 映像および音声解説の作成には長時間を要する可能性がありますが、他のアドビ製品が役に立つ場合があります。

詳細情報 - 音声解説または代替メディア（収録済み）（1.2.3）

キャプション（ライブ）（1.2.4）

  • 達成基準 1.2.4
  • レベル AA
  • キャプション（ライブ）:同期されたメディア内のすべてのライブオーディオコンテンツにキャプションが提供されます。

目的 — キャプション（ライブ）(1.2.4)

この達成基準は、聴覚障碍のあるユーザーのアクセシビリティに関する問題に対応する点で、キャプション（収録済み）と同じです。ただし、この達成基準では Web キャストなどライブのプレゼンテーションを扱う点が異なります。

達成方法 - キャプション（ライブ）（1.2.4）

次に示すガイダンスに従います。 キャプション（収録済み） 上ただし、メディアの生きた性質上、キャプションのプロビジョニングは、可能な限り迅速に、また、何が起きているかに応じて作成する必要があります。 したがって、リアルタイムキャプションまたは音声ツーテキストツールの使用を検討する必要があります。

詳細な手順説明はこのドキュメントの範囲外ですが、次のリソースで役に立つ情報が提供されています。

詳細情報 - キャプション（ライブ）（1.2.4）

音声解説（収録済み）（1.2.5）

  • 達成基準 1.2.5
  • レベル AA
  • 音声解説（収録済み）:音声解説は、同期されたメディア内のすべての収録済み映像コンテンツに対して提供されます。

目的 - 音声解説（収録済み）（1.2.5）

この達成基準は、音声解説または代替メディア（収録済み）と同じです。ただし作成者は、レベル AA に準拠するために、より詳細な音声解説を提供する必要があります。

達成方法 - 音声解説（収録済み）（1.2.5）

音声解説または代替メディア（収録済み）のガイダンスに従ってください。

詳細情報 - 音声解説（収録済み）（1.2.5）

適応可能 (1.3)

ガイドライン 1.3 適応可能：情報や構造を失うことなく、様々な方法（例えば、よりシンプルなレイアウト）で提示できるコンテンツを作成できます。

このガイドラインでは、以下をおこなうユーザーをサポートするために必要な要件について説明します。

  • そのコンテンツのデフォルト表示（複数列のレイアウトや、色や画像を多用したページなど）では、作成者が提示した情報にアクセスできない場合があるユーザー

  • 音声のみ、または大きいテキストや高いコントラストなど、代替の視覚表示を使用する可能性のあるユーザー

情報および関係性（1.3.1）

  • 達成基準 1.3.1
  • レベル A
  • 情報と関係：プレゼンテーションを通じて伝達される情報、構造、関係は、プログラムによって決定されるか、テキストで使用できます。

目的 — 情報および関係性 (1.3.1)

障害を持つユーザーが使用する多くの支援テクノロジーでは、効果的に表示または 理解する コンテンツ。 この構造情報は、ページ見出し、テーブルの行見出しおよび列見出し、およびリストタイプの形式を取ることができます。 例えば、スクリーンリーダーを使用すれば、ページ内を見出しから見出しへと移動できます。ただし、ページコンテンツの構造が基になる HTML ではなく、視覚的なスタイルでのみ設定されているように見える場合、支援テクノロジーでは構造情報を利用できず、ブラウジングの操作性の向上を十分サポートできなくなります。

この達成基準の目的は、ブラウザーおよび支援テクノロジーが構造情報にアクセスし情報を利用できるように、構造情報が HTML やその他のコーディング手法を使用してプログラムで確実に提供されるようにすることです。

達成方法 - 情報および関係性（1.3.1）

AEM では、適切な HTML 要素を使用することにより、意味のある Web コンテンツを簡単に構築できます。RTE（テキストコンポーネント）でページコンテンツを開き、 Paraformat メニュー（段落記号）を使用して、適切な構造要素（段落や見出しなど）を指定します。

次の要素を適宜使用して、Web ページに適切な構造が指定されていることを確認できます。

  • 見出し： RTE のアクセシビリティ機能を有効にしている限り、AEMでは 3 つのレベルのページ見出しが提供されます。 これらを使用して、コンテンツのセクションおよびサブセクションを識別できます。「見出し 1」は最上位の見出し、「見出し 3」は最下位の見出しです。システム管理者の設定により、使用可能な見出しレベルを増やすこともできます。

  • リスト：HTML を使用して、3 つの異なるタイプのリストを指定できます。

    • <ul> 要素は、順序なし（箇条書き）リストに使用します。個々のリスト項目は、<li> 要素を使用して識別されます。RTE では、 箇条書き アイコン
    • <ol> 要素は、番号付きリストに使用します​。​個々のリスト項目は、<li> 要素を使用して識別されます。RTE では、「番号付きリスト」アイコンを使用します。

    既存のコンテンツを特定のリストタイプに変更する場合は、適切なテキストをハイライト表示し、適切なリストタイプを選択します。 前の例に示すように、適切なリスト要素がHTMLに自動的に追加されます。

    全画面表示モードでは、個別の​箇条書きリスト​および​番号付きリスト​アイコンが表示されます。全画面表示モード以外の場合、1 つの​リスト​アイコンから 2 つのオプションを使用できます。

  • テーブル：データのテーブルは、HTML のテーブル要素を使用して識別する必要があります。

    • 1 つの <table> 要素
    • テーブルの行ごとに 1 つの <tr> 要素
    • 行および列の見出しごとに 1 つの <th> 要素
    • データセルごとに 1 つの <td> 要素

    また、アクセス可能なテーブルでは、次の要素と属性を使用します。

    • <caption> 要素は、テーブルの表示可能なキャプションを提供する際に使用します。キャプションは、デフォルトではテーブルの上に中央揃えで表示されますが、CSS を使用して適切に配置できます。 キャプションはプログラムによってテーブルに関連付けられるので、コンテンツを紹介する際に役立ちます。
    • <summary> 要素は、目の見えるユーザーに見えているものの概要を提示することで、視覚障碍のあるユーザーがテーブル内の情報をより簡単に理解できるように支援します。これは、複雑な、または従来とは異なるテーブルレイアウトが使用されている場合に便利です（この属性はブラウザーには表示されず、支援テクノロジーに対してのみ読み取られます）。
    • <th> 要素の scope 属性は、セルが特定の行のヘッダーを表すか、特定の列のヘッダーを表すかを示すために使用します。同様の方法として、データセルが 1 つ以上のヘッダーに関連付けられている複雑なテーブルで、header 属性と id 属性を使用することがあります。
    メモ

    デフォルトでは、これらの要素や属性を直接使用することはできませんが、システム管理者が、「テーブルのプロパティ」ダイアログボックスでこれらの値のサポートを追加することは可能です（追加の HTML 要素および属性のサポートの追加を参照してください）。

    「テーブルのプロパティ」タブを選択できる​テーブル​ダイアログを開くには、次のようにします。

    • 適切な キャプション.
    • 理想としては、「幅」、「高さ」、「ボーダー」、「セル内の余白」、「セルの間隔」のデフォルト値をすべて削除します。これらのプロパティはグローバルスタイルシートで設定できるからです。

    その後、 セルのプロパティ セルがデータ・セルかヘッダー・セルかを選択するには、次の手順に従います。

  • 強調：<strong> または <em> 要素を使用して強調を指定します。段落内のテキストをハイライト表示するために見出しを使用しないでください。

    • 強調するテキストをハイライト表示します。

    • 次をクリック： B アイコン ( <strong>) または I アイコン ( <em>) が プロパティ パネル ( 必ずHTMLを選択 )。

      メモ

      AEM の標準的なインストールに含まれる RTE は、次のように設定されています。

      • <b> の代わりに <strong> を使用
      • <i> の代わりに <em> を使用

      それぞれ実質的には同じですが、好ましいのは、意味的に正しい HTML である <strong> と <em> です。開発チームがプロジェクトインスタンスを作成する際に、<strong> と <em> ではなく <b> と <i> を使用するように RTE を設定できます。

  • 複雑なデータテーブル:2 つ以上のレベルのヘッダーを持つ複雑なテーブルが存在する場合、必要な構造情報をすべて提供するのに基本的なテーブルプロパティでは不十分な場合があります。 このような複雑なテーブルでは、 ヘッダー および id 属性。

    メモ

    id 属性は、標準のインストールでは使用できません。 有効にするには、RTE でHTMLルールとシリアライザーを設定します。

    例えば、以下に示すテーブルでは、支援テクノロジーユーザーのためのプログラムによる関連付けを作成するために、header と id が照合されています。

      <table>
    <tr>
      <th rowspan="2" id="h">Homework</th>
      <th colspan="3" id="e">Exams</th>
      <th colspan="3" id="p">Projects</th>
    </tr>
    <tr>
      <th id="e1" headers="e">1</th>
      <th id="e2" headers="e">2</th>
      <th id="ef" headers="e">Final</th>
      <th id="p1" headers="p">1</th>
      <th id="p2" headers="p">2</th>
      <th id="pf" headers="p">Final</th>
    </tr>
    <tr>
      <td headers="h">15%</td>
      <td headers="e e1">15%</td>
      <td headers="e e2">15%</td>
      <td headers="e ef">20%</td>
      <td headers="p p1">10%</td>
      <td headers="p p2">10%</td>
      <td headers="p pf">15%</td>
    </tr>
  </table>

    これをAEMで実現するには、ソース編集モードを使用してマークアップを直接追加します。

    メモ

    この機能は、標準インストールではすぐには使用できません。 RTE、HTMLルールおよびシリアライザーを設定する必要があります。

詳細情報 - 情報および関係性（1.3.1）

意味のあるシーケンス（1.3.2）

  • 達成基準 1.3.2
  • レベル A
  • 意味のあるシーケンス：コンテンツが提示される順序がその意味に影響を与える場合、正しい読み取り順序をプログラム的に決定することができる。

目的 - 意味のあるシーケンス（1.3.2）

この達成基準の目的は、ユーザーエージェントが意味を理解するために必要な読み取り順序を維持しながら、コンテンツの代替表示を可能にすることです。意味を持つコンテンツの少なくとも 1 つのシーケンスをプログラムで判断できることが重要です。この達成基準を満たさないコンテンツは、支援テクノロジーがコンテンツを誤った順序で読み取った場合や、代替スタイルシートやその他の書式変更が適用された場合、ユーザーを混乱させたり、方向を狂わせたりする可能性があります。

達成方法 - 意味のあるシーケンス（1.3.2）

達成基準 1.3.2 の達成方法のガイドラインに従います。

詳細情報 - 意味のあるシーケンス（1.3.2）

感覚的な特徴（1.3.3）

  • 達成基準 1.3.3
  • レベル A
  • 感覚的な特徴：内容を理解し、操作するために提供される指示は、形状、サイズ、視覚的な位置、向き、音などのコンポーネントの感覚的な特徴にのみ依存しません。

目的 — 感覚的な特徴 (1.3.3)

デザイナーは、情報を提示する際に、色、形状、テキストスタイル、コンテンツの絶対位置や相対位置など、視覚的なデザイン特性に注目することがよくあります。これらは情報を伝達する強力なデザイン技術です（認知アクセシビリティのニーズを持つ視覚的ユーザーの全体的なアクセシビリティを向上させます）が、視覚障碍のあるユーザーは、位置、色、形状などの属性を視覚的に識別する必要がある情報にアクセスできません。

同様に、話し手が男性か女性かなど、異なる音を区別する必要のある情報は、聴覚障碍のあるユーザーに対して、音声コンテンツの代替テキストに反映されないと、アクセシビリティの問題を生み出します。

メモ

色の代替に関する要件については、 色の使用.

達成方法 — 感覚的な特徴 (1.3.3)

ページコンテンツの視覚的特性に依存する情報も、別の形式で提示されるようにしてください。

  • 情報を提供する際に、視覚的な位置に依存しないでください。 例えば、ユーザーをページの右側にあるメニューに移動して詳細情報にアクセスしたい場合、 右のメニュー;代わりに、メニューに名前を付け（例えば、見出しを使用）、テキストでその名前を参照します。
  • 情報を伝える唯一の方法として、テキストのスタイル設定（太字や斜体など）に依存しないようにします。
メモ

非視覚的なコンテキストで意味を持つと理解されている場合は、記述的用語の使用にも同意できます。 例えば、 上 および 下 一般に、特定のコンテンツの項目の前後のコンテンツを示すので、受け入れ可能です。これは、コンテンツが声に出して話される場合に、引き続き意味をなします。

詳細情報 - 感覚的な特徴（1.3.3）

判別可能 (1.4)

ガイドライン 1.4 判別可能：コンテンツを、利用者にとって見やすく、聞きやすいものにします。これには、前景と背景を区別することも含む。

色の使用（1.4.1）

  • 達成基準 1.4.1
  • レベル A
  • 色の使用：色は、情報を伝達し、アクションを示し、応答を促す、または視覚要素を区別する唯一の視覚的手段としては使用されません。
メモ

この達成基準は、特に色覚に対応しています。 他の知覚の形態は、 適応可能 (1.3);色およびその他の視覚的表現コーディングへのプログラム的なアクセスを含む

目的 — 色の使用 (1.4.1)

色は、Web ページの美的な魅力を高める効果的な方法であり、情報を伝達するのにも役立ちます。 しかし、視覚障碍から視覚障碍まで、視覚障碍の範囲があり、特定の色を区別できない人もいます。 これにより、色分けが信頼できない情報提供方法になります。

例えば、赤 — 緑の色覚障害を持つ人は、緑の色合いと赤の色合いを区別できません。 両方の色が 3 番目の色（例えば、茶色）と見なされる場合があり、その場合、赤、緑、茶を区別できません。

また、テキストのみのブラウザー、モノクロのディスプレイデバイスを使用したり、ページの白黒印刷を表示したりしても、色を認識することはできません。

さらに考えてみれば 選択済み インターフェイス要素（タブ、切り替えボタンなど）の状態。色を使用する以外の方法で、視覚的な表示以外の方法で伝える必要があります。 このような要素については、特定の感覚に依存しない包括的なユーザーエクスペリエンスを作成する場合、さらにパターン、図形、プログラム情報を使用すると役に立ちます。

達成方法 - 色の使用（1.4.1）

色を使用して情報を伝達する場合は、色を見なくても情報を利用できるようにしてください。

例えば、色によって提供されている情報を、テキストでも明示的に提供します。

情報を提供するためのキューとして色を使用する場合は、スタイル（太字、斜体など）やフォントの変更など、さらに視覚的なキューを提供する必要があります。 これは、視力が低い人や、色覚多様性を持つ人物が情報を特定するのに役立ちます。ただし、ページをまったく見ることのできない人には役に立たないので、全面的に依存することはできません。したがって、視覚障碍のあるユーザーにこのような情報を伝えるには、隠しテキストを提供したり、ARIA（アクセシブルリッチインターネットアプリケーション）Web 標準規格などのプログラマティックソリューションを使用したりすると、役に立つ場合があります。

詳細情報 - 色の使用（1.4.1）

音声の制御（1.4.2）

  • 達成基準 1.4.2
  • レベル A
  • 音声の制御：web ページ上の任意の音声が 3 秒以上自動的に再生される場合は、音声を一時停止または停止するメカニズムか、システム全体の音量レベルとは別に、音声の音量を制御するメカニズムが使用できる。

目的 - 音量の制御（1.4.2）

画面読み上げソフトウェアを使用している個人は、同時に他の音声が再生されている場合、音声出力を聞き取るのが難しい場合があります。この問題は、スクリーンリーダーの音声出力が（現在のほとんどの場合と同様に）ソフトウェアベースで、サウンドと同じ音量コントロールを介して制御される場合に悪化します。 また、認知障碍や神経多様性のあるユーザーの中には、音に対する感受性が強い人もいる場合があります。 音声コンテンツの音量レベルを変更できないと、問題が発生します。

したがって、ユーザーがバックグラウンドサウンドをオフにできることが重要です。

メモ

音量の調節には、音量をゼロにできることを含みます。

達成方法 - 音声の制御（1.4.2）

達成基準 1.4.2 の達成方法のガイドラインに従います。

詳細情報 - 音声の制御（1.4.2）

コントラスト（最低限）（1.4.3）

  • 達成基準 1.4.3

  • レベル AA

  • コントラスト（最小）:テキストとテキストの画像の視覚的な表示は、以下の場合を除き、4.5:1 以上のコントラスト比を持ちます。

    • 大きいテキスト：大きなテキストと大きなテキストの画像のコントラスト比は 3:1 以上です。
    • 付随：非アクティブなユーザーインターフェイスコンポーネントに含まれるテキストまたはテキストの画像 純粋な装飾（誰にも表示されない、または他の視覚的コンテンツを含む画像の一部である場合）、コントラストの要件はありません。
    • ロゴタイプ：ロゴまたはブランド名の一部であるテキストには、最低コントラストの要件はありません。
    メモ

    詳しくは、 テキスト以外のコントラストについて 詳細については、を使用して、コンテンツ作成者がテキスト以外の要素（アイコン、インターフェイス要素など）に関する追加要件を把握できるようにします。

目的 - コントラスト（最低限）（1.4.3）

特定の視覚障碍のあるユーザーは、特定の低コントラストの色のペアを区別できない場合があります。次のいずれかの場合に、このようなユーザーにアクセシビリティの問題が発生することがあります。

  • テキストと背景色のコントラストが不十分な場合。
  • 情報を区別する際には、テキスト（リンクテキスト、非リンクテキストなど）の色分けが重要です。
メモ

装飾目的でのみ使用されるテキストは、この達成基準から除外されます。

達成方法 — コントラスト（最低限）(1.4.3)

テキストと背景とのコントラストが十分であることを確認します。 コントラスト比は、問題のテキストのサイズとスタイルによって異なります。

  • テキストのサイズが 18 ポイント（太字の場合は 14 ポイント）未満の場合、テキストまたはテキストの画像と背景の間のコントラスト比は 4.5:1 以上である必要があります。
  • サイズが 18 ポイント（太字の場合は 14 ポイント）以上のテキストの場合、コントラスト比は 3:1 以上である必要があります。
  • 背景をパターン化する場合は、4.5:1 または 3:1 の比率を維持するために、任意のテキストの周囲の背景を網掛けにする必要があります。
メモ

フォントは、同等の PT/PX/EM サイズ設定をレンダリングする方法が異なる場合があることに注意してください。

Web コンテンツに適したフォントとサイズ設定を選択する際は、読みやすさと使いやすさを慎重に考慮し、適切な判断を下してください。

メモ

次のサイトは他の単位への変換に役立ちます。

  • Px から Em 電卓 — オムニ
  • 「フォントサイズの変換：pixel-point-em-rem-percent" https://websemantics.uk/tools/font-size-conversion-pixel-point-em-rem-percent/
  • PMtoEM.com を参照してください。PX から EM への変換が簡単になった時点 http://pxtoem.com/

コントラスト比を確認するには、 Paciello Group 色コントラストアナライザ または WebAIM カラーコントラストチェッカー. これらのツールを使用すると、色のペアを確認し、コントラストの問題を報告できます。

また、ページの外観の指定に関心がない場合は、背景と前景のテキストの色を指定しないように選択できます。 ユーザーのブラウザーがテキストと背景の色を決定するので、コントラストチェックは必要ありません。

推奨コントラストレベルを満たせない場合は、（色コントラストの問題のない）代替の同等バージョンのページへのリンクを提供します。 または、ユーザーがページのカラースキームのコントラストを独自の要件に合わせて調整することもできます。

詳細情報 — コントラスト（最低限）(1.4.3)

テキストのサイズ変更（1.4.4）

  • 達成基準 1.4.4
  • レベル A
  • テキストのサイズ変更：テキストのキャプションと画像を除き、テキストは 200 パーセントまで支援テクノロジーを必要とせずに、コンテンツや機能を失うことなくサイズ変更できる。

目的 - テキストのサイズ変更（1.4.4）

この達成基準の目的は、テキストベースの制御（見えるように表示されたテキスト文字 [対 ASCII などのデータ形式にあるテキスト文字]）を含む、視覚的にレンダリングされたテキストを、拡大鏡などの支援テクノロジーを使用せずに、正常に拡大・縮小できるようにすることです。ユーザーが web ページのすべてのコンテンツを拡大・縮小するメリットを受ける場合もありますが、テキストは最も重要です。

達成方法 - テキストのサイズ変更（1.4.4）

次のガイドラインに従う以外に 達成基準 1.4.4 の達成方法 コンテンツ作成者が、ページデザインやフォントサイズ（「レスポンシブ Web デザイン」など）で流動的で柔軟な幅や高さを使用して、読者がテキストをサイズ変更できるようにすることができます。

詳細情報 - テキストのサイズ変更（1.4.4）

文字画像（1.4.5）

  • 達成基準 1.4.5
  • レベル AA
  • 文字画像：使用しているテクノロジーで視覚的表現を実現できる場合に、文字画像ではなくテキストを使用して情報を伝達している。ただし、次の場合を除く。
    • カスタマイズ可能：テキストの画像は、ユーザーの要件に合わせて視覚的にカスタマイズできます。
    • 基本：伝える情報には、特定のテキストの表示が不可欠です。
メモ

ロゴタイプ（ロゴまたはブランド名の一部であるテキスト）は必須と見なされます。

目的 — 文字画像 (1.4.5)

テキストの画像は、特定のスタイルのテキストが望ましい場合によく使用されます。例えば、ロゴタイプや、別のソースからテキストが生成された場合（紙のドキュメントをスキャンする場合など）です。 ただし、HTML で表示され、CSS を使用してスタイル設定されたテキストと比較すると、テキストの画像には、視覚障がいや読み取りが困難な人にとって必要なサイズや外観を変更するという柔軟性がありません。

達成方法 - 文字画像（1.4.5）

文字画像を使用する必要がある場合は、CSS を使用して、文字画像を同等の HTML テキストに置き換え、テキストをカスタマイズ可能にします。例については、 C30:CSS を使用して、テキストを画像のテキストに置き換え、切り替えるユーザーインターフェイスコントロールを提供する.

詳細情報 - 文字画像（1.4.5）

原則 2:操作可能

原則 2：操作可能 - ユーザーインターフェイスコンポーネントおよびナビゲーションは操作可能でなければならない。

キーボード操作可能（2.1）

ガイドライン 2.1 キーボード操作可能：すべての機能をキーボードから使用できること。

これは、キーボードを使用してすべての機能のアクセスを確保することを目的としています。

キーボード（2.1.1）

  • 達成基準 2.1.1
  • レベル A
  • キーボード：コンテンツのすべての機能が、個々のキー操作に特定のタイミングを必要とせずに、キーボードインターフェイスを介して操作できる。ただし、基になる機能は、エンドポイントだけでなく、ユーザーの移動のパスに依存する入力を必要とすることは例外とする。

目的 - キーボード（2.1.1）

この達成基準の目的は、可能な限りコンテンツをキーボード（または代替キーボード利用できるような）キーボードインターフェイスで操作ができるようにすることです。キーボードや代替キーボードを介して操作できる場合、視覚障碍（目の操作を必要とするマウスなどのデバイスを使用できない人）や、キーボードエミュレーターとして機能する代替キーボードや入力デバイスを使用する人が操作できます。 キーボードエミュレーターには、音声入力ソフトウェア、息操作ソフトウェア、画面キーボード、スキャンソフトウェア、様々な支援技術や代替キーボードが含まれます。 視覚障碍を持つ人は、ポインタの追跡が困難な場合があり、キーボードから制御できれば、ソフトウェアの使用がはるかに簡単（または可能な限り）になる可能性があります。

達成方法 - キーボード（2.1.1）

達成基準 2.1.1 の達成方法のガイドラインに従います。

詳細情報 - キーボード（2.1.1）

キーボードトラップなし（2.1.2）

  • 達成基準 2.1.2
  • レベル A
  • キーボードトラップなし：キーボードインターフェイスを使用してキーボードフォーカスをページのコンポーネントに移動できる場合、キーボードインターフェイスのみを使用してコンポーネントからフォーカスを移動できる。また修飾キーを伴わない矢印キーやタブキーなどの標準的な方法以上のものが必要な場合、ユーザーにフォーカスを外す方法を通知できる。

目的 - キーボードトラップなし（2.1.2）

この達成基準の目的は、コンテンツが web ページ上のコンテンツのサブセクション内にキーボードフォーカスを​トラップ​しないようにすることです。これは、複数の形式がページ内で組み合わされ、プラグインや埋め込みアプリケーションを使用してレンダリングされる場合に発生する一般的な問題です。

web ページの機能によって、フォーカスがコンテンツのサブセクション（モーダルダイアログなど）に制限される場合があります。そのような場合は、コンテンツのサブセクションからユーザーが移動できる方法を用意しておく必要があります（例えば、ESC キーや「閉じる」ボタンでモーダルダイアログを閉じるなど）。

達成方法 - キーボードトラップなし（2.1.2）

達成基準 2.1.2 の達成方法のガイドラインに従います。

詳細情報 - キーボードトラップなし（2.1.2）

十分な時間（2.2）

ガイドライン 2.2 十分な時間：ユーザーがコンテンツを読み、使用するのに十分な時間を提供します。

これは、ユーザーがコンテンツを読んで行動を起こすのに十分な時間を確保することを目的としています。

タイミング調整可能（2.2.1）

  • 達成基準 2.2.1
  • レベル A
  • キーボード：ユーザーがコンテンツを読み、使用するのに十分な時間を提供すること。

目的 - タイミング調整可能（2.2.1）

この達成基準の目的は、可能な限り常に、障碍のあるユーザーが Web コンテンツを利用するのに十分な時間を提供することです。全盲、視覚障碍、手指の障碍、認知機能の制限など、障碍のあるユーザーは、コンテンツを読むのに時間がかかる場合や、オンラインフォームの入力などの機能を実行するのに時間がかかる場合があります。Web 機能が時間に依存する場合は、制限時間より前に必要な操作を行うのが難しい場合があります。これにより、サービスにアクセスできなくなる場合があります。時間に依存しない機能をデザインすることで、障碍のあるユーザーがこれらの機能を完了するのに役立ちます。 時間制限の無効化、時間制限のカスタマイズ、時間制限になる前のリクエスト時間の延長をおこなうオプションを提供すると、タスクの完了に予想以上の時間を要するユーザーの役に立ちます。 これらのオプションは、ユーザーにとって最も役に立つ順に表示されます。時間制限を無効にする方が、時間制限の長さをカスタマイズするよりも効果的で、時間制限の長さをカスタマイズする方が、時間制限前の延長リクエストよりも効果的です。

達成方法 - タイミング調整可能（2.2.1）

達成基準 2.2.1 の達成方法のガイドラインに従います。

詳細情報 - タイミング調整可能（2.2.1）

一時停止、停止、非表示（2.2.2）

  • 達成基準 2.2.2
  • レベル A
  • 一時停止、停止、非表示：情報の移動、点滅、スクロールまたは自動更新について、以下が該当する。
    • 動き、点滅、スクロール：(a) 自動的に開始し、(b)5 秒以上存続し、© 他のコンテンツと並行して提示される移動、点滅、スクロールの情報に対して、移動、点滅、またはスクロールが必要なアクティビティの一部でない限り、ユーザーが一時停止、停止、非表示にする仕組みがある。
    • 自動更新：(a) 自動的に開始し、(b) 他のコンテンツと並行して提示される自動更新情報に対しては、自動更新が必要なアクティビティの一部でない限り、ユーザーが更新を一時停止、停止または非表示にしたり、更新の頻度を制御したりするメカニズムがあります。

注意点は次のとおりです。

  1. コンテンツの明滅や閃光に関連する要件については、発作の防止：発作を引き起こすようなコンテンツを設計しないこと（2.3）を参照してください。
  2. この達成基準を満たさないコンテンツがある場合は、ユーザーがページ全体を使用できない場合があるので、web ページ上のすべてのコンテンツ（他の達成基準を満たすために使用されているかどうかにかかわらず）が、この達成基準を満たす必要があります。適合要件の「5. 非干渉」を参照してください。
  3. ソフトウェアやユーザーエージェントにストリーミングされるコンテンツは、一時停止の開始と再開の間に生成または受け取った情報を保存または表示する必要はありません。これは技術的には不可能で、誤解を招く可能性があります。
  4. プリロードフェーズの一部として発生するアニメーションや同様の状況は、すべてのユーザーのフェーズでインタラクションが発生しない場合や、進行状況を示さない場合に、コンテンツが凍結または壊れたと考える原因となる場合は、重要と見なすことができます。

目的 — 一時停止、停止、非表示 (2.2.2)

ユーザーによっては、動くコンテンツが気が散る、さらには肉体的に苦痛とまで感じられて、ページの他の部分に集中することが難しくなる場合があります。また、動くテキストに追いつかない人には、このようなコンテンツが読みにくいことが証明される場合があります。

達成方法 - 一時停止、停止、非表示（2.2.2）

移動、閃光、点滅のコンテンツを含む Web ページを作成する際は、コンテンツの特性に応じて、次の 1 つ以上の提案事項を適用できます。

  • ユーザーがコンテンツを読むのに十分な時間を提供するために、コンテンツのスクロールを一時停止する手段を提供する。 例えば、ニュースティッカー、自動更新テキスト、自動進行する画像カルーセルなどです。
  • 点滅するコンテンツが、5 秒後に点滅を停止するようにします。
  • ブラウザーで無効にできる、動きや点滅のあるコンテンツを表示するには、適切なテクノロジーを使用します。例えば、Graphics Interchange Format（GIF）ファイルや Animated Portable Network Graphics（APNG）ファイルなどです。
  • ページ上の動きや点滅のあるコンテンツをすべてユーザーが無効にできるように、web ページでのフォームコントロールを提供します。
  • 上記の方法が不可能な場合は、含まれているすべてのコンテンツに動きや点滅がないページへのリンクを提供します。

詳細情報 - 一時停止、停止、非表示（2.2.2）

発作および身体的反応（2.3）

ガイドライン 2.3 発作の防止：発作や身体的反応を引き起こすようなコンテンツを設計しないこと。

3 回の閃光、またはしきい値以下（2.3.1）

  • 達成基準 2.3.1
  • レベル A
  • 3Flash以下：1 秒間の間に 3 回以上閃光するものが Web ページに含まれていない、または閃光が一般閃光しきい値および赤閃光しきい値を下回っている。
メモ

この達成基準を満たさないコンテンツは、ユーザーによるページ全体の使用に支障を来す可能性があるので、Web ページ上のすべてのコンテンツ（他の達成基準を満たすために使用されているかどうかに関わらず）は、この達成基準を満たす必要があります。 適合要件の「5. 非干渉」を参照してください。

目的 - 3 回の閃光、またはしきい値以下（2.3.1）

場合によっては、閃光するコンテンツが感光性発作を引き起こすことがあります。 この達成基準を使用すると、閃光によるコンテンツを気にすることなく、すべてのコンテンツにアクセスして体験することができます。

達成方法 — 3Flash以下 (2.3.1)

次の手順を実行して、次の手法が適用されていることを確認します。

  • 1 秒間の間に 3 回以上コンポーネントが点滅しないようにします。
  • 上記の条件を満たさない場合、 小安全地域 画面上のピクセル単位で指定します。 この領域は、複雑な数式 ( G176:点滅領域を十分に小さく保つしたがって、この方法に従う必要があるのは、コンテンツの点滅が必要な場合のみです。

詳細情報 - 3 回の閃光、またはしきい値以下（2.3.1）

ガイドライン 2.4 ナビゲーション可能：ユーザーのナビゲーション、コンテンツの検索、位置の特定に役立つ方法を提供します。

これは、ユーザーがコンテンツを簡単かつ明白にナビゲートできることを目的としています。

ブロックのスキップ（2.4.1）

  • 達成基準 2.4.1
  • レベル A
  • ブロックのスキップ：複数の web ページで繰り返されるコンテンツのブロックをスキップする仕組みが利用できる。

目的 - ブロックのスキップ（2.4.1）

この達成基準の目的は、コンテンツ間を順番に移動する訪問者が、web ページの主要なコンテンツにより直接敵にアクセスできるようにすることです。web ページやアプリケーションには、他のページや画面に表示されるコンテンツが含まれる場合が多くあります。コンテンツの繰り返しブロックの例としては、ナビゲーションリンク、ヘッダーグラフィック、メニュー、広告フレームなどがありますが、これらに限定されません。個々の単語、フレーズ、単一のリンクなどの小さな繰り返しセクションは、この規定の目的ではブロックとは見なされません。

達成方法 - ブロックのスキップ（2.4.1）

達成基準 2.4.1 の達成方法のガイドラインに従います。

詳細情報 - ブロックのスキップ（2.4.1）

ページタイトル（2.4.2）

  • 達成基準 2.4.2
  • レベル A
  • ページタイトル：web ページが、トピックまたは目的を説明するタイトルを持つ。

目的 — ページタイトル (2.4.2)

この達成基準は、特定の障害に関係なく、誰でも、ページを読み上げることなく、Web ページのコンテンツをすばやく特定するのに役立ちます。 これは、ページタイトルが「 」タブに表示されるので、複数の Web ページをブラウザーのタブで開く場合に便利です。ページタイトルはすばやく見つけることができます。

達成方法 — ページタイトル (2.4.2)

AEM で新しい HTML ページを作成する際には、ページタイトルを指定できます。訪問者がコンテンツがニーズに関連しているかどうかをすばやく識別できるように、ページのコンテンツや目的、特に独自の側面を十分に説明するタイトルにしてください。

ページを編集する際に、ページタイトルを編集することもできます（ページ情報／プロパティ​からアクセス可能）。

詳細情報 - ページタイトル（2.4.2）

フォーカス順序（2.4.3）

  • 達成基準 2.4.3
  • レベル A
  • フォーカス順序：web ページを順次ナビゲーションでき、ナビゲーションのシーケンスが意味や操作に影響を与える場合、フォーカス可能なコンポーネントは、意味や操作性を保持する順序でフォーカスを受け取る。

目的 - フォーカス順序（2.4.3）

この達成基準の目的は、ユーザーがコンテンツを順番に移動する際に、コンテンツの意味に合った順序で情報が表示され、キーボードから操作できるようにすることです。これにより、ユーザーがコンテンツの一貫したメンタルモデルを作成できるので、混乱が軽減されます。コンテンツ内の論理的な関係を反映した異なる順序が存在する場合があります。例えば、複数のフィールドやステップで構成されるオンラインフォームでのコンポーネント間の移動は、コンテンツ内の論理的な関係を反映しています。

達成方法 - フォーカス順序（2.4.3）

達成基準 2.4.3 の達成方法のガイドラインに従います。

詳細情報 - フォーカス順序（2.4.3）

  • 達成基準 2.4.4
  • レベル A
  • リンクの目的（コンテキスト内）:各リンクの目的は、リンクテキストのみから、またはプログラムで決定されたリンクコンテキストと共に、リンクテキストから決定できます。ただし、リンクの目的が一般的にユーザーにはあいまいな場合を除きます。

障害に関係なく、適切なリンクテキストを介したリンクの向きを明確に示すことが、すべてのユーザーにとって不可欠です。 これは、実際にリンクをたどるかどうかを判断するのに役立ちます。 目の見えるユーザーにとって意味のあるリンクテキストは、ページ上に複数のリンクがある場合（特にページがテキストの重い場合）に役立ちます。意味のあるリンクテキストは、ターゲットページの機能をより明確に示します。 支援テクノロジーのユーザーは、1 つのページにすべてのリンクのリストを生成できるので、リンクテキストが独特でしかも情報量が多ければ、コンテキストからリンクテキストをより簡単に理解できます。ただし、目の見えるユーザーでも認知機能に障碍がある場合は、リンク先を正確に説明するのに十分な情報をリンクが提供しないと、当惑する可能性があります。

何よりも、リンクの目的がリンクのテキスト内で明確に説明されていることを確認してください。

  • 悪い例：
    • テキスト：2010 年秋の夜間クラスについて詳しくは、ここをクリックしてください。
    • 理由：リンク先が不明瞭で、あいまいに示されています。
  • 良い例：
    • テキスト：2010 年秋の夜間クラス - 詳細。
    • 理由：テキストとリンク要素の位置をわずかに調整することにより、リンクテキストを改善できます。

リンクは複数ページにわたって一貫した表現にする必要があります。ナビゲーションバーの場合は特にそうです。例えば、特定のページへのリンクの名前を、あるページで「パブリケーション」とする場合は、一貫性を保つために、他のページでもそのテキストを使用します。

本ドキュメントの執筆時点では、ページに表示される類似リンクがリンク先に関する一意の情報を提供するようにタイトル属性を使用するには、問題がいくつかあります（例えば、「続きを読む」は多くの場合、様々なリンク先を指します）。

  • タイトル属性内に含まれるテキストは、マウスユーザーに対してツールチップのポップアップとしてのみ表示され、キーボードを使用した一貫したアクセスやモバイルユーザーによるアクセスはできません。
  • スクリーンリーダーはタイトル属性を読み上げることができますが、この機能はデフォルトでは有効になっていない場合があります。したがって、ユーザーは、タイトル属性が存在することに気付かない場合があります。
  • タイトルテキストの外観を変更するのは難しいので、読みにくい人や読みにくい人もいます。

そのため、title 属性を使用してリンクに追加のコンテキストを提供できますが、その制限事項に注意して、適切なリンクテキストの代わりに使用しないでください。

リンクが画像で構成されている場合は、画像の代替テキストでリンク先を説明してください。例えば、本棚の画像をある人物のパブリケーションへのリンクとして設定している場合は、代替テキストを John Smith のパブリケーション​とします。本棚​とはしないでください。

または、リンクアンカーに、画像要素に加えてリンクの目的を説明するテキストが含まれている場合（したがって、テキストが画像と一緒に表示される場合）、画像に空の alt 属性を使用します。

<a href="publications.html">
<img src = "bookshelf.jpg" alt = "" />
John Smith's publications
</a>
メモ

上記のスニペットは図です。 画像 コンポーネント。

追加のコンテキストを必要とせずにリンクの目的を識別するリンクテキストを指定することが望ましいものの、これが常に可能とは限らないことがわかっています。 コンテキストのないリンクは、次の場合に使用できます。HTML の例は、達成基準 2.4.4 の達成方法を参照してください。

  • リンクテキストは、密接に関連するリンクのリストの一部であり、リンクを含むリスト項目で十分なコンテキストが提供される場合。
  • リンクの目的は、 前 （後ろではなく）段落テキスト。
  • リンクはデータテーブル内に含まれているので、関連する見出しから目的を明確に識別できます。
  • リンクのリストは一連の見出し内に含まれ、見出し自体が適切なコンテキストを提供します。
  • リンクのリストはネストされたリンク内に含まれ、ネストされたリンクの上にある親リスト項目が適切なコンテキストを提供します。

ページ上に複数のリンクが存在する場合（各リンクが複雑で必要な詳細を示す）、完全に同じコンテンツを表示し、リンクテキストがそれほど詳細でない Web ページの代替バージョンを提供することが適切な場合があります。

または、最小限のテキストがリンク自体内に提供されるように、スクリプトを使用します。 ページの先頭に配置する適切なコントロールをアクティブ化すると、リンクテキストが次のようになります。 拡張 を参照してください。 同様の方法として、CSS を 非表示 目の見えるユーザーからの完全なリンク。ただし、スクリーンリーダーユーザーには引き続き完全に出力されます。 これはこのドキュメントの範囲外ですが、これを実現する方法の詳細については、 詳細情報 — リンクの目的（コンテキスト内）(2.4.4) 」セクションに入力します。

複数の手段（2.4.5）

  • 達成基準 2.4.5
  • レベル AA
  • 複数の手段：一連の web ページ内で web ページを見つける方法が複数ある。ただし、web ページがプロセスの結果や 1 ステップである場合を除く。

目的 - 複数の手段（2.4.5）

この達成基準の目的は、ユーザーがニーズに最も合った方法でコンテンツを見つけられるようにすることです。ユーザーは、複数の手段のなかから、より使いやすい、または分かりやすい手段を見つけられます。

小規模サイトでも、何らかの形で方向付けの手段を提供する必要があります。3 ～ 4 ページのサイトで、すべてのページがホームページからリンクされている場合、ホームページ上のリンクがサイトマップとしても機能するため、ホームページと各ページ間で相互にリンクを提供するだけで十分です。

対応方法 - 複数の手段（2.4.5）

達成基準 2.4.5 の達成方法のガイドラインに従います。

詳細情報 - 複数の手段（2.4.5）

見出しおよびラベル（2.4.6）

  • 達成基準 2.4.6
  • レベル AA
  • 見出しおよびラベル：見出しとラベルがトピックや目的を表している。

目的 - 見出しおよびラベル（2.4.6）

この達成基準の目的は、ユーザーが web ページに含まれる情報と、その情報の編成方法を理解できるようにすることです。見出しが明確で説明的な場合、ユーザーは探している情報が見つけやすくなり、コンテンツの異なる部分との関係を理解しやくなります。説明的なラベルは、コンテンツ内の特定のコンポーネントの識別に役立ちます。

達成方法 - 見出しおよびラベル（2.4.6）

達成基準 2.4.6 の達成方法のガイドラインに従います。

詳細 - 見出しおよびラベル（2.4.6）

フォーカスの可視化（2.4.7）

  • 達成基準 2.4.7
  • レベル AA
  • フォーカスの可視化：キーボード操作可能なユーザインターフェイスは、キーボードフォーカスインジケータを表示する操作モードがある。

目的 - フォーカスの可視化（2.4.7）

この達成基準の目的は、キーボードのフォーカスがある要素を知るのに役立ちます。

複数の要素の中で、キーボードフォーカスがある要素を知ることが可能である必要があります。画面に操作可能なキーボードコントロールが 1 つしかない場合、視覚的なデザインは操作可能なキーボードアイテムを 1 つだけ表示するので、達成基準は満たされます。

達成基準で「操作モード」としているのは、フォーカスインジケーターが常に表示されるとは限らないプラットフォームを考慮するためです。通常、操作のモードは 1 つだけなので、この達成基準が適用されます。

達成方法 - フォーカスの可視化（2.4.7）

達成基準 2.4.7 の達成方法のガイドラインに従います。

詳細情報 - フォーカスの可視化（2.4.7）

原則 3：理解可能

原則 3:理解可能 — 情報とユーザーインターフェイスの操作は理解可能である必要があります。

テキストコンテンツを読みやすく理解可能にする (3.1)

ガイドライン 3.1 読み取り可能：テキストコンテンツを読みやすく理解可能にします。

ページの言語 (3.1.1)

  • 達成基準 3.1.1
  • レベル A
  • ページの言語：各 web ページのデフォルトの自然言語がどの言語であるか、プログラムによる特定ができる。

目的 — ページの言語 (3.1.1)

この達成基準の目的は、テキストやその他の言語コンテンツが正しくレンダリングされるようにすることです。 スクリーンリーダーを使用する場合、これにより、コンテンツが正しく発音され、一方、視覚的なブラウザーでは特定の文字セットが正しく表示される可能性が高くなります。

達成方法 — ページの言語 (3.1.1)

この達成基準を満たすために、ページ上部の lang 要素内で <html> 属性を使用して、web ページのデフォルト言語を識別できます。次に例を示します。

  • 英語で書かれているページの場合、<html> 要素は次のようになります。
    <html lang = "en">

  • 一方、スペイン語でレンダリングされるページの場合は、次の標準規格を採用します。
    <html lang = "es">

AEM では、ページのデフォルト言語はページ作成時に設定されますが、ページプロパティの編集時に変更することもできます。

メモ

AEMは、ルート言語のバリエーションに応じてさらに微調整を行います。例えば、アメリカ英語 — en-us、イギリス英語 — en-gb、カナダ英語 — en-ca などです。 この詳細レベルは支援テクノロジーにとっては不必要な場合が多いですが、ページコンテンツの地域的なバリエーションに使用することができます。

詳細情報 - ページの言語（3.1.1）

一部分の言語（3.1.2）

  • 達成基準 3.1.2
  • レベル AA
  • パーツの言語：コンテンツ内の各節またはフレーズの人間言語をプログラムで決定できます。 例外は、固有名、技術用語、不定期な言語の単語、および直前を取り囲むテキストの言葉の一部となっている単語やフレーズです。

目的 — 一部分の言語 (3.1.2)

この達成基準の目的は、ページの言語の達成基準と類似していますが、単一のページに複数言語のコンテンツ（引用や一般的でない外来語）が含まれる web ページに適用される点が異なります。

この達成基準を適用するページでは、次のことが可能です。

  • アクセント付き文字を挿入する点字切り替えソフトウェア。
  • スクリーンリーダーで、特殊文字を含む単語やページレベルで識別されたデフォルト言語でない単語を発音。
  • コンテンツを言語間で正しく翻訳するためのGoogle Translate などの翻訳ツール。

達成方法 — 一部分の言語 (3.1.2)

この lang 属性を使用して、コンテンツの言語の変更を識別できます。 例えば、ドイツ語（ISO 639-1 コード「de」）の引用は、次のように表示できます。

<blockquote cite = "John F. Kennedy" lang = "de">
     <p>Ich bin ein Berliner</p>
 </blockquote>
メモ

Blockquote は、標準のインスタンスではサポートされていません。 この機能をサポートするカスタムコンポーネントを開発できます。

同様に、span 要素を次のように使用した場合は、一般的でない外来語やフレーズをブラウザーで正しくレンダリングできます。

<p>The only French phrase I know is <span lang = "fr">je ne sais quoi</code>.</p>
メモ

様々な言語の名前や都市名を含める場合は、この達成基準に従う必要はありません。また、デフォルト言語で一般的になった外来語やフレーズを使用する場合 ( 例： schadenfreude 英語で。

span 要素を適切な言語で追加するには、RTE のソース編集モードで、上記の内容になるように HTML マークアップを手動で編集します。または、システム管理者が lang 属性を RTE に含めることもできます（追加の HTML 要素および属性のサポートの追加を参照）。

詳細情報 - 一部分の言語（3.1.2）

予測可能（3.2）

ガイドライン 3.2 予測可能：web ページを予測可能な方法で表示および操作できるようにします。

これは、web ページの外観と動作の一貫性を確保することを目的としています。

フォーカス時（3.2.1）

  • 達成基準 3.2.1
  • レベル A
  • フォーカス時：どのユーザインターフェイスコンポーネントもフォーカスを受け取ったときに、コンテキストの変化を引き起こさない。

目的 - フォーカス時（3.2.1）

この達成基準の目的は、訪問者がドキュメント内を移動する際に、機能が予測可能であることを保証することです。フォーカスを受け取ったときにイベントをトリガーできるコンポーネントは、コンテキストを変更してはなりません。コンポーネントがフォーカスを受け取った場合のコンテキストの変更例を次に示しますが、これらに限定されません。

  • コンポーネントがフォーカスを受けると自動的に送信されるフォーム
  • コンポーネントがフォーカスを受けると起動する新しいウィンドウ
  • コンポーネントがフォーカスを受け取るとフォーカスが他のコンポーネントに変更される

フォーカスは、キーボード（例えば、タブキーからコントロールに移動）またはマウス（例えば、テキストフィールドをクリック）を使用してコントロールに移動できます。 コントロールの上にマウスを移動しても、スクリプティングによってこの動作が実装されていない限り、フォーカスは移動しません。一部の種類のコントロールでは、コントロールをクリックすると、コントロール（ボタンなど）もアクティブになり、コンテキストの変更が開始される場合があります。

達成方法 - フォーカス時（3.2.1）

達成基準 3.2.1 の達成方法のガイドラインに従います。

詳細情報 - フォーカス時（3.2.1）

入力時（3.2.2）

  • 達成基準 3.2.2
  • レベル A
  • 入力時：ユーザインターフェイスコンポーネントの設定を変更しても、コンポーネントを使用する前にユーザーに動作について通知されていない限り、コンテキストは自動的に変更されない。

目的 - 入力時（3.2.2）

この達成基準の目的は、データの入力やフォームコントロールの選択を確実に予測可能な結果にすることです。ユーザインターフェイスコンポーネントの設定を変更すると、コントロール内の一部の側面が変更され、ユーザーが操作しなくなったときに維持されます。 したがって、チェックボックスをオンにしたり、テキストフィールドにテキストを入力したり、リストコントロールで選択したオプションを変更したりすると、設定は変わりますが、リンクやボタンはアクティブになりません。コンテキストの変更は、変更を容易に認識できないユーザーや、変更によって注意力が散漫になりやすいユーザーを混乱させる可能性があります。コンテキストの変更は、ユーザーのアクションに応じてそのような変更がおこなわれることが明らかな場合にのみ適切です。

達成方法 - 入力時（3.2.2）

達成基準 3.2.2 の達成方法のガイドラインに従います。

詳細情報 - 入力時（3.2.2）

一貫したナビゲーション（3.2.3）

  • 達成基準 3.2.3
  • レベル AA
  • 一貫したナビゲーション：一連の web ページ内の複数の web ページで繰り返されるナビゲーションのメカニズムは、ユーザーが変更しない限り、繰り返されるたびに同じ相対順で発生する。

目的 - 一貫したナビゲーション（3.2.3）

この達成基準の目的は、一連の Web ページ内で繰り返されるコンテンツを操作し、特定の情報や機能を複数回見つけ出す必要があるユーザーに対して、一貫した表示とレイアウトの使用を促すことです。 視覚障碍を持つ人が画面の表示比率を使用して一度に画面の一部のみを表示する場合は、繰り返されるコンテンツをすばやく見つけ出すために、よく視覚的なキューやページの境界を使用します。繰り返されるコンテンツを同じ順序で表示することは、デザイン内の空間記憶や視覚的キューを使用して繰り返されるコンテンツを見つけ出す視覚的ユーザーにとっても重要です。

この節で使用される「同じ順序」というフレーズは、サブナビゲーションメニューを使用できないとか、またはセカンダリナビゲーションやページ構造のブロックを使用できないという意味ではありません。この達成基準は、Web ページ上で繰り返し使用されるコンテンツを操作するユーザーを支援し、探しているコンテンツの場所を予測できるようにすることを目的としています。 そして、彼らが再びそれに遭遇した時により迅速に見つける。

ユーザーは、アダプティブユーザーエージェントを使用するか、環境設定を設定して、ユーザーにとって最も役立つ方法で情報が表示されるように、順序を変更することもできます。

達成方法 - 一貫したナビゲーション（3.2.3）

達成基準 3.2.3 の達成方法のガイドラインに従います。

詳細情報 - 一貫したナビゲーション（3.2.3）

一貫した識別（3.2.4）

  • 達成基準 3.2.4
  • レベル A
  • 一貫した識別：一連の web ページ内で同じ機能を持つコンポーネントは一貫して識別される。

目的 - 一貫した識別（3.2.4）

この達成基準の目的は、一連の web ページ内で繰り返し表示される機能コンポーネントを一貫して識別することです。Web サイトの操作時にスクリーンリーダーを使用するユーザーが取る戦略は、異なる web ページに表示される機能になじみがあるかどうかに大きく依存しています。異なる Web ページ上で、同じ関数のラベルが異なる（または、より一般的には、アクセス可能な名前が異なる）場合、そのサイトは非常に使いにくくなります。 また、認知機能に障碍を持つ人にとっては、混乱を招き、認知負荷が高まる可能性があります。したがって、一貫したラベル付けが役立ちます。

この一貫性は、代替テキストにも及びます。アイコンやその他のテキスト以外の項目が同じ機能を持つ場合は、代替テキストも一貫性を保つ必要があります。

web ページ上に 2 つのコンポーネントがあり、両方のコンポーネントが、一連の web ページ内の別のページ上にあるコンポーネントと同じ機能を持つ場合は、3 つすべてのコンポーネントの一貫性が維持される必要があります。したがって、同じページ上の 2 つは一貫性を持つことになります。

1 つの web ページ内で一貫性を保つことは望ましく、ベストプラクティスでもありますが、3.2.4 では、複数ページにわたって何かが繰り返される、一連の web ページ内の一貫性のみに対応します。

達成方法 - 一貫した識別（3.2.4）

達成基準 3.2.4 の達成方法のガイドラインに従います。

詳細情報 - 一貫性のある識別（3.2.4）

入力支援（3.3）

ガイドライン 3.3 入力支援：利用者の間違いを防ぎ、修正を支援すること。

エラーの特定（3.3.1）

  • 達成基準 3.3.1
  • レベル A
  • エラーの特定：入力エラーが自動的に検出されると、エラーのある項目が識別され、そのエラーがユーザーにテキストで説明される。

目的 - エラーの特定（3.3.1）

この達成基準の目的は、エラーが発生したことをユーザーが確実に認識し、何が間違っているかを判断できるようにすることです。エラーメッセージは、できる限り具体的に記述する必要があります。フォームの送信に失敗した場合、フォームを再表示し、エラーのあるフィールドを示すのは、一部のユーザーにとって、エラーの発生を認識するのに十分ではありません。 例えば、スクリーンリーダーを使用するユーザーは、インジケーターの 1 つに遭遇するまでエラーが発生したことを知りません。 エラーインジケーターに遭遇する前に、ページが単に機能していないと考えて、フォームを完全に破棄する可能性があります。WCAG の定義によると、入力エラーは、ユーザーから提供される受け入れられない情報です。これには以下が含まれます。

Web ページで必要とされるが、ユーザーによって省略された情報、またはユーザーが提供するが、必要なデータ形式または許可されている値に該当しない情報。
次に例を示します。

  • 州、都道府県、地域のフィールドに適切な省略形を入力できない。
  • ユーザーが有効ではない州の省略形を入力する
  • ユーザーが存在しない郵便番号を入力する
  • ユーザーが 2 年後の生年月日を入力する
  • ユーザーが、数字しか受け入れない電話番号フィールドに英字や丸括弧を入力する
  • ユーザーが前回の入札または最小入札増分を下回る入札を入力する

達成方法 - エラーの特定（3.3.1）

達成基準 3.3.1 の達成方法のガイドラインに従います。

詳細情報 - エラーの特定（3.3.1）

ラベルまたは説明（3.3.2）

  • 達成基準 3.3.2
  • レベル A
  • ラベルまたは説明：コンテンツにユーザー入力が必要な場合は、ラベルまたは指示が提供されます。

目的 — ラベルまたは説明 (3.3.2)

ユーザーがフォームを完了するのに役立つ手順を提供することは、インターフェイスの操作性の基本的な部分です。 これは、視覚障碍または認知障碍のあるユーザーで、フォームのレイアウトや、特定のフォームフィールドに提供されるデータの種類を理解するのに困難が生じる場合に役立ちます。

フォーム

AEM WKND デモプロジェクトでは、テキストフィールド​などのフォームコンポーネントをページに追加すると、デフォルトのラベルが追加されます。このデフォルトのタイトルは、コンポーネントタイプによって異なります。 独自のタイトルを タイトルとテキスト 」タブをクリックします。 ラベルを使用すると、各フォームコンポーネントに関連付けられているデータを理解しやすくなります。

この タイトル フィールドは、支援テクノロジーで使用できるラベルを提供するので、フィールド要素に使用する必要があります。 フィールドの横のテキストにラベルを書くだけでは不十分です。

一部のフォームコンポーネントでは、 タイトルを非表示 チェックボックス。この方法で非表示になったラベルは、支援テクノロジーでは引き続き使用できますが、画面には表示されません。 これは、状況によっては便利な方法ですが、可能な限り視覚的なラベルを含めることをお勧めします。これは、一部のユーザーが画面の小さなセクション（一度に 1 つのフィールド）を見て、フィールドを正しく識別するためにラベルが必要になる場合があるからです。

画像ボタン

画像ボタンが使用される場所 ( 例： 画像ボタン （WKND プロジェクトのコンポーネント）、 タイトル フィールド タイトルとテキスト 編集ダイアログの「 」タブには、ラベルではなく、画像の代替テキストが実際に表示されます。 以下の例では、Submit というテキストを持つ画像に、Submit という代替テキストが、編集ダイアログの「タイトル」フィールドを使用して追加されています。

フォームフィールドのグループ

WKND プロジェクトで、関連するコントロールのグループ（例： ）が存在します。 ラジオグループ​の場合は、グループや個々のコントロールにタイトルが必要になる場合があります。 AEM でラジオボタンのセットを追加する場合、「タイトル」フィールドにはこのグループタイトルが表示されますが、個々のタイトルはラジオボタン（項目）の作成時に指定されます。

ただし、グループタイトルとラジオボタン自体との間には、プログラム的な関連付けはありません。テンプレートエディターでは、必要なタイトルでタイトルを囲む必要があります fieldset および legend タグを使用してこの関連付けを作成します。この処理は、ページのソースコードを編集することによってのみ可能です。 また、システム管理者がこれらの要素のサポートを追加して、フィールドのプロパティ​ダイアログに表示させることもできます（追加の HTML 要素および属性のサポートの追加を参照）。

フォームに関するその他の考慮事項

データを特定の形式で入力する必要がある場合は、ラベルテキストでそのことを明確に示します。例えば、日付を DD-MM-YYYY という形式で入力する場合は、ラベルの一部としてこのことを具体的に示します。つまり、スクリーンリーダーユーザーがフィールドに遭遇したとき、形式に関する追加情報も含めて、ラベルが自動的に読み上げられるということです。

入力が必須のフォームフィールドがある場合は、「必須」という単語をラベルの一部として使用して、このことを明確に示します。AEM では、必須のフィールドにはアスタリスクが追加されますが、「required」（必須）という単語をラベル自体に含めることが理想的です（編集ダイアログの「タイトル」フィールドを使用）。

ラベルの配置も、適切なフィールドを見つけるうえで役立つので重要です。このことは、複雑なフォームの場合に特に重要です。次の規則に従います。

  • チェックボックスまたはラジオボタン：ラベルをフィールドのすぐ右に配置します。
  • その他すべてのフォームコンポーネント（テキストボックス、コンボボックスなど）：
    ラベルをフィールドのすぐ上またはすぐ左に配置します。

機能が限られているシンプルなフォームでは、 Submit ボタンは、隣のフィールドのラベルとして機能できます ( 例： Search) をクリックします。 これは、ラベルテキストのスペースを見つけるのが難しい場合に便利です。

詳細情報 — ラベルまたは説明 (3.3.2)

エラー修正の提案（3.3.3）

  • 達成基準 3.3.3
  • レベル AA
  • キーボード：入力エラーが自動的に検出され、修正候補がわかる場合は、コンテンツのセキュリティや目的を危険にさらさない限り、修正候補がユーザーに提供される。

目的 - エラー修正の提案（3.3.3）

この達成基準の目的は、入力エラーの修正に必要な適切な提案がユーザーに確実に届くようにすることです。WCAG の入力エラーの定義は、「ユーザーが提供する情報で、受け入れられないもの」というものです。受け入れられない情報の例としては、必要であるがユーザーによって省略された情報や、ユーザーが提供するが、必要なデータ形式または許容される値に該当しない情報などがあります。

達成基準 3.3.1 はエラーの通知を提供します。しかし、認知機能に障碍を持つユーザーは、エラーの修正方法を理解するのが難しい場合があります。視覚に障碍を持つユーザーは、エラーの修正方法を正確に理解できない場合があります。フォームの送信に失敗した場合、エラーの発生を認識しているにもかかわらず、エラーの修正方法が不明なことから、ユーザーはフォームを放棄する可能性があります。

コンテンツ作成者によるエラーの説明の提供や、ユーザーエージェントによる、テクノロジーに特化した、プログラム的に決定された情報に基づく、エラーの説明の提供が可能です。

達成方法 - エラー修正の提案（3.3.3）

達成基準 3.3.3 の達成方法のガイドラインに従います。

詳細情報 - エラー修正の提案（3.3.3）

  • 達成基準 3.3.4

  • レベル AA

  • エラー回避（法務、金融、データ）：ユーザーに関する法的コミットメントや金融トランザクションの発生、データストレージシステム内にある、ユーザーが自分で制御可能なデータ変更や削除、またはユーザーテストの応答を送信する web ページでは、次のうち少なくとも 1 つを満たしている。

    • 取り消し
      送信を取り消すことができる
    • チェック
      ユーザーが入力したデータに入力エラーがないかどうかがチェックされ、ユーザーに修正の機会が与えられる
    • 確認
      送信の最終処理を行う前に、情報の見直し、確認および修正を行うメカニズムを利用できる

この達成基準の目的は、障碍を持つユーザーが、元に戻せない操作を実行する際に、誤りが原因で重大な結果が生じるのを回避できるよう支援することです。例えば、返金不能な航空券を購入したり、証券会社の口座で株式購入注文を送信したりすると、深刻な結果をもたらす金融取引となります。航空便の日付を間違えた場合、交換できない間違った日のチケットが発生する可能性があります。 購入する株式の数を間違えた場合、意図した数より多くの株式を購入する可能性があります。 どちらのタイプの高価なミスも、すぐに実行され、後で変更できないトランザクションを伴います。 同様に、旅行サービスの Web サイトの旅行プロファイル全体など、後でアクセスする必要があるデータベースに保存されたデータを誤って変更または削除した場合は、回復不能なエラーとなる場合があります。 「ユーザーが自分で制御可能」なデータの変更または削除を参照する場合、この達成基準の意図は、ファイルやレコードの削除など、大量のデータの損失を防ぐことです。保存コマンド、またはドキュメント、レコード、その他のデータの単純な作成や編集を実行するたびに、確認を要求するものではありません。

障碍を持つユーザーは、間違える可能性が高くなる場合があります。読字障碍を持つユーザーは数字や文字の位置を間違えることがあり、運動障碍を持つ利用者は誤ってキーを押してしまう可能性があります。アクションを取り消す機能を提供すると、ユーザーは重大な結果を招く可能性のある誤りを修正できます。また、入力内容を確認して修正できるようにすることで、重大な結果につながる行動を取ってしてしまう前に、ユーザーがミスに気づくことができるようになります。

ユーザーが自分で制御可能なデータとは、ユーザーが意図した行動によって変更および／または削除できる、ユーザーが閲覧可能なデータのことです。ユーザーがこれらのデータを制御するケースの例としては、ユーザーアカウントの電話番号と住所の更新や、Web サイトから過去の請求書レコードの削除などがあります。インターネットログや検索エンジンの監視データなど、ユーザーが直接表示又は情報交換できないデータは指しません。

達成基準 3.3.4 の達成方法のガイドラインに従います。

原則 4：堅牢

原則 4:堅牢 — コンテンツは、支援テクノロジーを含む様々なユーザーエージェントが確実に解釈できるように十分に堅牢でなければなりません。

互換性（4.1）

ガイドライン 4.1 互換性：支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。

支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。

構文解析（4.1.1）

  • 達成基準 4.1.1
  • レベル A
  • 構文解析：マークアップ言語を使用して実装したコンテンツでは、要素に完全な開始タグと終了タグが付けられ、要素は仕様に従ってネストされ、重複属性は含まれず、ID は一意である。ただし、指定によって機能が許可される場合を除く。

目的 - 構文解析（4.1.1）

この達成基準の目的は、支援テクノロジーを含むユーザーエージェントがコンテンツを正確に解釈および解析できるようにすることです。コンテンツをデータ構造に解析できない場合、異なるユーザーエージェントがそのコンテンツを異なる方法で表示したり、解析できなかったりする可能性があります。 一部のユーザーエージェントは、コード化が不完全なコンテンツをレンダリングする際に、「修復テクニック」を使用します。

修復手法はユーザーエージェントによって異なるので、作成者は、コンテンツが正確に解析されてデータ構造になったり、支援テクノロジーを含む専門的なユーザーエージェントで正しくレンダリングされたとは想定できません。 マークアップ言語では、要素と属性の構文のエラーと、正しくネストされた開始および終了タグの提供に失敗すると、エラーが発生し、ユーザーエージェントがコンテンツを確実に解析できなくなります。したがって、達成基準では、正式な文法規則の規則のみを使用して内容を解析できる必要があります。

達成方法 - 構文解析（4.1.1）

達成基準 4.1.1 の達成方法のガイドラインに従います。

詳細 - 構文解析（4.1.1）

名前、役割、値（4.1.2）

  • 達成基準 4.1.2
  • レベル A
  • 名前、役割、値：すべてのユーザーインターフェイスコンポーネント（以下を含むが、これらに限定されない）の場合：フォームの要素、リンク、およびスクリプトによって生成されたコンポーネント )、名前、役割は、プログラムによって決定できます。ユーザーが設定できる状態、プロパティ、値は、プログラムによって設定できます。また、これらの項目に対する変更の通知は、支援テクノロジーを含むユーザーエージェントが利用できます。

目的 - 名前、役割、値（4.1.2）

この達成基準の目的は、支援テクノロジー（AT）がコンテンツ内のユーザーインターフェイスコントロールのステータスに関する情報を収集、アクティブ化（設定）し、最新の状態に保つことです。

アクセシブルなテクノロジーの標準的なコントロールを使用する場合、このプロセスは簡単です。仕様に従ってユーザインタフェース要素を使用する場合、この規定の条件が満たされます。 （以下の達成基準 4.1.2 の例を参照）。

ただし、カスタムコントロールが作成された場合、またはインターフェイス要素が（コードまたはスクリプトで）通常とは異なる役割や機能を持つようにプログラムされている場合は、支援テクノロジーに重要な情報を提供し、支援テクノロジーで制御できるように、追加の対策を講じる必要があります。

ユーザインターフェイスコントロールの重要な状態は、フォーカスがあるかどうかです。 コントロールのフォーカス状態はプログラムで判定でき、フォーカスの変更に関する通知はユーザーエージェントや支援テクノロジーに送られます。ユーザインターフェイスの制御状態の他の例として、チェックボックスまたはラジオボタンが選択されている場合があります。 または、折りたたみ可能なツリーまたはリストノードが展開または折りたたまれているかどうか。

達成方法 - 名前、役割、値（4.1.2）

達成基準 4.1.2 の達成方法のガイドラインに従います。

詳細情報 - 名前、役割、値（4.1.2）

このページ