アクセシビリティをテストする
学習の目的
この単元を完了すると、次のことができるようになります。
- 自動テストに加えて手動でアクセシビリティテストを行うことが重要な理由を説明する。
- MacOS でキーボードとフォーカス管理のテストを行う手順を要約する。
- VoiceOver を使用したスクリーンリーダーテストで確認すべき項目を特定する。
- アクセシビリティテスト計画に含めるべき要素を見極める。
- 効果的な手動アクセシビリティテストのための戦略を説明する。
手動テストの重要性を理解する
自動アクセシビリティテストでは多くの問題を検出できますが、コンテキストを考慮したり、より微妙なアクセシビリティの問題を特定したりすることはできません。また、ときには重大な問題を見逃すことさえあります。そのため、自動テストで検出できなかった障壁を見つけるために、手動テストを行うことが非常に重要です。手動テストでは、自動テストで見つけた問題を検証したり、偽陽性を特定したりすることもできます。
自動アクセシビリティテストとは異なり、手動テストではユーザージャーニー全体を評価し、障害のあるユーザーや支援技術を使用するユーザーの操作をシミュレーションします。たとえば、キーボードの手動テストでは、ユーザーがキーボードだけでソフトウェアを操作する様子を再現し、スクリーンリーダーの手動テストでは、視覚障害のあるユーザーがソフトウェアをどのように体験するかを再現します。
ここからは、キーボードとフォーカス管理のテストから始めて、手動アクセシビリティテストをさらに詳しく見ていきましょう。
キーボードとフォーカス管理のテストを実施する
キーボードとフォーカス管理のテストは、ユーザーが UI を直感的で想定どおりに操作できるかどうかを確認するうえで非常に有効です。
キーボードテストでは、次のような質問への答えを検証します。
-
さまざまな入力方法でコンテンツにアクセスできるか? 音声コマンド、タッチスクリーン、スイッチコントロールなど、さまざまな入力デバイスを使用してコンテンツを操作できる必要があります。マウスを合わせたときにだけ表示されるコンテンツは、タッチスクリーン、音声入力、キーボードのユーザーは利用できません。
-
フォーカスの順序は論理的か? フォーカスの順序とは、リンク、ボタン、入力項目などの操作可能な要素が、フォーカスを受け取る順番のことです。順序が不自然だと、ナビゲーションが難しくなります。
-
ユーザーは効率的かつ一貫してコンテンツを操作できるか? 操作で使用するキーやコマンドなどが、ユーザーの予想に反して不規則に変化すると、特に支援技術を使用しているユーザーにとっては使いづらくなります。
-
すべてのユーザーがこのコンテンツを操作できるか? 身体の動作、細かな手の動き、視覚に困難を抱える方など、さまざまな障害を持つユーザーを考慮しましょう。
Mac でテストを行う際は、システム設定の [Keyboard (キーボード)] でフルキーボードアクセスを有効にする必要があります。次の手順を実行します。
MacOS でキーボードナビゲーションを有効にする
-
[System Preferences (システム設定)] の [Keyboard (キーボード)] 設定を開きます。
-
[Shortcuts (ショートカット)] タブを選択します。
- [Full Keyboard Access (フルキーボードアクセス)] で [All controls (すべてのコントロール)] を選択します。
![MacOS の [Keyboard (キーボード)] 設定画面の [Shortcuts (ショートカット)] タブで、[Full Keyboard Access (フルキーボードアクセス)] の部分が強調され、[All controls (すべてのコントロール)] が選択されている。](https://res.cloudinary.com/hy4kyit2a/f_auto,fl_lossy,q_70/learn/modules/testing-for-web-accessibility/test-for-accessibility-1/images/ja-JP/42bcf3b9cf41fc8e04ce956b08b1bbe4_kix.7wdr7u3po8tu.png)
Safari でキーボードアクセスを有効にする
- Safari の [Preferences (環境設定)] を開きます。
-
[Advanced (詳細)] タブを選択します。
-
[Accessibility (アクセシビリティ)] で [Press Tab to highlight each item on a webpage (Tab キーで Web ページ上の各項目を強調表示)] にチェックを入れます。
以下のキーを使用して Web ページを操作します。
キー: |
機能: |
|---|---|
Tab および Shift+Tab |
リンク、入力項目、その他の操作可能な項目間を移動します。Tab キーを押すと前方、Shift+Tab キーを押すと後方に移動します。ページ上には Tab キーで移動できない項目もありますが、それらはユーザーが操作できない項目なので心配はいりません。 |
Ctrl+Tab |
フレーム間を移動します。 |
Enter |
リンク先に移動します。 |
Enter および Space |
ボタンの操作を実行します。 |
Space |
チェックボックスのオン/オフを切り替えたり、選択メニューを開いたりします。 |
上矢印キーおよび下矢印キー |
メニュー、選択リスト、オートコンプリートドロップダウンメニューの中を上下に移動します。 |
左矢印キーおよび右矢印キー |
タブセットやカルーセルのタブ間を移動します。 |
Esc |
メニュー、モーダル、パネルを閉じます。 |
すべての対話型要素にアクセスしてアクションを実行できることを確認する
コンボボックス、メニュー、データグリッド、非モーダルおよびモーダルダイアログ、タブセットなど、複数の対話型要素を含む複雑なコンポーネントには、基本的な操作以外にも独特のキーボード操作が求められることがあります。これらのキーボード操作は、World Wide Web Consortium (W3C) の ARIA オーサリングプラクティスで定義されている「期待される操作」に準拠しています。
Salesforce は、これらの期待に基づいてキーボードガイドラインを作成しています。このガイドラインは、Lightning および Lightning Design System の React コンポーネントライブラリで使用されています。これらのコンポーネントを構築してテストする際に役立つリソースを Lightning Design System 2 のサイトで公開しています。
-
Keyboard Interaction Accessibility Guidelines (キーボード操作のアクセシビリティガイドライン): 手動でのキーボードテストのチェックリスト
-
Global Focus Accessibility Guidelines (グローバルフォーカスアクセシビリティガイドライン): フォーカス管理で期待される動作のヒント
-
Accessibility (アクセシビリティ): 一般的なウィジェットやパターンの HTML と操作の仕様
キーボード操作をテストする
キーボード操作のテストでは次の点を確認します。
-
Tab キーによる移動の順序が論理的であること。キーボードの Tab キーを使用してアプリケーション内を移動します。デフォルトの移動順序が論理的で自然に感じられる必要があります。
-
キーボードフォーカスが視認できること。キーボードを使用してページ内を移動し、フォーカスされている要素が視覚的なインジケーターによって判別できることことを確認します。
-
操作可能な項目がフォーカスを受け取ること。キーボードを使用してページ内を移動します。すべてのボタン、リンク、フォーム項目、タブ、その他の対話型項目がキーボードフォーカスを受け取れることを確認します。クリックして操作を実行できたり、マウスオーバーで情報が表示されたりする項目は、キーボード操作でもフォーカスを受け取れるようにする必要があります。
-
対話型要素に移動できること。メニュー、モーダル、ドラッグ＆ドロップ要素、タブセット、パネル、オートコンプリートドロップダウンなど、すべての対話型要素にキーボードでアクセスできることを確認します。キーボードで項目を選択して有効化できることを確認します。
-
モーダルダイアログを操作できること。キーボードでモーダルダイアログを開き、ダイアログのすべての対話型要素に移動して操作します。現在のモーダルウィンドウの要素のみが操作可能で、背後のページは操作できないことを確認してください。モーダルが開いている間は、フォーカスがモーダルに閉じ込められている必要があります。モーダルを閉じたときに、フォーカスがページ上の正しい場所に戻ることを確認してください。
キーボードとスクリーンリーダーのテストは同じではありません。スクリーンリーダーのテストを実施する前にキーボードのテストを行うと、スクリーンリーダーでは見落とされる可能性のある問題を特定できます。
スクリーンリーダーによるテストを実施する
MacOS と Windows の両方でスクリーンリーダーを使ってテストすることを推奨します。MacOS には VoiceOver という内蔵のスクリーンリーダーがあり、選択した要素の表示ラベルや代替テキストを読み上げます。スクリーンリーダーのテストでは、代替テキストが正確かどうかを確認し、必要に応じて修正します。
以下は、MacOS の VoiceOver を使用して実施できる簡単な確認です。
- Cmd+F5 で VoiceOver のオン/オフを切り替えます。
- Cmd+u で Web Rotor を開きます。
- Web Rotor を使用して以下を確認します。
- リンクやボタンに簡潔でわかりやすい表示ラベルが付いている
- 見出しが正しい順序で配置されている
- ページに適切なランドマークがある
- リンクやボタンに簡潔でわかりやすい表示ラベルが付いている
- UI の要素間を Tab キーで移動しながら以下を確認します。
- 編集可能な項目では、表示ラベル、入力種別、そして「編集」という言葉が読み上げられる
- タブセットでは、選択されているタブが通知され、矢印キーでタブ間を移動できる
- スペースバーでチェックボックスの状態を切り替えるとその状態が読み上げられる
- 編集可能な項目では、表示ラベル、入力種別、そして「編集」という言葉が読み上げられる
スクリーンリーダーを使用して UI 要素間を Tab キーで移動したときに、一部の要素にアクセスできなくても問題はありません。スクリーンリーダーでは、専用のキーボードショートカットを使ってページ上の要素間を移動しますが、その対象には操作できない要素も含まれます。一方で、Tab キーは操作可能な要素間のみを移動するため、すべての要素にアクセスできる必要はなく、むしろそうすべきではありません。VoiceOver では、Control＋Option＋左矢印キーで逆方向に、Control＋Option＋右矢印キーで順方向に、ページのコンテンツを直線的に読み進めることができます。
Windows では NVDA を使用することをお勧めします。
複数のスクリーンリーダーでアクセシビリティテストを実施してください。VoiceOver のみでテストすると、JAWS や NVDA など、別のスクリーンリーダーでは検出できる問題を見落としてしまう可能性があります。
スクリーンリーダーの使用に慣れていない状態でテストを実施すると、操作ミスが起こりがちです。スクリーンリーダーの使用方法の詳細については、リソースセクションにある A11ycasts の動画を参照してください。
アクセシビリティテスト計画を作成する
アクセシビリティをテスト計画の一部として組み込み、コンポーネント仕様、受け入れ条件、ユーザーストーリーに含めましょう。
例: アプリケーションランチャー
アプリケーションランチャーを開くには、
を選択します。アプリケーションランチャーでは、アプリケーションの検索、起動、説明の閲覧、並べ替えができます。
![[All Apps (すべてのアプリケーション)] セクションが展開された状態のアプリケーションランチャー。](https://res.cloudinary.com/hy4kyit2a/f_auto,fl_lossy,q_70/learn/modules/testing-for-web-accessibility/test-for-accessibility-1/images/ja-JP/ec448d85d40f314168dbc448743c95fd_kix.vtn4bqpgizdp.png)
アプリケーションの並べ替えを検証するために作成できるテストケース
以下は、アプリケーションランチャーに関連するさまざまなユースケースに対応したテスト計画の例です。
「種別」欄にある「機能性」は、製品やシステムの機能が想定どおりに動作するかどうかを検証することを意味します。「アフォーダンス」は、オブジェクトの見た目や挙動から、その使い方が直感的に伝わるようになっているかどうかを検証することを意味します。
種別 |
マウス |
キーボード |
スクリーンリーダー |
|---|---|---|---|
機能性 |
タイルをクリックするとアプリケーションが開く |
タイルで Enter キーを押すとアプリケーションが開く |
キーボードによる操作がすべて正常に行える |
アフォーダンス |
マウスを合わせるとタイルに移動カーソルが表示される |
タイルの移動ボタンに明確な視覚的フォーカスインジケーターが表示される |
ユーザーに可能な操作が通知される |
機能性 |
タイルをクリックして長押しするとドラッグが開始される |
Space キーでドラッグモードが開始される |
ドラッグモードに入ると、掴んだ状態であること、位置、操作方法が読み上げられる |
アフォーダンス |
ドラッグモードが視覚的に明確に示される (タイルが斜めで青い枠が表示される) |
ドラッグモードが視覚的に明確に示される (タイルが斜めで青い枠が表示される) |
|
機能性 |
ドラッグ中にマウスを動かすとタイルが移動する |
矢印キーを押すとアプリケーションがリスト内で前後の位置に移動する |
|
アフォーダンス |
アプリケーション位置のプレビューが表示される |
アプリケーション位置のプレビューが表示される |
位置が変わると、アプリケーションの位置が読み上げられる |
機能性 |
マウスを放すとドラッグが終了する |
Enter キーを押すとドラッグモードが終了する |
ドラッグモードを終了すると、新しい位置と移動完了の状態が読み上げられる |
他にどのようなテストケースを追加できるでしょうか? それらはどのようにテストすればよいでしょう? スクリーンリーダーの属性やキーボードの操作については、自動テストを作成できる場合もありますが、ユーザーエクスペリエンスがシームレスであることを確認するためには、手動テストも行うことが重要です。
手動テスト戦略を活用する
ここまでの内容を活かす準備はできましたか？ここでは、効果的なアクセシビリティの手動テストを行うための戦略をご紹介します。
テスト計画を作成する
次のような内容を含めるとよいでしょう。
- コンポーネントテストでの主要な視覚状態に対して $A.test.assertAccessible をコールする
- キーボード操作の流れを手動で確認する
- ユースケース特有の要素を考慮する
早期かつ頻繁にテストする
ユーザーインターフェースを構築する段階から、以下のような取り組みを行いましょう。
- 手動テストを実施する
- テストの自動化を有効にする
- カスタムテストを活用してアクセシビリティを確保する機会を探る
バグを記録して修正する
Salesforce では、影響を受けるユーザーの人数にかかわらず、アクセシビリティに関するバグに優先的に対応しています。こうしたバグは、該当ユーザーにとっては作業の妨げとなる重大な障壁になり得るからです。組織ごとにバグの優先順位は異なるかもしれませんが、未解決のアクセシビリティ問題は最小限に抑えるべきだという姿勢を貫きましょう。
自動テストと手動テストの両方を実施してアクセシビリティの障壁を取り除くことで、誰もが参加して楽しめる、真にインクルーシブなデジタルエクスペリエンスを提供できるのです。
リソース
- Web ページ: ARIA Authoring Practices (ARIA オーサリングプラクティス)
- Salesforce サイト: Lightning Design System 2: Keyboard Interaction Accessibility Guidelines (キーボード操作のアクセシビリティガイドライン)
- Salesforce サイト: Lightning Design System 2: Global Focus Accessibility Guidelines (グローバルフォーカスアクセシビリティガイドライン)
- Salesforce サイト: Lightning Design System 2: Accessibility (アクセシビリティ)
- Web サイト: NV Access (NV アクセス)
- Web サイト: Freedom Scientific: JAWS
- 動画: A11ycasts: How I do an accessibility check (アクセシビリティチェックを実施する方法)—A11ycasts #11
- 動画: A11ycasts: Screen Reader Basics: VoiceOver (スクリーンリーダーの基本: VoiceOver)—A11ycasts #07
- 動画: A11ycasts: Screen Reader Basics: NVDA (スクリーンリーダーの基本: NVDA)—A11ycasts #09