Voice agents en WCAG 2.2 AA: acht stille hoorfouten

Het is 14:00 op een dinsdag bij een middelgrote Nederlandse gemeente. De inkoper heeft jouw voice-agent demo open in het ene tabblad en de accessibility-vragenlijst van de tweede ronde in het andere. Ze is geen accessibility-specialist. Ze heeft een checklist die mapt op EN 301 549 en de gewoonte om "laat eens zien" te vragen zodra een leverancier "ja" invult in een compliance-vakje.

Op dat tabbladduo verliezen de meeste voice-agent pilots stilletjes. De agent werkt prima voor de horende beller in het demoscript. Hij breekt ook WCAG 2.2 AA voor de slechthorende beller, op manieren die onzichtbaar zijn totdat iemand een vraag stelt.

Dit is een veldgids voor de acht faalpunten die we het vaakst zien, op volgorde van welke zij als eerste eruit pikt.

1. Geen live transcript op een oppervlak dat de beller kan bereiken

Het meest voorkomende faalpunt is ook het goedkoopst om te vinden. De reviewer vraagt: "laat zien waar het live transcript verschijnt." Als jouw antwoord is "we hebben er een, hij staat in ons interne monitoring-dashboard," krijgt het volgende vakje een rood streepje.

WCAG 2.2 op zichzelf verplicht geen live captioning voor een telefoongesprek. EN 301 549 clause 6.2.2.1 verplicht real-time text capability voor tweerichtings-spraakdiensten die binnen scope vallen, en het Nederlandse overheidsregister leunt erop als operationele toets. Een slechthorende beller moet kunnen zien wat de agent zegt, in iets dat tegen real time aan ligt, op een oppervlak dat ze ook echt kunnen bereiken. Een intern dashboard telt niet. Een WhatsApp- of webcompanion-weergave wel.

De goedkoopste fix die we hebben gebouwd is een korte link, per SMS verstuurd aan het begin van het gesprek, die een webview opent waarin de tekst van de agent via server-sent events binnenstroomt. Round-trip latency van token naar scherm zit onder de 400ms.

2. Audio-only eenmalige verificatiecodes

Dit faalt WCAG 2.2 success criterion 3.3.8, Accessible Authentication (Minimum) op de schoonst mogelijke manier, en het is het faalpunt dat je security-team het langst zal verdedigen.

Het patroon: de beller verifieert zijn identiteit door een 6-cijferige code te herhalen die de agent voorleest. Als de beller de code niet kan horen, kan hij niet authenticeren. Er is geen cognitive-function-test uitzondering die dit redt, want de toets is gehoor, niet cognitie.

De fix is structureel. Lever de code via een kanaal dat de beller al heeft aangewezen. SMS, e-mail, een geauthenticeerde app, of een webview gekoppeld aan de call session. "We kunnen op verzoek terugvallen op SMS" leest slechter op een vragenlijst dan "de beller kiest zijn voorkeurkanaal tijdens de IVR-opener."

3. Geen handoff naar Teletolk of een andere text-relay dienst

In Nederland is de aangewezen relay-dienst voor d/Dove en slechthorende bellers KPN Teletolk. Inkopers kennen de naam. Ze vragen of de agent een binnenkomend Teletolk-gesprek kan aannemen, en wat er met de gesprekstoestand gebeurt zodra een menselijke relay-operator op de lijn komt.

Het eerlijke antwoord voor de meeste huidige voice agents is "de agent behandelt de relay-operator als beller, wat betekent dat de stem van de operator wordt getranscribeerd, de getypte input van de beller nooit bij de agent aankomt, en de loop halverwege breekt." Dit is op zichzelf geen WCAG-criterium. Het is de operationele consequentie van het tegelijk falen op meerdere: 2.2.1 Timing Adjustable, 3.3.1 Error Identification, en de RTT-clausules van EN 301 549.

Het minimaal acceptabele antwoord is: detecteer dat er een relay op de lijn zit, verlaag het tempo van de agent, verleng elke timeout, en bied aan om door te schakelen naar een menselijke wachtrij. Het betere antwoord is een eigen tekstkanaal dat de relay-operator direct kan bedienen, met een sessietoken dat hun getypte input koppelt aan dezelfde gespreksgeschiedenis die een sprekende beller zou hebben opgebouwd.

4. Timeouts alleen gekalibreerd voor horende bellers

Een standaard voice agent geeft de beller vijf tot zeven seconden stilte voordat hij opnieuw prompt. Voor een beller die een relay-dienst gebruikt is dat raam al voorbij voordat de operator de prompt klaar heeft getypt.

Dit is WCAG 2.2 success criterion 2.2.1, Timing Adjustable. Het criterium eist dat een gebruiker elke tijdslimiet die niet essentieel is, kan uitschakelen, aanpassen of verlengen. Een herhalings-window is niet essentieel. Het is UX-comfort.

De goedkope fix is een turn-by-turn flag. Als de sessie is geopend via een relay-nummer, of als de beller in de IVR-opener expliciet zei "ik gebruik een relay-dienst," wordt elke timeout in de dialoogboom maal drie. Hardcode dit. Vertrouw er niet op dat het model het onthoudt.

def reprompt_timeout(session):
    base_seconds = 6.0
    if session.relay_detected or session.caller_declared_relay:
        return base_seconds * 3
    if session.caller_requested_slow:
        return base_seconds * 2
    return base_seconds

5. Bevestigingspaden die alleen een gesproken "ja" accepteren

De agent zegt: "Ik ga zo de afspraak boeken voor donderdag om 10. Zeg ja om te bevestigen." Een slechthorende beller via een relay kan het woord niet zo uitspreken dat de speech-to-text laag het als bevestiging herkent. Een beller die wel kan horen maar niet helder kan spreken heeft hetzelfde probleem.

Dit stapelt op criterium 3.3.4 (Error Prevention) bij transactionele flows. De boeking is in theorie omkeerbaar, maar de beller heeft ook geen manier om die omkering te bevestigen.

Elke bevestigingsstap heeft minstens één niet-spraakpad nodig. DTMF (toets 1) is het saaie, juiste antwoord. Een web confirm-knop op de companion-view is beter. Beide tegelijk, met de agent die de optie benoemt, is de versie die op de vragenlijst de volle punten haalt.

6. Spraaktempo vastgezet op één default

Dit struikelt over success criterion 1.4.2, Audio Control in geest zo niet in letter. Een beller met licht gehoorverlies hoort vaak beter op 0.85x snelheid. Een beller met een cochleair implantaat dat is afgestemd op hogere frequenties heeft vaak liever een diepere stem.

Het minimum: een globaal "spreek langzamer" commando dat de agent in elke beurt herkent, plus een stemkeuzestap in de IVR-opener. Het "spreek langzamer" commando moet de SSML prosody rate aanpassen, niet de afspeelsnelheid van een vooraf gerenderd bestand, want voorgerenderd afspelen verslechtert juist de verstaanbaarheid in plaats van die te verbeteren.

7. Achtergrondmuziek of ambient prosody tijdens prompts

Wachtmuziek is prima. Muziek onder de prompts van de agent niet. Inkoop ziet dit niet uit de vragenlijst alleen. Ze vangen het de eerste keer dat ze een opgenomen sessie op 1.5x luisteren en horen dat de prompts moeilijker te volgen zijn dan de wachtmuziek.

Het relevante criterium is 1.4.7 (Low or No Background Audio), wat AAA is en niet strikt verplicht. De Nederlandse realiteit is dat publieke reviewers dit als zorgpunt markeren ongeacht het niveau. De fix is één regel in de voice config: zet het achtergrondbed uit tijdens prompt playback. Bewaar het ambient track voor de wachttoestand, waar het de beller ook echt helpt te weten dat de lijn nog leeft.

8. Geen transcript-artefact na het gesprek voor de beller

Het laatste faalpunt is degene die het gesprek overleeft. Een horende beller kan redelijk zeker zijn over wat de agent heeft afgesproken. Een slechthorende beller heeft niets om op terug te vallen.

WCAG 2.2 benoemt dit niet expliciet. De European Accessibility Act, van kracht sinds 28 juni 2025, behandelt artefacten na de transactie als deel van de toegankelijkheid van de dienst zelf. Een transcript dat binnen vijf minuten na ophangen naar de beller wordt gemaild, met een korte samenvatting en de vervolgactie, sluit de loop. Een link naar een webview die dezelfde inhoud 30 dagen vasthoudt doet hetzelfde.

Zet dit default-on. Maak de opt-out alleen mogelijk met expliciete toestemming van de beller binnen het gesprek. Het Nederlandse register controleert het.

Wat de vragenlijst in de tweede ronde echt vraagt

De vragenlijst verschilt per ministerie, maar de vorm is consistent. Er wordt gevraagd om elke in-scope feature te mappen op een EN 301 549 clausule, bewijs aan te leveren (een schermopname, een transcript-export, een config-snippet), en eventuele gedeeltelijke conformiteit te declareren. Er wordt niet gevraagd "bent u WCAG-compliant." Die formulering is uit modern Nederlands aanbestedingstaalgebruik verdwenen omdat hij nutteloze antwoorden oplevert.

Het nuttigste dat je voor inzending kunt doen is een gesimuleerd gesprek van vijf minuten opnemen waarin de beller op Teletolk zit. Bekijk dat terug met de vragenlijst open. De faalpunten die jij ziet, zijn de punten die de reviewer ook ziet. Los die eerst op, en neem dan opnieuw op.

De bedrading die we uiteindelijk hebben gehouden

Toen we afgelopen kwartaal een voice agent bouwden voor een Nederlandse verzekeraar, was het ding waar we steeds tegenaan liepen punt 3 hierboven. De relay-handoff brak elke keer de gesprekstoestand. We hebben het opgelost door de relay-operator als een geprivilegieerd kanaal te behandelen met een eigen tempo-config, en door de intent van de agent terug te schrijven naar een webview die de beller live kon volgen. Die webview functioneerde tegelijk als oppervlak voor punten 1, 5 en 8. Wil je zien hoe die bedrading eruitziet, dan staat de architectuur beschreven onder AI-agents.

De audit van vijf minuten die je vandaag kunt doen: pak een van je live voice flows, neem een sessie op waarin de beller nooit spreekt (alleen typt via een relay-simulator of een collega aan een toetsenbord), en luister terug met de acht punten hierboven op een Post-it. Het eerste faalpunt dat je hoort is degene die deze week aan de beurt is.