Jak sprawdzić dostępność cyfrową strony instytucji kultury?

Nie zaczynaj od wyniku procentowego

Narzędzia automatyczne potrafią szybko znaleźć część problemów: brakujące etykiety, niektóre błędy kontrastu, niepoprawne atrybuty czy problemy strukturalne. Nie potrafią jednak ocenić wszystkiego. Przycisk może mieć poprawny kod, a mimo to być niezrozumiały. Zdjęcie może mieć tekst alternatywny, który niczego nie wyjaśnia.

Dlatego wynik testera warto traktować jako listę tropów, a nie certyfikat jakości strony.

1. Odłóż mysz i przejdź całą stronę klawiaturą

Użyj klawisza Tab i sprawdź, czy można dotrzeć do menu, linków, przycisków, formularzy i innych elementów interaktywnych. Fokus powinien być widoczny, a kolejność przechodzenia logiczna. Użytkownik nie może utknąć w menu, oknie modalnym albo innym komponencie.

Sprawdź też, czy element aktywny można uruchomić z klawiatury i czy po zamknięciu dodatkowego okna fokus wraca w sensowne miejsce.

2. Sprawdź strukturę nagłówków, nie tylko ich wygląd

Nagłówki H1, H2 i H3 tworzą mapę treści. Nie powinny być wybierane wyłącznie dlatego, że mają odpowiedni rozmiar. Na stronie warto mieć jedno główne H1 opisujące temat, a kolejne poziomy powinny wynikać z logicznego podziału informacji.

To szczególnie ważne w serwisach instytucji, gdzie artykuły bywają kopiowane z dokumentów biurowych i mogą przynosić przypadkową strukturę.

3. Przeczytaj same linki i przyciski

„Kliknij tutaj”, „więcej” albo sam symbol strzałki niewiele mówi bez kontekstu. Tekst linku powinien wskazywać, dokąd prowadzi albo co się wydarzy. Jeżeli link otwiera plik PDF, zewnętrzny serwis lub nową kartę, użytkownik powinien móc to przewidzieć tam, gdzie ma to znaczenie.

4. Przetestuj formularze jak zwykły użytkownik

Każde pole powinno mieć czytelną etykietę. Błąd nie może być sygnalizowany wyłącznie kolorem, a po nieudanym wysłaniu użytkownik powinien dowiedzieć się, co trzeba poprawić. Warto sprawdzić formularz zarówno z klawiatury, jak i na telefonie.

W instytucjach kultury dotyczy to zwłaszcza formularzy zapisów, kontaktu, rezerwacji i zgłoszeń na zajęcia.

5. Sprawdź kontrast i informacje przekazywane kolorem

Jasnoszary tekst na białym tle może wyglądać subtelnie, ale być trudny do odczytania. Podobnie czerwony i zielony kolor nie powinny być jedynym sposobem oznaczenia statusu. Kolor może wspierać komunikat, ale nie powinien go zastępować.

6. Obejrzyj obrazy z wyłączonymi zdjęciami

Jeżeli fotografia przekazuje istotną informację, powinna mieć użyteczny tekst alternatywny. Jeśli jest wyłącznie dekoracyjna, czytnik ekranu nie powinien niepotrzebnie jej opisywać. Szczególnym problemem są plakaty publikowane jako jedyne źródło informacji o wydarzeniu.

Treść plakatu — data, godzina, miejsce, zasady zapisów — powinna znaleźć się również jako zwykły tekst w artykule.

7. Powiększ stronę i zwęź okno

Przy dużym powiększeniu tekst nie powinien znikać poza ekranem ani wymagać poziomego przewijania całej strony. Menu, formularze i komunikaty muszą pozostać użyteczne. To prosty test, który często ujawnia sztywne szerokości i elementy zaprojektowane tylko dla typowego ekranu laptopa.

8. Nie zapominaj o dokumentach i multimediach

Dostępna strona prowadząca wyłącznie do niedostępnych skanów PDF nie rozwiązuje problemu. Warto sprawdzać dokumenty, prezentacje i materiały do pobrania. Nagrania wideo i audio powinny mieć odpowiednie alternatywy tam, gdzie treść tego wymaga.

9. Automatyczne testy uruchamiaj regularnie

Automaty są bardzo dobre do wychwytywania regresji. Mogą szybko wskazać, że po zmianie szablonu zniknęły etykiety formularzy albo pojawiły się nowe błędy kontrastu. Najlepiej jednak traktować je jako część większego procesu: automat, test ręczny, poprawka i ponowna kontrola.

10. Sprawdź również sposób publikowania treści

Dostępność bardzo łatwo pogorszyć już po wdrożeniu strony. Redaktorzy potrzebują prostych zasad: jak pisać teksty alternatywne, jak budować nagłówki, jak opisywać linki, jak publikować pliki i czego nie wkładać na stronę jako samego obrazka.

Dlatego dobry audyt nie powinien kończyć się listą błędów technicznych. Powinien również wskazać, które problemy wynikają z szablonu, które z komponentów, a które z codziennej redakcji.