Table of Contents
Czy zdarzyło Ci się kiedyś nie trafić palcem w mały przycisk na stronie mobilnej albo pogubić się w chaotycznej strukturze formularza? Jeśli tak – to znaczy, że dostępność (ang. accessibility) dotyczy również Ciebie.
Choć temat testowania dostępności jeszcze do niedawna pojawiał się głównie przy okazji projektów dla sektora publicznego, dziś staje się standardem również w firmach prywatnych. A od czerwca 2025 – dzięki nowej unijnej dyrektywie – stanie się wręcz obowiązkiem w wielu branżach.
W tym artykule pokażę Ci, czym dokładnie jest dostępność, na czym polegają testy dostępności aplikacji webowych, jakich narzędzi warto używać i na co zwracać uwagę podczas testowania. Jeśli chcesz, by Twoje aplikacje były naprawdę przyjazne dla wszystkich użytkowników – jesteś we właściwym miejscu.
O co chodzi z testowaniem dostępności ?
W dostępności chodzi o to, aby osoby z niepełnosprawnościami miały zapewniony łatwiejszy dostęp do korzystania ze stron internetowych i aplikacji przez co nie były narażone na wykluczenie ze świata cyfrowego. Dlaczego firmy zaczynają się interesować tą tematyką? Ponieważ dostępność pozwala na zdobycie większej liczby odbiorców produktu, poszerza grupę docelową o osoby z niepełnosprawnościami, które również chcą kupować w Internecie, korzystać z mediów społecznościowych itd.
Co więcej, niektóre aplikacje i strony wydają się być tak mało dostępne i nieintuicyjne, że nawigacja po stronie staje się wyzwaniem nie tylko dla osób z niepełnosprawnościami. Przykładowo teksty napisane są bardzo małą czcionką, a ich powiększenie powoduje rozmycie czcionki.
Dlatego najwyższy poziom dostępności w świecie online, to taki dzięki któremu nawet osoby w pełni sprawne używają aplikacji z jeszcze większą łatwością.
Należy pamiętać, że niepełnosprawności to nie tylko te widoczne, permanentne, tj. słaby słuch, wzrok, brak kończyny. Mogą to być również niepełnosprawności niewidoczne, tj. ograniczenia czasowe, które każdy z nas może mieć. Migrena powoduje u Ciebie światłowstręt, a brak możliwości zmiany kontrastu kolorów/ jasności uniemożliwia Ci pracę czy funkcjonowanie online.
Co to jest EAA
Wspomniana wcześniej dyrektywa to Europejski Akt o Dostępności (European Accessibility Act) ma ona na celu ujednolicenie przepisów dotyczących dostępności na terenie całej Unii Europejskiej. Nakłada ona również obowiązek na firmy, aby dostosowały one swoje produkty i usługi do wymogów dostępności.
Wcześniejsza dyrektywa z 2019 o dostępności stron internetowych i aplikacji mobilnych dotyczyła sektora publicznego, np. szkół, urzędów czy szpitali. Natomiast obecna dyrektywa rozszerza dostępność na sektor prywatny. Będzie ona dotyczyła m.in. banków, e-commerce, platform streamingowych, transportu itd. Co więcej EAA rozszerza również tę dostępność na urządzenia fizyczne, np. bankomaty czy terminale płatnicze, e-booki. Wymagania jakie trzeba spełnić w ramach tej dyrektywy określa standard WCAG.
Co to jest WCAG (Web Content Accessibility Guidelines) i jak się łączy z testowaniem dostępności?
a) Poziomy
A-podstawowy poziom
Np. kryterium 2.5.1 dotyczące dostępności gestów na urządzeniach dotykowych poprzez obsługę jednym palcem, prostym przeciągnięciem lub stuknięciem. Alternatywą do rozszerzanie mapy może być przycisk „+” i „-„ wymagający jedynie jednego tapnięcia. Ułatwi to nawigacje osobom niepotrafiącym wykonywać skomplikowanych gestów lub tym, którzy korzystają z urządzeń wspomagających, np. rysików czy wskaźników głowy.
Dla przykładu, jeśli masz iPhona możesz włączyć „śledzenie głowy” (ustawienia systemowe->dostępność->sterowanie przełącznikami) lub śledzenie oczu (ustawienia systemowe->dostępność) i spróbować takiej nawigacji w webview lub w aplikacji.
Więcej informacji znajdziesz tutaj
AA- standard
Np. kryterium 1.4.13 dotyczące pojawiania się dodatkowej treści po najechaniu kursorem lub przeniesieniu fokusu na dany element. Dodatkową treścią mogą być podpowiedzi, etykiety, które mogą stanowić nieprzewidzianą i znikającą treść, która stanowi przeszkodę w odbiorze dla np. osób niedowidzących.
Rozwiązaniem może być zapewnienie możliwości jej odrzucenia, np. za pomocą „escape” lub osadzenie jej jako tooltip lub wyskakującego okna modalnego, co rozwiąże problem jej tymczasowości.
Więcej na stronie
AAA- odpowiada wyższym, specjalistycznym wymaganiom
Np. kryterium 1.2.6 dotyczące języka migowego, który powinien znaleźć się w materiałach wideo. Dzięki temu osoby głuchonieme lub słabosłyszące mają więcej sposobów na zrozumienie treści multimedialnych.
Więcej info na stronie
b) Zasady
Postrzegalność
Zasada postrzegalności jest spełniona, kiedy użytkownicy mogą korzystać ze strony internetowej lub aplikacji za pomocą dostępnych dla nich zmysłów. Np. dla osoby niewidomej zapewnienie alternatywnego tekstu dla obrazków, które niosą za sobą wartość semantyczną czy czytelna struktura strony.
Funkcjonalność
Zasada funkcjonalności polega na umożliwieniu użytkownikowi znajdowania i używania treści oraz funkcji niezależnie od tego, jak użytkownik nawiguje. Np. dotarcie do treści za pomocą klawiatury, przenoszenie fokusu na elementy, unikanie treści migających lub znikających albo możliwość zatrzymania pokazu slajdów, karuzeli, odtwarzania wideo. Użytkownik powinien tez mieć możliwość użycia funkcji, np. przycisku w celu przejścia do nowego ekranu/zakładki. Użytkownik musi wiedzieć, że jest to przycisk, może go kliknąć i gdzie go przeniesie.
Zrozumiałość
Zasada zrozumiałości opiera się na zrozumieniu dostępnej treści i sposobu działania strony lub aplikacji. Czyli musi być intuicyjna i prosta w odbiorze oraz spójna.
Solidność/kompatybilność
Zasada kompatybilności zapewnia, że treści i funkcje na stronie, w aplikacji będą działały poprawnie niezależnie od np. oprogramowania czy sprzętu z jakiego użytkownik korzysta.
Automatyczne testowanie dostępności w aplikacjach webowych
Narzędziem, który sprawdzi się w automatycznych testach jest axe DevTools. Jest to rozszerzenie do Chroma, które można dodać i otworzyć z poziomu narzędzi dla deweloperów. Niestety kilka opcji jest pro, ale darmowe też się sprawdzają. Można wykonać skan całej strony, którą chcemy przetestować, a narzędzie pokaże nam wykryte błędy:
Pod spodem będą one wylistowane. Możemy je podświetlić, aby wiedzieć o który konkretnie element chodzi. Axe DevTools oferuje nam dodatkowe informacje na temat wymogu „more information”, aby zrozumieć kontekst błędu.
A także jak możemy rozwiązać dany problem:
Rozszerzenie axe DevTools możesz również pobrać dla Firefoxa.
Innym rozszerzeniem dostępnym zarówno dla Chrome i Firefoxa jest WAVE oraz Accessibility Insights for Web. Możesz również skorzystać z wbudowanych narzędzi do badania dostępności w narzędziach dla deweloperów: Lighthouse dla Chroma czy inspektora dostępności dla Firefox.
Inne przeglądarki
Większość narzędzi dla Chrome powinna również działać na Operze po włączeniu obsługi rozszerzeń Chrome.
Safari ma również wbudowane narzędzie do badania dostępności, które możesz znaleźć w narzędziu programisty:
Safari > Ustawienia > Zaawansowane-> Pokaż funkcje dla deweloperów www.
Następnie przechodzisz do badanej strony i prawym klikiem „Skontroluj element” -> okienko „Kontrola”.
Innym narzędziem jest Pa11y, który działa w terminalu i nie potrzebujesz mieć dostępu do przeglądarki, działa na URL wpisanym w terminalu. Wszystko co potrzebujesz zrobić to w pierwszej kolejności zainstalować node.js, następnie Pa11y i już możesz wpisać stronę do audytu.
Przetestuj sobie powyższe narzędzia na wybranej stronie internetowej i zobacz które najlepiej odpowiadają Twoim potrzebom. Czy wyszukane problemy z dostępnością pokrywają się? Czy są jakieś różnice?
Na pewno warto użyć kilku narzędzi jednocześnie, aby zoptymalizować rezultaty testów. Jeśli nawet wybrane narzędzie automatycznie wykryje błędy, dajmy na to w tekstach alternatywnych, to nadal warto przyjrzeć się im manualnie, aby ocenić ich sens.
Manualne testowanie dostępności w aplikacjach webowych
Działanie klawiatury
Testując aplikację webową pod kątem dostępności musimy upewnić się, że komponenty, które można aktywować za pomocą myszy można również aktywować za pomocą klawiatury.
Sprawdzamy:
- działanie TAB i czy mamy możliwość poruszać się pomiędzy sekcjami. Poprawna kolejność działania przycisku TAB to od lewej do prawej.
- „Shift + TAB” natomiast cofa przeskakiwanie. Jeżeli TAB nie przeskakuje na kolejne sekcje oznacza to, że zgubiliśmy fokus, a jest to jeden z krytycznych błędów w naszych testach – pułapka klawiaturowa.
Szczególną uwagę należy zwrócić również na przeskakiwanie fokusa (czyli obramowania wokół elementu) kiedy otwieramy pop-up lub okna modalne. Fokus powinien przeskoczyć wtedy na pierwszy element na otwartym oknie. Kiedy natomiast zamykamy okno, fokus powinien wrócić do poprzedniego ekranu.
Kiedy fokus przejdzie na pole wyszukiwania, formularz lub inny input to musi się pojawić widoczny kursor, aby umożliwić edycję. Fokus powinien być używany na interaktywnych elementach oraz tymczasowo nieinteraktywnych, których dostępność w trakcie nawigacji może się zmienić. Takich przykładem mogą być przyciski na stronach e-commerce, gdzie pewne funkcje możemy odblokować po dodaniu produktów do koszyka. Dla takich elementów nieinteraktywnych dodaje się aria-hidden = „true”. Więcej o aria label tu.
Przy sprawdzaniu fokusa należy zwrócić również uwagę czy fokus nie usuwa kontrastu kolorów oraz czy zafokusowany element nie staje się mniej widoczny. Ponadto sprawdzamy także:
- czy działają strzałki góra/dół; prawo/lewo
- czy spacja zaznacza checkbox/ aktywuje przycisk
- czy enter aktywuje wybór
- czy escape zamyka tymczasowe elementy, więcej tu
Czytelność strony:
- czy występuje tekst w pionie? Nie jest to dobre rozwiązanie pod kątem dostępności. Tekst powinien być zapisany horyzontalnie,
- jaka jest zaimplementowana czcionka? Niektóre czcionki nie są czytelne dla odbiorcy, np. ozdobne czy dekoracyjne czcionki,
- zachowane są odpowiednie odstępy między wierszami, literami, słowami, akapitami opisane w kryterium 1.4.12 WCAG,
- wielkość różnego rodzaju aktywnych przycisków – rozmiar wg. Poziomu AAA to 44 pixel/44 pixel i 24/24 pixele wg.poziomu AA. Jeśli użytkownik ma ograniczenia ruchowe to wyzwaniem będzie nawigacja po mniejszych elementach,
- czy strona jest responsywna i czytelna przy powiększeniu do 200%.
Działanie screen readera
Screen reader to narzędzie służące do odczytywania zawartości strony/aplikacji/UI w sposób głosowy. W ramach testu sprawdzamy czy czytnik ekranu może przeczytać elementy strony.
Na Windowsie możemy używać NVDA (skróty klawiszowe dla narzędzia) i VoiceOver dla Maca.
Struktura strony
Aby screen reader mógł poprawnie przeczytać to co znajduje się na stronie, struktura html musi być poprawnie zaimplementowana.
Aby podejrzeć strukturę html otwieramy dev tools, gdzie sprawdzamy czy:
- dla „order list”, jeśli występuje na stronie, (gdzie kolejność jest ważna i ponumerowana) jest zaimplementowany znacznik <ol>,
- stosowany jest znacznik <ul> dla listy, gdzie kolejność nie jest istotna i zaczyna się od np. myślników,
- stosowane są znaczniki <table>, <tr>, <td>, <th> dla tabeli,
- stosuje się znacznik <a> z atrybutem target=”_blank” jeśli kliknięcie w link ma otwierać go w nowym oknie, screen reader wtedy poprawnie go przeczyta,
- zastosowanie <label>, <input>, <id> i określenie etykiet dla pól oraz identyfikacja unikatowego elementu zwiększa dostępność i interaktywność np. formularzy dla czytników,
- stosuje się znacznik <h> dla nagłówków strony. Nagłówki stanowią o hierarchii strony i są zaimplementowane z różnymi wielkościami po kolei, np. <h1>, <h2> dzieląc stronę na części i nadając jej czytelności. Oznacza to też, że nie można dać jako pierwszego nagłówka h5, a potem w środku strony użyć h1, czyli tego największego,
- dodanie atrybutu <alt> dla niesemantycznych elementów takich jak obrazki. Pamiętaj, że czytnik nie przeczyta niesemantycznych elementów. Dlatego ważne jest, aby dodawać taki tekst alternatywny dla elementów, które mają znaczenie dla strony. Jeśli obrazek pełni funkcję czysto dekoracyjną można go pominąć.
ARIA- Accessibility rich internet application
opisuje specyficzne atrybuty, które można dodać do znaczników HTML, aby dokładniej informować użytkowników technologii asystujących o stanach, rolach i właściwościach elementów stron internetowych i aplikacji.
Wszystkie atrybuty ARIA znajdziecie tutaj:
Najprawdopodobniej zetkniesz się najczęściej z:
- aria-label– do nazwania elementu w ramach jego roli, np. „zamknij” dla elementu typu „button” lub „otwórz w nowym oknie” dla elementu oznaczającego otwarcie linku w nowym tabie,
- aria-labelledby– służy do nazwania elementu, odwołuje się do nazwanych już wcześniej elementów na stronie. Jeżeli mamy użyte jednocześnie aria-label i aria-labelledby to aria-labelledby nadpisuje aria-label,
- aria-describedby– są używane do połączenia np. opisu z inputem, gdzie możemy coś wpisać, tak aby screen reader mógł przeczytać to co się wiąże bezpośrednio z inputem,
- aria-expanded– używa się do zawarcia informacji czy np. menu jest rozwinięte czy zwinięte, funkcjonuje na zasadzie true/false.
Zachęcam do eksplorowania różnych stron internetowych z użyciem dev tools i podglądania jak elementy na stronie są zaimplementowane. Które atrybuty ARIA są najczęściej używane i czy screen reader jest w stanie je wychwycić.
Atrybuty ARIA, które będą źle stosowane, mogą przyczynić się do niższej dostępności strony internetowej/aplikacji webowej.
Kontrast kolorów
Color contrast analyzer TPGI jest to narządzie do badania kontrastu między tłem, a np. tekstem na stronie. Należy zapewnić kontrast co najmniej 4:5:1.
Jednak narzędzia automatyczne powinny już wychwycić na etapie skanowania strony ewentualne braki w kontraście więc manualne badanie kontrastu może być opcjonalne.
Plan testów dostępności krok po kroku
- Jaki jest zakres testów? Jakie elementy wchodzą w skład webaplikacji/strony internetowej, które musimy sprawdzić?
- Skanowanie strony za pomocą automatycznych narzędzi. Skaner strony wychwyci większe błędy (np.kontrast). Przeanalizuj wychwycone błędy i oceń ich sens. Użyj kilku narzędzi, aby zoptymalizować wyniki testów, zob. automatyczne testowanie dostępności.
- Sprawdź czy screen reader właściwie czyta całą stronę, element po elemencie (tytuł, rola i cel, czyli co się stanie, jeśli naciśniesz konkretny element). Możesz wspomóc się dev toolem, aby podejrzeć strukturę html (nagłówki, teksty alternatywne, etykiety) i jakie ARIE zostały zaimplementowane.
- Sprawdź manualnie krytyczne ścieżki: czy nawigacja klawiaturą działa, czy fokus przechodzi na kolejne elementy i czy nie występują pułapki fokusu.Możesz się też wspomóc checklistami, które możesz znaleźć w internecie, a które określają kryteria, które strona musi spełnić. Dla przykładu checklista.
- Oceń czytelność strony pod kątem dostępności dla urządzeń wspomagających zob. manualne testowanie dostępności.
- Sprawdź responsywność strony na różnych rozdzielczościach i przeglądarkach.
- Zrób zrzuty ekranu i opisz znaleziony błąd, stwórz raport z testów.
Podsumowanie
Dostępność cyfrowa to temat, który coraz śmielej wchodzi do codziennej pracy testerów, projektantów i deweloperów. Dobrze wdrożona dostępność to nie tylko spełnianie wymogów prawnych, ale przede wszystkim realne wsparcie dla użytkowników – i tych z ograniczeniami, i tych w pełni sprawnych. Jeśli jeszcze nie miałeś okazji testować dostępności – zachęcam, by zacząć choćby od jednego z opisanych narzędzi. Małe kroki robią dużą różnicę.
Masz swoje sprawdzone praktyki lub narzędzia? Zostaw komentarz pod wpisem i zaglądaj na bloga – druga część artykułu będzie dotyczyć testów dostępności aplikacji mobilnych!
