Dostępność aplikacji mobilnych

Krótko

Dostępna aplikacja nie ogranicza się do współpracy z czytnikiem ekranu. Musi przekazywać znaczenie kontrolek, działać przy powiększonym tekście, obsługiwać różne metody wejścia, nie wymuszać złożonych gestów i nie zaskakiwać zmianami kontekstu.

Ten tutorial dotyczy natywnych i hybrydowych aplikacji na telefony oraz tablety. Zawiera wskazówki dla projektantów, programistów i osób wykonujących testy. Materiał został zaktualizowany 17 sierpnia 2026 r. na podstawie dokumentacji W3C, Apple, Androida, Fluttera i polskich źródeł urzędowych.

1. Zacznij od zakresu i właściwego punktu odniesienia

Najpierw ustal technologię aplikacji. Od niej zależy sposób implementacji i zestaw narzędzi testowych.

WCAG 2.2 a wymagania prawne w Polsce

WCAG 2.2 jest aktualną rekomendacją W3C i dobrym punktem odniesienia dla projektowania oraz audytu. W przypadku podmiotów publicznych w Polsce wymagania ustawy z 4 kwietnia 2019 r. uznaje się za spełnione z uwzględnieniem punktów 9, 10 i 11 normy PN-ETSI EN 301 549 V3.2.1:2021. Norma ta opiera się głównie na WCAG 2.1 AA i zawiera dodatkowe wymagania.

Kryteria dodane w WCAG 2.2, na przykład 2.5.8 Rozmiar celu i 3.3.8 Dostępne uwierzytelnianie, nie wynikają z obecnego załącznika do tej ustawy. Mogą jednak obowiązywać jako przyjęty standard projektu lub umowy i warto stosować je jako dobrą praktykę. Przed audytem sprawdź aktualną podstawę prawną właściwą dla produktu.

ARIA nie jest API aplikacji natywnej

WAI-ARIA opisuje semantykę treści webowych. W aplikacji natywnej nie dodajesz aria-label ani role="button". Przekazujesz tę samą intencję przez mechanizmy platformy: etykietę, rolę, stan, wartość, nagłówek, relację i akcję.

ARIA nadal ma zastosowanie w mobilnej stronie internetowej i w treści osadzonej w WebView. Nie należy jednak mechanicznie kopiować nazw atrybutów ARIA do kodu natywnego.

2. Zapewnij nazwę, rolę, stan i wartość

Czytnik ekranu powinien móc odpowiedzieć na cztery pytania: co to jest, jak się nazywa, w jakim jest stanie i jaka jest jego aktualna wartość. Najbezpieczniej zacząć od standardowego komponentu platformy.

Używaj standardowych komponentów

• Przycisk powinien być komponentem przycisku, a nie klikalnym kontenerem.
• Przełącznik powinien przekazywać stan włączony lub wyłączony.
• Suwak powinien mieć nazwę, bieżącą wartość, zakres i działające akcje zwiększania oraz zmniejszania.
• Pole tekstowe powinno mieć widoczną etykietę powiązaną programowo z polem.
• Komponent niestandardowy musi odtworzyć pełną semantykę i obsługę, a nie tylko wygląd.

Nazwa dostępna ma być krótka i zgodna z widoczną etykietą

Jeśli przycisk ma widoczny tekst „Zapisz”, czytnik ekranu nie potrzebuje nazwy „Przycisk Zapisz”. Rolę „przycisk” ogłosi system. Nie zastępuj też tej etykiety tekstem „Zatwierdź formularz”, bo użytkownik sterowania głosem może próbować wybrać element słowem, które widzi na ekranie.

Wskazówka nie zastępuje nazwy

Nazwa identyfikuje element, na przykład „Pobierz raport”. Wskazówka opisuje nietypowy rezultat, na przykład „Otwiera plik PDF w innej aplikacji”. Nie dodawaj wskazówek wyjaśniających standardowe gesty typu „stuknij dwukrotnie”. Sposób obsługi komunikuje technologia wspomagająca.

3. Komunikuj zmiany i zarządzaj fokusem

Po akcji użytkownika mogą pojawić się: błąd, potwierdzenie, nowe wyniki, zmiana liczby produktów albo nowy ekran. Informacja istotna wizualnie musi dotrzeć również do osoby korzystającej z technologii wspomagającej.

Kiedy ogłosić zmianę bez przenoszenia fokusu

• krótkie potwierdzenie, na przykład „Ustawienia zapisane”,
• komunikat o błędzie przesyłania danych,
• aktualizacja liczby wyników po zastosowaniu filtra,
• zmiana statusu zadania, jeśli użytkownik jej oczekuje.

Preferuj ogłoszenia spokojne. Komunikat pilny, który przerywa mowę czytnika ekranu, powinien być wyjątkiem. Nie oznaczaj jako regionu live zegara, licznika albo treści zmieniającej się wiele razy na sekundę.

Kiedy przenieść fokus

• po otwarciu modala, do jego logicznego początku lub pierwszej wymaganej kontrolki,
• po zamknięciu modala, z powrotem do elementu, który go otworzył,
• po przejściu na nowy ekran, do tytułu lub początku nowej zawartości, zgodnie z zachowaniem platformy,
• po nieudanej walidacji, do podsumowania błędów albo pierwszego błędnego pola, jeśli pomaga to naprawić formularz.

Nie przenoś fokusu tylko po to, żeby odczytać status. Nagłe skoki dezorientują i przerywają wykonywane zadanie.

4. Zbuduj dostępne formularze i komunikaty błędów

1. Dodaj widoczną etykietę. Placeholder albo podpowiedź w polu nie zastępują etykiety.
2. Określ przeznaczenie danych. Użyj właściwego typu klawiatury, autouzupełniania i formatu danych, jeśli platforma to wspiera.
3. Wyjaśnij ograniczenia przed wpisaniem danych. Podaj format daty, wymagania hasła i informację o polach wymaganych.
4. Opisz błąd tekstem. Kolor i ikona mogą wspierać komunikat, ale nie mogą być jedyną informacją.
5. Powiąż błąd z polem. Użytkownik powinien poznać nazwę pola, przyczynę i sposób poprawy.
6. Zachowaj wpisane dane. Po błędzie nie każ ponownie podawać informacji, które aplikacja już ma, jeśli nie wymaga tego bezpieczeństwo.
7. Zapobiegaj kosztownym błędom. Przy operacjach prawnych, finansowych i usuwaniu danych zapewnij weryfikację, potwierdzenie lub możliwość cofnięcia.

Uwierzytelnianie bez zbędnego obciążenia pamięci

Jeśli zakres obejmuje WCAG 2.2, sprawdź kryterium 3.3.8 Dostępne uwierzytelnianie na poziomie AA. Nie zmuszaj użytkownika do zapamiętywania ani ręcznego przepisywania hasła lub kodu jednorazowego, jeśli nie zapewniasz dozwolonej alternatywy albo mechanizmu wspomagającego.

• pozwól wklejać całe hasła i kody jednorazowe, także do pól podzielonych wizualnie na kilka części,
• nie blokuj autouzupełniania ani menedżerów haseł,
• wspieraj mechanizmy systemowe, na przykład kody z wiadomości, klucze dostępu (passkeys) i uwierzytelnianie biometryczne, jeśli są dostępne,
• sprawdź każdy etap logowania, odzyskiwania konta i uwierzytelniania wieloskładnikowego.

5. Opisz grafiki i zapewnij alternatywy dla multimediów

Grafiki

• Informacyjna: przekaż równoważną informację tekstem.
• Funkcjonalna: nazwij akcję, na przykład „Zrób zdjęcie”, a nie wygląd ikony aparatu.
• Dekoracyjna: usuń ją z drzewa dostępności, żeby nie dodawała szumu.
• Złożona: przygotuj krótką nazwę i pełniejsze objaśnienie danych w dostępnym miejscu.

Audio i wideo

Dobierz alternatywę do treści. Film z dialogiem potrzebuje napisów. Materiał tylko audio potrzebuje transkrypcji. Film, w którym ważna informacja pojawia się wyłącznie w obrazie, może wymagać audiodeskrypcji lub pełnego opisu tekstowego.

• Zapewnij dostępne przyciski odtwarzania, pauzy, przewijania, głośności i napisów.
• Nie uruchamiaj dźwięku bez świadomej akcji użytkownika. Jeśli gra automatycznie dłużej niż 3 sekundy, zapewnij zatrzymanie, pauzę albo niezależną regulację głośności.
• Nie zakładaj, że system zawsze poprawnie wyciszy multimedia podczas mowy VoiceOver lub TalkBack. Sprawdź rzeczywiste zachowanie.
• Animacje i automatycznie przewijane karuzele muszą dać się zatrzymać, jeśli spełniają warunki WCAG dotyczące ruchu i aktualizacji.

6. Zadbaj o strukturę, kolejność i język

Tytuły i nagłówki

Każdy ekran powinien mieć opisowy tytuł, który potwierdza miejsce i cel widoku. Dłuższe ekrany dziel nagłówkami. Nie oznaczaj nagłówkiem tekstu tylko dlatego, że jest duży lub pogrubiony.

SwiftUI wspiera poziomy nagłówków. Android Compose i Android Views pozwalają oznaczyć element jako nagłówek, a we Flutterze służy do tego właściwość headingLevel. Sprawdź jednak zachowanie z wersjami systemu wspieranymi przez produkt.

Kolejność odczytu

Domyślna kolejność powinna wynikać z logicznej struktury widoków i odpowiadać kolejności wizualnej. Ręczne priorytety stosuj dopiero wtedy, gdy nie można poprawić struktury. Po każdej zmianie układu sprawdź eksplorację dotykiem, gesty przesuwania, klawiaturę i sterowanie przełącznikami.

Listy i kolekcje

Używaj natywnych list i siatek. Platforma może dzięki temu przekazać liczbę elementów, pozycję w kolekcji oraz obsługę przewijania. Nie grupuj całej interaktywnej listy w jeden element semantyczny.

Język

Korzystaj z lokalizacji systemu i zasobów językowych platformy. Nie ustawiaj języka tylko przez nazwę pliku albo komentarz w projekcie. Jeśli pojedynczy fragment jest w innym języku, sprawdź, czy wybrany framework pozwala przekazać lokalizację dla tego fragmentu.

Projekt w Figma

Figma służy do udokumentowania intencji: nazwy kontrolki, roli, stanu, kolejności, zachowania po akcji, treści komunikatu i oczekiwanego fokusu. Nazwa warstwy lub adnotacja nie trafia automatycznie do aplikacji. Zespół musi przenieść tę informację do kodu i zweryfikować ją w działającym produkcie.

7. Zapewnij obsługę dotykiem, klawiaturą, głosem i przełącznikami

Rozmiar celu

Nie zamieniaj tych jednostek jeden do jednego. W projekcie przyjmij wytyczne platformy jako bezpieczny cel, a zgodność formalną oceniaj według właściwego standardu.

Gesty

• Każda funkcja wymagająca gestu wielopunktowego lub zależnego od ścieżki powinna mieć prostą alternatywę jednopunktową, jeśli złożony gest nie jest istotą działania.
• Przeciąganie powinno mieć alternatywę bez przeciągania, na przykład przyciski „Przenieś wyżej” i „Przenieś niżej”.
• Akcję uruchamianą ruchem urządzenia zapewnij także przez kontrolkę i pozwól wyłączyć reakcję na ruch.
• Nie nadpisuj gestów systemowych i gestów technologii wspomagających.

Klawiatura i inne metody wejścia

VoiceOver i TalkBack nie są testami klawiatury. Sprawdź osobno klawiaturę sprzętową, Full Keyboard Access, Voice Access, Switch Control lub Switch Access, jeśli są istotne dla platformy i zakresu produktu.

• Każda istotna akcja powinna być osiągalna bez gestu wymagającego precyzji.
• Kolejność fokusu ma być logiczna, a fokus nie może utknąć ani znikać.
• Element z fokusem nie może być całkowicie zasłonięty przez treść utworzoną przez aplikację, na przykład przyklejony pasek, modal albo własną nakładkę.
• Własne skróty klawiszowe nie mogą kolidować z systemem i technologiami wspomagającymi.
• Nie ograniczaj użytkownika do jednej metody wejścia, jeśli platforma obsługuje inne.

Orientacja

Nie blokuj aplikacji wyłącznie w pionie albo poziomie, chyba że konkretna orientacja jest niezbędna do funkcji. Sprawdź także urządzenia zamocowane w uchwycie, na których użytkownik nie może łatwo obrócić ekranu.

8. Sprawdź kontrast, tekst, czas i ruch

Kontrast

• Zwykły tekst: co najmniej 4,5:1 względem tła.
• Duży tekst: co najmniej 3:1.
• Informacja potrzebna do rozpoznania kontrolki, stanu i istotnej grafiki: co najmniej 3:1 względem koloru sąsiadującego.
• Kolor nie może być jedynym sposobem przekazania błędu, wyboru albo statusu.
• Sprawdź tryb jasny, ciemny, podwyższony kontrast i ustawienia odwrócenia kolorów wspierane przez platformę.

Skalowanie tekstu

• iOS: używaj semantycznych stylów tekstu i Dynamic Type. Układ powinien przechodzić z poziomego na pionowy, jeśli zabraknie miejsca.
• Android: rozmiar tekstu podawaj w sp, nie blokuj wysokości kontenerów i testuj maksymalną skalę. Od Androida 14 system obsługuje nieliniowe skalowanie do 200%.
• Flutter: respektuj MediaQuery i TextScaler. Nie ustawiaj globalnego limitu skali tylko po to, żeby zachować pierwotny układ.

autoSizeTextType na Androidzie dopasowuje tekst do miejsca i może go zmniejszyć. Nie jest zamiennikiem obsługi preferowanej wielkości tekstu.

Limity czasowe i automatyczne aktualizacje

Jeśli czas nie jest istotą działania, pozwól go wyłączyć, dostosować albo wydłużyć zgodnie z WCAG 2.2. Przed końcem sesji pokaż dostępne ostrzeżenie i daj użytkownikowi czas na reakcję. Nie zamykaj automatycznie komunikatów, których przeczytanie lub odnalezienie wymaga więcej czasu.

Przewidywalność

Uzyskanie fokusu albo zmiana wartości pola nie powinny same uruchamiać przejścia na inny ekran. Powtarzalne funkcje powinny mieć te same nazwy i zachowanie. Jeśli zmiana kontekstu jest nieoczekiwana, uprzedź o niej przed aktywacją.

9. Przykłady wdrożenia na trzech platformach

Przykłady pokazują intencję. Przed użyciem sprawdź minimalną wersję systemu i API przyjętą w projekcie.

VStack(alignment: .leading) {
    Text("Dane kontaktowe")
        .font(.headline)
        .accessibilityHeading(.h2)

    Button("Zapisz") {
        saveProfile()
    }
}

IconButton(onClick = onDelete) {
    Icon(
        imageVector = Icons.Default.Delete,
        contentDescription = stringResource(R.string.delete_message)
    )
}

Text(
    text = saveStatus,
    modifier = Modifier.semantics {
        liveRegion = LiveRegionMode.Polite
    }
)

Column(
  crossAxisAlignment: CrossAxisAlignment.start,
  children: [
    Semantics(
      headingLevel: 2,
      child: const Text('Dane kontaktowe'),
    ),
    Semantics(
      liveRegion: true,
      child: Text(saveStatus),
    ),
  ],
)

10. Wstępna kontrola dostępności aplikacji w 20 minut

Ta procedura pomaga wykryć oczywiste bariery, zebrać podstawowe informacje o aplikacji i lepiej przygotować zakres właściwego audytu. Możesz wykonać ją przed przekazaniem aplikacji audytorowi albo po większej zmianie produktu.

Co przygotować przed rozpoczęciem

• wersję aplikacji, numer wersji systemu i model urządzenia,
• konto testowe oraz dane potrzebne do przejścia wybranego procesu,
• jeden lub dwa najważniejsze procesy, na przykład logowanie, zakup, rezerwację albo wysłanie formularza,
• informację o platformach i wersjach systemu oficjalnie wspieranych przez produkt,
• miejsce do zapisywania problemów, na przykład dokument, arkusz albo system zgłoszeń.

Jeśli aplikacja działa na iOS i Androidzie, przeprowadź kontrolę osobno na każdej platformie. Wynik z jednego systemu nie potwierdza zachowania na drugim.

Przebieg kontroli

1. Minuty 0–3: wybierz proces. Określ jego początek, oczekiwany koniec i dane potrzebne do wykonania zadania. Nie próbuj sprawdzać wszystkich ekranów.
2. Minuty 3–8: włącz czytnik ekranu. Przejdź proces za pomocą VoiceOver albo TalkBack. Sprawdź, czy kontrolki mają zrozumiałe nazwy, role i stany oraz czy kolejność odczytu jest logiczna.
3. Minuty 8–12: sprawdź formularze i zmiany. Wywołaj co najmniej jeden błąd. Sprawdź jego treść, powiązanie z polem, zachowanie fokusu i ogłoszenie potwierdzenia albo statusu.
4. Minuty 12–16: zwiększ tekst i obróć ekran. Ustaw dużą skalę tekstu, sprawdź utratę treści, nachodzenie elementów oraz działanie w obu orientacjach, jeśli żadna z nich nie jest niezbędna.
5. Minuty 16–20: sprawdź sposób obsługi. Poszukaj przeciągania, gestów złożonych, małych celów dotykowych i funkcji zależnych od ruchu urządzenia. Sprawdź, czy mają prostą alternatywę.

Jeśli nie znasz gestów czytnika ekranu, skorzystaj z instrukcji VoiceOver na iPhonie albo TalkBack na Androidzie.

Jak zapisać znaleziony problem

Każde zgłoszenie powinno pozwolić innej osobie odtworzyć barierę. Zapisz:

• platformę, urządzenie, wersję systemu i wersję aplikacji,
• nazwę ekranu oraz sprawdzany proces,
• kroki prowadzące do problemu,
• zachowanie zaobserwowane i zachowanie oczekiwane,
• użytą technologię wspomagającą oraz jej ustawienia,
• nagranie lub zrzut ekranu, jeśli pomaga zrozumieć problem.

Nie nadawaj aplikacji procentowego wyniku zgodności na podstawie tej kontroli. Jej rezultatem jest lista pierwszych obserwacji i pytań do sprawdzenia podczas pełnego audytu.

Kiedy zaplanować pełny audyt

• czytnik ekranu nie pozwala ukończyć kluczowego procesu,
• aplikacja zawiera komponenty niestandardowe, rozbudowane gesty albo wiele zmian dynamicznych,
• proces obejmuje płatności, uwierzytelnianie, podpisanie umowy lub usuwanie danych,
• wyniki różnią się pomiędzy systemami lub wspieranymi wersjami aplikacji,
• trzeba ocenić zgodność z konkretnym standardem, umową albo wymaganiem prawnym.

11. Przeprowadź testy w kilku warstwach

Etap 1: projekt

• sprawdź kolejność informacji i fokusu,
• opisz zachowanie kontrolek, błędów, modali i komunikatów dynamicznych,
• przetestuj kontrast oraz układ przy dużym tekście,
• zaprojektuj alternatywy dla gestów, ruchu i treści multimedialnych,
• przekaż zespołowi teksty etykiet i komunikatów, nie tylko nazwy warstw.

Etap 2: kontrola automatyczna i inspekcja

• iOS: Accessibility Inspector i audyt w Xcode.
• Android: Accessibility Scanner, lint, Layout Inspector, Accessibility Test Framework i testy Compose.
• Flutter: Accessibility Guideline API, Semantics Debugger oraz inspektory natywne na iOS i Androidzie.

Automat może wykryć część brakujących nazw, małe cele, kontrast i wybrane problemy semantyki. Nie oceni wiarygodnie kolejności całego procesu, jakości etykiet, sensu ogłoszeń, dostępności złożonych gestów ani tego, czy aplikacja jest zrozumiała.

Etap 3: test manualny

1. Włącz czytnik ekranu i wykonaj kluczowe procesy bez patrzenia na ekran.
2. Sprawdź eksplorację dotykiem i nawigację gestami element po elemencie.
3. Zwiększ tekst i rozmiar elementów do maksymalnych wspieranych wartości.
4. Przetestuj obie orientacje, mały ekran oraz tryb jasny i ciemny.
5. Podłącz klawiaturę i sprawdź pełny przepływ fokusu.
6. Sprawdź Voice Access oraz sterowanie przełącznikami, jeśli są w zakresie.
7. Powtórz test na rzeczywistych urządzeniach i wspieranych wersjach systemu.

Etap 4: test z użytkownikami

Test ekspercki sprawdza wymagania i przewidywalne bariery. Badanie z osobami korzystającymi na co dzień z technologii wspomagających pokazuje problemy procesowe, których nie widać w pojedynczych kontrolkach. Oba typy testów uzupełniają się.

12. Deklaracja dostępności aplikacji mobilnej

Obowiązek deklaracji dostępności z ustawy z 4 kwietnia 2019 r. dotyczy aplikacji mobilnych podmiotów publicznych. Nie należy pisać, że każda aplikacja na rynku musi mieć taką deklarację.

Gdzie opublikować deklarację podmiotu publicznego

• na jednej ze stron internetowych podmiotu,
• w aplikacji mobilnej,
• jako link w miejscu, z którego można pobrać aplikację.

Aktualizacja

Podmiot publiczny przegląda i aktualizuje deklarację do 31 marca każdego roku oraz niezwłocznie po zmianach, które mogą wpłynąć na dostępność cyfrową aplikacji.

Identyfikatory a11y-*

Warunki techniczne w wersji 2.0 określają strukturę, treść i identyfikatory HTML deklaracji. Identyfikatory stosuje się w wersji HTML publikowanej na stronie oraz w aplikacji wykonanej w HTML. Nie dodaje się ich do natywnego ekranu iOS albo Androida.

Aplikacje podmiotów gospodarczych

Od 28 czerwca 2025 r. Polski Akt o Dostępności obejmuje wskazane produkty i usługi, między innymi część usług oferowanych przez urządzenia mobilne, bankowość detaliczną i handel elektroniczny. Zakres, wyłączenia i obowiązki informacyjne są inne niż deklaracja podmiotu publicznego. Ta część tutorialu nie jest opinią prawną; zakres konkretnej usługi trzeba ocenić osobno.

13. Checklista przed wydaniem aplikacji

Semantyka

• Każda kontrolka ma poprawną nazwę, rolę, stan, wartość i akcje.
• Widoczna etykieta jest częścią nazwy dostępnej.
• Dekoracje nie trafiają do drzewa dostępności.
• Komponenty niestandardowe mają pełną obsługę równoważną komponentom standardowym.

Nawigacja i zmiany

• Kolejność odczytu i fokusu odpowiada logice ekranu.
• Tytuły, nagłówki, listy i grupy są przekazane programowo.
• Modal zatrzymuje fokus w swoim zakresie i oddaje go po zamknięciu.
• Element z fokusem nie jest całkowicie zasłonięty przez treść aplikacji.
• Ważne statusy są ogłaszane bez zbędnego przenoszenia fokusu.

Formularze i uwierzytelnianie

• Pola mają widoczne etykiety, instrukcje i zrozumiałe komunikaty błędów.
• Logowanie pozwala korzystać z autouzupełniania, menedżera haseł oraz wklejania hasła i całego kodu jednorazowego.
• Każdy etap uwierzytelniania ma ścieżkę, która nie wymaga zapamiętywania lub ręcznego przepisywania danych, jeśli zakres obejmuje WCAG 2.2.

Widok i obsługa

• Tekst skaluje się bez utraty treści i funkcji.
• Kontrast spełnia właściwe wymagania w każdym motywie.
• Cele dotykowe spełniają wytyczne platformy i wymagania przyjętego standardu.
• Złożone gesty, przeciąganie i ruch urządzenia mają prostą alternatywę.
• Aplikacja działa w obu orientacjach, jeśli konkretna orientacja nie jest niezbędna.
• Limity czasu można dostosować albo wydłużyć, jeśli nie zachodzi wyjątek.

Testy

• Kluczowe procesy przeszły test z VoiceOver i TalkBack.
• Klawiatura i inne wspierane metody wejścia przeszły osobny test.
• Testy wykonano na rzeczywistych urządzeniach i wersjach systemu objętych wsparciem.
• Wyniki automatyczne zostały zweryfikowane manualnie.
• Po istotnych zmianach wykonano test regresji dostępności.

Źródła

Źródła techniczne i prawne sprawdzone 17 sierpnia 2026 r.

1. WCAG 2.2 (otwiera się w nowym oknie)
2. W3C: 2.4.11 Fokus niezasłonięty minimum (otwiera się w nowym oknie)
3. W3C: 3.3.8 Dostępne uwierzytelnianie minimum (otwiera się w nowym oknie)
4. W3C: Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (otwiera się w nowym oknie)
5. W3C: Guidance on Applying WCAG 2.2 to Mobile Applications (otwiera się w nowym oknie)
6. Apple Human Interface Guidelines: Accessibility (otwiera się w nowym oknie)
7. Apple: accessibility modifiers w SwiftUI (otwiera się w nowym oknie)
8. Apple: ogłoszenia dostępności (otwiera się w nowym oknie)
9. Android Developers: Accessibility in Jetpack Compose (otwiera się w nowym oknie)
10. Android Developers: Make apps more accessible (otwiera się w nowym oknie)
11. Android 14: nieliniowe skalowanie tekstu do 200% (otwiera się w nowym oknie)
12. Flutter API: Semantics (otwiera się w nowym oknie)
13. Flutter: accessibility testing (otwiera się w nowym oknie)
14. Flutter: migracja nagłówków semantycznych (otwiera się w nowym oknie)
15. Gov.pl: wymagania dla stron i aplikacji mobilnych (otwiera się w nowym oknie)
16. Gov.pl: deklaracja dostępności w aplikacjach mobilnych (otwiera się w nowym oknie)
17. Gov.pl: warunki techniczne deklaracji dostępności (otwiera się w nowym oknie)
18. Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (otwiera się w nowym oknie)
19. Ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (otwiera się w nowym oknie)