アクセシビリティ テスト

  • [アーティクル]

このトピックでは、Windows および Web アプリケーションのアクセシビリティ実装を確認するのに役立つさまざまなツールと手順について説明します。

ユーザー エクスペリエンスの成功

プログラムによるアクセスとキーボード アクセスは、アプリケーションでアクセシビリティをサポートするための重要な要件です。 Windows アプリケーション、支援技術 (AT) ツール、UI フレームワークのアクセシビリティをテストすることは、さまざまな障碍と制限 (視覚、学習、器用さ/モビリティ、言語/コミュニケーション障碍を含む) を持つユーザー、またはキーボードを使用するだけのユーザー エクスペリエンスを成功させるために不可欠です。

スクリーン リーダーやスクリーン キーボードなどのアクセシビリティの高いテクノロジ (AT) を適切にサポートしないと、視覚、学習、器用さ/モビリティ、言語/コミュニケーションの障碍や制限 (およびキーボードの使用のみを好むユーザー) を持つユーザーは、アプリケーションを使用するのが困難になる可能性があります。

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

Accessibility Insights

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

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

次の図は、メモ帳の [編集] メニュー要素の UI オートメーション プロパティを照会する Inspect ツールを示しています。

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

UI Accessibility Checker

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

UI Automation Verify

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

Accessible Event Watcher

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

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

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

キーボード アクセシビリティをテストするには、マウスを取り外す (タブレット デバイスを使っている場合は、スクリーン キーボードを使う) ことが最も良い方法です。 キーボード アクセシビリティのナビゲーションをテストするには、Tab キーを使います。 すべての対話型 UI 要素に Tab キーで移動できる必要があります。 コンポジット UI 要素については、方向キーを使って要素の部分間を移動できることを確認します。 たとえば、キーボードのキーを使って項目の一覧間を移動できる必要があります。 さらに、すべての対話型 UI 要素を、フォーカスがあるときにキーボードで実行できる (通常は Enter キーまたは Space キーを使う) ことを確認します。

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

色コントラスト ツールを使って、表示テキストのコントラスト比が適切であることを検証します。 ただし、非アクティブな UI 要素や、何も情報を伝えず、意味を変えることなく再配置できるロゴまたは装飾テキストは、例外です。 コントラスト比と例外について詳しくは、「アクセシビリティに対応したテキストの要件」をご覧ください。 コントラスト比をテストできるツールについては、Techniques for WCAG 2.0 の G18 (リソース セクション) をご覧ください。

注意

Techniques for WCAG 2.0 の G18 にリストされたツールのいくつかは、UWP アプリで対話的に使うことができません。 場合によっては、前景と背景の色の値を手動でツールに入力する必要があります。またアプリ UI の画面をキャプチャした後、そのキャプチャ画像に対してコントラスト比ツールを実行することが必要になる場合もあります。また、画像編集プログラムでソース ビットマップ ファイルを開いている間 (その画像がアプリによって読み込まれているときではなく) にツールを実行することが必要になる場合もあります。

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

ハイ コントラスト テーマがアクティブになっている状態でアプリを使って、すべての UI 要素が適切に表示されることを確認します。 すべてのテキストを読み取ることができ、すべての画像がクリアに表示されている必要があります。 XAML テーマ ディクショナリのリソースまたはコントロール テンプレートを調整し、コントロールが原因であるテーマの問題があれば修正します。 ハイ コントラストの重大な問題の原因がテーマまたはコントロール (イメージ ファイルなど) でない場合は、ハイ コントラスト テーマがアクティブになっているときに使う別のバージョンを用意します。

アプリの表示設定を確認する

ディスプレイの 1 インチあたりのドット数 (dpi) の値を調整するシステム ディスプレイ オプションを使い、DPI の値の変更に合わせてアプリの UI が正常に拡大縮小されることを確認します (一部のユーザーはアクセシビリティ対応オプションとして DPI の値を変更します。これは、[コンピューターの簡単操作] からだけでなく各種の表示プロパティでも設定できます)。問題が見つかった場合は、レイアウトとスケーリングのガイドライン に従い、さまざまなスケール ファクター用のリソースを追加します。

ナレーターでアプリの主要なシナリオを確認する

ナレーターを使ってアプリの画面の読み上げをテストします。

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

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

Windows 10 バージョン 1607 以降では、ナレーターで新しい開発者モードが導入されました。 ナレーターがオンになっている場合、"Control キー+ CapsLock キー + F12 キー" を押して、開発者モードをオンにします。 開発者モードを有効にすると、画面がマスクされ、アクセス可能なオブジェクトとナレーターにプログラムで公開されている関連のテキストのみが強調表示されます。 これにより、ナレーターに公開されている情報が適切な方法で視覚的に表示されます。

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

注意

4 つ以上のコンタクトをサポートするデバイスの場合、ナレーターは自動的にタッチ モードに移行します。 ナレーターは、マルチモニターや主要画面でのマルチタッチ デジタイザーをサポートしません。

  1. UI を操作し、レイアウトを確かめます。

    • 指 1 本のスワイプ ジェスチャを使って、UI を操作します。 項目間を移動するには左右のスワイプを使い、項目のカテゴリを変更するには上下のスワイプを使います。 カテゴリには、すべての項目、リンク、表、見出しなどがあります。 指 1 本のスワイプ ジェスチャによるナビゲーションは、CapsLock キーを押しながら方向キーを押すことによるナビゲーションとほぼ同じです。
    • タブ ジェスチャを使って、フォーカス可能な要素を移動します。 指 3 本を使った左右のスワイプは、キーボードで Tab キーを押したり、Shift キーを押しながら Tab キー を押したりするのと同じです。
    • 指 1 本を使って UI を空間的に調査します。 1 本の指を上下左右にドラッグして、ナレーターに指の下の項目を読み上げさせます。 代わりにマウスを使うこともできます。マウスでも 1 本指でのドラッグと同じヒット テスト ロジックを使っているためです。
    • 3 本指で上方向へスワイプすることで、ウィンドウ全体とウィンドウの全内容を読み上げます。 これは、CapsLock キーを押しながら W キーを押すのと同じです。

    重要な UI にアクセスできない場合、アクセシビリティに問題が存在する可能性があります。

  2. コントロールを操作して、プライマリ操作、セカンダリ操作、スクロール動作をテストします。

    プライマリ操作には、ボタンのアクティブ化、テキスト キャレットの配置、コントロールへのフォーカスの設定などが含まれます。 セカンダリ操作には、一覧項目の選択、オプションが複数あるボタンの展開などの操作が含まれます。

    • プライマリ操作のテスト: ダブルタップするか、指で押しながら別の指でタップします。
    • セカンダリ操作のテスト: トリプルタップするか、指で押しながら別の指でダブルタップします。
    • スクロール操作のテスト: 2 本指でスワイプし、目的の方向にスクロールします。

    一部のコントロールには、その他の操作も用意されています。 すべての一覧を表示するには、4 本指で 1 回タップします。

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

また、AccScope ツールを使ってアプリのナレーター アクセシビリティ シナリオをテストすることも検討してください。 「AccScope ツール トピック」では、ナレーター シナリオをテストするための AccScope の構成方法について説明しています。

アプリの UI オートメーションの表現を確認する

前述したいくつかの UI オートメーション テスト ツールでは、アプリがどのように見えるかを緩慢に考慮するのではなく、UI オートメーション要素の構造としてアプリを表現する方法についてアプリを確認する手段を提供しています。 この方法によって、UI オートメーション クライアント (主に支援技術) がアクセシビリティのシナリオでアプリを操作します。

AccScope ツールでは、視覚的な表現またはリストのいずれかとして UI オートメーション要素を表示できるので、アプリについて特に興味深いビューが得られます。 視覚エフェクトを使うと、アプリの UI の視覚的な外観に関連するように各部にドリルダウンできます。 すべてのロジックを UI に割り当てる前に、最初期の UI プロトタイプのアクセシビリティをテストすることさえ可能であり、アプリの視覚的な対話操作とアクセシビリティ シナリオのナビゲーションについて双方のバランスを確認できます。

テスト可能な側面の 1 つとして、表示したくない要素が UI オートメーション要素ビューに表示されるかどうかがあります。 ビューから除外したい要素、または反対に欠落する要素が見つかった場合に、アクセシビリティ ビューで XAML コントロールの表示を調整するために AutomationProperties.AccessibilityView XAML 添付プロパティを使用できます。 基本的なアクセシビリティ ビューを確認した後、コントロール ビューに公開される対話型の各部分にユーザーがアクセスできるかどうかについて、方向キーによって使用可能なタブ シーケンスまたは空間的なナビゲーションを再確認することもお勧めします。