Dostępność aplikacji mobilnych: wymagania WCAG 2.2 dla iOS i Androida

Ponad 72% dorosłych z niepełnosprawnościami posiada smartfon, a według jednego z badań około 86% użytkowników czytników ekranu polega na urządzeniu mobilnym — to wyższy odsetek niż w przypadku użytkowników komputerów stacjonarnych i laptopów. Tymczasem te same organizacje, które skrupulatnie audytują swoje strony internetowe, często mają aplikacje mobilne, które nigdy nie zostały przetestowane pod kątem choćby jednego kryterium dostępności. Ta luka szybko się zamyka, napędzana przez zmieniające się regulacje, rosnącą liczbę pozwów i — co najważniejsze — wytyczne W3C, które wprost mapują WCAG 2.2 na natywne aplikacje iOS i Android.

Dlaczego WCAG 2.2 dotyczy Twojej aplikacji mobilnej

Utrzymuje się mit, że WCAG to standard wyłącznie dla stron internetowych. Tak nie jest. W3C nie ma osobnych wytycznych dla dostępności mobilnej — zamiast tego dostępność mobilna jest ujęta w istniejącym frameworku WCAG, a Mobile Accessibility Task Force (MATF) W3C opracowała dedykowany dokument pt. Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile), który mapuje każde kryterium sukcesu na poziomie A i AA na natywne aplikacje mobilne, mobilne aplikacje webowe i aplikacje hybrydowe.

Praktyczne konsekwencje są znaczące. Gdy czytasz kryterium sukcesu WCAG, które odnosi się do „strony internetowej” („web page”), dokument WCAG2Mobile zastępuje to sformułowanie słowem „ekran” („screen”) lub „widok” („view”). Gdy kryterium mówi o „agencie użytkownika” („user agent”), chodzi o mobilny system operacyjny. Cztery zasady POUR — Postrzegalność (Perceivable), Funkcjonalność (Operable), Zrozumiałość (Understandable), Solidność (Robust) — przekładają się bezpośrednio na sposób, w jaki użytkownik wchodzi w interakcję z widokiem SwiftUI w iOS lub układem Jetpack Compose w Androidzie.

Z prawnego punktu widzenia presja nie jest już teoretyczna. Na mocy Tytułu II ADA zaktualizowane regulacje DOJ opublikowane w kwietniu 2024 r. wprost wymagają, aby organy stanowe i lokalne zapewniały dostępność swoich aplikacji mobilnych zgodnie z WCAG 2.1 AA. Organizacje opieki zdrowotnej przyjmujące Medicare lub Medicaid podlegają podobnym wymogom na mocy przepisów HHS sfinalizowanych w maju 2024 r. I choć pozwy dotyczące aplikacji mobilnych w sektorze prywatnym są nadal rzadsze niż pozwy dotyczące stron internetowych, co najmniej jeden „wysokowolumenowy” powód skupił się konkretnie na aplikacjach mobilnych z powodu braku równego dostępu na gruncie ADA, a oczekuje się, że ten trend przyspieszy wraz z nadejściem terminów zgodności z Tytułem II w 2026 r.

Europejski Akt o Dostępności (EAA), który wszedł w życie 28 czerwca 2025 r. i opiera się na EN 301 549 jako domyślnym standardzie technicznym, również wymaga zgodności z WCAG 2.2 dla produktów i usług cyfrowych, w tym aplikacji mobilnych sprzedawanych lub oferowanych na rynkach UE. Dla każdej organizacji z globalną bazą użytkowników WCAG 2.2 na urządzeniach mobilnych nie jest przyszłym aspiracyjnym celem — to obecny obowiązek.

Co zmieniło się w WCAG 2.2 i ma największe znaczenie dla urządzeń mobilnych

WCAG 2.2, opublikowane jako Rekomendacja W3C w październiku 2023 r., dodaje dziewięć nowych kryteriów sukcesu i usuwa przestarzałe już 4.1.1 Parsowanie (Parsing). Jest w pełni wstecznie kompatybilne: spełnienie wymogów 2.2 implikuje zgodność z 2.1 i 2.0. Kilka nowych kryteriów zostało napisanych z myślą o wzorcach interakcji mobilnych, a nawet te sformułowane wokół użycia klawiatury mają bezpośrednie odpowiedniki w technologiach asystujących dla iOS i Androida.

Warto zrozumieć tu ciągłość rozwoju. Po 2018 r. Mobile Accessibility Task Force zadbała o to, by kwestie mobilne kształtowały zarówno WCAG 2.1, jak i 2.2. Kryteria takie jak 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) oraz nowe 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) i 3.3.7 Redundant Entry (A) odzwierciedlają konkretne wzorce użyteczności mobilnej zidentyfikowane w testach z udziałem rzeczywistych użytkowników z niepełnosprawnościami korzystających ze smartfonów i tabletów.

Dziewięć nowych kryteriów sukcesu wprowadzonych w WCAG 2.2 celuje w konkretne bariery, z jakimi mierzą się realni użytkownicy: ścieżki logowania, które karzą osoby z problemami pamięci, interfejsy wymagające bardzo stabilnych dłoni do precyzyjnych stuknięć, funkcje pomocy ukryte w różnych miejscach każdego ekranu oraz wskaźniki fokusu znikające za przyklejonymi paskami nawigacyjnymi. Każde kryterium łata konkretną lukę — i niemal wszystkie mają bezpośrednie zastosowanie mobilne.

Nowe kryteria WCAG 2.2 i ich zastosowanie w iOS i Androidzie

2.5.8 Target Size Minimum (Poziom AA)

To prawdopodobnie najbardziej wpływowe nowe kryterium dla zespołów mobilnych. Wymaga ono, aby interaktywne cele — przyciski, linki, pola formularzy, pola wyboru, przełączniki — miały minimalny rozmiar 24 × 24 piksele CSS lub aby istniał 24‑pikselowy odstęp między sąsiadującymi celami, jeśli sam cel jest mniejszy. Uzasadnienie jest proste: użytkownicy z drżeniem rąk, chorobą Parkinsona lub ograniczoną sprawnością manualną mają realny problem z trafieniem w 16‑pikselową ikonę przycisku, a nawet użytkownicy bez niepełnosprawności popełniają znacznie więcej błędów przy małych celach.

W natywnym rozwoju mobilnym minimum 24 × 24 z WCAG 2.2 jest w rzeczywistości progiem dolnym, a nie górnym. Wytyczne Apple Human Interface Guidelines zalecają minimalny cel dotykowy 44 × 44 punkty w iOS i iPadOS. Material Design Google zaleca 48 × 48 piksele niezależne od gęstości (dp) w Androidzie. Jeśli Twoja aplikacja spełnia wytyczne platformowe Apple lub Google, już przekraczasz minimum WCAG 2.2 — ale wiele aplikacji tego nie robi. Te maleńkie przyciski zamykania na arkuszach modalnych, cieniutkie pola wyboru na ekranach ustawień i ikony w paskach narzędzi o rozmiarze 20 × 20 dp to wszystko potencjalne niezgodności, które tylko czekają, by zostać ujawnione w audycie.

Praktyczna uwaga: wymóg WCAG dotyczy interaktywnego obszaru trafienia, a nie wizualnego rozmiaru ikony. Ikona 16‑punktowa opakowana 14 punktami wypełnienia z każdej strony ma efektywny cel dotykowy 44 × 44 punkty. Oznacza to, że deweloperzy mogą spełnić kryterium bez wizualnego powiększania elementów — ale muszą świadomie ustawić to wypełnienie, a nie polegać na tym, że system zrobi to automatycznie.

2.5.7 Dragging Movements (Poziom AA)

To kryterium wymaga, aby każda funkcjonalność zaimplementowana za pomocą gestu przeciągania — suwaki, przeciągnij‑i‑upuść do zmiany kolejności, „pull‑to‑refresh”, przewijanie karuzeli — była również osiągalna za pomocą działania pojedynczym wskaźnikiem, które nie wymaga przeciągania. W iOS i Androidzie technologie asystujące platformy obsługują niektóre gesty w inny sposób, ale sama aplikacja musi udostępniać alternatywy bez przeciągania dla każdej niestandardowej funkcji opartej na przeciąganiu, którą implementuje.

W praktyce oznacza to, że lista z funkcją przeciągnij‑aby‑zmienić‑kolejność musi oferować alternatywę, taką jak przyciski krokowe „góra/dół”. Niestandardowy suwak zakresu, który reaguje wyłącznie na gest przeciągania, musi również reagować na stuknięcia w określone punkty lub zapewniać przyciski zwiększania/zmniejszania. Kryterium nie ma zastosowania, jeśli alternatywę zapewnia automatycznie system operacyjny lub technologia asystująca, ale deweloperzy powinni to przetestować wprost, zamiast zakładać, że zawsze zostanie to obsłużone za nich.

2.4.11 Focus Not Obscured — Minimum (Poziom AA) i 2.4.12 (Enhanced, Poziom AAA)

Te kryteria dotyczą wzorca niezwykle powszechnego zarówno w aplikacjach webowych, jak i natywnych mobilnych: element z fokusem jest częściowo lub całkowicie zasłonięty przez „sticky” UI — stały dolny pasek nawigacyjny, pływający przycisk akcji, górny pasek narzędzi zachodzący na obszar przewijania. Minimalne kryterium (Poziom AA) wymaga, aby gdy komponent otrzymuje fokus, przynajmniej jego część pozostawała widoczna. Wersja rozszerzona (Poziom AAA) wymaga, aby cały komponent z fokusem był widoczny.

W natywnych aplikacjach mobilnych „fokus klawiatury” jest interpretowany szeroko i obejmuje pierścień fokusu używany przez Switch Control lub Switch Access, Full Keyboard Access (iOS 15+) oraz Voice Control/Access. Aplikacja, w której element z fokusem przesuwa się pod dolny pasek nawigacyjny podczas przemiatania Switch Control, nie spełnia tego kryterium, mimo że nie ma fizycznej klawiatury. Interfejs aplikacji nie powinien zasłaniać kontrolki z fokusem własnymi nakładkami, przyklejonymi paskami czy powierzchniami tymczasowymi.

2.4.13 Focus Appearance (Poziom AA)

To kryterium określa minimalne wymagania dotyczące wizualnych cech wskaźnika fokusu: musi on mieć minimalny obszar równy obwodowi komponentu × 2 piksele CSS oraz kontrast co najmniej 3:1 względem sąsiadujących kolorów. Na natywnych platformach mobilnych pierścień fokusu dla VoiceOver i TalkBack jest kontrolowany przez system operacyjny i deweloperzy nie mogą zmieniać jego wyglądu — co oznacza, że zazwyczaj przyznaje się im wyjątek od tego konkretnego kryterium. Stylowanie aplikacji nie może jednak aktywnie zmniejszać widoczności fokusu, na przykład przez nakładanie półprzezroczystej zasłony na kontrolki z fokusem.

3.3.8 Accessible Authentication — Minimum (Poziom A)

To kryterium stanowi duży krok naprzód dla dostępności poznawczej. Wymaga, aby procesy uwierzytelniania nie opierały się wyłącznie na teście funkcji poznawczych — tzn. użytkownik nie może być zmuszony do zapamiętania hasła, rozwiązania łamigłówki czy przepisania CAPTCHA — chyba że aplikacja zapewnia dostępną alternatywę. W iOS oznacza to obsługę Apple Keychain i Sign in with Apple, aby umożliwić użytkownikom logowanie bez zapamiętywania danych uwierzytelniających. W Androidzie oznacza to obsługę frameworka Autofill Google, uwierzytelniania biometrycznego i nieblokowanie użycia menedżerów haseł firm trzecich.

Bardziej konkretnie: jeśli Twoja aplikacja blokuje wklejanie w polach hasła, prawdopodobnie jest niezgodna z 3.3.8. Jeśli przepływ uwierzytelniania dwuskładnikowego wymaga, aby użytkownik ręcznie wpisał kod OTP z powiadomienia bez zapewnienia mechanizmu kopiuj‑wklej, wprowadza to niepotrzebne obciążenie poznawcze. Aplikacja Wiadomości w Androidzie już udostępnia przycisk „kopiuj kod” w powiadomieniach OTP właśnie z tego powodu — dostosowując zachowanie platformy do intencji kryterium.

Kluczowy wniosek: Obsługa uwierzytelniania biometrycznego (Face ID, Touch ID, Android Biometric API) to nie tylko ulepszenie UX — to mechanizm zgodności z WCAG 2.2 dla użytkowników z niepełnosprawnościami poznawczymi, którzy nie są w stanie wiarygodnie zapamiętywać haseł.

3.3.7 Redundant Entry (Poziom A)

Jeśli wieloekranowy przepływ w Twojej aplikacji — checkout, onboarding, formularz przyjęcia do placówki medycznej — prosi użytkownika o wprowadzenie tych samych informacji więcej niż raz, musisz albo automatycznie uzupełnić wcześniej wprowadzoną wartość, albo zaoferować sposób jej wybrania z wcześniejszego wpisu. To kryterium ma bezpośrednie zastosowanie do natywnych aplikacji mobilnych. Klasyczny przykład niepowodzenia to formularz adresu wysyłki, po którym następuje formularz adresu rozliczeniowego bez opcji „taki sam jak adres wysyłki”, zmuszający użytkowników z niepełnosprawnościami ruchowymi lub poznawczymi do wielokrotnego przepisywania tego samego tekstu.

3.2.6 Consistent Help (Poziom A)

Jeśli Twoja aplikacja udostępnia mechanizm pomocy — przycisk czatu z pomocą, ikonę pomocy, link „skontaktuj się z nami” — musi on pojawiać się w spójnym miejscu na wszystkich ekranach aplikacji. Użytkownicy z niepełnosprawnościami poznawczymi polegają na przewidywalnym umiejscowieniu nawigacji i mechanizmów wsparcia. Umieszczanie przycisku pomocy w nagłówku na niektórych ekranach, w pasku kart na innych, a na niektórych ścieżkach ukrywanie go w menu ustawień narusza to kryterium.

Kryteria WCAG 2.1, które nadal są kluczowe dla urządzeń mobilnych

Nowe kryteria WCAG 2.2 przyciągają najwięcej uwagi, ale kilka wymogów WCAG 2.1 wprowadzonych specjalnie z myślą o urządzeniach mobilnych nadal jest rutynowo naruszanych w natywnych aplikacjach, a osoby odpowiedzialne za zgodność nie powinny ich pomijać podczas audytów.

1.3.4 Orientation (AA) zabrania blokowania aplikacji wyłącznie w orientacji pionowej lub poziomej, chyba że dana orientacja jest niezbędna do funkcji treści. Wiele aplikacji blokuje orientację pionową podczas przepływów onboardingowych lub w odtwarzaczach wideo bez uzasadnienia. Nieproporcjonalnie dotyka to użytkowników z urządzeniami zamontowanymi na wózkach, których nie można obracać. 1.4.10 Reflow (AA) wymaga, aby treść mogła być prezentowana bez przewijania poziomego przy szerokości 320 pikseli CSS (odpowiednik powiększenia 400%), co w praktyce mobilnej oznacza obsługę Dynamic Type i skalowania rozmiaru tekstu systemowego bez psucia układu czy obcinania treści.

2.5.1 Pointer Gestures (A) wymaga, aby każda funkcjonalność korzystająca z gestów wielopunktowych lub opartych na ścieżce — np. uszczypnięcie, aby powiększyć, przesunięcie dwoma palcami — miała również alternatywę z użyciem pojedynczego wskaźnika. 2.5.4 Motion Actuation (A) wymaga, aby funkcjonalność wyzwalana przez potrząsanie lub przechylanie urządzenia mogła być również obsługiwana za pomocą standardowych kontrolek UI oraz aby użytkownicy mogli wyłączyć wyzwalacze oparte na ruchu, by uniknąć przypadkowej aktywacji.

W zakresie prezentacji wizualnej 1.4.3 Contrast Minimum (AA) wymaga współczynnika kontrastu co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu. Wiele aplikacji nadal nie spełnia tego wymogu, ponieważ tekst zastępczy w polach wprowadzania, etykiety wyłączonych przycisków i tekst na tle fotograficznym mają zbyt niski kontrast. Deweloperzy powinni zadbać, aby wszystkie treści, kontrolki i komponenty działały poprawnie z Dynamic Type, pogrubionym tekstem, trybem ciemnym i systemowymi opcjami kontrastu zarówno w iOS, jak i Androidzie.

Wytyczne implementacyjne specyficzne dla platform

iOS oraz SwiftUI / UIKit

Apple zapewnia rozbudowane natywne wsparcie dla dostępności poprzez API UIAccessibility, a w SwiftUI poprzez modyfikatory accessibility. Dla wsparcia VoiceOver każdy element interaktywny musi mieć znaczącą etykietę dostępności, podpowiedź i wartość. Kontrolki niestandardowe, które nie dziedziczą po standardowych komponentach UIKit, muszą jawnie przyjąć odpowiednią cechę dostępności — .isButton, .isHeader, .isLink — aby VoiceOver poprawnie je zapowiadał. Xcode Accessibility Inspector może pomóc wykryć brakujące etykiety i niezgodności cech już na etapie rozwoju.

Dla Dynamic Type systemowe fonty UIKit UIFont.preferredFont(forTextStyle:) i SwiftUI .font(.body) automatycznie skalują się do preferowanego rozmiaru tekstu użytkownika. Twardo zakodowane rozmiary fontów w punktach, które nie używają scaledValue(for:), będą naruszać 1.4.4 Resize Text. W przypadku rozmiarów celów dotykowych można powiększyć obszar dotykowy małej ikony, używając contentEdgeInsets w UIKit lub modyfikatora .contentShape() w SwiftUI, bez zmiany wizualnej prezentacji elementu.

// SwiftUI: powiększenie obszaru dotyku bez zmiany wizualnego rozmiaru
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android oraz Jetpack Compose / Views

Dostępność w Androidzie jest udostępniana poprzez API AccessibilityNodeInfo, z którego korzystają TalkBack i Switch Access. W Jetpack Compose blok Modifier.semantics pozwala ustawiać opisy treści, role, opisy stanu i scalać semantykę potomków. W interfejsach opartych na View ViewCompat.setAccessibilityDelegate() umożliwia programową manipulację właściwościami dostępności dowolnego widoku.

W zakresie rozmiaru celów dotykowych wytyczne Material Design zalecają minimum 48 × 48 dp. Jeśli composable lub widok jest wizualnie mniejszy, możesz użyć Modifier.minimumInteractiveComponentSize() w Compose (wprowadzony w Material3), aby automatycznie wymusić minimum 48 dp, lub opakować mały widok w TouchDelegate, aby powiększyć jego obszar trafienia w starszym systemie View. Dla skalowania tekstu upewnij się, że wszystkie rozmiary tekstu są określone w sp (scale‑independent pixels), a nie w dp, aby respektowały preferencje rozmiaru czcionki ustawione w Ustawieniach wyświetlania Androida.

// Jetpack Compose: dostępny przycisk ikony z minimalnym rozmiarem
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // wymusza minimum 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // opisany przez element nadrzędny
    )
}

Testowanie aplikacji względem WCAG 2.2

Testowanie dostępności mobilnej wymaga połączenia narzędzi automatycznych i testów manualnych z użyciem rzeczywistych technologii asystujących. Narzędzia automatyczne — w tym axe DevTools Mobile firmy Deque, Accessibility Scanner Google dla Androida i Accessibility Inspector Apple w Xcode — mogą wykrywać brakujące etykiety, niewystarczający kontrast i cele dotykowe poniżej minimum platformy. Jednak narzędzia automatyczne wychwytują tylko część rzeczywistych problemów z dostępnością. Testy manualne z VoiceOver w iOS i TalkBack w Androidzie są niezbędne, aby zweryfikować poprawną kolejność odczytu, znaczące etykiety i logiczne zarządzanie fokusem w złożonych przepływach.

Dla kryteriów specyficznych dla WCAG 2.2 testy manualne są szczególnie ważne. Aby przetestować 2.5.8 (Target Size), użyj własnego palca — nie kursora myszy w iOS Simulator — aby spróbować wchodzić w interakcje z małymi kontrolkami. Aby przetestować 3.3.8 (Accessible Authentication), sprawdź, czy przepływ logowania pozwala na wklejanie w polach hasła, obsługuje menedżery haseł (1Password, Bitwarden, systemowy keychain) i obsługuje uwierzytelnianie biometryczne. Aby przetestować 2.4.11 (Focus Not Obscured), nawiguj po aplikacji wyłącznie za pomocą Switch Control w iOS lub Switch Access w Androidzie i upewnij się, że żaden element z fokusem nie znika za paskiem nawigacyjnym, nakładką modalną lub pływającym przyciskiem.

Kompleksowy plan testów dostępności powinien obejmować testy na co najmniej dwóch fizycznych urządzeniach — jednym iPhonie i jednym urządzeniu z Androidem — przy domyślnym rozmiarze czcionki użytkownika i przy maksymalnym rozmiarze czcionki systemowej, z włączonymi odpowiednio VoiceOver i TalkBack. Testy wyłącznie w symulatorach nie wychwycą różnic w rzeczywistym renderowaniu i zachowaniu technologii asystujących.

Rozważ wbudowanie kontroli dostępności w swój pipeline CI/CD. Zarówno Espresso (Android), jak i XCUITest (iOS) umożliwiają pisanie automatycznych testów UI, które weryfikują właściwości dostępności — opisy treści, cechy i stany włączony/wyłączony — tak aby regresje były wychwytywane przed scaleniem kodu, a nie dopiero w audycie produkcyjnym.

Przypadek prawny i biznesowy za działaniem już teraz

Poza moralnym imperatywem włączenia, biznesowy argument za dostępnością mobilną jest bardzo konkretny. Firmy, które przodują w zakresie włączania osób z niepełnosprawnościami, generują 1,6 razy wyższe przychody i 2,6 razy wyższy dochód netto niż konkurenci w branży. Osoby z niepełnosprawnościami w USA dysponują niemal pół biliona dolarów dochodu rozporządzalnego. A biorąc pod uwagę, że 69% osób z niepełnosprawnościami rezygnuje z aplikacji i stron internetowych, które uznają za trudne w użyciu, każda bariera dostępności to konwersja, która nigdy nie nastąpi.

Ryzyko prawne rośnie. Pozwy przeciwko firmom z powodu niepowodzeń w zakresie dostępności cyfrowej rosną z roku na rok. Przyjęcie przez DOJ WCAG jako standardu technicznego dla zgodności z ADA, terminy egzekwowania Tytułu II w 2026 r. oraz wejście w życie EAA w czerwcu 2025 r. łącznie tworzą wielojurysdykcyjny wymóg zgodności, który teraz wprost obejmuje natywne aplikacje mobilne. Poprzedni audyt WCAG 2.1 nie dowodzi automatycznie zgodności z WCAG 2.2 — przepływy uwierzytelniania, pola formularzy, komponenty interaktywne i zarządzanie fokusem muszą zostać ponownie ocenione względem dziewięciu nowych kryteriów sukcesu.

Co istotne, dostępność w aplikacjach mobilnych nie jest funkcją, którą można tanio „doinstalować” po premierze. Usuwanie niezgodności z WCAG w wydanej już aplikacji oznacza aktualizację zasobów, przebudowę komponentów, korektę układów, ponowne testowanie przepływów i potencjalną refaktoryzację systemów uwierzytelniania. Zespoły, które wbudowują zgodność z WCAG 2.2 w swoje systemy projektowe i biblioteki komponentów od początku — egzekwując minimalne rozmiary celów dotykowych, tokeny kontrastu, role semantyczne i wzorce uwierzytelniania na poziomie komponentów — ponoszą ułamek kosztów w porównaniu z naprawianiem niedostępnej aplikacji po premierze.

Kluczowe wnioski

• WCAG 2.2 dotyczy natywnych aplikacji iOS i Android. Wytyczne W3C WCAG2Mobile mapują każde kryterium sukcesu na poziomie A i AA na ekrany i widoki mobilne, co oznacza, że Twoja natywna aplikacja jest w zakresie — nie tylko Twoja mobilna strona internetowa.
• Rozmiar celu dotykowego to najczęstsza nowa niezgodność w audytach mobilnych. Minimum 24 × 24 z WCAG 2.2 to próg dolny; Apple zaleca 44 × 44 pt, a Google 48 × 48 dp. Powiększaj obszary trafienia za pomocą wypełnienia i natywnych API platformy, a nie przez wizualne powiększanie ikon.
• Blokowanie wklejania w polach hasła prawdopodobnie narusza 3.3.8 Accessible Authentication. Obsługuj systemowe keychainy, menedżery haseł, biometrię i automatyczne uzupełnianie OTP, aby spełnić wymagania dostępności poznawczej dla przepływów logowania na obu platformach.
• Testy manualne z VoiceOver i TalkBack są nie do pominięcia. Narzędzia automatyczne wychwytują tylko część problemów z dostępnością. Testuj na fizycznych urządzeniach przy maksymalnym rozmiarze czcionki, z włączonymi technologiami asystującymi, w każdym krytycznym scenariuszu użytkownika.
• Buduj dostępność w systemie projektowym teraz, a nie po premierze. Naprawianie niedostępnych aplikacji po premierze jest znacznie droższe niż egzekwowanie standardów dostępnych komponentów od pierwszego dnia. Przy zbliżających się terminach egzekwowania przez DOJ, HHS i EAA w latach 2025–2026 okno na niskokosztowe działania zgodności szybko się zamyka.