Billedbeskrivelse: En smartphone, der hviler på et træskrivebord, viser en AI-chatgrænseflade med tilsluttede høretelefoner — det visuelle markør for skærmlæservenligt AI-prompt-design.
Læsetid: 9 minutter
En ny designdisciplin er krystalliseret i tilgængelighedsfællesskabet over de seneste atten måneder, og den har endnu ikke et fast navn. Nogle teams kalder det “AT-bevidst prompt-engineering”; andre kalder det “skærmlæser-formede systemprompts”; de praktikere, der kom igennem stemme-UI-design, kalder det typisk “tale-output-laget af en LLM.” Uanset etiketten er håndværket det samme: at skrive systemprompts og output-formningsregler, der gør generative AI-assistenter — ChatGPT, Claude, Gemini, Copilot, Be My AI — nyttige for de ca. 253 millioner mennesker verden over, der anvender disse produkter via en skærmlæser.
Problemet er konkret, og fejlmåden er høj. En LLM trænet på det offentlige internet producerer som standard prosa pyntet med tankestreger, indlejrede markdown-lister, kodefragmenter, overskrifter, der kun eksisterer fordi modellen følte, svaret var “struktureret”, og dekorative emoji. Oplæst af NVDA, JAWS, VoiceOver eller TalkBack bliver det output en strøm af “streg streg”-indskud, “punktum punktum punktum”-optælling uden nogen fornemmelse af, hvor et punkt slutter, “overskrift niveau to”-bekendtgørelser der afbryder en sætning, og emoji-navnestrenge (“smilende ansigt med solbriller”) mellem hvert andet led. Oplysningerne er der. Brugeren kan ikke udtrække dem uden at spole tre gange tilbage. Denne artikel er en guide til, hvad disciplinen beder modelbyggere om, hvad produkterne hidtil har leveret, og de åbne UX-problemer, ingen har løst endnu.
Den nye disciplin — hvad den faktisk består af
Skærmlæser-bevidst prompt-design er ikke en enkelt regel. Det er et lille sæt begrænsninger, der tilsammen producerer output, en syntetisator kan udtale forståeligt, og en skærmlæser-navigeringstast kan bevæge sig igennem. Begrænsningerne falder i fire grupper.
Præcise svar med semantisk struktur. Standard-LLM-output er for langt til talt levering — et 600-ords svar, der læses fint i en seende brugers browser, bliver en fire minutters monolog, som skærmlæser-brugeren ikke har nogen måde at skimme. Disciplinen beder om kortere svar, men vigtigere om strukturerede kortere svar: et indledende ét-sætnings-resumé, som brugeren kan stoppe ved, efterfulgt af en struktur, skærmlæseren kan navigere efter overskrift eller listepunkt.
Undgå tankestreger og anden tegnsætning, som syntetisatorer udtaler forkert. Tankestreger, korte tankestreger, parenteser, skråstreg-som-konjunktion og ASCII-separatorer — alle disse læses højt som enten stilhed, en bogstavelig “streg” eller en forvirrende pause, der bryder et led midt over. Den konvention, der opstår på tværs af de store modeller, er: foretræk komma og punktum; brug kolontegnet det ene sted, det virkelig tjener sit formål; brug aldrig tankestreger i tale-kontekst-svar; brug aldrig ASCII-regler til at adskille sektioner.
Erklær hvad der er en liste, hvad der er en overskrift, hvad der er kode. Syntetisk tale har ingen visuel hierarki. En overskrift skal annonceres som “overskrift”, en liste skal annonceres som “liste med N punkter, punkt et”, kode skal annonceres som “kode”, og modellen skal enten producere strukturer, som skærmlæseren genkender (HTML, korrekt markdown som gengivelsesoverfladen konverterer til ARIA), eller mundtligt fortælle om strukturen selv (“Her er tre muligheder. Mulighed et: …”).
Ingen markdown-suppe. Markdown er fint, når gengivelsesoverfladen konverterer det til semantisk HTML. Markdown er fjendtlig, når overfladen viser de rå stjerner og understreger, fordi skærmlæseren så annoncerer “stjerne stjerne” før hvert fede ord. Disciplinen er at opdage gengivelseskonteksten — chat-UI med markdown-rendering kontra terminal kontra skærmlæser-drevet stemmegrænseflade — og forme output derefter. Den samme model skal producere forskellige overfladerepræsentationer af det samme svar.
Hvad skærmlæsere faktisk behøver fra AI
For at gøre begrænsningerne ovenfor konkrete er det nyttigt at se på den faktiske adfærd hos de fire skærmlæser- og OS-kombinationer, der dominerer feltet: JAWS på Windows, NVDA på Windows, VoiceOver på macOS og iOS og TalkBack på Android. De er ikke udskiftelige, og en prompt, der producerer godt output for én, kan være ulæselig på en anden.
Navigation via overskrift. Alle fire skærmlæsere eksponerer en overskrift-navigeringstast (H i JAWS og NVDA, Rotor i VoiceOver, læsekontrol-skift i TalkBack). For at et langt AI-svar skal kunne navigeres, skal modellen udsende rigtige semantiske overskrifter — enten via en markdown-gengivelsespipeline, der konverterer til <h2>/<h3> med korrekt niveauindlejring, eller via chatoverfladens egne strukturerede-svar-API. En model, der “strukturerer” sit svar ved at fremhæve de første tre ord i hvert afsnit med fed, har produceret noget, der visuelt ser struktureret ud og er fuldstændig fladt for en skærmlæser.
Navigation via liste. Lister er nyttige i talt output præcis fordi skærmlæseren annoncerer antallet (“liste med syv punkter”) og lader brugeren gå igennem med liste-punkts-navigeringstast (I i NVDA, L i JAWS). Men dette virker kun, hvis listen er en rigtig <ul> eller <ol>. En “liste” produceret ved at udsende bullet-tegn i begyndelsen af hver linje uden nogen list-wrapper, læses som almindelig prosa med et uforklaret “sort cirkel” eller “punktum”-indskud på hver linje.
Spring-til-sektion. Langt AI-svar — forklaringer, sammenligninger, kode-og-kommentar, flertrins-instruktioner — behøver en måde for skærmlæser-brugeren at springe til den sektion, de bekymrer sig om, uden at lytte sig igennem præamblen. Dette er det absolut sværeste stykke at designe godt, fordi modellen skal producere en navigerbar struktur og chatoverfladen skal gengive den på en måde, OS’en eksponerer for hjælpeteknologien, og skærmlæseren skal være konfigureret til at bruge overskrift-navigeringstast på den overflade. Alle tre ting fejler i praksis; det er normalt den midterste.
Udtale-hints. Syntetiske stemmer snubler over tekniske termer, akronymer med blandede bogstaver, URL’er, kodeidentifikatorer, matematisk notation og ikke-engelske navne. En veldesignet model vil til skærmlæser-kontekst-svar stave akronymer ud ved første brug (“WCAG, Retningslinjerne for tilgængeligt webindhold”), udvide initialisme, som syntetisatoren ikke kan udtale, og undgå at indlejre rå URL’er inde i løbende prosa, hvor synten vil læse skråstregerne højt. Ingen af de store produkter gør dette konsekvent i 2026.
Hvordan produkterne håndterer det
Pr. medio 2026 har de store generative AI-produkter taget mærkbart forskellige positioner om skærmlæser-bevidst output. Ingen af dem har knækket koden. Fremgangen er hurtigere end for tolv måneder siden, men kløften mellem bedst og dårligst er stadig bred.
ChatGPT (OpenAI). Webklienten leverer nu med en “kortfattet tilstand”-knap, der forkorter standardsvar og reducerer markdown-dekoration. Den stemmefunktion introduceret i 2024 — og substantielt opgraderet i 2025 — er det tætteste, noget større produkt er kommet på en skærmlæser-nativ grænseflade, fordi den omgår den visuelle chat fuldstændigt og leverer et talt svar med et stop-, genafspil- og “sig det igen”-gestus. Det brugerdefinerede instruktionsfelt giver skærmlæser-brugere mulighed for at erklære deres præferencer én gang og have dem gælde på tværs af sessioner, hvilket er den bruger-drevne løsning fællesskabet har fundet frem til. De tilbageværende mangler: GPT-modeller er stadig som standard tankestreg-tunge i prosa, medmindre man instruerer dem anderledes, og overskriftsniveauet udsendt i markdown afspejles ikke altid rent til ARIA i chatoverfladen.
Claude (Anthropic). Claudes systemprompt-disciplin har bevæget sig tættest på de konventioner, der er beskrevet ovenfor. Modellen er mærkbart mindre tankestreg-tilbøjelig end GPT-linjen i 2026, er som standard kortere svar, og reagerer godt på systemprompt-instruktioner som “du taler til en skærmlæser-bruger; brug ingen tankestreger, foretræk korte afsnit og brug rigtige overskrifter eller nummererede lister, når der er brug for struktur.” Claude.ai-chatoverfladen gengiver markdown til semantisk HTML med korrekte overskriftsniveauer, hvilket gør overskrift-navigeringstasten funktionel. Stemme-output via tredjepartsintegrationer eksisterer men er mindre udviklet end ChatGPTs first-party stemmefunktion.
Gemini (Google). Tæt integration med TalkBack på Android er Geminis strukturelle fordel; modellen kan overdrage til OS-niveau-skærmlæseren via Androids tilgængelighedstjenester på en måde, iOS- og web-konkurrenterne ikke kan. “Hey Google, spørg Gemini…”-flowet på tilgængeligt udstyrede Android-enheder er for nogle brugere den mest naturlige AI-plus-skærmlæser-oplevelse, der er tilgængelig. De tilbageværende mangler: webgrænsefladen over-dekorerer stadig svar, overskriftshierarkiet i Geminis websvar er inkonsekvent, og modellen er mere tilbøjelig til at producere dekorative emoji end sine konkurrenter.
Be My AI (Be My Eyes plus OpenAI). Dette er det mest snævert scoped af de fire — en visuel-beskrivelses-assistent, der bruger GPT-4-klasse-visionsmodeller til at beskrive billeder og omgivelser for blinde og svagsynede brugere. Det er også det eneste produkt på denne liste, der er designet fra dag et for en skærmlæser-bruger som den primære målgruppe. Be My AIs prompt-design er feltets tydeligste demonstration af, hvordan AT-bevidst output ser ud i praksis: beskrivelser åbner med et ét-sætnings-resumé, som brugeren kan stoppe ved, efterfulgt af struktureret detalje kun hvis bedt om det, og undgår rumlige udtryk (“til venstre”, “ovenfor”), der kræver seende kontekst for at fortolke. Produktet forbliver i 2026 det tætteste, feltet har på en referenceimplementering.
Den tværgående observation er, at de fire produkter har gjort fremskridt på de nemme dele — kortere svar, færre tankestreger, et brugerdefineret instruktionsfelt — og næsten ikke er begyndt på de svære dele. De svære dele er nedenfor.
Åbne UX-problemer ingen har løst
Litteraturen om skærmlæser-bevidst prompt-design konvergerer om fire åbne UX-problemer, hvor det rigtige svar endnu ikke kendes. Ingen af dem er model-kapabilitets-problemer; alle er interaktionsdesignproblemer, der sidder mellem LLM’en, chatoverfladen, OS’en og skærmlæseren.
Afbrydbarhed. En seende bruger kan skimme et LLM-svar på ca. to sekunder og afgøre, om det er relevant at læse. Det kan en skærmlæser-bruger ikke. Hvis svaret er forkert eller off-target, skal brugeren lytte nok af det til at opdage det og derefter afbryde. Stemmefunktioner har en stopknap. Teksttilstande har det generelt ikke — svaret streamer ind, og skærmlæseren annoncerer det som nyt indhold efterhånden som det ankommer, og brugeren har ingen ren måde at sige “stop generering, dette er ikke det, jeg spurgte om.” Be My AI-appen håndterer dette bedst; web-chatklienterne håndterer det dårligst.
Gentag-sidst-svar med valgbar granularitet. At bede en skærmlæser om at læse det sidste svar igen er nemt, hvis svaret er kort. Det er ubrugeligt, hvis svaret er seks afsnit, og brugeren kun ønsker at høre det tredje afsnit igen. Den interaktion, fællesskabet beder om, er “gentag det sidste listepunkt”, “gentag det sidste overskriftsafsnit”, “gentag det sidste kodeblok.” Det kræver, at chatoverfladen eksponerer strukturen for skærmlæseren på en måde, som skærmlæserens egne gentagelses-kommandoer kan adressere. I 2026 gør ingen af de store produkter dette; brugeren skal bruge skærmlæserens egne linje-for-linje-navigation, hvilket er besværligt.
Naviger-efter-sektion i talt output. Stemmefunktioner har ikke en overskrift-navigeringstast. Brugeren lytter lineært til et fire minutter langt svar uden mulighed for at springe fra “oversigt”-sektionen til “detaljer”-sektionen uden at spole tilbage i tid. De interaktionsdesigns, der prototyperes — en talt “sektionsliste”, brugeren kan navigere med piletaster, en “gå til sektion tre”-stemmekommando, en “giv mig kun overskrifterne”-tilstand — er tidlige. Be My AI-appens “mere detalje om farverne”-opfølgning er den tætteste fungerende version af dette i et sendt produkt.
AT-overdragelses-spørgsmålet — hvornår taler AI’en kontra læser indhold højt? Dette er det dybeste designspørgsmål. Hvis en skærmlæser-bruger åbner en AI-assistent på en webside, hvem taler så — AI’ens egen stemme (TTS-lag) eller brugerens installerede skærmlæser, der læser AI’ens tekstoutput? De to stemmer har forskellige indstillinger, forskellige talehastigheder, forskellige udtale-hints, forskellige stop-og-genafspil-gestus. To systemer, der forsøger at tale det samme indhold på samme tid, producerer intet brugbart. Den konvention, der opstår, er: stemmefunktion-interaktioner bruger AI’ens egne TTS og undertrykker eksplicit skærmlæseren; tekstfunktion-interaktioner udsender semantisk HTML og lader skærmlæseren tale. Men grænsen mellem de to tilstande er ikke altid klar — billedbeskrivelse, kodegenerering, matematisk notation og multimodale svar sidder alle akavet mellem stemme og tekst — og det er ved den grænse, de fleste af de aktuelle UX-problemer lever.
Hvad der sker som det næste
Disciplinen er ca. der, hvor webtilgængelighed var ca. i 2002 — forbi fasen “er dette et reelt problem?”, forbi fasen “er nogen ansvarlig?”, ind i fasen “hvad er de faktiske regler?” Tre ting vil sandsynligvis ske i løbet af 2026 og 2027.
For det første vil modelbyggerne kodificere deres interne skærmlæser-prompts og offentliggøre dem, på den måde Anthropic offentliggør Claudes systemprompts i VPAT-lignende tilgængelighedserklæringer, og OpenAI er begyndt at dokumentere GPTs adfærdsstandarder. Fællesskabet beder om det ækvivalente til et modelkort — et “skærmlæser-output-kort” — der navngiver de konventioner, en given model er trænet eller systemprompt-instru-eret til at følge.
For det andet vil chatoverfladerne — webklienter, mobilapps, IDE-integrationer — få korrekte semantisk-HTML-gengivelsespipelines og korrekt ARIA-eksponering for chathistorik med navigeringstaster kortlagt til OS-niveau-skærmlæseren. Dette er uglomourtøst arbejde, og det er det arbejde, der vil flytte nålen mest for daglige brugere.
For det tredje vil skærmlæser-leverandørerne selv — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — begynde at levere AI-bevidste funktioner: native overskrift-navigation inde i AI-chatoverflader, en standardiseret “stop generering”-gestus, klogere gentagelses-kommandoer, der kender til LLM-svarstruktur. NVDAs open source-add-on-økosystem producerer allerede tidlige versioner af disse. De proprietære skærmlæsere er langsommere, men retningen er den samme.
Den dybere observation er, at skærmlæser-bevidst prompt-design er holdt op med at være en nichebekymring for en håndfuld blinde udviklere og er blevet en basisforventning fra hvert AI-produktteam, der ønsker at levere til regulerede markeder. Det europæiske tilgængelighedsdirektiv gælder for “interaktive selvbetjeningsterminaler” og “forbruger-terminaludstyr med interaktiv beregningskapabilitet” — en kategori, der næsten med sikkerhed indfanger en stor AI-assistent på en telefon. AT-bevidst outputlaget er ikke en funktion mere; det er udbudsforpligtende. De teams, der finder ud af reglerne nu, vil levere de produkter, der overlever 28. juni 2025 og frem. De teams, der behandler det som en eftertanke, vil blive den næste runde af EAA-håndhævelsessager.
Afsluttende tanker
Håndværket er lille, indsatsen er stor, og reglerne er stadig under udformning. Hvis man bygger med LLM’er og endnu ikke har haft en samtale med en skærmlæser-bruger om, hvad ens produkt faktisk lyder som, når de bruger det, er det det næste på listen. Det meste af det, der er galt med AI for skærmlæser-brugere i 2026, er ikke et model-kapabilitets-problem; det er et prompt-og-overflade-designproblem, som ethvert produktteam kan løse på en sprint, hvis de beslutter sig for det.
Fællesskabet har været generøst med sin tid, sine tests og sin tålmodighed. Det mister også tålmodighed hurtigere end det plejede, fordi produkterne nu er mainstream, og undskyldningen “vi er stadig ved at finde ud af det” er løbet tør. Disciplinen er her. Konventionerne konvergerer. De næste atten måneder vil sortere de teams, der lyttede, fra de teams, der ikke gjorde.