- Poziom
- A
- Od wersji
- WCAG 2.0
- Pozycje
- 94 / 193
2.4.3 Kolejność fokusu
Gdy ktoś porusza się po stronie klawiszem Tab, fokus musi przechodzić w kolejności zgodnej z sensem i układem strony.
/ Czego wymaga
Osoby korzystające z klawiatury przechodzą od kontrolki do kontrolki po kolei i ta kolejność jest wszystkim, co mają. Jeśli fokus skacze z nagłówka do stopki i z powrotem albo zostaje poza oknem dialogowym, które właśnie się otworzyło, strona przestaje mieć sens. Użytkownicy czytników ekranu nie widzą układu, który tłumaczyłby taki skok. Widzące osoby korzystające z klawiatury i osoby używające powiększenia, które widzą tylko mały wycinek ekranu, gubią miejsce, w którym jest fokus.
Kryterium obowiązuje tam, gdzie po stronie da się poruszać sekwencyjnie, a kolejność wpływa na znaczenie lub obsługę. Kolejność nie musi dokładnie odpowiadać układowi wizualnemu. Ma zachowywać sens i możliwość obsługi, a poprawnych kolejności może być więcej niż jedna. Błędem jest kolejność, która rozdziela powiązane kontrolki, prowadzi użytkownika przez stronę nie po kolei albo zostawia fokus za oknem dialogowym lub menu, które właśnie otworzyło się nad stroną.
/ Jak strony go nie spełniają
- Dodatnie wartości tabindex, na przykład tabindex="5", wyciągają część kontrolek na początek kolejności, przed wszystko inne.
- Właściwość CSS order, flex-direction: row-reverse albo pozycjonowanie absolutne pokazuje kontrolki w jednej kolejności, a DOM zawiera je w innej.
- Okno modalne się otwiera, ale fokus zostaje na stronie pod nim, więc Tab dalej chodzi po treści, której użytkownik nie widzi.
- Okno dialogowe albo menu się zamyka, a fokus spada na początek dokumentu, zamiast wrócić do przycisku, który je otworzył.
- Treść wstawiana skryptem, na przykład rozwinięty panel, trafia na koniec DOM, daleko od kontrolki, która ją odsłoniła.
/ Jak sprawdzić samodzielnie
- Przejdź klawiszem Tab od góry strony do dołu i obserwuj wskaźnik fokusu. Powinien poruszać się tak, jak czyta się stronę, bez zawracania.
- Wróć w górę klawiszami Shift+Tab i sprawdź, czy droga powrotna jest lustrzanym odbiciem drogi w przód.
- Otwórz z klawiatury każde okno dialogowe, menu i rozwijany panel. Fokus powinien wejść do nowej treści, zostać w niej, dopóki okno modalne jest otwarte, i po zamknięciu wrócić do elementu, który je otworzył.
- Poszukaj w kodzie wartości tabindex większych od 0. W konsoli DevTools polecenie document.querySelectorAll('[tabindex]') wypisze każdy element, który ustawia ten atrybut.
- Przeczytaj kolejność DOM w panelu Elements i porównaj ją z układem wizualnym.
/ Jak to naprawić
- Usuń każdy dodatni tabindex. Użyj tabindex="0", by dodać element do naturalnej kolejności, i tabindex="-1" dla elementów, które dostają fokus tylko ze skryptu.
- Ułóż DOM tak, by odpowiadał kolejności wizualnej, zamiast przestawiać elementy właściwością CSS order albo pozycjonowaniem absolutnym.
- Po otwarciu okna modalnego przenieś do niego fokus. Natywny element dialog otwierany przez showModal() robi to sam, a atrybut inert nie wpuszcza fokusu do reszty strony.
- Po zamknięciu okna albo menu wywołaj focus() na kontrolce, która je otworzyła.
- Wstawiaj odsłanianą treść w DOM bezpośrednio za elementem, który ją wywołuje.
/ Co sprawdza nasz skaner
dialog-focus-outside zgłasza okno dialogowe, które jest otwarte w chwili sprawdzania strony, a fokus jest poza nim. focus-order-jumps porównuje położenie każdego zatrzymania tabulatora z poprzednim i zgłasza fokus, który wraca w górę strony, nie przesuwając się w prawo, z pominięciem elementów przypiętych. Trzy pokrywające się reguły zgłaszają tabindex większy od 0. Żaden test nie oceni, czy kolejność ma sens, i żaden nie otwiera zamkniętego okna.
/ Kto je łamie, według naszych pomiarów
Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.
/ Pytania o to kryterium
Czy kolejność fokusu musi odpowiadać kolejności wizualnej?
Nie co do joty. Kryterium wymaga kolejności, która zachowuje sens i możliwość obsługi, a takich kolejności może być kilka. W praktyce użytkownicy oczekują układu czytanego od góry do dołu w tej samej kolejności, w jakiej zapisano go w DOM, a rozjazd między DOM a ekranem jest najczęstszym powodem, dla którego kolejność przestaje mieć sens.
Czy dodatni tabindex jest błędem WCAG?
Nie automatycznie. HTML dopuszcza wartość dodatnią i jeśli wynikowa kolejność nadal zachowuje sens, strona spełnia kryterium. Kłopot w tym, że elementy z dodatnimi wartościami wyprzedzają wszystkie pozostałe kontrolki na stronie, więc wystarczy jeden, żeby przestawić kolejność, a porządek psuje się przy każdej zmianie strony. W3C opisuje powstały w ten sposób nieład jako błąd F44.
Gdzie powinien trafić fokus po otwarciu i zamknięciu okna dialogowego?
Gdy otwiera się okno modalne, fokus powinien przejść do niego: na pierwszą kontrolkę, nagłówek albo samo okno, a Tab powinien zostawać w nim, dopóki jest otwarte. Po zamknięciu fokus powinien wrócić do kontrolki, która okno otworzyła. Zostawienie fokusu na stronie pod spodem każe osobom korzystającym z klawiatury chodzić po treści, której nie widzą.