WCAG 2.3.2: 3回の閃光

このルールの意味

WCAG 2.3.2「3回の閃光」は、原則「操作可能」におけるレベルAAAの達成基準です。これは、ウェブページには、いかなる1秒間のあいだにも3回を超えて点滅するコンテンツを含めてはならないと定めています。レベルAAの対応基準（2.3.1「3回の閃光、または閾値以下」）とは異なり、この基準では、小さな点滅領域や、一般的な閃光および赤色閃光の閾値を下回る点滅に対する例外は一切認められません。ルールは絶対的であり、コンテンツが1秒あたり3回を超えて点滅すれば、サイズ、色、コントラストに関係なく不適合となります。

閃光（フラッシュ）はWCAGで、相対輝度が反対方向に変化する一対の変化として定義されており、一部の人に発作を引き起こす可能性があります。より実務的には、目に見えるオン・オフの点滅、ストロボのようなアニメーション、高速で切り替わる画像、または1秒間に3回を超える完全なサイクルを完了するちらつく動画は、すべてこのルールの対象となります。「3回の閃光」という用語は3回の完全な振動を指し、つまり、1秒以内に明るい状態と暗い状態の間を3回切り替えるコンテンツを意味します。

影響を受けるコンテンツの種類は幅広く、アニメーションGIF、@keyframesを用いたCSSアニメーション、高速な視覚的トグルを引き起こすJavaScriptによるDOM更新、HTML5 Canvasアニメーション、埋め込み動画コンテンツ、SVGアニメーション、アニメーションメディアを埋め込むサードパーティの広告ネットワークやウィジェットなどが含まれます。スクロールするマーキーテキストのわずかなちらつきや、高頻度で更新されるデータビジュアライゼーションであっても、その速度が1秒あたり3回の閃光を超える場合、この基準に抵触する可能性があります。

2.3.2における適合とは、ページ内に1秒あたり3回の閃光の閾値を超える点滅コンテンツが一切存在しないことを意味します。不適合は、ページのどの部分であっても—領域の大きさに関係なく—任意の1秒間のあいだに3回を超えて点滅した時点で発生します。この基準には安全領域の例外はなく、これが2.3.1との違いです。ごく小さな点滅カーソル、アニメーションするローディングスピナー、高速で切り替わる広告バナーなども、点滅頻度が3Hzを超える場合はすべて不適合となり得ます。

なぜ重要か

光過敏性てんかんは世界的に約4,000人に1人に影響するとされていますが、光過敏性片頭痛、前庭障害、非てんかん性光過敏など、何らかの光過敏性の神経反応を起こしうる人の総数は、これよりはるかに多くなります。これらの人々にとって、画面上の高速な点滅コンテンツへの曝露は単なる不快感ではなく、大発作、意識喪失、怪我、まれには死亡を引き起こすこともあります。多くのアクセシビリティ障壁がユーザー体験を損なうのに対し、点滅コンテンツは急性の安全上の危険をもたらします。

実際的なシナリオを考えてみましょう。トルコのニュースサイトが、速報に注目を集めるために8Hzで脈動するアニメーションのハイライト効果付きライブティッカーを埋め込んでいるとします。光過敏性てんかんを持つユーザーが通勤中にスマートフォンでそのページを開きます。数秒のうちに、その高速なちらつきが部分発作を引き起こし、その人はスマートフォンを落とし、一時的に筋肉の制御を失います。事前の警告も、その効果を無効化する手段も、救済策もありませんでした。このシナリオは、点滅速度を1秒あたり3回以下に制限するか、あるいは2.3.2が求めるように点滅コンテンツ自体を完全に排除することで、完全に防ぐことができます。

神経学的な安全性の側面にとどまらず、この基準に準拠することは、動きによってめまい、吐き気、方向感覚の喪失を感じる前庭障害のあるユーザー、視覚パターンによって片頭痛が誘発されるユーザー、急速に点滅するコンテンツを無視したり回避したりすることが困難な注意欠如障害のあるユーザーにも利益をもたらします。点滅コンテンツを減らす、あるいは排除することは、多くの場合、ページの専門性の印象を高め、ユーザーの離脱率を下げる効果もあります。障害の有無にかかわらず、多くのユーザーが攻撃的なアニメーションを不快に感じるためです。

SEOとパフォーマンスの観点からも、重いアニメーションや高速なCSSトランジションを排除することでCPUおよびGPU負荷が軽減され、Total Blocking TimeやCumulative Layout ShiftといったCore Web Vitalsのスコアが改善されます。これらはいずれもGoogleのランキングシグナルです。

関連するaxe-coreルール

WCAG 2.3.2には手動テストが必要です。この基準に直接対応する自動のaxe-coreルールは存在せず、これは意図的なものです。自動ツールが違反を確実に検出できない理由は次のとおりです。

• 手動テストが必要 — 閃光頻度の検出: 自動アクセシビリティスキャナーは、ある一時点における静的なDOMとCSSを検査します。コンテンツが1秒間のアニメーション再生中にどのように振る舞うかを観察したり、動画やアニメーションGIFの輝度振動の頻度を測定したり、Canvasアニメーションのフレームレートを評価したりすることはできません。閃光頻度は時間的な特性であり、リアルタイムの観察が必要なため、axe-coreのような静的解析ツールの根本的な限界を超えています。人間のテスター、あるいはPhotosensitive Epilepsy Analysis Tool（PEAT）のような光過敏性解析専用ツールが、アニメーションコンテンツを実際に動いている状態で確認し、1秒あたり3回の閃光閾値を超えているかどうかを判断する必要があります。
• 手動テストが必要 — サードパーティおよび埋め込みコンテンツ: 広告、埋め込み動画、ソーシャルメディアウィジェット、iframeは、ブラウザの同一オリジンポリシーの制約のためaxe-coreが解析できないアニメーションコンテンツを挿入する場合があります。テスターは、再生中のすべての埋め込みおよびサードパーティコンテンツを手動で観察し、適合状況を評価しなければなりません。
• 手動テストが必要 — JavaScript駆動のアニメーション: 高頻度でCSSクラスをトグルしたり、Canvasのピクセルを更新したり、JavaScriptでSVG要素を操作したりすると、静的なDOMスナップショットでは見えない点滅効果が生じることがあります。テスターはページをライブブラウザで実行し、すべてのアニメーション状態を観察し、手動またはフレームレート解析ツールを用いて閃光サイクルを計測する必要があります。

テスト方法

1. ベースラインとして自動スキャンを実行する: axe DevTools、Lighthouse、またはAccsibleウィジェットの組み込み監査機能を使用して、アニメーション関連の問題としてフラグされた項目を特定します。2.3.2に直接対応するルールは存在しませんが、これらのツールは高速なCSSアニメーションやARIAライブリージョンに関する警告を表示する場合があります。フラグされた項目を記録しつつも、自動レポートがクリーンであっても2.3.2への適合が確認されたことにはならない点を理解してください。
2. すべてのアニメーションコンテンツを手動で特定する: ブラウザでページを読み込み、操作せずに少なくとも30秒間観察します。点滅、フラッシュ、アニメーション、視覚状態の繰り返し変化を行うすべての要素を記録します。ローディングスピナー、バナー、ヒーローアニメーション、自動再生動画、アニメーション背景、サードパーティウィジェットなどを含めてください。これらの要素のインベントリを作成します。
3. Photosensitive Epilepsy Analysis Tool（PEAT）を使用する: 動画コンテンツやアニメーションの画面録画については、PEAT（Trace Research and Development Centerが提供する無料ツール）を使用してフレーム単位で解析します。PEATは閾値を超える閃光シーケンスをフラグし、一般的な閃光閾値と赤色閃光閾値の両方を報告します。2.3.2の不適合は、他の閾値に関係なく、1秒あたり3回を超えるすべての閃光です。
4. CSSおよびJavaScriptアニメーションの速度を測定する: ブラウザのDevTools（ChromeまたはFirefox）を開き、Performanceタブを使用してアニメーション再生中の5秒間のセッションを記録します。フレームグラフを確認し、高頻度で繰り返されるpaintやlayout処理を探します。また、Chrome DevToolsのAnimationsパネルを開いて実行中のアニメーションとその継続時間を確認し、アニメーションの継続時間で1000msを割ることでHzを算出できます。
5. NVDA + Firefox、VoiceOver + Safari、JAWS + Chromeでテストする: スクリーンリーダーユーザーも光過敏性から免れるわけではありません。各スクリーンリーダーを起動し、通常どおりページをナビゲートします。視覚的に点滅するコンテンツが、カウンターの各フレームをアナウンスするライブリージョンのように、画面の高速な再描画を引き起こす形で提示されている場合は、それを記録します。スクリーンリーダーユーザーであっても、ある程度の機能的な視力を持つ可能性があるため、視覚的な点滅は依然として違反となります。
6. サードパーティおよび埋め込みコンテンツを検証する: すべてのiframe、埋め込みソーシャルメディア投稿、広告枠、動画プレーヤーをスクロールして確認します。自動再生が無効になっている動画は手動で再生し、高速なちらつきがないか観察します。アニメーションGIFについては、右クリックして画像エディタやブラウザのNetworkタブでフレームデータを確認し、フレームレートを推定します。
7. デバイスとブラウザを変えてテストを繰り返す: 一部のアニメーションは、ハードウェアアクセラレーションの違いにより、モバイルとデスクトップで速度が異なる場合があります。デスクトップブラウザとモバイルデバイス（iOSのSafariとAndroidのChrome）の両方でテストし、一貫した適合を確認します。

修正方法

CSSキーフレームアニメーションの点滅が速すぎる — 不適切な例

<!-- 注目を集めるために点滅し、1秒間に8サイクルを完了するバッジ -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — 1秒あたり3回を大きく超える */
  }
</style>
<span class='alert-badge'>NEW</span>

CSSキーフレームアニメーションの点滅が速すぎる — 適切な例

<!-- アニメーションを遅くし、1秒あたり3サイクル未満にする -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.4s infinite; /* 約2.5 Hz — 3 Hzの閾値を安全に下回る */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- さらに望ましいのは、アニメーションを完全に削除し、静的な高コントラストのバッジを使用すること -->

JavaScriptによるDOMトグルが高速なちらつきを引き起こす — 不適切な例

<!-- ストロボ効果を模倣するため、1秒間に10回可視状態をトグルするスクリプト -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
  setInterval(function() {
    var el = document.getElementById('strobe-element');
    el.style.background = el.style.background === 'white' ? 'black' : 'white';
  }, 100); /* 100msごとに実行 = 1秒あたり10回の閃光 — 深刻な発作リスク */
</script>

JavaScriptによるDOMトグルが高速なちらつきを引き起こす — 適切な例

<!-- 高速トグルを完全に削除し、代わりにテキストやアイコンで状態変化を伝える -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- どうしてもアニメーションが必要な場合は、3 Hzを大きく下回るように保ち、
     高コントラストの輝度切り替えではなく不透明度や色のトランジションを優先する -->

高フレームレートのアニメーションGIF — 不適切な例

<!-- 10 fpsでフレームを切り替えるアニメーションGIF広告 -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- GIFの内部フレーム遅延が1フレームあたり10msに設定されており、高速なちらつきを生む -->

高フレームレートのアニメーションGIF — 適切な例

<!-- アニメーションGIFを静的画像に置き換えるか、
     1フレームあたり334ms以上（3 fps以下）のフレーム遅延でGIFを書き出し直す -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- 動きを維持する必要がある場合は、prefers-reduced-motionに対応したCSSアニメーションを使用する -->
<picture>
  <source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
  <img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>

よくある間違い

• 2.3.1の「小さな領域」例外が2.3.2にも適用されると想定すること: WCAG 2.3.1では、10度の視野の25%未満を占める点滅コンテンツを許容しています。WCAG 2.3.2にはそのような例外はありません。1秒あたり3回を超えて点滅するごく小さなカーソルやローディングドットであっても、AAAレベルで完全な違反となります。
• CSSのanimation-durationを0.1sや0.2sなどに設定し、その結果生じる点滅頻度を計算しないこと: 0.1sのアニメーションで2つの状態を行き来する場合、1秒あたり10サイクル（10 Hz）を完了します。秒単位の継続時間で1を割るとHzが求められます。その結果が3以下であることを確認してください。
• アニメーションの挙動を確認せずにサードパーティの広告スクリプトを埋め込むこと: 広告ネットワークは、アクセシビリティではなくクリック率の最適化を目的とした高頻度点滅のクリエイティブを配信することがよくあります。導入前に、必ずPEATや手動のフレーム検査でサードパーティコンテンツを監査してください。
• ローディングや進捗インジケーターのために、setIntervalやrequestAnimationFrameループでCSSクラスを高速にトグルすること: 要素の輝度や可視性を1秒あたり3回を超えて変化させるあらゆるJavaScriptループは、通常の閲覧条件では効果が控えめに見えても、2.3.2の違反を引き起こします。
• アニメーションSVGやCanvas要素をテストしないこと: <animate>やSMILを用いたSVGアニメーション、Canvasベースのゲームやデータビジュアライゼーションは、PEATやフレームレートツールでテストされることがほとんどありませんが、閾値を超える点滅を十分に引き起こし得ます。
• 2.3.2への適合確認をaxe-coreやLighthouseだけに頼ること: 自動ツールはこの基準を検出できません。自動スキャンの結果がクリーンであっても、2.3.2に関しては何も意味しません。適合を確認できるのは、手動レビューとPEAT解析だけです。
• prefers-reduced-motionを2.3.2の完全な解決策とみなすこと: prefers-reduced-motionメディアクエリに対応することはベストプラクティスであり、多くのユーザーにとって有用ですが、これはユーザーのオプトインに依存する仕組みです。WCAG 2.3.2は、ユーザーがシステム設定を行った場合だけでなく、デフォルトでコンテンツが安全であることを求めています。この設定を構成していないユーザーは依然としてリスクにさらされます。
• 動画にだけ点滅頻度の制限を適用し、CSS、JavaScript、GIFアニメーションには適用しないこと: チームが動画コンテンツをPEATで監査しつつ、CSSキーフレームアニメーションやJavaScript駆動のトグルを見落とすことがあります。すべてのアニメーション技術を評価する必要があります。
• background-imageのCSSプロパティでアニメーションGIFを表示すること: CSSの背景画像として設定されたアニメーションGIFは、視覚的なスキャンを行うテスターから見えにくく、監査時に見落とされがちです。アニメーションインベントリには、必ず背景画像も含めてください。
• A/Bテストやパーソナライゼーションの変更によって新しいアニメーションコンテンツが挿入された後に再テストを行わないこと: マーケティングやパーソナライゼーションのシステムは、WCAG 2.3.2への適合性が一度も確認されていないアニメーション付きバナーやオーバーレイを動的に挿入することがあります。動的に挿入されるコンテンツには、必ずレビューのゲートを設けてください。

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

トルコの大統領通達2025/10は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い主体に対して、ウェブおよびモバイルのアクセシビリティ基準を義務付けています。この通達は、技術的な参照枠組みとしてWCAG 2.2を採用しており、一般的にレベルAおよびレベルAAでの適合が義務付けられています。

WCAG 2.3.2はレベルAAAの基準であるため、通達の対象となる多くの主体にとって法的に義務付けられているわけではありません。しかし、その対象とする内容—発作を引き起こし得るコンテンツの防止—は、この規制を支える一般的な注意義務および無差別原則と直接交差しています。通達の対象となる主体には、eコマースプラットフォーム、公的機関および政府機関、銀行および金融機関、病院および医療提供者、20万人以上の加入者を有する通信会社、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などが含まれ、これらは2.3.2を厳格な法的義務ではない場合でも強いベストプラクティス上の義務として扱うべきです。

特に公的機関や医療提供者にとって、2.3.2の倫理的な重要性は非常に高いものです。政府の健康ポータルや病院の患者情報ページが、光過敏性の訪問者に発作を引き起こした場合、それは安全性の失敗であると同時に評判上の危機でもあります。通達はAAAレベルの適合を明示的に義務付けてはいませんが、調達要件の充足、公共の信頼、国際的なビジネスパートナーシップなどの観点から、最高水準のアクセシビリティを示そうとする組織は、必須のAおよびAAの義務と併せて2.3.2も実装すべきです。

欧州連合市場にサービスを提供する組織は、2025年6月に適用が開始されたEuropean Accessibility Act（EAA）がEN 301 549を参照し、EN 301 549がさらにWCAGを参照している点にも留意する必要があります。EU加盟国にデジタル製品やサービスを輸出するトルコ企業は、その経路を通じてより厳格な要件に直面する可能性があります。2.3.2を先行して実装することは、トルコの組織が国内および越境の両方のコンプライアンスにおいて有利な立場を確保することにつながります。

実務的な実装の観点からは、AccsibleのオーバーレイウィジェットSDKが、ページ上のすべてのアニメーションを一時停止または停止するオプションをユーザーに提供することで、光過敏性リスクの低減を支援できます。これは自分の状態を認識しているユーザーにとって有用ですが、このユーザー操作による制御は補完的な措置であり、2.3.2が求めるような、点滅コンテンツをソースレベルで削除または減速することの代替にはなりません。