Statusbeskeder

Hvad det kræver

Når siden fortæller brugeren, at noget er sket — „Vare lagt i kurv“, „3 resultater fundet“, „Forbindelse mistet“, „Gemmer…“ — skal den besked nå frem til skærmlæserbrugere uden at tvinge fokus til at flytte sig. Oplysningerne skal programmatisk bestemmes som en status, så hjælpeteknologi kan opfange og annoncere dem.

Tre kategorier, som WCAG fremhæver:

• Succes / afslutning — „Profil gemt“, „E-mail sendt“.
• Resultater af en handling — „12 resultater“, „Ingen matches fundet“.
• Programmets tilstand — „Gemmer…“, „Genopretter forbindelse“, „Upload 40 %“.

Sådan opfyldes det

• Placer en live-region i DOM’en ved sideindlæsning — et tomt element med role="status" (høflig) eller role="alert" (assertiv). Skriv den nye tekst ind i det ved opdatering.
• For ikke-kritiske bekræftelser og resultatantal: brug role="status" eller aria-live="polite". Skærmlæsere venter, til brugeren er inaktiv, og annoncerer derefter.
• For kritiske beskeder — formularindsendingsfejl, mistet forbindelse, session ved at udløbe — brug role="alert" eller aria-live="assertive". Annonceringen afbryder.
• Toast-notifikationer kræver en live-region. Toast-containeren skal eksistere i DOM’en, inden toasten vises, med aria-live sat, og toast-teksten injiceret som et underordnet element.
• Kombinér aria-live med aria-atomic="true", hvis hele regionen skal genlæses ved hver opdatering, ikke kun de ændrede noder.
• For formularfejl kan den indlejrede fejlbesked bruge role="alert", eller fokus kan flyttes til en opsummering øverst i formularen — men gør ikke begge dele; brugerne behøver kun at høre det én gang.

Hyppige fejl

• Toast-notifikationer gengivet i et element, der ikke fandtes før toasten — live-region-lytteren tilknyttes aldrig, intet annonceres.
• Et succesbanners, der indsættes, men ligger uden for enhver aria-live-region — synlig for seende brugere, usynlig for skærmlæserbrugere.
• Antal søgeresultater („Viser 12 af 340“), der opdateres stille efter filtrering. Brugere navigerer tilbage til resultaterne uden at vide, om noget er ændret.
• Formularvalidering, der opdaterer et indlejret <span class="error"> uden role="alert" eller aria-live — fejlen vises, skærmlæseren forbliver tavs.
• Brug af aria-live="assertive" til enhver statusopdatering. Konstante afbrydelser; skærmlæserbrugere deaktiverer siden.
• Flytning af fokus til en statusbesked, der ikke er en overskrift eller interaktiv — fokus lander på et element uden tab-fokus, og tastaturbrugere mister deres sted.
• „Gemmer…“ / „Gemt“-indikatorer, der skifter en CSS-klasse, men aldrig opdaterer noget tekstindhold inden i en live-region.

Hvorfor det er vigtigt

Statusbeskeder er der, hvor moderne single-page-applikationer fejler. Siden genindlæses aldrig, fokus flyttes sjældent, og brugerens eneste signal om, at noget er sket, er en visuel ændring — ubrugelig for alle, der ikke kigger på skærmen. 4.1.3 sikrer paritet: hvis en seende bruger kan se „Lagt i kurv“, kan en skærmlæserbruger høre det. Løsningen er næsten altid billig (én live-region, der udfyldes ved opdatering), og fraværet af den bryder næsten altid centrale forløb — betaling, søgning, formularindsendelse, realtidschat.