Inaktiva komponenter - Disabled states
Introduktion
Denna sidan beskriver de riktlinjer UX-ramverket har angående disabled states (inaktiva komponenter) och hur man ska tänka innan man väljer att använda det.
Källor som har använts
Is it ok to ‘grey out’ disabled buttons? | by H Locke | Medium
https://webbriktlinjer.se/riktlinjer/156-anvand-tillrackliga-kontraster-i-komponenter-och-grafik/
Vad är disabled state?
En inaktiverad komponent används när användaren inte tillåts interagera med komponenten på grund av antingen behörigheter, beroenden eller förutsättningar. Inaktiverade tillstånd tar helt bort den interaktiva funktionen för en komponent.
När man använder sig av disabled states för att visa att knapparna inte går att använda på grund av: behörighet, beroenden eller nödvändiga förutsättningar, så måste man ha några saker i åtanke. Man ska använda sig av disabled states om man vill förmedla till användaren att knappen finns men inte kan användas i nuläget. Om knappen inte ska användas alls av användaren ska det istället vara en “hidden state” eller inte finnas alls.
Fördelar med att använda disabled state
Användaren kan upptäcka knappen och förstå att den existerar innan de kan använda den.
Den andra fördelen är att användaren lär sig vart knappen befinner sig inom gränssnittet så de snabbt kan hitta tillbaka till den.
Nackdelarna med att använda disabled states
Inaktiva knappar ger användaren mer att tänka på, vilket kan leda till frustration och förvirring. Om användaren ser en inaktiv knapp kommer användarna fokusera på varför den inte går att använda och hur man aktiverar den. Detta går emot konceptet som Steve Krug beskriver i boken “Don’t make me think” där författaren beskriver att man ska ta bort element som gör att användaren behöver tänka mer än nödvändigt och där med göra webbsidan så enkel att förstå som möjligt.
En annan nackdel är att om det inte implementeras rätt kan inaktiva knappar förvirra användaren, exempelvis kan nedtonade knappar se ut som sekundära alternativ eller att kontrasten på knappen är så låg att användare inte ser den.
Rekommendation
UX-ramverket rekommenderar att avstå från disabled states om möjligt.
I exempelvis formulär som innehåller obligatoriska fält så kan man istället för att använda en inaktiverad-knapp låta den vara aktiv. När användaren klickar på knappen “skicka” och inte har fyllt i alla obligatoriska fält så kan man istället trigga ett valideringsfel som förklarar för användaren vad som saknas för att kunna utföra uppgiften. På så sätt så minskas risken att användaren blir förvirrad över varför det inte går att klicka på skicka-knappen på grund utav att hen kan ha missat att fylla i något.
Detta är även vanligt förekommande vid godkännande av användarvillkor.
Bildexempel mellan inaktiv knapp knapp och aktiv knapp med felmeddelande:
Om disabled states måste användas, se då till att det finns text som beskriver för användaren vad hen behöver göra för att aktivera den inaktiva komponenten, så det inte uppstår onödig förvirring.
Exempel på scenario: Det går att vara inloggad i ett administrativt-gränssnitt med olika roller som ger användaren olika behörigheter inom gränssnittet. Om användaren är inloggad med rollen “Statistik” så kan det finnas en begränsning i gränssnittet som gör att användaren inte kan administrera i gränssnittet. Men användaren kanske även kan logga in med en annan roll som “Administratör”, och där med får behörigheten att hantera och administrera i gränssnittet. Då kan det vara passande att användaren kan se att det finns funktioner som är inaktiverade för att få kännedom om att de existerar. Se då till att det finns en informativ text som förklarar för användaren varför funktionen är inaktiv och vad hen måste göra för att använda funktionen.
Exempeltext intill inaktiv funktion: “För att administrera uppdrag så måste du vara inloggad med rollen administratör”.
Sammanfattning
Överväg om det istället kan användas aktiva komponenter men som triggar felmeddelanden vid felaktig inmatning, istället för att använda inaktiva komponenter.
Tips vid implementering av disabled states
Tips | Bild |
|---|---|
På denna bild har vi en jämförelse mellan två bilder, bilden till vänster har enbart gjort den gråa färgen ljusare vilket gör att den vita texten blir svårt att se när den blir inaktiv, medans den högra bilden ändrar färgen från blå till lite mörkare grå som gör att båda fortfarande går att se även om knappen blir inaktiv. |  Bild hämtat från Is it ok to ‘grey out’ disabled buttons? | by H Locke | Medium |
Se till (om möjligt) att ha den inaktiva knappen på ett ställe där du vet att användaren kommer se den. Detta kan vara bredvid knappar som är aktiva. |
|
Bilden ger ett exempel där man kan ha stödjande text som beskriver varför knappen är inaktiv, detta för att klargöra vad det är som behövs för att kunna använda knappen. | Bild hämtat från Is it ok to ‘grey out’ disabled buttons? | by H Locke | Medium |
Se till att font storleken inte ändras beroende på storleken på skärmen, detta gäller aktiva som inaktiva knappar. |
|
Knappen ska vara läsbar av skärmläsare, detta kan göras med “aria-disabled=true” istället för “disabled” detta låter användaren veta om att det finns en knapp. “aria-live” låter användaren inte skicka in något. | Exempel finns här: |
Använd “cursor disabled” när man hovrar musen över knappen om det är en inaktiv knapp. Då får man ytterligare en indikation att den är inaktiv. |
Bild hämtat från Is it ok to ‘grey out’ disabled buttons? | by H Locke | Medium |
WCAG-krav vid användning av disabled states
Enligt WCAG så behöver man inte tillämpa någon kontrast skillnad mellan den inaktiva knappen och bakgrunden just för att det räknas som en tillfällighet, med det sagt är det ändå viktigt att tänka på att knappen inte är allt för nedtonad så att knappen inte är allt för svår att kunna se. Samt att man måste tänka på att inte enbart förmedla genom en nedtonad grå färg att knappen är inaktiv.
WCAG-kriteriet 1.4.3 - Använd tillräckligt höga kontraster mellan text och bakgrund
WCAG-kriteriet 1.4.1 - Använd inte enbart färg för att förmedla information