Statusmeddelanden

Vad det kräver

När sidan talar om för användaren att något hänt – “Artikel tillagd i kundvagnen”, “3 resultat hittades”, “Anslutningen bröts”, “Sparar…” – måste det meddelandet nå skärmläsaranvändare utan att tvinga fokus att flytta sig. Informationen måste vara programmässigt fastställd som en status, så att hjälpmedelsteknik kan fånga upp och annonsera den.

Tre kategorier som WCAG lyfter fram:

• Framgång / slutförande – “Profil sparad”, “E-post skickad.”
• Resultat av en åtgärd – “12 resultat”, “Inga träffar hittades.”
• Applikationsstatus – “Sparar…”, “Återansluter”, “Uppladdning 40 %.”

Hur man uppfyller det

• Placera en live-region i DOM:en vid sidinläsning – ett tomt element med role="status" (artig) eller role="alert" (påträngande). Skriv in ny text vid uppdatering.
• För icke-kritiska bekräftelser och resultatantal, använd role="status" eller aria-live="polite". Skärmläsare väntar tills användaren är inaktiv och annonserar sedan.
• För kritiska meddelanden – formulärinskickningsfel, förlorad anslutning, session nära utgång – använd role="alert" eller aria-live="assertive". Annonseringen avbryter.
• Toast-notiser behöver en live-region. Toast-behållaren bör finnas i DOM:en innan toasten visas, med aria-live inställt, och toast-texten injiceras som ett underordnat element.
• Para aria-live med aria-atomic="true" om du vill att hela regionen läses om vid varje uppdatering, inte bara de ändrade noderna.
• För formulärfel kan det inbyggda felmeddelandet använda role="alert", eller fokus kan flyttas till en sammanfattning överst i formuläret – men gör inte båda; användare behöver bara höra det en gång.

Vanliga fel

• Toast-notiser renderade i ett element som inte existerade innan toasten – live-regionlyssnaren kopplas aldrig, inget annonseras.
• En framgångsbanner som infogas men lever utanför en aria-live-region – synlig för seende användare, osynlig för skärmläsaranvändare.
• Antal sökresultat (“Visar 12 av 340”) som uppdateras tyst efter filtrering. Användare tabbar tillbaka till resultaten osäkra på om något ändrats.
• Formulärvalidering som uppdaterar ett inbyggt <span class="error"> utan role="alert" eller aria-live – felet visas, skärmläsaren förblir tyst.
• Användning av aria-live="assertive" för varje statusuppdatering. Konstanta avbrott; skärmläsaranvändare inaktiverar sidan.
• Att flytta fokus till ett statusmeddelande som inte är en rubrik eller interaktivt – fokus hamnar på ett element utan tabb-möjlighet, tangentbordsanvändare tappar bort sig.
• “Sparar…” / “Sparat”-indikatorer som växlar en CSS-klass men aldrig uppdaterar något textinnehåll inuti en live-region.

Varför det är viktigt

Statusmeddelanden är där moderna single-page-applikationer faller. Sidan laddas aldrig om, fokus flyttas sällan, och användarens enda signal om att något hänt är en visuell förändring – meningslös för den som inte tittar på skärmen. 4.1.3 tvingar fram paritet: om en seende användare kan se “Tillagd i kundvagnen” kan en skärmläsaranvändare höra det. Lösningen är nästan alltid billig (en live-region, ifylld vid uppdatering) och dess frånvaro bryter nästan alltid centrala flöden – kassa, sökning, formulärinskick, realtidschatt.