ユーザー補助機能の自動テスト

このコースではこれまで、デジタル アクセシビリティの個人面、ビジネス面、法律面と、デジタル アクセシビリティの適合性に関する基本について学習しました。ARIA と HTML の使い分け、JavaScript が不可欠な場合の色のコントラストの測定方法など、インクルーシブなデザインとコーディングに関連する具体的なトピックを見てきました。

残りのモジュールでは、ユーザー補助の設計と構築からテストに目を向けます。Google では、自動、手動、支援技術のテストツールと手法を含む 3 段階のテストプロセスを利用します。これらのテスト モジュール全体で同じデモを使用して、ウェブページを「アクセス不可」から「アクセス可能」に改善します。

可能な限りアクセスしやすいプロダクトを実現するには、自動、手動、支援技術の各テストが不可欠です。

Google のテストは、Web Content Accessibility Guidelines（WCAG）2.1 の適合性レベル A および AA を標準として利用しています。どのガイドラインに従うか、どのレベルに従うべきかは、業種、プロダクト タイプ、国や地域の法律とポリシー、または全体的なユーザー補助の目標によって決まります。プロジェクトに特定の標準が必要ない場合は、最新バージョンの WCAG に従うことをおすすめします。ユーザー補助の監査、適合性のタイプ/レベル、WCAG、POUR に関する一般的な情報については、デジタル アクセシビリティの測定方法をご覧ください。

ご存じのように、障がいのある人のサポートにおいて、ユーザー補助の適合性は必ずしも完全なものではありません。テストの参考になる指標として利用できますユーザー補助の適合性テスト以外にも、障がいのある方を対象にユーザビリティ テストを実施する、障がいのある方をチームに採用してもらう、デジタル アクセシビリティの専門知識を持つ個人や企業に協力を仰ぐなど、よりインクルーシブなプロダクトの構築をサポートするなど、アクセシビリティの適合性テスト以外の取り組みを行うことをおすすめします。

自動テストの基本

自動化されたユーザー補助テストでは、ソフトウェアを使用してデジタル プロダクトをスキャンし、事前定義されたユーザー補助の適合性基準に照らしてユーザー補助の問題を検出します。

自動化されたユーザー補助機能テストの長所:

• 製品ライフサイクルのさまざまな段階でテストを簡単に繰り返す
• 数ステップで実行でき、結果も非常に高速
• ユーザー補助機能の知識は、テストの実行や結果理解にほとんど必要ありません

自動化されたユーザー補助機能テストの短所:

• 自動化ツールではサービス内のユーザー補助エラーをすべて検出できない
• 偽陽性の報告（真の WCAG 違反ではない問題が報告された）
• プロダクトの種類や役割に応じて複数のツールが必要な場合がある

自動テストは、ウェブサイトまたはアプリのユーザー補助機能をチェックする最初のステップとして最適ですが、すべてのチェックを自動化できるわけではありません。自動化できない要素のユーザー補助機能をチェックする方法については、手動のユーザー補助機能テストのモジュールで詳しく説明します。

自動化ツールの種類

1996 年に Center for Applied Special Technology（CAST）によって最初のオンラインの自動ユーザー補助テストツールの一つが開発されました。これは「The Bobby Report」と呼ばれています。現在、100 種類を超える自動テストツールが用意されています。

自動化ツールの実装は、ユーザー補助ブラウザの拡張機能から、コードリンター、デスクトップ / モバイルアプリ、オンライン ダッシュボード、さらには独自の自動化ツールを構築するために使用できるオープンソース API まで多岐にわたります。

どの自動化ツールを使用するかは、次のようなさまざまな要因に左右されます。

• どの適合性標準 / レベルに対してテストを行っていますか？これには、WCAG 2.1、WCAG 2.0、米国第 508 条、またはユーザー補助ルールの修正リストが含まれます。
• テスト対象のデジタル プロダクトの種類ウェブサイト、ウェブアプリ、ネイティブ モバイルアプリ、PDF、キオスクなどのプロダクトが該当します。
• プロダクトをテストするのは、ソフトウェア開発ライフサイクルのどの段階ですか？
• ツールのセットアップと使用にはどのくらいの時間がかかりますか？個人、チーム、企業でどうすればよいでしょうか。
• テストの実施者（デザイナー、デベロッパー、QA など）
• ユーザー補助機能のチェックをどのくらいの頻度で行いたいですか？レポートにはどのような詳細情報を含めるべきでしょうか？問題はチケット発行システムに直接リンクする必要がありますか？
• 現在の環境に最適なツールチームに利用するには、

他にも考慮すべき要素はたくさんあります。ご自身やチームにとって最適なツールを選択する方法について詳しくは、WAI の記事「Selecting Web Accessibility Evaluation Tools」をご覧ください。

デモ: 自動テスト

自動ユーザー補助機能テストのデモでは、Chrome の Lighthouse を使用します。 Lighthouse はオープンソースの自動化ツールで、パフォーマンス、SEO、ユーザー補助など、さまざまな監査を実施してウェブページの品質改善を図ります。

このデモは、架空の組織「メディカル ミステリーズ クラブ」のために構築されたウェブサイトです。このサイトは意図的にアクセスできないようにしています。こうしたアクセスできない部分は、ユーザーに表示される場合もあれば、（すべてではない）自動テストで検出される場合もあります。

ステップ 1

Chrome ブラウザを使用して、Lighthouse 拡張機能をインストールします。

テスト ワークフローに Lighthouse を統合する方法は多数あります。このデモでは、Chrome 拡張機能を使用します。

ステップ 2

CodePen のデモを作成しました。テストをデバッグモードで表示して、次のテストに進みます。デモのウェブページを囲む <iframe> が削除され、一部のテストツールを妨げる可能性があるため、この更新は重要です。CodePen のデバッグモードの詳細を確認してください。

ステップ 3

Chrome DevTools を開き、[Lighthouse] タブに移動します。[ユーザー補助] 以外のカテゴリ オプションをすべてオフにします。このモードをデフォルトのままにして、テストを実行するデバイスタイプを選択します。

ステップ 4

[ページ読み込みを分析] ボタンをクリックし、Lighthouse でテストを実行する時間を確保します。

テストが完了すると、Lighthouse にはテスト対象のプロダクトのユーザー補助機能のスコアが表示されます。Lighthouse のスコアは、問題の数、問題の種類、検出された問題がユーザーに与える影響に基づいて計算されます。

Lighthouse のレポートには、スコアだけでなく、検出された問題に関する詳細情報と、問題を修復するためのリソースへのリンクも表示されます。このレポートには、合格したテストや適用できないテストと、手動で確認する追加項目のリストも含まれています。

ステップ 5

では、検出されたユーザー補助の問題を自動的に検出した例を確認し、関連するスタイルとマークアップを修正しましょう。

問題 1: ARIA ロール

最初の問題は、「子に特定の [role] を含める必要がある ARIA [role] を持つ要素に、これらの必須の子の一部またはすべてが欠落しています。一部の ARIA 親ロールには、目的のユーザー補助機能を実行するために特定の子ロールを含める必要があります。" ARIA ロールのルールの詳細

デモでは、ニュースレターの登録ボタンが失敗します。

<button role="list" type="submit" tabindex="1">Subscribe</button>

修正しましょう。

入力フィールドの横にある [チャンネル登録] ボタンに、正しくない ARIA ロールが適用されている。この場合、ロールは完全に削除できます。

<button type="submit" tabindex="1">Subscribe</button>

問題 2: ARIA が非表示になる

"[aria-hidden="true"] 要素にフォーカス可能な子孫が含まれています。[aria-hidden="true"] 要素内にフォーカス可能な子孫がある場合、スクリーン リーダーなどの支援技術のユーザーは、そのようなインタラクティブ要素を利用できなくなります。aria-hidden ルールの詳細

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

修正しましょう。

入力フィールドに aria-hidden="true" 属性が適用されています。この属性を追加すると、要素（および要素の下にネストされているすべての要素）が支援技術から非表示になります。

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

この場合、支援技術を使用するユーザーがフォーム フィールドの情報にアクセスして入力できるように、この属性を入力から削除する必要があります。

問題 3: ボタン名

ボタンにユーザー補助機能用の名前が付いていません。ボタンにユーザー補助機能用の名前が設定されていない場合、スクリーン リーダーでは「ボタン」として読み上げられるため、スクリーン リーダーを使用しているユーザーはボタンを使用できません。詳しくは、ボタン名のルールをご覧ください。

<button role="list" type="submit" tabindex="1">Subscribe</button>

修正しましょう。

問題 1 のボタン要素から不正確な ARIA ロールを削除すると、「購読」という単語がアクセス可能なボタン名になります。この機能は、セマンティック HTML ボタン要素に組み込まれています。より複雑な状況では、他にも考慮すべきパターン オプションがあります。

<button type="submit" tabindex="1">Subscribe</button>

問題 4: 画像の alt 属性

画像要素に [alt] 属性がありません。説明的要素は、簡潔でわかりやすい代替テキストにする必要があります。装飾要素は、空の alt 属性を使用して無視できます。詳しくは、画像の代替テキストのルールをご覧ください。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

修正しましょう。

ロゴ画像はリンクでもあるため、画像モジュールから、アクション可能な画像と呼ばれ、画像の目的に関する代替テキスト情報が必要であることがわかっています。通常、ページの最初の画像はロゴです。そのため、AT ユーザーがこのことを認識していると想定できます。また、この追加のコンテキスト情報を画像の説明に追加しないと考えることもできます。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

問題 5: リンクテキスト

リンクに識別可能な名前がありません。識別可能、一意、フォーカス可能なリンクテキスト（および画像の代替テキスト（リンクとして使用する場合））により、スクリーン リーダー ユーザーのナビゲーション エクスペリエンスが向上します。詳しくは、リンクテキストのルールをご覧ください。

<a href="#!"><svg><path>...</path></svg></a>

修正しましょう。

ページ上のすべての操作可能な画像に、リンクからユーザーが誘導される場所に関する情報を含める必要があります。この問題を解決するための方法の 1 つは、上記の例のロゴ画像で行ったように、目的に関する代替テキストを画像に追加することです。これは <img> タグを使用する画像には適していますが、<svg> タグでこのメソッドを使用することはできません。

ソーシャル メディア アイコン（<svg> タグを使用）の場合、SVG をターゲットとする別の代替説明パターンを使用し、<a> タグと <svg> タグの間に情報を追加してから、ユーザーに対して視覚的に非表示にする、サポートされている ARIA を追加する、またはその他のオプションを追加できます。環境とコードの制限によっては、あるメソッドが別の方法よりも適している場合があります。最も補助的なテクノロジーをカバーする最もシンプルなパターン オプションを使用します。つまり、role="img" を <svg> タグに追加し、<title> 要素を追加します。

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

問題 6: 色のコントラスト

背景色と前景の色のコントラスト比が十分ではありません。低コントラストのテキストを使用すると、多くのユーザーは読むことが困難または不可能になります。詳しくは、色のコントラスト ルールをご覧ください。

2 つの例が報告されました。

修正しましょう。

ウェブページで色のコントラストに関する問題が多数検出されています。色とコントラストのモジュールで学習したように、レギュラー サイズのテキスト（18 pt / 24 ピクセル未満）の色のコントラスト要件は 4.5:1 ですが、大きいサイズのテキスト（18 pt / 24 ピクセルまたは 14 pt / 18.5 ピクセル以上の太字）と重要なアイコンは 3:1 の要件を満たす必要があります。

ページタイトルの場合、ティール色のテキストはサイズが 24 ピクセルの大きいテキストであるため、3:1 のコントラスト要件を満たす必要があります。ただし、青緑色ボタンは、16 ピクセルの太字のレギュラー サイズのテキストとみなされるため、4.5:1 の色のコントラスト要件を満たす必要があります。

この場合、4.5:1 を満たすのに十分暗い青緑の色を見つけるか、ボタンテキストのサイズを 18.5 ピクセルの太字に拡大して青緑の値をわずかに変更することができます。どちらの方法でもデザインの美しさに合わせます。

また、ページ上で最も大きい 2 つの見出しを除き、白い背景にグレーのテキストでも色のコントラストがうまくいきません。このテキストは、4.5:1 のカラー コントラスト要件を満たすように暗くする必要があります。

問題 7 - リスト構造

リストアイテム（<li>）が <ul> または <ol> の親要素内にありません。スクリーン リーダーで適切に読み上げるには、リストアイテム（<li>）を親の <ul> または <ol> 内に含める必要があります。

詳しくは、リストルールについての記事をご覧ください。

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

修正しましょう。

このデモでは、<ul> タグの代わりに CSS クラスを使用して、順序なしリストをシミュレートしています。この不適切な記述により、このタグに組み込まれているセマンティック HTML 機能は削除されています。Google では、クラスを実際の <ul> タグに置き換えて、関連する CSS を変更することで、このユーザー補助機能の問題を解決しています。

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

問題 #8 - tabindex

[tabindex] の値が 0 より大きい要素があります。0 より大きい値は、ナビゲーションの順序が明示的に指定されていることを意味します。技術的には有効ですが、支援技術を利用するユーザーには不便となることがよくあります。tabindex ルールの詳細

<button type="submit" tabindex="1">Subscribe</button>

修正しましょう。

ウェブページの通常のタブ操作を妨げる特別な理由がない限り、tabindex 属性に正の整数を設定する必要はありません。自然なタブ順を維持するには、tabindex を 0 に変更するか、属性を完全に削除します。

<button type="submit">Subscribe</button>

ステップ 6

自動化されたユーザー補助の問題をすべて修正したので、新しいデバッグモードのページを開きます。Lighthouse のユーザー補助監査を再度実行します。スコアは初回実行時よりもはるかに良くなっているはずです。

こうしたユーザー補助の自動更新はすべて、新しい CodePen に適用されています。

次のステップ

いい成績です。たくさんのことを成し遂げてきていますが、まだ完了していません。次は、手動チェックについて考えましょう。手動のユーザー補助機能テスト モジュールで詳しく説明します。

理解度チェック

自動化されたユーザー補助テストに関する知識をテストする