手動テストの基本
手動によるユーザー補助機能テストでは、キーボード、視覚、認知の各テスト、ツール、 自動化ツールでは検出できない問題を発見できます自動設定 ツールは 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 を削除するか、値を 0 に設定して、入力が再びキーボード フォーカス可能になるようにします。
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
ステップ 3
キーボード フォーカスを確認したら、ビジュアル チェックとコンテンツ チェックに進みます。
問題 3: リンクの色のコントラスト
デモページを上下にタップしてキーボード テストを進めていくと、 お気づきかもしれませんが、キーボードの 3 つの視覚的隠しリンクに注目してください。 さまざまな病状に関する段落を含めます。
ページにアクセスできるようにするには、リンクが周囲のテキストよりも目立つようにする必要があります マウスのカーソルを合わせたときやキーボードのフォーカスがあるときに、色以外のスタイルが変わります。
<ph type="x-smartling-placeholder">
修正しましょう。
簡単な解決策は、段落内のリンクに下線を追加して目立たせることです。この方法ではアクセシビリティの問題は解決できますが、目指すデザインの全体的なデザインには合っていない可能性があります。
下線を追加しない場合は、背景とコピーのそれぞれの要件を満たすように色を変更する必要があります。
リンク コントラスト チェッカー ツールを使用してデモを見ると、リンクの色が通常サイズのテキストと背景の色のコントラスト 4.5:1 の要件を満たしていることがわかります。ただし、下線が付いていないリンクの場合は、周囲のテキストとの色のコントラストが 3:1 の要件を満たす必要があります。
たとえば、ページ上の他の要素に合わせてリンクの色を変更するという方法があります。ただし、リンクの色を緑に変更した場合は、3 つの要素（リンク、背景、周囲のテキスト）全体の色のコントラスト要件を満たすように本文のコピーも変更する必要があります。
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">問題 4: アイコンの色のコントラスト
色のコントラストが欠落しているもう一つの問題は、ソーシャル メディアのアイコンです。「色とコントラスト」モジュールでは、重要なアイコンは背景に対する色のコントラストが 3:1 である必要があることを学びました。ただし、このデモでは、ソーシャル メディア アイコンのコントラスト比が 1.3:1 になっています。
<ph type="x-smartling-placeholder">
修正しましょう。
色のコントラスト 3:1 の要件を満たすため、ソーシャル メディアのアイコンが濃いグレーに変更されます。
<ph type="x-smartling-placeholder">
問題 5: コンテンツ レイアウト
段落コンテンツのレイアウトを確認すると、テキストは完全に 両端揃え。前のモジュールで タイポグラフィ モジュール 「宇宙の川」が生まれ、一部のユーザーにとっては 読み取ります
p.bullet {
text-align: justify;
}
デモのテキストの配置をリセットするには、コードを
text-align: left; するか、その行を CSS から完全に削除します。左側の
ブラウザのデフォルトの配置です。その他のケースに遭遇した場合に備えて、
継承されたスタイルでは、デフォルトのテキストの配置が削除されます。
p.bullet {
text-align: left;
}
ステップ 4
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">前の手順で説明した手動によるユーザー補助の問題をすべて特定して修正すると、ページはスクリーンショットのようになります。
手動チェックでは、このモジュールで説明したユーザー補助の問題よりも多くの問題が見つかる可能性があります。次のモジュールで、これらの問題の多くについて学習します。
次のステップ
モバイル デバイスやタブレットでのキューなど、自動テスト モジュールと手動テスト モジュールを修了しました。 最新の CodePen をご覧ください。 自動と手動のユーザー補助修正がすべて適用されています。
では、前回のテストモジュールでは 支援技術のテスト。
理解度をチェックする
手動によるユーザー補助機能テストに関する知識をテストする
WCAG の色のコントラスト基準を満たす必要がある要素は何ですか？