WCAG 3.2.2: 入力時

このルールの意味

WCAG 3.2.2 On Input は理解可能という原則の一部であり、ガイドライン 3.2 予測可能 に属します。この達成基準は、ユーザーインターフェイスコンポーネントの設定を変更しても、ユーザーが事前にそのような挙動が起こると知らされていない限り、自動的にコンテキストの変化を引き起こしてはならないと定めています。

コンテキストの変化とは、1 つのウェブページ全体を一度に見られないユーザーを混乱させうる、ページ内容の大きな変化を指します。WCAG の仕様によると、コンテキストの変化には、ユーザーエージェント（ブラウザ）の変更、ビューポートの変更、フォーカスの変更、ページの意味を大きく変えるコンテンツの変更が含まれます。フォームの送信、新しいウィンドウのオープン、別ページへの移動は、いずれもコンテキストの変化に該当します。一方、アコーディオンの展開のように追加コンテンツを単に表示するだけのものは該当しません。

この達成基準は、特に UI コンポーネントの設定の変更に適用されます。たとえば、ラジオボタンの選択、チェックボックスのオン/オフ、<select> ドロップダウンでのオプション選択などであり、ボタンのクリックのようなコントロールの「起動」とは異なります。操作に明示的な起動ステップ（Enter キーの押下、送信ボタンのクリック）が必要な場合、一般的にはこの達成基準の対象にはなりません。問題となるパターンは、値を選択しただけで、何の警告もなく即座にナビゲーションや大きなページリロードが発生する場合です。

適合とみなされる例: ドロップダウンやチェックボックスを含んでいても、ユーザーの選択を処理するのに送信ボタンを使うフォームは、この達成基準に適合します。ページをリロードしたりフォーカスを大きく移動させたりすることなく、同一ページ上の結果をフィルタリングするドロップダウンも適合します。また、「言語を選択するとページが再読み込みされます」のように、特定の入力がコンテキストの変化を引き起こすことをページ上で事前にユーザーに知らせている場合も適合します。

不適合とみなされる例: 国や言語のセレクターで、オプションを選んだ瞬間に自動的に新しい URL にリダイレクトするものは不適合です。送信ボタンがないにもかかわらず、ラジオボタンを選択しただけで自動的にフォームを送信し、別ページへ移動してしまうフォームも不適合です。選択後に、何の警告もなくキーボードフォーカスをページ内の新しい領域へ移動させるオートコンプリートウィジェットも不適合です。

公式な例外: WCAG の仕様では、コンポーネントを使用する前にその挙動についてユーザーに知らせている場合、自動的なコンテキストの変化は許容されるとしています。この注意書きは、操作が行われる前に存在していなければならず、後から表示されるのでは不十分です。

なぜ重要か

予期しないコンテキストの変化は、ウェブ上でもっとも混乱を招く体験の 1 つであり、その影響は障害のあるユーザーにとってはさらに大きくなります。ページが予告なく突然ナビゲートされたり、再読み込みされたり、フォーカスが移動したりすると、ページ全体のレイアウトを視覚的に把握できないユーザーは完全に方向感覚を失ってしまいます。

スクリーンリーダー利用者は特に影響を受けやすいです。NVDA や JAWS を使う視覚障害のあるユーザーがドロップダウンでオプションを選択した直後にページが即座に再読み込みされたり別ページに移動したりすると、スクリーンリーダーは新しいページコンテキストを最初から読み上げます。ユーザーは自分がどこにいたのか、何をしていたのかを見失い、再びページ全体をナビゲートして状況を把握し直さなければなりません。これは単なる軽微な不便ではなく、そのタスクを自力で完了すること自体を不可能にしてしまう場合があります。

キーボードのみのユーザー（マウスを使えない運動障害のある人など）も同様の問題に直面します。Tab キーや矢印キーでフォームを操作している最中に、意図せずコンテキストの変化を引き起こしてしまうことがあります。細かな運動制御が難しい場合、意図しないページ遷移から立て直すには大きな労力が必要になります。

認知障害がある場合には、問題はさらに深刻になります。注意欠如、学習障害、記憶障害のあるユーザーは、何が起きているかを理解するために、予測可能で安定したインターフェイスに依存しています。突然のコンテキストの変化は、セッション中に構築してきたメンタルモデルを壊してしまい、最初からやり直さざるを得なくなったり、タスクを放棄してしまったりすることがよくあります。

前庭障害のあるユーザーは、ページが予期せず変化したとき、特にアニメーションやスクロール位置の変化を伴う場合に、身体的な不快感やめまいを感じることがあります。

具体的な実例として、トルコの EC サイトのチェックアウトページを考えてみましょう。ユーザーがドロップダウンから自分の県を選択したとき、その選択によって配送オプションを更新するためにページが即座に再読み込みされるとします。スクリーンリーダー利用者は、何が起きたのかの説明もなく、突然ページの先頭に戻されてしまうかもしれません。自分がどこにいたのか分からないまま、以前の入力内容が保持されているかどうかも分からず、すべてのフォームフィールドを再度たどる必要が出てきます。このような摩擦は、ユーザーが購入を完全に諦めてしまう原因になり得ます。

ユーザビリティと SEO の観点からも、予測可能な挙動をするページは直帰率が低くなります。ユーザーは苛立って離脱しにくくなり、検索エンジンのクローラーも、予期しないリダイレクトによってクロール経路が妨げられることなく、より確実にコンテンツをインデックスできます。

関連する axe-core のルール

WCAG 3.2.2 On Input は手動テストが必要です。axe-core のような自動化ツールは、この達成基準の違反を確実に検出することができません。なぜなら、問題となる挙動は文脈依存であり、特定の HTML 属性や構造の有無ではなく、インタラクションの背後にある意図に左右されるからです。ツールは <select> 要素に onchange イベントハンドラーが付いていることは検出できますが、そのハンドラーがコンテキストの変化を引き起こすかどうか、ユーザーに事前の警告があるかどうか、その結果としての挙動が実際に混乱を招くかどうかまでは判断できません。

• 手動テストが必要 — onchange によるナビゲーションパターン: 自動スキャナーは、JavaScript のイベントハンドラー（特に onchange）を持つ <select>、<input type='radio'>、<input type='checkbox'> 要素を検出できますが、それらのハンドラーがコンテキストの変化を引き起こすかどうかは判断できません。人間のテスターが各コントロールを実際に操作し、ページがナビゲートされたり、再読み込みされたり、フォーカスが大きく離れた領域に移動したり、ユーザーによる明示的な起動ステップなしに新しいウィンドウが開いたりしないかを観察する必要があります。
• 手動テストが必要 — 事前警告の有無と妥当性: コンテキストの変化が検出されたとしても、自動ツールは、ユーザーがそのコントロールを操作する前に十分な警告を受けていたかどうかを判断できません。人間が、事前の注意書きがコンポーネントに到達する前に見える位置にあるか、分かりやすい表現になっているか、実際に起こる挙動を説明しているかを確認しなければなりません。
• 手動テストが必要 — 入力後のフォーカス管理: 一部の違反は、明示的なナビゲーションではなく、入力の変更に伴ってフォーカスが予期しない場所に移動する形で現れます。自動ツールは、onchange イベントによってトリガーされるフォーカスの移動先を確実に追跡し、そのフォーカス位置が混乱を招くコンテキストの変化に当たるかどうかを判断することはできません。

テスト方法

1. 自動スキャンによるベースライン: ページに対して axe DevTools や Lighthouse を実行し、WCAG 3.2 に関連してフラグされた問題を特定します。3.2.2 自体は手動テストが必要ですが、axe は関連する問題（ラベルの欠如やフォーカス管理の問題など）を検出し、出発点を提供してくれる場合があります。特に <select> ドロップダウン、ラジオボタングループ、チェックボックスなど、すべてのフォームコントロールを記録し、手動での追跡調査対象とします。
2. 変更ハンドラーを持つすべての入力コントロールの特定: ブラウザの DevTools でページの JavaScript を調査するか、Event Listeners パネルを使用して、<select>、<input type='radio'>、<input type='checkbox'>、または onchange、oninput もしくは同等のイベントリスナーが付与されているカスタムウィジェットを特定します。
3. キーボードのみでの手動インタラクションテスト: キーボードだけを使用して（Tab で移動し、ラジオボタンや select のオプションには矢印キーを使用）、特定した各コントロールを操作します。オプションを選択したときに、ページがナビゲートされたり、再読み込みされたり、新しいウィンドウが開いたり、ページ内の大きく離れた部分にフォーカスが移動したりしないかを観察します。もしそうした挙動があれば、そのコントロールに到達する前に、目に見える警告が表示されていたかどうかを確認します。
4. NVDA + Firefox テスト: NVDA を起動した状態で Firefox を立ち上げます。NVDA の仮想カーソル（矢印キー）を使って各フォームコントロールに移動し、フォームモード（Enter または Space）で操作します。ドロップダウンやラジオグループでオプションを選択し、ページの読み込み、ナビゲーション、または大きなコンテキストの変化を示す予期しないアナウンスがないかを確認します。NVDA が新しいページタイトルや大きく異なる領域を読み上げないかどうかに注意します。
5. VoiceOver + Safari テスト（macOS/iOS）: VoiceOver を有効にし、VO+右矢印で各コントロールに移動します。ドロップダウンやチェックボックスを操作します。コンテキストの変化が起きた場合、VoiceOver は通常、新しいページやフォーカスの移動をアナウンスします。ユーザーが事前にそのことを知らされていたかどうかを判断します。
6. JAWS + Chrome テスト: JAWS を仮想カーソルモードで使用し、ページをナビゲートします。フォームコントロールを操作し、送信ボタンが起動されていないにもかかわらず、入力直後に JAWS がコンテキストの変化（ページタイトルの変更、新しい URL、読み上げ位置の移動）をアナウンスしないかどうかを確認します。
7. 視覚的な観察テスト: 支援技術を使用しない晴眼のユーザーとして、各ドロップダウンやラジオグループでオプションを選択し、ページが予期せずナビゲートされたり再読み込みされたりしないかを観察します。もしそうした挙動があれば、そのコントロールの前に表示されている説明テキストが、この挙動について警告しているかどうかを確認します。

修正方法

自動送信される select ドロップダウン — 不適切な例

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

自動送信される select ドロップダウン — 適切な例

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

ラジオボタンの自動送信パターン — 不適切な例

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

ラジオボタンの自動送信パターン — 適切な例

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

事前警告付きの言語切り替え — 適切な例

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

よくある間違い

• <select> 要素の onchange 属性に直接 window.location.href の代入を行うことで、送信ボタンなしに、ユーザーがオプションを選んだ瞬間にページ遷移が発生してしまう。
• ラジオボタンの onchange ハンドラー内で this.form.submit() を使用することにより、ユーザーが選択内容を確認する前に、ラジオボタンを選んだ瞬間にフォーム全体が送信され、別ページへ移動してしまう。
• DOM 上でコントロールの後に事前警告を配置することにより、スクリーンリーダー利用者やキーボード利用者が、そのコントロールが引き起こす挙動についての警告を聞いたり読んだりする前にコントロールに到達してしまう。
• 事前警告をツールチップやプレースホルダーテキストだけで表示することにより、支援技術に確実には伝わらず、スクリーンリーダー利用者が自分の入力の後にコンテキストの変化が起こることを全く知らされないままになってしまう。
• <div> や <ul> 要素を使ってカスタムドロップダウンウィジェットを構築することで、選択時に JavaScript でナビゲーションを発生させながらも、それがインタラクティブなコントロールであり 3.2.2 の観点から精査が必要であることを、テスターやアクセシビリティオーバーレイが認識できるようなセマンティック構造を欠いている。
• フォームの最後のフィールド（たとえば PIN や OTP 入力）で、必要な文字数に達した時点で自動的にフォーム送信を行うことで、ユーザーにその挙動が起こると知らせることなくコンテキストの変化を引き起こしてしまう。
• チェックボックスがオンになったことに応じてモーダルダイアログや新しいブラウザウィンドウを開くことで、事前の注意書きなしにビューポートとフォーカスを大きく移動させてしまう。これはコンテキストの変化に該当します。
• 予測可能なページ内コンテンツの更新とコンテキストの変化を混同することにより、すでに許容されるインタラクション（ライブ検索フィルターなど）の周りに不要な送信ボタンを追加して UI を煩雑にしてしまう。インラインで行われる、混乱を招かない更新には送信ステップが不要であることをチームが理解しておく必要があります。
• 自動アクセシビリティスキャンだけに頼ることで、自動ルールが何もフラグしなかったからという理由で 3.2.2 を適合とみなしてしまい、この達成基準が要求する必須の手動キーボードテストやスクリーンリーダーテストを実施しない。
• 検索結果リストのソートやフィルタリングに使われる <select> に、コンテキストの変化を引き起こす onchange ハンドラーを適用することで、AJAX 更新ではなくページ全体の再読み込みを行い、その再読み込みが選択と同時に起こることをユーザーに知らせないままにしてしまう。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、WCAG 2.2 に基づく必須のウェブアクセシビリティ要件を定めています。WCAG 3.2.2 On Input はレベル Aの達成基準であり、この通達における最低限の適合基準を表します。つまり、対象となる組織にとって、この達成基準への準拠は任意ではなく法的に義務付けられています。

通達では、2 段階の実施スケジュールが定められています。公共機関（省庁、自治体、国立大学、政府機関など）は、通達の公布から1 年以内にレベル A への完全な適合を達成しなければなりません。規制の対象となる民間部門の組織には、適合のための2 年間の猶予期間が与えられています。

通達の下で明示的に対象とされている組織種別は次のとおりであり、したがって自らのデジタルサービスが WCAG 3.2.2 に準拠していることを確保しなければなりません。EC プラットフォーム、あらゆるレベルの公共機関、銀行や金融機関、病院や医療提供者、20 万人以上の加入者を持つ通信会社、認可を受けた旅行代理店、民間の交通事業者、国民教育省（MoNE）に認可された私立学校です。

これらの組織にとって、WCAG 3.2.2 の違反（たとえば、選択と同時に自動リダイレクトする銀行ポータルの言語セレクターや、診療科のラジオボタンを選択しただけで自動送信されてしまう病院の予約フォームなど）は、規制への直接的な不適合を意味します。トルコには多くの障害のあるユーザーが存在し、政府のデジタルサービスが市民の公共サービス利用の主要なチャネルになりつつあることを踏まえると、この達成基準を無視することの実務的なリスクは非常に大きいと言えます。

通達の対象となる組織は、QA の中で WCAG 3.2.2 のテストを必須の監査ステップとして扱うべきです。自動ツールではこの達成基準の違反を検出できないため、訓練を受けたアクセシビリティ専門家による手動テスト（キーボード操作、NVDA や JAWS を用いたスクリーンリーダーの挙動、すべての onchange ベースのインタラクションの明示的なレビューを含む）をコンプライアンスプロセスに組み込む必要があります。テスト結果や、（事前警告を伴う）許容された例外を文書化しておくことは、規制当局に対して適切な対応を行っていることを示すうえで有用です。