手動テストの基本
手動アクセシビリティ テストでは、キーボード、視覚、認知に関するテスト、ツール、手法を使用して、自動ツールでは検出できない問題を検出します。自動ツールでは WCAG で特定されたすべての達成基準を網羅できないため、自動アクセシビリティ テストを実行し、テストを継続する ことが不可欠です。
技術の進歩に伴い、より多くのテストを自動ツールだけで実施できるようになる可能性があります、 現時点では、適用可能なすべての WCAG チェックポイントを網羅するために、テスト プロトコルに手動チェックと支援技術チェックの両方を追加する必要があります。
手動アクセシビリティ テストのメリット:
- 比較的簡単かつ迅速に実行できる
- 自動テストのみの場合よりも高い割合で問題を検出できる
- 成功に必要なツールや専門知識が少ない
手動アクセシビリティ テストのデメリット:
- 自動テストよりも複雑で時間がかかる
- 大規模な繰り返しが難しい場合がある
- テストの実行と結果の解釈には、アクセシビリティに関するより多くの専門知識が必要となる
自動ツールで検出できるアクセシビリティの要素と詳細と、検出できない要素と詳細を比較します。
手動テストの種類
ウェブページやアプリのデジタル アクセシビリティを確認する際には、多くの手動ツールと手法を検討する必要があります。手動テストの 3 つの主な重点分野は、キーボード機能、視覚的なレビュー、一般的なコンテンツ チェックです。
このモジュールでは、これらのトピックについて概要を説明しますが、以下のテストは、実行できる、または実行すべきすべての手動テストを網羅したリストではありません。信頼できるソースの手動アクセシビリティ チェックリストから始め、特定のデジタル プロダクトとチームのニーズに合わせて、重点的な手動テスト チェックリストを作成することをおすすめします。
キーボード チェック
すべてのデジタル アクセシビリティの問題の約 25% は、キーボード サポートの不足に関連していると推定されています。キーボード フォーカス モジュールで説明したように、これは、視覚障害のないキーボードのみを使用するユーザー、弱視/視覚障害のあるスクリーン リーダー ユーザー、コンテンツがキーボードでアクセス可能であることを前提とした技術を使用する音声認識ソフトウェアを使用するユーザーなど、あらゆるタイプのユーザーに影響します。
キーボード テストでは、次のような質問に回答します。
- ウェブページや機能を使用するにはマウスが必要ですか？
- タブ移動の順序は論理的で直感的ですか？
- キーボード フォーカス インジケーターは常に表示されていますか？
- フォーカスをトラップすべきでない要素にフォーカスがトラップされることはありますか？
- フォーカスをトラップすべき要素の背後または周囲に移動できますか？
- フォーカスを受け取った要素を閉じたときに、フォーカス インジケーターは論理的な場所に戻りましたか？
キーボード機能の影響は大きいですが、テスト手順は非常に簡単です。マウスを脇に置くか、 小さな JavaScript パッケージをインストールして、 キーボードのみを使用してウェブサイトをテストするだけです。キーボード テストには次のコマンドが不可欠です。
視覚的なチェック
視覚的なチェックでは、ページの視覚的な要素に焦点を当て、画面拡大やブラウザのズームなどのツールを使用して、ウェブサイトやアプリのアクセシビリティを確認します。
視覚的なチェックでは、次のことを確認できます。
- グラデーションや画像の上にテキストがあるなど、自動ツールでは検出できない色のコントラストの問題がありますか？
- 見出し、リスト、その他の構造要素のように見えるが、そのようにコーディングされていない要素はありますか？
- ナビゲーション リンクとフォーム入力は、ウェブサイトやアプリ全体で一貫していますか？
- 推奨を超える点滅、ストロボ、アニメーションはありますか？
- コンテンツのスペーシングは適切ですか？文字、単語、行、段落のスペーシングは適切ですか？
- 画面拡大やブラウザのズームを使用して、すべてのコンテンツを表示できますか？
コンテンツ チェック
レイアウト、動き、色に焦点を当てる視覚的なテストとは異なり、コンテンツ チェックではページ上の単語に焦点を当てます。コピー自体を確認するだけでなく、他のユーザーにとって意味があるかどうかを確認するために、コンテキストを確認する必要があります。
コンテンツ チェックでは、次のような質問に回答します。
- ページタイトル、見出し、フォームラベルは明確で説明的ですか？
- 画像の代替テキストは簡潔で正確かつ有用ですか？
- 意味や情報を伝える唯一の方法として色のみが使用されていますか？
- リンクは説明的ですか、それとも「詳細はこちら」や「ここをクリック」などの一般的なテキストを使用していますか？
- ページ内で言語が変更されていますか？
- 平易な言葉 が使用され、頭字語は最初に参照されたときにすべてスペルアウトされていますか？
一部のコンテンツ チェックは、部分的に自動化できます。たとえば、「ここをクリック」をチェックして変更を提案する JavaScript リンターを作成できます。 ただし、このようなカスタム ソリューションでは、コピーをコンテキストに応じたものに変更するために、依然として人の手が必要となることがよくあります。
デモ: 手動テスト
これまでのところ、デモのウェブページで自動テストを実行し、8 種類の問題タイプを検出して修正しました。次に、手動チェックを実行して、さらにアクセシビリティの問題を発見できるかどうかを確認します。
ステップ 1
更新された CodePen デモには、自動アクセシビリティの更新がすべて適用されています。
デバッグモードで表示して、
次のテストに進みます。これは、デモのウェブページを囲む <iframe> が削除されるため重要です。この
は、一部のテストツールと競合する可能性があります。CodePen のデバッグモードの詳細をご覧ください。
ステップ 2
マウスまたはトラックパッドを脇に置き、キーボードのみを使用して DOM を上下に移動して、手動テスト プロセスを開始します。
問題 1: フォーカス インジケーターが表示される
最初のキーボードの問題がすぐに表示されます。つまり、表示されるべきではありません。表示されるフォーカス インジケーターが削除されているためです。デモで CSS をスキャンすると、コードベースに「outline: none」が追加されていることがわかります。
:focus {
outline: none;
}
修正しましょう。
キーボード フォーカス モジュールで説明したように、ウェブブラウザでユーザーに表示される フォーカス を追加するには、このコード行を削除する必要があります。さらに、デジタル プロダクトの美観に合わせてスタイル設定されたフォーカス インジケーターを作成することもできます。
:focus {
outline: 3px dotted #008576;
}
問題 2: フォーカス順序
フォーカス インジケーターを変更して表示したら、ページをタブ移動します。その際、ニュースレターの登録に使用するフォーム入力フィールドにフォーカスが移動しないことに気づくはずです。負の tabindex によって、自然なフォーカス順序から削除されています。
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
ユーザーにこのフィールドを使用してニュースレターに登録してもらいたいので、負の tabindex を削除するか、ゼロに設定して、入力が再びキーボード フォーカス可能になるようにします。
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
ステップ 3
キーボード フォーカスを確認したら、視覚的なチェックとコンテンツ チェックに進みます。
問題 3: リンクの色のコントラスト
デモページをタブ移動してキーボード テストを行った際、さまざまな病状に関する段落で、視覚的に非表示の 3 つのリンクにキーボード フォーカスが移動したことに気づいたかもしれません。
ページにアクセスできるようにするには、リンクを周囲のテキストから目立たせ、マウスオーバー時とキーボード フォーカス時に色以外のスタイル変更を含める必要があります。
修正しましょう。
簡単な解決策は、段落内のリンクに下線を追加して目立たせることです。これでアクセシビリティの問題は解決しますが、達成したい全体的なデザインの美観には適さない可能性があります。
下線を追加しない場合は、背景とコピーの両方の要件を満たすように色を変更する必要があります。
リンク コントラスト チェッカー ツールを使用してデモを確認すると、 リンクの色が通常のサイズのテキストと背景の間の色のコントラスト要件 4.5:1 を満たしていることがわかります。 ただし、下線なしのリンクは、周囲のテキストに対して 3:1 の色のコントラスト要件も満たす必要があります。
1 つの方法として、リンクの色をページ上の他の要素と一致するように変更することがあります。 ただし、リンクの色を緑に変更する場合は、リンク、背景、周囲のテキストの 3 つの要素間の全体的な色のコントラスト要件を満たすように、本文のコピーも変更する必要があります。
問題 4: アイコンの色のコントラスト
見落とされた色のコントラストの問題は、ソーシャル メディア アイコンです。 色とコントラスト のモジュールで説明したように、重要なアイコンは背景に対して 3:1 の色のコントラスト を満たす必要があります。ただし、デモでは、ソーシャル メディア アイコンのコントラスト比は 1.3:1 です。
修正しましょう。
3:1 の色のコントラスト要件を満たすように、ソーシャル メディア アイコンが濃いグレーに変更されます。
問題 5: コンテンツのレイアウト
段落コンテンツのレイアウトを見ると、テキストは完全に均等割り付けされています。タイポグラフィ モジュールで説明したように、これにより「スペースの川」が作成され、一部のユーザーにとってテキストが読みにくくなる可能性があります。
p.bullet {
text-align: justify;
}
デモでテキストの配置をリセットするには、コードを text-align: left; に更新するか、その行を CSS から完全に削除します。左はブラウザのデフォルトの配置です。他の継承されたスタイルによってデフォルトのテキスト配置が削除される可能性があるため、コードをテストしてください。
p.bullet {
text-align: left;
}
ステップ 4
前の手順で説明した手動アクセシビリティの問題をすべて特定して修正すると、ページはスクリーンショットのようになります。
このモジュールで説明したよりも多くのアクセシビリティの問題が手動チェックで見つかる可能性があります。これらの問題の多くは、次のモジュールで検出します。
次のステップ
お疲れさまでした。自動テストと手動テストのモジュールを完了しました。 更新された CodePen をご覧ください。自動と手動のアクセシビリティの修正がすべて適用されています。