Serwis posiada elementy wyróżnione cechami wyglądu i nieoznaczone właściwymi znacznikami (błąd). – Procent wystąpień: 14%
Dotyczy kryteriów sukcesu WCAG: 4.1.2 Nazwa, rola, wartość
Kto może poprawić: Web developer
Opis / zalecane rozwiązanie: Należy trzymać się kanonu HTML. Poprawna semantyka kodu HTML jest kluczowa w przypadku technologii wspomagających. Jeżeli element tekstowy pełni funkcję nagłówka wyróżniającego dalszy tekst, to oznaczamy go znacznikiem <h…>, zamiast zmieniać jego wielkość i kolor. Podkreślenia tekstu kojarzone są z odnośnikami. W formularzach stosujemy elementy , zamiast zastępować je np. elementami <div> czy <span> powiązanymi z JavaScriptem. Niepoprawnie określone znaczniki HTML wprowadzają technologie asystujące w błąd i mogą powodować dodatkowe problemy np.: z responsywnością.
Częstym błędem jest używanie znaczników odnośnika <a> jako elementu wywołującego funkcję JavaScript. Link używamy, gdy dokądś prowadzi i następuje zmiana kontekstu. W celu wywołania funkcji (jakiegoś działania) standard HTML przewiduje użycie np. <button type=”button”>.
Równie często w roli elementów aktywnych używane bywa <i> – prawdopodobnie dlatego, że jest krótkie, a twórcy kodu nie chce się dużo pisać. Ten element ma swoje konkretne znaczenie w specyfikacji i używanie go jako uniwersalnego kontenera treści czy elementu klikalnego, jest BŁĘDNE. Zwłaszcza że zazwyczaj towarzyszy temu całkowita niedostępność z klawiatury.
Jeżeli już koniecznie trzeba używać elementu innego, niż przewidziany w specyfikacji, konieczne jest całkowite odtworzenie jego zachowania przy pomocy JavaScriptu i opatrzenie go niezbędnymi atrybutami ARIA. Jeśli tylko się da, należy tego unikać. ZAWSZE lepiej użyć właściwego znacznika HTML.
Zamiast komplikować:
<i tabindex=”0″ role=”link” onclick=”goToLink(event, 'https://www.w3.org/’)” onkeydown=”goToLink(event, 'https://www.w3.org/’)”>Serwis W3C </i> plus dodatkowo kilkadziesiąt linijek CSS i JavaScript kontrolujących wygląd i działanie tego “linku”.
lepiej użyć zawsze poprawnie działającego: <a href=”’https://www.w3.org/”>Serwis W3C</a>
Często błędy są spowodowane próbami dostosowania wyglądu elementów formularza do pożądanej szaty graficznej. Wiele natywnych elementów HTML ma ograniczoną możliwość zmiany wyglądu. Programiści stosują wówczas sztuczki z zastępowaniem ich innymi znacznikami i nadawaniem im dowolnego wyglądu. Często ich obsługa jest ograniczona tylko do myszy, a dostępność wcale nie jest brana pod uwagę. Podmiana elementów <input><select> itp. wymaga bardzo dużej uwagi.
Serwis posiada slajdery bez możliwości sterowania przy użyciu klawiatury (problem). – Procent wystąpień: 12,5%
Dotyczy kryteriów sukcesu WCAG:
Kto może poprawić: Administrator strony, Web developer
Opis / zalecane rozwiązanie: Należy zadbać, aby każdy element funkcji sterujących działaniem strony otrzymał focus klawiatury i że kolejność tabindex jest logiczna. Pokazy slajdów/ karuzele są potencjalnym źródłem problemów, bo treść w nich zawarta może się dynamicznie zmieniać. Niezbędne jest zapewnienie dobrze widocznych i czytelnie opisanych przycisków sterowania i zatrzymania pokazu slajdów. To zapewni osobom z problemami wzroku i funkcji poznawczych możliwość odczytania zawartości slajdów bądź wyłączenia rozpraszającej ich zmiany. Często pokazy slajdów mają funkcjonalność zatrzymania po najechaniu myszą – to jest niewystarczające, trzeba zapewnić taką samą funkcjonalność przy użyciu klawiatury.
Najlepszą opcją poprawy pod względem User Experience i dostępności jest… zastąpienie sliderów i karuzel innym elementem. Są nieefektywne, bardzo wiele osób ma tzw. “slider blindness” , mało użytkowników w ogóle je czyta, denerwują część odwiedzających. Stale zmieniająca się treść (lub część treści ukryta) powoduje poważne problemy z dostępnością. Jednocześnie istnieje mało poprawnie napisanych rowiązań. Proponujemy zastąpienie sliderów statycznymi formami typu “hero image”. W niektórych przypadkach sensowne może być utworzenie osobnej podstrony np. z rodzajem galerii pracowników zamiast karuzeli z ich zdjęciami i informacjami.
Serwis posiada akapity z justowaniem (problem). – Procent wystąpień: 12,2%
Dotyczy kryteriów sukcesu WCAG:
Opis / zalecane rozwiązanie: Ważne jest zapewnienie poprawnego odczytu osobom słabo widzącym lub z zaburzeniami funkcji poznawczych. Poprawna implementacja polega na takim formatowaniu tekstów, by po ręcznej zmianie po stronie użytkownika, nadal były one czytelne i widoczne. Teksty po powiększeniu odstępów nie powinny ukrywać się pod ramkami o sztywno określonych rozmiarach ani nachodzić na siebie. Unikamy justowania tekstów, bo po powiększeniu czcionek mogą się tworzyć pomiędzy wyrazami duże odstępy, utrudniające czytanie.