次の方法で共有

アクセシビリティ テスト

このトピックでは、Windows アプリのアクセシビリティを確認するためのさまざまなツールと手順について説明します。

これは、開発ライフサイクル全体にわたってアクセシビリティと自動テストに優先順位を付けるチームを対象としています。 最も効果的なアプローチは、CI で実行される自動化と、リスクの高いシナリオに対する重点的な手動支援技術テストを組み合わせたものです。

成功したユーザー エクスペリエンス

アクセシビリティのためには、プログラムとキーボードのアクセスが不可欠です。 Windows アプリ、支援技術 (AT) ツール、UI フレームワークをテストして、視覚障碍、学習、器用さ/モビリティ、言語/コミュニケーション障碍のあるユーザー、およびキーボード ナビゲーションを好むユーザーがエクスペリエンスを成功させるかどうかを確認します。

スクリーン リーダーやスクリーン キーボードなどの支援技術 (AT) を適切にサポートしないと、多くのユーザーがアプリを使いづらかったり不可能にしたりする可能性があります。

アクセシビリティのテスト用ツール

このセクションのツールは、リリース前だけでなく、開発全体で使用してください。 アクセシビリティ分析情報から始めて、影響の大きい迅速なチェックを行い、レガシ SDK ツールを使用して UI オートメーションのプロパティ、イベント、またはコントロール パターンをより詳細に検査します。

アクセシビリティ インサイト

Accessibility Insights は、 開発者が Web サイトと Windows アプリケーションの両方でアクセシビリティの問題を見つけて修正するのに役立ちます。

  • Windows 用の Accessibility Insights は、 開発者が Windows アプリのアクセシビリティの問題を見つけて修正するのに役立ちます。 このツールでは、次の 3 つの主要なシナリオがサポートされています。
    • Live Inspect を使用すると、開発者は、要素にマウス ポインターを合わせたり、キーボード フォーカスを設定したりするだけで、アプリ内の要素に適切な UI オートメーション プロパティがあることを確認できます。
    • FastPass - 開発者が一般的で影響の大きいアクセシビリティの問題を 5 分以内に特定するのに役立つ、軽量の 2 段階のプロセスです。
    • トラブルシューティング を使用すると、特定のアクセシビリティの問題を診断して修正できます。
  • Accessibility Insights for Web は、開発者が Web アプリやサイトのアクセシビリティの問題を見つけて修正するのに役立つ、Chrome および Microsoft Edge Insider 向けの拡張機能です。 次の 2 つの主要なシナリオがサポートされています。
    • FastPass - 開発者が一般的で影響の大きいアクセシビリティの問題を 5 分以内に特定するのに役立つ、軽量の 2 段階のプロセスです。
    • 評価 - Web サイトが 100% アクセシビリティ標準とガイドラインに準拠していることを誰でも確認できます。 Accessibility Insights では、UI オートメーションの要素、プロパティ、コントロール パターン、およびイベントを確認することもできます (次のセクションで説明する Inspect および AccEvent レガシ ツールと同様)。

レガシ テスト ツール

注

ここで説明するツールは引き続き Windows SDK で利用できますが、 Accessibility Insights に移行することを強くお勧めします。

Windows ソフトウェア開発キット (SDK) には、 AccScope、 Inspect 、 UI アクセシビリティ チェッカーなど、いくつかのアクセシビリティ テスト ツールが含まれています。

Microsoft Visual Studio コマンド プロンプトから、または Windows SDK が開発用コンピューターにインストールされている場所の bin フォルダーに移動して、次のアクセシビリティ テスト ツールを起動できます。

AccScope

AccScope を使用すると、初期の設計および開発フェーズでアプリケーションのアクセシビリティを視覚的に評価できます。 AccScope は、ナレーターのアクセシビリティ シナリオをテストすることを目的としており、アプリから提供される UI オートメーション情報を使用して、アクセシビリティを向上できる場所を示します。

Inspect

Inspect を使用すると、任意の UI 要素を選択し、そのアクセシビリティ データを表示できます。 Microsoft UI オートメーションのプロパティとコントロール パターンを表示し、UI オートメーション ツリーでオートメーション要素のナビゲーション構造をテストできます。 これは、共通コントロールを拡張するとき、またはカスタム コントロールを作成するときに、プロパティとコントロール パターンが正しく設定されるようにする場合に特に便利です。

UI の開発時に Inspect を使用して、UI オートメーションでアクセシビリティ属性がどのように公開されるかを確認します。 場合によっては、既定の XAML コントロール用に既に実装されている UI オートメーションのサポートから属性が取得されます。 その他の場合、属性は、 AutomationProperties 添付プロパティとして XAML マークアップで設定した特定の値から取得されます。

次の図は、メモ帳の [編集] メニュー要素の UI オートメーション プロパティに対してクエリを実行する検査ツールを示しています。

検査ツールのスクリーン ショット。

UI アクセシビリティ チェック

UI アクセシビリティ チェック (AccChecker) は、実行時にアクセシビリティの潜在的な問題を検出するのに役立ちます。 AccChecker には、UI オートメーション、Microsoft Active Accessibility、および Accessible Rich Internet Applications (ARIA) の検証チェックが含まれています。 名前の欠落、ツリーの問題などのエラーの静的なチェックを提供できます。 プログラムによるアクセスの検証に役立ち、アクセシビリティ テストを自動化するための高度な機能が含まれています。 AccChecker は、UI モードまたはコマンド ライン モードで実行できます。 UI モード ツールを実行するには、Windows SDK bin フォルダーの AccChecker フォルダーを開き、acccheckui.exe実行して、[ヘルプ] メニューをクリックします。

UI オートメーションの検証

UI オートメーション検証 (UIA 検証) は、コントロールまたはアプリケーションでの UI オートメーション実装の手動および自動テストのフレームワークです (結果をログに記録できます)。 UIA Verify は、テスト コードに統合し、UI オートメーション シナリオの定期的な自動テストまたはスポット チェックを実施でき、確立された機能を持つアプリケーションに対する変更に新しい問題や回帰がないことを確認するのに役立ちます。 UIA 検証は、Windows SDK bin フォルダーの UIAVerify サブフォルダーにあります。

アクセシビリティ対応の Event Watcher

Accessible Event Watcher (AccEvent) は、UI の変更が発生したときにアプリの UI 要素が適切な UI オートメーションおよび Microsoft Active Accessibility イベントを発生するかどうかをテストします。 UI の変更は、フォーカスが変更したときや、UI 要素の呼び出し、選択、状態またはプロパティの変更が行われたときに発生する可能性があります。 AccEvent は通常、問題をデバッグし、カスタム コントロールと拡張コントロールが正しく動作していることを検証するために使用されます。

アクセシビリティ テスト手順

オートメーション優先のアクセシビリティ ワークフローを構築する

単体テスト、統合テスト、信頼性テストと同じ方法で、アクセシビリティ テストをリリース ゲートとして使用します。

  1. コア ユーザー フローと制御動作に対するベースライン アクセシビリティの期待値を定義します。
  2. プル要求と CI で実行される自動チェックを追加して、回帰をすばやく検出します。
  3. 重大なアクセシビリティの問題が検出されたときにビルドを中止し、所有者と有効期限を設定して除外を追跡します。
  4. 人間の判断が必要なシナリオの手動スクリーン リーダーとキーボード検証をスケジュールします。
  5. テンプレート、制御ロジック、またはナビゲーション動作が変更されるたびに、影響を受けるシナリオを再テストします。

キーボードのアクセシビリティをテストする

ポインター入力なしでキーボードの動作を検証します。 すべての対話型要素の完全で論理的な Tab シーケンス、複合コントロール内の予期される方向キー ナビゲーション、およびフォーカス可能なすべてのコマンド サーフェイスに対する操作 (通常は Enter キーまたは Space キー) の信頼性の高いキーボード呼び出しを確認します。

表示されるテキストのコントラスト比を確認する

カラー コントラスト ツールを使用して、表示されるテキストのコントラスト比が許容されることを確認します。 例外には、非アクティブな UI 要素や、情報を伝達せず、意味を変更せずに再配置できるロゴや装飾テキストが含まれます。 コントラスト比と例外の詳細については、 アクセシビリティ対応テキストの要件 を参照してください。 コントラスト比をテストできるツールについては、 WCAG 2.0 G18 の手法 (リソース セクション) を参照してください。

注

WCAG 2.0 G18 の手法に記載されている一部のツールは、Windows アプリでは対話形式で使用できません。 場合によっては、ツールで前景色と背景色の値を手動で入力し、アプリ UI の画面キャプチャを行い、画面キャプチャ イメージに対してコントラスト比ツールを実行するか、そのイメージがアプリによって読み込まれている間ではなく、イメージ編集プログラムでソース ビットマップ ファイルを開いている間にツールを実行することが必要になる場合があります。

ハイ コントラストでアプリを確認する

ハイ コントラスト テーマがアクティブな状態でアプリを使用して、すべての UI 要素が正しく表示されることを確認します。 すべてのテキストを読みやすくし、すべての画像をクリアする必要があります。 XAML テーマ ディクショナリ リソースまたはコントロール テンプレートを調整して、コントロールから発生するテーマの問題を修正します。 目立つハイ コントラストの問題がテーマやコントロール (画像ファイルなど) から発生しない場合は、ハイ コントラスト テーマがアクティブな場合に使用する個別のバージョンを提供します。

表示設定を使用してアプリを確認する

アクセシビリティ主導のスケーリング シナリオなど、システム DPI の変更全体にわたる UI スケーリングを検証します。 レイアウトまたはレンダリングの回帰が表示される場合は、 レイアウトスケーリングのガイドライン を適用し、影響を受けるスケールファクターのリソースを追加します。

ナレーターを使用してアプリのメイン シナリオを確認する

ナレーターを使用して、アプリの画面読み取りエクスペリエンスをテストします。

マウスとキーボードでナレーターを使用してアプリをテストするには、次の手順に従います。

  1. Windows ロゴ キーを押しながら Ctrl + Enter キーを押してナレーターを起動します。 Windows 10 バージョン 1607 より前のバージョンでは、 Windows ロゴ キー + Enter キー を使用してナレーターを起動します。
  2. Tab キー、方向キー、CapsLock + 方向キーを使用して、キーボードを使用してアプリ内を移動します。
  3. アプリ内を移動するときに、ナレーターが UI の要素を読み上げ、次のことを確認します。
    • 各コントロールについて、ナレーターがすべての表示されているコンテンツを読み取っていることを確認します。 また、ナレーターが各コントロールの名前、該当する状態 (オン、選択など) とコントロールの種類 (ボタン、チェック ボックス、リスト アイテムなど) を読み取るようにします。
    • 要素が対話型の場合は、ナレーターを使用して Caps Lock + Enter キーを押してアクションを呼び出すことができることを確認します。
    • 各テーブルについて、ナレーターがテーブル名、テーブルの説明 (使用可能な場合)、行見出しと列見出しを正しく読み取っていることを確認します。
  4. Caps Lock + Shift + Enter キーを押してアプリを検索し、すべてのコントロールが検索リストに表示されていること、およびコントロール名がローカライズされ、読み取り可能であることを確認します。
  5. モニターをオフにして、キーボードとナレーターのみを使用して、アプリの主要なシナリオを実行します。 ナレーターのコマンドとショートカットの完全な一覧を取得するには、 Caps Lock + F1 キーを押します。

ナレーターの実行中に、 Control + CapsLock + F12 で開発者モードを有効にします。 開発者モードでは、画面がマスクされ、プログラムによってアクセス可能なオブジェクトとテキストのみが表示され、ナレーターが表示する出力を簡単に検証できます。

ナレーターのタッチ モードを使用してアプリをテストするには、次の手順に従います。

注

ナレーターは、4 つ以上の連絡先をサポートするデバイスで自動的にタッチ モードに切り替わります。 ナレーターは、プライマリ画面上のマルチモニター シナリオやマルチタッチ デジタイザーをサポートしていません。

  1. UI を理解し、レイアウトを調べる。

    • 1 本指のスワイプ ジェスチャを使用して UI 内を移動します。 左または右のスワイプを使用して項目間を移動し、上下のスワイプで移動する項目のカテゴリを変更します。 カテゴリには、すべてのアイテム、リンク、テーブル、ヘッダーなどが含まれます。 1 本指のスワイプ ジェスチャを使用したナビゲーションは、 CapsLock + Arrow を使用したナビゲーションと似ています。
    • タブ ジェスチャを使用して、フォーカス可能な要素間を移動します。 右または左への 3 本指のスワイプは、キーボードの Tab キーと Shift キーを押しながら Tab キーを押しながら移動する場合と同じです。
    • 1 本の指で UI を空間調査します。 ナレーターが指の下の項目を読み上げるには、1 本の指を上下または左右にドラッグします。 1 本の指をドラッグする場合と同じヒット テスト ロジックを使用するため、代わりにマウスを使用できます。
    • 3 本指で上にスワイプして、ウィンドウ全体とそのすべての内容を読み取ります。 これは Caps Lock + W の使用と同じです。

    アクセスできない重要な UI がある場合は、アクセシビリティの問題が発生している可能性があります。

  2. コントロールと対話して、そのプライマリ アクションとセカンダリ アクション、およびスクロール動作をテストします。

    主なアクションには、ボタンのアクティブ化、テキスト キャレットの配置、コントロールへのフォーカスの設定などがあります。 セカンダリ アクションには、リスト アイテムの選択や、複数のオプションを提供するボタンの展開などのアクションが含まれます。

    • 主なアクションをテストするには:ダブルタップするか、指で押して別の指でタップします。
    • セカンダリ アクションをテストするには:3 回タップするか、1 本の指で押し、別の指でダブルタップします。
    • スクロール動作をテストするには:2 本指でスワイプして目的の方向にスクロールします。

    一部のコントロールでは、追加のアクションが提供されます。 完全なリストを表示するには、4 本指で 1 回タップします。

    コントロールがマウスまたはキーボードに応答しても、プライマリまたはセカンダリのタッチ操作に応答しない場合、コントロールは追加の UI オートメーション コントロール パターンを実装する必要がある場合があります。

また、 AccScope ツールを使用して、アプリでナレーターのアクセシビリティ シナリオをテストすることも検討する必要があります。 AccScope ツールのトピックでは、ナレーターのシナリオをテストするように AccScope を構成する方法について説明します。

アプリの UI オートメーション表現を調べる

UI オートメーション検査ツールを使用して、支援技術によって使用される UIA 要素ツリーとしてアプリを表示します。

AccScope は、ツリーをリストまたはビジュアル オーバーレイとして表示し、オートメーション構造をレンダリングされた UI と関連付けることができるので便利です。 これは、完全な対話ロジックが実装される前の初期の UI プロトタイプでも有効です。

各アクセシビリティ ビューに目的の要素のみが表示され、必要な要素が存在することを確認します。 AutomationProperties.AccessibilityView を使用して省略や露出超過を修正し、コントロール ビューのすべての対話型要素のタブ オーダーと方向キー ナビゲーションを再検証します。

  • Last updated on