Wpisy

Pomocnik WCAG 2.1 - Windows Edition

Wprawdzie na podstawie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z dnia 4 kwietnia 2019 r., w polskim obiegu prawnym wciąż jako obowiązująca funkcjonuje wersja specyfikacji WCAG 2.1, to jednak warto wiedzieć, że w bliższej lub dalszej przyszłości ten stan rzeczy się zmieni, a wymagania dotyczące dostosowywania stron WWW i aplikacji mobilnych do potrzeb osób niepełnosprawnych wzrosną – W3C opublikowała bowiem nową wersję specyfikacji WCAG – WCAG 2.2.

Rewolucyjnych zmian nie ma – o najważniejszych można przeczytać tutaj – jednak warto wiedzieć, że w wyniku przesunięć między poszczególnymi działami WCAG, do osiągnięcia poziomu zgodności AA wymaganego „Ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” dojdzie 8 kolejnych kryteriów sukcesu – obecnie jest ich 50, będzie 58.

Aby ułatwić Wam zadanie przygotowania swoich stron WWW zaktualizowaliśmy naszą pomocniczą aplikację Pomocnik WCAG 2.1 do standardu WCAG 2.2 – nazwy i opisów w aplikacji na razie nie zmieniamy, jako, że wciąż oficjalnie obowiązującym w Polsce standardem jest WCAG 2.1, jednak sam silnik sprawdzający strony WWW w aplikacji został zaktualizowany do zgodności z wersją WCAG 2.2.

Dla przypomnienia – aplikacja Pomocnik WCAG 2.1 to praktyczne narzędzie ułatwiające prowadzenie i kontrolę audytu stron WWW, aplikacji wyprowadzających kod wynikowy zgodny z technologią HTML publikowanych w przestrzeni WWW i systemów teleinformatycznych wyprowadzających kod wynikowy zgodny z technologią HTML dostępnych w Internecie, pod kątem dostępności dla osób niepełnosprawnych zgodnie z wytycznymi zawartymi w instrukcji WCAG 2.1. Aplikacja zapewnia ponad 180 zautomatyzowanych testów i analiz pod kątem zgodności strony WWW ze specyfikacją WCAG 2.1. Pobierzecie ją bezpłatnie ze sklepu Microsoft Store.

Aplikacja jest przeznaczona do analizy stron WWW i aplikacji internetowych opublikowanych w języku polskim (PL).

Z racji swojego charakteru, aplikacja Pomocnik WCAG 2.1 jest kierowana przede wszystkim do webmasterów i osób odpowiedzialnych w jednostkach administracyjnych i publicznych za wdrożenie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z dnia 4 kwietnia 2019 r., w szczególności w zakresie dostosowania stron WWW, aplikacji i systemów informatycznych do specyfikacji WCAG 2.1.

Należy przy tym pamiętać, co zawsze podkreślaliśmy i będziemy podkreślać, że wskazania jakiejkolwiek aplikacji, również naszej Pomocnik WCAG 2.1 w żadnym wypadku nie mogą być traktowane jako ekwiwalent przeprowadzenia audytu dostępności strony WWW, czy aplikacji mobilnej lub internetowej, wymaganego „Ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych”. Wskazania aplikacji należy traktować jedynie orientacyjnie, jako pomoc przy planowaniu obszarów audytu, mając jednocześnie na uwadze, że audyt dostępności strony WWW lub aplikacji mobilnej obowiązkowo wymaga współpracy z osobami niepełnoprawnymi podczas jego przeprowadzania.

WCAG 2.1 zamiast WCAG 2.0

W polskim obiegu prawnym, jako obowiązujący standard dostosowywania stron WWW i aplikacji mobilnych podmiotów publicznych do potrzeb osób niepełnosprawnych, funkcjonuje wersja specyfikacji WCAG 2.1, zgodnie z „Ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z dnia 4 kwietnia 2019 r. Tymczasem W3C opublikowała nową wersję specyfikacji WCAG 2.2, która nie wprowadza wprawdzie rewolucji i nie zastąpi obowiązującego standardu, jednak doda do niego kolejne 9 kryteriów sukcesu. Razem na wszystkich poziomach będzie teraz 87 kryteriów do spełnienia, z których do zapewnienia poziomu AA, wymaganego ustawą, potrzeba będzie zadośćuczynić 58 kryteriom. To znaczący wzrost – według WCAG 2.1, aby osiągnąć poziom dostosowania AA trzeba było spełnić 50 kryteriów.

Należy pamiętać, że obecnie w Polsce obowiązuje standard WCAG 2.1. Nie wiadomo kiedy można spodziewać się aktualizacji ustawy – na razie nie są prowadzone prace legislacyjne. Biorąc pod uwagę, że ostatnia aktualizacja tych przepisów zajęła Sejmowi 4 lata, można przypuszczalnie założyć, że czasu na ewentualne przygotowania jest znacząca ilość. Co jednak nowego w WCAG 2.2?

Naszym zdaniem najważniejszą zmianą jest przeniesienie wymagania 2.4.7  Widoczny fokus z poziomu AA do poziomu podstawowego A. Z naszego doświadczenia – już na poziomie AA ten punkt sprawiał sporo problemów podczas audytów WCAG 2.1. Panuje wśród webmasterów wyraźna niechęć do widocznego zaznaczania tzw. outlinem aktywnego focusu. Przypuszczamy, że spowodowane jest to względami natury czysto estetycznej – outline elementów w rzucających się w oczy barwach nigdy nie sprawia pozytywnego wrażenia na odbiorcy pełnosprawnym. Cóż – taka jest właśnie rola tego elementu. Z góry przepraszamy za potoczne wyrażenie, ale aktywny focus ma „walić po oczach”, aby ułatwić zauważenie zaznaczonego elementu osobom słabowidzącym. Według WCAG 2.2 aktywny focus wchodzi do podstawowego poziomu zgodności A – w praktyce nie będzie sensu prowadzić audytu zgodności z WCAG strony bez aktywnego autofocusu, gdyż wynik będzie negatywny „z automatu”. Warto też dodatkowo zwrócić uwagę na nową wytyczną 2.4.11 – Wygląd fokusu, która głosi, że fokus ma być nie tylko widoczny, ale musi wyróżniać się z tła.

Nowe kryteria sukcesu w WCAG 2.2 dotyczą przede wszystkim zaburzeń poznawczych oraz zaburzeń uczenia się.

Poziom A

2.4.13 – Stałe punkty odniesienia
Publikacje elektroniczne muszą mieć numery stron, które odpowiadają wersji drukowanej, jeśli taka istnieje.

3.2.6 – Pomoc łatwa do znalezienia
Kryterium dotyczy opcji pomocy. Jeśli na stronie znajduje się „pomoc” należy upewnić się, że jest stale dostępna zawsze w tym samym miejscu, aby można ją było łatwo odnaleźć.

3.3.7 – Dostępne uwierzytelnianie
Jeśli istnieje mechanizm kontrolny, potwierdzający, że jesteś człowiekiem (np. captcha), musi istnieć alternatywny sposób uwierzytelniania, który nie wymaga testu poznawczego, taki jak np. uwierzytelnianie dwuskładnikowe.

3.3.8 – Nadmiarowość wprowadzania
Podczas wypełniania formularzy wszystkie wcześniej wprowadzone informacje są dostępne przez autouzupełnianie lub wybór. Wyjątkami są potwierdzanie haseł i porzucone formularze.

Poziom AA

2.4.11 – Wygląd fokusu (minimum)
Fokus musi wyróżniać się z tła, a nie tylko być widoczny.

2.5.7 – Przeciąganie
Jeśli gest przeciągania jest wymagany np. przesuwanie po pasku, należy zapewnić jego alternatywę taką jak kliknięcie lub dotknięcie.

2.5.8 – Odstępy między celem wskaźnika
Należy upewnić się, że wszystkie cele interaktywne zajmują co najmniej 44 × 44 piksele CSS. Może to obejmować odstęp wokół celu.

3.2.7 – Ukryte kontrolki
Wszelkie ważne elementy sterujące powinny pozostać widoczne i być dostępne dopóki są istotne. Nie powinny pozostawać ukryte lub znikać.

Poziom AAA

2.4.12 – Wygląd fokusu (wzmocniony)
Na poziomie AAA wygląd fokusu ma konkretnie określone parametry: minimalna grubość linii to 2 px, a kontrast minimalny 4,5:1

WCAG 2.1 zamiast WCAG 2.0

Nareszcie – tym krótkim słowem moglibyśmy podsumować wejście w życie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z 4 kwietnia 2019 r. Ustawa ta zmienia archaiczne założenia „Rozporządzenia Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności”, wymagającego dostosowania stron www do nieaktualnego od czerwca 2018 roku standardu WCAG 2.0 i wprowadza współczesny standard WCAG 2.1 – ARIA. Co to oznacza dla idei dostępności stron www dla osób niepełnosprawnych i sprawdzania tejże dostępności w postaci audytu strony www?

Zasadniczo niewiele, jednak w szczegółach bardzo dużo. Ramy samego audytu nie ulegają zmianie – nadal sprawdzana jest dostępność stron www do poziomu AA specyfikacji WCAG i nadal wymagane jest aby odbywało się to przy aktywnym współudziale osób niepełnosprawnych. Jednak specyfikacja WCAG 2.1 dostosowuje jednocześnie swoje wymagania do wymagań współczesnego rynku informatycznego, dzięki czemu nie narzuca już twórcom stron www i systemów teleinformatycznych przestarzałych rozwiązań. Sama ustawa porządkuje też kwestie certyfikacji dostosowania i deklaracji dostępności strony www, które to kwestie były całkowicie nieuregulowane w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. Mianowicie podmiot prowadzący audyt WCAG 2.1, zgodnie z wytycznymi specyfikacji WAI-ARIA, na koniec badania wystawia badanemu systemowi deklarację zgodności na usystematyzowanym formularzu stanowiącym załącznik do Ustawy – brak tego dokumentu był niezwykle odczuwalny w RRM z 12 kwietnia 2012 roku.

Nowa ustawa zasadniczo poprawia też sytuację deweloperów budujących strony www, którzy chcą (lub muszą, jeśli są to strony przeznaczone dla podmiotów administracji publicznej) dostosować swoje produkty do potrzeb osób niepełnosprawnych. Kierując się bowiem Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności należało m.in. zrezygnować z pełnego wykorzystania Java Scriptu. Strony niedziałające z wyłączonym Java Scriptem, według wytycznych WCAG 2.0 całkowicie bowiem nie spełniają zasady 4 – Kompatybilność. Aby zrozumieć dlaczego tak jest należy uzmysłowić sobie, że założenie dotyczące Java Scriptu przyjęte w wersji 2.0 specyfikacji WCAG pochodzi sprzed blisko dekady. W międzyczasie, w systemach informatycznych oraz samej specyfikacji WCAG dokonał się znaczący postęp. Sama specyfikacja WCAG, w czerwcu 2018 r., została opublikowana w wersji 2.1 uznającej i dostosowującej wytyczne do zmieniających się technologii informatycznych oraz nieustannie rozwijanych technologii asystujących wykorzystywanych przez osoby niepełnosprawne. WCAG 2.1 zmienia m.in. zasadę 4 – Kompatybilność. Zniesiony w niej został m.in. wymóg poprawnej obsługi systemu informatycznego z wyłączonym Java Scriptem, jako że od co najmniej 5 lat na rynku nie ma urządzenia bądź technologii asystującej nie obsługującej poprawnie Java Scriptu, który sam w sobie został włączony do podstawowej semantyki języka HTML, który to z kolei w ciągu ostatnich lat standaryzowano w wersji 5 (specyfikacja WCAG 2.0 odnosi się jeszcze do semantyki HTML 4).

WCAG 2.1 jest częścią WAI ARIA – (Web Accessibility Initiative – Accessible Rich Internet Applications) – specyfikacji technicznej opublikowanej przez W3C, zawierającej zestaw rekomendacji dotyczących poprawy dostępności złożonych aplikacji internetowych. WCAG 2.0, do którego odnosi się RRM z dnia 12 kwietnia 2012 r., nie uwzględnia standardu ARIA, jako, że w momencie publikacji tej wersji WCAG nie był on jeszcze dostępny (został wprowadzony 5 lat później), a kolejna wersja – WCAG 2.1 – stała się formalnie częścią ARIA – stanowiąc jej drugi rozdział.

W związku z wprowadzeniem ARIA dalsze odrębne rozwijanie specyfikacji WCAG stoi pod znakiem zapytania, jako, że WCAG odnosi się w swym założeniu tylko do stron internetowych opartych o język HTML i jest obecnie tylko jednym z rozdziałów ARIA, natomiast ARIA samo w sobie rozszerza pojęcie strony internetowej do „złożonej aplikacji internetowej”. Zatem badanie systemu, który w pełni wdraża i wykorzystuje ARIA dalece wykracza poza ramy oceny jego dostępności przy pomocy specyfikacji WCAG 2.0. Specyfikacja ARIA stanowi bowiem zestaw atrybutów, za pomocą których można nadać semantyczne znaczenie niesemantycznym elementom HTML, bądź też zmienić semantyczne znaczenie elementów, które zostały “przerobione” przy użyciu Java Scriptu na komponenty służące do innych celów, niż jest to opisane w dokumentacji HTML. Dzięki atrybutom ARIA możliwe jest uzupełnienie drzewka dostępności przeglądarki internetowej o dodatkowe informacje na temat właściwości tych elementów, a co za tym idzie przekazanie tych informacji technologiom asystującym. Efekty działania atrybutów ARIA są niewidoczne dla osób niekorzystających np. z czytników ekranu – strona internetowa, która nie używa ARIA będzie wyglądać dokładnie tak samo, jak używająca atrybutów ARIA. Zmieni się za to jej funkcjonalność i użyteczność z punktu widzenia osób korzystających z czytników ekranu. System oparty o ARIA jest zatem w pełni dostępny dla użytkowników niepełnosprawnych i to w stopniu znacząco wyższym, niż przewiduje to specyfikacja WCAG 2.0, choć formalnie może być całkowicie niezgodny z WCAG 2.0, która to specyfikacja nie przewidziała wychodzenia poza język HTML. I to jest właśnie najważniejsza zmiana wprowadzona nową ustawą.