Kilka słów wstępu

Tekst ten nie odnosi się tylko do stron wykorzystujących system WordPress jako CMS. Będzie tutaj kilka informacji ogólnych, które stosuje się do wszelkiego rodzaju stron z dostępnością dla osób niepełnosprawnych. Z racji, że sami korzystamy z systemu WordPress w roli bazy do zarządzania treścią na stronach, większość przykładów będzie opierać się właśnie o ten system.

Spis treści

Co to jest WCAG 2.1?

Na początek przytoczmy szybko, czym jest WCAG 2.1. Web Content Accessibility Guidelines poza tym, że jest to bardziej dopracowana wersja wcześniejszego WCAG 2.0, jest głównie zbiorem dokumentów opierających się o ustawę Parlamentu Europejskiego o dostępność stron internetowych oraz aplikacji mobilnych. Dostępność jest obowiązkowa dla podmiotów publicznych czyli np. sektor finansów publicznych, państwowe jednostki organizacyjne, czy też osoby prawne, ale także niektóre organizacje pozarządowe oraz jednostki dysponujące finansami publicznymi.

W praktyce oznacza to także zbiór kryteriów, jakie powinna spełniać strona / aplikacja w obszarach Postrzegalność, Funkcjonalność,  Zrozumiałość i Solidność, aby można było ją nazwać dostępną dla niepełnosprawnych.

Czy potrzebuję WCAG 2.1 na stronie?

Jak zostało napisane to wyżej – na chwile obecną obowiązkiem posiadania tego standardu objęte są instytucje państwowe, jednostki samorządu terytorialnego oraz wszystkie podmioty podlegające pod nie. Wymóg ten muszą również spełniać jednostki dysponujące finansami publicznymi. Za takie podmioty uznaje się:

  • Przedszkola, żłobki, szkoły publiczne oraz wyższe;
  • Urzędy miast, powiatu, gmin, wojewódzkie i marszałkowskie;
  • Agencje rządowe;
  • Domy kultury, publiczne muzea i galerie sztuki;
  • Sąd i prokuratura na wyższych szczeblach;
  • Policja, straż miejska, straż graniczna;
  • Zakłady karne;
  • Związki metropolitalne.

Na ten moment, jeżeli nie kwalifikujemy się pod żadną z powyższych grup to wdrożenie standardu WCAG nie jest od nas wymagane, a jedynie jest naszą dobrowolną inicjatywą skierowaną w kierunku osób niepełnosprawnych, aby ułatwić im poruszanie się na naszej stronie.

Od strony biznesowej otwieramy możliwości dla grupy potencjalnych Klientów, bowiem osoby niepełnosprawne stanowią prawie 1/7 ludności na świecie i również korzystają z internetu.

Jakie są obszary i poziomy WCAG 2.1?

Standard WCAG 2.1 dzieli się na 3 typy poziomów i dotyczą one stopnia dostępności pod niepełnosprawność:

Poziom A – oznacza minimalne wymogi, które musza zostać spełnione. Jeśli się tak nie stanie, treść opublikowana na stronie nie będzie dostępna dla części użytkowników z niepełnosprawnością.

Poziom AA – to zalecane do wdrożenia aspekty, które znacząco ułatwiają odbiór treści przez osoby niepełnosprawne.

Poziom AAA – oznacza wytyczne, które w pełni umożliwiają korzystanie z serwisu osobom z najróżniejszymi przypadłościami niepełnosprawności.

Poziomy uzupełniają się tz. chcąc zapewnić standard na poziomie AAA, musimy spełnić również wszystkie wymagania z poziomów A/AA.

Dodatkowo omówmy teraz obszary, na jakie dzieli się standard WCAG:

Postrzegalność – wszystkie informacje oraz interfejs musi być w pełni dostępny dla zmysłów użytkowników.

Funkcjonalność – interfejs musi w pełni umożliwiać swobodną nawigację po stronie.

Zrozumiałość – interfejs i obsługa interfejsu muszą być zrozumiałe dla odbiorcy.

Solidność – redagowanie treści w sposób taki, aby była prawidłowo interpretowana przez różnego rodzaju oprogramowania oraz technologie wspomagające np. czytniki dla osób niewidomych.

Wydawać by się mogło, że powyższe obszary są dość oczywiste i wdrażane są przy każdej stronie internetowej. Niestety tak nie jest. Weźmy przykładową zasadę z obszaru Funkcjonalność z pierwszego stopnia:

2.1.1 Klawiatura (Poziom A)

Wszystkie funkcjonalności w treści są obsługiwane za pomocą interfejsu klawiatury, bez wymogu określonego czasu użycia poszczególnych klawiszy, z wyjątkiem sytuacji, kiedy dana funkcja wymaga wprowadzenia informacji przez użytkownika w oparciu o ścieżkę ruchów, a nie w oparciu o punkty końcowe wejścia.

W przypadku wielu stron można zauważyć, że ta dość oczywista opcja nie występuje na każdej stronie. Za przykład niech posłuży nawigacja z menu zwykła lub rozwijanym dropdownem / otwieranym sidebarem.

Zrób mały test dla samego siebie. Włącz jakikolwiek czytnik ekranu np. windowsowy Narrator. Sprawdź teraz czy jesteś w stanie na swojej stronie bez problemu poruszać się przy pomocy samej klawiatury. Zacznij od wyżej wspomnianej nawigacji, a potem przejrzyj każdą podstronę. Dla zwiększenia autentyczności testu możesz poprosić o to osobę, która nigdy nie była na Twojej stronie internetowej i nie widziała jej graficznego układu.

Jak wiele utrudnień napotkałeś albo napotkała taka osoba? No właśnie… Na takich detalach również polega dostępność strony.

Problem z podejściem do tematu dostępności, czyli zróbmy to wtyczką lub byle jak.

Wiele osób, które dążą do zorganizowania dostępności swojej strony podchodzi do tego bez większego zagłębiania się w temat – no bo po co? Zdarza się, że takie osoby myślą: “nie jestem informatykiem i taka wiedza jest mi niepotrzebna, a przecież mogę sobie to zrobić wtyczką do WordPressa”. Pokażemy teraz na bardzo prostym przykładzie, dlaczego taka wtyczka niczego nam nie załatwia. Załóżmy, że naszą stronę odwiedza osoba kompletnie niewidoma.

Przyjrzyjmy się jednej z najpopularniejszej wtyczek w tym temacie, która zapewnia nam dostępność jednym kliknięciem. Dodaje ona nam menu kontekstowe z ułatwieniami (i tylko tyle). Co oferuje od strony użytkowej?

  • Powiększenie i pomniejszenie tekstu;
  • Skalę szarości;
  • Wysoki lub negatywny kontrast;
  • Podkreślenie linków;
  • Zmianę fontu na bardziej czytelny.

I oto wszystko, co dana wtyczka oferuje w ramach dostępności. “Już, gotowe. Mamy WCAG na stronie. Osoba niewidoma na pewno nie będzie miała problemu korzystania ze strony, bo może sobie teraz powiększyć tekst, aby był dla niej czytelny nawet jak nie widzi”.

Powyższe podsumowanie jest oczywiście sarkastycznym wyrazem tego, w jaki sposób działa ten proces przy rozwiązaniu tego zagadnienia za pomocą wtyczek.

Niestety prawda jest taka, że wtyczki sugerujące dostępność paroma kliknięciami niczego nam nie załatwiają, a co najwyżej dodadzą parę narzędzi do strony, które potencjalnie mogą ułatwić coś wybranej grupie osób, a patrząc po tym co oferują – ułatwiają korzystanie tylko osobom niedowidzącym lub ślepotą braw. No bo naprawdę – po co osobie niewidomej możliwość powiększania sobie tekstu? Na świecie jest 45 milionów osób niewidomych, a w samej Polsce jest ich ponad 150 000. Instalacją takiej wtyczki w żaden sposób nie umożliwiliśmy możliwość korzystania ze strony.

Tak osoba niewidoma widzi możliwości naszej wtyczki zapewniającą dostępność:

Przyjrzyjmy się teraz innemu przykładowi, który faktycznie takiej osobie znacząco pomoże poruszać się po stronie i zrozumieć jej zawarte treści.

Jednym z fundamentów dostępności strony dla osoby niewidomej jest zbudowanie kodu strony w taki sposób, aby był on w pełni semantyczny, wykorzystywał technologię WAI-ARIA, a konkretne informacje są bardziej zrozumiałe dzięki znacznikom mikrodanym schema.org.

Czym się różnią powyższe screeny kodu strony? Prawy zrzut przedstawia kod strony zbudowanej na Elementorze z zainstalowaną wspomnianą wcześniej wtyczką. Co się zmieniło? Nic.

Pisanie semantycznego kodu jest jednym ze standardów programowania stron internetowych. Niestety gotowe motywy stron internetowych są raczej pisane szybko w celach sprzedażowych i rzadko stosowana jest tam semantyka, a narzędzia typu Elementor nie generują żadnej semantyki.

Technologia ARIA i mikrodane pozwalają w logiczny sposób czytnikowi lub syntezatorowi odczytać treść strony, a co za tym idzie – jest to bardziej zrozumiałe i pomocne dla odbiorcy. W poniższym przypadku mamy zajawkę wpisu blogowego zbudowanego o semantyczny kod, a także z wykorzystaniem w/w technologii:

Na pierwszy rzut oka widać znaczącą różnice w logice kodu. Niestety, brak semantyki dyskwalifikuje naszą stronę z bycia dostępną, a sama w sobie semantyka jest standardem przy pisaniu stron internetowych oraz jedną z wielu wytycznych, które należy spełniać przy dostępności.

Oczywiście na semantycznym kodzie temat się nie kończy, a tak naprawdę dopiero zaczyna. Pomijając prace programistyczne związane z dostępnością – na późniejszym etapie redagowanie takiej strony również powinno być prowadzone zgodnie ze standardem poprzez np. mikrodane w treściach, uzupełnianie altów grafik, pliki PDF przygotowane z myślą o dostępności czy nawet np. transkrypcje video.

Deklaracja dostępności

Do przystosowanej pod dostępność strony internetowej powinna być wykonana deklaracja dostępności opisująca m.in.

  • Kto przeprowadzał audyt i na jakiej podstawie została sporządzona ocena dostępności;
  • Jaki standard (poziom) spełnia strona internetowa;
  • Jakie ułatwienia wprowadzają one dla użytkowników;
  • Co nie zostało przystosowane wraz z wyjaśnieniem;
  • Możliwość zgłoszenia problemu z dostępnością;
  • Datę złożenia deklaracji oraz ostatniej aktualizacji strony.

Jest tego oczywiście znacznie więcej.

Temat deklaracji szerzej omówimy w kolejnym artykule, bo jej obecność jest bardzo ważna. Niestety gotowe wtyczki nie sporządzą za nas deklaracji dostępności, a nikt świadomy wszystkich aspektów technicznych związanych z dostępnością nie podpisze się pod stroną, której dostępność została zrobiona wtyczką.

Co za tym idzie? W przypadku braku takiej deklaracji, którą realizuje się na bazie wdrożonej dostępności strony internetowej, możemy ponieść konsekwencje.

Czy za brak lub brak dostępności można dostać karę?

Tak. Oczywiście warunek ten muszą spełniać podmioty gospodarcze, które zostały wymienione na początku artykułu. Zgodnie z Ustawą o dostępności cyfrowej, niespełnienie wymogów dotyczących dostępności może pociągać za sobą nałożenie na instytucję kary finansowej. Konkretne cyfry przedstawiają się w ten sposób:

  • Brak zapewnienia dostępności – do 10 000 zł;
  • Brak deklaracji dostępności – do 5000 zł;
  • Brak dostępności dla Biuletynu Informacji Publicznej oraz elementów stron opisanych w Art. 8 ust. 2 pkt 2 – do 5000 zł.

Poza karami finansowymi, podmioty mogą utracić możliwość dofinansowania.

Kontrolę naszego serwisu i nałożenie kary może przeprowadzić Ministerstwo Cyfryzacji. Przypominamy, że pod koniec tego roku będzie miało miejsce pierwsze sprawozdanie do Komisji Europejskiej, a na rok 2022 przewiduje się pierwsze kary za brak deklaracji dostępności strony internetowej.

Jak sprawdzić czy moja strona spełnia WCAG?

Przede wszystkim nie należy sugerować się wtyczkami zapewniającymi dostępność strony w kilku prostych krokach i stwierdzać, że po ich instalacji mamy temat gotowy. Jeżeli nie jesteśmy osobami technicznymi lub posiadającymi wiedzę o dostępności, to nie należy także ufać naszej intuicji, bo jako osoby sprawne nie zauważamy wielu aspektów, które odczuć może osoba niepełnosprawna.

Najbardziej stosownym sposobem weryfikacji będzie przeprowadzenie audytu dostępności, na bazie którego następuje później wdrożenie standardu oraz sporządzenie deklaracji dostępności. Taki audyt najlepiej wykonać w firmach specjalizujących się w dziedzinie dostępności cyfrowej. Można również skorzystać z automatycznych usług audytujących stronę internetową, ale niestety nie będzie to takie dokładne, jak audyt i testy wykonane przez wykwalifikowanych specjalistów.

Podsumowanie

Temat dostępności stron internetowych jest bardzo obszerną kwestią wymagającą dużej wiedzy i doświadczenia związanymi z programowaniem stron internetowych. Co więcej, opiera się ona o doświadczenia użytkownika, umiejętności przewidywania zachowań i sytuacji użytkowników z niepełnosprawnością oraz ogólnych dobrych praktyk robienia stron internetowych.

Nie pozwólmy sobie wmówić, że wszystkie wyżej wymienione rzeczy jesteśmy w stanie załatwić instalacją jednej wtyczki do WordPresa. WordPress ma dużo możliwości zrobienia czegoś samemu, ale niestety dostępność nie zalicza się do grona takich rzeczy i wymaga dokładnego podejścia do tematu, bo pamiętajmy – mówimy o czymś, co poparte jest ustawą.

Źródła: dostepnastrona.pl, gov.pl, lepszyweb.pl, widzialni.org