WCAG 2.1.1: Klawiatura

Wprowadzenie do WCAG 2.1.1 Klawiatura

Kryterium sukcesu WCAG 2.1.1 „Klawiatura” (ang. Keyboard) jest podstawowym wymogiem dostępności na poziomie A, co oznacza, że jest kluczowe dla szerokiego grona użytkowników. Zapewnia ono, że cała funkcjonalność dostępna na stronie internetowej może być obsługiwana wyłącznie za pomocą interfejsu klawiatury, bez konieczności użycia myszy lub innego urządzenia wskazującego. Celem tego kryterium jest umożliwienie osobom, które nie mogą korzystać z myszy, pełnej interakcji z witryną i dostęp do wszystkich jej funkcji.

Dlaczego to jest ważne? (Wpływ na dostępność i grupy użytkowników)

Dostępność klawiaturowa jest fundamentem dla wielu użytkowników i ma ogromny wpływ na ich zdolność do korzystania z treści cyfrowych:

• Osoby z niepełnosprawnościami ruchowymi: Użytkownicy z ograniczeniami ruchowymi, takimi jak drżenie rąk, paraliż, brak kończyn górnych lub urazy, często nie są w stanie precyzyjnie operować myszą. Klawiatura (lub specjalistyczne urządzenia, które emulują klawiaturę) jest dla nich głównym, a często jedynym, sposobem nawigacji.
• Osoby niewidome i niedowidzące: Użytkownicy programów czytających ekran (screen readerów) polegają niemal wyłącznie na klawiaturze do nawigacji, interakcji z elementami i odczytywania treści. Widoczny wskaźnik fokusu i logiczna kolejność tabulacji są dla nich niezbędne.
• Osoby z niepełnosprawnościami poznawczymi: Dla niektórych osób z niepełnosprawnościami poznawczymi, korzystanie z myszy może być trudne ze względu na wymóg precyzyjnych ruchów. Prostsze, liniowe sterowanie klawiaturą może być łatwiejsze do opanowania.
• Użytkownicy bez myszy: Czasami użytkownicy mogą po prostu nie mieć dostępu do myszy (np. zepsuta mysz, urządzenie bez trackpada, przeglądanie na urządzeniach mobilnych z podłączoną klawiaturą).
• „Power userzy”: Nawet osoby bez niepełnosprawności często korzystają ze skrótów klawiaturowych, aby zwiększyć swoją efektywność i szybkość nawigacji.

Zapewnienie pełnej dostępności klawiaturowej jest kluczowe dla stworzenia inkluzywnego środowiska cyfrowego, które nikogo nie wyklucza.

Kryterium sukcesu i wymagania

WCAG 2.1.1 Klawiatura (Poziom A) brzmi następująco:

„Cała funkcjonalność treści może być obsługiwana za pomocą interfejsu klawiatury bez konieczności użycia określonego czasu dla poszczególnych naciśnięć klawiszy, z wyjątkiem sytuacji, gdy podstawowa funkcja nie wymaga klawiatury do działania.”

Kluczowe elementy tego kryterium:

• Cała funkcjonalność: Każda interaktywna funkcja strony (np. linki, przyciski, pola formularzy, menu rozwijane, zakładki, suwaki, odtwarzacze multimediów) musi być dostępna i obsługiwana za pomocą klawiatury.
• Interfejs klawiatury: Oznacza to, że użytkownik musi być w stanie używać klawiszy takich jak Tab, Shift+Tab, Enter, Spacja, klawisze strzałek i Escape do nawigacji i interakcji.
• Bez konieczności użycia określonego czasu: Użytkownik nie może być zmuszony do szybkiego lub precyzyjnego wykonywania sekwencji naciśnięć klawiszy w określonym czasie, aby aktywować funkcję. Wszelkie operacje muszą być tolerancyjne na zmienny czas reakcji użytkownika.
• Wyjątki: Istnieją bardzo rzadkie przypadki, gdy podstawowa funkcja rzeczywiście wymaga wejścia, które zależy od ścieżki ruchu użytkownika, a nie tylko od punktów początkowego i końcowego. Przykładem może być rysowanie odręczne w aplikacji graficznej, gdzie sens ma jedynie ruch myszy/rysika. W większości typowych stron internetowych ten wyjątek nie ma zastosowania.

Praktyczne wskazówki dotyczące zgodności

Aby spełnić kryterium 2.1.1, należy przestrzegać następujących zasad:

1. Widoczny wskaźnik fokusu

• Każdy element interaktywny, który otrzyma fokus klawiatury, musi mieć wyraźnie widoczny wskaźnik (np. obramowanie, cień, zmiana koloru tła). Domyślne wskaźniki przeglądarek są często niewystarczające lub mogą zostać usunięte przez CSS.
• Nie usuwaj domyślnego wskaźnika fokusu (np. `outline: none;`) bez zapewnienia alternatywnego, lepszego wizualnego stylu.

2. Logiczna kolejność tabulacji

• Kolejność, w jakiej klawisz Tab przenosi fokus między elementami interaktywnymi, powinna być logiczna i intuicyjna, zgodna z wizualnym przepływem treści. Zazwyczaj jest to od lewej do prawej, od góry do dołu.
• Unikaj modyfikowania kolejności tabulacji za pomocą atrybutu tabindex o wartościach dodatnich (np. tabindex="1"). Pozwól przeglądarce zarządzać naturalną kolejnością DOM, a tabindex="0" używaj tylko dla niestandardowych elementów interaktywnych, które z natury nie są w kolejności tabulacji.

3. Obsługa wszystkich elementów interaktywnych

• Natywne elementy HTML: Używaj standardowych elementów HTML, takich jak <a> (dla linków), <button> (dla przycisków), <input>, <select>, <textarea> (dla formularzy). Są one domyślnie dostępne z klawiatury.
• Niestandardowe komponenty: Jeśli tworzysz niestandardowe elementy interaktywne (np. niestandardowy rozwijany selektor, zakładki, akordeony), musisz zapewnić im pełną obsługę klawiatury:
  • Nadaj im atrybut tabindex="0", aby mogły otrzymać fokus.
  • Zastosuj odpowiednie role ARIA (np. role="button", role="tab", role="dialog").
  • Obsłuż zdarzenia klawiaturowe: `Enter` lub `Space` do aktywacji (dla przycisków), klawisze strzałek do nawigacji w grupach elementów (np. w menu, listach), `Escape` do zamykania (np. modali, wyskakujących okienek).

4. Brak pułapek klawiaturowych (Keyboard Traps)

• Użytkownik musi mieć możliwość opuszczenia każdego elementu lub komponentu za pomocą klawiatury. Żaden element nie może „uwięzić” fokusu, uniemożliwiając nawigację do innych części strony.
• Dotyczy to szczególnie modali, wyskakujących okienek, widżetów autouzupełniania itp. Upewnij się, że klawisz Escape lub Tab pozwala na zamknięcie lub wyjście z komponentu.

5. Linki „Pomiń do treści” (Skip Links)

• Dla stron z powtarzającymi się nagłówkami lub menu nawigacyjnymi, zaimplementuj „link pominięcia”, który pojawia się na początku strony po otrzymaniu fokusu i pozwala użytkownikowi przeskoczyć bezpośrednio do głównej treści. Zapobiega to konieczności wielokrotnego tabulowania przez te same elementy.

Przykłady prawidłowych i nieprawidłowych implementacji

Prawidłowe implementacje

<button type="button">Kliknij mnie</button>
<a href="#">Przejdź do innej strony</a>

<style>
    .custom-button {
      padding: 10px 20px;
      background-color: #007bff;
      color: white;
      border: none;
      cursor: pointer;
      font-size: 16px;
      border-radius: 4px;
    }
    .custom-button:focus {
      outline: 3px solid #0056b3; /* Wyraźny wskaźnik fokusu */
      outline-offset: 2px;
    }
</style>

<div
  class="custom-button"
  tabindex="0" 
  role="button"
  aria-label="Aktywuj funkcję X"
>
  Aktywuj X
</div>

<script>
  document.querySelector('.custom-button').addEventListener('keydown', function(event) {
    if (event.key === 'Enter' || event.key === ' ') {
      alert('Funkcja X aktywowana!');
      event.preventDefault(); // Zapobiega domyślnemu zachowaniu spacji (np. przewijaniu strony)
    }
  });
  document.querySelector('.custom-button').addEventListener('click', function() {
    alert('Funkcja X aktywowana!');
  });
</script>

<style>
    .skip-link {
        position: absolute;
        top: -40px;
        left: 0;
        background-color: #007bff;
        color: white;
        padding: 8px 12px;
        z-index: 1000;
    }
    .skip-link:focus {
        top: 0;
    }
</style>

<a href="#main-content" class="skip-link">Pomiń do głównej treści</a>
<header>... </header>
<nav>... </nav>
<main id="main-content">
  <h1>Główna treść strony</h1>
  <p>Tutaj znajduje się najważniejsza zawartość.</p>
</main>

Nieprawidłowe implementacje

<style>
    .incorrect-div-button {
      padding: 10px 20px;
      background-color: #dc3545;
      color: white;
      cursor: pointer;
    }
</style>

<div class="incorrect-div-button" onclick="alert('Funkcja aktywowana!');">
  Niedostępny przycisk
</div>

<style>
    button:focus {
      outline: none; /* BŁĄD: Usunięcie wskaźnika fokusu */
    }
</style>

<button type="button">Przycisk bez widocznego fokusu</button>

<!-- Wyobraźmy sobie modal, który otwiera się, ale nie można go zamknąć za pomocą klawisza Escape 
     ani nie można przenieść fokusu poza niego za pomocą klawisza Tab. -->
<div role="dialog" aria-modal="true">
  <h2>Modalna pułapka</h2>
  <p>Ta zawartość jest ważna.</p>
  <!-- Brak przycisku zamykającego dostępnego klawiaturowo lub brak obsługi Esc -->
</div>

Najlepsze praktyki i typowe pułapki

Najlepsze praktyki:

• Preferuj natywne elementy HTML: Zawsze, gdy to możliwe, używaj standardowych elementów HTML (<a>, <button>, <input>), ponieważ zapewniają one wbudowaną dostępność klawiaturową i semantykę.
• Testuj klawiaturą: Regularnie testuj całą stronę, używając wyłącznie klawiatury (Tab, Shift+Tab, Enter, Spacja, Strzałki, Esc). To najskuteczniejszy sposób na wykrycie problemów z dostępnością klawiaturową.
• Zapewnij wyraźny styl fokusu: Projektuj spójne i kontrastowe wskaźniki fokusu, które są łatwe do zauważenia.
• Implementuj linki „Pomiń do treści”: Są one nieocenione dla użytkowników klawiatury na stronach z dużą ilością powtarzalnych elementów nawigacyjnych.
• Używaj ARIA z rozwagą: Atrybuty ARIA są potężnym narzędziem, ale powinny być używane tylko wtedy, gdy natywny HTML nie spełnia wymagań, i zawsze zgodnie z zasadą „No ARIA is better than Bad ARIA”.
• Dokumentuj niestandardowe interakcje: Jeśli masz złożone komponenty wymagające specyficznych interakcji klawiaturowych (np. Ctrl+Strzałka), rozważ umieszczenie krótkich instrukcji dla użytkownika.

Typowe pułapki:

• Usunięcie outline: none; bez zamiennika: To najczęstszy błąd, który całkowicie dezorientuje użytkowników klawiatury.
• Używanie <div> lub <span> jako przycisków/linków bez tabindex i obsługi zdarzeń: Takie elementy nie są dostępne z klawiatury.
• Naruszenie kolejności tabulacji: Manipulowanie tabindex w sposób niezgodny z wizualnym i logicznym przepływem treści.
• Pułapki klawiaturowe: Komponenty, z których użytkownik nie może wyjść za pomocą klawiatury.
• Zależność od zdarzeń myszy: Funkcjonalność aktywowana tylko przez mouseover lub click, ale nie przez odpowiedniki klawiaturowe.
• Brak testowania klawiaturą: Zakładanie, że „to działa z myszą, więc działa z klawiaturą”, co jest często błędne.

Zgodność z WCAG 2.1.1 jest podstawowym krokiem w kierunku budowania dostępnych stron internetowych, które służą wszystkim użytkownikom, niezależnie od ich możliwości.