Screen Reader: wat is het, soorten schermlezers en werkingsprincipe

Wat is Screen Reader?

Screen Reader (schermlezer) — is een ondersteunende technologie (Assistive Technology, AT) die de grafische gebruikersinterface interpreteert en presenteert in een niet-visuele vorm: via gesynthetiseerde spraak of een tactiel brailleleesregel. Schermlezers zijn het belangrijkste middel voor toegang tot computers en mobiele apparaten voor mensen met volledig of gedeeltelijk verlies van het gezichtsvermogen.

De eerste schermlezers verschenen eind jaren 80 voor MS-DOS (bijv. Vocal-Eyes) en later voor Windows (JAWS, NVDA). Op mobiele platforms werden schermlezers op systeemniveau ingebouwd: Apple integreerde VoiceOver in de iPhone 3GS in 2009, Google integreerde TalkBack in Android 1.6 in hetzelfde jaar. Tegen 2025 hebben vrijwel alle moderne smartphones een ingebouwde schermlezer die geen installatie van extra software vereist.

Screen Reader leest niet alleen tekst van het scherm — het analyseert de hiërarchie van de interface, bepaalt de typen elementen (knop, link, koptekst, invoerveld), hun status (ingeschakeld/uitgeschakeld, geselecteerd/niet geselecteerd) en onderlinge relaties (ouder-kind, groep). Deze informatie wordt aan de gebruiker doorgegeven via spraakaanwijzingen of tactiele sensaties van het brailleleesregel, die cellen in realtime bijwerkt op basis van de positie van de focus.

Hoe werkt Screen Reader?

Screen Reader werkt nauw samen met het besturingssysteem en heeft toegang tot de interne weergave van de interface — de toegankelijkheidsboom (Accessibility Tree). Dit mechanisme is hetzelfde op iOS en Android, hoewel de API-namen verschillen.

Tekst-naar-spraak (TTS)

Het belangrijkste uitgangskanaal van de schermlezer is de spraaksynthesizer (Text-To-Speech, TTS). Wanneer de toegankelijkheidsfocus op een element valt, haalt de schermlezer de tekstuele inhoud (of de door de ontwikkelaar opgegeven beschrijving) op en stuurt deze naar de TTS-engine. Moderne TTS-engines zoals Apple Speech Synthesis en Google Text-to-Speech gebruiken neurale netwerken om natuurlijke spraak te genereren met de juiste intonatie, pauzes en accenten, afhankelijk van interpunctie en type inhoud.

De gebruiker kan de spraaksnelheid aanpassen (meestal 60-80% van het maximum voor comfortabele waarneming), toonhoogte en volume. Sommige schermlezers ondersteunen meerdere stemmen en schakelen ertussen op basis van het type inhoud — bijvoorbeeld een langzamere stem voor het lezen van tekst en een snelle voor navigatie door de interface. Brailleleesregels worden via Bluetooth aangesloten en tonen 40-80 tekens tegelijk, waarbij de regel wordt bijgewerkt bij elke wijziging van de focus.

Focusbeheer en navigatie

De schermlezer gebruikt het concept van toegankelijkheidsfocus (Accessibility Focus), die verschilt van de standaard invoerfocus. De gebruiker verplaatst de toegankelijkheidsfocus met gebaren (aanraken, vegen) en de schermlezer spreekt het element onder de focus uit. De navigatievolgorde volgt standaard de visuele volgorde: van links naar rechts, van boven naar beneden. De ontwikkelaar kan deze volgorde overschrijven voor complexe lay-outs.

De schermlezer ondersteunt ook verschillende navigatiemodi, die de gebruiker schakelt via de rotor (VoiceOver) of het menu (TalkBack): op koppen, links, tekens, woorden, formulieren. In de kopmodus beweegt de schermlezer alleen tussen H1-H6 — dit is cruciaal voor efficiënte navigatie door lange pagina's en documenten. De tekenmodus helpt bij het invoeren van bevestigingscodes of complexe wachtwoorden, waarbij elk teken afzonderlijk wordt uitgesproken.

Belangrijkste schermlezers voor mobiele platforms

Op mobiele platforms domineren twee schermlezers: VoiceOver op iOS en TalkBack op Android. Ze hebben verschillende API's, gebaren en mogelijkheden, maar een gemeenschappelijk werkingsprincipe — het lezen van de toegankelijkheidsboom en bediening met gebaren.

VoiceOver (iOS)

VoiceOver — de schermlezer van Apple, ingebouwd in iOS, iPadOS en macOS. Het gebruikt de UIAccessibility-API om informatie over elementen te verkrijgen en ondersteunt de rotor voor het schakelen van navigatiemodi. VoiceOver is geïntegreerd met iCloud (instellingen worden gesynchroniseerd tussen apparaten), Apple Pay (betalingsbevestiging via Touch ID of Face ID) en dynamische tekst (lettertype past zich aan gebruikersinstellingen aan).

VoiceOver-gebaren verschillen van TalkBack: er wordt gebruikgemaakt van rotatie met twee vingers (rotor), drievoudig tikken voor Screen Curtain en dubbel tikken met twee vingers om een actie te annuleren. VoiceOver ondersteunt aangepaste rotors, die de ontwikkelaar toevoegt via UIAccessibilityCustomRotor — bijvoorbeeld voor snelle navigatie door secties van de app, waarbij de standaardvolgorde wordt omzeild.

TalkBack (Android)

TalkBack — de schermlezer van Google, onderdeel van Android Accessibility Suite. Het gebruikt AccessibilityService en AccessibilityNodeInfo voor toegang tot de interface. TalkBack ondersteunt een globaal menu via L-vormig vegen, aangepaste acties voor elementen en LiveRegion voor dynamische updates. Vanaf Android 14 kreeg TalkBack ondersteuning voor eenhandige gebaren en verbeterde integratie met Google Assistant.

TalkBack heeft een flexibeler gebarensysteem dan VoiceOver: de gebruiker kan vrijwel elk gebaar aan elke actie toewijzen. TalkBack ondersteunt ook braille-invoer op het scherm (BrailleBack) — de gebruiker voert tekst in met braillekarakters direct op het touchscreen in een speciale 3×2-lay-out voor elke vinger, wat het typen aanzienlijk versnelt in vergelijking met het schermtoetsenbord.

Naast VoiceOver en TalkBack zijn er minder gangbare mobiele schermlezers: Select to Speak (Android, uitspreken van geselecteerd gebied), Samsung Voice Assistant (vervanging voor TalkBack op Samsung-apparaten met One UI) en third-party oplossingen voor specifieke niches — bijvoorbeeld voor gebruikers van Chinese smartphones zonder Google-diensten.

Hoe Screen Reader met de app interageert

Screen Reader heeft geen directe toegang tot de UI-componenten van de app. In plaats daarvan werkt het via een tussenlaag — de toegankelijkheids-API van het besturingssysteem. Het besturingssysteem bouwt de toegankelijkheidsboom (Accessibility Tree), die de schermlezer doorloopt en analyseert.

Accessibility Tree op iOS en Android

Op iOS wordt de toegankelijkheidsboom opgebouwd uit UIAccessibilityElement-objecten, die overeenkomen met elke View op het scherm. Elk element bevat label (hoofdtekst), traits (type element: knop, koptekst, link), hint (aanwijzing), value (huidige waarde voor schuifregelaars en indicatoren) en frame (aanraakgebied). Het systeem maakt automatisch elementen voor standaard UI-componenten, maar de ontwikkelaar kan ze toevoegen en configureren.

Op Android wordt de toegankelijkheidsboom opgebouwd uit AccessibilityNodeInfo-objecten. Elk knooppunt bevat: text (tekst of contentDescription), className (type element), contentDescription (beschrijving), stateDescription (status), isEnabled, isChecked, isClickable en andere vlaggen. Android ondersteunt ook AccessibilityAction — een lijst met acties die de schermlezer namens de gebruiker kan uitvoeren: klikken, lang indrukken, scrollen, focus instellen, tekst instellen.

Toegankelijkheidsgebeurtenissen (Accessibility Events)

Wanneer er een verandering in de interface plaatsvindt (nieuw element verschenen, tekst gewijzigd, element zichtbaar of onzichtbaar geworden), stuurt het besturingssysteem een AccessibilityEvent. De schermlezer is geabonneerd op deze gebeurtenissen en reageert erop: bijvoorbeeld wanneer een dialoogvenster verschijnt, verplaatst de schermlezer automatisch de focus naar de titel en spreekt de inhoud uit.

// Luisteren naar toegankelijkheidsgebeurtenissen op 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)
        }
    }
}

Op iOS worden soortgelijke gebeurtenissen afgehandeld via UIAccessibility.Notification: layoutChanged (lay-out gewijzigd), screenChanged (volledig nieuw scherm), announcement (willekeurige aankondiging), pageScrolled (pagina scrollen). De ontwikkelaar verzendt deze gebeurtenissen via UIAccessibility.post zodat de schermlezer correct reageert op wijzigingen. Bij het openen van een modaal venster moet bijvoorbeeld screenChanged met de nieuwe titel worden verzonden — anders blijft VoiceOver op het vorige element onder het venster staan.

App-ontwikkeling met het oog op Screen Reader

Het creëren van een toegankelijke app gaat niet alleen over het toevoegen van contentDescription aan elk element, maar over het doordenken van de gebruikerservaring voor niet-visuele interactie. De basisregels zijn voor beide platforms hetzelfde, hoewel de implementatie verschilt.

Basisregels voor toegankelijkheid

Alle interactieve elementen moeten een zinvolle beschrijving hebben: de knop „Verzenden" moet worden beschreven als „Bericht verzenden", niet als „Knop". Decoratieve elementen (scheidingstekens, achtergrondafbeeldingen, pictogrammen zonder functionaliteit) moeten worden verborgen voor de schermlezer. De navigatievolgorde moet overeenkomen met de logische stroom van het scherm, niet met de visuele indeling. Het tekstcontrast moet minimaal 4.5:1 zijn voor hoofdtekst en 3:1 voor grote tekst (WCAG AA).

// iOS: correcte configuratie voor een complex element
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Geluidsvolume"
customControl.accessibilityValue = "75 procent"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Verhoogt of verlaagt het volume"

// Bijwerken bij waardewijziging
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) procent"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Op iOS schakelt de vlag isAccessibilityElement de VoiceOver-ondersteuning in voor aangepaste elementen. De combinatie van traits (.adjustable + .button) informeert VoiceOver dat het element kan worden aangepast door omhoog/omlaag te vegen en kan worden geactiveerd door dubbel te tikken. Na het wijzigen van de waarde wordt verplicht een layoutChanged-melding verzonden — anders blijft VoiceOver de oude waarde uitspreken.

Specifieke aanbevelingen voor beide platforms

Voor iOS: gebruik accessibilityElements om de leesvolgorde te overschrijven, accessibilityCustomActions voor extra acties in het contextmenu en shouldGroupAccessibilityChildren om elementen te groeperen in logische groepen. Gebruik voor SwiftUI de modifiers .accessibilityLabel(), .accessibilityAddTraits() en .accessibilityRespondsToUserInteraction(). Vermijd het gebruik van isAccessibilityElement = false op containers met interactieve onderliggende elementen — dit verbergt ze voor VoiceOver.

Voor Android: gebruik accessibilityTraversalBefore en accessibilityTraversalAfter voor de navigatievolgorde, AccessibilityDelegate voor aangepaste elementen en LiveRegion (polite/assertive) voor dynamische updates. Gebruik in Compose de modifier .semantics {} met contentDescription, stateDescription en customActions. Vermijd het gebruik van focusable = true op niet-interactieve elementen — dit creëert valse focuspunten voor TalkBack en verwart de gebruiker.

Testtools

Testen met een schermlezer is verplicht op een fysiek apparaat. De emulator/simulator geeft een basisidee, maar gebaren en responstijd verschillen. Gebruik Accessibility Inspector (Xcode) voor iOS en Accessibility Scanner voor Android voor het automatisch vinden van problemen.

De belangrijkste testscenario's: registratie (formulier invullen, valideren, verzenden), zoeken en navigeren door de catalogus, bestellen, wachtwoordherstel. Elk scenario moet uitvoerbaar zijn zonder visuele controle — alleen via spraakaanwijzingen van de schermlezer. Als een gebruiker van een schermlezer het scenario niet in dezelfde tijd kan voltooien als een gewone gebruiker (±50%), — vereist de app een toegankelijkheidsverbetering.