Et svar vokser ord for ord. For seende ligner det fremskridt. Hvis hvert fragment læses op med det samme, kan det samme output føre til konstante afbrydelser. Spørgsmålet er derfor ikke, om en ændring er teknisk synlig, men hvilke oplysninger en person har brug for i det øjeblik.
I succeskriterium 4.1.3 behandler WCAG 2.2 statusmeddelelser, som skal kunne bestemmes programmatisk uden fokusskift. W3C's forklaring nævner også, at unødvendige afbrydelser skal undgås. Det indebærer ikke en generel forpligtelse til at annoncere hvert nygenereret ord enkeltvis. For en AI-chat er det særligt nyttigt at adskille arbejdstilstanden fra svarets indhold.
Tre tilstande i stedet for en endeløs annoncering
Vores egen demonstrationsmodel har tre forståelige situationer: forespørgsel modtaget, svar genereres, svar færdigt. De giver orientering om processen. Selve svarteksten besvarer det indholdsmæssige spørgsmål og bør derefter forblive læsbar i personens eget tempo.
Mens man venter, kan en person gå tilbage til sit eget inputfelt eller læse andre dele af siden. Grænsefladen bør ikke skubbe denne aktivitet til side, blot fordi endnu et stykke tekst er ankommet. Et færdigt svar behøver heller ikke automatisk at overtage tastaturfokus.
Den passende feedback afhænger af tilstanden. En proces, der stadig kører, er noget andet end en fejl, der kræver en ny beslutning. Hvis alle meddelelser præsenteres som lige presserende, forsvinder netop denne prioritering.
Et lille HTML-mønster adskiller indhold og status
Følgende fragment er vores eget og indeholder ingen AI-forbindelse. Det viser kun to områder med forskellige opgaver. Svarområdet rummer teksten, der kan læses senere. Den korte statuslinje formidler den aktuelle tilstand.
<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>W3C-teknikken ARIA22 beskriver role=status med en høflig live region og en annoncering af hele statusindholdet. Vores eksplicitte aria-atomic gør denne hensigt synlig i undervisningsfragmentet. Det er ingen grund til at lægge hele den konstant voksende svartekst ind i den samme korte statusmeddelelse.
En faktisk implementering ville opdatere statuslinjen ved meningsfulde overgange, for eksempel én gang ved starten og én gang efter fuldstændig afslutning. Hvor ofte en fremskridtsmeddelelse ind imellem reelt hjælper, skal testes med det konkrete forløb og med hjælpeteknologi.
Når du tjekker ved at lytte, så tænk også på en person, der allerede læser et andet sted, mens svaret genereres. Skal vedkommende hele tiden starte sin sætning forfra? Kan vedkommende senere bevidst finde det færdige svar? Disse iagttagelser tester mere præcist, hvordan mønsteret bruges, end blot at fastslå, at en annoncering høres et eller andet sted.
Annullering og fejl kræver deres egne ord
Hvis outputtet afbrydes, må „færdig“ ikke blot betyde, at der ikke ankommer flere tegn. En tekst, der bevidst blev stoppet, kan være ufuldstændig. En teknisk fejl kan betyde, at der slet ikke blev produceret et brugbart resultat. Disse forskelle hører hjemme i grænsefladens sprog.
Til et første tjek kan du bruge tre faste eksempeltekster og udløse overgangene manuelt. Iagttag, hvad der annonceres, mens du læser videre, om fokus bliver, hvor det er, og hvordan du kommer til den færdige tekst. Dette er en øvelse, du kan udføre, men den præsenteres her ikke som en bestået skærmlæsertest.
Hvis du forbereder din egen HTML og JavaScript på en KENJTEC-side, er udviklertilstanden i KENJTEC WebSiteBuilder ai tilgængelig til dette, med en sandboxet forhåndsvisning og udgivelse af din egen kode. Du overfører selv komponenten; det skaber ikke en ekstra, integreret AI-chattjeneste.
Den faktiske lytteoplevelse er afgørende
Et skærmbillede kan hverken bevise en afbrydelse eller en uventet annoncering. Test kræver derfor et tastatur og ægte hjælpeteknologi. Notér den anvendte enhed, browser og skærmlæser, hvis du senere rapporterer om et konkret resultat.
Selv et godt statusmønster opfylder ikke automatisk alle krav til en tilgængelig chat. Det besvarer et afgrænset spørgsmål: Hvordan bliver arbejdstilstanden forståelig uden at presse indholdet på nogen ord for ord? En god løsning bevarer begge dele: pålidelig orientering og personens kontrol over sit eget læsetempo.
Kilder og status
Research og dokumentation pr. 25. oktober 2026. Forståelse af SC 4.1.3: Statusmeddelelser · ARIA22: Brug af role=status til at præsentere statusmeddelelser.
