A11y sprawdzamy: Szybki audyt dostępności strony mObywatel – część 2.

Wstęp

W drugiej części szybkiego audytu dostępności usługi mObywatel z serii „A11y sprawdzamy” przyglądamy się elementom, które w praktyce przesądzają o komforcie korzystania z serwisu bez myszy: nawigacji klawiaturą, widoczności fokusu oraz dostępności formularzy – jako próbkę wybraliśmy proces zakładania skrzynki e-Doręczeń. Sprawdzamy, czy interfejs prowadzi użytkownika konsekwentnie przez kolejne kroki i gdzie pojawiają się bariery, które mogą utrudniać przejście ścieżki. 

Przeczytaj pierwszą część audytu dostępności mObywatel.

W audycie przeanalizowaliśmy trzy podstrony:

• Ścieżka ze strony głównej do logowania do serwisu – sprawdziliśmy, czy łatwo dotrzeć do logowania oraz czy wybór metody uwierzytelnienia jest czytelny. Testowana była często używana ścieżka – logowanie przez Profil zaufany.
  Dlaczego istotna: bez poprawnego logowania użytkownik nie ma dostępu do żadnych usług serwisu.

• Dashboard po zalogowaniu – pierwszy widok po zalogowaniu. Użytkownik widzi dostępne funkcje, dokumenty i usługi.
  Dlaczego istotna: od czytelności tego widoku zależy, czy użytkownik szybko odnajdzie potrzebne opcje i zrozumie możliwości serwisu.
• Formularz zakładania skrzynki e-Doręczeń – Od 1 stycznia 2026 korzystanie z wielu e-usług będzie możliwe tylko po założeniu skrzynki do e-Doręczeń.
  Dlaczego istotna: skoro jest to podstawowa forma kontaktu z urzędem, formularz musi być w pełni dostępny dla wszystkich użytkowników.

Cel i zakres audytu

Audyt przeprowadzono w ramach cyklu krótkich analiz stron internetowych i aplikacji pod kątem dostępności cyfrowej. Celem jest ocena, w jakim stopniu serwisy publiczne spełniają podstawowe wymogi WCAG 2.1 AA oraz wymagania polskiej Ustawy o dostępności cyfrowej z 2019 roku.

Zakres audytu ma charakter orientacyjny i dotyczy stanu strony w dniu badania.

Metoda audytu

Audyt został przeprowadzony autorską metodą szybkiej oceny Accesscheck, z wykorzystaniem obserwacji eksperckich i testów automatycznych. Ocenie poddajemy od 7 do maksymalnie 10 kluczowych kryteriów, obejmujących najczęściej spotykane błędy dostępności. Analiza obejmuje maksymalnie trzy, cztery widoki – te, od których użytkownik najczęściej rozpoczyna korzystanie z usługi.

Wynik ogólny dostępności strony określany jest trzystopniowej skali:

• Dostępna – strona spełnia zdecydowaną większość kryteriów WCAG 2.1 AA. Ewentualne niezgodności mają charakter marginalny i nie wpływają znacząco na dostępność treści.
• Częściowo dostępna – strona spełnia dużą część wymagań, jednak zawiera istotne błędy w wybranych obszarach (np. nawigacja, formularze, multimedia). Mogą one ograniczać dostępność dla części użytkowników.
• Niedostępna – strona nie spełnia kluczowych kryteriów WCAG 2.1 AA. Błędy w strukturze, nawigacji lub interakcji powodują, że część użytkowników nie może w pełni lub w ogóle korzystać z treści.

5. Obsługa z poziomu klawiatury i widoczność fokusu

2.1.1 Klawiatura (A), 2.1.2 Bez pułapki na klawiaturę (A),, 2.4.7 Widoczność fokusu (AA)

Dlaczego to ważne

Możliwość obsługi strony za pomocą klawiatury i widoczny fokus są kluczowe dla osób, które nie korzystają z myszy – np. z powodu preferencji osobistych, ograniczeń ruchowych lub problemów ze wzrokiem. Każdy element interaktywny (link, przycisk, pole formularza) powinien być dostępny z klawiatury, a aktualnie wybrany element musi być wyraźnie zaznaczony. Na ogół jest on wyróżniony poprzez ramkę oraz zmianę koloru. Dzięki temu użytkownik wie, na jakim elemencie się znajduje.

Co sprawdziliśmy

• Czy wszystkie linki, przyciski i pola formularzy można obsłużyć wyłącznie za pomocą klawiatury.
• Czy fokus (aktywny element) jest zawsze widoczny podczas nawigacji.
• Czy kolejność przechodzenia między elementami (tabulacja) jest logiczna i spójna.
• Czy nie występują pułapki klawiaturowe, z których nie można wyjść bez użycia myszy.

Wyniki

Ścieżka dotarcia do usługi mObywatel oraz badane podstrony są dostępne z poziomu klawiatury – użytkownik może przejść przez większość elementów, a ich zachowanie w dużej mierze odpowiada typowym wzorcom interakcji. Fokus podczas nawigacji jest wyraźny i konsekwentnie widoczny na wszystkich sprawdzanych widokach.

Na badanych podstronach wszystkie elementy klikalne są osiągalne klawiaturą. Kolejność fokusu również jest zasadniczo poprawna, z jednym wyjątkiem opisanym poniżej.

Strona główna

Plusy:

• Nawigacja główna opiera się na natywnych elementach (button, linki a) osadzonych w obrębie <nav>, co wspiera przewidywalną obsługę klawiaturą.
• Przycisk otwierający menu ma poprawnie zdefiniowaną relację z panelem nawigacji (aria-controls="gov-menu", id="gov-menu") oraz komunikację stanu rozwinięcia (aria-expanded).

Do poprawy:

• Kolejność fokusu – baner z ciasteczkami

Baner informujący o plikach cookie wyświetla się na dole strony i nie zasłania treści. Użytkownik może przewijać stronę i korzystać z linków bez jego zamykania, więc w tym przypadku nie ma konieczności stosowania pułapki fokusu. Stosuje się ją wtedy, gdy element działa jak okno modalne i ma „zamknąć” użytkownika w jednym obszarze interfejsu – tak, by fokus nie uciekał tabulatorem do treści pod spodem, dopóki użytkownik nie zamknie okna lub nie wykona wymaganej akcji.

Problemem jest jednak kolejność elementów w kodzie HTML. Baner znajduje się na końcu dokumentu i wyświetlany jest na dole strony, przez co osoba nawigująca klawiaturą trafia na niego dopiero po przejściu przez:

• skip linki „Przejdź do sekcji”,
• nawigację,
• treść główną,
• stopkę.

W efekcie użytkownik może rozpocząć korzystanie z serwisu bez świadomego wyboru dotyczącego prywatności.

Możliwe rozwiązania:

• przenieść fokus na baner w momencie jego wyświetlenia (z zachowaniem możliwości łatwego zamknięcia i powrotu do miejsca, w którym użytkownik był wcześniej),
• umieścić baner wyżej w strukturze HTML tak, aby pojawiał się wcześniej w kolejności tabulacji.

Strona dashboardu

Uwagi

• Na podstronie dashboardu nawigacja boczna została zaimplementowana inaczej niż na stronie startowej wejścia do usługi – jako komponent ARIA menu (role="menu" i role="menuitem"). W praktyce użytkownik może poruszać się po pozycjach wyłącznie tabulatorem, bez obsługi strzałek góra/dół zgodnej ze wzorcem WAI-ARIA. W efekcie deklarowane role ARIA nie odzwierciedlają rzeczywistego zachowania komponentu, co stanowi naruszenie WCAG 4.1.2 Nazwa, rola, wartość.

6. Obsługa formularzy

1.3.1 Informacje i relacje (A), 3.3.2 Etykiety lub instrukcje (A), 4.1.2 Nazwa, rola, wartość (A)

Dlaczego to ważne?

Etykiety pól formularzy pozwalają użytkownikom zrozumieć, jakie dane należy wpisać w poszczególne pola. Dzięki nim korzystanie z formularzy staje się prostsze i bardziej intuicyjne.

Są szczególnie istotne dla osób korzystających z czytników ekranu – technologia ta odczytuje etykiety i informuje użytkownika, jakiego rodzaju informacje są wymagane w danym polu. Brak etykiet sprawia, że osoby niewidome lub słabowidzące nie mogą samodzielnie wypełnić formularza.

Etykiety powinny być zawsze widoczne, niezależnie od rozdzielczości ekranu i zawartości wpisanej w pole.

Co sprawdziliśmy

• Czy pola formularzy mają prawidłowo przypisane etykiety (<label> lub atrybuty ARIA).
• Czy czytniki ekranu poprawnie interpretują strukturę formularza i relacje między elementami.
• Czy każde pole ma czytelną i jednoznaczną etykietę lub instrukcję.
• Czy etykiety są zawsze widoczne – niezależnie od rozdzielczości ekranu i wpisanej treści.
• Czy pola wymagane są odpowiednio oznaczone (, required, aria-required).
• Czy zastosowano grupowanie pól przy użyciu <fieldset> i <legend>, jeśli jest to uzasadnione.
• Czy elementy interaktywne mają określoną nazwę, rolę i wartość – poprzez semantyczne znaczniki HTML lub ARIA.
• Czy komponenty dynamiczne (np. komunikaty, panele dialogowe, zakładki) są dostępne dla czytników ekranu.
• Czy aktualny stan elementów (np. rozwinięty, aktywny, ukryty) jest prawidłowo przekazywany technologii asystującej.

Wyniki

Formularz zakładania skrzynki e-Doręczeń

Formularz jest zbudowany semantycznie: całość działa w ramach <form>, a pola – tam gdzie trzeba – są pogrupowane w czytelne sekcje (np. „Twoje dane”, „Adres do korespondencji”). Dla pól zastosowano spójny układ: etykieta, kontrolka i miejsce na komunikat błędu.

Radiobuttony są poprawnie zorganizowane jako fieldset i legend, a elementy akcji („Anuluj”, „Dalej”, „Wyczyść pole”) są oznaczone jako <button>, więc działają natywnie z klawiaturą.

• Dobrze obsłużona walidacja błędów – walidacja została zaimplementowana w sposób przyjazny dla technologii asystujących: błędnie wypełnione pola są oznaczane atrybutem aria-invalid, komunikat błędu jest jednoznacznie powiązany z polem przez aria-errormessage, a sama treść ostrzeżenia jest ogłaszana przez czytniki ekranu dzięki aria-live="assertive".

‍

7. Tytuł strony i język strony

2.4.2 Tytuł strony (A), 3.1.1 Język strony (A), 3.1.2 Język części (AA)

Dlaczego to ważne?

Tytuł strony informuje użytkowników o zawartości i celu strony, a także pomaga im w orientacji podczas przeglądania wielu zakładek. Jest widoczny na pasku przeglądarki, w wynikach wyszukiwania oraz w historii odwiedzonych stron. Dla osób korzystających z czytników ekranu tytuł ma szczególne znaczenie – to pierwsza informacja, jaką słyszą po wejściu na stronę. Tytuł wpływa również na pozycjonowanie w wyszukiwarkach. Powinien być unikalny dla każdej podstrony i zawierać kluczowe informacje, takie jak nazwa podstrony i nazwa serwisu.

Poprawne oznaczenie języka strony (atrybut lang) pozwala czytnikom ekranu prawidłowo odczytywać treść w odpowiednim języku i tonie głosu.

Brak lub błędne oznaczenie języka utrudnia zrozumienie treści, szczególnie na stronach wielojęzycznych. Każda strona powinna mieć ustawiony język główny, a fragmenty w innych językach – lokalne oznaczenie (lang="en", lang="de").

Co sprawdziliśmy

• Czy podstrony serwisu posiadają tytuł opisujący ich cel lub temat.
• Czy w kodzie strony ustawiono główny język dokumentu (<html lang="pl">)
• Czy fragmenty treści w innych językach mają lokalne oznaczenie (lang="en", lang="de", itp.)

Wyniki

Język strony

• Każda z audytowanych stron ma prawidłowo określony język dokumentu.

Tytuł strony

Formularz zakładania skrzynki e-Doręczeń

Sprawdzane podstrony posiadają precyzyjnie zdefiniowane tytuły

<title>Uzyskaj adres do e-Doręczeń u publicznego dostawcy usługi - Gov.pl - Portal Gov.pl</title>

8. Bezpośredni dostęp (skip links)

2.4.1 Możliwość pominięcia bloków (A)

Dlaczego to ważne?

Odnośniki umożliwiające pominięcie powtarzających się sekcji (tzw. skip links) ułatwiają szybkie przejście do głównej treści strony. Dzięki nim użytkownik może pominąć elementy takie jak nagłówek czy menu i od razu przejść do najważniejszych informacji.

To szczególnie ważne dla osób korzystających z klawiatury lub czytników ekranu, które muszą nawigować po stronie sekwencyjnie. Brak takiego rozwiązania zmusza je do wielokrotnego używania klawisza Tab, co utrudnia i spowalnia poruszanie się po stronie.

Co sprawdziliśmy

• Czy na początku strony znajduje się odnośnik umożliwiający przejście do głównej treści (np. „Przejdź do treści”).
• Czy ten odnośnik jest dostępny z poziomu klawiatury i widoczny po uzyskaniu fokusu.

Wyniki

Skip linki są obecne i działają prawidłowo.

9. Dopasowanie do ekranu

1.3.4 Orientacja (AA), 1.4.10 Dopasowanie do ekranu (AA), 1.4.4 Zmiana rozmiaru tekstu (AA)

Dlaczego to ważne?

Dopasowanie strony do różnych rozmiarów ekranów zapewnia wygodne korzystanie z niej na komputerach, tabletach i smartfonach. Dzięki temu użytkownicy nie muszą przewijać strony w poziomie ani powiększać widoku, aby odczytać treść czy kliknąć przycisk.

Co sprawdziliśmy

• Czy strona automatycznie dopasowuje się do rozmiaru okna i orientacji ekranu (pion/poziom) bez utraty treści lub funkcjonalności
• Czy treść strony nie traci informacji ani funkcjonalności i nie wymaga przewijania w poziomie przy szerokości ekranu 320 px, z wyjątkiem elementów, które tego naturalnie wymagają (np. tabele danych, wykresy, paski narzędzi).
• Czy tekst można powiększyć do 200% bez utraty zawartości lub funkcjonalności – bez obcinania, nakładania się elementów ani utraty czytelności
• Czy elementy interfejsu (np. przyciski, formularze, menu) pozostają czytelne, dostępne i zachowują właściwe proporcje w widoku mobilnym

Wyniki

Wszystkie kryteria są spełnione.

Podsumowanie

Ogólna ocena dostępności strony

Ocena: Strona jest dostępna

Badane widoki serwisu mObywatel umożliwiają samodzielne korzystanie z kluczowych funkcji przy użyciu klawiatury oraz technologii asystujących. Fokus jest konsekwentnie widoczny, podstawowa ścieżka użytkownika jest przewidywalna, a formularz zakładania skrzynki e-Doręczeń został wdrożony w sposób dojrzały (semantyka, grupowanie, walidacja i komunikaty). Zidentyfikowane niezgodności mają charakter punktowy i nie blokują przejścia przez główny proces, jednak warto je poprawić, aby zwiększyć spójność i przewidywalność interakcji.

Co działa dobrze

• Obsługa klawiaturą – elementy interaktywne są osiągalne, a fokus jest wyraźny i konsekwentny na sprawdzanych widokach.
• Skip linki – działają poprawnie i ułatwiają szybkie przejście do treści.
• Formularz e-Doręczeń – poprawna semantyka (<form>, sekcje, fieldset/legend), natywne przyciski oraz spójny układ pól.
• Walidacja błędów – czytelna i dobrze komunikowana technologiom asystującym (aria-invalid, aria-errormessage, aria-live).
• Tytuły podstron i język dokumentu – prawidłowo zdefiniowane.
  Dopasowanie do ekranu – brak utraty treści i funkcjonalności na wąskich widokach i po powiększeniu.
  
  

‍