WCAG 2.1.3: Klawiatura (bez wyjątku)

Co Oznacza Ta Zasada

WCAG 2.1.3 — Klawiatura (bez wyjątków) to kryterium sukcesu na poziomie AAA w ramach WCAG 2.1 i 2.2, które rozszerza WCAG 2.1.1 (Klawiatura, poziom A) poprzez usunięcie wszystkich wyłączeń. W szczególności stanowi: Cała funkcjonalność treści jest obsługiwana za pomocą interfejsu klawiatury bez konieczności stosowania określonych czasów dla poszczególnych naciśnięć klawiszy. Kluczową różnicą w stosunku do 2.1.1 jest brak klauzuli wyjątków, która wyłącza funkcjonalność, w której podstawowa funkcja wymaga wprowadzania danych zależnych od ścieżki ruchu użytkownika, a nie tylko od punktów końcowych.

W ramach 2.1.1 deweloperzy mogą w sposób uzasadniony wyłączyć z obsługi klawiatury takie funkcje jak płótna do rysowania odręcznego, narzędzia malowania oparte na gestach czy interfejsy przeciągania wrażliwe na ścieżkę, ponieważ dokładna ścieżka wskaźnika użytkownika determinuje wynik. WCAG 2.1.3 całkowicie eliminuje ten wyjątek. Zgodnie z tym kryterium każda pojedyncza funkcja—w tym rysowanie, przeciąganie, gesty zależne od ścieżki oraz każda interakcja, która historycznie opierała się na ruchu wskaźnika—musi być dostępna z poziomu klawiatury. Oznacza to, że deweloperzy muszą zapewnić alternatywne mechanizmy klawiaturowe (na przykład dostępną toolbar z narzędziami kształtów, tryby rysowania sterowane klawiaturą lub alternatywy oparte na formularzach) nawet dla zadań odręcznych lub zależnych od ścieżki.

Pozytywny wynik wymaga, aby każdą operację na stronie można było zainicjować, przejść przez nią i zakończyć wyłącznie za pomocą klawiatury. Obejmuje to zarządzanie fokusem, okna modalne, przeciąganie i upuszczanie w celu zmiany kolejności, niestandardowe suwaki, narzędzia do rysowania na canvas, interakcje z mapą, nawigację w karuzelach oraz kontrolki odtwarzania wideo. Nie może występować pułapka klawiaturowa (również objęta 2.1.2), żadna funkcja, którą można wywołać wyłącznie przez kliknięcie, najechanie kursorem lub gest dotykowy bez równoważnej ścieżki klawiaturowej, ani poleganie na ścieżkach wskaźnika myszy.

Negatywny wynik występuje, gdy jakakolwiek funkcjonalność—bez względu na to, jak niszowa lub drugorzędna może się wydawać—nie może zostać osiągnięta lub zakończona wyłącznie za pomocą klawiatury. Ponieważ to kryterium nie przewiduje wyjątków, nawet jedna funkcja niedostępna z poziomu klawiatury stanowi pełną porażkę, co czyni je jednym z najbardziej wymagających standardów w WCAG.

Dlaczego To Ma Znaczenie

Dostępność z poziomu klawiatury jest fundamentalna dla użytkowników z niepełnosprawnościami ruchowymi, którzy nie mogą korzystać z urządzeń wskazujących. Osoby z takimi schorzeniami jak choroba Parkinsona, tetraplegia, porażenie mózgowe, urazy wynikające z powtarzalnych przeciążeń czy różnice w budowie kończyn często polegają wyłącznie na fizycznej klawiaturze, urządzeniu przełącznikowym, kontrolerze typu sip-and-puff lub technologii śledzenia wzroku emulującej wejście z klawiatury. Według Światowej Organizacji Zdrowia około 1,3 miliarda ludzi na świecie żyje z jakąś formą znaczącej niepełnosprawności, a niepełnosprawności ruchowe lub fizyczne stanowią istotną część tej populacji. Tylko w Turcji dane Tureckiego Instytutu Statystycznego (TÜİK) wskazują, że ponad 8,5 miliona osób zgłasza co najmniej jedno ograniczenie funkcjonalne.

Poza niepełnosprawnościami ruchowymi, dostępność z poziomu klawiatury przynosi korzyści osobom niewidomym i słabowidzącym, które nawigują za pomocą czytników ekranu, takich jak NVDA, JAWS czy VoiceOver—wszystkie one polegają na poleceniach klawiaturowych do poruszania się po treści internetowej i interakcji z nią. Użytkownicy z nadwrażliwością na światło mogą unikać ekranów dotykowych, a osoby z niepełnosprawnościami poznawczymi często korzystają z przewidywalnej, liniowej nawigacji, jaką zapewnia interakcja za pomocą klawiatury.

Rozważmy konkretny scenariusz z rzeczywistości: platformę do projektowania graficznego, która oferuje narzędzie do wektorowego rysowania odręcznego. Zgodnie z WCAG 2.1.1 mogłoby ono być wyłączone, ponieważ kształt definiuje ścieżka wskaźnika. Zgodnie z WCAG 2.1.3 platforma musi zapewnić alternatywę—na przykład bibliotekę kształtów, serię punktów kontrolnych sterowanych klawiaturą lub edytor ścieżek SVG oparty na tekście—tak, aby użytkownik z niepełnosprawnością ruchową nadal mógł tworzyć grafikę wektorową bez myszy. Brak takiego rozwiązania wyklucza znaczącą grupę profesjonalistów kreatywnych, którzy polegają wyłącznie na dostępie z poziomu klawiatury.

Z perspektywy użyteczności i SEO interfejsy prawidłowo dostępne z poziomu klawiatury zazwyczaj charakteryzują się czystszym zarządzaniem fokusem, bardziej logiczną kolejnością tabulacji i dobrze ustrukturyzowanymi hierarchiami DOM—wszystko to przyczynia się do lepszej indeksowalności i wyższej jakości doświadczenia użytkownika dla wszystkich, w tym zaawansowanych użytkowników, którzy preferują skróty klawiaturowe ze względu na szybkość.

Powiązane Zasady Axe-core

WCAG 2.1.3 wymaga testów manualnych. W przeciwieństwie do wielu kryteriów WCAG, narzędzia automatyczne nie mogą wiarygodnie wykrywać naruszeń tego kryterium, ponieważ:

• Wykrywanie funkcjonalności zależnej od ścieżki wykracza poza analizę statyczną: Axe-core i Lighthouse analizują DOM pod kątem wzorców strukturalnych—brakującego tabindex, nieobecnych atrybutów role czy błędnego zarządzania fokusem—ale nie są w stanie zasymulować użytkownika próbującego wykonać każdą funkcję na stronie i ustalić, czy istnieje alternatywa klawiaturowa. Element canvas może być obecny w DOM bez atrybutów ARIA, a mimo to dostępny toolbar klawiaturowy w pobliżu może w pełni spełniać 2.1.3. Z drugiej strony pozornie zwykły przycisk może wywoływać akcję JavaScript, która uruchamia widget dostępny wyłącznie za pomocą myszy, którego narzędzia automatyczne nigdy nie oznaczą. Logiczna równoważność alternatyw klawiaturowych względem ścieżek sterowanych myszą wymaga oceny przez człowieka.
• Brak dedykowanej zasady axe-core mapującej się na 2.1.3: Najbliższe zasady axe—takie jak scrollable-region-focusable (która sprawdza, czy przewijalne regiony treści mogą otrzymać fokus klawiatury) i tabindex (która oznacza dodatnie wartości tabindex zakłócające naturalną kolejność fokusu)—dotyczą powiązanych, ale węższych zagadnień w ramach 2.1.1 i 2.4.3. Nie oceniają i nie mogą oceniać, czy cała funkcjonalność, w tym operacje zależne od ścieżki, ma odpowiednik klawiaturowy.
• Audyt interaktywnych widgetów wymaga interakcji w czasie rzeczywistym: Niestandardowe komponenty przeciągnij-i-upuść, edytory oparte na canvas oraz karuzele sterowane gestami ujawniają swoją niedostępność z poziomu klawiatury dopiero wtedy, gdy tester faktycznie spróbuje użyć ich bez myszy. Statyczne skanowanie DOM przez axe-core nie może wywoływać nasłuchiwaczy zdarzeń, obserwować utraty fokusu podczas operacji asynchronicznych ani oceniać, czy operację przeciągania można zakończyć za pomocą klawiszy strzałek i Enter/Spacja.
• Na co zwracać uwagę podczas audytu manualnego: Testerzy powinni w szczególności szukać elementów canvas używanych do rysowania lub interakcji, list lub obszarów przesyłania plików z przeciąganiem i upuszczaniem, niestandardowych kontrolek map lub wizualizacji danych, suwaków zależnych od czasu oraz wszelkich komponentów reagujących na zdarzenia mousemove, pointermove lub gesty dotykowe bez odpowiadających im obsług zdarzeń klawiaturowych.

Jak Testować

1. Uruchom automatyczne skanowanie bazowe: Użyj axe DevTools (rozszerzenie przeglądarki lub CLI) lub Google Lighthouse na swojej stronie, aby zidentyfikować oczywiste problemy z dostępnością klawiaturową—brakujące elementy fokusowalne, pułapki klawiaturowe lub elementy z pointer-events: none, które powinny być interaktywne. Choć te narzędzia nie wykryją bezpośrednio naruszeń 2.1.3, ujawnią powiązane problemy i ustanowią czystą bazę przed rozpoczęciem testów manualnych.
2. Sporządź katalog całej funkcjonalności interaktywnej: Przed testowaniem utwórz pełną inwentaryzację każdego interaktywnego komponentu na stronie: przyciski, linki, formularze, okna modalne, akordeony, karuzele, mapy, narzędzia canvas, obszary przeciągnij-i-upuść, niestandardowe rozwijane listy, selektory dat, odtwarzacze wideo oraz wszelkie widgety reagujące na zdarzenia myszy lub dotyku. Ta inwentaryzacja staje się twoją listą kontrolną testów.
3. Test nawigacji wyłącznie klawiaturą: Odłącz lub wyłącz mysz. Używaj klawiszy Tab i Shift+Tab do przemieszczania fokusu, Enter i Spacja do aktywowania kontrolek, klawiszy strzałek dla złożonych widgetów (menu, suwaki, zakładki, grupy przycisków radiowych) oraz Escape do zamykania okien dialogowych. Spróbuj wykonać każdą funkcję z listy inwentaryzacyjnej. Zanotuj każdą funkcję, której nie możesz zainicjować, zakończyć lub opuścić, używając wyłącznie klawiatury.
4. Testowanie z czytnikiem ekranu NVDA + Firefox: Uruchom NVDA (Windows) z Firefox. Nawiguj za pomocą kursora wirtualnego (H dla nagłówków, B dla przycisków, F dla pól formularzy, Tab dla elementów interaktywnych). Spróbuj wykonać każdą funkcję. Słuchaj ogłaszanych ról, nazw i stanów. Zidentyfikuj każdy interaktywny obszar, który jest nieosiągalny lub nie generuje żadnego komunikatu głosowego.
5. Testowanie z czytnikiem ekranu JAWS + Chrome: Użyj JAWS w systemie Windows z Chrome. Używaj wirtualnego kursora JAWS i trybu formularzy (przełączanego klawiszem Enter). Zweryfikuj, że całą funkcjonalność można obsłużyć i że fokus jest prawidłowo zarządzany po każdej interakcji—szczególnie po otwarciu okien modalnych lub załadowaniu treści AJAX.
6. Testowanie z czytnikiem ekranu VoiceOver + Safari (macOS/iOS): Włącz VoiceOver (Command + F5 w macOS). Używaj Control + Option + strzałki do nawigacji. W iOS używaj gestów przesunięcia. Potwierdź, że wszystkie funkcje są osiągalne i obsługiwalne. Zwróć szczególną uwagę na niestandardowe widgety dotykowe, które mogą nie mieć odpowiedników klawiaturowych w wersji desktopowej.
7. Audyt funkcjonalności zależnej od ścieżki: Dla każdego płótna do rysowania, interakcji z mapą lub komponentu sterowanego gestami sprawdź, czy istnieje alternatywny mechanizm klawiaturowy. Spróbuj utworzyć kształt, zmienić kolejność elementu listy lub przesunąć mapę, używając wyłącznie kontrolek klawiaturowych. Jeśli nie istnieje żadna ścieżka klawiaturowa, jest to bezpośrednie naruszenie 2.1.3.
8. Sprawdzenie widoczności fokusu: Podczas nawigacji wyłącznie klawiaturą potwierdź, że fokus jest zawsze widoczny na ekranie i logicznie uporządkowany. Niewidoczny fokus lub fokus, który przeskakuje w nieoczekiwane miejsca, jest porażką z punktu widzenia użyteczności i prawdopodobnie również narusza 2.4.7 i 2.4.3.

Jak Naprawić

Narzędzie do rysowania na canvas — Nieprawidłowe

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Narzędzie do rysowania na canvas — Prawidłowe

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Zmiana kolejności listy metodą przeciągnij-i-upuść — Nieprawidłowe

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Zmiana kolejności listy metodą przeciągnij-i-upuść — Prawidłowe

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Interaktywne kontrolki mapy — Nieprawidłowe

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Interaktywne kontrolki mapy — Prawidłowe

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Typowe Błędy

• Założenie, że wyjątek zależny od ścieżki z WCAG 2.1.1 nadal obowiązuje: Deweloperzy zaznajomieni z poziomem A czasami tworzą narzędzia do rysowania odręcznego lub narzędzia gestów bez alternatyw klawiaturowych, nie zdając sobie sprawy, że 2.1.3 wyraźnie usuwa ten wyjątek. Każda funkcja, w tym zależna od ścieżki, musi mieć odpowiednik klawiaturowy na tym poziomie.
• Podpinanie wyłącznie obsługi onclick i onmousedown do niestandardowych elementów interaktywnych: Niestandardowe widgety zbudowane z elementów <div> lub <span>, które nasłuchują tylko zdarzeń myszy, są całkowicie nieosiągalne z poziomu klawiatury. Zawsze dodawaj obsługę onkeydown lub onkeyup obok nasłuchiwaczy zdarzeń myszy i upewnij się, że element ma tabindex='0' oraz odpowiednią rolę ARIA.
• Używanie tabindex='-1' na elementach, które powinny znajdować się w kolejności tabulacji: Ustawienie tabindex='-1' usuwa element z sekwencyjnej kolejności tabulacji. Jest to odpowiednie tylko dla elementów zarządzanych programowo (np. w ramach złożonego widgetu używającego ruchomego tabindex). Zastosowanie tego do samodzielnych kontrolek interaktywnych czyni je niedostępnymi z poziomu klawiatury.
• Implementacja przeciągnij-i-upuść bez mechanizmu zmiany kolejności opartego na klawiaturze: Biblioteki takie jak SortableJS lub niestandardowe implementacje przeciągania często nie zapewniają domyślnie alternatywy klawiaturowej. Deweloperzy muszą zaimplementować wzorzec ARIA drag-and-drop lub zapewnić zmianę kolejności za pomocą klawiszy strzałek góra/dół, aby zmiana kolejności list była w pełni obsługiwana z poziomu klawiatury.
• Poleganie na CSS :hover do ujawniania kontrolek interaktywnych: Podmenu rozwijane, przyciski akcji oparte na podpowiedziach (tooltipach) lub kontrolki ujawniane wyłącznie przy najechaniu kursorem są niedostępne dla użytkowników klawiatury, chyba że obsłużone są również stany :focus i :focus-within. Użytkownik klawiatury nigdy nie może „najechać”, więc treść dostępna tylko przy najechaniu jest dla niego de facto ukryta.
• Brak zarządzania fokusem po zmianach dynamicznej treści: Gdy otwiera się okno modalne, pojawia się komunikat inline lub widget ładowany przez AJAX zastępuje istniejącą treść, fokus musi zostać programowo przeniesiony do nowej treści za pomocą element.focus(). Brak takiego działania pozostawia użytkowników klawiatury w miejscu, w którym wywołali zmianę, bez świadomości, że pojawiła się nowa treść.
• Budowanie niestandardowych suwaków wyłącznie z onmousemove: Suwaki typu range zbudowane z elementów <div>, które śledzą pozycję myszy w celu zmiany wartości, muszą również implementować obsługę klawiszy ArrowLeft, ArrowRight, Home i End zgodnie ze wzorcem suwaka ARIA oraz ujawniać bieżącą wartość za pomocą aria-valuenow, aria-valuemin i aria-valuemax.
• Umieszczanie fokusu klawiatury wewnątrz iframe bez zapewnienia wyjścia: Osadzone iframe—zwłaszcza te zawierające zewnętrzne widgety, takie jak mapy, formularze płatności czy narzędzia czatu—mogą uwięzić fokus klawiatury, jeśli osadzona treść sama w sobie nie jest dostępna z poziomu klawiatury i nie obsługuje klawisza Escape do przywrócenia fokusu do dokumentu nadrzędnego.
• Pomijanie wsparcia klawiatury w wizualizacjach danych opartych na canvas: Wykresy i grafy renderowane w <canvas> są niewidoczne dla klawiatury i czytników ekranu, chyba że obok elementu canvas zapewniona jest dostępna alternatywa (tabela danych, równoważny SVG z ARIA lub punkty danych nawigowalne z poziomu klawiatury).
• Testowanie dostępności klawiaturowej wyłącznie za pomocą Tab i Enter, z pominięciem wzorców klawiszy dla złożonych widgetów: Wiele wzorców widgetów ARIA—menu, drzewa, siatki, panele kart, listboxy—wymaga nawigacji klawiszami strzałek wewnątrz widgetu, z tylko jednym punktem tabulacji dla całego komponentu (ruchomy tabindex). Testowanie wyłącznie Tab i Enter nie ujawni błędów w tych złożonych wzorcach i da fałszywe poczucie zgodności.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia kompleksowe ramy dostępności stron internetowych i aplikacji mobilnych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okrężnica nakazuje zgodność ze standardami zgodnymi z WCAG 2.1 i 2.2, wymagając od objętych organizacji zapewnienia, że ich usługi cyfrowe są postrzegalne, operowalne, zrozumiałe i solidne dla wszystkich użytkowników, w tym osób z niepełnosprawnościami.

Podmioty objęte tymi regulacjami obejmują instytucje i agencje publiczne na wszystkich szczeblach administracji, platformy e-commerce, banki i dostawców usług finansowych, szpitale i placówki opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE). Dla tych organizacji zgodność z kryteriami sukcesu na poziomie A i AA stanowi minimalną podstawę prawną.

WCAG 2.1.3 — Klawiatura (bez wyjątków) jest kryterium na poziomie AAA, a zatem nie jest wyraźnie wymagane jako minimalny wymóg prawny na mocy okrężnicy. Jednak duch regulacji—zapewnienie równego dostępu cyfrowego dla milionów użytkowników z niepełnosprawnościami w Turcji—silnie współgra z intencją tego kryterium. Organizacjom w objętych sektorach, które oferują wyspecjalizowane usługi użytkownikom z niepełnosprawnościami ruchowymi lub prowadzą portale rządowe używane przez obywateli polegających na technologiach asystujących, zdecydowanie zaleca się dążenie do zgodności na poziomie AAA w zakresie dostępu z poziomu klawiatury.

Osiągnięcie zgodności z WCAG 2.1.3 sygnalizuje najlepsze w swojej klasie zaangażowanie w dostępność, wykraczające poza minimalne wymogi regulacyjne. Dla tureckich organizacji, które chcą obsłużyć jak najszerszą bazę użytkowników, wykazać odpowiedzialność społeczną lub uczestniczyć w rynkach cyfrowych Unii Europejskiej, gdzie mogą obowiązywać wyższe standardy dostępności, wdrożenie pełnej operowalności z poziomu klawiatury bez wyjątków stanowi zarówno przewagę konkurencyjną, jak i etyczną. W miarę jak turecki krajobraz regulacyjny będzie się rozwijał, a mechanizmy egzekwowania będą dojrzewać, wcześni adopci kryteriów na poziomie AAA, takich jak 2.1.3, będą w dobrej pozycji, aby sprostać ewentualnemu zaostrzeniu regulacji bez kosztownych działań naprawczych.