Deaktiverte tilstander kan være utfordrende for brukere å oppfatte og forstå, og vi anbefaler derfor at du ikke bruker dem i løsningen din. I denne artikkelen ser vi på alternative løsninger. I tilfeller der det likevel er aktuelt å bruke deaktiverte tilstander, tilbyr vi skadereduserende tiltak og komponenter designet til å kunne oppfattes av alle.
Hvorfor er deaktiverte tilstander problematiske?
Deaktiverte tilstander kan være vanskelig for folk å oppfatte. De er vanligvis designet med lav fargekontrast og med fargeendring som den eneste grafisk middel for å kommunisere tilstanden. Dette kan være problematisk ikke bare for folk som er svaksynte, men også folk som sitter i lysrike omgivelser eller som har dårlig skjerm.
Hvis vi lager et deaktivert design som faktisk møter kontrastkravene, kan det lett skje at brukeren oppfatter elementet som om det allikevel er aktivt. Da prøver de å aktivere elementet og skjønner ikke hvorfor dette ikke fungerer.
Et annet problem er at grunnen til at et element er deaktivert vanligvis implisitt—vi forklarer ikke hvorfor elementet er deaktivert. Brukeren må gjette, det kan hende at de gjetter feil.
Deaktiverte tilstander mottar heller ikke tastaturfokus, så leselist- og skjermleserbrukere kan gå glipp av dem.
Vanlige bruksområder
Designere bruker deaktiverte tilstander hovedsakelig i tre forskjellige situasjoner:
- For å vise at et valg ikke er relevant per daværende tidspunktet, men kan bli relevant i fremtiden.
- For å vise at et skjema ikke er utfylt riktig eller ikke er ferdig utfylt ennå.
- For å vise at et element ikke kan endres («read only»).
Alternative løsninger
Heldigvis så finnes det alternativer til bruk av deaktiverte tilstander.
Skjemavalidering
Vurderer du å bruke en deaktivert submit-knapp som en form for skjemavalidering? Du bør heller validere inline som vanlig, la knappen forbli aktiv og vise en feilmelding når brukeren prøver å sende inn skjemaet.
Skjemaer uten endringer
Fremfor å deaktivere submit-knappen når det ikke finnes endringer i skjemaet, kommuniser til brukeren når endringer har vært lagret, f.eks. med en inline statusmelding ved siden av eller inn i knappen, men la knappen forbli aktivt. Det er sjelden farlig at noen sender inn et par ekstra serverkall hvis det hjelper dem til å føle tryggere.
Ikke-aktuelle valg
Hvis et valg ikke er relevant, bør du helst fjern valget fremfor å deaktivere det. Tilby gjerne brukeren informasjon om hvorfor valget ikke er tilgjengelig.
Skrivebeskyttet innhold
Bruk vanlig tekst fremfor å deaktivere skrivebeskyttede inputfelter, eventuelt med tilleggsinformasjon som forteller hvorfor informasjonen ikke kan endres.
HTML-attributtene readonly
og aria-readonly
HTML har en readonly
-attributt, men denne er bare relevant for inputtyper som har en value som kan endres av brukeren, dvs. textarea
og tekstfelter (text
, search
, email
, osv.). Felter med readonly
-attributtet kommer i tabrekkefølgen, og brukere kan kopiere innholdet men ikke endre det. Informasjon i readonly
-felter kommer med når skjemaet sendes inn.
Inputfelter med readonly
-attributtet får ingen default styling som skiller dem ut fra vanlige, redigerbare felter. Dette kan være svært forvirrende for folk hvis de ikke skjønner hvorfor de ikke kan endre innholdet i feltet. Hvis du velger å bruke readonly, sørg for at du styler feltet annerledes fra vanlige tekstfelter og forklarer for folk hvorfor innholdet ikke kan endres.
Hvis du trenger kommunisere til hjelpemidler at andre skjemaelementer enn tekstfelter og textarea
er skrivebeskyttet kan du bruke aria-readonly="true"
. Ta i betraktning at som med all ARIA, er det bare semantikken som blir endret av aria-readonly
, ikke funksjonaliteten. Dvs. at du selv må sørge for at brukere ikke kan endre verdien til elementene aria-readonly brukes på.
Skadereduksjon
Dersom du må bruke deaktiverte tilstander:
- Sikre at komponenten kan allikevel oppfattes og forstås av alle, inkludert folk som er svaksynte, folk som bruker enheter med dårlig skjerm og de som sitter i omgivelser med sterk lys, i tillegg til folk som ikke er datakyndige og folk med kognitiv funksjonsnedsettelse.
- Sørg for at brukeren ikke må gjette for å vite hvorfor elementet ikke er aktuelt. Gi folk informasjon om hvorfor valget er deaktivert. Sørg for at alle får tilgang til informasjonen—dvs., den skal ikke bare være tilgjengelig på hover.
- Bruk andre grafiske midler i tillegg til farge for å skille mellom aktive og ikke-aktive valg.