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.

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 do Wordpressa.

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 pola 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, 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 nie należy do testów funkcjonalnych, więc testujemy ją na końcu.

Z jednej strony można byłoby to uznać za oczywistą prawdę, ale z drugiej strony co jeśli funkcjonalność nie jest dostępna z klawiatury lub odwrotnie jest dostępna z klawiatury, ale nie działa zbyt dobrze, jest to ewidentny test funkcjonalny, a jak wiadomo testy funkcjonalne wykonuje się w pierwszej kolejności. To pokazuje, że testów dostępności nie powinno się odkładać na sam koniec.

Mit 15: Spełniłem kryteria 2 lub 3 poziomu więc, nie muszę się martwić o kryteria poziomu pierwszego.

Szczerze, raczej nie jest możliwym, aby można było osiągnąć 2 lub 3 poziom dostępności, bez spełnienia kryteriów poziomu pierwszego. Nawet jeśli jakieś narzędzie do walidacji tak wykazuje.

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 czy wszystkie podstawowe kryteria są nadal spełnione.

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ę przełączać na stronę dostępną i czy aby nie będą mieli z tym problemów?

Mit 17: Zweryfikowałem/liśmy nasz produkt z wymaganiami i spełnia on założenia dostępności.

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.

Ustawienia tła strony

Obecnie ustawione tło

.JPG
Uwaga! Zmiana domyślnego tła, może nieco wydłużyć wczytywanie się strony.

Ustawienia odtwarzacza

Ustaw w jaki sposób mają być odtwarzane utwory: