WCAG 2.3.2: 세 번의 번쩍임

이 규칙의 의미

WCAG 2.3.2 Three Flashes는 Operable 원칙 아래의 AAA 수준 성공 기준이다. 이 기준은 웹 페이지에 어느 1초 구간에서도 3회 이상 깜박이는 요소가 포함되어서는 안 된다고 규정한다. AA 수준의 대응 기준(2.3.1 Three Flashes or Below Threshold)과 달리, 이 기준은 작은 깜박임 영역이나 일반 플래시 및 빨간색 플래시 임계값 아래에 해당하는 깜박임에 대해서도 어떠한 예외도 허용하지 않는다. 규칙은 절대적이다. 콘텐츠가 초당 3회 이상 깜박이면, 크기, 색상, 대비와 관계없이 실패다.

플래시(flash)는 WCAG에서 일부 사람들에게 발작을 유발할 수 있는 상대 휘도의 상반된 변화 쌍으로 정의된다. 보다 실질적으로는, 눈에 보이는 켜짐/꺼짐 깜박임, 스트로브 같은 애니메이션, 빠르게 순환하는 이미지, 또는 초당 3회 이상의 완전한 사이클을 완료하는 깜박이는 비디오가 모두 이 규칙의 범위에 포함된다. "three flashes"라는 용어는 세 번의 완전한 진동을 의미한다. 즉, 콘텐츠가 하나의 초 안에 밝은 상태와 어두운 상태 사이를 세 번 교대로 오가는 것을 말한다.

영향을 받는 콘텐츠 유형은 매우 넓으며, 애니메이티드 GIF, @keyframes를 사용하는 CSS 애니메이션, 빠른 시각적 토글을 유발하는 JavaScript 기반 DOM 업데이트, HTML5 Canvas 애니메이션, 임베디드 비디오 콘텐츠, SVG 애니메이션, 애니메이션 미디어를 삽입하는 서드파티 광고 네트워크나 위젯 등을 포함한다. 스크롤되는 마키 텍스트의 미묘한 깜박임이나 빠르게 업데이트되는 데이터 시각화조차도, 속도가 초당 3회 플래시를 초과하면 이 기준을 위반할 수 있다.

2.3.2에서의 통과는 페이지에 초당 3회 플래시 임계값을 초과하는 깜박이는 콘텐츠가 전혀 없다는 것을 의미한다. 실패는 페이지의 어느 부분이든 — 영역이 얼마나 작든 상관없이 — 어느 1초 구간에서든 3회 이상 깜박일 때 발생한다. 이 기준에는 안전 영역 예외가 없으며, 이것이 2.3.1과 구분되는 점이다. 아주 작은 깜박이는 커서, 애니메이션 로딩 스피너, 빠르게 순환하는 광고 배너 등은 모두 3 Hz를 초과하는 빈도로 깜박이면 실패에 해당할 수 있다.

왜 중요한가

광과민성 간질은 전 세계적으로 약 4,000명 중 1명에게 영향을 미치지만, 광과민성 편두통, 전정 장애, 비간질성 광과민성을 포함한 광과민성 신경학적 반응에 취약한 전체 인구는 훨씬 더 크다. 이들에게 화면에서 빠르게 깜박이는 콘텐츠에 노출되는 것은 단순한 불편이 아니라, 대발작, 의식 상실, 부상, 드문 경우 사망까지 유발할 수 있다. 많은 접근성 장벽이 사용자 경험을 저하시키는 수준에 그치는 것과 달리, 깜박이는 콘텐츠는 즉각적인 안전 위험을 초래한다.

실질적인 상황을 생각해 보자. 한 터키 뉴스 웹사이트가 속보에 주목을 끌기 위해 8 Hz로 맥동하는 애니메이션 하이라이트 효과가 있는 실시간 티커를 삽입했다고 하자. 광과민성 간질이 있는 사용자가 출퇴근 중 휴대폰으로 이 페이지를 연다. 몇 초 안에 빠른 깜박임이 부분 발작을 유발해, 사용자가 휴대폰을 떨어뜨리고 잠시 근육 제어를 잃는다. 사전 경고도, 효과를 미리 비활성화할 방법도, 대처 수단도 없었다. 플래시 속도를 초당 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) 같은 특수 광과민성 분석 도구가 애니메이션 콘텐츠를 실제 움직임 상태에서 검토해, 초당 3회 플래시 임계값을 초과하는지 판단해야 한다.
• 수동 테스트 필요 — 서드파티 및 임베디드 콘텐츠: 광고, 임베디드 비디오, 소셜 미디어 위젯, iframe은 브라우저의 동일 출처 정책 제약 내에서 동작하는 axe-core가 분석할 수 없는 애니메이션 콘텐츠를 삽입할 수 있다. 테스트 담당자는 재생 중 모든 임베디드 및 서드파티 콘텐츠를 수동으로 관찰해 준수 여부를 평가해야 한다.
• 수동 테스트 필요 — JavaScript 기반 애니메이션: CSS 클래스를 빠르게 토글하거나, 캔버스 픽셀을 업데이트하거나, 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 실패는 다른 임계값과 관계없이 초당 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 Keyframe 애니메이션 — 잘못된 예

<!-- 주목을 끌기 위해 초당 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 — 초당 3회를 훨씬 초과 */
  }
</style>
<span class='alert-badge'>NEW</span>

너무 빠르게 깜박이는 CSS Keyframe 애니메이션 — 올바른 예

<!-- 초당 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 토글 — 잘못된 예

<!-- 스트로브 효과를 시뮬레이션하기 위해 초당 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마다 실행 = 초당 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프레임으로 프레임을 순환하는 애니메이티드 GIF 광고 -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- GIF의 내부 프레임 지연이 프레임당 10ms로 설정되어 빠른 깜박임을 생성 -->

프레임 속도가 높은 애니메이티드 GIF — 올바른 예

<!-- 애니메이티드 GIF를 정적 이미지로 교체하거나,
     프레임당 최소 334ms(초당 3프레임 이하)의 프레임 지연으로 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에는 이런 예외가 없다. 초당 3회 이상 깜박이는 아주 작은 커서나 작은 로딩 점도 AAA 수준에서 완전한 위반이다.
• CSS animation-duration을 0.1s나 0.2s처럼 설정하면서 결과 플래시 속도를 계산하지 않는 것: 두 상태 사이를 진동하는 0.1s 애니메이션은 초당 10회 사이클(10 Hz)을 완료한다. 초 단위 지속 시간으로 1을 나누어 Hz를 구하고, 결과가 3 이하인지 확인해야 한다.
• 애니메이션 동작을 검토하지 않고 서드파티 광고 스크립트를 임베드하는 것: 광고 네트워크는 접근성이 아니라 클릭률 최적화를 위해 높은 플래시 속도의 애니메이션 크리에이티브를 자주 제공한다. 배포 전에 항상 PEAT나 수동 프레임 검사를 사용해 서드파티 콘텐츠를 감사해야 한다.
• 로딩 또는 진행 표시를 위해 CSS 클래스를 빠르게 토글하는 setInterval 또는 requestAnimationFrame 루프를 사용하는 것: 요소의 휘도나 가시성을 초당 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 keyframe 애니메이션과 JavaScript 기반 토글은 간과하는 경우가 있다. 모든 애니메이션 기술이 평가되어야 한다.
• background-image CSS 속성을 사용해 애니메이티드 GIF를 표시하는 것: CSS 배경 이미지로 설정된 애니메이티드 GIF는 시각적 스캔을 하는 테스트 담당자에게 덜 눈에 띄며, 감사 중에 쉽게 간과된다. 항상 배경 이미지를 애니메이션 인벤토리에 포함해야 한다.
• A/B 테스트나 개인화 변경 후 새 애니메이션 콘텐츠가 삽입되었을 때 재테스트를 하지 않는 것: 마케팅 및 개인화 시스템은 WCAG 2.3.2 준수 여부를 검토하지 않은 애니메이션 배너나 오버레이를 동적으로 삽입할 수 있다. 동적으로 삽입되는 모든 콘텐츠에 대해 검토 게이트를 마련해야 한다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 주체에 대해 웹 및 모바일 접근성 기준을 의무화한다. 이 대통령령은 WCAG 2.2를 기술적 참조 프레임워크로 채택하며, 일반적으로 A 및 AA 수준의 준수를 의무로 요구한다.

WCAG 2.3.2는 AAA 수준 기준이므로, 대부분의 적용 대상에게는 대통령령에 따라 법적으로 의무 사항은 아니다. 그러나 발작을 유발할 수 있는 콘텐츠의 방지라는 주제는 이 규정을 뒷받침하는 일반적인 주의 의무와 비차별 원칙과 직접적으로 맞닿아 있다. 다음과 같은 유형의 주체는, 엄격히 요구되지 않더라도 2.3.2를 강력한 모범 사례 의무로 취급해야 한다. 전자상거래 플랫폼, 공공 기관 및 정부 기관, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 여행사, 민간 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받은 사립 학교가 이에 해당한다.

특히 공공 기관과 의료 서비스 제공자의 경우, 2.3.2의 윤리적 중요성은 매우 크다. 정부 보건 포털이나 병원 환자 정보 페이지가 광과민성 방문자에게 발작을 유발한다면, 이는 안전 실패이자 평판 위기 모두에 해당한다. 대통령령이 AAA 준수를 명시적으로 의무화하지는 않지만, 조달 자격, 공공 신뢰, 국제 비즈니스 파트너십을 위해 최고 수준의 접근성을 입증하려는 조직은 의무적인 A 및 AA 의무와 함께 2.3.2도 구현해야 한다.

유럽연합 시장에 서비스를 제공하는 조직은 2025년 6월에 적용되기 시작한 European Accessibility Act(EAA)가 EN 301 549를 참조하고, 이 표준이 다시 WCAG를 참조한다는 점도 유의해야 한다. EU 회원국에 디지털 제품이나 서비스를 수출하는 터키 기업은 이 경로를 통해 더 엄격한 요구 사항에 직면할 수 있다. 2.3.2를 선제적으로 구현하면 터키 조직은 국내 및 국경 간 준수 모두에 잘 대비할 수 있다.

실질적인 구현 관점에서, Accsible 오버레이 위젯 SDK는 페이지의 모든 애니메이션을 일시 중지하거나 중지할 수 있는 옵션을 사용자에게 제공함으로써, 자신의 상태를 인지하고 있는 사용자들의 광과민성 위험을 줄이는 데 도움을 줄 수 있다. 그러나 이러한 사용자 트리거 제어는 보완적 조치일 뿐이며, 2.3.2가 요구하듯이 근본적으로 깜박이는 콘텐츠를 제거하거나 속도를 늦추는 것을 대체할 수는 없다.