WCAG 2.5.4: Uruchamianie ruchem

Co Oznacza Ta Zasada

WCAG 2.5.4 — Uruchamianie Ruchem dotyczy konkretnego, ale coraz częściej spotykanego scenariusza we współczesnych aplikacjach webowych: funkcjonalności uruchamianej przez fizyczny ruch urządzenia, taki jak potrząśnięcie smartfonem, przechylenie urządzenia czy wykonanie gestu przed kamerą. Kryterium ustanawia dwa równoległe wymagania, które muszą być spełnione jednocześnie, aby uzyskać zgodność.

Po pierwsze, każda funkcjonalność, którą można obsłużyć ruchem urządzenia lub ruchem użytkownika, musi być również możliwa do obsłużenia za pomocą komponentu interfejsu użytkownika — czyli przycisku, linku, kontrolki formularza lub podobnego interaktywnego elementu, który nie opiera się na ruchu. Zapewnia to, że osoby, które nie mogą wykonywać lub nie mogą wiarygodnie wykonywać gestów ruchowych, nie są całkowicie wykluczone z dostępu do tej funkcjonalności.

Po drugie, użytkownicy muszą mieć możliwość wyłączenia reakcji na ruch, tak aby przypadkowy lub mimowolny ruch nie wywoływał niezamierzonych działań. Chroni to użytkowników z drżeniem lub innymi zaburzeniami motorycznymi powodującymi mimowolne poruszanie urządzeniem przed ciągłymi zakłóceniami przez nieoczekiwane zachowanie aplikacji.

Kryterium dotyczy dwóch odrębnych typów ruchu: ruchu urządzenia, wykrywanego przez czujniki takie jak akcelerometry i żyroskopy wbudowane w smartfony i tablety (dostępne przez API takie jak DeviceMotionEvent i DeviceOrientationEvent), oraz ruchu użytkownika, wykrywanego przez kamery lub inne czujniki wejściowe śledzące ruch ciała lub gesty, a nie samo urządzenie.

Poprawna implementacja udostępnia całą funkcjonalność uruchamianą ruchem poprzez standardowy kontroler UI (przycisk, link lub odpowiednik) ORAZ pozwala użytkownikowi wyłączyć wykrywanie ruchu, jeśli tego chce. Niepoprawna implementacja albo zapewnia dostęp do funkcji wyłącznie przez ruch, bez alternatywnego kontrolera UI, albo zapewnia alternatywę, ale nie oferuje sposobu wyłączenia wyzwalacza ruchu, przez co mimowolny ruch nadal powoduje problemy.

WCAG 2.5.4 definiuje dwa ważne wyjątki. Uruchamianie ruchem jest wyłączone z wymagań, jeśli ruch jest niezbędny dla funkcji i jego wyłączenie zasadniczo zmieniłoby charakter aktywności — na przykład w aplikacji fitness liczącej kroki, w której śledzenie ruchu jest głównym celem, lub w grze zaprojektowanej wprost wokół mechaniki przechylania. Drugi wyjątek ma zastosowanie, gdy ruch jest używany do obsługi funkcjonalności poprzez wspierany interfejs dostępności, co oznacza, że platformowe funkcje dostępności obsługują interakcję ruchem w sposób kontrolowany samodzielnie przez użytkownika.

Dlaczego To Ma Znaczenie

Bariery związane z uruchamianiem ruchem w nieproporcjonalnym stopniu dotykają osoby z niepełnosprawnościami motorycznymi i ograniczeniami mobilności, ale wpływ jest szerszy, niż wielu deweloperów początkowo zakłada. Zrozumienie, kogo to dotyczy — i w jaki sposób — pomaga zespołom odpowiednio priorytetyzować to kryterium.

Osoby z zaburzeniami drżenia — w tym z drżeniem samoistnym, chorobą Parkinsona i stwardnieniem rozsianym — mogą doświadczać stałego lub okresowego mimowolnego ruchu rąk i ramion. Gdy trzymają smartfon, ich naturalne drżenie wystarcza, by wielokrotnie i nieoczekiwanie wywoływać okna dialogowe „potrząśnij, aby cofnąć”, akcje odświeżania lub inne funkcje aktywowane ruchem. Światowa Organizacja Zdrowia szacuje, że około 1,3 miliarda ludzi na świecie żyje z jakąś formą znaczącej niepełnosprawności, a schorzenia wpływające na precyzyjną kontrolę motoryczną należą do najpowszechniejszych we wszystkich grupach wiekowych.

Osoby z paraliżem lub różnicami w budowie kończyn mogą korzystać z urządzeń zamontowanych na wózkach inwalidzkich lub stojakach albo używać wskaźników głowy, śledzenia wzroku czy przełączników do interakcji z urządzeniami. Użytkownicy ci często w ogóle nie mogą potrząsać ani przechylać urządzenia, co sprawia, że funkcje dostępne wyłącznie przez ruch są całkowicie niedostępne. Jeśli jedynym sposobem cofnięcia wpisanego tekstu w mobilnej aplikacji webowej jest potrząśnięcie urządzeniem, użytkownik wózka z zamontowanym telefonem po prostu nie ma dostępu do tej funkcji.

Osoby starsze to kolejna istotnie dotknięta grupa. Schorzenia związane z wiekiem, w tym osłabienie siły chwytu, zapalenie stawów i drżenie samoistne, stają się coraz powszechniejsze wraz z wiekiem, co oznacza, że rosnący segment populacji — który jest jednocześnie coraz bardziej aktywny cyfrowo — może mieć trudności z precyzyjnymi lub zamierzonymi gestami ruchowymi.

Rozważmy konkretny scenariusz z życia: turecki serwis e-commerce dodaje funkcję „potrząśnij, aby przetasować”, która pokazuje użytkownikom losową rekomendację produktu po potrząśnięciu telefonem, czyniąc przeglądanie bardziej angażującym. Funkcja jest zabawna i nowatorska, ale nie ma równoważnego przycisku do wywołania tasowania ani sposobu wyłączenia wykrywania potrząśnięcia. Użytkownik z chorobą Parkinsona, który odwiedza ten serwis, doświadcza ciągłych, niekontrolowanych aktywacji tasowania, gdy jego naturalne drżenie wyzwala gest. Nie może spokojnie przeglądać, ponieważ strona wciąż przeskakuje do losowych produktów. Taki użytkownik jest w praktyce pozbawiony normalnego doświadczenia zakupowego — a zgodnie z tureckimi regulacjami dotyczącymi dostępności nie jest to jedynie problem UX, lecz naruszenie wymogów prawnych.

Poza dostępnością dla osób z niepełnosprawnościami, wyłączanie lub zapewnianie alternatyw dla funkcji ruchowych poprawia również doświadczenie użytkowników w środowiskach, w których ruch urządzenia jest nieprzewidywalny — w transporcie publicznym, w biurach lub w dowolnym miejscu, gdzie użytkownik nie może swobodnie poruszać urządzeniem.

Powiązane Zasady Axe-core

WCAG 2.5.4 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie wykryć obecności lub braku funkcjonalności opartej na ruchu wyłącznie poprzez analizę statycznego HTML i CSS. Uruchamianie ruchem zależy od nasłuchiwaczy zdarzeń JavaScript i zachowania w czasie działania, którego skanery automatyczne nie mogą w pełni przeanalizować. Poniżej wyjaśniono, dlaczego automatyzacja jest niewystarczająca i co musi obejmować ocena manualna.

• Nie istnieje bezpośrednia zautomatyzowana reguła axe-core dla 2.5.4. Axe-core i podobne silniki automatyczne działają poprzez inspekcję DOM, atrybutów ARIA i obliczonych stylów. Nie mogą zaobserwować, czy strona zarejestrowała nasłuchiwacz zdarzeń devicemotion lub deviceorientation, ani ustalić, czy istnieje równoważny kontroler UI dla jakiejkolwiek funkcjonalności uruchamianej ruchem. Strona może mieć rozbudowaną interaktywność opartą na ruchu bez żadnych widocznych w DOM wskaźników, co czyni automatyczne wykrywanie z natury niewiarygodnym. Axe-core oznacza zatem to kryterium jako wymagające przeglądu manualnego, zamiast próbować automatycznego wykrywania, które generowałoby wysoki odsetek fałszywie negatywnych wyników.
• Wymagana jest manualna inspekcja nasłuchiwaczy zdarzeń JavaScript. Testerzy muszą użyć narzędzi deweloperskich przeglądarki, aby wyszukać rejestracje DeviceMotionEvent, DeviceOrientationEvent oraz API kamery/wizji, takich jak Shape Detection API. Panel Event Listeners w DevTools przeglądarki może ujawnić, czy te zdarzenia są podłączone do obiektu window lub document.
• Równoważność funkcjonalna nie może być zautomatyzowana. Nawet gdyby narzędzie mogło wykryć nasłuchiwacz ruchu, nie byłoby w stanie ustalić, czy przycisk lub link w innym miejscu interfejsu zapewnia tę samą funkcjonalność. Ocena równoważności funkcjonalnej wymaga testera-ludzi, który rozumie funkcje aplikacji i może zweryfikować, że każda akcja uruchamiana ruchem ma osiągalną, działającą alternatywę w UI.
• Możliwość wyłączenia nie może być zautomatyzowana. Ustalenie, czy użytkownik może wyłączyć reakcje na ruch, wymaga interakcji z ustawieniami lub preferencjami aplikacji — jest to test behawioralny, którego narzędzia automatyczne nie są zaprojektowane, by wykonywać go w sposób kompleksowy.

Jak Testować

1. Automatyczne skanowanie jako punkt wyjścia: Uruchom axe DevTools, Lighthouse lub checker dostępności Accsible na stronie. Narzędzia te nie zgłoszą automatycznie naruszeń 2.5.4, ale mogą ujawnić powiązane problemy. Zanotuj wszystkie zgłoszone elementy, a następnie przejdź do kroków manualnych. Brak automatycznych zgłoszeń nie oznacza, że strona spełnia 2.5.4.
2. Identyfikacja funkcjonalności uruchamianej ruchem: Otwórz Chrome DevTools i przejdź do panelu Elements. Przeszukaj pliki źródłowe JavaScript strony (używając zakładki Sources i globalnego wyszukiwania Ctrl+Shift+F) pod kątem ciągów devicemotion, deviceorientation, accelerat, gyro i shake. Udokumentuj każdy znaleziony przypadek i powiązaną funkcjonalność.
3. Weryfikacja istnienia alternatyw UI: Dla każdej funkcjonalności uruchamianej ruchem wykrytej w poprzednim kroku spróbuj wykonać tę samą akcję, używając wyłącznie nawigacji klawiaturą i kliknięć myszą — bez ruchu urządzenia. Nawiguj po interfejsie za pomocą Tab, Enter, Spacji i klawiszy strzałek. Jeśli nie możesz znaleźć działającego kontrolera UI, który osiąga ten sam rezultat, kryterium nie jest spełnione.
4. Weryfikacja możliwości wyłączenia ruchu: Poszukaj menu ustawień, panelu preferencji, ustawień dostępności lub przełącznika specyficznego dla funkcji ruchowych. Spróbuj wyłączyć uruchamianie ruchem. Jeśli taki kontroler nie istnieje lub jeśli wyłączenie ruchu powoduje również wyłączenie alternatywy UI, kryterium nie jest spełnione.
5. Testowanie na fizycznym urządzeniu: Załaduj stronę na rzeczywistym smartfonie lub tablecie. Celowo poruszaj urządzeniem delikatnie (symulując mimowolne drżenie — małe, ciągłe ruchy) i obserwuj, czy funkcjonalność jest uruchamiana niezamierzenie. Następnie wykonaj ten sam test po wyłączeniu ruchu w dostępnych ustawieniach.
6. Testowanie z czytnikiem ekranu i klawiaturą: Używając NVDA z Firefoxem, VoiceOver z Safari na iOS lub JAWS z Chrome, nawiguj po stronie wyłącznie za pomocą klawiatury i poleceń czytnika ekranu. Potwierdź, że cała funkcjonalność dostępna przez ruch jest również osiągalna poprzez nawigację czytnikiem ekranu oraz że kontroler wyłączania ruchu (jeśli istnieje) jest sam w sobie dostępny z klawiatury i poprawnie opisany.
7. Symulacja urządzenia w narzędziach DevTools przeglądarki: W Chrome DevTools otwórz panel Sensors (More Tools > Sensors) i użyj kontrolek symulacji orientacji urządzenia i akcelerometru, aby programowo wywoływać zdarzenia ruchu. Umożliwia to testowanie zachowania uruchamianego ruchem na desktopie bez fizycznego urządzenia.

Jak Naprawić

Potrząśnij, aby odświeżyć, bez alternatywy — Niepoprawne

<!-- Nasłuchiwacz ruchu podłączony, ale nie zapewniono przycisku UI do odświeżania -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Potrząśnij, aby odświeżyć, bez alternatywy — Poprawne

<!-- Alternatywa dla ruchu: widoczny przycisk zapewnia tę samą akcję odświeżania.
     Przełącznik w ustawieniach pozwala użytkownikom całkowicie wyłączyć wyzwalacz ruchu. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Karuzela przewijana przechyleniem bez opcji wyłączenia — Niepoprawne

<!-- Karuzela przesuwa się przy przechyleniu urządzenia; brak sposobu, by to wyłączyć -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Karuzela przewijana przechyleniem bez opcji wyłączenia — Poprawne

<!-- Przyciski Poprzedni/Następny zapewniają alternatywy UI.
     Pole wyboru w ustawieniach pozwala użytkownikom zrezygnować z sterowania przechyleniem.
     Karuzela jest również dostępna z klawiatury za pomocą klawiszy strzałek. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Funkcja gestu przed kamerą bez alternatywy — Niepoprawne

<!-- Użytkownik macha ręką przed kamerą, aby zamknąć modal;
     nie istnieje przycisk ani metoda klawiaturowa, by zamknąć go w inny sposób -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Funkcja gestu przed kamerą bez alternatywy — Poprawne

<!-- Wyraźnie opisany przycisk zamykania zapewnia alternatywę UI.
     Modal jest w pełni obsługiwany z klawiatury, a fokus jest poprawnie zarządzany. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Typowe Błędy

• Zapewnienie alternatywnego przycisku UI, ale pominięcie przełącznika wyłączającego ruch: Wielu deweloperów dodaje równoważny przycisk, ale nigdy nie implementuje sposobu wyłączenia nasłuchiwacza ruchu, przez co użytkownicy z drżeniem nadal doświadczają niechcianych aktywacji, mimo że funkcja jest technicznie obsługiwana innymi metodami.
• Ukrywanie opcji wyłączenia ruchu w menu hamburger lub głęboko w ustawieniach: Kontroler wyłączający ruch musi być sam w sobie łatwo osiągalny. Jeśli użytkownik z drżeniem wielokrotnie wyzwala „potrząśnij, aby odświeżyć”, zanim zdoła przejść przez pięć poziomów menu, aby to wyłączyć, opcja wyłączenia nie jest praktycznie dostępna.
• Założenie, że preferencja systemowa „ogranicz ruch” spełnia 2.5.4: Media query prefers-reduced-motion i ustawienia dostępności systemu operacyjnego dotyczą animacji i problemów przedsionkowych, ale nie wyłączają automatycznie nasłuchiwaczy zdarzeń ruchu urządzenia w aplikacjach webowych. Musisz obsłużyć to we własnym kodzie.
• Ustawianie zbyt niskich progów ruchu: Używanie bardzo czułych progów dla wartości przyspieszenia DeviceMotionEvent oznacza, że drobne, mimowolne drżenia mogą przekraczać próg. Progi powinny wymagać zamierzonego, ruchu o dużej amplitudzie, a nawet wtedy wymagany jest przełącznik wyłączający.
• Rejestrowanie nasłuchiwaczy ruchu globalnie na window bez ich usuwania: Podłączenie nasłuchiwacza i brak jakiejkolwiek ścieżki kodu do jego usunięcia za pomocą removeEventListener oznacza, że przełącznik wyłączający może jedynie warunkowo tłumić zachowanie — jeśli sam przełącznik zawiedzie lub zresetuje się po przeładowaniu strony, ruch pozostaje aktywny.
• Uczynienie pola wyboru wyłączającego ruch niedostępnym: Implementowanie przełącznika wyłączającego jako ostylowanego <div> lub <span> z nasłuchiwaczem kliknięcia zamiast jako właściwego <input type='checkbox'> lub kontrolki z ARIA oznacza, że użytkownicy klawiatury i czytników ekranu nie mogą dotrzeć do kontrolera, który ma im pomagać.
• Brak utrwalania preferencji ruchu użytkownika między sesjami: Jeśli użytkownik wyłącza uruchamianie ruchem, ale preferencja nie jest zapisywana (np. w localStorage lub ustawieniach konta użytkownika), musi wyłączać ją przy każdej wizycie, co tworzy powtarzalne obciążenie dla osób najbardziej dotkniętych.
• Zbyt szerokie stosowanie wyjątku funkcji niezbędnej: Wyjątek „niezbędności” jest wąski. Galeria produktów używająca „potrząśnij, aby przetasować” nie jest niezbędna — funkcja tasowania nie jest główną funkcją serwisu zakupowego. Zespoły czasem błędnie stosują ten wyjątek, aby uniknąć pracy implementacyjnej.
• Brak testów na rzeczywistym fizycznym urządzeniu z faktycznym ruchem: Poleganie wyłącznie na narzędziach symulacyjnych desktop lub skanach automatycznych oznacza, że rzeczywiste problemy z czułością na ruch — w tym zachowanie funkcji, gdy użytkownik ma naturalne drżenie — nie są wykrywane, dopóki nie zgłoszą ich użytkownicy.
• Zapominanie, że funkcje ruchowe dodane przez zewnętrzne SDK lub biblioteki analityczne również muszą być zgodne: Nasłuchiwacze ruchu osadzone w zewnętrznych widgetach czatu, SDK grywalizacyjnych lub narzędziach A/B testingu nadal wchodzą w zakres odpowiedzialności strony za zgodność. Jeśli skrypt zewnętrzny rejestruje nasłuchiwacz devicemotion bez zapewnienia alternatywy, strona nie spełnia 2.5.4.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okrężnica Prezydencka nr 2025/10, opublikowana w Dzienniku Urzędowym (nr 32933) 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dostępności stron internetowych zgodne z WCAG 2.2. WCAG 2.5.4 Uruchamianie Ruchem jest kryterium poziomu A, co oznacza, że znajduje się w najwyższym priorytetowym poziomie obowiązkowej zgodności na mocy tej okrężnicy.

Okrężnica obejmuje szeroki zakres podmiotów publicznych i prywatnych. Instytucje publiczne — w tym wszystkie centralne i lokalne organy administracji, ministerstwa i agencje publiczne — muszą osiągnąć pełną zgodność z poziomem A w ciągu jednego roku od publikacji okrężnicy. Podmioty sektora prywatnego w objętych kategoriach muszą osiągnąć ten sam standard w ciągu dwóch lat. Objęte kategorie sektora prywatnego obejmują platformy i rynki e-commerce, banki i instytucje finansowe, szpitale i prywatnych świadczeniodawców opieki zdrowotnej, firmy telekomunikacyjne z 200 000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy transportowe oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE).

Uruchamianie ruchem ma szczególne znaczenie dla tureckich usług cyfrowych, ponieważ korzystanie z internetu mobilnego w Turcji jest bardzo wysokie, a większość ruchu webowego pochodzi ze smartfonów. Aplikacje webowe projektowane w modelu mobile-first i mobile-only są zatem niezwykle powszechne we wszystkich objętych sektorach. Każdy turecki serwis e-commerce, aplikacja bankowa lub portal rządowy, który wdrożył „potrząśnij, aby odświeżyć”, nawigację przechyleniem, interakcje oparte na gestach lub podobne funkcje ruchowe bez zapewnienia alternatyw UI i kontrolerów wyłączania, pozostaje w bezpośredniej sprzeczności z obowiązkowym wymaganiem poziomu A na mocy Okrężnicy Prezydenckiej 2025/10.

Dla objętych podmiotów przygotowujących mapy drogowe zgodności, uruchamianie ruchem powinno być oceniane jako część szerszego audytu dostępności mobilnej. Ponieważ narzędzia automatyczne nie mogą wykrywać naruszeń 2.5.4, organizacje powinny uwzględnić testy manualne prowadzone przez wykwalifikowanych specjalistów ds. dostępności jako element procesu weryfikacji zgodności. Biorąc pod uwagę, że okrężnica nie przewiduje okresu przejściowego dla funkcji wdrożonych przed jej publikacją — a jedynie harmonogram osiągnięcia zgodności — wszelka funkcjonalność oparta na ruchu obecnie wdrożona na objętych stronach musi zostać naprawiona w ramach obowiązującego terminu.

Podmioty, które nie spełnią wymogów okrężnicy, mogą podlegać sankcjom administracyjnym i są objęte egzekwowaniem przez właściwe organy nadzorcze dla danego sektora. Poza ryzykiem regulacyjnym, brak zgodności z 2.5.4 na tureckiej stronie mobilnej o dużym ruchu stanowi realną porażkę użyteczności dla milionów użytkowników, którzy mogą doświadczać ograniczeń motorycznych, drżenia lub korzystać z technologii wspomagających — populacji, której potrzeby są wprost uznane i chronione przez przyjęcie WCAG 2.2 poziomu A jako standardu bazowego w tej okrężnicy.