Se till att hjälpmedel kan presentera meddelanden som inte är i fokus
Om riktlinjen
- Innehåller lagkrav
- EN 9.4.1.3
- WCAG 4.1.3 (A)
Innehåller lagkravOmråde
När ett viktigt, men inte kritiskt, meddelande visas för personen ska detta meddelande presenteras för olika typer av hjälpmedel, utan att meddelandet får fokus.
Därför behöver hjälpmedel kunna presentera meddelanden som inte är i fokus
De som använder tekniska hjälpmedel som exempelvis skärmläsare och förstoringsprogram behöver göras uppmärksamma på viktiga meddelanden även om de presenteras utanför det område på sidan som personen har i fokus. Berörda personer riskerar annars att missa varningar, upplysningar och felmeddelanden. När en person
- deltar i en chatt,
- fyller i ett formulär eller
- står i kö
behöver hen kunna ta del av nya meddelanden som visas på sidan, men utan att dessa meddelanden får fokus. Detta är extra viktigt när en person använder olika hjälpmedel.
Meddelande om nya chattmeddelanden
När en person chattar är det viktigt att hen kan se nya meddelanden utan att hen behöver flytta sin uppmärksamhet (fokus) från skrivfältet.
I vanliga fall måste personen flytta sin uppmärksamhet till de nya meddelandena för att läsa dem och sedan flytta tillbaka fokus till skrivfältet för att svara, vilket är ganska krångligt.
Därför är det bättre om personen kan fortsätta fokusera på skrivfältet samtidigt som hen tar del av nya meddelanden. För personer som använder hjälpmedel blir det extra svårt att hela tiden byta fokus mellan att skriva och läsa nya meddelanden.
Bekräftelser eller felmeddelanden
När en person fyller i formulär så kan olika typer av meddelanden visas, till exempel bekräftelser eller felmeddelanden.
Dessa meddelanden kan visas samtidigt som personen fyller i, eller så fort hen lämnat, ett formulärelement. Dessa meddeladen behöver personen kunna ta del av utan att uppmärksamheten (fokus) flyttas från det hen gör.
Den som använder hjälpmedel behöver därför få dessa meddelanden utan att fokus flyttas fram och åter mellan formulärelementet och meddelandet.
Meddelande om uppdaterad kundkorg eller köplats
När innehållet i en kundvagn uppdateras eller för att chatta med exempelvis kundtjänst så behöver personen få information om när platsen i kön förändras eller när det är hens tur att köpa eller chatta.
När personen står i kö vill hen samtidigt kunna göra andra saker på sidan, därför är det viktigt att fokus inte flyttas till information om till exempel kötid utan att fokus flyttas från det hen ägnar sig åt.
För personer med hjälpmedel är det extra viktigt att kunna ta del av information utan att bli störd eller avbruten.
Undvik att avbryta i onödan
Generellt så krävs det alltså mer av personer med hjälpmedel för att ta sig tillbaka till det de gjorde om de blir avbrutna när fokus plötsligt och utan förvarning flyttas till ett meddelande som dyker upp samtidigt som de gör något annat. Därför är denna riktlinje viktig för att undvika att – helt i onödan – orsaka besvär för den som använder hjälpmedel.
Vad kräver lagen?
Statusmeddelanden ska presenteras för personer med hjälpmedel utan att meddelandet får fokus.
Termen statusmeddelande har en specifik betydelse i WCAG. Den syftar på meddelanden
- som inte innebär en kontextförändring
- som innehåller information om resultat av en åtgärd, om väntetid eller om felmeddelanden
- som presenteras någon annanstans än där personens fokus befinner sig.
Exempel: statusmeddelanden som behöver presenteras
Exempel på vad uttrycket “statusmeddelanden” kan innebära:
Sökresultat
När systemet presenterar en lista med sökresultat efter en sökning, samtidigt som det visas ett meddelande ovanför träfflistan “Din sökning resulterade i xx träffar”, så är det meddelandet ett statusmeddelande och skärmläsaren ska läsa upp det. Själva resultatlistan räknas inte som ett statusmeddelande.
Uppdatering av kundvagn
När en person klickar på knappen “Lägg i kundvagnen” ändras en text i närheten av ikonen till kundvagnen till ”5 artiklar”. Skärmläsaren ska meddela detta, till exempel: ”Fem artiklar i kundvagnen” eller ”Kundvagn, fem artiklar”.
Status och felmeddelande i formulär
Efter att en person skickat in en ansökan visas statusmeddelandet: “Din ansökan har skickats in.” Skärmläsaren ska meddela samma sak.
Meddelande om felaktigt värde
När en person angett ett felaktigt värde i formulärfältet “Postnummer”, visas ett felmeddelande ovanför fältet: ”Postnummer kan bara innehålla siffror”. Skärmläsaren ska lämna samma information.
Meddelande om upptagen applikation
När en person aktiverar en process, till exempel hämtar en fil, visas en ikon på skärmen som symboliserar att servern är upptagen. Skärmläsaren ska meddela personen detta i stil med ”Applikationen är upptagen”.
Meddelande i en process
En applikation visar en förloppsindikator för att ange status för en pågående uppgradering. Skärmläsaren ska ge personen samma meddelande om status. Det går att ge skärmläsare återkommande information om hur långt processen fortskridit, till exempel genom att med lämpliga intervall uppdatera värdet på attributet aria-valuenow.
.svg)
Exempel på förändringar som inte är statusmeddelanden
Dialogrutor
Dialogrutor får i regel fokus när de visas. Då presenteras innehållet automatiskt av hjälpmedel.
Dynamiska menyer och “dragspel”
När personen interagerar med gränssnittet och innehåll döljs eller exponeras, till exempel när en meny fälls ut, eller när innehåll ligger i ett så kallat dragspel ("accordion") som fälls ut och in, räknas det inte som ett statusmeddelande.
Det är ändå troligt att aria-kodning behövs (till exempel attributet aria-expanded).
Rekommendationer utöver lagkrav
Utöver det lagen kräver finns ett antal tips och rekommendationer för hur du kan arbeta med statusmeddelande för att förbättra digital tillgänglighet.
Markera med aria-kod de områden där statusmeddelanden kan presenteras
ARIA (Accessible Rich Internet Applications)
Länk till annan webbplats. kan användas för att märka upp de områden där statusmeddelanden kan presenteras. Hjälpmedel – framförallt skärmläsare – presenterar då förändringar i området för personen.
Aria-attributet role
Använd i första hand någon av de standardtyper av “live regions”som finns, med hjälp av aria-attributet role:
role=”alert”
Attributet används för viktiga brådskande meddelanden som behöver presenteras direkt i sin helhet av hjälpmedel.
Om role="alert" (MDN Web Docs) Länk till annan webbplats.
role=”status”
Attributet används för viktiga men inte brådskande meddelanden som presenteras i sin helhet av hjälpmedel när tid finnes.
Om role="status" (MDN Web Docs) Länk till annan webbplats.
role=”log”
Attributet används för områden där nya meddelanden successivt läggs till (i slutet). Enbart det nya innehållet presenteras av hjälpmedel, och detta först när tid finnes.
Om role="log" (MDN Web Docs) Länk till annan webbplats.
Om ingen av dessa passar kan du istället styra i detalj hur förändringar ska hanteras i hjälpmedel.
Aria-live
Aria-live används för att ange om och i så fall när informationen ska presenteras:
aria-live=”assertive”
Attributet anger att innehållet ska presenteras omedelbart. Det innebär att pågående uppläsning avbryts. Använd detta alternativ enbart om det verkligen är motiverat.
aria-live=”polite”
Attributet anger att innehållet ska presenteras när det finns tid, till exempel efter att nuvarande mening lästs färdigt, eller när användaren gör en paus under inmatning.
aria-live=”off”
Om aria-live (MDN Web Docs) Länk till annan webbplats.
Attributet anger att innehållet inte ska presenteras av hjälpmedel.
Andra aria-attribut
Följande attribut ger ytterligare möjlighet att ytterligare påverka presentationen:
aria-atomic=”true”
Attributet anger att hela innehållet ska presenteras av hjälpmedel (om attributet saknas eller har värdet “false” presenteras endast den del av innehållet i området som förändrats).
Om aria-atomic (MDN Web Docs) Länk till annan webbplats.
aria-busy=”true”
Attributet anger att förändringar pågår och att hjälpmedel kan vänta med att presentera förändringarna tills värdet (via script) återställs till standardvärdet false.
Om aria-busy (MDN Web Docs) Länk till annan webbplats.
aria-relevant=”additions”
Attributet anger att hjälpmedel bara ska informera användaren när nya html-element tillkommer i området.
aria-relevant=”removals”
Attributet anger att hjälpmedel bara ska informera användaren när innehåll avlägsnas från området.
aria-relevant=”text”
Attributet anger att hjälpmedel bara ska informera användaren när textförändringar sker i området.
aria-relevant=”all”
Attributet anger att hjälpmedel ska informera användaren oavsett vilka förändringar det rör sig om.
Om aria-relevant (MDN Web Docs) Länk till annan webbplats.
Använd aria med försiktighet så att du inte stör användaren
Den första riktlinjen i WAI-Aria Authoring Practices Länk till annan webbplats. kan sammanfattas med att det är bättre att inte använda aria alls än att skriva dålig aria-kod. Om vi exempelvis “för säkerhets skull” sätter aria-live=”assertive” på alla områden som kan komma att uppdateras dynamiskt så kan det resultera i att den som använder hjälpmedel ständigt blir avbruten och i praktiken inte kan använda sidan.
Var därför försiktig med att använda aria, och fundera på vilken information som verkligen måste presenteras för personen.
Dynamiska förändringar som inte räknas som statusmeddelanden
Dialogrutor
Dialogrutor får i regel fokus när de visas, och därmed presenteras innehållet automatiskt av hjälpmedel.
Dynamiska menyer och “dragspel”
När personen interagerar med gränssnittet och innehåll döljs eller exponeras, till exempel genom att fälla ut en meny, eller när delar av innehållet ligger i ett så kallat dragspel (accordion) Länk till annan webbplats. som kan dras ut eller in, räknas det inte som ett statusmeddelande.
Det är ändå troligt att aria-kodning behöver uppdateras (till exempel attributen aria-expanded och aria-collapsed).
Utdrag ur WCAG
WCAG 4.1.3 (A) Statusmeddelanden
Statusmeddelande kan märkas upp programmatiskt med hjälp av roll eller egenskaper så att de presenteras av hjälpmedel för användare utan att få fokus.
Originaltext på engelska: Success Criterion 4.1.3 Status Messages (w3.org) Länk till annan webbplats.
Därför länkar vi till WCAG på svenska och engelska.
Ditt svar hjälper oss att förbättra sidan
Senast uppdaterad: