Statusmeddelanden i webbutiken: besked som hörs

31 oktober 2026

Lagd i varukorgen, antal träffar, laddar och rabattkod: så får skärmläsaren höra beskeden utan att fokus flyttas. WCAG 4.1.3 med kodexempel och tester.

Det här är teknisk vägledning och inte juridisk rådgivning. För tolkningsfrågor om Lag (2023:254) om vissa produkters och tjänsters tillgänglighet, vänd dig till Post- och telestyrelsen (PTS).

Kunden trycker på Lägg i varukorgen. Siffran vid varukorgen ändras från 2 till 3 och en liten ruta visar en stund att jackan är tillagd. Den som ser skärmen märker det direkt. Den som använder skärmläsare hör ingenting och vet inte om knappen gjorde något. Kriteriet Statusmeddelanden (4.1.3, nivå AA) handlar om just det. Guiden går igenom var det händer i en webbutik och hur du rättar det. Punkten finns i checklistans grupp Hela butiken.

Vad kriteriet kräver

W3C:s definition av ett statusmeddelande har två villkor. Meddelandet ger information om resultatet av en handling, om att något väntar, om hur långt en process har kommit eller om att fel finns. Och det levereras utan ändrat sammanhang, alltså utan att ta fokus. Uppfyller texten båda villkoren ska den gå att avgöra programmatiskt med en roll eller en egenskap, så att en skärmläsare kan läsa upp den utan att kunden flyttar fokus dit.

W3C:s egna exempel ligger nära butiken: efter Lägg i varukorgen får texten vid varukorgsikonen ett nytt antal, efter en sökning visas ”18 results returned”, och en förloppsindikator berättar hur långt en uppdatering har kommit. Själva sökresultaten räknas däremot inte som statusmeddelande, bara den korta texten om dem.

Flera saker faller utanför. En dialog som tar fokus är redan ett ändrat sammanhang och skärmläsaren läser upp den. Menyer, dragspel och flikar som fälls ut hör till Namn, roll, värde (4.1.2), där tillståndet utfälld eller hopfälld ska kunna läsas av. Nya fält som läggs till i ett formulär efter ett val är inte heller statusmeddelanden.

Var det händer i en butik

Lagd i varukorgen. Produktsidan ligger kvar, varukorgsikonen får en ny siffra och kanske visas en ruta. Utan uppmärkning får skärmläsaren ingenting. Det är det vanligaste felet och det kunden märker mest.

Antal träffar. När filter eller sortering ändrar listan utan sidladdning behövs en mening som ”24 produkter” i en statusbehållare. Det går vi inte igenom här. Läs avsnittet ”Listan uppdateras utan besked (4.1.3)” i guiden Sök och filter i webbutiken.

Laddar och väntan. En snurra som visas medan frakten räknas om är ett väntläge. Om snurran är en bild utan text finns inget för skärmläsaren att läsa. Skriv en text som ”Räknar om frakten” i statusbehållaren och ta bort den när beräkningen är klar.

Rabattkod och frakt i kassan. ”Rabattkoden godkändes” och ”Frakt: 59 kr” dyker upp bredvid fältet eller i ordersammanfattningen. Båda är resultat av en handling och ska läsas upp. Att koden inte gick att använda är också ett statusmeddelande, eftersom W3C räknar besked om fel dit, och felmeddelandet ska dessutom följa kraven i 3.3.1. Där finns mer i guiden Formulär och felmeddelanden i kassan.

Lagerbesked. ”Bara 2 kvar i din storlek” som uppdateras när kunden byter variant är ett statusmeddelande om texten byts utan sidladdning.

Så gör du

W3C:s teknik ARIA22 använder rollen status. Elementet får implicit aria-live polite och aria-atomic true enligt WAI-ARIA 1.2, vilket betyder att skärmläsaren väntar tills den är klar med det den läser och sedan läser upp hela behållarens innehåll. ARIA22 tillägger att aria-atomic bör anges uttryckligen eftersom rollen i vissa miljöer inte behandlas som atomär som standard.

Rollen alert är en assertive live region och avbryter det skärmläsaren håller på med. WAI-ARIA 1.2 beskriver den som avsedd för viktig och oftast tidskritisk information. Använd status för det som är besked i förbigående, till exempel lagd i varukorgen, och spara alert för det som kunden måste få veta direkt. Rollen log (ARIA23) passar när nya rader läggs till i en historik, till exempel en chatt, och är sällan aktuell i en butik.

Behållaren ska finnas i sidan redan när den laddas, tom, och det är texten i den som byts. W3C skriver det som krav i tekniken för role=alert (ARIA19), och eftersom en live region fungerar likadant tillämpar vi samma försiktighet på status. Skapas elementet först samtidigt som texten läggs in kan skärmläsaren missa att något hände. Det är vår rekommendation för status, inte ett uttryckligt krav i ARIA22.

Så här kan Lägg i varukorgen se ut:

<button type="button" id="kop">Lägg i varukorgen</button>
<div id="besked" role="status" aria-atomic="true"></div>

<script>
  let antal = 0;
  document.querySelector("#kop").addEventListener("click", () => {
    antal += 1;
    document.querySelector("#besked").textContent =
      "Jackan lades i varukorgen. Varukorgen innehåller " + antal +
      (antal === 1 ? " vara." : " varor.");
  });
</script>

Vi provkörde exemplet i Chromium. Efter första klicket stod texten ”Jackan lades i varukorgen. Varukorgen innehåller 1 vara.” i behållaren, efter andra klicket 2 varor, och document.activeElement var hela tiden knappen. Fokus flyttades alltså inte. Hur en skärmläsare läser upp texten kan vi inte prova här, så den delen är obekräftad.

Några regler som sparar dig problem:

Skriv en hel mening som går att förstå utan skärmen. ”3” säger ingenting, ”Varukorgen innehåller 3 varor” gör det.
Ha en behållare per slags besked och inte en per produkt eller rad. W3C:s fel F103 gäller meddelanden som saknar roll, men för många live-regioner som talar samtidigt gör sidan svår att följa. Det är vår bedömning.
Flytta aldrig fokus bara för att meddelandet ska höras. Då blir det ett ändrat sammanhang och inte ett statusmeddelande.
Låt den synliga texten och den uppläsna vara samma text. Den som både ser och lyssnar ska inte få två olika besked.

Använder du ett bibliotek för små meddelanderutor, kontrollera vad rutan får för roll i den färdiga sidan och inte vad dokumentationen lovar.

Så testar du

Börja utan skärmläsare. Öppna sidan, högerklicka på meddelandet och välj Inspektera. Har elementet role status, alert eller log, eller aria-live? Fanns det i sidan innan du tryckte på knappen, eller skapades det av tryckningen?

Sedan med tangentbord: tryck på knappen med Enter och kontrollera att fokus ligger kvar där. Flyttas det är något fel.

Till sist med skärmläsare, på dator och i mobil. Lyssna efter att beskedet läses upp av sig självt, utan att du flyttar dig, och att meningen går att förstå. Upprepa för varje besked i listan ovan. Hörs inget, eller läses beskedet bara upp första gången, är det ett fel.

W3C:s testprocedur för F103 går i samma ordning: kontrollera att innehållet inte tar fokus, att det är ett resultat, ett väntläge, ett förlopp eller ett fel, att elementet saknar roll status, alert eller log och aria-live, och att skärmläsaren inte läser upp det. Är alla fyra sanna har sidan ett fel mot kriteriet.

Vad AccessAudit kontrollerar

Det gratis testet på butik.nightwave.se/tillganglighet läser källkoden på upp till fem sidor och ser inte besked som visas efter ett klick. Månadsgranskningen kör axe-core i en riktig webbläsare, och axe-core 4.11 har ingen regel som bevisar 4.1.3. Granskningen har en egen kontroll som rör kriteriet: den skickar formulär tomma utan att något går iväg och larmar när ett synligt felmeddelande dyker upp utan aria-invalid, role="alert", aria-live eller flyttat fokus. Lagd i varukorgen, antal träffar, laddar, rabattkod och lagerbesked prövas inte, så de kontrollerna i guiden är dina egna. Det är en teknisk granskning mot WCAG och inte juridisk rådgivning.

Börja här

Gör testet med Lägg i varukorgen först, eftersom det är det kunder oftast gör.
Lägg en tom behållare med role status i sidan och byt texten i den vid varje besked.
Kontrollera rabattkod, frakt och lagerbesked i kassan och på produktsidan på samma sätt.
Lyssna med en skärmläsare minst en gång innan du bedömer att det fungerar.

Källor

Alla källor lästa 2026-10-30.