Zasady WCAG istotne dla osób z niepełnosprawnościami ruchowymi – Prawne zagadnienia dostępności cyfrowej i powiązanych z nimi obszarów prawno-autorskich – kompendium wiedzy w publikacji internetowej

Osoby z niepełnosprawnościami ruchowymi często mają ograniczoną możliwość posługiwania się myszą lub ekranem dotykowym. Aby zapewnić im dostępność, WCAG (Wytyczne dotyczące dostępności treści internetowych) zawiera szereg kryteriów sukcesu na poziomach A, AA i AAA, które ułatwiają obsługę stron za pomocą klawiatury, urządzeń alternatywnych czy asystentów głosowych. Poniżej omówiono najważniejsze z tych kryteriów – przedstawiono cel i istotę każdego z nich oraz przykłady prawidłowych rozwiązań i najczęstszych błędów implementacyjnych.

1.3.4 Orientacja (poziom AA)

Cel i istota: Zapewnienie działania strony w układzie pionowym i poziomym urządzenia. Treść nie powinna wymuszać konkretnej orientacji ekranu (np. tylko poziomej), chyba że jest to niezbędne z uwagi na charakter treści[1]. Ma to duże znaczenie dla osób korzystających z urządzeń zamontowanych na wózkach lub statywach – mogą one nie mieć możliwości obrócenia ekranu. Strona dostępna w obu orientacjach pozwala takim użytkownikom wygodnie korzystać z treści bez konieczności manipulowania urządzeniem[2].
– Przykład poprawny: Strona reaguje na zmianę orientacji – układ elementów dostosowuje się automatycznie. Jeśli tablet jest zamontowany na stałe w pozycji poziomej, użytkownik nadal może odczytać i obsłużyć całą zawartość.
– Przykład błędny: Aplikacja mobilna wymusza tryb pionowy i blokuje wyświetlanie poziome. Użytkownik z urządzeniem przymocowanym na stałe w orientacji poziomej nie może z niej skorzystać, mimo że treści mogłyby być wyświetlone poprawnie również poziomo.

1.1.1 Tekst alternatywny dla elementów interaktywnych (poziom A)

Cel i istota: Zapewnienie tekstowych opisów dla nietekstowych elementów sterujących, takich jak przyciski czy linki prezentowane jako obrazy lub ikony. Choć kryterium 1.1.1 dotyczy głównie dostępności dla osób niewidomych, jest ono równie ważne dla użytkowników korzystających z nawigacji głosowej. Jeśli przycisk jest przedstawiony ikoną bez tekstu alternatywnego, osoba sterująca stroną głosem może nie wiedzieć, jak go wywołać[3]. Tekst alternatywny (atrybut alt lub odpowiedni opis aria-label) pozwala technologiom asystującym – w tym systemom rozpoznawania mowy – zidentyfikować element i umożliwić jego aktywację komendą głosową.
– Przykład poprawny: Ikona „wyszukaj” (lupa) w nagłówku strony ma ukryty tekst alternatywny „Szukaj”, dzięki czemu użytkownik może powiedzieć komendę „kliknij Szukaj” – technologia rozpozna odpowiedni przycisk[4].
– Przykład błędny: Klikalna ikona koszyka zakupów nie ma tekstu alternatywnego ani etykiety – użytkownik wydający polecenia głosowe nie ma możliwości aktywacji tego przycisku, bo asystent głosowy go nie rozpoznaje.

2.1.1 Klawiatura (poziom A)

Cel i istota: Zapewnienie pełnej obsługi wszystkich funkcji strony za pomocą klawiatury[5][6]. Oznacza to, że każda interaktywna kontrolka (link, przycisk, pole formularza, menu itp.) musi być osiągalna i działająca przy użyciu samej klawiatury – np. poprzez klawisz Tab przechodzimy między elementami, Enter aktywuje linki/przyciski, strzałki przewijają listy itp. Jest to kluczowe dla osób, które nie mogą posługiwać się myszą i korzystają wyłącznie z klawiatury lub urządzeń ją emulujących (jak przełączniki sterowane ruchem głowy, przyciski podłączone do wózka, technologie rozpoznawania mowy generujące zdarzenia klawiaturowe itp.)[7].
– Przykład poprawny: Wszystkie elementy strony (w tym menu rozwijane, odtwarzacz wideo, slider) można obsłużyć sekwencją naciśnięć klawiszy – np. Tab pozwala nawigować do przycisku „Odtwórz” na playerze, a Enter go uruchamia. Użytkownik z ograniczeniami ruchowymi może wykonać każdą czynność bez użycia myszy.
– Przykład błędny: Kalendarz do wyboru daty nie pozwala na obsługę klawiaturą – datę można wybrać tylko klikając myszą w miniaturowy kalendarz. Osoba mogąca używać wyłącznie klawiatury (np. z powodu paraliżu rąk) nie jest w stanie samodzielnie skorzystać z funkcjonalności wyboru daty.

2.1.2 Bez pułapki na klawiaturę (poziom A)

Cel i istota: Unikanie sytuacji, w której użytkownik klawiatury „utknie” na danym elemencie strony[8]. Jeśli fokus (aktywny element zaznaczony przez klawiaturę) może wejść do jakiegoś komponentu, musi istnieć możliwość opuszczenia go tylko za pomocą klawiatury. W praktyce oznacza to, że np. wyskakujące okno, elementy nawigacji czy widgety nie mogą przechwycić fokusu na stałe – użytkownik musi mieć możliwość powrotu Escapem, Tabem lub innym klawiszem bez konieczności użycia myszy. Brak „pułapek” na fokus jest kluczowy dla płynnej nawigacji klawiaturą.
– Przykład poprawny: Okno dialogowe na stronie (popup) po otwarciu ustawia fokus na swoim pierwszym elemencie, ale jednocześnie zapewnia przycisk „Zamknij” dostępny z klawiatury. Użytkownik może nacisnąć Esc lub przesunąć fokus na „Zamknij” i go aktywować, by wrócić do głównej treści.
– Przykład błędny: Strona posiada osadzony widżet (np. mapę), do którego można wejść Tabem, lecz nie można już klawiaturą z niego wyjść – fokus krąży wewnątrz widżetu. Użytkownik bez myszy zostaje „uwięziony” i nie może kontynuować przeglądania strony[9].

2.1.3 Klawiatura (bez wyjątków) (poziom AAA)

Cel i istota: Rozszerzenie wymogu 2.1.1 – wszystkie funkcje są dostępne z klawiatury, bez żadnych wyjątków[10]. Na poziomie A dopuszcza się odstępstwa dla funkcji wymagających ciągłego ruchu (np. rysowanie odręczne). Poziom AAA usuwa te wyjątki – nawet zadania zazwyczaj uznawane za „myszo-zależne” powinny mieć równoważną obsługę klawiaturową. To kryterium wyznacza najwyższy standard dostępności dla użytkowników klawiatury.
– Przykład poprawny: Aplikacja rysunkowa online udostępnia narzędzia „narysuj linię” czy „zakreśl obszar” także poprzez klawiaturę (np. strzałkami można przemieszczać kursor rysowania, a spacją zacząć i zakończyć rysowanie linii). Dzięki temu osoba niemogąca użyć myszy potrafi skorzystać z większości funkcji programu.
– Przykład błędny:* Interaktywna mapa pozwala tylko na przeciąganie kursorem** w celu przesunięcia widoku. Nie ma żadnej alternatywy klawiaturowej (np. klawiszy strzałek do przesuwania mapy), przez co użytkownik bez myszy nie może zmienić widoku mapy (wymagana jest czynność zależna od ciągłego ruchu wskaźnika, co narusza to kryterium).

2.1.4 Jednoznakowe skróty klawiaturowe (poziom A)

Cel i istota: Zapobieganie problemom z jednoklawiszowymi skrótami (np. samą literą) dla osób korzystających z rozpoznawania mowy lub alternatywnych klawiatur. Jeśli na stronie zdefiniowano skrót klawiszowy aktywowany pojedynczym znakiem (literą, cyfrą, symbolem) bez wymagania klawiszy modyfikujących, to powinny istnieć mechanizmy wyłączenia lub zmiany tego skrótu[11]. Ma to chronić przed niezamierzonym wywoływaniem akcji – np. użytkownik dyktujący tekst głosem mógłby przypadkowo wypowiedzieć słowo zawierające dany znak i niechcący uruchomić funkcję strony[12].
– Przykład poprawny: Web-aplikacja pocztowa posiada skróty (np. naciśnięcie „r” odpowiada „odpowiedz na e-mail”). Aplikacja udostępnia jednak ustawienia dostępności, gdzie użytkownik może wyłączyć skróty jednoklawiszowe lub zmienić je na kombinacje (np. Ctrl+R). Dzięki temu osoba korzystająca z mowy nie uruchomi przypadkiem funkcji podczas dyktowania treści.
– Przykład błędny: Strona czatu używa pojedynczych liter do akcji (np. „q” – wyloguj). Nie ma możliwości wyłączenia tych skrótów. Osoba używająca asystenta głosowego, wypowiadając zdanie z literą „q”, nieświadomie powoduje wylogowanie – to frustrujący błąd dostępności.

2.2.1 Dostosowanie czasu (poziom A)

Cel i istota: Zapewnienie, że użytkownicy mają wystarczająco dużo czasu na wykonanie czynności na stronie[13]. Osoby z niepełnosprawnością ruchową mogą potrzebować więcej czasu na nawigację klawiaturą, wypełnienie formularza czy podjęcie decyzji[14]. Kryterium to wymaga, aby wszelkie limity czasu (timeouty, odliczania) były: wyłączalne, przedłużalne lub dostosowywalne przez użytkownika (ew. muszą spełniać określone warunki wyjątków)[15][16]. Dzięki temu nikt nie zostanie wylogowany czy nie utraci wprowadzonych danych tylko dlatego, że fizycznie potrzebował więcej czasu na akcję.
– Przykład poprawny: Formularz zamówienia ma 5-minutowy limit bezczynności, ale przed upływem czasu pojawia się komunikat z pytaniem, czy przedłużyć sesję. Użytkownik może jednym klawiszem (np. Spacja) otrzymać dodatkowe 5 minut[17]. Osoba z ograniczeniami ruchowymi zdąży spokojnie zakończyć składanie zamówienia.
– Przykład błędny: Strona banku automatycznie wylogowuje po 60 sekundach braku aktywności bez ostrzeżenia. Użytkownik o powolniejszej motoryce nie zdąży przepisać kodu z tokena w tak krótkim czasie i jest stale wylogowywany, co uniemożliwia mu wykonanie operacji.

2.2.2 Pauza, zatrzymanie, ukrycie (poziom A)

Cel i istota: Umożliwienie zatrzymania lub ukrycia animowanych treści poruszających się automatycznie[18]. Osoba z niepełnosprawnością ruchową może mieć trudność w koncentracji lub interakcji, jeśli na stronie coś ciągle migocze lub przesuwa się, zwłaszcza gdy nie może szybko tego zatrzymać. Kryterium wymaga, by dla wszelkich animacji trwających dłużej niż 5 sekund (np. automatyczne przewijanie karuzeli zdjęć, banery reklamowe) była dostępna kontrola “Pauza/Stop”, chyba że animacja jest niezbędna[18]. Dzięki temu użytkownik może wstrzymać ruchomy element, skupić się na właściwej treści lub interakcji we własnym tempie.
– Przykład poprawny: Na stronie głównej automatycznie przewija się slider z ofertami. Jednak gdy użytkownik najedzie na slider fokusem klawiatury, przewijanie się zatrzymuje, a dodatkowo dostępny jest przycisk „▶︎⏸ Zatrzymaj animację”. Osoba mająca problem z nadążeniem za szybko zmieniającymi się slajdami może je zatrzymać i spokojnie przeczytać zawartość[19].
– Przykład błędny: W tle strony miga animowana grafika (np. spadające konfetti) i brak możliwości jej wyłączenia. Użytkownik, którego ruchy są powolne lub ograniczone, może mieć trudność z kliknięciem małych przycisków przy rozpraszającej animacji, co znacznie utrudnia korzystanie ze strony.

2.2.3 Bez ograniczeń czasowych (poziom AAA)

Cel i istota: Wyeliminowanie wszelkich niekoniecznych ograniczeń czasowych. Kryterium AAA „Bez ograniczeń czasowych” zakłada, że żadna czynność na stronie (poza nielicznymi wyjątkami) nie jest objęta sztywnym limitem czasu[20]. Jest to najwyższy standard – zapewnia pełną swobodę tempa działania użytkownika. Dla osób z poważnymi ograniczeniami ruchu (np. używających urządzeń sterowanych za pomocą mrugnięć lub ruchów głowy) absolutny brak presji czasu jest idealnym warunkiem korzystania z treści.
– Przykład poprawny: Gra edukacyjna online na poziomie AAA nie ma żadnych timerów – użytkownik może rozwiązywać quiz lub łamigłówkę tak długo, jak potrzebuje. Nie pojawi się komunikat o upłynięciu czasu, niezależnie od tego, czy zajmie to 5 minut czy 5 godzin.
– Przykład błędny: (Brak – spełnienie tego kryterium polega właśnie na usunięciu wszystkich standardowych ograniczeń czasu. Każde interaktywne zadanie z narzuconym czasem – o ile nie jest to np. transmisja na żywo czy aukcja – powoduje niespełnienie kryterium AAA.)

2.2.4 Przerywanie (poziom AAA)

Cel i istota: Pozwalać użytkownikowi wstrzymać lub wyciszyć wszelkie przerwania (np. wyskakujące powiadomienia), chyba że dotyczą one sytuacji awaryjnych[21]. Dla osób z ograniczoną sprawnością ruchową niespodziewane wyskakujące okienko czy alert może być kłopotliwy – jego zamknięcie wymaga szybkiej reakcji, precyzji lub przemieszczenia fokusu. Kryterium na poziomie AAA wymaga, by użytkownik mógł kontrolować takie przerwania, odkładając je na później. Na przykład powiadomienia czatu lub komunikaty mogą być kolejkowane, dopóki użytkownik sam nie zechce się nimi zająć.
– Przykład poprawny: Aplikacja webmail przychodzące wiadomości wyświetla dyskretnie na pasku, bez automatycznego wyskakiwania okienek. Użytkownik może zdecydować, kiedy przeczytać nowe e-maile. W ustawieniach dostępna jest także opcja „Nie przeszkadzać”, która wstrzymuje wszelkie powiadomienia do momentu wyłączenia trybu.
– Przykład błędny: Podczas wypełniania długiego formularza rejestracji na stronie pojawia się automatycznie okienko czatu z konsultantem po kilku minutach bezczynności. Przechwytuje ono fokus i odciąga uwagę. Użytkownik z niepełnosprawnością ruchową, który być może robił przerwę lub wolno pisze, zostaje nieoczekiwanie wyrwany z kontekstu i musi dodatkowo zamknąć okno czatu, co utrudnia dokończenie głównego zadania.

2.2.5 Ponowne potwierdzenie autentyczności (poziom AAA)

Cel i istota: Po wygaśnięciu sesji zalogowanego użytkownika (timeoutu) zapewnić, że można kontynuować pracę bez utraty wprowadzonych danych[22]. To kryterium chroni użytkowników, którzy wskutek wolniejszego działania nie zdążyli np. wysłać formularza przed automatycznym wylogowaniem. Jeśli spełnione, po zalogowaniu ponownie (re-auth) użytkownik powraca do stanu sprzed wygaśnięcia sesji i dane które wprowadził nie znikają. Ma to duże znaczenie dla osób z ograniczeniami ruchowymi, aby nie musiały powtarzać mozolnie wpisywanych informacji.
– Przykład poprawny: Użytkownik wypełnia podanie online. Sesja wygasa z powodu długiej przerwy, ale po ponownym zalogowaniu formularz nadal zawiera wszystkie wcześniej wpisane dane, pozwalając kontynuować od momentu przerwania.
– Przykład błędny: Strona sklepu internetowego wylogowała użytkownika podczas wypełniania adresu dostawy. Po zalogowaniu ponownie, koszyk jest pusty, a wszystkie dane dostawy zniknęły – użytkownik musi zaczynać od początku. Taka sytuacja szczególnie mocno dotyka osoby, którym wpisanie tych danych zajęło dużo czasu i wysiłku.

2.2.6 Ostrzeżenie o limicie czasu (poziom AAA)

Cel i istota: Informowanie użytkownika o długości bezczynności po której nastąpi utrata danych lub wylogowanie[23]. Jeśli strona ma automatyczny limit czasu (np. po 10 min niewypełniania formularza nastąpi reset), to na poziomie AAA użytkownik musi być wcześniej wyraźnie ostrzeżony o tym limicie. Dla osób z niepełnosprawnościami ruchowymi jest to cenna informacja – mogą zaplanować swoje działania tak, by nie przekroczyć limitu, lub podjąć środki (np. zapisać częściowo dane).
– Przykład poprawny: Na początku długiego formularza zamieszczono komunikat: „Ze względów bezpieczeństwa sesja wygaśnie po 15 minutach bezczynności. Po tym czasie niezapisane dane mogą zostać utracone.” Użytkownik już na starcie wie, z jakim limitem musi się liczyć i może np. przygotować potrzebne informacje wcześniej, by zmieścić się w czasie, albo skopiować wpisane odpowiedzi na bieżąco.
– Przykład błędny: Strona ankiety nie informuje, że po 5 minutach nastąpi automatyczne odświeżenie. Użytkownik działający powoli po 5 minutach traci cały postęp i dopiero wtedy widzi komunikat o wygaśnięciu sesji – zabrakło wcześniejszego ostrzeżenia, które umożliwiłoby mu zapobieżenie tej sytuacji.

2.4.1 Możliwość pominięcia bloków (poziom A)

Cel i istota: Ułatwienie nawigacji klawiaturą poprzez umożliwienie pomijania powtarzalnych fragmentów strony[24]. Najczęściej chodzi o link „Przejdź do treści” (skip link) lub inne mechanizmy pozwalające ominąć np. rozbudowane menu czy nagłówek witryny. Osoba korzystająca tylko z klawiatury nie musi wtedy żmudnie tabulować przez kilkadziesiąt linków menu za każdym razem, gdy przechodzi na kolejną podstronę. To kryterium istotnie przyspiesza i ułatwia obsługę dla użytkowników z ograniczeniami ruchu, oszczędzając im wielu zbędnych operacji klawiszowych[25].
– Przykład poprawny: Zaraz po otwarciu strony (fokus na elemencie <body>) jest dostępny ukryty link „Pomiń nawigację – przejdź do głównej treści” pojawiający się po naciśnięciu Tab. Aktywacja tego linku przeskakuje fokus bezpośrednio do sekcji z właściwą treścią strony, pomijając menu i inne powtarzalne elementy nagłówka.
– Przykład błędny: Strona nie oferuje żadnej możliwości pominięcia headera. Użytkownik klawiatury na każdej podstronie musi przechodzić przez te same rozbudowane menu kategorii, listy popularnych tagów itp., zanim dotrze do unikalnej treści strony. Jest to dla niego męczące i czasochłonne.

2.4.3 Kolejność fokusu (poziom A)

Cel i istota: Zapewnienie logicznej i przewidywalnej kolejności przenoszenia fokusu podczas nawigacji klawiaturą[26]. Oznacza to, że elementy interaktywne powinny otrzymywać fokus w takiej kolejności, która odpowiada naturalnemu czytaniu lub logicznemu porządkowi interfejsu. Dzięki temu użytkownik klawiatury przemieszcza się krok po kroku w sensowny sposób – np. formularz fokusuje pola od pierwszego do ostatniego, a nie losowo. Dla osób z niepełnosprawnością ruchową to kwestia zarówno wygody, jak i skuteczności: nie muszą wykonywać zbędnych skoków ani zastanawiać się, gdzie fokus „uciekł”.
– Przykład poprawny: Na stronie formularza rejestracji, naciskając Tab, fokus przechodzi kolejno przez: pole „Imię”, „Nazwisko”, „Email”, „Hasło”, przycisk „Wyślij”. Taka kolejność zachowuje poprawne znaczenie i logikę (od danych osobowych do zatwierdzenia)[26]. Użytkownik nie będzie zdezorientowany.
– Przykład błędny: Fokus na stronie przeskakuje w nieintuicyjny sposób – np. po menu głównym przechodzi od razu do stopki, pomijając ważne linki po drodze, albo w formularzu adresowym po polu „Ulica” nagle trafia na pole „Kod pocztowy”, pomijając pole „Miasto”. Taka nielogiczna kolejność zmusza użytkownika klawiaturowego do dodatkowych manewrów i może uniemożliwić poprawne wypełnienie formularza.

2.4.7 Widoczny fokus (poziom AA)

Cel i istota: Wyraźna wizualna wskazówka, który element interfejsu aktualnie ma fokus klawiatury[27]. Gdy użytkownik nawiguje Tabem czy strzałkami, powinien zawsze widzieć, gdzie znajduje się aktywny fokus – np. poprzez obramowanie, podświetlenie lub inny kontrastowy wskaźnik. Dla osób korzystających z klawiatury jest to absolutnie kluczowe: „zgubienie” fokusu uniemożliwia dalszą interakcję[28]. Dlatego WCAG wymaga, by tryb nawigacji klawiaturą zapewniał dobrze widoczny fokus na wszystkich elementach sterujących.
– Przykład poprawny: Witryna posiada dostosowany styl fokusu – np. aktywny link lub przycisk otrzymuje grubą żółtą ramkę albo niebieskie podświetlenie tła, wyraźnie odcinające się od tła. Dzięki temu użytkownik zawsze łatwo lokalizuje aktualny element i wie, który przycisk zostanie aktywowany po naciśnięciu Enter[27].
– Przykład błędny: Po najechaniu Tabem na interaktywne kafelki galerii fokus jest praktycznie niewidoczny – np. różnica to jedynie delikatna krawędź w kolorze zbliżonym do tła. Osoba nawigująca klawiaturą nie może dostrzec, który kafelek jest aktualnie wybrany, co prowadzi do dezorientacji i błędów w obsłudze strony.

2.4.11 Fokus niezakryty (minimum) (poziom AA)

Cel i istota: Upewnienie się, że fokus klawiatury nie zostaje schowany za innymi elementami na ekranie[29]. Gdy element otrzymuje fokus, powinien być w pełni widoczny dla użytkownika – niezasłonięty np. przez stały nagłówek, popup czy przyklejony pasek. To kryterium zapobiega sytuacji, gdzie użytkownik klawiatury widzi wskaźnik fokusu, ale nie widzi samego elementu, bo np. fokus przeszedł na przycisk pod zasłaniającym go menu. Dotyczy to głównie projektów z elementami nakładającymi się na treść. Spełnienie kryterium poprawia wygodę nawigacji klawiaturą dla wszystkich, w tym osób z ograniczeniami ruchu – nie muszą oni dodatkowo przewijać strony czy zamykać nagłówka, by odsłonić aktywny element[30].
– Przykład poprawny: Strona ma stały pasek menu na górze, ale zastosowano mechanizm, że gdy fokus przechodzi do fragmentu treści pod paskiem, pasek automatycznie się chowa lub zmniejsza, aby odsłonić fokusowany element. Użytkownik zawsze widzi zaznaczony link lub przycisk, nawet jeśli znajduje się on tuż pod obszarem pierwotnie zakrytym przez nagłówek.
– Przykład błędny: Na stronie jest „przyklejony” czat-bot w rogu, który nachodzi na część listy elementów. Gdy fokus klawiatury dojdzie do elementów za tym okienkiem, użytkownik już ich nie widzi, bo okienko czatu je zasłania. Strona nie oferuje sposobu automatycznego przesunięcia ani zamknięcia zasłaniającego elementu, przez co realnie fokus jest ukryty przed wzrokiem użytkownika.

2.4.12 Fokus niezakryty (ulepszony) (poziom AAA)

Cel i istota: Wersja rozszerzona powyższego kryterium – na poziomie AAA żadna część elementu z fokusem nie może być zakryta przez inne treści[31]. O ile poziom AA dopuszczał, że część elementu może być niewidoczna, byle nie cały element, o tyle „ulepszony” fokus wymaga pełnej widoczności. Ta zasada zapewnia maksymalną czytelność interfejsu dla użytkowników klawiatury, choć jej spełnienie bywa trudne w niektórych dynamicznych układach stron.
– Przykład poprawny: W trybie AAA strona z rozbudowanym interfejsem zarządza widocznością tak, że aktywny element zawsze wysuwa się na wierzch lub inne elementy się odsuwają, by nic go nie zasłaniało. Np. rozwinięte submenu automatycznie przewija się w dół, gdy fokus schodzi do treści poniżej, tak aby fokusoany link nie był przykryty przez menu.
– Przykład błędny: Galeria lightbox spełniająca AA (miniaturka z fokusem nie jest całkiem zakryta) nie spełnia AAA, bo część zaznaczonej miniatury wciąż znika pod paskiem przewijania. Aby spełnić AAA, projekt musiałby przewidzieć dodatkowe odstępy lub inny układ – brak takich rozwiązań oznacza niespełnienie poziomu ulepszonego.

2.5.1 Gesty dotykowe (poziom A)

Cel i istota: Zapewnienie alternatywy dla złożonych gestów dotykowych (multipunktowych lub ścieżkowych) – tak, by każdą funkcję dało się obsłużyć pojedynczym wskazaniem punktowym (kliknięciem/tapnięciem) bez potrzeby wykonywania skomplikowanych ruchów[32]. Osoby z ograniczeniami ruchowymi mogą mieć trudność z gestami typu „uszczypnięcie dwoma palcami”, „przeciągnij po krzywej” czy wielokrotne machnięcia – często ich urządzenia asystujące generują jedynie proste kliknięcia. Dlatego interfejs powinien oferować inne metody aktywacji – np. zamiast przeciągania obiektów – przyciski „przenieś w lewo/prawo”, zamiast rozsuwania dwoma palcami – przycisk zoom +/-. Jeśli złożony gest jest niezbędny, to kryterium dopuszcza wyjątek, ale to rzadkie przypadki (np. gra rysunkowa).
– Przykład poprawny: Suwak cen na stronie (zakres od-do) umożliwia zmianę wartości także kliknięciem w plus/minus obok suwaka, a nie tylko poprzez przeciągnięcie kółka wskaźnika. Osoba niemogąca wykonać precyzyjnego drag-and-drop może klikać w przyciski, osiągając ten sam efekt.
– Przykład błędny: Aplikacja mapowa umożliwia zmianę orientacji widoku wyłącznie za pomocą gestu rotacji dwoma palcami. Nie ma przycisku do obrotu ani opcji wpisania kąta. Użytkownik korzystający z urządzenia śledzącego ruch oczu (generującego pojedyncze tapnięcia) nie jest w stanie wykonać takiego gestu – aplikacja nie spełnia wymogu dostępności.

2.5.2 Rezygnacja ze wskazania (poziom A)

Cel i istota: Zmniejszenie ryzyka przypadkowego uruchomienia funkcji przy dotykowym/pointerowym sterowaniu poprzez odpowiednie reagowanie na zdarzenia. To kryterium zaleca, by kliknięcia/aktywacje nie działy się w momencie dotknięcia (down-event), ale dopiero na podniesienie palca/klawisza (up-event), oraz by istniała opcja anulowania akcji po jej rozpoczęciu[33][34]. Dzięki temu osoba z drżeniem rąk lub trudnością w precyzyjnym trafieniu ma szansę cofnąć gest jeśli zorientuje się, że dotknęła nie tego elementu co trzeba. Wymóg ten zapobiega np. sytuacji, że lekkie muśnięcie ekranu od razu usuwa coś nieodwracalnie.
– Przykład poprawny: Strona z listą e-maili pozwala usunąć wiadomość przyciskiem „Usuń”. Jednak mechanizm jest tak zrobiony, że naciśnięcie (touchstart/mousedown) nie usuwa od razu – dopiero puszczenie (touchend/mouseup) wykonuje akcję. Jeśli użytkownik zacznie naciskać przycisk, a potem przesunie palec poza niego zanim puści, akcja zostanie anulowana (tzw. slip guard). Ponadto system oferuje Cofnij po skasowaniu, więc nawet gdy dojdzie do omyłki, łatwo ją naprawić[33][35].
– Przykład błędny: Aplikacja mobilna kasuje element listy natychmiast w momencie rozpoczęcia gestu „przesuń w lewo” – już w momencie dotknięcia i ruchu palcem item zostaje usunięty na stałe. Osoba z niesprawną motoryką może niechcący rozpocząć taki gest i nie ma sposobu go odwrócić. Wymagana byłaby zmiana, by usunięcie następowało dopiero po pełnym wykonaniu gestu i ewentualnym potwierdzeniu.

2.5.3 Etykieta w nazwie (poziom A)

Cel i istota: Dbanie o to, by tekst widoczny na etykiecie elementu interfejsu pokrywał się z jego nazwą dostępną w kodzie[36]. W praktyce – jeśli przycisk ma na ekranie napis „Wyślij formularz”, to jego dostępna nazwa (np. atrybut aria-label lub tekst przycisku) powinna również zawierać „Wyślij formularz”. To istotne dla użytkowników korzystających z technologii sterowanych głosem – zazwyczaj wydają oni komendy typu „kliknij {nazwa przycisku}”. Jeśli programowo nazwa przycisku różni się od tej wizualnej, może dojść do niepowodzenia rozpoznania polecenia[4]. Dotyczy to także czytników ekranu, ale w kontekście ruchowym głos jest częstym zamiennikiem rąk.
– Przykład poprawny: Ikona przy koszyku ma widoczny opis „Dodaj do koszyka” i dokładnie taki sam tekst znajduje się w kodzie jako nazwa przycisku (np. <button aria-label=”Dodaj do koszyka”>…). Użytkownik może powiedzieć „Dodaj do koszyka” i asystent głosowy naciśnie właściwy przycisk[4].
– Przykład błędny: Przycisk z ikoną plusa ma tooltip „Dodaj do koszyka”, ale w kodzie aria-label brzmi „Dodaj”. Osoba korzystająca z komend głosowych widzi tekst „Dodaj do koszyka”, wydaje polecenie „kliknij Dodaj do koszyka” – jednak asystent nie znajduje takiej nazwy (przycisk nazywa się inaczej). Polecenie kończy się fiaskiem przez niespójność etykiety wizualnej z programistyczną.

2.5.4 Aktywowanie ruchem (poziom A)

Cel i istota: Zapewnienie alternatyw dla funkcji sterowanych poruszeniem urządzenia (np. potrząśnięciem telefonu, przechyleniem) oraz możliwość wyłączenia takiego sterowania[37][38]. Dla wielu osób z niepełnosprawnościami ruchowymi fizyczne poruszenie urządzeniem może być niewykonalne lub przypadkowe (np. ktoś może mieć telefon zamocowany na stałe do wózka). Kryterium wymaga, by wszystkie akcje dostępne poprzez gesty ruchowe były również dostępne przez tradycyjny interfejs (np. przyciskiem), a także by użytkownik mógł wyłączyć reagowanie strony na ruch. Chroni to przed niechcianymi akcjami wywołanymi np. drżeniem ręki czy przypadkowym pochyleniem urządzenia.
– Przykład poprawny: Aplikacja ma funkcję „potrząśnij, aby odświeżyć”, ale realizuje również tę samą operację przyciskiem „Odśwież” na ekranie[39][40]. Dodatkowo w ustawieniach jest opcja wyłączenia rozpoznawania ruchu urządzenia. Dzięki temu użytkownik z ograniczoną mobilnością może po prostu nacisnąć przycisk, a jeśli jego ręce mimowolnie poruszają urządzeniem – nie spowoduje to niechcianych efektów.
– Przykład błędny:* Gra mobilna wymaga sterowania balansem poprzez pochylanie urządzenia (np. labirynt z kulką). Nie oferuje joysticka ekranowego ani klawiszy jako alternatywy. Użytkownik z urządzeniem zamocowanym na sztywno lub niemogący wykonywać takich ruchów nie ma możliwości grania, bo twórcy nie przewidzieli innego sposobu aktywacji funkcji.

2.5.5 Rozmiar celu (ulepszone) (poziom AAA)

Cel i istota: Zapewnienie wystarczająco dużych obszarów kliknięcia dla interaktywnych elementów, tak by osoby o ograniczonej precyzji ruchów mogły w nie trafić. Poziom AAA „ulepszony” wymaga minimalnego rozmiaru celu 44×44 CSS px (ok. 1cm na ekranie)[40], z pewnymi wyjątkami. Duże cele zapobiegają chybionym kliknięciom i ułatwiają korzystanie z interfejsu osobom z drżeniem rąk, ograniczoną motoryką czy korzystającym z urządzeń typu head-pointer. Choć AAA nie jest obowiązkowe, stanowi wzorzec projektowy: większe przyciski i linki poprawiają wygodę wszystkich użytkowników[41].
– Przykład poprawny: Na stronie mobilnej przyciski mają wysokość co najmniej 48px, a odstępy między klikalnymi ikonami gwarantują, że każdy cel dotykowy ma zalecaną wielkość. Np. małe checkboxy w formularzu są powiązane z etykietami tekstowymi – kliknięcie w tekst również zaznacza checkbox (powiększa to efektywny obszar celu)[42]. Osoba o niedokładnych ruchach łatwo trafi w taki duży cel bez chybiania.
– Przykład błędny: Linki w wersji mobilnej strony są ułożone bardzo gęsto, np. lista odnośników w stopce ma czcionkę 10px i minimalne odstępy. Kliknięcie palcem (albo głowicą wskazującą) jednego linku często skutkuje trafieniem w sąsiedni. Użytkownik z niepełną sprawnością dłoni będzie miał ogromne trudności w wybraniu właściwej opcji – interfejs nie spełnia standardu dużych celów.

2.5.8 Rozmiar celu (minimalny) (poziom AA)

Cel i istota: Wersja poziomu AA dotycząca rozmiaru celów – wymaga minimalnie 24×24 CSS px powierzchni aktywnej dla elementu, bądź zachowania odpowiednich odstępów jeśli element jest mniejszy[43]. To nowsze kryterium (WCAG 2.2) mające na celu ułatwienie obsługi dotykowej dla osób o ograniczonej precyzji. Jeżeli przyciski lub linki są mniejsze, powinny być rozstawione tak, by wyobrażalne kółko o średnicy 24px wokół każdego z nich nie nachodziło na inne cele[44]. Dzięki temu nawet jeśli cel nie jest duży, wolna przestrzeń wokół zapobiega oddaniu przypadkowego kliknięcia w sąsiedni element[45][46].
– Przykład poprawny: Rzędy ikon akcji w serwisie zostały przeprojektowane – choć same ikony mają ~20px, to każda otoczona jest dodatkowym marginesem (obszar klikalny to ~28px). Ponadto, między sąsiednimi ikonami jest przerwa, więc nawet użytkownik dotykając niezbyt dokładnie – nie naciśnie dwóch naraz ani nie pomyli elementów.
– Przykład błędny: Strona ma wiele drobnych linków w chmurze tagów, ułożonych blisko siebie bez odstępów. Użytkownik o większych palcach lub ograniczonej kontroli motorycznej niemal na pewno dotknie kilka na raz. Brak spełnienia wymogu minimalnego rozmiaru/spacji sprawia, że taka chmura jest praktycznie nieużywalna dla osób z niepełnosprawnością ruchową.

2.5.6 Równoległy mechanizm wprowadzania danych (poziom AAA)

Cel i istota: Niedyskryminowanie różnych sposobów sterowania – treść nie powinna ograniczać użytkownika do jednej metody wprowadzania (np. tylko dotyk)[47]. Osoby z niepełnosprawnościami ruchowymi często korzystają z niestandardowych interfejsów (klawiatury, przełączniki, sterowanie głosem). To kryterium zabrania autorom stron blokowania lub wyłączania pewnych metod (chyba że jest to niezbędne dla bezpieczeństwa lub funkcji). Na przykład, jeśli urządzenie obsługuje zarówno mysz, jak i dotyk – strona nie powinna działać tylko z dotykiem, ignorując klawiaturę. Dzięki temu użytkownik może równocześnie lub zamiennie używać różnych dostępnych mu narzędzi do obsługi interfejsu.
– Przykład poprawny: Aplikacja web działa zarówno z myszą, jak i klawiaturą, a na tablecie – zarówno dotykowo, jak i z podłączoną klawiaturą Bluetooth. Jeśli użytkownik podłączy alternatywne urządzenie wejścia (np. trackball lub sterowanie głosowe generujące zdarzenia klawiaturowe), aplikacja nadal w pełni reaguje na te sposoby inputu.
– Przykład błędny: Strona mobilna wykrywa urządzenie dotykowe i celowo wyłącza możliwość nawigacji klawiaturą (ignoruje focusable elementy). W efekcie osoba, która np. do tabletu podłączyła specjalną klawiaturę z dużymi klawiszami (bo nie może precyzyjnie dotykać ekranu), nie jest w stanie nic zrobić – choć technicznie urządzenie przekazuje sygnały klawiaturowe, strona je ignoruje. To poważna bariera sprzeczna z ideą równoległych mechanizmów wprowadzania.

2.5.7 Ruch przeciągania (poziom AA)

Cel i istota: Zapewnienie alternatywy dla interakcji wymagających przeciągania elementów (drag and drop) – tak, aby można je było wykonać przy pomocy pojedynczych kliknięć[48]. Dla wielu użytkowników z niepełnosprawnością ruchową długie przeciąganie kursorem jest trudne. Kryterium WCAG 2.2 w poziomie AA nakazuje, by jeśli jakaś funkcja opiera się na przeciąganiu, była również dostępna inaczej. Np. elementy listy da się przesunąć strzałkami i zatwierdzić pozycję; plik można załączyć poprzez przycisk „Wybierz plik” obok zamiast przeciągania do okienka; suwak wartości można regulować klikając w pasku postępu, a nie tylko ciągnąc uchwyt. Eliminacja konieczności ciągłego nacisku i ruchu znacznie ułatwia obsługę stron osobom o ograniczonej sile i precyzji[49][50].
– Przykład poprawny: Na stronie listy zadań każdy element ma oprócz „uchwytu” do przeciągania także przyciski „Przenieś w górę / w dół”, które pozwalają zmienić kolejność za pomocą pojedynczych kliknięć. Użytkownik niemogący wykonywać drag-and-drop ustawia kolejność listy, klikając te przyciski – osiąga to samo, bez potrzeby ciągłego przytrzymywania i przeciągania elementów.
– Przykład błędny: Interfejs kanban do zarządzania zadaniami pozwala przenosić kartki wyłącznie metodą drag and drop. Brak opcji typu „Przenieś do kolumny X” w menu kontekstowym czy listy pozycji. Osoba posługująca się wyłącznie klawiaturą albo mająca problem z utrzymaniem wciśniętego przycisku myszy nie zdoła przenieść żadnej kartki, co praktycznie uniemożliwia jej korzystanie z aplikacji – nie spełnia ona kryterium dostępności.

3.3.2 Etykiety lub instrukcje (poziom A)

Cel i istota: Zapewnienie jasnych etykiet i wskazówek przy polach formularzy i elementach interaktywnych[51]. Dla użytkowników z ograniczeniami ruchowymi istotne jest, by proces wypełniania formularzy był prosty i nie wymagał zbędnych poprawek – każda poprawka to dodatkowy wysiłek. Dlatego WCAG wymaga, aby każde pole było opisane etykietą (label) lub instrukcją, co i w jakim formacie należy wpisać. Użytkownik nie musi domyślać się, minimalizuje to liczbę błędów. Jak podkreślają wytyczne, wyraźne oznaczenie wymaganych pól, formatów danych oraz dołączanie instrukcji ułatwia i przyspiesza korzystanie z formularzy[52].
– Przykład poprawny: Formularz rejestracyjny posiada nad polami jasne etykiety (np. „Adres e-mail:” obok pola tekstowego) oraz dodatkowe podpowiedzi tam, gdzie to potrzebne (np. „hasło min. 8 znaków, w tym jedna cyfra”). Pola obowiązkowe są oznaczone gwiazdką i legendą „ – pole wymagane” na górze formularza. Osoba wprowadzająca dane dokładnie wie, co gdzie wpisać i nie musi poprawiać błędów.
– Przykład błędny:* Formularz kontaktowy ma puste pola bez etykiet (placeholdery znikają po rozpoczęciu pisania). Nie ma informacji, które pola są wymagane – użytkownik dowiaduje się dopiero po próbie wysłania, że „pole X jest wymagane” lub „nieprawidłowy format”. Taki projekt zmusza do poprawek i dodatkowych działań, co przy powolnym wprowadzaniu danych znacząco obciąża użytkownika.

3.3.3 Sugestie korekty błędów (poziom AA)

Cel i istota: Gdy użytkownik popełni błąd wprowadzania danych, strona powinna nie tylko go poinformować, ale również zasugerować jak błąd poprawić (o ile jest to możliwe)[53]. Dla osób z niepełnosprawnością ruchową, które często wkładają dużo wysiłku w wpisanie informacji, przyjazne sugestie oszczędzają dodatkowej pracy. Przykładowo, jeśli w polu email brakuje „@”, komunikat mógłby brzmieć: „Proszę dodać znak @ w adresie email”. Użytkownik nie musi się zastanawiać nad przyczyną błędu i tracić czasu na szukanie rozwiązania – dostaje wskazówkę od razu, co przyspiesza poprawienie pomyłki.
– Przykład poprawny: Po wysłaniu formularza system sprawdza dane i przy polu „Kod pocztowy” wyświetla komunikat: „Podany kod ma za mało cyfr. Polski kod pocztowy ma format 00-000 (5 cyfr).” Taka sugestia jasno wskazuje, w czym rzecz i jak prawidłowo wprowadzić kod. Użytkownik może szybko nanieść poprawkę bez zgadywania poprawnego formatu.
– Przykład błędny: Formularz rejestracji zwraca po wysłaniu jedynie lakoniczny błąd „Nie udało się zarejestrować, sprawdź dane.” Nie wiadomo, które pole zawiera błąd ani co jest nie tak. Użytkownik z trudem ponownie przegląda wszystkie pola, próbując odgadnąć, co poprawić – dodatkowy, niepotrzebny wysiłek, który mogłyby zaoszczędzić konkretne podpowiedzi.

3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych) (poziom AA)

Cel i istota: Redukowanie ryzyka poważnych pomyłek użytkownika poprzez wymaganie potwierdzenia lub możliwości anulacji przy krytycznych akcjach[54]. To kryterium dotyczy operacji wiążących się z prawem, transakcjami finansowymi lub modyfikacją danych użytkownika – czyli tam, gdzie błąd może mieć dotkliwe skutki. Dla osób z niepełnosprawnością ruchową jest to szczególnie ważne – przypadkowe kliknięcie „usuń konto” czy literówka w polu kwoty przelewu mogą się zdarzyć przy niesprawnych rękach. Mechanizmy zgodne z tym kryterium (np. okno „Czy na pewno chcesz usunąć?”, opcja przejrzenia i zatwierdzenia danych przed wysłaniem, przyciski Anuluj obok Zapisz) działają jako siatka bezpieczeństwa, pozwalając wyłapać i skorygować pomyłkę zanim stanie się problemem.
– Przykład poprawny: W sklepie internetowym po wprowadzeniu danych do przelewu wyświetla się strona podsumowania z pełnym zestawieniem zamówienia, adresu dostawy i kwoty, z prośbą o potwierdzenie. Użytkownik może na spokojnie sprawdzić, czy wszystko jest poprawne, zanim finalizuje transakcję. Dodatkowo, klikając „Złóż zamówienie”, jeszcze raz proszony jest o potwierdzenie decyzji.
– Przykład błędny: Panel klienta banku pozwala wykonać przelew natychmiast po wpisaniu danych i naciśnięciu Enter, bez żadnego podsumowania i potwierdzenia. Użytkownik z drżącą ręką mógł wpisać złą kwotę (np. jedną cyfrę więcej) i jednym naciśnięciem zatwierdzi transakcję, której nie da się cofnąć. Brak mechanizmu weryfikacji skutkuje potencjalnie poważnym błędem trudnym do naprawienia.

3.3.6 Zapobieganie błędom (wszystkim) (poziom AAA)

Cel i istota: Rozciągnięcie zasad zapobiegania błędom na wszelkie formularze i operacje (nie tylko te krytyczne z 3.3.4). Na poziomie AAA oczekuje się, że każda istotna akcja użytkownika, która zmienia lub wysyła dane, będzie odwracalna, sprawdzona lub potwierdzona[54]. Dla użytkowników z niepełnosprawnościami ruchowymi oznacza to maksymalne zabezpieczenie przed utratą danych czy skutkami pomyłek. W praktyce: tam gdzie to możliwe – oferuj opcję cofnięcia (Undo), weryfikuj wprowadzane informacje przed ostatecznym zapisem oraz proś o potwierdzenie wykonania akcji. To kryterium, choć wysoce zalecane, bywa trudne do pełnego wdrożenia.
– Przykład poprawny: Edytor tekstu online automatycznie zapisuje wersje robocze podczas pisania i pozwala przywrócić poprzednie wersje (Undo/Redo). Nawet jeśli użytkownik przez niekontrolowany ruch skasuje cały wpis, może jednym poleceniem cofnąć tę zmianę. Również wszystkie formularze na stronie po wysłaniu wyświetlają „Dane zostały zapisane” z opcją „Edytuj ponownie” przez kilka minut, na wypadek gdyby użytkownik zauważył błąd po fakcie.
– Przykład błędny: System zarządzania treścią usuwa artykuł ze strony natychmiast po kliknięciu „Usuń”, bez możliwości przywrócenia. Redaktor z niepełnosprawnością ruchową omyłkowo kliknął zły przycisk – artykuł znika trwale. Na dodatek brak jest komunikatu „pomyślnie usunięto” czy innego feedbacku, co może wprowadzić dodatkowe zamieszanie. Taki system nie oferuje zabezpieczeń na poziomie AAA.

Podsumowanie: Powyższe kryteria WCAG koncentrują się na eliminowaniu barier, z jakimi mierzą się osoby z ograniczeniami motorycznymi. Kluczowe jest zapewnienie obsługi bez użycia myszy (klawiatura i alternatywy), dostosowanie interfejsu dla powolniejszego, mniej precyzyjnego działania oraz zabezpieczenie przed skutkami niezamierzonych akcji. Stosowanie tych zasad czyni strony bardziej przyjaznymi nie tylko dla osób z niepełnosprawnościami ruchowymi, ale często poprawia użyteczność dla wszystkich użytkowników[55][41].

Źródła: W3C WAI, How People with Disabilities Use the Web – Physical[41][56]; Wytyczne WCAG 2.1 i 2.2 (tłumaczenia i dokumentacja)[57][30]; Krakweb – Wytyczne WCAG a niepełnosprawności ruchowe[58][59]; oraz materiały własne.

[1] [5] [8] [9] [10] [11] [12] [13] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [26] [27] [32] [33] [34] [35] [36] [37] [38] [39] [40] [47] [57] Web Content Accessibility Guidelines (WCAG) 2.1