Obsługa strony bez myszy jest jednym z podstawowych warunków dostępności cyfrowej. Jeżeli użytkownik nie może otworzyć menu, przejść przez formularz albo zamknąć okna za pomocą klawiatury, część funkcji serwisu pozostaje dla niego niedostępna.
Problem wydaje się prosty do sprawdzenia. Wystarczy odłożyć mysz, nacisnąć Tab i zobaczyć, czy da się przejść przez stronę. Taka próba może ujawnić oczywiste bariery, ale sama w sobie nie jest jeszcze audytem.
Profesjonalna ocena wymaga znacznie więcej niż sprawdzenia, czy wokół linków pojawia się obramowanie. Trzeba rozumieć strukturę interfejsu, oczekiwane zachowanie komponentów, zasady zarządzania fokusem i wpływ błędów na rzeczywiste zadania użytkownika.
Dostęp z klawiatury nie dotyczy wyłącznie osób niewidomych
Klawiatura jest podstawowym sposobem obsługi dla wielu osób, które nie mogą sprawnie korzystać z myszy lub ekranu dotykowego. Powodem może być ograniczona sprawność dłoni, drżenie, uraz, ból, trudność w wykonywaniu precyzyjnych ruchów albo korzystanie z urządzeń wspomagających.
Z nawigacji klawiaturowej korzystają również osoby używające czytników ekranu. W ich przypadku widoczny interfejs i struktura odczytywana przez technologię wspomagającą muszą tworzyć spójny proces.
Jeżeli strona działa wyłącznie po kliknięciu myszą, problem nie ogranicza się do mniejszego komfortu. Użytkownik może nie być w stanie wykonać podstawowego zadania, na przykład wysłać formularza, zapisać się na wydarzenie albo otworzyć dokumentu.
Widoczny fokus to dopiero początek oceny
Najbardziej zauważalnym elementem obsługi klawiaturą jest fokus, czyli wskazanie aktualnie aktywnego linku, przycisku lub pola.
Brak widocznego fokusu jest poważną barierą. Użytkownik nie wie wtedy, który element uruchomi po naciśnięciu Enter. Jednak samo pojawienie się obramowania nie oznacza jeszcze, że interfejs działa prawidłowo.
W audycie trzeba ocenić między innymi, czy fokus:
- jest dostatecznie widoczny na różnych tłach,
- nie znika po zmianie stanu elementu,
- nie zostaje zasłonięty przez nagłówek lub komunikat,
- porusza się w logicznej kolejności,
- trafia do właściwego miejsca po otwarciu nowego komponentu,
- wraca tam, gdzie użytkownik oczekuje go po zakończeniu działania.
To właśnie te zależności są trudniejsze do wykrycia podczas pobieżnego testu.
Strona może być obsługiwana klawiaturą i nadal pozostawać niedostępna
Czasami każdy element otrzymuje fokus i reaguje na Enter, a mimo to korzystanie ze strony jest bardzo trudne.
Przykładem może być menu, które formalnie da się otworzyć, ale po rozwinięciu fokus przechodzi do linków ukrytych pod nawigacją. Innym przypadkiem jest formularz, który można wypełnić, lecz po błędzie użytkownik nie otrzymuje informacji, gdzie powinien dokonać poprawy.
Może się również zdarzyć, że kolejność przechodzenia nie odpowiada układowi treści. Użytkownik porusza się wtedy między nagłówkiem, stopką, formularzem i menu w sposób, którego nie da się przewidzieć.
Takie problemy pokazują różnicę między techniczną możliwością użycia klawiatury a rzeczywistą dostępnością procesu.
Najwięcej błędów pojawia się w elementach dynamicznych
Proste linki i standardowe przyciski zazwyczaj zachowują się przewidywalnie. Większe ryzyko pojawia się przy komponentach tworzonych indywidualnie albo dostarczanych przez wtyczki i zewnętrzne biblioteki.
Dotyczy to szczególnie:
- menu rozwijanych,
- okien modalnych,
- kalendarzy,
- sekcji rozwijanych,
- karuzel,
- niestandardowych list,
- odtwarzaczy,
- map,
- formularzy wieloetapowych.
Każdy z tych elementów wymaga określonego sposobu zarządzania fokusem i właściwych reakcji na klawisze. Błąd może prowadzić do zgubienia orientacji, przejścia do niewidocznego elementu albo całkowitego zablokowania dalszej obsługi.
Właśnie dlatego ocena komponentów dynamicznych wymaga znajomości standardowych wzorców interakcji. Sam fakt, że element „jakoś działa”, nie wystarcza.
Pułapka klawiatury może zatrzymać cały proces
Jednym z najpoważniejszych błędów jest pułapka klawiatury. Fokus trafia wtedy do określonego elementu, ale użytkownik nie może go opuścić.
Taka sytuacja może wystąpić w mapie, odtwarzaczu, kalendarzu, osadzonym dokumencie albo niestandardowym polu formularza. Osoba korzystająca wyłącznie z klawiatury zostaje uwięziona w jednym fragmencie interfejsu.
W praktyce może to oznaczać konieczność odświeżenia strony, zamknięcia karty albo rozpoczęcia zadania od początku.
Pułapki klawiatury są szczególnie niebezpieczne w procesach wieloetapowych, w których użytkownik wcześniej wprowadził dane lub dodał załączniki. Jedna wada komponentu może wtedy zablokować całą usługę.
Formularz wymaga oceny całego przebiegu
Formularz może posiadać poprawnie opisane pola i nadal być niedostępny.
Znaczenie ma nie tylko możliwość przejścia pomiędzy elementami. Trzeba ocenić również działanie kalendarza, list wyboru, zgód, dodawania plików, komunikatów błędów i potwierdzenia wysłania.
Ważne jest także to, co dzieje się po wykonaniu działania. Jeżeli użytkownik wysyła formularz z błędem, fokus powinien zostać poprowadzony w sposób pomagający odnaleźć problem. Jeżeli pojawia się okno potwierdzenia, nie może ono pozostawić użytkownika w ukrytej części strony.
Takie zależności często umykają podczas prostego przechodzenia po pustych polach. Dopiero wykonanie całego zadania pokazuje, czy proces rzeczywiście jest dostępny.
Kolejność fokusu ujawnia problemy strukturalne
Strona może wyglądać logicznie, ponieważ układ został uporządkowany wizualnie za pomocą arkuszy stylów. Kod może jednak zawierać elementy w zupełnie innej kolejności.
Dla użytkownika klawiatury oznacza to, że fokus porusza się inaczej niż wzrok. Przycisk może pojawić się przed instrukcją, formularz przed opisem usługi, a działania w stopce przed główną treścią.
Takie błędy są szczególnie częste w wielokolumnowych układach, kartach, menu mobilnych i elementach przenoszonych zależnie od szerokości ekranu.
Ocena kolejności wymaga spojrzenia na serwis jako na strukturę, a nie tylko atrakcyjny układ wizualny.
Wersja mobilna może zachowywać się inaczej
Strona poprawnie obsługiwana klawiaturą na komputerze może mieć zupełnie inne problemy po przejściu do wąskiego widoku.
Menu zmienia się w przycisk, część elementów zostaje ukryta, kolumny układają się jedna pod drugą, a na ekranie pojawiają się dodatkowe paski i komunikaty. Fokus może wtedy trafiać do elementów niewidocznych albo zostać zasłonięty.
Znaczenie ma również połączenie klawiatury z urządzeniem mobilnym, używanie przełączników i obsługa za pomocą technologii sterujących fokusem.
Dlatego test wykonany wyłącznie na szerokim ekranie nie daje pełnego obrazu dostępności interfejsu.
Automatyczny skaner nie oceni tego procesu
Narzędzia automatyczne mogą wykryć część błędów w kodzie. Mogą wskazać element bez właściwej roli, podejrzany atrybut `tabindex` albo brak dostępnej nazwy.
Nie przejdą jednak przez stronę w taki sposób jak użytkownik.
Nie ocenią wiarygodnie, czy po otwarciu menu fokus znajduje się we właściwym miejscu, czy kolejność jest zrozumiała ani czy użytkownik nie traci orientacji po zamknięciu okna. Nie wykonają również pełnego procesu formularza z błędami i zmianami dynamicznymi.
Dlatego testy automatyczne mogą wspierać audyt, ale nie zastąpią oceny manualnej.
Prosty test może wykryć problem, ale nie zawsze wskaże rozwiązanie
Osoba odpowiedzialna za serwis może zauważyć, że fokus znika albo menu zachowuje się nieprawidłowo. To ważna informacja, ale ustalenie źródła błędu bywa znacznie trudniejsze.
Problem może wynikać z:
- nieprawidłowej struktury HTML,
- działania skryptu,
- błędu biblioteki komponentów,
- konfliktu wtyczek,
- sposobu ukrywania elementów,
- niewłaściwego zarządzania fokusem,
- błędnej konfiguracji systemu zewnętrznego.
Profesjonalny audyt powinien nie tylko wykazać niezgodność, ale również opisać jej wpływ, sposób odtworzenia i kierunek naprawy. Dzięki temu wykonawca otrzymuje informację możliwą do zastosowania, a nie ogólne stwierdzenie, że „strona źle działa z klawiaturą”.
Ocenie powinny podlegać zadania, a nie pojedyncze elementy
Użytkownik nie przychodzi na stronę po to, aby sprawdzić działanie przycisku. Chce odnaleźć informację, złożyć wniosek, zapisać się, dokonać płatności albo skontaktować się z instytucją.
Dlatego audyt powinien obejmować całe scenariusze. Nawet poprawnie działające elementy mogą tworzyć niedostępny proces, jeśli zostały połączone w niewłaściwy sposób.
Szczególne znaczenie mają usługi zewnętrzne. Strona urzędu może być poprawna, ale po kliknięciu przycisku użytkownik trafia do systemu rezerwacyjnego lub płatniczego, którego nie da się obsłużyć bez myszy.
Z perspektywy odbiorcy nadal jest to jedna usługa. Niedostępność ostatniego etapu powoduje, że cały proces staje się nieskuteczny.
Profesjonalny test wymaga interpretacji
Audyt dostępności nie polega na odhaczeniu, że każdy element można zaznaczyć klawiszem Tab.
Trzeba ocenić przewidywalność działania, logiczną kolejność, widoczność fokusu, sposób otwierania i zamykania komponentów, komunikowanie zmian oraz możliwość ukończenia zadania.
Wymaga to znajomości WCAG, semantyki HTML, wzorców interakcji i sposobu działania technologii wspomagających. Potrzebna jest też umiejętność rozróżnienia błędów kosmetycznych od barier blokujących usługę.
Dobrze przeprowadzony audyt powinien wskazywać nie tylko miejsce występowania problemu, ale także jego znaczenie dla użytkownika i priorytet naprawy.
Samodzielna kontrola jest użyteczna, ale nie zastępuje audytu
Właściciel strony może wykonać podstawową próbę i sprawdzić, czy fokus jest widoczny oraz czy można przejść przez najważniejsze elementy. Taka kontrola pozwala szybko zauważyć najbardziej oczywiste bariery.
Nie powinna jednak być traktowana jako potwierdzenie zgodności.
Najpoważniejsze problemy często pojawiają się dopiero w określonym stanie komponentu, po wywołaniu błędu, zmianie szerokości ekranu albo przejściu do systemu zewnętrznego. Ich prawidłowa ocena wymaga testowania pełnych procesów i interpretacji zachowania interfejsu.
Samo przejście strony klawiszem Tab może więc rozpocząć diagnozę. Nie zastąpi jednak profesjonalnego audytu klawiaturowego.
Dostępność nie sprowadza się do tego, czy fokus pojawia się na ekranie. Najważniejsze jest to, czy użytkownik może zachować orientację, zrozumieć działanie komponentów i samodzielnie zakończyć rozpoczęte zadanie. Dopiero taka ocena pokazuje rzeczywistą jakość serwisu.