WCAG 2.3.1: Trzy błyski lub poniżej progu

Co Oznacza Ta Zasada

WCAG 2.3.1 — Trzy błyski lub poniżej progu — to kryterium sukcesu na poziomie A w ramach zasady Operable (Możliwość obsługi). Wymaga ono, aby strony internetowe nie zawierały żadnych treści, które błyskają więcej niż trzy razy w dowolnym okresie jednej sekundy, chyba że błyskająca treść jest na tyle mała lub na tyle mało jasna, że mieści się poniżej zdefiniowanego ogólnego progu błysku lub progu czerwonego błysku.

Błysk jest zdefiniowany jako para przeciwstawnych zmian względnej luminancji, które mogą wywołać napady u osób podatnych. WCAG wyróżnia w szczególności dwa rodzaje niebezpiecznych błysków:

• Ogólny błysk: Para przeciwstawnych zmian, w której wyższa luminancja wynosi co najmniej 10% maksymalnej względnej luminancji (0,80), a różnica luminancji wynosi co najmniej 10% maksymalnej wartości. W praktyce oznacza to treści szybko przechodzące między jasnym a ciemnym stanem w tempie wystarczającym do wywołania efektu stroboskopowego.
• Czerwony błysk: Para przeciwstawnych przejść obejmujących nasycony kolor czerwony. Traktuje się je ze szczególną ostrożnością, ponieważ czerwone błyski są klinicznie powiązane z wyższym ryzykiem wywołania napadów fotowrażliwych.

Kryterium ma zastosowanie do wszystkich treści internetowych niezależnie od formatu — animacji HTML, przejść CSS, efektów sterowanych JavaScriptem, osadzonych filmów, GIF-ów, animacji SVG, scen WebGL, grafiki renderowanej na canvas oraz zewnętrznych widżetów reklamowych. Jeśli treść błyska z częstotliwością przekraczającą trzy błyski na sekundę i nie mieści się poniżej progów luminancji lub rozmiaru, bezwarunkowo nie spełnia tego kryterium.

Wyjątki i progi pozwalające treściom przejść: WCAG 2.3.1 dopuszcza błyskające treści, jeśli spełniają jeden z poniższych warunków:

• Łączny obszar błysków występujących jednocześnie nie pokrywa więcej niż 0,006 steradiana w obrębie dowolnego 10-stopniowego pola widzenia na ekranie (w przybliżeniu prostokąt 341 × 256 pikseli przy typowych odległościach oglądania, lub około 21 824 piksele kwadratowe na ekranie o szerokości 1024 pikseli oglądanym z odległości wyciągniętego ramienia).
• Błysk znajduje się poniżej ogólnego progu błysku (zmiana luminancji jest mniejsza niż 10%) lub poniżej progu czerwonego błysku (nasycony komponent czerwieni nie zmienia się o więcej niż zdefiniowany próg).

Pojedyncze zdarzenie błysku o bardzo niskim kontraście luminancji lub bardzo małym obszarze na ekranie może być zatem dopuszczalne. Jednak ze względu na to, że progi te są złożone i wymagają fotometrycznych narzędzi pomiarowych do precyzyjnej weryfikacji, większość praktyków przyjmuje zachowawcze podejście polegające na całkowitym unikaniu treści błyskających więcej niż trzy razy na sekundę. Treści błyskające dokładnie trzy razy na sekundę (3 Hz) znajdują się na granicy — treści przekraczające 3 Hz są niezgodne niezależnie od rozmiaru, chyba że progi rozmiaru lub luminancji są jednoznacznie spełnione.

Kryterium dotyczy wszelkich treści renderowanych podczas normalnej interakcji ze stroną. Nie zwalnia treści ukrytych za kontrolkami wyzwalanymi przez użytkownika, jeśli te treści odtwarzają się automatycznie po załadowaniu strony. Jeśli film zaczyna odtwarzać się automatycznie i zawiera sekwencje błysków przekraczające próg, strona nie spełnia tego kryterium od momentu załadowania.

Dlaczego To Ma Znaczenie

Padaczka fotowrażliwa dotyka około 1 na 4 000 osób na świecie — około 3% całej populacji osób z padaczką. Jednak wrażliwość na szybko błyskające lub migoczące światło wykracza poza klinicznie zdiagnozowaną padaczkę. Wiele osób z zaburzeniami migrenowymi, dysfunkcjami przedsionkowymi, ze spektrum autyzmu oraz z zespołem po wstrząśnieniu mózgu może doświadczać znacznego dyskomfortu, dezorientacji, nudności lub bólu w wyniku szybko błyskających bodźców wzrokowych, nawet jeśli nie mają zdiagnozowanego zaburzenia napadowego.

Stawka jest wyjątkowo wysoka w przypadku tego kryterium w porównaniu z większością innych wymogów dostępności. Użytkownik napotykający brakujący tekst alternatywny doświadcza wykluczenia i frustracji. Użytkownik napotykający treść wywołującą napad fotowrażliwy może doświadczyć nagłego zagrożenia zdrowia — w tym utraty przytomności, obrażeń spowodowanych upadkiem, a w rzadkich, ale udokumentowanych przypadkach, zagrożenia życia. Harding Flash and Pattern Analyzer, szeroko stosowane narzędzie w nadawstwie, zostało opracowane specjalnie w celu zapobiegania takim zdarzeniom w telewizji, a sieć stwarza analogiczne ryzyka.

Konkretny scenariusz z życia dobrze ilustruje to zagrożenie: rozważmy serwis informacyjny, który automatycznie odtwarza film promocyjny zawierający szybką sekwencję naprzemiennych jasnych i ciemnych klatek — częsty artefakt niektórych metod kompresji wideo lub efektów lampy błyskowej aparatu. Osoba z padaczką fotowrażliwą odwiedza stronę główną podczas porannego dojazdu do pracy na urządzeniu mobilnym. Bez jakiegokolwiek ostrzeżenia i bez możliwości wyłączenia treści zostaje wystawiona na sekwencję, która wywołuje napad podczas korzystania z transportu publicznego. Ten scenariusz nie jest hipotetyczny; miał miejsce w rzeczywistych kontekstach, w tym w głośnym incydencie z odcinkiem Pokémon z 2007 roku, który wywołał napady u setek widzów w Japonii, oraz w udokumentowanych przypadkach dotyczących internetowych jednostek reklamowych.

Poza wymiarem bezpieczeństwa, zgodność z tym kryterium ma również konsekwencje użytecznościowe dla ogółu odbiorców. Szybko błyskające treści tworzą złe warunki do czytania, zwiększają obciążenie poznawcze i są uznawane za rozpraszające oraz nieprofesjonalne w większości kontekstów projektowych. Eliminacja takich treści poprawia koncentrację, zmniejsza współczynnik odrzuceń i buduje zaufanie — co pozytywnie wpływa na wskaźniki SEO, takie jak czas spędzony na stronie i wskaźniki zaangażowania. Dodatkowo roboty wyszukiwarek w coraz większym stopniu uwzględniają Core Web Vitals i sygnały doświadczenia użytkownika w rankingach, a witryny z inwazyjnymi, błyskającymi reklamami lub animacjami mogą być pośrednio karane.

Powiązane Zasady Axe-core

WCAG 2.3.1 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie analizować właściwości fotometrycznych treści dynamicznych w czasie rzeczywistym. Żadna zautomatyzowana zasada axe-core nie mapuje się bezpośrednio na to kryterium. Przyczyny tego ograniczenia wynikają z podstawowego sposobu działania automatyzacji dostępności:

• Dlaczego automatyzacja tu zawodzi: Automatyczne skanery analizują statyczny DOM i CSS w danym momencie. Mogą wykryć, że istnieje animacja lub element wideo, ale nie są w stanie zmierzyć rzeczywistej częstotliwości błysków, wartości luminancji w każdej klatce ani przestrzennego obszaru błyskającego regionu postrzeganego przez człowieka z typowej odległości oglądania. Ustalenie, czy błysk przekracza próg 3 Hz lub próg obszaru 0,006 steradiana, wymaga fotometrycznej analizy klatka po klatce — zadania wymagającego dedykowanych narzędzi, takich jak Harding Flash and Pattern Analyzer (HFPA), Photosensitive Epilepsy Analysis Tool (PEAT) lub ręcznego przeglądu plików źródłowych animacji.
• Osadzone wideo i treści zewnętrzne: Znaczna część treści o najwyższym ryzyku (automatycznie odtwarzane reklamy wideo, osadzone widżety mediów społecznościowych, zewnętrzne biblioteki animacji) jest ładowana z domen zewnętrznych. Narzędzia automatyczne zazwyczaj nie mają dostępu do treści cross-origin na poziomie klatek, co uniemożliwia programową ocenę częstotliwości błysków w tych zasobach.
• Animacje GIF i canvas: Animowane pliki GIF i elementy HTML5 canvas renderują swoje klatki animacji poza normalnym drzewem dostępności. Axe-core i Lighthouse nie mają możliwości dekodowania czasu trwania klatek GIF ani przechwytywania wywołań rysowania canvas w celu obliczenia zmian luminancji między klatkami.
• Animacje CSS i JavaScript: Choć axe-core może wykryć obecność właściwości CSS animation lub transition, nie jest w stanie ocenić, czy wynikowy efekt wizualny w czasie wykonywania powoduje zmiany luminancji przekraczające ogólny próg błysku lub próg czerwonego błysku.

Ponieważ żadne zautomatyzowane reguły nie wychwytują tego naruszenia, cały ciężar zgodności spoczywa na ręcznym przeglądzie projektów, analizie wideo przed publikacją oraz świadomości deweloperów na etapie tworzenia treści. To sprawia, że kluczowe dla trwałej zgodności są procesy redakcyjne i kontrola QA — nie tylko techniczne działania naprawcze.

Jak Testować

1. Sporządź inwentarz wszystkich treści dynamicznych: Przed jakimkolwiek testowaniem narzędziowym przeprowadź audyt strony pod kątem wszystkich treści, które się poruszają, błyskają, migają lub animują. Obejmuje to automatycznie odtwarzane filmy, animowane GIF-y, animacje kluczowe CSS, animacje sterowane JavaScriptem, animacje SVG, elementy canvas oraz osadzone widżety zewnętrzne, takie jak jednostki reklamowe czy osadzenia mediów społecznościowych. Udokumentuj każdy przypadek wraz z jego źródłem i mechanizmem sterowania.
2. Użyj Photosensitive Epilepsy Analysis Tool (PEAT): PEAT to bezpłatne narzędzie opracowane przez Trace Research and Development Center, zaprojektowane specjalnie do analizy treści wideo pod kątem zagrożeń błyskami zgodnie ze specyfikacją Hardinga. Nagraj zrzut ekranu strony internetowej lub analizowanej animacji w pełnej rozdzielczości, a następnie zaimportuj plik wideo do PEAT. Narzędzie zgłosi, czy jakakolwiek sekwencja przekracza ogólny próg błysku lub próg czerwonego błysku oraz w jakich znacznikach czasu.
3. Zastosuj Harding Flash and Pattern Analyzer dla treści o jakości emisyjnej: W przypadku treści wideo, które będą osadzane z procesów produkcyjnych (np. strony nadawców, serwisy informacyjne), przed publikacją przepuść pliki źródłowe wideo przez HFPA. Jest to narzędzie złotego standardu do wstępnego screeningu.
4. Obserwacja manualna — liczenie trzech błysków: W przypadku animacji CSS, efektów JavaScript lub plików GIF, dla których analiza narzędziowa jest niepraktyczna, odtwórz animację i spróbuj policzyć liczbę pełnych cykli jasne–ciemne–jasne w ciągu jednej sekundy. Jeśli zaobserwujesz trzy lub więcej pełnych cykli na sekundę, treść prawdopodobnie jest niezgodna. Użyj oprogramowania do nagrywania ekranu z odtwarzaniem klatka po klatce, aby wspomóc to liczenie.
5. Sprawdź treści wideo klatka po klatce: Otwórz pliki wideo w edytorze wideo (np. DaVinci Resolve, wersja bezpłatna), który wyświetla dane waveform lub histogram na poziomie klatek. Przewijaj fragmenty z szybkimi zmianami wizualnymi i sprawdzaj naprzemienne wzorce wysokiej i niskiej luminancji występujące więcej niż trzy razy na sekundę. Zwróć szczególną uwagę na sekwencje z nasyconą czerwienią na ciemnym tle.
6. Testuj za pomocą narzędzi deweloperskich przeglądarki dla animacji CSS: W Chrome DevTools otwórz panel Animations (More Tools → Animations). Sprawdź zadeklarowane czasy trwania animacji i cykle iteracji. Animacja o czasie trwania krótszym niż 333 milisekundy, która przy każdej iteracji przełącza się między stanami o wysokim kontraście, przekroczy próg 3 Hz. Oblicz: jeśli pełny cykl jasne–ciemne–jasne kończy się w czasie krótszym niż 333 ms, treść jest niezgodna.
7. Oceń obszar przestrzenny w przypadkach granicznych: Jeśli treść błyska z częstotliwością powyżej 3 Hz, ale wydaje się bardzo mała na ekranie, zmierz jej wymiary w pikselach. Na ekranie o szerokości 1024 pikseli przy normalnej odległości oglądania (około 57–60 cm) próg bezpiecznego obszaru wynosi około 21 824 piksele kwadratowe. Pomnóż szerokość i wysokość błyskającego regionu; jeśli wynik jest poniżej tego progu, treść może mieścić się w wyjątku bezpiecznego obszaru — ale dokładnie udokumentuj tę ocenę.
8. Przetestuj automatycznie odtwarzane wideo po załadowaniu strony: Po załadowaniu strony nie wykonuj żadnych interakcji i obserwuj, czy jakiekolwiek wideo lub animacja zaczyna odtwarzać się automatycznie. Jeśli tak się dzieje, natychmiast zastosuj powyższe testy do automatycznie odtwarzanych treści, ponieważ użytkownik nie ma możliwości interwencji przed ekspozycją.

Jak Naprawić

Automatycznie odtwarzany GIF z szybkim błyskiem — Nieprawidłowe

<!-- An animated GIF that cycles between a bright yellow and black frame
     at approximately 10 times per second, far exceeding the 3 Hz threshold -->
<img src='attention-flash.gif' alt='Special offer alert' width='600' height='300'>

Automatycznie odtwarzany GIF z szybkim błyskiem — Prawidłowe

<!-- Replace the flashing GIF with a static image and use a subtle CSS
     animation that does not alter luminance rapidly. The animation here
     uses a gentle scale pulse at a rate well below 3 Hz (one cycle per 2 seconds). -->
<img src='attention-static.png'
     alt='Special offer alert'
     class='pulse-attention'
     width='600'
     height='300'>

<style>
  @keyframes gentlePulse {
    0%, 100% { transform: scale(1); }
    50% { transform: scale(1.03); }
  }
  .pulse-attention {
    animation: gentlePulse 2s ease-in-out infinite;
  }
</style>

Animacja kluczowa CSS migająca między kolorami o wysokim kontraście — Nieprawidłowe

<!-- A CSS animation that alternates a banner between white and black
     with a 100ms total duration, producing 10 flashes per second -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 0.1s linear infinite;
  }
</style>

Animacja kluczowa CSS migająca między kolorami o wysokim kontraście — Prawidłowe

<!-- Slowing the animation duration to 1 second per full cycle means
     the luminance alternates once per second (1 Hz), well below the 3 Hz limit.
     Alternatively, use prefers-reduced-motion to disable animation entirely
     for users who have opted into reduced motion at the OS level. -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 1s linear infinite;
  }

  @media (prefers-reduced-motion: reduce) {
    .flash-banner {
      animation: none;
      background-color: #1a1a8c;
      color: #ffffff;
    }
  }
</style>

Osadzone automatycznie odtwarzane wideo z sekwencjami błysków — Nieprawidłowe

<!-- Auto-playing video with no controls, no PEAT analysis performed,
     and no mechanism for the user to stop or pause before exposure -->
<video src='promo.mp4' autoplay loop muted width='800' height='450'></video>

Osadzone automatycznie odtwarzane wideo z sekwencjami błysków — Prawidłowe

<!-- Best practice: provide controls so users can pause immediately,
     add a poster frame so no video plays without interaction,
     or use preload='none' to prevent auto-loading. If autoplay is
     genuinely required by business logic, the video MUST have been
     screened with PEAT or HFPA and confirmed free of flash hazards. -->
<video
  src='promo-screened.mp4'
  controls
  muted
  preload='metadata'
  poster='promo-poster.jpg'
  width='800'
  height='450'>
  <track kind='captions' src='promo-captions.vtt' srclang='tr' label='Türkçe'>
</video>
<p>Bu video flaş analizi aracıyla (PEAT) incelenmiş ve güvenli bulunmuştur.</p>

Najczęstsze Błędy

• Założenie, że pliki GIF są domyślnie bezpieczne: Wielu deweloperów uważa, że ponieważ animowane GIF-y są formatem „legacy”, są z natury nieszkodliwe. W rzeczywistości GIF-y mogą przełączać się między klatkami z częstotliwością przekraczającą 3 Hz, a format nie nakłada żadnego technicznego limitu na liczbę klatek na sekundę. Każdy GIF z naprzemiennymi klatkami o wysokim kontraście musi zostać zmierzony pod względem czasu trwania.
• Pomijanie zewnętrznych skryptów reklamowych: Sieci reklam displayowych często serwują kreacje zawierające błyskające lub migające animacje. Wydawcy, którzy osadzają tagi reklamowe bez przeglądu treści kreacji, nadal ponoszą odpowiedzialność za wszelkie naruszenia WCAG 2.3.1, które te reklamy powodują na ich stronach. Wdroż polityki przeglądu kreacji reklamowych i wymagania kontraktowe wobec sieci reklamowych.
• Mylenie WCAG 2.3.1 z WCAG 2.2.2 (Pause, Stop, Hide): Niektóre zespoły rozwiązują symptom, dodając przycisk pauzy (co spełnia 2.2.2), ale nie zajmują się podstawową częstotliwością błysków (co narusza 2.3.1). Te dwa kryteria są niezależne: kontrolka pauzy nie sprawia wstecznie, że treść, która już zaczęła błyskać, staje się zgodna z 2.3.1, ponieważ użytkownik jest narażony, zanim zdąży zareagować.
• Brak odrębnego uwzględnienia progu czerwonego błysku: Deweloperzy świadomi ogólnego progu 3 Hz czasem pomijają odrębny próg czerwonego błysku. Treści z szybko naprzemiennymi nasyconymi wartościami czerwieni mogą wywoływać napady fotowrażliwe nawet przy częstotliwościach nieco poniżej 3 Hz u niektórych osób. Animacje z nasyconą czerwienią powinny być analizowane ze szczególną uwagą.
• Ignorowanie treści ładowanych w iframe: Strony osadzające treści zewnętrzne za pomocą elementów <iframe> — w tym widżety mediów społecznościowych, narzędzia czatu na żywo czy osadzone pulpity — odpowiadają za dostępność tych treści w formie renderowanej na ich stronie. Zagrożenia błyskami w iframe są równie niebezpieczne jak w dokumencie głównym.
• Pomijanie implementacji media query prefers-reduced-motion: Nawet jeśli podstawowe animacje są poniżej progu 3 Hz, brak implementacji @media (prefers-reduced-motion: reduce) oznacza, że osoby, które zadeklarowały na poziomie systemu operacyjnego preferencję ograniczonego ruchu, nie otrzymują żadnego dostosowania. Choć jest to przede wszystkim przedmiotem WCAG 2.3.3 na poziomie AAA, uwzględnienie tego zapytania jest niskokosztową, a bardzo skuteczną praktyką, która pokazuje zaangażowanie w dostępność i zmniejsza ryzyko.
• Używanie JavaScript setInterval lub requestAnimationFrame bez ograniczania częstotliwości: Animacje sterowane przez setInterval(fn, 50) wywołują się co 50 milisekund, co daje 20 cykli na sekundę — znacznie powyżej limitu 3 Hz. Deweloperzy muszą jawnie obliczyć czas interwału wymagany do utrzymania częstotliwości na poziomie co najwyżej jednej zmiany na 333 ms dla każdej animacji zmieniającej luminancję.
• Brak screeningu treści wideo przed publikacją: Wiele organizacji ma proces publikacji obejmujący wizualne QA i przegląd praw autorskich, ale pozbawiony kroku screeningu pod kątem zagrożeń błyskami. Bez włączenia PEAT lub HFPA do procesu przed publikacją, zagrożenia fotowrażliwością w treściach wideo mogą pozostać niewykryte aż do momentu wyrządzenia szkody.
• Traktowanie wyjątku rozmiaru jako łatwego do wykorzystania: Niektórzy deweloperzy poznają wyjątek bezpiecznego obszaru 0,006 steradiana i próbują używać go do uzasadnienia pozostawienia niebezpiecznych efektów błysków, zmniejszając ich rozmiar. W praktyce dokładne obliczenie, czy treść mieści się w progu, wymaga znajomości odległości oglądania i rozdzielczości wyświetlacza — zmiennych, których deweloper nie kontroluje. Poleganie na wyjątku rozmiaru bez fotometrycznych pomiarów jest ryzykowne i prawnie niepewne.
• Brak dokumentowania ocen zagrożeń błyskami: Organizacje, które testują treści wideo lub animacje pod kątem zagrożeń błyskami, często nie przechowują zapisów tych ocen. W przypadku skargi użytkownika lub audytu regulacyjnego udokumentowane dowody, że przeprowadzono screening PEAT lub HFPA i że treści uznano za zgodne, są kluczowe dla wykazania należytej staranności.

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

Okrężnik Prezydencki Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych i aplikacji mobilnych, zgodne z WCAG 2.2. WCAG 2.3.1, jako kryterium sukcesu na poziomie A, mieści się w zakresie obowiązkowej zgodności dla wszystkich objętych podmiotów.

Okrężnik definiuje etapowy harmonogram zgodności: instytucje i agencje publiczne muszą osiągnąć pełną zgodność na poziomie A w ciągu roku od daty wejścia w życie okrężnika, podczas gdy podmioty sektora prywatnego objęte regulacją mają dwa lata na dostosowanie. Biorąc pod uwagę krytyczny dla bezpieczeństwa charakter WCAG 2.3.1 — który bezpośrednio wiąże się z ryzykiem wywołania nagłych zdarzeń medycznych u użytkowników — niezgodność z tym konkretnym kryterium niesie ze sobą podwyższone ryzyko reputacyjne i prawne, nawet w porównaniu z innymi wymaganiami poziomu A.

Następujące typy podmiotów są wyraźnie objęte Okrężnikiem Prezydenckim 2025/10 i muszą zatem spełniać WCAG 2.3.1:

• Instytucje publiczne i agencje rządowe: Wszystkie centralne i lokalne organy administracji, ministerstwa, gminy i organizacje powiązane z państwem prowadzące serwisy internetowe lub aplikacje mobilne skierowane do obywateli.
• Platformy e-commerce: Operatorzy handlu detalicznego online i platform marketplace oferujący towary lub usługi konsumentom za pośrednictwem platform cyfrowych, niezależnie od branży.
• Banki i instytucje finansowe: Wszystkie licencjonowane banki, banki partycypacyjne, firmy inwestycyjne i operatorzy fintech świadczący cyfrowe usługi bankowe lub finansowe.
• Szpitale i świadczeniodawcy opieki zdrowotnej: Publiczne i prywatne szpitale, przychodnie i sieci opieki zdrowotnej oferujące usługi cyfrowe skierowane do pacjentów, w tym rezerwację wizyt i portale pacjenta.
• Przedsiębiorstwa telekomunikacyjne z 200 000 lub większą liczbą abonentów: Główni operatorzy sieci komórkowych i dostawcy usług internetowych spełniający próg liczby abonentów, w tym ich portale samoobsługowe i aplikacje mobilne.
• Biura podróży: Licencjonowane biura podróży i turystyki oferujące rezerwacje online, usługi rezerwacyjne lub informacyjne.
• Prywatne przedsiębiorstwa transportowe: Linie lotnicze, przewoźnicy autobusowi dalekobieżni, operatorzy promów i inni prywatni przewoźnicy prowadzący platformy cyfrowe skierowane do konsumentów.
• Prywatne szkoły autoryzowane przez Ministerstwo Edukacji Narodowej (MoNE): Prywatne instytucje edukacyjne z autoryzacją MoNE, które prowadzą strony internetowe lub cyfrowe platformy edukacyjne.

Dla podmiotów objętych regulacją zgodność z WCAG 2.3.1 wymaga nie tylko jednorazowego audytu, ale ciągłego zaangażowania operacyjnego. Ponieważ zagrożenia błyskami są najczęściej wprowadzane poprzez treści dynamiczne — przesyłane filmy, animacje marketingowe, reklamy zewnętrzne — organizacje muszą wbudować screening zagrożeń błyskami w swoje procesy publikacji treści, a nie ograniczać się do wstępnego audytu serwisu. Wykorzystanie narzędzi takich jak PEAT do screeningu wideo przed publikacją, w połączeniu ze szkoleniami deweloperów w zakresie bezpiecznych częstotliwości animacji i implementacji CSS prefers-reduced-motion, stanowi minimalny standard należytej staranności operacyjnej oczekiwany od podmiotów objętych okrężnikiem. Organizacje polegające na zewnętrznych systemach zarządzania treścią lub systemach reklamowych muszą również zapewnić postanowienia umowne wymagające zgodności z WCAG 2.3.1 od swoich dostawców, ponieważ obowiązek regulacyjny spoczywa na podmiocie prowadzącym cyfrową usługę skierowaną do społeczeństwa.