アクセシビリティレビューを行う方法

モジュール、テーマ、またはサイトのアクセシビリティの度合いを把握することは、困難な作業のように思えるかもしれません。アクセシビリティに不慣れな場合、このテーマ自体がどこから始めればよいのか戸惑わせるかもしれません。多様な能力の範囲に適応するということは、それに応じて多様な問題を考慮する必要があることを意味します。このドキュメントでは、必要な考慮事項を、モジュールのテーマやサイトのアクセシビリティをレビューするための論理的で段階的なプロセスとしてまとめました。

まず自動化ツールを実行することから始める

多くのアクセシビリティの問題は、自動化ツールでページを実行することで発見できます。自動化ツールにはWAVE、Tenon、Accessibility Insights、Google Lighthouse、Siteimprove、Chrome用のSiteimproveアクセシビリティチェック拡張機能などがあります。一部はaxe-coreで自動化できます。これらのツールは、不正なマークアップ構造、ARIA属性の欠落、不十分な色のコントラストなど、アクセシビリティの問題をすばやく特定するのに役立ちます。

キーボードナビゲーションのテスト

キーボードナビゲーションは、マウスを使用できない、または使用しないことを選択したユーザーが、画面上のすべてに到達するための主要な手段です。これには、スクリーンリーダーのユーザーや、反復性ストレス障害（RSI）や麻痺などの運動障害を持つユーザーが含まれます。優れたキーボード体験を実現するには、論理的なタブ順序と、簡単に識別できるフォーカススタイルを目指してください。また、ユーザーが過剰な数のタブ位置を移動する必要がないようにすることも確認してください。

確認すべき点

• 繰り返されるコンテンツをスキップできますか？

ナビゲーションメニューなどの繰り返されるコンテンツをスキップして、そのページに固有のコンテンツにユーザーを直接移動させるスキップリンクを提供する必要があります。スキップリンクはページの最初のタブ位置にある必要があり、フォーカスされたときに表示される必要があります。

• すべてのコントロールが完全に機能しますか？

すべてのインタラクティブな要素はキーボードで使用できる必要があります。展開/折りたたみ、ツリービューとスライダー、ダイアログとオーバーレイ、ドラッグアンドドロップ、すべて。または、アクションを実行するための代替手段が必要です。

• 両方向にタブ移動できますか？

ページを前方にタブ移動するのは正常に機能するが、後方への移動（Shift + Tabキーの組み合わせを使用）が不可能なアプリケーションを見たことがあります。これはキーボードトラップを作成します。インターフェースを両方向にタブ移動できることを確認してください。

• キーボードトラップはありますか？

どこかの時点でフォーカスが完全に捕捉されないように注意してください。キーボードだけを使って、オーバーレイ、モーダル、オートコンプリートウィジェットから抜け出す方法はありますか？ない場合、それはキーボードトラップを作成しています。

• ダイアログがあるとき、フォーカスはその中に制限されていますか？

ダイアログがある場合、キーボードフォーカスはその中に制限される必要があります。そうしないと、ダイアログの後ろのページを移動してしまい、どこにいるのか見えなくなる可能性があります。

• フォーカスは常に表示されていますか？

一般的なルールとして、ユーザーが操作したり入力を提供したりできるコントロールはすべてフォーカス可能で、フォーカスインジケータ（フォーカスリングなど）を表示する必要があります。キーボードユーザーが自分が何をターゲットにしているかを見られなければ、ページと対話する方法がありません。

• 表示されないがキーボードでアクセス可能なコンテンツはありますか？

非表示にする必要があるのに、まだタブ順序に含まれているコンテンツがないことを確認してください。

• ホバー時に表示されるコンテンツには、キーボードでアクセス可能な代替手段がありますか？

マウスを使用して、ホバー時のみ表示され、キーボードだけではアクセスできないコンテンツがあるかどうかを確認してください。ホバー時に表示されるコンテンツには、代替のアクセス方法が必要です。これはキーボードナビゲーションを使用するユーザーだけでなく、タッチ操作を使用するユーザーにも必要です。

• フォーカス可能であるべきでないフォーカス可能な要素はありますか？

- 非インタラクティブなコンテンツはフォーカス可能であるべきではありません。フォーカスできるものは、ユーザーが何かを実行できると期待されます。操作できないフォーカス可能なコンテンツは、ユーザーを混乱させたりイライラさせたりする可能性があります。         

- ユーザーが操作する必要がない限り、要素にtabindex="0"属性を配置しないでください。

- 非インタラクティブな要素に不要なtabindex属性を追加すると、コンテンツのナビゲーションに多くの労力が必要になることも意味します。

• タブ順序は自然で論理的ですか？

tabindexが変更された場合、またはページレイアウトがDOM（ドキュメントオブジェクトモデル、つまりページ内で実際にスクリプト化されている要素）の自然な流れに従って再編成された場合、視覚のあるキーボードユーザーはページをナビゲートする際に混乱する流れを経験する可能性があります

ブレークポイントを確認する

これらすべてのキーボードテストを実行したら、ブレークポイントに達するまでブラウザのズームを大きくして、すべてをもう一度行います。高いレベルのブラウザズームを使用する人は、ノートパソコンで「タブレット」または「電話」バージョンを操作することになります。モバイルブレークポイント はタッチスクリーンユーザーのためだけのものではありません。

見出し

見出しはコンテンツの基盤です。優れた見出し構造は、本の目次のように、ページの内容を反映します。説明的な見出しと意味のあるレベルを持つことが重要です。スクリーンリーダーの一部のユーザーは、ページの内容を閲覧するためにこれらを使用するためです。

すでに自動アクセシビリティツールのいずれかを実行した場合は、見出しに関連する問題のほとんどを検討した可能性があります。

確認すべき点

• ページにH1要素は1つだけですか？

ページには、そのページが何についてであるかを説明するH1要素が1つだけある必要があります。

• 見出しレベルはコンテンツに対応していますか？

他の見出しは、フォントサイズではなくレベルに応じて使用することが重要です。見出しレベルをスキップしないことが重要です。

• 見出しは十分に説明的ですか？

優れた見出しテキストは、見出しの後に続くコンテンツを簡潔に説明します。

色とコントラスト

十分な色のコントラストが必要です

色のコントラストは、前景（テキスト）の色と背景の色の比率です。テキストは背景との比率が4.5:1以上である必要があります。色のコントラストチェッカーを使用して、色がこの要件を満たしているかどうかを判断できます。

色は視覚情報を伝える唯一の手段であってはなりません

色は視覚情報を表示するための有効な手段ですが、情報を伝える唯一の方法であってはなりません。色覚異常の人は、重要な情報を伝えるために1つの色だけが使用されている場合、困難を経験する可能性があります（そして完全に見逃す可能性があります）。

情報を伝えるために色が使用されている場合は、次の追加の方法の少なくとも1つを使用してください：

• 情報を提供するために意味のあるテキストを使用します。例えば、緑から赤に変わる丸の横に「オン」と「オフ」。
• 意味のあるアイコンを使用して、ユーザーが形によって値を区別できるようにします。
• フォームエラーを示すには、「赤でマークされたフィールド」と言うだけでは不十分です。フィールド名を読み上げ、認識可能なエラーアイコンでマークする方がよいでしょう。

別の例は、必須フィールドを赤色でマークすることです。一部のユーザーは赤を他の色と区別できない可能性があり、このフォームを記入するための情報が不足します。この問題は、フィールドラベルにアスタリスクを追加することで解決できます。

フォーカス状態は色だけに依存してはなりません。フォーカスを伝えるためには追加の形式が必要です。一般的には、フォーカスを持つインタラクティブなコントロールの周りに追加のアウトラインが表示されます。

アイコンだけでは不十分

アイコンが機能の重要な部分を表す場合、その目的を説明するテキストを伴う必要があります。ナビゲーションメニューなどのインタラクティブな要素にラベルが付けられていることを確認してください。あなたにとって明らかなアイコンをすべてのユーザーが理解するわけではありません。スクリーンリーダーが要素を読み取るには、ラベルも必要です。

音声とビデオ

ページが情報を伝えるために音声またはビデオを使用している場合、キャプションまたは文字起こしが利用できることを確認してください。詳細はWebAimのキャプション、文字起こし、音声説明に関する記事をご覧ください。

• ウェブページで有益なビデオを音声ありまたは音声なしで使用する場合、視覚障害のある人のためにビデオのテキスト文字起こしも必要です。
• ウェブページで有益なビデオを音声ありで使用する場合、聴覚障害のある人のためにビデオにクローズドキャプションを含める必要があります。
• 有益で複雑な音声付きビデオを使用する場合、視覚障害のある人向けに、クローズドキャプションでは通常提供されないビデオ内のシーンやアクションの文脈を説明する音声説明を提供する必要がある場合があります。
• ライブビデオを使用する場合、聴覚障害のある人にキャプションを提供する必要があります。
• ライブ音声を使用する場合、視覚障害のある人にテキストの代替手段を提供する必要があります。

これは時間ベースのメディア、WCAGのガイドライン1.2に関連します。

アニメーションとビデオ・オーディオの自動再生

ユーザーの制御なしに自動再生されるアニメーション、ビデオ、および/またはオーディオは、ページの他の部分から注意をそらす可能性があります。アニメーションやビデオが問題を引き起こさないと思われるページ上の位置にあっても、ユーザーがページをどのように表示するかを制御することはできません。

アニメーション、ビデオとオーディオの自動再生の例：

• アニメーション：カルーセルが一連の画像を自動的にめくります。
• ビデオの自動再生：ページが読み込まれるとすぐにYouTubeビデオが再生されます。
• オーディオの自動再生：ページが読み込まれるとすぐにラジオチャンネルが再生されます。

 

ページの気が散る要素を減らすには：

• アニメーション、ビデオ、コンテンツを5秒以上再生しないようにしてください。
• ユーザーがアニメーション、ビデオ、オーディオを停止、再生、一時停止するタイミングを選択できるように、コントロールを提供してください。

 

動的に変化するコンテンツ

JavaScriptを使用すると、ページ全体を再読み込みせずにページの一部を動的に変更できます。これらの変更を完全に見ることができないユーザーは、変更が発生したことを知る必要があります。ページ上の動的な変更の例には、検索結果リストのその場での更新や、ユーザーの操作を必要としない別個の通知の表示があります。Drupal.announce () APIは、一部の支援技術で動的なコンテンツの変更を通知する機能を提供します。

Drupal.announce ()はARIA live regionsに基づいて構築されたAPIです。使用例の一部は、ARIA live regionsのロールに関するこのドキュメントにあります。

動的に変化するコンテンツをテストする最良の方法は、スクリーンリーダーを使用することです。

スクリーンリーダーによるテスト

自動アクセシビリティチェックの実行と手動でのページのタブ移動は、すでに大きな効果があります。スクリーンリーダーの使用に慣れていない場合でも、これらの問題の多くはスクリーンリーダーなしで発見できます。

確認すべき点

• すべてのコントロールにラベルがありますか？

すべてのコントロールには、コントロールの目的を説明するラベルが必要です。ほとんどの場合、これはlabel要素を使用して行われますが、複雑なケースではaria-labelledby属性を使用する必要がある場合があります。

• カスタムコントロールはありますか？適切なロールと、その状態を伝える必須のARIA属性で説明されていますか？

支援技術のユーザーは、フォーマット、カーソルスタイル、位置などの視覚的な手がかりを通じて視覚ユーザーに伝えられるのと同じ情報にアクセスできる必要があります。ネイティブ要素はこのセマンティック情報をブラウザに組み込んでいますが、カスタムコントロールではこの情報を追加するためにARIAを使用する必要があります。例えば、カスタムスライダーコンポーネントは、aria-valuenow、aria-valuemin、aria-valuemaxなどの関連するARIA属性を持つARIAスライダーロールを引き受けることができます。

• 情報の流れは画面上で見えるものと一致し、意味をなしますか？

情報の流れはCSSで変更できます。スクリーンリーダーでアクセスした場合、コンテンツの流れも意味をなしますか？

• リンクテキストは意味をなしますか？

ほとんどのスクリーンリーダーは、各リンクの前に「リンク」と読み上げます。例えば、「商品」というリンクは「商品リンク」と読み上げられます。したがって、リンクテキストに「リンク」を含めるべきではありません。すべてのユーザーがそれがリンクであることをすでに知っているからです。

リンクからリンクへ移動することは、スクリーンリーダーユーザーがウェブコンテンツを閲覧する方法です。リンクは文脈から切り離されても意味をなす必要があります。「ここをクリック」「詳細」「詳細情報はクリック」などのフレーズは、文脈から外れて読むと曖昧です。

• すべての画像に正しい代替テキストがありますか？

すべての画像に正しい代替テキストが必要です。この慣行の例外は、画像が主に装飾目的であり、コンテンツの重要な部分ではない場合です。画像をスクリーンリーダーでスキップする必要がある場合は、alt属性の値を空文字列に設定します。

スクリーンリーダーによる手動テスト

一部の問題は、スクリーンリーダーを使用したアプリの手動テストによってのみ発見できます。最も一般的なスクリーンリーダーは、VoiceOver（Mac OS）とNVDA（Windows）です。VoiceOverを始めるには、VoiceOverの基本に関するビデオを視聴し、WebAIMのVoiceOverチュートリアルを読むことができます。NVDAを始めるには、NVDAの基本に関するビデオを視聴し、Marco ZeheによるNVDAとFirefoxを使用したウェブページのアクセシビリティテストについて読むことができます。

スクリーンリーダーに慣れて、必要な基本的なキーボードコマンドを学んだら、モニターを消してマウスを片付けてみてください。スクリーンリーダーの発音はテストの範囲外に置くべきであることを覚えておいてください。

まだスクリーンリーダーのユーザーでない場合、スクリーンリーダーでのテストは思ったほど簡単ではありません。視覚的なナビゲーションから離れ、スクリーンリーダーユーザーが利用できるショートカットとメソッドを学ぶには、時間と努力が必要です。さらに、すべてのスクリーンリーダーは少しずつ動作が異なり、可能な限り多くのスクリーンリーダーと、異なるブラウザやプラットフォームでテストすることが重要です。