Screen Reader: ce este, tipuri de cititoare de ecran și principiul de funcționare

Ce este Screen Reader?

Screen Reader (cititor de ecran) — este o tehnologie asistivă (Assistive Technology, AT) care interpretează interfața grafică a utilizatorului și o prezintă într-o formă non-vizuală: prin vorbire sintetizată sau afișaj tactil Braille. Cititoarele de ecran sunt principalul mijloc de acces la computere și dispozitive mobile pentru persoanele cu pierdere totală sau parțială a vederii.

Primele cititoare de ecran au apărut la sfârșitul anilor 1980 pentru MS-DOS (de exemplu, Vocal-Eyes) și mai târziu pentru Windows (JAWS, NVDA). Pe platformele mobile, cititoarele de ecran au început să fie încorporate la nivel de sistem: Apple a integrat VoiceOver în iPhone 3GS în 2009, Google — TalkBack în Android 1.6 în același an. Până în 2025, aproape toate smartphone-urile moderne au un cititor de ecran încorporat care nu necesită instalarea de software suplimentar.

Screen Reader nu doar citește textul de pe ecran — el analizează ierarhia interfeței, determină tipurile de elemente (buton, link, titlu, câmp de intrare), starea lor (activat/dezactivat, selectat/neselectat) și relațiile reciproce (părinte-copil, grup). Aceste informații sunt transmise utilizatorului prin indicii vocale sau senzații tactile ale afișajului Braille, care actualizează celulele în timp real în funcție de poziția focalizării.

Cum funcționează Screen Reader?

Screen Reader funcționează în strânsă legătură cu sistemul de operare, având acces la reprezentarea sa internă a interfeței — arborele de accesibilitate (Accessibility Tree). Acest mecanism este același pe iOS și Android, deși denumirile API diferă.

Transformarea textului în vorbire (TTS)

Principalul canal de ieșire al cititorului de ecran este sintetizatorul de vorbire (Text-To-Speech, TTS). Când focalizarea de accesibilitate ajunge la un element, cititorul de ecran extrage conținutul său text (sau descrierea stabilită de dezvoltator) și îl trimite către motorul TTS. Motoarele TTS moderne, precum Apple Speech Synthesis și Google Text-to-Speech, utilizează rețele neuronale pentru a genera vorbire naturală cu intonație, pauze și accente corecte în funcție de punctuație și tipul de conținut.

Utilizatorul poate ajusta viteza vorbirii (de obicei 60–80% din maxim pentru o percepție confortabilă), înălțimea tonului și volumul. Unele cititoare de ecran suportă mai multe voci și comutarea între ele în funcție de tipul de conținut — de exemplu, o voce mai lentă pentru citirea textului și una rapidă pentru navigarea prin interfață. Afișajele Braille se conectează prin Bluetooth și afișează 40–80 de caractere simultan, actualizând rândul la fiecare schimbare a focalizării.

Controlul focalizării și navigarea

Cititorul de ecran utilizează conceptul de focalizare de accesibilitate (Accessibility Focus), care diferă de focalizarea standard de intrare. Utilizatorul mută focalizarea de accesibilitate cu ajutorul gesturilor (atingere, glisare), iar cititorul de ecran anunță elementul aflat sub focalizare. Ordinea de navigare implicită urmează ordinea vizuală: de la stânga la dreapta, de sus în jos. Dezvoltatorul poate suprascrie această ordine pentru layout-uri complexe.

Cititorul de ecran suportă și diferite moduri de navigare, pe care utilizatorul le comută prin rotor (VoiceOver) sau meniu (TalkBack): după titluri, linkuri, caractere, cuvinte, formulare. În modul titluri, cititorul de ecran se deplasează doar între H1-H6 — acest lucru este esențial pentru navigarea eficientă prin pagini și documente lungi. Modul caractere ajută la introducerea codurilor de confirmare sau a parolelor complexe, pronunțând fiecare caracter separat.

Principalele cititoare de ecran pentru platforme mobile

Pe platformele mobile domină două cititoare de ecran: VoiceOver pe iOS și TalkBack pe Android. Acestea au API-uri, gesturi și capacități diferite, dar un principiu comun de funcționare — citirea arborelui de accesibilitate și controlul prin gesturi.

VoiceOver (iOS)

VoiceOver — cititorul de ecran de la Apple, încorporat în iOS, iPadOS și macOS. Utilizează API-ul UIAccessibility pentru a obține informații despre elemente și suportă rotorul pentru comutarea modurilor de navigare. VoiceOver este integrat cu iCloud (setările se sincronizează între dispozitive), Apple Pay (confirmarea plății prin Touch ID sau Face ID) și textul dinamic (fontul se adaptează la setările utilizatorului).

Gesturile VoiceOver diferă de TalkBack: se utilizează rotația cu două degete (rotor), atingerea triplă pentru Screen Curtain și atingerea dublă cu două degete pentru anularea acțiunii. VoiceOver suportă rotori personalizați, pe care dezvoltatorul îi adaugă prin UIAccessibilityCustomRotor — de exemplu, pentru navigarea rapidă prin secțiunile aplicației, ocolind ordinea standard.

TalkBack (Android)

TalkBack — cititorul de ecran de la Google, parte din Android Accessibility Suite. Utilizează AccessibilityService și AccessibilityNodeInfo pentru accesul la interfață. TalkBack suportă meniul global prin glisare în formă de L, acțiuni personalizate pentru elemente și LiveRegion pentru actualizări dinamice. Începând cu Android 14, TalkBack a primit suport pentru gesturi cu o singură mână și integrare îmbunătățită cu Google Assistant.

TalkBack are un sistem de gesturi mai flexibil decât VoiceOver: utilizatorul poate configura aproape orice gest pentru orice acțiune. TalkBack suportă și introducerea Braille pe ecran (BrailleBack) — utilizatorul introduce textul cu caractere Braille direct pe ecranul tactil într-un aranjament special 3×2 pentru fiecare deget, ceea ce accelerează semnificativ tastarea în comparație cu tastatura ecran.

Pe lângă VoiceOver și TalkBack, există cititoare de ecran mobile mai puțin răspândite: Select to Speak (Android, anunțarea zonei selectate), Samsung Voice Assistant (înlocuitor pentru TalkBack pe dispozitivele Samsung cu One UI) și soluții terțe pentru nișe specifice — de exemplu, pentru utilizatorii de smartphone-uri chinezești fără servicii Google.

Cum interacționează Screen Reader cu aplicația

Screen Reader nu are acces direct la componentele UI ale aplicației. În schimb, funcționează printr-un strat intermediar — API-ul de accesibilitate al sistemului de operare. Sistemul de operare construiește arborele de accesibilitate (Accessibility Tree), pe care cititorul de ecran îl parcurge și analizează.

Accessibility Tree pe iOS și Android

Pe iOS, arborele de accesibilitate este construit din obiecte UIAccessibilityElement, corespunzând fiecărui View de pe ecran. Fiecare element conține label (textul principal), traits (tipul elementului: buton, titlu, link), hint (sugestie), value (valoarea curentă pentru glisoare și indicatoare) și frame (zona de atingere). Sistemul creează automat elemente pentru componentele UI standard, dar dezvoltatorul le poate adăuga și configura.

Pe Android, arborele de accesibilitate este construit din obiecte AccessibilityNodeInfo. Fiecare nod conține: text (text sau contentDescription), className (tipul elementului), contentDescription (descriere), stateDescription (stare), isEnabled, isChecked, isClickable și alte flaguri. Android suportă și AccessibilityAction — o listă de acțiuni pe care cititorul de ecran le poate executa din partea utilizatorului: clic, apăsare lungă, derulare, setare focalizare, setare text.

Evenimente de accesibilitate (Accessibility Events)

Când are loc o schimbare în interfață (a apărut un element nou, s-a schimbat textul, elementul a devenit vizibil sau invizibil), sistemul de operare trimite un AccessibilityEvent. Cititorul de ecran este abonat la aceste evenimente și reacționează la ele: de exemplu, la apariția unei ferestre de dialog, cititorul de ecran mută automat focalizarea pe titlul acesteia și anunță conținutul.

// Ascultarea evenimentelor de accesibilitate pe Android
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)
        }
    }
}

Pe iOS, evenimente similare sunt gestionate prin UIAccessibility.Notification: layoutChanged (s-a schimbat layout-ul), screenChanged (ecran complet nou), announcement (anunț arbitrar), pageScrolled (derulare pagină). Dezvoltatorul trimite aceste evenimente prin UIAccessibility.post pentru ca cititorul de ecran să reacționeze corect la modificări. De exemplu, la deschiderea unei ferestre modale, trebuie trimis screenChanged cu noul titlu — altfel VoiceOver va rămâne pe elementul anterior sub fereastră.

Dezvoltarea aplicațiilor ținând cont de Screen Reader

Crearea unei aplicații accesibile nu înseamnă doar adăugarea de contentDescription la fiecare element, ci gândirea experienței utilizatorului pentru interacțiunea non-vizuală. Regulile de bază sunt comune pentru ambele platforme, deși implementarea diferă.

Reguli de bază de accesibilitate

Toate elementele interactive trebuie să aibă o descriere semnificativă: butonul „Trimite" trebuie descris ca „Trimite mesaj", nu ca „Buton". Elementele decorative (separatoare, imagini de fundal, pictograme fără funcționalitate) trebuie ascunse de cititorul de ecran. Ordinea de navigare trebuie să corespundă fluxului logic al ecranului, nu aranjamentului vizual. Contrastul textului trebuie să fie de cel puțin 4.5:1 pentru textul principal și 3:1 pentru textul mare (WCAG AA).

// iOS: configurarea corectă pentru un element complex
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volumul sunetului"
customControl.accessibilityValue = "75 procente"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Crește sau reduce volumul"

// Actualizare la schimbarea valorii
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) procente"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Pe iOS, flagul isAccessibilityElement activează suportul VoiceOver pentru elementele personalizate. Combinația de traits (.adjustable + .button) informează VoiceOver că elementul poate fi reglat prin glisare în sus/jos și activat prin atingere dublă. După modificarea valorii, se trimite obligatoriu notificarea layoutChanged — altfel VoiceOver va continua să anunțe valoarea veche.

Recomandări specifice pentru ambele platforme

Pentru iOS: utilizați accessibilityElements pentru a suprascrie ordinea de citire, accessibilityCustomActions pentru acțiuni suplimentare în meniul contextual și shouldGroupAccessibilityChildren pentru gruparea elementelor în grupuri logice. Pentru SwiftUI, aplicați modificatorii .accessibilityLabel(), .accessibilityAddTraits() și .accessibilityRespondsToUserInteraction(). Evitați utilizarea isAccessibilityElement = false pe containere care conțin elemente interactive copil — acest lucru le va ascunde de VoiceOver.

Pentru Android: utilizați accessibilityTraversalBefore și accessibilityTraversalAfter pentru ordinea de navigare, AccessibilityDelegate pentru elemente personalizate și LiveRegion (polite/assertive) pentru actualizări dinamice. În Compose, aplicați modificatorul .semantics {} cu contentDescription, stateDescription și customActions. Evitați utilizarea focusable = true pe elemente neinteractive — acest lucru va crea puncte de focalizare false pentru TalkBack și va deruta utilizatorul.

Instrumente de testare

Testarea cu cititorul de ecran este obligatorie pe un dispozitiv fizic. Emulatorul/simulatorul oferă o idee de bază, dar gesturile și viteza de răspuns diferă. Utilizați Accessibility Inspector (Xcode) pentru iOS și Accessibility Scanner pentru Android pentru căutarea automată a problemelor.

Principalele scenarii de testare: înregistrarea (completarea formularului, validare, trimitere), căutarea și navigarea prin catalog, plasarea comenzii, recuperarea parolei. Fiecare scenariu trebuie să fie realizabil fără control vizual — doar prin indicii vocale ale cititorului de ecran. Dacă un utilizator al cititorului de ecran nu poate finaliza scenariul în același timp ca un utilizator obișnuit (±50%), — aplicația necesită îmbunătățiri de accesibilitate.