🎨 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

Para valorar cómo elegir una camiseta de fútbol para un aficionado joven con criterios claros, es recomendable revisar el ajuste previsto para actividad deportiva o uso casual. Para evitar errores, merece la pena revisar qué versión aparece exactamente en las fotografías.