Rekommendationer för kodning av förändringar utanför fokusLänk hit

• Markera med aria-kod de områden där statusmeddelanden kan presenteras.
• Använd gärna samma teknik även för andra viktiga förändringar.
• Använd aria med försiktighet så att du inte stör användaren.

Markera med aria-kod de områden där statusmeddelanden kan presenterasLänk hit

Termen statusmeddelande har en specifik betydelse i WCAG: Den syftar på viktiga meddelanden (information om resultat av en åtgärd, om väntetid eller om felmeddelanden) som presenteras någon annanstans än där användarens fokus (tangentbordsfokus, för närvarande uppläst text eller inzoomat område) för närvarande befinner sig. Se exempel nedan.

Använd aria-kod för att märka upp de områden där sådan information kan presenteras. Hjälpmedel – framförallt skärmläsare – presenterar då förändringar för användaren.

Använd i första hand någon av de standardtyper av “levande områden” (på engelska “live regions”) som finns, med hjälp av aria-attributet role:

• Attributet role=”alert” används för viktiga brådskande meddelanden som behöver presenteras direkt i sin helhet av hjälpmedel.
• Attributet role=”status” används för viktiga men inte brådskande meddelanden som presenteras i sin helhet av hjälpmedel när tid finnes.
• Attributet role=”log” 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.
• Attributet role=”marquee” används för områden som förändras men inte nödvändigtvis i slutet. Förändringarna presenteras i regel inte av hjälpmedel.
• Attributet role=”timer” används för områden som innehåller en tidsangivelse som kontinuerligt eller regelbundet uppdateras. Förändringarna presenteras i regel inte av hjälpmedel.

Om ingen av dessa passar kan du istället styra i detalj hur förändringar ska hanteras i hjälpmedel.

Aria-live används för att ange om och i så fall när informationen ska presenteras:

• Attributet aria-live=”assertive” 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.
• Attributet aria-live=”polite” 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.
• Attributet aria-live=”off” anger att innehållet inte ska presenteras av hjälpmedel.

Följande attribut ger ytterligare möjlighet att ytterligare påverka presentationen:

• Attributet aria-atomic=”true” 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).
• Attributet aria-busy=”true” 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.
• Attributet aria-relevant=”additions” anger att hjälpmedel bara ska informera användaren när nya html-element tillkommer i området.
• Attributet aria-relevant=”removals” anger att hjälpmedel bara ska informera användaren när innehåll avlägsnas från området.
• Attributet aria-relevant=”text” anger att hjälpmedel bara ska informera användaren när textförändringar sker i området.
• Attributet aria-relevant=”all” anger att hjälpmedel ska informera användaren oavsett vilka förändringar det rör sig om.

Använd aria med försiktighet så att du inte stör användarenLänk hit

Den första riktlinjen i WAI-Aria Authoring Practices 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 användaren.

Dessutom finns det vissa dynamiska förändringar som inte räknas som statusmeddelanden och som inte bör ha något annat värde på aria-live än standardvärdet off. Till exempel följande:

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 användaren 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) 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). Dessutom ska skräddarsydda komponenter ges en roll, ett, värde och namn enligt WCAG 4.1.2 så att användaren ändå får reda på vad som händer.

Använd gärna samma teknik för andra relevanta förändringar i innehålletLänk hit

Överväg att använda samma teknik till ändringar i innehållet som användaren kan tänkas vilja ha upplysningar om men som egentligen inte krävs för att uppfylla riktlinjen. Till exempel:

• Ett formulärfält frågar hur många barn en person har och användaren skriver in siffran fem varpå sidan uppdateras med ytterligare fem fält för barnens namn. Skärmläsaren meddelar: Fem fält läggs till formuläret.
• En lista med 15 produkter finns på en sida med knappen ”Se fler produkter” längst ner. När användaren klickar på knappen meddelar skärmläsaren: ”Ytterligare 15 produkter läggs till på sidan.”

Exempel på vad uttrycket “statusmeddelanden” kan innebäraLänk hit

Sökresultat

Själva resultatlistan efter en sökning räknas inte som ett statusmeddelande, men om systemet presenterar sökresultaten samtidigt som det visas ett meddelande ovanför träfflistan “Din sökning resulterade i xx träffar.”, då är det meddelandet ett statusmeddelande och skärmläsaren bör läsa upp det.

Uppdatering av kundvagn

När en användare klickar på knappen “Lägg i kundvagnen” ändras en text i närheten av ikonen till kundvagnen ”5 artiklar”. Skärmläsare meddelar användare: ”Fem artiklar” eller ”Kundvagn, fem artiklar”.

Status och felmeddelande i formulär

Efter att en användare skickat in en ansökan visas statusmeddelandet: “Din ansökan har skickats in.” Skärmläsaren meddelar samma sak.

Efter att en användare angett ett felaktig värde i formulärfältet “Postnummer”, visas ett felmeddelande ovanför fältet ”Ogiltig postnummer”. Skärmläsaren bör lämna samma information.

Meddelande om upptagen applikation

När en användare aktiverar en process, till exempel hämtar en fil, visas en ikon på skärmen som symboliserar att servern är upptagen. Skärmläsaren meddelar användaren ”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 kan ge användaren återkommande information om hur långt processen fortskridit, till exempel genom att script med lämpliga intervall uppdaterar värdet på attributet aria-valuenow.

Kodexempel:

<div class="progress">
<div class="progress-bar" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100"></div>
</div>

Utdrag från WCAG-standardenLänk hit

Riktlinje 4.1 Kompatibelt: Maximera kompatibiliteten med nuvarande och framtida användarprogram, inklusive hjälpmedel.

4.1.3 Status Messages In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. (Nivå AA)

TerminologiLänk hit

Förloppsindikator, på engelska progress bar, progress indicator eller progress meter visar användaren hur mycket av en process som är genomförd genom att en list fylls allt eftersom. Ibland anges samtidigt en procentsats för att förtydliga processen. Förloppsindikatorn används ofta för att visa hur långt en nedladdning eller programinstallation har kommit.

Det dragspelsliknande designmönstret accordion skrivs ibland med fransk stavning: accordeon.