Generatieve AI en schermlezer-prompts: een ontwerpdiscipline neemt vorm aan

Afbeeldingsomschrijving: Een smartphone op een houten bureau met een AI-chatinterface en koptelefoon ingeplugd — het visuele kenteken voor schermlezer-vriendelijk AI-promptontwerp.

Leestijd: 9 minuten

De afgelopen achttien maanden heeft zich binnen de toegankelijkheidsgemeenschap een nieuwe ontwerpdiscipline afgetekend die nog geen vaste naam heeft. Sommige teams noemen het “AT-bewuste promptengineering”; anderen spreken van “schermlezervormige systeemprompts”; de beoefenaars die zijn opgeleid in spraak-UI-ontwerp neigen naar “de spraakuitvoerlaag van een LLM.” Wat de naam ook is, het vakgebied is hetzelfde: het schrijven van systeemprompts en uitvoervormingsregels die generatieve AI-assistenten — ChatGPT, Claude, Gemini, Copilot, Be My AI — bruikbaar maken voor de circa 253 miljoen mensen wereldwijd die die producten bereiken via een schermlezer.

Het probleem is concreet en de faalvorm is luidruchtig. Een LLM getraind op het publieke web produceert standaard proza versierd met koppeltekens, geneste markdown-lijsten, codefences, koppen die alleen bestaan omdat het model vond dat het antwoord “gestructureerd” was, en decoratieve emoji. Voorgelezen door NVDA, JAWS, VoiceOver of TalkBack wordt die uitvoer een stroom van “streepje streepje”-tussenwerpsels, “opsommingsteken opsommingsteken opsommingsteken”-opsommingen zonder enig idee waar het ene item eindigt, “kop niveau twee”-aankondigingen die een zin onderbreken, en emoji-naamstrings (“lachend gezicht met zonnebril”) tussen elke twee zinsdelen. De informatie zit er wel in. De gebruiker kan ze niet extraheren zonder driemaal terug te spoelen. Dit stuk is een primer over wat de discipline vraagt van modelbouwers, wat de producten tot nu toe hebben geleverd en de openstaande UX-problemen die nog niemand heeft opgelost.

De nieuwe discipline — wat zij concreet inhoudt

Schermlezer-bewust promptontwerp is geen enkelvoudige regel. Het is een kleine verzameling beperkingen die samen uitvoer produceren die een synthesizer begrijpelijk kan uitspreken en waardoorheen een schermlezer-navigatietoets kan bewegen. De beperkingen vallen uiteen in vier categorieën.

Beknopte antwoorden met semantische structuur. Standaard LLM-uitvoer is te lang voor gesproken levering — een antwoord van 600 woorden dat prima leest in de browser van een ziende gebruiker wordt een monoloog van vier minuten waarover de schermlezergebruiker niet kan scannen. De discipline vraagt om kortere antwoorden, maar nog belangrijker om gestructureerde kortere antwoorden: een openingszin van één zin waarop de gebruiker kan stoppen, gevolgd door structuur waardoorheen de schermlezer kan navigeren via kop of lijstitem.

Vermijd koppeltekens en andere interpunctie die synthesizers verkeerd uitspreken. Het gedachtestreepje, het halve streepje, de tussenhaak, de schuine streep als samenvoegend woord, het ASCII-art-scheidingsteken — al deze worden hardop gelezen als stilte, een letterlijk “streepje” of een verwarrende pauze die een zinsdeel middendoor breekt. De conventie die zich aftekent over de grote modellen heen is: geef de voorkeur aan de komma en de punt; gebruik de dubbele punt op de ene plek waar die echt zijn waarde bewijst; gebruik nooit gedachtestreepjes in antwoorden met een gesproken context; gebruik nooit ASCII-regels om secties te scheiden.

Declareer wat een lijst is, wat een kop is, wat code is. Gesynthetiseerde spraak heeft geen visuele hiërarchie. Een kop moet worden aangekondigd als “kop”, een lijst moet worden aangekondigd als “lijst met N items, item één”, code moet worden aangekondigd als “code”, en het model moet ofwel structuren uitvoeren die de schermlezer herkent (HTML, correcte markdown die het renderingoppervlak omzet naar ARIA) of de structuur zelf verbaal vertellen (“Hier zijn drie opties. Optie één: …”).

Geen markdown-soep. Markdown is prima als het renderingoppervlak het omzet naar semantische HTML. Markdown is vijandig wanneer het oppervlak de ruwe sterretjes en underscores weergeeft, omdat de schermlezer dan “sterretje sterretje” aankondigt voor elk vetgedrukt woord. De discipline is om de renderingcontext te detecteren — chat-UI met markdown-rendering versus terminal versus schermlezersgestuurde spraakinterface — en de uitvoer daar dienovereenkomstig op te vormen. Hetzelfde model moet verschillende oppervlakrepresentaties van hetzelfde antwoord produceren.

Wat schermlezers daadwerkelijk nodig hebben van AI

Om de bovenstaande beperkingen concreet te maken, is het nuttig te kijken naar het werkelijke gedrag van de vier schermlezer/besturingssysteem-combinaties die het veld domineren: JAWS op Windows, NVDA op Windows, VoiceOver op macOS en iOS, en TalkBack op Android. Ze zijn niet uitwisselbaar, en een prompt die uitstekende uitvoer produceert voor de ene, kan onleesbaar zijn op de andere.

Navigatie via kop. Alle vier de lezers bieden een kopnavigatietoets (H in JAWS en NVDA, Rotor in VoiceOver, de leesbesturingsschakelaar in TalkBack). Voor een lang AI-antwoord dat navigeerbaar is, moet het model echte semantische koppen uitvoeren — ofwel via een markdown-renderingpijplijn die converteert naar <h2>/<h3> met correcte niveaunesting, ofwel via de eigen gestructureerde-antwoord-API van het chatoppervlak. Een model dat zijn antwoord “structureert” door de eerste drie woorden van elke alinea vetgedrukt te maken, heeft iets geproduceerd dat er visueel gestructureerd uitziet en volledig vlak is voor een schermlezer.

Navigatie via lijst. Lijsten zijn nuttig in gesproken uitvoer juist omdat de schermlezer het aantal aankondigt (“lijst met zeven items”) en de gebruiker stap voor stap kan bewegen met de lijstitemnavigatietoets (I in NVDA, L in JAWS). Maar dit werkt alleen als de lijst een echte <ul> of <ol> is. Een “lijst” geproduceerd door opsommingstekens aan het begin van elke regel te plaatsen, zonder lijstwikkel, wordt gelezen als gewone proza met een onverklaard “zwarte cirkel” of “opsommingsteken”-tussenwerping op elke regel.

Overslaan per sectie. Uitgebreide AI-antwoorden — uitleg, vergelijkingen, code-en-commentaar, meerstapsinstructies — vereisen een manier voor de schermlezergebruiker om naar de sectie te springen die hem interesseert zonder door de inleiding te luisteren. Dit is het enige moeilijkste onderdeel om goed te ontwerpen, want het model moet een navigeerbare structuur produceren en het chatoppervlak moet die renderen op een manier die het besturingssysteem blootstelt aan de hulptechnologie, en de schermlezer moet zijn geconfigureerd om de kopnavigatietoets te gebruiken in dat oppervlak. Alle drie falen in de praktijk; gewoonlijk is het de middelste.

Uitspraakaanwijzingen. Synthetische stemmen struikelen over technische termen, afkortingen met gemengde letters, URL’s, code-identificatoren, wiskundige notatie en niet-Engelstalige namen. Een goed ontworpen model zal, voor antwoorden in schermlezerscontext, afkortingen bij eerste gebruik uitschrijven (“WCAG, de Richtlijnen voor toegankelijkheid van webcontent”), initialismen uitbreiden die de synthesizer niet kan uitspreken en vermijden rauwe URL’s in vloeiende proza in te sluiten waar de synth de schuine strepen hardop leest. Geen van de grote producten doet dit in 2026 consistent.

Hoe de producten ermee omgaan

Vanaf medio 2026 hebben de grote generatieve AI-producten zichtbaar verschillende posities ingenomen ten aanzien van schermlezer-bewuste uitvoer. Geen van hen heeft het volledig goed. De voortgang is sneller dan twaalf maanden geleden, maar de kloof tussen het beste en het slechtste is nog steeds groot.

ChatGPT (OpenAI). De webclient wordt nu geleverd met een schakelaar “beknopte modus” die standaardantwoorden verkort en markdown-decoratie vermindert. De spraakmodus die in 2024 werd geïntroduceerd — en in 2025 substantieel verbeterd — is het dichtst bij een schermlezer-native interface dat een groot product heeft gebracht, omdat hij de visuele chat volledig omzeilt en een gesproken antwoord levert met een stop-, replay- en “zeg dat nog eens”-gebaar. Met het veld voor aangepaste instructies kunnen schermlezergebruikers hun voorkeuren eenmalig opgeven en die in alle sessies laten gelden, wat de door de community aangenomen workaround is. De resterende hiaten: GPT-modellen zijn nog standaard gedachtestreepjes-zwaar tenzij anders geïnstrueerd, en het koopniveau dat in markdown wordt uitgestoten, mapt niet altijd schoon op ARIA in het chatoppervlak.

Claude (Anthropic). De systeempromptdiscipline van Claude heeft zich het dichtst bij de hierboven beschreven conventies bewogen. Het model is in 2026 merkbaar minder gedachtestreepjesgevoelig dan de GPT-lijn, geeft standaard kortere antwoorden en reageert goed op systeempromptinstructies als “u spreekt met een schermlezergebruiker; gebruik geen gedachtestreepjes, geef de voorkeur aan korte alinea’s en gebruik echte koppen of genummerde lijsten wanneer structuur nodig is.” Het Claude.ai-chatoppervlak rendert markdown naar semantische HTML met juiste kopniveaus, waardoor de kopnavigatietoets werkt. Spraakuitvoer via integraties van derden bestaat maar is minder ontwikkeld dan de first-party spraakmodus van ChatGPT.

Gemini (Google). Strakke integratie met TalkBack op Android is het structurele voordeel van Gemini; het model kan overdragen aan de schermlezer op besturingssysteemniveau via de toegankelijkheidsdiensten van Android op een manier die iOS- en webcompetitors niet kunnen. De stroom “Hé Google, vraag Gemini…” op toegankelijke Android-apparaten is voor sommige gebruikers de meest natuurlijke AI-plus-schermlezerervaring die beschikbaar is. De resterende hiaten: de webinterface versiert antwoorden nog te veel, de kophiërarchie in de webantwoorden van Gemini is inconsistent en het model is meer geneigd tot decoratieve emoji dan zijn concurrenten.

Be My AI (Be My Eyes plus OpenAI). Dit is het meest smal gerichte van de vier — een visuele-beschrijvingsassistent die GPT-4-klasse visiemodellen gebruikt om afbeeldingen en omgevingen te beschrijven voor blinde en slechtziende gebruikers. Het is ook het enige product in deze lijst dat vanaf dag één is ontworpen voor een schermlezergebruiker als primaire doelgroep. Het promptontwerp van Be My AI is de duidelijkste demonstratie van het vakgebied van hoe AT-bewuste uitvoer er in de praktijk uitziet: beschrijvingen openen met een samenvattende zin van één zin waarop de gebruiker kan stoppen, gevolgd door gestructureerde detail alleen op verzoek, en vermijden van ruimtelijke taal (“aan de linkerkant”, “boven”) die ziende context vereist om te interpreteren. Het product is in 2026 nog steeds de dichtstbijzijnde referentie-implementatie die het vakgebied heeft.

De overkoepelende observatie is dat de vier producten vooruitgang hebben geboekt op de gemakkelijke onderdelen — kortere antwoorden, minder gedachtestreepjes, een veld voor aangepaste instructies — en nauwelijks begonnen zijn aan de moeilijke onderdelen. De moeilijke onderdelen staan hieronder.

Openstaande UX-problemen die nog niemand heeft opgelost

De literatuur over schermlezer-bewust promptontwerp convergeert op vier openstaande UX-problemen waarbij het juiste antwoord nog niet bekend is. Geen van hen zijn modelcapaciteitsproblemen; het zijn allemaal interactieontwerpproblemen die zitten tussen de LLM, het chatoppervlak, het besturingssysteem en de schermlezer.

Onderbrekbaarheid. Een ziende gebruiker kan een LLM-antwoord in circa twee seconden scannen en beslissen of het de moeite waard is om te lezen. Een schermlezergebruiker kan dat niet. Als het antwoord onjuist of niet relevant is, moet de gebruiker genoeg ervan beluisteren om dat te weten, dan onderbreken. Spraakmodi hebben een stopknop. Tekstmodi doorgaans niet — het antwoord stroomt binnen en de schermlezer kondigt het aan als nieuwe inhoud zodra het arriveert, en de gebruiker heeft geen nette manier om te zeggen “stop met genereren, dit is niet wat ik vroeg.” De Be My AI-app gaat hiermee het best om; de webchatclients het slechtst.

Herhaal-laatste-antwoord met selecteerbare granulariteit. Een schermlezer vragen het laatste antwoord opnieuw voor te lezen is eenvoudig als het antwoord kort is. Het is onbruikbaar als het antwoord zes alinea’s telt en de gebruiker alleen de derde alinea opnieuw wil horen. De interactie die de community vraagt is “herhaal het laatste lijstitem”, “herhaal de laatste kopsectie”, “herhaal het laatste codeblok.” Dat vereist dat het chatoppervlak de structuur aan de schermlezer blootstelt op een manier die de eigen herleescommando’s van de schermlezer kunnen adresseren. In 2026 doet geen van de grote producten dit; de gebruiker moet de eigen regel-voor-regel-navigatie van de schermlezer gebruiken, wat moeizaam is.

Navigeren per sectie in gesproken uitvoer. Spraakmodi hebben geen kopnavigatietoets. De gebruiker luistert lineair naar een antwoord van vier minuten, zonder manier om van de “overzicht”-sectie naar de “details”-sectie te springen zonder terug te spoelen in tijd. De interactieontwerpen die worden geprototyped — een gesproken “sectielijst” waardoorheen de gebruiker met pijltoetsen kan navigeren, een spraakcommando “ga naar sectie drie”, een modus “geef me alleen de koppen” — zijn vroeg. Het vervolgvraag-ontwerp “meer detail over de kleuren” in de Be My AI-app is de dichtstbijzijnde functionerende versie hiervan in een geleverd product.

De AT-overdrachtsvraag — wanneer spreekt de AI versus leest het inhoud hardop voor? Dit is de diepste ontwerkvraag. Als een schermlezergebruiker een AI-assistent opent op een webpagina, wie spreekt er dan — de eigen stem van de AI (TTS-laag), of de geïnstalleerde schermlezer van de gebruiker die de tekstuitvoer van de AI leest? De twee stemmen hebben verschillende instellingen, verschillende spreeksnelheden, verschillende uitspraakaanwijzingen, verschillende stop-en-replay-gebaren. Twee systemen die tegelijkertijd dezelfde inhoud proberen voor te lezen, produceren niets bruikbaars. De conventie die zich aftekent is: spraakmode-interacties gebruiken de eigen TTS van de AI en onderdrukken expliciet de schermlezer; tekstmode-interacties sturen semantische HTML uit en laten de schermlezer het spreken. Maar de grens tussen de twee modi is niet altijd duidelijk — afbeeldingsbeschrijving, codegeneratie, wiskundige notatie en multimodale antwoorden zitten allemaal ongemakkelijk tussen spraak en tekst — en die grens is waar de meeste live UX-problemen leven.

Waar het naartoe gaat

De discipline bevindt zich ruwweg waar webtoegankelijkheid zich in circa 2002 bevond: voorbij de fase “is dit een echt probleem?”, voorbij de fase “is iemand verantwoordelijk?”, in de fase “wat zijn de werkelijke regels?”. Drie dingen zullen zich waarschijnlijk voltrekken gedurende 2026 en 2027.

Ten eerste zullen de modelbouwers hun interne schermlezer-prompts codificeren en publiceren, zoals Anthropic de systeemprompts van Claude publiceert in VPAT-stijl toegankelijkheidsverklaringen en OpenAI de gedragsstandaarden van GPT begint te documenteren. De community vraagt om het equivalent van een modelkaart — een “schermlezeruitvoerkaart” — die de conventies noemt die een bepaald model is getraind of via systeemprompt is gebracht te volgen.

Ten tweede zullen de chatoppervlakken — webclients, mobiele apps, IDE-integraties — correcte semantische-HTML-renderingpijplijnen en correcte ARIA-blootstelling voor chatgeschiedenis krijgen, met navigatietoetsen die zijn gekoppeld aan de schermlezer van het besturingssysteem. Dit is onglamoureus werk, en het is het werk dat het meeste verschil zal maken voor dagelijkse gebruikers.

Ten derde zullen de schermlezerverkopers zelf — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — AI-bewuste functies gaan leveren: native kopnavigatie in AI-chatoppervlakken, een gestandaardiseerd “stop met genereren”-gebaar, slimmere herleescommando’s die de structuur van LLM-antwoorden kennen. Het open-source add-on-ecosysteem van NVDA produceert al vroege versies hiervan. De propriëtaire lezers zijn trager maar de richting is dezelfde.

De diepere observatie is dat schermlezer-bewust promptontwerp is gestopt een niche-zorg te zijn van een handvol blinde ontwikkelaars en een basisverwachting is geworden van elk AI-productteam dat wil leveren in gereguleerde markten. De Europese Toegankelijkheidsakte is van toepassing op “interactieve zelfbedieningsterminals” en “consuminatorterminalapparatuur met interactieve rekencapaciteit” — een categorie die grote AI-assistenten op een telefoon vrijwel zeker omvat. De AT-bewuste uitvoerlaag is geen functie meer; het is aanbestedingsbindend. De teams die de regels nu uitvogelen, zullen de producten leveren die 28 juni 2025 en daarna overleven. De teams die het als bijzaak behandelen, zullen de volgende ronde handhavingszaken onder de EAA zijn.

Slotgedachten

Het vakgebied is klein, de inzet is groot en de regels worden nog geschreven. Als er met LLMs wordt gebouwd en er nog geen gesprek is geweest met een schermlezergebruiker over hoe het product daadwerkelijk klinkt wanneer zij het gebruiken, is dat het volgende punt op de lijst. Het meeste dat in 2026 mis is met AI voor schermlezergebruikers is geen modelcapaciteitsprobleem; het is een prompt-en-oppervlakontwerprobleem dat elk productteam in een sprint kan oplossen, als zij daartoe besluiten.

De community is royaal geweest met haar tijd, haar testen en haar geduld. Zij verliest ook sneller geduld dan vroeger, omdat de producten nu mainstream zijn en het excuus van “we zoeken het nog uit” zijn geldigheid heeft verloren. De discipline is er. De conventies convergeren. De komende achttien maanden zullen de teams die geluisterd hebben, scheiden van de teams die dat niet deden.