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

このコースではこれまでに、個人、ビジネス、ビジネス デジタル アクセシビリティの法的側面と基本事項 できます。このコースでは、インクルーシブ デザインに関する具体的なトピックと、 ARIA と HTML の使い分け、色のコントラストの測定方法、 特に JavaScript が不可欠な場合

以降のモジュールでは、設計と構築からテストへと移行します。 考えています次の 3 段階のテストプロセスを使用します。 自動、手動、支援技術のテストツールと手法。Google では、 これらのテスト モジュール全体で同じデモを使用して、 困難です。

各テスト（自動化、手動、支援技術）は、 アクセスしやすいプロダクトをつくるのです。

Google のテストは、Web Content Accessibility Guidelines（WCAG）2.1 に準拠しています。 準拠レベル A および AA の 対応できます。ご自身の業界、商品カテゴリ、地域や国の法律に留意し、 または全体的なユーザー補助の目標によって、どのガイドラインを フォローしたり、レベルを設定したりできます。運用に関して特定の標準を 最新バージョンの WCAG に従うことをおすすめします。 デジタル アクセシビリティの測定方法をもう一度確認しましょう。 （監査、適合性のタイプ/レベル、適合性の監査に関する一般情報）を WCAG POUR。

すでにご存じのとおり、ユーザー補助の適合性は、Google が取り組むなかで 障がいのある人々への支援の必要性に迫られています。ただし、データ アナリストが テストに使用できる指標が得られるからです。ぜひ 次のような、ユーザー補助機能の適合性テスト以外の追加のアクション ユーザビリティテストの実施 障がいのある人々の採用 チームで仕事をしたり、個人や企業に よりインクルーシブなプロダクトを構築できるよう、デジタル アクセシビリティの専門知識を提供しています。

自動テストの基本

ユーザー補助機能の自動テストでは、ソフトウェアを使用してデジタル商品をスキャンし、 事前定義済みのアクセシビリティ適合性標準に照らして、アクセシビリティの問題を明確化します。

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

• 製品ライフサイクルのさまざまな段階で簡単にテストを繰り返す
• わずか数ステップで実行すれば、すぐに結果が得られます
• テストの実施や結果の理解に必要なユーザー補助機能の知識はほとんど必要ない

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

• 自動化ツールでは、プロダクトのユーザー補助エラーをすべて検出できない
• 誤検出の報告（実際の WCAG 違反ではない問題が報告されている）
• 製品の種類や役割に応じて複数のツールが必要になる場合がある

自動テストは、ウェブサイトやアプリで すべてのチェックを自動化できるわけではありません。この後のモジュールで モジュールで自動化できない要素のアクセシビリティを確認する 手動によるユーザー補助機能テストモジュールをご覧ください。

自動化ツールの種類

世界初のオンライン自動ユーザー補助機能テストツールの 1 つは、 によって 1996 年に設立されました。 「The Bobby Report」現在、 100 種類以上の自動テストツールから選択 から！

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

どの自動化ツールを使用するかは、次のようなさまざまな要因によって決まります。

• どの適合性標準とレベルに対してテストしますか？このため、 WCAG 2.1、WCAG 2.0、U.S.セクション 508、またはユーザー補助ルールの修正済みリスト。
• テストするデジタル商品のタイプは何ですか？ウェブサイト、ウェブ モバイルアプリ、ネイティブ モバイルアプリ、PDF、キオスクなどのプロダクトに展開できます。
• ソフトウェア開発ライフサイクルのどの段階でプロダクトのテストを行っていますか？
• ツールの設定と使用にはどれくらいの時間がかかりますか？個人の場合 チームまたは会社ですか？
• デザイナー、デベロッパー、QA など、誰がテストを行いますか。
• ユーザー補助機能を確認する頻度を選択してください。説明すべき内容 含まれるか問題がチケット発行に直接関係しているかどうか ありますか？
• 現在の環境に最適なツールはどれですか？チームにとっても、

他にも考慮すべき要因は多数あります。WAI の記事を見る 「Web Accessibility Evaluation Tools」をご覧ください。 をご覧ください。

デモ: 自動テスト

ユーザー補助機能の自動テストのデモでは、Chrome の Lighthouse: Lighthouse は、Google Cloud で基盤となるインフラストラクチャの ウェブページをさまざまなタイプの監査（パフォーマンス、SEO、 学びました。

デモは、架空の組織「Medical Mysteries」用に構築されたウェブサイトです。 クラブだ。このサイトは、デモのために意図的にアクセスできないように設定されています。この一部 アクセス不能な状態に表示され、一部（すべてではありません）が 確認します

ステップ 1

Chrome ブラウザを使用して、 Lighthouse 拡張機能:

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

ステップ 2

CodePen のデモを作成しました。 デバッグモードで表示して、次の手順に進んでください。 説明します。これを囲む <iframe> が削除されるため、これは重要です。 使用すると、一部のテストツールに影響する可能性があります。詳細: CodePen のデバッグモード。

ステップ 3

Chrome DevTools を開きます。 [Lighthouse]タブに移動します次を除くすべてのカテゴリ オプションのチェックボックスをオフにします。 「ユーザー補助」モードをデフォルトのままにして、使用するデバイスの種類を選択します。 テストを実行できます

ステップ 4

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

テストが完了すると、Lighthouse では、 アクセスできる状態であることを確認します。「 Lighthouse のスコア は、問題の数、問題のタイプ、 表示されます。

Lighthouse レポートには、スコアだけでなく、 検出された問題と、解決方法の詳細を確認できるリソースへのリンク できます。このレポートには、合格したテストや適用されないテスト、 追加項目のリストを取得できます

ステップ 5

では、ユーザー補助機能の自動化に関するそれぞれの問題の例を見ていきましょう。 関連するスタイルとマークアップを検出して修正します

問題 1: ARIA ロール

最初の問題は次のとおりです。「ARIA [ロール] を持つ要素で、子が 必要な子の一部またはすべてが欠落している。 一部の ARIA 親ロールには、実行するために特定の子ロールが含まれている必要があります 記述する必要があります ARIA ロールのルールの詳細を確認する。

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

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

</ph> 修正しましょう。

「チャンネル登録」入力フィールドの横のボタンの 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>

</ph> 修正しましょう。

入力フィールドに 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>

</ph> 修正しましょう。

Google Cloud コンソールのボタン要素から不正確な ARIA ロールを削除すると、 問題 1、「定期購読」という言葉アクセスボタンになり 表示されます。この機能は、セマンティック 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>

</ph> 修正しましょう。

ロゴ画像もリンクなので 画像モジュールが表示されます 画像の目的に関する代替テキスト情報が必要です。 通常、ページの最初の画像はロゴなので、 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>

</ph> 修正しましょう。

ページ上のすべての操作可能な画像には、そのページの場所に関する情報を含める必要があります。 ユーザーを誘導しますこの問題を解決するための 1 つの方法は、 使用します。これは <img> タグを使用する画像には適していますが、<svg> タグではこのメソッドを使用できません。

<svg> タグを使用するソーシャル メディア アイコンの場合、 異なる記述パターン SVG をターゲット設定するには、<a> タグと <svg> タグの間に情報を追加してから、 ユーザーに対して非表示にしたり、サポートされている ARIA を追加したり、その他のオプションを追加したりします。影響する 環境やコードの制限によっては、特定のメソッドよりも 別のものです。最もシンプルなパターン オプションを使用して テクノロジーの範囲: <svg> タグに role="img" を追加する これには <title> 要素が含まれます。

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

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

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

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph> をご覧ください。 <ph type="x-smartling-placeholder">で確認できます。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph>

</ph> 修正しましょう。

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

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

この場合、4.5:1 を満たすのに十分な濃い青緑色、または ボタンテキストのサイズを 18.5 ピクセルに増やして太字にして、 少し青緑色になります。どちらの方法でも設計と一貫性を保ちます 美観です

白い背景上の灰色のテキストも、色のコントラストが不適切です。ただし、 ページ上で最も大きい 2 つの見出しで要件を満たすには、このテキストの色を暗くする必要があります 色のコントラストが 4.5:1 の場合。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph> をご覧ください。 <ph type="x-smartling-placeholder">で確認できます。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph>

問題 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>

</ph> 修正しましょう。

このデモでは CSS クラスを使用して、 <ul> タグを使用する。このコードを誤って記述した場合は、 セマンティック HTML 機能を実装している場合に便利です。クラスを実際の <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>

</ph> 修正しましょう。

特に理由がない限り、ウェブ上での自然なタブの順序が崩れるような場合は別です。 tabindex 属性に正の整数を指定する必要はありません。宛先 タブの順序を自然に維持するには、tabindex を 0 に変更するか、 属性を完全に削除します。

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

ステップ 6

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

これらのユーザー補助機能の自動更新はすべて CodePen。

次のステップ

いい成績です。あなたはすでに多くのことを成し遂げていますが、まだ完了していません。次に 手動チェックに進みます 手動によるユーザー補助機能テストモジュールをご覧ください。

理解度をチェックする

ユーザー補助機能の自動テストに関する知識をテストする