DostepnyDesign.pl

Dzisiaj na celowniku Dostępny Design – strona, dzięki której zapiszemy się na dofinansowywany ze środków unijnych kurs projektowania uniwersalnego.

W sumie miałem przejść do porządku dziennego nad tą stroną, ale moją uwagę przykuła informacja w stopce: Strona zgodna z WCAG 2.1. A z tym nie mogę się zgodzić i już piszę dlaczego.

WCAG 2.1 (istnieje też oficjalne polskie tłumaczenie) to najnowsza wersja standardu określającego podstawowe zalecenia przy zapewnianiu dostępności stron internetowych. Co prawda strona zgodna z tym standardem nie staje się z automatu dostępna (istnieje naprawdę wiele sposobów, żeby „oszukać” wytyczne), ale na pewno jest bliżej niż dalej. Można się spierać, czy pełna zgodność jest w ogóle możliwa do osiągnięcia. Jednak sam standard jasno określa, co to znaczy formalna zgodność – spełnienie wszystkich kryteriów sukcesu dla wybranego poziomu (A, AA lub AAA). Jeśli strona nie spełnia choćby jednego kryterium, no to przykro nam, ale formalnie nie jest zgodna ze standardem WCAG 2.1. Innymi słowy: wystarczy znaleźć jedno niespełnione kryterium, by strona formalnie stała się niezgodna ze standardem.

Problem polega na tym, że… takie kryterium zauważyłem od razu po wejściu na stronę. Nie ukrywam, że nie mam najlepszego wzroku, więc takie rzeczy, jak za niski kontrast, od razu rzucają mi się w oczy (wybaczcie słaby dowcip). Na tej stronie ten problem jest wykrywany także przez Lighthouse, który wskazuje, że większość miejsc, w których pojawia się biały tekst na pomarańczowym tle (lub na odwrót), ma za niski kontrast. Jego współczynnik wynosi 1.85. Natomiast standard wymaga, by wynosił co najmniej 4.5:1. To oznacza, że, zgodnie z wymaganiami opisanymi w samym standardzie, strona nie jest zgodna z poziomem AA WCAG 2.1.

Niestety, okazuje się, że nie jest także zgodna z poziomem A. Po kliknięciu przycisku Zapisz się jesteśmy przenoszeni do formularza kontaktowego. Problem widać od razu po próbie przejścia do dowolnego pola formularza. Mam w zwyczaju klikać w etykiety pól. Tutaj jednak takie kliknięcie nic nie robi, co oznacza, że opisy pól nie są odpowiednio oznaczone przy pomocy label. A odpowiednie oznaczenie pola formularzy jest wymogiem w kryterium 3.3.2 oraz w kryterium 4.1.2. Zwłaszcza to drugie kryterium jest interesujące w tym kontekście, bo wymaga, by każda etykieta (nazwa) pola formularza mogła być określona programowo. W największym skrócie: chodzi o to, żeby elementy miały przyporządkowaną tzw. accessible name (dostępną nazwę), która jest następnie eksponowana w drzewku dostępności. Algorytm określania dostępnej nazwy jest mocno złożony, ale w skrócie można uznać, że dla pól formularzy w HTML-u nazwa jest określana na podstawie połączonych z danym polem elementów label, w ostateczności na podstawie atrybutu [placeholder]. W tym formularzu elementów label nie ma, jest za to atrybut [placeholder]. Problem polega na tym, że w formularzu jest też pole select, które nie posiada ani label, ani tego atrybutu. Etykieta nie jest też dołączona przy pomocy ARIA (np. [aria=label]), na co zezwala specyfikacja. To oznacza, że pole select nie ma nazwy możliwej do określenia programowo, a więc kryterium 4.1.2 nie jest spełnione.

Niemniej to nie wszystkie problemy z formularzem. Atrybut [placeholder] co prawda spełnia kryterium 4.1.2, ale nie spełnia wspomnianego kryterium 3.3.2. Powodem jest fakt, że taka etykieta przestaje być widoczna dla użytkownika w chwili, gdy zaczyna wpisywać tekst do danego pola. Chyba problem ten jest najbardziej widoczny w autouzupełnianych formularzach. Wówczas często nie wiadomo, czy przeglądarka wypełniła pola poprawnie i trzeba ręcznie sprawdzać, czy na pewno dobre dane trafiły do odpowiedniego pola. Można by się spierać, czy w przypadku akurat tego formularza nie jest to rozwiązywane przez etykiety nad polami (bo kryterium 3.3.2 nie wymaga, by były one oznaczane w odpowiedni sposób, ale by były w odpowiednim miejscu), ale to już, jak dla mnie, akademicka dyskusja. Prawda jest taka, że zastosowanie tutaj label rozwiązywałoby wszystkie problemy i zamykało dyskusję.

Kolejny problem, jaki można zaobserwować na tej stronie, związany jest z kryterium 1.1.1, czyli alternatywą tekstową dla m.in. obrazków. Można to osiągnąć przy pomocy atrybutu [alt]. Specyfikacja HTML zawiera bardziej szczegółowe wymogi dotyczące doboru odpowiedniej wartości tego atrybutu. I tu trzeba przyznać: na stronie praktycznie wszystkie obrazki mają atrybut [alt]. Problem jest z drugą częścią kryterium: tekstowa alternatywa ma służyć tym samym celom, co obrazek. Już pierwszy obrazek na stronie zdaje się tę zasadę łamać. Mowa o logo strony umieszczonym wewnątrz linku prowadzącego do strony głównej. Zgodnie z wymogami opisanymi w specyfikacji HTML, w tym wypadku atrybut [alt] powinien opisywać, dokąd prowadzi link. W kodzie strony jednak ten obrazek ma atrybut [alt] o wartości logo dd. Nie dość, że link ten nie prowadzi do żadnego loga, to dodatkowo zostaje tutaj wprowadzony skrótowiec (dd – Dostępny Design; a przynajmniej tak myślę, bo skrót ten nie jest nigdzie rozwijany). Warto tutaj przy okazji zauważyć, że sam link ma ustawiony atrybut [aria-label] o wartości „logo dd”, który nadpisuje niejako informacje pobrane z obrazka, ale i tak ustawia całkowicie niepomocny opis linka. To z kolei jest niezgodne z kryterium 2.4.4.

Także inne obrazki mają źle dopasowane atrybuty [alt], np. grupa ikon. Ten obrazek jest ewidentnie ozdobnikiem i jako taki powinien mieć pusty atrybut [alt]. Wymóg ten jest zawarty zarówno w samym WCAG 2.1, jak i w specyfikacji HTML. Z kolei obrazek zawierający informację, skąd pochodzą fundusze na Dostępny Design, ma atrybut [alt] o wartości stopka ue, podczas gdy powinien zawierać spis poszczególnych źródeł finansowania.

Także kryterium 2.4.7 nie jest do końca spełnione. Większość linków zawierających obrazki (link do strony głównej, do firm, które współtworzyły projekt, do profili poszczególnych ekspertów itd.) nie ma widocznego wskaźnika focusu. Problem braku wskaźnika focusu staje się jeszcze bardziej widoczny, gdy przełączymy się na wersję mobilną strony. Wówczas można nawigować po zamkniętym menu nawigacyjnym strony.

Warto też zauważyć, że na stronie jest tzw. skip link (link „pomijający”), pozwalający przeskoczyć bezpośrednio do głównej treści. Problem w tym, że jest on po angielsku – a więc w języku innym niż reszta strony i fakt ten nie jest w żaden sposób zaznaczony (np. przy pomocy atrybutu [lang]). To jest niezgodne z kryterium 3.1.2. Inna rzecz, że nie ma sensu, aby jeden element na stronie po polsku był po angielsku. I to w dodatku taki, który ma podnosić dostępność!

Strona posiada także animacje „wchodzenia” poszczególnych elementów strony. Animacje te jednak nie respektują ustawień użytkownika w zakresie ograniczania ruchu. Można to wykryć przy pomocy odpowiedniego media query. Ten problem jest powiązany z kryterium 2.3.3.

I tak już na sam koniec trochę poza WCAG, bo w końcu w dostępności (czy, szerzej, inkluzywności) nie chodzi o to, żeby strona była zgodna z formalnymi wymogami. Chodzi o to, żeby jak najwięcej osób mogło bez żadnych przeszkód korzystać z danej strony czy aplikacji. Jedną z najbardziej cenionych technik osiągania tego jest Progressive Enhancement (Stopniowe Ulepszanie). Technika ta polega na tworzeniu strony/aplikacji warstwowo. Każda kolejna warstwa dokłada nowe funkcje. Natomiast te najniższe dostarczają najbardziej podstawowego doświadczenia. Dzięki temu różne urządzenia dostaną stronę dostosowaną pod swoje możliwości. W ekstremalnych przypadkach taką podstawową warstwą może być „goły” HTML. Z kolei w przypadku najnowszego Chrome’a uruchomionego na mocarnym kompie użytkownik dostanie pełne doświadczenie, z toną JS-a itd. Progressive Enhancement jest już tak mocno zrośnięte z dostępnością, że… niektórzy nie widzą już różnicy. Dlatego oczekiwałbym, że strona poświęcona projektowaniu uniwersalnemu będzie właśnie wykonana przy pomocy tej techniki. Tak jednak nie jest. Strona bowiem wymaga działającego JS-a, żeby w ogóle pokazać jakąkolwiek treść. A wszystko z powodu animacji. Strona jest domyślnie ukryta i dopiero animacja w JS-ie ją pokazuje. A można to zrobić właśnie w duchu Progressive Enhancement: domyślnie pokazywać stronę i dopiero, gdy JS faktycznie będzie działał, ukryć ją i wprowadzić animacje. Oczywiście respektując przy tym ustawienia użytkownika co do ograniczania ruchu.

I tym oto sposobem artykuł powstał, bo Comandeer dostrzegł jedno zdanie w stopce i się z nim nie zgodził…