Text-to-speech versus screenreaders

Uw content heeft een stem

Text-to-speech (TTS) zet geschreven informatie om in audio. Het helpt mensen met blindheid, slechtziendheid, dyslexie en ADHD om content te verwerken op een manier die voor hen werkt. TTS wordt ook veel gebruikt op scholen, door taalleerders en door professionals die met het oor in plaats van met het oog proeflezen.

Omdat zowel TTS als screenreaders een synthetische stem produceren, gaan mensen er vaak van uit dat het hetzelfde is — of dat het toevoegen van een “voorleesknop” aan een website die toegankelijk maakt voor blinde gebruikers. Die aanname is onjuist, en ernaar handelen kan u opzadelen met een site die toegankelijk klinkt maar voor veel mensen onmogelijk daadwerkelijk te gebruiken is. Dit artikel legt uit hoe elke technologie werkt, wie erop vertrouwt, waar de grens tussen beide echt ligt en wat er nodig is om goed voor screenreaders te bouwen. Als u maar één ding onthoudt, laat het dan dit zijn: een voorleeswidget is een gemaksfunctie, geen toegankelijkheidsfunctie.

Hoe werkt TTS?

TTS verwerkt tekst in drie globale fasen:

Tekstanalyse — het bepalen van toon, grammatica en structuur, het uitschrijven van getallen en symbolen (“$5” wordt “vijf dollar”) en het opsplitsen van zinnen.
Linguïstische verwerking — het berekenen van uitspraak, klemtoon en nadruk, vaak met behulp van een uitspraakwoordenboek plus regels voor onbekende woorden.
Audiosynthese — het genereren van spraak op basis van wiskundige stemmodellen, in toenemende mate met neurale netwerken die veel natuurlijker klinken dan oudere concatenatieve engines.

Moderne systemen bieden stemaanpassing zoals snelheid, toonhoogte, stempersona en taalkeuze. Het cruciale punt is wat TTS als invoer neemt: een blok tekst dat iemand al heeft geselecteerd, geplakt of aangewezen. TTS is fundamenteel een content-out-technologie. Het spreekt uit wat het krijgt. Het verkent geen interface en heeft geen besef van knoppen, formuliervelden of paginastructuur.

Wat zijn de beperkingen van TTS-technologie?

TTS is echt nuttig, maar het is niet perfect, en de beperkingen ervan zijn van belang voor de vergelijking die volgt:

Uitspraakhiaten — het kan ongebruikelijke woorden, eigennamen, medische of juridische termen en afkortingen verkeerd uitspreken.
Ongelijke taalondersteuning — veel tools verwerken gangbare talen goed, maar worstelen met minder voorkomende talen en regionale dialecten.
Toon en nuance — TTS heeft moeite met sarcasme, humor en idiomatische uitdrukkingen, waardoor content met de verkeerde toon kan worden overgebracht.
Geen interactiemodel — en dit is de belangrijkste: TTS leest; het laat u niets doen. U kunt geen afrekenformulier invullen, een modaal venster sluiten of tussen menu-items wisselen met alleen TTS.

Die laatste beperking is precies waar de verwarring met screenreaders begint.

Wat is het verschil tussen text-to-speech en screenreader-technologie?

Hier ontstaat het veelvoorkomende misverstand. Text-to-speech leest tekst hardop voor — dat is de primaire functie. Een screenreader doet veel meer: hij stelt gebruikers in staat om een hele computer of mobiel apparaat te bedienen en erdoorheen te navigeren met het oor en het toetsenbord (of aanraakgebaren).

Screenreaders kondigen interfacelabels, formuliervelden, knoppen en links aan; ze lezen de alternatieve tekst bij afbeeldingen voor zodat gebruikers visuele content begrijpen; en ze maken de status van componenten zichtbaar — of een selectievakje is aangevinkt, een menu is uitgeklapt, een tabblad is geselecteerd of er een foutmelding is verschenen. Ze zetten een visuele, muisgestuurde interface om in een lineaire, hoorbare, bedienbare interface.

Een snelle manier om het verschil te voelen: TTS beantwoordt de vraag “Wat staat er in deze alinea?” Een screenreader beantwoordt “Waar ben ik, wat kan ik hier doen en wat is er net gebeurd?” Het eerste gaat over het verwerken van content. Het tweede gaat over het bedienen van software.

Hoe een screenreadergebruiker zich daadwerkelijk door een pagina beweegt

Ziende gebruikers scannen een pagina in enkele seconden. Een screenreadergebruiker bouwt sequentieel een mentaal model op en vertrouwt op structuur om efficiënt te navigeren. In de praktijk doen ze het volgende:

Tussen koppen springen om de paginaopbouw te begrijpen (daarom is een correcte koppenhiërarchie zo belangrijk).
Een lijst van alle links of alle formuliervelden opvragen om per oriëntatiepunt te navigeren in plaats van van boven naar beneden te lezen.
Oriëntatiegebieden (banner, navigatie, hoofdinhoud, voettekst) gebruiken om meteen naar de gewenste content te springen.
Door interactieve elementen bewegen met de Tab-toets en verwachten dat de focus ergens zichtbaar en logisch landt.
Luisteren naar live-aankondigingen wanneer er iets verandert zonder een volledige herlading van de pagina.

Niets hiervan werkt tenzij de onderliggende markup de pagina eerlijk beschrijft. Een “voorlees”-functie biedt geen van deze navigatiemogelijkheden — het vertelt slechts welke tekst op het scherm staat, in visuele volgorde, zonder mogelijkheid om de besturingselementen te bedienen.

Wie elk gebruikt, en waarom dat ertoe doet

TTS wordt gebruikt door een breed publiek, vaak situationeel: mensen met dyslexie, ADHD of slechtziendheid; multitaskers; taalleerders; en iedereen die simpelweg liever luistert. De meeste van deze gebruikers kunnen het scherm nog steeds zien en een muis gebruiken.

Screenreadergebruikers zijn onder meer mensen die blind zijn of een ernstige visuele beperking hebben, evenals sommige mensen met cognitieve of motorische beperkingen, die van de technologie afhankelijk zijn om een apparaat überhaupt te kunnen gebruiken. Voor hen is het geen voorkeurslaag bovenop een bruikbare interface — het is de interface. De meest voorkomende tools zijn NVDA en JAWS op Windows, VoiceOver op Apple-apparaten en TalkBack op Android. Elk interpreteert dezelfde webpagina iets anders, wat een van de redenen is waarom testen op alle tools van belang is.

Waarom voorleeswidgets geen vervanging voor toegankelijkheid zijn

Een groeiend aantal websites plakt er een “luister naar deze pagina”-knop op of een widget van derden die tekst markeert en uitspreekt. Deze tools kunnen sommige lezers helpen, en er is niets mis met het aanbieden ervan als gemak. Het probleem is dat het wordt behandeld als een vervanging voor echte screenreaderondersteuning. Dat is het niet, om verschillende concrete redenen.

Ze lezen alleen; ze bedienen niet. Een voorleeswidget zal uw prijstabel voorlezen, maar het kan een blinde gebruiker niet een abonnement laten kiezen, de winkelwagen openen, betaalgegevens invoeren en de aankoop afronden. Echte taken vereisen bedienbare besturingselementen, geen verhaal.
Ze kunnen status of rollen niet zichtbaar maken. Of een knop is ingedrukt, een veld verplicht is, een sectie is ingeklapt of er net een foutmelding is verschenen — niets daarvan wordt overgebracht door zichtbare tekst voor te lezen. Screenreaders vertrouwen op rollen, namen en statussen in de markup om dit aan te kondigen.
Screenreadergebruikers hebben al een tool. Blinde gebruikers nemen hun eigen screenreader mee, fijn afgestemd op hun voorkeuren en spiergeheugen. Een widget op paginaniveau concurreert ermee, verstoort het soms en doet niets om de gebrekkige markup waar hun screenreader op vastloopt te herstellen.
Ze maskeren problemen in plaats van ze op te lossen. Als een formulierveld geen label heeft, slaat de widget het net zo over als een screenreader zou doen — maar nu is het ontbrekende label verborgen achter een functie die behulpzaam lijkt. Het onderliggende defect blijft bestaan.

Diezelfde logica geldt, zelfs nog sterker, voor zogenaamde toegankelijkheidsoverlays — scripts die directe naleving beloven door geautomatiseerde fixes en een werkbalk over een bestaande site heen te leggen. Ze repareren de onderliggende code niet, ze conflicteren vaak met de eigen hulptechnologie van gebruikers, en ze kunnen geen echte conformiteit leveren. De betrouwbare weg is het herstellen van de bron. Voor een uitgebreidere uitleg van waarom oppervlakkige fixes tekortschieten, zie onze gids over echte digitale toegankelijkheid.

Een concreet voorbeeld: de afrekenpagina die “praat”

Stel u een online winkel voor die een voorleeswidget heeft toegevoegd en ervan overtuigd is dat de site nu toegankelijk is. Een blinde klant komt binnen met zijn eigen screenreader draaiend. De productbeschrijving wordt prima voorgelezen — dat deel is gewoon tekst. Maar de “Toevoegen aan winkelwagen”-bediening is een gestylede div met een klikhandler in plaats van een echte knop, dus de screenreader kondigt hem nooit als knop aan en het toetsenbord kan hem niet bereiken. De aantalkiezer werkt een totaal bij zonder live-regio, dus de wijziging is stil. Het kortingscodeveld heeft tijdelijke tekst maar geen bijbehorend label, dus het wordt alleen aangekondigd als “tekst bewerken”. Het verzendformulier toont visueel een rode fout, maar de fout is niet aan het veld gekoppeld en wordt helemaal niet aangekondigd. De voorleeswidget vertelt vrolijk de zichtbare tekst en verandert hier niets aan. De klant kan de marketingtekst horen, maar kan geen aankoop voltooien. Die kloof — tussen content horen en een product bedienen — is het volledige verschil tussen een gemaksfunctie en toegankelijkheid.

Wat het daadwerkelijk vergt om voor screenreaders te bouwen

Screenreaders ondersteunen gaat niet over het toevoegen van een functie — het gaat over het zo bouwen van uw pagina’s dat betekenis, structuur en gedrag beschikbaar zijn voor software, niet alleen voor het menselijk oog. De kerningrediënten:

Semantische, gestructureerde HTML

Gebruik echte koppen (h1–h6) in een logische volgorde, native knoppen en links voor de juiste doeleinden, lijsten voor lijsten en oriëntatie-elementen voor paginagebieden. Semantische HTML draagt toegankelijkheidsinformatie gratis met zich mee; een muur van generieke containers draagt niets.

Tekstalternatieven voor niet-tekstuele content

Elke betekenisvolle afbeelding heeft accurate alternatieve tekst nodig, en decoratieve afbeeldingen moeten zo worden gemarkeerd dat ze worden overgeslagen. Pictogrammen die als knoppen fungeren, hebben toegankelijke namen nodig. Grafieken en infographics hebben een tekstueel equivalent nodig dat dezelfde informatie overbrengt.

Toegankelijke namen, rollen en statussen

Formuliervelden hebben programmatisch gekoppelde labels nodig. Aangepaste componenten — tabbladen, accordeons, comboboxen, modale vensters — hebben de juiste rollen en statussen nodig zodat de screenreader aankondigt wat ze zijn en hoe ze zich gedragen. Waar native HTML niet voldoende is, vult ARIA het gat op, maar het moet nauwkeurig worden gebruikt; onjuiste ARIA is erger dan geen.

Bedienbaarheid met het toetsenbord en focusbeheer

Alles wat met een muis werkt, moet met een toetsenbord werken, de focusvolgorde moet logisch zijn, de focusindicator moet zichtbaar zijn, en dynamische wijzigingen (een dialoogvenster openen, een fout onthullen) moeten de focus op de juiste manier verplaatsen of aankondigen. Toetsenbordondersteuning en screenreaderondersteuning zijn diep met elkaar verweven.

Dynamische wijzigingen aankondigen

Wanneer content wordt bijgewerkt zonder een herlading van de pagina — een formuliervalidatiebericht, een winkelwagenteller, een laadstatus — gebruik dan live-regio’s zodat de screenreader de gebruiker vertelt dat er iets is gebeurd. Stille updates zijn onzichtbaar voor mensen die het scherm niet kunnen zien.

Al deze verwachtingen zijn vastgelegd in de WCAG 2.2-succescriteria, die de technische ruggengraat vormen van de European Accessibility Act en de ADA zoals toegepast op het web. Wilt u de praktische details, dan loopt onze gids voor screenreadertesten stap voor stap door hoe u elk van deze gedragingen met echte tools verifieert.

Waarom “voor mij wordt het prima voorgelezen” misleidend is

Een ziende ontwikkelaar kan een voorleesfunctie inschakelen, nette zinnen horen en concluderen dat de pagina toegankelijk is. De valkuil is dat voorlezen de zichtbare leesvolgorde en de zichtbare tekst reproduceert, die beide al logisch zijn voor iemand die naar het scherm kijkt. Het zegt niets over de vraag of een aangepaste dropdown zijn opties aankondigt, of de focus opgesloten zit in een geopend dialoogvenster, of een knop met alleen een pictogram een naam heeft, of de tabvolgorde overeenkomt met de visuele lay-out. Dat zijn precies de dingen die kapot gaan voor screenreadergebruikers en precies de dingen die een voorleesdemo niet kan onthullen. De enige manier om het te weten is testen zoals de echte gebruikers dat doen.

Hoe u voor beide test — en waarom automatisering alleen niet genoeg is

U kunt niet bevestigen dat een pagina werkt voor screenreadergebruikers door naar een voorleesknop te luisteren. U bevestigt het door structuur, namen, rollen, statussen, toetsenbordbediening en de daadwerkelijke screenreaderervaring te controleren over meerdere tools en platforms.

Een degelijk proces combineert drie lagen:

Geautomatiseerd scannen om de grootschalige, machinaal detecteerbare problemen op te sporen — ontbrekende alt-tekst, lege labels, gebroken ARIA-verwijzingen, contrastfouten. Onze toegankelijkheidsscansoftware en een gratis toegankelijkheidsscan zijn een snelle manier om vast te stellen waar u staat.
Handmatig testen door experts om alles te beoordelen wat automatisering niet kan inschatten: of een naam betekenisvol is, of de focusvolgorde logisch is, of een aangepaste widget echt bedienbaar is. De redenering achter deze laag wordt behandeld in onze gids voor handmatige toegankelijkheidsaudits.
Testen met echte hulptechnologie en echte gebruikers. Niets vervangt het bedienen van de pagina met NVDA, JAWS, VoiceOver en TalkBack — en, idealiter, het observeren van mensen die deze tools dagelijks gebruiken. Onze audits door mensen met een beperking brengen precies die geleefde expertise.

Geautomatiseerde tools detecteren doorgaans slechts een deel van de WCAG 2.2-succescriteria; de rest vereist menselijk oordeel. Een geslaagde geautomatiseerde scan als bewijs van toegankelijkheid behandelen is dezelfde categorie fout als een voorleeswidget als screenreaderondersteuning behandelen.

Waar QualiBooth past

QualiBooth test uw website tegen zowel TTS- als screenreader-gebruiksscenario’s, zodat uw content toegankelijk is voor gebruikers die op een van beide technologieën vertrouwen — en zodat de mensen die afhankelijk zijn van een screenreader uw content niet alleen kunnen horen maar uw product daadwerkelijk kunnen bedienen. Onze toegankelijkheidstoolkit en het Agora-platform combineren scannen met gestructureerde handmatige beoordeling, en ons team voor toegankelijkheidsadvies helpt u te verhelpen wat de tests aan het licht brengen en aan te sluiten op de eisen van WCAG 2.2, EAA en ADA.

De conclusie is eenvoudig. Een stem aan uw content toevoegen is een mooie toevoeging. Uw content navigeerbaar, bedienbaar en correct aangekondigd maken voor een screenreader is toegankelijkheid — en slechts één daarvan voldoet aan de wet en aan de mensen die zij beschermt.