WCAG 1.3.4: Orientacja

Co oznacza ta zasada

WCAG 1.3.4 Orientation to kryterium na poziomie AA wprowadzone w WCAG 2.1 i przeniesione do WCAG 2.2. Stanowi ono, że treść nie może być zablokowana w jednym ustawieniu orientacji ekranu — pionowym (portretowym) lub poziomym (landscape) — chyba że dana orientacja jest niezbędna do działania treści. W praktyce oznacza to, że strony internetowe i aplikacje webowe muszą reagować poprawnie i pozostawać w pełni obsługiwalne niezależnie od tego, czy urządzenie użytkownika jest trzymane pionowo czy poziomo, oraz niezależnie od tego, czy orientacja jest kontrolowana przez system operacyjny urządzenia, czy przez preferencje samego użytkownika.

Kryterium to dotyczy sytuacji, w których deweloperzy używają zapytań medialnych CSS, JavaScriptu lub interfejsów API urządzenia, aby celowo ograniczyć treść do jednej orientacji. Typowym naruszeniem jest wyświetlanie komunikatu w rodzaju „Obróć urządzenie do trybu poziomego”, przy jednoczesnym ukrywaniu lub wyłączaniu całej treści interaktywnej w trybie pionowym. Innym naruszeniem jest sytuacja, gdy aplikacja webowa stosuje transformację CSS lub wymusza obrót widoku (viewport), nadpisując ustawienia orientacji urządzenia użytkownika.

Co uznaje się za spełnienie wymogu: Treść jest dostępna zarówno w orientacji pionowej, jak i poziomej. Cały tekst, elementy interaktywne, formularze, nawigacja i multimedia pozostają widoczne i obsługiwalne niezależnie od orientacji urządzenia. Układ może się dostosowywać — z użyciem technik projektowania responsywnego, takich jak CSS Flexbox, CSS Grid czy media queries — ale nic nie jest usuwane ani unieczyniane wyłącznie ze względu na orientację.

Co uznaje się za naruszenie: Treść, która ukrywa, wyłącza lub blokuje interakcję w jednej orientacji; komunikaty nakazujące użytkownikom obrócenie urządzenia bez zapewnienia działającej alternatywy; JavaScript nasłuchujący DeviceOrientationEvent lub screen.orientation, a następnie blokujący lub wyłączający części interfejsu; albo CSS używający @media (orientation: portrait) do wyświetlania blokującej nakładki lub display: none na kluczowej treści.

Wyjątek „niezbędności”: WCAG uznaje, że niektóre treści mają z natury cel ściśle powiązany z określoną orientacją. Aplikacja klawiatury fortepianowej może zasadnie wymagać trybu poziomego, ponieważ układ pionowy nie jest w stanie wyświetlić wystarczającej liczby klawiszy, by była ona muzycznie użyteczna. Funkcja wpłaty czeku bankowego, która polega na tym, że aparat rejestruje poziomo ułożony czek, może wymagać trybu poziomego. Interfejs zestawu słuchawkowego VR może wymagać stałej orientacji, aby działać. Jednak próg dla „niezbędności” jest wysoki — zwykła wygoda dewelopera lub preferencje estetyczne nie kwalifikują się. Wyjątek musi być uzasadniony fundamentalnym wymogiem samej treści, a nie wyborem projektowym.

Dlaczego to ma znaczenie

Ograniczenia orientacji w nieproporcjonalny sposób dotykają osoby z niepełnosprawnościami fizycznymi i motorycznymi. Weźmy pod uwagę użytkownika w wózku inwalidzkim, którego tablet jest zamontowany na stałe w pozycji pionowej na podłokietniku. Nie może on fizycznie przechylić urządzenia, więc każda treść wymagająca orientacji poziomej staje się dla niego całkowicie niedostępna. Nie jest to hipotetyczny przypadek brzegowy — montowanie urządzeń wspomagających w stałej orientacji jest powszechnym udogodnieniem dla osób z takimi schorzeniami jak porażenie mózgowe, urazy rdzenia kręgowego, ALS czy ciężkie zapalenie stawów.

Poza urządzeniami montowanymi, wielu użytkowników polega na funkcji blokady orientacji w systemie operacyjnym z powodów niezwiązanych z niepełnosprawnością. Osoba leżąca w łóżku może zablokować telefon w orientacji pionowej, aby zapobiec ciągłemu obracaniu się ekranu. Osoba z zaburzeniami przedsionkowymi — schorzeniem dotyczącym ucha wewnętrznego i równowagi — może odczuwać nagłe zmiany układu spowodowane zmianą orientacji jako dezorientujące lub fizycznie wywołujące nudności. Zmuszanie takich użytkowników do odblokowania orientacji urządzenia, aby uzyskać dostęp do treści, tworzy niepotrzebną i dyskryminującą barierę.

Dostępność poznawcza również ma tu znaczenie. Użytkownicy z niepełnosprawnościami poznawczymi często odnoszą korzyści z układów spójnych i przewidywalnych. Aplikacja, która nagle blokuje treść lub wyświetla komunikat przypominający błąd z prośbą o obrócenie urządzenia, może być myląca i niepokojąca, szczególnie dla użytkowników, którzy mogą nie rozumieć, dlaczego ich urządzenie pokazuje ostrzeżenie zamiast oczekiwanej treści.

Z perspektywy użyteczności i biznesu ograniczenia orientacji szkodzą wszystkim użytkownikom. Znaczna część ruchu w sieci mobilnej odbywa się w trybie pionowym, a ograniczenie witryny do trybu poziomego może skutkować natychmiastowym porzuceniem. Wyszukiwarki coraz częściej uwzględniają przyjazność dla urządzeń mobilnych i Core Web Vitals — w tym stabilne zachowanie układu — w swoich algorytmach rankingowych, co oznacza, że problemy związane z orientacją mogą mieć mierzalny negatywny wpływ na wyniki SEO i ruch organiczny.

Na całym świecie około 1,3 miliarda osób żyje z jakąś formą niepełnosprawności według Światowej Organizacji Zdrowia. Znacząca część tej grupy używa urządzeń mobilnych jako podstawowego lub jedynego sposobu dostępu do internetu, co sprawia, że dostępność związana z orientacją na urządzeniach mobilnych ma szczególne znaczenie.

Powiązane reguły Axe-core

WCAG 1.3.4 Orientation wymaga testów manualnych. Nie istnieje zautomatyzowana reguła axe-core, która niezawodnie wykrywa ograniczenia orientacji, ponieważ naruszenie zależy od zachowania w czasie działania, warunkowej logiki renderowania i fizycznego stanu urządzenia — a żadnego z tych aspektów analiza statycznego DOM ani automatyczne skanowanie strony nie są w stanie ocenić. Poniżej wyjaśniono, dlaczego automatyzacja jest niewystarczająca i na co muszą zwracać uwagę testerzy manualni:

• Brak zautomatyzowanej reguły axe-core (wymagane testy manualne): Zautomatyzowane skanery dostępności, takie jak axe-core, Lighthouse czy IBM Equal Access Checker, analizują DOM i CSSOM w jednym momencie. Nie mogą zasymulować obrotu urządzenia, ocenić, co dzieje się z układem, gdy zmienia się screen.orientation, ani ustalić, czy blok @media (orientation: landscape) w CSS ukrywa kluczową treść. Skaner może widzieć, że wszystkie elementy są obecne i technicznie widoczne w orientacji, w której testuje, nie wiedząc, że połowa z nich znika w alternatywnej orientacji. Dlatego WCAG 1.3.4 jest sklasyfikowane jako wymagające testów manualnych — żadne narzędzie nie zastąpi faktycznego obrócenia prawdziwego urządzenia lub symulacji obrotu w narzędziach deweloperskich przeglądarki.
• Wykrywanie blokady orientacji w JavaScript: Skryptów wywołujących screen.orientation.lock() lub nasłuchujących window.addEventListener('orientationchange', ...) w celu przekierowania lub wyłączenia treści nie można wykryć analizą statyczną. Linter mógłby oznaczyć użycie tych interfejsów API w kodzie źródłowym, ale nie jest w stanie ustalić, czy wynikające z nich zachowanie stanowi naruszenie WCAG bez oceny człowieka, czy ma zastosowanie wyjątek „niezbędności”.
• Blokujące nakładki oparte na CSS: Arkusz stylów może używać @media (orientation: portrait) { .orientation-warning { display: block; } }, aby wyświetlić pełnoekranowy blokujący komunikat w trybie pionowym. Axe-core, skanując stronę w trybie poziomym, nigdy nie napotka tego elementu w stanie widocznym i nie zgłosi problemu. Dopiero testowanie w trybie pionowym — lub inspekcja CSS pod kątem wzorców blokowania zależnych od orientacji — ujawnia naruszenie.

Jak testować

1. Uruchom skan automatyczny jako punkt odniesienia: Otwórz stronę w Chrome, Firefox lub Edge. Użyj rozszerzenia przeglądarki axe DevTools lub uruchom audyt dostępności Lighthouse, aby ustalić punkt wyjścia. Choć narzędzia te nie wykryją bezpośrednio naruszeń związanych z orientacją, mogą wskazać powiązane problemy z projektowaniem responsywnym, meta tagiem viewport lub brakującym ARIA, które potęgują błędy dostępności związane z orientacją. Zwróć uwagę, że czysty raport z automatycznego skanowania nie potwierdza zgodności z 1.3.4.
2. Użyj emulacji urządzeń w narzędziach DevTools przeglądarki: W Chrome lub Edge otwórz DevTools (F12), kliknij ikonę paska narzędzi urządzenia (Ctrl+Shift+M / Cmd+Shift+M) i wybierz urządzenie mobilne, takie jak iPhone 14 lub Galaxy S21. Przełączaj się między orientacją pionową i poziomą, używając ikony obrotu na pasku narzędzi urządzenia. Systematycznie weryfikuj, że cała treść — nawigacja, nagłówki, tekst główny, formularze, przyciski, obrazy i multimedia — pozostaje widoczna i obsługiwalna w obu orientacjach. Szukaj blokujących nakładek, ukrytych sekcji lub wyłączonych elementów interaktywnych, które pojawiają się w jednej orientacji, a w drugiej nie.
3. Testuj na rzeczywistych urządzeniach: Podłącz urządzenie z Androidem lub iOS i otwórz stronę w przeglądarce mobilnej. Fizycznie obracaj urządzenie między orientacją pionową i poziomą. Upewnij się, że blokada orientacji systemu operacyjnego (gdy jest włączona) nie powoduje błędnego działania treści ani wyświetlania monitu o obrót. Testuj zarówno z włączoną, jak i wyłączoną blokadą orientacji.
4. Testowanie z czytnikiem ekranu z symulacją orientacji: W iOS z włączonym VoiceOver (trzykrotne kliknięcie przycisku bocznego) nawiguj po stronie w orientacji pionowej, używając gestów przesuwania. Następnie obróć urządzenie do orientacji poziomej i sprawdź, czy kolejność odczytu VoiceOver i nazwy dostępne pozostają poprawne. W Androidzie z TalkBack wykonaj ten sam test. Użyj NVDA z Firefox na komputerze stacjonarnym i zasymuluj orientację przez DevTools, aby zweryfikować, że drzewo dostępności jest spójne w różnych orientacjach.
5. Sprawdź CSS i JavaScript pod kątem ograniczeń orientacji: W DevTools otwórz panel Sources lub Elements i przeszukaj arkusze stylów pod kątem zapytań medialnych orientation: portrait i orientation: landscape. Przejrzyj, co robi każdy blok: czy ukrywa treść za pomocą display: none, stosuje blokującą nakładkę, czy tylko dostosowuje układ? Przeszukaj pliki JavaScript pod kątem screen.orientation, orientationchange i screen.orientation.lock. Oceń, czy znalezione wzorce blokują interfejs użytkownika lub treść.
6. Zweryfikuj wyjątek „niezbędności”: Jeśli witryna celowo ogranicza orientację, potwierdź, że istnieje udokumentowany, uzasadniony przypadek użycia, w którym orientacja jest niezbędna. Wyjątek musi wynikać z treści, a nie z aspektów kosmetycznych. Udokumentuj swoje ustalenia zrzutem ekranu i konkretnym uzasadnieniem.

Jak naprawić

Blokująca nakładka CSS w trybie pionowym — nieprawidłowe

<!-- Pełnoekranowa nakładka wyświetlana tylko w trybie pionowym, blokująca całą treść -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* blokuje całą treść pod spodem */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- Cała treść aplikacji tutaj -->
</main>

Blokująca nakładka CSS w trybie pionowym — prawidłowe

<!-- Całkowicie usuń blokującą nakładkę. Zamiast tego użyj responsywnego CSS, aby dostosować układ. -->
<style>
  /* Układ pionowy: ułóż elementy pionowo jeden pod drugim */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Układ poziomy: kolumny obok siebie */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Treść dostosowuje układ, ale zawsze pozostaje dostępna -->
  </div>
</main>

Blokada orientacji w JavaScript — nieprawidłowe

<script>
  // Blokuje ekran do trybu poziomego i pokazuje błąd, jeśli się nie powiedzie (np. w iOS)
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- Treść aplikacji -->
</div>

Blokada orientacji w JavaScript — prawidłowe

<script>
  /*
    Nie blokuj orientacji za pomocą JavaScript.
    Zamiast tego nasłuchuj zmian orientacji i dostosowuj interfejs
    bez ukrywania lub wyłączania treści.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Dostosuj klasę układu wyłącznie do stylowania — nigdy nie ukrywaj treści
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- Cała treść pozostaje widoczna i obsługiwalna w obu orientacjach -->
</div>

Meta tag viewport uniemożliwiający zmianę orientacji — nieprawidłowe

<!-- Niektóre starsze implementacje próbowały „naprawić” orientację przez viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  Chociaż 'user-scalable=no' nie blokuje bezpośrednio orientacji,
  połączenie go z transformacjami CSS obracającymi viewport
  jest znanym antywzorcem, który powoduje błędy dostępności związane z orientacją.
-->
<style>
  /* Antywzorzec: obracanie całego body, aby zasymulować tryb poziomy na urządzeniu pionowym */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

Meta tag viewport uniemożliwiający zmianę orientacji — prawidłowe

<!-- Użyj standardowego, responsywnego meta tagu viewport. Nigdy nie obracaj body za pomocą transformacji CSS. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Pozwól przeglądarce i systemowi operacyjnemu naturalnie obsługiwać orientację.
  Projektuj responsywnie, aby treść działała przy wszystkich proporcjach widoku.
  Używaj CSS Grid i Flexbox do przeorganizowania treści, a nie transformacji.
-->

Typowe błędy

• Używanie @media (orientation: portrait) do zastosowania display: none do menu nawigacyjnych, paneli bocznych lub głównych obszarów treści. Każde zapytanie medialne CSS dotyczące orientacji, które usuwa treść z widoku — zamiast po prostu zmieniać jej położenie — jest potencjalnym naruszeniem. Przejrzyj każde zapytanie medialne dotyczące orientacji w arkuszu stylów, aby upewnić się, że zmienia ono tylko układ, a nie dostępność treści.
• Wywoływanie screen.orientation.lock() w aplikacjach, dla których nie jest to niezbędne. Ten interfejs Web API jest przeznaczony dla gier i określonych przypadków użycia multimediów. Używanie go w standardowej aplikacji webowej lub serwisie e-commerce w celu „poprawy estetyki” w trybie poziomym nie kwalifikuje się jako wyjątek „niezbędności” i stanowi bezpośrednie naruszenie WCAG 1.3.4.
• Wyświetlanie ekranu powitalnego „obróć urządzenie” bez dostępnej alternatywy. Nawet jeśli wyświetlana jest krótka podpowiedź dotycząca orientacji, nigdy nie może ona blokować dostępu do treści. Jeśli w ogóle jest pokazywana, musi dać się zamknąć, nie może zasłaniać głównej treści i musi być przekazana jako sugestia, a nie wymóg.
• Założenie, że użytkownicy mobilni zawsze preferują tryb poziomy dla treści wideo. Osadzenie odtwarzacza wideo, który wyłącza elementy sterujące odtwarzaniem lub przycisk odtwarzania w trybie pionowym — zmuszając użytkowników do obrócenia urządzenia, zanim będą mogli wejść w interakcję — narusza 1.3.4, chyba że format wideo rzeczywiście nie może być renderowany w trybie pionowym (co prawie nigdy nie ma miejsca w przypadku standardowego wideo webowego).
• Stosowanie CSS transform: rotate(90deg) do elementu <body> lub kontenera głównego w jednej orientacji. Symuluje to zmianę orientacji w CSS zamiast pozwolić urządzeniu obsłużyć ją naturalnie, co prowadzi do uszkodzonych układów, treści poza ekranem i poważnego zamieszania w drzewie dostępności dla czytników ekranu.
• Brak testowania zachowania orientacji podczas QA, ponieważ zespoły testują tylko w przeglądarkach desktopowych. Symulacja orientacji w DevTools przeglądarki desktopowej nie zawsze jest używana w standardowych cyklach QA. Orientacja powinna być wyraźnym punktem w planach testów mobilnych, weryfikowanym na rzeczywistych urządzeniach z iOS i Androidem.
• Nadpisywanie zachowania orientacji wewnątrz iframe bez uwzględnienia stanu orientacji strony nadrzędnej. Widżety zewnętrzne, osadzone mapy i iframe płatności mogą niezależnie blokować orientację. Nawet jeśli Twoja strona jest zgodna, hostowanie zablokowanego iframe sprawia, że Twoja strona staje się niezgodna, chyba że niezbędny wyjątek dla iframe jest udokumentowany.
• Używanie serwerowego wykrywania user-agenta do serwowania wersji strony „tylko poziomej” użytkownikom mobilnym. Przekierowywanie użytkowników mobilnych do osobnego adresu URL, który działa tylko w trybie poziomym, bez zapewnienia kompatybilnej wersji pionowej, jest systemowym naruszeniem, które dodatkowo powoduje problemy z SEO i kanonizacją adresów URL.
• Stosowanie ograniczeń orientacji tylko w buildach produkcyjnych, co sprawia, że są niewidoczne podczas testów deweloperskich. Flagi funkcji lub frameworki A/B testów czasami aktywują kod blokujący orientację tylko w określonych środowiskach lub dla określonych segmentów użytkowników, przez co naruszenie zostaje pominięte podczas przedpremierowych audytów dostępności.
• Założenie, że wyjątek „niezbędności” ma zastosowanie, ponieważ projektant preferuje układ poziomy. Wyjątek „niezbędności” to wysoki próg prawny i etyczny. Wymaga, aby podstawowa funkcja treści była fundamentalnie niemożliwa w alternatywnej orientacji — a nie tylko, że wygląda lepiej lub że zespołowi zabrakło czasu na wdrożenie responsywnego układu pionowego.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okrężnica Prezydencka nr 2025/10, opublikowana w Dzienniku Urzędowym (Resmî Gazete) nr 32933 w dniu 21 czerwca 2025 r., ustanawia kompleksowe krajowe ramy dla dostępności cyfrowej. Okrężnica nakłada na objęte nią podmioty obowiązek przestrzegania WCAG 2.2 na poziomie AA, który wprost obejmuje WCAG 1.3.4 Orientation. Oznacza to, że każda usługa cyfrowa lub strona internetowa obsługiwana przez podmiot objęty regulacją nie może ograniczać treści do jednej orientacji, co odzwierciedla zamiar Okrężnicy, aby zapewnić wszystkim obywatelom — w tym osobom z niepełnosprawnościami — dostęp do usług cyfrowych niezależnie od tego, w jaki sposób fizycznie korzystają ze swoich urządzeń.

Podmiotami objętymi Okrężnicą i zobowiązanymi do osiągnięcia zgodności na poziomie AA są: instytucje i agencje publiczne (wszystkie organy rządowe prowadzące strony internetowe i usługi cyfrowe), banki i instytucje finansowe, szpitale i świadczeniodawcy opieki zdrowotnej, firmy telekomunikacyjne z 200 000 lub większą liczbą abonentów, platformy e-commerce, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla tych podmiotów ograniczenia orientacji naruszające 1.3.4 — takie jak portale rządowe wymagające dostępu wyłącznie w trybie poziomym lub aplikacje bankowe blokujące się w trybie pionowym z powodów innych niż niezbędne — stanowią bezpośrednią niezgodność z wiążącymi regulacjami krajowymi.

Logo Dostępności (Erişilebilirlik Logosu), wydawane przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı), jest znakiem certyfikacyjnym sygnalizującym zgodność z krajowym standardem dostępności. Osiągnięcie zgodności na poziomie AA jest warunkiem wstępnym uzyskania tego logo. Organizacje ubiegające się o Erişilebilirlik Logosu muszą wykazać, że ich zasoby cyfrowe spełniają wszystkie kryteria poziomu A i AA, w tym 1.3.4. Naruszenie związane z ograniczeniem orientacji — nawet w niewielkiej części witryny — może zagrozić całej certyfikacji.

Ponieważ WCAG 1.3.4 wymaga testów manualnych i nie może zostać potwierdzone wyłącznie przez skany automatyczne, podmioty objęte regulacją powinny włączyć przypadki testowe specyficzne dla orientacji do swoich formalnych procesów audytu dostępności. Dokumentacja wyników testów w orientacji pionowej i poziomej na rzeczywistych urządzeniach powinna być utrzymywana jako część rejestrów zgodności z dostępnością wymaganych na potrzeby zgodności regulacyjnej i certyfikacji logo. SDK Accsible pomaga organizacjom w identyfikowaniu i usuwaniu barier związanych z orientacją w ramach całościowego podejścia do spełniania ewoluujących zobowiązań Turcji w zakresie dostępności cyfrowej.