手動ユーザー補助機能テスト

手動テストの基本

手動のユーザー補助機能テストでは、キーボード、視覚、認知のテスト、ツール、手法を使用して、自動ツールでは検出できない問題を検出します。自動ツールでは WCAG で特定されたすべての達成基準を網羅できないため、自動アクセシビリティ テストを実行し、テストを継続することが不可欠です。

技術の進歩に伴い、自動化ツールだけでより多くのテストをカバーできるようになる可能性がありますが、現時点では、該当するすべての WCAG チェックポイントをカバーするために、手動チェックと支援技術チェックの両方をテスト プロトコルに追加する必要があります。

手動のユーザー補助機能テストのメリット:

• 比較的簡単で、実行も迅速
• 自動テストだけでは検出できない問題の割合を増やす
• 成功に必要なツールと専門知識が少ない

手動アクセシビリティ テストのデメリット:

• 自動テストよりも複雑で時間がかかる
• 大規模な繰り返しが難しい場合がある
• テストの実行と結果の解釈にアクセシビリティに関する専門知識が必要

自動ツールで検出できるユーザー補助要素と詳細と、検出できないユーザー補助要素と詳細を比較します。

手動テストの種類

ウェブページやアプリのデジタル アクセシビリティを検討する際には、考慮すべき手動のツールや手法が数多くあります。手動テストの 3 つの主な重点分野は、キーボード機能、視覚的なレビュー、一般的なコンテンツ チェックです。

このモジュールでは、これらの各トピックの概要を説明しますが、次のテストは、実行できる、または実行すべきすべての手動テストを網羅したリストではありません。信頼できるソースのアクセシビリティの手動チェックリストから始め、特定のデジタル プロダクトとチームのニーズに合わせて、独自の重点的な手動テスト チェックリストを作成することをおすすめします。

キーボード チェック

デジタル アクセシビリティに関する問題の約 25% は、キーボードのサポート不足に関連していると推定されています。キーボード フォーカス モジュールで説明したように、これは、キーボードのみを使用する視覚のあるユーザー、ロービジョン/目の不自由なスクリーン リーダー ユーザー、キーボードでアクセス可能なコンテンツに依存するテクノロジーを使用する音声認識ソフトウェアを使用するユーザーなど、あらゆるタイプのユーザーに影響します。

キーボード テストでは、次のような疑問を解消できます。

• ウェブページまたは機能の動作にマウスが必要ですか？
• タブ移動の順序は論理的で直感的ですか？
• キーボード フォーカス インジケーターは常に表示されますか？
• フォーカスをトラップすべきでない要素にフォーカスが移動したままになることはありますか？
• フォーカスをトラップするはずの要素の背後または周囲に移動できますか？
• フォーカスを受け取った要素を閉じたときに、フォーカス インジケーターは論理的な場所に戻りましたか？

キーボード機能の影響は大きいですが、テスト手順は非常に簡単です。マウスを脇に置いておくか、小さな JavaScript パッケージをインストールして、キーボードのみを使用してウェブサイトをテストします。キーボード テストには、次のコマンドが不可欠です。

視覚的なチェック

視覚的なチェックでは、ページの視覚要素に焦点を当て、画面の拡大やブラウザのズームなどのツールを使用して、ウェブサイトやアプリのアクセシビリティを確認します。

目視検査では、次のことを確認できます。

• グラデーションや画像の上にテキストが配置されているなど、自動ツールでは検出できない色のコントラストの問題はありますか？
• 見出しやリストなどの構造要素のように見えるが、そのようにコーディングされていない要素はありますか？
• ウェブサイトまたはアプリ全体で、ナビゲーション リンクとフォーム入力は一貫していますか？
• 推奨値を超える点滅、ストロボ、アニメーションはありますか？
• コンテンツのスペーシングは適切ですか？文字、単語、行、段落の単位で読み上げますか？
• 拡大鏡やブラウザのズーム機能を使って、すべてのコンテンツを確認できますか？

コンテンツのチェック

レイアウト、動き、色に焦点を当てるビジュアル テストとは異なり、コンテンツ チェックはページ上の単語に焦点を当てます。コピー自体だけでなく、コンテキストも確認して、他のユーザーにとって意味のあるものになっていることを確認する必要があります。

コンテンツ チェックでは、次のような疑問を解消できます。

• ページのタイトル、見出し、フォームのラベルは明確で説明的ですか？
• 画像の説明は簡潔で正確かつ有用ですか？
• 色のみが意味や情報を伝える唯一の手段として使用されているか。
• リンクは説明的ですか？それとも、「詳細はこちら」や「ここをクリック」などの一般的なテキストを使用していますか？
• ページ内の言語に変更はありますか？
• 平易な言葉が使用され、頭字語はすべて最初に参照されたときにスペルアウトされていますか？

コンテンツ チェックの一部は自動化できます。たとえば、「ここをクリック」をチェックして変更を提案する JavaScript リンターを作成できます。ただし、このようなカスタム ソリューションでも、コピーをコンテキストに沿ったものに変更するには、人間による作業が必要になることがよくあります。

デモ: 手動テスト

これまでに、デモのウェブページで自動テストを実行し、8 種類の問題タイプを検出して修正しました。これで、手動チェックを実行して、さらに多くのユーザー補助の問題を検出できるかどうかを確認する準備が整いました。

ステップ 1

更新された CodePen デモには、自動化されたアクセシビリティの更新がすべて適用されています。

デバッグモードで確認して、次のテストに進みます。これは、デモのウェブページを囲む <iframe> を削除するため、重要です。この <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: アイコンの色のコントラスト

もう 1 つのコントラストの問題は、ソーシャル メディア アイコンです。色とコントラスト モジュールでは、重要なアイコンは背景に対して 3:1 の色のコントラストを満たす必要があることを学びました。ただし、デモでは、ソーシャル メディア アイコンのコントラスト比は 1.3:1 です。

この問題を解決しましょう。

3:1 の色のコントラスト要件を満たすため、ソーシャル メディア アイコンが濃いグレーに変更されます。

問題 5: コンテンツのレイアウト

段落コンテンツのレイアウトを見ると、テキストが両端揃えになっています。タイポグラフィ モジュールで説明したように、この方法では「スペースの川」ができてしまい、一部のユーザーにとってテキストが読みにくくなる可能性があります。

p.bullet {
   text-align: justify;
}

修正しましょう。

デモでテキストの配置をリセットするには、コードを text-align: left; に更新するか、CSS からその行を完全に削除します。ブラウザのデフォルトの配置は左です。他の継承されたスタイルによってデフォルトのテキスト配置が削除される可能性があるため、コードをテストしてください。

p.bullet {
   text-align: left;
}

ステップ 4

前の手順で説明した手動のユーザー補助に関する問題をすべて特定して修正すると、ページはスクリーンショットのようになります。

手動チェックでは、このモジュールで説明した以外にもユーザー補助機能に関する問題が見つかる可能性があります。これらの問題の多くについては、次のモジュールで説明します。

次のステップ

お疲れさまでした。自動テストと手動テストのモジュールを完了しました。更新された CodePen をご覧ください。自動および手動のアクセシビリティ修正がすべて適用されています。

それでは、支援技術のテストに焦点を当てた最後のテスト モジュールに進みましょう。