| Innehållsförteckning |
|---|
Exempel
...
Designspecifikation
Progressbar finns för närvarande i färgerna grått och grönt.
Do’s and Don’ts
Undvik färgerna blått (då komponenten inte går att interagera med för användaren) samt rött.
Tillgänglighet
En progressbar indikerar att användarens begäran har tagits emot och att en tjänst gör framsteg mot att slutföra den begärda uppgiften. Vid användning av en progressbar är det viktigt att man också kan förmedla den informationen till icke-seende. Det kan göras genom Role=”Progressbar”. Beroende på vart någonstans progressbaren används så är det bra att erbjuda användaren nödvändig information relaterat till hur långt man är framme i en process eller vad det är som händer så att man inte lämnas till att undra vad det är som faktiskt händer. Om det inte är möjligt att visa hur långt framme man så kan man överväga att hoppa över det, det är heller inte önskvärt att ösa onödig uppdateringsinformation och avvägningar behöver göras från situation till situation.
Beroende på hur en progressbaren används och kontexten så kan man behöva vidta extra åtgärder som finns beskrivna här:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role
Det finns några problem man kan stöta på i användandet av en progressbar. Om progressbaren är menad att ta upp hela sidan låt inte användare navigera utanför den med exempelvis ett tangentbord. Då kan det också vara relevant att använda sig av sätt att annonsera händelsen (progressbaren), genom en alert och fokus som skiftar till progressbaren och sedan tillbaka till sidan.
Research på komponenten
-
Relaterade resurser/komponenter
Status
...
Status
...
En progress bar används för att visuellt representera slutförandet av en uppgift eller process. Den visar hur mycket av uppgiften/processen som har slutförts och hur mycket som fortfarande är kvar.
Innehållsförteckning
| Innehållsförteckning |
|---|
Komponentkällor
1177
Inera
Tillgänglighet
Ska ha roll: progressbar
Ange värdet för aria-valuenow, aria-valuemin och aria-valuemax, såvida inte värdet är obestämt,
då ska attributet aria-valuenow uteslutas. Uppdatera dessa värden när den
visuella progressen uppdateras. Om progressbaren beskriver laddningen för en viss region på en sida,
så bör man använda aria-describedby för att peka på statusen och ställa in aria-busy-attributet till true i
regionen tills det är färdig laddad. Mer information fins här: https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/#progressbar
WCAG-kriteriet 1.1.1 Beskriv med text allt innehåll som inte är text:
Om loading spinner kommer vara synlig i flera sekunder dvs om en laddning kan ta flera sekunder så ska användare med skärmläsare informeras så de inte tror att sidan har kraschat eller liknande. Detta kan göra att användare trycker på uppdatera knappen eller att de lämnar sidan och där med förlorar sin progress i onödan. Eftersom loading spinner är en visuell animation så ska den då förklaras för de som inte kan se. Detta kan göras med exempelvis en dold text för seende användare men som är synlig för skärmläsare. Prova att lyssna med skärmläsare för att se att det inte blir för upprepande.
WCAG-kriteriet 4.1.3 Se till att hjälpmedel kan presentera meddelanden som inte är i fokus:
Se till att de som använder tekniska hjälpmedel som exempelvis skärmläsare och förstoringsprogram kan göras uppmärksamma på viktiga meddelanden även om de presenteras utanför det område på sidan som användaren har i fokus. Ange med hjälp av attributen role eller aria-live var viktiga meddelanden kan förekomma, så får hjälpmedel kännedom om dessa och kan presentera dem för användaren vid ett lämpligt tillfälle.
WCAG-kriteriet 1.4.3 Kontrast på text:
Se till att liten text har ett kontrastvärde av minst 4.5:1 mot bakgrunden, och stor text minst 3.0:1. (Nivå AA)
WCAG-kriteriet 1.4.11 Kontrast på icke-textobjekt:
Grafik, så som ikoner, komponenter och andra informationsbärande grafiska element ska ha kontrast värde på minst 3.0:1. (Nivå AA)
WCAG-kriteriet 1.3.1 Ange i koden vad sidans olika delar har för roll:
Koda komponenter korrekt, exempelvis att en knapp kodas som en knapp så även hjälpmedel lätt kan avgöra vad det är för något när användaren kommer i kontakt med den. Information, struktur, och relationer som förmedlas genom presentation kan bli automatiskt tydliggjord eller finnas som text. (Nivå A)
Feedback
Hjälp oss att förbättra den här komponenten genom att ge feedback, ställa frågor och lämna andra kommentarer på Inera UX Slacken i kanalen #komponenter_design eller #komponenter_kod alternativt kan du använda vårt formulär.
Publicerad | |
Senast uppdaterad |
...