- Zapewnię wierne tłumaczenie znaczenia, tonu i stylu. - Zachowam wszystkie oryginalne podziały wierszy i akapity. - Utrzymam liczby, symbole i formatowanie dokładnie tak jak w oryginale. - Zastosuję odpowiedni rejestr językowy zgodny z tekstem źródłowym. - Sprawdzę końcowy tekst pod kątem zgodności z oryginałem i poprawię ewentualne nieścisłości. Dostępność z użyciem klawiatury jest jednym z najważniejszych — i najbardziej zaniedbywanych — aspektów dostępności stron internetowych, a badania pokazują, że 85% witryn wciąż nie zapewnia odpowiedniej nawigacji za pomocą klawiatury. Ten przewodnik omawia wymagania WCAG, typowe schematy błędów oraz praktyczne techniki na poziomie kodu, które pomagają deweloperom i osobom odpowiedzialnym za zgodność tworzyć naprawdę dostępne z poziomu klawiatury doświadczenia.

Wyobraź sobie, że próbujesz wypełnić podanie o pracę, zarezerwować wizytę lekarską albo dokończyć zakup online — i twoja mysz nie działa. Nie jest zepsuta, po prostu nie ma znaczenia: poruszasz się wyłącznie za pomocą klawiszy Tab, Enter i strzałek. Dla milionów osób na całym świecie to nie jest eksperyment myślowy. Osoby z niepełnosprawnościami ruchowymi, urazami przeciążeniowymi, z niepełnosprawnością wzroku oraz osoby korzystające z czytników ekranu polegają na nawigacji klawiaturą jako swoim podstawowym interfejsie z siecią. Tymczasem badania konsekwentnie pokazują, że 85% stron internetowych nie zapewnia odpowiedniej nawigacji klawiaturą, odcinając te osoby od podstawowych zadań cyfrowych każdego dnia. Jeśli twoja strona należy do tej większości, ten przewodnik jest dla ciebie.

Kto polega na nawigacji klawiaturą — i dlaczego ma to większe znaczenie, niż myślisz

Dostępność z poziomu klawiatury nie jest niszową kwestią dla małej grupy użytkowników. Grupa osób, które jej potrzebują, jest szersza i bardziej zróżnicowana, niż większość deweloperów sobie uświadamia. Osoby z niepełnosprawnościami fizycznymi, które nie mogą używać myszy, osoby niewidome, które nie widzą wskaźnika myszy na ekranie, oraz osoby z przewlekłymi schorzeniami, takimi jak urazy przeciążeniowe, które powinny ograniczać użycie myszy — wszystkie one polegają na nawigacji klawiaturą jako swojej bramie do internetu. Poza niepełnosprawnością, wielu zaawansowanych użytkowników — deweloperzy, pisarze, osoby wprowadzające dane — preferuje skróty klawiaturowe ze względu na szybkość i efektywność.

Użytkownicy czytników ekranu stanowią kolejną dużą grupę. Czytniki ekranu interpretują i odczytują elementy strony na podstawie fokusu i struktury semantycznej, a użytkownicy poruszają się po treści za pomocą skrótów klawiaturowych. Jeśli strona nie utrzymuje fokusu klawiatury lub nie wspiera logicznej kolejności fokusu, nawigacja z czytnikiem ekranu całkowicie się załamuje. Oprogramowanie rozpoznawania mowy, takie jak Dragon NaturallySpeaking, również generuje zdarzenia klawiaturowe, co oznacza, że słabe wsparcie dla klawiatury psuje także przeglądanie sterowane głosem.

Argument biznesowy jest równie przekonujący. Według dostępnych danych osoby z niepełnosprawnościami w USA dysponują niemal pół biliona dolarów dochodu rozporządzalnego. Gdy twoja strona nie jest dostępna z poziomu klawiatury, aktywnie odpychasz znaczną część tego rynku. Ryzyko prawne jest również realne: dostępność klawiatury jest kluczowa dla zgodności z WCAG, które stanowią punkt odniesienia dla zgodności z ADA, Section 508, European Accessibility Act i EN 301 549 na całym świecie. Same pułapki klawiaturowe — sytuacje, w których użytkownik utknie w elemencie strony bez możliwości wyjścia — są wskazywane jako oczywiste naruszenia WCAG, które pojawiały się w pozwach dotyczących dostępności.

Być może najbardziej wymowne jest to, że: 71% użytkowników z niepełnosprawnościami po prostu porzuci stronę, którą uzna za trudną w obsłudze. Nie skarżą się. Odchodzą. A ponieważ problemy z dostępnością klawiatury mają tendencję do skupiania się wokół najbardziej krytycznych punktów interakcji — formularzy, modali, menu nawigacyjnych i procesów zakupowych — szkody uderzają bezpośrednio w twoje współczynniki konwersji.

Ramy WCAG: czego tak naprawdę wymagają zasady

Web Content Accessibility Guidelines (WCAG) organizują wymagania dotyczące klawiatury głównie w ramach wytycznej 2.1 — „Zapewnij dostępność wszystkich funkcji z poziomu klawiatury”. Zrozumienie, co jest, a co nie jest wymagane, to pierwszy krok do zgodności. WCAG 2.2, które stało się oficjalnym standardem W3C 5 października 2023 r. i dodało dziewięć nowych kryteriów sukcesu do istniejących ram, jest obecnie zalecanym standardem dla ADA, Section 508 i European Accessibility Act.

Kluczowe kryteria sukcesu związane z klawiaturą, które musisz znać, to:

SC 2.1.1 Keyboard (poziom A): Cała funkcjonalność musi być obsługiwana za pomocą interfejsu klawiatury bez konieczności zachowania określonego czasu dla pojedynczych naciśnięć klawiszy, z wyjątkiem sytuacji, gdy dana funkcja wymaga wprowadzania zależnego od ścieżki (jak rysowanie odręczne). To jest poziom bazowy — każdy element interaktywny musi być osiągalny i obsługiwalny z klawiatury.
SC 2.1.2 No Keyboard Trap (poziom A): Jeśli fokus klawiatury można przenieść na komponent za pomocą klawiatury, fokus musi dać się również przenieść z niego, używając wyłącznie klawiatury. Jeśli do wyjścia wymagany jest niestandardowy sposób, użytkownicy muszą zostać o nim poinformowani. Pułapki klawiaturowe są absolutną blokadą dla użytkowników klawiatury.
SC 2.4.3 Focus Order (poziom A): Jeśli po stronie można nawigować sekwencyjnie, kolejność fokusu musi zachowywać znaczenie i możliwość obsługi. Logiczna, przewidywalna kolejność tabulacji jest niepodlegająca negocjacjom.
SC 2.4.7 Focus Visible (poziom AA): Każdy interfejs użytkownika obsługiwany z klawiatury musi mieć tryb, w którym wskaźnik fokusu klawiatury jest widoczny. Użytkownicy muszą zawsze widzieć, gdzie się znajdują na stronie.
SC 2.4.11 Focus Not Obscured (Minimum) (poziom AA — nowe w WCAG 2.2): Gdy element, na który można przenieść fokus klawiatury, otrzymuje fokus, nie może być całkowicie zasłonięty przez treści stworzone przez autora, takie jak przyklejone nagłówki czy banery cookie.
SC 2.4.12 Focus Not Obscured (Enhanced) (poziom AAA): Bardziej rygorystyczna wersja wymagająca, aby żadna część elementu z fokusem nie była zasłonięta przez treści stworzone przez autora.
SC 2.5.8 Target Size (Minimum) (poziom AA — nowe w WCAG 2.2): Interaktywne cele muszą mieć co najmniej 24x24 piksele CSS, co zmniejsza liczbę błędów u użytkowników z ograniczoną kontrolą motoryczną.
SC 2.5.7 Dragging Movements (poziom AA — nowe w WCAG 2.2): Każda funkcjonalność wymagająca przeciągania musi mieć alternatywę obsługiwaną pojedynczym wskaźnikiem — co pośrednio pomaga użytkownikom klawiatury, którzy nie mogą wykonywać operacji przeciągania.

WCAG 2.2 jest w pełni wstecznie kompatybilne z WCAG 2.1 — dodaje kryteria, ale żadnego nie usuwa (z wyjątkiem obecnie przestarzałego 4.1.1 Parsing). Jeśli twoja strona już spełnia WCAG 2.1 AA, musisz wdrożyć jedynie sześć nowych kryteriów poziomu AA. W kontekście dostępności klawiatury najważniejszym nowym dodatkiem jest zapewnienie, że elementy z fokusem nigdy nie są w pełni zasłonięte przez „meble” strony typu sticky — powszechny problem w rzeczywistych projektach, którego WCAG 2.1 nie adresowało wprost.

Zasada WCAG jest prosta do sformułowania, wymagająca we wdrożeniu: jeśli całą funkcjonalność można zrealizować za pomocą klawiatury, mogą z niej skorzystać użytkownicy klawiatury, osoby używające sterowania głosem, klawiatur ekranowych oraz szeroka gama technologii asystujących generujących symulowane naciśnięcia klawiszy. Żaden inny rodzaj wejścia nie ma takiej elastyczności ani nie jest tak powszechnie wspierany.

Najczęstsze błędy w dostępności klawiatury (i co je powoduje)

Ręczne audyty konsekwentnie pokazują, że problemy z dostępnością klawiatury należą do najczęstszych i najbardziej destrukcyjnych barier dostępności w sieci. W jednym zakrojonym na szeroką skalę badaniu 54% stron z formularzami miało problemy z dostępnością klawiatury wpływające na krytyczne działania użytkownika, takie jak przechodzenie Tabem między polami formularza, zamykanie wyskakujących okienek czy naciskanie przycisków Submit. Testerzy byli często zmuszeni porzucać koszyki zakupowe lub odświeżać strony po utknięciu na elementach, których nie mogli obsłużyć wyłącznie klawiaturą.

Przyczyny źródłowe skupiają się wokół kilku powtarzających się wzorców, którym warto przyjrzeć się dokładniej.

1. Obsługa zdarzeń tylko myszą. Używanie onmouseover, onmouseout lub onclick na elementach <div> bez równoważnych obsług zdarzeń klawiatury jest jednym z najczęstszych błędów. <div> z obsługą kliknięcia nie jest przyciskiem — nie ma domyślnej roli klawiaturowej, nie otrzyma fokusu przez Tab i nie zareaguje na Enter ani Spację. Dodanie role='button' przez ARIA pomaga czytnikom ekranu, ale nadal wymaga ręcznego dodania tabindex='0', obsługi onkeydown i onkeyup. Właściwą poprawką jest niemal zawsze użycie prawdziwego elementu <button>.

2. Wyłączone obrysy fokusu. Jednym z najbardziej rozpowszechnionych problemów jest reguła CSS outline: none lub outline: 0 zastosowana globalnie lub do elementów z fokusem. Projektanci często usuwają domyślny obrys fokusu przeglądarki, ponieważ wygląda nieestetycznie w niektórych motywach. W efekcie użytkownicy klawiatury nie mają pojęcia, gdzie znajdują się na stronie. To bezpośrednie naruszenie WCAG SC 2.4.7 i jeden z najłatwiejszych do stworzenia — i naprawienia — problemów.

3. Pułapki klawiaturowe w modalach, widżetach i iframe’ach. Okna modalne, które nie ograniczają poprawnie fokusu, pozwalają Tabowi przechodzić dalej poza modal do zasłoniętej treści w tle, co sprawia, że modal staje się niemożliwy do zamknięcia z klawiatury. Widżety firm trzecich — narzędzia czatu, odtwarzacze wideo, selektory dat, osadzone mapy — są na to szczególnie podatne, ponieważ ich wewnętrzna obsługa klawiatury jest dla ciebie nieprzejrzysta.

4. Nielogiczna kolejność tabulacji. Domyślna kolejność nawigacji klawiaturą jest determinowana przez kolejność w drzewie DOM. Gdy deweloperzy używają CSS Grid, Flexboxa lub pozycjonowania CSS do zmiany kolejności prezentacji wizualnej niezależnie od kolejności w DOM, fokus Tab przeskakuje po ekranie w sposób całkowicie oderwany od układu wizualnego. Dodatnie wartości tabindex (np. tabindex='2') używane do wymuszenia konkretnej kolejności znacząco pogarszają ten problem w większości rzeczywistych przypadków.

5. Rozwijane menu tylko na hover. Menu nawigacyjne, które otwierają się wyłącznie po najechaniu myszą, bez wyzwalacza klawiaturowego, pozostawiają użytkowników klawiatury na lodzie. To niezwykle częsty wzorzec w menu rozwijanych opartych wyłącznie na CSS, gdzie podmenu pojawiają się przy :hover, ale nigdy nie są udostępnione nawigacji opartej na fokusie.

6. Brak przywrócenia fokusu po interakcjach dynamicznych. Gdy modal, panel wysuwany lub flyout zostanie zamknięty, fokus musi wrócić do elementu, który go wywołał. Jeśli tak się nie dzieje — jeśli ląduje na górze strony lub znika w nieokreślonym miejscu — użytkownik całkowicie traci orientację. Dynamiczne aplikacje jednostronicowe są na to szczególnie narażone.

Budowanie dostępności klawiatury we właściwy sposób: praktyczne wdrożenie

Mając w pamięci wzorce błędów, tak wygląda poprawne wdrożenie w najważniejszych obszarach typowej strony internetowej.

Najpierw używaj semantycznego HTML

Natywne elementy HTML są domyślnie dostępne z poziomu klawiatury. Linki (<a href>), przyciski (<button>), pola formularzy, selecty i textarea biorą udział w kolejności tabulacji, reagują na standardowe naciśnięcia klawiszy i komunikują swoją rolę technologiom asystującym — wszystko to bez ani jednej dodatkowej linijki JavaScriptu. Element <button> automatycznie ma poprawną rolę, jest dostępny z klawiatury, reaguje na Enter i Spację oraz ma wbudowane poprawne zarządzanie fokusem. Dodanie role='button' do <div> nadaje poprawną rolę, ale nadal wymaga ręcznej implementacji obsługi klawiatury i zarządzania fokusem. Zawsze preferuj semantyczny HTML.

<!-- Unikaj: niesemantyczny div udający przycisk -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Poprawnie: natywny element button -->
<button type='button' onclick='doSomething()'>Submit</button>

Napraw wskaźniki fokusu

Zamiast usuwać domyślny obrys przeglądarki, nadpisz go stylizowanym, własnym wskaźnikiem fokusu. WCAG 2.2 SC 2.4.11 wymaga, aby obszar wskaźnika fokusu był co najmniej tak duży, jak obwód nieaktywnego komponentu o grubości 2 pikseli CSS, z kontrastem co najmniej 3:1 między stanem z fokusem i bez. Używaj pseudoklasy :focus-visible zamiast :focus, aby pokazywać wskaźniki fokusu tylko dla użytkowników klawiatury, bez wpływu na estetykę interakcji myszą.

/* Usuń domyślny obrys tylko po to, by zastąpić go lepszym wskaźnikiem */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Takie podejście daje pełną kontrolę wizualną przy zachowaniu zgodności z WCAG. Upewnij się, że kolor fokusu ma wystarczający kontrast zarówno względem tła, jak i samego komponentu, szczególnie na stronach w ciemnych motywach lub nad obrazami.

Zarządzaj fokusem w interakcjach dynamicznych

Gdy treść zmienia się dynamicznie — otwarcie modala, załadowanie nowej treści, usunięcie elementu — musisz programowo zarządzać fokusem. Przy otwieraniu modala przenieś fokus na pierwszy element, który może go otrzymać, wewnątrz modala. Przy zamykaniu przywróć fokus do elementu wyzwalającego. Używaj do tego metody JavaScript .focus(). Aby poprawnie „uwięzić” fokus wewnątrz modala, przechwytuj zdarzenia klawiszy Tab i Shift+Tab i cykluj fokus między pierwszym i ostatnim elementem z fokusem w obrębie dialogu.

// Otwieranie modala: przenieś fokus do środka
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Zamykanie modala: przywróć fokus do wyzwalacza
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Wdroż linki pomijania nawigacji

Użytkownicy klawiatury muszą naciskać Tab, aby przejść przez każdy element interaktywny przed główną treścią — nagłówki, menu nawigacyjne, paski wyszukiwania — przy każdym ładowaniu strony. Linki pomijania są rozwiązaniem: wizualnie ukryty link na samym szczycie strony, który staje się widoczny po uzyskaniu fokusu i przenosi użytkowników bezpośrednio do obszaru głównej treści. Są one wymaganiem WCAG na poziomie A i jednym z najbardziej efektywnych „szybkich zwycięstw”.

<!-- Umieść jako pierwszy element w <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Docelowy znacznik kotwicy na kontenerze głównej treści -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Pokazuj link pomijania tylko przy fokusie z klawiatury */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Buduj dostępne menu nawigacyjne

Menu nawigacyjne z rozwijanymi podmenu wymagają szczególnej uwagi. Poprawny wzorzec interakcji klawiaturą dla menu nawigacyjnego jest następujący: Tab przechodzi między elementami najwyższego poziomu; Enter lub Spacja otwiera podmenu; klawisze strzałek nawigują w obrębie podmenu; Escape zamyka podmenu i przywraca fokus do wyzwalacza. Używaj atrybutów ARIA do komunikowania stanu. Menu, które otwierają się wyłącznie przy najechaniu myszą, bez wyzwalacza klawiaturowego, są niedostępne i muszą zostać poprawione.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Używaj aria-expanded='false' i aria-expanded='true' przełączanych za pomocą JavaScriptu, aby komunikować stan otwarcia/zamknięcia. Używaj aria-haspopup='true', aby zasygnalizować, że aktywacja przycisku ujawnia podmenu. Upewnij się, że klawisz Escape zamyka podmenu i przywraca fokus do przycisku wyzwalającego.

Poprawne użycie tabindex

Istnieją trzy znaczące wartości tabindex i każda ma odrębne zastosowanie. tabindex='0' dodaje element nieinteraktywny do naturalnej kolejności tabulacji — używaj tego, gdy naprawdę potrzebujesz, aby element, który normalnie nie otrzymuje fokusu (jak kontener niestandardowego widżetu), mógł go otrzymać. tabindex='-1' usuwa element z kolejności tabulacji, ale pozwala mu otrzymać fokus programowo za pomocą .focus() — to kluczowe dla celów modali i miejsc docelowych linków pomijania. Dodatnie wartości tabindex (jak tabindex='1' czy tabindex='5') nadpisują naturalną kolejność w sposób, który niemal zawsze powoduje więcej problemów niż rozwiązuje; całkowicie ich unikaj i zamiast tego popraw kolejność w DOM.

ARIA: potężne narzędzie, nie cudowny lek

Atrybuty Accessible Rich Internet Applications (ARIA) rozszerzają semantykę HTML, aby pomóc technologiom asystującym zrozumieć komponenty niestandardowe, których natywny HTML nie obejmuje — zakładki, akordeony, widoki drzewiaste, karuzele, pola kombi. Atrybuty ARIA mogą dostarczać dodatkowego kontekstu, ale powinny uzupełniać — a nie zastępować — semantyczny HTML. Częstym i niebezpiecznym błędem jest sięganie po ARIA, zanim rozważy się, czy natywny element HTML nie mógłby spełnić tej samej roli.

Pierwsza zasada ARIA brzmi: nie używaj ARIA, jeśli natywny element HTML lub atrybut może wykonać tę samą pracę. Druga zasada: brak ARIA jest lepszy niż zła ARIA. Niepoprawne oznaczenie ARIA — na przykład zastosowanie role='menu' bez właściwej hierarchii dzieci role='menuitem' lub użycie aria-hidden='true' na elemencie, który otrzymuje fokus — może aktywnie szkodzić dostępności zamiast jej pomagać.

Gdy ARIA jest rzeczywiście potrzebna, najczęściej użyteczne atrybuty dla interakcji klawiaturą to: aria-expanded do komunikowania stanu otwarcia/zamknięcia elementów zwijanych; aria-controls do powiązania wyzwalacza z treścią, którą kontroluje; aria-haspopup do sygnalizowania, że przycisk otwiera menu lub dialog; aria-modal='true' na elementach dialogowych, aby zasygnalizować, że treść w tle jest nieaktywna; oraz regiony aria-live (polite dla komunikatów statusu, assertive dla pilnych alertów), aby ogłaszać dynamiczne zmiany treści użytkownikom czytników ekranu bez przenoszenia fokusu.

Jedna subtelna, ale ważna kwestia: czytniki ekranu, takie jak NVDA i JAWS, używają własnych skrótów klawiaturowych — na przykład naciśnięcie H w NVDA przenosi użytkownika do kolejnego nagłówka na stronie. Deweloperzy powinni unikać tworzenia niestandardowych skrótów aplikacji, które kolidują z tymi poleceniami technologii asystujących.

Testowanie dostępności klawiatury

Najskuteczniejszy test, jaki możesz wykonać od razu, nie wymaga żadnych narzędzi: odłącz mysz i nawiguj po swojej stronie wyłącznie za pomocą klawiatury. Naciskaj Tab, aby przechodzić do przodu między elementami interaktywnymi, Shift+Tab, aby cofać się, Enter, aby aktywować linki i przyciski, Spację, aby przełączać pola wyboru i aktywować przyciski, Escape, aby zamykać modale i menu, oraz klawisze strzałek, aby nawigować w obrębie komponentów. Zadaj sobie pytania: Czy możesz dotrzeć do każdego elementu interaktywnego? Czy zawsze widzisz, gdzie się znajdujesz? Czy możesz ukończyć każdą krytyczną ścieżkę użytkownika bez utknięcia?

Narzędzia automatyczne mogą wychwycić znaczącą część problemów z dostępnością klawiatury — szczególnie brakujące etykiety, puste przyciski i niektóre problemy z zarządzaniem fokusem. Narzędzia takie jak axe DevTools, WAVE i Lighthouse są wartościowym pierwszym krokiem. Jednak narzędzia automatyczne wykrywają tylko około 40% problemów WCAG. Widoczność fokusu, logiczna kolejność fokusu i poprawne zarządzanie stanem ARIA wymagają ręcznej oceny przez człowieka. Dla najbardziej dokładnej oceny połącz automatyczne skanowanie z ręcznym testowaniem wyłącznie klawiaturą w wielu przeglądarkach oraz uwzględnij testy z czytnikami ekranu NVDA (Windows), JAWS (Windows) lub VoiceOver (macOS/iOS).

Kilka konkretnych scenariuszy, które należy testować ręcznie za każdym razem, gdy wdrażasz nowy komponent lub stronę: Czy możesz otworzyć i zamknąć każdy dropdown, modal i akordeon, używając wyłącznie Tab, Enter i Escape? Gdy modal się zamyka, czy fokus wraca do wyzwalacza? Czy link pomijania nawigacji pojawia się i działa przy pierwszym naciśnięciu Tab? Czy są miejsca, w których fokus Tab znika w elemencie bez widocznego wskaźnika? Czy przyklejone nagłówki lub banery cookie zasłaniają elementy z fokusem, gdy przechodzisz po stronie Tabem?

Dla zespołów budujących biblioteki komponentów WAI-ARIA Authoring Practices Guide (APG) publikowany przez W3C jest ostatecznym punktem odniesienia dla wzorców interakcji klawiaturą dla dziesiątek typów widżetów — od akordeonów i karuzel po selektory dat i widoki drzewiaste. Każdy wzorzec dokładnie określa, które klawisze muszą być obsługiwane i jakie powinno być oczekiwane zachowanie.

Przyklejone nagłówki, stałe stopki i zasłanianie fokusu

Jednym z najbardziej praktycznie istotnych nowych wymagań w WCAG 2.2 jest kryterium sukcesu 2.4.11: Focus Not Obscured. Dotyczy ono problemu tak powszechnego, że praktycznie definiuje współczesny internet: przyklejone paski nawigacyjne, banery zgody na cookies, widżety czatu i stałe stopki, które leżą na wierzchu treści strony. Gdy użytkownik klawiatury przechodzi Tabem do elementu, który przewinął się za jedną z tych stałych warstw, element z fokusem staje się niewidoczny — użytkownik nie widzi, z czym wchodzi w interakcję.

Poprawka wymaga współpracy CSS i JavaScriptu. Gdy element otrzymuje fokus, przeglądarka musi przewinąć go do widocznego obszaru. Ale przyklejony nagłówek z position: fixed i wysokością, powiedzmy, 80px oznacza, że górne 80px widoku jest trwale zajęte. Wyrównanie przewijania w CSS może to skompensować:

html {
  /* Wysokość przyklejonego nagłówka + niewielki margines */
  scroll-padding-top: 96px;
}

To informuje przeglądarkę, aby skorygowała zakotwiczenie przewijania o podaną wartość, tak aby przy automatycznym przewijaniu elementu z fokusem do widoku uwzględniała stały nagłówek. Możesz również potrzebować odpowiedniego scroll-padding-bottom, jeśli masz przyklejoną stopkę. W przypadku banerów cookie lub nakładek, które pojawiają się i znikają, upewnij się, że mają wartości z-index, które nie zasłaniają elementu z fokusem, lub dynamicznie dostosowuj wyrównanie przewijania, gdy baner jest widoczny.

Najważniejsze wnioski

Semantyczny HTML to twój najlepszy pierwszy krok. Natywne elementy, takie jak <button>, <a> i kontrolki formularzy, są domyślnie dostępne z poziomu klawiatury. Każdy niestandardowy widżet zbudowany z divów kosztuje cię dostępność, którą następnie musisz ręcznie odtwarzać za pomocą ARIA i JavaScriptu.
Nigdy nie wyłączaj wskaźników fokusu bez ich zastąpienia. Globalna reguła outline: none to jedna z najbardziej szkodliwych rzeczy, jakie możesz umieścić w arkuszu stylów. Używaj :focus-visible, aby zapewnić stylizowany, wysokokontrastowy pierścień fokusu, który spełnia minimalne wymagania WCAG 2.2 dotyczące rozmiaru i kontrastu.
Zarządzaj fokusem programowo dla każdej dynamicznej interakcji. Modale, panele wysuwane, powiadomienia typu toast i dynamiczne zmiany treści wymagają wyraźnego zarządzania fokusem — przenoszenia fokusu do środka i przywracania go po zamknięciu. Bez tego użytkownicy klawiatury tracą orientację za każdym razem, gdy interfejs się zmienia.
Dodaj link pomijania nawigacji na górze każdej strony. Wymaga to mniej niż 20 linii kodu i dramatycznie poprawia doświadczenie użytkowników klawiatury, którzy w przeciwnym razie musieliby przechodzić Tabem przez cały nagłówek i nawigację przy każdym ładowaniu strony.
Testuj klawiaturą przed wdrożeniem. Narzędzia automatyczne wychwytują tylko część problemów z dostępnością klawiatury. Dziesięciominutowy przegląd klawiaturą najważniejszych ścieżek użytkownika ujawni realne blokery, których żaden skaner nie wykryje — i może zostać wykonany przez dowolnego dewelopera w zespole bez specjalistycznego szkolenia.

Dostępność z klawiatury: jak sprawić, by Twoja strona była w pełni nawigowalna za pomocą klawiatury