🎨 uxowy.dev #69: 10 podstawowych błędów dostępności (popełnianych w dużej części przez developerów)

Mikołaj Waśkowski -

...szykuje się gruby refaktor 👀

Co raz częściej widzi się wzmianki o EEA (European Accessibility Act). Wiele stron, które wcześniej w ogóle nie dbały o dostępność, czeka niemała rewolucja.

I to nie jest tak, że tylko EEA powinno nas zmusić do tworzenia bardziej dostępnych stron. W USA są tego typu wymogi już od dawna. Ale i tak, pomijając wszelkie nakazy prawne, powinniśmy po prostu robić nasze strony i aplikacje dostępne. Bo...

Osób żyjących z jakimiś niepełnosprawnościami:

  • w Polsce mamy 7 milionów (to są oficjalne dane, w rzeczywistości może być ich jeszcze więcej),
  • a na świecie szacuje się, że jest to około 15-16% populacji.

No a kto będzie musiał tę całą dostępność cyfrową ogarnąć?
No głównie my. Developerzy. Także warto wejść w temat dostępności (a skillsy te na pewno będą bardzo pożądane na rynku pracy 🤫).

Dlatego dziś podsyłam Ci garstkę podstawowych błędów dostępności. I jak się zaraz przekonasz, w dużej części są one popełniane przez nas, developerów 🤷‍♂️. Ale nie tylko, żeby było jasne. O dostępność powinni dbać wszyscy, na każdym etapie tworzenia produktu.

To jedziemy:

1. Focus

  • brak widocznego focusa klawiaturowego - np. dodanie "outline: 0" na interaktywnych elementach bez dodania innych styli, które wskazałyby, że dany element ma aktualnie focus; zwróć uwagę, czy zestaw klas typu "reset" nie ma takiej definicji,
  • focusowanie elementów aktualnie niewidocznych na ekranie - klasyczny przykład to modal, którego nie możemy zamknąć z poziomu klawiatury, bo focusujemy elementy pod nim; albo menu, które jest zwinięte ale my focusujemy wszystkie jego ukryte elementy, zanim przejdziemy z focusem dalej.

2. Kontrast

  • klasyka, więc nie będę się rozpisywać - kontrast między tłem a tekstem powinien spełniać wymogi WCAG,
  • kontrast możemy sprawdzić z pomocą wielu narzędzi, m.in. na tej stronie: https://webaim.org/resources/contrastchecker.

3. Formularze

  • każdy input powinien mieć label, powiązany z inputem za pomocą for="id_inputa",
  • dopracowana walidacja - unikaj ogólnych komunikatów typu "To pole jest wymagane", zamiast tego użyj "Podaj swoje imię"; komunikat powinien być bezpośrednio przy polu, najlepiej oznaczony nie tylko kolorem, ale też ikonką,
  • pokaż podpowiedzi - jeśli pole ma jakieś ukryte wymagania lub ograniczenia, powiedz o tym od razu, nie dopiero po walidacji; typowy przykład to pole hasła,
  • przejście formularza z poziomu klawiatury - wszystkie pola powinny być osiągalne z poziomu klawiatury; niby podstawa, ale wiele stron ma z tym problem, najczęściej to się pojawia przy pisaniu własnych kontrolek (o tym dalej),
  • wygodny sposób wpisywania danych, np. datepicker powinien być wygodny do obsłużenia z poziomu klawiatury, czyli m.in. umożliwić nawigowanie po dniach za pomocą strzałek, umożliwić zmianę roku, miesiąca itd.,
  • przewidywalny wygląd i działanie inputów - niech select wygląda jak select itd.; nie bądź kreatywny i trzymaj się utartych szlaków.

4. Nagłówki

  • używaj ich, ale:
  • użyj dokładnie jednego nagłówka h1 na stronę,
  • używaj nagłówków w odpowiedniej kolejności - nie rób przeskoków: h1 > h3 > h5; struktura nagłówków na stronie powinna wyglądać jak drzewo z kolejnymi poziomami,
  • nie używaj nagłówków do określania wyglądu tekstu, typowy przykład, to "dam tutaj h3 bo potrzebuję troszkę większy tekst", do tego używaj klas CSS.

5. ARIA

6. Customowe zachowania elementów

  • divy i spany z onClick to klasyka - staraj się używać natywnych klikalnych elementów: np. linków do nawigacji, buttonów do wywoływania JS, radio, checkboxów itd.; ich wygląd możesz modyfikować w CSS,
  • jeśli już robisz takie rzeczy, to oznacz elementy odpowiednimi rolami i tagami ARIA, np. role="radiogroup", aria-lebelledby="id", role="radio", aria-checked="boolean" itd. Przykłady właściwego użycia tych oznaczeń w różnych komponentach są w punkcie wyżej dot. ARIA;

7. Linki bez href

  • nie używaj linków bez href - np. do wywołania funkcji JS,
  • jeśli coś ma się zachować jak przycisk, niech to będzie przycisk (button).

8. Szybko zmieniający się obraz i autoplay

  • lepiej nic nie odtwarzać automatycznie (wideo, dźwięku, slidera),
  • jeśli już musisz, to daj możliwość zastopowania,
  • weź pod uwagę prefers-reduced-motion.

9.  Opis tekstowy elementów nietekstowych

  • dla obrazków - dodaj alt; jeśli obrazek jest typowo dekoracyjny, to dodaj pusty alt, dzięki temu voice over nie przeczyta URL'a obrazka; jeśli alt jest przydatny, staraj się dobrze opisać go w jednym zdaniu (co się znajduje na obrazku?),
  • dla wideo - dodaj napisy lub transkrypt,
  • dla infografik - umieść tekst pod inforgrafiką, może być ukryty za pomocą CSS,
  • dla przycisków z samą ikoną - dodaj np. aria-label lub wizualnie ukryty element z tekstem wewnątrz - nie będzie widoczny na ekranie, ale czytnik ekranowy go przeczyta.

10. CAPTCHA

  • dodanie CATPCHA może bardzo utrudnić życie osobom, które używają technologii wsparcia dostępności, np. czytnika ekranowego; więcej tutaj: https://www.w3.org/TR/turingtest/
  • rozważ użycie technik alternatywnych - np. honeypot, timestamp lub poproś o rozwiązanie prostego równania.

PS. Powyższa lista inspirowana jest lekcją z kursu Dostępność cyfrowa dla programistów. Kursu nie ukończyłem jeszcze w 100%, ale już teraz mogę Ci go polecić. Wojtek (wspominany już wcześniej w uxowy.dev) naprawdę wie, o czym mówi i robi świetną robotę.

To wszystko na dziś!

Pozdrawiam i dobrego tygodnia! 🚀

Mikołaj Waśkowski
uxowy.dev

🚨
Jeśli podoba Ci się ten mail, wrzuć info o nim na swoje socjale lub firmowego Slacka! Może jest tam ktoś, komu przyda się trochę wiedzy o UI/UX dla developera? Poniżej gotowiec do skopiowania 👇
Na moją skrzynkę wpadł właśnie newsletter uxowy.dev, a w nim 10 podstawowych błędów dostępności (popełnianych głównie przez developerów...). Polecam: https://uxowy.dev/email/69

Daj znać, gdzie wrzuciłeś(aś).
Może będę w stanie się jakoś odwdzięczyć 🤝

Przegapiłeś któreś wydanie?

Lista ostatnich wysyłek 🎨 uxowy.dev: