アクセシブルなナビゲーションの理解

学習の目的

この単元を完了すると、次のことができるようになります。

• ユーザーにナビゲーションとアクションに関する情報を提供する戦略を挙げる。
• Web アプリケーション開発でのフォーカス管理の重要性について説明する。

はじめに

ユーザーは、アプリケーション内で自分がどこにいて、次にどのアクションを実行できるかを常に知っている必要があります。ユーザーにナビゲーションとアクションに関する情報を提供するには、次のことを実行します。

• 一貫性のあるナビゲーション要素を使用する。
• 見出しに適切なネストと順序を適用する。
• ランドマーク領域にラベルを付ける。
• 読む順序 (左から右へ記述される言語では左から右、上から下。右から左に記述される言語では右から左) に一致する論理的なタブ順序を使用する。
• すべてのインタラクティブ項目に表示フォーカスインジケーターを使用する。

コンテキストの変更

コンテキストの変更については、次の原則を考慮します。

1. コンテキストが変更されることをユーザーが知っている必要があります。ユーザーが変更を要求したのでない場合は、変更が行われることを説明します。
2. 変更が行われた後に、ユーザーが自分がページ上のどこにいるかを知る必要があります。

下の [Report (レポート)] と [Folders (フォルダー)] のナビゲーションの画像の [Show More (さらに表示)] ボタンについて考えてみましょう。 

ユーザーが [Show More (さらに表示)] をクリックした後に、表示される新しいコンテンツについてユーザーに知らせる方法がいくつかあります。

1. 新しいコンテンツの最初の項目にフォーカスを置く。これが最善の方法だという場合もありますが、ボタンの表示ラベルは「さらに表示」であって「別のコンテンツに移動」ではありません。
2. aria-live 領域を使用して、ページにナビゲーション項目が追加されたことをスクリーンリーダーに通知する。
3. ボタンのテキストを [Show Less (表示を減らす)] に変更する。これが最善のオプションです。このボタンの新しいテキストによって、ユーザーは「表示を減らすことができるのは、さらに多くの項目が表示されているからだ」と考えて、操作の成功を知ることができます。

この時点でスクリーンリーダーユーザーが抱く疑問は「新しく追加された項目はどこにあるのか?」ということです。ユーザーの前に新しいコンテンツを置けば、この疑問への答えを簡単に見つけることができます。

場合によっては、ユーザーのフォーカスを移動させることや aria-live 領域を使用することが適していることもあります。特定の状況でどの手法を使用するかを判断するには、ユーザーの期待を理解することが重要です。 

たとえば、モーダルを開く [編集] ボタンがあるとします。 

モーダルが開くと [編集] ボタンはモーダルによって隠されるため、ボタンにフォーカスを置いておくのは意味がありません。この場合は、フォーカスをモーダル自体に移します。原則として、ユーザーが明示的にアクションを実行しない限り、ユーザーのフォーカスを移動させるべきではありません。この例では、ユーザーが [編集] をクリックした後に、フォーカスを編集コンテキストに移動させるのが自然です。

また、ユーザーが何かの上でアクションを実行し、その何かが非表示になった場合は、フォーカスを論理的に移動させることが重要です。引き続きこの例で考えると、モーダルが閉じられたときにはユーザーのフォーカスをどこに移動すべきでしょうか? フォーカスをどこかに置く必要がありますが、ページの上部では芸がありません。この場合、理にかなっているのは最初にモーダルを開いた [編集] ボタンに戻ることです。 

Aria-live 領域を含むコンテキスト変更の詳細については、下記の「リソース」セクションを確認してください

フォーカスの管理

適切にフォーカスを管理することは、アクセシビリティ対応の Web アプリケーションを開発するための重要な要素です。一般に、ユーザーは Tab キーを押すことでページ内のフォーカスを前または下に移動させることができ、Shift+Tab を押すことで後ろまたは上に移動させることができます。これは、アンカー、ボタン、フォームコントロールなど、本来フォーカスを置くことができる HTML 要素に適用されます。

インタラクティブグリッド、メニュー、コンボボックス、タブセットなどの複雑なコンポーネントは矢印キーを使用して操作されます。これらの高度なインタラクションをプログラミングすることは、ARIA ロール属性を使用したときにユーザーに約束したことの一部です。

ユーザーのコンテキストが変更されたときにフォーカスをどのように管理するかについて考えてみましょう。ユーザーが次のことを行ったときに、フォーカスをどうすればよいでしょうか? 

• 新しいページに移動する。
• モーダルダイアログを開くまたは閉じる。
• レコードを削除する。
• ドラッグアンドドロップ操作を実行する。

これらの質問への答えやその他の詳細は、SLDS の『Global Focus Guideline (グローバルフォーカスガイドライン)』を参照してください。 

これらのガイドライン以外に、次のことについて考慮します。

1. 視覚障害などの障害を持つユーザーは、通常、アプリケーションを操作するときにページを前または下へと移動します。設計によってページに新しいコンテンツを追加する場合は、新しいコンテンツがその変更をトリガーした項目の次に追加されるようにします。たとえば、ページ上にインラインでフォームを追加するボタンをユーザーがクリックしたときには、DOM の順序でフォームがボタンの後になるようにします。ユーザーは、ページを前または下に進むとフォームがあると予測し、後ろにあるとは考えません。
2. コンポーネントを初期化するときにフォーカスを切り替えないようにします。ただし、コンポーネントの仕様に含まれる場合は例外です。たとえば、モーダルダイアログを初期化すると、そのモーダルダイアログにフォーカスが切り替えられます。
3. フォーカストラップを作成しないようにします。ユーザーがコンポーネントから出られるようにします。ただし、この場合もモーダルなどのようにコンポーネントの想定された動作である場合は例外です。
4. 無限読み込みは慎重に扱う。キーボードのみを使用しているユーザーがフィード、リスト、テーブル全体を読み込んで移動しなければ反対側のコンテンツにたどりつけないということがないようにします。たとえば、Salesforce の Chatter フィードにはすべて [フィードをスキップ] リンクがフィードの先頭にあります。

次は、アクセシビリティ対応コンポーネントの記述について見ていきましょう。 

リソース

Salesforce ヘルプ: Lightning Design System Global Focus Guidelines (Lightning Design System グローバルフォーカスガイドライン)

W3C の Techniques for WCAG 2.0: ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (ARIA role=alert 領域または Live 領域を使用したエラーの特定)