Ostatnio przeczytałem artykuł Léonie Watson Difference between keyboard and screen reader navigation (polecam zresztą cały blog Léonie). Ta to umie nazywać rzeczy po imieniu.
Léonie opisuje i porównuje w tym artykule sposób nawigacji i doświadczenia użytkowników, którzy:
- nie używają myszy, ale widzą zawartość,
- nie używają myszy i nie widzą zawartości.
A użytkownicy Ci mają zgoła odmienne doświadczenia i możliwości.
Coraz częściej spotykam się z używaniem czytników ekranu przez projektantów, UXów, testerów wewnętrznych, a nawet developerów. Wykorzystują oni czytniki jako narzędzi do testowania. Potwierdzają to zresztą cząstkowe wyniki tegorocznej edycji badania „Kto w Polsce zajmuje się dostępnością cyfrową 2020”.
Jednocześnie coraz rzadziej słyszę, żeby ktoś testował rozwiązanie samą klawiaturą. A nie wiem czy kiedykolwiek ktoś przyznał się do używania w czasie badania funkcji Switch Access czy Switch Control.
W efekcie tego kilka razy usłyszałem ostatnio:
Ale po co te etykiety w formularzu? Przecież NVDA czyta placeholdery, a poza tym dodaliśmy jeszcze aria-label.
i
Po co dawać skip link „Przejdź do treści”? Mamy strukturę nagłówkową i użytkownik może spokojnie skoczyć do nagłówka <h1> i będzie w treści głównej.
Problem jest taki, że zarówno wszelkie dobrodziejstwa ARIA jak i nawigowanie po nagłówkach, linkach, elementach logicznych tabeli itp. jest dostępne jedynie dla użytkowników korzystających z czytników ekranu.
Ci zaś użytkownicy, którzy „nie używają myszy, ale widzą zawartość”, mogą co najwyżej westchnąć w takiej sytuacji i podziękować za opcje, które są dla nich… dostępne jak <title> na tablecie.
Zajmujesz się w jakikolwiek sposób dostępnością cyfrową lub inclusive design? Weź koniecznie udział w badaniu „Kto w Polsce zajmuje się dostępnością cyfrową 2020”.