Screen Reader: co to jest, typy czytników ekranu i zasada działania

Co to jest Screen Reader?

Screen Reader (czytnik ekranu) — to technologia wspomagająca (Assistive Technology, AT), która interpretuje graficzny interfejs użytkownika i prezentuje go w formie niewizualnej: poprzez syntetyzowaną mowę lub dotykowy wyświetlacz brajlowski. Czytniki ekranu są głównym środkiem dostępu do komputerów i urządzeń mobilnych dla osób z całkowitą lub częściową utratą wzroku.

Pierwsze czytniki ekranu pojawiły się pod koniec lat 80. XX wieku dla MS-DOS (np. Vocal-Eyes) i później dla Windows (JAWS, NVDA). Na platformach mobilnych czytniki ekranu zaczęto wbudowywać na poziomie systemowym: Apple zintegrowało VoiceOver w iPhone 3GS w 2009 roku, Google — TalkBack w Android 1.6 w tym samym roku. Do 2025 roku praktycznie wszystkie nowoczesne smartfony mają wbudowany czytnik ekranu, niewymagający instalacji dodatkowego oprogramowania.

Screen Reader nie tylko czyta tekst z ekranu — analizuje hierarchię interfejsu, określa typy elementów (przycisk, link, nagłówek, pole wprowadzania), ich stan (włączony/wyłączony, zaznaczony/niezaznaczony) i wzajemne powiązania (rodzic-dziecko, grupa). Ta informacja przekazywana jest użytkownikowi przez podpowiedzi głosowe lub wrażenia dotykowe wyświetlacza brajlowskiego, który aktualizuje komórki w czasie rzeczywistym zgodnie z położeniem fokusa.

Jak działa Screen Reader?

Screen Reader działa w ścisłym powiązaniu z systemem operacyjnym, uzyskując dostęp do jego wewnętrznej reprezentacji interfejsu — drzewa dostępności (Accessibility Tree). Ten mechanizm jest taki sam na iOS i Android, choć nazwy API się różnią.

Przekształcanie tekstu na mowę (TTS)

Głównym kanałem wyjściowym czytnika ekranu jest syntezator mowy (Text-To-Speech, TTS). Gdy fokus dostępności trafia na element, czytnik ekranu pobiera jego treść tekstową (lub opis określony przez dewelopera) i wysyła do silnika TTS. Nowoczesne silniki TTS, takie jak Apple Speech Synthesis i Google Text-to-Speech, wykorzystują sieci neuronowe do generowania naturalnej mowy z prawidłową intonacją, pauzami i akcentami w zależności od interpunkcji i typu treści.

Użytkownik może dostosować prędkość mowy (zwykle 60–80% maksymalnej dla komfortowego odbioru), wysokość tonu i głośność. Niektóre czytniki ekranu obsługują wiele głosów i przełączanie między nimi w zależności od typu treści — na przykład wolniejszy głos do czytania tekstu i szybszy do nawigacji po interfejsie. Wyświetlacze brajlowskie podłączane są przez Bluetooth i wyświetlają do 40–80 znaków jednocześnie, aktualizując wiersz przy każdej zmianie fokusa.

Sterowanie fokusem i nawigacja

Czytnik ekranu wykorzystuje koncepcję fokusa dostępności (Accessibility Focus), który różni się od standardowego fokusa wejścia. Użytkownik przesuwa fokus dostępności za pomocą gestów (dotknięcie, przeciągnięcie), a czytnik ekranu odczytuje element pod fokusem. Kolejność nawigacji domyślnie podąża za porządkiem wizualnym: od lewej do prawej, od góry do dołu. Deweloper może nadpisać tę kolejność dla złożonych układów.

Czytnik ekranu obsługuje również różne tryby nawigacji, które użytkownik przełącza przez rotor (VoiceOver) lub menu (TalkBack): według nagłówków, linków, znaków, słów, formularzy. W trybie nagłówków czytnik ekranu porusza się tylko między H1-H6 — to krytycznie ważne dla efektywnej nawigacji po długich stronach i dokumentach. Tryb znaków pomaga przy wprowadzaniu kodów potwierdzających lub złożonych haseł, wymawiając każdy znak osobno.

Główne czytniki ekranu dla platform mobilnych

Na platformach mobilnych dominują dwa czytniki ekranu: VoiceOver na iOS i TalkBack na Androidzie. Mają one różne API, gesty i możliwości, ale wspólną zasadę działania — odczytywanie drzewa dostępności i sterowanie gestami.

VoiceOver (iOS)

VoiceOver — czytnik ekranu od Apple, wbudowany w iOS, iPadOS i macOS. Wykorzystuje API UIAccessibility do uzyskiwania informacji o elementach i obsługuje rotor do przełączania trybów nawigacji. VoiceOver jest zintegrowany z iCloud (ustawienia synchronizują się między urządzeniami), Apple Pay (potwierdzenie płatności przez Touch ID lub Face ID) i dynamicznym tekstem (czcionka dostosowuje się do ustawień użytkownika).

Gesty VoiceOver różnią się od TalkBack: używa się obrotu dwoma palcami (rotor), potrójnego dotknięcia dla Screen Curtain i podwójnego dotknięcia dwoma palcami do anulowania akcji. VoiceOver obsługuje niestandardowe rotory, które deweloper dodaje przez UIAccessibilityCustomRotor — na przykład do szybkiej nawigacji po sekcjach aplikacji z pominięciem standardowej kolejności.

TalkBack (Android)

TalkBack — czytnik ekranu od Google, wchodzący w skład Android Accessibility Suite. Wykorzystuje AccessibilityService i AccessibilityNodeInfo do dostępu do interfejsu. TalkBack obsługuje globalne menu przez przeciągnięcie w kształcie L, niestandardowe akcje dla elementów i LiveRegion do dynamicznych aktualizacji. Począwszy od Androida 14, TalkBack otrzymał obsługę gestów jedną ręką i lepszą integrację z Google Assistant.

TalkBack ma bardziej elastyczny system gestów niż VoiceOver: użytkownik może skonfigurować praktycznie każdy gest do dowolnej akcji. TalkBack obsługuje również wprowadzanie brajla na ekranie (BrailleBack) — użytkownik wprowadza tekst znakami brajla bezpośrednio na ekranie dotykowym w specjalnym układzie 3×2 dla każdego palca, co znacznie przyspiesza wprowadzanie tekstu w porównaniu z klawiaturą ekranową.

Oprócz VoiceOver i TalkBack istnieją mniej rozpowszechnione mobilne czytniki ekranu: Select to Speak (Android, odczytywanie zaznaczonego obszaru), Samsung Voice Assistant (zamiennik TalkBack na urządzeniach Samsung z One UI) i rozwiązania firm trzecich dla specyficznych nisz — na przykład dla użytkowników chińskich smartfonów bez usług Google.

Jak Screen Reader współdziała z aplikacją

Screen Reader nie ma bezpośredniego dostępu do komponentów UI aplikacji. Zamiast tego działa przez warstwę pośrednią — API dostępności systemu operacyjnego. System operacyjny buduje drzewo dostępności (Accessibility Tree), które czytnik ekranu przegląda i analizuje.

Accessibility Tree na iOS i Android

Na iOS drzewo dostępności budowane jest z obiektów UIAccessibilityElement, odpowiadających każdemu View na ekranie. Każdy element zawiera label (główny tekst), traits (typ elementu: przycisk, nagłówek, link), hint (podpowiedź), value (bieżąca wartość dla suwaków i wskaźników) i frame (obszar dotyku). System automatycznie tworzy elementy dla standardowych komponentów UI, ale deweloper może dodawać i konfigurować je.

Na Android drzewo dostępności budowane jest z obiektów AccessibilityNodeInfo. Każdy węzeł zawiera: text (tekst lub contentDescription), className (typ elementu), contentDescription (opis), stateDescription (stan), isEnabled, isChecked, isClickable i inne flagi. Android obsługuje również AccessibilityAction — listę akcji, które czytnik ekranu może wykonać w imieniu użytkownika: kliknięcie, długie naciśnięcie, przewinięcie, ustawienie fokusa, ustawienie tekstu.

Zdarzenia dostępności (Accessibility Events)

Gdy w interfejsie następuje zmiana (pojawił się nowy element, zmienił się tekst, element stał się widoczny lub niewidoczny), system operacyjny wysyła AccessibilityEvent. Czytnik ekranu subskrybuje te zdarzenia i reaguje na nie: na przykład przy pojawieniu się okna dialogowego czytnik ekranu automatycznie przesuwa fokus na jego nagłówek i odczytuje treść.

// Nasłuchiwanie zdarzeń dostępności na Androidzie
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

Na iOS podobne zdarzenia są obsługiwane przez UIAccessibility.Notification: layoutChanged (zmienił się układ), screenChanged (całkowicie nowy ekran), announcement (dowolne ogłoszenie), pageScrolled (przewinięcie strony). Deweloper wysyła te zdarzenia przez UIAccessibility.post, aby czytnik ekranu prawidłowo reagował na zmiany. Na przykład przy otwarciu okna modalnego należy wysłać screenChanged z wskazaniem nowego nagłówka — w przeciwnym razie VoiceOver pozostanie na poprzednim elemencie pod oknem.

Tworzenie aplikacji z uwzględnieniem Screen Reader

Tworzenie dostępnej aplikacji to nie dodawanie contentDescription do każdego elementu, ale przemyślenie doświadczenia użytkownika dla interakcji niewizualnej. Podstawowe zasady są wspólne dla obu platform, choć implementacja się różni.

Podstawowe zasady dostępności

Wszystkie interaktywne elementy powinny mieć znaczący opis: przycisk „Wyślij" powinien być opisany jako „Wyślij wiadomość", a nie „Przycisk". Elementy dekoracyjne (separatory, obrazy tła, ikony bez funkcjonalności) powinny być ukryte przed czytnikiem ekranu. Kolejność nawigacji powinna odpowiadać logicznemu przepływowi ekranu, a nie wizualnemu rozmieszczeniu. Kontrast tekstu powinien wynosić co najmniej 4.5:1 dla tekstu podstawowego i 3:1 dla dużego (WCAG AA).

// iOS: prawidłowa konfiguracja złożonego elementu
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Głośność dźwięku"
customControl.accessibilityValue = "75 procent"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Zwiększa lub zmniejsza głośność"

// Aktualizacja przy zmianie wartości
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) procent"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Na iOS flaga isAccessibilityElement włącza obsługę VoiceOver dla niestandardowych elementów. Kombinacja traits (.adjustable + .button) informuje VoiceOver, że element można regulować przeciągnięciem w górę/dół i aktywować podwójnym dotknięciem. Po zmianie wartości obowiązkowo wysyłane jest powiadomienie layoutChanged — w przeciwnym razie VoiceOver będzie nadal odczytywać starą wartość.

Zalecenia specyficzne dla obu platform

Dla iOS: używaj accessibilityElements do nadpisania kolejności czytania, accessibilityCustomActions dla dodatkowych akcji w menu kontekstowym i shouldGroupAccessibilityChildren do grupowania elementów w logiczne grupy. Dla SwiftUI stosuj modyfikatory .accessibilityLabel(), .accessibilityAddTraits() i .accessibilityRespondsToUserInteraction(). Unikaj używania isAccessibilityElement = false na kontenerach zawierających interaktywne elementy potomne — ukryje je to przed VoiceOver.

Dla Android: używaj accessibilityTraversalBefore i accessibilityTraversalAfter do kolejności nawigacji, AccessibilityDelegate dla niestandardowych elementów i LiveRegion (polite/assertive) dla dynamicznych aktualizacji. W Compose stosuj modyfikator .semantics {} z contentDescription, stateDescription i customActions. Unikaj używania focusable = true na nieinteraktywnych elementach — stworzy to fałszywe punkty fokusa dla TalkBack i zdezorientuje użytkownika.

Narzędzia testowania

Testowanie z czytnikiem ekranu jest obowiązkowe na fizycznym urządzeniu. Emulator/symulator daje podstawowe pojęcie, ale gesty i szybkość reakcji się różnią. Używaj Accessibility Inspector (Xcode) dla iOS i Accessibility Scanner (Android) do automatycznego wyszukiwania problemów.

Główne scenariusze testowania: rejestracja (wypełnianie formularza, walidacja, wysyłanie), wyszukiwanie i nawigacja po katalogu, składanie zamówienia, odzyskiwanie hasła. Każdy scenariusz powinien być wykonalny bez kontroli wzrokowej — tylko przez podpowiedzi głosowe czytnika ekranu. Jeśli użytkownik czytnika ekranu nie może ukończyć scenariusza w tym samym czasie co zwykły użytkownik (±50%), — aplikacja wymaga poprawy dostępności.