Accessibility — podstawy, VoiceOver i TalkBack dla niewidomych użytkowników

Czym jest Accessibility (a11y) w aplikacjach mobilnych?

Accessibility (w skrócie a11y — 11 liter między «a» i «y») — praktyka tworzenia aplikacji dostępnych dla osób z zaburzeniami wzroku, słuchu, motoryki i cechami poznawczymi. W programowaniu mobilnym accessibility obejmuje cztery główne scenariusze: niewidomi użytkownicy (czytniki ekranu), słabowidzący (skalowanie, kontrast), głusi i niedosłyszący (napisy, wizualne alternatywy dla dźwięku), użytkownicy z ograniczoną motoryką (sterowanie głosowe, Switch Control, większy obszar dotyku).

Wymogi prawne — w wielu krajach accessibility jest obowiązkowa z mocy prawa. USA: Section 508 i ADA. UE: European Accessibility Act (2025). Wielka Brytania: Equality Act 2010. Bez wsparcia accessibility aplikacja może stać się przedmiotem pozwu sądowego — w USA w 2023 roku złożono ponad 4000 pozwów o niedostępność produktów cyfrowych. Apple i Google sprawdzają accessibility podczas moderacji aplikacji: App Store Review Guidelines (4.2) i Google Play Store wymagają minimalnego wsparcia dostępności.

Argument biznesowy — dostępność zwiększa audytorium. Według Return on Disability (2021) osoby z niepełnosprawnością kontrolują 13 bilionów dolarów dochodu rozporządzalnego rocznie. Dostępne aplikacje lepiej pozycjonują się w wyszukiwarkach (semantyczny HTML, teksty alternatywne), mają wyższe oceny użytkowników i mniej opinii o problemach z UX. W IT Sectr włączamy accessibility do definition of done wszystkich projektów — to standard jakości, a nie opcjonalne ulepszenie.

Accessibility w iOS: VoiceOver i UIAccessibility

VoiceOver — czytnik ekranu Apple wbudowany w iOS, iPadOS i macOS. Użytkownik przesuwa palcem po ekranie, VoiceOver odczytuje nazwę elementu pod palcem. Podwójne dotknięcie — aktywacja elementu. VoiceOver obsługuje ponad 40 gestów: trzy palce przesunięcie (przewijanie), dwa palce podwójne dotknięcie (stop), gest Z (powrót). Deweloper kontroluje, co i jak czyta VoiceOver, poprzez protokół UIAccessibility oraz właściwości accessibilityLabel, accessibilityTraits, accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // override accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Przycisk wysyłania formularza" }
        set {}
    }

    // override accessibilityHint
    override var accessibilityHint: String? {
        get { return "Dotknij dwukrotnie, aby wysłać dane" }
        set {}
    }

    // override accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — skalowanie tekstu
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Dynamiczna typografia — Dynamic Type w iOS pozwala użytkownikowi wybrać rozmiar tekstu (od XS do XXXL). Deweloper używa UIFontMetrics.scaledFont do automatycznego skalowania. Tekst musi być poprawnie wyświetlany we wszystkich rozmiarach: wiersze nie mogą być przycinane, przyciski muszą rosnąć proporcjonalnie do tekstu. UITableView automatycznie aktualizuje wysokość komórek przy zmianie rozmiaru tekstu. Zignorowanie Dynamic Type oznacza uczynienie aplikacji niedostępną dla słabowidzących użytkowników.

Accessibility w SwiftUI

SwiftUI udostępnia modyfikatory dla accessibility: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Domyślnie wszystkie standardowe elementy SwiftUI (Text, Button, Image) są już elementami accessibility z automatycznymi etykietami. Dla niestandardowych View używaj .accessibilityElement(children: .combine) do łączenia elementów podrzędnych w jeden. SwiftUI automatycznie obsługuje Dynamic Type i VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Usuń element"))
    Text("Kosz")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Usuwa wybrany element bez możliwości przywrócenia"))

Accessibility w Android: TalkBack i contentDescription

TalkBack — czytnik ekranu Google, preinstalowany na większości urządzeń Android (dostępny w Google Play dla wszystkich wersji Android 5+). TalkBack używa tych samych gestów co VoiceOver: przesunięcie do nawigacji, podwójne dotknięcie do aktywacji. Deweloper ustawia opis elementów poprzez atrybut android:contentDescription w XML lub przez setContentDescription() w kodzie. Dla ImageView contentDescription jest obowiązkowy — bez niego TalkBack zgłosi «nieoznakowane» lub odczyta nazwę pliku.

// XML: contentDescription dla ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: ustawienie programowe
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (niestandardowy)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Przycisk usuwania"
        info.contentDescription = "Usuń wybrany element"
        info.className = Button::class.java.name
    }
}

// Live Regions do dynamicznych aktualizacji
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — mechanizm Android do powiadamiania TalkBack o zmianie zawartości bez fokusu. Atrybut android:accessibilityLiveRegion przyjmuje trzy wartości: none (brak powiadomień), polite (ogłosić po bieżącym), assertive (ogłosić natychmiast). Używaj polite do aktualizacji statusu ładowania, assertive — do krytycznych błędów. Nadużywanie assertive doprowadzi do chaosu dla użytkownika — TalkBack będzie ciągle przerywać bieżącą czynność.

Accessibility Scanner

Accessibility Scanner — darmowa aplikacja od Google do testowania dostępności aplikacji Android bez dostępu do kodu źródłowego. Skaner sprawdza: kontrast tekstu, rozmiar obszarów dotykowych (minimum 48×48dp według Android Accessibility Guidelines), obecność contentDescription dla ImageView, poprawność hierarchii elementów. Do automatycznych testów używaj AccessibilityChecks z Espresso — integrują się one z CI/CD i sprawdzają accessibility przy każdym buildzie.

WCAG 2.1: kontrast, rozmiar i obszary dotykowe

WCAG 2.1 (Web Content Accessibility Guidelines) — międzynarodowy standard dostępności opracowany przez W3C. Wersja 2.1 (2018) zawiera 13 dodatkowych kryteriów dla aplikacji mobilnych. Poziomy zgodności: A (minimalny), AA (obowiązkowy dla większości organizacji), AAA (maksymalny). Apple i Google zalecają poziom AA jako minimalny do publikacji aplikacji. WCAG 2.2 został wydany w 2023 roku z doprecyzowaniami dotyczącymi fokusu i wprowadzania danych.

Kluczowe kryteria dla programowania mobilnego: kontrast tekstu nie mniej niż 4.5:1 (AA) lub 7:1 (AAA), rozmiar obszarów dotykowych minimum 44×44pt (iOS) lub 48×48dp (Android), obsługa orientacji poziomej i pionowej bez utraty funkcjonalności, możliwość wyłączenia animacji (prefers-reduced-motion), obecność napisów do multimediów, kompatybilność ze sterowaniem głosowym (Voice Control na iOS, Voice Access na Android).

Narzędzia do sprawdzania kontrastu — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). W IT Sectr sprawdzamy kontrast na etapie projektu (Figma + Stark) i ponownie na etapie programowania (Accessibility Inspector / Accessibility Scanner). Minimalne wymaganie — 4.5:1 dla całego tekstu mniejszego niż 18pt (14pt bold). Dla logotypów i elementów dekoracyjnych kontrast nie jest wymagany.

Testowanie dostępności: narzędzia i lista kontrolna

Testowanie iOS — Accessibility Inspector w Xcode (Xcode → Open Developer Tool → Accessibility Inspector) sprawdza label, traits, hint dla każdego elementu. VoiceOver można włączyć w ustawieniach lub przez Accessibility Shortcut (potrójne naciśnięcie przycisku). Do testów automatycznych używaj XCUITest z XCTAssertTrue(app.staticTexts["label"].isAccessibilityElement). Apple zaleca przetestowanie wszystkich ekranów aplikacji z włączonym VoiceOver.

Testowanie Android — Accessibility Scanner (Play Store) sprawdza kontrast, rozmiar obszarów dotykowych, contentDescription. Do automatyzacji: Espresso AccessibilityChecks (import: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google zaleca listę kontrolną: każdy ImageView ma contentDescription, obszary dotykowe nie mniejsze niż 48×48dp, tekst skalowalny do 200% bez przycinania, wszystkie elementy osiągalne przez przesunięcie TalkBack.

Lista kontrolna IT Sectr — przed wydaniem sprawdzamy: (1) VoiceOver/TalkBack poprawnie odczytuje wszystkie elementy, (2) tekst skaluje się do maksymalnego rozmiaru bez utraty funkcjonalności, (3) wszystkie ImageView mają contentDescription, (4) kontrast tekstu ≥4.5:1 we wszystkich motywach, (5) obszary dotykowe ≥44pt/48dp, (6) brak menu kontekstowego dostępnego tylko po długim przytrzymaniu, (7) obsługa Reduce Motion / Remove Animations w ustawieniach systemowych. Ta lista kontrolna wchodzi w skład definition of done każdego sprintu.