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

...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

• nie nadużywaj ARIA - "no ARIA is better than bad ARIA", lepiej przczytać najpierw artykuł: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
• semantyczny HTML załatwia nam wiele rzeczy - nadmiarowe oznaczanie ARIA, np. <nav role="navigation"> jest błędne,
• tutaj można obczaić jak używać ARIA i jak tworzyć dostępne komponenty: https://www.w3.org/WAI/ARIA/apg/patterns/

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

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:

• #68: narzędzie AI, które tworzy kod widoków + świetne art z HTMHell
• #67: Kiedy i jak najlepiej prosić o pozwolenie na powiadomienia, HTMHell, kurs Figmy
• #66: Buttony - na te rzeczy zwróć szczególną uwagę
• #65: 16 małych zasad tworzenia UI, które robią wielką różnicę
• #64: 7 wskazówek na dobry UX nawigacji, redesign platformy Steam