ウェブアクセシビリティ向上には様々な取り組みが必要ですが、特に重要なのがキーボード操作のサポートです。
なぜなら、「キーボード操作を行えないとウェブコンテンツを利用することが難しい」というユーザーが多く存在しているからです。
ウェブコンテンツを作る時にキーボード操作をサポートすることで、より多くの人に情報を届けるコンテンツにすることができます。
今回の記事では、ウェブコンテンツにおけるキーボード操作の重要性に焦点を当て、ウェブアクセシビリティを高めるための具体的な方法を解説します。
なお、キーボードで操作できるモーダルダイアログやフォームの実装には細かい調整が必要となりますので、別途ご紹介する予定です。
ウェブアクセシビリティの基本について知りたい方はこちらの記事へ!
ウェブアクセシビリティの基本原則などを詳しく知りたい方はこちらの記事へ!
1. キーボード操作はなぜ重要?
キーボード操作ができないとコンテンツ利用が困難になるユーザーがいることは、最初にお伝えしました。
いったいそれはどういったユーザーなのか、またその理由についても詳しく見ていきましょう。
1-1. 視覚障がい者
視覚障がいがある人の中には、画面を見ながらマウス操作をするのが困難な人もいます。
そのような場合、スクリーンリーダーやキーボードを操作してウェブコンテンツを利用します。
スクリーンリーダーでウェブコンテンツの内容を把握できたとしても、キーボード操作ができなければコンテンツやページの移動、お問い合わせフォームの送信などが行えない可能性があります。
1-2. 上肢障がい者
上肢障がいがある人の中には、手や腕の動きに制限があることでマウスでの細かい操作が難しい、またはマウスの使用自体が不可能という人がいます。
その場合、マウスに代わりキーボードや専用の入力デバイスを操作してウェブコンテンツを利用します。
マウスでしか操作できない仕様になっている場合、そのコンテンツの利用が困難になります。
1-3. 一時的な障がいがある人
アクセシビリティについて考える時には、ケガや病気、機器の故障などで一時的に何かしらの制限を受ける人を「一時的な障がいがある人」として考えます。
例えば今回の場合、利き腕の骨折により一時的にマウスの使用が難しい人や、マウスが故障したけれど代わりのマウスを持っていない人などが一時的な障がいがある人として当てはまるでしょう。
一時的な障がいがある人も、キーボード操作でウェブコンテンツを使用する可能性があります。
キーボード操作がサポートされていない場合、このようなユーザーもコンテンツ利用に不便を感じる可能性が高くなります。
1-4. 高齢者
年齢による身体的変化や認知機能の低下により、マウス操作が難しくなることがあります。
例えば、高齢者によく見られる手の震えもマウス操作を困難にする原因の一つです。
その人の症状や状況にもよりますが、マウスよりキーボードの方が楽に操作できることも十分に考えられます。
このように、キーボード操作がサポートされていない場合、ウェブコンテンツの操作や利用が非常に困難になるユーザーが存在します。
そういった事情から、キーボード操作のサポートはもっとも重要なウェブアクセシビリティの一つであると考えられるのです。
2. キーボード操作の基本
2-1. WCAGから見るキーボード操作
まず、キーボード操作のサポートではどのようなことが求められるのかを知る必要があります。
WCAG2.0のキーボード操作に関わる項目の中から、JIS X 8341-3:2016における適合レベルAA、Aとなっている基準を見ていきましょう。
2.1.1 キーボード
下記は、WCAG2.0解説書 達成基準2.1.1を理解するの引用です。
コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。(レベルA)
注記1:上記の例外は、根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法(手書き)は利用者の動作による軌跡に依存した入力を必要とするが、その根本的な機能(テキスト入力)は利用者の動作による軌跡に依存した入力を必要とするものではない。
注記2:これは、キーボード操作に加えて、マウス入力、又はその他の入力手段を提供することを禁ずるものでも妨げるものでもない。
要約すると以下のようになります。
- すべてのコンテンツは、キーを押すタイミングに関わらずキーボードだけで操作できる必要がある。
- 例外として、手書きのように始めから終わりまで手を動かす必要がある特定の機能についてはこのルールが適用されない。
- この基準は、キーボード操作以外にマウスや他の入力手段を使用することを禁止するものではない。
2.1.2 キーボードトラップなし
下記は、WCAG2.0解説書 達成基準2.1.2を理解するの引用です。
キーボードインタフェースを用いてキーボードフォーカスをそのウェブページのあるコンポーネントに移動できる場合、キーボードインタフェースだけを用いてそのコンポーネントからフォーカスを外すことが可能である。さらに、修飾キーを伴わない矢印キー、Tabキー、又はフォーカスを外すその他の標準的な方法でフォーカスを外せない場合は、フォーカスを外す方法が利用者に通知される。(レベルA)
注記:この達成基準を満たさないコンテンツでは、利用者がそのウェブページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。
要約すると以下のようになります。
- ウェブページの特定の部分(モーダルダイアログなど)にキーボードだけでフォーカスできる場合、その部分から
- フォーカスを解除するのもキーボードだけで行える必要がある。
- フォーカスを解除する方法が標準的なものではない場合、解除方法をユーザーに通知する必要がある。
- この基準を満たさないとユーザーがウェブページ全体を使えなくなる可能性があるため、ウェブページ上のすべてのコンテンツはこの基準を満たす必要がある。
2-2. キーボード操作サポートのために必要な対応
上で確認したWCAG2.0の内容を元に、キーボード操作をサポートするために必要な対応を3つにまとめて解説します。
すべての要素をキーボードで操作できるようにする
ウェブコンテンツがキーボードで操作できない場合、キーボードユーザーはそのコンテンツを利用することができません。
そのため、タブキー、エンターキー、スペースキー、矢印キーなどを使って、コンテンツ上のリンクやボタン、フォームなど、ユーザーが操作できるすべての要素を選択したり操作したりできるようにする必要があります。
実装する上で、キーボード操作を可能にするために多少工夫が必要な場合があります。
しかし、セマンティックHTMLでコーディングすればある程度のキーボード操作は可能となるため、まずはタグを適切に使用してコーディングするよう意識することが大切です。
セマンティックHTMLについて知りたい方はこちらの記事へ!
フォーカスインジケータを表示する
ブラウザの標準機能として、キーボード操作時にはフォーカスが当たっている場所を明確に示すためにフォーカスインジケータが表示されます。
それぞれのブラウザにより表示方法は多少異なるものの、一般的にはフォーカスされた部分が線で囲まれるようになっています。
しかしながら、フォーカスインジケータを非表示にしているウェブサイトも多くあります。
理由としては、「デザインの崩れを防ぐため」「フォーカスインジケータの必要性を感じていない」などさまざまあるかと思います。
とはいえ、ウェブアクセシビリティの観点から言うとフォーカスインジケータの表示は必須です。
なぜなら、フォーカスインジケータが表示されない場合、コンテンツがキーボードで操作できるように作られていたとしても「現在の選択箇所が分からず利用できない」という状況に陥ってしまうからです。
また、CSSなどを利用してフォーカスインジケータをカスタマイズする場合、視認性を高めるために周囲の色との間に十分なコントラスト比を確保する必要があります。
キーボードトラップを回避する
あるコンテンツにフォーカスを当てた際、「キーボード操作だけではフォーカス解除ができず、特定のコンテンツから抜け出すことができない」という状況が発生することがあります。
これを「キーボードトラップ」と言います。
具体例を挙げると、モーダルダイアログを開くとキーボードでは閉じることができず、ダイアログ内に閉じ込められてしまうなどです。
ちなみに、モーダルダイアログとはウェブページなどを閲覧している際に一時的に開かれる小さい画面のことです。
下の画像のようにメッセージを表示するものの他、画像を拡大表示するものなどがあります。
キーボードトラップが一部でも存在すると、ページやサイト全体の利用が困難になることがあります。
そのため、キーボードトラップが発生しないように制作する必要があります。
キーボードトラップを回避するためには、モーダルダイアログやポップアップ画面などの特定コンテンツから抜け出す方法を用意し、ユーザーに提供します。
例えば、「エスケープキーを押して画面を閉じる」「×アイコンを選んでエンターキーを押す」などです。
その方法が一般的でなかったり分かりづらいものである場合は、コンテンツの近くに操作方法を記載するなどの対応も必要となります。
3. チャコウェブ公式サイトのキーボード操作
チャコウェブ公式サイトでもキーボード操作のサポートを行いました。
※ブログに関してはCMSやプラグインの関係ですぐに対応できない箇所があり、順次対応中です。
コーディングはすべてセマンティックHTMLで行っています。
そのため、ボタン、リンク、タブ、フォームなど、すべてがキーボード操作可能となっています。
それでは、チャコウェブ公式サイトにおけるフォーカスインジケータと、要素を選択した時の変化を見ていきましょう。
3-1. フォーカスインジケータ
チャコウェブ公式サイトでは、ブラウザ標準のフォーカスインジケータを無効にし、CSSを利用してカスタマイズを行っています。
実際に使用しているフォーカスインジケータのCSSは以下です。
「*」は全称セレクターと言って、すべての要素を指定するためのセレクターです。
すべての要素においてoutline: none;を指定することで、標準のフォーカスインジケータを消しています。
そのあと、box-shadowプロパティを使って細い白線と太い黒線を重ねることで、明るい背景色、暗い背景色のどちらにも対応できるフォーカスインジケータを設定しています。
個人的な感想ですが、標準のフォーカスインジケータだとボタン選択時に若干の見にくさを感じたため、box-shadowを使用して実装しました。
ただ、この部分に関してはoutlineの太さを太くする、outline-offsetを使用してボタンの境界線からフォーカスインジケータを離すなど様々なやり方がありますので、box-shadowでの実装にこだわる必要はないと考えています。
また、フォーカスインジケータの設定には「:focus-visible」という疑似クラスを使用しています。
ブラウザによっては、要素をマウスでクリックした時にその要素にフォーカスが当たり、マウス操作であるにも関わらずフォーカスインジケータが表示される場合があります。
マウス操作でフォーカスインジケータが出てしまうと、非常に野暮ったい感じがします。
かといって、フォーカスインジケータを非表示にしてしまうとキーボード操作が困難になってしまいます。
そういった場面で、フォーカスインジケータを表示すべきかどうか自動的に判断して出し分けてくれるのが「:focus-visible」です。
要素にフォーカスが当たった時、フォーカスインジケータを表示すべきであればこの疑似クラスに設定したCSSプロパティが適用されます。
それ以外の場合、この疑似クラスに設定したCSSプロパティは適用されません。
3-2. ナビゲーション
チャコウェブ公式サイトをPCで見ると、画面の上部と下部にそれぞれナビゲーションがあります。
画面上部のナビゲーション(ヘッダーナビゲーション)は背景色が明るく、画面下部のナビゲーション(フッターナビゲーション)は背景色の暗いナビゲーションです。
どちらもナビゲーション内のリンクはaタグでコーディングしているため、キーボードで操作することが可能です。
また、キーボード操作時にフォーカスインジケータが表示されるようになっています。
このフォーカスインジケータですが、上で説明した通り、ブラウザ標準のものではなくカスタマイズしたものです。
キーボード操作時にのみ表示され、マウス操作時には表示されないようにしています。
また、パーツごとにCSSを書き直さなくても良いようにしていて、背景が明るいところでは黒色に、背景が暗いところでは白色に見えるようになっています。
3-3. ボタン
ボタンはdivタグやaタグを組み合わせて作る方法がよく使われますが、セマンティックHTMLの観点から考えるとbuttonタグを使用する方法が好ましいでしょう。
チャコウェブのホームページで使用しているボタンは以下のようなHTMLになっています。
(一部簡略化しています。)
buttonタグのtype属性は3種類ありますが、まずは簡単に
- 送信ボタンならtype=”submi”
- リセットボタンならtype=”reset”
- それ以外(他ページに移動するボタンなど)ならtype=”button”
と覚えれば良いかと思います。
詳しい仕様はドキュメントを読むと勉強になります。
参考:MDN web docsのボタン要素に関する解説記事
buttonタグを使用して作成したボタンの場合、onclick属性を使用して他のページに移動します。
書き方は以下です。
【buttonタグのonclick属性を使用して移動する方法】
なお、この部分の記述は絶対パス、相対パスのどちらでも問題ありません。
続いて、このボタンを操作した時に起こる表示の変化を見ていきましょう。
まず、こちらが何も操作していない状態のボタンです。
次の画像は、マウスホバー(マウスカーソルをボタン上に乗せた時)の変化です。
マウスホバー時の処理を「:hover」に記述しているので、ボタンの背景色や文字色が変化しています。
マウス操作時はフォーカスインジケータが表示されないようにしているので、ホバー時もクリック時もフォーカスインジケータは表示されません。
次の画像は、キーボード操作時のボタンの変化です。
マウスホバー時のように背景色や文字色の変化はなく、ボタン自体は何も操作していない時と同じ状態です。
ですが、現在このボタンが選ばれていることが分かるように、ボタンを囲うフォーカスインジケータが表示されています。
「:focus-visible」を使用してフォーカスインジケータの出し分けを設定しているため、キーボード操作時はフォーカスインジケータが表示されます。
マウス操作時はフォーカスインジケータが表示されません。
ホバーはマウス操作時にのみ起こる状態のため、「:hover」の記述がキーボード操作時に適用されることはありません。
4. まとめ
今回は、ウェブアクセシビリティ対応の中でも重要度の高いキーボード操作についてまとめました。
改めて、キーボード操作について重要なことは以下の3点です。
- すべての要素をキーボードで操作できるようにする
- フォーカスインジケータを表示する
- キーボードトラップを回避する
ボタンやリンクをキーボードで操作できるようにする方法や、フォーカスインジケータを表示する方法については具体的にご紹介しました。
キーボードで操作できるフォームを作るためには、細かい調整が必要となります。
また、キーボードトラップが発生しやすいモーダルダイアログは、キーボードトラップを回避して実装する必要があります。
この2点については別の記事で詳しく解説する予定ですので、更新をお楽しみに!