フォーカス管理とキーボード操作：モーダルとドロワーの実装で見落とされる点
モーダルやドロワーは、フォーカスを内部に閉じ込め、背景を不活性化し、閉じたときにフォーカスを元へ返す必要がある。トラップだけでは不十分で、返却の欠落と背景の放置が典型的な破綻を生む。
モーダルダイアログやオフキャンバスのドロワーは、見た目こそ単純だが、キーボードとスクリーンリーダーの観点では注意点が多い。マウスでは問題なく見えても、キーボードだけで操作すると破綻する実装は珍しくない。ここでは、W3CのARIA Authoring Practicesが示す要件を土台に、実装で崩れやすい点を整理する。
モーダルが要求するフォーカスの制約
モーダルが開いているあいだ、フォーカスはその内部に閉じ込められていなければならない。Tabキーで背景の要素へ移動できてしまうと、利用者は見えない場所に迷い込む。同時に、背景のコンテンツは操作対象から外す必要がある。ここで見落とされがちなのは、視覚的に隠すことと、支援技術から不活性化することが別だという点だ。背景を暗くしただけでは、スクリーンリーダーの仮想カーソルはモーダルの外を読み進めてしまう。
フォーカストラップの実装で崩れる点
フォーカストラップは、TabとShift+Tabが末尾・先頭で折り返すよう制御することで実現する。実装が崩れる典型は、内部の要素が動的に増減する場合だ。開いた時点の要素だけを対象にしていると、後から追加された要素にフォーカスが届かない。折り返しの対象は、その都度取得し直す必要がある。アクセシブルなフォーム設計で扱うフォームをモーダル内に置く場合、この問題はより起きやすい。
フォーカスの返却と背景の不活性化
最も多い不具合は、閉じたときにフォーカスを返し忘れることだ。モーダルを閉じてその要素をDOMから外すと、フォーカスは行き場を失い、多くのブラウザでページ先頭に飛ぶ。開く直前にフォーカスがあった要素を記録し、閉じたら明示的に戻す必要がある。背景の不活性化には inert 属性が使え、aria-hidden とtabindexを組み合わせる従来手法よりも簡潔だ。ただし、対応状況はブラウザによって差があり、フォールバックの検討は残る。
キーボードだけで検証する
これらの問題は、マウスを使ったテストでは表面化しない。検証はキーボードだけで行うのが確実だ。Tabで内部を一巡し、末尾で先頭に戻るか。Escで閉じ、フォーカスが開くきっかけとなった要素に戻るか。背景の要素にフォーカスが漏れないか。一方で、自動テストはDOM構造は確認できても、フォーカスの体験までは捉えにくい。実機での手動確認は省けない。トークンで管理する見た目とは違い、フォーカスはデザイントークンの設計のように静的には検証できない。
トラップ・返却・不活性化の三点
モーダルとドロワーのフォーカス管理は、内部への閉じ込め、閉じたときの返却、背景の不活性化という三点に集約される。どれか一つでも欠ければ、キーボード利用者は迷子になる。見た目の実装が終わってからではなく、最初からこの三点を要件として設計に含めることが、後戻りを減らす近道になる。
