WCAG 2.2 nie wywraca zasad dostępności cyfrowej do góry nogami. Nadal najważniejsze pozostają czytelna struktura strony, obsługa za pomocą klawiatury, odpowiedni kontrast, teksty alternatywne, dostępne formularze i możliwość korzystania z serwisu bez względu na używane urządzenie lub technologię wspomagającą. Nowa wersja standardu zwraca jednak większą uwagę na problemy, które pojawiają się podczas wykonywania konkretnych czynności: wybierania elementów na ekranie, przeciągania obiektów, logowania, wprowadzania tych samych danych oraz korzystania z interfejsu, gdy część strony zasłania aktualnie wybrany element.
WCAG 2.2 zostało opublikowane jako rekomendacja W3C i rozwija wcześniejszą wersję 2.1. Kryteria pozostają sformułowane jako testowalne wymagania niezależne od konkretnej technologii. Oznacza to, że można je stosować nie tylko do klasycznych stron internetowych, lecz także do aplikacji, systemów obsługi mieszkańców, paneli redakcyjnych i innych usług cyfrowych.
W przypadku podmiotów publicznych trzeba jednak odróżnić standard techniczny od bezpośredniego zakresu obowiązków ustawowych. Polska ustawa o dostępności cyfrowej nadal odwołuje się do wymagań odpowiadających WCAG 2.1 na poziomie AA. WCAG 2.2 warto więc traktować jako aktualny kierunek projektowania, zamawiania i rozwijania serwisów, nawet gdy część nowych kryteriów nie została jeszcze wprost wpisana do krajowego załącznika ustawowego. Projektowanie nowej strony wyłącznie według minimum sprzed kilku lat oznacza ryzyko, że serwis będzie wymagał kolejnych kosztownych poprawek niedługo po uruchomieniu.
Fokus nie może znikać pod nagłówkiem ani komunikatem
Osoba korzystająca z klawiatury przechodzi pomiędzy linkami, przyciskami i polami formularza za pomocą klawisza Tab. Aktualnie wybrany element powinien być widoczny. Samo istnienie obramowania lub innego znacznika fokusu nie wystarczy jednak wtedy, gdy element zostaje zasłonięty przez przyklejony nagłówek, pasek zgody na pliki cookie, wysuwane okno albo stałą belkę umieszczoną na dole ekranu.
WCAG 2.2 wprowadza kryterium „Fokus niezasłonięty”, które na poziomie AA wymaga, aby element posiadający fokus nie był całkowicie ukryty przez treść utworzoną przez autora strony. Użytkownik musi widzieć przynajmniej część elementu, na którym aktualnie pracuje.
Na stronie urzędu problem może wystąpić na przykład w rozbudowanym formularzu. Użytkownik przechodzi klawiaturą do przycisku „Wyślij”, ale przycisk znajduje się pod stałym paskiem dotyczącym prywatności. Technicznie fokus nadal istnieje, lecz osoba nie widzi, gdzie się znajduje. Podobnie może działać przyklejone menu, które zasłania pierwszy link po przewinięciu strony.
Nie jest to wyłącznie problem estetyczny. Brak widocznego miejsca interakcji utrudnia obsługę osobom z niepełnosprawnością ruchową, korzystającym z klawiatury, przełączników lub sterowania głosem. Może również powodować przypadkowe uruchomienie niewłaściwej funkcji.
Przy odbiorze strony trzeba więc sprawdzić nie tylko to, czy da się przejść po elementach klawiszem Tab. Test powinien obejmować również widoczność fokusu przy otwartym menu, powiększonej stronie, aktywnym pasku cookies, komunikatach błędów i oknach modalnych.
Widoczny fokus powinien być rzeczywiście widoczny
WCAG 2.2 rozwija także temat wyglądu fokusu. Kryterium dotyczące jego rozszerzonej widoczności znajduje się na poziomie AAA, ale daje bardzo praktyczną wskazówkę projektową: fokus powinien mieć dostateczną powierzchnię i kontrast, aby można go było szybko zauważyć. W3C zwraca uwagę, że drobna zmiana koloru albo cienka, słabo kontrastująca linia może być niewidoczna dla osób starszych i osób z obniżoną wrażliwością na kontrast.
Na wielu stronach urzędowych fokus jest domyślnie usuwany w arkuszu stylów, ponieważ projektant uznał obramowanie za nieestetyczne. Czasami pojawia się dopiero po interwencji audytora, ale zostaje zaprojektowany jako niemal niewidoczna szara linia. Formalne dodanie efektu nie oznacza jeszcze, że użytkownik będzie w stanie go dostrzec.
Dobry fokus powinien odcinać się od tła, być widoczny na jasnych i ciemnych elementach oraz nie opierać się wyłącznie na subtelnej zmianie koloru tekstu. W serwisie zawierającym różne typy przycisków, kart i odnośników warto stosować spójny mechanizm, na przykład wyraźne obramowanie z odpowiednim odstępem od elementu.
Przeciąganie nie może być jedynym sposobem wykonania zadania
Nie każdy użytkownik może precyzyjnie złapać element kursorem, przytrzymać go i przeciągnąć w określone miejsce. Taka operacja jest trudna dla osób z ograniczoną sprawnością dłoni, drżeniem, bólem lub problemami z koordynacją. Może też sprawiać trudność na ekranie dotykowym.
Nowe kryterium WCAG 2.2 wymaga, aby funkcja oparta na przeciąganiu była możliwa do wykonania również za pomocą prostszej operacji wskaźnika, chyba że przeciąganie jest istotą działania albo funkcja jest zapewniana przez przeglądarkę lub technologię pomocniczą.
W serwisach urzędowych problem może pojawić się w kalendarzu rezerwacji, generatorze formularzy, systemie wyboru kolejności pozycji, mapie lub module przesyłania dokumentów. Jeżeli użytkownik musi przeciągnąć plik do oznaczonego pola, powinien mieć również możliwość wybrania go za pomocą standardowego przycisku. Jeżeli musi ułożyć elementy w określonej kolejności, można dodać przyciski „Przenieś wyżej” i „Przenieś niżej”.
Nie chodzi o usuwanie nowoczesnych mechanizmów interakcji. Chodzi o to, aby przeciąganie było opcją, a nie barierą blokującą wykonanie zadania.
Małe przyciski powodują realne pomyłki
WCAG 2.2 wprowadza na poziomie AA minimalne wymaganie dotyczące wielkości elementów obsługiwanych wskaźnikiem. Zasadniczo obszar aktywny powinien mieć co najmniej 24 na 24 piksele CSS albo powinien być rozmieszczony w taki sposób, aby użytkownik nie uruchamiał przypadkowo sąsiedniego elementu. Kryterium przewiduje wyjątki, między innymi dla elementów występujących w tekście, rozwiązań kontrolowanych przez przeglądarkę i sytuacji, w których mniejszy rozmiar jest niezbędny.
Na stronie publicznej problemem bywają małe ikony drukowania, pobierania, zamykania komunikatu albo przechodzenia między miesiącami w kalendarzu. Jeszcze większe ryzyko powstaje wtedy, gdy kilka drobnych ikon znajduje się obok siebie.
Osoba z ograniczoną precyzją ruchu może nacisnąć niewłaściwy przycisk. Na telefonie podobny problem dotyczy praktycznie każdego użytkownika. Małe cele dotykowe są trudne do trafienia, szczególnie przy powiększeniu, w ruchu lub podczas obsługi urządzenia jedną ręką.
Wymaganie nie powinno być interpretowane jako zachęta do projektowania wszystkich przycisków dokładnie w minimalnym rozmiarze. Minimum techniczne nie zawsze oznacza komfort użytkowania. Główne działania, takie jak wysłanie formularza, zapisanie danych lub przejście do kolejnego kroku, powinny mieć wyraźnie większy obszar aktywny.
Logowanie nie może zależeć wyłącznie od pamięci i rozwiązywania zagadek
Jedna z najważniejszych zmian WCAG 2.2 dotyczy dostępnego uwierzytelniania. Standard zwraca uwagę, że logowanie nie powinno wymagać od użytkownika wykonania testu funkcji poznawczych, takiego jak zapamiętanie hasła, przepisanie go bez możliwości użycia menedżera haseł albo rozwiązanie zadania, chyba że zapewniono dostępny mechanizm pomocniczy lub alternatywną metodę.
Celem kryterium jest zapewnienie łatwego i bezpiecznego sposobu logowania również osobom z niepełnosprawnościami poznawczymi. W3C wskazuje, że konieczność zapamiętania loginu i hasła, a następnie wykonania dodatkowych operacji, może stanowić bardzo poważną barierę.
Dla urzędu ma to znaczenie przy projektowaniu portalu mieszkańca, systemu rezerwacji, platformy konsultacyjnej, konta podatnika lub innej usługi wymagającej uwierzytelnienia. Formularz nie powinien blokować wklejania hasła ani korzystania z menedżera haseł. Kod jednorazowy powinien dać się wkleić. Mechanizm CAPTCHA powinien posiadać dostępną alternatywę i nie może uzależniać dostępu do usługi od rozpoznawania obrazów lub rozwiązywania zagadek.
Bezpieczeństwo i dostępność nie są przeciwieństwami. Dobrze zaprojektowane logowanie może chronić konto bez przerzucania całego ciężaru na pamięć użytkownika.
Użytkownik nie powinien wielokrotnie wpisywać tych samych danych
W wieloetapowych formularzach często pojawia się konieczność ponownego wprowadzenia informacji podanych wcześniej. Użytkownik wpisuje dane kontaktowe na początku procesu, a następnie musi powtórzyć je na kolejnej stronie. WCAG 2.2 ogranicza takie sytuacje. Informacja wcześniej wprowadzona w tym samym procesie powinna zostać automatycznie uzupełniona albo możliwa do wybrania, chyba że powtórzenie jest niezbędne, potrzebne ze względów bezpieczeństwa lub wcześniej wprowadzona informacja straciła aktualność.
W praktyce urząd powinien przeanalizować cały proces, a nie tylko pojedynczy ekran. Jeśli mieszkaniec podał adres w pierwszym kroku, system nie powinien bez uzasadnienia żądać jego ponownego wpisania w kroku czwartym. Jeżeli dane są już znane po zalogowaniu, można je podpowiedzieć i umożliwić ich korektę.
Powtarzanie informacji zwiększa ryzyko błędów, wydłuża obsługę i szczególnie obciąża osoby z trudnościami poznawczymi, dysleksją, ograniczoną sprawnością ruchową albo korzystające z urządzeń mobilnych.
Pomoc powinna znajdować się w przewidywalnym miejscu
WCAG 2.2 wprowadza także wymaganie dotyczące spójnego położenia mechanizmów pomocy. Jeżeli na kilku stronach procesu dostępne są dane kontaktowe, formularz pomocy, mechanizm kontaktu z pracownikiem lub sekcja najczęściej zadawanych pytań, powinny występować w tej samej względnej kolejności.
Na jednej podstronie numer telefonu nie powinien znajdować się w nagłówku, na drugiej pod formularzem, a na kolejnej wyłącznie w ukrytym menu. Użytkownik, który raz odnalazł pomoc, powinien móc przewidzieć, gdzie znajdzie ją ponownie.
Ma to szczególne znaczenie w rozbudowanych e-usługach. Osoba, która napotka błąd podczas wypełniania wniosku, nie powinna przerywać procesu i przeszukiwać całego serwisu w poszukiwaniu kontaktu. Spójność zmniejsza obciążenie poznawcze i zwiększa szansę na samodzielne ukończenie zadania.
WCAG 2.2 trzeba sprawdzać w procesach, nie tylko na podstronach
Nowych wymagań nie da się rzetelnie ocenić przez samo uruchomienie automatycznego skanera. Narzędzie może wskazać niektóre problemy techniczne, ale nie sprawdzi, czy przyklejony nagłówek zasłania fokus w konkretnym momencie, czy formularz nie wymaga ponownego wpisywania danych ani czy przeciąganie ma prostą alternatywę. Ministerstwo Cyfryzacji również podkreśla, że testy automatyczne wykrywają tylko część błędów dostępności.
Ocena powinna obejmować całe zadania wykonywane przez użytkownika. W serwisie urzędowym może to być odnalezienie informacji, zapisanie się na wydarzenie, wysłanie formularza, pobranie dokumentu, utworzenie konta, zalogowanie się, dokonanie płatności albo zarezerwowanie terminu.
Test należy przeprowadzić za pomocą klawiatury, na urządzeniu mobilnym, przy powiększeniu oraz z uwzględnieniem komunikatów, okien modalnych i dynamicznie pojawiających się elementów. Dopiero wtedy można ocenić, czy użytkownik rzeczywiście jest w stanie ukończyć proces.
Nowy serwis powinien być projektowany z myślą o aktualnym standardzie
Podmiot publiczny nie powinien czekać z uwzględnieniem WCAG 2.2 do momentu, w którym każde nowe kryterium zostanie wprost wymienione w przepisach. Standard jest już dostępny, opisany i możliwy do zastosowania w projektowaniu oraz testowaniu. Włączenie go do zamówienia, projektu i odbioru strony ogranicza ryzyko powstawania barier, które później trzeba będzie usuwać w działającym systemie.
Największe znaczenie mają dziś nie efektowne deklaracje zgodności, lecz jakość konkretnych procesów. Użytkownik powinien widzieć, gdzie znajduje się fokus, móc wybrać odpowiednio duży przycisk, wykonać zadanie bez przeciągania, zalogować się bez pokonywania bariery poznawczej i przejść przez formularz bez wielokrotnego wpisywania tych samych danych.
WCAG 2.2 przesuwa uwagę z samej obecności elementu na rzeczywistą możliwość jego użycia. Dla stron urzędowych jest to ważna zmiana. Dostępność nie kończy się na tym, że treść da się odczytać. Serwis musi również pozwalać bezpiecznie, samodzielnie i skutecznie załatwić sprawę.