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

Wstęp

Publikacja jest podzielona na dwie części i stanowi element naszego cyklu krótkich audytów serwisów publicznych. Przeczytaj pierwszą część audytu dostępności PKP Intercity.

W audycie sprawdziliśmy cztery podstrony najistotniejsze dla doświadczenia użytkownika na tym portalu:

• Strona główna – to punkt startowy dla odwiedzających.
  ‍
  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 Lista połączeń – Wyniki wyszukiwania połączeń – prezentuje dostępne połączenia odpowiadające podanym kryteriom. Użytkownik wybiera tu najdogodniejszą trasę, sprawdza godziny, przesiadki.
  
  Dlaczego istotna: jest to pierwszy moment realnej decyzji o wyborze podróży – problemy dostępności na tym etapie mogą uniemożliwić kontynuację zakupu.

• Podstrona Twoja podróz – Wybór miejsc – pozwala wybrać miejsce w wagonie lub zaakceptować automatyczny przydział; zawiera rozbudowane komponenty interfejsu: mapy wagonów, komunikaty i wybór opcji dodatkowych.
  
  Dlaczego istotna: nieczytelne etykiety, brak opisów miejsc lub problemy z obsługą klawiaturą mogą uniemożliwić użytkownikowi zakup biletu.
  
  
• Podstrona Płatność – ostatni etap, w którym użytkownik potwierdza dane zamówienia i wybiera formę płatności.
  
  Dlaczego istotna: to miejsce, które decyduje o konwersji. Błędy mogą zablokować finalizację zakupu.

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

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

Ogólnie 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.

Nawigacja główna

Plusy:

• Fokus jest zawsze widoczny podczas nawigacji na całej stronie.
• Nawigacja główna działa zgodnie z oczekiwanymi wzorcami obsługi klawiaturą. Rozwijane menu można aktywować Enterem, poruszanie się pomiędzy pozycjami submenu odbywa się za pomocą strzałek, a powrót do nawigacji pierwszego poziomu jest możliwy przy użyciu klawisza Esc.

Do poprawy:

• Element zmiany wielkości czcionki w nawigacji głównej jest pomijany podczas nawigacji klawiaturą, co oznacza, ze użytkownik tabulatora nie może zmieni rozmiaru fontów. Dzieje się tak, ponieważ w kodzie zastosowano elementy <span> zamiast semantycznego elementu <button>.

‍

• Przeniesienie fokusu na pierwszą pozycję w submenu po jego rozwinięciu – obecnie fokus nie przenosi się, więc użytkownik klawiatury musi dodatkowo naciśnąć Tab.

Wyszukiwanie połączenia

Nie wszystkie elementy są obsługiwane klawiaturą:

• Przycisk zamiany stacji (strzałki) otrzymuje fokus, ale nie reaguje na klawiaturę (Enter), ponieważ w kodzie nie użyto semantycznego znacznika <button>.

• Nie można za pomocą klawiatury wywołać komponentu kalendarza ani wybrać z niego daty. Interakcja ogranicza się wyłącznie do ręcznego wpisania daty w polu tekstowym.
• Pole wyboru godziny jest nieprawidłowo zaimplementowane i nie działa poprawnie ani z klawiatury, ani przy użyciu myszy – przy próbie zmiany wartości pole automatycznie wraca do aktualnej godziny.

‍

Lista połączeń – Wyniki wyszukiwania połączeń 

• Pułapka klawiaturowa – po otwarciu modala z filtrami fokus początkowo trafia do jego wnętrza, jednak po przejściu tabulatorem przez wszystkie interaktywne elementy fokus „ucieka” do treści strony znajdującej się pod modalem, co oznacza, że użytkownik musi  przeklikać tabulatorem całą stronę, zanim wróci do komponentu.
  

Twoja podróz – Wybór miejsc

Niedostępny z klawiatury wizualny wybór miejsc – fokus podczas nawigacji po komponencie zachowuje się niestabilnie – potrafi „zniknąć” i nie ma możliwości powrotu do elementu.
Co prawda możliwy jest alternatywny wybór miejsca z listy, jednak w momencie wejścia w wizualny wybór miejsc na mapie SVG za pomocą klawiatury użytkownik wpada w pułapkę fokusu.

Płatność 

Plusy:

• Wszystkie elementy na formularzu są dostępne z klawiatury.
• Formularz ma prawidłowo zaimplementowane wzorce obsługi klawiaturą. Checkboxy są zaznaczane klawiszem spacji, a poruszanie się pomiędzy opcjami w obrębie grupy radio odbywa się za pomocą klawiszy strzałek.
  

‍

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.

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.

Wyniki

Płatność 

Plusy:

• W całym formularzu etykiety są poprawne powiązanie z polami – label for i input id.

Problemy:

• Instrukcja pod polem Imię i nazwisko podróżnego nie jest powiązana z polem formularza. Oznacza to, że czytnik ekranu nie odczyta tej informacji po wejściu w pole, więc użytkownik korzystający z czytnika może nie wiedzieć, że 
  
  • że wymagane są prawdziwe dane,
  • że nie wolno wpisywać kilku nazwisk.

‍
Dodatkowo pole to jest obowiązkowe, ale ani wizualnie, ani w kodzie nie jest to prawidłowo oznaczone: 

• Brak required
• Brak aria-required="true"

• Pozostałe pola obowiązkowe oznaczone są tylko gwiazdką. Brak aria-required="true" i/lub required przy polach oznaczonych jako obowiązkowe.

• Sekcja „Dane do faktury” jest dynamicznie wyświetlana po zaznaczeniu checkboxa, ale brak informacji o zmianie stanu (aria-expanded, aria-live),
  a fokus nie jest przenoszony do nowo odsłoniętej treści.
  
  

• Pole wybór kraju jest w stanie disabled. Użytkownik klawiatury trafia na element, z którym nie może nic zrobić. Użytkownicy myszki mogą kliknąć i otworzyć wybór.

‍

‍

• Radio buttony mają etykiety, ale brakuje nagłówka grupy.
  Mamy:
  
  • Osoba fizyczna
  • Firma
    Ale pola nie są zawarte w fieldset z legend, co jest wymagane, żeby: czytniki ekranu wiedziały, jaką kategorię wyboru opisują, a grupa była semantycznie rozpoznawalna.
    

Komunikaty błędu:

• Brak widocznych komunikatów błędu.
• Błąd jest sygnalizowany wyłącznie kolorem – jedynym wskaźnikiem błędu jest czerwona ramka, bez tekstowego komunikatu wyjaśniającego, co należy poprawić.
  To oznacza:
  
  • użytkownik nie wie, co dokładnie jest niepoprawne,
  • komunikat błędu nie jest powiązany programistycznie z polem,
  • czytnik ekranu nie otrzyma żadnej informacji o błędzie.
    

‍

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

Wyniki

Język strony

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

Tytuł strony

Sprawdzane podstrony posiadają niejednoznacznie opisujce zawartoś tytuły oraz nie sa unikalne.

• Strona główna
  <title>Kup bilet - PKP Intercity</title>
  Tytuł nie odzwierciedla w pełni charakteru strony głównej. 
• Lista połączeń / wyniki wyszukiwania
  <title>e-IC2 - Internetowa rezerwacja miejsc</title>
  Tytuł jest zbyt ogólny, nie wskazuje, że użytkownik znajduje się na liście wyników wyszukiwania.
• Podstrona płatności
  <title>e-IC2 - Internetowa rezerwacja miejsc</title>
  Tytuł jest identyczny jak na poprzednim etapie procesu. Użytkownik nie otrzymuje informacji, że znajduje się na etapie płatności.

Podsumowanie

Ocena: 

Częściowo dostępna

Ogólna ocena dostępności strony

Strona PKP Intercity spełnia tylko część wymagań dostępności i zawiera istotne bariery, które mogą utrudniać samodzielne używanie serwisu osobom korzystającym z czytników ekranu lub klawiatury. Choć wiele komponentów zostało zaprojektowanych z myślą o dostępności, niespójności w implementacji sprawiają, że proces zakupu biletu nie jest w dostępny na wszystkich etapach.

Co działa dobrze

• Zapewniono alternatywny sposób wyboru miejsc siedzących poprzez listę, co kompensuje niedostępność wizualnej mapy wagonu.
• Licznik czasu na etapie płatności został poprawnie oznaczony atrybutem aria-live, dzięki czemu użytkownicy czytników ekranu są informowani o upływie czasu.
• Główna nawigacja strony głównej jest obsługiwana klawiaturą zgodnie z przyjętymi wzorcami interakcji.

Najważniejsze problemy do naprawy

• Obsługa klawiaturą:
  
  • Nie wszystkie elementy interaktywne są obsługiwalne z poziomu klawiatury (m.in. przyciski oparte na elementach <span>, wybór daty i godziny, wizualny wybór miejsc).
  • Występują pułapki fokusu w modalach.
  • Fokus nie zawsze jest przenoszony do nowo otwieranych lub dynamicznie wyświetlanych treści.
• Formularze i komunikaty błędów:
  
  • Brakuje tekstowych komunikatów błędów.
  • Pola obowiązkowe nie są konsekwentnie oznaczone w kodzie (required, aria-required).
  • Instrukcje przy polach oraz dynamicznie wyświetlane sekcje (np. dane do faktury) nie są komunikowane użytkownikom klawiatury i czytników ekranu.
    ‍