今日の問い
マウスを使わずに、予約変更を最後まで終えられますか。
30秒でつかむ
キーボード確認では、到達できる、順序が自然、現在地が見える、抜け出せるの四点を追います。フォームでは、各入力欄の目的を見えるラベルとコード上の関連付けで伝えます。
チェック項目を眺めるだけでは不十分です。実際にTab、ShiftとTab、Enter、Space、矢印キーを使い、主要タスクを最初から最後まで操作します。
30秒図解 · LESSON 26
流れ図
視線がなくても、操作の筋道を保つ
順序、現在地、名前、結果をキーボードだけで確認します。
- 01Tab順序
- 02可視フォーカス
- 03明確な名前
- 04結果の通知
CLUE · 見抜く手掛かり
マウスなしで完了まで到達できるか
TRAP · ありがちな罠
フォーカス枠を装飾として消す
原則
まず、マウスやトラックパッドから手を離します。ページの先頭からTabで進み、操作できる部品へすべて到達できるか確認します。独自のカード全体をクリック可能にした実装や、ドラッグだけで日時を動かす実装は見落としやすい箇所です。
次に、フォーカス順序がタスクの理解を助けるかを見ます。CSSで見た目だけを並べ替えると、表示順とDOM順がずれることがあります。フォーカスが画面を飛び回るなら、まず文書構造を直します。
現在地は、色の薄い変化だけに任せません。ブラウザーの標準表示を消したままにせず、背景に対して識別できるフォーカス表示を用意します。固定ヘッダーやダイアログの背後に隠れていないことも確認します。
フォームのラベルは、入力欄の用途を説明します。可能ならlabel要素のforと入力欄のidを一致させます。プレースホルダーは入力すると消えるため、ラベルの代わりにはしません。
アイコンだけのボタンにも、目的が伝わる名前が必要です。見える文字がある場合は、支援技術へ伝わる名前にも同じ言葉を含めます。見た目、キーボード操作、支援技術への名前を別々に確認するのが要点です。WCAG 2.2の2.1.1 Keyboardと2.4.7 Focus Visibleを、キーボード到達とフォーカス表示の規範上の確認点にします。
フォーム部品を目的の分かるラベルで識別し、label要素と入力部品を関連付ける実装を解説するWAI Tutorial。
良い例と惜しい例
予約日時入力の実装
AIへの指示例
目的: 予約変更をキーボードだけで完了でき、各入力欄とボタンの目的が伝わるようにする
制約: tabindexの正数で順番を作らない。フォーカス表示を消さない。プレースホルダーを唯一のラベルにしない
参照: screens/、primary-flow.md、component-states.md
受入条件: TabとShift+Tabの順序がDOM順と一致し、全操作へ到達できる。各入力欄に見えるラベルが関連付き、ダイアログを開閉してもフォーカスを失わない
確認問題
セルフチェック
1. Tabを押すと、見た目では左端の日時欄より先に右端の確定ボタンへ移動します。最初に確認するものは何ですか。
最終制作へ反映する
accessibility-audit.mdにキーボード確認を加える
主要フローをキーボードだけで操作し、到達、順序、フォーカス表示、閉じ込め、ラベルの結果を画面IDごとに追記する。
Acceptance criteria
- 入口から完了までマウスなしで試した操作手順と、問題が起きた位置が記録されている
- 各フォーム部品の見えるラベル、コード上の関連付け、操作後のフォーカス位置を確認している
今日のまとめ
- キーボード確認は、到達、順序、現在地、脱出を実操作で追う
- ラベルは入力の目的を説明し、フォーム部品とコード上で関連付ける
- 次は、狭い画面へのリフローと操作対象の大きさを確かめる