キーボードでページを使う

マウスを外して Tab を押しましょう。リンク、ボタン、入力欄が、ページを読む順に1つずつ光るはずです。

キーボードを使う人

マウスにまったくさわらない人はたくさんいます。マウスをしっかり持てない人もいれば、スイッチ、マウススティック、キー入力を送る音声認識を使う人もいます。スクリーンリーダーの利用者も、たいていキーボードで移動します。WCAG 2.2のレベルAの達成基準2.1.1「キーボード」は、ページのすべてがキーボードで操作できなければならないとしています。達成基準2.1.2「キーボードトラップなし」はさらに、フォーカスがページのある部分に入れるなら、キーボードでまたそこから出られなければならないとしています。

最初から動く要素を使う

href のあるリンク、button、input、select、textarea は、そのままでフォーカスでき、正しいキーに反応します。クリックハンドラーを付けた div はそうではありません。Tab でたどり着けず、Enter を押しても何も起こらず、スクリーンリーダーはそれをボタンとして読み上げません。MDNの助言は明快です。div をボタンのように動かすために tabindex を使わず、button 要素を使いましょう。役割もキーボードの動作も最初から組みこまれています。

フォーカス順序と tabindex

Tab の順序は、HTMLのソースの要素の順に従います。達成基準2.4.3「フォーカス順序」は、この順序がページの意味と使い方を保つことを求めるので、おかしな順序のいちばん簡単な直し方はHTMLを並べかえることです。MDNは tabindex の値を3種類に分けています。0は要素をふつうの順序に入れます。負の値（ふつうは -1）は要素を Tab の順序から外しますが、スクリプトから focus() を呼ぶことはできるので、ダイアログやエラーメッセージに役立ちます。正の値は要素をほかのすべてより前に押し出します。正の値を使うと順序が追いにくくなるので、MDNは0と-1だけを使うよう勧めています。

今どこにいるかを見せる

キーボードの利用者には、どの要素にフォーカスがあるかが見える必要があります。レベルAAの達成基準2.4.7「フォーカスの可視化」は見えるフォーカスインジケーターを求めるので、代わりを何も置かずに outline: none のようなスタイルシートのルールを書くと不合格です。WCAG 2.2は関連する達成基準を2つ加えました。レベルAAの2.4.11「フォーカスの非隠蔽（最低限）」は、フォーカスされた項目が、固定フッターやクッキーのバナーのように制作者が加えたものの後ろに完全に隠れてはならないとしています。同じくAAの2.5.8「ターゲットのサイズ（最低限）」は、クリックやタップをするものが少なくとも 24×24 CSSピクセルあるか、まわりに十分なすき間があることを求めます。

もう1つ、とても役に立つパターンがあります。スキップリンクです。長いメニューのあるサイトでは、キーボードの利用者はどのページでもメニューのすべての項目を Tab で通らなければなりません。ページの最初に置き、メインコンテンツを指すリンクがあれば、1回のキー入力でそこを飛びこえられます。フォーカスを受けるまでは見た目の上で隠しておくこともできます。

確かめるのは2分で済みます。アドレスバーをクリックしてから、Tab をくり返し押してページ全体をたどります。すべてのコントロールにたどり着けるか、順序が読む順と合っているか、フォーカスの位置がいつも見えるか、Enter と Space がマウスのクリックと同じ働きをするかを確かめます。それから Shift+Tab で戻ります。たどり着けないコントロールや、フォーカスが見えなくなる場所があれば、それはバグです。