Dostępność cyfrowa nie jest osobną wersją strony dla wybranej grupy użytkowników. Jest właściwością serwisu, aplikacji, dokumentów i procesów, dzięki której informację można odnaleźć, odczytać, zrozumieć i wykorzystać także przy użyciu klawiatury, czytnika ekranu, powiększenia, sterowania głosem albo innych technologii asystujących. Dla podmiotu publicznego oznacza to jednocześnie obowiązek prawny, standard jakości usługi i stały proces utrzymania.
Ten przewodnik porządkuje najważniejsze obszary odpowiedzialności. Nie zastępuje audytu konkretnego serwisu ani analizy prawnej nietypowego przypadku. Pokazuje natomiast, gdzie najczęściej powstają bariery, jak łączą się wymagania techniczne z treścią i organizacją oraz dlaczego jednorazowe „dostosowanie strony” nie rozwiązuje problemu.
Kogo obejmują obowiązki
Podstawowym aktem jest ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Określa podmioty objęte obowiązkiem, zakres dostępności, wyłączenia, zasady sporządzania deklaracji, monitoring oraz tryb żądania zapewnienia dostępności cyfrowej. W zakresie nieuregulowanym znaczenie może mieć również ustawa o zapewnianiu dostępności osobom ze szczególnymi potrzebami.
Ocena zakresu nie powinna zaczynać się od nazwy organizacji, lecz od jej statusu prawnego, sposobu finansowania, powierzonych zadań i charakteru konkretnego serwisu lub aplikacji. Szczególnej analizy wymagają jednostki powiązane, organizacje realizujące zadania publiczne, projekty partnerskie i rozwiązania prowadzone przez wykonawcę na innej domenie.
Wyłączenia dotyczą określonych treści i warunków. Nie można uznać całej strony za wyłączoną tylko dlatego, że jest stara, ma mało użytkowników albo jej naprawa jest trudna. Powołanie się na nadmierne koszty wymaga odrębnej, udokumentowanej oceny. Nie jest synonimem braku budżetu ani argumentem stosowanym automatycznie po otrzymaniu wyceny.
WCAG, standard europejski i polska ustawa
WCAG to rekomendacje W3C opisujące dostępność treści internetowych. Ich cztery zasady mówią, że treść ma być postrzegalna, funkcjonalna, zrozumiała i kompatybilna. Kryteria sukcesu porządkują wymagania, ale nie stanowią instrukcji obsługi konkretnego systemu. To, jak je spełnić, zależy od technologii, komponentu i funkcji użytkownika.
W polskim prawie zakres wymagań dla podmiotów publicznych wynika z załącznika do ustawy i jego związku z europejskim standardem EN 301 549. Nie należy więc używać zamiennie sformułowań „obowiązek ustawowy” i „WCAG 2.2”. WCAG 2.2 jest aktualną rekomendacją W3C i rozsądnym celem jakościowym dla nowych lub modernizowanych rozwiązań, ale umowa, audyt i deklaracja powinny precyzyjnie rozróżniać wymaganie prawne od przyjętego dodatkowego standardu.
Poziom AA nie oznacza, że wystarczy wybrać z listy kryteria oznaczone literami A i AA. Ocena zgodności dotyczy całych stron i procesów, uwzględnia wymagania dotyczące kompletności, technologii wspieranych i braku mechanizmów zakłócających dostęp. Pojedyncza dostępna podstrona nie kompensuje niedostępnego formularza, przez który użytkownik musi przejść, aby wykonać usługę.
Strona internetowa to więcej niż szablon
Audyt techniczny często rozdziela problemy na warstwę globalną i treściową. Warstwa globalna obejmuje nawigację, nagłówek, stopkę, wyszukiwarkę, formularze, modale, komunikaty, sposób zarządzania fokusem i zachowanie po powiększeniu. Jeden błąd komponentu może występować na tysiącach podstron. Jego naprawa w szablonie daje większy efekt niż ręczne poprawianie każdego widoku.
Treści tworzą jednak drugi, równie ważny poziom. Nagłówki, listy, linki, tabele, opisy obrazów, załączniki i multimedia zależą od redaktorów oraz dostawców materiału. Serwis może przejść odbiór techniczny, a po kilku tygodniach zawierać niedostępne skany, plakaty bez tekstu i komunikaty złożone z samego obrazu. Dostępność nie jest więc cechą motywu, którą można „włączyć” raz na zawsze.
Szczególnej uwagi wymagają formularze. Pole musi mieć dostępną nazwę, instrukcję i komunikat błędu. Kolejność fokusu powinna odpowiadać logice zadania, a użytkownik musi móc wrócić do problematycznego pola i poprawić dane. CAPTCHA, wybór daty, autouzupełnianie i limity czasu mogą tworzyć bariery mimo prawidłowego wyglądu.
Aplikacje mobilne wymagają osobnej metodyki
Aplikacja mobilna nie jest tylko stroną na małym ekranie. Korzysta z komponentów systemu, gestów, orientacji urządzenia, powiadomień, uprawnień i funkcji dostępności Androida lub iOS. Badanie powinno obejmować rzeczywistą wersję aplikacji, wspierane systemy i pełne procesy użytkownika.
Trzeba sprawdzić między innymi dostępne nazwy i role elementów, kolejność eksploracji czytnikiem ekranu, widoczność i położenie fokusu, powiększanie, skalowanie tekstu, orientację, cele dotykowe, gesty alternatywne, komunikaty o zmianie stanu i działanie po pojawieniu się klawiatury ekranowej. Test samego kodu albo kilku zrzutów ekranu nie potwierdza dostępności aplikacji.
Każda aplikacja podmiotu publicznego potrzebuje deklaracji dostępności. Jeżeli funkcjonuje razem ze stroną i zewnętrzną usługą, użytkownik powinien rozumieć, którego elementu dotyczy deklaracja i gdzie zgłosić problem.
Dokumenty, multimedia i informacje wizualne
Dokumenty są jednym z największych źródeł barier. Skan PDF bez warstwy tekstowej jest przypadkiem oczywistym, lecz problemem może być także dokument wygenerowany z nieprawidłowo zbudowanego Worda, arkusz bez opisanych tabel, prezentacja z błędną kolejnością odczytu i formularz z nieoznaczonymi polami.
Najskuteczniejszy proces zaczyna się w pliku źródłowym. Autor stosuje style nagłówków, prawidłowe listy, tabele z nagłówkami, logiczną kolejność i opisy elementów. Następnie eksportuje dokument w sposób zachowujący strukturę i sprawdza wynik. Remediacja gotowego PDF bywa konieczna, ale jest zwykle droższa i mniej trwała niż poprawa szablonu oraz kompetencji autorów.
Nie każda informacja powinna być plikiem. Komunikat, zaproszenie, instrukcja i podstawowe dane o usłudze są zazwyczaj wygodniejsze w HTML. Dokument pozostaje uzasadniony, gdy użytkownik potrzebuje go jako odrębnego formularza, raportu, arkusza lub materiału do wydruku. Format powinien wynikać z funkcji.
W multimediach trzeba uwzględnić napisy, informacje o ważnych dźwiękach, audiodeskrypcję lub dostępny odpowiednik treści wizualnej. Plakat nie staje się dostępny po dodaniu altu „plakat wydarzenia”. Data, miejsce, program, cena i warunki udziału powinny znaleźć się w zwykłym tekście strony.
Deklaracja dostępności musi opisywać stan faktyczny
Deklaracja dostępności jest obowiązkową informacją o konkretnej stronie lub aplikacji. Ma wskazywać stan zgodności, niedostępne treści, przyczyny, sposób przygotowania oceny, dane kontaktowe oraz tryb żądania i skargi. Sama deklaracja powinna być w pełni dostępna nawet wtedy, gdy reszta serwisu ma bariery.
Szablon ułatwia zachowanie struktury, ale nie zastępuje badania. Poziom zgodności musi wynikać z oceny reprezentatywnej próby stron, procesów, dokumentów i komponentów. Raport automatyczny nie wystarcza do stwierdzenia pełnej zgodności. Coroczny przegląd do 31 marca powinien weryfikować stan, a nie jedynie zmieniać datę.
Deklaracja może być połączona z planem naprawczym. Opisane bariery powinny mieć właścicieli i terminy. Jeżeli podmiot nie potrafi powiązać deklaracji z żadnym działaniem, dokument pozostaje formalnością zamiast narzędziem transparentności.
Zgłoszenie bariery i żądanie zapewnienia dostępności
Użytkownik może zgłosić problem, a także wystąpić z żądaniem zapewnienia dostępności cyfrowej. Podmiot powinien zapewnić dostępność bez zbędnej zwłoki, co do zasady nie później niż w ciągu siedmiu dni. Gdy nie jest to możliwe, informuje o przyczynach i wyznacza nowy termin nie dłuższy niż dwa miesiące albo proponuje alternatywny sposób dostępu.
Obsługa wymaga rejestru, właściciela i ścieżki eskalacji. Wiadomość nie może utknąć na ogólnej skrzynce. Osoba zgłaszająca nie musi znać numeru kryterium WCAG ani technicznej przyczyny błędu. Rolą podmiotu jest rozpoznać zasób, zapewnić pomoc i sprawdzić, czy ten sam problem nie występuje w innych miejscach.
Alternatywny dostęp nie powinien być domyślnym sposobem świadczenia usługi. Jeżeli formularz internetowy stale nie działa z klawiaturą, możliwość telefonicznego zgłoszenia nie usuwa przyczyny i może nie być równoważna pod względem czasu, kosztu oraz prywatności.
Audyt: automaty, testy manualne i użytkownicy
Automatyczny test znajduje część problemów i dobrze nadaje się do monitorowania powtarzalnych błędów. Nie potrafi jednak ocenić sensu nazw, pełnej obsługi klawiaturą, zachowania czytnika ekranu, logicznej kolejności, jakości alternatyw i kompletności procesu. Wynik „zero błędów” nie oznacza zgodności.
Pełniejszy audyt powinien objąć reprezentatywną próbę, komponenty globalne, kluczowe zadania, dokumenty i integracje. Metodyka musi wskazywać środowisko, technologie, narzędzia oraz sposób klasyfikacji problemów. Raport powinien opisywać nie tylko naruszone kryterium, ale miejsce, wpływ na użytkownika, sposób odtworzenia, zasięg i zalecany kierunek naprawy.
Testy z użytkownikami pokazują bariery i strategie, których nie zawsze widać w kontroli eksperckiej. Nie zastępują jednak oceny zgodności z pełnym standardem, ponieważ niewielka grupa nie reprezentuje wszystkich potrzeb i scenariuszy. Najlepszy model łączy analizę automatyczną, ekspercką i użytkową.
Plan naprawczy i retest
Raport trzeba przełożyć na zadania pogrupowane według przyczyny i właściciela. Błąd globalnego komponentu może rozwiązać setki wystąpień. Problem dokumentów może wymagać zmiany szablonu, procedury i umowy, a nie ręcznej naprawy każdego pliku. Priorytet powinien uwzględniać wpływ na użytkownika, znaczenie usługi, zasięg i pilność.
Każde zadanie potrzebuje kryterium akceptacji i retestu. Informacja „programista poprawił” nie jest dowodem, że element działa z klawiaturą i czytnikiem ekranu. Retest sprawdza także, czy poprawka nie wprowadziła regresji. Wynik powinien aktualizować backlog, dokumentację i deklarację, jeżeli zmienił się stan faktyczny.
Zamówienie i odbiór dostępnego rozwiązania
Dostępność musi pojawić się w analizie potrzeb, opisie przedmiotu zamówienia, projekcie, kryteriach odbioru, gwarancji i utrzymaniu. Ogólne zdanie „zgodne z WCAG” nie określa wersji, poziomu, zakresu ani dowodu. Wymagania powinny objąć także dokumenty, treści demonstracyjne, panel redakcyjny, komponenty zewnętrzne oraz aktualizacje.
Oświadczenie wykonawcy jest pomocne, ale nie zastępuje odbioru. Podmiot powinien mieć prawo do testów, raportu, retestu i odmowy odbioru błędu. Umowa musi określać termin naprawy oraz odpowiedzialność za regresje. W przypadku rozwiązania abonamentowego dostępność powinna być utrzymywana przez cały czas świadczenia usługi.
Szczególne ryzyko tworzą platformy biletowe, płatności, transmisje, mapy, formularze i rozwiązania osadzane z innych domen. Wymagania należy stawiać przed wyborem produktu. Po podpisaniu umowy możliwości negocjacji są znacznie mniejsze.
WordPress: dostępny motyw nie wystarczy
WordPress może być podstawą dostępnego serwisu, ale wynik zależy od motywu, wtyczek, własnego kodu, konfiguracji i treści. Oznaczenie motywu jako „accessibility-ready” opisuje określony proces przeglądu, nie gwarantuje zgodności gotowej strony i wszystkich rozszerzeń.
Przed wdrożeniem trzeba przetestować szablony, menu, wyszukiwarkę, formularze, komunikaty, galerie, karuzele, modale i panel zgód. Redaktor powinien mieć bezpieczne komponenty oraz ograniczony wybór formatowania. Kreator pozwalający dowolnie zmieniać kolory i strukturę może szybko zniszczyć dostępność nawet poprawnego motywu.
Aktualizacje są konieczne dla bezpieczeństwa, ale wymagają testów regresji. Naprawy nie powinny być wprowadzane bez dokumentacji w sposób, który zniknie przy kolejnej wersji. Dostępność, bezpieczeństwo i wydajność muszą być utrzymywane razem.
Model stałego utrzymania
Dojrzała organizacja zna swoje zasoby, właścicieli i ryzyka. Ma standard publikacji, szablony dokumentów, kontrolę odbioru, rejestr zgłoszeń i plan naprawczy. Szkolenie nie jest jednorazowe: nowe osoby otrzymują wdrożenie, a zespół aktualizuje wiedzę po zmianach systemu i przepisów.
Warto monitorować kilka mierników: liczbę nowych barier, czas obsługi żądań, udział dokumentów posiadających pliki źródłowe, wykonanie retestów, stan kluczowych procesów i zaległe przeglądy treści. Nie chodzi o tworzenie rankingu dla samego rankingu. Dane mają wskazywać, gdzie proces przestaje działać.
Najważniejsza zmiana polega na przesunięciu dostępności z końca projektu na początek decyzji. Gdy wymagania pojawiają się dopiero po zakupie systemu albo po publikacji tysięcy dokumentów, naprawa jest kosztowna i konfliktowa. Gdy są częścią projektowania, umowy, tworzenia treści i kontroli, stają się zwykłym elementem jakości.
Od czego zacząć
Pierwszym krokiem nie musi być pełny audyt całego cyfrowego środowiska. Warto sporządzić listę stron, aplikacji, BIP, systemów zewnętrznych, dokumentów i właścicieli. Następnie wybrać kluczowe procesy użytkownika, sprawdzić deklaracje oraz zatrzymać najczęstsze źródła nowych barier. Taki przegląd pozwala dobrze zamówić badanie i od razu wykorzystać jego wynik.
Jeżeli serwis ma już raport, potrzebuje planu naprawczego i retestów. Jeżeli powstaje nowy system, potrzebuje wymagań oraz niezależnego odbioru. Jeżeli największym problemem są treści, pierwszeństwo mają standard redakcyjny, szablony i odpowiedzialność. Punkt startu zależy od organizacji, ale cel pozostaje ten sam: dostępność ma działać w praktyce, a nie wyłącznie w deklaracji.
Źródła
- Ustawa o dostępności cyfrowej — tekst jednolity: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20230001440
- Ustawa o zapewnianiu dostępności — tekst jednolity: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20190001696
- Serwis Ministerstwa Cyfryzacji: https://www.gov.pl/web/dostepnosc-cyfrowa/
- WCAG 2.2: https://www.w3.org/TR/WCAG22/
- How to Meet WCAG 2.2: https://www.w3.org/WAI/WCAG22/quickref/