Dostępność cyfrowa systemów PDWD - obowiązki JST i zgodność z WCAG 2.1

Systemy do prowadzenia Publicznie Dostępnych Wykazów Danych Środowiskowych (PDWD), o ile są stronami internetowymi posiadanymi lub zarządzanymi przez podmiot publiczny, podlegają wymogom ustawy o dostępności cyfrowej - tak samo jak BIP czy portal gminy. Warto więc sprawdzić, czy system spełnia podstawowe kryteria dostępności, także te na poziomie A - czyli najniższym z wymaganych.

Podstawa prawna: ustawa z 4 kwietnia 2019 r.

Ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (t.j. Dz.U. 2023 poz. 1440) implementuje Dyrektywę UE 2016/2102. Nakłada ona obowiązek zapewnienia zgodności z wytycznymi WCAG 2.1 na poziomie AA na strony internetowe i aplikacje mobilne podmiotów publicznych - w tym BIP-y, portale gminne i systemy PDWD, które podmiot publiczny posiada lub którymi zarządza. Wyłączenie z art. 3 ust. 2 pkt 6 dotyczy treści prezentowanych w intranecie lub ekstranecie, opublikowanych przed 23 września 2019 r., jeżeli od tego czasu nie podlegały przebudowom ani zmianom objętym tym przepisem, dotyczącym m.in. wyglądu, struktury lub sposobu publikowania informacji. Zastosowanie wyłączenia należy ocenić indywidualnie.

Ustawa weszła w życie stopniowo:

• Strony opublikowane po 23.09.2018 r. - wymogi od 23 września 2019 r.
• Strony opublikowane przed 23.09.2018 r. - wymogi od 23 września 2020 r. (12-miesięczny okres przejściowy)
• Aplikacje mobilne - wymogi od 23 czerwca 2021 r.

Nowe treści dodawane do systemu od tych dat - w tym kolejne karty informacyjne wpisywane do PDWD - podlegają wymogom w pełni, niezależnie od tego, kiedy uruchomiono sam system.

Które systemy muszą spełniać wymogi

Obowiązek dotyczy stron internetowych i aplikacji mobilnych, które posiada podmiot publiczny lub którymi zarządza. W przypadku PDWD mogą to być:

• Systemy do prowadzenia PDWD dostępne pod własną domeną (np. dedykowane portale gminne lub powiatowe)
• Moduły PDWD wbudowane w portal urzędu lub BIP
• Strona urzędu na platformie SaaS dostawcy, jeśli urząd jest jej posiadaczem lub zarządcą. Gdy urząd publikuje informacje w serwisie zewnętrznym, który nie spełnia wymagań dostępności, publikuje te same informacje w dostępny sposób na wybranej własnej stronie (art. 6 ustawy)
• Systemy informacji o środowisku (SIOS) prowadzone przez organy administracji rządowej i JST

Kluczowe kryteria WCAG 2.1 AA dla systemów PDWD

WCAG 2.1 składa się z 78 kryteriów sukcesu. Poniżej te najistotniejsze z perspektywy systemu wykazów, czyli formularzy wyszukiwania, tabel wyników i stron ze szczegółami kart informacyjnych:

Typowe naruszenia w systemach PDWD

Poniżej błędy, które warto sprawdzić w każdym systemie tego rodzaju - naruszają one kryteria WCAG 2.1 na poziomach A i AA:

• ✗
  Brak <meta name="viewport"> - strona może wyświetlać wersję desktopową w miniaturze, trudną do odczytania na urządzeniach mobilnych. Brak tego znacznika to sygnał do sprawdzenia, czy treść jest czytelna po powiększeniu do 200% i czy układ strony działa poprawnie (kryterium 1.4.4, poziom AA) - sam brak znacznika nie przesądza automatycznie o naruszeniu.
• ✗
  Pola formularzy bez dostępnej nazwy - pole "Wpisz słowo kluczowe" nie ma dostępnej nazwy dla technologii wspomagających. Brak poprawnie nadanej dostępnej nazwy może uniemożliwiać czytnikowi ekranu przekazanie użytkownikowi przeznaczenia pola. Dostępna nazwa może pochodzić z label[for], owijającego elementu label lub aria-label - nie trzeba stosować ich wszystkich jednocześnie; wystarczy jeden poprawnie zastosowany mechanizm. Potencjalne naruszenie 1.3.1 i 3.3.2 (wymaga ręcznej weryfikacji).
• ✗
  Niedostateczny kontrast kolorów - tekst w kolorze złoto-oliwkowym na białym tle daje kontrast ~2,8:1, podczas gdy wymóg wynosi 4,5:1. Nieczytelne dla osób słabowidzących i w słabym oświetleniu. Naruszenie 1.4.3 (poziom AA).
• ✗
  Brak mechanizmu "przeskocz do treści" - osoba nawigująca klawiaturą musi tabulować przez całe menu główne na każdej podstronie, zanim dotrze do listy kart informacyjnych. Naruszenie 2.4.1 (poziom A).
• ✗
  Modale bez atrybutów ARIA - okno dialogowe otwierające szczegóły karty nie ma role="dialog", aria-modal="true" ani zarządzania focusem. Czytnik ekranowy nie informuje użytkownika o otwarciu okna. Naruszenie 4.1.2 (poziom A).
• ✗
  Nagłówki tabel użyte jako zwykłe komórki - tabela z listą kart używa elementów <td> zamiast <th> dla nagłówków kolumn. W prostych tabelach samo użycie <th> wystarcza; w złożonych tabelach wielopoziomowych stosuje się różne techniki powiązania danych z nagłówkami (scope, headers/id i inne). Potencjalne naruszenie 1.3.1 (wymaga ręcznej weryfikacji).

Deklaracja dostępności - obowiązek formalny

Poza samą zgodnością techniczną, ustawa (art. 10) wymaga opublikowania deklaracji dostępności. Struktura i wymagana treść deklaracji wynikają z art. 10 ustawy z 4 kwietnia 2019 r. (t.j. Dz.U. 2023 poz. 1440), wzoru z decyzji wykonawczej Komisji (UE) 2018/1523 oraz warunków technicznych publikacji udostępnianych przez ministra właściwego do spraw informatyzacji. Poza elementami wzoru (m.in. status zgodności ze wskazaniem odstępstw) deklaracja zawiera ponadto (art. 10 ust. 4):

• datę publikacji i datę ostatniej aktualizacji strony lub aplikacji
• informację lub link do informacji o sposobie dokonania oceny dostępności cyfrowej
• dane teleadresowe siedziby podmiotu publicznego wraz z danymi kontaktowymi osoby lub komórki odpowiedzialnej za dostępność cyfrową
• informacje o niestandardowych skrótach klawiszowych
• informację lub link do informacji o dostępności architektonicznej siedziby
• informację o dostępności tłumacza języka migowego za pośrednictwem środków komunikacji elektronicznej albo informację o jej braku
• informację o możliwości powiadomienia podmiotu publicznego o braku dostępności cyfrowej
• link do strony internetowej Rzecznika Praw Obywatelskich

Pełny katalog (m.in. link do aplikacji mobilnej, jeśli podmiot ją posiada) wskazuje art. 10 ust. 3-5 ustawy. Deklarację przegląda się i aktualizuje do 31 marca każdego roku oraz niezwłocznie po zmianach mogących mieć wpływ na dostępność (art. 11).

Brak deklaracji lub brak jej obowiązkowych elementów jest podstawą kary pieniężnej do 5000 zł, nakładanej, gdy brak ten zostanie wykazany w dwóch kolejnych monitorowaniach (art. 19 ust. 1 pkt 2, ust. 3 i ust. 5 pkt 2). Deklaracja powinna przy tym odzwierciedlać rzeczywisty stan dostępności.

Jak sprawdzić swój system - bezpłatne narzędzia

Pełny audyt WCAG wymaga testów z czytnikami ekranowymi i udziału użytkowników z niepełnosprawnościami. Wstępną ocenę można jednak przeprowadzić samodzielnie w kilka minut:

• 1.
  axe DevTools (rozszerzenie Chrome/Firefox, bezpłatne) - otwórz stronę systemu, uruchom axe, kliknij "Analyze". Wykrywa automatycznie wiele typowych naruszeń, choć nie zastąpi pełnego audytu manualnego. To najlepszy punkt startowy.
• 2.
  Lighthouse w Chrome DevTools - F12, zakładka Lighthouse, kategoria Accessibility, kliknij Analyze. Wynik poniżej 90 wskazuje na potencjalne problemy warte sprawdzenia; sam wynik nie jest jednak kwalifikacją prawną - wysoki wynik nie gwarantuje pełnej zgodności z WCAG.
• 3.
  Sprawdzenie viewport - Ctrl+U (kod źródłowy strony), Ctrl+F, wpisz "viewport". Brak wyników = strona nie ma meta viewport - to sygnał do sprawdzenia, czy treść jest czytelna po powiększeniu do 200% (kryterium 1.4.4).
• 4.
  Sprawdzenie etykiet formularzy - F12, Console, wpisz: document.querySelectorAll('input:not([aria-label]):not([id])').length. Wynik > 0 to sygnał do ręcznej weryfikacji - pole bez id i aria-label może mieć etykietę przez owijający element label, a pole z id może nadal nie mieć dostępnej nazwy. Potencjalne naruszenie 1.3.1.
• 5.
  Nawigacja klawiaturą - odłóż mysz i nawiguj klawiszem Tab. Czy widzisz wyraźny focus? Czy możesz wypełnić formularz wyszukiwania i przejść przez wyniki bez myszy? Jeśli nie - naruszenia 2.1.1 lub 2.4.7.

Co grozi za brak zgodności

Ustawa z 2019 r. przewiduje kilka ścieżek egzekwowania wymogów:

• Żądanie i skarga obywatelska (art. 18 ustawy) - każdy może złożyć do podmiotu publicznego żądanie zapewnienia dostępności konkretnej treści. Podmiot ma 7 dni na zapewnienie dostępności (art. 18 ust. 3), a jeśli to niemożliwe, informuje o przyczynach opóźnienia i nowym terminie nie dłuższym niż dwa miesiące od wystąpienia z żądaniem (ust. 4). W razie odmowy informuje o przyczynach i wskazuje alternatywny sposób dostępu (ust. 6). Po odmowie zapewnienia dostępności lub odmowie skorzystania z dostępu alternatywnego przysługuje skarga do tego podmiotu publicznego (art. 18 ust. 7; stosuje się przepisy działu VIII KPA, ust. 8). Właściwym adresatem skargi jest podmiot publiczny prowadzący daną stronę lub aplikację - nie dostawca oprogramowania, który nie jest podmiotem publicznym.
• Nadzór i monitoring ministra właściwego do spraw informatyzacji - minister monitoruje dostępność stron podmiotów publicznych raz w roku (art. 12 pkt 2) i publikuje wyniki w BIP w ciągu trzech miesięcy (art. 16). W ramach nadzoru może występować do podmiotów publicznych z zapytaniami (m.in. o liczbę i sposób załatwienia skarg) oraz nakładać kary pieniężne w drodze decyzji (art. 13 ust. 1). Kara do 10 000 zł dotyczy nieuzasadnionego i uporczywego braku dostępności, czyli braku poprawy w trzech kolejnych monitorowaniach przy rosnącej liczbie uzasadnionych skarg (art. 19 ust. 1 pkt 1, ust. 2 i ust. 5 pkt 1).

Źródłem postępowania może być żądanie lub skarga złożona przez osobę, która nie może skorzystać z systemu dostępnego publicznie. Liczba uzasadnionych skarg jest jedną z przesłanek uporczywego braku dostępności (art. 19 ust. 2).

Co z systemami dostawcy - kto odpowiada?

Ustawa nakłada obowiązki na podmiot publiczny, który posiada stronę internetową lub aplikację mobilną albo zarządza ich elementami (art. 2). Urząd, który korzysta z systemu dostawcy zewnętrznego (SaaS lub oprogramowanie instalowane), pozostaje stroną ustawy w odniesieniu do swoich stron i treści, a żądanie i skargę z art. 18 kieruje się do podmiotu publicznego, nie do firmy IT. Samego dostawcę, który nie jest podmiotem publicznym, ustawa nie obejmuje.

Oznacza to, że kupując lub przedłużając umowę na system PDWD, warto sprawdzić:

• Czy dostawca posiada deklarację zgodności z WCAG 2.1 AA dla oferowanego systemu?
• Czy dostarcza gotową deklarację dostępności do opublikowania na stronie urzędu?
• Czy aktualizacje systemu obejmują naprawy problemów dostępności?
• Czy system jest responsywny (działa na urządzeniach mobilnych)?