Webデザインでフォーカスしただけで画面が切り替わらないようにする方法|勝手に切り替わる作りとアクセシビリティの基準
Tabキーで入力欄に移っただけで、別の窓が開いたりフォーカスが飛んだりする作りを避ける方法を、アクセシビリティの基準WCAG 3.2.1をもとに解説します。フォーカスで窓を開く版との違いも、ブラウザで比べて紹介します。
目次
この記事でわかること
- フォーカスについて定めた、WCAGの達成基準3.2.1の内容
- 「状況の変化」の例と、フォーカスで起こしてよいこと・いけないこと
- 説明はフォーカスで出し、詳しい説明の窓はボタンで開く書き方
- フォーカスで窓を開く版・フォーカスを外す版と、ブラウザで比べた結果
入力欄にTabキーで移っただけで、ヘルプの窓が開いてしまう。次の欄へ進もうとしても、また窓が開いて先へ進めない。マウスで操作していると気づきにくいこうした作りは、キーボードで操作する人をひどく迷わせます。この記事では、フォーカスしただけでは画面を切り替えない作り方を、WCAG 2.2の達成基準3.2.1を軸に整理します。
当たった資料は、W3Cの達成基準3.2.1の解説(Understanding)と、技法G107、失敗例F55で、どれも2026年11月1日に原文で確かめました。例に出す入力フォームはこの記事用の見本で、ここでは道具や講座を選んで勧めることはしません。
先に結論: フォーカスでは内容を見せるだけにし、切り替えはボタンで行う
部品にフォーカスが移っただけで、別の窓を開いたり、送信したり、フォーカスを別の所へ動かしたりしません。 説明を近くに表示する程度なら問題ありません。窓を開く・次の画面へ進むといった切り替えは、ボタンを押したときに行います。
| フォーカスしたときの動き | 基準との関係 |
|---|---|
| 欄の下に説明を表示する | 内容の変化で、問題にならない |
| 新しい窓やダイアログを開く | 状況の変化で、避ける |
| フォームを送信する | 状況の変化で、避ける |
| フォーカスを別の部品へ動かす・外す | 状況の変化で、避ける |
フォーカスに関わる基準(3.2.1)
WCAG 2.2の達成基準3.2.1(レベルA)は、どの部品がフォーカスを受け取っても、状況の変化を起こさないことを求めています。解説では、ねらいを、文書の中を移っていくときに動きが予測できるようにすることだとしています。
解説が挙げる状況の変化の例は、部品がフォーカスを受け取ったときに、フォームが自動で送信される、新しい窓が開く、フォーカスが別の部品へ移る、の3つです。この基準は、目の見えにくい人、認知に障害のある人、体を動かしにくい人を、思いがけない状況の変化から守るとしています。
「内容の変化」と「状況の変化」の違い
解説では、内容の変化がいつも状況の変化になるわけではないとしています。状況の変化を伴わない内容の変化なら、この基準は自動的に満たされます。入力欄の下に説明の文を出すことは、内容の変化です。
フォーカスは、キーボード(Tabキーでの移動)でも、マウス(入力欄のクリック)でも移ります。一方で、マウスを部品の上に重ねるだけでは、スクリプトでそうしない限りフォーカスは移らない、と解説は説明しています。
解説の失敗の例は、入力欄がフォーカスを受け取るとヘルプの窓が開くものです。Tabキーで進もうとするたびに窓が開き、フォーカスが入力欄から離れてしまいます。
書き方の例: 説明はフォーカスで出し、詳しい説明の窓はボタンで開く
次のHTMLは、郵便番号の欄にフォーカスが移ったら欄の下に短い説明を出し、詳しい説明の窓はボタンを押したときだけ開く例です。
<label for="fullname">氏名</label>
<input id="fullname" type="text">
<label for="post">郵便番号(ハイフンなし)</label>
<input id="post" inputmode="numeric" aria-describedby="post-hint">
<!-- 説明は欄のすぐ下に出す。フォーカスは動かさない -->
<p id="post-hint" hidden>7桁の数字を、続けて入力します。</p>
<button type="button" id="help-open">入力のしかたを詳しく見る</button>
<dialog id="help">
<p>郵便番号が分からないときは、住所の欄から先に入力できます。</p>
<button type="button" id="help-close">閉じる</button>
</dialog>
<script>
const help = document.getElementById("help");
// フォーカスしたときは、説明を表示するだけにする
document.getElementById("post").addEventListener("focus", () => {
document.getElementById("post-hint").hidden = false;
});
// 詳しい説明の窓は、ボタンを押したときだけ開く
document.getElementById("help-open").addEventListener("click", () => help.showModal());
document.getElementById("help-close").addEventListener("click", () => help.close());
</script>
技法G107では、状況の変化は、リンクを押す・送信ボタンを押すといった、ふつう状況の変化を起こす利用者の操作でだけ起こし、フォーカスを動かすだけの操作では起こさないとしています。
手順: 自分のサイトをTabキーで確かめる
- ページの最初から始める: アドレスバーの次から、Tabキーで1つずつ進みます
- フォーカスが移るたびに見る: 窓が開く、ページが移る、送信される、フォーカスが別の所へ飛ぶ、のどれかが起きないかを確かめます
- 入力欄はクリックでも確かめる: マウスで欄をクリックしたときも、同じことが起きないかを見ます
- 起きた所の処理を見直す: focusの出来事に付いた処理を、clickやボタンの操作に移します
- 最後まで進めるか見る: ページの最後までTabキーで進み、途中で戻されたり止められたりしないかを確かめます
試した結果
上のHTMLと、郵便番号の欄のfocusで詳しい説明の窓を開く版、focusでフォーカスを外す版(失敗例F55の形)を作りました。どれも自分のPCの中で配信し、画面を出さないChromeで開いて、Tabキーを送って比べました。
- 上のHTMLで、氏名の欄からTabキーを押すと、フォーカスは郵便番号の欄に移り、欄の下に説明が出ました。窓は開きませんでした
- もう一度Tabキーを押すと、フォーカスは「入力のしかたを詳しく見る」のボタンへ進みました。ボタンでEnterキーを押すと窓が開き、フォーカスは窓の「閉じる」のボタンへ移りました
- 窓を開く版では、氏名の欄からTabキーを押しただけで窓が開き、フォーカスは郵便番号の欄ではなく「閉じる」のボタンにありました
- フォーカスを外す版では、Tabキーで郵便番号の欄へ移ったとたんにフォーカスが外れ、どの部品にもフォーカスがない状態になりました
試すのに使ったのは、作業用のMacのGoogle Chrome 156を、画面を出さない形で動かしたものです。画面の読み上げソフトを使った確認は、していません。
自分で直すか、相談するかの判断
目安は、「フォーカスで動く処理が、自分の書いたスクリプトの中にあるか」です。それなら、focusの処理を説明の表示だけにし、窓を開く処理をボタンのclickへ移すだけで直せます。
使っているフォームの部品やライブラリが、フォーカスで窓を開いたり入力を補ったりしている場合は、設定で止められるかを先に調べます。止められなければ、部品を作った会社や担当の人に相談します。分からないことは、Webデザインを学べる講座で質問して確かめる方法もあります。
つまずきやすいところ
- 選んだだけで送信する: セレクトボックスで選んだだけでページが移る作りは、入力の基準(3.2.2)の問題です。考え方は、Webデザインで選んだだけで画面が切り替わらないようにする方法にまとめています
- フォーカスの枠を消す: 失敗例F55では、フォーカスを受け取ったときにスクリプトで外す作りは、キーボードの利用者がマウスでしか操作できなくなるとしています。フォーカスの見せ方は、Webデザインでキーボードだけで操作できるかを確かめる方法で紹介しています
- フォーカスで出る説明が消えにくい・閉じにくい: ホバーやフォーカスで出る内容の作り方は、Webデザインのツールチップとホバーで出る内容の作り方で紹介しています
まとめ
- 部品にフォーカスが移っただけで、窓を開く・送信する・フォーカスを動かすといった状況の変化を起こしません
- 欄の下に説明を出すような内容の変化は、問題になりません
- 窓を開く・次へ進むといった切り替えは、ボタンを押したときに行います
- Tabキーでページの最初から最後まで進めて、確かめます
よくある質問
フォーカスしたときに、欄の下へ説明を表示するのはかまいませんか?
かまいません。解説では、内容の変化がいつも状況の変化になるわけではなく、状況の変化を伴わない内容の変化なら、この基準は自動的に満たされるとしています。試した例でも、説明を出してもフォーカスは入力欄に残りました。
マウスを重ねたときに動く処理も、この基準の対象ですか?
解説では、マウスを部品の上に動かしても、スクリプトでそうしない限りフォーカスは移らないとしています。そのため、ホバーで出る内容はふつうは別の基準で考えます。ただし、クリックで入力欄にフォーカスが移ることはあり、その場合はこの基準の対象です。
ボタンをクリックしたら画面が移るのは、問題ありませんか?
問題ありません。技法G107では、状況の変化は、リンクを押す・送信ボタンを押すといった、ふつう状況の変化を起こす利用者の操作でだけ起こすとしています。解説でも、ボタンのような部品はクリックで動かすことがあり、それが状況の変化につながることもあるとしています。
フォーカスの枠が見た目に合わないので、フォーカスをすぐ外してもよいですか?
外してはいけません。失敗例F55では、フォーカスを受け取ったときにスクリプトで外す作りを失敗としています。キーボードの利用者にとってフォーカスの表示は大事で、外すとマウスでしか操作できなくなるとしています。
どうやって確かめればよいですか?
技法G107の確かめ方は、キーボードで全体のフォーカスを順に回し、どの部品にフォーカスが移っても状況の変化が起きないかを見ることです。Tabキーで最初から最後まで進め、窓が開いたり、ページが移ったり、フォーカスが別の所へ飛んだりしないかを確かめます。