Bildbeskrivning: En smartphone på ett träskrivbord som visar ett AI-chattgränssnitt med hörlurar anslutna — det visuella märket för skärmläsarvänlig AI-promptdesign.

Lästid: 9 minuter

En ny designdisciplin har kristalliserats inom tillgänglighetsgemenskapen under de senaste arton månaderna, och den har ännu inget etablerat namn. Vissa team kallar det “AT-medveten promptteknik”. Andra kallar det “skärmläsarformade systemprompt”. Praktiker som kom upp via röstgränssnittsdesign tenderar att kalla det “talutdatalagret för ett LLM.” Oavsett etikett är hantverket detsamma: att skriva systemprompt och outputformningsregler som gör generativa AI-assistenter — ChatGPT, Claude, Gemini, Copilot, Be My AI — användbara för de ungefär 253 miljoner människor worldwide som når dessa produkter via en skärmläsare.

Problemet är konkret och felsättet är högljutt. Ett LLM tränat på den öppna webben producerar som standard prosa dekorerad med tankstreck, nästlade markdown-listor, kodblock, rubriker som bara finns för att modellen ansåg att svaret var “strukturerat” och dekorativa emoji. Uppläst av NVDA, JAWS, VoiceOver eller TalkBack blir den utdatan en ström av “streck streck”-inskott, “punkt punkt punkt”-uppräkning utan känsla för var en post slutar, “rubrik nivå två”-meddelanden som avbryter en mening och emojinamnsträngar (“leende ansikte med solglasögon”) mellan varannan mening. Informationen finns där. Användaren kan inte extrahera den utan att spola tillbaka tre gånger. Den här texten är en primer om vad disciplinen begär av modellbyggare, vad produkterna har levererat hittills och de öppna UX-problem ingen löst ännu.

Den nya disciplinen — vad den faktiskt består av

Skärmläsarmedveten promptdesign är inte en enda regel. Det är en liten uppsättning begränsningar som, tillsammans, producerar output en syntesizer kan uttala begripligt och en skärmläsares navigeringstangent kan röra sig igenom. Begränsningarna faller i fyra kategorier.

Kortfattade svar med semantisk struktur. Standard-LLM-output är för lång för talad leverans — ett 600-ords svar som läses bra i en seende användares webbläsare blir en fyra minuters monolog som skärmläsaranvändaren inte har något sätt att scanna. Disciplinen efterfrågar kortare svar, men viktigare är strukturerade kortare svar: en inledande ettmenigarssammanfattning som användaren kan stanna vid, följt av struktur som skärmläsaren kan navigera per rubrik eller listobjekt.

Undvik tankstreck och annan interpunktion som syntesizer uttalar fel. Tankstrecket, halvtankstrecket, parentetiken, snedstrecket-som-konjunktion, ASCII-konst-separatorn — allt detta läses upp som antingen tystnad, ett bokstavligt “streck” eller en förvirrande paus som delar en mening på mitten. Konventionen som framträder över de stora modellerna är: föredra komma och punkt. Använd kolon för det enda ställe det verkligen tjänar sitt syfte. Använd aldrig tankstreck i talavsiktsrespons. Använd aldrig ASCII-linjer för att separera avsnitt.

Deklarera vad som är en lista, vad som är en rubrik, vad som är kod. Syntetiserat tal har ingen visuell hierarki. En rubrik måste meddelas som “rubrik”, en lista måste meddelas som “lista med N objekt, objekt ett”, kod måste meddelas som “kod”, och modellen måste antingen leverera strukturer som skärmläsaren känner igen (HTML, riktig markdown som renderingsytan konverterar till ARIA) eller verbalt berätta strukturen (“Här är tre alternativ. Alternativ ett: …”).

Ingen markdown-soppa. Markdown är bra när renderingsytan konverterar det till semantisk HTML. Markdown är fientligt när ytan visar råa asterisker och understreck, eftersom skärmläsaren då meddelar “asterisk asterisk” före varje fetstilsord. Disciplinen är att detektera renderingskontexten — chattgränssnitt med markdown-rendering kontra terminal kontra skärmläsardriven röstgränssnitt — och forma output därefter. Samma modell behöver producera olika ytrepresentationer av samma svar.

Vad skärmläsare faktiskt behöver av AI

För att göra ovanstående begränsningar konkreta är det hjälpsamt att titta på det faktiska beteendet hos de fyra skärmläsare/OS-kombinationer som dominerar fältet: JAWS på Windows, NVDA på Windows, VoiceOver på macOS och iOS samt TalkBack på Android. De är inte utbytbara, och en prompt som producerar bra output för en kan vara oläsbar på en annan.

Navigering per rubrik. Alla fyra läsare exponerar en rubrikknavigationstangent (H i JAWS och NVDA, Rotor i VoiceOver, läskontrollväxeln i TalkBack). För att ett långt AI-svar ska vara navigerbart måste modellen emittera verkliga semantiska rubriker — antingen genom en markdown-renderingspipeline som konverterar till <h2>/<h3> med korrekt nivånästling, eller via chattytans eget strukturerade svar-API. En modell som “strukturerar” sitt svar genom att fetmarkera de tre första orden i varje stycke har producerat något som ser strukturerat ut visuellt och är helt platt för en skärmläsare.

Navigering per lista. Listor är användbara i talad output just för att skärmläsaren meddelar antalet (“lista med sju objekt”) och låter användaren stega igenom med listobjektnavigationstangenten (I i NVDA, L i JAWS). Men detta fungerar bara om listan är en riktig <ul> eller <ol>. En “lista” som produceras genom att emittera punkttecken i början av varje rad, utan listomslagselement, läses som ordinär prosa med ett oförklarat “svart cirkel”- eller “punkt”-inskott på varje rad.

Hoppa per avsnitt. Längre AI-svar — förklaringar, jämförelser, kod och kommentarer, flerstegsinstruktioner — behöver ett sätt för skärmläsaranvändaren att hoppa till det avsnitt de bryr sig om utan att lyssna igenom inledningen. Det är det enskilt svåraste stycket att designa väl, eftersom modellen måste producera en navigerbar struktur och chattytany måste rendera det på ett sätt som OS exponerar för hjälpmedelseknik, och skärmläsaren måste vara konfigurerad att använda rubrikknavigationstangenten i den ytan. Alla tre sakerna misslyckas i verkligheten. Vanligtvis är det den mellersta.

Uttalstips. Syntetiska röster snubblar på tekniska termer, akronymer med blandade bokstäver, URL:er, kodidentifierare, matematisk notation och icke-engelska namn. En väldesignad modell kommer, för skärmläsarkontextsvar, att stava ut akronymer vid första användning (“WCAG, Riktlinjer för tillgängligt webbinnehåll”), expandera initialerna som syntesizern inte kan uttala och undvika att bädda in råa URL:er i löpande prosa där syntesen läser snedstrecken högt. Ingen av de stora produkterna gör detta konsekvent 2026.

Hur produkterna hanterar det

Per mitten av 2026 har de stora generativa AI-produkterna tagit synligt olika positioner i skärmläsarmedveten output. Ingen av dem har löst det. Utvecklingen är snabbare än för tolv månader sedan, men klyftan mellan den bästa och den sämsta är fortfarande bred.

ChatGPT (OpenAI). Webbklienten levereras nu med en “kortfattat läge”-växel som förkortar standardsvar och minskar markdown-dekoration. Röstläget som introducerades 2024 — och uppgraderades väsentligt 2025 — är det närmaste någon stor produkt kommit ett skärmläsarnaturt gränssnitt, eftersom det kringgår den visuella chatten helt och levererar ett talat svar med en stopp-, uppspelnings- och “säg det igen”-gest. Fältet för anpassade instruktioner låter skärmläsaranvändare deklarera sina preferenser en gång och låta dem gälla över sessioner, vilket är den användarstyrda lösningen som gemenskapen har landat i. Återstående brister: GPT-modeller använder fortfarande tankstrecksrik prosa som standard om de inte instrueras annorlunda, och rubrikkivån som emitteras i markdown mappar inte alltid rent till ARIA i chattytany.

Claude (Anthropic). Claudes systempromptdisciplin har rört sig närmast de konventioner som beskrivs ovan. Modellen är märkbart mindre tankstrecksbenägen än GPT-linjen 2026, standardiserar sig på kortare svar och svarar väl på systempromptinstruktioner som “du talar till en skärmläsaranvändare. Använd inga tankstreck, föredra korta stycken och använd riktiga rubriker eller numrerade listor när struktur behövs.” Claude.ai-chattytany renderar markdown till semantisk HTML med korrekta rubrikkniåer, vilket gör att rubrikknavigationstangenten fungerar. Röstoutput via tredjepartsintegrationer finns men är mindre utvecklad än ChatGPTs förstaparts röstläge.

Gemini (Google). Tät integration med TalkBack på Android är Geminis strukturella fördel. Modellen kan överlämna till OS-nivåns skärmläsare via Androids tillgänglighetstjänster på ett sätt som iOS- och webbkonkurrenterna inte kan. Flödet “Hej Google, fråga Gemini…” på tillgängliga Android-enheter är, för vissa användare, den mest naturliga AI-plus-skärmläsarupplevelsen som finns. Återstående brister: webbgränssnittet överdekorerar fortfarande svar, rubrikkiarkinen i Geminis webbsvar är inkonsekvent och modellen är mer benägen att producera dekorativa emoji än sina konkurrenter.

Be My AI (Be My Eyes + OpenAI). Detta är den mest avgränsade av de fyra — en visuell beskrivningsassistent som använder GPT-4-klassens synmodeller för att beskriva bilder och omgivningar för blinda och synskadade användare. Det är också den enda produkten på den här listan som från dag ett designades med en skärmläsaranvändare som primär målgrupp. Be My AIs promptdesign är fältets tydligaste demonstration av hur AT-medveten output ser ut i praktiken: beskrivningar öppnar med en ettmenigarssammanfattning som användaren kan stanna vid, följer med strukturerade detaljer bara vid begäran och undviker spatialt språk (“till vänster”, “ovanför”) som kräver seende kontext för att tolkas. Produkten förblir, 2026, det närmaste fältet har en referensimplementation.

Den genomgående iakttagelsen är att de fyra produkterna gjort framsteg på de enkla delarna — kortare svar, färre tankstreck, ett fält för anpassade instruktioner — och knappt börjat på de svåra delarna. De svåra delarna behandlas nedan.

Öppna UX-problem som ingen löst

Den skärmläsarmedvetna promptdesignlitteraturen konvergerar på fyra öppna UX-problem där rätt svar ännu inte är känt. Inget av dem är modellkapabilitetsproblem. Alla är interaktionsdesignproblem som sitter mellan LLM:et, chattytany, operativsystemet och skärmläsaren.

Avbrottsbarhet. En seende användare kan skanna ett LLM-svar på ungefär två sekunder och avgöra om man vill läsa det. En skärmläsaranvändare kan inte det. Om svaret är fel eller bredvid ämnet måste användaren lyssna tillräckligt för att inse det, sedan avbryta. Röstlägen har en stoppknapp. Textlägen har i allmänhet inte det — svaret strömmar in och skärmläsaren meddelar det som nytt innehåll allteftersom det anländer, och användaren har inget rent sätt att säga “sluta generera, detta är inte vad jag frågade.” Be My AI-appen hanterar detta bäst. Webbchattsklienterna hanterar det sämst.

Upprepa senaste svar med valbar granularitet. Att be en skärmläsare läsa upp det senaste svaret igen är enkelt om svaret är kort. Det är oanvändbart om svaret är sex stycken och användaren bara vill höra det tredje stycket igen. Interaktionen som gemenskapen efterfrågar är “upprepa det senaste listobjektet”, “upprepa det senaste rubrikavsnittet”, “upprepa det senaste kodblocket.” Det kräver att chattytany exponerar strukturen för skärmläsaren på ett sätt som skärmläsarens egna uppläsningskommandon kan adressera. 2026 gör ingen av de stora produkterna detta. Användaren måste använda skärmläsarens egna rad-för-rad-navigering, vilket är omständligt.

Navigera per avsnitt i talad output. Röstlägen har ingen rubrikknavigationstangent. Användaren lyssnar på ett fyra minuters svar linjärt, utan möjlighet att hoppa från “översikts”-avsnittet till “detaljer”-avsnittet utan att spola tillbaka tidsmässigt. De interaktionsdesigner som prototypas — en talad “avsnittslista” som användaren kan navigera med piltangenter, ett “gå till avsnitt tre”-röstkommando, ett “ge mig bara rubrikerna”-läge — är tidiga. Be My AI-appens “mer detalj om färgerna”-uppföljning är den närmaste fungerande versionen av detta i en levererad produkt.

AT-överlämningsfrågan — när talar AI kontra läser upp innehåll högt? Det är den djupaste designfrågan. Om en skärmläsaranvändare öppnar en AI-assistent på en webbsida, vem talar då — AI:ns egen röst (TTS-lagret), eller användarens installerade skärmläsare som läser upp AI:ns textoutput? De två rösterna har olika inställningar, olika talhastigheter, olika uttalstips, olika stopp-och-uppspelningsgest. Två system som försöker tala samma innehåll samtidigt producerar ingenting användbart. Konventionen som framträder är: röstlägesinteraktioner använder AI:ns eget TTS och undertrycker skärmläsaren explicit. Textlägesinteraktioner emitterar semantisk HTML och låter skärmläsaren göra talandet. Men gränsen mellan de två lägena är inte alltid tydlig — bildbeskrivning, kodgenerering, matematisk notation och multimodala svar sitter alla obekvämt mellan röst och text — och den gränsen är där de flesta av de levande UX-problemen befinner sig.

Vart det tar vägen härnäst

Disciplinen befinner sig ungefär där webbtillgänglighet var ungefär 2002 — förbi “är detta ett verkligt problem?”-fasen, förbi “är någon ansvarig?”-fasen, in i “vad är de faktiska reglerna?”-fasen. Tre saker kommer troligen att hända under 2026 och 2027.

För det första kommer modellbyggarna att kodifiera sina interna skärmläsarprompt och publicera dem, på det sätt Anthropic publicerar Claudes systemprompt i VPAT-liknande tillgänglighetsredogörelser och OpenAI har börjat dokumentera GPT:s beteendestandard. Gemenskapen efterfrågar motsvarigheten till ett modellkort — ett “skärmläsaroutputkort” — som namnger de konventioner en given modell har tränats eller systempromptats att följa.

För det andra kommer chattytorna — webbklienter, mobilappar, IDE-integrationer — att få riktiga semantisk-HTML-renderingspipelines och korrekt ARIA-exponering för chatthistorik, med navigationstangenter mappade till OS-nivåns skärmläsare. Det är oglamoröst arbete, och det är arbetet som kommer att göra störst skillnad för dagliga användare.

För det tredje kommer skärmläsarleverantörerna själva — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — att börja leverera AI-medvetna funktioner: native rubrikknavigering inne i AI-chattytory, en standardiserad “sluta generera”-gest, smartare uppläsningskommandon som känner till LLM-svarsstruktur. NVDA:s öppen källkods-tillägg-ekosystem producerar redan tidiga versioner av dessa. De proprietära läsarna är långsammare men riktningen är densamma.

Den djupare iakttagelsen är att skärmläsarmedveten promptdesign har slutat vara en nischfråga för en handfull blinda utvecklare och blivit en baslinjsförväntning för varje AI-produktteam som vill leverera till reglerade marknader. Europeiska tillgänglighetsakten gäller “interaktiva självbetjäningsterminaler” och “konsumenterminaler med interaktiv beräkningskapacitet” — en kategori som nästan säkert fångar en stor AI-assistent på en telefon. Det AT-medvetna outputlagret är inte längre en funktion. Det är upphandlingsbindande. De team som räknar ut reglerna nu kommer att leverera de produkter som överlever den 28 juni 2025 och framåt. De team som behandlar det som en eftertanke kommer att bli nästa omgång av EAA-tillsynsfall.

Avslutande tankar

Hantverket är litet, insatserna är stora och reglerna skrivs fortfarande. Om du bygger med LLM:er och ännu inte haft ett samtal med en skärmläsaranvändare om hur din produkt faktiskt låter när de använder den, är det nästa punkt på listan. Det mesta som är fel med AI för skärmläsaranvändare 2026 är inte ett modellkapabilitetsproblem. Det är ett prompt- och ytdesignproblem som vilket produktteam som helst kan lösa under en sprint, om de bestämmer sig för det.

Gemenskapen har varit generös med sin tid, sina tester och sitt tålamod. Den förlorar också tålamod snabbare än tidigare, eftersom produkterna nu är mainstream och ursäkten “vi håller fortfarande på att räkna ut det” har runnit ut. Disciplinen finns här. Konventionerna konvergerar. De närmaste arton månaderna kommer att skilja de team som lyssnade från de team som inte gjorde det.