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

Wstęp

W poniższej drugiej części szybkiego audytu dostępności strony Rzecznika Finansowego kontynuujemy ocenę serwisu. Zobacz pierwszą część audytu dostępności strony Rzecznika Finansowego.

Strona Rzecznik Finansowy służy obywatelom do uzyskania informacji i pomocy w sporach z instytucjami finansowymi – takimi jak banki, ubezpieczyciele, firmy pożyczkowe czy towarzystwa emerytalne. Umożliwia złożenie wniosku o interwencję lub postępowanie polubowne, zapoznanie się z prawami konsumentów na rynku finansowym oraz skorzystanie z pomocy ekspertów Rzecznika.

W audycie sprawdzamy trzy kluczowe podstrony istotne dla doświadczenia użytkownika na tym portalu publicznym:

• Strona główna – to punkt startowy dla większości użytkowników, zarówno konsumentów, jak i dziennikarzy czy instytucji. Zawiera główne sekcje informacyjne, aktualności, skróty do usług, komunikaty o działalności Rzecznika oraz menu prowadzące do kluczowych obszarów tematycznych.
  Dlaczego istotna: od jakości i czytelności strony głównej zależy, czy użytkownik zrozumie strukturę serwisu i szybko odnajdzie potrzebne treści.

• Podstrona „Dla klientów – Wzory wniosków” – sekcja, w której użytkownicy szukają gotowych formularzy i dokumentów niezbędnych do złożenia wniosków o interwencję lub postępowanie polubowne.
  Dlaczego istotna: to miejsce, w którym użytkownik podejmuje pierwszy realny krok w kierunku rozwiązania swojego problemu.

• Podstrona „Wniosek o przeprowadzenie pozasądowego postępowania w sprawie rozwiązania sporu z podmiotem rynku finansowego” – podstrona opisująca możliwość złożenia wniosku o postępowanie polubowne oraz udostępniająca formularz do jego pobrania lub wypełnienia.
  Dlaczego istotna: stanowi końcowy etap ścieżki użytkownika poszukującego pomocy.

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.

6. 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 sprawdzaliś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

Ogólnie strona Rzecznika Finansowego jest częściowo dostępna z poziomu klawiatury – użytkownik może dotrzeć do większości elementów, jednak nie wszystkie zachowują się zgodnie z oczekiwanymi wzorcami interakcji.

Niestety formularz wniosku o przeprowadzenie pozasądowego postępowania w sprawie rozwiązania sporu z podmiotem rynku finansowego zawiera elementy, które nie są obsługiwalne klawiaturą (np. część pól wyboru – checkboxy), co oznacza, że nie da się go wypełnić.

Nawigacja główna

• Po aktywacji enterem elementu menu z rozwijanym podmenu fokus nie przenosi się na pierwszy element rozwiniętej listy.
  
• W obrębie submenu brakuje nawigacji strzałkami – zamiast przemieszczania się między pozycjami, przewija się tło strony.

Formularz wniosku

• Tabulator pomija niektóre pola, zwłaszcza checkboxy, przez co nie można ich zaznaczyć bez użycia myszy.

7. 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

W większości pola formularza mają prawidłowo przypisane etykiety <label> oraz użyto atrybutu aria-required="true", co zapewnia informację o wymaganiu pola dla technologii asystujących. Zidentyfikowaliśmy jednak kilka błędów i niespójności w strukturze formularza.

Wykryte problemy

• Etykiety – niektóre pola (np. Ulica) nie mają prawidłowo powiązanej etykiety (for i id), co utrudnia ich identyfikację przez czytniki ekranowe.
  

• Pytania jednokrotnego wyboru
  
  
  • Dla odpowiedzi wzajemnie wykluczających się (TAK/NIE) błędnie zastosowano checkboxy – zgodnie z zasadami dostępności powinny zostać użyte radio buttony.
  • Brakuje semantycznego grupowania pytania i odpowiedzi – należy zastosować elementy <fieldset> i <legend>, aby czytniki ekranowe mogły poprawnie rozpoznać kontekst pytania.

• Obsługa błędów
  
  • Komunikaty o błędach są niedostępne dla czytników ekranowych – zostały oznaczone aria-hidden="true", przez co nie są odczytywane.
  • Teksty komunikatów są zbyt ogólne (np. „Proszę wypełnić to pole”) i nie wskazują, którego pola dotyczą. Zalecamy stosowanie opisów w formacie: „Uzupełnij pole ulica” lub „Wpisz numer domu”.
  • Nie zastosowano atrybutu aria-describedby, który powinien łączyć komunikat o błędzie z konkretnym polem formularza.

• Sekcje formularza, które pojawiają się lub znikają dynamicznie (np. „Dane drugiego wnioskodawcy”, które wyskakują po kliknięciu “Nie”), nie mają prawidłowej komunikacji ARIA – kontrolki nie przekazują informacji o rozwinięciu (aria-expanded, aria-controls), a ukryte pola nie są oznaczone hidden ani aria-hidden. W efekcie czytniki ekranowe nie wiedzą, że treść się zmieniła, użytkownicy tracą kontekst, co uniemożliwia obsługę formularza.

Pomniejsze problemy

• Dla czytników można ukryć gwiazdkę dla pól wymaganych - informacja o wymaganiu pola już jest w kodzie.
• Placeholdery powielają treść etykiet i nie wnoszą dodatkowej wartości – mogą zostać usunięte.
• Dla czytników ekranowych można ukryć gwiazdkę przy polach wymaganych (aria-hidden="true"), ponieważ informacja o obowiązkowości pola jest już przekazywana przez aria-required lub required.
• Użycie masek mających w zamyśle podpowiadać format wprowadzania danych. Czytniki ekranu przeczytają to na przykład jako “podkreślenie podkreśleniemyślnik-podkreślenie-podkreślenie-podkreślenie” – to niewygodne dla użytkowników czytników ekranu.

• Niedostępny komponent wgrywania plików‍
  
  • Komponent dodawania plików nie jest dostępny – przycisk „Wgraj pliki z dysku” został zrealizowany jako link (<a href="#">), a nie przycisk (<input type="file">). Dla użytkowników korzystających z czytników ekranowych lub klawiatury oznacza to brak możliwości samodzielnego przesłania pliku i brak informacji o celu działania. Dodatkowo komponent nie przekazuje kontekstu (np. dozwolonych formatów czy liczby plików), przez co staje się nieczytelny dla technologii asystujących.

8. 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").

Wyniki

• Sprawdzane podstrony posiadają poprawnie zdefiniowane tytuły, jednoznacznie opisujące zawartość, np.:
• <title>Strona główna - Rzecznik Finansowy</title>
• <title>Wzory wniosków - Rzecznik Finansowy</title>
• Każda z audytowanych stron ma prawidłowo określony język dokumentu – polski w wersji podstawowej oraz ukraiński po przełączeniu języka.
• Nie stwierdzono fragmentów treści w innych językach niż język główny strony.

9. 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.

10. 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 częściowo dostępna

Strona Rzecznik Finansowy ma poważne braki dostępności – przede wszystkim nie da się jej w pełni obsłużyć samą klawiaturą, formularze są trudne lub momentami niemożliwe do wypełnienia bez myszy, a wiele linków nie mówi jasno, dokąd prowadzi i co się po kliknięciu stanie. Elementy statyczne wypadają lepiej (nagłówki, tytuły, język, kontrast, responsywność), ale to nie kompensuje problemów w kluczowych miejscach. W efekcie serwis – w sprawdzonych widokach – nie spełnia istotnej części wymagań dostępności i wymaga priorytetowych poprawek.

Co działa dobrze

• Struktura nagłówków jest logiczna i uporządkowana – dzięki temu treści są czytelne i łatwe do nawigacji.
• Tytuły stron i język zostały poprawnie zdefiniowane – strona rozpoznaje zarówno wersję polską, jak i ukraińską.
• Kontrast tekstów i elementów interfejsu jest w większości prawidłowy.
• Strona dobrze dopasowuje się do różnych urządzeń – działa poprawnie na komputerach i telefonach, a treści nie „rozsypują się” po powiększeniu.

Najważniejsze problemy do naprawy

• Obsługa klawiaturą i widoczność fokusu
  
  • Z poziomu klawiatury nie da się w pełni korzystać z menu i formularzy – niektóre elementy (np. checkboxy) są pomijane.

• Formularze
  
  • W wielu miejscach zastosowano niepoprawne typy pól (np. pytania TAK/NIE jako checkboxy zamiast radio)
  • Komunikaty o błędach nie są odczytywane przez czytniki ekranu, a niektóre etykiety nie są prawidłowo połączone z polami.

• Linki‍
  
  • Wiele linków nie mówi, dokąd prowadzi („Czytaj więcej”, „Link”).
  • Tagi w sekcji aktualności działają jak przyciski zamiast prawidłowych linków.

• Sekcje rozwijane‍
  
  • Pola, które pojawiają się po zaznaczeniu opcji (np. „Dane drugiego wnioskodawcy”), nie przekazują tej zmiany czytnikom ekranu, więc użytkownik nie wie, że pojawiły się nowe treści.

• Wgrywanie plików‍
  
  • Przycisk „Wgraj pliki z dysku” nie działa jak standardowy element dodawania plików.
  • Brakuje informacji o dopuszczalnych formatach i liczbie plików, co utrudnia zrozumienie, jak korzystać z tej funkcji.