From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../accessibility/understanding_wcag/index.html | 58 ++++ .../understanding_wcag/operable/index.html | 319 ++++++++++++++++++ .../understanding_wcag/perceivable/index.html | 357 +++++++++++++++++++++ .../understanding_wcag/robust/index.html | 85 +++++ .../understanding_wcag/understandable/index.html | 259 +++++++++++++++ 5 files changed, 1078 insertions(+) create mode 100644 files/ja/web/accessibility/understanding_wcag/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/operable/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/perceivable/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/robust/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/understandable/index.html (limited to 'files/ja/web/accessibility/understanding_wcag') diff --git a/files/ja/web/accessibility/understanding_wcag/index.html b/files/ja/web/accessibility/understanding_wcag/index.html new file mode 100644 index 0000000000..67d1dcfbe8 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/index.html @@ -0,0 +1,58 @@ +--- +title: ウェブコンテンツ・アクセシビリティガイドラインを理解する +slug: Web/Accessibility/Understanding_WCAG +tags: + - Accessibility + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

この一連の記事では、W3C {{glossary("WCAG","ウェブコンテンツ・アクセシビリティガイドライン")}} 2.0 または 2.1（WCAG、Web Content Accessibility Guidelines）で概説されている推奨事項に準拠するために必要な手順を理解するのに役立つ簡単な説明を提供します。

+ +

WCAG 2.0 と 2.1 は、さまざまな障碍を持つ人々にとってウェブコンテンツをよりアクセスしやすくするための詳細なガイドラインを提供しています。 それは包括的ですが信じられないほど詳細であり、そして迅速な理解を得ることは非常に困難です。 このため、さまざまな推奨事項を満たすために必要な実際的な手順をまとめ、必要に応じて詳細へのリンクを追加しました。

+ +

4つの原則

+ +

WCAG は大きく4つの原則に分割されます —  ウェブコンテンツがアクセス可能であるように熟慮しなければならない主要な事柄（WCAG 定義のためのアクセシビリティの4つの原則の理解（英語）を参照してください）。

+ +

以下の各リンクはこれらの分野をさらに拡大するページにあなたを連れて行くでしょう。 それらは、WCAG 2.0 および 2.1 の各ガイドラインで概説されている達成基準に準拠するように、ウェブコンテンツの書き方について実際的なアドバイスを与え、各原則をさらに細分化します。

+ + + +

WCAG 2.0 と 2.1 のどちらを使うべきか？

+ +

WCAG 2.1 は最新かつ関連性のあるアクセシビリティ標準です。 WCAG 2.1 を使用して、より多くの障碍者を支援し、ウェブサイト所有者に対する将来の法的リスクを軽減します。 リソースを割り当てるときは、最初に WCAG 2.0 を目標にしてください。 それから WCAG 2.1 にステップアップしてください。

+ +

WCAG 2.1 とは何か？

+ +

WCAG 2.1 は、2018年6月5日に公式勧告として発行されました。 欧州連合（EU）は、2018年9月にデジタルアクセシビリティ標準として WCAG 2.1 を採用しました。 W3C は、プレスリリース ヨーロッパにおける WCAG 2.1 の採用（英語）を発表しました。

+ +

WCAG 2.1 には以下が含まれます。

+ + + + + +

このガイドは、より良く、よりアクセスしやすいウェブサイトを構築するのに役立つ実用的な情報を提供することを目的としています。 しかし、私たちは弁護士ではありません、そしてこれのどれも法的助言を構成しません。 ウェブのアクセシビリティが法的にどのような意味を持つのかを心配している場合は、あなたの国や地域のウェブや公共のリソースに対するアクセシビリティを規定する特定の法律を調べ、有資格の弁護士に相談することをお勧めします。

+ +

アクセシビリティとは？と、その中のアクセシビリティのガイドラインと法律のセクションには、より関連性の高い情報が記載されています。

diff --git a/files/ja/web/accessibility/understanding_wcag/operable/index.html b/files/ja/web/accessibility/understanding_wcag/operable/index.html new file mode 100644 index 0000000000..52d258a1a8 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/operable/index.html @@ -0,0 +1,319 @@ +--- +title: 操作可能 +slug: Web/Accessibility/Understanding_WCAG/Operable +tags: + - Accessibility + - Focus + - Navigation + - Principle 2 + - Timing + - WCAG + - Web Content Accessibility Guidelines + - headings + - keyboard + - keyboard trap + - labels + - operable + - seizures +translation_of: Web/Accessibility/Understanding_WCAG/Operable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の操作可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 操作可能とは、ユーザーインターフェイス・コンポーネントとナビゲーションが操作可能でなければならないということです。

+ +
+

注: 操作可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 2: 操作可能 — ユーザーインターフェース・コンポーネントとナビゲーションが操作可能でなければならない（英語）を参照してください。

+
+ +

ガイドライン 2.1 — キーボードアクセス可能: キーボードから全ての機能を利用可能にする

+ +

このガイドラインは、キーボード制御に頼るユーザーがコアウェブサイト機能にアクセスできるように、他の手段（例えば、マウス）に加えてキーボードを介してそれらを利用可能にする必要性をカバーする。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.1.1 キーボード (A)キーボードを使用して行えない場合（例えば、フリーハンド描画）を除き、全ての機能はキーボード制御を使用してアクセス可能であるべきです。 可能な場合は組み込みのコントロールを使用するべきで（例えば、フォームコントロール間のタブ移動）、必要な場合にのみカスタム機能を組み込むべきです。UI コントロールとキーボード・アクセシビリティを取り戻すを参照してください。
2.1.2 キーボードを閉じ込めない (A) +

キーボードを使用してある機能のセクションに入るときは、キーボードのみを使用してそのセクションから再び出ることができるべきです。 例えば、フォーカスのあるボタンの上で Enter / Return を押してオプションウィンドウを開いたら、キーボードを使ってそのウィンドウを再び閉じてメインコンテンツに戻ることができるべきです。

+ +

キーボードユーザーをアプリの特定のセクションに閉じ込めないようにするために、これは非常に重要です。

+ 		 
2.1.3 キーボード — 全機能 (AAA)これは、基準 2.1.1 を超えるさらなるステップです。 AAA 準拠を達成するために、全ての機能はキーボードコントロールを使用してアクセス可能であるべきです — 例外なく。UI コントロールとキーボード・アクセシビリティを取り戻すを参照してください。
2.1.4 文字キーショートカット (A) 2.1 で追加（英語）単一文字キーショートカットが存在する場合は、少なくとも次の1つが当てはまります。 単一文字キーショートカットは、オフにする、再マップする、または関連するユーザーインターフェース・コンポーネントにフォーカスがあるときにのみアクティブにすることができます。文字キーショートカットを理解する（英語）
+ +
+

注: ガイドライン 2.1: キーボードアクセス可能: キーボードから全ての機能を利用可能にする（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.2 — 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する

+ +

このガイドラインでは、機能に制限時間があるかもしれない状況について説明します。 例えば、セキュリティ上の理由から、購入を制限時間内に完了する必要がある場合があります。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.2.1 タイミングは調整可能 (A) +

制限時間付きの機能の場合（例えば、ホテルやフライトの予約を完了するには制限時間があることが多い）、ユーザーには、制限時間の調整、延長、または無効化を許可するコントロールを与えるべきです。

+ +

これに対する例外は、20時間を超える制限時間のある活動、リアルタイムイベント（例えば、ライブマルチプレイヤーゲーム）、および制限時間が必要で、無効にされた場合に無効になるその他の活動です。

+ 		 
2.2.2 一時停止、停止、非表示 (A) +

自動的に開始され、5秒以上続き、他のコンテンツと一緒に表示されるコンテンツを移動や点滅させるには、一時停止、停止、または非表示にするためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの移動や点滅には適用されません。 例としては、テキストのスクロールと動画があります。

+ +

自動的に開始され、他のコンテンツと一緒に表示される自動更新情報の場合は、一時停止、停止、または非表示にするため、あるいは更新頻度を制御するためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの自動更新には当てはまりません。 例としては、回転木馬や回転アナウンスがあります。

+ 		 
2.2.3 制限時間なし (AAA)これは基準 2.2.1 に基づいており、AAA 適合に合格したいコンテンツには制限時間がないことを述べています。 
2.2.4 中断を抑止する (AAA)アラートやインタースティシャル広告などによる中断には、緊急アラートでない限り、それらを抑制または延期するための機能を用意するべきです。 
2.2.5 再認証 (AAA)ウェブアプリの使用中に認証セッションが期限切れになった場合、ユーザーはデータを失うことなく再認証して使用を続けることができます。 
2.2.6 タイムアウト (AAA) 2.1 で追加（英語） +

タイムアウトした場合（ユーザーの非活動状態が原因で）、プロセスの開始時にユーザーに警告するので、タイムアウトが存在していても驚くことはありません（または、20時間の非活動状態の後にのみタイムアウトするようにします）。

+ 		タイムアウトを理解する（英語）
+ +
+

注: ガイドライン 2.2: 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン2.3 — 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください

+ +

これは、変更しないとてんかんなどの症状のあるユーザーに発作を起こす可能性がある、または前庭障碍などの症状のあるユーザーに身体的反応（めまいなど）を引き起こす可能性があるコンテンツを意味します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.3.1 3回の閃光、またはしきい値を下回る (A)コンテンツに1秒間に3回以上の閃光を放つアスペクトが含まれていない、または閃光を放つコンテンツが許容できる閃光および赤色閃光のしきい値（英語）を下回っている。 
2.3.2 3回の閃光 (AAA)コンテンツには、1秒間に3回以上の閃光を放つアスペクトは含まれていません。 
2.3.3 インタラクションによるアニメーション (AAA) 2.1 で追加（英語）ユーザーがインタラクションによるアニメーションを無効にできるようにする（アニメーションが必須でない限り）。インタラクションによるアニメーションを理解する（英語）
+ +
+

注: ガイドライン 2.3: 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.4 — ナビゲート可能: ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する

+ +

このガイドラインの下での適合基準は、ユーザーが自分自身を指向し、サイトの現在のページや他のページで探しているコンテンツと機能を見つけることが期待できる方法に関連しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.4.1 ブロックのバイパス (A) +

繰り返される機能（会社のロゴやナビゲーションなど）を通り過ぎて、ユーザーがページにあるメインコンテンツや機能に直接スキップできるようにするメカニズムを提供するべきです。 これはしばしば、スキップリンク（"skip links"）を使用して達成されます — メインコンテンツにリンクする CSS によって隠されたリンクはページのソースのトップに置かれます。

+ +

見出しと意味論のコンテナの適切な構造（例えば、{{htmlelement("section")}}、{{htmlelement("aside")}} など）がナビゲートするために提供されている場合は、追加のスキップリンクは必要ありません。

+ 		スキップリンクのセクションを追加する必要があります。
2.4.2 ページタイトルを含める (A)各ウェブページには有益な {{htmlelement("title")}} を含めるべきです。 そのコンテンツは、ページのコンテンツや目的を説明しています。タイトルの追加を参照してください。
2.4.3 論理的なフォーカスの順序 (A)フォーカス可能なページ機能（例えば、リンク、ボタン、フォーム入力）の「タブ順序」は論理的に意味があり、そのページはまだ非晴眼者でもキーボードのユーザーでも使用可能であることを意味します。コントロールへのタブ移動に関する一般的なアドバイスについては、UI コントロールを参照してください。 要素を独特なレイアウトに配置する必要がある場合は、ソースの順序が適切であることを確認してから、配置などの CSS 機能を使用してレイアウトを扱うことをお勧めします。
2.4.4 リンクの目的（コンテキストにそった）（A）リンクの目的や行き先は、リンクテキストから、またはその周囲（例えば、周囲のテキスト）から決定することができます。 例外は、リンクの目的が全てのユーザーにとってあいまいな場合です（これに関する有用な説明については、一般的にユーザーにとってあいまい（英語）を参照してください）。わかりやすいテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。
2.4.5 複数のナビゲーションメカニズム (AA) +

ウェブサイト上のページを見つけるために少なくとも二つの一般的なナビゲーションメカニズム、例えば、ナビゲーションメニュー、パンくずリスト、サイト検索、サイトマップ、関連リンクのリストなどを提供するべきです。

+ +

これに対する唯一の例外は、ページがプロセスの1ステップである場合で、論理的には前後のステップへのリンクのみを持つべきです。

+ 		これらのメカニズムのほとんどは、単純な HTML 機能を使用して作成できます。 例えば、検索フィールド、ナビゲーションメニューの作成、ボタンとしてのリンクのスタイリングを参照してください。
2.4.6 見出しとラベル (AA)見出し（例えば、{{htmlelement("h2")}}）および {{htmlelement("label")}} 要素は、それらが説明していると思われるコンテンツおよびフォーム要素の目的を明確に説明しています。 +

UI コントロール、わかりやすいテキストラベル、見出しと段落の基本、<label> 要素を参照してください。

+ +

構造上、それらを簡単に区別できない場合を除き、見出しやラベルの重複は避けるべきです（例えば、「詳細情報」が複数ある場合）。

+
2.4.7 フォーカス可能な要素に対する可視フォーカス (AA)リンクやフォーム入力などのフォーカス可能な要素間をタブ移動するときは、どの要素に現在フォーカスがあるかを示す視覚的なインジケーターがあるはずです。 これは通常、デフォルトでは点線や青のアウトラインです（ブラウザ、プラットフォームなどによって異なります）が、CSS によって上書きすることができます。ネイティブなキーボード・アクセシビリティの使用を参照してください。
2.4.8 サイト内の場所 (AAA)複雑なサイトまたは一連のステップ内のページにいる場合は、パンくずリスト、サイトマップ、「Form page 2 of 10」といったテキストなど、サイト内の場所を示すインジケーターをユーザーに提示するべきです。 
2.4.9 リンクの目的（リンクのみ） (AAA)この基準は 2.4.4 に基づいており、AAA に準拠するためには、コンテキストから外れていてもリンクの目的やリンク先はリンクテキストのみから決定可能であるべきであると述べています。わかりやすいテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。
2.4.10 セクション見出し (AAA) +

便利な文書構造を作成するだけでなく、見出しも正確に記述し、コンテンツ領域を論理的なセクションに分割するべきです。

+ +

この基準は、一般的なウェブコンテンツの見出しとタイトルを指すことに注意してください（例えば、テキストコンテンツ内の見出し）。 ユーザーインターフェースの見出しとタイトルは、基準 4.1.2 で扱われる特別なケースです。

+ 		+

見出しと段落の基本を参照してください。

+
+ +
+

注: ガイドライン 2.4: ナビゲート可能：ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.5 — 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする

+ +

このガイドラインの適合基準は、ユーザーがキーボードやマウス以外のさまざまな入力方法（タッチスクリーン、音声、デバイスの動き、その他の入力デバイスを含む）を使用してデジタルテクノロジーと対話できることを保証します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.5.1 ポインタジェスチャー (A) 2.1 で追加（英語）ポインタで操作できる全ての機能は、シングルポイントのアクションで操作できます。 パスベースやマルチポイントのジェスチャーは、機能を操作するために必要ではありません。 例外があります。ポインタジェスチャーを理解する（英語）
2.5.2 ポインタキャンセル (A) 2.1 で追加（英語）シングルポインタを使用して操作できる機能については、次のうち少なくとも1つが当てはまります。 ダウンイベントなし、中止や元に戻す、アップリバーサル、必要不可欠。ポインタキャンセルを理解する（英語）
2.5.3 名前のラベル (A) 2.1 で追加（英語）表示可能なテキストラベルを含む各ユーザーインターフェイス・コンポーネントについて、アクセス可能な名前がラベルの表示可能なテキストと一致する（または含まれる）ことを確認します。名前のラベルを理解する（英語）
2.5.4 動きによる作動 (A) 2.1 で追加（英語）a）デバイスの動き（揺れ、傾きのような）、または b）デバイスのセンサー（カメラを含む）によって検出されたユーザーのジェスチャーによって引き起こされる可能性のある機能について、次の両方が当てはまることを確認します。 1) 動きによる作動を無効にすることができ、2) 機能をデバイスの動きやユーザーのジェスチャーを使用せずに動作させることができる。 例外があります。動きによる作動を理解する（英語）
2.5.5 ターゲットサイズ (AAA) 2.1 で追加（英語）アクション可能アイテムのタッチターゲットのサイズは、幅と高さの両方で少なくとも 44 CSS ピクセルにする必要があります。 例外があります。ターゲットサイズを理解する（英語）
2.5.6 同時入力メカニズム (AAA) 2.1 で追加（英語）タッチスクリーン、キーボード、マウス、音声コマンド、その他の入力デバイスを含むデジタルコンテンツと対話するときに、さまざまな入力モードを使用したり切り替えたりできることを確認します。 本質的な例外があります。同時入力メカニズムを理解する（英語）
+ +
+

注: ガイドライン2.5: 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/perceivable/index.html b/files/ja/web/accessibility/understanding_wcag/perceivable/index.html new file mode 100644 index 0000000000..ff6eae9cac --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/perceivable/index.html @@ -0,0 +1,357 @@ +--- +title: 知覚可能 +slug: Web/Accessibility/Understanding_WCAG/Perceivable +tags: + - Accessibility + - Principle 1 + - WCAG + - Web Content Accessibility Guidelines + - contrast + - different presentation + - text alternatives + - time-based media +translation_of: Web/Accessibility/Understanding_WCAG/Perceivable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の知覚可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 知覚可能とは、ユーザーが自分の感覚の1つ以上を使用して何らかの方法でそれを知覚できなければならないということです。

+ +
+

注: 知覚可能の W3C 定義とそのガイドラインおよび達成基準を読むには、原則 1: 知覚可能 — 情報とユーザーインターフェイス・コンポーネントが、ユーザーが認識できる方法で提示可能である必要があります（英語）を参照してください。

+
+ +

ガイドライン 1.1 — 非テキストコンテンツのための代替テキストの提供

+ +

ここで重要なのは、テキストならば障碍のある人が使用できる他の形式に変換できることです。 例えば、スクリーンリーダーで話させたり、ズームインしたり、点字ディスプレイに表示したりできます。 非テキストコンテンツとは、画像、音声、動画などのマルチメディアを指します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.1.1 同等のテキストを提供する (A)意味のある内容を伝える全ての画像は、適切な代替テキストを与えられるべきです。代替テキスト。
複雑な画像や図表には、同じページ上またはリンク先のいずれかにアクセス可能な代替手段を用意するべきです。 {{htmlattrxref("longdesc","img")}} 属性ではなく通常のリンクを使用してください。 +

テキストの説明や、アクセス可能なデータ表がうまくいくかもしれません（HTML 表の高度な機能とアクセシビリティを参照）。 longdesc 反対論については、その他の代替テキストの仕組みも参照してください。

+
マルチメディアコンテンツ（例えば、音声や動画）は、少なくともわかりやすい識別が利用できるべきです（例えば、キャプションまたは同様のもの）。 +

静的キャプションの選択肢については代替テキストを、その他の選択肢についてはオーディオトランスクリプト、 ビデオテキストトラック、その他のマルチメディアコンテンツを参照してください。

+
フォーム要素やボタンのような UI コントロールには、その目的を説明するテキストラベルを付けるべきです。ボタンは簡単です — ボタンのテキストがボタンの機能を説明していることを確認してください（例えば、<button>画像のアップロード</button>）。 他の UI コントロールの詳細については、UI コントロールを参照してください。
支援技術には見えない方法で、装飾的な（コンテンツではない）画像、動画などを実装すると、ユーザーを混乱させません。 +

装飾画像は CSS 背景画像を使用して実装する必要があります（背景を参照）。 {{htmlelement("img")}} 要素を介して画像を含める必要がある場合は、空白の alt（alt=""）を付けます。 そうしないと、スクリーンリーダーがファイルパスなどを読み上げようとする可能性があります。

+ +

自動再生する背景の動画や音声を含める場合は、できるだけ目立たないようにします。 コンテンツのように見せたり鳴らさないでください。 また、無効にするコントロールを提供してください。 理想的には、それをまったく含めないでください。

+
+ +
+

注: ガイドライン1.1: 代替テキスト（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.2 — タイムベースト・メディアのための代替テキストの提供

+ +

タイムベースト・メディアは、持続期間を有するマルチメディア、すなわち音声および動画を指します。 また、それらの音声や動画が既存のテキストコンテンツの代替を兼ねる場合は、別の代替テキストを提供する必要はありません。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.2.1 記録済みの音声のみおよび動画のみのコンテンツに代わるものを提供する (A)トランスクリプトは、録音済みの音声のみのメディアに提供するべきで、トランスクリプトまたは音声解説は、録画済みの動画のみのメディア（すなわち、サイレントビデオ）に提供するべきです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。 音声解説のチュートリアルはまだありません。
1.2.2  ウェブベースの動画にキャプションを付ける (A)ウェブ上に表示される動画（例えば、HTML5 動画）には、キャプションを付けるべきです。 これは、動画の音声部分が聞こえない人々のためのものです。HTML5 動画のキャプションについてはビデオテキストトラックを、その他のテクノロジについてはその他のマルチメディアコンテンツを参照してください。 独自の字幕とクローズドキャプションを追加する（YouTube、英語）も参照してください。
1.2.3 ウェブベースの動画にテキストトランスクリプトまたは音声解説を提供する (A)ウェブ上に提示される動画（例えば、HTML5 動画）のためのテキストトランスクリプトまたは音声解説を提供するべきです。 これは、動画の視覚的な部分を見ることができず、音声だけではコンテンツ全体を取得できない人々のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。 音声解説のチュートリアルはまだありません。
1.2.4 生音声にキャプションを付ける (AA)音声を含んだ全ての生のマルチメディア（ビデオ会議、生音声放送など）には、同期したキャプションを付けるべきです。 
1.2.5 録画済み動画の音声解説を提供する (AA)音声解説は、録画済み動画に対して提供するべきですが、既存の音声が動画によって表現された完全な意味を伝えない場合に限ります。 
1.2.6 録音済み音声と同等の手話を提供する (AAA)音声を含んだ記録済みコンテンツには、同等の手話動画を提供するべきです。 
1.2.7 音声解説付きの拡張動画を提供する (AAA)動画のタイミングの問題で音声解説を提供できない場合（例えば、音声解説を挿入するコンテンツに適切な間がない場合）（1.2.5 を参照）、挿入された間（と音声解説）を含んだ動画の代替バージョンを提供するべきです。 
1.2.8 記録済みメディアの代替を提供する (AAA)動画を特徴とする全てのコンテンツには、わかりやすいテキストトランスクリプトを提供する必要があります。 例えば、あなたが見ている映画のスクリプトなどです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。
1.2.9 生音声用のトランスクリプトを提供する (AAA)放送されている生音声のコンテンツのために、例えば、あなたが聞いている演劇やミュージカルのスクリプトのような説明文を提供するべきです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。
+ +
+

注: ガイドライン 1.2: タイムベースト・メディア: タイムベースト・メディアに代わるものを提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.3 — さまざまな方法で提示できるコンテンツの作成

+ +

このガイドラインは、異なるニーズに柔軟に対応して、コンテンツがユーザーによってさまざまな方法で消費される能力について言及しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.3.1 情報と関係 (A) +

いかなるコンテンツ構造 — またはコンテンツ間に作られた視覚的関係 — もまた、プログラム的に決定されるか、またはテキストの説明から推論され得ます。 これが関連する主な状況は次のとおりです。

+ +
    +
  • テキストラベルとそれが説明するフォーム要素は、{{htmlelement("label")}} 要素を使用して明確に関連付けられて、スクリーンリーダーなどが拾うことができます。
    • +
  • 画像の代替テキスト — コンテンツ画像には、その画像の内容を明確に説明するテキストが含まれているべきです。 これは、プログラム的に関連付けることができます（例えば、{{htmlattrxref("alt","img")}} テキスト）。 そうでない場合は、関連付けるのは簡単です（例えば、それを説明し、そのすぐ隣に置きます）。 これは、たとえあなたが画像を見ることができなくても、完全な意味がまだ推測できることを意味するはずです。
    • +
  • リスト — リスト項目の順序が重要で、順序付きリストを使用するべき場合（{{htmlelement("ol")}}）。
    • +
+ 		+

HTML: アクセシビリティの基礎全体には、これに関する情報が満載されていますが、特に優れた意味論、UI コントロール、代替テキストを参照するべきです。

+
1.3.2 重要なコンテンツの順序 (A)賢明で論理的な読み上げ順序は、たとえそれが独特な方法で視覚的に提示されていても、どんな内容に対しても決定しやすいはずです。 マークアップに関係なく、CSS を使用して独特なレイアウトスタイルを作成することで、正しい意味論的要素（見出し、段落など）を使用して順序を明確にするべきです。繰り返しますが、HTML: アクセシビリティの基礎を参照してください。
1.3.3 感覚的性質 (A) +

コントロールを操作したり、コンテンツを理解したりするための指示は、単一の感覚には依存しません — これは、その感覚に関連する障碍を持つ人々、またはその感覚をサポートしていないデバイスにとってアクセスできないことを証明するかもしれません。 だから、例えば、

+ +
    +
  • 「続けるために丸いボタンをクリックしてください」 — それがあなたが押す必要があるボタンであることは明らかであるように、ボタンは明確にラベル付けされるべきです。 複数のボタンがある場合は、それらの機能を区別するために全てが明確にラベル付けされていることを確認してください。
    • +
  • 「ガイダンスに関する音声の説明を聞く」 — これは明らかに問題があります — 音声は聴覚障碍のある人にはアクセスできないのに対して、テキストは読むことができるだけでなく、必要に応じてスクリーンリーダーによって話させることもできます。
    • +
  • 「メニューを表示するには、画面の右側からスワイプ」 — 一部のユーザーは、障碍のためや、デバイスがタッチをサポートしていないために、画面をスワイプできない可能性があります。 キーボードショートカットや、キーボードなどの手段でアクティブにできるボタンなどの代替手段を提供する必要があります。
    • +
+ +
+

注: 色だけで指示を伝えることは関連していますが、異なるガイドラインでカバーされています — 1.4.1。

+
+ 		 
1.3.4 オリエンテーション (AA) 2.1 で追加（英語）特定のディスプレイの向きが重要でない限り、コンテンツの表示と操作はポートレートやランドスケープなどの単一のディスプレイの向きに制限されません。 +

オリエンテーションを理解する（英語）

+
1.3.5 入力の目的の識別 (AA) 2.1 で追加（英語） +

 

+ +

53個の入力フィールド（英語）のリストに従って、プログラム的にフィールドの目的を識別してください。

+ 		入力の目的の識別を理解する（英語）
1.3.6 目的の識別 (AAA) 2.1 で追加（英語）マークアップ言語を使用して実装されたコンテンツでは、ユーザーインターフェイス・コンポーネント、アイコン、およびリージョンの目的はプログラム的に決定できます。目的の識別を理解する（英語）
+ +
+

注: ガイドライン 1.3: 適応可能: 情報や構造を失うことなくさまざまな方法で提示できるコンテンツを作成する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.4: 前景と背景の分離を含め、ユーザーがコンテンツを見たり聞いたりしやすくする

+ +

このガイドラインは、コアコンテンツが背景や他の装飾から識別しやすいことを確認することに関するものです。 典型的な例は、色で（色のコントラストと指示を伝えるための色の使い方の両方が）、他の状況でも適用されます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.4.1 色の使い方 (A) +

色だけを頼りにして情報を伝えるべきではありません — 例えば、フォームでは、必須フィールドに純粋に色（赤など）で印を付けることは絶対にしないでください。 代わりに（または同様に）、「必須」というラベルの付いたアスタリスクのようなものがより適切です。

+ 		色とそのコントラストおよび複数のラベルを参照してください。
1.4.2 音声コントロール (A)3 秒以上再生される音声の場合は、音声や動画の再生と一時停止、および音量のミュートや調整を行うためのアクセス可能なコントロールを用意する必要があります。ビデオプレーヤーのスタイリングの基本に示すように、ネイティブの <button> を使用してアクセス可能なキーボードコントロールを提供します。
1.4.3 最低限のコントラスト (AA) +

背景と前景のコンテンツの間の色のコントラストは、読みやすさを確実なものとするための最低限のレベルであるべきです。

+ +
    +
  • テキストとその背景のコントラスト比は少なくとも 4.5:1 であるべきです。
    • +
  • 見出し（またはそれよりも大きい）テキストの比は、少なくとも 3:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
    • +
+ 		色とそのコントラストを参照してください。
1.4.4 テキストのサイズ変更 (AA)テキストサイズが2倍になったときに、ページは読みやすく使えるべきです。 つまり、デザインはレスポンシブであるべきで、テキストサイズを大きくしてもコンテンツにアクセス可能であることを意味します。 
1.4.5 テキストの画像 (AA)テキストが仕事をするようなコンテンツを提示するために画像を使用してはいけません。 例えば、画像がほとんどテキスト形式の場合、画像だけでなくテキストも使用して表現できます。 
1.4.6 強化されたコントラスト (AAA) +

これは、基準 1.4.3 に従い、その上に構築されます。

+ +
    +
  • テキストとその背景のコントラスト比は少なくとも 7:1 であるべきです。
    • +
  • 見出し（またはそれよりも大きい）テキストの比は少なくとも 4.5:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
    • +
+ 		 
1.4.7 背景音声は小さいか無い (AAA)話し言葉を主な特徴とする録音済みの音声記録は、背景雑音を最小限に抑えるべきため、コンテンツを簡単に理解できます。 
1.4.8 視覚的表現 (AAA) +

テキストコンテンツの表現では、次のことが当てはまります。

+ +
    +
  • 前景色と背景色は、ユーザーが選択できるようにするべきです。
    • +
  • テキストブロックは、読みやすくするために、80 文字（またはグリフ）以下の幅にしてください。
    • +
  • テキストは、両端揃えにするべきではありません（例えば、{{cssxref("text-align","text-align: justify;")}}）。
    • +
  • 行の高さは、段落内ではテキストサイズの 1.5 倍以上（例えば、{{cssxref("line-height","line-height: 1.5;")}}）、段落間ではテキストサイズの 2.25 倍以上（例えば、{{cssxref("padding","padding: 2.25rem;")}}）にするするべきです。
    • +
  • テキストサイズが2倍になったときに、コンテンツのスクロールが必要になるべきではありません。
    • +
+ 		 
1.4.9 テキストの画像（例外なし） (AAA)テキストは、純粋に装飾である（すなわち、それがいかなる内容も伝えない）か、または他の方法で提示することができない限り、画像の一部として提示するべきではありません。 
1.4.10 リフロー (AA) 2.1 で追加（英語） +
    +
  • 右から左への言語（英語など）や、左から右への言語（アラビア語など）の水平スクロール無し。
    • +
  • 上から下への言語（日本語など）の垂直スクロール無し。
    • +
  • 使用法や意味のために2次元レイアウトを必要とするコンテンツの部分を除く（大きなデータ表のように）。
    • +
+ 		リフローを理解する（英語）
1.4.11 テキスト以外のコントラスト (AA) 2.1 で追加（英語）ユーザーインターフェイス・コンポーネントとグラフィックオブジェクトの最低限のカラーコントラスト比は 3:1 です。テキスト以外のコントラストを理解する（英語）
1.4.12 テキストの間隔 (AA) 2.1 で追加（英語） +

次のスタイルを適用しても、コンテンツや機能が失われることはありません。

+ +
    +
  • 行の高さ（行間）をフォントサイズの 1.5 倍以上にします。
    • +
  • 後続の段落との間隔をフォントサイズの 2 倍以上にします。
    • +
  • 文字間隔（トラッキング）をフォントサイズの 0.12 倍以上にします。
    • +
  • 単語間隔をフォントサイズの 0.16 倍以上にします。
    • +
+ 		テキストの間隔を理解する（英語）
1.4.13 ホバーまたはフォーカスにおけるコンテンツ (AA) 2.1 で追加（英語） +

追加のコンテンツがホバーやキーボードフォーカスに連動して現れたり消えたりします。 この達成基準では、満たす必要がある次の3つの条件を指定します。

+ +
    +
  • 却下可能（閉じたり取り除くことが可能）。
    • +
  • ホバリング可能（追加のコンテンツは、ポインタが上にあるときは消えません）。
    • +
  • 永続的（追加のコンテンツは、ユーザーの操作なしでは消えません）。
    • +
+ 		ホバーまたはフォーカスにおけるコンテンツを理解する（英語）
+ +
+

注: ガイドライン 1.4: 識別可能: 背景から前景を分離するなど、ユーザーがコンテンツを見やすく、聞き取りやすくする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/robust/index.html b/files/ja/web/accessibility/understanding_wcag/robust/index.html new file mode 100644 index 0000000000..18f492e218 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/robust/index.html @@ -0,0 +1,85 @@ +--- +title: 堅牢 +slug: Web/Accessibility/Understanding_WCAG/Robust +tags: + - Accessibility + - HTML + - Parsing + - Principle 4 + - Robust + - Role(2) + - Validation + - WAI-ARIA + - WCAG + - Web Content Accessibility Guidelines + - value +translation_of: Web/Accessibility/Understanding_WCAG/Robust +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の堅牢原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 堅牢とは、支援技術を含む多種多様なユーザーエージェントによって確実に解釈されることができるほど十分に堅牢でなければならないと述べています。 これは通常、ウェブ標準に準拠し、厳密にテストすることによって実現できます。

+ +
+

.注: W3C の堅牢の定義とそのガイドラインおよび達成基準を読むには、原則 4: 堅牢 — コンテンツは、支援技術を含むさまざまなユーザーエージェントによって確実に解釈されるよう十分に堅牢である必要があります（英語）を参照してください。

+
+ +

ガイドライン 4.1 — 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する

+ +

このガイドラインは、現在のユーザーエージェント（例えば、ブラウザ）だけでなく将来のものともコンテンツをできる限り互換性を持たせることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
4.1.1 解析 (A) +

コンテンツは、ブラウザやスクリーンリーダーのような他のユーザーエージェントによって正常に解析されるように、整形式（well-formed）にするべきです。

+ +

この基準に合格するには、HTML ができるだけ妥当（valid）であることを確認してください。 マークアップを検証するために W3C の検証ツール（英語）を使用してください。

+ 		実用的なガイドについては、HTML のデバッグを参照してください。
4.1.2 名前、役割、値 (A) +

ユーザインターフェース・コンポーネント（例えば、フォーム入力、ボタン、リンクなど）の名前と役割（role、ロール）はプログラム的に決定可能であるべきです。

+ +

意図された目的のために意味論の要素を正しく使用するとき、この基準に自動的に合格するはずです。 カスタムコンポーネントをスクリプト化するときは、例えば、晴眼でマウスのユーザーだけでなく、スクリーンリーダーのユーザー、キーボードのみのユーザーなども、コントロールが解釈されて意図したとおりに使用できるようにするために、WAI-ARIA のロールおよびその他の機能を使用する必要があります。

+ 		HTML: アクセシビリティの基礎と WAI-ARIA の基本を参照してください。
4.1.3 ステータスメッセージ (AA) 2.1 で追加（英語） +

支援技術のユーザーは、ページに追加された新しいステータスメッセージを認識します。

+ 		ステータスメッセージを理解する（英語）
+ +
+

注: ガイドライン 4.1: 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/understandable/index.html b/files/ja/web/accessibility/understanding_wcag/understandable/index.html new file mode 100644 index 0000000000..43a97f8b90 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/understandable/index.html @@ -0,0 +1,259 @@ +--- +title: 理解可能 +slug: Web/Accessibility/Understanding_WCAG/Understandable +tags: + - Accessibility + - HELP + - Language + - Navigation + - Principle 3 + - Text + - Understandable + - WCAG + - Web Content Accessibility Guidelines + - abbreviations + - consistency + - error messages + - form validation + - labels + - slang +translation_of: Web/Accessibility/Understanding_WCAG/Understandable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の理解可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法について実用的なアドバイスを提供します。 理解可能とは、情報とユーザーインターフェースの操作が理解可能でなければならないと述べています。

+ +
+

注: 理解可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 3: 理解可能 — 情報とユーザーインターフェイスの操作が理解可能でなければならない（英語）を参照してください。

+
+ +

ガイドライン 3.1 — 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする

+ +

このガイドラインは、テキストコンテンツをできるだけわかりやすくすることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.1.1 ページの言語 (A)各ウェブページのデフォルトの人間の言語はコードで検出できるべきです。 これは、読者が自分に合った言語で書かれたページにアクセスしたことを確認するなどの目的に不可欠です。 これを実現する最も簡単な方法は、ページの {{htmlelement("html")}} 要素に {{htmlattrxref("lang")}} 属性を設定して、ページが書かれている言語を最もよく表す言語コードをそれに与えることです。文書の第一言語の設定を参照してください。
3.1.2 パーツの言語 (AA) +

ページのコンテンツに第一言語とは異なる言語の単語や語句が含まれている場合は、問題の用語を囲む要素（例えば、意味論の要素が利用できない場合は {{htmlelement("span")}}）に {{htmlattrxref("lang")}} 属性を使用して適切な言語を設定します。

+ +

言語に関係なく同じである単語や語句に異なる言語を設定する必要はありません（例えば、固有名詞、特定の言語の一部ではない専門用語など）。

+ 		 
3.1.3 珍しい単語 (AAA)専門用語、業界用語、または慣用句やスラングが使用されている場合は、そのような語句や単語に対して定義を提供するべきです。 サイトでは、そのような言葉や用語の定義を含む用語集を、それらが現れたときにリンクできるように提供するか、少なくとも周囲のテキストやページ下部の説明リストのどこかに定義を提供するべきです。 
3.1.4 略語 (AAA) +

略語が使用されている場合は、それらの展開や、必要に応じて定義を提供するべきです。

+ +

{{htmlelement("abbr")}} 要素は、略語の展開を提供するための推奨される方法と考えられています — 展開を含む {{htmlattrxref("title")}} 属性を取り、略語をマウスオーバーしたとき、これが表示されます。 ただし、title の内容はキーボードからはアクセスできず、スクリーンリーダーによって確実に読み上げられるわけでもありません。 これを扱うためのより良い方法は、この場合も先と同様に略語の展開と説明を含む用語集のページへのリンクを提供するか、少なくともコンテキスト内の周囲のテキストにそれらを含めることです。

+ 		略語を参照してください。
3.1.5 読解力 (AAA) +

前期中等教育レベル（通常11〜14歳前後の子供）より高い読解力を必要とするテキストが提供される場合は、それを読むことができない人々を支援する補足説明資料を提供するか、あるいは前期中等教育レベルで書かれた代替バージョンを提供します。

+ +

これは、全ての主題が全ての人に理解されるべきであるという意味ではありませんが、書くスタイルは全ての人にアクセス可能であるべきです。 そうしない正当な理由や（例えば、詩的効果のための代替的なスタイル）、厳密なスタイルで記述する必要（例えば、W3C の仕様）がない限り、プログラミングチュートリアルのような技術文書でさえも、全てのコンテンツを前期中等教育レベルで書くことをお勧めします。

+ 		 
3.1.6 発音 (AAA) +

コンテンツを完全に理解するために必要な単語の発音へのアクセスをユーザーに与えるためのメカニズムを提供するべきです。

+ +

HTML5 の {{htmlelement("audio")}} 要素を使用して、正しい発音を含む音声ファイルを読者が再生できるようにするコントロールを作成できます。 そして、辞書のエントリーと同じように難しい言葉の後にテキストの発音ガイドを含めるのも理にかなっています。

+ 		+

動画と音声のコンテンツ、および英語辞書の発音ガイド（英語）を参照してください。

+
+ +
+

注: ガイドライン 3.1: 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 3.2 — 予測可能: ウェブページを予測可能な方法で表示して操作させる

+ +

このガイドラインは、ユーザーインターフェースを直感的でわかりやすくすることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.2.1 フォーカス時 (A) +

コントロールや他のページ機能がフォーカスを受けたときに、ユーザーが混乱したり迷ったりするような方法でコンテキストを変更するべきではありません。

+ +

これは賢明なデザインの問題です — 人々はインターフェースによって驚かされることを望みません。 彼らは物事が直感的で期待通りに振る舞うことを望みます。 例えば、ナビゲーションメニューのオプションにフォーカスを置いても、表示されたページは変わりません — 表示が変わる前にアクティブにする必要があります。

+ 		{{domxref("GlobalEventHandlers.onfocus")}} には、役に立つ情報がいくつか含まれています。 役に立つ実装のアイデアについては、キーボード・アクセシビリティを取り戻すを参照してください。
3.2.2 入力時 (A) +

データがコントロールに入力されたとき、または設定が変更されたときに、コンテキストが予期せずに変更されるべきではありません。 差し迫った変更が発生する前に、ユーザーに警告や通知をする必要があります。

+ +

繰り返しますが、賢明なデザインを実装するべきです。 例えば、ボタンを押してアプリケーションが現在のビューを終了すると、ユーザーは必要に応じて作業内容を保存するかなど、この操作の確認を求められるべきです。

+ 		{{domxref("GlobalEventHandlers.oninput")}} はここで役に立ちます。
3.2.3 一貫したナビゲーション (AA) +

ナビゲーションのメニューやコントロールのスタイルと配置は、ウェブページの異なるページやビューの間で一貫しているべきで、例えば、新しい項目が追加されたとしても、既存の項目は同じ順序で現れるべきです。 ユーザーが変更を始めた場合、例えば、ナビゲーションのために異なる配色や位置を選択すると、それらの選択は全てのページにわたって尊重されるべきです。

+ +

繰り返しますが、賢明なデザイン — 全てのページやビューでナビゲーションコントロールを同じにします。

+ 		モダンなレイアウトのマークアップについては、ページレイアウトを参照してください。 便利なアクセス可能なナビゲーションメニューの例については、ボタンとしてのリンクのスタイリングも参照してください。
3.2.4 一貫した識別 (AA) +

同じ機能を持つコントロールやコンポーネントは、異なるページやビューでも同じように識別されるべきです。 例えば、世界旅行サイトの全てのページに表示される通貨換算機は、意味論的にもラベルの観点からもまったく同じであるべきです。

+ +

繰り返しますが、賢明なデザイン！

+ 		「ラベル」とは、テキストコンテンツ内の説明的な情報、または HTML フォームのラベルのことです。 詳細については、わかりやすいテキストラベルを参照してください。
3.2.5 要求に応じた変更 (AAA) +

ユーザーを混乱させたり、迷わせたりする可能性があるコンテキストの変更は、ユーザーから要求された場合にのみ行われるべきか、あるいは、ユーザーはそれらをオフにできるべきです。

+ +

現在のビュー（例えば、コンテンツやコントロール）を大幅に変更するものが必要な場合は、変更をいつ実行するかをユーザーに制御させます（例えば、どのページを表示するか、いつギャラリーの次の写真に進むか...）。

+ +

ページに回転木馬のようなものが必要な場合は、自動的に進まないようにするオプションを提供します。 可能であれば、そのような機能を避ける方が良いでしょう。

+ 		 
+ +
+

注: ガイドライン 3.2: 予測可能: ウェブページを予測可能な方法で表示して操作させる（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 3.3 — 入力支援: ユーザーが間違いを避けて修正できるようにする

+ +

このガイドラインは、必要なときにユーザーが正しい情報を間違いを最小限にとどめて入力できるように手助けすることを中心にしています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.3.1 エラーの識別 (A) +

ユーザーがフォームに入力したりオプションを選択したりするときに検出したエラーは、エラーに関連するフォームコントロールと共に、ユーザーに明確に報告するべきです。

+ +

状況に最適なものであれば、HTML5 フォームの検証機能や JavaScript を使用して、クライアント側のエラー検出と処理を実装することをお勧めします。 エラーを検出したら、ユーザーが入力を修正するのを助けるために、直観的なエラーメッセージをフォーム入力の横に表示するべきです。 スクリーンリーダーのユーザーの場合は、ARIA のライブリージョンを使用して、ページ上の変更についてユーザーに警告することができます。

+ +
+

注: サーバー側の検証は、クライアント側の検証と同時に常に使用するべきです。 クライアント側の検証は、無効にしたり回避したりするのが簡単すぎるため、単独では信頼できません。

+
+ 		包括的な検証情報についてはフォームデータの検証を、ライブリージョンに関する情報については WAI-ARIA: 動的コンテンツの更新を参照してください。
3.3.2 ラベルや指示 (A) +

データ入力が必要な場合は、明確な指示を提供するべきです。 単純な指示やプロンプトが必要な場合は、名前や年齢のような単一入力には {{htmlelement("label")}} 要素を使用したり、（生年月日や住所の要素のような）複数を一緒にした入力には {{htmlelement("label")}} と {{htmlelement("fieldset")}} / {{htmlelement("legend")}} を組み合わせて使用できます。

+ +

より複雑な説明が必要な場合は、常に説明段落を含めることも、フォームをより直感的にすることを試みる必要があるかもしれません。

+ 		わかりやすいテキストラベルと便利な例については HTML フォームの作成方法を参照してください。
3.3.3 エラーに対する提案 (AA) +

エラーが検出され、修正の提案が判明したら、セキュリティ上の問題（例えば、パスワード入力時）やコンテキスト上の問題（例えば、クイズアプリでの回答時）が発生しない限り、ユーザーにこれらの情報を提供してください（例えば、ユーザーが既に選らんだことがあるユーザー名についての選択肢の提案）。

+ +

このような場合、これが適切であれば、おそらく JavaScript とサーバー側の機能の組み合わせを使用して、エントリが正しいかどうかを確認し、正しくない場合は、ユーザーに実行可能な提案を提示できます。 そのような提案は、エラーメッセージのようなコンテキストの中で有用に表示されるべきです（3.3.1 を参照）。

+ 		まだチュートリアルの提案はありません。
3.3.4 エラー防止（法務、財務、データ） (AA) +

機密データの入力に関わるフォーム（法的契約、電子商取引、個人データなど）の場合は、少なくとも次のいずれかに該当するべきです。

+ +
    +
  • 提出は可逆的です。
    • +
  • データにエラーがないかチェックされ、ユーザーにはエラーを修正する機会が与えられます。
    • +
  • 最終提出の前に情報を確認し修正するためのメカニズムが利用可能です。
    • +
+ 		+

可逆的 — データを入力できるビューには、必要に応じてエントリを編集または削除することもできる同等のビューを提供します（例えば、Django ウェブフレームワークを参照）。

+ +

データのチェック — 3.3.1 で説明したように、クライアント側とサーバー側の検証を組み合わせてエラーを検出し、入力を修正できるようにユーザーに役立つメッセージを表示するべきです。

+ +

確認と修正 — 必要に応じて、（製品の購入のような）一連のフォームフィールドに入力するタスクを実行した後、ユーザーに確認画面を表示して入力内容を見直し、正しくないものは修正できるようにするべきです。 このパターンは、Amazon のような電子商取引サイトで一般的に使用されています。

+
3.3.5 状況依存ヘルプが利用可能 (AAA)フォームの完成と提出を助けるために、コンテキストの中で指示と他の適切な合図を提供してください。これは実際には単に 3.3.1 や他の同様の基準に基づいていますが、もっと徹底的なコンテキスト上のヘルプ情報とサービスを必要とします。 例えば、各ページのヘルプページまたはサービスへの専用リンクを提供し、正常に完了したらどのように見えるか示す例を提供します。
3.3.6 エラー防止（全て） (AAA)この原則は 3.3.4 に基づいており、機密データを含むものだけでなく、全てのユーザ入力状況に要件を拡張しています。繰り返しますが、3.3.4 を参照してください。
+ +
+

注: ガイドライン 3.3: 入力支援: ユーザーが間違いを避けて修正できるようにする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

-- cgit v1.2.3-54-g00ecf