制作スタジオのサイトを訪れた人が、マウスに触れずにトップページからサービス、そして問い合わせ先へ移動する場面を考えてみましょう。今どこにいるか分かるでしょうか。目的の項目を開けるでしょうか。この短い経路をたどるだけでも、ナビゲーションが見た目の配置だけでなく、操作のための仕組みとして設計されているかが見えてきます。W3C WAIのキーボード操作に関する解説が示す基本は、インターフェースの機能をキーボードから利用できるようにすることです。
分かりやすい構造から始める
一般的なサイトナビゲーションでは、nav要素の中にリストを置き、その中にリンクをまとめます。これはWAIのメニュー構造のチュートリアルで説明されている基本です。リンクはページへの移動、ボタンはサブメニューの開閉を担当します。「サービス」に概要ページと下位項目の両方がある場合は、その二つの操作を分けましょう。項目名を選ぶと概要ページへ進み、隣のボタンを押すと選択肢が開く。このように、実装前から動作を説明できる設計にしておきます。
移動する順序を決める
Tabでは分かりやすい順に進み、Shift + Tabでは前に戻れるようにします。WAIのフォーカス順序の解説では、意味と操作性を保つことが重視されています。デザイン上に「ロゴ、主要項目、問い合わせボタン、その次の操作要素」という経路を描くと、具体的に検討できます。フォーカスが離れた場所へ突然飛ぶなら、画面上の配置だけでなく、コード内の要素の順序も確認しましょう。アニメーションを追加する前に、想定する移動順序を共有しておくと役立ちます。
フォーカスを見つけやすくする
フォーカスは、次のキーボード操作を受け取る要素を示します。Focus Visibleの解説では、表示されているフォーカスの目印を時間経過で消さないことが求められています。標準の輪郭線は、明確に見える代替表現を用意せずに消してはいけません。WAIのメニューのスタイルに関するチュートリアルでは、フォーカスと現在のページを別々の状態として扱っています。両方が同時に表示される状態も設計しましょう。例えば、開いているセクションには下線を付け、キーボードの現在位置にははっきりした枠を付ける方法があります。
サブメニューは意図した操作で開く
マウスを重ねることだけを、下位リンクを表示する唯一の方法にしないでください。WAIのドロップダウンメニューの説明では、キーボード操作と、aria-expandedによる開閉状態の伝達が扱われています。通常のナビゲーションにmenuロールを付ける必要があるとは限りません。WAIの開閉式ナビゲーションの例では、Enterとスペースでボタンを操作し、Escapeでサブメニューを閉じて操作元のボタンにフォーカスを戻します。例を完成済みのコードとしてそのまま使うのではなく、自分たちの実装で動作を確かめる必要があります。
実際の利用経路を一つ試す
- トップページを開いてマウスから手を離し、Tabで最初のメニュー項目を見つけます。
- 「サービス」まで進んでサブメニューを開き、ページを一つ選びます。逆方向の移動も試します。
- サブメニューを閉じてから再び開き、それぞれの操作後にフォーカスがどこへ移るか確認します。
- ウィンドウ幅を狭くした状態や、ページを拡大した状態でも繰り返します。既存の通知や固定表示のバーは表示したままにします。
重なりも別に確認しましょう。WAIは、ページ側のコンテンツがフォーカス中の要素を完全に隠さないことを求めています。また、利用者はキーボードでコンポーネントから抜けられる必要があります。通常のメニュー内だけを延々と巡回させる状態にはしないでください。
印象ではなく動作を記録する
修正に役立つ記録には、ページのURL、ブラウザー、ウィンドウ幅、押したキーの順序、期待した結果を含めます。「メニューが使いにくい」ではなく、「サブメニューを閉じるとフォーカスが見えなくなり、次のTabで最初から移動が始まる」と書くと、再確認しやすくなります。この短い手順はナビゲーションの問題を見つける助けになりますが、包括的なアクセシビリティ評価の代わりにはならず、それだけでWCAGへの適合を示すものでもありません。