Nie dziwi Cię, że ani w necie, ani na meetupach, ani na konferencjach prawie nikt nie opowiada konkretnych case’ów dostępnościowych? Takich klasyków opisanych „po bożemu” – tak było, zrobiliśmy to i to, przybuliliśmy za to cirka tyle, udało się nam to i to, a to schrzaniliśmy. Szukasz i nie ma… Sam wiele razy próbowałem namówić moich klientów do podzielenia się swoimi doświadczeniami z takiego wdrożenia – udało się raptem z 5 razy. Skąd ten opór? Powodów jest pewnie wiele, ale postanowiłem poznęcać się nad jednym z nich. Nazywam go „wszystko albo nic”.
Na czym polega „wszystko albo nic”
Polega to na tym, że nie mówimy o dostępności naszych rozwiązań dopóki nie zrobimy wszystkiego na tip top.
W przypadku instytucji publicznych i telekomów łatwiej teoretycznie zidentyfikować „tip top”, bo mają one narzucony prawnie obowiązek zgodności z WCAG 2.0 na poziomie AA. W przypadku całej reszty graczy, nie jest to już tak jednoznaczne ale najczęściej oznacza… dokładnie to samo. Czyli tip top to pełna zgodność z WCAG na określonym poziomie.
W takiej rzeczywistości wiele osób zakłada następujący scenariusz – będzie audyt zgodności z WCAG, błędy jak wyjdą to poprawimy w 3, no dobra 4, tygodnie i po temacie. Wtedy będziemy już dostępni i piknie to zakomunikujemy miastu i światu.
Tyle że taki scenariusz to najdelikatniej mówiąc „kupka” i zdarzył się co najwyżej kilku dostępnościowym jednorożcom.
Dlaczego „wszystko albo nic” jest bez sensu
Jest to bez sensu, bo bazuje na różnych, mylnych założeniach. Darujmy je sobie żeby ich nie powielać w googlach. Jest po prostu tak:
1. Dostępność to nie projekt do odhaczenia
I „projekt” i „odhaczenie” sugeruje szybki temat do realizacji, po upływie którego wszystkie problemy będą rozwiązane. Tyle że przy dostępności to tak nie zadziała. Można w ten sposób co najwyżej wdrożyć jakiś jej element np. kolorystykę czcionek, która będzie przyjazna dla użytkowników. Jest problem z kontrastem czcionki do tła – ustalamy kolory, które spełniają wymogi kontrastowe – testujemy – wdrażamy je np. w CSS i Design System- zamykamy temat.
Wdrożenie pełnej zgodność z WCAG w ten sposób to mrzonka, albo co najmniej gwarancja wrzodów żołądka.
Dostępność (nawet rozumiana jako zgodność z WCAG) jest bardziej złożona i musi się dziać. Jako takie dzianie się dostępności rozumiem Inclusive Design – sposób projektowania, ale też wdrażania, w efekcie którego powstaje rozwiązanie dostępne dla maksymalnie wielu użytkowników.
Projektowe traktowanie całościowej dostępności wynika też bardzo często z myślenia o niej jako o oddzielnej dziedzinie projektowania, co gorsza niepowiązanej z innymi cechami danego rozwiązania. Więc teoretycznie skoro jest problem z dostępnością, to robimy nowy, oddzielny projekt i jedziemy z koksem. Tyle, że w tym samym czasie serwis czy apka żyje i rozwija się w swoim tempie, a my walczymy w naszym projekcie tylko z historycznymi już problemami.
2. Ludzie nie czekają na tip top
Większość z tych, którzy korzystają z faktu, że serwis jest stworzony w pełni zgodnie z WCAG nigdy nie słyszała i nie usłyszy o takim standardzie. Dostępność to dla nich po prostu „jest, działa, mogę, rozumiem”. Czy to znaczy, że WCAG jest bez sensu? Nigdy w życiu, ale to przewodnik, a nie cel ostateczny. Przynajmniej nie dla tych, dla których robisz Internety. Oni nigdy nie będą Cię sprawdzać, czy na pewno wszystko jest na tip top – chyba, że będą się strasznie nudzić, na maksa zaleziesz im za skórę, albo będą chcieli zarobić na tym, że masz obowiązek prawny zgodności z WCAG, a go w jakimś miejscu nie spełniasz.
Nie czekaj zatem z wdrożeniem idealnym. Warto na bieżąco wrzucać nawet najmniejsze modyfikacje, które sprawią, że dane rozwiązanie działa po prostu lepiej, bo jest bardziej dostępne. Zrobiłeś te nowe kolory czcionek? Wrzucasz. Dorobiłeś 2 skip linki? Wrzucasz. Itd.
3. Konkurencja nie czeka tylko na Twój brak tip topu
Słyszałem kiedyś w kuluarach konferencji prezentującej wyniki Raportu dostępności Fundacji Widzialni – „Zobacz, zobacz. Spadli!! HEHEHE. A my cały czas na trzecim[1] miejscu. Puszczaj szybko tweeta ministra!” Ale mili Państwo, to jest tylko patologia.
Zwłaszcza przy żyjących i rozwijających się serwisach takie porównania nie mają sensu. Bo jeden z nich dodał w ostatnim roku np. gigantyczny dział multimediów i oddzielną sekcję do obsługi organizowanych przez siebie wydarzeń i dał radę ograć to dostępnościowo, tak że ludzie z tego korzystają. A „Państwo HEHEHE” w tym samym czasie wycięli np. kilka wcześniej problematycznych dostępnościowo działów. I co w tej sytuacji warte jest ich trzecie miejsce w rankingu?
Kurde, to jednak wychodzi, że ta konkurencja może czekać na Twój brak tip topu, żeby o tym zatweetować? Dobra, ale jeśli robisz dostępność na bieżąco, to możesz mieć to głęboko w… poważaniu.
Dostępnościowcy! Też mamy swoje za uszami!
- bo sprzedajemy głównie audytu zgodność z WCAG 2.0/2.1 i mniej lub bardziej świadomie stawiamy w naszych wypowiedziach znak równości między WCAG, a dostępnością,
- bo w raportach z tych audytów opisujemy po kilkadziesiąt czy kilkaset problemów i zrównujemy je do jednej kategorii „Niezgodność z WCAG”, a tym samym dobijamy swoich klientów i ich zainteresowanie tematem,
- bo piszemy tak techniczne raporty i teksty, że ludzie wymiękają próbując je zrozumieć… a w końcu zrozumiałość też wchodzi w zakres dostępności, nie?
- bo czasem zbyt łatwo robimy podśmiechujki z klientów konkurencji, u których znajdziemy jakąś niezgodność z WCAG albo wprost wbijamy do klienta konkurencji z klasycznym „kto Panu to tak sp…”
Jak uniknąć „wszystko albo nic”
Po prostu nie zakładaj, że poziom „wszystko na tip top” osiągniesz od razu. Działaj na bieżąco, konsekwentnie i mów o tym co zrobiłeś, robisz i planujesz jeszcze zrobić w temacie dostępności. Ludzie to docenią.
1. Jasno i na bieżąco mów co masz, a czego nie
Tu mamy polską nowinkę. Zgodnie z obowiązującym w Polsce prawem instytucje publiczne mają obowiązek publikować deklaracje dostępności, w której „jak chłop krowie na rowie” piszą, które elementy WCAGa spełniają w swoim serwisie i aplikacji, a których nie. To dobre miejsce, żeby nawet w tych punktach o niespełnionych elementach nie zlewać się rumieńcem ale napisać coś do ludzi np. kiedy planowane jest poprawienie tego elementu, albo jak sobie radzić z obecnymi utrudnieniami. Deklaracja musi zawierać także informacje o tym gdzie i jak zgłosić problem z dostępnością i co się z takim zgłoszeniem zadzieje.
Dobre to. Warto używać nawet jak nie ma się obowiązku prawnego publikowania takiej informacji.
2. Wyciśnij coś dobrego nawet z tego „czego nie masz”
Coś nie jest jeszcze w Twoim serwisie czy aplikacji wdrożone zgodnie z WCAG, albo może sprawiać problemy dostępnościowe? Zaplanuj jak to poprawisz, ale póki co pomyśl o rozwiązaniu alternatywnym i jasno o nim powiedz użytkownikom. Nie działa Ci w pełni dostępnie np. jakaś interaktywna mapa, a jej poprawa wiążę się ze zmianą dostawcy tej technologii, albo co najmniej kilkutygodniową wymianą maili? Daj informację, że można zadzwonić lub napisać do Centrum Obsługi i uzyskać informacje prezentowane na mapie. Ludzie na bum cyk cyk to docenią. Jeszcze może się okazać że stworzysz przez to 3 razy lepszy kanał przekazywania informacji prezentowanych dotąd tylko na tej mapie.
3. Włączaj dostępność do projektowania i UX
Dzięki temu dostępność naturalnie wchodzi w proces tworzenia nowych rozwiązań w Twojej organizacji i po prostu zaczyna się dziać. Nie czekasz na jakiś raport z audytu, nie czekasz aż Ci przywali na facebooku „brakiem tip topu”, tylko robisz swoje. Małymi kroczkami. Dzisiaj np. fokus klawiatury, a przez najbliższy tydzień przegląd Design Systemu przy wsparciu jakiegoś narzędzia symulującego zaburzenia widzenia kolorów i zapytanie o jego czytelność swojego dziadka.
4. Zrób show z procesu!
Mam wrażenie, że dwa główne powody „wszystko albo nic” to: „kac moralny” (powinniśmy być dostępni, bo w sumie korzysta z tego niemal każdy no i jeszcze to prawo) albo „powiemy jak już wszystko będzie” (zrobimy fajną konferencję jak już się ogarniemy, przykleimy sobie logo certyfikatu „100% dostępni”, puścimy to w newsletterze i jeszcze wpiszemy sobie w raport CSR).
A gdyby tak w super otwartej komunikacji spytać użytkowników z czym mają problemy? Nie tylko tych, którzy już korzystają z Twojego rozwiązania, ale też innych, bo może ktoś nie korzysta właśnie ze względu na hard core’owy brak dostępności. Potem stworzyć listę rzeczy do poprawy, podzielić się nią z ludźmi i spytać znów, która powinna zostać poprawiona w pierwszej kolejności. A może zacząć prowadzić twitterową albo instagramową powieść „co dziś zrobiliśmy dla dostępności”? Albo nagrodzić klientów, którzy znajdą najwięcej problemów, a piwo postawić temu kto najwięcej ich rozwiąże? Albo zarąbać w maju z racji Global Accessibility Awareness Day wszystkie myszki w firmie i zobaczyć jak Twoi kumple radzą sobie nawigując samą klawiaturą? Szukasz więcej pomysłów? Napisz do mnie 😊
Nie od razu Rzym zbudowano
Podejście „wszystko albo nic” nie działa i potrafi spalić fajnie zapowiadający się projekt. Zdecydowanie lepiej robić mniej ale częściej. Warto dobrze planować swoje działania, ale też ich efekty wystawiać na ocenę innych, głównych zainteresowanych. Dostępność to cel, zgodność z WCAG to kierunek, a cały proces to projektowanie włączające.
PS.
Aha, jest jeszcze gorsze cholerstwo niż „Wszystko albo nic”.
To „Nic, a jakby wszystko”. Widziałem kilka takich dzieł, gdzie po dodaniu obsługi
klawiaturą (dobrze widoczny fokus i 2 skip linki) ogłaszana była całemu światu,
pełna dostępność serwisu. Czasem okraszona jeszcze jakimś logo „WCAG 2.0 AAA
compliance”. Jeśli robione jest to świadomie, to jest po prostu kłamstwo i totalna
siara.
[1] Z litości dla wypowiadających miejsce zmienione.