Eksempler

Varianter

Størrelser

Komponenten kommer i to størrelser:

• Medium (standard) brukes både på eksterne og interne flater.
• Small brukes på interne flater der det er behov for et mer komprimert grensesnitt.

Max length

Textarea kan vise antall gjenværende tegn som er tillatt å skrive inn. Tallet oppdateres etterhvert som brukeren skriver eller fjerner innhold. NB! Dette er bare en visuell indikator. Faktisk begrensning og validering må håndteres i kode.

Skjule label visuelt

Textarea skal alltid ha en label. I spesielle tilfeller kan label skjules visuelt, f.eks. i tabeller der en select får ledeteksten sin fra tabellheaderen--bruk da ```aria-label``` eller ```aria-labelledby```.

Read-only

Readonly-attributtet spesifiserer at et inputfelt i et skjema er skrivebeskyttet. Et skrivebeskyttet felt kan ikke endres, men brukere kan tabbe til det, markere det og kopiere tekst fra det. Til forskjell fra disabled-felter vil innholdet i readonly-felter inkluderes når et skjema sendes inn.

Retningslinjer

Plassering av label og description

Label og description er alltid plassert over tekstfeltet slik at det er godt synlig på små skjermer og ikke kommer i konflikt med feilmelding.

Ikke bruk placeholder-tekst

Vi fraråder bruk av placeholder-tekst. Fordi placeholder-teksten forsvinner så snart brukeren begynner å skrive i feltet, må informasjonen uansett gjentas i label eller beskrivelse. Om man skulle brukt placeholder-tekst må den møte kontrastkravene fra WCAG, og da blir teksten så mørk at brukere lett kan tro at feltet allerede er utfylt. Sørg heller for at du skriver den informasjon som trengs til utfylling av feltet i label og beskrivelse.

Tilpass bredden på tekstfeltet

Tekstfelt bør ha en bredde som er tilpasset det brukeren skal skrive inn. Når tekstfeltene har forskjellig bredde blir det lettere å navigere i skjemaer med mange felter.

Input og formatering

• Bruk `autocomplete` for felter som mottar personlig informasjon. For felter som etterspør personlig informasjon om en annen person enn brukeren, skru autocomplete av. (WCAG 1.3.5)
• Bruk gjerne inputtyper som tilsvarer informasjonstypen du ber om (`tel`, `search`, `email`, osv.). Disse tilbyr mobilbrukere et tastatur som er tilpasset inputtypen, men ta i betraktning at de kan også utløse client-side validering av feltets input.
• Vær generøs i hva du aksepterer av data. Godta input fra brukeren så lenge den er forståelig, f.eks. telefonnumre med mellomrom, personnumre med punktum, epost-adresser med mellomrom til slutt.
• Dersom input blir automatisk formattert, må dette være synlig for brukere slik at de kan kontrollere om det ble riktig.
• Feltets `name` må inkludere, og helst starte med teksten i dens `label`. (WCAG 2.5.3)
• Unngå bruk av all-caps og kursiv tekst til labels. Disse er vanskeligere å lese.

Tilgjengelighet

Disabled

Selv om vi fraråder bruk av disabled state generelt, finnes det helt sikkert unntak. Ta kontakt med våre eksperter på universell utforming for å finne best mulig løsning.

Prefix/suffix

Fra et uu-perspektiv anbefaler vi å unngå prefix eller suffix i forbindelse med inputfelter. Dette kan føre til problemer for folk som bruker autofill-verktøy, skjermlesere og skjermforstørrere. Dessuten kan slik informasjon inn i feltet føre til at folk opplever feltet som allerede fylt ut. Bruk heller en label som forklarer hva innholdet i feltet skal være inkludert enhet, uten forkortelser.

Props

Tokens