- Poziom
- A
- Od wersji
- WCAG 2.0
3.2.1 Po otrzymaniu fokusu
Przeniesienie fokusu na element, tabulatorem albo kliknięciem, nie może samo z siebie otwierać okna, wysyłać formularza, ładować strony ani przerzucać fokusu gdzie indziej.
/ Czego wymaga
Otrzymanie fokusu to sposób, w jaki użytkownik klawiatury albo czytnika ekranu dociera do kontrolki, zanim zdecyduje, co z nią zrobić. Kryterium mówi, że gdy dowolny komponent interfejsu otrzymuje fokus, samo to nie może zapoczątkować zmiany kontekstu. Jako przykłady W3C podaje formularze wysyłane przy otrzymaniu fokusu, nowe okna otwierane przy otrzymaniu fokusu i fokus przenoszony dalej na inny komponent. Zmiana kontekstu to poważna zmiana: nowa strona, nowe okno, fokus przeniesiony w inne miejsce albo treść przebudowana tak, że strona znaczy coś innego. Osoby, które przechodzą po stronie tabulatorem, oraz osoby korzystające z powiększenia lub czytnika ekranu gubią się, gdy tak się dzieje.
Fokus może trafić na element z klawiatury albo po kliknięciu w pole; najechanie kursorem nie przenosi fokusu, chyba że robi to skrypt. Kliknięcie przycisku jednocześnie daje mu fokus i go aktywuje, a aktywacja może zmienić kontekst i jest to dozwolone. Zmiana treści, która nie jest zmianą kontekstu, na przykład wskazówka pojawiająca się pod polem albo menu rozwijane, gdy fokus zostaje na miejscu, spełnia kryterium. Kryterium nie ma wyjątków i w odróżnieniu od 3.2.2 Podczas wprowadzania danych nie daje wyjścia w postaci wcześniejszego uprzedzenia.
/ Jak strony go nie spełniają
- Okno pomocy otwiera się za każdym razem, gdy pole otrzymuje fokus, i zabiera fokus ze sobą, więc użytkownik klawiatury nigdy nie przejdzie tabulatorem dalej.
- Link albo przycisk wywołuje this.blur() w obsłudze onfocus, żeby ukryć obramowanie fokusu, i w ten sposób zrzuca fokus z elementu.
- Przejście tabulatorem na przycisk „Gotowe” wysyła formularz i ładuje następny ekran, choć przycisk nie został naciśnięty.
- Okno wyskakujące otwiera się, gdy link w nawigacji otrzymuje fokus.
- Ustawienie fokusu w polu wyszukiwania w nagłówku przenosi na osobną stronę wyszukiwania, zanim cokolwiek zostanie wpisane.
/ Jak sprawdzić samodzielnie
- Zacznij od góry strony i przechodź tabulatorem przez wszystkie elementy, nie naciskając Enter ani spacji. Obserwuj, czy pojawiają się nowe okna, ładują się strony, wysyłają formularze albo fokus przeskakuje tam, gdzie go nie posłano.
- Powtórz to klawiszami Shift+Tab i kliknij myszą w każde pole tekstowe, bo fokus, który trafia na element ze wskaźnika, też się liczy.
- Otwórz własne widżety, takie jak menu, kalendarze i listy z podpowiedziami, samym fokusem. Wszystko, co się pojawia, jest w porządku, o ile fokus zostaje tam, gdzie był, a strona zachowuje znaczenie.
- W narzędziach deweloperskich przeszukaj skrypty pod kątem obsługi zdarzeń focus i focusin oraz atrybutów onfocus, które wywołują submit(), window.open() albo blur() lub ustawiają location.
- Przejdź stronę jeszcze raz z czytnikiem ekranu, takim jak NVDA, i zanotuj każde miejsce, w którym komunikat przeskakuje do innej części strony.
/ Jak to naprawić
- Zmiany kontekstu wywołuj aktywacją, czyli zdarzeniem click na przycisku albo linku, nigdy zdarzeniem focus lub focusin.
- Usuń wywołania blur() z obsługi fokusu, a wskaźnik fokusu stylizuj przez :focus-visible, zamiast odbierać fokus.
- Pomoc do pola pokazuj na miejscu, jako tekst pod nim powiązany przez aria-describedby, zamiast otwierać okno dialogowe, gdy pole otrzymuje fokus.
- Nowe okna otwieraj tylko z linku albo przycisku, który użytkownik aktywuje.
- Jeśli pole wyszukiwania prowadzi do pełnej strony wyszukiwania, przechodź na nią po wysłaniu zapytania, a nie po ustawieniu fokusu w polu.
/ Co sprawdza nasz skaner
W naszym skanie żadna reguła nie jest przypisana do 3.2.1. Silnik renderujący ustawia fokus kolejno na elementach, gdy mierzy 2.4.7 Widoczny fokus, ale nie zapisuje, co to ustawienie spowodowało, a element, który nie chce utrzymać fokusu, pomija jako nieobsługujący fokusu, zamiast go zgłosić. Test HTML_CodeSniffer dla 3.2.1 zgłasza tylko uwagę, którą skan odrzuca. Przejście strony tabulatorem i ocena każdego skutku należą do audytu ręcznego.
/ Kto je łamie, według naszych pomiarów
Cotygodniowy indeks nie ma danych dla tego kryterium, bo żaden test uruchamiany przez skan witryny go nie sprawdza. Ocenia je człowiek i do tego służy audyt ręczny.
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
Czym różnią się kryteria 3.2.1 Po otrzymaniu fokusu i 3.2.2 Podczas wprowadzania danych?
3.2.1 dotyczy komponentu, który otrzymuje fokus. 3.2.2 dotyczy zmiany jego ustawienia, na przykład wybrania opcji albo zaznaczenia pola. Podczas wprowadzania danych zmiana kontekstu jest dozwolona, jeśli użytkownik został o niej poinformowany, zanim użył kontrolki. Po otrzymaniu fokusu nie ma takiego zastrzeżenia, więc ustawienie fokusu na komponencie nigdy nie może wywołać zmiany kontekstu.
Czy menu albo podpowiedź może się otworzyć, gdy element otrzymuje fokus?
Tak, jeśli to zmiana treści, a nie zmiana kontekstu. Pokazanie podpowiedzi, rozwinięcie podmenu czy odsłonięcie wskazówki jest dozwolone, o ile fokus zostaje na elemencie, a strona zachowuje swoje znaczenie. Kryterium jest naruszone, gdy otwarcie przenosi fokus, otwiera nowe okno albo ładuje inną stronę.
Czy kliknięcie przycisku, który otwiera nową stronę, narusza to kryterium?
Nie. Kliknięcie jednocześnie daje przyciskowi fokus i go aktywuje, a kontekst zmienia właśnie aktywacja, o którą człowiek poprosił. Kryterium dotyczy samego fokusu, na przykład sytuacji, gdy ktoś przechodzi tabulatorem na przycisk i coś się dzieje, zanim go naciśnie.
