Czy urząd musi wdrożyć WCAG 2.2? 

Polska administracja publiczna nie ma jeszcze formalnego obowiązku prawnego wdrażania standardu WCAG 2.2 w zakresie dostępności cyfrowej. Obecnie, podczas corocznego monitoringu, Ministerstwo Cyfryzacji weryfikuje serwisy internetowej samorządowe i rządowe wyłącznie pod kątem wytycznych WCAG 2.1 na poziomie AA. 

Pomimo braku wymagań stosowania WCAG 2.2, zamawianie nowego portalu dla miasta, strony urzędu gminy czy Biuletynu Informacji Publicznej (BIP) wyłącznie w standardzie dostępności 2.1 jest błędem technologicznym i inwestycyjnym, który za kilka lub kilkanaście miesięcy wymusi poprawki. Będzie to więc zbędny wydatek dla jednostki, który można zaoszczędzić na starcie, realizując witrynę zgodną z WCAG 2.2. 

Dlaczego WCAG 2.2 nie jest jeszcze formalnie wymagane w urzędach? 

Rozdźwięk między publikacją nowego standardu a obowiązkami urzędu wynika ze specyfiki unijnego i polskiego procesu legislacyjnego. 

1. Źródło prawa w Polsce: Podstawowym aktem prawnym regulującym dostępność serwisów administracji jest 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). Załącznik do tej ustawy zawiera tabelę bezpośrednio mapującą kryteria sukcesu standardu WCAG 2.1 na poziomie AA.
2. Mechanizm norm zharmonizowanych (EN 301 549): Polskie przepisy stanowią implementację unijnej Dyrektywy 2016/2102. Zgodnie z prawem unijnym domniemanie zgodności z dyrektywą daje spełnienie zharmonizowanej normy europejskiej EN 301 549.
3. Ścieżka wdrożeniowa: Choć konsorcjum W3C wydało WCAG 2.2 jako oficjalną rekomendację, standard ten nie staje się prawem automatycznie. Europejskie organizacje normalizacyjne (CEN, CENELEC, ETSI) muszą najpierw zaktualizować normę EN 301 549, a Komisja Europejska musi opublikować odniesienie do niej w Dzienniku Urzędowym UE. Dopiero wówczas nasz prawodawca znowelizuje załącznik do ustawy krajowej. 

W konsekwencji żaden podmiot publiczny nie otrzyma dziś kary od Ministra Cyfryzacji za brak spełnienia wytycznych specyficznych dla WCAG 2.2. Cały czas, obowiązującym standardem wymaganym pozostaje WCAG 2.1. 

Podstawowe różnice pomiędzy WCAG 2.1 a WCAG 2.2 

Standard WCAG 2.2 opiera się na zasadzie wstecznej kompatybilności: strona spełniająca wymagania WCAG 2.2 automatycznie spełnia wersję 2.1. Wprowadzono jedno wycofanie przestarzałego kryterium oraz 6 nowych wymagań na poziomach A i AA, które bezpośrednio dotyczą serwisów internetowych i aplikacji mobilnych jednostek publicznych. 

1. Kryterium wycofane (obsolete) 

• 4.1.1 Parsowanie (Poziom A): Zostało usunięte ze standardu WCAG 2.2. W dobie nowoczesnych silników przeglądarek i ustandaryzowanego parsowania kodu HTML błędy takie jak niedomknięte znaczniki przestały blokować czytniki ekranu. W testach WCAG 2.2 kryterium to uznaje się za automatycznie spełnione. 

 2. Nowe kryteria sukcesu na poziomach A i AA 

Kryterium WCAG 2.2	Poziom	Czego wymaga od strony urzędu?	Przełożenie na sprawy mieszkańca
2.4.11 Obramowanie fokusu (Focus Not Obscured - Min.)	AA	Aktywny element nawigacji klawiaturą (np. zaznaczony link, pole formularza) nie może być całkowicie zakryty przez inne warstwy interfejsu.	Paski cookies, pływające banery czy przyklejone menu główne (sticky header) nie mogą zasłaniać pola, w które mieszkaniec wpisuje dane za pomocą klawisza Tab.
2.5.7 Ruchy przeciągania (Dragging Movements)	AA	Każda funkcja wymagająca przeciągania elementów (drag-and-drop) musi posiadać alternatywę obsługiwaną pojedynczym kliknięciem.	Jeśli interaktywny plan zagospodarowania lub sortowanie załączników wymaga przeciągania myszą, muszą być dostępne zwykłe przyciski klikalne (np. strzałki góra/dół).
2.5.8 Rozmiar celu (Target Size - Min.)	AA	Minimalny rozmiar elementów klikalnych i dotykowych to 24×24 piksele CSS (lub odpowiedni odstęp od sąsiednich elementów).	Mieszkaniec obsługujący portal urzędu na smartfonie nie kliknie przypadkowo sąsiedniej kategorii w menu BIP.
3.2.6 Spójna pomoc (Consistent Help)	A	Jeśli serwis udostępnia formy kontaktu lub pomocy, muszą one znajdować się w tej samej relatywnej pozycji na każdej podstronie.	Mieszkaniec szukający numeru telefonu do biura obsługi lub odnośnika do czatu zawsze znajdzie go w tym samym miejscu (np. w nagłówku lub stopce).
3.3.7 Ponowne wprowadzanie (Redundant Entry)	A	Formularze wieloetapowe nie mogą wymagać ponownego wpisywania tych samych danych w tej samej sesji procesu.	Przy składaniu wniosku przez e-formularz dane wnioskodawcy (PESEL, adres) wprowadzone w kroku 1 muszą automatycznie przenieść się do kolejnych kroków.
3.3.8 Dostępne uwierzytelnianie (Accessible Authentication - Min.)	AA	Logowanie i autoryzacja nie mogą opierać się na testach kognitywnych (zagadkach, przepisywaniu obrazków CAPTCHA czy zapamiętywaniu haseł bez opcji wklejenia).	Formularze logowania do portalu mieszkańca muszą obsługiwać menedżery haseł (działać ze schowkiem systemowym) oraz wspierać autoryzację np. przez Profil Zaufany lub biometrię.

(Pozostałe 3 nowe kryteria z WCAG 2.2 – 2.4.12, 2.4.13 oraz 3.3.9 – znajdują się na poziomie AAA, który jest rekomendowany jako dobra praktyka, ale nie stanowi wymogu prawnego dla sektora publicznego). 

Dlaczego zamawianie serwisu wyłącznie w WCAG 2.1 to błąd inwestycyjny? 

Średni cykl życia Strony WWW urzędu lub systemu BIP w polskim samorządzie wynosi od 4 do 7 lat. Proces formalnej aktualizacji normy EN 301 549 oraz polskiej ustawy o dostępności cyfrowej sprawi, że w trakcie eksploatacji tworzonego dziś serwisu WCAG 2.2, z bardzo dużym prawdopodobieństwem, stanie się wymogiem bezwzględnym. 

Uchwalenie nowelizacji przepisów postawi podmioty publiczne przed koniecznością przeprowadzenia kosztownych audytów oraz zlecenia prac programistycznych pod presją czasu na dostosowanie. Wprowadzenie zasad WCAG 2.2 na etapie projektowania architektury informacji, szablonów graficznych i kodu HTML5 nie podnosi odczuwalnie kosztu realizacji nowej strony internetowej. Z kolei późniejsza modyfikacja gotowego, wdrożonego systemu (zwłaszcza w zakresie logiki wieloetapowych formularzy czy architektury widoków mobilnych) wiąże się ze znaczącymi wydatkami budżetowymi i koniecznością rozpisywania kolejnych postępowań przetargowych.  

Jak sformułować zapis w OPZ, aby zabezpieczyć urząd? 

Aby jednostka samorządu terytorialnego lub instytucja publiczna otrzymała portal przygotowany na zmiany przepisów, w Opisie Przedmiotu Zamówienia (OPZ) lub zapytaniu ofertowym warto zastosować precyzyjną klauzulę:

„Wykonawca zobowiązany jest do zaprojektowania i wdrożenia serwisu internetowego zgodnie z wymogami Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848), z uwzględnieniem wytycznych standardu Web Content Accessibility Guidelines (WCAG 2.2) na poziomie AA.” 

 

Zapis ten powinien gwarantować urzędowi bezpieczeństwo prawne podczas kontroli ministerialnych już teraz, a jednocześnie chroni budżet jednostki przed wydatkami na dostosowanie serwisu, gdy standard 2.2 zostanie wpisany do polskiego porządku prawnego. 

Przygotowujesz przetarg lub planujesz modernizację strony urzędu? 

W IntraCOM.pl od lat tworzymy serwisy internetowe i Biuletyny Informacji Publicznej (BIP) w oparciu o realną dostępność cyfrową. Dbamy o to, aby zamawiane u nas portale nie tylko przechodziły bez zastrzeżeń bieżący monitoring Ministerstwa Cyfryzacji, ale aby były w pełni przygotowane na nadchodzące zmiany przepisów. 

• Tworzysz dokumentację przetargową? Prześlij nam swój projekt OPZ lub zapytania ofertowego – zweryfikujemy zapisy techniczne dotyczące WCAG, aby chronić Twoją jednostkę przed nierzetelnymi wykonawcami.
• Nie masz pewności, czy obecna strona spełnia wytyczne? Zgłoś się do nas na konsultację – sprawdzimy stan techniczny Twojego serwisu i wskażemy, które elementy wymagają pilnych poprawek. 

Skontaktuj się z ekspertami IntraCOM.pl – porozmawiajmy o bezpiecznym, dostępnym cyfrowo wdrożeniu nowej Strony WWW dla Twojego urzędu.