Screen Reader: mi ez, a képernyőolvasók típusai és működési elve

Mi az a Screen Reader?

Screen Reader (képernyőolvasó) — egy segítő technológia (Assistive Technology, AT), amely értelmezi a grafikus felhasználói felületet és nem vizuális formában jeleníti meg: szintetizált beszéd vagy tapintható Braille-kijelző segítségével. A képernyőolvasók a fő hozzáférési eszközök a számítógépekhez és mobil eszközökhöz a teljes vagy részleges látásvesztéssel élő emberek számára.

Az első képernyőolvasók az 1980-as évek végén jelentek meg MS-DOS-ra (pl. Vocal-Eyes) és később Windows-ra (JAWS, NVDA). Mobil platformokon a képernyőolvasók rendszerszinten kezdtek beépülni: az Apple 2009-ben integrálta a VoiceOver-t az iPhone 3GS-be, a Google ugyanebben az évben a TalkBack-et az Android 1.6-ba. 2025-re szinte minden modern okostelefon rendelkezik beépített képernyőolvasóval, amely nem igényel további szoftver telepítését.

A Screen Reader nem csak szöveget olvas a képernyőről — elemzi a felület hierarchiáját, meghatározza az elemek típusait (gomb, link, fejléc, beviteli mező), azok állapotát (bekapcsolt/kikapcsolt, kiválasztott/nem kiválasztott) és kölcsönös kapcsolatait (szülő-gyermek, csoport). Ez az információ hangos útmutatásokon vagy a Braille-kijelző tapintási érzésein keresztül jut el a felhasználóhoz, amely a fókusz helyzetének megfelelően valós időben frissíti a cellákat.

Hogyan működik a Screen Reader?

A Screen Reader szoros kapcsolatban működik az operációs rendszerrel, hozzáférve annak a felület belső reprezentációjához — az akadálymentesítési fához (Accessibility Tree). Ez a mechanizmus azonos iOS-en és Androidon, bár az API nevek különböznek.

Szöveg beszéddé alakítása (TTS)

A képernyőolvasó fő kimeneti csatornája a beszédszintetizátor (Text-To-Speech, TTS). Amikor az akadálymentesítési fókusz egy elemre kerül, a képernyőolvasó kivonja annak szöveges tartalmát (vagy a fejlesztő által megadott leírást) és elküldi a TTS-motorba. A modern TTS-motorok, mint az Apple Speech Synthesis és a Google Text-to-Speech, neurális hálózatokat használnak a természetes beszéd generálásához, megfelelő intonációval, szünetekkel és hangsúlyokkal, az írásjelektől és a tartalom típusától függően.

A felhasználó beállíthatja a beszéd sebességét (általában a maximum 60-80%-a a kényelmes érzékeléshez), a hangmagasságot és a hangerőt. Egyes képernyőolvasók több hangot és a tartalom típusától függő váltást támogatnak — például lassabb hangot szövegolvasáshoz és gyorsat a felület navigálásához. A Braille-kijelzők Bluetooth-on keresztül csatlakoznak, és egyszerre 40-80 karaktert jelenítenek meg, soronként frissítve a fókusz minden változásakor.

Fókuszvezérlés és navigáció

A képernyőolvasó az akadálymentesítési fókusz (Accessibility Focus) koncepcióját használja, amely eltér a szokásos beviteli fókusztól. A felhasználó gesztusokkal (érintés, húzás) mozgatja az akadálymentesítési fókuszt, és a képernyőolvasó felolvassa a fókusz alatti elemet. A navigáció sorrendje alapértelmezés szerint a vizuális sorrendet követi: balról jobbra, fentről lefelé. A fejlesztő felülbírálhatja ezt a sorrendet összetett elrendezések esetén.

A képernyőolvasó különböző navigációs módokat is támogat, amelyeket a felhasználó a rotor (VoiceOver) vagy a menü (TalkBack) segítségével vált: fejlécek, linkek, karakterek, szavak, űrlapok szerint. Fejléc módban a képernyőolvasó csak H1-H6 között mozog — ez kritikus fontosságú a hosszú oldalak és dokumentumok hatékony navigálásához. A karakter mód segít a megerősítő kódok vagy összetett jelszavak beírásakor, minden karaktert külön kiejtve.

Fő képernyőolvasók mobil platformokhoz

A mobil platformokon két képernyőolvasó dominál: a VoiceOver iOS-en és a TalkBack Androidon. Különböző API-kkal, gesztusokkal és képességekkel rendelkeznek, de közös a működési elvük — az akadálymentesítési fa olvasása és gesztusokkal történő vezérlés.

VoiceOver (iOS)

VoiceOver — az Apple képernyőolvasója, beépítve az iOS, iPadOS és macOS rendszerekbe. A UIAccessibility API-t használja az elemekkel kapcsolatos információk megszerzéséhez, és támogatja a rotort a navigációs módok váltásához. A VoiceOver integrálva van az iCloud-dal (a beállítások szinkronizálódnak az eszközök között), az Apple Pay-jel (fizetés megerősítése Touch ID vagy Face ID segítségével) és a dinamikus szöveggel (a betűtípus a felhasználó beállításaihoz igazodik).

A VoiceOver gesztusai eltérnek a TalkBack-től: kétujjas forgatást (rotor), háromszori érintést a Screen Curtain-hez és kétujjas dupla érintést a művelet megszakításához használ. A VoiceOver támogatja az egyéni rotorokat, amelyeket a fejlesztő a UIAccessibilityCustomRotor segítségével ad hozzá — például az alkalmazás szekcióin keresztüli gyors navigációhoz, megkerülve a szokásos sorrendet.

TalkBack (Android)

TalkBack — a Google képernyőolvasója, az Android Accessibility Suite része. Az AccessibilityService és AccessibilityNodeInfo segítségével fér hozzá a felülethez. A TalkBack támogatja a globális menüt L-alakú húzással, egyéni műveleteket elemekhez és a LiveRegion-t a dinamikus frissítésekhez. Az Android 14-től kezdve a TalkBack egykezes gesztusok támogatását és továbbfejlesztett Google Assistant-integrációt kapott.

A TalkBack rugalmasabb gesztusrendszerrel rendelkezik, mint a VoiceOver: a felhasználó szinte bármilyen gesztust beállíthat bármilyen művelethez. A TalkBack támogatja a Braille-bevitelt is a képernyőn (BrailleBack) — a felhasználó közvetlenül az érintőképernyőn ír be szöveget Braille-karakterekkel, ujjonként egy speciális 3×2 elrendezésben, ami jelentősen felgyorsítja a gépelést a képernyő-billentyűzethez képest.

A VoiceOver és TalkBack mellett léteznek kevésbé elterjedt mobil képernyőolvasók is: Select to Speak (Android, kiválasztott terület felolvasása), Samsung Voice Assistant (TalkBack helyettesítő Samsung One UI eszközökön) és harmadik féltől származó megoldások specifikus niche-ekre — például Google-szolgáltatások nélküli kínai okostelefonok felhasználóinak.

Hogyan lép kapcsolatba a Screen Reader az alkalmazással

A Screen Reader nem rendelkezik közvetlen hozzáféréssel az alkalmazás UI-komponenseihez. Ehelyett egy köztes rétegen — az operációs rendszer akadálymentesítési API-ján — keresztül működik. Az operációs rendszer felépíti az akadálymentesítési fát (Accessibility Tree), amelyet a képernyőolvasó bejár és elemzi.

Accessibility Tree iOS-en és Androidon

iOS-en az akadálymentesítési fa UIAccessibilityElement objektumokból épül fel, amelyek a képernyő minden View-jának megfelelnek. Minden elem tartalmazza: label (fő szöveg), traits (elem típusa: gomb, fejléc, link), hint (útmutatás), value (aktuális érték csúszkákhoz és jelzőkhöz) és frame (érintési terület). A rendszer automatikusan létrehozza az elemeket a szabványos UI-komponensekhez, de a fejlesztő hozzáadhatja és konfigurálhatja azokat.

Androidon az akadálymentesítési fa AccessibilityNodeInfo objektumokból épül fel. Minden csomópont tartalmazza: text (szöveg vagy contentDescription), className (elem típusa), contentDescription (leírás), stateDescription (állapot), isEnabled, isChecked, isClickable és egyéb jelzőket. Az Android támogatja az AccessibilityAction-t is — a műveletek listáját, amelyeket a képernyőolvasó a felhasználó nevében végrehajthat: kattintás, hosszú nyomás, görgetés, fókusz beállítása, szöveg beállítása.

Akadálymentesítési események (Accessibility Events)

Amikor változás történik a felületen (új elem jelent meg, megváltozott a szöveg, az elem láthatóvá vagy láthatatlanná vált), az operációs rendszer AccessibilityEvent-et küld. A képernyőolvasó feliratkozik ezekre az eseményekre és reagál rájuk: például egy párbeszédablak megjelenésekor a képernyőolvasó automatikusan a fejlécére helyezi a fókuszt és felolvassa a tartalmat.

// Akadálymentesítési események figyelése Androidon
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)
        }
    }
}

iOS-en hasonló eseményeket a UIAccessibility.Notification kezel: layoutChanged (megváltozott az elrendezés), screenChanged (teljesen új képernyő), announcement (tetszőleges bejelentés), pageScrolled (oldal görgetés). A fejlesztő a UIAccessibility.post segítségével küldi ezeket az eseményeket, hogy a képernyőolvasó megfelelően reagáljon a változásokra. Például egy modális ablak megnyitásakor screenChanged-et kell küldeni az új fejléccel — különben a VoiceOver az ablak alatti előző elemen marad.

Alkalmazásfejlesztés a Screen Reader figyelembevételével

Egy akadálymentes alkalmazás létrehozása nem csupán a contentDescription hozzáadását jelenti minden elemhez, hanem a nem vizuális interakció felhasználói élményének átgondolását. Az alapvető szabályok mindkét platformon közösek, bár a megvalósítás eltérő.

Az akadálymentesítés alapvető szabályai

Minden interaktív elemnek értelmes leírással kell rendelkeznie: a „Küldés" gombot „Üzenet küldése"-ként kell leírni, nem „Gomb"-ként. A dekoratív elemeket (elválasztók, háttérképek, funkció nélküli ikonok) el kell rejteni a képernyőolvasó elől. A navigáció sorrendjének a képernyő logikai folyamatát kell követnie, nem a vizuális elrendezést. A szövegkontrasztnak legalább 4.5:1-nek kell lennie a fő szöveghez és 3:1-nek a nagy szöveghez (WCAG AA).

// iOS: összetett elem helyes konfigurációja
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Hangerő"
customControl.accessibilityValue = "75 százalék"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Növeli vagy csökkenti a hangerőt"

// Frissítés értékváltozáskor
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) százalék"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

iOS-en az isAccessibilityElement jelző bekapcsolja a VoiceOver-támogatást az egyéni elemekhez. A traits (.adjustable + .button) kombináció tájékoztatja a VoiceOver-t, hogy az elem fel/le húzással állítható és dupla érintéssel aktiválható. Az érték megváltozása után kötelező a layoutChanged értesítés elküldése — különben a VoiceOver továbbra is a régi értéket olvassa fel.

Speciális ajánlások mindkét platformhoz

iOS-hez: használja az accessibilityElements tulajdonságot az olvasási sorrend felülbírálásához, az accessibilityCustomActions-t további műveletekhez a helyi menüben és a shouldGroupAccessibilityChildren-t az elemek logikai csoportokba rendezéséhez. SwiftUI-hez alkalmazza a .accessibilityLabel(), .accessibilityAddTraits() és .accessibilityRespondsToUserInteraction() módosítókat. Kerülje az isAccessibilityElement = false használatát olyan tárolókon, amelyek interaktív gyermekelemeket tartalmaznak — ez elrejti őket a VoiceOver elől.

Androidhoz: használja az accessibilityTraversalBefore és accessibilityTraversalAfter tulajdonságokat a navigációs sorrendhez, az AccessibilityDelegate-et egyéni elemekhez és a LiveRegion-t (polite/assertive) a dinamikus frissítésekhez. Compose-ban alkalmazza a .semantics {} módosítót contentDescription, stateDescription és customActions paraméterekkel. Kerülje a focusable = true használatát nem interaktív elemeken — ez hamis fókuszpontokat hoz létre a TalkBack számára és összezavarja a felhasználót.

Tesztelő eszközök

A képernyőolvasóval történő tesztelés fizikai eszközön kötelező. Az emulátor/szimulátor alapvető képet ad, de a gesztusok és a válaszidő eltérő. Használja az Accessibility Inspector-t (Xcode) iOS-hez és az Accessibility Scanner-t Androidhoz a problémák automatikus kereséséhez.

A fő tesztelési forgatókönyvek: regisztráció (űrlap kitöltése, érvényesítés, elküldés), keresés és navigáció a katalógusban, rendelés leadása, jelszó helyreállítása. Minden forgatókönyvnek végrehajthatónak kell lennie vizuális kontroll nélkül — csak a képernyőolvasó hangos útmutatásain keresztül. Ha egy képernyőolvasót használó felhasználó nem tudja ugyanannyi idő alatt (±50%) befejezni a forgatókönyvet, mint egy átlagos felhasználó, — az alkalmazás akadálymentesítési fejlesztést igényel.