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, foreslår vi skadereduserende tiltak.

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:

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.

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: