Hjem » Siste artikler » Tilgjengelig HTML i praksis: slik gjør du skjemaer forståelige for alle

Tilgjengelig HTML i praksis: slik gjør du skjemaer forståelige for alle

Hovedillustrasjon
Hovedillustrasjon. Foto: Daniil Komov / Pexels.

Skjemaer er blant det mest kritiske på en nettside: kontakt, innlogging, bestilling, påmelding og mye mer. Hvis skjemaet er tungt å bruke, mister du både brukere og data, og for mange blir det rett og slett umulig å fullføre.

Med noen få, bevisste grep i HTML kan du gjøre skjemaer langt mer tilgjengelige for både skjermlesere, tastaturbrukere og folk som bare er litt stresset på mobilen.

Hvorfor tilgjengelige skjemaer er viktigere enn du tror

Et skjema er ofte stedet der noe faktisk skjer: noen melder seg på, aksepterer vilkår eller gir deg en bestilling. Små hindringer her gir stor effekt, både på brukeropplevelse og konvertering.

Tilgjengelighet handler ikke bare om brukere med varige funksjonsnedsettelser. Det handler også om dårlig lys, liten skjerm, midlertidig skade eller bare det å være sliten og ukonsentrert. Et tydelig, strukturert skjema hjelper alle.

Start med semantikk: label, input og riktig type felt

Det viktigste du kan gjøre, er å koble hvert felt til en beskrivende tekst. Det gjør du med<label>og attributtetfor, som peker til feltetsid.

Et enkelt tekstfelt kan da se slik ut:

<label for=”email”>E-post</label>
<input type=”email” id=”email” name=”email”>

Skjermleseren vil da lese opp etiketten sammen med feltet, og brukeren forstår hva som skal fylles inn. Dette gjør det også enklere å klikke på etiketten for å aktivere feltet.

Bruk i tillegg riktigtypepå feltene:email,tel,number,url,date,passwordog så videre. Det gir riktigere tastatur på mobil og bedre validering i nettleseren.

Plassholder er ikke label: unngå den klassiske fellen

En vanlig feil er å droppe<label>og i stedet skrive instruksjonen somplaceholder. Det kan virke ryddig visuelt, men er problematisk av flere grunner.

Plassholderteksten forsvinner ofte når brukeren begynner å skrive. Da er det lett å glemme hva feltet egentlig var, spesielt i lange skjemaer. Kontrastnivået på plassholdertekst er også gjerne lavt, som gjør det vanskelig å lese.

Bruk heller en tydelig label, og reserver placeholder til korte, supplerende eksempler, som for eksempel “[email protected]” i et e-postfelt.

Grupper relaterte felt med fieldset og legend

Når du har flere relaterte felt, for eksempel en gruppe med radioknapper eller en seksjon for fakturainformasjon, blir strukturen mye tydeligere hvis du bruker<fieldset>og<legend>.

Et eksempel med radioknapper:

<fieldset>
<legend>Hvordan vil du kontaktes?</legend>
<label><input type=”radio” name=”kontakt” value=”epost”> E-post</label>
<label><input type=”radio” name=”kontakt” value=”telefon”> Telefon</label>
</fieldset>

Legend gir skjermleserbrukeren en helhetlig overskrift for gruppen, og det blir tydelig at valgene hører sammen. Dette er spesielt viktig når det er mange felt.

Feilmeldinger som faktisk hjelper brukeren

Tematisk illustrasjon
Tematisk illustrasjon. Foto: Markus Spiske / Pexels.

Skjemaer som bare viser en rød ramme rundt et felt når noe er feil, er vanskelige for mange å forstå. Farge alene er ikke nok, hverken for fargeblinde eller for de som bruker skjermleser.

Gi alltid en tydelig tekstlig forklaring på feilen. Det kan være under feltet, eller samlet i en feilliste øverst på siden som linker ned til hvert felt. Husk å beskrive hva som må gjøres, ikke bare at noe er feil.

Eksempel på hjelpetekst under et felt:

<label for=”telefon”>Telefon</label>
<input type=”tel” id=”telefon” name=”telefon” aria-describedby=”telefon-hjelp”>
<p id=”telefon-hjelp”>Skriv kun tall, uten mellomrom.</p>

Hvis valideringen feiler, kan du i tillegg oppdatere denne teksten til å forklare feilen og hva brukeren bør endre.

Bruk aria først når HTML ikke er nok

Mye kan løses med ren HTML hvis du utnytter elementene godt. Men noen ganger trenger du hjelp fra ARIA-attributter for å gjøre tilstanden på skjemaet tydelig.

Noen nyttige attributter er:

  • aria-required=”true”for å markere at et felt er påkrevd, i tillegg til visuell markering
  • aria-invalid=”true”på et felt som har fått en valideringsfeil
  • aria-describedbyfor å knytte feltet til hjelpetekst eller feilmelding

Bruk ARIA som et supplement, ikke som erstatning for label, riktig type felt og god struktur. Start alltid med det semantiske grunnlaget først.

Gjør det mulig å bruke skjemaet kun med tastatur

En helt sentral del av tilgjengelighet er at hele skjemaet kan navigeres med tastatur. Det gjelder både for personer som ikke kan bruke mus, og for mange som bruker tastaturet fordi det går fortere.

Test skjemaet ditt ved å bruke Tab, Shift+Tab, piltaster, mellomrom og Enter. Du bør kunne:

  • gå gjennom alle felt i logisk rekkefølge
  • se tydelig hvilket felt som har fokus
  • velge radioknapper og avkrysningsbokser
  • bekrefte skjemaet uten å bruke mus

Unngå å fjerne fokusrammen med CSS. Hvis du vil style den, gjør den tydeligere i stedet for å gjemme den.

Enkle forbedringer du kan starte med i dag

Hvis du allerede har et skjema i produksjon, trenger du ikke skrive alt på nytt. Ofte kan noen små justeringer gjøre stor forskjell uten at designet må endres dramatisk.

En kort sjekkliste:

  • Har alle felter en tydelig label som er koblet med for og id?
  • Bruker du riktig input-type for e-post, telefon og dato?
  • Er påkrevde felter markert både visuelt og tekstlig?
  • Er feilmeldinger konkrete og knyttet til riktig felt?
  • Fungerer alt med kun tastatur på mobil og desktop?

Ta ett skjema av gangen, og test underveis med ekte brukere der det er mulig. Små forbedringer på riktige steder gir ofte rask gevinst.

Oppsummert: tilgjengelige skjemaer er god webutvikling

Tilgjengelighet i skjemaer handler om mer enn å oppfylle krav og standarder. Det handler om å respektere tiden og energien til alle som prøver å gi deg informasjonen du ber om.

Med riktig bruk av label, fieldset, tydelige feilmeldinger, ARIA der det trengs og god tastaturnavigasjon, kan du gjøre skjemaene dine både mer inkluderende og mer effektive. Det er god HTML, god brukeropplevelse og god forretning på samme tid.

0 kommentarer