WCAG 3.2.5: 要求に応じた変更

この規定の意味

WCAG 3.2.5「要求による変更」は、「理解可能」という原則の下にあるレベルAAAの達成基準です。これは、コンテキストの変更は必ずユーザーによって開始されなければならず、システムによって自動的にトリガーされてはならないと定めています。「コンテキストの変更」はWCAGで、ユーザーがページ全体を一度に閲覧できない場合に、ユーザーが気づかないうちに方向感覚を失わせるおそれのある、ウェブページ内容の大きな変化と定義されています。これには、ユーザーエージェント（ブラウザ）、ビューポート、フォーカス、またはページの意味を大きく変えるコンテンツの変更が含まれます。

具体的には、この達成基準は、明示的なユーザーの要求なしにコンテキストの変更を引き起こすあらゆる仕組みを禁止します。これは、3.2.1（フォーカス時）および3.2.2（入力時）の要件を拡張し、自動的なコンテキスト変更が起こりうる残りのすべてのシナリオを対象とします。たとえば、自動リフレッシュするページ、自動的に進んで別の場所へ移動するカルーセル、短い遅延を伴うmetaリダイレクトタグ、フォームフィールドの入力完了時にJavaScriptでナビゲーションをトリガーする仕組み、ユーザーの働きかけなしに新しいウィンドウやタブを開く動作などが含まれますが、これらに限定されません。

この達成基準に適合するには、次の2つの条件のいずれかを満たす必要があります。コンテキストの変更が、ボタンやリンクの起動など、明示的で意図的なユーザー操作によってのみトリガーされるか、あるいは自動的なコンテキスト変更が起こる前に、それをオフにできる仕組みがユーザーに提供されていることです。たとえば、ページが30秒ごとに自動リフレッシュされ、新しいコンテンツへ移動する場合、そのままでは不適合です — ただし、最初のリフレッシュが起こる前にその動作を無効化できる、明確にラベル付けされたコントロールが存在する場合を除きます。事後的に警告を表示するだけでは不十分です。

この達成基準は、すべてのインタラクティブかつ動的なウェブコンテンツに広く適用されます。よく影響を受ける要素や挙動には、<meta http-equiv='refresh'>によるリダイレクト、タイマーでトリガーされるJavaScriptのwindow.locationやhistory.pushStateの呼び出し、新しいURLへ移動する<select>要素上のonchangeイベントハンドラ、自動送信されるフォーム、フォーカスによってトリガーされるナビゲーション、ユーザー入力なしに自動スクロールしたりスライドを進めたり、表示中のコンテンツセットを変更したりするウィジェットなどがあります。

重要な公式の例外として、コンテキストの変更が、ユーザーが明示的かつ自覚的に設定した構成に応じて行われる場合 — たとえば、ユーザー設定パネルで「1分ごとに自動リフレッシュ」を選択した場合 — その自動動作はユーザーが要求したものなので許容されます。重要な違いは、ユーザーが自動動作を有効にすることについて、情報に基づいた意図的な選択を行ったのか、それとも予期せず遭遇したのかという点です。

なぜ重要か

予期しないコンテキストの変更は、ウェブ上でもっとも方向感覚を失わせる体験のひとつであり、その影響は、障害のあるさまざまなユーザーグループによって大きく異なります。

スクリーンリーダーに依存する視覚障害のあるユーザーにとって、突然のページ遷移やコンテンツのリフレッシュは、読み上げカーソルがページ上のまったく別の位置に飛んだり、何の告知もなく先頭にリセットされたりする原因になります。長い記事の途中を読んでいる最中にページが自動的に新しいURLへリダイレクトされると、ユーザーは完全に位置を見失い、何が起きたのか、どうやって元に戻ればよいのか理解できないかもしれません。NVDA、JAWS、VoiceOverのようなスクリーンリーダーは、ページレベルのナビゲーションイベントを常に一貫したタイミングで告知するとは限らないため、ユーザーは自分がどこにいて何が変わったのか混乱する可能性があります。

キーボード、ヘッドポインタ、スイッチデバイス、視線入力技術などで操作する運動障害のあるユーザーにとって、予期しないフォーカスの移動は致命的になりえます。たとえば、フォームが前のフィールドの入力完了と同時に自動的に次のフィールドへ進むなど、ユーザー操作なしにフォーカスがプログラム的に移動すると、ユーザーは自分の位置を見失い、システムがどこへ連れて行ったのかを見つけるために、骨の折れる再ナビゲーションを強いられます。入力デバイスの1回の操作に大きな身体的負担がかかるユーザーにとって、この再ナビゲーションは実質的なアクセシビリティ障壁となります。

注意欠如障害、記憶障害、不安障害などを含む認知障害のあるユーザーは、予期しない変化に特に脆弱です。自動的なページの変更は、インターフェースに対する彼らのメンタルモデルを壊してしまいます。説明文を読むために一時停止し、その後ページがリロードされていることに気づいたユーザーは、混乱したり動揺したりしやすくなります。このような中断は、取引を完了したり情報を自力で取得したりすることを不可能にする場合があります。

前庭障害のあるユーザーにとって、急激で予期しない視覚的変化 — たとえばナビゲーションもトリガーする自動進行カルーセルなど — は、めまいや吐き気などの身体症状を引き起こすことがあります。診断された障害のない晴眼者であっても、予測可能なインターフェースから恩恵を受けます。研究では一貫して、予期しないナビゲーションがすべてのユーザーグループにおいてエラー率とタスク放棄率を高めることが示されています。

具体的な実例として、あるトルコのECサイトでは、ユーザーがドロップダウンで値を選択した瞬間に商品フィルタフォームを自動送信し、新しい検索結果のURLへ移動します。複数の条件を選択するためにフィルタをTabキーで移動しているキーボード専用ユーザーは、最初のオプションを選択した途端にページがリロードされ、フィルタパネルが折りたたまれてしまうことに気づきます。ユーザーはパネルを再度開き、元の位置まで再ナビゲーションし、再度試さなければならず、その繰り返しによって機能が完全に使えなくなる可能性があります。世界保健機関によると、世界で約13億人が何らかの障害を抱えており、このようなパターンは彼らをデジタルサービスから不釣り合いに排除してしまいます。

ユーザビリティとSEOの観点からも、自動リダイレクトや自動リフレッシュを行うページは、予期しない挙動に遭遇したユーザーが離脱しやすいため、直帰率が高くなる傾向があります。検索エンジンは、クローラとユーザーのセッションで異なる予期しないリダイレクトを行うサイトにペナルティを課すこともあるため、3.2.5への適合は、良好な技術的SEOの衛生状態とも整合します。

関連するaxe-coreルール

WCAG 3.2.5は、コンテキストの変更がユーザーによって開始されたのか、システムによって自動的にトリガーされたのかを自動ツールが確実に検出できないため、手動テストが必要です。この区別は、ユーザーの意図やインタラクションフローの理解に依存しており、人間の判断を要します。axe-coreルールで、この達成基準の範囲全体に直接対応するものはありません。ただし、自動および半自動テストに関して、次の点が考慮されます。

• 直接対応するaxe-coreルールはなし（手動テストが必要）： axe-coreやLighthouseは、JavaScriptによるナビゲーション、自動リフレッシュするページ、自動送信されるフォームを検出できません。これらの挙動は、実行時の状況、タイミング、ユーザーインタラクションの状態に依存しており、静的またはスクリプトによるスキャンでは再現できないためです。ある時点のDOMを観察しているスキャナは、window.location.hrefがタイマーに応じて設定されているのか、ユーザーのクリックに応じて設定されているのかを判断できません。
• meta refreshの検出（部分的な自動化が可能）： いくつかの自動ツール（旧来のaxeルールやブラウザ拡張機能を含む）は、ドキュメントのhead内にある<meta http-equiv='refresh' content='0; url=...'>の存在をフラグ付けできます。ただし、axe-coreにはバージョン4.10において、これ専用の本番ルールはありません。自動リダイレクトが発生していないことを確認するには、ページソースとHTTPヘッダーの手動確認が必要です。
• イベントリスナーの分析（手動）： ナビゲーションをトリガーする<select>要素上のonchangeハンドラを検出するには、手動のコードレビューや、ブラウザの開発者ツールを用いたイベントリスナーの確認が必要です。自動スキャンはレンダリング後のDOMを観察しますが、各要素と対話した結果としての挙動までは観察しません。
• フォーカス管理の検証（手動）： フォーカスが、ユーザー操作ではなくシステム主導のコンテキスト変更の結果として予期せず移動するかどうかを確認するには、テスターが実際にページと対話し、キーボードと必要に応じてスクリーンリーダーを用いてリアルタイムにフォーカスの挙動を観察する必要があります。

テスト方法

1. 自動スキャン（ベースライン）： ページに対してaxe DevToolsまたはLighthouseを実行し、リダイレクトやフォーカス管理に関連してフラグ付けされた問題を検出します。Chrome DevToolsでは、Lighthouseパネルを開き、Accessibility監査を実行します。axe DevTools拡張機能では、「Analyze」をクリックして結果を確認します。自動テストで問題が検出されなかったとしても、それだけで3.2.5への適合が確認できるわけではなく、手動テストが不可欠であることに注意してください。
2. meta refreshの確認： ブラウザでページを開き、右クリックして「ページのソースを表示」を選択し、http-equivまたはrefreshを検索（Ctrl+F / Cmd+F）します。URLを含む、または72時間を超える遅延を持ちながら、それを無効化する仕組みのない<meta http-equiv='refresh'>タグがあれば、不適合となります。
3. 時間経過に伴うページ挙動の観察： ページを読み込み、2〜5分間何も操作せずに待ちます。自動的なコンテンツの変更、ページのリロード、ナビゲーションイベント、新しいウィンドウのオープンがないか観察します。ブラウザのアドレスバーやタブタイトルに変化がないかも確認します。ユーザーの入力なしに何かが起これば、この達成基準に違反している可能性が高いです。
4. フォームコントロールとドロップダウンのテスト： キーボードのみ（Tab、矢印キー、Enter、Space）を使って、各<select>、ラジオボタングループ、チェックボックスに移動します。値を変更し、送信ボタンを起動する前に、選択と同時にナビゲーションや大きなコンテンツ変更が起こるかどうかを観察します。もしそうであれば、その要素に到達する前にこの挙動を無効化するコントロールが提供されていない限り、不適合となります。
5. NVDA + Firefoxでのテスト： NVDAを有効にし（ブラウズモードにはInsert+Space）、矢印キーとTabでページを移動します。フォーム操作を行い、フォーカスや読み上げ位置が予期せず移動しないか確認します。ページ変更の告知を聞き取ります。スクリーンリーダーが新しいページを告知したり、ユーザーの明示的な操作なしに仮想カーソルがリセットされたりする場合、コンテキストの変更が起きていることを示します。
6. VoiceOver + Safari（macOS/iOS）でのテスト： VoiceOverを有効にし（MacではCmd+F5）、VO+矢印キーで移動します。コントロールと対話し、予期しないページの告知やカーソルリセットがないかを確認します。iOSでは、要素をスワイプで移動し、自分が起動していないのにアクセシビリティツリー構造に突然の変化がないかを確認します。
7. JAWS + Chromeでのテスト： JAWSを有効にし、Tabと矢印キーで移動します。フォームを送信し、動的ウィジェットと対話します。フォーカスと仮想カーソルの位置が常に予測可能で、ユーザーの制御下にあることを確認します。
8. JavaScriptソースの確認： Chrome DevToolsでSourcesパネルを使用するか、検索（Ctrl+Shift+F）でwindow.location、location.href、history.pushState、ナビゲーション呼び出しと組み合わされたsetTimeout、およびonchange属性などのパターンを探します。これらがタイマーやシステムイベントによってトリガーされているのか、明示的なユーザー操作によってトリガーされているのかを評価します。
9. 自動進行カルーセルやスライダーの確認： ページ上のカルーセル、スライドショー、ローテーションバナーを特定します。それらが自動的に進行するかどうかを確認します。自動進行する場合、自動進行時に新しいページへのリンクなどナビゲーションもトリガーするかどうかを確認します。表示コンテンツのみを変更する自動進行カルーセルは2.2.2の対象となる場合がありますが、ナビゲーションも引き起こす場合は3.2.5の対象となります。

修正方法

meta refreshによるリダイレクト — 不適切な例

<!-- このmetaタグは5秒後にユーザーを自動的にリダイレクトします。
     ユーザーはこのナビゲーションを制御できません。 -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>まもなく別のページへ移動します...</p>
</body>

meta refreshによるリダイレクト — 適切な例

<!-- 自動リダイレクトを完全に削除します。
     ユーザーが自分のタイミングで起動できる明示的なリンクを提供します。
     これにより、ナビゲーションのタイミングを完全にユーザーが制御できます。 -->
<head>
  <!-- meta refreshタグは使用しない -->
</head>
<body>
  <p>このページは移動しました。新しい場所はこちらをご覧ください。</p>
  <a href='https://example.com/new-page'>更新されたページへ移動</a>
</body>

変更時に自動ナビゲーションするselect要素 — 不適切な例

<!-- onchangeハンドラが、ユーザーが値を選択した直後にナビゲーションを行います。
     キーボードユーザーは、ナビゲーション前に選択内容を確認することができません。 -->
<label for='category'>カテゴリを選択:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>選択してください...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

変更時に自動ナビゲーションするselect要素 — 適切な例

<!-- select要素は、変更時にナビゲーションをトリガーしなくなりました。
     明確にラベル付けされたボタンが、いつ先へ進むかをユーザーに明示的に制御させます。
     このパターンは、キーボードユーザーやスクリーンリーダーユーザーを含むすべてのユーザーに有効です。 -->
<label for='category'>カテゴリを選択:</label>
<select id='category'>
  <option value=''>選択してください...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>カテゴリへ移動</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

ナビゲーションをトリガーする自動進行カルーセル — 不適切な例

<!-- このカルーセルは3秒ごとに自動進行し、各スライドは新しいページへのリンクになっています。
     スライドが自動的に切り替わると、そのスライド上のどこをクリックしても予期せずナビゲーションが起こります。 -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

ナビゲーションをトリガーする自動進行カルーセル — 適切な例

<!-- カルーセルは自動進行しなくなりました。
     スライド間および遷移先ページへのナビゲーションは、完全にユーザーが制御します。
     一時停止と前/次ボタンにより、2.2.2と3.2.5の両方を満たします。 -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='前のスライド' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='次のスライド' onclick='nextSlide()'>›</button>
</div>

よくある間違い

• <select>要素でonchangeを使用して、即座にwindow.location.hrefによるナビゲーションをトリガーすることにより、別の送信ボタンを提供せず、キーボードユーザーに選択内容を確認する前の即時ページ変更を強いる。
• セッションタイムアウト処理のために<meta http-equiv='refresh' content='30; url=...'>を実装することにより、ユーザーがセッションを延長したり、自動リダイレクトを発火前に無効化したりする仕組みを提供しない。
• setTimeoutやsetIntervalを使用してlocation.replace()やhistory.pushState()を呼び出すことにより、自動保存とURL更新のような「利便性」機能を実装し、ユーザーを予期せず新しいブラウザ履歴状態へ移動させてしまう。
• タイマーや自動プロセスによってトリガーされるwindow.open()を使用して新しいブラウザウィンドウやタブを開くことにより、クリックやキー押下といったユーザーのジェスチャではなく自動的にポップアップを開き、多くのブラウザにブロックされるだけでなく、常に望まれないコンテキストの変更を引き起こす。
• oninputでトリガーされるdebounce関数内でform.submit()を使用して検索フォームやフィルタフォームを自動送信することにより、遅延があったとしても、代替の制御手段として目に見える送信ボタンを提供しない。
• 最初の自動ナビゲーションがすでに発生した後になって初めて表示される「自動進行をオフにする」コントロールを提供することにより、オプトアウトの仕組みを、最初のコンテキスト変更が起こる前ではなく後にしか利用できないようにしてしまう。
• コンテンツの更新とコンテキストの変更を混同すること。テキストをその場で更新するライブリージョン（例：株価ティッカー）はコンテキストの変更ではなく許容されますが、ページ全体の表示を自動的に置き換えたり、新しいURLへナビゲーションしたりすることはコンテキストの変更であり、この達成基準の対象となります。
• 自動ナビゲーションの前に警告ダイアログを表示すれば達成基準を満たすと誤解すること。そのダイアログ自体が自動的にトリガーされ、キーボードフォーカスを閉じ込めてしまう場合があります。ユーザーは単に警告されるだけでなく、その挙動を無効化できなければなりません。
• onblurやonfocusoutイベントハンドラを使用してフォーム検証と自動リダイレクトをトリガーし、ユーザーが明示的に先へ進むことを要求していないのに、エラーページやマルチステップフォームの別のステップへ移動させてしまう。
• スクロール量や滞在時間に基づいてhistory.pushStateを更新するシングルページアプリケーション（SPA）のルーティングを導入すること。これは分析目的で使われることがありますが、ユーザーが開始していないコンテキストの変更にあたり、URL状態に結びついた仮想バッファを使用するスクリーンリーダーユーザーを混乱させる可能性があります。

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

トルコの大統領通達2025/10は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い主体に対し、WCAG 2.2に整合した必須のウェブアクセシビリティ要件を定めています。この通達は、公的機関・政府機関、ECプラットフォーム、銀行・金融機関、病院・医療提供者、20万以上の加入者を持つ通信会社、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校を対象としています。

通達は、対象となる組織に対し、WCAG 2.2レベルAAでの適合をベースライン標準として義務付けています。WCAG 3.2.5「要求による変更」はレベルAAAの達成基準であり、そのため通達が定める最低限の法的要件として直接求められているわけではありません。しかし、これはトルコの文脈においてこの達成基準が無関係であることを意味するものではありません。

対象組織のいくつかのカテゴリには、3.2.5へのAAA適合を追求する強い実務的理由があります。大規模なユーザーベースを持つECプラットフォームや旅行代理店は、動的フィルタリング、自動サジェストナビゲーション、プロモーションカルーセルなど、まさにこの達成基準に違反しやすいパターンをしばしば実装しています。予期しないナビゲーションがエラーやセキュリティ上の懸念を引き起こしうる機密性の高い取引を扱う銀行や金融サービス提供者は、すべてのコンテキスト変更が明示的にユーザー制御であることを保証することで大きな恩恵を受けます。ユーザーが脆弱な状態にあり、予測可能で落ち着いたインターフェースを必要とする医療ポータルも、3.2.5のようなAAA達成基準によってAAベースラインを上回ることが、倫理的なコミットメントと実務的なユーザー安全の両面で重要となるカテゴリです。

通達に基づき監査や報告義務の対象となる公的機関は、自らの適合レベルを文書化する必要があります。レベルAAAは法的に義務付けられてはいませんが、それを達成し、文書化することは、最高水準のアクセシビリティへのコミットメントを示す防御可能な記録となります。社会保障機関（SGK）や障害者支援サービスなど、障害のあるユーザーを主たる、あるいは重要な対象とする組織にとって、レベルAAA適合を目指すことは、この規制の精神と特に合致します。

WCAG 3.2.5に自主的に適合する組織は、欧州連合のアクセシビリティ整合の文脈でも有利な立場を得ます。トルコのEU加盟国とのデジタル貿易関係では、調達やパートナーシップの条件としてアクセシビリティが重視される傾向が強まっているためです。2025年6月に発効した欧州アクセシビリティ法（EAA）は、EU市場で提供される製品やサービス — トルコ企業が欧州のユーザーに提供するものを含む — に適用されており、3.2.5と整合するユーザー制御型のインタラクションパターンを強く推奨しています。

実務的には、AccsibleのオーバーレイSDKを実装するトルコの開発チームは、動的に挿入されるウィジェット、設定パネル、支援コントロールが、それ自体としてユーザーが開始していないコンテキストの変更を導入しないようにする必要があります。SDKのツールバーや設定パネルは、明示的なユーザー操作にのみ応じて開閉されなければならず、オーバーレイを通じてトリガーされるナビゲーションやコンテンツ更新は、すべてユーザーが開始したものでなければなりません。これにより、アクセシビリティソリューション自体が、解消しようとしている障壁を新たに生み出さないようにできます。