Czy osoba z czytnikiem ekranu zaloguje się i zapłaci w Twojej aplikacji?

Źródła sprawdzone 9 listopada 2026.

Ten poradnik jest dla właściciela produktu, CTO albo osoby odpowiedzialnej za e-commerce, która chce sprawdzić, czy klient z niepełnosprawnością może ukończyć zakup w aplikacji. Opisuje metodę testu, a nie wynik audytu konkretnej aplikacji.

Logowanie i płatność to miejsca, w których jedna przeszkoda zatrzymuje całą ścieżkę: nienazwany przycisk, kod do przepisania bez możliwości wklejenia ani innej metody, błąd pokazany tylko kolorem albo limit czasu, który kończy sesję. Od 28 czerwca 2025 r. Europejski akt o dostępności obejmuje m.in. usługi handlu elektronicznego. Opis: Europejski akt o dostępności — Komisja Europejska. Ten artykuł nie jest poradą prawną; zakres obowiązków ustala się osobno.

WCAG 2.2 to standard pisany głównie z myślą o treściach webowych, ale jego kryteria są powszechnie stosowane jako punkt odniesienia także dla aplikacji mobilnych. Pełny tekst: WCAG 2.2 — W3C. Poniższa lista nie jest kompletna; wskazuje kryteria, które mogą rozstrzygać o tym, czy zakup da się ukończyć. Opisy są skrótami; obowiązują dokładne warunki i wyjątki z dokumentów W3C.

Szczególnie ważne jest kryterium uwierzytelniania bez testu poznawczego, opisane w Accessible Authentication (Minimum) — W3C.

Drugie to minimalny rozmiar celu dotykowego, opisany w Target Size (Minimum) — W3C.

• 1.1.1 Treść nietekstowa: ikony i przyciski bez tekstu mają nazwę odczytywaną przez czytnik.
• 1.4.4 Zmiana rozmiaru tekstu: w treściach webowych tekst da się powiększyć do 200% bez technologii wspomagających i bez utraty treści lub funkcji (z wyjątkiem napisów i tekstu w obrazach). W aplikacji traktuj to jako praktyczny punkt odniesienia dla systemowego rozmiaru tekstu.
• 2.2.1 Możliwość dostosowania czasu: każdy limit czasu użytkownik może wyłączyć albo dostosować (w zakresie co najmniej dziesięciokrotności domyślnego czasu) przed jego napotkaniem, albo dostaje ostrzeżenie przed upływem czasu i co najmniej 20 sekund na wydłużenie go prostą czynnością, możliwe co najmniej 10 razy. Wyjątki są wąskie: limit jest wymaganą częścią zdarzenia w czasie rzeczywistym (np. aukcji) i nie ma dla niego alternatywy, limit jest niezbędny, a jego wydłużenie unieważniłoby czynność, albo limit jest dłuższy niż 20 godzin.
• 2.5.8 Rozmiar celu (minimum): w treściach webowych cel ma co najmniej 24 × 24 piksele CSS albo wystarczający odstęp od innych celów; kryterium ma też wyjątki (np. równoważny cel, tekst w linii, element przeglądarki, przypadki niezbędne). W aplikacji traktuj to jako praktyczny punkt odniesienia.
• 3.3.1 Identyfikacja błędu: błąd jest opisany tekstem, nie tylko kolorem.
• 3.3.8 Dostępne uwierzytelnianie (minimum): żaden krok logowania nie wymaga testu poznawczego (np. zapamiętania hasła, przepisania kodu, rozwiązania zagadki), chyba że dostępna jest alternatywna metoda bez takiego testu albo mechanizm pomocy, np. wklejanie czy menedżer haseł. Wyjątkami są też test polegający na rozpoznawaniu obiektów oraz na wskazaniu nietekstowej treści (np. zdjęcia), którą użytkownik wcześniej sam dostarczył.
• 4.1.3 Komunikaty o stanie: informacje typu „płatność w toku” lub „błąd karty” są ogłaszane bez przenoszenia fokusu.

Test na symulatorze lub z narzędziem automatycznym jest pomocny, ale nie zastąpi przejścia ścieżki z włączonym czytnikiem ekranu na prawdziwym telefonie. Android opisuje połączenie testów ręcznych i automatycznych w Testowanie dostępności — Android Developers.

Podstawy obsługi czytnika na iOS: VoiceOver — Apple Developer.

Podstawy obsługi czytnika na Androidzie: TalkBack — Pomoc Google.

Jeśli aplikacja jest napisana w React Native, właściwości dostępności komponentów opisuje Accessibility — React Native.

1. Co najmniej jeden iPhone z VoiceOver i jeden telefon z Androidem z TalkBack, w wersjach używanych przez klientów.
2. Konto testowe i środowisko płatności testowych, żeby przejść całą ścieżkę bez prawdziwej transakcji.
3. Ustawienie największego rozmiaru tekstu systemowego oraz trybu pogrubionego tekstu.
4. Lista kroków ścieżki od otwarcia aplikacji do potwierdzenia zamówienia.
5. Sposób zapisu: nagranie ekranu z dźwiękiem czytnika i krótka notatka przy każdym problemie.

Przejdź logowanie wyłącznie gestami czytnika ekranu, bez patrzenia na ekran. Przy każdym kroku zapisz, co czytnik ogłasza, i porównaj z tym, czego potrzebuje użytkownik.

1. Pola: czy pola e-mail, telefonu i hasła mają zrozumiałe nazwy, a nie tylko podpowiedź znikającą po wpisaniu.
2. Menedżer haseł i wklejanie: czy można wkleić hasło lub kod i skorzystać z autouzupełniania systemu.
3. Kod jednorazowy: czy kod z SMS lub e-maila da się wkleić albo uzupełnić automatycznie, zamiast przepisywać go z pamięci.
4. Logowanie biometryczne: czy istnieje alternatywa dla osób, które nie mogą z niego skorzystać.
5. Błąd logowania: czy czytnik ogłasza, co poszło nie tak i co zrobić dalej.
6. CAPTCHA lub podobna weryfikacja: czy istnieje wariant niewymagający rozpoznawania obrazów ani rozwiązywania zagadek.

Płatność może łączyć ekrany aplikacji z komponentami dostawcy płatności i dodatkowym uwierzytelnieniem w banku. Przetestuj całość, bo użytkownik nie widzi granicy między systemami.

Szczególnie sprawdź moment przejścia do formularza dostawcy płatności i powrotu do aplikacji: czy fokus czytnika trafia w sensowne miejsce i czy wynik płatności jest ogłaszany.

1. Koszyk: czy nazwa produktu, ilość, cena i przycisk usunięcia są odczytywane razem i w zrozumiałej kolejności.
2. Zmiana ilości: czy po zmianie czytnik ogłasza nową ilość i sumę.
3. Dane dostawy: czy pola mają nazwy, a wymagane pola są oznaczone nie tylko gwiazdką lub kolorem.
4. Wybór metody płatności: czy zaznaczona opcja jest ogłaszana jako wybrana.
5. Formularz karty lub przekierowanie: czy komponent dostawcy płatności i ekran banku są obsługiwane przez czytnik.
6. Wynik płatności: czy sukces i odmowa są ogłaszane, a przy odmowie użytkownik wie, jak spróbować ponownie.
7. Potwierdzenie: czy numer zamówienia i najważniejsze informacje da się odczytać i zapisać.

Przejdź całą ścieżkę jeszcze raz z największym rozmiarem tekstu systemowego. Sprawdź, czy przycisk płatności nie znika poza ekranem, czy ceny nie są obcięte i czy da się przewinąć do każdego pola. Na iOS skalowanie tekstu opisuje Automatyczne skalowanie czcionek — Apple Developer.

Sprawdź też rozmiar i odstępy przycisków, zwłaszcza obok siebie: „Zapłać”, „Anuluj”, „Zmień”. Jeśli sesja płatności lub kod wygasają, ustal, czy użytkownik dostaje ostrzeżenie i może wydłużyć czas. Kryterium opisuje Timing Adjustable — W3C.

Najpierw napraw to, co uniemożliwia ukończenie zakupu. Problemy, które utrudniają, ale nie blokują, trafiają na kolejną listę. Zapisuj obserwację, a nie od razu rozwiązanie techniczne.

Opisany scenariusz sprawdza najważniejszą ścieżkę, ale nie zastępuje pełnego audytu dostępności ani oceny prawnej. Warto znać jego granice, zanim wynik trafi do decyzji.

Jeśli test pokaże wiele problemów w starszej aplikacji, pomocny może być poradnik naprawić, zmodernizować czy przepisać aplikację mobilną.

• Pozostałych ekranów aplikacji, takich jak wyszukiwarka, konto czy zwroty.
• Wszystkich technologii wspomagających, np. sterowania przełącznikami czy głosem.
• Komponentów zewnętrznych dostawców w każdej konfiguracji, którą mogą mieć klienci.
• Oceny zgodności z przepisami i dokumentacji wymaganej od firmy.
• Testów z udziałem osób z niepełnosprawnościami, które mogą ujawnić problemy niewidoczne dla zespołu.