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

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

残りのモジュールでは、設計と構築からアクセシビリティのテストに切り替えます。自動テスト、手動テスト、支援技術テストのツールと手法を含む 3 段階のテストプロセスについて説明します。これらのテスト モジュール全体で同じデモを使用して、ウェブページをアクセスできない状態からアクセスできる状態にしていきます。

自動テスト、手動テスト、支援技術テストの各テストは、可能な限りアクセシビリティの高いプロダクトを実現するために不可欠です。Google のテストは、Web Content Accessibility Guidelines（WCAG）2.1 適合性レベル A と AA を標準としています。

業界、プロダクト タイプ、地域や国の法律とポリシー、または全体的なアクセシビリティの目標によって、従うべきガイドラインと満たすべきレベルが決まります。プロジェクトに特定の標準が必要ない場合は、最新バージョンの WCAG に従うことをおすすめします。 アクセシビリティ監査、適合性のタイプ/レベル、WCAG、POURに関する一般的な情報については、「デジタル アクセシビリティはどのように測定されますか？」をご覧ください。

ご存じのとおり、アクセシビリティの準拠は、障がいのあるユーザーをサポートするうえで完全なものではありません。 ただし、テストできる指標を提供するため、良い出発点となります。よりインクルーシブなプロダクトを構築するために、適合性テストに加えて次の操作を行うことをおすすめします。

• 障がいのあるユーザーを対象にユーザビリティ テストを実施する。
• 障がいのあるユーザーをチームに採用する。
• デジタル アクセシビリティの専門知識を持つ個人または企業に相談する。

自動テストの基本

自動アクセシビリティ テストでは、ソフトウェアを使用して、事前定義されたアクセシビリティ適合性標準に照らしてデジタル プロダクトのアクセシビリティの問題をスキャンします。

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

• プロダクト ライフサイクルのさまざまな段階でテストをすばやく繰り返すことができます。
• 実行する手順が少なく、結果がすぐに得られます。
• テストの実行や結果の理解にアクセシビリティに関する知識はほとんど必要ありません。

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

• 自動ツールでは、プロダクトのアクセシビリティ エラーをすべて検出できるわけではありません。
• 偽陽性（WCAG の違反ではない問題が報告される）が報告されることがあります。
• プロダクト タイプやロールによって複数のツールが必要になる場合があります。

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

自動ツールの種類

最初のオンライン自動アクセシビリティ テストツールの 1 つは、 1996 年に Center for Applied Special Technology（CAST）によって開発された「The Bobby Report」です。現在では、 100 種類以上の自動テストツールから選択できます。

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

使用する自動ツールは、次のような多くの要因によって異なります。

• テスト対象の適合性標準とレベル。これには、WCAG 2.2、WCAG 2.1、米国リハビリテーション法第 508 条、または変更されたアクセシビリティ ルールのリストが含まれます。
• テストするデジタル プロダクトのタイプ。ウェブサイト、ウェブアプリ、ネイティブ モバイルアプリ、PDF、キオスクなどがあります。
• プロダクトをテストするソフトウェア開発ライフサイクルのどの部分か。
• ツールの設定と使用にかかる時間。個人、チーム、企業向けですか？
• テストを実施するのは、デザイナー、デベロッパー、QA、またはその他の担当者ですか？
• アクセシビリティのチェックをどのくらいの頻度で行うか。レポートに含めるべき詳細情報。 問題をチケット発行システムに直接リンクする必要があるか。
• 環境に最適なツール。チーム向けですか？

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

デモ: 自動テスト

自動アクセシビリティ テストのデモでは、Chrome の Lighthouseを使用します。 Lighthouse は、パフォーマンス、SEO、アクセシビリティなど、さまざまなタイプの監査を通じてウェブページの品質を向上させるために作成されたオープンソースの自動ツールです。

デモは、架空の組織である Medical Mysteries Club 向けに作成されたウェブサイトです。このサイトは、デモ用に意図的にアクセスできないように作られています。このアクセシビリティの問題の一部は表示されることがありますが、すべてが自動テストで検出されるわけではありません。

ステップ 1

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

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

ステップ 2

CodePen でデモを作成しました。 デバッグモードで表示して、 次のテストに進みます。デモのウェブページを囲む<iframe>が削除されるため、 一部のテストツールで問題が発生する可能性があります。

CodePen のデバッグモードの詳細

ステップ 3

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

ステップ 4

[Analyze page load] をクリックし、Lighthouse がテストを実行するまで待ちます。

テストが完了すると、Lighthouse はテスト対象のプロダクトのアクセシビリティを測定するスコアを表示します。 Lighthouse スコア は、検出された問題の数、問題のタイプ、ユーザーへの影響に基づいて計算されます。

Lighthouse レポートには、スコアだけでなく、検出された問題の詳細情報や、問題を解決する方法について詳しく説明するリソースへのリンクも含まれています。また、合格したテストや該当しないテスト、手動で確認する追加アイテムのリストも含まれています。

ステップ 5

検出された自動アクセシビリティの問題の例を 1 つずつ確認し、関連するスタイルとマークアップを修正します。

問題 1: ARIA ロール

最初の問題は、「ARIA [role] が指定されている要素には、特定の [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 px 未満）の色コントラストの要件は 4.5:1 ですが、大きいサイズのテキスト（18 pt / 24 px 以上または 14 pt / 18.5 px の太字）と重要なアイコンは 3:1 の要件を満たす必要があります。

ページタイトルは 24 px の大きいサイズのテキストであるため、ティール色のテキストは 3:1 の色コントラストの要件を満たす必要があります。ただし、ティール色のボタンは 16 px の太字の通常のサイズのテキストと見なされるため、4.5:1 の色コントラストの要件を満たす必要があります。

この場合、4.5:1 を満たすのに十分な濃さのティール色を見つけるか、ボタンのテキストサイズを 18.5 px の太字に増やして、ティール色の値を少し変更します。どちらの方法でも、デザインの美しさを維持できます。

白い背景のグレーのテキストはすべて、ページ上の 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>

修正しましょう。

このデモでは、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>

修正しましょう。

ウェブページの自然なタブ移動順序を中断する特別な理由がない限り、tabindex 属性に正の整数を指定する必要はありません。自然なタブ移動順序を維持するには、tabindex を 0 に変更するか、属性を完全に削除します。

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

ステップ 6

自動アクセシビリティの問題をすべて修正したら、新しいデバッグモード ページを開きます。Lighthouse のアクセシビリティ監査をもう一度実行します。スコアは初回よりも大幅に改善されているはずです。

これらの自動アクセシビリティの更新をすべて新しい CodePenに適用しました。

次のステップ

いい成績です。すでに多くのことを達成しましたが、まだ終わりではありません。 次に、 手動アクセシビリティ テスト モジュールで説明されているように、手動チェックに進みます。