Dostępność: checklista dla developera


Dostępność jest bardzo często traktowana (podobnie jak cały UX) po macoszemu. Z moich rozmów z developerami wynika, że to nie tyle z ignorancji co z bagatelizowania problemu. O tempora! Biznes nie kładzie odpowiedniego nacisku na to, marginalizując problem. Ale dostępność to jest po prostu zbiór dobrych praktyk. Im szybciej je wdrożysz tym lepiej.

Nie chcę tutaj (znowu) pisać etosów o odpowiedzialności projektowej. Zakładam, że temat jest Ci znany. Zakładam też, że znasz wymagania WCAG. Część odpowiedzialności za dostępność spoczywa na barkach całego zespołu. Skupmy się jednak na odpowiedzialności programisty:

Zdefiniuj atrybut języka

Atrybut lang HTML jest ważny m.in. dla SEO. Jeżeli chodzi o dostępność: zapewniają prawidłowy akcent i wymowę czytnikom. Po prostu użyj „HTML lang „.

Użyj poprawnego elementu HTML dla swoich treści

Wizualnie dany element możesz umieścić na kilka sposobów. Jednak poprawność kodu decyduje m.in. o tym w jaki sposób jest odbierany przez czytniki.

Pamiętaj o nawigacji za pomocą klawiatury

Wiele osób na stałe, lub tymczasowo nie może korzystać z myszy. Spraw aby nawigacja klawiaturą była prosta i intuicyjna.

Zrozum i wykorzystaj punkty orientacyjne HTML

Osoby korzystające z czytników często korzystają z punktów orientacyjnych, nagłówków, znaczników. Ułatwiają one nawigację po stronie. Poznaj te rozwiązania i odpowiednio ich używaj.

Stosuj alternatywne opisy dla elementów wizualnych

Wszelkie obrazy powinny mieć zdefiniowany alt. Opis ten będzie wykorzystywany przez wszystkie czytniki aby oddać jak najlepiej content strony.

Aktywny element powinien być zawsze opisany

Etykiety nie powinny nigdy całkowicie znikać. Zwłaszcza podczas focusu na danym elemencie. To może bardzo zdezorientować użytkownika np. przy nawigacji klawiaturą.

Nie używaj tylko koloru do walidacji

Umieść komunikaty o błędach w tekście, które wyjaśniają błąd i jak naprawić błąd. 

Poznaj i zacznij używać ARIA

Aria obecnie jest opcjonalnym atrybutem. Dla Ciebie powinien być obowiązkowy 🙂 Po prostu go używaj. Łącz buttony z akcjami i inputami. Sprawdź jak odbierają go czytniki. 

Pozwól pominąć nawigację

Czasami naiwgacja głównego poziomu jest tak rozbudowana, że „przeklikanie” jej tabulatorem jest udręką. Dodaj button „pomiń nawigację” – może być widoczny tylko wtedy gdy jest aktywny. To bardzo pomaga.

Twórz linki opisowe

Unikaj sformułowań „Czytaj dalej, więcej, kliknij tutaj” one nic nie mówią. Używaj labeli, które obronią się same.

Unikaj wizualizacji generowanych w CSS

Obecnie czytniki nie są w stanie tego dostarczyć użytkownikowi w przystępny sposób.

SVG powinny być opisane

Pliki SVG są często jako podbicie elementów nawigacyjnych. Powinny mieć zdefiniowany tekst (może być widoczny tylko gdy element jest aktywny). Unikaj niepodpisanych ikon.

Ukryj elementy dekoracyjne

Często w interfejsach są używane elementy dekoracyjne: separatory, ozdobniki etc. Ukryj je przed czytnikami. Patrz Aria.

Linki powinny być jednoznaczne

Linki powinny się wybijać atrybutami (i wizualnie)  z treści, mieć opisany active i focus.

Wszyscy odpowiadamy za dostępność

To nie jest tak, że za dostępność odpowiadają tylko developerzy. Odpowiedzialność spoczywa na wszystkich od designera po copywritera. Nawet jeżeli Biznes Owner to ignoruje (sic!) to przecież nie może na nas wymusić pomijania dobrych praktyk. By żyło się lepiej!


Fajne? Udostępnij dalej: Twitter, LinkedIn, Facebook, Poczta Polska.