Toastmeddelanden

Toast-meddelanden är små flytande popup-fönster som visas längst ned på skärmen i några sekunder. Meddelandet som visas i en toast är i regel kort information som exempelvis en bekräftelse på att något har gått bra eller att något har misslyckats. Detta kan ofta skapa problem tillgänglighetsmässigt, särskilt eftersom meddelandet i regel enbart visas några sekunder och sedan försvinner automatiskt.

När ett statusmeddelande visas på skärmen ska användaren få information om det utan att behöva flytta sig till ett annat område på sidan. Exempel på statusändringar kan vara:

• En förändring i en pågående process

• Det visas ett meddelande med antalet sökträffar

• Live-validering i formulär

Den här typen av ändringar ska meddela användaren utan att fokus för hjälpmedlet eller tangentbordsnavigeringen flyttas. Ett sätt att göra det är genom att använda aria-live.

Rekommendation:

UX-ramverket avråder från att använda toast-meddelanden om det inte verkligen behövs. Detta på grund utav att det finns många saker som kan gå fel tillgänglighetsmässigt med toastmeddelanden. Överväg gärna andra alternativ för att visa att förändringar har inträffat på sidan eller statusmeddelanden som säger att något har gått bra eller misslyckats.

Mer information om toastmeddelanden/ statusmeddelanden finns att läsa om här:

• Defining ‘Toast’ Messages

• Understanding Success Criterion 4.1.3: Status Messages | WAI | W3C

Områden som måste beaktas för att uppnå tillgänglighetskraven

Om man nu ska använda toastmeddelanden i sin tjänst/system så måste man ha tillgänglighetsaspekterna i åtanke. Detta dokument kommer ta upp A och AA-krav från WCAG som ingår i dos-lagen.

Tidsaspekt

Toastmeddelanden visas bara en kort stund, det går dock att konfigurera så meddelandet ska visas en längre tid. Man kan ge användaren valmöjligheten att i förväg anpassa hur länge ett meddelande ska visas eller så kan man sätta en längre tid som meddelandet ska visas för användaren som default.

Flera toast på varandra

Som fortsättning på föregående punkt så kan man förlänga tiden på toastmeddelanden, men en annan aspekt är att toastmeddelanden har en tendens att lägga sig ovan på varandra som kan sluta med en lång pelare av toastmeddelanden.  Detta kan bli ett bekymmer för bland annat användare som använder skärmläsare då det förväntas att skärmläsaren läser upp dessa meddelanden utan att komponenten får fokus (liknande som en alert). En alert läses upp när den visas på skärmen, detta kan göras med en aria-role eller aria-live. Vissa role och live aria attribut kan upplevas aggressivare som kommer avbryta det användaren läser aktuellt och istället läsa upp det nya meddelandet eller förändringen. Aria-Live=”Polite” ger där emot användaren tid att slutfölja det som läsas aktuellt och när den läsningen är klar så läses meddelandet upp. Om flera toast uppstår samtidigt så finns risken att den endast läser upp flera toast i följd (som kan vara den samma, där med upprepande) eller så finns risken att de avbryter varandra och användaren är där med ovetande om det andra toastmeddelanden som uppstått. En annan risk med toast som lägger sig ovanpå varandra är att det kan lägga sig framför annat innehåll och där med störa användarens arbete. Testa noggrant hur skärmläsare beter sig med toastmeddelanden och var varsam så inte meddelanden lägger sig i vägen för annat innehåll.

Toastmeddelandets innehåll

Ett toastmeddelande används för att ge statusuppdateringar. Är texten för lång så finns risken att en användare inte hinner att läsa igenom meddelandet innan det försvinner, om tiden inte är tillräcklig.

Toasten ska inte heller innehålla kritiskinformation som användaren inte kan nå på något annat sätt. Det kan vara svårt för personer med kognitiva svårigheter, personer med nedsatt synförmåga, personer som har mycket inzoomat läge på skärmen, eller en stressad person som kollar bort i 5 sekunder från området där toasten dyker upp. Den ska enbart användas som ett komplement i sådana fall. 

Relevanta WCAG-krav

Här är relevanta tillgänglighetskrav som man bör se över för att säkra tillgängligheten för toastmeddelanden. Det krav som ligger här har en kortare sammanfattad beskrivning. Varje krav har en länk direkt till informationskällan, vi rekommenderar att ni läser helheten av kraven om ni ska implementera toastmeddelanden.

WCAG-kriteriet 3.2.3 Var konsekvent i navigation, struktur och utformning – Se till att toasten uppstår på samma ställe på sidan/tjänsten så inte användaren blir överraskad eller missar den.

WCAG-kriteriet 2.1.1 Utveckla systemet så att det går att hantera med enbart tangentbordet – om det finns interaktiva element i toastmeddelandet så ska man kunna nå det med tangentbordsnavigering (exempelvis en stäng knapp).

WCAG-kriteriet 2.4.6 Skriv beskrivande rubriker och etiketter – om toastmeddelandet innehåller en rubrik så ska den vara tydlig och ha korrekt rubriksnivå (H1-H6).

WCAG-kriteriet 1.4.10 Skapa en flexibel layout som fungerar vid förstoring eller liten skärm – Det ska gå att se toastmeddelandet trotts att man har inzoomat upp till 200%, eller använder en mindre skärm. Det ska inte skapas scrollbars i två dimensioner (lodrätt och vågrätt).

WCAG-kriteriet 1.4.4 Se till att text går att förstora utan problem – All text ska kunna förstoras dubbelt utan att texten lägger sig utanpå/över eller bakom något annat innehåll på sidan. Det ska inte skapas scrollbars i två dimensioner (lodrätt och vågrätt).

WCAG-kriteriet 4.1.2 Namn, roll, värde – Använd i första hand standard element/roller när ni skapar fram komponenter, det ska vara tydligt vilken roll och värde komponenten har, samt att meddelanden om förändringar i dessa komponenter är tillgängliga för hjälpmedel.

WCAG-kriteriet 2.1.2 Se till att markören inte fastnar vid tangentbordsnavigation – Om det går att navigera in i komponenten så ska användaren även kunna navigera ut ur den eller stänga den med enbart tangentbord.

WCAG-kriteriet 4.1.3 Se till att hjälpmedel kan presentera meddelanden som inte är i fokus – Användare av skärmläsare måste vara medvetna om att ett meddelande har poppat upp, se därför till att den läses upp av skärmläsare trotts att den inte har fokus. Ta hjälp utav attributen aria-role eller aria-live för att förmedla viktiga meddelanden, felmeddelanden och förändringar.

WCAG-kriteriet 1.4.12 Se till att det går att öka avstånd mellan tecken, rader, stycken och ord – Det ska gå att öka avstånd mellan tecken/bokstäver/ord utan att innehåll överlappas eller går sönder.

WCAG-kriteriet 1.3.2  Presentera innehållet i en meningsfull ordning för alla – Hjälpmedel som skärmläsare läser innehåll sekventiellt och om koden visar innehållet i en annan ordning än det som visuellt visas på sidan så kan det skapa förvirring för användaren.

WCAG-kriteriet 1.4.13 Popup-funktioner ska kunna hanteras och stängas av alla – Om det är en icke-modal pop up (toaster) så är det viktigt att tänka på att användaren behöver ha god tid att kunna ta sig an meddelandet, den kanske tar tid för användaren att se/navigera till meddelandet, användaren kanske inte blir medveten om att det har dykt upp nytt innehåll eller att det nya innehållet stör vad användaren håller på med (risk att toast lägger sig i vägen för annat innehåll exempelvis).

WCAG-kriteriet 2.4.7  Markera tydligt vilket fält eller element som är i fokus – om det finns något interaktivt element i toasten (som exemeplvis en stängknapp) så ska den visa tydlig fokusram när användaren hovrar eller navigerar med tangentbord till det interaktiva elementet. Här ingår kontrastkravet minst 3.0 i kontrastvärde på fokusram.

WCAG-kriteriet 2.4.3 Gör en logisk tab-ordning – Om toastmeddelandet har interaktiva element så ska den precis som allt annat på sidan ha en logisk tab-ordning i samspel med resterande innehåll på sidan. Här finns dock en risk att man som användare inte hinner till toastmeddelandet när man tabbar genom sidan om den har en kort visningstid.

WCAG-kriteriet 2.2.1 Ge användarna möjlighet att justera tidsbegränsningar - Ge användaren tillräckligt med tid för att läsa och använda innehållet. Användare med dyslexi kan till exempel behöva längre tid för att läsa och skriva. Användare med nedsatt syn kan behöva längre tid för att lyssna igenom sidan, samt lyssna om något flera gånger. Ge endast användaren möjlighet att justera hur länge sådana meddelanden ska visas i förväg. Användaren tillåts förlänga tidsgränsen åtminstone 10 gånger, eller låt meddelanden visas i 20 timmar såvida inte användaren aktivt väljer att stänga den.

WCAG-kriteriet 1.1.1  Beskriv med text allt innehåll som inte är text – Innehåller meddelandet någon form av informationsbärande-grafik eller färg som indikerar en viss status så måste detta uppmärksammas för användare med skärmläsare så de inte tappar kontext. Är det ett felmeddelande så skriv då ”Felmeddelande – filen kunde inte sparas” exempelvis.

WCAG-kriteriet 1.4.11 Använd tillräckliga kontraster i komponenter och grafik – Komponenter och grafiska element ska uppnå minst 3.0 i kontrastvärde.

WCAG-kriteriet 1.4.3 Använd tillräcklig kontrast mellan text och bakgrund – Text ska uppnå minst 4.5 i kontrastvärde mot bakgrund.

WCAG-kriteriet 3.2.4 Benämn funktioner konsekvent - Komponenter som har samma funktionalitet inom en uppsättning av webbsidor identifieras konsekvent.

WCAG-kriteriet 2.5.8 (WCAG 2.2) Små klickytor – Om det använda klickbara element i toastmeddelandet som exempelvis en kryssruta för att stänga meddelandet så bör den uppnå minimum kravet för klickbara element 24 x 24 pxl. Mer information finns via länken ovan.