Kuvan kuvaus: Älypuhelin puisella pöydällä, kuulokkeet kytkettynä, tekoälychat-käyttöliittymä näytöllä — visuaalinen merkki ruudunlukuohjelmalle sopivalle tekoälykyselysuunnittelulle.

Lukuaika: 9 minuuttia

Saavutettavuusyhteisöön on viimeisten kahdeksantoista kuukauden aikana kiteytyinyt uusi suunnittelukuri, jolle ei ole vielä vakiintunutta nimeä. Jotkut tiimit kutsuvat sitä “avustavan teknologian tietoiseksi kyselysuunnitteluksi”; toiset kutsuvat sitä “ruudunlukuohjelmaan muotoilluiksi järjestelmäkyselyiksi”; äänipohjaisen käyttöliittymäsuunnittelun kautta tulleet ammattilaiset kutsuvat sitä “suuren kielimallin puhutun tulosteen tasoksi.” Nimestä riippumatta käytäntö on sama: järjestelmäkyselyjen ja tulostetta muovaavien sääntöjen kirjoittaminen, jotka tekevät generatiivisista tekoälyavustajista — ChatGPT, Claude, Gemini, Copilot, Be My AI — hyödyllisiä noin 253 miljoonalle maailmanlaajuiselle käyttäjälle, jotka käyttävät näitä tuotteita ruudunlukuohjelman kautta.

Ongelma on konkreettinen ja virheilmoitus on äänekäs. Julkiseen verkkoon koulutettu suuri kielimalli tuottaa oletuksena proosaa, joka on koristeltu ajatusviivoja, sisäkkäisiä markdown-listoja, koodikehyksiä, otsikoita, jotka ovat olemassa vain siksi että malli koki vastauksen olevan “jäsennelty”, ja koristelevia emojeja. NVDA:n, JAWS:n, VoiceOverin tai TalkBackin ääneen lukemana tuo tuloste muuttuu “viiva viiva” -välilauseiden virrraksi, “piste piste piste” -luetteloksi ilman mitään käsitystä siitä, missä yksi kohta päättyy, “otsikko taso kaksi” -ilmoituksiksi, jotka keskeyttävät lauseen, ja emoji-nimistöiksi (“hymyilevät kasvot aurinkolaseilla”) joka toisen lauseen välissä. Tieto on siellä. Käyttäjä ei pysty poimimaan sitä kelaamatta kolmesti. Tämä artikkeli on johdanto siihen, mitä kuri vaatii mallinrakentajilta, mitä tuotteet ovat tähän mennessä toimittaneet ja avoimet UX-ongelmat, joita kukaan ei ole vielä ratkaissut.

Uusi kuri — mistä se käytännössä koostuu

Ruudunlukuohjelman tietoinen kyselysuunnittelu ei ole yksittäinen sääntö. Se on pieni joukko rajoitteita, jotka yhdessä tuottavat tulostetta, jonka syntetisaattori voi lausua ymmärrettävästi ja jonka läpi ruudunlukuohjelman navigointinäppäin voi liikkua. Rajoitteet jakautuvat neljään kategoriaan.

Tiiviit vastaukset semanttisella rakenteella. Oletusarvoinen suuren kielimallin tuloste on liian pitkä puhutun toistuksen tarpeisiin — 600 sanan vastaus, joka lukee hyvin näkevän käyttäjän selaimessa, muuttuu neljän minuutin monologiksi, jota ruudunlukuohjelmakäyttäjällä ei ole keinoa silmäillä. Kuri vaatii lyhyempiä vastauksia, mutta ennen kaikkea jäsenneltyjä lyhyempiä vastauksia: avaavan yhden lauseen tiivistelmän, johon käyttäjä voi pysähtyä, ja rakenteen, jota ruudunlukuohjelma voi navigoida otsikon tai listaalkion perusteella.

Vältä ajatusviivoja ja muuta välimerkkiä, jonka syntetisaattorit lausuvat väärin. Ajatusviitta, puolipitkä viiva, sulkeiden sisäinen rakenne, kauttaviiva-konjunktio, ASCII-erottimet — kaikki nämä luetaan ääneen joko hiljaisuutena, kirjaimellisena “viivana” tai hämmentävänä taukona, joka rikkoo lauseen kahtia. Suurimpien mallien välillä kehittyvä käytäntö on: suosi pilkkua ja pistettä; käytä kaksoispistettä siinä yhdessä paikassa, jossa se todella ansaitsee paikkansa; älä koskaan käytä ajatusviivoja puhutun kontekstin vastauksissa; älä koskaan käytä ASCII-sääntöjä osioiden erottamiseen.

Ilmoita, mikä on lista, mikä otsikko, mikä koodi. Syntetisoidulla puheella ei ole visuaalista hierarkiaa. Otsikko on ilmoitettava “otsikkona”, lista “listana, jossa N kohtaa, kohta yksi”, koodi “koodina”, ja mallin on joko tuotettava rakenteita, jotka ruudunlukuohjelma tunnistaa (HTML, asianmukainen markdown, jonka renderointipinta muuntaa ARIA:ksi), tai kerrottava rakenne sanallisesti (“Tässä on kolme vaihtoehtoa. Vaihtoehto yksi: …”).

Ei markdown-soppa. Markdown on hyvä, kun renderointipinta muuntaa sen semanttiseksi HTML:ksi. Markdown on vihamielinen, kun pinta näyttää raa’at asteriskit ja alleviivaukset, koska ruudunlukuohjelma sitten ilmoittaa “asteriski asteriski” ennen jokaista lihavoitua sanaa. Kuri on tunnistaa renderointikonteksti — markdown-renderöinnillä varustettu chat-käyttöliittymä versus terminaali versus ruudunlukuohjelmapohjaiseen ääniliitäntään — ja muokata tuloste sen mukaan. Saman mallin on tuotettava erilaisia pintaesityksiä samasta vastauksesta.

Mitä ruudunlukuohjelmat todella tarvitsevat tekoälyltä

Yllä olevien rajoitteiden konkretisoimiseksi on hyödyllistä tarkastella neljän dominoivan ruudunlukuohjelma/käyttöjärjestelmä-yhdistelmän todellista käyttäytymistä: JAWS Windowsilla, NVDA Windowsilla, VoiceOver macOS:lla ja iOS:lla sekä TalkBack Androidilla. Ne eivät ole keskenään vaihdettavissa, ja kysely, joka tuottaa erinomaisen tulostuksen yhdelle, voi olla lukukelvoton toiselle.

Navigointi otsikon avulla. Kaikki neljä ohjelmaa tarjoavat otsikonavigointinäppäimen (H JAWS:ssa ja NVDA:ssa, Rotor VoiceOverissa, lueminohjaus-vaihto TalkBackissa). Jotta pitkä tekoälyvastaus olisi navigoitavissa, mallin on lähetettävä todelliset semanttiset otsikot — joko markdown-renderöintiputken kautta, joka muuntaa ne <h2>/<h3>-elementeiksi asianmukaisella tasojen sisäkkäisyydellä, tai chat-pinnan jäsennellyn vastauksen API:n kautta. Malli, joka “jäsentelee” vastauksensa lihavoimalla jokaisen kappaleen kolme ensimmäistä sanaa, on tuottanut jotain, joka näyttää jäsennellyltä visuaalisesti mutta on täysin litteä ruudunlukuohjelmalle.

Navigointi listan avulla. Listat ovat hyödyllisiä puhutussaa tulostuksessa juuri siksi, että ruudunlukuohjelma ilmoittaa lukumäärän (“lista, jossa seitsemän kohtaa”) ja antaa käyttäjän astua eteenpäin listakohta-navigointinäppäimellä (I NVDA:ssa, L JAWS:ssa). Mutta tämä toimii vain jos lista on todellinen <ul> tai <ol>. “Lista”, joka tuotetaan lähettämällä bullet-merkit jokaisen rivin alussa ilman listawrapperia, luetaan tavallisena proosana selittämättömällä “musta ympyrä”- tai “piste”-välihuudahduksella jokaisella rivillä.

Osion ohittaminen. Pitkämuotoiset tekoälyvastaukset — selitykset, vertailut, koodi ja kommentit, monivaiheisset ohjeet — tarvitsevat tavan, jolla ruudunlukuohjelmakäyttäjä voi hypätä haluamaansa osioon kuuntelematta johdantoa läpi. Tämä on yksittäinen vaikein asia suunnitella hyvin, koska mallin on tuotettava navigoitava rakenne ja chat-pinnan on renderöitävä se tavalla, jonka käyttöjärjestelmä tarjoaa avustavalle teknologialle, ja ruudunlukuohjelma on oltava asetettu käyttämään otsikonavigointinäppäintä kyseisessä pinnassa. Kaikki kolme asiaa epäonnistuvat käytännössä; yleensä se on keskimmäinen.

Ääntämisvihjeet. Syntetisoidut äänet kompastuvat teknisiin termeihin, sekabukstaimen akronyymeihin, URL-osoitteisiin, kooditunnisteisiin, matemaattiseen merkintöihin ja muunkielisiin nimiin. Hyvin suunniteltu malli kirjoittaa ruudunlukuohjelmakontekstin vastauksissa akronyymit auki ensimmäisellä kerralla (“WCAG, Verkkosisällön saavutettavuusohjeet”), laajentaa lyhenteet, joita syntetisaattori ei pysty lausumaan, ja välttää raakojen URL-osoitteiden upottamista juoksevaan proosaan, jossa synth lukee kauttaviivat ääneen. Yksikään suurimmista tuotteista ei tee tätä johdonmukaisesti vuonna 2026.

Miten tuotteet käsittelevät sitä

Vuoden 2026 puolivälissä suuret generatiiviset tekoälytuotteet ovat ottaneet selvästi erilaisia kantoja ruudunlukuohjelman tietoiseen tulostukseen. Yksikään niistä ei ole ratkaissut sitä. Kehitys on nopeampaa kuin kaksitoista kuukautta sitten, mutta kuilu parhaan ja huonoimman välillä on edelleen suuri.

ChatGPT (OpenAI). Verkkoasiakas toimittaa nyt “tiivis tila” -kytkimen, joka lyhentää oletusarvoisia vastauksia ja vähentää markdown-koristelua. Vuonna 2024 esitelty ja vuonna 2025 merkittävästi päivitetty äänitila on lähimpänä mitä mikään suuri tuote on tullut ruudunlukuohjelmalle natiiviin käyttöliittymään, koska se ohittaa visuaalisen chatin kokonaan ja toimittaa puhutun vastauksen stop-, replay- ja “sano uudelleen” -eleellä. Mukautettujen ohjeiden kenttä sallii ruudunlukuohjelmakäyttäjien ilmoittaa mieltymyksensä kerran ja soveltaa niitä istuntoihin, mikä on käyttäjälähtöinen kiertotie, johon yhteisö on asettunut. Jäljelle jäävät puutteet: GPT-mallit oletavat silti ajatusviiva-rikkaan proosan ellei toisin neuvota, ja markdown-tasoisesti lähetetty otsikkorakenne ei aina kartoitu siististi ARIA:ksi chat-pinnassa.

Claude (Anthropic). Clauden järjestelmäkyselyn kuri on siirtynyt lähimmäksi yllä kuvattuja käytäntöjä. Malli on vuonna 2026 selvästi vähemmän ajatusviiva-altis kuin GPT-linja, oletuksena lyhyempiä vastauksia, ja reagoi hyvin järjestelmäkyselyohjeisiin kuten “puhut ruudunlukuohjelmakäyttäjälle; älä käytä ajatusviivoja, suosi lyhyitä kappaleita ja käytä todellisia otsikoita tai numeroituja listoja kun rakenne on tarpeen.” Claude.ai-chat-pinta renderöi markdownin semanttiseksi HTML:ksi asianmukaisilla otsikkotasoilla, mikä saa otsikonavigointinäppäimen toimimaan. Äänituloste kolmannen osapuolen integraatioiden kautta on olemassa mutta vähemmän kehittynyt kuin ChatGPT:n ensimmäisen osapuolen äänitila.

Gemini (Google). Tiukka integraatio TalkBackin kanssa Androidilla on Geminin rakenteellinen etu; malli voi siirtyä käyttöjärjestelmätason ruudunlukuohjelmalle Androidin saavutettavuuspalvelujen kautta tavalla, jota iOS- ja verkkokilpailijat eivät pysty. “Hei Google, kysy Geminiltä…” -virta saavutettavissa Android-laitteissa on joillekin käyttäjille luontevin käytettävissä oleva tekoäly-plus-ruudunlukuohjelma-kokemus. Jäljelle jäävät puutteet: verkkoliittymä koristaa edelleen vastauksia liikaa, Geminin verkkovanstauksien otsikkohierarkia on epäjohdonmukainen, ja malli on alttiimpi tuottamaan koristelevia emojeja kuin kilpailijansa.

Be My AI (Be My Eyes + OpenAI). Tämä on neljästä kapein — visuaalinen kuvaamisavustaja, joka käyttää GPT-4-luokan näkömallia kuvaamaan kuvia ja ympäristöjä sokeille ja heikkonäköisille käyttäjille. Se on myös ainoa tässä listassa oleva tuote, joka on suunniteltu alusta alkaen ruudunlukuohjelmakäyttäjää ensisijaisena kohderyhmänä. Be My AI:n kyselysuunnittelu on alalla selkein osoitus siitä, miltä avustavan teknologian tietoinen tuloste näyttää käytännössä: kuvaukset avautuvat yhden lauseen tiivistelmällä, johon käyttäjä voi pysähtyä, jatkuvat jäsennellyllä yksityiskohdalla vain pyydettäessä, ja välttävät tilatermejä (“vasemmalla”, “yläpuolella”), jotka vaativat näkevää kontekstia tulkitsemiseen. Tuote pysyy vuonna 2026 lähimpänä sitä, mitä alalla on referenssitoteutuksena.

Kaikkia leikkaava havainto on, että neljä tuotetta ovat edistyneet helpommissa osissa — lyhyemmät vastaukset, vähemmän ajatusviivoja, mukautettujen ohjeiden kenttä — ja ovat tuskin aloittaneet vaikeammissa osissa. Vaikeat osat ovat alla.

Avoimet UX-ongelmat, joita kukaan ei ole ratkaissut

Ruudunlukuohjelman tietoisen kyselysuunnittelun kirjallisuus kokoontuu neljään avoimeen UX-ongelmaan, joissa oikeaa vastausta ei vielä tiedetä. Yksikään niistä ei ole mallikyvykkyysongelmia; kaikki ovat vuorovaikutussuunnittelun ongelmia, jotka istuvat suuren kielimallin, chat-pinnan, käyttöjärjestelmän ja ruudunlukuohjelman välillä.

Keskeyttämismahdollisuus. Näkevä käyttäjä voi silmäillä suuren kielimallin vastauksen noin kahdessa sekunnissa ja päättää, lukeeko sen. Ruudunlukuohjelmakäyttäjä ei voi. Jos vastaus on väärä tai epäosuva, käyttäjän on kuunneltava riittävästi tietääkseen sen, sitten keskeyttää. Äänitiloissa on stopin painike. Tekstitiloissa yleensä ei ole — vastaus virtaa sisään ja ruudunlukuohjelma ilmoittaa siitä uutena sisältönä sen saapuessa, eikä käyttäjällä ole siistiä tapaa sanoa “lopeta generointi, tämä ei ole mitä kysyin.” Be My AI -sovellus käsittelee tämän parhaiten; verkko-chat-asiakkaat käsittelevät tämän huonoiten.

Toista viimeinen vastaus valittavalla tarkkuudella. Pyytäminen ruudunlukuohjelmaa lukemaan viimeinen vastaus uudelleen on helppoa jos vastaus on lyhyt. Se on käyttökelvoton jos vastaus on kuusi kappaletta ja käyttäjä haluaa kuulla vain kolmannen kappaleen uudelleen. Yhteisön pyytämä vuorovaikutus on “toista viimeinen listakohta”, “toista viimeinen otsikko-osio”, “toista viimeinen koodilohko.” Tämä vaatii, että chat-pinta paljastaa rakenteen ruudunlukuohjelmalle tavalla, jota ruudunlukuohjelman omat uudelleenlukukomennot voivat käsitellä. Vuonna 2026 yksikään suurimmista tuotteista ei tee tätä; käyttäjän on käytettävä ruudunlukuohjelman omaa rivi kerrallaan -navigointia, joka on vaivalloista.

Navigointi osion mukaan puhutussa tulostuksessa. Äänitiloissa ei ole otsikonavigointinäppäintä. Käyttäjä kuuntelee neljän minuutin vastausta lineaarisesti ilman mahdollisuutta hypätä “yleiskatsaus”-osiosta “yksityiskohdat”-osioon kelaamatta ajan mukaan. Prototyypitettävät vuorovaikutussuunnittelut — puhuttu “osiolista”, jota käyttäjä voi navigoida nuolinäppäimillä, “siirry osioon kolme” -äänikomento, “anna vain otsikot” -tila — ovat varhaisia. Be My AI -sovelluksen “lisää yksityiskohtia väreistä” -jatkokysymys on lähimpänä toimivaa versiota tästä toimitettavassa tuotteessa.

Avustavan teknologian siirtymäkysymys — milloin tekoäly puhuu versus lukee sisällön ääneen? Tämä on syvin suunnittelukysymys. Jos ruudunlukuohjelmakäyttäjä avaa tekoälyavustajan verkkosivulla, kuka puhuu — tekoälyn oma ääni (TTS-taso), vai käyttäjän asennettu ruudunlukuohjelma lukemassa tekoälyn tekstituloste? Kahdella äänellä on erilaiset asetukset, erilaiset puhenopeudet, erilaiset ääntämisvihjeet, erilaiset stop-ja-toista-eleet. Kaksi järjestelmää, jotka yrittävät puhua samaa sisältöä samanaikaisesti, ei tuota mitään käyttökelpoista. Kehittyvä käytäntö on: äänitilaiset vuorovaikutukset käyttävät tekoälyn omaa TTS:ää ja eksplisiittisesti tukahduttavat ruudunlukuohjelman; tekstitilaiset vuorovaikutukset lähettävät semanttisen HTML:n ja antavat ruudunlukuohjelman puhua. Mutta raja kahden tilan välillä ei ole aina selkeä — kuvankuvaus, koodintuotto, matemaattinen merkintä ja monimoodiset vastaukset istuvat kaikki kömpelösti äänen ja tekstin välissä — ja tuo raja on se, missä useimmat live-UX-ongelmat elävät.

Minne se menee seuraavaksi

Kuri on suunnilleen siinä vaiheessa, missä verkkosaavutettavuus oli noin vuonna 2002 — “onko tämä todellinen ongelma?” -vaiheen ohi, “onko kukaan vastuussa?” -vaiheen ohi, “mitkä ovat todelliset säännöt?” -vaiheeseen. Kolme asiaa tapahtuu todennäköisesti 2026 ja 2027 aikana.

Ensinnäkin mallinrakentajat kodifioivat sisäiset ruudunlukuohjelmakyselynsä ja julkaisevat ne, samoin kuin Anthropic julkaisee Clauden järjestelmäkyselyt VPAT-tyylisiä saavutettavuusselosteita vastaavissa dokumenteissa ja OpenAI on alkanut dokumentoida GPT:n käyttäytymiseen liittyviä oletuksia. Yhteisö pyytää vastaavaa mallikortille — “ruudunlukuohjelman tulostekortille” — joka nimeää käytännöt, joita tietty malli on koulutettu tai järjestelmäkyselyllä noudattamaan.

Toiseksi chat-pinnat — verkkoasiakkaat, mobiilisovellukset, IDE-integraatiot — saavat asianmukaiset semanttis-HTML-renderöintiputket ja asianmukaisen ARIA-paljastamisen chat-historialle, ja navigointinäppäimet yhdistettynä käyttöjärjestelmätason ruudunlukuohjelmaan. Tämä on puudukas työ, ja se on työ, joka siirtää neulaa eniten päivittäisille käyttäjille.

Kolmanneksi ruudunlukuohjelmamyyjät itse — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — alkavat toimittaa tekoälytietoisia ominaisuuksia: natiivi otsikonavigaatio tekoälychat-pinnoissa, standardoitu “lopeta generointi” -ele, älykkäämmät uudelleenlukukomennot, jotka tietävät suuren kielimallin vastausrakenteesta. NVDA:n avoimen lähdekoodin lisäosaekosysteemi tuottaa jo varhaisia versioita näistä. Suljetut ohjelmat ovat hitaampia mutta suunta on sama.

Syvempi havainto on, että ruudunlukuohjelman tietoinen kyselysuunnittelu on lakannut olemasta muutaman sokean kehittäjän kapea huoli ja siitä on tullut jokaisen säännellyille markkinoille toimittavan tekoälytuotetiimin perusodotus. Eurooppalainen esteettömyysdirektiivi koskee “interaktiivisia itsepalvelupäätteitä” ja “interaktiivisella laskentakapasiteetilla varustettuja kuluttajapäätteistöjä” — kategoria, joka lähes varmasti kattaa suuren tekoälyavustajan puhelimella. Avustavan teknologian tietoinen tulostustaso ei ole enää ominaisuus; se on hankintasitova. Tiimit, jotka selvittävät säännöt nyt, toimittavat tuotteet, jotka selviävät 28. kesäkuuta 2025:n jälkeisestä ajasta. Tiimit, jotka käsittelevät sitä jälkiajatuksena, ovat seuraavan EAA-täytäntöönpanotapausten kierroksen materiaalia.

Loppuajatukset

Kuri on pieni, panokset ovat suuret ja säännöt kirjoitetaan edelleen. Jos rakennat suurilla kielimalleilla etkä ole vielä käynyt ruudunlukuohjelmakäyttäjän kanssa keskustelua siitä, miltä tuotteesi todella kuulostaa heidän käyttäessään sitä, se on seuraava asia listalla. Suurin osa siitä, mikä on vialla tekoälyssä ruudunlukuohjelmakäyttäjille vuonna 2026, ei ole mallikyvykkyysongelmia; se on kysely-ja-pinta-suunnitteluongelma, jonka mikä tahansa tuotetiimi voi korjata sprintissä, jos he päättävät tehdä sen.

Yhteisö on ollut antelias ajallaan, testauksellaan ja kärsivällisyydellään. Se myös menettää kärsivällisyyttä nopeammin kuin ennen, koska tuotteet ovat nyt valtavirtaa ja “olemme vielä selvittämässä sitä” -selityksen aika on kulunut umpeen. Kuri on täällä. Käytännöt lähestyvät. Seuraavat kahdeksantoista kuukautta erottavat tiimit, jotka kuuntelivat, tiimeistä, jotka eivät kuunnelleet.