WCAG 2.2の達成基準3.2.5「リクエスト時の変更」は、利用者が要求していない文脈の変更を起こさないこと、またはその変更を止める仕組みを提供することを求めるLevel AAAの基準です。
ページが突然切り替わる、フォーカスが別の場所へ移る、新しいウィンドウが開くといった動作は、利用者が現在地や作業の続き方を見失う原因になります。
この基準を実装するときは、「何か操作されたか」ではなく、「利用者がその文脈の変更を明示的に求めたか」を確認します。
達成基準3.2.5が求めること
文脈の変更とは、利用者が現在の作業場所や状態を見失いかねない大きな変化です。
代表例には、別ページへの移動、新しいウィンドウやタブの表示、フォーカスの移動、ページの意味が変わるほど大きな内容の入れ替えがあります。
ただし、内容が変われば必ず文脈の変更になるわけではありません。
タブやメニューの一部が展開されるだけで、フォーカスやページの意味が変わらない場合は、文脈の変更に当たらないことがあります。
達成方法は次のどちらかです。
- 文脈の変更を、利用者がその変化を求めた操作によって開始する。
- 文脈が自動で変わる場合は、その変更を利用者が止められる仕組みを提供する。
判断しやすい代表例
| 場面 | 問題になりやすい動作 | 改善の方向 |
|---|---|---|
| 情報の更新 | ページ全体が一定時間ごとに再読み込みされる | 「最新情報を更新する」ボタンを用意するか、自動更新を止められるようにする |
| ページ移動 | 数秒後に別ページへ自動で移動する | 移動先が分かるリンクを用意し、利用者が選んで移動できるようにする |
| 選択リスト | 項目を選んだ瞬間に別ページへ移動する | 項目の選択とページ移動を分け、「移動」ボタンで確定する |
| 新しいウィンドウ | ページの表示時、入力時、フォーカス時に別ウィンドウが開く | 新しいウィンドウで開くことをリンクやボタンの文言で示し、利用者の実行操作で開く |
実装例
更新を利用者の操作に切り替える
自動更新が文脈の変更を起こす場合は、更新のタイミングを利用者が決められるようにします。
<p>表示中の情報は自動では更新されません。</p>
<button type='button' id='refresh-content'>最新情報を更新する</button>
更新処理は、このボタンの実行操作に結び付けます。
自動更新が必要なサービスでは、「自動更新を停止する」操作も分かりやすい場所に用意します。
時間指定のページ移動をリンクへ置き換える
次のように待ち時間の後で移動する実装は、利用者が読んでいる途中で文脈を変えてしまいます。
<meta http-equiv='refresh' content='5; url=next-page.html'>
移動先を説明するリンクに置き換えると、利用者が自分のタイミングで移動できます。
<a href='next-page.html'>次のページへ進む</a>
選択とページ移動を分ける
select要素の値が変わっただけで移動させず、選択後のボタン操作で確定します。
<label for='destination'>移動先</label>
<select id='destination' name='destination'>
<option value='home'>ホーム</option>
<option value='about'>会社概要</option>
</select>
<button type='button' id='go-to-page'>選んだページへ移動</button>
この設計なら、項目を確認する操作と実際に移動する操作を区別できます。
新しいウィンドウを開くことを明示する
リンクやボタンを押した結果として新しいウィンドウを開く場合は、その動作をラベルから判断できるようにします。
<a href='popup.html' target='_blank'>補足情報を新しいウィンドウで開く</a>
「詳しくはこちら」のような文言だけでは、移動先や新しいウィンドウが開くことを事前に判断できません。
よくある誤解
内容の更新をすべて禁止する基準ではない
対象になるのは、利用者を混乱させる可能性がある文脈の変更です。
ページの一部を書き換えるだけで現在地、フォーカス、ページの意味が保たれる場合は、内容が変わっても直ちに違反とは限りません。
クリックがあれば常に利用者の要求になるわけではない
リンクを押した結果、説明なく新しいウィンドウまで開く場合、利用者が要求したのはリンク先への移動だけかもしれません。
起こる変化をリンク文言で具体的に示し、その変化を選べる状態にします。
自動検査だけでは判断できない
AxeやWAVEなどの自動検査は、関連するコードや一部の問題を見つける補助として利用できます。
利用者の操作と文脈の変更の関係は画面の流れに依存するため、最終判断には手動操作とコードレビューが必要です。
手動テストの手順
- ページを開き、操作していない状態でページ移動、新しいウィンドウ、フォーカス移動、大きな内容変更が起きないか確認する。
- キーボードでリンク、ボタン、入力欄、選択リストへ順にフォーカスし、フォーカスしただけで文脈が変わらないか確認する。
- 入力欄への入力や選択リストの変更を試し、その操作だけで予期しないページ移動やウィンドウ表示が起きないか確認する。
- 更新、移動、新しいウィンドウの表示が、内容を説明したリンクやボタンの実行によって始まるか確認する。
- 自動で文脈が変わる機能を残す場合は、停止する仕組みを見つけて操作できるか確認する。
フォーカスを受け取ったときの動作は達成基準3.2.1「フォーカス時の動作」、入力による変化は達成基準3.2.2「入力時の動作」もあわせて確認すると、切り分けやすくなります。
実装時の確認ポイント
- 文脈の変更と、ページの一部の内容変更を区別する。
- 利用者が変化そのものを要求した操作かどうかを確認する。
- 自動で文脈を変える場合は、利用者が停止できる仕組みを用意する。
- 時間指定の移動、選択直後の移動、要求されていない新規ウィンドウを避ける。
- 自動検査だけで終えず、キーボード操作を含む一連の流れを手動で確認する。
達成基準3.2.5への対応は、画面の変化を利用者が予測し、自分のタイミングで操作を続けられる設計につながります。
当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
既存サイトのアクセシビリティ向上を検討している方は、サービスの詳細をご覧ください。
