アクセシブルなコンテンツ（WCAG 2.1 適合）の作成 creating-accessible-content-wcag-conformance
ワールドワイドウェブコンソーシアムの作業グループが策定したウェブコンテンツアクセシビリティガイドライン（WCAG）2.1 は、障害があるユーザーでも web コンテンツにアクセスして利用できるようにするための、技術に依存しない一連のガイドラインと達成基準で構成されています。
手順の説明に、コンソーシアムは一連のセクションとサポートドキュメントを提供しています。
さらに、詳細は次を参照してください。
- WCAG 2.1 クイックガイド。
- Accessibility conformance reports for Adobe solutions（アドビソリューションのアクセシビリティ準拠レポート）
- アクセシブルなコンテンツを生成するためのリッチテキストエディターの設定
ガイドラインは 3 つの適合レベル（レベル A（最低）、レベル AA、レベル AAA（最高））に分けられます。各レベルの簡単な定義を次に示します。
- レベル A： サイトのアクセシビリティ基本的な最低レベルに達しています。このレベルに達するには、レベル A の達成基準をすべて満たしている必要があります。
- レベル AA： 理想的なレベルのアクセシビリティです。ほとんどの状況で、ほとんどのテクノロジーを使用して、ほとんどのユーザーがアクセスできるように、サイトのアクセシビリティの基盤が整備されています。このレベルに達するには、レベル A とレベル AA の達成基準をすべて満たしている必要があります。
- レベル AAA： サイトのアクセシビリティが非常に高いレベルに達しています。このレベルに達するには、レベル A、レベル AA およびレベル AAA の達成基準をすべて満たしている必要があります。
サイトを作成する際は、サイトが準拠する全体的なレベルを決めておく必要があります。
次の節では、WCAG 2.1 ガイドラインのレイヤーおよび適合レベル A と AA の関連する達成基準を示します。
- WCAG 2.1 ガイドライン用の省略名。
- WCAG の Web サイトとの相互参照を目的として WCAG 2.1 のガイドラインで使用されている番号。
原則 1：知覚可能 principle-perceivable
原則 1：知覚可能 - 情報およびユーザーインターフェイスコンポーネントは、ユーザーが知覚できる方法でユーザーに提示可能でなければならない。
代替テキスト（1.1） text-alternatives
ガイドライン 1.1 代替テキスト：テキスト以外のコンテンツにはすべて、拡大印刷、点字、音声、シンボル、平易な言葉などの人物が必要とする形式に変換できるように、代替テキストを提供すること。
非テキストコンテンツ (1.1.1) non-text-content
- 達成基準 1.1.1
- レベル A
- テキスト以外のコンテンツ：ユーザーに提示されるすべてのテキスト以外のコンテンツには、同等の目的を果たす代替テキストが提供されます。ただし、次の場合は除きます。
目的 - テキスト以外のコンテンツ（1.1.1） purpose-non-text-content
Web ページの情報は、画像、ビデオ、アニメーション、図表、グラフなど、様々な非テキスト形式で提供される可能性があります。目が見えないユーザーや重度の視覚障害があるユーザーは、非テキストコンテンツを見ることができません。ただし、スクリーンリーダーで読み上げたり、点字ディスプレイ装置を使用して触覚で表現することで、テキストコンテンツにアクセスすることは可能です。そのため、グラフィック形式のコンテンツに対する代替テキストを提供すると、グラフィックコンテンツを見ることができない人であっても、コンテンツが提供する情報と同等のバージョンにアクセスすることができます。
代替テキストを使用すると、検索エンジン技術によって非テキストコンテンツのインデックスを作成できるという利点もあります。
達成方法 - 非テキストコンテンツ（1.1.1） how-to-meet-non-text-content
静的なグラフィックの場合、そのグラフィックと同等の代替テキストを指定することが基本的な要件です。そのためには、「代替テキスト」フィールドを使用します。例えば、コアコンポーネント 画像 を参照してください。
alt 属性をサポートするようにこれらのコンポーネントを設定する必要があります（追加の HTML 要素および属性のサポートの追加を参照）。AEM では、デフォルトで入力される「代替テキスト」フィールドが必要です。画像が単なる装飾用で代替テキストが不要な場合は、「画像は装飾画像」オプションをチェックできます。
適切な代替テキストの作成 creating-good-text-alternatives
テキスト以外のコンテンツには様々な形式があるので、代替テキストの値は、Web ページにおけるグラフィックの役割に応じて異なります。従う必要のある一般的な手法を次に示します。
-
代替テキストは、簡潔にしつつ、非テキストコンテンツが提供する基本情報を明確に示す必要があります。
-
過度に長い説明（100 文字を超える）は避ける必要があります。代替テキストに詳細が必要な場合は、次のようにします。
- 代替テキストで短い説明を提示する
- テキストでの長い説明は、同じページの別の場所、または別の web ページに含めます。画像をリンクにするか、画像の横にテキストリンクを配置することで、この個別の説明へのリンクを設定します。
-
代替テキストは、同じページの近くにあるテキスト形式のコンテンツと重複しないようにします。画像の多くは、そのページのテキストですでに説明されている点を図解したものであるため、詳細な代替テキストが存在する場合があります。
-
非テキストコンテンツが別のページやドキュメントへのリンクであり、同じリンクを構成するテキストが他にない場合は、画像の代替テキストでリンク先を示す必要があります。その画像の説明にはしないでください。
-
非テキストコンテンツがボタン要素に含まれ、同じボタンの一部を構成するテキストが他にない場合は、画像の代替テキストでボタンの機能を示す必要があります。その画像の説明にはしないでください。
-
ある画像に空（Null）の代替テキストを指定することは、その画像に代替テキストを設ける必要がない場合にのみ、問題ありません。例えば、純粋に装飾用のグラフィックであったり、同等のテキストがページテキスト内に存在したりする場合です。
代替テキストが必要な、テキスト以外のコンテンツには、次のようなタイプがあります。
-
説明のための写真：人物、物または場所の画像です。ページ内での写真の役割を考えて、画像の内容を説明することが重要です。支援テクノロジーでは要素のタイプ（
graphicやimageなど）を知らせるので、代替テキストの説明でscreenshotやillustrationを使用すると、より明確な説明になることがありますが、それは状況によります。一貫性は重要な要素です。オーサリングチーム全体で決定し、その決定をユーザーエクスペリエンス全体に適用する必要があります。 -
アイコン：特定の情報を伝える小さい絵文字です。ページおよびサイト全体で一貫して使用する必要があります。1 つのページまたはサイト上の同じアイコンにはすべて、短く簡潔な同じ代替テキストを含める必要があります。ただし、そうすることにより、隣接するテキストと無駄に重複してしまう場合を除きます。
-
チャートとグラフ：通常は数値データを表します。そのため、代替テキストを提供する 1 つのオプションとしては、チャートまたはグラフィックで示される主なトレンドの簡単な概要を含めることがあります。必要に応じて、「詳細画像プロパティ」タブの「説明」フィールドを使用して、詳細な説明をテキストで提供します。さらに、ページまたはサイトの別の場所で、ソースデータを表形式で提供することもできます。
-
地図、図、フローチャート：空間データを提供するグラフィックの場合（例：オブジェクト間の関係やプロセスの説明をサポートする場合）は、主要なメッセージをテキスト形式で提供し、このテキスト情報を各関連データポイントの近くに配置します。地図の場合、完全に同等なテキストを提供することは困難な場合が多いものの、特定の場所への行き方を見つける手段として地図が提供されている場合は、地図画像の代替テキストで「X の地図」と簡単に示し、ページ内の別の場所または 画像 コンポーネントの「詳細」タブの「説明」フィールドで、目的の場所への道案内を提供します。
-
CAPTCHA：CAPTCHA とは「コンピューターと人間を区別するための完全自動化公開チューリングテスト」の略です。悪意のあるソフトウェアと人間を区別するために web ページで使用されるセキュリティチェックですが、アクセシビリティの障壁になる場合があります。セキュリティテストに合格するには、ユーザーが、それらの画像に何が表示されているかを説明する必要があります。この画像の代替テキストを提供することはできないので、代替となる非グラフィックソリューションを検討する必要があります。W3C では、次のような提案を提供しています。
- 論理パズル
- 画像の代わりにサウンド出力を使用
- アカウントおよびスパムフィルターの使用制限
-
背景画像：HTML ではなくカスケーディングスタイルシート（CSS）を使用します。つまり、代替テキスト値の指定は不可能ということです。したがって、背景画像では重要なテキスト情報を提供しないでください。提供する場合は、同じ情報をページのテキストでも提供する必要があります。ただし、画像を表示できないときに代替の背景を表示することは重要です。
詳細情報 - 非テキストコンテンツ（1.1.1） more-information-non-text-content
時間依存メディア（1.2） time-based-media
ガイドライン 1.2 時間依存メディア：時間依存メディアには代替コンテンツを提供すること。
ここでは、時間依存 の Web コンテンツについて扱います。これには、ユーザーが再生可能なコンテンツ（映像、音声、アニメーションなど）や、収録済みのコンテンツ、ライブストリームなどが含まれます。
音声のみおよび映像のみ（収録済み）（1.2.1） audio-only-and-video-only-prerecorded
-
達成基準 1.2.1
-
レベル A
-
音声のみおよび映像のみ（収録済み）：事前に収録された音声のみおよび映像のみのメディアには、以下が該当します。ただし、音声または映像がテキストの代替であり、その旨の明確なラベルが付けられている場合を除きます。
- 収録済みの音声のみ：時間依存メディアの代替コンテンツが提供されており、収録済みの音声のみのコンテンツと同等の情報を提示している。
- 収録済みの映像のみ：時間依存メディアの代替コンテンツまたは音声トラックが提供されており、収録済みの映像のみのコンテンツと同等の情報を提示している。
目的 - 音声のみおよび映像のみ（収録済み）（1.2.1） purpose-audio-only-and-video-only-prerecorded
音声と映像のアクセシビリティの問題は、次のようなユーザーに発生する場合があります。
- 視覚障碍のあるユーザー（音声がまったくない場合や、映像またはアニメーションの内容が音声で十分に伝えられていない場合）
- 聴覚障害のあるユーザー（耳が聞こえない、または音声トラックを聞くことができないユーザー）
- 音声を聞くことはできるが、内容を理解できないユーザー（理解できない言語が使用されている場合など）
映像または音声は、Adobe Flash など特定のメディア形式のコンテンツ再生をサポートしていないブラウザーやデバイスを使用しているユーザーも使用できない場合があります。
この情報を別の形式（テキストや、音声なしの映像に音声を付けるなど）で提供すると、元のコンテンツにアクセスできないユーザーがアクセスできるようになります。
達成方法 - 音声のみおよび映像のみ（収録済み）（1.2.1） how-to-meet-audio-only-and-video-only-prerecorded
-
映像なしの収録済み音声コンテンツ（ポッドキャストなど）の場合：
- 音声コンテンツの字幕のリンクをコンテンツの直前または直後に提示します。字幕は、話の内容と、話されていない重要な内容のすべてに相当するテキストを含む HTML ページとし、話者を明記し、状況説明、声の表情、その他の重要な音声の説明を含める必要があります。
-
音声なしのアニメーションまたは収録済み映像コンテンツの場合：
- 映像で提供されている情報に相当するテキスト説明のリンクをコンテンツの直前または直後に提示します。
- または、MP3 など一般的に使用されている音声形式で、相当する音声解説のリンクを提示します。
マルチメディアを AEM web ページに挿入することは、画像の挿入と似ています。ただし、マルチメディアコンテンツには静止画像より多くの機能が含まれているので、マルチメディアの再生方法を制御するための様々な設定やオプションが用意されています。
詳細情報 - 音声のみおよび映像のみ（収録済み）（1.2.1） more-information-audio-only-and-video-only-prerecorded
キャプション（収録済み）（1.2.2） captions-prerecorded
- 達成基準 1.2.2
- レベル A
- キャプション（収録済み）：同期されたメディアに含まれるすべての収録済み音声コンテンツに対してキャプションが提供されます。ただし、そのメディアがテキストの代替メディアであり、その旨の明確なラベルが付けられている場合を除きます。
目的 - キャプション（収録済み）（1.2.2） purpose-captions-prerecorded
聴覚障碍のあるユーザーは、音声コンテンツにアクセスできないか、アクセスが非常に困難になります。キャプションは、音声で話されている内容と話されていない内容に相当するテキストであり、映像再生中に適時画面に表示されます。これにより、音声を聞くことのできないユーザーが内容を理解できます。
達成方法 - キャプション（収録済み）（1.2.2） how-to-meet-captions-prerecorded
キャプションは、次のいずれかの状態に設定できます。
- オープン：映像再生時に常に表示
- クローズド：ユーザーがキャプションのオン、オフを切り替え可能
可能な場合はクローズドキャプションを使用して、ユーザーがキャプションの表示と非表示を選択できるようにします。
クローズドキャプションを使用する場合、適切な形式（SMIL など）の同期キャプションファイルを作成して、ビデオファイルと一緒に提供します（この方法の詳細は本ガイドの範囲外ですが、詳細情報 - キャプション（収録済み）（1.2.2）でチュートリアルへのリンクをいくつかご覧いただけます）。映像でキャプションを利用できることをユーザーに知らせるために、注意書きを表示するか、ビデオプレーヤーのキャプション機能を有効にしてください。
オープンキャプションを使用する必要がある場合は、映像トラック内にテキストを埋め込みます。これを行うには、映像にタイトルをオーバーレイできるビデオ編集アプリケーションを使用します。
詳細情報 - キャプション（収録済み）（1.2.2） more-information-captions-prerecorded
音声解説または代替メディア（収録済み）（1.2.3） audio-description-or-media-alternative-prerecorded
- 達成基準 1.2.3
- レベル A
- 音声解説または代替メディア（収録済み）：同期されたメディアに関しては、時間ベースのメディアまたは事前に録音されたビデオコンテンツの音声解説が提供されます。ただし、メディアがテキストの代替メディアであり、そのように明確にラベル付けされている場合には提供されません。
目的 - 音声解説または代替メディア（収録済み）（1.2.3） purpose-audio-description-or-media-alternative-prerecorded
映像やアニメーションの情報が視覚的にのみ提供されている場合や、内容を視覚的に理解するのに十分な情報が音声で提供されていない場合は、視覚障碍のあるユーザーにアクセシビリティの問題が発生します。
達成基準 - 音声解説または代替メディア（収録済み）（1.2.3） how-to-meet-audio-description-or-media-alternative-prerecorded
この達成基準を満たすために採用できる方法は 2 つあります。次のいずれかを使用できます。
-
ビデオコンテンツに音声解説を追加します。これを行うには、次の 3 つのうちいずれかの方法を使用します。
-
既存のボイスの休止部分で、既存の音声トラックでは提示されていないシーンの変化に関する情報を提供します。
-
元の音声だけでなくシーンの変化に関する音声情報も含む、新しいオプションの音声トラックを追加で提供します。
- ユーザーは既存の音声トラック（音声解説を 含まない）と新しい音声トラック（音声解説を 含む）を切り替えることができます。
- これにより、追加の説明を必要としないユーザーの混乱を避けることができます。
-
音声解説を拡張できるように、2 つ目のバージョンのビデオコンテンツを作成します。これにより、適切な時点で音声と映像を一時的に休止して既存のボイスの合間に詳細な音声解説を提供することに関連する困難な作業を軽減できます。その結果、アクションが再開される前に、より長い音声解説を指定できます。前の例と同様に、追加の説明を必要としないユーザーが混乱しないように、このコンテンツはオプションのオーディオトラックとして追加するのが最適です。
-
-
ビデオまたはアニメーションのオーディオや視覚要素に対応する、適切なテキストの字幕を提供します。字幕には、必要に応じて、話者、状況の説明、イベント、視覚的に提示される情報、音声表現に関する内容を含めてください。字幕は長さによって、ビデオやアニメーションと同じページに配置するか、別のページに配置することができます。別のページに配置する場合は、ビデオやアニメーションのすぐ近くに字幕へのリンクを提示してください。
音声解説付きビデオの作成方法に関する正確な詳細は、本ガイドの範囲外です。映像および音声解説の作成には長時間を要する可能性がありますが、他のアドビ製品が役に立つ場合があります。
詳細情報 - 音声解説または代替メディア（収録済み）（1.2.3） more-information-audio-description-or-media-alternative-prerecorded
キャプション（ライブ）（1.2.4） captions-live
- 達成基準 1.2.4
- レベル AA
- キャプション（ライブ）：同期されたメディアに含まれるすべてのライブ音声コンテンツに対してキャプションが提供されている。
目的 - キャプション（ライブ）(1.2.4) purpose-captions-live
この達成基準は、聴覚障碍のあるユーザーのアクセシビリティに関する問題に対応する点で、キャプション（収録済み）と同じです。ただし、この達成基準では Web キャストなどライブのプレゼンテーションを扱う点が異なります。
達成方法 - キャプション（ライブ）（1.2.4） how-to-meet-captions-live
上記のキャプション（収録済み）のガイダンスに従ってください。ただし、ライブ（リアルタイム）というメディアの性質上、キャプションは起こっていることに応じて、可能な限り短時間に作成する必要があります。そのため、リアルタイムキャプションツールまたは音声テキスト変換ツールの使用を検討する必要があります。
詳細な手順説明はこのドキュメントの範囲外ですが、次のリソースで役に立つ情報が提供されています。
詳細情報 - キャプション（ライブ）（1.2.4） more-information-captions-live
音声解説（収録済み）（1.2.5） audio-description-prerecorded
- 達成基準 1.2.5
- レベル AA
- 音声解説（収録済み）：同期されたメディアに含まれるすべての収録済み映像コンテンツに対して音声解説が提供されている。
目的 - 音声解説（収録済み）（1.2.5） purpose-audio-description-prerecorded
この達成基準は、音声解説または代替メディア（収録済み）と同じです。ただし作成者は、レベル AA に準拠するために、より詳細な音声解説を提供する必要があります。
達成方法 - 音声解説（収録済み）（1.2.5） how-to-meet-audio-description-prerecorded
音声解説または代替メディア（収録済み）のガイダンスに従ってください。
詳細情報 - 音声解説（収録済み）（1.2.5） more-information-audio-description-prerecorded
適応可能 (1.3) adaptable
ガイドライン 1.3 適応可能：情報や構造を維持しながら、様々な方法（よりシンプルなレイアウトなど）で提示できるコンテンツを作成します。
このガイドラインは、次のようなユーザーのサポートに必要な要件に対応しています。
-
そのコンテンツのデフォルト表示（複数列のレイアウトや、色や画像を多用したページなど）では、作成者が提示した情報にアクセスできない場合があるユーザー
-
音声のみ、または大きいテキストや高いコントラストなど、代替の視覚表示を使用する可能性のあるユーザー
情報および関係性（1.3.1） info-and-relationships
- 達成基準 1.3.1
- レベル A
- 情報および関係性：プレゼンテーションを通して伝えられる情報、構造および関係性を、プログラムによって特定できる、またはテキスト形式で利用できる。
目的 - 情報および関係性（1.3.1） purpose-info-and-relationships
障害のあるユーザーが使用する多くの支援テクノロジーでは、コンテンツを効果的に表示したり 理解 したりするために、構造的な情報に依存しています。この構造的な情報は、ページの見出し、表の行や列の見出し、リストの種類などの形を取ることがあります。例えば、スクリーンリーダーを使用すれば、ページ内を見出しから見出しへと移動できます。ただし、ページコンテンツの構造が基になる HTML ではなく、視覚的なスタイルでのみ設定されているように見える場合、支援テクノロジーでは構造情報を利用できず、ブラウジングの操作性の向上を十分サポートできなくなります。
この達成基準の目的は、ブラウザーおよび支援テクノロジーが構造情報にアクセスし情報を利用できるように、構造情報が HTML やその他のコーディング手法を使用してプログラムで確実に提供されるようにすることです。
達成方法 - 情報および関係性（1.3.1） how-to-meet-info-and-relationships
AEM では、適切な HTML 要素を使用することにより、意味のある web コンテンツを簡単に構築できます。RTE（テキストコンポーネント）でページコンテンツを開き、段落書式 メニュー（段落記号）を使用して、適切な構造要素（段落、見出しなど）を指定します。
次の要素を適宜使用して、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 属性を使用することがあります。
note note NOTE デフォルトでは、これらの要素や属性を直接使用することはできませんが、システム管理者が、「テーブルのプロパティ」ダイアログボックスでこれらの値のサポートを追加することは可能です（追加の HTML 要素および属性のサポートの追加を参照してください）。 「テーブルのプロパティ」タブを選択できる テーブル ダイアログを開くには、次のようにします。
- 適切な キャプション を定義します。
- 理想としては、「幅」、「高さ」、「ボーダー」、「セル内の余白」、「セルの間隔」のデフォルト値をすべて削除します。これらのプロパティはグローバルスタイルシートで設定できるからです。
その後、セルのプロパティ を使用して、セルがデータまたはヘッダーのセルなのかを選択します。
- 1 つの
-
強調：
<strong>または<em>要素を使用して強調を指定します。段落内のテキストをハイライト表示するために見出しを使用しないでください。-
強調するテキストをハイライト表示します。
-
「B」アイコン（
<strong>に対応）または「I」アイコン（<em>に対応）を、プロパティ パネルでクリックします。HTML が選択されていることを確認してください。note note NOTE AEM の標準的なインストールに含まれる RTE は、次のように設定されています。 <b>の代わりに<strong>を使用<i>の代わりに<em>を使用
それぞれ実質的には同じですが、好ましいのは、意味的に正しい HTML である <strong>と<em>です。開発チームがプロジェクトインスタンスを作成する際に、<strong>と<em>ではなく<b>と<i>を使用するように RTE を設定できます。
-
-
複雑なデータテーブル：レベルが 2 つ以上あるヘッダーを含む複雑なテーブルがある場合など、場合によっては、基本的なテーブルのプロパティでは必要な構造情報を十分に指定できないことがあります。このような複雑なテーブルでは、header 属性と id 属性を使用して、ヘッダーとその関連セルの間に直接の関係を作成する必要があります。
note note NOTE id 属性は、標準のインストールでは使用できません。有効にするには、RTE で HTML ルールとシリアライザーを設定します。 例えば、以下に示すテーブルでは、支援テクノロジーユーザーのためのプログラムによる関連付けを作成するために、header と id が照合されています。
code language-xml <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 で実現するには、ソース編集モードを使用してマークアップを直接追加します。
note note NOTE この機能は、標準インストールではすぐには使用できません。RTE、HTML ルールおよびシリアライザーを設定する必要があります。
詳細情報 - 情報および関係性（1.3.1） more-information-info-and-relationships
意味のあるシーケンス（1.3.2） meaningful-sequence
- 達成基準 1.3.2
- レベル A
- 意味のあるシーケンス：コンテンツが提示される順序がその意味に影響を与える場合、正しい読み取り順序をプログラム的に決定することができる。
目的 - 意味のあるシーケンス（1.3.2） purpose-meaningful-sequence
この達成基準の目的は、ユーザーエージェントが意味を理解するために必要な読み取り順序を維持しながら、コンテンツの代替表現を可能にすることです。意味を持つコンテンツの少なくとも 1 つのシーケンスをプログラムで判断できることが重要です。この達成基準を満たさないコンテンツは、支援テクノロジーがコンテンツを誤った順序で読み取った場合や、代替スタイルシートやその他の書式変更が適用された場合、ユーザーを混乱させたり、方向を狂わせたりする可能性があります。
達成方法 - 意味のあるシーケンス（1.3.2） how-to-meet-meaningful-sequence
達成基準 1.3.2 の達成方法のガイドラインに従います。
詳細情報 - 意味のあるシーケンス（1.3.2） more-information-meaningful-sequence
感覚的な特徴（1.3.3） sensory-characteristics
- 達成基準 1.3.3
- レベル A
- 感覚的な特徴：コンテンツを理解および操作するために提供されている指示は、シェイプ、サイズ、視覚的な場所、方向、音声などの、コンポーネントの感覚的な特徴のみに依存していません。
目的 - 感覚的な特徴（1.3.3） purpose-sensory-characteristics
デザイナーは、情報を提示する際に、色、形状、テキストスタイル、コンテンツの絶対位置や相対位置など、視覚的なデザイン特性に注目することがよくあります。このような特性は、情報を伝達する上で強力な設計手法になり得ます（また、視覚障害のないユーザーが認知的なアクセシビリティを必要としている場合に、アクセシビリティ全体を向上させることができます）。ただし、視覚障害のあるユーザーは、位置、色、形状などの視覚的に属性を識別する必要のある情報にはアクセスできない可能性があります。
同様に、異なる音声を区別する必要のある情報（話し手が男性または女性であるコンテンツなど）は、音声コンテンツの代替テキストに反映されていない場合、聴覚障害のあるユーザーにアクセシビリティの問題を引き起こします。
達成方法 - 感覚的な特徴（1.3.3） how-to-meet-sensory-characteristics
ページコンテンツの視覚的特性に依存する情報も、別の形式で表示されるようにしてください。
- 視覚的な位置に依存して情報を提供しないでください。例えば、追加情報にアクセスするためにページの右側にあるメニューをユーザーに示す場合は、右側のメニュー とは言わずに、見出しを使用するなどしてメニューに名前を付けて、テキストではその名前で説明します。
- 情報を伝える唯一の方法として、テキストのスタイル設定（太字や斜体など）に依存しないようにします。
詳細情報 - 感覚的な特徴（1.3.3） more-information-sensory-characteristics
判別可能（1.4） distinguishable
ガイドライン 1.4 判別可能：コンテンツを、利用者にとって見やすく、聞きやすいものにします。これには、前景と背景を区別することも含む。
色の使用（1.4.1） use-of-color
- 達成基準 1.4.1
- レベル A
- 色の使用：色は、情報を伝達したり、アクションを示したり、応答を促したり、視覚要素を区別したりするために使用できる、唯一の視覚的方法ではありません。
目的 - 色の使用（1.4.1） purpose-use-of-color
色は、web ページの美的な魅力を高める効果的な方法であり、情報伝達にも役立ちます。しかし、視力障害や色覚異常などの様々な視覚障害があり、特定の色を区別できないユーザーもいます。つまり、色による区分は信頼性の低い情報提供方法であると言えます。
例えば、赤緑色覚障害があるユーザーは、緑と赤の色合いを区別できません。両方の色を第 3 の色（茶色など）として認識してしまう可能性があり、その場合は、赤、緑、茶色が見分けられません。
また、ユーザーがテキストのみのブラウザーやモノクロ表示のデバイスを使用している場合や、ページの白黒印刷を表示する場合も、色は認識されません。
インターフェイス要素（タブ、トグルボタンなど）の 選択 状態についてはより慎重に考慮する必要があり、色の使用や視覚的な表現のみに頼らない、他の方法で伝える必要があります。このような要素については、特定の感覚に依存しない包括的なユーザーエクスペリエンスを作成する場合、さらにパターン、図形、プログラム情報を使用すると役に立ちます。
達成方法 - 色の使用（1.4.1） how-to-meet-use-of-color
色を使用して情報を伝達する場合は、色を見なくても情報を利用できるようにしてください。
例えば、色によって提供されている情報を、テキストでも明示的に提供します。
情報提供のヒントとして色を使用する場合は、スタイル（太字、斜体など）やフォントの変更などの視覚的なヒントを追加する必要があります。これは、視力が悪い人や、色覚多様性を持つ人物が情報を特定するのに役立ちます。ただし、ページをまったく見ることのできない人には役に立たないので、全面的に依存することはできません。したがって、視覚障碍のあるユーザーにこのような情報を伝えるには、隠しテキストを提供したり、ARIA（アクセシブルリッチインターネットアプリケーション）Web 標準規格などのプログラマティックソリューションを使用したりすると、役に立つ場合があります。
詳細情報 - 色の使用（1.4.1） more-information-use-of-color
音声の制御（1.4.2） audio-control
- 達成基準 1.4.2
- レベル A
- 音声の制御：web ページ上の任意の音声が 3 秒以上自動的に再生される場合は、音声を一時停止または停止するメカニズムか、システム全体の音量レベルとは別に、音声の音量を制御するメカニズムが使用できる。
目的 - 音量の制御（1.4.2） purpose-audio-control
画面読み上げソフトウェアを使用しているユーザーは、同時に他の音声が再生されると、音声出力を聞き取るのが難しい場合があります。この問題は、画面読み上げの音声出力が（現在のほとんどの場合がそうであるように）ソフトウェアベースで行われ、サウンドと同じ音量コントロールを介して制御されている場合に深刻化します。さらに、認知障害や神経多様性のあるユーザーは、音に対する感受性が強い場合があります。このようなユーザーにとっては、オーディオコンテンツの音量レベルを変更できないことが大きな問題になります。
したがって、ユーザーがバックグラウンドサウンドをオフにできることが重要です。
達成方法 - 音声の制御（1.4.2） how-to-meet-audio-control
達成基準 1.4.2 の達成方法のガイドラインに従います。
詳細情報 - 音声の制御（1.4.2） more-information-audio-control
コントラスト（最低限）（1.4.3） contrast-minimum
-
達成基準 1.4.3
-
レベル AA
-
コントラスト（最低限）：テキストと、テキストの画像は、以下の場合を除き、4.5:1 以上のコントラスト比で視覚的に表示されます。
- 大きなテキスト：大きなテキストと大きなテキストの画像のコントラスト比は 3:1 以上です。
- 付随的：テキストまたはテキストの画像が、非アクティブなユーザーインターフェイスコンポーネントの一部である場合、装飾のみを目的としている場合、誰にも表示されない場合、他の重要な視覚的コンテンツを含む画像の一部である場合は、コントラストの要件はありません。
- ロゴタイプ：ロゴまたはブランド名の一部であるテキストには、最低コントラストの要件はありません。
note note NOTE 詳しくは、テキスト以外のコントラストの理解を参照し、コンテンツ作成者はテキスト以外の要素（アイコン、インターフェイス要素など）に関する追加要件を把握するようにしてください。
目的 - コントラスト（最低限）（1.4.3） purpose-contrast-minimum
特定の視覚障碍のあるユーザーは、特定の低コントラストの色のペアを区別できない場合があります。次のいずれかの場合に、このようなユーザーにアクセシビリティの問題が発生することがあります。
- テキストと背景色のコントラストが不十分な場合。
- 情報を区別する上で、テキスト（リンクテキスト、リンクされていないテキストなど）の色分けが重要な役割を果たしている場合。
達成方法 - コントラスト（最低限）（1.4.3） how-to-meet-contrast-minimum
テキストと背景のコントラストが十分であることを確認します。コントラスト比は、対象となるテキストのサイズとスタイルによって異なります。
- テキストのサイズが 18 ポイント（太字の場合は 14 ポイント）未満の場合、テキストまたはテキストの画像と背景の間のコントラスト比は 4.5:1 以上である必要があります。
- テキストのサイズが 18 ポイント（太字の場合は 14 ポイント）以上の場合、コントラスト比は 3:1 以上である必要があります。
- 背景にパターンを使用している場合は、テキスト周辺の背景に陰影を付けて、4.5:1 または 3:1 のコントラスト比を維持する必要があります。
- Px から Em への変換 - Omni
https://websemantics.uk/tools/font-size-conversion-pixel-point-em-rem-percent/で「フォントサイズの変換：pixel-point-em-rem-percent」を参照してください。http://pxtoem.com/で「PMtoEM.com：PX から EM への変換を容易にする」を参照してください。
コントラスト比を確認するには、Paciello Group の Color Contrast Analyser や WebAIM の Color Contrast Checker などのカラーコントラストチェッカーを使用してください。これらのツールを使用すると、色のペアを確認し、コントラストの問題を報告できます。
また、ページの外観を重視しない場合は、テキストの背景色と前景色をを指定しないように選択できます。その場合、テキストや背景の色はユーザーのブラウザーによって決まるので、コントラストの確認は不要です。
推奨されるコントラストレベルを満たすことができない場合は、代わりとなる同等のページ（色のコントラストに関する問題がないページ）へのリンクを提供します。または、ユーザーが自分の要件に合わせてページの配色のコントラストを調整できるようにする必要があります。
詳細情報 - コントラスト（最低限）（1.4.3） more-information-contrast-minimum
テキストのサイズ変更（1.4.4） resize-text
- 達成基準 1.4.4
- レベル A
- テキストのサイズ変更：テキストのキャプションと画像を除き、テキストは 200 パーセントまで支援テクノロジーを必要とせずに、コンテンツや機能を失うことなくサイズ変更できる。
目的 - テキストのサイズ変更（1.4.4） purpose-resize-text
この達成基準の目的は、テキストベースの制御（見えるように表示されたテキスト文字 [対 ASCII などのデータ形式にあるテキスト文字]）を含む、視覚的にレンダリングされたテキストを、拡大鏡などの支援テクノロジーを使用せずに、正常に拡大・縮小できるようにすることです。ユーザーが web ページのすべてのコンテンツを拡大・縮小するメリットを受ける場合もありますが、テキストは最も重要です。
達成方法 - テキストのサイズ変更（1.4.4） how-to-meet-resize-text
達成基準 1.4.4 の達成方法のガイドラインに沿うだけでなく、閲覧者がテキストのサイズを変更できるように、ページデザインやフォントサイズに流動的で柔軟な幅と高さ（レスポンシブ web デザインなど）を使用するよう、コンテンツ作成者に促すことができます。
詳細情報 - テキストのサイズ変更（1.4.4） more-information-resize-text
文字画像（1.4.5） images-of-text
-
達成基準 1.4.5
-
レベル AA
-
文字画像：使用しているテクノロジーで視覚的表現を実現できる場合に、文字画像ではなくテキストを使用して情報を伝達している。ただし、次の場合を除く。
- カスタマイズ可能：テキストの画像を、ユーザーの要件に合わせて視覚的にカスタマイズできる。
- 必須：テキストの特定の表現が、伝達する情報にとって必須である。
目的 - テキストの画像（1.4.5） purpose-images-of-text
テキストの画像は、特定のスタイルのテキストが望ましい場合によく使用されます。例えば、ロゴタイプや、別のソースからテキストが生成された場合（紙のドキュメントをスキャンする場合など）です。 ただし、HTML で表示され、CSS を使用してスタイル設定されたテキストと比較すると、テキストの画像には、視覚障がいや読み取りが困難な人にとって必要なサイズや外観を変更するという柔軟性がありません。
達成方法 - 文字画像（1.4.5） how-to-meet-images-of-text
文字画像を使用する必要がある場合は、CSS を使用して、文字画像を同等の HTML テキストに置き換え、テキストをカスタマイズ可能にします。例については、C30：CSS を使用してテキストをテキストの画像に置換し、変換用のユーザーインターフェイスコントロールを提供するを参照してください。
詳細情報 - 文字画像（1.4.5） more-information-images-of-text
原則 2：操作可能 principle-operable
原則 2：操作可能 - ユーザーインターフェイスコンポーネントおよびナビゲーションは操作可能でなければならない。
キーボード操作可能（2.1） keyboard-accessible
ガイドライン 2.1 キーボード操作可能：すべての機能をキーボードから使用できること。
これは、キーボードを使用してすべての機能のアクセスを確保することを目的としています。
キーボード（2.1.1） keyboard
- 達成基準 2.1.1
- レベル A
- キーボード：コンテンツのすべての機能が、個々のキー操作に特定のタイミングを必要とせずに、キーボードインターフェイスを介して操作できる。ただし、基になる機能は、エンドポイントだけでなく、ユーザーの移動のパスに依存する入力を必要とすることは例外とする。
目的 - キーボード（2.1.1） purpose-keyboard
この達成基準の目的は、可能な限りコンテンツをキーボード（または代替キーボード利用できるような）キーボードインターフェイスで操作ができるようにすることです。コンテンツをキーボードやキーボードの代用装置で操作できるようにすると、視覚障害のある（目と手の協調運動を必要とするマウスのようなデバイスを使用できない）ユーザーや、キーボードの代用装置またはキーボードエミュレーターとして機能する入力デバイスを使用する必要があるユーザーでも操作できます。キーボードエミュレーターには、音声入力ソフトウェア、息操作ソフトウェア、画面キーボード、スキャンソフトウェアなどの、様々な支援テクノロジーやキーボードの代用装置が含まれます。視覚障害があるユーザーはポインターを目で追うのが困難な場合があり、キーボードから制御できれば、ソフトウェアの使用が容易になる（あるいは可能になる）可能性があります。
達成方法 - キーボード（2.1.1） how-to-meet-keyboard
達成基準 2.1.1 の達成方法のガイドラインに従います。
詳細情報 - キーボード（2.1.1） more-information-keyboard
キーボードトラップなし（2.1.2） no-keyboard-trap
- 達成基準 2.1.2
- レベル A
- キーボードトラップなし：キーボードインターフェイスを使用してキーボードフォーカスをページのコンポーネントに移動できる場合、キーボードインターフェイスのみを使用してコンポーネントからフォーカスを移動できる。また修飾キーを伴わない矢印キーやタブキーなどの標準的な方法以上のものが必要な場合、ユーザーにフォーカスを外す方法を通知できる。
目的 - キーボードトラップなし（2.1.2） purpose-no-keyboard-trap
この達成基準の目的は、コンテンツが web ページ上のコンテンツのサブセクション内にキーボードフォーカスを トラップ しないようにすることです。これは、複数の形式がページ内で組み合わされ、プラグインや埋め込みアプリケーションを使用してレンダリングされる場合に発生する一般的な問題です。
web ページの機能によって、フォーカスがコンテンツのサブセクション（モーダルダイアログなど）に制限される場合があります。そのような場合は、コンテンツのサブセクションからユーザーが移動できる方法を用意しておく必要があります（例えば、ESC キーや「閉じる」ボタンでモーダルダイアログを閉じるなど）。
達成方法 - キーボードトラップなし（2.1.2） how-to-meet-no-keyboard-trap
達成基準 2.1.2 の達成方法のガイドラインに従います。
詳細情報 - キーボードトラップなし（2.1.2） more-information-no-keyboard-trap
十分な時間（2.2） enough-time
ガイドライン 2.2 十分な時間：ユーザーに対し、コンテンツを読んで使用するのに十分な時間を提供します。
これは、ユーザーがコンテンツを読んで行動を起こすのに十分な時間を確保することを目的としています。
タイミング調整可能（2.2.1） timing-adjustable
- 達成基準 2.2.1
- レベル A
- キーボード：ユーザーがコンテンツを読み、使用するのに十分な時間を提供すること。
目的 - タイミング調整可能（2.2.1） purpose-timing-adjustable
この達成基準の目的は、可能な限り常に、障碍のあるユーザーが Web コンテンツを利用するのに十分な時間を提供することです。全盲、視覚障碍、手指の障碍、認知機能の制限など、障碍のあるユーザーは、コンテンツを読むのに時間がかかる場合や、オンラインフォームの入力などの機能を実行するのに時間がかかる場合があります。Web 機能が時間に依存する場合は、制限時間より前に必要な操作を行うのが難しい場合があります。それらのユーザーがサービスにアクセスできない場合があります。時間に依存しない機能を設計することで、障害のあるユーザーが上記のような機能を完了できるようになります。時間制限の無効化、制限時間の長さのカスタマイズ、制限時間になる前に時間の延長をリクエストするためのオプションを提供することで、タスクの完了に予想以上の時間を要するユーザーをサポートできます。これらのオプションは、ユーザーにとって最も役に立つ順に表示されます。有効性の高い順に、時間制限を無効にする、時間制限の長さをカスタマイズする、時間制限の長さをカスタマイズする、となります。
達成方法 - タイミング調整可能（2.2.1） how-to-meet-timing-adjustable
達成基準 2.2.1 の達成方法のガイドラインに従います。
詳細情報 - タイミング調整可能（2.2.1） more-information-timing-adjustable
一時停止、停止、非表示（2.2.2） pause-stop-hide
-
達成基準 2.2.2
-
レベル A
-
一時停止、停止、非表示：情報の移動、点滅、スクロールまたは自動更新について、以下が該当する。
-
移動、点滅、スクロール：情報の次のような移動、点滅またはスクロールの場合。
- (a) 自動的に始まる、
- (b) 5 秒より長く持続する、
- © 他のコンテンツと並行して提示される。この場合は、移動、点滅またはスクロールがアクティビティの不可欠な一部でない限り、ユーザーが一時停止、停止または非表示にする仕組みがあります。
-
自動更新：情報の次のような自動更新の場合。
- (a) 自動的に始まる、
- (b) 他のコンテンツと並行して提示される。
この場合は、自動更新がアクティビティの不可欠な一部でない限り、ユーザーが更新を一時停止、停止または非表示にしたり、更新の頻度を制御したりするメカニズムがあります。
-
注意点は次のとおりです。
- コンテンツのちらつきや閃光に関連する要件については、発作の防止：発作を引き起こすようなコンテンツを設計しないこと（2.3）を参照してください。
- この達成基準を満たさないコンテンツがある場合は、ユーザーがページ全体を使用できない場合があるので、web ページ上のすべてのコンテンツ（他の達成基準を満たすために使用されているかどうかにかかわらず）が、この達成基準を満たす必要があります。適合要件の「5. 非干渉」を参照してください。
- ソフトウェアによって定期的に更新されるか、ユーザーエージェントにストリーミングされるコンテンツは、一時停止の開始と再開の間に生成または受け取った情報を保存または表示する必要はありません。これは技術的に不可能な場合があり、多くの場合、そうすると誤解を招く可能性があります。
- すべてのユーザーにプリロードフェーズでインタラクションが発生しない場合や、進捗を表示しないとユーザーの混乱を招いたり、コンテンツがフリーズした、または壊れているとユーザーが思ってしまう場合、プリロードフェーズの一部として発生するアニメーションや同様の状況は、重要と見なすことができます。
目的 - 一時停止、停止、非表示（2.2.2） purpose-pause-stop-hide
ユーザーによっては、動くコンテンツが気が散る、さらには肉体的に苦痛とまで感じられて、ページの他の部分に集中することが難しくなる場合があります。さらに、動くテキストを目で追うのに苦労するユーザーには、そのようなコンテンツは読みにくい場合もあります。
達成方法 - 一時停止、停止、非表示（2.2.2） how-to-meet-pause-stop-hide
移動、閃光、点滅の性質を持つコンテンツを含む web ページを作成する際には、コンテンツの性質に応じて、次のうち 1 つ以上の提案事項を適用できます。
- ユーザーが十分な時間をかけてコンテンツを読めるよう、コンテンツのスクロールを一時停止する手段を提供します。例えば、ニュースティッカー、自動更新テキスト、自動進行する画像カルーセルなどです。
- 点滅するコンテンツが、5 秒後に点滅を停止するようにします。
- ブラウザーで無効にできる、動きや点滅のあるコンテンツを表示するには、適切なテクノロジーを使用します。例えば、Graphics Interchange Format（GIF）ファイルや Animated Portable Network Graphics（APNG）ファイルなどです。
- ページ上の動きや点滅のあるコンテンツをすべてユーザーが無効にできるように、web ページでのフォームコントロールを提供します。
- 上記の方法が不可能な場合は、含まれているすべてのコンテンツに動きや点滅がないページへのリンクを提供します。
詳細情報 - 一時停止、停止、非表示（2.2.2） more-information-pause-stop-hide
発作および身体的反応（2.3） seizures-and-physcial-reactions
ガイドライン 2.3 発作の防止：発作や身体的反応を引き起こすようなコンテンツを設計しないこと。
3 回の閃光、またはしきい値以下（2.3.1） three-flashes-or-below-threshold
- 達成基準 2.3.1
- レベル A
- 3 回の閃光、またはしきい値以下：1 秒間の閃光回数が 3 回を超えるものが web ページに含まれていません。または、閃光が一般閃光しきい値および赤色閃光しきい値を下回る。
目的 - 3 回の閃光、またはしきい値以下（2.3.1） purpose-three-flashes-or-below-threshold
場合によっては、コンテンツが放つ閃光によって光過敏性発作が発生する可能性があります。この達成基準を使用すると、閃光によるコンテンツを気にすることなく、すべてのコンテンツにアクセスして体験することができます。
達成方法 - 3 回の閃光、またはしきい値以下（2.3.1） how-to-meet-three-flashes-or-below-threshold
次の手順を実行して、次の手法が適用されていることを確認します。
- 1 秒間の間に 3 回を超えてコンポーネントが点滅しないようにします。
- 上記の条件を満たすことができない場合は、画面上のピクセル単位の 小さい安全な領域 内に、閃光コンテンツを表示します。この領域は、「G176: 閃光を放つエリアを十分に小さくする」で説明している複雑な数式を使用して計算されるので、この技法を使用するのは、閃光コンテンツが絶対に必要な場合のみにする必要があります。
詳細情報 - 3 回の閃光、またはしきい値以下（2.3.1） more-information-three-flashes-or-below-threshold
ナビゲーション可能（2.4） navigable
ガイドライン 2.4 ナビゲーション可能：ユーザーのナビゲーション、コンテンツの検索、位置の特定に役立つ方法を提供します。
これは、ユーザーがコンテンツを簡単かつ明白にナビゲートできることを目的としています。
ブロックのスキップ（2.4.1） bypass-blocks
- 達成基準 2.4.1
- レベル A
- ブロックのスキップ：複数の web ページで繰り返されるコンテンツのブロックをスキップする仕組みが利用できる。
目的 - ブロックのスキップ（2.4.1） purpose-bypass-blocks
この達成基準の目的は、コンテンツ間を順番に移動する訪問者が、web ページの主要なコンテンツにより直接敵にアクセスできるようにすることです。web ページやアプリケーションには、他のページや画面に表示されるコンテンツが含まれる場合が多くあります。コンテンツの繰り返しブロックの例としては、ナビゲーションリンク、ヘッダーグラフィック、メニュー、広告フレームなどがありますが、これらに限定されません。個々の単語、フレーズ、単一のリンクなどの小さな繰り返し節は、この規定の目的ではブロックとはみなされません。
達成方法 - ブロックのスキップ（2.4.1） how-to-meet-bypass-blocks
達成基準 2.4.1 の達成方法のガイドラインに従います。
詳細情報 - ブロックのスキップ（2.4.1） more-information-bypass-blocks
ページタイトル（2.4.2） page-titled
- 達成基準 2.4.2
- レベル A
- ページタイトル：web ページが、トピックまたは目的を説明するタイトルを持つ。
目的 - ページタイトル（2.4.2） purpose-page-titled
この達成基準は、特定の障害に関係なく、誰でも、ページを読み上げることなく、web ページのコンテンツをすばやく特定するのに役立ちます。これは、ページタイトルがタブに表示され、すばやく見つけることができるため、ブラウザーのタブで複数の web ページが開かれている場合に便利です。
達成方法 - ページタイトル（2.4.2） how-to-meet-page-titled
AEM で新しい HTML ページを作成する際には、ページタイトルを指定できます。コンテンツが自分のニーズに実際に関係があるかどうかを訪問者がすばやく特定できるように、ページのコンテンツや目的、特に独自の観点を十分に反映したタイトルにしてください。
ページを編集する際に、ページタイトルを編集することもできます（ページ情報／プロパティ からアクセス可能）。
詳細情報 - ページタイトル（2.4.2） more-information-page-titled
フォーカス順序（2.4.3） focus-order
- 達成基準 2.4.3
- レベル A
- フォーカス順序：web ページを順次ナビゲーションでき、ナビゲーションのシーケンスが意味や操作に影響を与える場合、フォーカス可能なコンポーネントは、意味や操作性を保持する順序でフォーカスを受け取る。
目的 - フォーカス順序（2.4.3） purpose-focus-order
この達成基準の目的は、ユーザーがコンテンツを順番に移動する際に、コンテンツの意味に合った順序で情報が表示され、キーボードから操作できるようにすることです。これにより、ユーザーがコンテンツの一貫したメンタルモデルを作成できるので、混乱が軽減されます。コンテンツ内の論理的な関係を反映した異なる順序が存在する場合があります。例えば、複数のフィールドやステップで構成されるオンラインフォームでのコンポーネント間の移動は、コンテンツ内の論理的な関係を反映しています。
達成方法 - フォーカス順序（2.4.3） how-to-meet-focus-order
達成基準 2.4.3 の達成方法のガイドラインに従います。
詳細情報 - フォーカス順序（2.4.3） more-information-focus-order
リンクの目的（コンテキスト内）（2.4.4） link-purpose-in-context
- 達成基準 2.4.4
- レベル A
- リンクの目的（コンテキスト内）：各リンクの目的は、リンクテキストのみから、またはプログラムで決定されたリンクコンテキストと共に、リンクテキストから決定できます。ただし、リンクの目的が一般的にユーザーにはあいまいな場合を除きます。
目的 - リンクの目的（コンテキスト内）（2.4.4） purpose-link-purpose-in-context
障害に関係なく、適切なリンクテキストを介したリンクの向きを明確に示すことが、すべてのユーザーにとって不可欠です。これは、実際にリンクをたどるかどうかを判断するのに役立ちます。目の見えるユーザーにとって意味のあるリンクテキストは、ページ上に複数のリンクがある場合（特にページがテキストの重い場合）に役立ちます。意味のあるリンクテキストは、ターゲットページの機能をより明確に示します。支援テクノロジーのユーザーは、1 つのページにすべてのリンクのリストを生成できるので、リンクテキストが独特でしかも情報量が多ければ、コンテキストからリンクテキストをより簡単に理解できます。ただし、目の見えるユーザーでも認知機能に障害がある場合は、リンク先を正確に説明する十分な情報をリンクが提供しないと、当惑する可能性があります。
達成方法 - リンクの目的（コンテキスト内）（2.4.4） how-to-meet-link-purpose-in-context
何よりも、リンクの目的がリンクのテキスト内で明確に説明されていることを確認してください。
-
悪い例：
- テキスト：2010 年秋の夜間クラスについて詳しくは、ここをクリックしてください。
- 理由：リンク先が不明瞭で、あいまいに示されています。
-
良い例：
- テキスト：2010 年秋の夜間クラス - 詳細。
- 理由：テキストとリンク要素の位置をわずかに調整することにより、リンクテキストを改善できます。
リンクは複数ページにわたって一貫した表現にする必要があります。ナビゲーションバーの場合は特にそうです。例えば、特定のページへのリンクの名前を、あるページで パブリケーション とする場合は、一貫性を保つために、他のページでもそのテキストを使用します。
本ドキュメントの執筆時点では、ページに表示される類似リンクがリンク先に関する一意の情報を提供するようにタイトル属性を使用するには、問題がいくつか発生しています（例えば、「続きを読む」は多くの場合、様々なリンク先を指します）。
- title 属性内に含まれるテキストは、マウスユーザーにツールチップのポップアップとして表示されるだけで、キーボードを使用した、またはモバイルユーザーによる一貫したアクセスはできません。
- スクリーンリーダーは title 属性を読み上げることができますが、この機能はデフォルトでは有効になっていない場合があります。したがって、ユーザーは、title 属性が存在することに気付かない場合があります。
- タイトルテキストの外観を変更するのは難しいので、一部の人にとっては読むのが困難または不可能な場合があります。
そのため、title 属性を使用してリンクに追加のコンテキストを提供できますが、その制限事項に注意して、適切なリンクテキストの代わりに使用しないでください。
リンクが画像で構成されている場合は、画像の代替テキストでリンク先を説明してください。例えば、本棚の画像をある人物のパブリケーションへのリンクとして設定している場合は、代替テキストを John Smith のパブリケーション とします。本棚 とはしないでください。
または、リンクアンカーに、画像要素に加えてリンクの目的を説明するテキストが含まれている場合（したがって、テキストが画像と一緒に表示される場合）、画像に空の alt 属性を使用します。
<a href="publications.html">
<img src = "bookshelf.jpg" alt = "" />
John Smith's publications
</a>
追加のコンテキストを必要とせずにリンクの目的を識別するリンクテキストを提供することが望ましいものの、これが常に可能とは限らないことがわかっています。コンテキストのないリンクは、次の場合に使用できます。HTML の例は、達成基準 2.4.4 の達成方法を参照してください。
- リンクテキストが、密接に関連するリンクのリストの一部であり、リンクを含むリスト項目で十分なコンテンツが提供されている場合。
- リンクの目的が、前の（後ろではない）段落テキストから明確に識別できる場合。
- リンクはデータテーブル内に含まれているので、関連する見出しから目的を明確に識別できます。
- リンクのリストは一連の見出し内に含まれ、見出し自体が適切なコンテキストを提供します。
- リンクのリストはネストされたリンク内に含まれ、ネストされたリンクの上にある親リスト項目が適切なコンテキストを提供します。
1 つのページ上に複数のリンクがある場合（各リンクで提供される指示が複雑だが必要な詳細である場合）は、代替バージョンの web ページを提供することが妥当と言えます。代替バージョンは、まったく同じコンテンツを表示する一方で、リンクテキストはそれほど詳細ではありません。
または、最小限のテキストがリンク自体内に提供されるように、スクリプトを使用します。ページ上部に配置された適切なコントロールをアクティブにすると、リンクテキストが 展開されて さらに詳細になります。同様の方法は、CSS を使用して目の見えるユーザーから完全なリンクを 隠す ことですが、スクリーンリーダーのユーザーには完全なリンクを出力します。これはこのドキュメントの範囲外ですが、これを実現する方法の詳細については、「詳細情報 - リンクの目的（コンテキスト内）（2.4.4）」節を参照してください。
詳細情報 - リンクの目的（コンテキスト内）（2.4.4） more-information-link-purpose-in-context
複数の手段（2.4.5） multiple-ways
- 達成基準 2.4.5
- レベル AA
- 複数の手段：一連の web ページ内で web ページを見つける方法が複数ある。ただし、web ページがプロセスの結果や 1 ステップである場合を除く。
目的 - 複数の手段（2.4.5） purpose-multiple-ways
この達成基準の目的は、ユーザーがニーズに最も合った方法でコンテンツを見つけられるようにすることです。ユーザーは、複数の手段のなかから、より使いやすい、または分かりやすい手段を見つけられます。
小規模サイトでも、何らかの形で方向付けの手段を提供する必要があります。3 ～ 4 ページのサイトで、すべてのページがホームページからリンクされている場合、ホームページ上のリンクがサイトマップとしても機能するため、ホームページと各ページ間で相互にリンクを提供するだけで十分です。
対応方法 - 複数の手段（2.4.5） how-to-meet-multiple-ways
達成基準 2.4.5 の達成方法のガイドラインに従います。
詳細情報 - 複数の手段（2.4.5） more-information-multiple-ways
見出しおよびラベル（2.4.6） headings-and-labels
- 達成基準 2.4.6
- レベル AA
- 見出しおよびラベル：見出しとラベルがトピックや目的を表している。
目的 - 見出しおよびラベル（2.4.6） purpose-headings-and-labels
この達成基準の目的は、ユーザーが web ページに含まれる情報と、その情報の編成方法を理解できるようにすることです。見出しが明確で説明的な場合、ユーザーは探している情報が見つけやすくなり、コンテンツの異なる部分との関係を理解しやくなります。説明的なラベルは、コンテンツ内の特定のコンポーネントの識別に役立ちます。
達成方法 - 見出しおよびラベル（2.4.6） how-to-meet-headings-and-labels
達成基準 2.4.6 の達成方法のガイドラインに従います。
詳細 - 見出しおよびラベル（2.4.6） more-information-headings-and-labels
フォーカスの可視化（2.4.7） focus-visible
- 達成基準 2.4.7
- レベル AA
- フォーカスの可視化：キーボード操作可能なユーザインターフェイスは、キーボードフォーカスインジケータを表示する操作モードがある。
目的 - フォーカスの可視化（2.4.7） purpose-focus-visible
この達成基準の目的は、キーボードのフォーカスがある要素を知るのに役立ちます。
複数の要素の中で、キーボードフォーカスがある要素を知ることが可能である必要があります。画面に操作可能なキーボードコントロールが 1 つしかない場合、視覚的なデザインは操作可能なキーボードアイテムを 1 つだけ表示するので、達成基準は満たされます。
達成基準で「操作モード」としているのは、フォーカスインジケーターが常に表示されるとは限らないプラットフォームを考慮するためです。ほとんどの場合、操作モードは 1 つだけなので、この達成基準が適用されます。
達成方法 - フォーカスの可視化（2.4.7） how-to-meet-focus-visible
達成基準 2.4.7 の達成方法のガイドラインに従います。
詳細情報 - フォーカスの可視化（2.4.7） more-information-focus-visible
原則 3：理解可能 principle-understandable
原則 3：理解可能 - 情報とユーザーインターフェイスの操作は理解可能である必要があります。
テキストコンテンツを読みやすく理解可能にする（3.1） make-text-content-readable-and-understandable
ガイドライン 3.1 読み取り可能：テキストコンテンツを読みやすく理解可能にします。
ページの言語（3.1.1） language-of-page
- 達成基準 3.1.1
- レベル A
- ページの言語：各 web ページのデフォルトの自然言語がどの言語であるか、プログラムによる特定ができる。
目的 - ページの言語（3.1.1） purpose-language-of-page
この達成基準の目的は、テキストやその他の言語コンテンツが正しくレンダリングされるようにすることです。スクリーンリーダーを使用しているユーザーの場合、これにより、コンテンツが正しく発音されるようになり、視覚的なブラウザーでも、特定の文字セットが正しく表示される可能性が高くなります。
達成方法 - ページの言語（3.1.1） how-to-meet-language-of-page
この達成基準を満たすために、ページ上部の lang 要素内で <html> 属性を使用して、web ページのデフォルト言語を識別できます。次に例を示します。
-
英語で書かれているページの場合、
<html>要素は次のようになります。<html lang = "en"> -
一方、スペイン語でレンダリングされるページの場合は、次の標準規格を採用します。
<html lang = "es">
AEM では、ページのデフォルト言語はページ作成時に設定されますが、ページプロパティの編集時に変更することもできます。
詳細情報 - ページの言語（3.1.1） more-information-language-of-page
- 達成基準 3.1.1 について
- 達成基準 3.1.1 の達成方法
- コードは ISO 639-1 に基づいています。各言語の詳細なコードリストについて詳しくは、W3 Schools サイトを参照してください。
一部分の言語（3.1.2） language-of-parts
- 達成基準 3.1.2
- レベル AA
- 一部分の言語：コンテンツ内の各節またはフレーズの人間言語をプログラムで決定できます。例外は、固有名、技術用語、不定期な言語の単語、および直前を取り囲むテキストの言葉の一部となっている単語やフレーズです。
目的 - 一部分の言語（3.1.2） purpose-language-of-parts
この達成基準の目的は、ページの言語の達成基準と類似していますが、単一のページに複数言語のコンテンツ（引用や一般的でない外来語）が含まれる web ページに適用される点が異なります。
この達成基準を適用するページでは、次のことが可能です。
- アクセント付き文字を挿入する点字翻訳ソフトウェア。
- スクリーンリーダーで、特殊文字を含む単語やページレベルで識別されたデフォルト言語でない単語を発音。
- コンテンツを言語間で正しく翻訳するための翻訳ツール（Google Translate など）。
達成方法 - 一部分の言語（3.1.2） how-to-meet-language-of-parts
lang 属性を使用して、コンテンツの言語の変更を識別できます。例えば、ドイツ語（ISO 639-1 コード「de」）の引用は、次のように表示できます。
<blockquote cite = "John F. Kennedy" lang = "de">
<p>Ich bin ein Berliner</p>
</blockquote>
同様に、span 要素を次のように使用した場合は、一般的でない外来語やフレーズをブラウザーで正しくレンダリングできます。
<p>The only French phrase I know is <span lang = "fr">je ne sais quoi</code>.</p>
span 要素を適切な言語で追加するには、RTE のソース編集モードで、上記の内容になるように HTML マークアップを手動で編集します。または、システム管理者が lang 属性を RTE に含めることもできます（追加の HTML 要素および属性のサポートの追加を参照）。
詳細情報 - 一部分の言語（3.1.2） more-information-language-of-parts
予測可能（3.2） predictable
ガイドライン 3.2 予測可能：web ページを予測可能な方法で表示および操作できるようにします。
これは、web ページの外観と動作の一貫性を確保することを目的としています。
フォーカス時（3.2.1） on-focus
- 達成基準 3.2.1
- レベル A
- フォーカス時：どのユーザインターフェイスコンポーネントもフォーカスを受け取ったときに、コンテキストの変化を引き起こさない。
目的 - フォーカス時（3.2.1） purpose-on-focus
この達成基準の目的は、訪問者がドキュメント内を移動する際に、機能が予測可能であることを保証することです。フォーカスを受け取ったときにイベントをトリガーできるコンポーネントは、コンテキストを変更してはなりません。コンポーネントがフォーカスを受け取った場合のコンテキストの変更例を次に示しますが、これらに限定されません。
- コンポーネントがフォーカスを受けると自動的に送信されるフォーム
- コンポーネントがフォーカスを受けると起動する新しいウィンドウ
- コンポーネントがフォーカスを受け取るとフォーカスが他のコンポーネントに変更される
キーボード（コントロールへのタブ移動など）やマウス（テキストフィールドのクリックなど）を使用して、フォーカスをコントロールに移動させることもできます。コントロールの上にマウスを移動しても、スクリプティングによってこの動作が実装されていない限り、フォーカスは移動しません。コントロールのタイプによっては、コントロールをクリックするとコントロール（ボタンなど）がアクティブになり、コンテキストの変更が開始する場合があります。
達成方法 - フォーカス時（3.2.1） how-to-meet-on-focus
達成基準 3.2.1 の達成方法のガイドラインに従います。
詳細情報 - フォーカス時（3.2.1） more-information-on-focus
入力時（3.2.2） on-input
- 達成基準 3.2.2
- レベル A
- 入力時：ユーザインターフェイスコンポーネントの設定を変更しても、コンポーネントを使用する前にユーザーに動作について通知されていない限り、コンテキストは自動的に変更されない。
目的 - 入力時（3.2.2） purpose-on-input
この達成基準の目的は、データの入力やフォームコントロールの選択を確実に予測可能な結果にすることです。ユーザインターフェイスコンポーネントの設定を変更すると、コントロールの一部の側面が変更され、ユーザーが操作を完了したタイミングで保存されます。したがって、チェックボックスをオンにしたり、テキストフィールドにテキストを入力したり、リストコントロールで選択したオプションを変更したりすると、設定は変わりますが、リンクやボタンはアクティブになりません。コンテキストの変更は、変更を容易に認識できないユーザーや、変更によって注意力が散漫になりやすいユーザーを混乱させる可能性があります。コンテキストの変更は、このような変更がユーザーのアクションに応じて行われることが明確な場合にのみ適切です。
達成方法 - 入力時（3.2.2） how-to-meet-on-input
達成基準 3.2.2 の達成方法のガイドラインに従います。
詳細情報 - 入力時（3.2.2） more-information-on-input
一貫したナビゲーション（3.2.3） consistent-navigation
- 達成基準 3.2.3
- レベル AA
- 一貫したナビゲーション：一連の web ページ内の複数の web ページで繰り返されるナビゲーションのメカニズムは、ユーザーが変更しない限り、繰り返されるたびに同じ相対順で発生する。
目的 - 一貫したナビゲーション（3.2.3） purpose-consistent-navigation
この達成基準の目的は、一連の web ページ内で繰り返されるコンテンツを操作し、特定の情報や機能を複数回検索する必要があるユーザーに、一貫した表示とレイアウトの使用を促すことです。視覚障碍を持つ人が画面の表示比率を使用して一度に画面の一部のみを表示する場合は、繰り返されるコンテンツをすばやく見つけ出すために、よく視覚的なキューやページの境界を使用します。繰り返されるコンテンツを同じ順序で表示することは、デザイン内の空間記憶や視覚的キューを使用して繰り返されるコンテンツを見つけ出す視覚的ユーザーにとっても重要です。
この節で使用される「同じ順序」というフレーズは、サブナビゲーションメニューを使用できない、またはセカンダリナビゲーションやページ構造のブロックを使用できないという意味ではありません。この達成基準の目的は、web ページ上で繰り返されるコンテンツを操作するユーザーにとって、探しているコンテンツの場所を予測しやすくすることです。そして、同様のコンテンツを再度目にしたときに、より迅速に見つけ出せるようにすることです。
ユーザーは、アダプティブユーザーエージェントを使用するか、環境設定を設定して、ユーザーにとって最も役立つ方法で情報が表示されるように、順序を変更することもできます。
達成方法 - 一貫したナビゲーション（3.2.3） how-to-meet-consistent-navigation
達成基準 3.2.3 の達成方法のガイドラインに従います。
詳細情報 - 一貫したナビゲーション（3.2.3） more-information-consistent-navigation
一貫した識別（3.2.4） consistent-identification
- 達成基準 3.2.4
- レベル A
- 一貫した識別：一連の web ページ内で同じ機能を持つコンポーネントは一貫して識別される。
目的 - 一貫した識別（3.2.4） purpose-consistent-identification
この達成基準の目的は、一連の web ページ内で繰り返し表示される機能コンポーネントを一貫して識別することです。Web サイトの操作時にスクリーンリーダーを使用するユーザーが取る戦略は、異なる web ページに表示される機能になじみがあるかどうかに大きく依存しています。別の web ページの同じ機能に、異なるラベル（または、より一般的には、別のアクセシブルな名前）が付いている場合、そのサイトは非常に使いにくくなります。また、認知機能に障害があるユーザーにとっては、混乱を招き、認知負荷が高まる可能性があります。したがって、一貫したラベル付けが役立ちます。
この一貫性は、代替テキストにも及びます。アイコンやその他のテキスト以外の項目が同じ機能を持つ場合は、代替テキストも一貫性を保つ必要があります。
web ページ上に 2 つのコンポーネントがあり、両方のコンポーネントが、一連の web ページ内の別のページ上にあるコンポーネントと同じ機能を持つ場合は、3 つすべてのコンポーネントの一貫性が維持される必要があります。したがって、同じページ上の 2 つは一貫性を持つことになります。
1 つの web ページ内で一貫性を保つことは望ましく、ベストプラクティスでもありますが、3.2.4 では、複数ページにわたって何かが繰り返される、一連の web ページ内の一貫性のみに対応します。
達成方法 - 一貫した識別（3.2.4） how-to-meet-consistent-identification
達成基準 3.2.4 の達成方法のガイドラインに従います。
詳細情報 - 一貫性のある識別（3.2.4） more-information-consistent-identification
入力支援（3.3） input-assistance
ガイドライン 3.3 入力支援：利用者の間違いを防ぎ、修正を支援すること。
エラーの特定（3.3.1） error-identification
- 達成基準 3.3.1
- レベル A
- エラーの特定：入力エラーが自動的に検出されると、エラーのある項目が識別され、そのエラーがユーザーにテキストで説明される。
目的 - エラーの特定（3.3.1） purpose-error-identification
この達成基準の目的は、エラーが発生したことをユーザーが確実に認識し、何が間違っているかを判断できるようにすることです。エラーメッセージは、できる限り具体的に記述する必要があります。フォームの送信に失敗した場合に、フォームを再表示してエラーのあるフィールドを示すことは、一部のユーザーにとって、エラーの発生を認識するのに十分ではありません。例えば、スクリーンリーダーを使用するユーザーは、いずれかのインジケーターに遭遇するまで、エラーがあったことに気づきません。エラーインジケーターに遭遇する前に、単純にページが機能していないのだと思い、フォームを完全に破棄してしまう可能性があります。WCAG の定義によると、入力エラーは、ユーザーから提供される受け入れられない情報です。これには以下のものが含まれます。
Web ページで必要とされるが、ユーザーによって省略された情報。またはユーザーが提供したが、必要なデータ形式または許可されている値に該当しない情報。
例：
- ユーザーが、州、準州、地域のフィールドに適切な省略形を入力しない
- ユーザーが有効ではない州の省略形を入力する
- ユーザーが存在しない郵便番号を入力する
- ユーザーが 2 年後の生年月日を入力する
- ユーザーが、数字しか受け入れない電話番号フィールドに英字や丸括弧を入力する
- ユーザーが前回の入札または最小入札増分を下回る入札を入力する
達成方法 - エラーの特定（3.3.1） how-to-meet-error-identification
達成基準 3.3.1 の達成方法のガイドラインに従います。
詳細情報 - エラーの特定（3.3.1） more-information-error-identification
ラベルまたは説明（3.3.2） labels-or-instructions
- 達成基準 3.3.2
- レベル A
- ラベルまたは説明：コンテンツにユーザー入力が必要な場合に、ラベルまたは説明が提供されている。
目的 - ラベルまたは説明（3.3.2） purpose-labels-or-instructions
フォームへの入力を支援する説明を提供することは、インターフェイスを使いやすくするための基本です。このような説明は、視覚や認知機能で支援を必要としているユーザーが、フォームのレイアウトや、フォームの特定のフィールドで入力する必要があるデータの種類を理解するのに役立ちます。
Forms
AEM WKND デモプロジェクトでは、テキストフィールド などのフォームコンポーネントをページに追加すると、デフォルトのラベルが追加されます。このデフォルトのタイトルはコンポーネントのタイプによって異なります。そのフィールドの編集ダイアログの「タイトルとテキスト」タブに、独自のタイトルを追加できます。各フォームコンポーネントに関連付けられているデータをユーザーが理解できるようなラベルを指定することが重要です。
この「タイトル」フィールドは、支援テクノロジーで使用できるラベルを提供するので、フィールド要素用に使用する必要があります。フィールドの横のテキストにラベルを書き込むだけでは不十分です。
一部のフォームコンポーネントでは、「タイトルを非表示にする」チェックボックスを使用してラベルを非表示にすることもできます。この方法で非表示にしたラベルは、支援テクノロジーでは引き続き使用できますが、画面には表示されません。状況によっては、この方法で十分ですが、可能な限り視覚的なラベルを含めることをお勧めします。画面の非常に狭い部分（フィールド 1 つずつ）を見ていて、ラベルによってフィールドを正確に識別できることを必要としているユーザーがいる可能性もあるからです。
画像ボタン image-buttons
画像ボタンが使用されている場合（WKND プロジェクトの 画像ボタン コンポーネントなど）、編集ダイアログの「タイトルとテキスト」タブの「タイトル」フィールドには、ラベルではなく、画像の代替テキストが実際に表示されます。以下の例では、Submit というテキストを持つ画像に、Submit という代替テキストが、編集ダイアログの「タイトル」フィールドを使用して追加されています。
フォームフィールドのグループ groups-of-form-fields
ラジオグループ など、関連するコントロールのグループがある WKND プロジェクトでは、個々のコントロールだけでなく、グループにタイトルが必要になる場合があります。AEM でラジオボタンのセットを追加する場合、「タイトル」フィールドにはこのグループタイトルが表示されますが、個々のタイトルはラジオボタン（項目）の作成時に指定されます。
ただし、グループタイトルとラジオボタン自体との間には、プログラム的な関連付けはありません。テンプレートエディターでは、必要な fieldset タグと legend タグでタイトルを囲んで、この関連付けを作成する必要があります。この処理は、ページのソースコードを編集することによってのみ可能です。また、システム管理者がこれらの要素のサポートを追加して、フィールドのプロパティ ダイアログに表示させることもできます（追加の HTML 要素および属性のサポートの追加を参照）。
フォームに関するその他の考慮事項 additional-considerations-for-forms
データを特定の形式で入力する必要がある場合は、ラベルテキストでそのことを明確に示します。例えば、日付を DD-MM-YYYY という形式で入力する場合は、ラベルの一部としてこのことを具体的に示します。つまり、スクリーンリーダーユーザーがフィールドに遭遇したとき、形式に関する追加情報も含めて、ラベルが自動的に読み上げられるということです。
入力が必須のフォームフィールドがある場合は、「必須」という単語をラベルの一部として使用して、このことを明確に示します。AEM では、必須のフィールドにはアスタリスクが追加されますが、「required」（必須）という単語をラベル自体に含めることが理想的です（編集ダイアログの「タイトル」フィールドを使用）。
ラベルの配置も、適切なフィールドを見つけるうえで役立つので重要です。このことは、複雑なフォームの場合に特に重要です。次の規則に従います。
- チェックボックスまたはラジオボタン：ラベルをフィールドのすぐ右に配置します。
- その他すべてのフォームコンポーネント（テキストボックス、コンボボックスなど）：
ラベルをフィールドのすぐ上またはすぐ左に配置します。
機能が限られた簡単なフォームでは、「Submit」ボタンに適切なラベルを付けると、隣のフィールド（「Search」など）のラベルとしての役割を果たすことができます。これは、ラベルテキストのスペースを見つけることが困難な可能性のある場合に便利です。
詳細情報 - ラベルまたは説明（3.3.2） more-information-labels-or-instructions
エラー修正の提案（3.3.3） error-suggestion
- 達成基準 3.3.3
- レベル AA
- キーボード：入力エラーが自動的に検出され、修正候補がわかる場合は、コンテンツのセキュリティや目的を危険にさらさない限り、修正候補がユーザーに提供される。
目的 - エラー修正の提案（3.3.3） purpose-error-suggestion
この達成基準の目的は、入力エラーの修正に必要な適切な提案がユーザーに確実に届くようにすることです。WCAG の入力エラーの定義は、「ユーザーが提供する情報で、受け入れられないもの」というものです。受け入れられない情報の例としては、必要であるがユーザーによって省略された情報や、ユーザーが提供するが、必要なデータ形式または許容される値に該当しない情報などがあります。
達成基準 3.3.1 はエラーの通知を提供します。しかし、認知機能に障碍を持つユーザーは、エラーの修正方法を理解するのが難しい場合があります。視覚に障碍を持つユーザーは、エラーの修正方法を正確に理解できない場合があります。フォームの送信に失敗すると、ユーザーはエラーの発生を認識しているにもかかわらず、エラーの修正方法が分からないために、フォームを放棄してしまうことがあります。
コンテンツ作成者がエラーの説明を提供するか、ユーザーエージェントが、テクノロジーに特化した、プログラム的に決定された情報に基づいてエラーの説明を提供することができます。
達成方法 - エラー修正の提案（3.3.3） how-to-meet-error-suggestion
達成基準 3.3.3 の達成方法のガイドラインに従います。
詳細情報 - エラー修正の提案（3.3.3） more-information-error-suggestion
エラー回避（法務、金融、データ）（3.3.4） error-prevention-legal-financial-data
-
達成基準 3.3.4
-
レベル AA
-
エラー回避（法務、金融、データ）：ユーザーに関する法的コミットメントや金融トランザクションの発生、データストレージシステム内にある、ユーザーが自分で制御可能なデータ変更や削除、またはユーザーテストの応答を送信する web ページでは、次のうち少なくとも 1 つを満たしている。
- 取り消し
送信を取り消すことができる - チェック
ユーザーが入力したデータに入力エラーがないかどうかがチェックされ、ユーザーに修正の機会が与えられる - 確認
送信の最終処理を行う前に、情報の見直し、確認および修正を行うメカニズムを利用できる
- 取り消し
目的 - エラー回避（法務、金融、データ）（3.3.4） purpose-error-prevention-legal-financial-data
この達成基準の目的は、障碍を持つユーザーが、元に戻せない操作を実行する際に、誤りが原因で重大な結果が生じるのを回避できるよう支援することです。例えば、返金不能な航空券を購入したり、証券会社の口座で株式購入注文を送信したりすると、深刻な結果をもたらす金融取引となります。航空便の日付を誤った場合、ユーザーは、交換できない間違った日付のチケットを購入することになります。購入する株式の数を間違えた場合は、ユーザーは、意図した数よりも多くの株式を購入する可能性があります。大きな出費を伴うどちらのタイプのミスも、すぐに実行され、後で変更できないトランザクションが関わっています。同様に、データベースに保存された、後でアクセスする必要があるデータ（例えば旅行サービスの web サイトに保存されている旅行プロファイル全体など）を誤って変更または削除してしまうと、回復不能なエラーとなる可能性があります。「ユーザーが自分で制御可能」なデータの変更または削除を参照する場合、この達成基準の意図は、ファイルやレコードの削除など、大量のデータの損失を防ぐことです。保存コマンド、またはドキュメント、レコード、その他のデータの単純な作成や編集を実行するたびに、確認を要求するものではありません。
障碍を持つユーザーは、間違える可能性が高くなる場合があります。読字障碍を持つユーザーは数字や文字の位置を間違えることがあり、運動障碍を持つ利用者は誤ってキーを押してしまう可能性があります。アクションを取り消す機能を提供すると、ユーザーは重大な結果を招く可能性のある誤りを修正できます。また、入力内容を確認して修正できるようにすることで、重大な結果につながる行動を取ってしてしまう前に、ユーザーがミスに気づくことができるようになります。
ユーザーが自分で制御可能なデータとは、ユーザーが意図した行動によって変更および／または削除できる、ユーザーが閲覧可能なデータのことです。ユーザーがこれらのデータを制御するケースの例としては、ユーザーアカウントの電話番号と住所の更新や、Web サイトから過去の請求書レコードの削除などがあります。インターネットログや検索エンジンの監視データなど、ユーザーが直接表示または操作できないデータは指しません。
達成方法 - エラー回避（法務、金融、データ）（3.3.4） how-to-meet-error-prevention-legal-financial-data
達成基準 3.3.4 の達成方法のガイドラインに従います。
詳細情報 - エラー回避（法務、金融、データ）（3.3.4） more-information-error-prevention-legal-financial-data
原則 4：堅牢 principle-robust
原則 4：堅牢 - コンテンツは、支援テクノロジーを含む様々なユーザーエージェントが確実に解釈できるように十分に堅牢でなければならない。
互換性（4.1） compatible
ガイドライン 4.1 互換性：支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。
支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。
構文解析（4.1.1） parsing
- 達成基準 4.1.1
- レベル A
- 構文解析：マークアップ言語を使用して実装したコンテンツでは、要素に完全な開始タグと終了タグが付けられ、要素は仕様に従ってネストされ、重複属性は含まれず、ID は一意である。ただし、指定によって機能が許可される場合を除く。
目的 - 構文解析（4.1.1） purpose-parsing
この達成基準の目的は、支援テクノロジーを含むユーザーエージェントがコンテンツを正確に解釈および解析できるようにすることです。コンテンツをデータ構造に解析できない場合、異なるユーザーエージェントがそのコンテンツを異なる方法で表示する、または全く解析できない可能性があります。一部のユーザーエージェントは、コード化が不完全なコンテンツをレンダリングする際に、「修復テクニック」を使用します。
修復技術はユーザーエージェントによって異なるので、そのテクノロジーの正式な文法で定義された規則に従ってコンテンツが作成されない限り、コンテンツが正確にデータ構造に解析される、または支援テクノロジーなどの特殊なユーザーエージェントによって正しくレンダリングされることを、作成者は前提にすることはできません。マークアップ言語では、要素と属性の構文のエラーと、正しくネストされた開始および終了タグの提供に失敗すると、エラーが発生し、ユーザーエージェントがコンテンツを確実に解析できなくなります。したがって、達成基準では、正式な文法規則の規則のみを使用して内容を解析できる必要があります。
達成方法 - 構文解析（4.1.1） how-to-meet-parsing
達成基準 4.1.1 の達成方法のガイドラインに従います。
詳細 - 構文解析（4.1.1） more-information-parsing
名前、役割、値（4.1.2） name-role-value
- 達成基準 4.1.2
- レベル A
- 名前、役割、値：すべてのユーザーインターフェイスコンポーネント（フォーム要素、リンク、スクリプトによって生成されるコンポーネントを含むが、これらに限定されない）で、名前と役割をプログラムによって決定できる。ユーザーが設定できるステータス、プロパティ、値は、プログラムによって設定できる。また、これらの項目に対する変更の通知は、支援テクノロジーを含むユーザーエージェントが利用できる。
目的 - 名前、役割、値（4.1.2） purpose-ame-role-value
この達成基準の目的は、支援テクノロジー（AT）がコンテンツ内のユーザーインターフェイスコントロールのステータスに関する情報を収集、アクティブ化（設定）し、最新の状態に保つことです。
アクセシブルなテクノロジーの標準的なコントロールを使用する場合、このプロセスは簡単です。仕様に従ってユーザーインターフェイス要素を使用することで、この規定の条件が満たされます（以下の達成基準 4.1.2 の例を参照）。
ただし、カスタムコントロールを作成した場合、または（コードまたはスクリプト内の）インターフェイス要素が通常とは異なる役割および／または機能を持つようにプログラムされている場合は、支援テクノロジーに重要な情報を提供し、支援テクノロジーで制御できるように、追加の対策を講じる必要があります。
ユーザーインターフェイスのコントロールの特に重要な状態は、フォーカスがあるかどうかです。コントロールのフォーカス状態はプログラムで判定でき、フォーカスの変更に関する通知はユーザーエージェントや支援テクノロジーに送られます。ユーザーインターフェイスのコントロールの状態に関する他の例には、チェックボックスやラジオボタンが選択されているかどうかがあります。または、折りたたみ可能なツリーやリストノードが展開されているのか、折りたたまれているのかもあります。
達成方法 - 名前、役割、値（4.1.2） how-to-meet-ame-role-value
達成基準 4.1.2 の達成方法のガイドラインに従います。