Pora na kolejny wpis z serii o nieoczywistych problemach, które czekają na organizacje próbujące wdrożyć dostępność cyfrową pod strzechy. Tym razem chciałem rzucić nieco światła na problem, który jest wynikiem pewnej, rzec by można, klęski urodzaju, a raczej zaangażowania.
Kiedy wszystko idzie (aż za) dobrze
Większość moich klientów ma problemy z wdrażaniem dostępności cyfrowej. To raczej normalne. Koszt, brak odpowiedniej wiedzy i doświadczenia w zespołach, galimatias wynikający z chęci dostosowania się do aktu EAA, a do tego oczywiście praca nad całą resztą typowych zagadnień projektowych. I wszystko naraz. Rodzą się opóźnienia i wątpliwości, a na podłogę spada coraz więcej wyrwanych z cebulkami włosów.
Dygresja: dowiedziałem się ostatnio jak działa procedura transplantacji włosów i od tego czasu bardzo się cieszę, że mężczyźni w mojej rodzinie są włochaci do ostatniego tchnienia. Nie sprawdzaj, jak to się robi. To nie jest piękne. Dziękuję, wracamy do tematu.
Zdarzają się jednak takie organizacje, w których gadki o dostępności padają na bardzo żyzny grunt. Ludzie są już zmęczeni produkcją chały, istnieją wymogi prawne, przeciwko którym nikt nie chce fikać, a co najlepsze, znajdą się nawet pieniądze na to, żeby to wszystko rozwijać. Można zrobić odpowiednie audyty, szkolenia i co tam jeszcze jest potrzebne. Krótko mówiąc, z perspektywy zewnętrznego pomocnika takiego jak ja, jest to sytuacja cud-miód. Ale czy na pewno?
Więcej niż można zjeść
Z wprowadzaniem dostępności do pracy jest trochę jak z gotowaniem (pisząc to, zakładam, że odróżniasz dobre jedzenie — czyli gotowane z sercem — od niedobrego, gotowanego naprędce). Otóż, idea slow food działa i tutaj. Jak coś jest dobre, to musi zająć trochę czasu. Nie da się obrócić Wisły kijem, a przynajmniej nie od razu, no i ten Kraków też nie powstał w 10 minut. Musieli się trochę ziomkowie naprodukować, żeby go postawić na nogi. A tutaj często widać problem; wszyscy chcą wszystkiego od razu. Osoby szefujące myślą, że reszta kontyngentu nauczy się pracy z dostępnością w tydzień. Te uczące się osoby mają natomiast nadzieję, że od momentu, w którym będą już rozróżniać <aria-label>
od <label>
, wszystko pójdzie jak trzeba i znajdzie się i kasa, i miejsce na badania i pisanie specyfikacji i audyty i co tylko — bęc, proces projektowy będzie od razu taki, jak trzeba.
W rezultacie wszyscy jarają się tak bardzo, że zaczynają ustawiać sobie nierealistyczne cele („wszystko będzie dostępne na poziomie AA w miesiąc!”), pracują z coraz większą prędkością, na czym cierpi dokładność, a dodatkowo tak się rozpędzają, że przeoczają zupełnie etapy planowania, badań i określania wymagań. Ten miszmasz skutkuje dziwną hybrydą figmocentrycznego tworzenia usług i produktów cyfrowych, które dalej zorientowane jest na nic innego jak na wypluwanie kolejnych artefaktów.
Całkiem jak z kiełbasą z rożna na festynie w Klepaczce. Załadujesz całą do buzi na raz to i owszem, smacznie pewnie będzie, ale źle zadzieje się w środku i do niczego dobrego to nie doprowadzi. Nie mówię nawet o tym, jakie przeżycia będą czekać Cię następnego dnia. Dość powtórzyć dobrą, szkocką maksymę: shit in, shit out.
Daj. Se. Czas.
Jeśli na Twe barki spłynął słodki obowiązek i przyjemność zajmowania się nowym dla Twojego otoczenia tematem dostępności cyfrowej, daj sobie czas. Daj czas innym. Zauważ, że tego nie da się zaimplementować od razu. Nie da się też tego zrobić porządnie bez:
- Inwestycji czasu w zaplanowanie całego procesu.
- Zrozumienia, gdzie Twoja organizacja ma obecnie „dziury” w tym temacie.
- Takiego zaplanowania działań, które pozwoli na poprawianie istniejących błędów i jednoczesną naukę, dzięki której unikniesz błędów w przyszłości (to jest, swoją drogą, największy problem z zatrudnianiem „ekspertów”, którzy wchodzą, mówią, jak jest, po czym wychodzą, zostawiając zespoły w ciemnej dupie).
- Wsparcia na etapie nauki — po to, żeby te wszystkie zaangażowane w temat osoby czuły, że idą do jednego celu i, że ktoś im w tym pomaga.
A przede wszystkim wymaga to przyglądania się postępom i dynamicznej oceny sytuacji. Nie wszystko musi być dostępne od razu. Pomijając heydonowy gryps, który brzmi: „niektórzych rzeczy nie powinno być w ogóle”, trzeba patrzeć na to tak: czas pomaga opracować rozwiązania, które działają dużo lepiej, niż takie natychmiastowe, sklejane taśmą klejącą i gumą arabską.
Jak długo to może trwać?
Trudno powiedzieć. Jeszcze mi się nie zdarzyło pracować z organizacją, w której udałoby się wprowadzić dostępność w proces software development w tydzień, a nawet w miesiąc. Zdarzało mi się pracować z takimi firmami, które potrzebowały na to kilku, a nawet kilkunastu miesięcy. Przeciętnie okres paru miesięcy wystarczy do tego, żeby całość zaczęła działać jako-tako. W miejscu osadza się praktyki, które pozwalają na rozważne projektowanie i pisanie kodu. Implementuje się metody badawcze i testowe. Całość spina się odpowiednim programem wsparcia dla zespołów wykonujących pracę projektową.
Dopóki nie zapanuje powszechna zgoda na to, że projektujemy dostępnie po to, żeby ludziom było lżej i wygodniej a nie po to, żeby wypełniać potrzeby kapitalistycznej maszyny do zarabiania kasy, to lekko nie będzie.
Zwalniajmy zatem — nie tylko przed weekendem, ale po to, by się nie przeżreć dostępnościową kiełbasą.
Zapraszam na warsztaty
Pod koniec miesiąca poprowadzę dwudniowe warsztaty, które wprowadzą Cię w zagadnienia dostępności cyfrowej. Sprawdź je. Cena jest dobra, prowadzący też całkiem daje radę (ha ha), a więc warto.
Dodaj komentarz