WCAG 2.2「3.2.2 入力時の動作」とは？Level Aの実装例と確認方法

WCAG ​2.2の達成基準3.2.2「入力時の動作」（Level ​A）は、フォーム部品などの設定を変えたとき、予告のないページ移動やフォーカス移動を自動的に起こさないよう求めています。

対象になるのは、選択肢を変える、チェックを入れる、文字を入力するといった操作です。

すべての画面変化を禁止する基準ではなく、利用者が次に起こることを予測できるようにするための基準です。

WCAGにおける予測可能性の全体像は、JIS ​X ​8341-3:2016（WCAG）の「予測可能」とは？でも確認できます。

「入力」と「文脈の変化」の意味

達成基準を正しく判定するには、「設定の変更」と「文脈の変化」を分けて考えます。

達成基準3.2.2で確認する用語

用語	意味	例
設定の変更	操作後も残る値や状態を変えること	プルダウンの選択、チェックボックスの切り替え、テキスト入力
文脈の変化	利用者が現在位置や作業の流れを見失い得る大きな変化	別ページへの移動、新しいウィンドウの表示、フォーカスの移動、ページ内容の大幅な並べ替え
事前の通知	操作する前に、起こる変化を説明すること	「選択すると、そのページへ自動的に移動します」という説明

入力内容に応じて同じページ内の項目が表示されるだけなら、それだけで直ちに文脈の変化になるわけではありません。

一方、選択した瞬間に別ページへ移動したり、フォーカスが予期せず別の場所へ移ったりすると、利用者は操作の途中で現在位置を見失うことがあります。

リンクやボタンの実行とは区別する

リンクを開く、送信ボタンを押すといった操作は、コンポーネントの設定変更ではなく、利用者が機能を実行する操作です。

したがって、ボタンを押した後のページ移動そのものを達成基準3.2.2が禁止しているわけではありません。

なお、フォーカスを受けただけで文脈が変わる問題は、関連するWCAG ​2.2「3.2.1 ​フォーカス時の動作」で扱います。

予期しない変化を防ぐ実装方法

選択と実行を分ける

プルダウンをナビゲーションに使う場合は、選択しただけで移動させず、実行用のボタンを用意すると意図が明確になります。

<form ​action="/move" ​method="get">
 ​ ​<label ​for="destination">移動先を選んでください</label>
 ​ ​<select ​id="destination" ​name="page">
 ​ ​ ​ ​<option ​value="home">ホーム</option>
 ​ ​ ​ ​<option ​value="about">概要</option>
 ​ ​ ​ ​<option ​value="contact">お問い合わせ</option>
 ​ ​</select>
 ​ ​<button ​type="submit">選択したページへ移動</button>
</form>

この例では、利用者が選択内容を確認してから「選択したページへ移動」ボタンを押します。

ボタンのラベルにも結果が書かれているため、「送信」のような抽象的な表現より動作を予測しやすくなります。

自動的に変える場合は先に説明する

設計上、選択と同時にページを移動させる必要がある場合は、利用者がコンポーネントを操作する前に動作を説明します。

<p ​id="destination-note">
 ​ ​移動先を選ぶと、選択したページへ自動的に移動します。
</p>
<label ​for="destination">移動先</label>
<select ​id="destination"
 ​ ​ ​ ​ ​ ​ ​ ​aria-describedby="destination-note"
 ​ ​ ​ ​ ​ ​ ​ ​onchange="location.href=this.value">
 ​ ​<option ​value="/home">ホーム</option>
 ​ ​<option ​value="/about">概要</option>
</select>

説明を変更後に表示しても事前通知にはならないため、案内はプルダウンより前に置きます。

aria-describedbyは説明とプルダウンの関係をプログラムで示しますが、画面上の説明文も残します。

同じページ内の表示変更を見分ける

たとえば、配送方法を選ぶと住所入力欄が表示される設計でも、現在位置やページの意味が保たれていれば、単なる内容の変化として扱える場合があります。

ただし、表示と同時にフォーカスを遠い場所へ移したり、操作中の内容を大きく並べ替えたりすると、文脈の変化に当たる可能性があるため、実際の挙動を確認します。

よくある失敗と直し方

• プルダウンの選択だけで別ページへ移動する：「移動」ボタンを追加するか、選択前に自動移動を明記します。
• チェックを入れた瞬間に新しいウィンドウが開く：別の実行ボタンに分けるか、チェックボックスより前に動作を説明します。
• 入力を終えるとフォーカスが自動的に移る：自動移動を避けるか、入力を始める前にフォーカスの移動を説明します。
• 最後の項目を選ぶとフォームが自動送信される：送信ボタンを用意し、利用者が内容を確認してから実行できるようにします。

通常のリンクを利用者が実行して新しいタブを開く行為は、設定変更とは区別されます。

ただし、「料金表（新しいタブで開きます）」のようにリンク先の開き方を示すと、サイト全体の予測可能性を高められます。

手動テストの手順

1. プルダウン、チェックボックス、ラジオボタン、テキスト入力欄など、設定が変わるコンポーネントを洗い出します。
2. 各コンポーネントをマウスとキーボードで操作します。
3. ページ移動、新しいウィンドウ、フォーカス移動、内容の大幅な並べ替えが自動的に起こらないか確認します。
4. 文脈の変化が起こる場合は、その内容が操作前にわかる説明になっているか確認します。
5. リンクやボタンの実行と、入力値や選択状態の変更を区別して判定します。
6. 同じページ内の表示変更について、現在位置や作業の流れが保たれているか確認します。

自動検査ツールはコード上の手掛かりを見つける助けになりますが、利用者が変化を予測できるかどうかは挙動と説明の順序を含めた手動確認が必要です。

フォーム全体のラベル、エラー、必須項目も見直す場合は、WCAG ​2.2で押さえる入力支援とエラー設計の基本も参考になります。

実装前後のチェックリスト

• 選択や入力だけでページを移動させていないか
• 自動的な文脈の変化が必要な場合、操作前に具体的な説明があるか
• 選択と実行を分けられる箇所に、目的のわかるボタンがあるか
• フォーカスを予期しない場所へ移していないか
• 内容の表示変更と文脈の変化を混同していないか
• マウスとキーボードの両方で挙動を確認したか

達成基準3.2.2への対応では、利用者が入力後の結果を予測でき、自分の意思で次の操作へ進める設計が基本になります。

当社では、Webアクセシビリティの導入と改善を支援するUUU ​ウェブアクセシビリティを提供しています。

サイトの入力フォームや画面遷移を見直したい方は、サービスの詳細をご覧ください。