diff options
Diffstat (limited to 'files/ja/learn/accessibility')
| -rw-r--r-- | files/ja/learn/accessibility/accessibility_troubleshooting/index.html | 129 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/css_and_javascript/index.html | 373 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/html/index.html | 564 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/index.html | 63 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/mobile/index.html | 316 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/multimedia/index.html | 371 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/wai-aria_basics/index.html | 434 | ||||
| -rw-r--r-- | files/ja/learn/accessibility/what_is_accessibility/index.html | 233 |
8 files changed, 2483 insertions, 0 deletions
diff --git a/files/ja/learn/accessibility/accessibility_troubleshooting/index.html b/files/ja/learn/accessibility/accessibility_troubleshooting/index.html new file mode 100644 index 0000000000..a43b4a509b --- /dev/null +++ b/files/ja/learn/accessibility/accessibility_troubleshooting/index.html @@ -0,0 +1,129 @@ +--- +title: '評価: アクセシビリティのトラブルシューティング' +slug: Learn/Accessibility/Accessibility_troubleshooting +tags: + - Accessibility + - Assesment + - Beginner + - CSS + - CodingScripting + - HTML + - JavaScript + - Learn + - WAI-ARIA +translation_of: Learn/Accessibility/Accessibility_troubleshooting +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}</div> + +<p class="summary">このモジュールの評価では、あなたが診断、修正するべきいくつかのアクセシビリティの問題を持った簡単なサイトを表示します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識:</th> + <td>基本的なコンピューターの知識、HTML、CSS、JavaScript に対する基本的な理解、<a href="/ja/docs/Learn/Accessibility">このコースのこれまでの記事</a>への理解。</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>アクセシビリティの基礎に対する基本的な知識をテストすること。</td> + </tr> + </tbody> +</table> + +<h2 id="Starting_point" name="Starting_point">開始地点</h2> + +<p>評価を始めるために、<a href="https://github.com/mdn/learning-area/blob/master/accessibility/assessment-start/assessment-files.zip?raw=true">例を含むファイルの ZIP</a> を取得してください。あなたのコンピューターのいずれかのディレクトリーにそのコンテンツを解凍してください。</p> + +<p>あるいは、<a class="external external-icon" href="http://jsbin.com/">JSBin</a> や <a href="https://glitch.com/">Glitch</a> のようなサイトを使って試験できます。HTML, CSS, JavaScript をオンラインエディターのいずれかにペーストします。もし使っているオンラインエディターに個別の CSS/JS パネルがない場合、適当な <code><style></code> / <code><script></code> 要素内に置いて下さい。</p> + +<p>解凍が完了した評価サイトは次のように見えるはずです:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14555/assessment-site-finished.png" style="border-style: solid; border-width: 1px; display: block; height: 457px; margin: 0px auto; width: 800px;"></p> + +<p>この評価の開始時点であなたがサイトを表示したとき、いくつかの違いや問題を見つけることでしょう。これは主にマークアップ中の違いが原因であり、CSS が正しく適用されずにスタイリングの問題を引き起こしています。心配しないでください。以降の節でそれらの問題を修正します！</p> + +<div class="blockIndicator note"> +<p><strong>注</strong>: もし行き詰まって助けを求める場合 — ページ最下部の {{anch("Assessment or further help")}} セクションを見てください。</p> +</div> + +<h2 id="Project_brief" name="Project_brief">プロジェクトの概要</h2> + +<p>このプロジェクトでは、熊の「事実」に関する記事を表示する架空の自然のサイトが表示されます。現状では、これはいくつものアクセシビリティの問題を持っています。あなたの仕事は現状のサイトを見て、全力を尽くして修正し、以下の質問に答えることです。 </p> + +<h3 id="Color" name="Color">色</h3> + +<p>テキストは現在のカラースキームのせいで読みづらくなっています。現状のカラーコントラスト (テキスト/背景) をテストして、テストの結果を報告し、割り当てられた色を変更して修正できますか？</p> + +<h3 id="Semantic_HTML" name="Semantic_HTML">セマンティック HTML</h3> + +<ol> + <li>コンテンツはまだあまりアクセシブルではありません。スクリーンリーダーを使ってナビゲートしようとしたとき、何が起こるか報告してください。</li> + <li>スクリーンリーダーのユーザーがナビゲートしやすいように、記事のテキストを変更できますか？</li> + <li>サイトのナビゲーションメニュー ( <code><div class="nav"></div></code> で囲まれた部分) は正しい HTML5 セマンティック要素の中に入れることでよりアクセシブルになったかもしれません。どれを変更する必要がありますか？変更してください。</li> +</ol> + +<div class="note"> +<p><strong>注</strong>: タグをスタイル付けする CSS ルールセレクターは、セマンティック見出しのために適切に変更する必要があります。<font>パラグラフ要素を加えると、スタイルもより良く見えることに気がつくでしょう。</font></p> +</div> + +<h3 id="The_images" name="The_images"><font>画像</font></h3> + +<p><font>現状の画像はスクリーンリーダーのユーザーにとってアクセシブルではありません。修正できますか？</font></p> + +<h3 id="The_audio_player" name="The_audio_player"><font>オーディオプレイヤー</font></h3> + +<ol> + <li><font><code><audio></code> プレイヤーは聴覚障害者にとってアクセシブルではありません</font>。それらのユーザーのために何らかのアクセシブルな代替手段を加えることができますか？</li> + <li><font><code><audio></code> プレイヤーは、HTML5 をサポートしていない古いブラウザーを使用しているユーザーにとってアクセシブルではありません。彼らに対してどのようにオーディオにアクセスさせることができますか？</font></li> +</ol> + +<h3 id="The_forms" name="The_forms"><font>フォーム</font></h3> + +<ol> + <li><font>トップにある検索フォームの <code><input></code> 要素はラベルとともに使用できるかもしれませんが、表示されるテキストを追加するとデザインを悪化させる可能性がありますし、視覚に問題のないユーザーにとってはあまり必要ありません。スクリーンリーダーにのみアクセシブルなラベルをどうやって追加すればいいでしょう？</font></li> + <li><font>コメントフォームの中の 2 つの <code><input></code> 要素は表示されるテキストラベルを含んでいますが、それらのラベルと明確に関連付けられていません。どのように関連付けますか？いくつかの CSS ルールも修正しなければいけない点に注意してください。</font></li> +</ol> + +<h3 id="The_showhide_comment_control" name="The_showhide_comment_control"><font>コメント show/hide 制御</font></h3> + +<p><font>現状のコメント show/hide 制御ボタンは、キーボードからアクセスすることができません。タブキーによるフォーカス、リターンキーによる有効化という形で、キーボードをアクセシブルにすることができますか？</font></p> + +<h3 id="The_table" name="The_table"><font>テーブル</font></h3> + +<p><font>現状のデータテーブルはあまりアクセシブルではありません。スクリーンリーダーのユーザーにとって行と列を関連付けることは難しく、またテーブルが何を示しているのかを明確にする概要もありません。この問題を解決するために何らかの機能を HTML に追加することはできますか？</font></p> + +<h3 id="Other_considerations" name="Other_considerations"><font>他には？</font></h3> + +<p><font>このウェブサイトをよりアクセシブルにする 2 つ以上の改善アイデアを挙げることができますか？</font></p> + +<h2 id="Assessment_or_further_help" name="Assessment_or_further_help"><font>評価とヒント</font></h2> + +<p><font>あなたの作業を教師やメンターに渡して採点してもらったり、行き詰まってヒントが欲しい場合は次のようにしてください:</font></p> + +<ol> + <li>成果をオンラインで共有できるエディター、例えば <a href="https://codepen.io/">CodePen</a>, <a href="https://jsfiddle.net/">jsFiddle</a>, <a href="https://glitch.com/">Glitch</a> に置きます。</li> + <li>採点や手助けのための投稿を <a href="https://discourse.mozilla.org/c/mdn/learn">MDN Discourse forum Learning category</a> に書いてください。投稿には次のものを(英語で)入れて下さい: + <ul> + <li>"Assessment wanted for Accessibility troubleshooting"のような説明的なタイトル。</li> + <li>何を試して、どうしてほしいのかの詳細。つまり行き詰まって助けてほしいのか、採点評価してほしいのか。</li> + <li>オンラインで共有できるエディター (上記ステップ 1 で触れたもの)での例のリンク。これは身につけるとよい習慣です — コーティングの問題を、他の人がコードを見ずに助けるのは困難です。</li> + <li>助けてもらいたい問題が見つかるような、タスクや評価のページのリンク</li> + </ul> + </li> +</ol> + +<p><font>{{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}</font></p> + +<h2 id="このモジュール内">このモジュール内</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは？</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティ成功事例</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/WAI-ARIA_basics" rel="nofollow">WAI-ARIA の基本</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/Multimedia" rel="nofollow">アクセシブルなマルチメディア</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/Mobile" rel="nofollow">モバイルアクセシビリティ</a></li> + <li><a href="https://developer.mozilla.org/ja/docs/Learn/Accessibility/Accessibility_troubleshooting" rel="nofollow">アクセシビリティのトラブルシューティング</a></li> +</ul> diff --git a/files/ja/learn/accessibility/css_and_javascript/index.html b/files/ja/learn/accessibility/css_and_javascript/index.html new file mode 100644 index 0000000000..76ea71cce1 --- /dev/null +++ b/files/ja/learn/accessibility/css_and_javascript/index.html @@ -0,0 +1,373 @@ +--- +title: CSS と JavaScript のアクセシビリティの ベスト・プラクティス +slug: Learn/Accessibility/CSS_and_JavaScript +tags: + - Accessibility + - Article + - CSS + - CodingScripting + - Guide + - JavaScript + - Learn + - color + - contrast + - hiding + - unobtrusive + - ひかえめ + - アクセシビリティ + - ガイド + - コントラスト + - 学習 + - 色 + - 隠す +translation_of: Learn/Accessibility/CSS_and_JavaScript +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div> + +<p class="summary">CSS と JavaScript も、適切に使えばアクセシブルなウェブ体験を可能にしてくれる可能性がありますが、誤用すると、大幅にアクセシビリティを悪化させることがあります。本記事では、複雑なコンテンツでもできる限りアクセシブルにすることを保証するために考慮すべき、CSS と JavaScript のベスト・プラクティスのいくつかを概観します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識:</th> + <td>基本的なコンピューターの知識、HTML と CSS と JavaScript に関する基本的な理解、<a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは何か</a>に関する理解。</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>アクセシビリティを損わず、最大化するように、自身のウェブドキュメントで CSS と JavaScript を適切に使うことに慣れること。</td> + </tr> + </tbody> +</table> + +<h2 id="CSS_and_JavaScript_are_accessible" name="CSS_and_JavaScript_are_accessible">CSS と JavaScript はアクセシブルなの?</h2> + +<p>CSS と JavaScript は、アクセシビリティに関して HTML と同じだけの直接的重要性があるわけではありません。ですが、それでも使い方によっては、アクセシビリティを高めることも損うこともありえます。別の言葉で言うと、自分の CSS と JavaScript の使い方によってドキュメントのアクセシビリティを台無しにしていないと確認するために、いくつかのベスト・プラクティスを考慮することが重要です。</p> + +<h2 id="CSS" name="CSS">CSS</h2> + +<p>CSS を見ることから始めましょう。</p> + +<h3 id="Correct_semantics_and_user_expectation" name="Correct_semantics_and_user_expectation">正しいセマンティクスと、ユーザの予期すること</h3> + +<p>CSS を使って、どのような HTML 要素を<em>どのように</em>見せかけることも可能です。しかし、このことは、そうすべきだと意味しているわけではありません。「<a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a>」という記事でしばしば述べたように、可能な場合にはいつでも、役割にふさわしい意味の要素を使うべきです。そうしないと、混乱を巻き起こしかねませんし、あらゆる人にとっての——とりわけ障碍のあるユーザーにとっての——使い勝手の問題を引き起こしかねません。正しいセマンティクスを使うことは、ユーザーの予期することと大いに関係があります。つまり、要素とは、その機能にしたがって、特定の見かけをしており特定のふるまいをするものであり、こうした通常の慣習をユーザーは予期するものなのです。</p> + +<p>一例として、開発者が見出し要素を適切に使ってコンテンツをマークアップしていなかった場合には、スクリーン・リーダーのユーザーは、見出し要素を通じてページの見通しを得ることができないでしょう。同様に、見出しのようには見えないように見出しにスタイルをつけた場合には、見出しは視覚的な目的を失ってしまいます。</p> + +<p>大まかな目安はこうです。つまり、自分のデザインに合わせるように、ページ項目のスタイル付けを更新するのは構いません。しかし、その項目が予期されるのとは全然違う見かけになったり、予期されるのとは全然違うふるまいをしたりするほど大幅にスタイル付けを変えてはいけません。以下の節では、考慮すべき主な HTML 項目について概説します。</p> + +<h4 id="Standard_text_content_structure" name="Standard_text_content_structure">「標準的」なテキストコンテンツ構造</h4> + +<p>見出し、段落、リスト——これらは、ページの中心的テキストコンテンツです。</p> + +<pre class="brush: html"><h1>見出し</h1> + +<p>段落</p> + +<ul> + <li>わたしのリストには</li> + <li>二つの項目があるよ。</li> +</ul></pre> + +<p>ある種の典型的な CSS は以下のようなものかもしれません。</p> + +<pre class="brush: css">h1 { + font-size: 5rem; +} + +p, li { + line-height: 1.5; + font-size: 1.6rem; +}</pre> + +<p>なすべきことは以下の通りです。</p> + +<ul> + <li>文章を筋道立っていて判読可能で心地よく読めるものにするために、フォントサイズや行高や文字間隔などは、分別のあるものを選びましょう。</li> + <li>見出しが本文と区別できる (典型的には、デフォルトのスタイル付けと同様に、大きくて太い文字になっている) ようにしましょう。リストは、リストであるように見えるべきです。</li> + <li>テキストの色は、背景色と十分に異なっているべきです。</li> +</ul> + +<p>より詳しくは、<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals">HTML テキストの基礎</a>と<a href="/ja/docs/Learn/CSS/Styling_text">テキストのスタイリング</a>を参照してください。</p> + +<h4 id="Emphasised_text" name="Emphasised_text">強調したテキスト</h4> + +<p>囲んでいるテキストに対して特定の強調を与えるインライン・マークアップは、たとえば以下のようなものです。</p> + +<pre class="brush: html"><p>そのお湯は<em>とても熱いよ</em>。</p> + +<p>表面に集まる水滴は、<strong>結露</strong>と呼ばれます。</p></pre> + +<p>強調したテキストに対して、なんらかの単純な色付けを加えたいかもしれません。</p> + +<pre class="brush: css">strong, em { + color: #a60000; +}</pre> + +<p>けれども、なんらかの目立つ方法で強調要素をスタイル付けする必要はめったにないでしょう。太字とイタリック体のテキストという標準的慣習はとても認識しやすく、そのスタイルを変更することは混乱を招きかねません。強調についてのさらなる情報は、<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals#Emphasis_and_importance">強調と重要性</a>を参照してください。</p> + +<h4 id="Abbreviations" name="Abbreviations">略語</h4> + +<p>略語、頭文字語、つまり頭文字で表したものを、その展開形と関連付けることを可能とする要素は、たとえば以下のようなものです。</p> + +<pre class="brush: html"><p>ウェブ・コンテンツは、<abbr title="Hypertext Markup Language">HTML</abbr>を使ってマークアップされています。</p></pre> + +<p>この場合も、なんらかの単純な方法でスタイルを付けたいかもしれません。</p> + +<pre class="brush: css">abbr { + color: #a60000; +}</pre> + +<p>略語に対する公認のスタイル付けの慣習は、点線の下線です。そして、点線の下線から大きく逸脱するのは愚かしいことです。略語についてのさらなる情報は、<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/Advanced_text_formatting#Abbreviations">略語</a>を参照してください。</p> + +<h4 id="Links" name="Links">リンク</h4> + +<p>ハイパーリンク——ウェブ上の新たな場所に行く方法——は、たとえば以下のようなものです。</p> + +<pre class="brush: html"><p><a href="https://www.mozilla.org">Mozilla のホームページ</a>に来てくださいね。</p></pre> + +<p>ある種のとても簡単なリンクのスタイル付けを以下に示します。</p> + +<pre class="brush: css">a { + color: #ff0000; +} + +a:hover, a:visited, a:focus { + color: #a60000; + text-decoration: none; +} + +a:active { + color: #000000; + background-color: #a60000; +}</pre> + +<p>標準的なリンクの慣習は、下線を引いた、標準状態とは異なる色 (デフォルトは青) と、そのリンクを以前にたどったことがある場合の別の色変化 (デフォルトは紫) と、そのリンクがアクティブになっている場合のさらに別の色 (デフォルトは赤) です。さらに、リンクにマウスオーバーした場合には、マウスポインターがポインターアイコンに変化しますし、リンクは、(たとえばタブキーを押して) フォーカスが当たったり、アクティブ化されたりすると、ハイライトされます。以下の画像は、Firefox でのハイライト (点線の輪郭線) と Chrome でのハイライト (青い輪郭線) の双方を示したものです。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14371/focus-highlight-firefox.png" style="display: block; height: 173px; margin: 0px auto; width: 319px;"></p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14369/focus-highlight-chrome.png" style="display: block; height: 169px; margin: 0px auto; width: 309px;"></p> + +<p>ユーザーがリンクを対話的に操作する際にユーザーに対してフィードバックを与え続ける限りは、リンクのスタイルに関して創造性を発揮して構いません。状態が変化する際には何かが明確に生じるべきであり、かつ、ポインターカーソルも輪郭線も——この両者は、キーボード・コントロールを使う人々にとって非常に重要なアクセシビリティの助けなのです——除去するべきではありませんが。</p> + +<h4 id="Form_elements" name="Form_elements">フォーム要素</h4> + +<p>ユーザーがウェブサイトにデータを入力できるようにする要素であり、たとえば以下のようなものです。</p> + +<pre class="brush: html"><div> + <label for="name">お名前を入力してください</label> + <input type="text" id="name" name="name"> +</div></pre> + +<p><a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-css.html">form-css.html</a> の例 (<a href="http://mdn.github.io/learning-area/accessibility/css/form-css.html">ライブも見てください</a>) において、ある種の適切な例示的 CSS が見られます。</p> + +<p>フォーム用に書く CSS のほとんどは、要素のサイズを変更したり、ラベルと入力欄を整列したり、それらをすっきり整えたりするためのものでしょう。</p> + +<p>ですが、フォーム要素にフォーカスが当たったときにそのフォーム要素が受けとる、予期された視覚的フィードバックからは、逸脱しすぎるべきではありません。そのことは、リンクの場合 (上記参照) と基本的に同様です。フォームのフォーカス / ホバー状態に対してスタイルを付けて、このふるまいがブラウザ間でより首尾一貫したものとなるようにしてもよいでしょうし、あるいは、自分のページ・デザインとより良く適合するようにしてもよいでしょう。しかし、予期される視覚的フィードバックをすべて捨て去ってはなりません。再び言いますが、これらの手がかりが、何が起きているのかを知る手助けになってくれるだろう、と人々は当てにしているのです。</p> + +<h4 id="Tables" name="Tables">テーブル</h4> + +<p>表データを提示するためのテーブルです。</p> + +<p><a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/table-css.html">table-css.html</a> の例 (<a href="http://mdn.github.io/learning-area/accessibility/css/table-css.html">ライブも見てください</a>) において、テーブルの HTML と CSS の、適切で簡潔な例を見られます。</p> + +<p>テーブル CSS は一般に、テーブルを自分のデザインによりうまく適合させて、見苦しさを減らすのに役立ちます。テーブルの見出しが目立つようにすること (普通は太字を使います)、異なる行同士が見分けやすいようにシマウマ的配色を使うことは、良い考えです。</p> + +<h3 id="Color_and_color_contrast" name="Color_and_color_contrast">色とそのコントラスト</h3> + +<p>自分のウェブサイト用のカラー・スキームを選ぶときには、テキスト (前景) の色が背景色と十分に差があることを確認してください。あなたのデザインはかっこよく見えるかもしれませんが、もし色盲などの視覚障碍のある人々がコンテンツを読めなかったら、まったく良いデザインではありません。</p> + +<p>問題を起こさない程度に十分にコントラストが大きいかどうかを調べる簡単な方法があります。前景色と背景色を入力して調べることができる、コントラストのチェック用ツールが、オンライン上にいくつもあります。たとえば、WebAIM の <a href="http://webaim.org/resources/contrastchecker/">Color Contrast Checker</a> は、簡単に使えますし、色のコントラストに関して WCAG の基準に適合するためには何を行えば良いのかについて、説明もしてくれます。</p> + +<div class="note"> +<p><strong>注意</strong>: コントラスト比を高くすることによって、光沢のある画面のスマートフォンまたはタブレットを使う人が陽光のような明るい環境でページを読みやすくもなるでしょう。</p> +</div> + +<p>もう一つ別のコツは、標識や案内について色だけに頼らないことです。というのも、色だけに頼るのは、色が見えない人々にとってまったく良くないからです。必須のフォーム・フィールドを赤でマークする代わりに、たとえば、アスタリスクと赤でマークしましょう。</p> + +<h3 id="Hiding_things" name="Hiding_things">ものごとを隠す</h3> + +<p>すべてのコンテンツをいちどきに示さないことを視覚的デザインが求めているような、多くの事例があります。たとえば、<a href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">Tabbed info box example</a> の例 (<a href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">ソースコード</a>を参照) では、三つの情報パネルがありますが、それらをお互いの上に<a href="/ja//docs/Learn/CSS/CSS_layout/Positioning">配置</a>しており、クリックするとそれぞれの情報パネルを表示できるタブを設けています (これはキーボード・アクセシブルでもあります。つまり、情報パネルを選ぶのに、クリックする代わりに、タブキーとエンターキー / リターンキーとを使うこともできます)。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13368/tabbed-info-box.png" style="display: block; height: 400px; margin: 0px auto; width: 450px;"></p> + +<p>スクリーン・リーダーのユーザーは、こうしたことは何も気にしません。ソースの順序が意味をなしている限りはコンテンツに満足しますし、コンテンツすべてに到達できます。(この例で使われているような) 絶対的な位置指定は、一般的に、視覚効果のためにコンテンツを隠す最善の仕組みの一つとして見られるものです。なぜなら、これは、スクリーン・リーダーがコンテンツに到達するの邪魔しないからです。</p> + +<p>一方で、 {{cssxref("visibility")}}<code>:hidden</code> も {{cssxref("display")}}<code>:none</code> も、スクリーン・リーダーからコンテンツを隠してしまうので、使うべきではありません。もちろん、スクリーン・リーダーからこのコンテンツを隠したいと思う然るべき理由がない限りは、ということですが。</p> + +<div class="note"> +<p><strong>注意</strong>: <span class="subtitle"><a href="http://webaim.org/techniques/css/invisiblecontent/">Invisible Content Just for Screen Reader Users</a> </span>には、この話題をめぐる多くのさらに有用な詳細があります。</p> +</div> + +<h3 id="ユーザーがスタイルを上書きできることを受け入れる">ユーザーがスタイルを上書きできることを受け入れる</h3> + +<h4 id="Accept_that_users_can_override_your_styles" name="Accept_that_users_can_override_your_styles">ユーザーがスタイルを上書きできることを受け入れる</h4> + +<p>ユーザーは、自分のカスタム・スタイルでスタイルを上書きできます。たとえば以下のとおりです。</p> + +<ul> + <li>Firefox において手動でスタイルを上書きする方法を含む有用なガイドとしては、 Sarah Maddox の <a class="external external-icon" href="https://www.itsupportguides.com/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-firefox/" rel="noopener">How to use a custom style sheet (CSS) with Firefox</a> を参照のこと。同等な IE の命令については、Adrian Gordon による <a href="https://www.itsupportguides.com/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-internet-explorer/">How to use a custom style sheet (CSS) with Internet Explorer</a> を参照のこと。</li> + <li>拡張機能を使ってスタイルを上書きするのは、おそらくもっと簡単です。たとえば、<a href="https://addons.mozilla.org/en-US/firefox/addon/stylish/">Firefox</a> 用、<a href="https://safari-extensions.apple.com/details/?id=com.sobolev.stylish-5555L95H45">Safari</a> 用、<a href="https://addons.opera.com/en/extensions/details/stylish/">Opera</a> 用、<a href="https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe">Chrome</a> 用の Stylish という拡張機能が利用できます。</li> +</ul> + +<p>ユーザーは様々な理由から、スタイルの上書きを行うかもしれません。視覚障碍のあるユーザーは、すべての訪問先のウェブサイトでテキストを大きくしたいかもしれませんし、あるいは、重度の色覚障碍のあるユーザーは、すべてのウェブサイトを自分でも見やすい高コントラストの色にしたいかもしれません。その必要性がいかなるものであるにせよ、(スタイルの上書きという) この事態にはなじんでおくべきですし、そうした変更が自分のデザインにおいてうまく機能するように、自分のデザインを十分に柔軟なものとしておくべきです。例として、主なコンテンツ領域がより大きいテキストを扱えて (その領域は、全体を見られるようにスクロールし始めるかもしれません)、ただ隠したり完全に破綻したりしないように、気をつけると良いでしょう。</p> + +<h2 id="JavaScript" name="JavaScript">JavaScript</h2> + +<p>JavaScript も、その使い方によっては、アクセシビリティをぶち壊しにする可能性があります。</p> + +<p>モダンな JavaScript は強力な言語です。簡単なコンテンツと UI の更新から、本格的な 2D ゲームや 3D ゲームに至るまで、近頃では JavaScript を使ってとても多くのことができます。すべてのコンテンツがすべての人々にとって 100% アクセシブルであるべきだ、といった決まりはありません。自分にできることをし、自分のアプリをできる限りアクセシブルにする必要があるだけなのです。</p> + +<p>単純なコンテンツと機能——たとえば、テキスト、画像、テーブル、フォーム、関数を起動する押しボタン——は、まず間違いなく、アクセシブルにするのが簡単です。<a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a> の記事で見たように、考慮すべき重要な事項は以下のとおりです。</p> + +<ul> + <li>良いセマンティクス: ふさわしい要素をふさわしい役割に使うこと。たとえば、見出しと段落を使い、{{htmlelement("button")}} 要素と {{htmlelement("a")}} 要素を使うようにします。</li> + <li>コンテンツを、テキストとして利用可能にすること——テキスト・コンテンツや、フォーム要素に対する適切なテキスト・ラベルの形で、直接的に利用可能とするか、あるいは、たとえば画像に対する alt テキストのような<a href="/ja/docs/Learn/Accessibility/HTML#Text_alternatives">代替テキスト</a>として、利用可能にすること。</li> +</ul> + +<p>機能が欠けているところに機能を盛り込むように JavaScript を使う方法の例も見ました (<a href="/ja/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a> を参照)。この例は理想的ではありません。実際、ただふさわしい要素をふさわしい役割に使うべきなのです。が、この例は、使われるマークアップを何らかの理由で統制できない状況においては、こうしたこともあり得るのだと示しています。非意味的な、JavaScript で実装されたウィジェットについて、アクセシビリティを向上させる別の方法は、WAI-ARIA を用いて追加的なセマンティクスをスクリーン・リーダーのユーザーに提供することです。次の記事では、このことも詳しく扱います。</p> + +<p>3D ゲームのような複雑な機能は、アクセシブルにするのがそう簡単ではありません。<a href="/ja/docs/Web/API/WebGL_API">WebGL</a> を使って作られた複雑な 3D ゲームは {{htmlelement("canvas")}} 要素上に描画されるでしょうが、今のところ {{htmlelement("canvas")}} 要素には、重度の視覚障碍のあるユーザーが利用できるように代替テキストもしくは他の情報を提供する手段がないのです。 そうしたゲームは、こうした人々のグループを実際に主要な対象者の一部としてはいないのだ、というのはもっともです。それに、そのゲームを、目の見えない人々にとって 100% アクセシブルにせよ、と期待するのも不合理でしょう。しかし、マウスを使わないユーザーにとって利用可能なように<a href="/ja/docs/Games/Techniques/Control_mechanisms/Desktop_with_mouse_and_keyboard">キーボード・コントロール</a>を実装することや、 色覚障碍のある人々にとって利用可能なようにカラー・スキームに十分なコントラストを持たせることならできるでしょう。</p> + +<h3 id="The_problem_with_too_much_JavaScript" name="The_problem_with_too_much_JavaScript">過度の JavaScript にともなう問題</h3> + +<p>JavaScript に頼りすぎると、しばしば問題が起きます。ときどき、何でもかんでも JavaScript で行われたウェブサイト—— HTML が JavaScript により生成され、CSS が JavaScript により生成され、といった調子のもの——を見るでしょう。これには、あらゆる種類のアクセシビリティの問題および付随するその他の問題があり、お勧めできません。</p> + +<p>ふさわしい役割にふさわしい要素を使うのと同様に、ふさわしい役割にふさわしい技術を使っていることも確認しておくべきです! JavaScript で実装されたキラキラの 3D 情報ボックスが必要なのか、あるいは、プレーンな古めかしいテキストでも用が足りそうか、ということについて注意深く考えてください。複雑で非標準的なフォーム・ウィジェットが必要なのか、あるいは、テキスト入力でも用が足りそうか、ということについて注意深く考えてください。そして、とにかく可能な場合に JavaScript を使ってすべての HTML コンテンツを生成する、などということはしないでください。</p> + +<h3 id="Keeping_it_unobtrusive" name="Keeping_it_unobtrusive">ひかえめに保つこと</h3> + +<p>コンテンツを作るときには、<strong>ひかえめな (unobtrusive) JavaScript</strong> を心に留めておくべきです。ひかえめな JavaScript という考え方は、次のようなものです。すなわち、機能を拡張できるところならどこでも使うべきだけれども、機能を盛り込むためにはまったく使うべきではない——基本的機能は JavaScript なしでも理想的には動くはずなのだから。もっとも、これが常に選択できるとは限らないことはよく理解されているのですが。しかし再び言いますが、この考えの大部分を占めるのは、可能な箇所ではブラウザーの組み込み機能を使うということです。</p> + +<p>ひかえめな JavaScript の適切な使用例には、次のものが含まれます。</p> + +<ul> + <li>クライアントサイドのフォーム検査を提供すること。これは、サーバーがデータを調べるのを待つ必要なしに、フォーム入力にともなう問題をユーザーに対して素早く警告してくれます。もしクライアントサイドのフォーム検査が利用できなくても、フォームは依然として動作するでしょうが、検査は遅くなるかもしれません。</li> + <li>キーボードのみのユーザーにとってアクセシブルな 、HTML5 <code><video></code> 用のカスタム・コントロールを提供すること。それとともに、JavaScript が利用できない場合にその動画にアクセスするのに使える、動画への直接リンクも提供すること (ほとんどのブラウザでは、デフォルトの <code><video></code> ブラウザ・コントロールは、キーボード・アクセシブルではありません)。</li> +</ul> + +<p id="Client-side_form_validation">一例として、やっつけ仕事のクライアントサイドのフォーム検査の例を書きました。<a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> を参照してください (<a href="http://mdn.github.io/learning-area/accessibility/css/form-validation.html">demo live</a> も参照してください). ここでは、単純なフォームが見えます。一方または双方のフィールドを空にしたままフォームを送信しようとすると、送信が失敗し、エラーメッセージ・ボックスが現れて、何が間違っているのかを教えてくれます。</p> + +<p>この種のフォーム検査はひかえめです。JavaScript が利用できなくても、依然としてまったく申し分なくフォームを使えます。それに、分別のあるフォームの実装なら何であれ、サーバーサイドの検査も作動させておくことでしょう。なぜなら、悪意のあるユーザーがクライアントサイドの検査を (たとえば、ブラウザで JavaScript をオフにしておくことによって) 迂回することは、あまりに容易だからです。クライアントサイドの検査は、それでも実際に、エラーを報告するためには有用なのです。ユーザーは、自分のおかした間違いについて、サーバーまでのラウンドトリップおよびページリロードを待つ必要なしに、すぐに知ることができます。これは使い勝手の上での明らかな利点です。</p> + +<div class="note"> +<p><strong>注意</strong>: この単純なデモではサーバーサイドの検査を実装しませんでした。</p> +</div> + +<p>このフォーム検査も、とてもアクセシブルにしておきました。{{htmlelement("label")}} 要素を用いて、フォーム・ラベルがそのラベルの入力欄に曖昧な点なしに紐付けられるようにして、それによってスクリーン・リーダーがラベルを一緒に読み上げられるようにしました。</p> + +<pre class="brush: html"><label for="name">お名前を入力してください (Enter your name):</label> +<input type="text" name="name" id="name"></pre> + +<p>フォームが送信されるときにだけ検査をしています。これは、UI をあまりに頻繁に更新しないようにするため、そして、スクリーン・リーダーのユーザーを (また、おそらくは他のユーザーも) 潜在的に混乱させることがないようにするためです。</p> + +<pre class="brush: js">form.onsubmit = validate; + +function validate(e) { + errorList.innerHTML = ''; + for(var i = 0; i < formItems.length; i++) { + var testItem = formItems[i]; + if(testItem.input.value === '') { + errorField.style.left = '360px'; + createLink(testItem); + } + } + + if(errorList.innerHTML !== '') { + e.preventDefault(); + } +}</pre> + +<div class="note"> +<p><strong>注意</strong>: この例では、絶対的な位置指定を用いてエラーメッセージ・ボックスを隠したり見せたりしています。visibility や display などの他の方法を使っているわけではありません。なぜなら、絶対的な位置指定は、スクリーン・リーダーがコンテンツを読めるようにしておくことを妨げないからです。</p> +</div> + +<p>現実のフォーム検査は、これよりもっと複雑でしょう。入力された名前が実際に名前のようであることを確認したいかもしれませんし、入力された年齢が実際に数であり、かつ現実的である (たとえば、負数ではなく、4 桁でもない、など) ということを確認したいかもしれません。ここでは、各入力フィールドに値が入れられたことを確認する (<code>if(testItem.input.value === '')</code> という) 簡単な検査を実装しただけです。</p> + +<p>検査が実行された際に、もしテストに通れば、フォームが送信されます。もしエラーがあれば (つまり <code>if(errorList.innerHTML !== '')</code> であれば)、 (<code><a href="/ja/docs/Web/API/Event/preventDefault">preventDefault()</a></code> を用いて) フォームの送信を中止し、生成されたエラーメッセージをすべて表示します (下記参照)。この仕組みは、エラーが存在するときにだけエラーが表示される、ということを意味します。そしてそのことは、使い勝手のうえで、より良いことなのです。</p> + +<p>フォームが送信される際に値が入れられていない入力それぞれについて、リンクを有するリスト項目を作って、それを <code>errorList</code> に挿入しています。</p> + +<pre class="brush: js">function createLink(testItem) { + var listItem = document.createElement('li'); + var anchor = document.createElement('a'); + anchor.textContent = testItem.input.name + ' field is empty: fill in your ' + testItem.input.name + '.'; + anchor.href = '#' + testItem.input.name; + anchor.onclick = function() { + testItem.input.focus(); + }; + listItem.appendChild(anchor); + errorList.appendChild(listItem); +}</pre> + +<p>各リンクは二つの役割を果たします。つまり、何のエラーなのかを教えてくれますし、さらに、そのリンクをクリックする / アクティブにすると問題の入力要素へ直接ジャンプして入力を訂正できるようになっています。</p> + +<div class="note"> +<p><strong>注意</strong>: この例の <code>focus()</code> の部分は少し手が込んでいます。Chrome と Edge (と、IE の新しいバージョン) は、リンクがクリックされたときに要素にフォーカスを当てるので、<code>onclick</code>/<code>focus()</code> ブロックを必要としません。Safari はリンク自体とともにフォーム要素をハイライトするだけであり、そのため、実際にフォーム要素にフォーカスを当てるには <code>onclick</code>/<code>focus()</code> ブロックが必要です。Firefox は、こうした状況において入力要素に適切にフォーカスを当てることはまったくありません。よって、Firefox のユーザーは、現時点ではこの <code>onclick</code>/<code>focus()</code> ブロックの利益を享受できません (それ以外のすべてはうまく機能するのですが)。Firefox の問題はすぐに修正されるはずです。というのも、他のブラウザと同等のふるまいを Firefox にさせるための作業が、今なされている最中ですから ({{bug(277178)}} を参照).</p> +</div> + +<p>さらに、ソース順における先頭に <code>errorField</code> を置いてあります (CSS を使って、UI 上では別のところに配置してありますが)。これが意味することは、ユーザーが、ページの最初に戻ることで、自分のフォーム送信でまさに何が間違っているのかも分かるし、問題の入力要素にも行ける、ということです。</p> + +<p>最後の注記ですが、このデモではいくつか WAI-ARIA 属性を使いました。ページリロードをともなわずに絶えず更新するコンテンツの領域が引き起こすアクセシビリティの問題を、解決する手助けとするためです (スクリーン・リーダーは、デフォルトでは、こうしたコンテンツを拾い上げたり、ユーザーにこうしたコンテンツを警告したりはしないでしょう)。</p> + +<pre><div class="errors" role="alert" aria-relevant="all"> + <ul> + </ul> +</div></pre> + +<p>もっと詳細に <a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> を扱う次の記事で、これらの属性について説明します。</p> + +<div class="note"> +<p><strong>注意</strong>: HTML5 フォームには <code>required</code> 属性や <code>min</code>/<code>minlength</code> 属性や <code>max</code>/<code>maxlength</code> 属性のような組み込みの検査の仕組みがあること (より詳しくは、{{htmlelement("input")}} 要素のリファレンスを参照) について考える読者もおそらくいることでしょう。このデモでは、結局これらの属性は使いませんでした。なぜなら、これらの属性についてのクロスブラウザ・サポートが当てにならないからです (たとえば IE10 以上のみでのサポートだったり、Safari ではサポートされていなかったりします)。</p> +</div> + +<div class="note"> +<p><strong>注意</strong>: WebAIM の <a href="http://webaim.org/techniques/formvalidation/">Usable and Accessible Form Validation and Error Recovery</a> は、アクセシブルなフォーム検査についてのさらに有用な情報をいくつか教えてくれます。</p> +</div> + +<h3 id="Other_JavaScript_accessibility_concerns" name="Other_JavaScript_accessibility_concerns">JavaScript のアクセシビリティのその他の問題</h3> + +<p>JavaScript で実装しつつアクセシビリティについて考えるときに意識すべきことは他にもあります。見つけ次第、さらなる事項を追加するつもりです。</p> + +<h4 id="mouse-specific_events" name="mouse-specific_events">マウスに特有のイベント</h4> + +<p> お気づきのとおり、ユーザーとの対話的動作のほとんどは、イベントハンドラーを使ってクライアントサイドの JavaScript で実装されます。イベントハンドラーによって、特定のイベントが起きるのに応じて関数を実行できるようになります。ある種のイベントには、アクセシビリティの問題があるかもしれません。読者が見つけることになるであろう主な例は、<a href="/ja/docs/Web/Events/mouseover">mouseover</a> や <a href="/ja/docs/Web/Events/mouseout">mouseout</a> や <a href="/ja/docs/Web/Events/dblclick">dblclick</a> などの、マウスに特有のイベントです。これらのイベントに応じて動作する機能は、キーボード・コントロールのような他の仕組みを用いていると、アクセシブルではなくなります。</p> + +<p>こうした問題を軽減するには、これらのイベントと、他の手段によってアクティブにできるような類似のイベントとの二重化をすべきです (いわゆるデバイスとは独立なイベントハンドラーです)。<a href="/ja/docs/Web/Events/focus">focus</a> と <a href="/ja/docs/Web/Events/blur">blur</a> は、キーボードのユーザーに対するアクセシビリティを提供してくれることでしょう。</p> + +<p>これが有用になりうる場合においてハイライトを行う事例を見てみましょう。ときにはサムネイル画像を設けたいことがあります。そのサムネイル画像にマウスオーバーした場合またはフォーカスが当たった場合に、その画像の、より大きなバージョンを表示するものです (電子商取引の商品カタログ上で見受けられるようなものです)。</p> + +<p>とても簡単な例を作りました。これは、<a href="http://mdn.github.io/learning-area/accessibility/css/mouse-and-keyboard-events.html">mouse-and-keyboard-events.html</a> で見られます (<a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/mouse-and-keyboard-events.html">ソースコード</a> も参照)。このコードは、ズームインした画像を表示する関数と隠す関数という、二つの関数を特徴としています。これらの関数は、これらの関数をイベントハンドラーとして設定する以下の行により実行されます。</p> + +<pre class="brush: js">imgThumb.onmouseover = showImg; +imgThumb.onmouseout = hideImg; + +imgThumb.onfocus = showImg; +imgThumb.onblur = hideImg;</pre> + +<p>最初の 2 行は、それぞれ、マウスポインターがサムネイル上にホバーしたときと、マウスポインターがサムネイル上にホバーするのをやめたときに、関数を動作させます。しかしこれだと、ズームしたビューにキーボードを通じてアクセスすることはできません。それをできるようにするために、後ろの方の 2 行を含めました。この 2 行は、画像にフォーカスが当たったときと、画像からフォーカスが外れた (フォーカスが停止した) ときに、関数を動作させます。こうしたことは、タブキーで画像上に移動することでできることです。なぜなら、画像に <code>tabindex="0"</code> を含めておいたからです。</p> + +<p><a href="/ja/docs/Web/Events/click">click</a> クリックイベントは興味深いものです。マウス依存のように聞こえる名前ですが、ほとんどのブラウザーは、フォーカスの当たっているリンクまたはフォーム要素上でエンター / リターンが押された後に、あるいは、そうした要素がタッチスクリーン装置上でタップされたときに、<a href="/ja/docs/Web/API/GlobalEventHandlers/onclick">onclick</a> イベントハンドラーをアクティブにすることでしょう。しかしこれは、tabindex を用いて、デフォルトではフォーカス可能ではないイベントがフォーカスを持つようにしていると、デフォルトのままではうまく機能しません。そうした場合では、まさにそのキーが具体的にはいつ押されたのかを検出する必要があります (<a href="/ja/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a> を参照)。</p> + +<h2 id="Summary" name="Summary">まとめ</h2> + +<p>ウェブページ上での CSS と JavaScript の使用にまつわるアクセシビリティの問題について、このページが適切な量の細部と理解をもたらしたのであれば幸いです。</p> + +<p>次は WAI-ARIA の番です!</p> + +<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div> + +<div> +<h2 id="In_this_module" name="In_this_module">このモジュール内</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは?</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></li> +</ul> +</div> diff --git a/files/ja/learn/accessibility/html/index.html b/files/ja/learn/accessibility/html/index.html new file mode 100644 index 0000000000..519594ad89 --- /dev/null +++ b/files/ja/learn/accessibility/html/index.html @@ -0,0 +1,564 @@ +--- +title: 'HTML: アクセシビリティの基礎' +slug: Learn/Accessibility/HTML +tags: + - AT + - Accessibility + - Article + - Beginner + - Buttons + - CodingScripting + - Forms + - HTML + - Learn + - Links + - a11y + - assistive technology + - keyboard + - screenreader + - semantics + - アクセシビリティ + - キーボード + - スクリーンリーダー + - セマンティクス + - フォーム + - ボタン + - リンク + - 初心者 + - 学習 + - 意味 +translation_of: Learn/Accessibility/HTML +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</div> + +<p class="summary">正確な HTML要素が、常に正しい目的で使用されているかを確認するだけで、たくさんのウェブコンテンツがアクセシブルになります。 ここでは、最大限のアクセシビリティを確保するために、HTML をどのように使用できるかについて詳しく説明します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識:</th> + <td>基本的なコンピュータの知識、HTML に関する基本的な理解 (<a href="/ja/docs/Learn/HTML/Introduction_to_HTML">HTML 概論</a> を参照)、<a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは何か</a> に関する理解。</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>HTML のうち、どの機能にアクセシビリティ上の利点があるのか、また、自身のウェブドキュメントでそうした機能を適切に使うにはどうしたらよいのか、ということに精通すること。</td> + </tr> + </tbody> +</table> + +<h2 id="HTML_and_accessibility" name="HTML_and_accessibility">HTML とアクセシビリティ</h2> + +<p>HTML について学習を進めるのにつれて——資料をたくさん読んだり、たくさんの例を見たりするのにつれて——共通の主題を繰り返し見続けることになるでしょう。つまり、意味的な (セマンティックな) HTML を使うことの重要性という主題です (これは、POSH すなわち Plain Old Semantic HTML (簡潔な昔ながらの意味的 HTML) と呼ばれることがあります)。これが意味することは、できる限り、ふさわしい HTML 要素をふさわしい目的に使う、ということです。</p> + +<p>これが何故それほど重要なのか、不思議に思うかもしれません。何しろ、CSS と JavaScript の組み合わせを使って、ほぼすべての HTML 要素を、どのような仕方であれ望みどおりに振る舞わせることができるわけですから。たとえば、サイト上で動画を再生するためのコントロール・ボタンを、次のようにマークアップすることもできます。</p> + +<pre class="brush: html"><div>動画を再生する</div></pre> + +<p>けれども、後にさらに詳しく見るとおり、この役割にふさわしい要素を使うことには、とても意味があります。</p> + +<pre class="brush: html"><button>動画を再生する</button></pre> + +<p>HTML の <code><button></code> は、ある種の適切なスタイルが (おそらくそのスタイルを上書きしたいと思うでしょうが) デフォルトで適用されているだけでなく、組み込みのキーボード・アクセシビリティも備えています。つまり、<code><button></code> 同士の間をタブで移動できますし、リターン / エンターを使って <code><button></code> をアクティブにできます。</p> + +<p>もしプロジェクトの最初から首尾一貫して意味的な HTML を書くならば、意味的な HTML を書く方が非意味的な (駄目な) マークアップを書くよりも長くなったりはしません。それに、意味的な HTML には、アクセシビリティ以外の他の利点もあります。</p> + +<ol> + <li><strong>より開発しやすい</strong>——上述のとおり、ある種の機能がただで手に入りますし、それに、より理解しやすいという点はまず間違いないところです。</li> + <li><strong>モバイル機器に関して、より優れている</strong>——意味的な HTML は非意味的なスパゲッティ・コードよりも、ファイルサイズの点でほぼ間違いなく軽量ですし、レスポンシブにするのも簡単です。</li> + <li><strong>SEO に関しても良好である</strong>——検索エンジンは、非意味的な <code><div></code> などに含まれるキーワードよりも、見出しやリンクなどの中のキーワードの方に重みを持たせているので、ドキュメントが顧客に見つけてもらいやすくなるでしょう。</li> +</ol> + +<p>それでは、ここからアクセシブルな HTML をより詳しく見てゆきましょう。</p> + +<div class="note"> +<p><strong>注</strong>: 自分のローカルコンピューターにスクリーンリーダーを用意することは良い考えです。そうすれば、以下に示す例について、ある程度のテストができます。より詳しくは、<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">Screenreaders guide</a> を参照してください。</p> +</div> + +<h2 id="Good_semantics" name="Good_semantics">良いセマンティクス</h2> + +<p>良いセマンティクスの重要性について、そして、ふさわしい役割にふさわしい HTML 要素を使うべきである理由については、すでに述べました。このことは無視してはなりません。なぜなら、適切に扱わないとアクセシビリティがひどく損なわれてしまう主な箇所のうちの一つだからです。</p> + +<p>ウェブ上のどこかで、実は、人々は HTML のマークアップに関してとても変なことをしています。HTML の悪用のうちには、まだ完全に忘れ去られたわけではない過去の遺物的な慣行によるものもあり、ただ単純な無知によるものもあります。いずれにせよ、そうした駄目なコードは、どこで見たものであれ、可能な場合にはいつでも置き換えるべきです。</p> + +<p>ときには、駄目なマークアップを取り去れる状況にいるとは限りません。自分で完全に制御しきれるわけではない、ある種のサーバーサイド・フレームワークによって、生成されたページなのかもしれません。あるいは、自分のページ上に、自分が管理していない (広告バナーのような) 第三者のコンテンツを含むかもしれません。</p> + +<p>しかし、目標は「全か無か」というものではありません。自分ができる改善のことごとくが、アクセシビリティの理念に役立つことでしょう。</p> + +<h3 id="Text_content" name="Text_content">テキストコンテンツ</h3> + +<p>スクリーンリーダーのユーザーが得られる最良のアクセシビリティ支援の一つは、見出しや段落やリストなどの適切なコンテンツ構造です。きちんと意味を備えた例は、以下のようなものになるでしょう。</p> + +<pre class="brush: html example-good line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h1</span><span class="punctuation token">></span></span>見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h1</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>これは文書のうちの最初のセクションです。<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>ここにも、もう一つ段落を足すつもり。<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">> + +<ol> + <li>ここには</li> + <li>読んでもらいたいことの</li> + <li>リストがあります。</li> +</ol></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">></span></span>下位見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>これは文書のうちの最初のサブセクションです。みんながこのコンテンツを見つけられるといいな!<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">></span></span>2 番目の下位見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>これはコンテンツのうちで 2 番目のサブセクションです。この前のものより面白いと思いますよ。<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span></code></pre> + +<p>スクリーンリーダーを使って試せるように、より長いテキストのバージョンを用意してあります (<a href="http://mdn.github.io/learning-area/accessibility/html/good-semantics.html">good-semantics.html</a> を参照)。これの全体をナビゲートして (経巡って) みれば、これはとても見通しが得やすいものだということがわかるでしょう。</p> + +<ol> + <li>コンテンツの中を進んでゆくのにつれて、スクリーンリーダーは各ヘッダを読み上げて、どれが見出しでどれが段落なのかといったことを知らせてくれます。</li> + <li>どのような速度が快適であるにせよ、その速度で進んでいけるように、スクリーンリーダーは各要素の後で停止します。</li> + <li>多くのスクリーンリーダーでは、次の見出し / 前の見出しへとジャンプできます。</li> + <li>多くのスクリーンリーダーでは、すべての見出しの一覧を取り出せます。それらの見出しを、特定のコンテンツを見つけるための手軽な目次のようにも使えます。</li> +</ol> + +<p>ときには、たとえば以下のように、体裁用の HTML や改行を使って見出しや段落などを書く人もいます。</p> + +<pre class="brush: html example-bad line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>7<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +これは文書のうちの最初のセクションです。 +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +ここにも、もう一つ段落を足すつもり。 +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +1. ここには +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +2. 読んでもらいたいことの +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +3. リストがあります。 +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>下位見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +これは文書のうちの最初のサブセクションです。みんながこのコンテンツを見つけられるといいな! +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>2 番目の下位見出し<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +これはコンテンツのうちで 2 番目のサブセクションです。この前のものより面白いと思いますよ。</code></pre> + +<p>より長いバージョンをスクリーンリーダーで試してみれば (<a href="http://mdn.github.io/learning-area/accessibility/html/bad-semantics.html">bad-semantics.html</a> を参照)、とても良い体験が得られる、とはいかないことでしょう。スクリーンリーダーは、標識として使えるものを何も得られないので、有用な目次は取得できません。また、ページ全体を単一の巨大な塊として見ることになるので、ページ全体が一度にひとかたまりで読み上げられるだけなのです。 </p> + +<p>アクセシビリティ以外の他の問題もあります。たとえば、CSS を使ってコンテンツにスタイルをつけることや、あるいは、JavaScript でコンテンツを操作することが、より難しくなるのです。なぜなら、セレクターとして使える要素がないからです。</p> + +<h4 id="Using_clear_language" name="Using_clear_language">明確な言葉を使う</h4> + +<p>使っている言い回しもアクセシビリティに影響を与えることがあります。一般に、過度に複雑ではない、明確な言葉を使うべきです。また、不必要な専門用語 (ジャーゴン) や俗語を使わないようにしましょう。これは、認知的な障害またはその他の障害を抱える人たちの助けとなるだけではありません。母語以外で書かれたテキストの読者や、年少者の助けにもなりますし、実際のところあらゆる人の助けになります! それに加えて、スクリーンリーダーによって明確に読み上げられない言い回しや文字を使うことを避けるように努めるべきです。たとえば、以下のようなことです。</p> + +<ul> + <li>やめられるものなら、ダッシュを使わないようにしましょう。「5–7」と書く代わりに「5 から 7」と書きましょう。</li> + <li>略語を展開しましょう。「Jan」と書く代わりに「January」と書きましょう。</li> + <li>少なくとも一、二回は、頭文字語を展開しましょう。最初の出現箇所で「HTML」と書く代わりに、「Hypertext Markup Language すなわち HTML」と書きましょう。</li> +</ul> + +<h3 id="Page_layouts" name="Page_layouts">ページレイアウト</h3> + +<p>古き悪しき時代には、HTML テーブルを使って (つまり、ヘッダー、フッター、サイドバー、主要コンテンツの列、などなどを含む、別々のテーブル・セルを使って)、ページレイアウトを作成していたものです。これは良い考えではありません。なぜなら、スクリーンリーダーが、こんがらがった読み上げを発する可能性が高いからです。特に、レイアウトが複雑で多くの入れ子になったテーブルがある場合には、そうなりがちです。</p> + +<p><a href="http://mdn.github.io/learning-area/accessibility/html/table-layout.html">table-layout.html</a> の例を試してみてください。これは、以下のような感じになっています。</p> + +<pre class="brush: html"><table width="1200"> + <!-- 主要な見出しの行 --> + <tr id="heading"> + <td colspan="6"> + + <h1 align="center">Header</h1> + + </td> + </tr> + <!-- ナビゲーション・メニューの行 --> + <tr id="nav" bgcolor="#ffffff"> + <td width="200"> + <a href="#" align="center">Home</a> + </td> + <td width="200"> + <a href="#" align="center">Our team</a> + </td> + <td width="200"> + <a href="#" align="center">Projects</a> + </td> + <td width="200"> + <a href="#" align="center">Contact</a> + </td> + <td width="300"> + <form width="300"> + <input type="search" name="q" placeholder="Search query" width="300"> + </form> + </td> + <td width="100"> + <button width="100">Go!</button> + </td> + </tr> + <!-- 間隔をあけるための詰め物の行 --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- 主要なコンテンツと余談の行 --> + <tr id="main"> + <td id="content" colspan="4" bgcolor="#ffffff"> + + <!-- 主要なコンテンツがここに来る --> + </td> + <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top"> + <h2>Related</h2> + + <!-- 余談的コンテンツがここに来る --> + + </td> + </tr> + <!-- 間隔をあけるための詰め物の行 --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- フッターの行 --> + <tr id="footer" bgcolor="#ffffff"> + <td colspan="6"> + <p>©Copyright 2050 by nobody. All rights reversed.</p> + </td> + </tr> + </table></pre> + +<p> スクリーンリーダーを使ってこれを読んで回ろうとすると、おそらくスクリーンリーダーは、見るべきテーブルがありますよ、と教えてくれるでしょう (もっとも、一部のスクリーンリーダーは、テーブル・レイアウトとデータ・テーブルとの違いを推測できるでしょうが)。すると、(使っているスクリーンリーダーによりますが) オブジェクトとしてのテーブルのところまで行って、そのテーブルの項目をそれぞれ別々に見て、それからやっと、テーブルから抜けて元の場所に戻り、コンテンツを読んで回ることを続ける、というふうにせざるを得ない可能性が高いでしょう。</p> + +<p>テーブル・レイアウトは過去の遺物です。テーブル・レイアウトは、CSS のサポートがブラウザに広く行き渡っていなかった当時には意味を持っていましたが、スクリーンリーダーのユーザーに対して混乱を巻き起こします。しかも、他の多くの理由でも有害です (テーブルの乱用ですし、ほぼ間違いなくマークアップをより多く要しますし、デザインの柔軟さを損ねます)。テーブル・レイアウトをしてはなりません!</p> + +<p>直前にした体験を、<a href="http://mdn.github.io/learning-area/html/introduction-to-html/document_and_website_structure/">よりモダンなウェブサイトの構成例</a> (以下のような感じです) と比較することで、上記のような (テーブル・レイアウトは駄目だという) 主張の正しさを確認できます。</p> + +<pre class="brush: html"><header> + <h1>Header</h1> +</header> + +<nav> + <!-- 主なナビゲーションはここです。 --> +</nav> + +<!-- ここにページの主要コンテンツが来ます。 --> +<main> + + <!-- 主要コンテンツは記事を含みます。 --> + <article> + <h2>Article heading</h2> + + <!-- 記事の中身はここです。 --> + </article> + + <aside> + <h2>Related</h2> + + <!-- 余談の中身はここです。 --> + </aside> + +</main> + +<!-- そしてここには、ウェブサイトの全ページを通じて使う主要なフッターが来ます。 --> + +<footer> + <!-- フッターの中身はここです。 --> +</footer></pre> + +<p>よりモダンな構造の例をスクリーンリーダーで試してみれば、もはやレイアウト・マークアップが妨げになることもなく、コンテンツの読み上げを混乱させることもない、とわかるでしょう。また、これは、コード・サイズの点で、より無駄がなく、より小さくなっています。これが意味することは、コードの保守が容易になるということ、そして、ユーザがダウンロードするのに帯域幅が小さくて済むということです (特に、接続が遅い人たちにとってはこれが効きます)。</p> + +<p>レイアウトを作る際に考慮すべきもう一つの事柄は、上記の例に見られるように HTML5 の意味的要素を用いることです (<a href="/ja/docs/Web/HTML/Element#Content_sectioning">コンテンツセクショニング</a> を参照)。 入れ子になった {{htmlelement("div")}} 要素だけを使ってレイアウトを作ることもできますが、適切なセクショニング (区分け) 要素を使って、主要なナビゲーション ({{htmlelement("nav")}}) やフッター ({{htmlelement("footer")}}) や繰り返し現れるコンテンツ単位 ({{htmlelement("article")}}) などを囲う方が良いのです。これらの区分け要素は、いまナビゲートしている最中のコンテンツについての追加的な手がかりをユーザーに与えられるように、スクリーンリーダー (および他のツール) に追加的な意味 (セマンティクス) を提供してくれます (スクリーンリーダー・サポートとはどのようなものなのかについての考え方に関しては、<a href="http://www.weba11y.com/blog/2016/04/22/screen-reader-support-for-new-html5-section-elements/">Screen Reader Support for new HTML5 Section Elements</a> を参照)。</p> + +<div class="note"> +<p><strong>注</strong>: コンテンツは、ちゃんと意味的なものにしておき、レイアウトも魅惑的にしておくだけでなく、ソース順において論理的に意味をなすようにもしておくべきです。あとで CSS を使えば必ず望みどおりの場所にコンテンツを配置できますが、ソース順は、その順で読み始めるのが適切なようにしておくべきです。そうすれば、スクリーンリーダーのユーザーが読み上げさせたものが、意味をなすことでしょう。</p> +</div> + +<h3 id="UI_controls" name="UI_controls">UI コントロール</h3> + +<p>ここで UI コントロールという言葉によって意味しているのは、ユーザーが対話的に操作する対象の、ウェブドキュメントの主要部分のことであり、もっとも一般的には、ボタン、リンク、およびフォーム・コントロールのことです。本節では、そうしたコントロールを作る際に認識しておくべき基本的なアクセシビリティの問題を見てゆきましょう。WAI-ARIA とマルチメディアに関する後続の記事で、UI アクセシビリティの他の側面について見ることにします。</p> + +<p>UI コントロールのアクセシビリティに対する一つの重要な側面は、ブラウザがデフォルトでは 、UI コントロールをキーボードで操作できるようにしている、ということです。このことは、<a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">native-keyboard-accessibility.html</a> の例 (<a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">ソースコード</a> を参照) を用いて試せます。これを新規タブで開いて、タブキーを押してみてください。二、三回押してみた後には、フォーカス可能な異なる要素の間をタブ・フォーカスが動き回り始めたのだと分かるはずです。どの要素にフォーカスが当たっているのかが分かるように、どのブラウザでも、フォーカスの当たっている要素には、ハイライトされたデフォルトのスタイルが付与されます (そのスタイルは、異なるブラウザ間では少し差があります)。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14215/button-focused-unfocused.png" style="border-style: solid; border-width: 1px; display: block; height: 39px; margin: 0px auto; width: 288px;"></p> + +<p>その後、エンターキー / リターンキーを押すと、フォーカスの当たっているリンクをたどることもできますし、または、ボタンを押すこともできますし (ボタンにメッセージ警告を出させるための JavaScript を含めておきました)、あるいは、テキスト入力欄にテキストを入力するためのタイピングを開始することもできます (他のフォーム要素には別のコントロールがあります。たとえば、{{htmlelement("select")}} 要素は、選択肢を表示させることや、上下の矢印キーを用いて選択肢の間を行ったり来たりさせることができます)。</p> + +<div class="note"> +<p><strong>注</strong>: 異なるブラウザでは、異なるキーボード・コントロール・オプションを使用可能としている場合があります。さらに詳しいことは、<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Using native keyboard accessibility</a> を参照してください。</p> +</div> + +<p>こうした振る舞いは、たとえば以下のように単に適切な要素を用いるだけで、本質的にはただで手に入ります。</p> + +<pre class="brush: html example-good"><h1>Links</h1> + +<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p> + +<p>Another link, to the <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p> + +<h2>Buttons</h2> + +<p> + <button data-message="This is from the first button">Click me!</button> + <button data-message="This is from the second button">Click me too!</button> + <button data-message="This is from the third button">And me!</button> +</p> + +<h2>Form</h2> + +<form> + <div> + <label for="name">Fill in your name:</label> + <input type="text" id="name" name="name"> + </div> + <div> + <label for="age">Enter your age:</label> + <input type="text" id="age" name="age"> + </div> + <div> + <label for="mood">Choose your mood:</label> + <select id="mood" name="mood"> + <option>Happy</option> + <option>Sad</option> + <option>Angry</option> + <option>Worried</option> + </select> + </div> +</form></pre> + +<p>これは、リンクやボタンやフォーム要素やラベルを適切に用いることを意味しています (フォーム・コントロール用の {{htmlelement("label")}} 要素を含めています)。</p> + +<p>しかし、またしてもですが、人が HTML で変なことをする場合がときにはあるものです。たとえば、次のように {{htmlelement("div")}} を用いてマークアップしたボタンを見かけることも、ときにはあります。</p> + +<pre class="brush: html example-bad"><div data-message="This is from the first button">Click me!</div> +<div data-message="This is from the second button">Click me too!</div> +<div data-message="This is from the third button">And me!</div></pre> + +<p>しかし、そうしたコードを使うことは、勧められることではありません。単に {{htmlelement("button")}} 要素を使っていたなら得られていたはずの、ネイティブなキーボード・アクセシビリティを直ちに失ってしまううえに、当該ボタンが得るデフォルトの CSS スタイル付けを何も得られないからです。</p> + +<h4 id="Building_keyboard_accessibility_back_in" name="Building_keyboard_accessibility_back_in">キーボード・アクセシビリティを呼び戻すように盛り込む</h4> + +<p>そうした利点を呼び戻すように追加するには、ちょっとした作業が必要です (<a class="external external-icon" href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> で例示的コードを試せます。<a class="external external-icon" href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">ソースコード</a> も参照してください)。ここでは、各ボタンに <code>tabindex="0"</code> という属性を付与することによって、見せかけの <code><div></code> ボタンにフォーカスを当てられるようにしました (タブキーを通じてのフォーカスを含みます)。</p> + +<pre class="brush: html"><div data-message="This is from the first button" tabindex="0">Click me!</div> +<div data-message="This is from the second button" tabindex="0">Click me too!</div> +<div data-message="This is from the third button" tabindex="0">And me!</div></pre> + +<p>基本的には、{{htmlattrxref("tabindex")}} 属性は、タブキーでの移動が可能な要素に、単なるデフォルトのソース順でのタブ移動の代わりとなる特別あつらえのタブ順序 (正数の順で指定されるもの) を持たせられるようにすることを、主に意図したものです。これはほとんどの場合、筋の悪い考え方です。なぜなら、重大な混乱を招きかねないからです。本当に必要な場合にのみ、{{htmlattrxref("tabindex")}} 属性を使うようにしてください。たとえば、レイアウトによって、物事がソースコードとはまるで違った見かけ上の順序で示されており、かつ、より論理的に物事を機能させたいと望んでいるような場合です。<code>tabindex</code> には、あと二つの選択肢があります。</p> + +<ul> + <li><code>tabindex="0"</code> — 上記のとおり、この値によって、普通ならタブキーでの移動が可能ではない要素が、タブキーでの移動が可能となります。これは、<code>tabindex</code> の一番有益な値です。</li> + <li><code>tabindex="-1"</code> — これによって、普通ならタブキーでの移動が可能ではない要素が、(たとえば JavaScript を介して) プログラム的にフォーカスを得たり、あるいはリンクのターゲットとしてフォーカスを得たりすることが可能となります。</li> +</ul> + +<p>上記のような追加作業によって、タブキーでボタンに移動できるようにはなりますが、エンターキー / リターンキーを介してボタンをアクティブにすることはできるようになりません。それを可能とするには、以下のようなちょっとした JavaScript のごまかしを追加せねばなりません。</p> + +<pre class="brush: js line-numbers language-js"><code class="language-js">document<span class="punctuation token">.</span>onkeydown <span class="operator token">=</span> <span class="keyword token">function</span><span class="punctuation token">(</span>e<span class="punctuation token">)</span> <span class="punctuation token">{</span> + <span class="keyword token">if</span><span class="punctuation token">(</span>e<span class="punctuation token">.</span>keyCode <span class="operator token">===</span> <span class="number token">13</span><span class="punctuation token">)</span> <span class="punctuation token">{</span> <span class="comment token">// The Enter/Return key</span> + document<span class="punctuation token">.</span>activeElement<span class="punctuation token">.</span><span class="function token">onclick</span><span class="punctuation token">(</span>e<span class="punctuation token">)</span><span class="punctuation token">;</span> + <span class="punctuation token">}</span> +<span class="punctuation token">}</span><span class="punctuation token">;</span></code></pre> + +<p>ここでは、キーボード上でいつボタンが押されたのかを検出するために、<code>document</code> オブジェクトにリスナーを追加しています。どのボタンが押されたのかを、イベント・オブジェクトの <code><a href="https://developer.mozilla.org/ja/docs/Web/API/KeyboardEvent/keyCode">keyCode</a></code> プロパティを介して調べています。 [訳注: 以上の二つの文の「ボタン」はキーボード上のキーのことのようです。また、<code>keyCode</code> プロパティは非推奨になっています。]もしエンターキー / リターンキーに合致するキーコードだったら、<code>document.activeElement.onclick()</code> を用い、ボタンの <code>onclick</code> ハンドラーに記憶されている関数を実行します [訳注: この文の「ボタン」は <code><div></code> ボタンのことのようです]。<code><a href="https://developer.mozilla.org/ja/docs/Web/API/Document/activeElement">activeElement</a></code> は、ページ上で現在フォーカスの当たっている要素を教えてくれます。</p> + +<div class="note"> +<p><strong>注</strong>: 自分の独自のイベントハンドラーを、イベントハンドラー・プロパティ (たとえば <code>onclick</code>) を介して設定した場合にのみ、この技法がうまくいくだろうということに留意すべきです。<code>addEventListener</code> だと、うまくいきません。</p> +</div> + +<p>これでは、機能を呼び戻すように盛り込むための、余計な厄介ごとの山ですね。それに、これにともなう他の問題もきっとあるはずです。<strong>そもそも、単にふさわしい要素をふさわしい役割に使うべきなのです。</strong></p> + +<h4 id="Meaningful_text_labels" name="Meaningful_text_labels">意味の通るテキストラベル</h4> + +<p>UI コントロールのテキストラベルはあらゆるユーザーにとって大変有益ですが、そうしたラベルを適切なものにしておくことは、とりわけ、障碍のあるユーザーにとって重要です。</p> + +<p>ボタンとリンクテキストのラベルが、理解可能であり、かつ弁別性のあるものになっていることを、確認すべきです。ラベルとして単に「ここをクリック」を使うのはいけません。なぜなら、スクリーンリーダーのユーザーは、ボタンとフォーム・コントロールの一覧をまとめ上げることがあるからです。以下のスクリーンショットは、Mac 上の VoiceOver によって一覧化されたコントロールを示しています。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14335/voiceover-formcontrols.png" style="display: block; height: 604px; margin: 0px auto; width: 802px;"></p> + +<p>ラベルが存在している段落の文脈内においてラベルが意味をなすようにするだけでなく、文脈を離れてもラベルが意味をなすように (ラベルが単独で読まれても意味をなすように) してください。たとえば、以下のものは、良いリンクテキストの例を示しています。</p> + +<pre class="brush: html example-good"><p>クジラは本当にすごい生き物です。<a href="whales.html">クジラについてもっと知ってくださいね</a>。</p></pre> + +<p>しかしこれは駄目なリンクテキストです。</p> + +<pre class="brush: html example-bad"><p>クジラは本当にすごい生き物です。クジラについてもっと知るには、<a href="whales.html">ここをクリックしてください</a>。</p></pre> + +<div class="note"> +<p><strong>注</strong>: リンクの実装とベスト・プラクティスに関するさらなる情報を、<a href="/ja/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks">Creating hyperlinks</a> という記事で知ることができます。また、いくつかの良い例と悪い例を、<a href="http://mdn.github.io/learning-area/accessibility/html/good-links.html">good-links.html</a> と <a href="http://mdn.github.io/learning-area/accessibility/html/bad-links.html">bad-links.html</a> で見ることもできます。</p> +</div> + +<p>フォーム・ラベルも重要です。なぜなら、各フォーム入力欄に何を入力する必要があるのかについての手がかりを与えてくれるからです。以下のものは、十分に筋の通った例のように見えます。</p> + +<pre class="brush: html example-bad">名前を入れてください: <input type="text" id="name" name="name"></pre> + +<p>しかしこれは、障碍のあるユーザーにとって、それほど有用ではありません。このラベルを曖昧性なしにフォーム入力欄に結びつけ、そして、仮に入力欄が見えなくても、入力欄をどう埋めたら良いのかを明確にしてくれるものが、上記の例には何もありません。なんらかのスクリーンリーダーでこの例にアクセスした場合には、「テキストを編集する」のような感じの説明のみが与えられることもあるかもしれません。</p> + +<p>以下のものは、ずっと良い例です。</p> + +<pre class="brush: html example-good"><div> + <label for="name">名前を入れてください:</label> + <input type="text" id="name" name="name"> +</div></pre> + +<p>このようなコードだと、ラベルが明確に入力欄と結びつけられることになります。説明は、(上記のような単なる「テキストを編集する」ではなくて) むしろ「名前を入れてください: テキストを編集する」といった感じのものになるでしょう。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14337/voiceover-good-form-label.png" style="display: block; margin: 0 auto;"></p> + +<p>追加のおまけとして、ほとんどのブラウザにおいて、ラベルをフォーム入力欄に結びつけることは、ラベルをクリックして当該フォーム要素を選択 / アクティブ化することが可能なことを意味します。このことにより、入力欄に対して、より大きなヒット領域を与えることになり、したがって、入力欄が選択しやすくなります。</p> + +<div class="note"> +<p><strong>注</strong>: <a href="http://mdn.github.io/learning-area/accessibility/html/good-form.html">good-form.html</a> と <a href="http://mdn.github.io/learning-area/accessibility/html/bad-form.html">bad-form.html</a> で、いくつかの良いフォーム例と悪いフォーム例を見られます。</p> +</div> + +<h2 id="Accessible_data_tables" name="Accessible_data_tables">アクセシブルなデータテーブル</h2> + +<p>基本的なデータテーブルは、たとえば以下のように、とても簡素なマークアップで書けます。</p> + +<pre class="brush: html"><table> + <tr> + <td>Name</td> + <td>Age</td> + <td>Gender</td> + </tr> + <tr> + <td>Gabriel</td> + <td>13</td> + <td>Male</td> + </tr> + <tr> + <td>Elva</td> + <td>8</td> + <td>Female</td> + </tr> + <tr> + <td>Freida</td> + <td>5</td> + <td>Female</td> + </tr> +</table></pre> + +<p>しかしこれには問題があります。スクリーンリーダーのユーザーには、行または列をデータの集まりとしてまとめて関連づける手段が何もないのです。こうした関連づけを行うには、見出し行がどれなのか、見出し行は複数の行を統率しているのか、複数の列を統率しているのか、などといったことを知らねばなりません。こうしたことは、上記のテーブルでは、視覚的に行われる以外にありません (<a href="http://mdn.github.io/learning-area/accessibility/html/bad-table.html">bad-table.html</a> を参照して、その例をご自分で試してみてください)。</p> + +<p>では、 <a href="https://github.com/mdn/learning-area/blob/master/css/styling-boxes/styling-tables/punk-bands-complete.html">パンクバンドのテーブルの例</a> を見てみましょう。ここでは、多少のアクセシビリティ支援が機能していることが分かりますね。</p> + +<ul> + <li>テーブルの見出しは、 {{htmlelement("th")}} 要素を用いて定義されています。さらに、<code>scope</code> 属性を使って、その見出しが行に対する見出しなのか列に対する見出しなのかを指定することもできます。こうすると、スクリーンリーダーが一つの単位として処理できる、データの完全なグループが示されることになります。</li> + <li>{{htmlelement("caption")}} 要素と、<code><table></code> の <code>summary</code> 属性は、どちらも似たような役割を果たします。テーブルに対する alt テキストとして機能し、スクリーンリーダーのユーザーに対して、テーブルの中身についての有用で手短な要約を示すのです。<code><caption></code> が一般に好ましいのですが、それは、晴眼者のユーザーに対しても <code><caption></code> の中身がアクセシブルだからであり、晴眼者のユーザーもその中身を有用だと思うでしょう。実際には、(必ずしも) 二つとも必要というわけではありません。</li> +</ul> + +<div class="note"> +<p><strong>注</strong>: アクセシブルなデータテーブルにまつわる更なる詳細は、<a href="/ja/docs/Learn/HTML/Tables/Advanced">HTML テーブルの発展的な機能とアクセシビリティ</a> という記事を参照してください。</p> +</div> + +<h2 id="Text_alternatives" name="Text_alternatives">代替テキスト</h2> + +<p>テキストによるコンテンツは本質的にアクセシブルですが、マルチメディア・コンテンツについては必ずしも同じことが言えるわけではありません。画像 / 動画コンテンツは視覚障碍者には見えず、音声コンテンツは聴覚障碍者には聞こえません。動画と音声のコンテンツについては、<a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a> という記事で後に詳しく扱うことにしますが、本記事では、ごく普通の {{htmlelement("img")}} 要素についてのアクセシビリティを見てゆきましょう。</p> + +<p><a href="http://mdn.github.io/learning-area/accessibility/html/accessible-image.html">accessible-image.html</a> という簡単な例を書き上げました。これは、4 枚の同じ画像を含んでいます。</p> + +<pre><img src="dinosaur.png"> + +<img src="dinosaur.png" + alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."> +<!-- +[alt 属性の訳: 赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります。] +--> + +<img src="dinosaur.png" + alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth." + title="The Mozilla red dinosaur"> +<!-- +[alt 属性の訳: 赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります。] +[title 属性の訳: Mozzila の赤い恐竜] +--> + +<img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.</p> +<!-- +[p 要素の中身の訳: Mozilla の赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります。] +--></pre> + +<p>1 枚目の画像は、スクリーンリーダーで見たときに、実際のところ大した手助けをユーザーに与えてはくれません。たとえば VoiceOver は、「/dinosaur.png, image」と読み上げます。なんらかの手助けを提供しようとしてファイル名を読み上げるわけです。この例では、ユーザーは、少なくともこれがある種の恐竜なのだと知ることでしょうが、機械で生成されたファイル名とともにファイルが (たとえばディジタルカメラから) アップロードされる場合もよくありますし、そうしたファイル名は画像の中身に対する文脈を何も与えてはくれないでしょう。</p> + +<div class="note"> +<p><strong>注</strong>: これこそが、画像の内部にテキストコンテンツを決して含めるべきではない理由です。スクリーンリーダーは、まったくそのテキストコンテンツにアクセスできません。それに、他の欠点もあります。すなわち、そのテキストコンテンツを選択することもコピー / ペーストすることもできません。画像の内部にテキストコンテンツを含めるなどということは、とにかくしないでください!</p> +</div> + +<p>スクリーンリーダーは、2 枚目の画像に出くわすと、alt 属性を丸々読み上げます。つまり、「赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります」と読み上げます。</p> + +<p>この例は、いわゆる <strong>alt テキスト</strong>が万一使えない場合に備えて意味のあるファイル名を使うことだけでなく、可能な場合にはいつでも alt テキストを <code>alt</code> 属性において確実に提供しておくことの重要性を、際立たせるものです。<code>alt</code> 属性の中身は常に、画像の端的な描写と、画像が視覚的に伝えているものとを提供すべきであることに、注意してください。ここには、個人的な知識や追加的な説明を何も含めるべきではありません。なぜなら、以前にその画像に出くわしたことのない人にとって有益ではないからです。</p> + +<p>考えるべきことの一つは、画像がコンテンツの内部で意味を持っているのか、あるいは、純粋に視覚的装飾のためのものであって意味は持たないのか、ということです。もし画像が装飾用であれば、その画像を CSS 背景画像としてページ内に含めるだけにする方が良いのです。</p> + +<div class="note"> +<p><strong>注</strong>: 画像の実装とベスト・プラクティスについての更なる多くの情報については、<a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML">Images in HTML</a> と <a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a> をお読みください。</p> +</div> + +<p>文脈のある追加的な情報をどうしても提示したい場合、その情報は、画像の周囲のテキストの中か、あるいは、上記のように <code>title</code> 属性の内部に入れるべきです。この場合、ほとんどのスクリーンリーダーは、<code>alt</code> テキストと、<code>title</code> 属性と、ファイル名とを読み上げるでしょう。さらに、マウスオーバーしたときには、ブラウザが <code>title</code> テキストをツールチップとして表示します。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14333/title-attribute.png" style="display: block; margin: 0 auto;"></p> + +<p>4 番目の方法についてもざっと見ておきましょう。</p> + +<pre class="brush: html"><img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">The Mozilla red Tyrannosaurus ... </p></pre> + +<p>この場合、<code>alt</code> 属性をまったく使っていません。その代わり、画像についての説明を通常のテキスト段落として提示し、その段落に <code>id</code> を与え、そして、その <code>id</code> を参照するための <code>aria-labelledby</code> 属性を用いました。こうすると、スクリーンリーダーに、その段落をその画像についての alt テキスト / ラベルとして使わせることになります。これは、複数の画像に対して同じテキストをラベルとして使いたい場合に、とりわけ有用です (こうしたことは、<code>alt</code> を使ってではできない事柄なのです)。</p> + +<div class="note"> +<p><strong>注</strong>: <code>aria-labelledby</code> は <a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> 仕様の一部です。これのおかげで開発者は、必要な箇所においてスクリーンリーダーのアクセシビリティを高めるために、自分のマークアップに追加的な意味 (セマンティクス) を足すことができます。これがどのように機能するのかについての更なる情報を知るには、<a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a> の記事をお読みください。</p> +</div> + +<h3 id="Other_text_alternative_mechanisms" name="Other_text_alternative_mechanisms">その他の代替テキストの仕組み</h3> + +<p>画像には、説明的テキストを提供するのに利用可能な別の仕組みもあります。たとえば、画像についての広範囲にわたる説明を含む別のウェブドキュメントを指すことを意図した、<code>longdesc</code> 属性があります。たとえば以下のようなものです。</p> + +<pre class="brush: html"><img src="dinosaur.png" longdesc="dino-info.html"></pre> + +<p>これは良い考えのように思えます。というのも、とりわけ、多くの情報が載っている大きな図表のようなインフォグラフィックを、代わりにアクセシブルなデータテーブル (前節を参照) として表現することがおそらくは可能でしょうから。しかし、<code>longdesc</code> は、スクリーンリーダーによっていつもサポートされているわけではありませんし、スクリーンリーダー以外のものを使っているユーザーにとっては、コンテンツがまったくアクセス不能です。まず間違いなく、画像と同じページに長い説明を含めるか、あるいは、通常のリンクを使って長い説明にリンクする方が、ずっと良いのです。</p> + +<p>HTML5 は、{{htmlelement("figure")}} と {{htmlelement("figcaption")}} という二つの新規要素を含みます。これらは、なんらかの種類の図面 (任意のものであってよく、必ずしも画像とは限りません) を、図面キャプション (説明文) と結びつけることになっているものです。</p> + +<pre class="brush: html"><figure> + <img src="dinosaur.png" alt="Mozilla のティラノサウルス"> + <figcaption>赤いティラノサウルス・レックス。人間のように直立する二足歩行の恐竜で、腕は小さく、頭部は大きくて多くの鋭い歯があります。</figcaption> +</figure></pre> + +<p>あいにく、ほとんどのスクリーンリーダーは、まだ、図面キャプションを図面と結びつけてはくれないようです。ですが、この要素構造は CSS でのスタイルづけにとって有益ですし、ソース内で画像の隣にその画像の説明を配置するための手段を与えてもくれます。</p> + +<h3 id="Empty_alt_attributes" name="Empty_alt_attributes">空の代替テキスト</h3> + +<pre class="brush: html"><h3> + <img src="article-icon.png" alt=""> + ティラノサウルス・レックス: 恐竜の王 +</h3></pre> + +<p>画像がページのデザインに含まれるけれども、主目的は視覚的装飾である、といった場合もあるかもしれません。上記のコード例において、画像の <code>alt</code> 属性が空であることにお気づきでしょう。これは、スクリーンリーダーに画像を認識させるものですが、その画像を説明しようとさせるものではありません (説明する代わりに、スクリーンリーダーは、単に「画像」とか何とか言うでしょう)。</p> + +<p><code>alt</code> を含めないようにする代わりに空の <code>alt</code> を用いる理由は、<code>alt</code> が与えられていない場合には多くのスクリーンリーダーが画像の URL を丸々全部発声するからです。上記の例において画像は、その画像が結びつけられている見出しに対する視覚的装飾として機能しています。このような場合、および、画像が単に装飾にすぎず中身の価値がない場合には、画像に空の <code>alt</code> を入れるべきです。別の選択肢は、<code>role="presentation"</code> という ARIA <code>role</code> 属性を使うことです。こうすることによっても、スクリーンリーダーに代替テキスト (<code>alt</code> テキスト) を読み上げるのをやめさせることができます。</p> + +<div class="note"> +<p><strong>注</strong>: もし可能なら、単なる修飾であるような画像を表示するのには CSS を使うべきです。</p> +</div> + +<h2 id="Summary" name="Summary">要約</h2> + +<p> 今や読者の皆さんは、ほとんどの場合にアクセシブルな HTML を書くことについて、熟知しているはずです。<a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a> の記事も、この知識の抜けを埋めてくれるでしょうが、本記事でもその基本には気を配ってきました。次は、CSS と JavaScript を検討しましょう。そして、CSS と JavaScript の良い使い方やまずい使い方によって、アクセシビリティがどのような影響を受けるのかを検討しましょう。</p> + +<p>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</p> + +<p> </p> + +<h2 id="In_this_module" name="In_this_module">このモジュール内</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは?</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></li> +</ul> + +<p> </p> diff --git a/files/ja/learn/accessibility/index.html b/files/ja/learn/accessibility/index.html new file mode 100644 index 0000000000..eb71416a85 --- /dev/null +++ b/files/ja/learn/accessibility/index.html @@ -0,0 +1,63 @@ +--- +title: アクセシビリティ +slug: Learn/Accessibility +tags: + - ARIA + - Accessibility + - Articles + - Beginner + - CSS + - CodingScripting + - HTML + - JavaScript + - Landing + - Learn + - Module + - アクセシビリティ + - ランディング + - 初心者 +translation_of: Learn/Accessibility +--- +<div>{{LearnSidebar}}</div> + +<p class="summary">ウェブ開発者になりたい場合、HTML, CSS, JavaScript の学習は役立ちます。しかし知識は単に技術を使うよりも前に進める必要があります — それらを責任を持って使う必要があり、その結果ウェブサイトの聴衆を増やし、またそれを使わないことに縛らないことになります。これを達成するには、一般的な成功事例 (<a href="/ja/docs/Learn/HTML">HTML</a>, <a href="/ja/docs/Learn/CSS">CSS</a>, <a href="/ja/docs/Learn/JavaScript">JavaScript</a> のトピックに示されています) を積み上げ、<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing">クロスブラウザーテスト</a>を行って、最初からアクセシビリティを考慮しておきます。このモジュールでは後者を詳しく扱います。</p> + +<h2 id="Prerequisites" name="Prerequisites">前提知識</h2> + +<p>このモジュールの大半の理解には、少なくとも <a href="/ja/docs/Learn/HTML">HTML</a>, <a href="/ja/docs/Learn/CSS">CSS</a>, <a href="/ja/docs/Learn/JavaScript">JavaScript</a> の最初の 2 モジュールを通して読むのが良いでしょうし、 たぶんもっと良いのは、関連するテクノロジートピックを進めるにつれて、関連するアクセシビリティの部分を進めるのが良いでしょう。</p> + +<div class="note"> +<p><strong>メモ</strong>: 自分のファイルを作れない コンピューター/タブレット/その他の端末で作業する場合、コードの実例の大半を <a href="http://jsbin.com/">JSBin</a> や <a href="https://glitch.com/">Glitch</a> などのオンラインコーディングプログラム内で試すことができます。</p> +</div> + +<h2 id="Guides" name="Guides">ガイド</h2> + +<dl> + <dt><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは？</a></dt> + <dd>この記事では実際アクセシビリティとは何かについてよく観察するモジュールから開始します — これには考慮が必要な人のグループや、いろいろな人がウェブとやり取りするのになぜ、どんなツールを使うのかや、アクセシビリティをウェブ開発の作業フローに取り組む方法が含まれます。</dd> + <dt><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></dt> + <dd>ウェブコンテンツをアクセシビリティ高くすることの多くの部分は、どんなときも正しい HTML要素を正しい目的で使うことです。 この記事ではアクセシビリティを最大化するためにどう HTML が使われるかの詳細を見ていきます。</dd> + <dt><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティ成功事例</a></dt> + <dd>CSS と JavaScript も、適切に使うと、アクセシビリティの高いウェブ体験を可能にする力を持っていますが、誤用されると目立ってアクセシビリティを害することもあります。この記事では、複雑なコンテンツでもなるべくアクセシビリティ高める CSS と JavaScript のいくつかの成功事例をざっと見ます。</dd> + <dt><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></dt> + <dd>前の記事に続いて、複雑な UI に非セマンティックな HTML や動的な JavaScript-更新コンテンツを作ることは難しいかもしれません。WAI-ARIA は、そうした問題をブラウザーと補助技術が認識できるセマンティクスを追加することで補助し、ユーザーに何が起きているのかを知らせるのに使うテクノロジーです。ここではアクセシビリティを改善する基本レベルの使用方法を示します。</dd> + <dt><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></dt> + <dd>アクセシビリティの問題を起こす可能性がある他のカテゴリは、マルチメディアです。ビデオ、オーディオ、およびイメージのコンテンツには、補助技術とユーザーが理解できるような、適切な代替テキストを付与する必要があります。どのように表示されるべきか分かるように。</dd> + <dt><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルアクセシビリティ</a></dt> + <dd>モバイル端末でのウェブへのアクセスが増えるとともに、アクセシビリティのツールが本格的に提供されている iOS や Android のような一般的なプラットフォームが普及しています。これらのプラットフォームでのあなたのウェブコンテンツのアクセシビリティを考えることが重要です。モバイル特有のアクセシビリティについて検討しましょう。</dd> +</dl> + +<h2 id="Assessments" name="Assessments">評価</h2> + +<dl> + <dt><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></dt> + <dd>このモジュールの評価では、分析と修正が必要な多くのアクセシビリティの問題があるシンプルなサイトを紹介します。</dd> +</dl> + +<h2 id="See_also" name="See_also">関連情報</h2> + +<ul> + <li><a href="https://egghead.io/courses/start-building-accessible-web-applications-today">Start Building Accessible Web Applications Today</a> — Marcy Sutton によるすばらしい動画チュートリアル</li> + <li><a href="https://dequeuniversity.com/resources/">Deque University resources</a> — コードサンプルやスクリーンリーダーリファレンスやその他の役立つリソースを含む</li> + <li><a href="http://webaim.org/resources/">WebAIM resources</a> — ガイド、チェックリスト、ツールなどを含む</li> +</ul> diff --git a/files/ja/learn/accessibility/mobile/index.html b/files/ja/learn/accessibility/mobile/index.html new file mode 100644 index 0000000000..24cad97ef9 --- /dev/null +++ b/files/ja/learn/accessibility/mobile/index.html @@ -0,0 +1,316 @@ +--- +title: モバイルのアクセシビリティ +slug: Learn/Accessibility/Mobile +tags: + - Accessibility + - コードスクリプト + - スクリーンリーダー + - タッチ + - モバイル + - レスポンシブ + - 初心者 + - 学習 + - 記事 +translation_of: Learn/Accessibility/Mobile +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<p class="summary">モバイルデバイスでのウェブアクセスは非常に人気があり、iOS や Android などの一般的なプラットフォームには本格的なアクセシビリティツールが備わっているため、これらのプラットフォームでのウェブコンテンツのアクセシビリティを考慮することが重要です。この記事では、モバイル固有のアクセシビリティについて検討します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識</th> + <td>基本的なコンピューターの知識、HTML、CSS、JavaScript の基本的な知識、<a href="/ja/docs/Learn/Accessibility">前回までの記事</a>の理解。</td> + </tr> + <tr> + <th scope="row">学習目標</th> + <td>モバイルデバイスのアクセシビリティにどのような問題があるのか、またそれらを克服する方法を理解すること。</td> + </tr> + </tbody> +</table> + +<h2 id="Accessibility_on_mobile_devices" name="Accessibility_on_mobile_devices">モバイルデバイスのアクセシビリティ</h2> + +<p>アクセシビリティの現状と、ウェブ標準全般のサポートは、現代のモバイルデバイスでは優れています。モバイルデバイスがデスクトップブラウザーとはまったく異なるウェブ技術を実行し、開発者がブラウザースニッフィングを使用してそれらを完全に別々のサイトで提供することを余儀なくされた時代は終わりました（ただし、かなりの数の企業が依然としてモバイルデバイスの使用を検出し、それらに別のモバイルドメインを提供しています）。</p> + +<p>最近の一般的なモバイルデバイスは、「脂肪分たっぷり」のウェブサイトを扱うことができ、主なプラットフォームには視覚障害のあるユーザーがそれらをうまく使えるようにスクリーンリーダーが組み込まれています。最近のモバイルブラウザーは <a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> もよくサポートしています。</p> + +<p>ウェブサイトをモバイルでアクセス可能かつ使用可能にするには、一般的な優れたウェブデザインとアクセシビリティのベストプラクティスに従う必要があるだけです。</p> + +<p>モバイルに特別な配慮が必要な例外がいくつかあります。主なものは次のとおりです。</p> + +<ul> + <li>制御機構 — ボタンのようなインターフェイスのコントロールが、デスクトップやラップトップ（主にマウスとキーボード）と同様に、モバイル（主にタッチスクリーン）でアクセス可能であることを確認する。</li> + <li>ユーザー入力 — モバイルでのユーザー入力要件をできるだけ苦痛でないものにします（例えば、フォームでは、タイピングを最小限に抑えます）。</li> + <li>レスポンシブデザイン — レイアウトがモバイルで機能することを確認し、画像のダウンロードサイズを節約し、高解像度画面用の画像の提供について検討します。</li> +</ul> + +<h2 id="Summary_of_screenreader_testing_on_Android_and_iOS" name="Summary_of_screenreader_testing_on_Android_and_iOS">Android および iOS でのスクリーンリーダーテストの概要</h2> + +<p>最も一般的なモバイルプラットフォームは完全に機能的なスクリーンリーダーを持っています。これらはデスクトップのスクリーンリーダーとほとんど同じように機能しますが、キーの組み合わせではなくタッチジェスチャーを使用して主に操作される点が異なります。</p> + +<p>主な 2 つを見てみましょう: Android の TalkBack と iOS の VoiceOver です。</p> + +<h3 id="Android_TalkBack" name="Android_TalkBack">Android TalkBack</h3> + +<p>TalkBack スクリーンリーダーは Android オペレーティングシステムに組み込まれています。</p> + +<p>オンにするには、スマートフォンのモデルと Android バージョンを調べて、TalkBack メニューの場所を探します。これは Android のバージョンやスマートフォンのモデルによっても大きく違います。あるスマートフォンメーカー(Samusung など)では、最新の機種で TalkBack がなくて、代わりに独自のスクリーンリーダーを選んでいることもあります。</p> + +<p>TalkBack メニューが見つかったら、スライダースイッチを押してオンにします。画面に表示される追加の指示に従います。</p> + +<p>TalkBack がオンになっているとき、あなたの Android デバイスの基本的なコントロールは少し違います。例えば、</p> + +<ol> + <li> アプリをシングルタップするとそれが選択され、デバイスはそのアプリが何かを読み上げます。</li> + <li>左右にスワイプすると、アプリ間、またはコントロールバーにいる場合はボタンやコントロールの間を移動します。デバイスは各オプションを読み上げます。</li> + <li>どこでもダブルタップするとアプリが開いたり、オプションが選択されたりします。</li> + <li>また、「タッチで探索」することもできます — ドラッグ（指を画面に置いたまま移動）すると、デバイスは移動先のさまざまなアプリや項目を読み上げます。</li> +</ol> + +<p>TalkBack をオフにしたい場合は、</p> + +<ol> + <li>上記のジェスチャーを使用して [設定] アプリに移動します。</li> + <li>[ユーザー補助] > [TalkBack] に移動します。</li> + <li>スライダースイッチに移動してアクティブにすると、オフになります。</li> +</ol> + +<div class="blockIndicator note"> +<p><strong>注</strong>: 連続した動きで上にスワイプしてから左にスワイプすると、いつでもホーム画面にアクセスできます。複数のホーム画面がある場合は、左右に 2本指でスワイプすることでそれらの間を移動できます。</p> +</div> + +<p>TalkBack ジェスチャーのより完全なリストについては、<a href="https://support.google.com/accessibility/android/answer/6151827?hl=ja">TalkBack ジェスチャーを利用する</a>を参照してください。</p> + +<h4 id="Unlocking_the_phone" name="Unlocking_the_phone">端末のロックを解除する</h4> + +<p>TalkBack がオンになっているとき、端末のロック解除は少し違います。</p> + +<p>ロック画面の下から上に 2本指でスワイプすることができます。デバイスのロックを解除するためのパスコードまたはパターンを設定している場合は、関連する入力画面に移動して入力します。</p> + +<p>画面の中央下部にある [ロック解除] ボタンをタッチで探索してから、ダブルタップすることもできます。</p> + +<h4 id="Global_and_local_menus" name="Global_and_local_menus">グローバルメニューとローカルメニュー</h4> + +<p>TalkBack を使用すると、デバイス上のどこに移動しても、グローバルおよびローカルのコンテキストメニューにアクセスできます。前者はデバイス全体に関するグローバルオプションを提供し、後者は現在のアプリや画面だけに関するオプションを提供します。</p> + +<p>これらのメニューにアクセスするには、</p> + +<ol> + <li>すばやく下にスワイプしてから右にスワイプしてグローバルメニューにアクセスします。</li> + <li>すばやく上にスワイプしてから右にスワイプしてローカルメニューにアクセスします。</li> + <li>左右にスワイプしてさまざまなオプションを切り替えます。</li> + <li>必要なオプションを選択したら、ダブルタップしてそのオプションを選択します。</li> +</ol> + +<p>グローバルおよびローカルのコンテキストメニューで使用可能なすべてのオプションの詳細については、<a href="https://support.google.com/accessibility/android/answer/6007066?hl=ja">グローバル コンテキストメニューとローカル コンテキスト メニューを使う</a>を参照してください。</p> + +<h4 id="Browsing_web_pages" name="Browsing_web_pages">ウェブページのブラウジング</h4> + +<p>ウェブブラウザーでローカルコンテキストメニューを使用して、見出し、フォームコントロール、リンク、行単位の移動などウェブページを移動するためのオプションを見つけることができます。</p> + +<p>例えば、TalkBack をオンにした場合、</p> + +<ol> + <li>ウェブブラウザーを開きます。</li> + <li>URL バーをアクティブにします。</li> + <li>Ebbc.co.uk のフロントページのように、見出しがたくさんあるウェブページを入力します。URL のテキストを入力するには、 + <ul> + <li>URL バーが得られるまで左右にスワイプしてから、ダブルタップして URL バーを選択します。</li> + <li>目的の文字が得られるまで仮想キーボードに指を置いたまま動かしてから、指を離して入力します。これを各文字について繰り返します。</li> + <li>終わったら、<kbd>Enter</kbd> キーを見つけて押します。</li> + </ul> + </li> + <li>左右にスワイプすると、ページ上のさまざまな項目間を移動できます。</li> + <li>連続した動きで上にスワイプしてから右にスワイプして、ローカルコンテキストメニューに入ります。</li> + <li>[見出しとランドマーク] オプションが見つかるまで右にスワイプします。</li> + <li>ダブルタップして選択します。これで、見出しと ARIA のランドマークの間を移動するために左右にスワイプすることができます。</li> + <li>デフォルトモードに戻るには、上にスワイプしてから右にスワイプしてローカルコンテキストメニューに再度入り、[デフォルト] を選択してからダブルタップしてアクティブにします。</li> +</ol> + +<p><strong>注</strong>: より完全なドキュメントは <a href="https://support.google.com/accessibility/android/answer/6283677?hl=ja">Android で TalkBack を使ってみる</a>をご覧ください。</p> + +<h3 id="iOS_VoiceOver" name="iOS_VoiceOver">iOS VoiceOver</h3> + +<p>VoiceOver のモバイル版は iOS オペレーティングシステムに組み込まれています。</p> + +<p>それをオンにするには、あなたの設定アプリに行き、[一般] > [アクセシビリティ] > [VoiceOver] を選択してください。VoiceOver スライダを押して有効にします（このページには VoiceOver に関連する他の多数のオプションも表示されます）。</p> + +<div class="blockIndicator note"> +<p><strong>記</strong>: 古い iOS 端末では VoiceOver メニューは <em>設定</em> > <em>一般</em> > <em>アクセシビリティ</em> > <em>VoiceOver</em>にあります。</p> +</div> + +<p>VoiceOver が有効になると、iOS の基本的なコントロールジェスチャーは次のように少し違います。</p> + +<ol> + <li>シングルタップすると、タップした項目が選択されます。デバイスはあなたがタップした項目を読み上げるでしょう。</li> + <li>左右にスワイプして項目間を移動したり、画面上で指をスライドさせてさまざまな項目間を移動したりして、画面上の項目を移動することもできます（必要な項目が見つかったら、指を離して選択できます）。</li> + <li>選択した項目をアクティブにする（例えば、選択したアプリを開く）には、画面上のどこでもダブルタップします。</li> + <li>3本指でスワイプしてページをスクロールします。</li> + <li>カメラアプリで写真を撮るなど、状況に応じたアクションを実行するには、2本指でタップします。</li> +</ol> + +<p>もう一度オフにするには、上記のジェスチャを使用して [設定] > [一般] > [アクセシビリティ] > [VoiceOver] に戻り、[VoiceOver] スライダをオフに切り替えます。</p> + +<h4 id="Unlock_phone" name="Unlock_phone">端末のロック解除</h4> + +<p>端末のロックを解除するには、通常どおりホームボタンを押す（またはスワイプする）必要があります。パスコードが設定されている場合は、上で説明したようにスワイプ/スライドして各番号を選択し、次に正しい番号を見つけたらダブルタップして各番号を入力できます。</p> + +<h4 id="Using_the_Rotor" name="Using_the_Rotor">ローターを使用する</h4> + +<p>VoiceOver がオンになっているとき、ローターと呼ばれるナビゲーション機能を使えます。それは素早く多くの一般的で役に立つオプションから選ぶことを可能にします。それを使用するには、</p> + +<ol> + <li>ダイヤルを回すように、画面上で 2本の指をひねります。あなたがさらにひねるにつれて、各オプションを読み上げるでしょう。あなたは行ったり来たりしてオプションを切り替えることができます。</li> + <li>あなたが望むオプションを見つけたら、 + <ul> + <li>指を離して選択します。</li> + <li>それが（音量や話す速度のような）値を反復できるオプションである場合は、選択した項目の値を増減するために上下にスワイプすることができます。</li> + </ul> + </li> +</ol> + +<p>ローターで利用可能なオプションは状況依存型です — それらはどのアプリやビューにいるかによって異なります（例については下記を参照）。</p> + +<h4 id="Browsing_web_pages_2" name="Browsing_web_pages_2">ウェブページのブラウジング</h4> + +<p>VoiceOver を使ったウェブブラウジングを試してみましょう。</p> + +<ol> + <li>ウェブブラウザーを開きます。</li> + <li>URL バーをアクティブにします。</li> + <li>bbc.co.uk のフロントページのように、見出しがたくさんあるウェブページを入力します。URL のテキストを入力するには、 + <ul> + <li> URL バーが得られるまで左右にスワイプしてダブルタップし、URL バーを選択します。</li> + <li>各文字について、目的の文字が得られるまで仮想キーボードに指を置いたまま動かしてから、指を離して選択します。ダブルタップして入力します。</li> + <li>終ったら、<kbd>Enter</kbd> キーを見つけて押します。</li> + </ul> + </li> + <li>左右にスワイプすると、ページ上の項目間を移動できます。項目をダブルタップして選択することができます（例えば、リンクをたどる）。</li> + <li>デフォルトでは、選択されたローターオプションは話す速度です。現在は上下にスワイプして話す速度を上げ下げできます。</li> + <li>今、ダイヤルのように 2本指で画面を回転させてローターを表示し、ローターのオプション間を移動します。利用可能なオプションの例をいくつか示します。 + <ul> + <li>話す速度: 話す速度を変更します。</li> + <li>コンテナ: ページ上のさまざまな意味論的コンテナ間を移動します。</li> + <li>見出し: ページ上の見出し間を移動します。</li> + <li>リンク: ページ上のリンク間を移動します。</li> + <li>フォームコントロール: ページ上のフォームコントロール間を移動します。</li> + <li>言語: 利用可能な場合は、さまざまな翻訳間を移動します。</li> + </ul> + </li> + <li>見出しを選択します。これで、上下にスワイプしてページ上の見出し間を移動できます。</li> +</ol> + +<p>注: 利用可能な VoiceOver ジェスチャおよび iOS でのアクセシビリティテストに関するその他のヒントを網羅した詳細なリファレンスについては、<a href="https://developer.apple.com/library/archive/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html">VoiceOver を使用してデバイスのアクセシビリティをテストする</a>（英語）を参照してください。</p> + +<h2 id="Control_mechanisms" name="Control_mechanisms">制御機構</h2> + +<p>CSS および JavaScript のアクセシビリティの記事では、特定の種類の制御機構に固有のイベントの概念を調べました（<a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript#mouse-specific_events">マウスに特有のイベント</a>を参照）。要約すると、他の制御機構は関連する機能をアクティブにできないため、これらはアクセシビリティの問題を引き起こします。</p> + +<p>例えば、<a href="/ja/docs/Web/API/GlobalEventHandlers/onclick">click</a> イベントはアクセシビリティの点で優れています — 関連付けられているイベントハンドラは、ハンドラが設定されている要素をクリックするか、タブ移動して <kbd>Enter</kbd> / <kbd>Return</kbd> キーを押すか、タッチスクリーンデバイスでタップすることで起動できます。<a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-button-example.html">simple-button-example.html</a> の例を試してみてください（<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-button-example.html">ライブで動いているのを見る</a>）。</p> + +<p>あるいは、<a href="/ja/docs/Web/API/GlobalEventHandlers/onmousedown">mousedown</a> や <a href="/ja/docs/Web/API/GlobalEventHandlers/onmouseup">mouseup</a> のようなマウス固有のイベントは問題を引き起こします — それらのイベントハンドラはマウス以外の制御を使って呼び出すことはできません。</p> + +<p>キーボードまたはタッチで、<a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-box-drag.html">simple-box-drag.html</a> の例を制御しようとすると、問題が発生します（<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-box-drag.html">ライブで例を見る</a>）。これは、次のようなコードを使用しているために発生します。</p> + +<pre><code>div.onmousedown = function() { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + movePanel(); +} + +document.onmouseup = stopMove;</code></pre> + +<p>他の形式の制御を有効にするには、異なるが同等のイベントを使用する必要があります — 例えば、タッチイベントはタッチスクリーンデバイスで機能します。</p> + +<pre><code>div.ontouchstart = function(e) { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + positionHandler(e); + movePanel(); +} + +panel.ontouchend = stopMove;</code></pre> + +<p>マウスイベントとタッチイベントを一緒に使用する方法を示す簡単な例を示しました — <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/multi-control-box-drag.html">multi-control-box-drag.html</a> を参照してください（<a href="http://mdn.github.io/learning-area/accessibility/mobile/multi-control-box-drag.html">この例もライブで見てください</a>）。</p> + +<p><strong>注</strong>: <a href="/ja/docs/Games/Techniques/Control_mechanisms">ゲーム制御機構の実装</a>では、さまざまな制御機構を実装する方法を示す完全に機能する例も見ることができます。</p> + +<h2 id="Responsive_design" name="Responsive_design">レスポンシブデザイン</h2> + +<p><a href="/ja/docs/Web/Progressive_web_apps">レスポンシブデザイン</a>は、画面のサイズや解像度などの要因に応じて、レイアウトやその他のアプリの機能を動的に変更することです。だから、さまざまなデバイスタイプのユーザーにとって使用可能でアクセス可能です。</p> + +<p>特に、モバイルに関して対処する必要がある最も一般的な問題は次のとおりです。</p> + +<ul> + <li>モバイルデバイス用のレイアウトの適合性。例えば、複数列のレイアウトは狭い画面ではうまくいきませんし、見やすくするためにテキストサイズを大きくする必要があるかもしれません。このような問題は、<a href="/ja/docs/Web/CSS/Media_Queries">メディアクエリ</a>、<a href="/ja/docs/Mobile/Viewport_meta_tag">ビューポート</a>、<a href="/ja/docs/Learn/CSS/CSS_layout/Flexbox">フレックスボックス</a>などの技術を使用してレスポンシブレイアウトを作成することで解決できます。</li> + <li>ダウンロードした画像サイズを節約する。一般的に、小型画面のデバイスは、デスクトップと同等の大きさの画像を必要としませんし、低速のネットワーク接続上にある可能性が高くなります。したがって、必要に応じて狭い画面のデバイスに小さい画像を提供することが賢明です。<a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">レスポンシブ画像のテクニック</a>を使用してこれを扱えます。</li> + <li>高解像度について考える。多くのモバイルデバイスは高解像度の画面を持っているため、ディスプレイがくっきりと鮮明に見えるようにするために、より高解像度の画像が必要です。ここでも、レスポンシブ画像テクニックを使用して、必要に応じて画像を提供できます。さらに、SVG ベクター画像フォーマットを使用して多くの画像要件を満たすことができます。これは今日のブラウザー間で十分にサポートされています。SVG はファイルサイズが小さく、表示されているサイズに関係なく鮮明に保たれます（詳細は<a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web">ウェブにベクターグラフィックスを追加する</a>を参照）。</li> +</ul> + +<p><strong>注</strong>: レスポンシブデザインのテクニックについては、MDN の他の場所で説明されているため、ここでは詳しく説明しません（上記のリンクを参照）。</p> + +<h3 id="Specific_mobile_considerations" name="Specific_mobile_considerations">特定のモバイルに関する考慮事項</h3> + +<p>モバイルでサイトにアクセスしやすくするために考慮すべき他の重要な問題があります。ここにその一部を列挙しましたが、私たちがそれらを考えるときにはさらに追加します。</p> + +<h4 id="Not_disabling_zoom" name="Not_disabling_zoom">ズームを無効にしない</h4> + +<p><a href="/ja/docs/Mobile/Viewport_meta_tag">ビューポート</a>を使用すると、ズームを無効にすることができます。常にリサイズ可能にして、{{htmlelement("head")}} で端末の幅にあわせるにはこうします:</p> + +<pre class="brush: html"><code><meta name="viewport" content="width=device-width; user-scalable=yes"></code></pre> + +<p>なるべく<code>user-scalable=no</code> とはセットしないでください — 多くの人があなたのウェブサイトのコンテンツを見るためにズームに頼るので、この機能を奪うことは本当に悪い考えです。ズーミングによって UI が壊れる場合があります。そのような場合、絶対にズームを無効にする必要があると感じる場合は、UI を壊さないようにテキストサイズを大きくするためのコントロールのような、他の同等の機能を提供するべきです。</p> + +<h4 id="Keeping_menus_accessible" name="Keeping_menus_accessible">メニューにアクセスしやすくする</h4> + +<p>モバイルデバイスでは画面が非常に狭いため、メディアクエリやその他の技術を使用して、ナビゲーションメニューをディスプレイ上部の小さなアイコンに縮小するのがとても一般的です — これは一般的に「3本の水平線」アイコンで表され、デザインパターンでは「ハンバーガーメニュー」と呼ばれています — サイトがモバイルで表示されるときに必要です。</p> + +<p>そのようなメニューを実装するときは、上記の制御機構で説明したように、それを明らかにするためのコントロールは適切な制御機構（通常はモバイル用タッチ）でアクセスできること確認する必要があります。また、メニューの操作中に混乱しないように、メニューにアクセスしている間はページの残りの部分が邪魔にならないように移動するか、何らかの方法で非表示にします。</p> + +<p><a href="http://fritz-weisshart.de/meg_men/">良いハンバーガーメニューの例</a>（ドイツ語）を参照してください。</p> + +<h2 id="User_input" name="User_input">ユーザー入力</h2> + +<p>モバイルデバイスでは、データを入力することは、デスクトップコンピューター上の同等の経験よりもユーザーにとってより面倒なことが多いです。タッチスクリーンの仮想キーボードや小型のモバイル物理キーボードよりも、デスクトップやラップトップのキーボードを使用してテキストをフォーム入力に入力する方が便利です。</p> + +<p>このため、必要なタイピングの量を最小限に抑えることを試みる価値があります。例として、通常のテキスト入力を使用して毎回ユーザーに役職を記入させるのではなく、最も一般的な選択肢を含む <select> メニューを提供できます（データ入力の一貫性を保つのにも役立ちます）。そして、それ以外の値を入力するテキストフィールドを表示する「その他」選択肢を提供できます。<a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/common-job-types.html">common-job-types.html</a> で、このアイデアの簡単な例を実際に見ることができます（<a href="http://mdn.github.io/learning-area/accessibility/mobile/common-job-types.html">一般的な仕事の例をライブで見る</a>）。</p> + +<p>モバイルプラットフォームでの日付などの HTML5 フォームの入力タイプを使用することも考慮する価値があります。例えば、Android と iOS の両方で、デバイスエクスペリエンスに適した使用可能なウィジェットが表示されます。いくつかの例については <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/html5-form-examples.html">html5-form-examples.html</a> を参照してください（<a href="http://mdn.github.io/learning-area/accessibility/mobile/html5-form-examples.html">HTML5 フォームの例をライブで見る</a>） - これらをモバイルデバイスでロードして操作してみてください。例えば、</p> + +<ul> + <li>番号（<code>number</code>）、電話番号（<code>tel</code>）、電子メール（<code>email</code>）の入力では、番号や電話番号を入力するための適切な仮想キーボードを表示します。</li> + <li>日時（<code>date</code>, <code>time</code>）の入力では、日時を選択するための適切なピッカーを表示します。</li> +</ul> + +<p>デスクトップとは別の解決策を提供したい場合は、機能検出を使用して、モバイルデバイスに常に別のマークアップを提供できます。さまざまな入力タイプの検出に関する生の情報については<a href="http://diveinto.html5doctor.com/detect.html#input-types">入力タイプ</a>（英語）を参照してください。また、より多くの情報については<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">機能検出の記事</a>をチェックしてください。</p> + +<h2 id="Summary" name="Summary">まとめ</h2> + +<p>この記事では、モバイルのアクセシビリティ固有の一般的な問題とその解決方法について詳しく説明しました。また、アクセシビリティテストを支援するために、最も一般的なスクリーンリーダーの使い方を紹介しました。</p> + +<h2 id="See_also" name="See_also">関連情報</h2> + +<ul> + <li><a href="https://www.smashingmagazine.com/guidelines-for-mobile-web-development/">モバイルウェブ開発のためのガイドライン</a>（英語） — モバイルウェブデザインのためのさまざまな技術を網羅した <em>Smashing Magazine</em> の記事のリスト。</li> + <li><a href="http://www.creativebloq.com/javascript/make-your-site-work-touch-devices-51411644">サイトをタッチデバイスで機能させる</a>（英語） — タッチイベントを使用してモバイルデバイスで対話を機能させるための便利な記事。</li> +</ul> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<div> +<h2 id="In_this_module" name="In_this_module">このモジュール内の文書</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは？</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルのアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></li> +</ul> +</div> diff --git a/files/ja/learn/accessibility/multimedia/index.html b/files/ja/learn/accessibility/multimedia/index.html new file mode 100644 index 0000000000..e79aa9a6e9 --- /dev/null +++ b/files/ja/learn/accessibility/multimedia/index.html @@ -0,0 +1,371 @@ +--- +title: アクセシブルマルチメディア +slug: Learn/Accessibility/Multimedia +tags: + - Accessibility + - Article + - Audio + - Beginner + - CodingScripting + - HTML + - Images + - JavaScript + - Learn + - Multimedia + - Video + - captions + - subtitles + - text tracks +translation_of: Learn/Accessibility/Multimedia +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}</div> + +<p class="summary">アクセシビリティの問題を引き起こす他のカテゴリーは、マルチメディアでです。ビデオ、オーディオ、画像といったコンテンツは、支援技術 (assistive technologies) とユーザーが理解可能となる適切な代替テキストを必要とします。この記事ではその方法を説明します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識:</th> + <td>基本的なコンピューターの知識、HTML 、CSS 、JavaScript に対する基本的な理解、 <a href="/ja/docs/Learn/Accessibility/What_is_accessibility">前回の記事</a> の理解</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>マルチメディアが引き起こすアクセシビリティの問題、およびその解決方法を理解すること</td> + </tr> + </tbody> +</table> + +<h2 id="Multimedia_and_accessibility" name="Multimedia_and_accessibility">マルチメディアとアクセシビリティ</h2> + +<p>このモジュールまで、様々なコンテンツに対してそのアクセシビリティを保証するために何が必要かを見てきました。シンプルな文章から始まって、データテーブル、画像、フォーム要素やボタンといったネイティブのコントロール、より複雑なマークアップ構造 (<a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> 属性) などです。</p> + +<p>一方こちらの記事は、アクセシビリティの保証が難しい別のマルチメディアのコンテンツ群について扱っています。画像、ビデオ、{{htmlelement("canvas")}} 要素、Flash 動画などは、スクリーンリーダーによる理解やキーボードによるナビゲーションが容易ではないため、私たちが手を差し伸べる必要があります。</p> + +<p>ですが絶望はしないでください。ここではマルチメディアをアクセシブルにするために利用できる技術について紹介し、あなたの手助けをします。</p> + +<h2 id="Simple_images" name="Simple_images">シンプルな画像</h2> + +<p>私達は既に <a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a> で HTML 画像のシンプルな代替テキストについてカバーしました — 詳細を確認するために、そこに戻っても良いです。簡単に言うと、ビジュアルコンテンツとなり得るものは、スクリーンリーダーがユーザーのために読み上げることができるよう、代替テキストが利用可能であることを保証するべきです。</p> + +<p>例えば:</p> + +<pre class="brush: html"><img src="dinosaur.png" + alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."> +</pre> + +<h2 id="Accessible_audio_and_video_controls" name="Accessible_audio_and_video_controls">アクセシブルなオーディオとビデオコントロール</h2> + +<p>ウェブベースのオーディオ/ビデオのコントロールを実装するのは問題にはならないはずですよね？調べてみましょう。</p> + +<h3 id="The_problem_with_native_HTML5_controls" name="The_problem_with_native_HTML5_controls">ネイティブ HTML5 コントロールの問題</h3> + +<p>HTML5 の video と audio インスタンスは、ビルトインのコントロールと一緒に提供されており、何も設定せずにメディアの制御を行うことができます。例えば (<code>native-controls.html</code> <a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/native-controls.html">ソースコード</a>と<a href="http://mdn.github.io/learning-area/accessibility/multimedia/native-controls.html">実際の動作</a>を参照):</p> + +<pre class="brush: html"><audio controls> + <source src="viper.mp3" type="audio/mp3"> + <source src="viper.ogg" type="audio/ogg"> + <p>Your browser doesn't support HTML5 audio. Here is a <a href="viper.mp3">link to the audio</a> instead.</p> +</audio> + +<br> + +<video controls> + <source src="rabbit320.mp4" type="video/mp4"> + <source src="rabbit320.webm" type="video/webm"> + <p>Your browser doesn't support HTML5 video. Here is a <a href="rabbit320.mp4">link to the video</a> instead.</p> +</video></pre> + +<p>control 属性は、あなたがメディアプレイヤーに対して期待する再生/一時停止ボタンやシークバーといった基本的なコントロールを提供します。Firefox と Chrome では次のように表示されます。</p> + +<p><img alt="Screenshot of Video Controls in Firefox" src="https://mdn.mozillademos.org/files/14440/native-controls-firefox.png" style="display: block; height: 361px; margin: 0px auto; width: 400px;"></p> + +<p><img alt="Screenshot of Video Controls in Chrome" src="https://mdn.mozillademos.org/files/14438/native-controls-chrome.png" style="display: block; height: 344px; margin: 0px auto; width: 400px;"></p> + +<p>しかし、これらのコントロールには問題があります:</p> + +<ul> + <li>たいていのブラウザーではキーボードでアクセスできません。つまりネイティブプレイヤー内でコントロール間をタブ移動できません。Opera と Chrome ではいくらか動きますが、理想的なものではありません。</li> + <li>ネイティブコントロールは各ブラウザーによって異なるスタイルと機能が提供され、かつスタイリングすることができません。それは、サイトのスタイルガイドに従うのが容易ではないことを意味します。</li> +</ul> + +<p>これを改善するために、私たちは自分たちのカスタムコントロールを作成することができます。どのようにするのか見てみましょう。</p> + +<h3 id="Creating_custom_audio_and_video_controls" name="Creating_custom_audio_and_video_controls">カスタム audio/video コントロール</h3> + +<p>HTML5 の video と audio は HTML メディア要素という API を提供しています。これは、あなたが定義したボタンや他のコントロールにカスタム機能をマップすることを可能にします。</p> + +<p>上の video を例として、カスタムコントロールを追加してみましょう。</p> + +<h4 id="Basic_setup" name="Basic_setup">基本のセットアップ</h4> + +<p>はじめに、<a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/custom-controls-start.html">custom-controls-start.html</a>、 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/custom-controls.css">custom-controls.css</a>, <a href="https://raw.githubusercontent.com/mdn/learning-area/master/accessibility/multimedia/rabbit320.mp4">rabbit320.mp4</a>、そして <a href="https://raw.githubusercontent.com/mdn/learning-area/master/accessibility/multimedia/rabbit320.webm">rabbit320.webm</a> のコピーを取得し、あなたのハードドライブのディレクトリーに保存します</p> + +<p>main.js というファイルを新規作成し、同じディレクトリーに保存します。</p> + +<p>最初に、ビデオプレイヤーの HTML を見てみましょう。HTML の中は次のようになっています:</p> + +<pre class="brush: html"><section class="player"> + <video controls> + <source src="rabbit320.mp4" type="video/mp4"> + <source src="rabbit320.webm" type="video/webm"> + <p>Your browser doesn't support HTML5 video. Here is a <a href="rabbit320.mp4">link to the video</a> instead.</p> + </video> + + <div class="controls"> + <button class="playpause">Play</button> + <button class="stop">Stop</button> + <button class="rwd">Rwd</button> + <button class="fwd">Fwd</button> + <div class="time">00:00</div> + </div> +</section></pre> + +<h4 id="JavaScript_basic_setup" name="JavaScript_basic_setup">JavaScript の基本セットアップ</h4> + +<p>私たちは video の下にいくつかの簡単なボタンを挿入しました。もちろん、このままではこれらのコントロールは何もしません。機能を加えるためには JavaScript を使います。</p> + +<p>まずはそれぞれのコントロールの設定を保持しておく必要があります。JavaScript ファイルの先頭に次のコードを追加してください:</p> + +<pre class="brush: js">const playPauseBtn = document.querySelector('.playpause'); +const stopBtn = document.querySelector('.stop'); +const wdBtn = document.querySelector('.rwd'); +const fwdBtn = document.querySelector('.fwd'); +const timeLabel = document.querySelector('.time');</pre> + +<p>次に、video/audio プレイヤー自身の参照を取得する必要があります。次の行を先ほどのコードの下に加えてください:</p> + +<pre class="brush: js">const player = document.querySelector('video');</pre> + +<p>これは {{domxref("HTMLMediaElement")}} オブジェクトへの参照を保持します。このオブジェクトは、私たちのボタンに機能を紐づけるために使用可能ないくつかの便利なプロパティやメソッドを持っています。 </p> + +<p>私たちのボタンの機能を作る前に、カスタムコンロールの邪魔にならないようネイティブコントロールを削除しましょう。JavaScript の下に次のコードを追加してください:</p> + +<pre class="brush: js">player.removeAttribute('controls');</pre> + +<p>最初から controls 属性を含めないようにするのではなく、わざわざこのようにするのには理由があります。もし JavaScript コードが何らかの理由で失敗しても、ユーザーは利用可能な何かしらのコントロールを使うことができるのです。</p> + +<h4 id="Wiring_up_our_buttons" name="Wiring_up_our_buttons">ボタンを紐つける</h4> + +<p>最初に、再生/一時停止ボタンをセットアップしましょう。次のように、再生と一時停止をシンプルな条件によって切り替えることで、この機能を実現できます。これをあなたのコードの下に追加しましょう:</p> + +<pre class="brush: js">playPauseBtn.onclick = function() { + if(player.paused) { + player.play(); + playPauseBtn.textContent = 'Pause'; + } else { + player.pause(); + playPauseBtn.textContent = 'Play'; + } +};</pre> + +<p>次に、ストップボタンを制御する次のコードを下に追加しましょう:</p> + +<pre class="brush: js">stopBtn.onclick = function() { + player.pause(); + player.currentTime = 0; + playPauseBtn.textContent = 'Play'; +};</pre> + +<p>{{domxref("HTMLMediaElement")}} には <code>stop()</code> 関数がありません。そこで <code>pause()</code> 関数を使用し、同時に <code>currentTime</code> に 0 を設定します。</p> + +<p>続いて、巻き戻しと早送りボタンです。次のブロックをあなたのコードの下に追加してください:</p> + +<pre class="brush: js">rwdBtn.onclick = function() { + player.currentTime -= 3; +}; + +fwdBtn.onclick = function() { + player.currentTime += 3; + if(player.currentTime >= player.duration || player.paused) { + player.pause(); + player.currentTime = 0; + playPauseBtn.textContent = 'Play'; + } +};</pre> + +<p>これらはとてもシンプルで、クリックされる度に <code>currentTime</code> 単に 3 秒を足すか引くだけです。実際のビデオプレイヤーでは、あなたはもっと手の込んだものを作りたいでしょう。</p> + +<p>早送りボタンが押されたとき、 <code>currentTime</code> がメディアのトータルの <code>duration</code> よりも大きいか、そしてメディアが再生されていないかをチェックするという点についても気をつけてください。もしいずれかの条件が満たされているなら、ビデオが再生されていない時に早送りしようとしてもおかしくならないよう、単純にビデオを停止するか、ビデオの最後まで飛ばします。</p> + +<p>最後に、再生時間を表示するために次の内容をコードの最後に追加します:</p> + +<pre class="brush: js">player.ontimeupdate = function() { + let minutes = Math.floor(player.currentTime / 60); + let seconds = Math.floor(player.currentTime - minutes * 60); + let minuteValue; + let secondValue; + + if (minutes<10) { + minuteValue = "0" + minutes; + } else { + minuteValue = minutes; + } + + if (seconds<10) { + secondValue = "0" + seconds; + } else { + secondValue = seconds; + } + + mediaTime = minuteValue + ":" + secondValue; + timeLabel.textContent = mediaTime; +};</pre> + +<p>時間が更新される度に (1秒に一度) 、この関数を実行します。これは秒として渡された currentTime の値 (秒で与えられる) から分と秒の数を算定するもので、もし分か秒の値が 10 以下であれば先頭に 0 を追加し、表示用の値を生成して時間ラベルに追加します。 </p> + +<h4 id="Further_reading" name="Further_reading">参考記事</h4> + +<p>ここでは、video/audio プレイヤーに対してどのようにカスタムしたプレイヤー機能を加えるかという基本的なアイデアが得られます。video/audio プレイヤーに対して、古いブラウザーでの Flash のフォールバックも含めて、より複雑な機能を加えるには、以下のリンク先を参照してください:</p> + +<ul> + <li><a href="/ja/docs/Web/Apps/Fundamentals/Audio_and_video_delivery">Audio and video delivery</a></li> + <li><a href="/ja/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Video_player_styling_basics">Video player styling basics</a></li> + <li><a href="/ja/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/cross_browser_video_player">Creating a cross-browser video player</a></li> +</ul> + +<p>さらに私たちは、あなたがどのようにしてオブジェクト指向システムを作ることができるかを見せるために高度な例も作りました。これは、ページ内のすべての video と audio プレイヤーを見つけ (どれだけ存在していたとしても)、私たちのカスタムコントロールを追加するものです。<a href="http://mdn.github.io/learning-area/accessibility/multimedia/custom-controls-OOJS/">custom-controls-oojs</a> を見てください (<a href="https://github.com/mdn/learning-area/tree/master/accessibility/multimedia/custom-controls-OOJS">ソースコード</a>も見てください) 。</p> + +<h2 id="Audio_transcripts" name="Audio_transcripts">オーディオトランスクリプト(Audio transcripts)</h2> + +<p>聴覚障害の方にオーディオコンテンツを提供する場合、トランスクリプトのテキストを必ず用意する必要があります。これらは同じページの中に何らかの形で含んでも良いですし、リンクされた別ページに用意することもできます。</p> + +<p>トランスクリプトを実際に作成する際は、次の選択肢があります。</p> + +<ul> + <li>商用サービス — プロフェッショナルに料金を払って文字起こししてもらうことができるでしょう。例として <a href="https://scribie.com/">Scribie</a>、<a href="https://castingwords.com/">Casting Words</a>、<a href="https://www.rev.com/">Rev</a> などの会社を見てください。色々見てアドバイスをもらい、あなたがうまく作業できる評判の良い会社を見つけてください。</li> + <li>コミュニティ/草の根/自身の文字起こし — あなたがアクティブなコミュニティや職場のチームの一員であるなら、彼らに文字起こしのヘルプを頼むことができるでしょう。試しに自分自身で文字起こしに挑戦することもできます。</li> + <li>自動サービス — <a href="https://trint.com/">Trint</a> のように利用可能な AI サービスがあります。サイトにビデオ/オーディオファイルをアップロードすれば、自動的にそれを書き起こします。YouTube では、自動的にキャプション/トランスクリプトを生成するように選択できます。生成されるトランスクリプトのクォリティは、どれだけ明瞭に話されているかに応じて大きく変わります。</li> +</ul> + +<p>人生の多くのものがそうであるように、あなたは支払った分相応のものを手に入れます。つまり、サービスが異なれば、トランスクリプト作成に要する時間と正確さが異なるということです。文字起こしをするために信頼できる会社や AI サービスにお金を払えば、正確なトランスクリプトを早く入手できるでしょう。料金を払いたくないのであれば、遅く、質の低いものになりやすいです。</p> + +<p>オーディオリソースを公開するがトランスクリプトは後で提供する、という約束は良いものではありません。そのような約束は大抵守られず、ユーザーとの間にある信頼を損なってしまいます。もしオーディオが対面ミーティングやライブスピーチのようなものであるならば、それらが行われている間にノートを取り、オーディオと共に公開して、後からまとめ上げるということはできるでしょう。</p> + +<h3 id="Transcript_examples" name="Transcript_examples">トランスクリプト例</h3> + +<p>もしあなたが自動サービスを使用しているならば、おそらくツールが提供しているユーザーインターフェイスを使用する必要があるでしょう。例えば、<a href="https://www.youtube.com/watch?v=mwF-PpJOjMs">Wait, ARIA Roles Have Categories?</a> を見て、 3点メニュー (. . .) <em>> Show Transcript</em> を選択してください。トランスクリプトは別のパネルに表れるでしょう。</p> + +<p>オーディオとそのトランスクリプトを表示するユーザーインターフェイスを自身で作成する場合、あなたのが考える形で作ることができますが、表示/非表示が可能なパネルを含むと良いかもしれません。私たちの <a href="http://mdn.github.io/learning-area/accessibility/multimedia/audio-transcript-ui/">audio-transcript-ui</a> の例を見てください。 (<a href="https://github.com/mdn/learning-area/tree/master/accessibility/multimedia/audio-transcript-ui">ソースコード</a> も見てください).</p> + +<h3 id="Audio_descriptions" name="Audio_descriptions">オーディオの説明</h3> + +<p>オーディオに伴った映像がある場合、追加のコンテンツを描写するためにオーディオの説明を提供する必要があるでしょう。</p> + +<p>多くの場合これはビデオの形を取り、この章の次のセクションで説明されるテクニックを使用してキャプションを埋め込むことができます。</p> + +<p>しかし、いくつかのエッジケースもあります。例えば、スプレッドシートやグラフの資料を使用したミーティングの録音オーディオがあるかもしれません。その場合、それらの資料がオーディオとトランスクリプトとともに提供されていることを確認するべきであり、特にトランスクリプトの中でそれらの資料に言及されている箇所をリンクとすることが大事です。これは聴覚障害の方だけでなく、すべてのユーザーの助けになります。</p> + +<div class="note"> +<p><strong>注</strong>: オーディオトランスクリプトは、一般的に様々なユーザーグループを助けます。聴覚障害の人へオーディオに含まれたコンテンツにアクセスを提供するように、オーディオをダウンロードすることが困難な狭い帯域のユーザーのことを考えて見ましょう。パブやバーのような騒音の多い環境で、雑音のためにオーディオを聞くことが難しいユーザーのことも考えて見ましょう。</p> +</div> + +<h2 id="Video_text_tracks" name="Video_text_tracks">ビデオテキストトラック</h2> + +<p>聴覚障害者、視覚障害者、そして他のユーザー (狭い帯域のユーザーや、ビデオで使用される言語を話さないユーザー) にとってビデオをアクセシブルにするために、ビデオコンテンツにテキストトラックを含める必要があります。</p> + +<div class="note"> +<p><strong>注</strong>: テキストトラックは障害者だけでなく他のユーザーにとっても便利になる可能性があります。例えば、うるさい環境 (スポーツ中継を流している混雑したバーなど) にいるためにオーディオが聞こえないユーザーや、他の人を邪魔したくない静かな場所 (図書館など) にいるユーザーなどです。</p> +</div> + +<p>これは新しいコンセプトではありません — テレビ放送では、かなり長い間クローズドキャプションを提供しています:</p> + +<p><img alt='Frame from an old-timey cartoon with closed captioning "Good work, Goldie. Keep it up!"' src="https://mdn.mozillademos.org/files/14436/closed-captions.png" style="display: block; height: 240px; margin: 0px auto; width: 320px;"></p> + +<p>一方で、多くの国では英語の映画を自国の母語の字幕とともに提供していて、DVD では他の言語の字幕も利用可能となっています。</p> + +<p><img alt='An English film with German subtitles "Emo, warum erkennst du nicht die Schonheit dieses Ortes?"' src="https://mdn.mozillademos.org/files/14442/Subtitles_German.jpg" style="display: block; margin: 0 auto;"></p> + +<p>テキストトラックには、目的に応じた様々な種類のものがあります。あなたが接する主な種類は、次のものです:</p> + +<ul> + <li>キャプション — オーディオを聞くことができない聴覚障害者のためのものであり、話されている言葉、誰が話しているか、人が怒っているのか悲しんでいるのか、どのような雰囲気の音楽が流れているのかなど、場面に関する情報を含みます。</li> + <li>字幕 — 話されている言語を理解しないユーザーのための翻訳された音声の台本です。</li> + <li>ディスクリプション (Descriptions) — ビデオを見ることができない視覚障害者のための描写を含みます。例えば、どのようなシーンに見えるか、などです。</li> + <li>チャプタータイトル — メディアリソースを移動するユーザーを助けることを目的としたチャプターマーカーです。</li> +</ul> + +<h3 id="Implementing_HTML5_video_text_tracks" name="Implementing_HTML5_video_text_tracks">HTML5 ビデオテキストトラックの実装</h3> + +<p>HTML5 のビデオで表示されるテキストトラックは、WebVTT で記述される必要があります。これは、テキストの文字列とメタデータを含むテキストフォーマットであり、テキストが表示されるべき時間や、スタイル、ポジションといった情報まで含みます。これらの文字列はキュー (cues) と呼ばれます。</p> + +<p>典型的な WebVTT ファイルは、次のようなものです:</p> + +<pre>WEBVTT + +1 +00:00:22.230 --> 00:00:24.606 +This is the first subtitle. + +2 +00:00:30.739 --> 00:00:34.074 +This is the second. + + ...</pre> + +<p>HTML のメディア再生と共に表示させるためには、次のことをする必要があります:</p> + +<ul> + <li>.vtt ファイルとしてアクセス可能な場所に保存します。</li> + <li>{{htmlelement("track")}} 要素で .vtt へのリンクを設定します。 <code><track></code> は <code><audio></code> か <code><video></code> の間に設置する必要がありますが、すべての <code><source></code> 要素の後でなければいけません。 {{htmlattrxref("kind","track")}} 属性を使い、キューが字幕、キャプション、ディスクリプションのどれなのかを指定します。さらに、 {{htmlattrxref("srclang","track")}} を使って、字幕でどの言語が使用されているのかを伝えます。</li> +</ul> + +<p>例を見てみましょう:</p> + +<pre class="brush: html"><video controls> + <source src="example.mp4" type="video/mp4"> + <source src="example.webm" type="video/webm"> + <track kind="subtitles" src="subtitles_en.vtt" srclang="en"> +</video></pre> + +<p>これは、字幕が表示されたビデオとなり、次のようになります:</p> + +<p><img alt='Video player with standard controls such as play, stop, volume, and captions on and off. The video playing shows a scene of a man holding a spear-like weapon, and a caption reads "Esta hoja tiene pasado oscuro."' src="https://mdn.mozillademos.org/files/7887/video-player-with-captions.png" style="display: block; height: 365px; margin: 0px auto; width: 593px;"></p> + +<p>詳細は <a href="/ja/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video">Adding captions and subtitles to HTML5 video</a> を読んでください。あなたは、GitHub で GIan Devlin によって作られた<a href="http://iandevlin.github.io/mdn/video-player-with-captions/">例</a>をこの記事と併せて見ることができます。(<a href="https://github.com/iandevlin/iandevlin.github.io/tree/master/mdn/video-player-with-captions">source ソースコード</a> も見てください) この例では JavaScript を使用して、ユーザーが異なる言語の字幕を選択できるようになっています。字幕を表示するためには、"CC" ボタンをクリックして英語、ドイツ語、スペイン後のオプションを選択する必要があります。</p> + +<div class="note"> +<p><strong>注</strong>: テキストトラックは {{glossary("SEO")}} でも役に立ちます。検索エンジンはテキストによって更新されるためです。検索エンジンは、テキストトラックによってビデオの途中に直接リンクすることさえできます。</p> +</div> + +<h2 id="Other_multimedia_content" name="Other_multimedia_content">その他のマルチメディアコンテンツ</h2> + +<p>上のセクションでは、あなたがウェブページに載せたいかもしれないすべての種類のマルチメディアコンテンツをカバーしていません。また、ゲーム、アニメーション、スライドショー、埋め込まれたビデオ、そして他の利用可能なテクノロジーを利用して作られたコンテンツを扱う必要があるかもしれません。例えば:</p> + +<ul> + <li><a href="/ja/docs/Web/API/Canvas_API">HTML5 canvas</a></li> + <li>Flash</li> + <li>Silverlight</li> +</ul> + +<p>そのようなコンテンツには、アクセシビリティの懸念事項とケースバイケースで対応する必要があります。いくつかのケースでは、これはそれほど悪いことではありません。例えば:</p> + +<ul> + <li>もし Flash や Silverlight のようなプラグイン技術を使用してオーディオコンテンツを埋め込んでいる場合、上の {{anch("Transcript examples")}} セクションで既に紹介したのと同じ方法でオーディオトランスクリプトを提供することができるでしょう。</li> + <li>Flash や Silverlight のようなプラグイン技術でビデオコンテンツを埋め込んでいる場合、それらの技術で利用可能なキャプション/字幕の技術を利用することができます。例えば、 <a href="http://www.adobe.com/accessibility/products/flash/captions.html">Flash captions</a>、<a href="https://help.adobe.com/en_US/as3/components/WS5b3ccc516d4fbf351e63e3d118a9c65b32-7ee5.html">Using Timed Text Captions</a> (Flash用) 、 <a href="https://blogs.msdn.microsoft.com/anilkumargupta/2009/05/01/playing-subtitles-with-videos-in-silverlight/">Playing Subtitles with Videos in Silverlight</a> などを見てください。</li> +</ul> + +<p>しかし、他のマルチメディアはアクセシブルにすることがそう簡単ではありません。例えば、没入型 3D ゲームやバーチャルリアリティアプリを扱っている場合、そのような体験に対して代替テキストを提供することは非常に困難であるし、盲目のユーザーはそのようなアプリのターゲットに当てはまらないと考えるかもしれません。</p> + +<p>しかしそのようなアプリでも、視力や色覚に問題を抱えるユーザーにとって認識できるよう、カラーコントラストや表示の明瞭さが十分であるかどうか、そしてキーボードからアクセス可能であるかを確かめることはできます。アクセシビリティは、100% を常に目指すというよりは、可能な限り行うものであるということを覚えておいてください。100% は大抵不可能なのです。</p> + +<h2 id="Summary" name="Summary">まとめ</h2> + +<p>このチャプターでは、マルチメディアにおけるアクセシビリティの関心ごとの要約をいくつかの実践的なソリューションと共に提供しました。</p> + +<p>{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}</p> + +<h2 id="In_this_module" name="In_this_module">このモジュール内の文書</h2> + + + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは?</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></li> +</ul> diff --git a/files/ja/learn/accessibility/wai-aria_basics/index.html b/files/ja/learn/accessibility/wai-aria_basics/index.html new file mode 100644 index 0000000000..778b3ed1fe --- /dev/null +++ b/files/ja/learn/accessibility/wai-aria_basics/index.html @@ -0,0 +1,434 @@ +--- +title: WAI-ARIAの基本 +slug: Learn/Accessibility/WAI-ARIA_basics +tags: + - ARIA + - Accessibility + - Article + - Beginner + - CodingScripting + - Guide + - HTML + - JavaScript + - Learn + - WAI-ARIA + - semantics + - アクセシビリティ + - セマンティクス + - 初心者 + - 学習 +translation_of: Learn/Accessibility/WAI-ARIA_basics +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</div> + +<p class="summary">前回の記事に続いて言えることですが、意味論的ではない HTML や JavaScript によって更新される動的なコンテンツを含むような、複雑な UI コントロールの作成は難しくなることがあります。 WAI-ARIA は、ブラウザーや支援技術が認識できるさらなる意味論を追加することによってそのような問題に対処し、ユーザーの理解を助ける技術です。 ここでは、アクセシビリティを向上させるための基本的な使い方を説明します。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">前提知識:</th> + <td>基本的なコンピューターの知識、 HTML 、 CSS 、 JavaScript に対する基本的な理解、 <a href="/ja/docs/Learn/Accessibility">前回までの記事</a>に対する理解</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>WAI-ARIA、および、アクセシビリティを向上させるために必要に応じて有用な追加の意味論を提供する方法について知識を得ること</td> + </tr> + </tbody> +</table> + +<h2 id="What_is_WAI-ARIA" name="What_is_WAI-ARIA">WAI-ARIA って何？</h2> + +<p>まずは、WAI-ARIA とは何か、そして何ができるのかという点から始めましょう。</p> + +<h3 id="A_whole_new_set_of_problems" name="A_whole_new_set_of_problems">全く新しい問題</h3> + +<p>ウェブアプリがより複雑で動的なものになると、新しいアクセシビリティの機能と問題が明らかになってきます。</p> + +<p>例えば、 HTML5 は普遍的なページの機能を定義するためにいくつもの意味論的要素を取り入れました（{{htmlelement("nav")}} 、 {{htmlelement("footer")}} 等）。 これらが利用可能になる以前は、開発者は <code><div class="nav"></code> のように単に {{htmlelement("div")}} を ID や class と共に使っていましたが、メインナビゲーションのようなページ内の機能をプログラムで識別する簡単な方法が無いために問題がありました。</p> + +<p>初期の解決方法は、ナビゲーションへとリンクさせるため、次のようにページ上部に1つ以上の隠しリンク（もしくは他の何か）を追加することでした。</p> + +<pre class="brush: html"><a href="#hidden" class="hidden">Skip to navigation</a></pre> + +<p>しかしこれは簡潔な方法ではない上に、スクリーンリーダーがページの先頭から読み込む場合にのみ利用できるものでした。</p> + +<p>他の例としては、アプリが日付選択のための日付ピッカーや値選択のためのスライダーなどの複雑なコントロールを使いだしたケースがあります。 HTML5 は、そのようなコントロールを表す特別な入力タイプを提供しています。</p> + +<pre class="brush: html"><input type="date"> +<input type="range"></pre> + +<p>これらはブラウザー間で十分にサポートされておらず、またスタイル付けすることが非常に困難であるため、ウェブサイトのデザインに合わせる上で不便となります。 結果として、開発者は多くの場合 JavaScript ライブラリを利用して複数のネストされた {{htmlelement("div")}} でそのようなコントロールを生成したり、クラス名を持った表要素に対して CSS によるスタイル付けと JavaScript によるコントロールを行ったりします。</p> + +<p>この場合の問題は、見た目上は動作するものの、スクリーンリーダーはそれらが何なのか全く理解できず、ユーザーには意味を成さないごちゃごちゃの要素であるとしか教えられないという点にあります。</p> + +<h3 id="Enter_WAI-ARIA" name="Enter_WAI-ARIA">WAI-ARIA の導入</h3> + +<p><a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> は W3C によって定められた仕様で、要素に適用できる追加の意味論を提供する一連の HTML 属性を定義しており、それが欠けているどのような場所でもアクセシビリティを向上させます。 この仕様では、主に次の3つの機能があります。</p> + +<ul> + <li><strong>ロール（Role）</strong> — これは要素が何か、もしくは何をするかを定義します。 多くの場合はいわゆるランドマークロール（landmark role）であり、主に HTML5 構造要素の意味論を複製します。 例えば、 <code>role="navigation"</code> ({{htmlelement("nav")}}) や <code>role="complementary"</code> ({{htmlelement("aside")}}) などです。 しかし、それ以外にも別のページ構造を定義するものもあります。 例えば、 <code>role="banner"</code> 、 <code>role="search"</code> 、 <code>role="tabgroup"</code> 、 <code>role="tab"</code> 等で、 UI に多く見られます。</li> + <li><strong>プロパティ（Property）</strong> — これは要素の性質を定義するものであり、追加の意図や意味論を与えるために使用することができます。 例えば、 <code>aria-required="true"</code> はフォーム入力が有効となるために値を入力しなければならないことを定義し、 <code>aria-labelledby="label"</code> は、要素に ID を追加することで、複数の場合も含めてページ内の他のどの要素からもラベルとして参照することを可能にします。 これは <code><label for="input"></code> ではできません。 別の例として、 <code>aria-labelledby</code> を使って主な説明を含む1つの {{htmlelement("div")}} が表の複数セルのラベルであると指定することができますし、画像の代替テキストの代わりとして使用することもできます。 これは、 <code>alt</code> 属性で繰り返すのではなく、ページの既存の情報を画像の代替テキストとして指定します。 <a href="/ja/docs/Learn/Accessibility/HTML#Text_alternatives">代替テキスト</a> で例を確認することができます。</li> + <li><strong>ステート（State）</strong> — 要素の現在の状態を定義する特別なプロパティです。 例えば、 <code>aria-disabled="true"</code> は、フォーム入力が現在 disabled であることをスクリーンリーダーに対して伝えます。 ステートはプロパティとは異なり、プロパティはアプリのライフサイクルを通して変化しないのに対して、ステートは主に JavaScript によって変更されます。</li> +</ul> + +<p>WAI-ARIA 属性の重要な点は、ブラウザーのアクセシビリティ API（スクリーンリーダーはここから情報を取得する）によって提供される情報を除いて、それらはウェブページに何の影響も与えないという点です。 WAI-ARIA はウェブページの構造や DOM に影響を与えませんが、 CSS の要素選択で利用することが可能です。</p> + +<div class="note"> +<p><strong>注</strong>: WAI-ARIA の仕様で、ARIA ロールの使用方法と追加情報へのリンクを含む便利なリストを確認することができます。 <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">ロールの定義</a>（英語）を見てください。</p> + +<p>この仕様では、プロパティとステートの追加情報を含んだリストも確認することができます。 <a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">ステートとプロパティの定義（すべての aria-* 属性）</a>（英語）を見てください。</p> +</div> + +<h3 id="Where_is_WAI-ARIA_supported" name="Where_is_WAI-ARIA_supported">WAI-ARIA はどこでサポートされていますか？</h3> + +<p>この質問に答えるのは簡単ではありません。 次の理由より、どこで、WAI-ARIA のどの機能がサポートされているのかを記述する決定的なリソースを見つけることが難しいためです。</p> + +<ol> + <li>WAI-ARIA には大量の機能がある。</li> + <li>検討しなければいけないオペレーティングシステム、ブラウザー、スクリーンリーダーの組み合わせが大量にある。</li> +</ol> + +<p>最後の点は重要です。 そもそもスクリーンリーダーを使用するためには、オペレーティングシステムが所定のアクセシビリティ API を持つブラウザーを動作させる必要があり、それはスクリーンリーダーが動作するために必要となる情報を提供しなければいけません。 ほとんどの人気の OS は、スクリーンリーダーが動作可能である1つか2つの所定のブラウザーを持っています。 Paciello Group は、この件に関してほぼ最新のデータを投稿しています — <a href="https://www.paciellogroup.com/blog/2014/10/rough-guide-browsers-operating-systems-and-screen-reader-support-updated/">ラフガイド: ブラウザ、オペレーティングシステム、スクリーンリーダーのサポート</a>（英語）を見てください。</p> + +<p>次に、ブラウザーが問題となっている ARIA の機能をサポートしているのか、および API を通してそれらを公開しているのかという点を気にする必要があります。 しかし、スクリーンリーダーがそれらの情報を認識し、ユーザーに有益なやり方で伝えているのかという点もまた気にしなければいけません。</p> + +<ol> + <li>ブラウザーのサポート状況は概ね良いです。 本記事の執筆時点で、 <a href="http://caniuse.com/#feat=wai-aria">caniuse.com</a> は全体のブラウザーの WAI-ARIA のサポート状況は 88% だとしています。</li> + <li>スクリーンリーダーの ARIA のサポート状況はそこまでではありませんが、多くの一般的なスクリーンリーダーはそれに近いものになってきています。 Powermapper による <a href="http://www.powermapper.com/tests/screen-readers/aria/">WAI-ARIA のスクリーンリーダーの互換性</a>（英語）の記事で、サポート状況を確認することができます。</li> +</ol> + +<p>この記事では、全ての WAI-ARIA の機能と詳細についてカバーするわけではありません。 代わりに、あなたが知るべき最も重要な WAI-ARIA の機能についてカバーします。 もしサポートの詳細について何も記述してしない場合は、その機能が十分にサポートされていると想定してください。 この例外がある場合は、明確に記述します。 </p> + +<div class="note"> +<p><strong>注</strong>: JavaScript ライブラリには WAI-ARIA をサポートしているものがありますが、それはライブラリが複雑なフォームコントロールのような UI を生成した場合に、アクセシビリティを向上させるための ARIA 属性を追加することを意味します。 迅速な UI 開発のためにサードパーティーの JavaScript ライブラリを探しているのであれば、その決断を下す際、UI のアクセシビリティのサポートを重要な要素として必ず考慮すべきです。 良い例としては、 jQuery UI（<a href="https://jqueryui.com/about/#deep-accessibility-support">jQuery UI について: ディープアクセシビリティサポート</a>（英語）を見てください）、 <a href="https://www.sencha.com/products/extjs/">ExtJS</a> 、 <a href="https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html">Dojo/Dijit</a> があります。</p> +</div> + +<h3 id="When_should_you_use_WAI-ARIA" name="When_should_you_use_WAI-ARIA">いつ WAI-ARIA を使うべき？</h3> + +<p>私達は WAI-ARIA が作られるに至ったいくつかの問題について最初の方で話しましたが、基本的には WAI-ARIA が有用となる4つの主な場面があります。</p> + +<ol> + <li><strong>道しるべ/ランドマーク（Signpost/Landmark）</strong>: ARIA の <code>role</code> 属性の値は、HTML 要素の意味論（例えば {{htmlelement("nav")}}）を再現するランドマークとして振る舞ったり、 <code>search</code> 、 <code>tabgroup</code> 、 <code>tab</code> 、 <code>listbox</code> のようにHTML5 の意味論の範囲外となる道しるべ（signpost）を異なる機能エリアに提供することができます。</li> + <li><strong>動的なコンテンツの更新</strong>: スクリーンリーダーは、絶えず更新されるコンテンツが得意ではない傾向があります。 ARIA の <code>aria-live</code> を使うことで、 <a href="/ja/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a> や <a href="/ja/docs/Web/API/Document_Object_Model">DOM API</a> を通してコンテンツが更新された場合に、スクリーンリーダーのユーザーに対してそれを伝えることができます。</li> + <li><strong>キーボードのアクセシビリティの向上</strong>: キーボードのアクセシビリティを最初から持つ HTML 要素がありますが、 JavaScript を使ってそれ以外の要素に同じようなインタラクションをさせる場合、スクリーンリーダーにとって困難が生じます。 こうしなければならない場合、 WAI-ARIA は他の要素に対してフォーカスを得る手段を提供しています（<code>tabindex</code> の使用）。</li> + <li><strong>意味論的ではないコントロールのアクセシビリティ</strong>: ネストした一連の <code><div></code> が CSS/JavaScript と共に複雑な UI 機能を構成していたり、ネイティブのコントロールが JavaScript によって大きく強化/変更されている場合、アクセシビリティの提供は困難になります。 そこに意味論や手がかりが無ければ、スクリーンリーダーのユーザーはその機能が何をするのか判断するのが難しくなるでしょう。 このような状況では、 <code>button</code> 、 <code>listbox</code> 、または <code>tabgroup</code> といったロールの組み合わせ、もしくは <code>aria-required</code> や <code>aria-posinset</code> などのプロパティにより機能の手がかりを提供することで、 ARIA は足りないものを補うことができます。</li> +</ol> + +<p>一点忘れてはいけないのが、 <strong>WAI-ARIA は必要な場合のみ使用する</strong>という点です。 理想的には、スクリーンリーダーのユーザーの理解に必要となる意味論の提供は、常に <a href="/ja/docs/Learn/Accessibility/HTML">ネイティブの HTML 機能</a> を使用して行うべきです。 しかし、コードの制御が限定されていたり、 HTML 要素への実装が容易ではない複雑なものを作っているなどの理由で、これが困難となるケースがあります。 そのような場合、 WAI-ARIA はアクセシビリティを向上させる上で価値のあるツールとなります。</p> + +<p>もう一度言いますが、必要な時だけ使ってください！</p> + +<div class="note"> +<p><strong>注</strong>: 実際のさまざまなユーザーによってあなたのサイトをテストすることも忘れないでください — 障害のないユーザー、スクリーンリーダーを使用するユーザー、キーボードナビゲーションを使用するユーザーなどです。 どれだけうまく動作するかという点で、彼らはあなたよりもうまく観察してくれるでしょう。 </p> +</div> + +<h2 id="Practical_WAI-ARIA_implementations" name="Practical_WAI-ARIA_implementations">実際的な WAI-ARIA の実装</h2> + +<p>次のセクションでは、実際の例と共に、より詳細な4つのエリアを見てみます。 続行する前に、これから見る例をテストできるように、スクリーンリーダーのテスト環境を用意してください。 </p> + +<p>詳細は <a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">スクリーンリーダーのテスト</a> を確認してください。</p> + +<h3 id="SignpostsLandmarks" name="SignpostsLandmarks">道しるべ/ランドマーク（Signpost/Landmark）</h3> + +<p>WAI-ARIA は <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions"><code>role</code> 属性</a>（英語）をブラウザーに追加することで、必要に応じてあなたのサイトに付加的な意味論的<span class="tlid-translation translation"><span title="">価値</span></span>を追加することができます。 これが有用となる最初の領域は、スクリーンリーダーのユーザーが共通のページ要素を見つけることができるようになる情報の提供です。 例を見てみましょう。私達の <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-no-roles">website-no-roles</a> の例（<a href="http://mdn.github.io/learning-area/accessibility/aria/website-no-roles/">実際の動作</a>）は、次の構造を持っています。</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav> + <ul>...</ul> + <form> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article>...</article> + <aside>...</aside> +</main> + +<footer>...</footer></pre> + +<p>もしあなたがモダンなブラウザーでスクリーンリーダーのテストをした場合、いくつかの有用な情報を手に入れるでしょう。 例えば、 VoiceOver は次の内容を読み上げます:</p> + +<ul> + <li><code><header></code> 要素の上 — "banner, 2 items"（見出しと <code><nav></code> を含んでいる）</li> + <li><code><nav></code> 要素の上 — "navigation 2 items"（リストとフォームを含む）</li> + <li><code><main></code> 要素の上 — "main 2 items"（記事（article）と余談（aside）を含む）</li> + <li><code><aside></code> 要素の上 — "complementary 2 items"（見出しとリストを含む）</li> + <li>検索フォーム入力の上 — "Search query, insertion at beginning of text"</li> + <li><code><footer></code> 要素の上 — "footer 1 item"</li> +</ul> + +<p>VoiceOver の Landmarks メニューを見ると（VoiceOver キー + U でアクセスし、矢印キーでメニューを選択する）、多くの要素が素早くアクセスできるように綺麗に並んでいることが確認できます。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14420/landmarks-list.png" style="display: block; margin: 0 auto;"></p> + +<p>しかし、これは改善することができます。 検索フォームはユーザーが見つけたいと考える重要なランドマークですが、ここでは Landmarks メニューの中に列挙されておらず、検索入力<code>（<input type="search"></code>）であるということ以上に目立つランドマークとしても扱われていません。 加えて、いくつかの古いブラウザー（特に IE8）は HTML5 要素の意味論を認識しません。</p> + +<p>ARIA の機能を使用してこれを改善しましょう。 まず、 HTMLに対していくつかの <code>role</code> 属性を追加します。 私達のオリジナルファイルをコピーするか（<a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/index.html">index.html</a> と <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/style.css">style.css</a> を参照）、 <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-aria-roles">website-aria-roles</a> の例（<a href="http://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/">実際の動作</a>）へ移動すると、次の構造を確認できます。</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav role="navigation"> + <ul>...</ul> + <form role="search"> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article role="article">...</article> + <aside role="complementary">...</aside> +</main> + +<footer>...</footer></pre> + +<p>この例では、ボーナス機能も提供しています — {{htmlelement("input")}} は <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code> 属性が設定されていますが、これは {{htmlelement("label")}} 要素が含まれていない場合でもスクリーンリーダーによって読み上げられる説明ラベルを設定します。 こういうケースでは、この機能はとても便利です — このような検索フォームはよくあるものであり、簡単に識別できるので、見えるラベルを設定するとデザインを台無しにしてしまうのです。</p> + +<pre class="brush: html"><input type="search" name="q" placeholder="Search query" aria-label="Search through site content"></pre> + +<p>さて、この例を VoiceOver で見た時、次の改善を確認することができます。</p> + +<ul> + <li>ページをブラウジングした時と、 Landmarks メニューで見た時の両方において、検索フォームが分離したアイテムとして認識される。</li> + <li>フォーム入力がハイライトされた時、 <code>aria-label</code> に含まれているテキストが読み上げられる。</li> +</ul> + +<p>さらに、このサイトは IE8 のような古いブラウザーを使用しているユーザーにとってもアクセス可能となる可能性が高いので、そのために ARIA ロールを含める価値もあります。 そして、もしあなたのサイトが何らかの理由により <code><div></code> のみで構成されているなら、必要な意味論を提供するために確実に ARIA ロールを含めるべきです！</p> + +<p>改善された検索フォームは、 HTML5 で利用できる意味論以上に ARIA が可能とすることを見せてくれました。 あなたは以下の記事、特に {{anch("Accessibility of non-semantic controls","意味論的でないコントロールのアクセシビリティ")}} のセクションで、より多くの意味論や ARIA のプロパティ/属性が持つ力を見ることがでしょう。 まずは、 ARIA が動的コンテンツの更新をどのように助けるかを見てみましょう。</p> + +<h3 id="Dynamic_content_updates" name="Dynamic_content_updates">動的なコンテンツの更新</h3> + +<p>DOM に読み込まれたコンテンツ（本文の内容や、画像の代替テキストなど）はスクリーンリーダーを用いて容易にアクセスできます。 従って、テキストコンテンツで作られた伝統的で静的なウェブサイトを、視覚的ハンディキャップを持つ人々にとってアクセス可能にすることは容易です。</p> + +<p>問題はモダンなウェブアプリが静的なテキストだけを使うことは少ないという点です。 それらは動的に更新されるコンテンツ、すなわち、<a href="/ja/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>、<a href="/ja/docs/Web/API/Fetch_API">Fetch</a>、<a href="/ja/docs/Web/API/Document_Object_Model">DOM API</a> などの機構を通してページ全体をリロードすることなく更新を行うコンテンツで構成されることが多いです。 このような箇所はしばしば<strong>ライブリージョン（live region）</strong>と呼ばれます。</p> + +<p>簡単な例を見てみましょう。 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> をご覧ください（もしくは <a href="http://mdn.github.io/learning-area/accessibility/aria/aria-no-live.html">動作版をご覧ください</a>）。 この例では、ランダムに引用文を表示する1つの箱があります。</p> + +<pre class="brush: html"><section> + <h1>Random quote</h1> + <blockquote> + <p></p> + </blockquote> +</section></pre> + +<p>JavaScript が <code><a href="/ja/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a></code> を通して JSON ファイルを読み込みます。 この JSON ファイルには、複数のランダムな引用文とその著者が含まれています。 読み込みの完了後に <code><a href="/ja/docs/Web/API/WindowTimers/setInterval">setInterval()</a></code> ループを開始し、引用文の表示を10秒ごとに新しいものに切り替えます。</p> + +<pre class="brush: js">var intervalID = window.setInterval(showQuote, 10000);</pre> + +<p>これは正しく動作しますが、アクセシビリティとしてはよくありません。 コンテンツの更新がスクリーンリーダーに検知されないため、ユーザーは何が起こっているかを知ることができないからです。 これはつまらない例ですが、更新され続けるコンテンツを多く含む複雑な UI をあなたが作ることを想像してください（チャットルームや戦略ゲームの UI、動的に更新されるショッピングカートの表示など）。 ユーザーに更新を知らせる何かしらの手段がない限り、それがどんなに実用的なアプリであっても使いこなすことはできないでしょう。</p> + +<p>幸いなことに WAI-ARIA はそのような通知を行う便利な機構を提供しています。 それが <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-live">aria-live</a></code> プロパティです。 このプロパティを要素に適用すると、スクリーンリーダーが更新されたコンテンツを読み上げてくれるようになります。 どのような緊急性をもってコンテンツを読み上げてくれるかは、次のように属性値によって変わります。</p> + +<ul> + <li><code>off:</code> デフォルト値。更新は通知されない (should not)。</li> + <li><code>polite</code>: 更新はユーザが暇になったときのみ通知される (should)。</li> + <li><code>assertive</code>: 更新は可能な限り早くユーザに通知される (should)。</li> +</ul> + +<p><a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> と <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/quotes.json">quotes.json</a> のコピーを作成し、<code><section></code> タグの内容を次のように更新してください。</p> + +<pre class="brush: html"><section aria-live="assertive"></pre> + +<p>これにより、コンテンツの更新があった際にスクリーンリーダーがその内容を読み上げてくれるようになります。</p> + +<div class="note"> +<p><strong>注</strong>: <code>file://</code> URL をもつページから <code>XMLHttpRequest</code> を呼び出そうとするとほとんどのブラウザーはセキュリティ例外を投げます。 例えば、（ダブルクリックなどにより）ファイルを直接ブラウザーで読み込んだ場合に <code>file://</code> URLで開かれます。 動作させるためには、 ウェブサーバー（<a href="/ja/docs/Learn/Common_questions/Using_Github_pages">GitHub を利用</a>するなど）やローカルウェブサーバー（<a href="http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/">Python の SimpleHTTPServer</a>（英語）など）にファイルをアップロードする必要があります。</p> +</div> + +<p>加えて、考慮すべきことがあります。 テキストの更新された部分だけを読み上げるべきかどうかです。 常に見出し全体を読み上げる方が、何を読み上げられているかをユーザーが認識できるという点で望ましいかもしれません。 その対象に <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-atomic">aria-atomic</a></code> プロパティを追加することで、このような動作を得ることができます。 手元の <code><section></code> タグを再度更新して、次のようにしてください。</p> + +<pre class="brush: html"><section aria-live="assertive" aria-atomic="true"></pre> + +<p>この <code>aria-atomic="true"</code> 属性が、更新された一部分だけではなく、要素全体のコンテンツを1つのまとまりとして読み上げるようスクリーンリーダーに伝えます。</p> + +<div class="note"> +<p><strong>注</strong>: 完成した例は <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html">aria-live.html</a> をご覧ください（もしくは<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-live.html">動作版をご覧ください</a>）。</p> +</div> + +<div class="note"> +<p><strong>注</strong>: <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> プロパティはライブリージョンが更新された際に何が読み上げられるかを制御するのに非常に役に立ちます。 例えば、追加や削除をされた内容だけを読み上げさせることもできます。</p> +</div> + +<h3 id="Enhancing_keyboard_accessibility" name="Enhancing_keyboard_accessibility">キーボードでのアクセシビリティの拡張</h3> + +<p>このモジュールの他の箇所でも何度か言及したように、アクセシビリティという観点での HTML がもつ重要な能力の1つが、キーボードでのアクセシビリティが組み込まれていることです。 キーボードから、ボタンやフォームコントロール、リンクなどの機能にアクセスできます。 一般的に、タブキーでコントロール間を移動したり、エンター/リターンキーでコントロールの選択や活性化をしたり、必要に応じたその他の制御（例えば、上下矢印キーでの <code><select></code> ボックス内のオプション間の移動）ができます。</p> + +<p>しかし、時には（ボタンや他のタイプのコントロールとして）意味論的でない要素や正しい用途ではないフォーカス可能な要素を利用するコードを書かざるをえないこともあるでしょう。 あなたが引き継いだ作りの悪いコードを修正したり、そのようなコードを必要とする複雑なウィジェットを作ったりする場合があるかもしれません。</p> + +<p>フォーカスできないコードをフォーカス可能にするために、WAI-ARIA では <code>tabindex</code> 属性を拡張して次のようにいくつかの値を加えています。</p> + +<ul> + <li><code>tabindex="0"</code> — 上で示したように、この値は通常タブキーでの移動対象とならない要素をタブ移動可能にします。 この値は <code>tabindex</code> の値の中で最も便利なものです。</li> + <li><code>tabindex="-1"</code> — この値は通常タブキーでの移動対象とならない要素がプログラム的にフォーカスを受け付けられるようにします。 例えば、JavaScript を利用したりリンクのターゲットとしてフォーカスするケースです。</li> +</ul> + +<p>より詳細な議論や典型的な実装例については、HTML のアクセシビリティに関する記事 — <a href="/ja/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">キーボード・アクセシビリティを呼び戻すように盛り込む</a> をご覧ください。</p> + +<h3 id="Accessibility_of_non-semantic_controls" name="Accessibility_of_non-semantic_controls">意味論的でないコントロールのアクセシビリティ</h3> + +<p>このセクションの内容は前セクションの続きです。 多くの入れ子になった <code><div></code> 要素と CSS/JavaScript を利用して複雑な UI 機能を構築した場合、また、JavaScript で本来のコントロールの機能を拡張/改変した場合を考えてみましょう。 そのようなときには、キーボードでのアクセシビリティが損なわれるだけでなく、スクリーンリーダーのユーザーが各機能のふるまいを理解することは何らかの意味論や手がかりがない限り困難となってしまう。 そのような状況においても、ARIA はそこにあるべき意味論を補足する手助けができます。</p> + +<h4 id="Form_validation_and_error_alerts" name="Form_validation_and_error_alerts">フォーム検査とエラー警告</h4> + +<p>まず、CSS と JavaScript のアクセシビリティ の記事で最初に見たフォームの例を再検討しましょう（完全なまとめを再び見るには、<a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript#Keeping_it_unobtrusive">ひかえめに保つこと</a> をお読みください）。 フォームを送信しようとした際に検査エラーがあると現れるエラーメッセージ・ボックスにいくつかの ARIA 属性を含めたことを、そのセクションの末尾で示しておきました。</p> + +<pre class="brush: html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>div</span> <span class="attr-name token">class</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>errors<span class="punctuation token">"</span></span> <span class="attr-name token">role</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>alert<span class="punctuation token">"</span></span> <span class="attr-name token">aria-relevant</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>all<span class="punctuation token">"</span></span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>ul</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>ul</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>div</span><span class="punctuation token">></span></span></code></pre> + +<ul> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#alert">role="alert"</a></code> は、適用先の要素を自動的にライブリージョンにします。 すると、その要素に対する変更は読み上げられます。 また、<code><a href="https://www.w3.org/TR/wai-aria-1.1/#alert">role="alert"</a></code> は、その要素が警告メッセージ（重要であり、時間 / コンテキストの影響を受ける情報）なのだ、と意味論的に特定しています。 かつ、ユーザーに警告を伝える、より優れていてよりアクセス可能な方法も、表現しています（<code><a href="/ja/docs/Web/API/Window/alert">alert()</a></code> の呼び出しのようなモーダル・ダイアログには、いくつものアクセシビリティの問題があります。 WebAIM による <a href="http://webaim.org/techniques/javascript/other#popups">ポップアップ・ウィンドウ</a>（英語）を参照）。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> の <code>all</code> という値は、エラー・リストに対して何らかの変更がなされた際には（つまり、エラーが追加または削除された際には）エラー・リストの中身を読み上げるよう、スクリーンリーダーに命令するものです。 これは有用です。 なぜなら、ユーザーは、リストに何が追加され、リストから何が削除されたのかを知りたいだけでなく、何のエラーが残っているのかを知りたいでしょうからね。</li> +</ul> + +<p>ARIA を使用して、更に先へ踏み込むこともできるでしょうし、なんらかの検査の手助けを更に提供することもできるでしょう。 そもそもフィールドが必須かどうかを示すことや、年齢がどの範囲にあるべきかを示すこと、などはいかがでしょうか？</p> + +<ol> + <li>いまの時点で、<a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> と <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/validation.js">validation.js</a> のファイルのコピーをとり、それをローカル・ディレクトリに保存してください。</li> + <li>両ファイルをテキストエディタで開き、コードがどのように動くのかを見てください。</li> + <li>まず始めに、<code><form></code> 開始タグのすぐ上に次のような段落を加えるとともに、フォームの <code><label></code> には、両方ともアスタリスクの印をつけてください。 これは、晴眼者ユーザー用に必須フィールドに印をつける通常の方法です。 + <pre class="brush: html"><p>Fields marked with an asterisk (*) are required.</p> +訳: <p>アスタリスク（*）が付いているフィールドは必須です。</p></pre> + </li> + <li>これは視覚的に意味をなしますが、スクリーンリーダーのユーザーにとっては、理解するのがそれほど容易ではありません。 さいわい、WAI-ARIA には、フォーム入力欄を埋める必要があることをユーザーに伝えるべきだとスクリーンリーダーにヒントを与えるための、<code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-required">aria-required</a></code> 属性があります。 <code><input></code> 要素を次のように更新してください。 + <pre class="brush: html"><input type="text" name="name" id="name" aria-required="true"> + +<input type="number" name="age" id="age" aria-required="true"></pre> + </li> + <li>この例をここで保存してスクリーンリーダーでテストしてみれば、「Enter your name star, required, edit text（名前を入れてください 星、必須、テキストを編集）」のようなものを聞くことになるはずです。</li> + <li>年齢の値がどうあるべきかについて、スクリーンリーダーのユーザーと晴眼者のユーザーに知らせるのも、有用かもしれません。 これはツールチップとして提示されることがよくあり、あるいは、フォームのフィールド内部のプレースホルダーとして提示されることも、多分あります。 最小値と最大値を指定するための <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemin">aria-valuemin</a></code> プロパティと <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemax">aria-valuemax</a></code> プロパティを、WAI-ARIA は確かに含んではいますが、これらのプロパティは、今のところそれほどちゃんとサポートされてはいないようです。 よりちゃんとサポートされている機能は、HTML5 の <code>placeholder</code> 属性です。 これは、何の値も入力されていないときに入力欄の中に表示されるメッセージを含むことができ、多くのスクリーンリーダーにより読み上げられます。 数値入力欄を次のように更新してください。 + <pre class="brush: html"><input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true"></pre> + </li> +</ol> + +<div class="note"> +<p><strong>注</strong>: この完成した例を、<a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html">form-validation-updated.html</a> においてライブ版で見られます。</p> +</div> + +<p>また、古典的な {{htmlelement("label")}} 要素以上の、ある種の先進的なフォームのラベルづけ技法も、WAI-ARIA によって可能になります。 晴眼者のユーザーに対してラベルを可視にしたくない箇所にラベルを設けるために <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code> プロパティを使うことについては、すでに述べました（上記の {{anch("SignpostsLandmarks", "道しるべ/ランドマーク（Signpost/Landmark）")}} のセクションを参照）。 別のプロパティを使う別のラベルづけ技法も、いくつかあります。 例えば、非 <code><label></code> 要素をラベルとして指定したいとき、または、同じラベルで複数のフォーム入力欄にラベルづけをしたいときに <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby">aria-labelledby</a></code> を使うとか、別の情報をフォーム入力欄に関連づけてその情報も同様に読み上げさせたいときに <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-describedby">aria-describedby</a></code> を使うとかいったものです。 より詳しくは、WebAIM の <a href="http://webaim.org/techniques/forms/advanced">高度なフォームのラベル付け</a>（英語）の記事を参照してください。</p> + +<p>フォーム要素の状態を示すための有用なプロパティやステートは、ほかにもたくさんあります。 例えば、フォーム・フィールドが無効化されていることを示すには、<span class="subtitle"><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-disabled">aria-disabled</a>="true"</code> </span>が使えます。 多くのブラウザーは、無効化されたフォーム・フィールドを単に飛ばすだけでしょうし、無効化されたフォーム・フィールドは、スクリーンリーダーに読み上げられることすらないでしょう。 しかし、無効化されたフォーム・フィールドが認識される場合もあるでしょう。 ですから、無効化されている入力欄が実際に無効化されているのだ、とスクリーンリーダーに知らせるために、この（<span class="subtitle"><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-disabled">aria-disabled</a>="true"</code></span> という）属性を含めておくことは、良い考えです。</p> + +<p>もし入力欄の無効化ステートが変化する可能性が高いなら、その変化が起きた時点と、その結果どうなったのかを示すことも、良い考えです。 例えば、<span class="subtitle"><a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-checkbox-disabled.html">form-validation-checkbox-disabled.html</a> </span>のデモには、チェックされると他のフォーム入力欄への更なる情報の入力を可能とするようなチェックボックスがあります。 次のように隠しライブリージョンを設定してあります。</p> + +<pre class="brush: html"><p class="hidden-alert" aria-live="assertive"></p></pre> + +<p>これは、絶対的位置指定を使って、視界からは隠してあります。 これがチェックされたり、これのチェックが外されたりすると、このチェックボックスのチェックの結果がどうなったのかをスクリーンリーダーのユーザーに伝えるために、<code>aria-disabled</code> ステートやいくつかの視覚的表示を更新するだけでなく、この隠しライブリージョン内部のテキストも更新します。</p> + +<pre class="brush: js">function toggleMusician(bool) { + var instruItem = formItems[formItems.length-1]; + if(bool) { + instruItem.input.disabled = false; + instruItem.label.style.color = '#000'; + instruItem.input.setAttribute('aria-disabled', 'false'); + hiddenAlert.textContent = 'Instruments played field now enabled; use it to tell us what you play.'; + } else { + instruItem.input.disabled = true; + instruItem.label.style.color = '#999'; + instruItem.input.setAttribute('aria-disabled', 'true'); + instruItem.input.removeAttribute('aria-label'); + hiddenAlert.textContent = 'Instruments played field now disabled.'; + } +}</pre> + +<h4 id="Describing_non-semantic_buttons_as_buttons" name="Describing_non-semantic_buttons_as_buttons">非意味論的なボタンをボタンとして説明する</h4> + +<p>この課程の中で既に二、三回、ボタンやリンクやフォーム要素に本来備わったアクセシビリティ（および、ボタンやリンクやフォーム要素の外見を模倣するために他の要素を使うことの背後に隠れた、アクセシビリティの問題）について述べました（HTML アクセシビリティの記事の <a href="/ja/docs/Learn/Accessibility/HTML#UI_controls">UI コントロール</a> と、上記の {{anch("Enhancing_keyboard_accessibility", "キーボードでのアクセシビリティの拡張")}} を参照）。<br> + 基本的には、多くの場合、<code>tabindex</code> とほんの少しの JavaScript を使えば、それほど問題を生じずにキーボード・アクセシビリティを追加して呼び戻せます。</p> + +<p>しかし、スクリーンリーダーについてはどうでしょうか？ スクリーンリーダーはそれでもまだ、そうした要素をボタンとは見なさないことでしょう。 もし <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> の例をスクリーンリーダーで試してみれば、見せかけのボタンは「Click me!, group（クリックしてください！、グループ）」のような語句を使って報告されるでしょうし、それは明らかに混乱を招くものです。</p> + +<p>WAI-ARIA ロールを用いてこれを修正できます。 <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> のローカルコピーを作って、ボタンとしての <code><div></code> の各々に <code><a href="https://www.w3.org/TR/wai-aria-1.1/#button">role="button"</a></code> と追加してください。 例えば次のようにします。</p> + +<pre><div data-message="This is from the first button" tabindex="0" role="button">Click me!</div></pre> + +<p>今や、スクリーンリーダーを使ってこれを試してみれば、「Click me!, button（クリックしてください！、ボタン）」のような語句を使ってボタンを報告させることになるでしょう。 ずっと良くなりましたね。</p> + +<div class="note"> +<p><strong>注</strong>: とはいえ、可能な箇所では正しい意味的要素を使うことの方が常に良いのだ、ということを忘れないようにしてください。 もしボタンを作りたいなら、そして {{htmlelement("button")}} 要素が使えるなら、{{htmlelement("button")}} 要素を使うべきです！</p> +</div> + +<h4 id="Guiding_users_through_complex_widgets" name="Guiding_users_through_complex_widgets">複雑なウィジェットを通じてユーザーを案内する</h4> + +<p>非意味論的な要素構造を、標準的な HTML で利用可能な UI 機能以上の一般的な UI 機能——例えば、<code><a href="https://www.w3.org/TR/wai-aria-1.1/#combobox">combobox</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#slider">slider</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tree">tree</a></code> など——として指定できる、大変多くの他の <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">ロール</a>（英語）があります。 そうしたコントロールをどのようにすればアクセス可能にできるのかについて理解するために、<a href="https://dequeuniversity.com/library/">Deque 大学のコード・ライブラリ</a>（英語）で多くの有用な事例を見ることができます。</p> + +<p>わたしたち自身の事例を検討しましょう。 単純で、絶対的位置指定をした、タブ付きのインターフェイス（CSS と JavaScript のアクセシビリティの記事の、<a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript#Hiding_things">ものごとを隠す</a> を参照）へと戻りましょう。 これは、<a class="external external-icon" href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">タブ付きの情報ボックスの例</a>（<a class="external external-icon" href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">ソースコード</a> を参照）の中に見つかります。</p> + +<p>この例は、このままでもキーボード・アクセシビリティに関しては、うまく機能します。 幸いなことに、異なるタブ同士の間でのタブ移動が可能ですし、タブを選択して当該タブの中身を表示することもできます。 また、次の点でもかなりアクセス可能です。 すなわち、たとえ画面上で何が起きているのかが見えないとしても、コンテンツ全体にわたってスクロールすることはできますし、見出しを使って見通しを得ることもできます。 でも、そのコンテンツが何であるのかは、明らかではありません。 スクリーンリーダーは今のところ、そのコンテンツのことを、リンクのリストと、三つの見出しを備えた何らかのコンテンツである、と報告してきます。 スクリーンリーダーは、コンテンツ間にどういう関係があるのかについては、何も知らせてくれません。 コンテンツの構造に関する更なる手がかりをユーザーに与えることは、常に良いことです。</p> + +<p>ものごとを改善するために、わたしたちは、<a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-tabbed-info-box.html">aria-tabbed-info-box.html</a> と呼ばれる、本例の新たなバージョンを作成しました（<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-tabbed-info-box.html">これがライブ版で動くところも参照</a>）。 タブ付きのインターフェイスの構造を次のように更新しておきました。</p> + +<pre class="brush: html"><ul role="tablist"> + <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li> +</ul> +<div class="panels"> + <article class="active-panel" role="tabpanel" aria-hidden="false"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> +</div></pre> + +<div class="note"> +<p><strong>注</strong>: ここでの最も際立った変更点は、この例にもともと存在していたリンクを削除して、単にリスト項目をタブとして使ったことです。 このようにした理由は、スクリーンリーダーのユーザーにとっての物事の紛らわしさを減らせるからであり（これらのリンクは、実際にどこかへ連れて行ってくれるものではなく、ただ見かけを変化させるだけのものなのです）、また、セット機能における setsize/position が、よりうまく機能できるようになるからです。 setsize/position がリンク上に設定されている場合、ブラウザーは、「3 分の 1」「3 分の 2」などではなく、常に「1 分の 1」と報告し続けます。</p> +</div> + +<p>新たな機能は次の通りです。</p> + +<ul> + <li>新たなロール——すなわち <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tablist">tablist</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tab">tab</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code> ——は、タブ付きインターフェイスでの重要な領域——つまり、タブ群のコンテナと、タブ自体と、対応するタブパネル——を識別します。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-selected">aria-selected</a></code> — 今どのタブが選択されているのかを定めます。 別のタブがユーザーにより選択されると、その別のタブ上のこの属性の値が、JavaScript を介して更新されます。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-hidden">aria-hidden</a></code> — スクリーンリーダーに読み上げられないように、要素を隠します。 別のタブがユーザーにより選択されると、その別のタブ上のこの属性の値が、JavaScript を介して更新されます。</li> + <li><code>tabindex="0"</code> — リンクを削除したので、リスト項目にキーボード・フォーカスを与えるためには、リスト項目にこの属性を与える必要があります。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-setsize">aria-setsize</a></code> — 要素が一連のもののうちの一部なのだということと、その一連のものの中にいくつの項目があるのかということを、スクリーンリーダーに対して指定することが、このプロパティによって可能となります。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-posinset">aria-posinset</a></code> — 一連のものの中で要素がどの位置にあるのかを指定することが、このプロパティによって可能となります。 このプロパティを <code>aria-setsize</code> と一緒に用いると、現在「3 分の 1」の項目にいます、などと知らせるのに十分な情報を、スクリーンリーダーに対して提供してくれます。 多くの場合、ブラウザーは、要素の階層構造からこの情報を推測できるはずですが、<code>aria-posinset</code> は、更なる手がかりを与えるのに確かに役立ちます。</li> +</ul> + +<p>わたしたちの検査では、この新たな構造は、物事を全体的に改善するのに確かに役立ちました。 今や、タブはタブとして認識されます（例えば、スクリーンリーダーが「タブ」と話します）し、選択されたタブは、そのタブ名で読み上げられて「選択中」と示されますし、スクリーンリーダーは、どのタブ番号のところに今いるのかということも教えてくれます。 さらに、<code>aria-hidden</code> の設定（まさに隠されていないタブのみに、<code>aria-hidden="false"</code> と設定されている）のおかげで、隠されていないコンテンツのみが、ナビゲートして下ってゆける唯一のコンテンツとなっており、このことは、選択されたコンテンツを見つけやすくなったことを意味します。</p> + +<div class="note"> +<p><strong>注</strong>: スクリーンリーダーに読み上げさせたくないと明示的に思うものが何かある場合、スクリーンリーダーに対して、<code>aria-hidden="true"</code> 属性を与えることができます。</p> +</div> + +<h2 id="Summary" name="Summary">まとめ</h2> + +<p>本記事は、WAI-ARIA で利用可能なすべてのものを取り扱ったとは、到底、言えません。 でも、WAI-ARIA の使い方を理解するのに十分な情報をお伝えしたはずです。 また、これから出会うであろう、WAI-ARIA を必要とするような最もよくあるパターンのうちのいくつかを知るのに十分な情報も、お伝えしたはずです。</p> + +<h2 id="See_also" name="See_also">関連情報</h2> + +<ul> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">ロールの定義</a> — ARIA ロールのリファレンスです。（英語）</li> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">ステートとプロパティの定義（すべての aria-* 属性）</a> — プロパティとステートのリファレンスです。（英語）</li> + <li><a href="https://dequeuniversity.com/library/">Deque 大学のコード・ライブラリ</a> — WAI-ARIA 機能を使ってアクセス可能にしてある複雑な UI コントロールを見せてくれる、実に有用かつ実践的な例からなるライブラリです。（英語）</li> + <li><a href="http://w3c.github.io/aria-practices/">WAI-ARIA のオーサリング・プラクティス</a> — W3C による非常に詳細なデザイン・パターンです。異なる種類の複雑な UI コントロールを、WAI-ARIA 機能を用いてアクセス可能にしつつ、実装する方法を説明しています。（英語）</li> + <li><a href="https://www.w3.org/TR/html-aria/">ARIA in HTML</a> — HTML の部品の各々について、どのアクセシビリティ（ARIA）の意味論がその部品に対してブラウザーにより暗黙裡に設定されるのか、そして、追加の意味論が必要な場合にはどの WAI-ARIA 機能をその部品に設定しうるのか、ということを定義する、W3C の仕様書です。</li> +</ul> + +<p>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</p> + + + +<h2 id="In_this_module" name="In_this_module">このモジュール内の文書</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは？</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルのアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">評価: アクセシビリティのトラブルシューティング</a></li> +</ul> diff --git a/files/ja/learn/accessibility/what_is_accessibility/index.html b/files/ja/learn/accessibility/what_is_accessibility/index.html new file mode 100644 index 0000000000..8f4efd327a --- /dev/null +++ b/files/ja/learn/accessibility/what_is_accessibility/index.html @@ -0,0 +1,233 @@ +--- +title: アクセシビリティとは？ +slug: Learn/Accessibility/What_is_accessibility +tags: + - AT + - Accessibility + - Article + - Beginner + - CSS + - CodingScripting + - HTML + - JavaScript + - Learn + - Tools + - Users + - assistive technology + - keyboard + - screan reader + - screenreader +translation_of: Learn/Accessibility/What_is_accessibility +--- +<div>{{LearnSidebar}}</div> + +<div>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</div> + +<p class="summary">この記事では実際アクセシビリティとは何かについてよく観察するモジュールから開始します — これには考慮が必要な人のグループや、いろいろな人がウェブとやり取りするのになぜ、どんなツールを使うのかや、アクセシビリティをウェブ開発のワークフローに取り組む方法が含まれます。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row"> + <p>前提知識:</p> + </th> + <td>基本的なコンピューターの知識、HTML と CSS に関する基本的な理解</td> + </tr> + <tr> + <th scope="row">学習目標:</th> + <td>アクセシビリティとは何か、そしてそれがウェブ開発者としてのあなたにどう関わってくるかを含め、アクセシビリティに詳しくなる</td> + </tr> + </tbody> +</table> + +<h2 id="So_what_is_accessibility" name="So_what_is_accessibility">で、アクセシビリティって何？</h2> + +<p>アクセシビリティというのはあなたのウェブサイトを可能な限り多くの人に利用してもらうようにすることです。かつては我々はアクセシビリティのことをハンディキャップを持つ人々のためのものだと考えていましたが、現在はモバイルデバイスや遅いネットワークを利用している人々のためのものでもあると考えられています。</p> + +<p>アクセシビリティを、能力や環境にかかわらず全員を同一に扱い、同じ機会を与えることと考えることもあります。車椅子に乗っているために物理的な建物から誰かを除外するのは正しくないのと同様に(昨今一般的に公的な建物では、車椅子のスロープやエレベーターを備えています)、視覚障碍があるためにウェブサイトから特定のユーザーを除外するのも正しくありません。我々はみんな異なっていて、しかしみんな人間であり、ゆえに同じ人権を持っています。</p> + +<p>アクセシビリティは正しい行為です。アクセシブルなサイトを提供することは、いくつかの国では法律の一部でもあり、そうしなければサービスを利用したり、製品を買ったりすることなどができなかったであろう、いくつかの重要な市場を開拓することができます。</p> + +<p>アクセシブルなサイトを構築するのは、すべての人の利益になります:</p> + +<ul> + <li>意味論的 HTML (これはアクセシビリティを改良します) は SEO の改善にもなり、サイトがもっと発見しやすいものになります。</li> + <li>アクセシビリティへの留意は倫理とモラルを誇示することになり、公的イメージが良くなります。</li> + <li>その他のアクセシビリティ改良の事例は、例えば携帯電話のユーザーや、ネットワーク速度が遅い人といったその他のグループにとってより使いやすくなります。実際にすべての人がこうした改良で利益を得ます。</li> + <li>ある場所では法律となっているって言いましたっけ？</li> +</ul> + +<h2 id="What_kinds_of_disability_are_we_looking_at" name="What_kinds_of_disability_are_we_looking_at">私たちが考える"不利な条件"とは？</h2> + +<p>障碍のある人は障碍のない人と同じくらい多様であり、よってその障碍も同じくらい多様です。ここでの重要な教訓は、あなたがコンピューターの向こうでウェブをどのように使うかを考え、他の人がどのように使っているかを学習し始めることです — あなたはユーザーとは違います。考慮すべき障碍の主な種類を、ウェブコンテンツにアクセスするために使う特別なツール（<strong>支援技術</strong>、<strong>assistive technology</strong> や <strong>AT</strong> として知られるもの）とともに以下に説明します。</p> + +<div class="note"> +<p><strong>注</strong>: 世界保健機構(WHO)の<a href="https://www.who.int/en/news-room/fact-sheets/detail/disability-and-health">障碍と健康</a>（英語）の報告によると、「10億人以上の人(世界人口の約15%)が何らかの障碍を持っています」し、「1億～1億9000万人の大人に目立った機能障碍があります」</p> +</div> + +<h3 id="People_with_visual_impairments" name="People_with_visual_impairments">視覚障碍者</h3> + +<p>視覚障碍者には全盲の人や、視覚が低レベルな人、色盲の人などが含まれます。これらの多くはスクリーン拡大鏡 (物理的な拡大鏡とソフトウェアズーム機能のいずれか — 大半のブラウザーと OS には今日ズーム機能があります) を使い、スクリーンリーダー、つまりデジタルテキストを読み上げるソフトウェアを使う人もいます。スクリーンリーダーの例はこれらです:</p> + +<ul> + <li>有償の商用製品、例えば <a class="external external-icon" href="https://www.freedomscientific.com/Products/software/JAWS/">JAWS</a> (Windows) や <a href="https://yourdolphin.com/screenreader">Dolphin Screen Reader </a>(Windows).</li> + <li>無償の製品、例えば <a class="external external-icon" href="https://www.nvaccess.org/">NVDA</a> (Windows), <a class="external external-icon" href="https://www.chromevox.com/">ChromeVox</a> (Chrome, Windows Mac OS X), や <a class="external external-icon" href="https://wiki.gnome.org/Projects/Orca">Orca</a> (Linux).</li> + <li>OS に組み込まれたもの、例えば <a class="external external-icon" href="https://www.apple.com/accessibility/mac/vision/">VoiceOver</a> (Mac OS Xと iPadOSと iOS), <a class="external external-icon" href="https://support.microsoft.com/en-us/help/22798/windows-10-narrator-get-started">Narrator</a> (Microsoft Windows), <a class="external external-icon" href="http://www.chromevox.com/">ChromeVox</a> (Chrome OS), や <a class="external external-icon" href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a> (Android).</li> +</ul> + +<p>スクリーンリーダーに精通するのは良い考えです; スクリーンリーダーをセットアップして試してみて、その動作方法を理解するべきです。 <a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">クロスブラウザーテストのスクリーンリーダーのガイド</a> を見ると詳しい使い方がわかります。下記の動画も、その体験がどのようなものかの簡単な例です。</p> + +<p>{{EmbedYouTube("IK97XMibEws")}}</p> + +<p>統計では、WHO は「世界中で 2億8500万人が視覚障碍者で、うち 3900万人が全盲で 2億4600万人がロービジョンです」と見積もっています(<a href="https://www.who.int/mediacentre/factsheets/fs282/en/">視覚障碍と盲目</a>（英語）を参照)。これは単にサイトが適切にコーディングされていないために逃すユーザーとしては多くて重要です — 米国の人口とほぼ同じ大きさです。</p> + +<h3 id="People_with_hearing_impairments" name="People_with_hearing_impairments">聴覚障碍者</h3> + +<p>耳の障碍者や、ろう者とも知られて、このグループの人には聞こえにくい人と全く聞こえない人の両方がいます。聴覚障碍者は AT（<a href="https://www.nidcd.nih.gov/health/assistive-devices-people-hearing-voice-speech-or-language-disorders">聴覚、発声能力、発話能力、言語に障碍のある人のための補助装置</a>（英語）を参照）を使いますが、コンピューターやウェブに特化した特別な AT はありません。</p> + +<p>しかしながら、単純なテキストトランスクリプトから、動画と一緒に表示できるテキストトラック（すなわちキャプション）まで、彼らが音声コンテンツに代わって読むことができるテキストを提供するために留意すべき特定のテクニックがあります。後の記事で詳しく扱います。</p> + +<p>聴覚障碍者もまた重要なユーザー基盤を代表しています — 「世界中で 4億6,600万人が日常生活に支障を来すほどの聴覚障害を持っています」と WHO は<a href="https://www.who.int/mediacentre/factsheets/fs300/en/">ろうと聴覚障碍</a>（英語）で報告しています。</p> + +<h3 id="People_with_mobility_impairments" name="People_with_mobility_impairments">運動障碍のある人</h3> + +<p>これらの人々は、（四肢の喪失や麻痺のような）純粋に肉体的な問題や、四肢の衰弱や制御不能につながる神経学的障碍や遺伝子疾患を伴う可能性がある、運動に関する障碍を持っています。マウスを使うのに必要な正確な手の動きが難しい人もいれば、もっと深刻な影響を受けて、コンピューターと対話するために<a href="https://www.performancehealth.com/baseball-cap-head-pointer">ヘッドポインタ</a>（英語）を使う必要があるところまで著しく麻痺している人もいます。</p> + +<p>この種の障碍は、特定のトラウマや状態ではなく、老年期の結果であることもあります。それに、ハードウェアの制限から生じることもあります — 一部のユーザーはマウスを持っていないかもしれません。</p> + +<p>これが通常ウェブ開発作業に影響するのは、コントロールがキーボードからアクセス可能であることという要件です — このモジュールの後の記事でキーボード・アクセシビリティを扱いますが、どのようにやるかを見るためにキーボードだけを使っていくつかのウェブサイトを試してみることは良い考えです。例えば、<kbd>Tab</kbd> キーを使ってウェブフォームのさまざまなコントロール間を移動できますか？ キーボードコントロールの詳細については、<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">クロスブラウザーテストのネイティブなキーボード・アクセシビリティを使う</a>のセクションを参照してください。</p> + +<p>統計では、有意な数の人が運動障碍を持っています。米国疾病管理予防センターの<a href="https://www.cdc.gov/nchs/fastats/disability.htm">障碍と機能 (施設に入らない 18 歳以上の大人) </a>（英語）の報告によると、米国では "肉体的な機能障碍のある大人の割合は、16.1%" です。</p> + +<h3 id="People_with_cognitive_impairments" name="People_with_cognitive_impairments">認知障碍者</h3> + +<p>認知障碍者とは最も広い範囲の障碍をいい、最も限定された能力をもつ知的障碍者からわれわれがみな加齢とともに考えたり記憶したりが困難になることまでがあります。この範囲には <a href="https://www.nimh.nih.gov/health/topics/depression/index.shtml">鬱病</a>（英語）や <a href="https://www.nimh.nih.gov/health/topics/schizophrenia/index.shtml">統合失調症</a>（英語）といった精神疾患のほか、<a href="https://www.ninds.nih.gov/Disorders/All-Disorders/Learning-Disabilities-Information-Page">ディスクレシア</a>（英語）や<a href="https://www.nimh.nih.gov/health/topics/attention-deficit-hyperactivity-disorder-adhd/index.shtml">ADHD（注意欠陥多動性障碍）</a>（英語）のような学習障害も含みます。</p> + +<p>理解と集中の困難、<a href="https://www.nimh.nih.gov/health/topics/autism-spectrum-disorders-asd/index.shtml">自閉症スペクトラム</a>（英語）の人々に、<a href="https://www.nimh.nih.gov/health/topics/schizophrenia/index.shtml">統合失調症</a>（英語）を有する人々、および他の多くの障碍を指します。このような障碍は、記憶、問題解決、理解、注意などの問題により、日常生活の多くの部分に影響を及ぼします。重要なこととして、認知障碍の臨床的な定義が広がっていても、そうした障碍をもつ人には共通の機能不全があります。それにはコンテンツを理解し難いこと、タスクを完了する方法を記憶すること、一貫性のないウェブページレイアウトによって混乱することがあります。</p> + +<p>認知障碍者へのアクセシビリティの良い基本事項は、次のものです:</p> + +<ul> + <li>コンテンツを2つ以上の方法で配信する、例えば文字スピーチや動画</li> + <li>簡単に理解できるコンテンツ、例えば簡潔な言語標準で書かれた文章など</li> + <li>重要なコンテンツに焦点があたっていること</li> + <li>気をそらすものを最小化する、例えば不要なコンテンツや広告</li> + <li>ウェブページのレイアウトやナビゲーションに一貫性をもたせる</li> + <li>なじみの要素、例えば未訪問のリンクは下線つきの青で、訪問済みは紫など</li> + <li>複数の処理を論理的で本質的な手順に分けて、進捗を指すものをつけること</li> + <li>ウェブサイトの認証は、セキュリティに妥協しない範囲で、できる限り簡単にする</li> + <li>フォーム完了までに必要な操作はできるだけ少ないこと、例えば明白なエラーメッセージと簡潔なエラー復帰</li> +</ul> + +<h3 id="注記">注記</h3> + +<ul> + <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/Accessibility/Cognitive_accessibility">認知的なアクセシビリティ</a>をもってデザインするのは良い習慣になります。どんな人にも利益になるでしょう。</li> + <li>知的障碍者の多くは身体的な障碍も持っています。ウェブサイトは W3Cの<a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web コンテンツアクセシビリティガイドライン</a>と、その中の<a href="https://wiki.developer.mozilla.org/en-US/docs/Web/Accessibility/Cognitive_accessibility#Guidelines">認知的アクセシビリティガイドライン</a>に従う必要があります。</li> + <li>W3Cの <a href="https://www.w3.org/WAI/GL/task-forces/coga/">認知と学習障碍者のアクセシビリティタスクフォース</a>では認知障碍者のためのウェブアクセシビリティガイドラインを制作しています。</li> + <li>WebAIM の<a href="https://webaim.org/articles/cognitive/">認知のページ</a>には関連する情報やリソースがあります<a name="_GoBack"></a>.</li> + <li>アメリカ疾病予防管理センターの見積もりでは、2018年以降、4人に1人の米国市民には障碍があり、その中で、<a href="https://www.cdc.gov/media/releases/2018/p0816-disability.html">若い人には認知障碍が最もよく見られます。</a></li> + <li>米国では、“知的障碍” は “精神遅滞”の新用語です。英国では、“知的障碍”とは、"学習障害” や “学習困難”のことです。</li> +</ul> + +<h2 id="Implementing_accessibility_into_your_project" name="Implementing_accessibility_into_your_project">プロジェクトにアクセシビリティを実装する</h2> + +<p>よくあるアクセシビリティ神話は、アクセシビリティはプロジェクトに実装するための高価な「余分な追加」であるということです。この神話は、実際には次のいずれかの場合に当てはまります。</p> + +<ul> + <li>重大なアクセシビリティ問題を抱えている既存のウェブサイトにアクセシビリティを「組み込んで改良」しようとしています。</li> + <li>プロジェクトの後期段階で、アクセシビリティとそれに関連する問題を検討し始めたばかりです。</li> +</ul> + +<p>ただし、プロジェクトの開始時からアクセシビリティを検討している場合は、ほとんどのコンテンツをアクセス可能にするためのコストはごくわずかなはずです。</p> + +<p>プロジェクトを計画するときは、他の重要な対象観客セグメント（対象とするデスクトップやモバイルのブラウザーなど）のテストと同様に、アクセシビリティのテストをテスト体制に組み入れます。早期に頻繁にテストし、理想的にはプログラムで検出可能な欠けている機能（画像の<a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Text_alternatives">代替テキスト</a>の欠落、リンクテキストの不良のような — <a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Element_relationships_and_context">要素の関係とコンテキスト</a>を参照）を検出するための自動テストの実行し、より複雑なサイト機能が障碍のあるユーザーのグループに対してどの程度うまく機能するかを確認するために、それらのグループでいくつかのテストを行います。例えば、</p> + +<ul> + <li>私の日付選択ウィジェットをスクリーンリーダーを使う人が使用できますか？</li> + <li>コンテンツが動的に更新される場合、視覚障碍者はそれについて知っていますか？</li> + <li>私の UI ボタンは、キーボードとタッチインターフェイスを使ってアクセスできますか？</li> +</ul> + +<p>コンテンツをアクセス可能にするための作業が必要なコンテンツの潜在的な問題領域をメモしておくことができ、またそうすべきで、徹底的にテストしていることを確認し、解決策や代替案について考えます。次の記事で見るように、テキストコンテンツは簡単ですが、マルチメディアコンテンツや、最先端の 3D グラフィックはどうでしょうか？ あなたはプロジェクトの予算を見て、現実的にそのようなコンテンツをアクセス可能にするために利用可能などんな解決策があるかついて考えるべきです。あなたはマルチメディアコンテンツすべてを転記するために支払うことができます。これは高価になることがありますが、行うことができます。</p> + +<p>現実的にもなりましょう。「100% のアクセシビリティ」は達成不可能な理想です — あなたは常にある種の最先端のケースに出くわすことになり、その結果特定のユーザーが特定のコンテンツを使いにくいと感じることになります — しかしできる限りはするべきです。WebGL を使用して作成した最先端の 3D 円グラフのグラフィックを含めることを計画している場合は、データのアクセス可能な代替表現としてデータ表を含めることができます。あるいは、表だけを含めて 3D 円グラフを取り除くことをお勧めします — 表には誰でもアクセスでき、コード作成が早く、CPU 使用率が低く、保守が簡単です。</p> + +<p>これに反して、興味深い 3D アートを展示したギャラリーのウェブサイトで作業している場合、それが完全に視覚的な媒体であることを考えると、すべてのアートが視覚障碍者にとって完全にアクセス可能であることを期待するのは不合理でしょう。</p> + +<p>あなたがアクセシビリティに関心があり、考えていることを示すために、あなたのサイトに、アクセシビリティに向けた方針と、サイトをアクセス可能にするためにどのようなステップを踏んだかを詳しく記載した、アクセシビリティに関する声明を発表してください。あなたのサイトにアクセシビリティの問題があると誰かが文句を言ってきたら、彼らと対話を始め、共感し、そして問題を解決するために合理的なステップを踏みます。</p> + +<div class="note"> +<p><strong>注</strong>: <a href="/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">よくあるアクセシビリティの問題を扱う</a>の記事では、より詳細にテストするべきであるアクセシビリティの詳細について説明しています。</p> +</div> + +<p>要約すると、</p> + +<ul> + <li>プロジェクトの最初からアクセシビリティを考慮し、早期に頻繁にテストしてください。他のバグと同じように、アクセシビリティの問題は、後で発見されたものほど修正が高くつきます。</li> + <li>アクセシビリティに関するベストプラクティスの多くは、障碍のあるユーザーだけではなく、すべてのユーザーに役立つことを念頭に置いてください。例えば、意味論に頼ったマークアップは、スクリーンリーダーに適しているだけでなく、読み込みや実行が高速であるため、すべての人、特にモバイルデバイスを使用している人、および/または遅い接続に適しています。</li> + <li>あなたのサイトにアクセシビリティの声明を発表し、問題を抱えている人々と関わり合いましょう。</li> +</ul> + +<h2 id="Accessibility_guidelines_and_the_law" name="Accessibility_guidelines_and_the_law">アクセシビリティのガイドラインと法律</h2> + +<p>アクセシビリティテストの基礎となる多数のチェックリストと一連のガイドラインがあります。これは、一見すると圧倒的に思われるかもしれません。アドバイスとしては、あなたが注意を払う必要がある基本的な分野に精通すること、そしてあなたにとって最も関連性のあるガイドラインの高いレベルの構造を理解することです。</p> + +<ul> + <li>はじめに、W3C は、アクセシビリティ適合のための非常に正確な、技術に依存しない基準を含む、大きくて非常に詳細なドキュメントを公開しました。これらは <a href="https://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines</a>（WCAG）と呼ばれていますが、決して短く読むことはできません。基準は 4 つの主なカテゴリに分けられます。これらは、実装を認識可能、操作可能、理解可能、そして堅牢にする方法を指定します。簡単に紹介して学習を開始するのに最適な場所は、<a href="https://www.w3.org/WAI/WCAG20/glance/Overview.html">WCAG の概要</a>（英語）です。WCAG の全てを学ぶ必要はありません — 主な関心分野に注意し、WCAG の基準に適合していない分野をハイライトするために、さまざまなテクニックやツールを使用します（詳細は下記を参照）。</li> + <li>あなたの国はまた、彼らの人口に役立つウェブサイトがアクセス可能であることを規定する特定の法律を持つかもしれません — 例えば、EU の <a href="https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf">EN 301 549</a>（PDF、英語）、米国の<a href="https://www.section508.gov/content/learn">リハビリテーション法のセクション 508</a>（英語）、ドイツの<a href="https://www.einfach-fuer-alle.de/artikel/bitv_english/">バリアフリー情報技術に関する連邦条例</a>（英語）、英国の<a href="https://www.legislation.gov.uk/uksi/2018/952/introduction/made">アクセシビリティ規則 2018</a>（英語）、イタリアの<a href="https://www.agid.gov.it/it/design-servizi/accessibilita-siti-web">アクセシビリティ</a>（イタリア語) 、オーストラリアの<a href="https://www.humanrights.gov.au/world-wide-web-access-disability-discrimination-act-advisory-notes-ver-41-2014">障碍者差別禁止法</a>（英語）など。W3C は、国ごとの<a href="https://www.w3.org/WAI/policies/">ウェブアクセシビリティの法および政策</a>（英語）のリストを保持しています。</li> +</ul> + +<p>そのため、WCAG は一連のガイドラインですが、あなたの国ではおそらくウェブアクセシビリティ、または少なくとも公的に利用可能なサービスのアクセシビリティ（ウェブサイト、テレビ、物理的な空間などを含む）を規制する法律があるでしょう。あなたの法律が何であるかを調べることは良い考えです。あなたのコンテンツがアクセス可能であることを確認しようと努力せずに、障碍を持つ人々が訴えた場合、法律な責任を負うこともあります。</p> + +<p>これは深刻に思えますが、実際には、上で概説したように、アクセシビリティをウェブ開発の最優先事項として考慮する必要があります。疑問がある場合は、資格のある弁護士に相談してください。私たちは弁護士ではないので、これ以上のアドバイスは提供しません。</p> + +<h2 id="Accessibility_APIs" name="Accessibility_APIs">アクセシビリティの API 群</h2> + +<p>ウェブブラウザーは、支援技術（AT）に役立つ情報を公開する（基礎となる OS によって提供される）特別な<strong>アクセシビリティ API</strong> を利用します — AT は大抵は意味論的情報を利用する傾向があるので、この情報にはスタイル情報や JavaScript のようなものを含みません。この情報は、<strong>アクセシビリティツリー</strong>と呼ばれる情報のツリーで構成されています。</p> + +<p>次のように、OS が異なれば、利用可能なアクセシビリティ API も異なります。</p> + +<ul> + <li>Windows: Microsoft Active Accessibility（MSAA） / IAccessible、UIAExpress、IAccessible2</li> + <li>Mac OS X: NSAccessibility</li> + <li>Linux: AT-SPI</li> + <li>Android: Accessibility framework</li> + <li>iOS: UIAccessibility</li> +</ul> + +<p>ウェブアプリにおいて HTML 要素によって提供されるネイティブな意味論的情報が足りない場合は、あなたは <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA の仕様</a>（英語）の機能でそれを補うことができます。これにより、アクセシビリティツリーに意味論的情報が追加され、アクセシビリティが向上します。<a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a>の記事で WAI-ARIA についてもっと多くを学ぶことができます。</p> + +<h2 id="Summary" name="Summary">まとめ</h2> + +<p>この記事では高いレベルでアクセシビリティの概要を説明し、それが重要である理由と、ワークフローに取り込む方法を見てきました。サイトをアクセシブルにするための実装の詳細について学ぶことを渇望する人もいるでしょう。それでは次の記事では、HTML がアクセシビリティの良い基礎である理由を見ていきます。</p> + +<p>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</p> + +<h2 id="In_this_module" name="In_this_module">このモジュール内の文書</h2> + +<ul> + <li><a href="/ja/docs/Learn/Accessibility/What_is_accessibility">アクセシビリティとは？</a></li> + <li><a href="/ja/docs/Learn/Accessibility/HTML">HTML: アクセシビリティの基礎</a></li> + <li><a href="/ja/docs/Learn/Accessibility/CSS_and_JavaScript">CSS と JavaScript のアクセシビリティのベスト・プラクティス</a></li> + <li><a href="/ja/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA の基本</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Multimedia">アクセシブルなマルチメディア</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Mobile">モバイルアクセシビリティ</a></li> + <li><a href="/ja/docs/Learn/Accessibility/Accessibility_troubleshooting">アクセシビリティのトラブルシューティング</a></li> +</ul> + + + +<h2 id="See_Also" name="See_Also">関連情報</h2> + +<ul> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG">WCAG</a> + + <ul> + <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><a href="/ja/docs/Web/Accessibility/Understanding_WCAG/Understandable">理解可能</a></li> + <li><a href="/ja/docs/Web/Accessibility/Understanding_WCAG/Robust">堅牢</a></li> + </ul> + </li> +</ul> |