キーボードのアクセシビリティを考慮してアプリを設計するための 5 つのステップ

「平均的な」ユーザーについて考えるとき、コンピューターでマウスやトラックパッドを使用しているユーザーを想像する傾向があります。 しかし、彼らの好みまたは唯一のオプションがキーボードを使用することだったとしたらどうでしょうか? キーボードのアクセシビリティを考慮してアプリを設計することを検討したことがありますか?

コンピューターを使用するためにマウスやトラックパッドを操作したくない、または操作できない理由はたくさんあります。 彼らは、器用さや筋肉の制御を制限する永続的、慢性的、または一時的な状態にある可能性があり、手首や手が過敏になったり、画面上のマウスカーソルをたどることが困難になったりします. また、ワークフローを合理化するための近道を探している「パワー ユーザー」である可能性もあります。 これらのケースのいずれにおいても、キーボードは、テクノロジと対話する個人の好みまたは必要な手段である可能性があります。

この記事では、キーボード アクセシビリティのガイドラインと、キーボードでアクセスできるようにアプリを設計する際に留意すべき 5 つの手順について説明します。

キーボードのアクセシビリティはどのように機能しますか?

アプリがキーボードでアクセスできる場合、それはユーザーがキーボードのみを使用してコントロール要素を操作するオプションがあることを意味します。 コントロール要素は、ボタン、リンク、フォーム入力、ビデオ、その他のインタラクティブなコンテンツなど、ページ上のインタラクティブなコンポーネントです。

キーボード ナビゲーションの基本

キーボード ナビゲーションに使用される基本的なキーを次に示します。

• 次のコントロール要素への移動: Tab (または、関連するラジオ ボタンと選択オプションの右矢印キーまたは下矢印キー)
• 前のコントロール要素への移動: Shift + Tab (または、関連するラジオ ボタンと選択オプションの左または上矢印キー)
• コントロール要素をクリック: Enter および/またはスペースバー
• 関連するラジオ ボタン間を移動するか、オプションを選択する:矢印キー

フォーカス順

コントロール要素がキーボード イベントに応答できる順序は、フォーカス順序と呼ばれます。 要素がフォーカスされている場合、特定のキーボード コントロールを使用して操作できます。 要素がフォーカスを失うと、ぼやけます。 ブラウザはデフォルトのフォーカス状態をレンダリングして、現在どの要素がフォーカスされているかをユーザーが追跡できるようにします。

こちらもお勧め:ユニバーサル デザイン: サイトやアプリをよりアクセシブルにするための 11 の実用的なヒント。

キーボードのアクセシビリティと Web コンテンツ アクセシビリティ ガイドライン (WCAG)

Web コンテンツ アクセシビリティ ガイドライン (WCAG) では、レベル A、レベル AA、およびレベル AAA の 3 つのコンプライアンス レベルを概説しています。これらは、世界中の地域または国の Web アクセシビリティ法の標準として採用されています。

キーボードのアクセシビリティは、レベル A 準拠の成功基準の 1 つです。 レベル A の基準は、すべての Web コンテンツに必須の機能を示しています。 また、実装が最も簡単であると考えられています。

「キーボードのアクセシビリティも、注意しないと簡単に間違えてしまいます。」

とはいえ、注意しないと、キーボードのアクセシビリティも簡単に間違えてしまいます。 Web で見られる一般的なキーボードのアクセシビリティの問題の例を次に示します。

• 目に見えないフォーカス状態
• フォーカス順序が正しくありません
• フォーカスを受け取れないインタラクティブな要素
• キーボードの操作を認識しない複雑なコンポーネント

幸いなことに、キーボードのユーザーを念頭に置いて、独自のアプリでこれらの間違いを避けるために使用できる多くのテクニックがあります.

キーボードでアクセス可能なアプリを構築するための 5 つのステップ

1. 直感的なインタラクションをデザインする

動作をカスタマイズせずに単純なコントロール要素をレンダリングする場合、通常、組み込みのキーボード アクセシビリティ機能を活用できます。 ただし、ボタン、リンク、または入力に関連付けられた標準的なキーボードの動作がわからない場合、キーボード ユーザーに混乱を招く体験をうっかり作成してしまう可能性があります。

「ボタン、リンク、または入力に関連付けられた標準的なキーボードの動作がわからない場合、キーボード ユーザーに混乱を招くエクスペリエンスをうっかり作成してしまう可能性があります。」

たとえば、開発者は CSS を使用してネイティブの HTML ラジオ ボタンを非表示にし、より様式化されたビジュアルを優先することがあります。 入力がバックグラウンドでラジオ ボタンであることは明らかではないため、キーボード ユーザーは、関連するオプション間でフォーカスを移動するために、Tab キーではなく矢印キーを使用する必要があることに気付かない場合があります。

この問題を回避するには、少なくともネイティブ HTML 要素に似たものを表示して、キーボードを使用して操作したい、または操作する必要がある人に視覚的な合図を提供する必要があります。

2. マウスでできることはすべてキーボードでできるようにアプリを作成する

キーボード アクセシビリティ機能が組み込まれていない要素に注意してください。 レイアウト要素、リスト、テーブル、ヘッダー、段落、および非セマンティック HTML タグは、既定ではキーボード ショートカットをサポートしていません。 それでも、タブ、ドラッグ アンド ドロップ リスト、モーダルなど、より複雑なコンポーネントを構築するために頻繁に使用されます。

JavaScript を使用すると、コントロール以外の要素をマウスのクリックやジェスチャーに応答させるイベント リスナーを追加できます。 たとえば、React では、 onClick prop を使用して、リスト項目要素にインタラクティブ性を追加できます。

非コントロール要素にインタラクティブ性を追加するときはいつでも、それらのtabIndex属性を0に設定する必要があります。 これにより、Tab キーが押されたときに要素が正しいフォーカス順序でフォーカスを受けることができます。 また、キープレスまたはキーダウン イベント ハンドラーを実装して、Enter キーおよび/またはスペースバーを介して「クリック」を登録する必要があります (リンクは両方を使用してクリックできますが、ボタンは Enter キーのみをサポートします)。

代わりにアンカー タグやボタン要素などのコントロールを使用することで、この余分な作業の一部を回避できます。 CSS を使用して、デフォルトのリンクとボタンのスタイルをオーバーライドし、インタラクティブな要素をその非インタラクティブな親の幅全体に広げて、ターゲット領域を最大化することができます。

非ネイティブ機能にコントロール要素を使用するかどうかにかかわらず、矢印キー (タブ コンポーネント内のタブ間を移動するため) または Escape キー (オーバーレイを閉じるため) のイベント リスナーを追加して、コンポーネントを 100 にする必要がある場合があります。パーセント キーボード アクセス可能。

より複雑なコンポーネントに非標準のキーボード動作を実装する場合は、ユーザーがコンポーネントを操作するために使用できるキーボード コントロールを説明する目に見える指示を提供すると役立ちます。

3.デフォルトのフォーカス順序をオーバーライドするときに余分な作業を行う

フォーカス順序は、キーボードのアクセシビリティに密接に関連するもう 1 つの WCAG 要件です。 レベル A の基準を満たすには、フォーカスの順序が、ページ上のインタラクティブな要素の視覚的な順序と一致している必要があります。 キーボード ユーザーは、画面上のコントロール要素を上から下へ、テキスト コンテンツと同じ水平方向 (左から右、または右から左) にナビゲートできる必要があります。

この基準を満たす最も簡単な方法は、デフォルトのフォーカス順序をそのままにしておくことです。デフォルトのフォーカス順序は、マークアップ内で要素が配置される順序によって決定されます。 コントロール要素の視覚的な順序とソース コードでの配置方法との間に不一致を導入すると、この基準を満たさないリスクがあります。

あなたも好きかもしれません： LiquidとShopifyでアクセシブルなブレッドクラムナビゲーションを構築する。

上のスクリーンショットを例として使用すると、「タグの更新」カードと「説明の更新」カードが狭いビューポートにスタックするときに位置を入れ替えたいとします。 カードがフレックス アイテムとしてレンダリングされる場合、order CSS プロパティを使用して、特定のブレークポイントでの順序を変更することを検討できます。

orderプロパティはフレックス アイテムの視覚的な順序に影響を与えますが、ソース コード内の配置は更新しません。 その結果、ユーザーが Tab キーを押して各ボタン間を移動すると、画面上では逆の順序で表示されていても、[タグの更新] ボタンは [説明の更新] の前にフォーカスを受け取ります。 これにより、フォーカスが予期せずページを上下に移動し、ユーザーの方向感覚を失わせます。

この問題を回避する 1 つの方法は、マークアップで 2 つのバージョンのカードをレンダリングすることです。1 つは広いビューポート幅に適した順序で、もう 1 つは狭いビューポート幅に適した順序です。 displayプロパティを使用して、特定のブレークポイントでそれらを切り替えることができます。

マークアップで 2 つのバージョンを維持したくない場合は、JavaScript を使用して、カードがページ上に積み重ねられるときにカードのtabIndex属性を更新する必要があります。 レンダリングするコントロール要素の数によっては、マークアップでカードの異なるバージョンを維持するよりも、このアプローチを正しく行うのが難しい場合があります。

4. フォーカス状態をカスタマイズするときは、それを最も必要とするユーザー向けに設計する

ブラウザーは、 outline CSS プロパティを使用して、要素がフォーカスされていることを視覚的に示すものをレンダリングします。 フォーカス状態は、ユーザーがキーボードでページをナビゲートするときに、どの要素がキーボード イベントを登録するかを識別できるようにすることを目的としています。

デザイナーや開発者が、ブラウザーによってレンダリングされるデフォルトのフォーカス状態を置き換えることは非常に一般的です。 これには、デフォルトのoutlineの更新、またはそれを完全に削除して、 background 、 border 、 box-shadow 、 color 、またはtransformなどの別の CSS プロパティに置き換えることが含まれる場合があります。

あなたも好きかもしれません： Liquidでアクセシブルなページネーションを作成する。

ただし、アプリでカスタム フォーカス状態をレンダリングすることにしましたが、次のアクセシビリティ要件を満たしていることを確認する必要があります。

• 十分な色のコントラスト:視覚障害のあるユーザーが現在どの要素がフォーカスされているかを簡単に追跡できるように、フォーカス状態とその周囲の色との間に十分なコントラストが必要です。
• 色の変化は、他の視覚的指標と対になっています。要素の境界線、フォント、または背景の色を変更しても、色盲のユーザーには気付かれない場合があります。 ユーザーが色を区別する必要のない他の視覚的な変更と組み合わせる必要があります。 これは、色の変化を伴うホバーおよびエラー状態にも適用されます。
• ハイ コントラスト テーマで表示: Windows デバイスでハイ コントラスト モードが有効になっている場合、 backgroundやbox-shadowなどの一部の CSS プロパティは無視されます。 色の変化も記録されない可能性があるため、背景色と前景色のコントラストをさらに必要とする人々が認識できる追加の指標に頼ることが二重に重要です。

デフォルトのoutlineプロパティをオーバーライドすることは許容されますが、代替を提供せずにデフォルトのフォーカス状態を削除しないでください。

5. キーボード ユーザーにショートカットを提供する

誰かがマウスを使用して Web ページをナビゲートする場合、ページが読み込まれるときに無関係なヘッダー コンテンツをスクロールして、探している情報にたどり着くことができます。 このプロセスは、ページの主要なコンテンツの前にある複数のナビゲーション リンクやその他のコントロール要素をタブで移動する必要があるキーボード ユーザーにとっては合理化されていません。

開発者は、アプリの各ページの上部に「スキップ リンク」を提供して、キーボード ユーザーがページのメイン コンテンツの前にあるコントロール要素をバイパスできるようにすることができます。 スキップ リンクは通常、フォーカスを受け取るまで非表示になっています。 マウスを使用してアプリを操作するユーザーには表示されませんが、キーボードを使用するユーザーがフォーカスを受け取る最初の要素になります。

リンクがクリックされると、フォーカスがプライマリ コンテンツ コンテナーに移動し、キーボード ユーザーはページ上のメイン コントロール要素をすぐにタブ移動し始めることができます。

スキップ リンクは便利なショートカット以上のものです。 これらは、レベル A の WCAG 標準を満たすために必要なバイパス ブロックの例です。

自分でキーボード ユーザーになってアプリを頻繁にテストする

キーボードのアクセシビリティのテストは、支援技術やデバイスの使用に慣れていない人にとっては、学習曲線が比較的低くなります。 必要なのは、キーボードへのアクセス、標準的なキーボードの動作に精通していること、および Windows ハイコントラスト モードへのアクセス (Windows デバイスの取得または仮想マシンのインストールによる) だけです。

キーボードのアクセシビリティについてアプリをテストする際に留意すべき質問を次に示します。

• キーボードを使用して、マウスのクリックやジェスチャに反応するものを操作できますか?
• フォーカスを受け取ったときにこの要素を操作する方法を誰かが知っていますか?
• フォーカスの順序は、ページ上のインタラクティブな要素の視覚的な順序と一致していますか?
• 色間のコントラストを高くする必要がある場合でも、現在どの要素がフォーカスされているかを追跡できますか?
• ページのメイン コンテンツに簡単にアクセスできますか?

これらすべての質問に「はい」と答えるのに、それほど労力を費やす必要はありません。ユーザーが身体に障害を持っているか、時間を節約する方法を探しているか、片手で自分のコンピューター。

アクセシビリティ テストは、アプリ開発の重要な要素です。 具体的には、キーボードのアクセシビリティは、スクリーン リーダーを使用するユーザーに代替テキストを提供したり、オーディオ コンテンツを聞くことができないユーザーにキャプションを提供したりするのと同じくらい重要です。 結局のところ、アプリに完全にアクセスできるようにする場合、アプリを使用するためにマウスを使用する必要はありません。