次に、私たちはアクセシビリティに注意を向け、一般的な問題、簡単なテストの方法、そしてアクセシビリティの問題を見つけるための監査/自動化ツールの使い方を説明します。
| 前提条件: | コア HTML、CSS、および JavaScript 言語に精通していること。 高水準のクロスブラウザーテストの原則の理解。 |
|---|---|
| 目的: | 一般的なアクセシビリティの問題を診断し、それらを修正するための適切なツールとテクニックを使用できるようにすること。 |
ウェブ技術のコンテキストでアクセシビリティと言うとき、ほとんどの人は即座にウェブサイトやアプリが障碍のある人にも使えるようにすることを考えます。 例えば、
しかし、アクセシビリティが単に障碍に関するものであると言うのは間違っています。 実際、アクセシビリティの目的は、高性能デスクトップコンピュータを使用しているユーザーだけでなく、できるだけ多くのコンテキストで、できるだけ多くのユーザーがウェブサイトやアプリを使用できるようにすることです。 極端な例には次のものが含まれます。
ある意味では、このモジュール全体がアクセシビリティについてのものです — クロスブラウザーテストは、あなたのサイトができるだけ多くの人々によって使用できることを確認します。 アクセシビリティとは？では、この記事よりも完全かつ徹底的にアクセシビリティを定義します。
とは言っても、この記事では、クロスブラウザーと障碍のある人々を取り巻く問題のテスト、そして彼らのウェブの使い方について説明します。 モジュール内の他の場所で、レスポンシブデザインとパフォーマンスのような他の分野についてはすでに説明しました。
注: ウェブ開発における多くのことと同様に、アクセシビリティは 100% 成功したかどうかではありません。 特にサイトが複雑になるにつれて、100% のアクセシビリティを全てのコンテンツに対して達成することはほとんど不可能です。 その代わりに、防御的なコーディングを介して、できるだけ多くの人があなたのコンテンツのできるだけ多くにアクセスできるようにし、ベストプラクティスに従うようにする努力をします。
このセクションでは、従うべきベストプラクティスと共に、特定の技術と結びつけて、ウェブのアクセシビリティに関して生じる主な問題のいくつかと、サイトが正しい方向に進んでいるかどうかを確認するための簡単なテストについて、詳細を説明します。
注: アクセシビリティは道徳的に正しいことであり、ビジネスには適していますし（多くの障碍のあるユーザー、モバイルデバイスのユーザーなどが重要な市場セグメントを提示しています）、ウェブ資産を障碍のある人々がアクセスできないようにすることは、世界の多くの地域で法律にも違反しています。 詳しくはアクセシビリティのガイドラインと法律を読んでください。
意味論的 HTML（要素が正しい目的のために使用されているもの）は箱から出してすぐにアクセスできます — そのようなコンテンツは晴眼者でも読めますし（CSS を使用して、テキストを小さくしすぎたり、隠したりするような愚かなことはしないでください）、スクリーンリーダー（文字通りウェブページをユーザーに読み上げるアプリ）などの支援技術でも使用可能になり、他の利点も付与されます。
意味論的 HTML で最も重要なすばやい勝利は、コンテンツに見出しと段落の構造を使用することです。 これは、スクリーンリーダーのユーザーが、必要なコンテンツをすばやく見つけるために文書の見出しを道標として使用する傾向があるためです。 あなたのコンテンツが見出しを持っていない場合、彼らが得るのは、何かを見つけるための道標のないテキストの巨大な壁だけです。 悪い HTML と良いHTML の例としては、
<font size="7">私の見出し</font> <br><br> これが私の文書の最初のセクションです。 <br><br> ここにも段落を追加します。 <br><br> <font size="5">私の副見出し</font> <br><br> これが私の文書の最初のサブセクションです。 私は人々がこのコンテンツを見つけることができるようにしたいです！ <br><br> <font size="5">私の2番目の副見出し</font> <br><br> これは私のコンテンツの2番目のサブセクションです。 私は最後のものよりも面白いと思います。
<h1>私の見出し</h1> <p>これが私の文書の最初のセクションです。</p> <p>ここにも段落を追加します。</p> <h2>私の副見出し</h2> <p>これが私の文書の最初のサブセクションです。 私は人々がこのコンテンツを見つけることができるようにしたいです！</p> <h2>私の2番目の副見出し</h2> <p>これは私のコンテンツの2番目のサブセクションです。 私は最後のものよりも面白いと思います。</p>
さらに、あなたのコンテンツはそのソース順で論理的に意味があるべきです — あなたは後で CSS を使い、いつでもそれを望んだ所に置くことができますが、最初から正しいソース順を手にするべきです。
テストとして、あなたはサイトの CSS をオフにして、CSS がなければそれがどれほど理解できるか見ることができます。 コードから CSS を取り除くだけでこれを手動で行うことができますが、最も簡単な方法はブラウザー機能を使用することです。 例えば、
特定の HTML 機能はキーボードのみを使用して選択できます — これはデフォルトの動作で、ウェブの初期の頃から使用可能です。 この機能を持つ要素は、ユーザーがウェブページと対話することを可能にする一般的なもの、すなわちリンク、{{htmlelement("button")}}、そして {{htmlelement("input")}} のようなフォーム要素です。
native-keyboard-accessibility.html の例を使ってこれを試すことができます（ソースコードを見る） — これを新しいタブで開いて、そして Tab キーを押してみてください。 数回押すと、タブフォーカスがさまざまなフォーカス可能な要素を通過し始めます。 どの要素がフォーカスされているかわかるように、フォーカスされた要素には全てのブラウザーでハイライトされたデフォルトのスタイルが与えられます（ブラウザーによって若干異なります）。
次に Enter / Return を押してフォーカスのあるリンクをたどるか、ボタンを押すか（ボタンにメッセージを知らせるための JavaScript が含まれています）、テキスト入力にテキストを入力するためにタイプし始めることができます（他のフォーム要素には異なるコントロールがあります。 例えば、{{htmlelement("select")}} 要素では、上下の矢印キーを使用してそのオプションを表示したり切り替えたりできます）。
ブラウザーが異なれば、使用可能なキーボードコントロールオプションも異なることに注意してください。 最近のほとんどのブラウザーは上記のタブパターンに従いますが（フォーカス可能な要素を逆方向に移動するために Shift + Tab を押すこともできます）、次のようにブラウザーによっては独自の特徴があります。
重要: あなたが書く新しいページのどれでも、この種のテストを実行するべきです — 機能がキーボードによってアクセスできることを確認してください。
この例では、正しい仕事に正しい意味論的要素を使用することの重要性を強調しています。 任意の要素を、CSS でリンクやボタンのように見せたり、JavaScript でリンクやボタンのように振る舞うようにスタイルすることは可能ですが、実際にはリンクやボタンにはならず、あなたはこれらの要素が無料で与えるアクセシビリティの多くを失うでしょう。 あなたがそれを避けることができるならばしないでください。
もう1つのヒント — 次の例に示すように、{{cssxref(":focus")}} 疑似クラスを使用して、フォーカス可能要素のフォーカス時の外観をコントロールできます。 フォーカスとホバーのスタイルを倍増するのは良い考えです。 それにより、マウスやキーボードを使用しているかどうかに関わらず、ユーザーがコントロールをアクティブにしたときに何かが行われるという視覚的な手がかりを得ることができます。
a:hover, input:hover, button:hover, select:hover,
a:focus, input:focus, button:focus, select:focus {
font-weight: bold;
}
注: CSS を使用してデフォルトのフォーカススタイルを取り除く場合は、デザインに適した他のスタイルに置き換えてください — これは非常に有用なアクセシビリティツールであり、取り除くべきではありません。
時にはキーボード・アクセシビリティを失うことが避けられないこともあります。 意味論的にあまり良くないサイトを継承したかもしれませんし（<div> で作られたボタンを生成する恐ろしい {{glossary("CMS")}} に行き着くかもしれません）、HTML5 の {{htmlelement("video")}} 要素のようにキーボード・アクセシビリティが組み込まれていない複雑なコントロールを使用しているかもしれません（驚くべきことに、Opera は <video> 要素のデフォルトのブラウザーコントロールをタブ操作できる唯一のブラウザーです）。 次のようないくつかの選択肢があります。
<button> 要素（デフォルトでタブ移動可能）と JavaScript を使用してカスタムコントロールを作成し、それらの機能を関連付けます。 これについての良い例は、クロスブラウザーのビデオプレーヤーの作成を参照してください。tabindex="0" という属性を与えることで（もっと有用な詳細については WebAIM の tabindex の記事（英語）を見てください）、偽の <div> ボタンにフォーカスできるようにしました（タブを介すことも含む）。 これにより、ボタンにタブ移動することはできますが、Enter / Return キーでそれらをアクティブにすることはできません。 そのためには、次のちょっとした JavaScript トリックを追加する必要があります。
document.onkeydown = function(e) {
if(e.keyCode === 13) { // The Enter/Return key
document.activeElement.onclick(e);
}
};
ここでは、document オブジェクトにリスナーを追加して、キーボードのボタンが押されたことを検出します。 イベントオブジェクトの keyCode プロパティを使ってどのボタンが押されたかをチェックし、Return / Enter と一致するキーコードであれば、document.activeElement.onclick() を使用してボタンの onclick ハンドラに格納されている関数を実行します。 activeElement は現在ページにフォーカスしている要素を与えます。注: この手法は、イベントハンドラ・プロパティ（onclick など）を使ってオリジナルのイベントハンドラを設定した場合にのみ機能します。 addEventListener は機能しません。 これは、機能を再構築するための非常に面倒な作業です。 それに他にも問題があるはずです。 そもそも正しい要素を正しい仕事に使うほうがよいでしょう。
代替テキストは、アクセシビリティにとって非常に重要です — ある人が視覚障碍または聴覚障碍を抱えているためにコンテンツを見たり聞いたりすることができなくなると、これが問題になります。 最も単純な代替テキストは、控え目な {{htmlattrxref("alt","img")}} 属性で、関連するコンテンツを含む全ての画像に含めるべきです。 これはスクリーンリーダーが拾ってユーザーに読み上げるために、ページ上にその意味と内容をうまく伝える画像の説明を含むべきです。
注: 詳しくは、代替テキストをお読みください。
欠落している代替テキストは、アクセシビリティ{{anch("Auditing tools","監査ツール")}}を使用するなど、さまざまな方法でテストできます。
代替テキストは、動画と音声のコンテンツにとってはもう少し複雑です。 テキストトラック（字幕など）を定義し、動画の再生時にそれらを {{htmlelement("track")}} 要素と WebVTT 形式の形式で表示する方法があります（詳細なチュートリアルについては、HTML5 の動画へのキャプションと字幕の追加を参照してください）。 これらの機能に対するブラウザーの互換性はかなり良いのですが、音声用の代替テキストを提供したり、古いブラウザーをサポートしたりする場合は、ページのどこかや別のページに提示した単純なテキストトランスクリプトをお勧めします。
HTML には、他に存在しない要素間のコンテキストと関係を提供するように設計された特定の機能とベストプラクティスがあります。 最も一般的な3つの例は、リンク、フォームラベル、およびデータ表です。
アクセス可能なリンクテキストの鍵は、スクリーンリーダーを使用している人々が、ページ上の全てのリンクのリストを引き出すという共通の機能を使用することが多いということです。 この場合、リンクテキストはコンテキスト外で意味を成す必要があります。 例えば、「ここをクリック」、「ここをクリック」などのラベルが付いたリンクのリストは、アクセシビリティにとって本当に悪いものです。 リンクテキストはコンテキスト内でもコンテキスト外でも意味を成すのが得策です。
次に、フォームの {{htmlelement("label")}} 要素は、フォームをアクセス可能にすることを可能にする中心的な機能の1つです。 フォームの悩みは、各フォーム入力にどのデータを入力するべきかを示すためにラベルが必要なことです。 各ラベルを {{htmlelement("label")}} 内に含めて相方のフォーム入力に明確にリンクする必要があり（各 <label> の for 属性値はフォーム要素の id 値と一致する必要があります）、ソース順が完全に論理的ではなくても（これは公平であるべきです）、それは意味があります。
注：リンクテキストとフォームラベルの詳細については、わかりやすいテキストラベルを参照してください。
最後に、データ表について簡単に説明します。 基本的なデータ表は非常に簡単なマークアップで書くことができますが（bad-table.html のライブとソースを見る）、問題があります — スクリーンリーダーのユーザーがデータのグループとして行や列を関連付ける方法はありません — これを行うには、ヘッダー行がどれであるか、そしてそれらが行、列などを見出ししているかどうかを知る必要があります。 これはそのような表に対しては視覚的にしかできません。
代わりに punk-bands-complete.html の例（ライブ、ソース）を見ると、表のヘッダー（{{htmlelement("th")}} と scope 属性）、{{htmlelement("caption")}} 要素など、いくつかのアクセシビリティ補助機能が働いていることがわかります。
注: アクセス可能な表の詳細については、アクセス可能なデータ表を参照してください。
CSS は HTML よりもはるかに少ない基本的なアクセシビリティ機能を提供する傾向がありますが、それでも誤って使用された場合、それはアクセシビリティにちょうど同じくらい多くの損害を与えることができます。 CSS に関するアクセシビリティのヒントをいくつかすでに説明しました。
考慮すべき点が他にもいくつかあります。
ウェブサイトの配色を選択するときは、テキスト（前景）のカラーコントラストが背景色とよく合うことを確認するべきです。 あなたのデザインはかっこいいかもしれませんが、色覚異常のような視覚障碍を持つ人々がコンテンツを読むことができないならば、それは良くありません。 配色に十分なコントラストがあるかどうかチェックするために WebAIM のカラーコントラストチェッカー（英語）のようなツールを使ってください。
もう1つのヒントは、道標や情報を色だけに頼らないようにすることです。 これは、色が見えない人には良くないでしょう。 例えば、必須のフォームフィールドを赤でマークする代わりに、赤いアスタリスクでマークします。
注: コントラスト比が高いと、光沢のある画面を備えたスマートフォンやタブレットを使用している人は誰でも、日光のような明るい環境にいるときにページを読みやすくなります。
ビジュアルデザインでは、全てのコンテンツを一度に表示する必要がない多くの実例があります。 例えば、タブ付き情報ボックスの例（ソースコードを見る）には3つの情報パネルがありますが、それらを重ねて配置し、それぞれを表示するためにクリックできるタブを提供しています（キーボードからもアクセス可能です — 代わりに Tab と Enter / Return を使って選択することもできます）。
スクリーンリーダーのユーザーは、このことを気にしません — コンテンツのソース順が意味を成す限り幸せで、全てに到達できます。 絶対配置（この例で使用されているような）は一般に視覚効果のためにコンテンツを隠す最も良いメカニズムの1つとして見られます、なぜならそれはスクリーンリーダーがそれに到達するのを止めないからです。
一方で、スクリーンリーダーからコンテンツを隠すので、{{cssxref("visibility")}}:hidden や {{cssxref("display")}}:none は使用しないでください。 正当な理由があるのでなければ、なぜこのコンテンツをスクリーンリーダーから隠したいのでしょうか。
注: スクリーンリーダーのユーザーには見えないコンテンツ（英語）には、このトピックに関するもっと有用な詳細があります。
JavaScript はアクセシビリティに関して CSS と同じ種類の問題を抱えています — それが悪用されたり、乱用されたりするとアクセシビリティの災害になる可能性があります。 JavaScript に関連するアクセシビリティの問題、主に意味論的 HTML の分野についてはすでに示唆しています — 例えば、リンクやボタンを適切に使用するなど、適切な意味論的 HTML を使用して機能を実装するべきです。 可能であれば、JavaScript コードで <div> 要素を使用して機能を偽造しないでください — エラーが発生しやすく、HTML の無料機能を使用するよりも手間がかかります。
一般的に単純な機能は HTML だけで適切に機能するはずです — JavaScript は機能を強化するためにのみ使用されるべきであり、完全には組み込みません。 JavaScript の良い使い方には次のものが含まれます。
<video> のカスタムコントロールを提供します（前述したように、デフォルトのブラウザーコントロールはほとんどのブラウザーでキーボードからアクセスできません）。注: WebAIM のアクセス可能な JavaScript（英語）は、アクセス可能な JavaScript の考慮事項に関する有用な詳細をいくつか提供します。
より複雑な JavaScript による実装はアクセシビリティに問題をもたらす可能性があります — できる限りのことをする必要があります。 例えば、WebGL を 100% を使用して書かれた複雑な 3D ゲームを視覚障碍者が利用できるようにすることは期待できませんが、マウス以外のユーザーが使用できるようにキーボードコントロールを実装し、色覚異常のある人にも使えるように配色に十分なコントラストがあるようにすることができます。
アクセシビリティにとって問題となる主な分野の1つは、（日付の選択のような）複雑なフォームコントロールを含む複雑なアプリと、頻繁に増分的に更新される動的コンテンツです。
ネイティブではない複雑なフォームコントロールは、ネストされた <div> が多数含まれる傾向があり、ブラウザーがデフォルトでそれらをどう処理するかわからないため、問題があります。 自分でそれらを考案しているのなら、それらがキーボードからアクセスできることを確認する必要があります。 何らかのサードパーティ製フレームワークを使用している場合は、利用可能なオプションを慎重に検討して、飛びつく前にそれらがどれほどアクセス可能かを確認してください。 Bootstrap は、アクセシビリティにはかなり適しているように見えます。 例えば、Rhiana Heath による Bootstrap をもう少しアクセス可能にする（英語）では、その問題のいくつかを調べ（主にカラーコントラストに関連した）、いくつかの解決策を検討しています。
定期的に更新される動的コンテンツは、スクリーンリーダーのユーザーがそれを見逃す可能性があるため、特に突然更新される場合は問題になる可能性があります。 XMLHttpRequest または Fetch を使用して定期的に更新されるメインコンテンツパネルを備えた単一ページのアプリがある場合、スクリーンリーダーのユーザーはそれらの更新を見逃す可能性があります。
そのような複雑な機能を使用する必要がありますか、それともごく普通の意味論的 HTML が代わりにやりますか？ 複雑なものが必要な場合は、WAI-ARIA（Accessible Rich Internet Applications）を使用することを検討するべきです。 これは、ほとんどのブラウザーやスクリーンリーダーが理解できる複雑なフォームコントロールや更新パネルのような項目に（新しい HTML 属性の形式で）意味論を提供する仕様です。
複雑なフォームウィジェットを扱うには、さまざまな要素がウィジェット内でどのような役割を担っているか（例えば、タブなのか、タブパネルなのか）を示す role、コントロールが無効かどうかを示す aria-disabled などの ARIA 属性を使う必要があります。
定期的に更新されるコンテンツのリージョンを扱うには、更新されるリージョンを識別する aria-live 属性を使用できます。 その値は、次のようにスクリーンリーダーがどれほど緊急にそれを読み上げるべきかを示します。
off: デフォルト。 更新はアナウンスされるべきではありません。polite: 更新はユーザーがアイドル状態の場合にのみアナウンスされるべきです。assertive: 更新はできるだけ早くユーザーにアナウンスされるべきです。rude: ユーザーに割り込んだとしても、更新はすぐにアナウンスされるべきです。これが一例です。
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
Freedom Scientific の ARIA（Accessible Rich Internet Applications）のライブリージョン（英語）の例で実行中の例を見ることができます — 強調表示された段落はその内容を10秒ごとに更新し、スクリーンリーダーはユーザーにこれを読み上げるべきです。 ARIA のライブリージョン - Atomic（英語）は別の有用な例を提供しています。
ここでは WAI-ARIA を詳細にカバーするためのスペースはありません。 WAI-ARIA の基本でもっと詳しく学ぶことができます。
今まで（キーボードナビゲーションやカラーコントラストチェッカーのような）いくつかのテストのテクニックを含め、さまざまなウェブ技術に対するアクセシビリティの考慮事項について説明してきました。 次に、アクセシビリティのテストを実行するときに使用できる他のツールを見てみましょう。
あなたのウェブページを指さすことができる利用可能な監査ツールがいくつかあります。 それらはページを見て、ページに存在するアクセシビリティ問題のリストを返すでしょう。 例えば次のものが含まれます。
Tenon を使って例を見てみましょう。
また、Tenon をプログラム的に使用するための API と同様に、探索できるいくつかのオプション（ページ上部の近くにある [Show Options] リンクを参照）もあります。
注: このようなツールは、アクセシビリティの問題を全て自分で解決するのに十分ではありません。 全体像を把握するには、これらの組み合わせ、知識と経験、ユーザーテストなどが必要です。
Deque の aXe ツール（英語）は、前述した監査ツールよりも少しばかり進化しています。 他のものと同様に、ページをチェックしてアクセシビリティエラーを返します。 その最もすぐに役立つ形式は、おそらく次のブラウザー拡張機能です。
これらはブラウザー開発者ツールにアクセシビリティタブを追加します。 例えば、Firefox 用のバージョンをインストールし、それを使用して bad-table.html の例を監査すると、次の結果が得られます。
aXe は npm を使ってもインストール可能で、Grunt や Gulp のようなタスクランナー、Selenium や Cucumber のような自動化フレームワーク、Jasmin のような単体テストフレームワークなどと統合することができます（やはり、詳細についてはメインの aXe ページ（英語）を参照してください）。
重度の視覚障碍者がウェブをどのように使用しているかに慣れるには、スクリーンリーダーを使ってテストする価値があります。 次のように利用可能なスクリーンリーダーは多数あります。
一般的に、スクリーンリーダーはホストオペレーティングシステム上で動作する独立したアプリで、ウェブページだけでなく他のアプリのテキストも読むことができます。 これは必ずしもそうとは限りませんが（ChromeVox はブラウザーの拡張機能です）、通常はそうです。 スクリーンリーダーは少し異なる方法で動作し、異なるコントロールを持つ傾向があるので、全ての詳細を得るためにはあなたが選んだスクリーンリーダーのドキュメントを参照しなければなりません — と言っても、それらは全て基本的に同じような方法で機能します。
いくつかの異なるスクリーンリーダーを使っていくつかのテストを行い、それらがどのように機能するのか、またどのようにテストするのかについての一般的な考えを説明しましょう。
注: WebAIM のスクリーンリーダーの互換性のための設計（英語）では、スクリーンリーダーの使用方法とスクリーンリーダーに最適な機能についての役立つ情報が提供されています。 いくつかの興味深いスクリーンリーダーの使用統計については、第6回スクリーンリーダーのユーザー調査の結果（英語）も参照してください。
VoiceOver（VO）は Mac / iPhone / iPad には無料で含まれているので、あなたが Apple 製品を使っているならそれはデスクトップ/モバイルでテストするのに役に立ちます。 ここでは、MacBook Pro の Mac OS X でテストします。
オンにするには、Cmd + Fn + F5 を押します。 今までに VO を使ったことがない場合は、ようこそ画面が表示され、そこで VO を起動するかどうかを選択できます。 また、使い方を学ぶためにかなり役に立つチュートリアルを実行することもできます。 再びオフにするには、もう一度 Cmd + Fn + F5 を押します。
注: チュートリアルは少なくとも一度は実行するべきです — これは VO を学ぶ上で非常に便利な方法です。
VO がオンになっていると、ディスプレイはほぼ同じに見えますが、画面の左下に、現在選択されている VO に関する情報を含む黒いボックスが表示されます。 現在の選択範囲も黒枠で強調表示されます — この強調表示は VO カーソルと呼ばれます。
VO を使用するには、「VO 修飾キー」を多用します — これは、実際の VO キーボードショートカットに加えて、それらを機能させるために押す必要があるキーまたはキーの組み合わせです。 このような修飾キーを使用するのは、スクリーンリーダーに共通で、他のコマンドとコマンドが衝突しないようにするためです。 VO の場合、修飾キーは CapsLock または Ctrl + Option のいずれかです。
VO にはたくさんのキーボードコマンドがありますので、ここではそれら全てをリストしません。 ウェブページのテストに必要な基本的なものは、次の表のとおりです。 キーボードショートカットでは、VO は「VoiceOver 修飾キー」を意味します。
| キーボードショートカット | 説明 |
|---|---|
| VO + 矢印キー | VO カーソルを上下左右に移動します。 |
| VO + スペースバー | VO カーソルで強調表示されている項目を選択/アクティブ化します。 これには、ローター（下記参照）で選択した項目が含まれます。 |
| VO + Shift + 下矢印 | （HTML の表やフォームなどの）項目のグループ内に入ります。 グループ内に入ると、通常どおり上記のコマンドを使用してそのグループ内の項目を移動して選択できます。 |
| VO + Shift + 上矢印 | グループから出ます。 |
| VO + C | （表内の場合）現在の列のヘッダーを読み上げます。 |
| VO + R | （表内の場合）現在の行のヘッダーを読み上げます。 |
| VO + C + C（2つの連続した C） | （表内の場合）ヘッダーを含む現在の列全体を読み上げます。 |
| VO + R + R（2つの連続した R） | （表内の場合）各セルに対応するヘッダーを含め、現在の行全体を読み上げます。 |
| VO + 左矢印、VO + 右矢印 | （日付の選択や時刻の選択などの一部の水平オプション内の場合）オプション間を移動します。 |
| VO + 上矢印、VO + 下矢印 | （日付の選択や時刻の選択などの一部の水平オプション内の場合）現在のオプションを変更します。 |
| VO + U | 簡単にナビゲーションできるように、見出し、リンク、フォームコントロールなどのリストを表示するローターを使用します。 |
| VO + 左矢印、VO + 右矢印 | （ローター内の場合）ローターで利用可能な異なるリスト間を移動します。 |
| VO + 上矢印、VO + 下矢印 | （ローター内の場合）現在のローターリスト内の異なる項目間を移動します。 |
| Esc | （ローター内の場合）ローターを終了します。 |
| Ctrl | （VO が話している場合）読み上げを一時停止/再開します。 |
| VO + Z | 読み上げの最後の部分をやり直します。 |
| VO + D | Mac の Dock に入るので、その中で実行するアプリを選択できます。 |
これはたくさんのコマンドのように思えますが、慣れればそれほど悪くはありません。 VO は、特定の場所でどのコマンドを使用するかについて定期的に注意を促します。 今は VO で遊びましょう。 その後、{{anch("Screenreader testing","スクリーンリーダーのテスト")}}のセクションで例のいくつかを試してみることができます。
NVDA は Windows 専用で、インストールする必要があります。
これで NVDA はあなたのコンピュータ上でアクティブになります。
NVDA を使用するには、「NVDA 修飾キー」を多用します — これは、実際の NVDA のキーボードショートカットに加えて、それらを機能させるために押す必要があるキーです。 このような修飾キーを使用するのは、スクリーンリーダーに共通で、他のコマンドとコマンドが衝突しないようにするためです。 NVDA の場合、修飾キーは Insert（デフォルト）、または CapsLock（[OK] を押す前に NVDA へようこそダイアログボックスの最初のチェックボックスをオンにして選択できます）のいずれかになります。
注: NVDA は、VoiceOver よりも、それがどこにあるのか、また何をしているのかを強調する方法という点では微妙です。 あなたが見出しやリストなどをスクロールしているとき、あなたが選択している項目は一般的に微妙なアウトラインでハイライトされますが、これはいつも全てのことに当てはまるわけではありません。 完全に迷子になった場合は、Ctrl + F5 を押して現在のページを更新し、もう一度上から始めることができます。
NVDA にはたくさんのキーボードコマンドがありますので、ここではそれら全てをリストしません。 ウェブページのテストに必要な基本的なものは、次の表のとおりです。 キーボードショートカットでは、NVDA は「NVDA 修飾キー」を意味します。
| キーボードショートカット | 説明 |
|---|---|
| NVDA + Q | 起動している NVDA を再びオフにします。 |
| NVDA + 上矢印 | 現在行を読み上げます。 |
| NVDA + 下矢印 | 現在位置から読み上げを始めます。 |
| 上矢印 と 下矢印、または Shift + Tab と Tab | ページ内の前/次の項目に移動して、それを読み上げます。 |
| 左矢印 と 右矢印 | 現在の項目の前/次の文字に移動して、それを読み上げます。 |
| Shift + H と H | 前/次の見出しに移動して、それを読み上げます。 |
| Shift + K と K | 前/次のリンクに移動して、それを読み上げます。 |
| Shift + D と D | 前/次の文書のランドマーク（<nav> など）に移動して、それを読み上げます。 |
| Shift + 1 〜 6 と 1 〜 6 | 前/次の見出し（レベル 1 〜 6）に移動して読み上げます。 |
| Shift + F と F | 前/次のフォーム入力に移動して、それにフォーカスを当てます。 |
| Shift + T と T | 前/次のデータ表に移動して、それにフォーカスを当てます。 |
| Shift + B と B | 前/次のボタンに移動して、ラベルを読み上げます。 |
| Shift + L と L | 前/次のリストに移動して、その最初のリスト項目を読み上げます。 |
| Shift + I と I | 前/次のリスト項目に移動して、それを読み上げます。 |
| Enter / Return | （リンク/ボタンまたは他のアクティブ化可能項目が選択されている場合）項目をアクティブ化します。 |
| NVDA + スペースバー | （フォームが選択されている場合）個々の項目を選択できるようにフォーム内に入るか、すでにフォームに入っている場合はフォームから出ます。 |
| Shift + Tab と Tab | （フォーム内の場合）フォーム入力間を移動します。 |
| 上矢印 と 下矢印 | （フォーム内の場合）フォーム入力の値を変更します（選択ボックスなどの場合）。 |
| スペースバー | （フォーム内の場合）選択値を選択します。 |
| Ctrl + Alt + 矢印キー | （表が選択されている場合）表のセル間を移動します。 |
スクリーンリーダーを使用することに慣れてきましたが、スクリーンリーダーがどのようにウェブページの良い機能と悪い機能に対処するかを理解するために、簡単なアクセシビリティテストを行うためにスクリーンリーダーを使用したいと思います。
<label> 要素を適切に使用することで、フォーム入力がラベルでどのように説明されるかに注目してください。 bad-form.html では、それらは「空白」の行に沿って役に立たないラベルを取得します。上記のように、あなたはあなたのサイトのアクセシビリティ問題を決定するために自動化されたツールだけに頼ることはできません。 テスト計画を立てる際には、可能であればアクセシビリティユーザーグループをいくつか含めることをお勧めします（詳細については、コースの前半のユーザーテストのセクションを参照してください）。 必要に応じて、スクリーンリーダーを使用するユーザー、キーボードを使用するユーザー、聴覚を持たないユーザー、および他のグループも参加してください。
次のリストは、プロジェクトで推奨されるアクセシビリティテストを確実に実行したことを確認するためのチェックリストです。
あなたがアクセシビリティに関して遭遇するであろう他の多くの問題があります。 本当に知っておくべき最も重要なことは、オンラインで答えを見つける方法です。 HTML と CSS の記事の助けを探すのセクションを参考にしてください。
たぶん、この記事はあなたが遭遇するかもしれない主なアクセシビリティ問題とそれらをどうやってテストして克服するかについての良い下地を与えたでしょう。
次の記事では、機能の検出について詳しく説明します。
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}