diff options
Diffstat (limited to 'files/ja/web/accessibility/understanding_wcag/understandable')
| -rw-r--r-- | files/ja/web/accessibility/understanding_wcag/understandable/index.html | 259 |
1 files changed, 259 insertions, 0 deletions
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 +--- +<p class="summary">この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の<strong>理解可能</strong>原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法について実用的なアドバイスを提供します。 理解可能とは、情報とユーザーインターフェースの操作が理解可能でなければならないと述べています。</p> + +<div class="note"> +<p><strong>注</strong>: 理解可能の W3C の定義とそのガイドラインおよび達成基準を読むには、<a href="https://www.w3.org/TR/WCAG21/#understandable">原則 3: 理解可能 — 情報とユーザーインターフェイスの操作が理解可能でなければならない</a>（英語）を参照してください。</p> +</div> + +<h2 id="Guideline_3.1_—_Readable_Make_text_content_readable_and_understandable" name="Guideline_3.1_—_Readable_Make_text_content_readable_and_understandable">ガイドライン 3.1 — 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする</h2> + +<p>このガイドラインは、テキストコンテンツをできるだけわかりやすくすることに焦点を当てています。</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">達成基準</th> + <th scope="col">基準への準拠方法</th> + <th scope="col">実用的なリソース</th> + </tr> + </thead> + <tbody> + <tr> + <td>3.1.1 ページの言語 (A)</td> + <td>各ウェブページのデフォルトの人間の言語はコードで検出できるべきです。 これは、読者が自分に合った言語で書かれたページにアクセスしたことを確認するなどの目的に不可欠です。 これを実現する最も簡単な方法は、ページの {{htmlelement("html")}} 要素に {{htmlattrxref("lang")}} 属性を設定して、ページが書かれている言語を最もよく表す言語コードをそれに与えることです。</td> + <td><a href="/ja/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML#Setting_the_primary_language_of_the_document">文書の第一言語の設定</a>を参照してください。</td> + </tr> + <tr> + <td>3.1.2 パーツの言語 (AA)</td> + <td> + <p>ページのコンテンツに第一言語とは異なる言語の単語や語句が含まれている場合は、問題の用語を囲む要素（例えば、意味論の要素が利用できない場合は {{htmlelement("span")}}）に {{htmlattrxref("lang")}} 属性を使用して適切な言語を設定します。</p> + + <p>言語に関係なく同じである単語や語句に異なる言語を設定する必要はありません（例えば、固有名詞、特定の言語の一部ではない専門用語など）。</p> + </td> + <td> </td> + </tr> + <tr> + <td>3.1.3 珍しい単語 (AAA)</td> + <td>専門用語、業界用語、または慣用句やスラングが使用されている場合は、そのような語句や単語に対して定義を提供するべきです。 サイトでは、そのような言葉や用語の定義を含む用語集を、それらが現れたときにリンクできるように提供するか、少なくとも周囲のテキストやページ下部の<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/Advanced_text_formatting#Description_lists">説明リスト</a>のどこかに定義を提供するべきです。</td> + <td> </td> + </tr> + <tr> + <td>3.1.4 略語 (AAA)</td> + <td> + <p>略語が使用されている場合は、それらの展開や、必要に応じて定義を提供するべきです。</p> + + <p>{{htmlelement("abbr")}} 要素は、略語の展開を提供するための推奨される方法と考えられています — 展開を含む {{htmlattrxref("title")}} 属性を取り、略語をマウスオーバーしたとき、これが表示されます。 ただし、<code>title</code> の内容はキーボードからはアクセスできず、スクリーンリーダーによって確実に読み上げられるわけでもありません。 これを扱うためのより良い方法は、この場合も先と同様に略語の展開と説明を含む用語集のページへのリンクを提供するか、少なくともコンテキスト内の周囲のテキストにそれらを含めることです。</p> + </td> + <td><a href="/ja/docs/Learn/HTML/Introduction_to_HTML/Advanced_text_formatting#Abbreviations">略語</a>を参照してください。</td> + </tr> + <tr> + <td>3.1.5 読解力 (AAA)</td> + <td> + <p>前期中等教育レベル（通常11〜14歳前後の子供）より高い読解力を必要とするテキストが提供される場合は、それを読むことができない人々を支援する補足説明資料を提供するか、あるいは前期中等教育レベルで書かれた代替バージョンを提供します。</p> + + <p>これは、全ての主題が全ての人に理解されるべきであるという意味ではありませんが、書くスタイルは全ての人にアクセス可能であるべきです。 そうしない正当な理由や（例えば、詩的効果のための代替的なスタイル）、厳密なスタイルで記述する必要（例えば、W3C の仕様）がない限り、プログラミングチュートリアルのような技術文書でさえも、全てのコンテンツを前期中等教育レベルで書くことをお勧めします。</p> + </td> + <td> </td> + </tr> + <tr> + <td>3.1.6 発音 (AAA)</td> + <td> + <p>コンテンツを完全に理解するために必要な単語の発音へのアクセスをユーザーに与えるためのメカニズムを提供するべきです。</p> + + <p>HTML5 の {{htmlelement("audio")}} 要素を使用して、正しい発音を含む音声ファイルを読者が再生できるようにするコントロールを作成できます。 そして、辞書のエントリーと同じように難しい言葉の後にテキストの発音ガイドを含めるのも理にかなっています。</p> + </td> + <td> + <p><a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Video_and_audio_content">動画と音声のコンテンツ</a>、および<a href="http://www.oxfordlearnersdictionaries.com/us/about/pronunciation_english.html">英語辞書の発音ガイド</a>（英語）を参照してください。</p> + </td> + </tr> + </tbody> +</table> + +<div class="note"> +<p><strong>注</strong>: <a href="https://www.w3.org/TR/WCAG21/#readable">ガイドライン 3.1: 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする</a>（英語）に関する WCAG の説明も参照してください。</p> +</div> + +<h2 id="Guideline_3.2_—_Predictable_Make_Web_pages_appear_and_operate_in_predictable_ways" name="Guideline_3.2_—_Predictable_Make_Web_pages_appear_and_operate_in_predictable_ways">ガイドライン 3.2 — 予測可能: ウェブページを予測可能な方法で表示して操作させる</h2> + +<p>このガイドラインは、ユーザーインターフェースを直感的でわかりやすくすることに焦点を当てています。</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">達成基準</th> + <th scope="col">基準への準拠方法</th> + <th scope="col">実用的なリソース</th> + </tr> + </thead> + <tbody> + <tr> + <td>3.2.1 フォーカス時 (A)</td> + <td> + <p>コントロールや他のページ機能がフォーカスを受けたときに、ユーザーが混乱したり迷ったりするような方法でコンテキストを変更するべきではありません。</p> + + <p>これは賢明なデザインの問題です — 人々はインターフェースによって驚かされることを望みません。 彼らは物事が直感的で期待通りに振る舞うことを望みます。 例えば、ナビゲーションメニューのオプションにフォーカスを置いても、表示されたページは変わりません — 表示が変わる前にアクティブにする必要があります。</p> + </td> + <td>{{domxref("GlobalEventHandlers.onfocus")}} には、役に立つ情報がいくつか含まれています。 役に立つ実装のアイデアについては、<a href="/ja/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">キーボード・アクセシビリティを取り戻す</a>を参照してください。</td> + </tr> + <tr> + <td>3.2.2 入力時 (A)</td> + <td> + <p>データがコントロールに入力されたとき、または設定が変更されたときに、コンテキストが予期せずに変更されるべきではありません。 差し迫った変更が発生する前に、ユーザーに警告や通知をする必要があります。</p> + + <p>繰り返しますが、賢明なデザインを実装するべきです。 例えば、ボタンを押してアプリケーションが現在のビューを終了すると、ユーザーは必要に応じて作業内容を保存するかなど、この操作の確認を求められるべきです。</p> + </td> + <td>{{domxref("GlobalEventHandlers.oninput")}} はここで役に立ちます。</td> + </tr> + <tr> + <td>3.2.3 一貫したナビゲーション (AA)</td> + <td> + <p>ナビゲーションのメニューやコントロールのスタイルと配置は、ウェブページの異なるページやビューの間で一貫しているべきで、例えば、新しい項目が追加されたとしても、既存の項目は同じ順序で現れるべきです。 ユーザーが変更を始めた場合、例えば、ナビゲーションのために異なる配色や位置を選択すると、それらの選択は全てのページにわたって尊重されるべきです。</p> + + <p>繰り返しますが、賢明なデザイン — 全てのページやビューでナビゲーションコントロールを同じにします。</p> + </td> + <td>モダンなレイアウトのマークアップについては、<a href="/ja/docs/Learn/Accessibility/HTML#Page_layouts">ページレイアウト</a>を参照してください。 便利なアクセス可能なナビゲーションメニューの例については、<a href="/ja/docs/Learn/CSS/Styling_text/Styling_links#Styling_links_as_buttons">ボタンとしてのリンクのスタイリング</a>も参照してください。</td> + </tr> + <tr> + <td>3.2.4 一貫した識別 (AA)</td> + <td> + <p>同じ機能を持つコントロールやコンポーネントは、異なるページやビューでも同じように識別されるべきです。 例えば、世界旅行サイトの全てのページに表示される通貨換算機は、意味論的にもラベルの観点からもまったく同じであるべきです。</p> + + <p>繰り返しますが、賢明なデザイン！</p> + </td> + <td>「ラベル」とは、テキストコンテンツ内の説明的な情報、または HTML フォームのラベルのことです。 詳細については、<a href="/ja/docs/Learn/Accessibility/HTML#Meaningful_text_labels">わかりやすいテキストラベル</a>を参照してください。</td> + </tr> + <tr> + <td>3.2.5 要求に応じた変更 (AAA)</td> + <td> + <p>ユーザーを混乱させたり、迷わせたりする可能性があるコンテキストの変更は、ユーザーから要求された場合にのみ行われるべきか、<strong>あるいは</strong>、ユーザーはそれらをオフにできるべきです。</p> + + <p>現在のビュー（例えば、コンテンツやコントロール）を大幅に変更するものが必要な場合は、変更をいつ実行するかをユーザーに制御させます（例えば、どのページを表示するか、いつギャラリーの次の写真に進むか...）。</p> + + <p>ページに回転木馬のようなものが必要な場合は、自動的に進まないようにするオプションを提供します。 可能であれば、そのような機能を避ける方が良いでしょう。</p> + </td> + <td> </td> + </tr> + </tbody> +</table> + +<div class="note"> +<p><strong>注</strong>: <a href="https://www.w3.org/TR/WCAG21/#predictable">ガイドライン 3.2: 予測可能: ウェブページを予測可能な方法で表示して操作させる</a>（英語）に関する WCAG の説明も参照してください。</p> +</div> + +<h2 id="Guideline_3.3_—_Input_Assistance_Help_users_avoid_and_correct_mistakes" name="Guideline_3.3_—_Input_Assistance_Help_users_avoid_and_correct_mistakes">ガイドライン 3.3 — 入力支援: ユーザーが間違いを避けて修正できるようにする</h2> + +<p>このガイドラインは、必要なときにユーザーが正しい情報を間違いを最小限にとどめて入力できるように手助けすることを中心にしています。</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">達成基準</th> + <th scope="col">基準への準拠方法</th> + <th scope="col">実用的なリソース</th> + </tr> + </thead> + <tbody> + <tr> + <td>3.3.1 エラーの識別 (A)</td> + <td> + <p>ユーザーがフォームに入力したりオプションを選択したりするときに検出したエラーは、エラーに関連するフォームコントロールと共に、ユーザーに明確に報告するべきです。</p> + + <p>状況に最適なものであれば、HTML5 フォームの検証機能や JavaScript を使用して、クライアント側のエラー検出と処理を実装することをお勧めします。 エラーを検出したら、ユーザーが入力を修正するのを助けるために、直観的なエラーメッセージをフォーム入力の横に表示するべきです。 スクリーンリーダーのユーザーの場合は、ARIA のライブリージョンを使用して、ページ上の変更についてユーザーに警告することができます。</p> + + <div class="note"> + <p><strong>注</strong>: サーバー側の検証は、クライアント側の検証と同時に<strong>常に</strong>使用するべきです。 クライアント側の検証は、無効にしたり回避したりするのが簡単すぎるため、単独では信頼できません。</p> + </div> + </td> + <td>包括的な検証情報については<a href="/ja/docs/Learn/HTML/Forms/Data_form_validation">フォームデータの検証</a>を、ライブリージョンに関する情報については <a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics#Dynamic_content_updates">WAI-ARIA: 動的コンテンツの更新</a>を参照してください。</td> + </tr> + <tr> + <td>3.3.2 ラベルや指示 (A)</td> + <td> + <p>データ入力が必要な場合は、明確な指示を提供するべきです。 単純な指示やプロンプトが必要な場合は、名前や年齢のような単一入力には {{htmlelement("label")}} 要素を使用したり、（生年月日や住所の要素のような）複数を一緒にした入力には {{htmlelement("label")}} と {{htmlelement("fieldset")}} / {{htmlelement("legend")}} を組み合わせて使用できます。</p> + + <p>より複雑な説明が必要な場合は、常に説明段落を含めることも、フォームをより直感的にすることを試みる必要があるかもしれません。</p> + </td> + <td><a href="/ja/docs/Learn/Accessibility/HTML#Meaningful_text_labels">わかりやすいテキストラベル</a>と便利な例については <a href="/ja/docs/Learn/HTML/Forms/How_to_structure_an_HTML_form">HTML フォームの作成方法</a>を参照してください。</td> + </tr> + <tr> + <td>3.3.3 エラーに対する提案 (AA)</td> + <td> + <p>エラーが検出され、修正の提案が判明したら、セキュリティ上の問題（例えば、パスワード入力時）やコンテキスト上の問題（例えば、クイズアプリでの回答時）が発生しない限り、ユーザーにこれらの情報を提供してください（例えば、ユーザーが既に選らんだことがあるユーザー名についての選択肢の提案）。</p> + + <p>このような場合、これが適切であれば、おそらく JavaScript とサーバー側の機能の組み合わせを使用して、エントリが正しいかどうかを確認し、正しくない場合は、ユーザーに実行可能な提案を提示できます。 そのような提案は、エラーメッセージのようなコンテキストの中で有用に表示されるべきです（3.3.1 を参照）。</p> + </td> + <td>まだチュートリアルの提案はありません。</td> + </tr> + <tr> + <td>3.3.4 エラー防止（法務、財務、データ） (AA)</td> + <td> + <p>機密データの入力に関わるフォーム（法的契約、電子商取引、個人データなど）の場合は、少なくとも次のいずれかに該当するべきです。</p> + + <ul> + <li>提出は可逆的です。</li> + <li>データにエラーがないかチェックされ、ユーザーにはエラーを修正する機会が与えられます。</li> + <li>最終提出の前に情報を確認し修正するためのメカニズムが利用可能です。</li> + </ul> + </td> + <td> + <p><strong>可逆的</strong> — データを入力できるビューには、必要に応じてエントリを編集または削除することもできる同等のビューを提供します（例えば、<a href="/ja/docs/Learn/Server-side/Django">Django ウェブフレームワーク</a>を参照）。</p> + + <p><strong>データのチェック</strong> — 3.3.1 で説明したように、クライアント側とサーバー側の検証を組み合わせてエラーを検出し、入力を修正できるようにユーザーに役立つメッセージを表示するべきです。</p> + + <p><strong>確認と修正</strong> — 必要に応じて、（製品の購入のような）一連のフォームフィールドに入力するタスクを実行した後、ユーザーに確認画面を表示して入力内容を見直し、正しくないものは修正できるようにするべきです。 このパターンは、Amazon のような電子商取引サイトで一般的に使用されています。</p> + </td> + </tr> + <tr> + <td>3.3.5 状況依存ヘルプが利用可能 (AAA)</td> + <td>フォームの完成と提出を助けるために、コンテキストの中で指示と他の適切な合図を提供してください。</td> + <td>これは実際には単に 3.3.1 や他の同様の基準に基づいていますが、もっと徹底的なコンテキスト上のヘルプ情報とサービスを必要とします。 例えば、各ページのヘルプページまたはサービスへの専用リンクを提供し、正常に完了したらどのように見えるか示す例を提供します。</td> + </tr> + <tr> + <td>3.3.6 エラー防止（全て） (AAA)</td> + <td>この原則は 3.3.4 に基づいており、機密データを含むものだけでなく、全てのユーザ入力状況に要件を拡張しています。</td> + <td>繰り返しますが、3.3.4 を参照してください。</td> + </tr> + </tbody> +</table> + +<div class="note"> +<p><strong>注</strong>: <a href="https://www.w3.org/TR/WCAG21/#input-assistance">ガイドライン 3.3: 入力支援: ユーザーが間違いを避けて修正できるようにする</a>（英語）に関する WCAG の説明も参照してください。</p> +</div> + +<p> </p> + +<h2 id="See_Also" name="See_Also">関連情報</h2> + +<ul> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG">WCAG</a> + + <ol> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG/Perceivable">知覚可能</a></li> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG/Operable">操作可能</a></li> + <li>理解可能</li> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG/Robust">堅牢</a></li> + </ol> + </li> +</ul> + +<p> </p> |