Darmowe narzędzie: Dostępność

Test dostępności strony internetowej

Wpisz adres, a przetestujemy tę stronę i maksymalnie cztery kluczowe podstrony w prawdziwej przeglądarce według reguł WCAG 2.2 na poziomach A i AA. Każdej barierze towarzyszą element, podstrona, zrzut ekranu i wyjaśnienie, kogo dotyczy.

Za darmo. Testuje do pięciu kluczowych podstron w około minutę.

Co sprawdza to narzędzie

  • Pięć stron reprezentujących Twoją witrynę

    Strona, którą podajesz, oraz maksymalnie cztery podstrony wybrane spośród jej linków odpowiednio do rodzaju witryny. W sklepie są to kolekcja, produkt, koszyk i strona z treścią; w innych witrynach na przykład cennik, kontakt, artykuł lub usługi. Szablony się powtarzają, więc jedna strona produktu zwykle pokazuje problemy wszystkich pozostałych.

  • Reguły WCAG na wyrenderowanej stronie

    Każda strona ładuje się w Chromium w rozdzielczości 1366 × 900, a axe-core, otwartoźródłowy silnik reguł firmy Deque, uruchamia swoje reguły WCAG 2.0, 2.1 i 2.2 dla poziomów A i AA po wykonaniu skryptów strony. Dzięki temu wychwytuje problemy, które motyw lub aplikacja tworzy dopiero wtedy, gdy strona zostanie zbudowana w przeglądarce.

  • Wpływ i kryteria sukcesu

    Każda niespełniona reguła pokazuje swój wpływ (krytyczny, poważny, umiarkowany lub drobny), kryteria sukcesu WCAG, którym odpowiada, oraz liczbę elementów i stron, których dotyczy.

  • Błędny element, obrysowany

    Kod HTML przykładowego elementu i zrzut ekranu strony z obrysowanym elementem, dzięki czemu Ty lub Twój programista możecie znaleźć go w szablonie bez zgadywania.

  • Kwestie, o których musi zdecydować człowiek

    Gdy axe-core znajdzie coś, czego nie potrafi rozstrzygnąć, na przykład tekst na obrazie w tle, którego kontrastu nie da się zmierzyć, pozycja trafia na listę „Do sprawdzenia”. Nigdy nie jest liczona jako błąd.

  • Test klawiatury

    Na pierwszej stronie naciskamy Tab 40 razy i zapisujemy, gdzie trafia fokus: czy w ogóle się przesuwa, czy nie utyka w pętli (często wewnątrz banera cookies), czy pierwszym przystankiem jest link pomijający (skip link) i które elementy z fokusem nie mają widocznego wskaźnika fokusu. Ta ostatnia kontrola jest heurystyczna, dlatego jej wynik ma status „Do sprawdzenia”.

Czego nie może sprawdzić

  • Usłyszeć, co odczytuje czytnik ekranu. Oprogramowanie może potwierdzić, że przycisk ma nazwę, ale nie to, że ta nazwa ma sens, gdy zostanie przeczytana na głos.
  • Ocenić napisów, transkrypcji ani audiodeskrypcji do filmów i nagrań dźwiękowych.
  • Ocenić kryteriów poznawczych i dotyczących treści, na przykład tego, czy instrukcje są zrozumiałe albo czy komunikaty o błędach pomagają je naprawić.
  • Przetestować stron za logowaniem, hasłem lub ochroną przed botami ani przejść przez proces zakupu (checkout).
  • Powiedzieć Ci, czy Twoja witryna jest zgodna z WCAG lub spełnia wymogi jakiegokolwiek prawa. Automatyczne reguły znajdują część problemów; resztę muszą sprawdzić ludzie.

Dlaczego to ważne

Bariery dostępności to często drobne błędy w szablonie o dużych skutkach. Przycisk koszyka złożony wyłącznie z ikony i pozbawiony dostępnej nazwy jest odczytywany po prostu jako „przycisk”, więc osoba korzystająca z czytnika ekranu nie wie, do czego służy. Szary tekst na białym tle, który nie osiąga współczynnika kontrastu 4,5:1, jest trudny do odczytania dla wielu osób słabowidzących, a także dla każdego, kto używa telefonu w pełnym słońcu.

Ponieważ ten sam nagłówek, karta produktu i stopka pojawiają się na każdej stronie, jedna poprawka w szablonie może usunąć setki błędów naraz. Dlatego wyniki są pogrupowane według reguł, z liczbą elementów i stron, zamiast wymieniać każde wystąpienie jako osobny problem.

W wielu krajach dostępność ma też wymiar prawny. Skan nie powie Ci, czy dane przepisy Cię obowiązują ani czy je spełniasz. Daje natomiast datowaną listę rzeczywistych barier na Twoich własnych stronach, a od tego w każdym przypadku warto zacząć.

Jak czytać wyniki

Krytyczny
Bariera może całkowicie uniemożliwić niektórym osobom korzystanie z elementu, na przykład pole formularza bez etykiety lub przycisk bez nazwy. Napraw je w pierwszej kolejności.
Poważny
Bariera znacznie utrudnia niektórym osobom wykonanie zadania, na przykład tekst główny, który nie spełnia wymaganego współczynnika kontrastu.
Umiarkowany
Bariera powoduje trudności lub dezorientację, ale zwykle da się ją obejść.
Drobny
Niewielki problem lub niedogodność. Mimo to warto go poprawić przy najbliższej edycji tego szablonu.
Kryteria sukcesu WCAG
Numery obok reguły, na przykład 1.1.1 lub 1.4.3, to kryteria, które ona testuje. Reguła bez podanego kryterium to dobra praktyka (best practice), a nie wymóg WCAG.
Elementy i strony
Ile elementów nie spełniło reguły i na ilu testowanych stronach. Reguła niespełniona na każdej stronie zwykle dotyczy wspólnej części, takiej jak nagłówek, menu lub stopka.
Do sprawdzenia
axe-core znalazł coś, czego nie potrafił rozstrzygnąć. Obejrzyj element samodzielnie: może spełniać wymagania albo nie. Te pozycje nie są liczone jako błędy.
Pułapka fokusu
Klawisz Tab cały czas przenosił fokus w kółko po tych samych kilku elementach. Jeśli należą one do banera cookies, osoby korzystające z klawiatury mogą nie dotrzeć do reszty strony.
Fokus się nie przesuwa (Focus doesn’t move)
Po naciśnięciu Tab fokus nie trafił na żaden element. Linki i przyciski mogą być zbudowane z elementów div lub span albo jakiś skrypt przechwytuje klawisz.
Link pomijający
Czy pierwszym przystankiem klawisza Tab jest link „Przejdź do treści”. Bez niego osoby korzystające z klawiatury muszą na każdej stronie przechodzić przez cały nagłówek. Kryterium WCAG 2.4.1 Możliwość pominięcia bloków mogą spełnić także regiony strony (landmarki) i nagłówki.
Brak widocznego wskaźnika fokusu
Elementy z fokusem, przy których nie wykryliśmy obrysu (outline), cienia (box-shadow) ani podkreślenia. Inny styl, na przykład zmiana koloru, może być mimo to widoczny, więc przejdź po nich klawiszem Tab samodzielnie, aby to potwierdzić.

Jak naprawić najczęstsze problemy

  • Tekst, który nie spełnia współczynnika kontrastu

    Zwykły tekst wymaga co najmniej 4,5:1 względem tła, a duży tekst (około 24 px lub około 18,7 px pogrubiony) 3:1. Zmień kolor w ustawieniach motywu lub w tokenach projektowych zamiast poprawiać element po elemencie, a potem ponownie sprawdź tekst zastępczy (placeholder), stany po najechaniu kursorem i tekst na obrazach.

  • Obrazy bez tekstu alternatywnego

    Nadaj każdemu znaczącemu obrazowi atrybut alt, który mówi, co obraz przedstawia lub do czego służy, na przykład nazwę i kolor produktu. Obrazy dekoracyjne dostają pusty alt (alt=""), aby czytniki ekranu je pomijały. W Shopify tekst alternatywny dodajesz przy obrazie w sekcji multimediów produktu (Media); w WordPressie w polu „Tekst alternatywny” w Bibliotece mediów.

  • Pola formularzy bez etykiet

    Powiąż etykietę z każdym polem za pomocą <label for> zgodnego z id pola albo użyj aria-label, gdy nie ma widocznego tekstu. Nie polegaj na tekście zastępczym jako jedynej etykiecie: znika, gdy tylko ktoś zacznie pisać. Najczęstsi winowajcy to formularze zapisu do newslettera i pola wyszukiwania w nagłówku.

  • Przyciski i linki bez dostępnej nazwy

    Ikonowe elementy sterujące koszykiem, wyszukiwarką, menu czy profilami w mediach społecznościowych często zawierają tylko SVG. Dodaj widoczny tekst lub aria-label, który mówi, co robi dany element („Otwórz koszyk”, a nie „ikona”), a samemu SVG nadaj aria-hidden="true".

  • Baner cookies, który więzi fokus

    Upewnij się, że do każdego przycisku banera można dojść klawiszem Tab i użyć go klawiszem Enter lub spacją, że po zamknięciu banera fokus wraca na stronę i że baner, który nie blokuje strony, w ogóle nie zatrzymuje fokusu. Sprawdź ustawienia narzędzia do zarządzania zgodami i zaktualizuj je, jeśli skrypt jest stary.

  • Obrysy fokusu usunięte w CSS

    Wyszukaj w arkuszach stylów outline: none lub outline: 0 dla linków, przycisków i :focus. Zastąp je widocznym stylem, na przykład :focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }.

Pytania o to narzędzie

Czy ten test dostępności strony jest darmowy?

Tak. Nie trzeba zakładać konta; potwierdzasz tylko, że jesteś właścicielem witryny lub nią zarządzasz. Płatny Raport naprawy dostępności dodaje do 20 kolejnych stron z Twojej mapy witryny, przejście ścieżki wyłącznie za pomocą klawiatury, test dopasowania do szerokości 320 px (reflow), kod „przed i po” przygotowany na podstawie Twojego błędnego kodu, prompty dla narzędzi AI, plik PDF i 5 ponownych testów.

Jaką część WCAG może sprawdzić automatyczny test?

Tylko część. Reguła może sprawdzić, czy obraz ma tekst alternatywny, ale nie to, czy ten tekst opisuje obraz; czy pole ma etykietę, ale nie to, czy etykieta jest zrozumiała. Traktuj wyniki jako listę pewnych problemów, a resztę przetestuj za pomocą klawiatury i czytnika ekranu.

Jeśli skan nic nie znajdzie, czy moja strona jest zgodna z ADA lub WCAG?

Nie. Żaden automatyczny test nie może wykazać, że witryna jest zgodna z WCAG albo spełnia wymogi ADA, europejskiego aktu o dostępności (European Accessibility Act) czy jakiegokolwiek innego prawa. Czysty wynik oznacza, że automatyczne reguły nie znalazły błędów na przetestowanych stronach.

Czy mogę sprawdzić wersję testową (staging) lub strony za logowaniem?

Stron za logowaniem, hasłem lub ochroną przed botami nie da się przetestować. Jeśli ochrona przed botami blokuje skan, dopuść user agenta FixReportsScanner albo przetestuj publiczną kopię testową.

Problem został naprawiony. Dlaczego wynik się nie zmienił?

Wyniki dla tego samego adresu mogą pochodzić ze skanu wykonanego w ciągu ostatniej godziny. Odczekaj, aż ta godzina minie, i wyczyść pamięć podręczną strony lub CDN, zanim przetestujesz ją ponownie.

Źródła

Powiązane narzędzia

Raport naprawy dostępności ($174, jednorazowo) zaczyna od pełnego darmowego skanu i dodaje więcej podstron, zmianę do wprowadzenia dla każdego wykrytego problemu, plik PDF i ponowne testy do weryfikacji poprawek.

Raport naprawy dostępności: szczegóły