Een antwoord groeit woord voor woord. Voor ziende mensen ziet dat eruit als voortgang. Als elk fragment meteen wordt voorgelezen, kan dezelfde uitvoer tot voortdurende onderbrekingen leiden. De vraag is daarom niet of een wijziging technisch zichtbaar is, maar welke informatie iemand op dat moment nodig heeft.
In succescriterium 4.1.3 behandelt WCAG 2.2 statusberichten, die programmatisch bepaalbaar moeten zijn zonder focuswijziging. De toelichting van het W3C noemt ook het vermijden van onnodige onderbrekingen. Dit impliceert geen algemene verplichting om elk nieuw gegenereerd woord afzonderlijk aan te kondigen. Voor een AI-chat is het vooral nuttig om de werkstatus te scheiden van de inhoud van het antwoord.
Drie statussen in plaats van een eindeloze aankondiging
Ons eigen demonstratiemodel kent drie begrijpelijke situaties: verzoek ontvangen, antwoord wordt gegenereerd, antwoord voltooid. Ze bieden oriëntatie over het proces. De antwoordtekst zelf beantwoordt de inhoudelijke vraag en moet daarna in iemands eigen tempo leesbaar blijven.
Tijdens het wachten kan iemand teruggaan naar het eigen invoerveld of andere delen van de pagina lezen. De interface mag deze activiteit niet opzijschuiven alleen omdat er weer een stuk tekst is binnengekomen. Een voltooid antwoord hoeft ook niet automatisch de toetsenbordfocus over te nemen.
De passende feedback hangt af van de status. Een proces dat nog loopt, is iets anders dan een fout die een nieuwe beslissing vereist. Als alle meldingen als even dringend worden gepresenteerd, verdwijnt juist deze prioriteit.
Een klein HTML-patroon scheidt inhoud en status
Het volgende fragment is van onszelf en bevat geen AI-koppeling. Het toont alleen twee gebieden met verschillende taken. Het antwoordgebied bevat de tekst die later gelezen kan worden. De korte statusregel geeft de huidige status door.
<section aria-labelledby="answer-title">
<h2 id="answer-title">Answer</h2>
<div id="answer"></div>
</section>
<p id="answer-status" role="status" aria-atomic="true"></p>De W3C-techniek ARIA22 beschrijft role=status met een beleefde live region en een aankondiging van de volledige statusinhoud. Onze expliciete aria-atomic maakt deze bedoeling zichtbaar in het lesfragment. Het is geen reden om de hele, voortdurend groeiende antwoordtekst in hetzelfde korte statusbericht te zetten.
Een echte implementatie zou de statusregel bijwerken bij betekenisvolle overgangen, bijvoorbeeld één keer bij de start en één keer na volledige voltooiing. Hoe vaak een voortgangsmelding daartussen echt helpt, moet worden getest met de specifieke flow en met hulptechnologie.
Denk bij het controleren op gehoor ook aan iemand die al ergens anders aan het lezen is terwijl het antwoord wordt gegenereerd. Moet die steeds opnieuw aan de zin beginnen? Kan die het voltooide antwoord later bewust terugvinden? Deze observaties testen het gebruik van het patroon nauwkeuriger dan alleen vaststellen dat er ergens een aankondiging te horen is.
Annulering en fouten hebben eigen woorden nodig
Als de uitvoer wordt onderbroken, mag „klaar” niet zomaar betekenen dat er geen tekens meer binnenkomen. Een tekst die bewust is gestopt, kan onvolledig zijn. Een technische fout kan betekenen dat er helemaal geen bruikbaar resultaat is ontstaan. Deze verschillen horen thuis in de taal van de interface.
Voor een eerste controle kun je drie vaste voorbeeldteksten gebruiken en de overgangen handmatig activeren. Let op wat er wordt aangekondigd terwijl je doorleest, of de focus blijft waar hij is en hoe je bij de voltooide tekst komt. Dit is een oefening die je kunt uitvoeren, maar ze wordt hier niet gepresenteerd als een geslaagde screenreadertest.
Als je je eigen HTML en JavaScript voorbereidt in een KENJTEC-pagina, is daarvoor de ontwikkelaarsmodus van KENJTEC WebSiteBuilder ai beschikbaar, met een gesandboxte preview en het publiceren van je eigen code. Je zet de component zelf over; hierdoor ontstaat geen extra, geïntegreerde AI-chatdienst.
De echte luisterervaring is doorslaggevend
Een screenshot kan geen onderbreking en ook geen onverwachte aankondiging bewijzen. Testen vereist daarom een toetsenbord en echte hulptechnologie. Noteer het gebruikte apparaat, de browser en de screenreader als je later over een specifiek resultaat rapporteert.
Zelfs een goed statuspatroon voldoet niet automatisch aan elke eis voor een toegankelijke chat. Het beantwoordt een beperkte vraag: hoe wordt de werkstatus begrijpelijk zonder iemand de inhoud woord voor woord op te dringen? Een goede oplossing behoudt beide: betrouwbare oriëntatie en iemands controle over het eigen leestempo.
Bronnen en status
Onderzoek en documentatie, stand per 25 oktober 2026. Understanding SC 4.1.3: Status Messages · ARIA22: Using role=status to present status messages.
