Wpisy

Jak to jest z tym audytem WCAG 2.1

Przepisy o dostosowywaniu aplikacji i stron internetowych do potrzeb osób niepełnosprawnych funkcjonują w obiegu prawnym od dekady, a mimo to wciąż budzą wiele wątpliwości. Może już nie w sferze tego kto musi je stosować – ta świadomość stała się dość powszechna. Najprościej rzecz ujmując – wszystkie przejawy działalności informacyjnej opłacane z publicznych pieniędzy muszą być dostępne dla wszystkich obywateli, dzięki pieniądzom których powstają. Skoro osoby niepełnosprawne płacą podatki, to strony internetowe i aplikacje oferowane przez podmioty publiczne lub opracowywane przy użyciu publicznych pieniędzy muszą być dostępne także dla nich.

Wątpliwości wciąż dotyczą tego jak sprawdzić, czy strona WWW lub aplikacja mobilna rzeczywiście jest dla osób niepełnosprawnych dostępna. Większość zainteresowanych wie, że trzeba przeprowadzić audyt zgodności strony WWW lub aplikacji mobilnej ze specyfikacją WCAG 2.1 i na tym wiedza się kończy. Jak? Kto może taki audyt przeprowadzić? Jak powinien on wyglądać? – to już kwestie które, na które większość osób odpowiedzialnych nie zna odpowiedzi.

„Zasługę” należy tu przypisać zagmatwanym przepisom dotyczącym tej kwestii – są ogromnie skomplikowane pod względem struktury. Wymogi dotyczące prowadzenia audytu WCAG 2.1 istnieją w systemie prawnym i są konkretnie określone, ale dotarcie do nich to długa i skomplikowana ścieżka, gdyż polska „Ustawa o dostępności cyfrowej stron WWW i aplikacji mobilnych podmiotów publicznych” z 2019 r odwołuje się do decyzji wykonawczych Komisji Europejskiej, które z kolei odwołują się do dyrektyw Parlamentu Europejskiego, które z kolei odwołują się do kolejnych decyzji wykonawczych KE i do Normy Europejskiej EN 301 549 V1.1.2 (2015-04).

Jednym z pytań najczęściej budzących wątpliwości jest – czy istnieje lista jednostek uprawnionych do prowadzenia audytu WCAG 2.1? Nie istnieje. Nie ma żadnego oficjalnego rejestru. Przepisy są oparte o zasadę zaufania lub udowodnienia, że jednostka podejmująca się audytu WCAG 2.1 posiada odpowiednią wiedzę, doświadczenie i środki umożliwiające przeprowadzenie takiego audytu. Decyzje wykonawcze Komisji Europejskiej obwarowują warunki prowadzenia audytu WCAG 2.1 następująco:

Audyt WCAG 2.1 jest to:

  • Badanie techniczne strony WWW lub aplikacji mobilnej przeprowadzone przez dwóch specjalistów – programistów z minimum pięcioletnim stażem lub doświadczeniem zawodowym. Przy czym to doświadczenie może być potwierdzone wykształceniem kierunkowym i minimum pięcioletnim stażem pracy lub też innym dowodem takim jak np. dowody na przeprowadzenie co najmniej 5 audytów WCAG 2.1 w ciągu ostatnich 3 lat.
  • Badanie faktycznego odbioru strony WWW lub aplikacji mobilnej przez użytkowników z różnych grup niepełnosprawności – tzw. badanie testerskie. Uczestniczą w nim minimum 4 osoby reprezentujące grupy niepełnosprawności: niewidomi/słabowidzący, niesłyszący, osoby z dysfunkcjami motorycznymi, osoby z problemami kognitywnymi. Zaleceniem jest koordynacja tego zespołu przez osobę z doświadczeniem w rehabilitacji niepełnosprawnych. Przy czym decyzje wykonawcze Komisji Europejskiej nie precyzują sposobu weryfikacji niepełnosprawności tych osób zostawiając to krajom członkowskim ze względu na różne systemy kwalifikacji niepełnosprawności w poszczególnych krajach, a polskie przepisy wynikające z owych decyzji wykonawczych temat omijają – przyjmuje się, że są to po prostu osoby z orzeczeniami o niepełnosprawności danego typu.

W audyt WCAG 2.1 musi być zatem zaangażowanych minimum 6 osób. Audyt i dostosowanie strony WWW lub aplikacji mobilnej do wymogów WCAG 2.1 musi być przeprowadzony w następujących etapach:

  • Audyt właściwy, dwuetapowy, przeprowadzony według opisanych wyżej założeń,
  • Nanoszenie poprawek na stronie WWW lub w aplikacji mobilnej zgodnie z wynikami audytu,
  • Audyt ponowny, dwuetapowy, według powyższych założeń potwierdzający zgodność ze specyfikacją WCAG 2.1.
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ą.

WCAG 2.0 - obalamy mity

Wykonujemy znaczną ilość audytów WCAG 2.0 kontrolujących stopień dostosowania stron internetowych do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, i zarysowała nam się pewna prawidłowość – w polskim Internecie panuje błędne przekonanie, że strona www spełniająca wymagania specyfikacji WCAG 2.0 jest wyposażona w kilkanaście przełączników służących do zmiany kolorów na bardziej kontrastowe, umożliwiających zmianę wielkości czcionek etc. Tymczasem… nie jest to prawda. To o tyle zaskakujące, że sytuacja dotyczy także nowo powstających stron www, a to świadczy o niezrozumieniu czym jest specyfikacja WCAG 2.0 i jakie są jej zalecenia. W dużym skrócie – strona spełniająca założenia specyfikacji WCAG 2.0 jest w równym stopniu dostępna dla osób pełnosprawnych, jak i niepełnosprawnych – nie potrzebuje żadnych przełączników kolorów, kontrastów itp., gdyż od podstaw jest budowana tak, aby była dostępna dla wszystkich. Nowo powstające strony www budowane z myślą o WCAG 2.0 tych elementów nie mają – rozmaite kontrolki po prostu nie są na nich do niczego potrzebne.

Obecność przełączników kontrastu, wielkości czcionek etc. nie świadczy o spełnianiu przez stronę założeń specyfikacji WCAG 2.0. Ich obecność to obejście, swoiste „koło ratunkowe” – w polskich warunkach wymuszone wspomnianym Rozporządzeniem Rady Ministrów, które generalnie dostosowuje polskie prawo do dyrektyw Unii Europejskiej w tym zakresie. Zgodnie z tym aktem prawnym, strony www i systemy teleinformatyczne muszą być zgodne z WCAG 2.0, jednak na budowanie ich od nowa zazwyczaj nie można sobie pozwolić z powodu np. zbyt dużego rozbudowania istniejącego systemu, zbyt wysokich kosztów, które za sobą pociągałaby budowa strony jeszcze raz itp. Autorzy rozporządzenia słusznie zauważają, że większość stron administracji publicznej jest obecnie całkowicie niedostępna dla osób niepełnosprawnych. Osoba np. niewidoma tymczasem także ma prawo wezwać policję, czy pogotowie ratunkowe w sytuacji zagrożenia, albo zapytać jak załatwić sprawę w urzędzie, a potrzebny numer telefonu znaleźć na stronie www danej instytucji lub po prostu skontaktować się z ową instytucją za pomocą formularza kontaktowego na stronie – tak jak robią to internauci pełnosprawni. Kontrolki przełączania warstw systemu na zgodne z WCAG 2.0 (czy też raczej ułatwiające poruszanie się po stronie osobom z różnymi rodzajami niepełnosprawności) masowo pojawiające się obecnie na urzędowych stronach www to, jak wspomnieliśmy, „koło ratunkowe” – elementy dostosowujące istniejące strony wprowadzane są po to, aby nie musieć budować ich od podstaw. Obecność przełączników kontrastu, dostosowywania czcionek etc. świadczy jedynie o tym, że dana strona była/jest dostosowywana do specyfikacji WCAG 2.0, nie zaś o tym, że ją spełnia – nie zawsze jest to bowiem w pełni możliwe w przypadku istniejącego systemu informatycznego.

Sytuacja taka w ogóle nie powinna mieć miejsca w przypadku nowo powstających systemów teleinformatycznych, czy stron www. Strona WCAG 2.0 z założenia ma być bezproblemowo dostępna zarówno dla osób pełnosprawnych, jak i niepełnosprawnych – i na tym polega idea WCAG 2.0 w swej istocie. Kontrast na zgodnej stronie jest od początku dobrany tak, że umożliwia czytanie osobom niedowidzącym i nie trzeba go przełączać, a dla osób widzących może stanowić co najwyżej kwestie estetyczne (strony WCAG 2.0 są stosunkowo stonowane), czcionki są odpowiednio duże (osoba pełnosprawna także bez kłopotu przeczyta większy tekst, a przy okazji nie męczy oczu drobną czcionką), strona jest w pełni obsługiwana z klawiatury i ma wbudowane skróty klawiaturowe, co nie oznacza, że standardowa obsługa zostaje wyłączona – osoby pełnosprawne dalej poruszają się po systemie klasycznie przy pomocy myszki. I można by tak wymieniać bardzo długo – tak długo, jak obszerna jest specyfikacja WCAG 2.0.

Kompendium WCAG 2.0: Zasada 4: Rzetelność

Dotarliśmy do końca omawiania podstawowej specyfikacji WCAG 2.0. To już ostatni punkt specyfikacji i tym samym ostatni wpis na naszym blogu z cyklu „Kompendium WCAG 2.0”. Wszystkim, którzy przez ostatnie dwa lata śledzili ten cykl wpisów dziękujemy za obecność, komentarze i ocenianie artykułów. Tych kilkadziesiąt artykułów nie wyczerpuje naturalnie w pełni tematu WCAG 2.0, niemniej jednak wystarczy do zrozumienia idei budowy dostępnych stron www i systemów informatycznych. Jeśli chcielibyście Państwo, abyśmy kontynuowali ten cykl omawiając pełną specyfikację WCAG 2.0, wraz wyjaśnieniami i komentarzami w niej zawartymi, czekamy na Wasze komentarze.

Treść na stronie www musi być wystarczająco rzetelna, aby mogła zostać poprawnie zinterpretowana na wiele różnych sposobów stosowanych przez użytkownika do jej przeglądania, wliczając w to technologie wspomagające.

Wytyczna 4.1 Kompatybilność
Staraj się zapewnić jak największą kompatybilność z obecnymi i przyszłymi sposobami stosowanymi przez użytkownika do przeglądania strony, wliczając w to technologie asystujące.

4.1.1 Poprawność kodu
Kod HTML i CSS powinien być jak najbardziej zgodny z deklaracją DOCTYPE html i jak najbardziej „czysty”, tzn. wolny od błędów i poprawny semantycznie. Po każdej zmianie na stronie www kontroluj, czy w kodzie nie wkradł się błąd. Niedomknięte, czy niepoprawnie zagnieżdżone znaczniki, powtarzające się identyfikatory ID, powodują, że czytniki ekranu i inne technologie wspomagające stosowane przez osoby niepełnosprawne mogą niepoprawnie interpretować treść strony.

4.1.2 Nazwa, przeznaczenie, wartość
Ostatni punkt podstawowej specyfikacji WCAG 2.0 skierowany jest nie tyle do webmasterów i osób prowadzących strony www, co jest rodzajem apelu do programistów tworzących elementy interfejsu użytkownika za pomocą rozmaitych technologii jak np. flash, javascript, actionscript, adobe air itp. Jest to prośba, aby wszystkie komponenty interfejsów użytkownika z wbudowanymi mechanizmami wspierania dostępności, podobnie jak kod stron www, także były jednoznacznie identyfikowane przez nadawanie im nazw, etykiet itd. Szczególnie ważne jest to dla użytkowników niepełnosprawnych używających technologii wspomagających – np. dzięki stosowaniu tych zasad czytniki ekranu będą mogły zrozumieć nazwę, czy przeznaczenie interpretowanego elementu i przeczytać odpowiednią nazwę lub instrukcję swojemu niewidomemu właścicielowi.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompendium WCAG 2.0: Wytyczna 3.3 Pomoc przy wprowadzaniu danych

Postaraj się pomóc użytkownikom nie robić błędów, a w razie wystąpienia błędu pomóż go skorygować

tak brzmi wytyczna 3.3 specyfikacji WCAG 2.0 i należy ją rozumieć dosłownie.

3.3.1 Jasna identyfikacja błędów
Informacja po wystąpieniu błędu musi być jasna, skuteczna i intuicyjna oraz dostępna dla wszystkich użytkowników.
Trzeba pozwalać użytkownikowi jednoznacznie określić błąd oraz udostępnić możliwość jego skorygowania. Prostym przykładem jest formularz z wymaganym polem „Wpisz swoje imię”. Jeśli użytkownik nie wypełni tego pola i usiłuje wysłać formularz strona wyświetla jasny, tekstowy komunikat „Proszę wpisz swoje imię!”.

3.3.2 Etykiety i instrukcje
W każdym miejscu strony www, w którym wymagane jest wprowadzenie przez użytkownika informacji należy zapewnić jasne etykiety, instrukcje wypełnienia formularza, przykłady itp. pomoc.

3.3.3 Podpowiadaj rozwiązania błędów
Stosuj czytelne, jasne i prezentowane w sposób dostępny podpowiedzi w wypadku wystąpienia błędu podczas wprowadzania danych do formularza przez użytkownika. Sugestie nie mogą zmieniać celu treści oraz stanowić zagrożenia bezpieczeństwa (np. system nie może wyświetlać w podpowiedzi hasła użytkownika).

3.3.4 Zapobieganie błędom podczas wypełniania formularzy niosących konsekwencje prawne
Należy zapewnić dostępne mechanizmy umożliwiające przywrócenie danych oraz ich weryfikację.
Jeśli na stronie www użytkownik może:
– zawierać zobowiązania prawne lub transakcje finansowe,
– modyfikować i usuwać przechowywane dane,
– wypełniać testy
trzeba zapewnić dostępne mechanizmy umożliwiające przywrócenie danych oraz ich weryfikację.

3.3.5 Pomoc
W każdym miejscu strony www, gdzie użytkownik może wprowadzać, zmieniać lub usuwać informacje trzeba zapewnić pełną, jasną i rzeczową informację o tym, jak należy to zrobić. Może to być forma opisu, prezentacji, wirtualnego asystenta i wszelkie inne formy pomocy zaimplementowane w sposób zapewniający dostępność.

3.3.6 Bezwzględne zapobieganie błędom
Ten punkt jest tożsamy z wytyczną 3.3.4 z rozszerzeniem, że mechanizmy pozwalające na przywrócenie poprzednich danych i ich weryfikację muszą być zaimplementowane bezwzględnie dla wszystkich formularzy wysyłających dane ze strony www.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompendium WCAG 2.0: Wytyczna 3.2 Przewidywalność

Buduj strony www, tak aby otwierały się i działały w sposób, który da się przewidzieć

tak brzmi zalecenie wytycznej 3.2 specyfikacji WCAG 2.0

3.2.1 Zaznaczanie elementu
Na stronie www nie powinna zaistnieć żadna zmiana kontekstu wprowadzająca w błąd lub dezorientująca użytkownika, jeśli jakikolwiek element tej strony otrzymał zaznaczenie (angielskie: focus). Nie powinno dochodzić do automatycznego przeładowywania strony, wysyłania formularzy etc. Wszystkie zmiany muszą być świadomym działaniem ze strony użytkownika.

3.2.2 Wprowadzanie danych
Nie wolno powodować automatycznej zmiany kontekstu treści podczas zmiany ustawień jakiegokolwiek elementu interfejsu przez użytkownika. Jeśli taki mechanizm jest niezbędny, należy bezwzględnie ostrzec użytkownika o takiej zmianie i to jeszcze zanim zacznie korzystać z elementu powodującego zmianę.

3.2.3 Jednolita nawigacja
Wszystkie elementy nawigacji powtarzające się na podstronach strony www, czy systemu informatycznego powinny pojawiać się w tym samym porządku za każdym razem, gdy są prezentowane. Dozwolone jest umieszczanie dodatkowych informacji pomiędzy powtarzającymi się elementami nawigacji, czy ich pomijanie w uzasadnionych sytuacjach, jednak pod warunkiem zachowania ustalonego porządku pozostałych.

3.2.4 jednolita identyfikacja
Elementy o tożsamej funkcjonalności na różnych podstronach strony www powinny być tak samo rozpoznawane. Np. formularze powinny być zawsze o tym samym wyglądzie. Takie działanie ułatwia odbiór strony użytkownikom z problemami kognitywnymi.

3.2.5 Zmiana na żądanie
Wszystkie zmiany treści i kontekstu strony www (np. pojawienie się wyskakujących okien, przekierowania, elementy wprowadzania danych) są wywoływane i prezentowane tylko na świadome życzenie użytkownika – bez wyjątku w całym serwisie.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Certyfikaty WCAG 2.0

Nawiązując do dużej ilości zadawanych nam pytań postaramy się wyjaśnić kwestę tzw. certyfikatów zgodności stron internetowych z WCAG 2.0, co ma związek z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, nakazującym instytucjom użyteczności publicznej oraz organom administracji państwowej i samorządowej dostosowanie stron www i systemów teleinformatycznych do standardu WCAG 2.0.

Już na wstępie należy podkreślić, że Polskie instytucje państwowe nie prowadzą certyfikacji zgodności stron z WCAG 2.0. Wynika to z natury samej specyfikacji WCAG 2.0, która jest tworzona i rozwijana na bieżąco przez jedną z agend ONZ. Rząd musiałaby powołać stosowny urząd kontrolny, a instytucja ta musiałaby zostać akredytowana przy W3C i ONZ. Nie istnieje zatem certyfikat zgodności z WCAG 2.0 w rozumieniu dokumentu poświadczanego przez instytucję państwową. Deklarację zgodności wystawia jednostka przeprowadzająca audyt poświadczając tym samym poziom zgodności i przyjmując na siebie za taką deklarację odpowiedzialność.

Również w przypadku prowadzonego przez nas audytu WCAG 2.0 wystawiana jest pisemna deklaracja zgodności strony z WCAG 2.0 i Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności. Strony www, które uzyskują wymagany poziom zgodności mogą ponadto posługiwać się logotypem W3C informującym o zgodności z danym poziomem WCAG 2.0. Wzory logotypów wyglądają następująco:

Logotypy zgodności z WCAG 2.0

Logotypy zgodności z WCAG 2.0

Warto także przypomnieć, że rozporządzenie nakłada obowiązek dostosowania stron www według wybranych 36 pozycji specyfikacji WCAG 2.0, pogrupowanych w 12 wymagań, według 4 zasad, w 10 punktach do poziomu AA (drugi, z trzech możliwych), w pozostałych do poziomu A. Nie jest wymagany zatem pełny audyt WCAG 2.0 i dostosowywanie stron do poziomu AAA. Ta kwestia budzi wiele wątpliwości – strony www według wspomnianego rozporządzenia muszą zostać dostosowane do poziomu AA WCAG 2.0.

Należy także pamiętać, że wspomniane rozporządzenie określa ponadto minimalne wymagania, które musi spełnić sam audyt WCAG 2.0. Wymagania te wynikają bezpośrednio ze specyfikacji WCAG 2.0 i ich niespełnienie może skutkować zakwestionowaniem audytu WCAG 2.0 przez instytucje kontrolne. Minimalnych wymagań nigdy nie spełni audyt WCAG 2.0 przeprowadzony przez jedną osobę. W audycie WCAG 2.0 bierze udział minimum 6-oosobowy zespół specjalistów – złożony nie tylko z programistów oceniających techniczną budowę kodu strony internetowej i zastosowane rozwiązania z zakresu user experience lecz również samych zainteresowanych: osób niepełnosprawnych z różnymi dysfunkcjami, do których kierowane jest rozporządzenie. Audyt powinien zostać również skontrolowany i zatwierdzony przez specjalistę ds. rehabilitacji osób niepełnosprawnych. Audyt WCAG 2.0 prowadzony bez udziału osób niepełnosprawnych nie spełnia wymagań Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, które to rozporządzenie w dużej mierze opiera się na specyfikacji WCAG 2.0. Sama specyfikacja bowiem, w swoich założeniach, przewiduje oprócz kontroli technicznych aspektów działania, dostępności i dostosowania strony internetowej, kontrolę jej faktycznego odbioru przez osoby niepełnosprawne.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.

 

Kompendium WCAG 2.0: Wytyczna 3.1 Czytelność

Treść strony www oraz obsługa interfejsu użytkownika musi być zrozumiała

tak w dosłownym przekładzie brzmi zasada 3 specyfikacji WCAG 2.0.

Wytyczna 3.1 Czytelność
Po prostu: twórz treści czytelne i łatwe do zrozumienia

3.1.1 Język strony
Język strony powinien być jasno określony za pomocą atrybutu lang lub xml:lang w znacznikach HTML. Pozwala to poprawnie wybrać interpretowany język przez urządzenia wspomagające, używane przez osoby niepełnosprawne. W praktyce chodzi głównie o syntetyzery mowy czytające strony www osobom niewidomym.

3.1.2 Język elementów
Język elementów strony powinien być jasno określony za pomocą atrybutu lang lub xml:lang w znacznikach HTML. Podobnie, jak w punkcie 3.1.1 – pozwala m.in. poprawnie określić język dla syntetyzerów mowy.

3.1.3 Nietypowe słowa
Jeśli w treści strony www użyte są skróty, należy zapewnić opisy ich znaczeń w pełnej formie.

3.1.4 Skróty
Słowa nietypowe, nieznane powszechnie, dwuznaczne, albo używane w specyficzny sposób powinny być wytłumaczone. Np. w podręcznym słowniczku dostępnym obok tekstu.

3.1.5 Poziom umiejętności czytania
Teksty, instrukcje i informacje zawierające nazwy własne, których zrozumienie wymaga wiedzy i wykształcenia wyższego, niż poziom gimnazjalny, należy uzupełniać o streszczenia, ilustracje, wykresy itp.

3.1.6 Jak to wymówić?
Jeśli do zrozumienia słowa użytego w treści strony www niezbędna jest znajomość wymowy, zaraz po użytym słowie należy zapewnić możliwość poznania wymowy tego słowa lub zamieścić odnośnik do stosownego słownika.

 

Jeśli interesuje Państwa audyt WCAG 2.0 zgodny z Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, zachęcamy do zapoznania się z metodyką prowadzonego przez nas audytu dostępności stron www zgodnego z tym rozporządzeniem, dostępną pod tym odnośnikiem: Audyt WCAG 2.0

Dla wszystkich śledzących nasz cykl wpisów „Kompendium WCAG 2.0” przygotowaliśmy także bezpłatną aplikację mobilną Pomocnik WCAG 2.0, stanowiącą uzupełnienie tego cyklu. Aplikacja kierowana jest do webmasterów i osób odpowiedzialnych w jednostkach publicznych za dostosowanie stron www do wymagań WCAG 2.0 zgodnie z Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności.