Opcje dostępności

Mity na temat dostępności - część 2

Opublikowano: , aktualizacja: 2017-12-31

Ciąg dalszy omawania powstałych mitów wokół tematu dostepności stron www.

Przeczytaj również część pierwszą .

Mit 11: Gotowe szablony i wtyczki typu „Accessible - ready” załatwiają sprawę dostępności.

Nie można, a wręcz nie wolno twierdzić, że jest się dostępnym, jeśli używamy gotowych szablonów czy wtyczek wpierających dostępność. Nie ma nic gotowego i sprawdzonego co zapewni stuprocentową dostępność. Nawet po zainstalowaniu takowych dodatków, strona nadal może być niedostępna.

Wystarczy, że wystąpi mała czkawka na łączach, która spowodujemże taki plugin się nie załaduje i cała ta psełdo "dostępność" oparta na nakładce przestaje istnieć.

Tzw. „gotowce” szablony czy pluginy typu „Accessible – ready” nie wystarczą. Mogą pomóc osiągnąć zgodność z zaledwie kilkoma wytycznymi WCAG, ale nigdy nie zapewnią dostępności.Nie można traktować dostępności jako „bonus”, swojego rodzaju dodatek do strony w postaci np. szablonu lub wtyczki na stronie.

Mit 12: Testowanie dostępności sprawdzonym i rekomendowanym narzędziem daje gwarancję znalezienia wszystkich błędów.

Żadne narzędzie nie daje gwarancji znalezienia wszystkich błędów, ba mało tego testowane tylko jednym narzędziem jest złe. W sieci można znaleźć różnej maści waliatory, jedne lepsze drugie gorsze, ale nigdy nie należy polegać tylko na jednym narzędziu, choćby było darmowe lub najwygodniejsze w użyciu. Automatyczne waliatory także nie są pozbawione wad i błędów. Dla przykładu jedno z narzędzi do testowania dostępności (po aktualizacji do nowszej wersji) zaczęło wykazywać na mojej stronie brak etykiety dla jednego z pól formularza pomimo, że ten takową posiada i nie jest ona ukryta. Dlatego do oceny mierzalnych automatem wymagań WCAG, zawsze należy używać kilku narzędzi (mniej więcej 2 do 3).

Mit 13: W projekcie osobami odpowiedzialnymi za dostępność są programiści.

Oczywiście, że nie tylko oni. Duży nakład pracy owszem leży po stronie programistów, ale równie dużą role odgrywają tu również analitycy, UI designer oraz osoby piszące/wstawiające tekst (content maker), testerzy, którzy muszą to wszystko później zweryfikować, a nawet główny odbiorca (product owner). Oni także odpowiadają za spełnienie niektórych wymagań dostępności1.

Mit 14: Testowanie dostępności, to testy niefunkcjonalne więc wykonujemy je na końcu.

Z jednej strony można byłoby to uznać za prawdę, ale z drugiej strony co jeśli funkcjonalność nie działa zbyt poprawnie tylko gdy wywołasz ją za pomocą klawiatury, to nie jest czasami test funkcjonalny...? Jak wiadomo testy funkcjonalne wykonuje jako jedne z pierwszych. To pokazuje, że testów dostępności nie powinno się odkładać na sam koniec. Poza tym co się stanie jak testy dostępności, które wykonasz na końcu wykażą sporą ilość błędów?

Będziesz fixować na szybko w nadziei, że nic innego nie zepsujesz? A może zablokujesz wdrożenie do póki nie zostaną poprawione..., szczerze w to wątpię? To może zrobisz często popełniany błąd przez managerów i wdrożysz produkt cyfrowy na produkcję z pominięciem dostępności i niespełnionym DoD?

Wykonuj testy dostępności jak najwcześniej, żeby później nie musieć odpowiadać sobie lub komuś na tego typu pytania.

Mit 15: Spełniłem wszystkie wymagane kryteria, więc nie muszę się dłużej martwić dostępnością

Jeśli zdołałeś zdobyć drugi lub wyższy poziom dostępności, to gratuluję. Jednak to nie zwalnia Ciebie lub twojego działu IT od sprawdzenia co jakiś czas, czy wszystkie kryteria są nadal spełnione. Zapewnianie dostępności to nie lista zadań do odhaczenia, ale ciągły proces podczas którego stale trzeba monitorować czy nie nastąpił regres.

Mit 16: Wersja tekstowa jest najlepszym rozwiązaniem.

Duplikując treść na stronie, w formie tylko tekstowej, doprowadzasz do redundancji danych, czyli powtarzania tekstów na Twojej witrynie, co z czasem powodować będzie zamieszanie i trudności w jej utrzymaniu. Poza tym, tylko tekstowa prezentacja danych pozbawia wielu użytkowników dodatkowych informacji, które zamieszczone mogą być w różnego rodzaju animacjach, filmach czy grafikach, które akurat są zamieszczone na niedostępnej wersji witryny. Powstaje więc jeszcze jedna kwestia do wyjaśnienia. Jeśli użytkownicy z problemami dostępności nie mogą używać „standardowej” wersji Twojej strony (bo jest niedostępna), to na jakiej zasadzie mieliby się przedostać na stronę tekstową i czy aby nie będą mieli z tym problemów?

Mit 17: Zweryfikowałem/liśmy produkt, wprowadziliśmy kilka zmian i uważam/y, że jest dostępny

Osobiście pokusiłbym się jedynie o stwierdzenie, że jest bardziej dostępny, niż w pełni dostępny.

Aby stwierdzić czy produkt (strona www lub aplikacja) jest dostępna należałoby odpowiedzieć sobie jeszcze na kilka pytań:

Czy oprócz testów różnymi narzędziami, serwis był weryfikowany manualnie?

Czy robiły to tylko osoby z IT czy może weryfikacja nastąpiła w formie audytu dostępności?

Czy na stronę www spojrzał ktoś z dysfunkcjami? Np. wzroku lub słuchu, a najlepiej osoba niepełnosprawna?

Czy serwis był testowany jakimkolwiek czytnikiem ekranu?

Czy dokumenty PDF (lub w innego typu) zamieszczone na stronie są dostępne?

Przypisy
  • https://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown
Smyku.pl
Smyku.pl

Zmień widoczność widżetów