Drugi potwór z szafy

Kontynuujemy serię wpisów na temat nieoczywistych problemów, które czekać mogą na Twoją organizację w momencie, w którym złapiesz się za głowę i krzykniesz: „Ojezu! Toć musim wprowadzić tę dostępność, a chyżo!”. Dzisiaj będzie o tym, jak połapać się w gąszczu platform cyfrowych, które nam przyszło brać pod uwagę w dostępnościowych planach. No to jedziemy.

Prawdziwy problem!

Pomysł na ten wpis nie wziął się znikąd. Wielu moich klientów na wieść o tym, że obsługiwać trzeba różne platformy cyfrowe prawie dostaje zapaści. Zwłaszcza, kiedy się nad nimi zastanowimy: Google Chrome na macOS i Windows. Safari na macOS. Edge (czyli dawny Mikrosoft Eksploder) na Wingrozie. I do tego mobilki. I jeszcze tablety i iPad. I telewizory. I mikrofalówki. Samochody. Rowery. Ekrany wbudowane w wanny. Zegarek. Naprawdę — życie nie jest lekkie. „Na czym to ma działać? A na czym testować?”, pytają klienci. Ja lekko się uśmiecham, bo miałbym chęć odpowiedzieć, że działać ma na wszystkim. A testować trzeba mądrze. A tak naprawdę to trzeba do tego podchodzić od zupełnie innej strony.

Powrót do źródła

Dosłownie i w przenośni. Odpowiedzią na tę kołomyję spowodowaną przez olbrzymią ilość kombinacji rozmiarów ekranu, platform software’owych i metod interakcji jest powrót do źródeł. Źródeł kodu HTML, JavaScript i CSS oraz aplikacji natywnych. Z dostępnością cyfrową jest bowiem tak, że kiedy budujemy rozwiązania według standardów i trzymamy się wskazówek, to większość rzeczy po prostu działa. Oczywiście, nawet najlepszy i najczystszy kod nie uchroni Cię od buby, jeśli ścieżka podróży użytkownika nie ma sensu, produkt nie trzyma się kupy, albo tekst, czyli copy, nie da się zrozumieć. Ale programowanie w zgodzie ze standardami ma olbrzymią zaletę z punktu widzenia dbałości o dostępność. A mianowicie, zapewnia minimum niezbędnej zgodności z technologiami asystującymi.

Dobrze zaplanowany, zaprojektowany i zakodowany będzie po prostu działał na (mniej więcej) wszystkim. Tak, serio. Oczywiście, przeglądarki internetowe w kombinacji z czytnikami ekranowymi, ale także innymi technologiami wsparcia dostępności, będą robić różne psikusy. Czasem trochę przypadkowo. Ale baza, podstawa, czy jak to nazwać — fundament? — będzie na tyle spoko, że rozwiązanie zadziała i dla cioci Kloci, i dla wujka Staszka.

Tylko bez paniki

W zasadzie mógłbym zacząć sprzedawać takie koszulki z napisem „tylko bez paniki”. Panika bowiem towarzyszy wielu zespołom stykającym się z dostępnością cyfrową po raz pierwszy. Osoby, onieśmielone ilością czekających ich testów, zmianami kontekstu i upierdliwością dokumentowania tego wszystkiego wolałyby najchętniej, aby ktoś pod nos podetknął im taki cheatsheet i powiedział: „sprawdź to i na tym i o, gotowe”. Tak niestety nie jest. Trzeba do tego podejść z otwartym umysłem, ale bez paniki.

Programowanie i testowanie aplikacji mobilnych jest pod tym względem dość proste (co nie znaczy, że każda nindża umie w to), bo, tak na końcu, mamy do czynienia z dwiema platformami: Androidem i iOS. Produkty Apple dość dobrze radzą sobie z dobrze napisanymi aplikacjami, a ogólny standard produkcyjny jest wyższy, chociaż oczywiście coraz więcej koszmarów opartych na rozwiązaniach hybrydowych. Na Androidzie może czekać nas masakra, no jasne, ale tam też da się programować z poszanowaniem zasad dostępności. Mimo to, sprawna osoba testująca oprogramowanie (czy to zajmując się developerką, UX, czy QA) da radę. Dobre planowanie, dobry projekt, standardy, postępowanie zgodnie z dokumentacją i będzie spoko.

Strony internetowe to trochę inna bajka. Te spierdzielić jest bardzo prosto, a więc trzeba się opanować.

Tworzenie stron internetowych w Metodologii Świętego Spokoju (MŚS)

Niniejszym ogłaszam, że ukułem powyższy termin dwie minuty temu i, że jaram się tym, że nie da się tego skrótu wymówić. Na przekór. Po to, żeby zapamiętać, jakie to ważne. Metodologia Świętego Spokoju wygląda tak:

  1. Zbadaj potrzeby swoich użytkowników i zastanów się nad tym, czy masz naprawdę jakiś problem do rozwiązania.
  2. Współpracuj z nimi cały czas, by zrozumieć, jak korzystają z technologii wsparcia dostępności.
  3. Projektuj swoje rozwiązania w sposób świadomy.
  4. Pisz kod w zgodzie ze standardami sieciowymi.
  5. Całość sprawdzaj na bieżąco z użyciem technologii wsparcia, do których masz dostęp i, z których korzystają Twoi użytkownicy.
  6. Jeśli się zakałapućkasz, sięgaj po WCAG. Uwaga: sięgaj po niego cały czas, jeśli dopiero zaczynasz układać te klocki.
  7. Nie panikuj. To, co nie działa popraw. To, co poprawione, sprawdź.
  8. I tak w kółko.

Proste, no nie?

On se jaja robi!

Zanim to Ci przyjdzie do głowy, pamiętaj o tym, o czym już napisałem: metodą na zapobieżenie panice wynikającej z mnogości opcji dostępnych użytkownikom i konieczności testowania ile wlezie są rozumne wybory i powrót do standardów sieciowych. Ale wiem, że lubisz listy, więc masz następną, która przybliży Ci to w praktyce. Oto…

Krótka recepta na spokojny sen

  1. Specyfikacje HTML, JavaScriptu i CSS są po to, żeby z nich korzystać. Doskonałe zasoby takie jak MDN mają wszystko.
  2. Za każdym razem, kiedy Chcesz wcisnąć na stronę jakiś dziwny komponent, rozbierz go na czynniki pierwsze i sprawdź, czy ma sens. Jeśli możesz, zastąp go natywnym rozwiązaniem HTML. I ostyluj sobie CSS jak potrzebujesz.
  3. Kiedy dokonujesz wyboru frameworku, z którego skorzystasz przy budowie strony internetowej albo aplikacji, sprawdź, jak daje sobie radę z dostępnością i przeczytaj dokumentację (RTFM, czyli Read the Fucking Manual naprawdę wiecznie żywe). Większość frameworków użytych nierozważnie doprowadzi osoby korzystające z technologii asystujących do łez. Choć pewnie i tak już nie mają szans ich toczyć, biorąc pod uwagę tonami szajsu, jakimi zalewa je Internet.
  4. WCAG jest książką kucharską, a Ty Jesteś hardkorem jak Carmen Berzatto z „The Bear”, tylko masz fajniejsze tatuaże i nie zachowujesz się jak aspołeczna buła ogarnięta megalomanią.

Będzie dobrze. Tylko oddychaj.

A potem testuj w Chrome, Edge i Safari i skumaj, że ma po prostu działać na wszystkim. Senkju.

Parę linków na koniec

  1. Zasoby dla osób tworzących rozwiązania dostępne od Apple, Androida i Małego Miękkiego (jak Cię bardzo ciśnie).
  2. Sieciowe standardy opisane przez MDN. Kompletna instrukcja robienia po bożemu.
  3. „The Bear” na Wikipedii. Świetny serial. Nauczy Cię przywiązywania uwagi do szczegółow. Albo nie.

Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *