WCAG 達成基準 · Level AAA

WCAG 2.3.3: インタラクションによるアニメーション

WCAG 2.3.3 は、ユーザーの操作によって開始されるモーションアニメーションについて、それが機能や伝達される情報にとって不可欠でない限り、無効化できるようにすることを求めています。これは、モーションが前庭障害を誘発し、人口のかなりの割合にめまい、吐き気、方向感覚の喪失を引き起こす可能性があるため重要です。

このルールの意味

WCAG 2.3.3「インタラクションによるアニメーション」は、原則「操作可能」の下にあるレベルAAAの達成基準です。これは、インタラクションによってトリガーされるモーションアニメーションについて、機能や伝達される情報にとって本質的でない限り、ユーザーがそれを無効化できるようにすることを求めています。この達成基準は、クリック、スクロール、ホバー、フォーカス、その他あらゆる形態のインタラクションによって開始されるアニメーションに適用されます。ページ読み込み時に自動再生されるアニメーションには適用されません(それらは 2.2.2「一時停止、停止、非表示」など別の達成基準の対象となる場合があります)。

ここでの重要な概念はモーションアニメーションです。これには、パララックススクロール効果、ページ遷移アニメーション、要素のスライドやズーム、スピナーなどのインジケーター、その他ユーザーの操作の直接的な結果として発生するあらゆる動きが含まれます。単純な不透明度のフェードや色の変化は、前庭反応を引き起こしうる空間的な動きを伴わないため対象外です。ここでの区別は、空間的な移動(害を引き起こしうる)と、空間的な位置の変化を伴わない見た目の変化(一般的には害を引き起こさない)との違いです。

適合とみなされるには、ユーザーがそのようなアニメーションを無効化しても、同じコンテンツや機能へのアクセスを失わない、信頼できる仕組みが必要です。最も広く受け入れられている手法は、OSレベルのprefers-reduced-motionメディアクエリを尊重することです。これは、モーションを減らすというユーザーのシステム設定を反映します。代替として、インターフェース内の目立つ位置(設定パネルやアクセシビリティウィジェットなど)にサイトレベルのトグルを設置する方法も、このトグルがセッションをまたいで保持され、かつ見つけやすい場合には達成基準を満たします。

本質的(essential)例外は範囲が狭いものです。アニメーションが本質的とみなされるのは、それを取り除くと情報や機能が根本的に変わってしまい、かつ同等の非アニメーションの代替手段が存在しない場合に限られます。コンテンツ取得中であることを示す唯一の視覚的手がかりが回転するローディングインジケーターである場合などは該当しうる一方、ユーザーのスクロールに合わせて動く装飾的なパララックス背景画像は、デザイン上重要な要素であっても本質的とはみなされません。

この達成基準は、アニメーションを完全に削除することを求めているわけではなく、それらを無効化するための仕組みが存在することを求めています。その仕組みが有効化された状態でもコンテンツは完全に利用可能でなければならず、非アニメーションの代替手段が同じ情報を提供するか、同じ機能を果たす必要があります。

なぜ重要か

前庭障害(内耳と脳に影響し、バランスや眼球運動を制御する状態)は、世界人口のかなりの割合に影響を与えています。Vestibular Disorders Association によると、米国では40歳以上の成人のおよそ35%が何らかの前庭機能障害を経験しています。世界的にも、良性発作性頭位めまい症(BPPV)、メニエール病、前庭性片頭痛などの状態が数千万人に影響しています。これらの人々にとって、画面上の動きは、めまい、回転性めまい、吐き気、頭痛、重度の場合には一時的な行動不能といった即時の身体症状を引き起こすことがあります。

前庭性片頭痛を持つユーザーが旅行予約サイトを訪れる状況を考えてみてください。そのサイトでは、ユーザーがスクロールするとヒーロー画像がページコンテンツとは異なる速度で動く、全画面のパララックススクロール効果を使用しています。スクロールを始めて数秒以内に、そのユーザーは激しいめまいと吐き気を感じます。予約を完了できず、サイトを完全に離れざるを得ません。これは認知的な障壁や運動障害のためではなく、画面上の動きに対する身体的反応のためです。これこそが、WCAG 2.3.3 が防ごうとしている現実の被害です。

前庭障害以外にも、モーションアニメーションは、持続的またはトリガーされる動きが気になって仕方がない注意欠如障害のあるユーザーや、予期しない動きが苦痛を引き起こしうる不安障害のあるユーザーに悪影響を与える可能性があります。脳震盪や外傷性脳損傷から回復中の人々も、視覚的な動きに非常に敏感です。診断された状態のないユーザーであっても、長時間のセッションでは過度なアニメーションを疲れやすいと感じることがあります。

ユーザビリティとビジネスの観点からも、モーション削減の設定を尊重することは、感受性の高いユーザーにおけるタスク完了率やセッション時間の向上と相関しています。システムレベルの設定を尊重することは、プロダクトがよく設計され、ユーザーのニーズに配慮していることのシグナルにもなり、信頼構築につながります。カート放棄が収益に直結するeコマースにおいては、不必要なアニメーションによる障壁を取り除くことは、具体的な商業的メリットとなります。

関連する axe-core のルール

WCAG 2.3.3 は手動テストを必要とします。この達成基準に直接対応する axe-core の自動ルールは存在せず、これは見落としではなく意図的な設計です。自動ツールが違反を確実に検出できない理由は本質的なものです。

  • 自動化で検出できない理由: モーションアニメーションを検出するには、ユーザーインタラクションに応じたページの視覚的レンダリングを時間経過とともに理解する必要があります。自動アクセシビリティスキャナーは、静的または簡易レンダリングされたDOMスナップショットを解析するだけであり、スクロールやクリックなどのユーザーインタラクションをシミュレートして、その後にCSSトランジションやJavaScript駆動のアニメーションが空間的な動きを生み出すかどうかを観察することはありません。仮にスキャナーがCSSの animation や transition プロパティの存在を検出できたとしても、そのアニメーションが空間的な移動(前庭反応を引き起こしうる)を伴うのか、単なる不透明度のフェード(そうではない)なのかを判断することはできません。さらに、スキャナーは prefers-reduced-motion メディアクエリがアニメーションを抑制するよう正しく実装されているか、サイトレベルのトグルが存在するか、そのアニメーションが本当に本質的かどうかを判断することもできません。これらすべての判断には、レンダリングされた体験を観察し、ページとインタラクトし、その結果を評価できる人間のテスターが必要です。
  • 手動検査で確認すべき点: テスターは、空間的な動きを生み出すすべてのCSSプロパティ—transform: translateX/Y/Ztransform: scaletransform: rotatetop/left/margin のトランジション、要素を空間的に移動させる animation のキーフレーム—を特定し、それぞれが prefers-reduced-motion: reduce メディアクエリまたはユーザー制御のトグルの背後にあることを確認しなければなりません。GSAP、Framer Motion などのライブラリや、独自の requestAnimationFrame ループを用いた JavaScript 駆動のアニメーションも同様の厳密さでレビューする必要があります。

テスト方法

  1. OSレベルでモーション削減を有効にする: macOS では「システム設定」>「アクセシビリティ」>「ディスプレイ」で「動きを減らす」を有効にします。Windows 11 では「設定」>「アクセシビリティ」>「視覚効果」で「アニメーション効果」をオフにします。iOS では「設定」>「アクセシビリティ」>「動作」で「視差効果を減らす」を有効にします。Android では「設定」>「アクセシビリティ」>「アニメーションを削除」を有効にします。これにより、prefers-reduced-motion: reduce メディアクエリが有効になります。
  2. 自動スキャンをベースラインとして実行する: 対象ページに対して Chrome DevTools で axe DevTools または Lighthouse を開きます。どちらのツールも WCAG 2.3.3 の違反を直接フラグ付けすることはありませんが、関連する問題を表面化させる場合があり、テスト環境が機能していることの確認にもなります。文脈のために、アニメーション関連の検出結果があればメモしておきます。
  3. OSのモーション削減を有効にした状態でページとインタラクトする: ページをゆっくりスクロールし、ボタン、ナビゲーショントグル、ドロップダウン、カルーセル、モーダルなどのインタラクティブ要素をクリックします。要素にホバーします。キーボードでタブ移動します。空間的なモーションアニメーションが再生され続けていないか観察します。アニメーションが抑制されていれば、OS設定経由のパスについては適合とみなせます。
  4. OSのモーション削減を無効にして再テストする: OSのモーション削減をオフにした状態で、すべてのインタラクションを繰り返します。ユーザーインタラクションによってトリガーされるすべてのモーションアニメーションを特定します。それぞれについて、トリガーとなる操作と観察されたアニメーションの内容を記録します。
  5. サイトレベルのアニメーショントグルを確認する: OSのモーション削減が尊重されていない場合、アクセシビリティウィジェット、設定メニュー、フッターなどにあるサイトレベルのコントロールを探します。それを有効にし、すべてのインタラクションテストを繰り返して、モーションが抑制されることを確認します。
  6. CSS と JavaScript における prefers-reduced-motion の実装を確認する: DevTools を開き、Sources または Elements パネルでスタイルシートファイル内の prefers-reduced-motion を検索します。特定したすべてのモーションアニメーションがこのメディアクエリによって制御されていることを確認します。Chrome DevTools ではメディアクエリをエミュレートできます。「Rendering」タブ(More Tools > Rendering)を開き、「Emulate CSS media feature prefers-reduced-motion」を「reduce」に設定します。ブラウザを再起動せずにアニメーションが抑制されることを確認します。
  7. 本質的例外を評価する: モーション削減が有効な状態で残っている各アニメーションについて、それが本当に本質的かどうかを評価します—それを削除すると、非アニメーションの同等手段が存在しない情報や機能が失われるかどうか。各判断について、その理由を文書化します。
  8. スクリーンリーダーでの検証(NVDA + Firefox、JAWS + Chrome、VoiceOver + Safari): 部分的な視力を持つスクリーンリーダーユーザーも、前庭への影響から免れるわけではありません。スクリーンリーダーを有効にし、OSのモーション削減を有効にした状態で、キーボードのみを使ってページを操作します。フォーカスイベントやキーボード操作によってトリガーされるアニメーションで、モーション削減の配慮がないものが発生しないことを確認します。

修正方法

パララックススクロール効果 — 不適切な例

<!-- スクロール時に背景がコンテンツと異なる速度で動く -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* スクロール時にパララックスを生成 */
    height: 100vh;
  }
</style>
<div class='hero'></div>

パララックススクロール効果 — 適切な例

<!-- ユーザーがモーション削減を希望する場合はパララックスを無効化 -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* デフォルトではパララックス */
    height: 100vh;
  }

  @media (prefers-reduced-motion: reduce) {
    .hero {
      background-attachment: scroll; /* 静的な背景。空間的な動きなし */
    }
  }
</style>
<div class='hero'></div>

インタラクティブ要素のCSSトランジション — 不適切な例

<!-- モーション削減への配慮なしに、クリック時にボタンがスライド&拡大縮小 -->
<style>
  .btn {
    transition: transform 0.4s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }
</style>
<button class='btn'>Submit</button>

インタラクティブ要素のCSSトランジション — 適切な例

<!-- 空間的な transform を抑制し、状態はモーションなしの不透明度変化で伝える -->
<style>
  .btn {
    transition: transform 0.4s ease, opacity 0.2s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }

  @media (prefers-reduced-motion: reduce) {
    .btn {
      transition: opacity 0.2s ease; /* 非空間的な変化のみ保持 */
    }
    .btn:active {
      transform: none; /* 動きなし */
      opacity: 0.75;   /* 視覚的に状態を伝える */
    }
  }
</style>
<button class='btn'>Submit</button>

JavaScript アニメーションライブラリ(GSAP)— 不適切な例

<!-- ユーザーのモーション設定に関係なく、クリック時にGSAPのトゥイーンが発火 -->
<script>
  document.querySelector('#open-modal').addEventListener('click', () => {
    gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
  });
</script>

JavaScript アニメーションライブラリ(GSAP)— 適切な例

<!-- 空間的アニメーションを実行する前に matchMedia を確認し、即時表示にフォールバック -->
<script>
  const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

  document.querySelector('#open-modal').addEventListener('click', () => {
    if (prefersReducedMotion) {
      /* 空間的な動きをスキップし、モーダルを即座に表示するだけにする */
      gsap.set('#modal', { opacity: 1, y: 0 });
    } else {
      gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
    }
  });
</script>

サイトレベルのアニメーショントグル(アクセシビリティウィジェット)— 適切なパターン

<!-- ユーザー設定を localStorage に保存し、<html> にクラスを付与 -->
<button id='toggle-motion' aria-pressed='false'>Reduce Motion</button>

<style>
  /* デフォルト: アニメーション有効 */
  .card { transition: transform 0.3s ease; }
  .card:hover { transform: translateY(-8px); }

  /* ウィジェットでユーザーがオプトアウトした場合 */
  html.reduce-motion .card {
    transition: none;
  }
  html.reduce-motion .card:hover {
    transform: none;
  }
</style>

<script>
  const btn = document.getElementById('toggle-motion');
  const stored = localStorage.getItem('reduceMotion') === 'true';

  if (stored) {
    document.documentElement.classList.add('reduce-motion');
    btn.setAttribute('aria-pressed', 'true');
  }

  btn.addEventListener('click', () => {
    const isActive = document.documentElement.classList.toggle('reduce-motion');
    btn.setAttribute('aria-pressed', String(isActive));
    localStorage.setItem('reduceMotion', String(isActive));
  });
</script>

よくある間違い

  • prefers-reduced-motion を CSS アニメーションにだけ適用し、CSS トランジションには適用しない: animation ショートハンドと transition プロパティの両方が空間的な動きを生み出す可能性があります。チームはしばしばキーフレームアニメーション用のメディアクエリは記述する一方で、ホバーやフォーカス時の transition: transform 0.3s もモーションを引き起こし、制御対象にすべきであることを忘れがちです。
  • reduce ではなく prefers-reduced-motion: no-preference をクエリ条件として使用する: 正しいパターンは、モーション削減用のスタイルを @media (prefers-reduced-motion: reduce) で囲むことであり、その逆ではありません。アニメーションスタイルを @media (prefers-reduced-motion: no-preference) 内に記述する方法も機能しうるものの、エラーを招きやすく、ユーザーが明示的に設定していない場合にもアニメーションが有効のままになってしまうことがよくあります。
  • matchMedia の結果を一度だけ取得し、その後再チェックしない: ユーザーはページを開いている間にOSの設定を変更する可能性があります。matchMedia(...).addEventListener('change', handler) を購読し、ページの再読み込みを必要とせずに、JavaScript 駆動のアニメーションが設定変更にリアルタイムで対応できるようにする必要があります。
  • 不透明度のみのフェードを抑制すべきモーションアニメーションとして扱う: この達成基準が対象としているのは空間的な動きです。モーション削減が有効なときに不透明度のトランジションまで削除するのは過剰であり、ユーザビリティを損ないます。要素を空間的に移動させないフェードは、一般的には保持して問題ありません。
  • アニメーショントグルをアクセスしづらい設定メニューの奥深くに配置する: OSのメディアクエリの代わりに(またはそれに加えて)サイトレベルのコントロールを使用する場合、それは見つけやすい場所にある必要があります。理想的には、常設のサイトヘッダーやフッター、またはアクセスしやすいオーバーレイウィジェット内であり、ログインが必要なユーザーアカウント設定ページの3階層目のような場所に埋もれていてはなりません。
  • すべてのアニメーションライブラリが自動的に prefers-reduced-motion を尊重すると想定する: GSAP、Anime.js、独自の requestAnimationFrame 実装など、多くの JavaScript アニメーションライブラリは、メディアクエリを自動的には尊重しません。各プログラム的アニメーションは、JavaScript レイヤーで matchMedia チェックによって個別に制御する必要があります。
  • 十分な根拠なくアニメーションを本質的と宣言する: チームが、修正作業を避けるために複雑な装飾アニメーションを本質的とみなしてしまうことがあります。本質的例外の範囲は狭く、そのアニメーションが伝える情報を静的または非アニメーションの手段で表現できない場合にのみ本質的とみなされます。ローディングスピナー、装飾的なパララックス、ページ入場時のトランジションなどが本質的とみなされることはほとんどありません。
  • クリック以外のインタラクション、特にスクロールやホバーのテストを怠る: パララックススクロール効果やホバーでトリガーされる transform は、前庭への影響が最も大きいものの一部ですが、テストはしばしばクリックインタラクションに限定されがちです。包括的なテストでは、スクロール、ホバー、フォーカス、ドラッグ、キーボードナビゲーションなど、すべてのインタラクション手段をカバーする必要があります。
  • サイトレベルトグルの設定をセッションをまたいで保持しない: ユーザーがサイトのトグルでモーション削減を設定しても、別のページに移動したり翌日サイトに戻ったときに設定がリセットされてしまう場合、その配慮は事実上失敗しています。設定は localStorage やユーザープロファイルに保存し、すべてのページ読み込み時に再適用する必要があります。
  • サードパーティの埋め込みやウィジェットを見落とす: 埋め込みのソーシャルフィード、チャットウィジェット、地図の埋め込み、広告スクリプトなどは、ホストサイトのCSS制御の外側で独自のモーションアニメーションを導入する場合があります。サードパーティコンテンツも監査し、ベンダーにモーション削減対応を求めるか、可能な場合にはCSSのコンテインメント戦略によってモーションを抑制するコンテナでラップする必要があります。

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

トルコの大統領通達 2025/10は、2025年6月21日付の官報(Resmî Gazete)第32933号で公布され、トルコで事業を行う特定の主体に対して拘束力のあるデジタルアクセシビリティ義務を定めています。対象となる主体には、公的機関・機構、eコマースプラットフォーム、銀行および金融サービス提供者、病院および民間医療施設、20万件以上の加入者を持つ通信事業者、認可を受けた旅行代理店、民間輸送会社、国民教育省(MoNE)に認可された私立学校が含まれます。

この通達は、発効日以降に作成または大幅に更新されるデジタルサービスについて、WCAG 2.1 レベルAAへの適合をベースライン標準として義務付けています。WCAG 2.3.3「インタラクションによるアニメーション」はレベルAAAの達成基準であるため、大統領通達 2025/10 の下では必須要件ではありません。対象主体は、この達成基準を実装しなくても、トルコ法上の適合ステータスを達成することができます。

しかし、2.3.3 のような達成基準でレベルAAAに適合することは、トルコの組織にとって実務的にも評判の面でも大きな価値があります。前庭およびモーション感受性の状態は、スクリーンリーダー対応にのみ焦点を当てたアクセシビリティ監査では見落とされがちな、目に見えない障害です。神経学的な状態によりモーション感受性が高まっている患者を含む可能性がある医療分野(病院や民間のヘルスプラットフォーム)、およびスクロール量が多くアニメーションUIパターンが一般的なeコマースや旅行代理店などのセクターにおいて、2.3.3 を実装することは、成熟したユーザー中心のアクセシビリティアプローチを示すものです。

任意のAAA適合を目指す組織—公共調達での優位性、国際市場への参入、業界認証の取得などを目標とする組織—は、2.3.3 を優先度の高い達成基準として扱うべきです。というのも、(よく構造化された prefers-reduced-motion メディアクエリ戦略をデザインシステム全体に体系的に適用できるため)修正コストが比較的低く、その不在が直接的な身体的被害を引き起こしうるからです。Accsible のようなアクセシビリティオーバーレイウィジェット内にアニメーションコントロールを含めることで、トルコの組織は、ユーザーにOS設定の場所を探させることなくこの配慮を提供でき、モーション削減への導線をできるだけ多くのユーザーにとって発見しやすく、利用しやすいものにできます。