Dostępność klawiaturowa

Dostępność klawiaturowa oznacza, że każda czynność możliwa do wykonania na stronie może być wykonana wyłącznie za pomocą klawiatury. Jest to najbardziej bezwzględny wymóg dostępności: bez niego żadna technologia wspomagająca nie działa.

Interfejs klawiaturowy jest interfejsem uniwersalnym

Czytniki ekranu, urządzenia przełącznikowe, sterowanie głosowe, śledzenie wzroku — każda technologia wspomagająca stosowana w internecie ostatecznie działa przez warstwę klawiaturową. Użytkownik bez dysfunkcji motorycznej może nigdy nie nacisnąć klawisza Tab, jednak ta sama strona musi być w pełni obsługiwalna w ten sposób, aby osoby z niepełnosprawnościami mogły z niej korzystać.

Właśnie dlatego 2.1.1 Keyboard jest kryterium sukcesu na poziomie A: jego niespełnienie nie utrudnia korzystania ze strony — czyni ją całkowicie niedostępną dla całych grup użytkowników.

Co „obsługiwalność klawiaturą” rzeczywiście wymaga

• Tab i Shift+Tab przemieszczają fokus do przodu i do tyłu między elementami interaktywnymi.
• Enter aktywuje łącza i większość przycisków.
• Space aktywuje przyciski oraz przełącza pola wyboru i przyciski radiowe.
• Klawisze strzałek nawigują wewnątrz złożonych widgetów (panele zakładek, menu, grupy przycisków radiowych, listboxy, suwaki).
• Escape zamyka okna modalne, popovers i rozwijane listy.
• Page Up/Down, Home/End nawigują po długiej treści, gdy wynika to z konwencji platformy.

Widget, który nie implementuje konwencji klawiaturowej oczekiwanej przez użytkowników czytników ekranu ze względu na swoją rolę — np. kombobox ARIA reagujący na kliknięcia, ale nie na klawisze strzałek — jest technicznie fokusowalny, lecz funkcjonalnie uszkodzony.

Najszybszy audyt manualny

Należy przejść przez stronę klawiszem Tab od samej góry (fokus na pasku adresu, następnie Tab) aż do stopki. Kolejność fokusa powinna odpowiadać kolejności wizualnej. Każdy klikalny element powinien otrzymać fokus dokładnie raz. Naciśnięcie Enter lub Space na sfokusowanym elemencie powinno dać taki sam wynik jak kliknięcie go. Naciśnięcie Escape wewnątrz okna modalnego powinno je zamknąć. Jeśli jakiś element jest nieosiągalny, coś jest osiągane poza kolejnością lub fokus jest uwięziony — znaleziono błędy.

Pięć minut zdyscyplinowanej nawigacji klawiszem Tab ujawnia więcej problemów z dostępnością niż piętnaście minut skanowania narzędziem axe-core.

Typowe wzorce błędów

• <div onclick> dla klikalnych kart. Niefokowalne, niemożliwe do aktywowania klawiaturą, całkowicie niewidoczne dla czytników ekranu jako elementy interaktywne. Należy używać <button> (dla akcji) lub <a href> (dla nawigacji).
• Niestandardowe rozwijane listy, które nie otwierają się na Enter/Space. Zbudowane wyłącznie z obsługą kliknięć; użytkownicy klawiatury mogą sfokusować wyzwalacz, ale nie mogą otworzyć listy.
• Okna modalne, które nie zatrzymują fokusa. Tab przemieszcza fokus poza okno modalne i do (wizualnie ukrytej) strony za nim. Użytkownik nie może zobaczyć, gdzie się znajduje.
• Okna modalne, które nadmiernie zatrzymują fokus. Escape nie zamyka. Użytkownik jest uwięziony.
• Cel łącza pomijającego jest niefokusowalny. Łącze pomijające kieruje do #main, ale <main id="main"> nie ma tabindex="-1", więc fokus faktycznie się nie przemieszcza i następny Tab restartuje od początku strony.

Dwie biblioteki warte poznania: focus-trap do zarządzania fokusem wewnątrz okien modalnych oraz tabbable do znajdowania fokusowalnych elementów w kontenerze. Obie są małe i nie narzucają żadnych rozwiązań.