手動テストの基本
手動のユーザー補助機能テストでは、キーボード、視覚テスト、認知テスト、ツール、手法を使用して、自動化ツールでは検出できない問題を見つけます。自動化ツールが WCAG で特定されたすべての成功基準に対応しているわけではないため、自動化されたユーザー補助テストを実行してからテストを停止することは不可欠です。
技術の進歩に伴い、自動ツールだけで対応できるテストも増えていきますが、現在は、該当するすべての WCAG チェックポイントをテストするために、手動と支援の両方の技術チェックをテスト手順に追加する必要があります。
手動のユーザー補助機能テストのメリット:
- まあまあ簡単ですぐに実行できる
- 自動テストのみの場合よりも高い割合で問題を捕捉
- 成功に必要なツールと専門知識がほとんどない
手動のユーザー補助機能テストの短所:
- 自動テストよりも複雑で時間がかかる
- 大規模な再現は難しい場合がある
- テストを実行して結果を解釈するには、より多くのユーザー補助機能の専門知識が必要
自動化ツールで現在検出できるユーザー補助要素やユーザー補助情報と、検出されないユーザー補助要素と詳細を比較してみましょう。
手動テストの種類
ウェブページやアプリでデジタル アクセシビリティ機能を利用する際に考慮すべき手動ツールや手法は多数あります。手動テストで特に重点を置いているのは、キーボード機能、視覚に訴えるレビュー、一般的なコンテンツ チェックの 3 つです。
このモジュールではこうした各トピックについて大まかに説明しますが、以下のテストは、実行できる（または実行すべき手動テストをすべて網羅したリストではありません）。まずは、信頼できる情報源による手動のユーザー補助機能チェックリストから始め、特定のデジタル プロダクトとチームのニーズに焦点を絞った独自の手動テスト チェックリストを作成することをおすすめします。
キーボードのチェック
デジタル アクセシビリティに関するすべての問題の約 25% は、キーボード サポートがないことに関連していると推定されます。キーボード フォーカス モジュールで説明したように、これは、目の見えるキーボードのみを使用するユーザー、ロービジョンまたは目の見えないスクリーン リーダーのユーザー、キーボードでアクセス可能なテクノロジーを使用する音声認識ソフトウェアを使用しているユーザーなど、あらゆるタイプのユーザーに影響します。
キーボード テストでは、次のような質問に答えることができます。
- ウェブページや機能を動作させるにはマウスが必要ですか？
- タブ操作は論理的かつ直感的ですか？
- キーボードのフォーカス インジケーターが常に表示されていますか？
- フォーカスを閉じられるべきでない要素に行き詰まることがありますか？
- フォーカスをトラップすべき要素の背後または周囲に移動できますか？
- フォーカスを受け取った要素を閉じるとき、フォーカス インジケーターは論理的な場所に戻りましたか？
キーボードの機能の影響は多大ですが、テスト手順は非常にシンプルです。必要な作業は、マウスを用意するか、小さな JavaScript パッケージをインストールし、キーボードだけでウェブサイトをテストすることだけです。キーボード テストには以下のコマンドが必要です。
目視チェック
目視チェックでは、ページの視覚要素に焦点を当て、画面拡大やブラウザのズームなどのツールを使用して、ウェブサイトやアプリのユーザー補助機能を評価します。
目視確認を使用すると、次のことがわかります。
- グラデーションや画像の上のテキストなど、自動化ツールでは検出できない色のコントラストに関する問題はありますか。
- 見出しやリスト、その他の構造的要素のように見えても、そのようにコーディングされていない要素はありますか。
- ウェブサイトまたはアプリ全体で、ナビゲーション リンクとフォーム入力に一貫性がありますか？
- 推奨事項を超える点滅、ストロボ効果、アニメーションは含まれていませんか？
- コンテンツ間に適切なスペースがありますか？文字、単語、行、段落
- 拡大鏡やブラウザのズームを使ってすべてのコンテンツを表示できるか。
コンテンツ チェック
レイアウト、動き、色に焦点を当てたビジュアル テストとは異なり、コンテンツ チェックはページ上の単語に着目します。テキストそのものを見るだけでなく、文脈を精査して、他の人にとって意味が通じるかを確認することも求められます。
コンテンツ チェックは、次のような質問に答えます。
- ページのタイトル、見出し、フォームラベルは、明確でわかりやすいですか。
- 代替画像は簡潔で、正確で、有用ですか？
- 意味や情報を伝える唯一の手段として色のみが使用されているか？
- リンクがわかりやすいか、「もっと読む」や「ここをクリック」などの一般的なテキストを使用しているか
- ページ内の言語に変更はありますか？
- 平易な言葉が使用されており、最初に言及した頭字語はすべてスペルアウトされていますか。
一部のコンテンツ チェックは、部分的に自動化できます。たとえば、「Click here」を確認して変更を提案する 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 をご覧ください。この CodePen では、ユーザー補助の自動修正と手動修正がすべて適用されています。
最後のテスト モジュールでは、支援技術のテストに焦点を当てました。
理解度チェック
手動のユーザー補助機能テストに関する知識をテストする
WCAG の色のコントラスト基準を満たす必要がある要素は何ですか？