WCAG 2.1.1: Klawiatura

Co Oznacza Ta Zasada

WCAG 2.1.1 (Keyboard) wymaga, aby każda funkcjonalność na stronie internetowej lub w aplikacji była obsługiwana za pomocą interfejsu klawiatury. Oznacza to, że jeśli użytkownik może kliknąć przycisk, przeciągnąć element, najechać kursorem, aby rozwinąć menu, lub wchodzić w interakcję z jakimkolwiek innym elementem za pomocą myszy, musi być w stanie wykonać dokładnie tę samą akcję wyłącznie przy użyciu klawiatury — zazwyczaj klawiszy Tab, Shift+Tab, Enter, Spacja oraz strzałek.

Kryterium dotyczy wszystkich elementów interaktywnych: linków, przycisków, kontrolek formularzy, niestandardowych widżetów, okien modalnych, rozwijanych menu, akordeonów, karuzel, selektorów dat, interfejsów typu „przeciągnij i upuść”, interakcji opartych na canvas oraz wszelkich innych komponentów reagujących na dane wejściowe użytkownika. Jeśli treść wymaga od użytkownika wykonania ścieżki rysowania (gdzie sam przebieg ścieżki jest danymi wejściowymi, a nie tylko punkt końcowy), jest to jedyny formalnie uznany wyjątek w WCAG. Poza tym wąskim wyjątkiem każda inna funkcjonalność musi być dostępna z poziomu klawiatury.

Pozytywny wynik oznacza, że użytkownik korzystający wyłącznie z klawiatury może dotrzeć do każdego elementu interaktywnego za pomocą nawigacji klawiszem Tab lub strzałkami, aktywować go klawiszem Enter lub Spacja i zrealizować zamierzoną akcję bez konieczności użycia myszy na jakimkolwiek etapie. Negatywny wynik występuje, gdy spełniony jest którykolwiek z poniższych warunków: element interaktywny w ogóle nie otrzymuje fokusu; fokus jest nadawany, ale elementu nie da się aktywować; funkcja jest wywoływana wyłącznie przez zdarzenie myszy, takie jak onmouseover lub ondblclick, bez klawiaturowego odpowiednika; albo przewijalny kontener nie jest osiągalny z klawiatury, przez co zawartość w nim zostaje uwięziona.

Ważne jest, aby odróżnić WCAG 2.1.1 od WCAG 2.1.2 (No Keyboard Trap). Kryterium 2.1.1 zapewnia, że użytkownicy klawiatury mogą dotrzeć do wszystkiego i z tego korzystać; kryterium 2.1.2 zapewnia, że użytkownicy klawiatury nigdy nie są uwięzieni wewnątrz komponentu. Oba muszą być spełnione, aby uzyskać pełną zgodność na poziomie A.

Dlaczego To Ma Znaczenie

Dostępność z poziomu klawiatury nie jest kwestią niszową. Szacuje się, że 1 na 4 dorosłych w Stanach Zjednoczonych żyje z jakąś formą niepełnosprawności, a zaburzenia motoryczne — w tym takie schorzenia jak choroba Parkinsona, stwardnienie rozsiane, urazy rdzenia kręgowego, zespół RSI, różnice w budowie kończyn i drżenia — często uniemożliwiają użytkownikom obsługę standardowej myszy lub ekranu dotykowego. Użytkownicy ci polegają całkowicie na klawiaturach, przełącznikach, urządzeniach typu sip-and-puff, wskaźnikach głowy lub innych technologiach asystujących, które ostatecznie emulują dane wejściowe z klawiatury na poziomie systemu operacyjnego.

Osoby niewidome i słabowidzące, które korzystają z czytników ekranu, takich jak NVDA, JAWS czy VoiceOver, nawigują wyłącznie za pomocą klawiatury. Jeśli element nie jest osiągalny z klawiatury, czytnik ekranu nigdy go nie ogłosi, co sprawia, że treść staje się dla takiego użytkownika całkowicie niewidoczna. Według Światowej Organizacji Zdrowia co najmniej 2,2 miliarda ludzi na świecie ma jakąś formę zaburzeń widzenia z bliska lub daleka.

Rozważmy konkretny scenariusz: użytkownik z zaawansowanym reumatoidalnym zapaleniem stawów w obu dłoniach odwiedza stronę z procesem zakupowym w e-commerce. Niestandardowy selektor metody płatności na stronie jest zaimplementowany jako seria ostylowanych elementów <div>, które reagują wyłącznie na kliknięcia myszy. Użytkownik może przejść klawiszem Tab do kontenera, ale żadna pojedyncza opcja nie otrzymuje fokusu, a naciśnięcie Enter nic nie robi. Nie może dokończyć zakupu. Nie jest to drobna niedogodność — to całkowite wykluczenie z transakcji handlowej, które stanowi zarówno ryzyko prawne, jak i istotny scenariusz utraty przychodów dla firmy.

Poza niepełnosprawnością, dostępność z poziomu klawiatury przynosi korzyści zaawansowanym użytkownikom, którzy preferują skróty klawiaturowe ze względu na szybkość, użytkownikom w środowiskach korporacyjnych lub rządowych, gdzie użycie myszy jest ograniczone przepisami, oraz użytkownikom korzystającym z niestandardowych urządzeń wejściowych. Koreluje ona również pozytywnie z czystymi, semantycznymi strukturami HTML, które wyszukiwarki analizują bardziej niezawodnie, co przyczynia się do lepszej wydajności SEO i długoterminowej łatwości utrzymania bazy kodu.

Powiązane Reguły Axe-core

• scrollable-region-focusable: Ta reguła sprawdza, czy każdy element, który ma nadmiarową zawartość (tzn. jest przewijalny), jest osiągalny z klawiatury. Gdy kontener ma właściwości CSS takie jak overflow: auto lub overflow: scroll, widzący użytkownicy myszy mogą przewijać go kółkiem myszy lub gładzikiem. Użytkownicy klawiatury muszą jednak mieć możliwość przejścia klawiszem Tab do kontenera lub użycia klawiszy strzałek do przewijania. Reguła oznacza przewijalne regiony, które nie mają atrybutu tabindex ani naturalnie fokusowalnego elementu potomnego, co oznacza, że użytkownik korzystający wyłącznie z klawiatury nie miałby żadnej możliwości dostępu do nadmiarowej treści. Automatyczne wykrywanie jest tu wiarygodne, ponieważ axe może sprawdzić obliczone style i drzewo DOM, aby zidentyfikować elementy z przewijalnym overflow, które nie mają możliwości uzyskania fokusu z klawiatury.
• server-side-image-map: Ta reguła oznacza użycie map obrazów po stronie serwera — elementów HTML <img> z atrybutem ismap. Mapy obrazów po stronie serwera wysyłają do serwera surowe współrzędne pikseli kliknięcia myszy, aby określić, który link został aktywowany. Ponieważ działanie zależy całkowicie od współrzędnych pikseli pochodzących z urządzenia wskazującego, nie istnieje równoważny mechanizm klawiaturowy. W przeciwieństwie do map obrazów po stronie klienta (które używają elementów <map> i <area> i mogą być dostępne z klawiatury), mapy obrazów po stronie serwera są z założenia niekompatybilne z nawigacją wyłącznie klawiaturą. Axe oznacza każdy element <img ismap> jako błąd dostępności z poziomu klawiatury. Ręczna weryfikacja powinna potwierdzić, czy mapa obrazu jest jedynym sposobem dostępu do powiązanej nawigacji lub funkcjonalności.

Kluczowe jest zrozumienie, że narzędzia automatyczne, takie jak axe-core, mogą wykryć tylko podzbiór błędów dostępności z poziomu klawiatury. Wiele naruszeń wymaga testów manualnych, ponieważ obejmują one niestandardowe nasłuchiwacze zdarzeń JavaScript, dynamiczne zarządzanie fokusem lub złożone wzorce interakcji, których analiza statyczna nie jest w stanie w pełni ocenić. Na przykład przycisk zaimplementowany jako <div> z nasłuchiwaczem zdarzenia click może otrzymywać fokus dzięki tabindex='0', ale nie reagować na naciśnięcia klawiszy Enter lub Spacja — jest to błąd, którego axe nie zawsze może wykryć bez wykonania interakcji.

Jak Testować

1. Automatyczne skanowanie za pomocą axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools dla Chrome lub Firefox. Przejdź do testowanej strony i uruchom skan całej strony. Przefiltruj wyniki pod kątem reguł oznaczonych tagami wcag2a i keyboard. Szukaj w szczególności naruszeń scrollable-region-focusable i server-side-image-map. W Lighthouse (Chrome DevTools) uruchom audyt Accessibility i przejrzyj kategorię „Keyboard”. Pamiętaj, że te narzędzia ujawnią oczywiste błędy strukturalne, ale nie wykryją wszystkich problemów z niestandardowymi widżetami.
2. Ręczny test nawigacji klawiaturą: Odłącz lub odłóż całkowicie mysz. Zaczynając od paska adresu przeglądarki, naciskaj wielokrotnie klawisz Tab, aby przechodzić do przodu przez wszystkie elementy fokusowalne na stronie. Naciśnij Shift+Tab, aby przechodzić wstecz. Dla każdego elementu interaktywnego — linków, przycisków, pól formularza, niestandardowych rozwijanych list, okien modalnych, suwaków — sprawdź, czy: (a) otrzymuje widoczny wskaźnik fokusu; (b) naciśnięcie klawisza Enter lub Spacja aktywuje go zgodnie z oczekiwaniami; (c) każde wynikowe okno dialogowe lub panel można również nawigować i zamknąć za pomocą klawiatury. Używaj klawiszy strzałek wewnątrz widżetów, które implementują wzorce złożone (menu, listy kart, grupy przycisków radiowych, listboxy).
3. Test czytnika ekranu + klawiatury z NVDA i Firefox: Uruchom NVDA (darmowy, Windows) i otwórz Firefox. Użyj trybu Browse NVDA (klawisze strzałek), aby czytać stronę i identyfikować wszystkie elementy interaktywne. Przełącz się na tryb Focus (Insert+Spacja lub automatycznie w polach formularza), aby wchodzić w interakcję z kontrolkami. Sprawdź, czy niestandardowe widżety ogłaszają swoją rolę, stan i nazwę oraz czy całą funkcjonalność można zrealizować bez myszy. Przetestuj wszystkie przewijalne kontenery, próbując przejść do nich klawiszem Tab i użyć klawiszy strzałek do przewijania.
4. Test czytnika ekranu z VoiceOver i Safari (macOS/iOS): Włącz VoiceOver (Command+F5 na macOS). Użyj VO+strzałka w prawo, aby liniowo nawigować po stronie. Użyj klawisza Tab, aby przechodzić między elementami interaktywnymi. Potwierdź, że regiony przewijalne są osiągalne i że żadna funkcjonalność nie wymaga gestu przesunięcia lub interakcji wskaźnikiem bez alternatywy dostępnej z klawiatury.
5. Test z JAWS i Chrome: Z uruchomionym JAWS otwórz Chrome i przejdź do strony. Użyj wirtualnego kursora JAWS, aby przeglądać treść, oraz klawisza Tab, aby przechodzić między elementami interaktywnymi. Przetestuj w szczególności wszystkie niestandardowe widżety JavaScript — akordeony, karuzele, okna modalne, niestandardowe pola wyboru — przechodząc do nich klawiszem Tab i próbując w pełni obsłużyć je za pomocą klawiatury. Zanotuj każdy element, który otrzymuje fokus, ale nie może zostać aktywowany, lub każdą funkcjonalność, która jest dostępna wyłącznie poprzez najechanie myszą.
6. Specyficzny test regionów przewijalnych: Zidentyfikuj wszystkie kontenery na stronie z widocznymi paskami przewijania lub zawierające więcej treści niż ich widoczny obszar. Spróbuj przejść klawiszem Tab do każdego kontenera. Jeśli Tab nie przenosi fokusu do wnętrza kontenera i nie ma on fokusowalnych elementów potomnych, kontener prawdopodobnie stanowi błąd dostępności z poziomu klawiatury. Spróbuj nacisnąć klawisze strzałek, gdy fokus ma kontener lub pobliski element, aby sprawdzić, czy przewijanie jest możliwe.

Jak Naprawić

Scenariusz 1: Przewijalny Kontener — Nieprawidłowy

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenariusz 1: Przewijalny Kontener — Prawidłowy

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenariusz 2: Mapa Obrazu po Stronie Serwera — Nieprawidłowy

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Scenariusz 2: Mapa Obrazu po Stronie Serwera — Prawidłowy

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Scenariusz 3: Niestandardowy Widżet Używający Wyłącznie Zdarzeń Myszy — Nieprawidłowy

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Scenariusz 3: Niestandardowy Widżet Używający Wyłącznie Zdarzeń Myszy — Prawidłowy

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Scenariusz 4: Menu Rozwijane Tylko na Hover — Nieprawidłowy

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Scenariusz 4: Menu Rozwijane Tylko na Hover — Prawidłowy

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Typowe Błędy

• Używanie onclick jako jedynego obsługiwacza zdarzeń na nienatywnym elemencie bez dodania odpowiedniego obsługiwacza onkeydown lub onkeyup — kliknięcia myszy wywołują onclick, ale aktywacja klawiaturą na <div> lub <span> już nie.
• Dodanie tabindex='0' do niestandardowego elementu interaktywnego, ale zapomnienie o dodaniu role='button' (lub odpowiedniej roli), co oznacza, że czytniki ekranu nie przekazują użytkownikowi celu elementu.
• Budowanie nawigacji rozwijanej, która opiera się wyłącznie na pseudoklasie CSS :hover, bez klawiaturowego przełącznika opartego na JavaScript, co sprawia, że podmenu są niewidoczne i nieosiągalne dla użytkowników klawiatury.
• Implementowanie interfejsów typu „przeciągnij i upuść” — sortowanie list, tablice kanban, strefy przesyłania plików — bez alternatywnego mechanizmu dostępnego z klawiatury, takiego jak polecenia przenoszenia wywoływane klawiaturą lub osobna kontrolka do zmiany kolejności.
• Tworzenie przewijalnych kontenerów (takich jak pola z regulaminem, okna czatu czy tabele danych wewnątrz kontenerów o stałej wysokości) bez tabindex='0', co uniemożliwia użytkownikom klawiatury przewijanie w celu obejrzenia całej treści.
• Używanie <img ismap> dla komponentów nawigacyjnych odziedziczonych po starszych bazach kodu bez zastąpienia ich mapami obrazów po stronie klienta lub standardowymi linkami nawigacyjnymi.
• Stosowanie tabindex='-1' na elementach interaktywnych w celu usunięcia ich z naturalnej kolejności Tab bez zapewnienia programistycznej strategii zarządzania fokusem, co skutkuje kontrolkami, które są trwale nieosiągalne z klawiatury.
• Wywoływanie funkcjonalności wyłącznie na zdarzeniach mouseenter, mouseleave lub mousemove (podpowiedzi, podglądy, menu kontekstowe) bez równoważnych alternatyw zdarzeń focus, blur lub zdarzeń klawiatury.
• Zakładanie, że okno modalne automatycznie zarządza fokusem — brak przeniesienia fokusu do okna dialogowego po jego otwarciu i brak przywrócenia fokusu do elementu wywołującego po jego zamknięciu, co pozostawia użytkowników klawiatury zdezorientowanych na stronie.
• Ustawianie w CSS pointer-events: none na elemencie, który powinien być dostępny z klawiatury, co, choć nie wpływa bezpośrednio na zachowanie klawiatury, często jest powiązane ze wzorcami JavaScript, które również blokują interakcję z klawiatury.

Związek z Przepisami Dotyczącymi Dostępności w Turcji

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych zgodne z WCAG 2.1 na poziomie AA. WCAG 2.1.1 (Keyboard) jest kryterium poziomu A, co stawia je w najwyższym priorytetowo koszyku wymogów zgodności. Zgodność na poziomie A jest absolutnym minimalnym poziomem bazowym — jeśli strona nie spełnia kryteriów poziomu A, jest uznawana za niedostępną niezależnie od innych wprowadzonych usprawnień.

Zgodnie z okrężnicą terminy dostosowania są zróżnicowane w zależności od typu podmiotu: instytucje publiczne i agencje rządowe są zobowiązane do osiągnięcia zgodności w ciągu jednego roku od daty publikacji okrężnicy, podczas gdy podmioty sektora prywatnego objęte regulacją mają na dostosowanie dwa lata.

Podmioty objęte Okrężnicą Prezydencką 2025/10 obejmują szeroki przekrój tureckich usług cyfrowych: platformy e-commerce, instytucje publiczne i ministerstwa, banki i instytucje finansowe, szpitale i ś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 upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

Dla wszystkich tych podmiotów niespełnienie WCAG 2.1.1 oznacza, że użytkownicy zależni od klawiatury — w tym obywatele z niepełnosprawnościami motorycznymi, osoby starsze i użytkownicy czytników ekranu — nie mogą uzyskać dostępu do ich kluczowych usług cyfrowych. Jest to bezpośrednie naruszenie przepisów. W praktyce oznacza to, że serwis e-commerce, w którym procesu zakupu nie da się ukończyć za pomocą klawiatury, lub szpitalny portal pacjenta, w którym rezerwacja wizyty wymaga interakcji myszą, byłby niezgodny z wymaganiami okrężnicy.

Organizacje objęte okrężnicą powinny przeprowadzić audyt dostępności z poziomu klawiatury jako pierwszy krok w swoim programie naprawczym w zakresie dostępności. Ponieważ błędy WCAG 2.1.1 są często natury architektonicznej — wynikają z wyboru elementów HTML, wzorców wiązania zdarzeń i domyślnych ustawień frameworków komponentów — ich usunięcie może wymagać zmian na poziomie kodu, a nie jedynie korekt konfiguracyjnych. SDK nakładki Accsible może pomóc w ujawnianiu i łagodzeniu typowych luk w dostępności z poziomu klawiatury na warstwie JavaScript, ale zespoły powinny również dążyć do wprowadzenia strukturalnych poprawek w swoim kodzie źródłowym, aby osiągnąć solidną, możliwą do audytowania zgodność, która zadowoli organy nadzorcze.