Serwis posiada odnośniki wyróżnione tylko kolorem, które nie spełniają wymogów kontrastu (błąd). – Procent wystąpień: 12,2%
Dotyczy kryteriów sukcesu WCAG:
Kto może poprawić: Administrator serwisu, Web developer
Opis / zalecane rozwiązanie: Prawidłowa widoczność odnośników jest szczególnie ważna dla osób z zaburzeniami widzenia. Przeczytaj zalecenia kontrastu podane powyżej. Dodatkowe wyróżnienie odnośników ma znacznie dla osób z zaburzeniem widzenia kolorów. Przeczytaj zalecenia wyróżniania elementów aktywnych powyżej.
Widoczność fokusa klawiatury
- Serwis ukrywa widoczność fokusa klawiatury (błąd). – Procent wystąpień: 12,2%
- Serwis może ukrywać widoczność fokusa klawiatury (problem). – Procent wystąpień: 11,9%
Dotyczy kryteriów sukcesu WCAG: 2.4.7 Widoczny fokus
Kto może poprawić: Administrator serwisu, Web developer
Opis / zalecane rozwiązanie: Wszelkie elementy aktywne i klikalne na stronie, które przechwytują focus klawiatury (są dostępne przez nawigację klawiszem Tab), muszą być wyróżniane graficznie. Uzyskujemy to przez stylowanie CSS dla pseudoklasy “focus-visible”. Może to być ramka, cień, inwersja kolorów lub inna metoda pozwalająca wyraźnie i jednoznacznie określić, który element jest aktywny. Zmiana musi dotyczyć więcej niż tylko samego koloru tekstu (musi być rozpoznawalna przez użytkowników ze ślepotą barw).
Przeglądarki zwykle dodają własny wskaźnik fokusu, ale tylko, jeśli w kodzie stronty nie zostanie on określony. Twórcy stron bardzo często wyłączają tę funkcję, bo kiedyś była w przeglądarkach dla pseudoklasy “focus” (ramka pokazywała się po kliknięciu myszką i uzyskaniu fokusu klawiatury) i nie wyglądało to dobrze. Jednocześnie nie zapewniano indykatorów fokusu dla klawiatury. Współczesne przeglądarki dodają obrys tylko przy nawigacji klawiaturą (focus-visible), ale ze względu na opisane przyzwyczajenie developerów nie można liczyć na jego poprawne wyświetlanie.
Proponujemy dodać następujący kod CSS do strony (w WordPress można to łatwo zrobić w funkcji “Dostosuj > Własny CSS”):
body a:focus-visible {
outline: solid 2px blue; */zastąp kolor w zależności od potrzeb/*
outline-offset: 2px;
}
Responsywność serwisu
- W trybie mobilnym część informacji może być niewidoczna (błąd). – Procent wystąpień: 10,7%
- Serwis nie umożliwia dynamicznego dopasowywania zawartości do wielkości ekranu (błąd). – 8,9%
Dotyczy kryteriów sukcesu WCAG: 1.4.10 Dopasowanie do ekranu
Kto może poprawić: Web developer
Opis / zalecane rozwiązanie: Treść po powiększeniu w przeglądarce (np. funkcją Ctrl + kółko myszki) powinna mieścić się w zmaksymalizowanym oknie bez konieczności poziomego przewijania ekranu. Jednocześnie elementy powinny płynnie zmieniać swoje położenie i nie nachodzić na siebie (nie zasłaniać jedne drugich).
Osoby z dysfunkcjami wzroku muszą mieć możliwość powiększenia czcionek. Należy zadbać, aby kontenery (ramki, obszary) zawierające tekst nie miały sztywno ustawionych rozmiarów i aby ich wielkość zmieniała się wraz z ich zawartością. Sztywne rozmiary powodują, że część treści przesuwa się poza ekran, lub ukrywa pod innymi elementami strony. Dotyczy to również obrazów, które powinny poprawnie się skalować, niezależnie od wielkości ekranu. Do określania rozmiarów czcionek, odstępów i innych elementów używamy jednostek relatywnych (em, rem). Dzięki temu powiększane czcionki nie będą nachodzić na siebie, a kontenery je zawierające będą dostosowywać swoją wielkość do czcionek. Dostosowanie CSS przy pomocy tzw. media queries pozwala uzyskać poprawny wygląd strony na różnych wielkościach ekranów i na urządzeniach mobilnych.
Formularze w witrynie
- W serwisie występują formularze z problemami dot. właściwej sygnalizacji błędnego wypełnienia danych (błąd)– Procent wystąpień: 10,7%
- Pole wyszukiwania nie posiada etykiety lub została ona błędnie powiązana (błąd) – Procent wystąpień: 9,9%
- Pola formularza nie posiadają etykiet lub etykiety zostały błędnie powiązane z polami (błąd) – Procent wystąpień: 8,9%
- Serwis posiada pola formularza bez etykiet lub tekstu alternatywnego (błąd) – Procent wystąpień: 7,8%
- W serwisie występują przyciski bez etykiety tekstowej (błąd)– Procent wystąpień: 6%
Dotyczy kryteriów sukcesu WCAG:
- 1.3.5 Określenie pożądanej wartości
- 2.4.6 Nagłówki i etykiety
- 3.3.1 Identyfikacja błędu
- 3.3.2 Etykiety lub instrukcje
- 3.3.3 Sugestie korekty błędów
Kto może poprawić: Administrator serwisu, formularze wbudowane – Web developer
Opis / zalecane rozwiązanie: Te błędy należą do najbardziej poważnych. Poprawność przesyłania informacji nie może być zakłócona lub przekłamana.
Informowanie o poprawności wprowadzonych danych jest kluczowe dla osób korzystających z technologii wspomagających. Pola, które są wymagane można np.: oznaczyć tekstem (wymagane) w znaczniku <label>. Można też w znaczniku input umieścić atrybut: aria-required=”true”. Koniecznie należy zadbać, aby poinformować użytkownika o sukcesie, lub niepowodzeniu wysłania danych. Techniki używane w tym celu opisano na stronie przykładami przygotowanymi przez WAI
Etykiety formularza informują technologie wspomagające o funkcji i działaniu danego elementu formularza. Poprawne działanie uzyskujemy, stosując zalecane elementy HTML. <label> dla opisania funkcji elementów <input> oraz <fieldset> i <legend> do grupowania i informowania o celu całego formularza. Teksty etykiet powinny być możliwie krótkie, ale dokładnie opisujące przeznaczenie elementu, do którego się odnoszą. Należy zadbać, aby cel, na który wskazuje atrybut “for” miał prawidłową wartość atrybutu “id” elementu formularza.
Serwis nie Deklaracji Dostępności (błąd). – Procent wystąpień: 8,3%
Dotyczy kryteriów sukcesu WCAG: wymagane w Ustawie o dostępności cyfrowej.
Kto może poprawić: Administrator serwisu
Opis / zalecane rozwiązanie:
Zgodnie z Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) każda strona należąca lub używana przez podmioty publiczne musi posiadać Deklarację Dostępności, do której odnośnik będzie dostępny na wszystkich podstronach serwisu – w praktyce, odnośnik ten jest umieszczany w stałej stopce dla wszystkich stron serwisu. Informacje wymagane w Deklaracji Dostępności określone są wprost w Ustawie. Postać Deklaracji Dostępności określają Warunki techniczne publikacji oraz struktura dokumentu elektronicznego Deklaracji Dostępności. Jednostki UW mogą zgłosić się do BON w celu uzyskania wsparcia poprzez przeprowadzenie audytu dostępności cyfrowej swoich stron internetowych, oraz przygotowania na tej podstawie Deklaracji Dostępności.
Deklaracja dostępności musi być aktualizowana co najmniej raz do roku, a także po każdej istotnej aktualizacji serwisu, która może mieć wpływ na dostępność cyfrową.
Język serwisu
- Link do przeskoczenia do treści strony posiada komunikat w języku angielskim (błąd) – Procent wystąpień: 13,4%
- Serwis zawiera znacznik języka niezgodnego z językiem treści (błąd). – Procent wystąpień: 7,1%
- Na stronach serwisu nie określono znacznika języka (błąd). – Procent wystąpień: 6,8%
- Serwis posiada treści w języku innym niż podstawowy język strony i nieoznaczone znacznikiem języka (błąd). – Procent wystąpień: 4,8%
Dotyczy kryteriów sukcesu WCAG:
Kto może poprawić: w treści (część tekstu) – Redaktor treści, różne wersje językowe serwisu – Administrator serwisu lub Web developer
Opis / zalecane rozwiązanie: Wartość atrybutu określającego język strony <html lang=…> musi być zgodna z tabelą określającą standard — wartość atrybutu “lang” jest wykorzystywana przez Google do tworzenia wyników wyszukiwania i przez czytniki ekranowe do wyboru języka i wymowy tekstu.
Programy do odczytu ekranu włączają automatycznie wymowę zgodną z językiem określonym w serwisie. Niezgodność tego atrybutu z treścią może spowodować, że stanie się ona całkowicie niezrozumiała.