WCAG 2.3.2: Trzy błyski

Co Oznacza Ta Zasada

WCAG 2.3.2 Three Flashes to kryterium sukcesu na poziomie AAA w ramach zasady Operable. Stanowi ono, że strony internetowe nie mogą zawierać żadnych elementów, które błyskają więcej niż trzy razy w dowolnym okresie jednej sekundy. W przeciwieństwie do odpowiadającego mu kryterium na poziomie AA (2.3.1 Three Flashes or Below Threshold), to kryterium nie dopuszcza żadnych wyjątków dla małych obszarów migających ani dla błysków, które mieszczą się poniżej ogólnego progu błysków i progu czerwonych błysków. Zasada jest bezwzględna: jeśli treść błyska więcej niż trzy razy na sekundę, jest to niezgodne z wymaganiami, niezależnie od rozmiaru, koloru czy kontrastu.

Błysk jest zdefiniowany w WCAG jako para przeciwstawnych zmian względnej luminancji, które mogą wywołać napady u niektórych osób. Bardziej praktycznie, wszelkie widoczne miganie włącz/wyłącz, animacja przypominająca stroboskop, szybko zmieniające się obrazy lub migoczące wideo, które wykonują więcej niż trzy pełne cykle na sekundę, mieszczą się w zakresie tej zasady. Termin „three flashes” odnosi się do trzech pełnych oscylacji — oznacza to treść, która przełącza się między jaśniejszym a ciemniejszym stanem trzy razy w ciągu jednej sekundy.

Zakres typów treści objętych zasadą jest szeroki i obejmuje animowane GIF-y, animacje CSS z użyciem @keyframes, aktualizacje DOM sterowane JavaScriptem, które powodują szybkie przełączanie wizualne, animacje HTML5 Canvas, osadzone treści wideo, animacje SVG oraz zewnętrzne sieci reklamowe lub widgety osadzające animowane media. Nawet subtelne migotanie w przewijanym tekście typu marquee lub szybko aktualizowane wizualizacje danych mogą naruszać to kryterium, jeśli częstotliwość przekracza trzy błyski na sekundę.

Zaliczenie w ramach 2.3.2 oznacza, że strona nie zawiera żadnej treści migającej, która przekracza próg trzech błysków na sekundę. Niezaliczenie występuje za każdym razem, gdy jakakolwiek część strony — niezależnie od tego, jak mały jest obszar — błyska więcej niż trzy razy w dowolnym jednosekundowym oknie. W ramach tego kryterium nie ma wyjątku „bezpiecznego obszaru”, co odróżnia je od 2.3.1. Mały migający kursor, animowany wskaźnik ładowania czy szybko zmieniający się baner reklamowy mogą wszystkie stanowić naruszenie, jeśli migają z częstotliwością przekraczającą 3 Hz.

Dlaczego To Ma Znaczenie

Padaczka fotowrażliwa dotyka około 1 na 4 000 osób na świecie, ale całkowita populacja podatna na jakąś formę fotowrażliwej reakcji neurologicznej — w tym fotowrażliwe migreny, zaburzenia przedsionkowe i niefotowrażliwą padaczkę — jest znacząco większa. Dla tych osób kontakt z szybko migającą treścią na ekranie nie jest jedynie irytacją: może wywołać napady toniczno-kloniczne, utratę przytomności, urazy, a w rzadkich przypadkach śmierć. W przeciwieństwie do wielu barier dostępności, które pogarszają doświadczenie użytkownika, migająca treść stanowi bezpośrednie zagrożenie bezpieczeństwa.

Rozważmy praktyczny scenariusz: turecki portal informacyjny osadza pasek na żywo z animowanym efektem podświetlenia, który pulsuje z częstotliwością 8 Hz, aby przyciągnąć uwagę do wiadomości z ostatniej chwili. Użytkownik z padaczką fotowrażliwą otwiera stronę na telefonie w czasie dojazdu. W ciągu kilku sekund szybkie migotanie wywołuje napad częściowy, powodując, że osoba upuszcza telefon i na moment traci kontrolę nad mięśniami. Nie miała żadnego ostrzeżenia, żadnej możliwości wyłączenia efektu z wyprzedzeniem i żadnego środka zaradczego. Tego scenariusza można całkowicie uniknąć, ograniczając częstotliwość błysków do trzech na sekundę lub mniej — albo eliminując migającą treść całkowicie, jak wymaga 2.3.2.

Poza wymiarem bezpieczeństwa neurologicznego, spełnianie tego kryterium przynosi korzyści także osobom z zaburzeniami przedsionkowymi (które doświadczają zawrotów głowy, nudności lub dezorientacji z powodu ruchu), osobom z migrenami wywoływanymi przez wzory wizualne oraz osobom z zaburzeniami uwagi, dla których szybko migająca treść jest niemożliwa do zignorowania lub obejścia. Ograniczenie lub eliminacja migającej treści zwykle poprawia także postrzegany profesjonalizm strony i zmniejsza współczynnik porzuceń, ponieważ wielu użytkowników — z niepełnosprawnościami lub bez — uważa agresywne animacje za irytujące.

Z perspektywy SEO i wydajności eliminacja ciężkich animacji i szybkich przejść CSS zmniejsza obciążenie CPU i GPU, poprawiając wskaźniki Core Web Vitals, takie jak Total Blocking Time i Cumulative Layout Shift, które są sygnałami rankingowymi Google.

Powiązane Zasady Axe-core

WCAG 2.3.2 wymaga testów manualnych. Żadna zautomatyzowana zasada axe-core nie odpowiada bezpośrednio temu kryterium i jest to zamierzone — oto dlaczego narzędzia automatyczne nie są w stanie wiarygodnie wykrywać naruszeń:

• Wymagane testy manualne — wykrywanie częstotliwości błysków: Zautomatyzowane skanery dostępności analizują statyczny DOM i CSS w jednym momencie. Nie są w stanie obserwować zachowania treści w ciągu pełnej sekundy odtwarzania animacji, mierzyć częstotliwości oscylacji luminancji wideo lub animowanego GIF-a ani oceniać liczby klatek na sekundę animacji Canvas. Częstotliwość błysków jest właściwością czasową, która wymaga obserwacji w czasie rzeczywistym, co z definicji wykracza poza możliwości narzędzi analizy statycznej, takich jak axe-core. Tester — lub wyspecjalizowane narzędzia do analizy fotowrażliwości, takie jak Photosensitive Epilepsy Analysis Tool (PEAT) — musi przeanalizować animowaną treść w ruchu, aby ustalić, czy przekracza ona próg trzech błysków na sekundę.
• Wymagane testy manualne — treści zewnętrzne i osadzone: Reklamy, osadzone filmy, widgety mediów społecznościowych i iframy mogą wstrzykiwać animowaną treść, której axe-core nie może analizować, ponieważ działa w ramach ograniczeń polityki samego pochodzenia przeglądarki. Tester musi ręcznie obserwować wszystkie treści osadzone i zewnętrzne podczas odtwarzania, aby ocenić zgodność.
• Wymagane testy manualne — animacje sterowane JavaScriptem: Szybkie przełączanie klas CSS, aktualizowanie pikseli canvas lub manipulowanie elementami SVG za pomocą JavaScriptu z wysoką częstotliwością może powodować efekty migania, które są niewidoczne w statycznym zrzucie DOM. Testerzy muszą uruchomić stronę w żywej przeglądarce, obserwować wszystkie stany animacji i mierzyć cykle błysków ręcznie lub za pomocą narzędzi do analizy liczby klatek.

Jak Testować

1. Uruchom skan automatyczny jako punkt wyjścia: Użyj axe DevTools, Lighthouse lub wbudowanego audytu w widżecie Accsible, aby zidentyfikować wszelkie zgłoszone problemy związane z animacjami. Chociaż żadna zasada nie odpowiada bezpośrednio 2.3.2, narzędzia te mogą wskazać powiązane ostrzeżenia dotyczące animacji CSS lub regionów ARIA live, które aktualizują się szybko. Zanotuj wszystkie zgłoszone elementy, ale pamiętaj, że czysty raport z narzędzia automatycznego nie potwierdza zgodności z 2.3.2.
2. Ręcznie zidentyfikuj całą animowaną treść: Załaduj stronę w przeglądarce i obserwuj ją przez co najmniej 30 sekund bez interakcji. Zanotuj każdy element, który miga, błyska, animuje się lub wielokrotnie zmienia stan wizualny. Uwzględnij wskaźniki ładowania, banery, animacje hero, automatycznie odtwarzane filmy, animowane tła oraz wszelkie widgety zewnętrzne. Utwórz inwentarz tych elementów.
3. Użyj Photosensitive Epilepsy Analysis Tool (PEAT): Dla treści wideo lub nagrań ekranu animacji użyj PEAT (bezpłatnego narzędzia z Trace Research and Development Center), aby analizować materiał klatka po klatce. PEAT oznaczy sekwencje, które przekraczają progi błysków, i zgłosi zarówno ogólny próg błysków, jak i próg czerwonych błysków. Niezaliczenie 2.3.2 to każdy błysk przekraczający trzy na sekundę, niezależnie od innych progów.
4. Zmierz częstotliwość animacji CSS i JavaScript: Otwórz DevTools przeglądarki (Chrome lub Firefox) i użyj zakładki Performance, aby nagrać 5-sekundową sesję podczas odtwarzania animacji. Sprawdź wykres płomieniowy pod kątem szybko powtarzających się operacji malowania lub układu. Możesz także otworzyć panel Animations w Chrome DevTools, aby zobaczyć działające animacje i ich czas trwania — podziel 1000 ms przez czas trwania animacji, aby obliczyć Hz.
5. Testuj z NVDA + Firefox, VoiceOver + Safari i JAWS + Chrome: Użytkownicy czytników ekranu nie są wyłączeni z ryzyka fotowrażliwości. Uruchom każdy czytnik ekranu i nawiguj po stronie w zwykły sposób. Jeśli jakakolwiek treść, która błyska wizualnie, jest również prezentowana w sposób powodujący szybkie odświeżanie ekranu (na przykład region live ogłaszający każdą klatkę licznika), udokumentuj to. Miganie wizualne pozostaje naruszeniem nawet dla użytkowników czytników ekranu, ponieważ mogą oni mieć pewien poziom funkcjonalnego widzenia.
6. Zweryfikuj treści zewnętrzne i osadzone: Przewiń wszystkie iframy, osadzone posty z mediów społecznościowych, sloty reklamowe i odtwarzacze wideo. Ręcznie odtwórz wszystkie filmy, dla których autoplay jest wyłączony, i obserwuj, czy nie występuje szybkie migotanie. Sprawdź animowane GIF-y, klikając prawym przyciskiem i analizując dane klatek w edytorze obrazów lub w zakładce Network przeglądarki, aby oszacować liczbę klatek na sekundę.
7. Powtórz testy na różnych urządzeniach i w różnych przeglądarkach: Niektóre animacje działają z różną prędkością na urządzeniach mobilnych i desktopowych z powodu różnic w akceleracji sprzętowej. Testuj zarówno w przeglądarce desktopowej, jak i na urządzeniu mobilnym (iOS Safari i Android Chrome), aby potwierdzić spójną zgodność.

Jak Naprawić

Animacja CSS Keyframe Migająca Zbyt Szybko — Nieprawidłowe

<!-- Odznaka, która miga, aby przyciągnąć uwagę, wykonując 8 cykli na sekundę -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — znacznie przekracza 3 na sekundę */
  }
</style>
<span class='alert-badge'>NEW</span>

Animacja CSS Keyframe Migająca Zbyt Szybko — Prawidłowe

<!-- Animacja spowolniona tak, aby wykonywała mniej niż 3 cykle na sekundę -->
<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 — bezpiecznie poniżej progu 3 Hz */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Jeszcze lepiej: całkowicie usuń animację i użyj statycznej odznaki o wysokim kontraście -->

Przełączanie DOM w JavaScript Powodujące Szybkie Migotanie — Nieprawidłowe

<!-- Skrypt przełącza widoczność 10 razy na sekundę, aby symulować efekt stroboskopu -->
<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); /* Wywoływane co 100 ms = 10 błysków na sekundę -- poważne ryzyko napadu */
</script>

Przełączanie DOM w JavaScript Powodujące Szybkie Migotanie — Prawidłowe

<!-- Całkowicie usunięto szybkie przełączanie; zamiast tego przekaż zmianę stanu za pomocą tekstu lub ikony -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Jeśli animacja jest naprawdę potrzebna, utrzymuj ją wyraźnie poniżej 3 Hz i preferuj przejścia
     krycia/koloru zamiast przełączeń o wysokim kontraście luminancji -->

Animowany GIF z Wysoką Liczbą Klatek — Nieprawidłowe

<!-- Animowana reklama GIF, która przechodzi przez klatki z prędkością 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- Wewnętrzne opóźnienie klatek GIF-a jest ustawione na 10 ms na klatkę, co powoduje szybkie migotanie -->

Animowany GIF z Wysoką Liczbą Klatek — Prawidłowe

<!-- Zastąp animowany GIF statycznym obrazem lub wyeksportuj GIF ponownie
     z minimalnym opóźnieniem 334 ms na klatkę (3 fps lub wolniej) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Jeśli ruch musi zostać zachowany, użyj animacji CSS z obsługą prefers-reduced-motion -->
<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>

Typowe Błędy

• Założenie, że wyjątek „małego obszaru” z 2.3.1 ma zastosowanie do 2.3.2: WCAG 2.3.1 dopuszcza migającą treść, która zajmuje mniej niż 25% pola widzenia o rozpiętości 10 stopni. WCAG 2.3.2 nie ma takiego wyjątku — mały migający kursor lub mała kropka ładowania, która błyska więcej niż trzy razy na sekundę, stanowi pełne naruszenie na poziomie AAA.
• Ustawianie CSS animation-duration na wartości takie jak 0.1s lub 0.2s bez obliczenia wynikowej częstotliwości błysków: Animacja 0.1s, która oscyluje między dwoma stanami, wykonuje 10 cykli na sekundę (10 Hz). Podziel 1 przez czas trwania w sekundach, aby uzyskać Hz; upewnij się, że wynik wynosi 3 lub mniej.
• Osadzanie zewnętrznych skryptów reklamowych bez przeglądu zachowania animacji: Sieci reklamowe często serwują kreacje animowane z wysoką częstotliwością błysków, zoptymalizowane pod kątem współczynnika klikalności, a nie dostępności. Zawsze audytuj treści zewnętrzne za pomocą PEAT lub ręcznej inspekcji klatek przed wdrożeniem.
• Używanie pętli setInterval lub requestAnimationFrame do szybkiego przełączania klas CSS dla wskaźników ładowania lub postępu: Każda pętla JavaScript, która zmienia luminancję lub widoczność elementu więcej niż trzy razy na sekundę, tworzy naruszenie 2.3.2, nawet jeśli efekt wydaje się subtelny w normalnych warunkach oglądania.
• Brak testowania animowanych SVG i elementów Canvas: Animacje SVG z użyciem <animate> lub SMIL oraz gry lub wizualizacje danych oparte na Canvas rzadko są testowane za pomocą PEAT lub narzędzi do analizy liczby klatek, a mimo to w pełni mogą przekraczać próg błysków.
• Poleganie wyłącznie na axe-core lub Lighthouse w celu potwierdzenia zgodności z 2.3.2: Narzędzia automatyczne nie są w stanie wykryć tego kryterium. Czysty wynik skanowania automatycznego nic nie znaczy dla 2.3.2; tylko przegląd manualny i analiza PEAT mogą potwierdzić zgodność.
• Traktowanie prefers-reduced-motion jako pełnego rozwiązania dla 2.3.2: Respektowanie media query prefers-reduced-motion jest dobrą praktyką i pomaga wielu użytkownikom, ale jest to mechanizm wymagający działania użytkownika. WCAG 2.3.2 wymaga, aby treść była bezpieczna domyślnie, a nie tylko wtedy, gdy użytkownik ustawił odpowiednie preferencje systemowe. Użytkownicy, którzy nie skonfigurowali tego ustawienia, nadal są narażeni.
• Stosowanie ograniczeń częstotliwości błysków tylko do wideo, a nie do animacji CSS, JavaScript lub GIF: Zespoły czasami audytują treści wideo za pomocą PEAT, ale pomijają animacje CSS keyframe i przełączanie sterowane JavaScriptem. Wszystkie technologie animacji muszą być ocenione.
• Używanie właściwości CSS background-image do wyświetlania animowanych GIF-ów: Animowane GIF-y ustawione jako obrazy tła CSS są mniej widoczne dla testerów wykonujących skan wizualny i łatwo je przeoczyć podczas audytów. Zawsze uwzględniaj obrazy tła w swoim inwentarzu animacji.
• Brak ponownego testowania po wprowadzeniu zmian A/B testing lub personalizacji, które wstrzykują nową animowaną treść: Systemy marketingowe i personalizacyjne mogą dynamicznie wstrzykiwać banery lub nakładki z animacjami, które nigdy nie były sprawdzane pod kątem zgodności z WCAG 2.3.2. Ustanów punkt kontrolny przeglądu dla wszelkich dynamicznie wstrzykiwanych treści.

Związek z Przepisami Dotyczącymi Dostępności w Turcji

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe standardy dostępności stron internetowych i aplikacji mobilnych dla szerokiego zakresu podmiotów działających w Turcji. Okólnik przyjmuje WCAG 2.2 jako techniczne ramy odniesienia, z ogólnie wymaganym obowiązkowym poziomem zgodności A i AA.

WCAG 2.3.2 jest kryterium na poziomie AAA i dlatego nie jest prawnie wymagane na mocy okólnika dla większości objętych podmiotów. Jednak jego zakres — zapobieganie treściom, które mogą wywoływać napady — bezpośrednio przecina się z ogólnym obowiązkiem należytej staranności i zasadami niedyskryminacji, które stanowią podstawę regulacji. Następujące typy podmiotów są objęte okólnikiem i powinny traktować 2.3.2 jako silne zobowiązanie w zakresie najlepszych praktyk, nawet jeśli nie jest ono ściśle wymagane: platformy e-commerce, instytucje publiczne i agencje rządowe, banki i instytucje finansowe, szpitale i świadczeniodawcy opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

Dla instytucji publicznych i świadczeniodawców opieki zdrowotnej stawka etyczna związana z 2.3.2 jest szczególnie wysoka. Rządowy portal zdrowotny lub strona z informacjami dla pacjentów szpitala, która wywoła napad u fotowrażliwego odwiedzającego, stanowiłaby zarówno porażkę w zakresie bezpieczeństwa, jak i kryzys reputacyjny. Chociaż okólnik nie nakazuje wprost zgodności z poziomem AAA, organizacje dążące do wykazania wzorcowej dostępności — czy to dla kwalifikacji przetargowych, zaufania publicznego, czy międzynarodowych partnerstw biznesowych — powinny wdrożyć 2.3.2 obok obowiązkowych wymogów na poziomie A i AA.

Organizacje świadczące usługi na rynek Unii Europejskiej powinny również zauważyć, że Europejski Akt o Dostępności (EAA), który wszedł w życie w czerwcu 2025 r., odwołuje się do EN 301 549, który z kolei odwołuje się do WCAG. Tureckie firmy eksportujące produkty lub usługi cyfrowe do państw członkowskich UE mogą napotkać bardziej rygorystyczne wymagania tą drogą. Proaktywne wdrożenie 2.3.2 dobrze pozycjonuje tureckie organizacje zarówno pod kątem zgodności krajowej, jak i transgranicznej.

Z praktycznego punktu widzenia, SDK nakładki widżetu Accsible może wspierać objęte organizacje, zapewniając użytkownikom możliwość wstrzymania lub zatrzymania wszystkich animacji na stronie, co pomaga zmniejszyć ryzyko fotowrażliwości dla użytkowników świadomych swojej kondycji. Ten sterowany przez użytkownika mechanizm kontroli jest jednak środkiem uzupełniającym, a nie substytutem usuwania lub spowalniania migającej treści u źródła, jak wymaga 2.3.2.