🎉 Nytt verktøy: Enkelt språk. Klikk på knappen og prøv det live

Hvordan er skjemaelementer utformet for å være tilgjengelige?

Ung kvinne sitter forvirret foran en bærbar datamaskin.

Del innlegget:

Ung kvinne sitter forvirret foran en bærbar datamaskin.

Hvordan er skjemaelementer utformet for å være tilgjengelige?

Del dette innlegget:

Ung kvinne sitter forvirret foran en bærbar datamaskin.

Alle har på et eller annet tidspunkt måttet forholde seg til skjemaer. Før i tiden mest på papir. I dag er det mer og mer digitale skjemaer, fordi de tjener brukerens interaksjon med et nettsted. Enten det dreier seg om kommunikasjon på Internett eller bestilling av en vare, finner du dem overalt. Søk på internett, for eksempel med Google, påvirkes også. Det er vanskeligere å fylle ut disse skjemaene for personer med fysiske eller kognitive funksjonsnedsettelser, samt for blinde og svaksynte. For at alle mennesker skal kunne delta i det offentlige liv, må disse skjemaene utformes slik at de er uten hindringer. Men hvordan lager man egentlig tilgjengelige skjemaelementer?

Det finnes ulike teknikker for dette. Før man går i gang med teknikkene, bør man imidlertid kjenne til skjemaelementene. Disse kan deles inn i ulike typer. Det finnes blant annet følgende typer

  • Inndatafelt med én linje
  • inndataområder med flere linjer
  • Utvalgslister
  • Radioknapper
  • Avmerkingsbokser
  • Send/Avbryt-knapper

Merking av skjemafelt

For å oppnå tilgjengelighet i skjemaer må de ulike kontrollene merkes. Disse merkelappene gjør det mulig for hjelpemidler å gjenkjenne kontrollenes funksjoner og formidle dem til brukeren. Det er viktig at etikettene er tydelig knyttet til kontrollene, ellers vil skjermlesere ikke kunne koble seg til elementene. Resultatet er at brukerne får problemer med å forstå skjemaet. De kan ikke se hvilken informasjon som skal fylles inn i hvilke felt. Dermed kan de ikke fylle ut skjemaet korrekt og gjør ofte feil. Alle beskrivelsene er imidlertid ikke merket på samme måte. Det avgjørende er om de skal være synlige for alle eller ikke. I programmeringsspråket HTML skilles det derfor mellom label-elementet og aria-attributtene. Label-elementet brukes til inndatafelt, valglister, radioknapper og avkrysningsbokser og må plasseres deretter. For inndatafelt og valglister plasseres etiketten foran kontrollelementene. For radioknapper og avkrysningsbokser plasseres etiketten etter kontrollelementet. For at etikettene skal knyttes til det aktuelle elementet, må for-attributtet legges til.

 

Attributtet aria brukes i HTML for knapper. Knapper kan for eksempel representere send eller avbryt i et skjema. Gjennom aria-attributter blir beskrivelsene av de respektive elementene kun gjenkjennelige for hjelpeteknologier. De kan derfor også brukes til inndatafelt som bare skal være synlige for skjermleseren. Det finnes mange aria-attributter som brukes for å forbedre tilgjengeligheten på Internett. Disse varierer imidlertid i type og funksjon. Den såkalte aria-label brukes til å merke et element. Det er selvfølgelig også mulig å bruke samme etikett for flere elementer. Dette er mulig med en aria-labelledby.

Inndatafelt med én eller flere linjer

Inndatafelt er blant de mest brukte elementene i skjemaer. De kan ha én eller flere linjer. Felter med én linje brukes til korte spørringer, f.eks. etter en persons navn, en e-postadresse, en gate eller et sted.

De opprettes i HTML med input-Tag og type-attributtet.

I tillegg kan ytterligere attributter legges til, f.eks. for å definere linjelengden.

Flerlinjersfelt brukes vanligvis til større tekstområder, for eksempel tekstmeldinger. Disse opprettes da med textarea-Tag . Også her kan utvikleren angi antall linjer og linjelengde. For at disse feltene skal være tilgjengelige uten hindringer, må etikettenTag likevel legges til. Det er imidlertid ikke mulig å opprette en forbindelse mellom etiketten og elementene hvis de ikke er tydelig tilordnet. Disse må da kobles sammen via for-attributtet og id-attributtet. I det følgende HTML-eksemplet er enkle etiketter implementert i slike inndatafelt.

 

<label for=“vorname“>Ihr Vorname: </label>

<input type“text“ name=“vorname“ id=“vorname“ />

<br />

<label for=“nachricht“>Ihre Nachricht: </label>

<textarea name=“nachricht“ id=“nachricht“> </textarea>

 

Her opprettes først et enlinjers inndatafelt for fornavnet med typen "text". Overskriften "Ditt fornavn:" gjøres synlig for alle ved hjelp av label-elementet. Dette elementet plasseres foran input-elementet, ettersom det skrives ut før input-feltet. For-attributtet i label-elementetTag og id-attributtet i input-elementet knytter disse områdene sammen. Det er viktig at innholdet er identisk, ellers kan de ikke kobles sammen. Attributtet name fungerer som en identifikator for dette feltet og er nødvendig for å overføre dataene til en serverside.

Deretter opprettes et inndataområde med flere linjer med Tag "textarea". Her vises etiketten "Din melding:" via label-elementet. Også her er de to områdene med samme tekstinnhold forbundet med hverandre via attributtene for og id.

Generelle merknader

Generelt bør skjemaene være klare og entydige. Forutsigbarhet er også svært nyttig. På denne måten kan brukerne raskt se hva som kreves av dem. En tydelig og fornuftig struktur er også svært viktig. Relaterte innholdselementer kan grupperes sammen. Logisk adskilte enheter kan også skilles visuelt fra hverandre. Dette gjør det lettere å orientere seg. I tillegg kan de skilles fra hverandre ved hjelp av farger. Det er viktig at minimumskontrasten på 4,5:1 opprettholdes.

Betjening av tastaturet

En av de viktigste funksjonene for universell utforming av skjemafelt er at de kan betjenes via tastaturet. Det finnes mennesker som ikke kan bruke musen på grunn av nedsatt funksjonsevne. Derfor er det desto viktigere å utforme skjemaer på en slik måte at de også kan navigeres med tastaturet. Bruk av label-elementer og aria-attributter gjør skjemaene enklere å forstå og betjene. En annen måte å forenkle betjeningen via tastaturet på er å bruke hurtigtaster. Her kan skjemaelementer lagres med tastatursnarveier. Dette kan bidra til at man kommer raskere til bestemte områder eller til å betjene funksjoner raskere. Til dette formålet brukes accesskey-attributtet i HTML. Dette attributtet settes inn i elementet som det skal brukes til. Der tilordnes ganske enkelt tasten som deretter brukes til tastaturkommandoen. Hvis for eksempel tasten "n" tilordnes et felt eller en knapp, kan den i Windows betjenes med hurtigtasten (Alt + n).

Du må imidlertid forsikre deg om at denne hurtigtasten ikke allerede brukes til en annen kommando i nettleseren.

Reduksjon til et minimum

Det er også tilrådelig å redusere det hele til det vesentlige for ikke å belaste personer med nedsatt funksjonsevne unødvendig. Derfor bør man bare be om de absolutt nødvendige opplysningene. Forespørsler om allerede eksisterende data bør utelates. I tillegg kan synligheten av skjemafeltene tilpasses situasjonen. Valgfrie inndatafelt eller felt som er knyttet til betingelser, trenger ikke å være synlige. De kan vises når det er behov for dem. Det gir for eksempel ingen mening å be om alder på barn hvis det på forhånd er valgt at det ikke er noen barn til stede.

Hjelp og feilmeldinger

I tillegg bør det tilbys inndatahjelp. Dette kan være i form av et dialogvindu eller et verktøytips. Ved hjelp av disse kan inndataene forklares mer detaljert. En annen mulighet er å lenke til en egen hjelpeside. Dette vil øke suksessraten betraktelig. Det skjer fortsatt feil. Det er viktig å gi meningsfulle feilmeldinger. Hvis for eksempel passordet ble oppgitt feil ved innlogging, bør ikke meldingen "Brukernavn eller passord er feil" vises. Det er bedre å filtrere feilen. Korrekt her ville være: "Det oppgitte passordet er ikke riktig. Vennligst skriv inn riktig passord". 

Det finnes forskjellige typer feil. For det første formatfeil. Her legges passordet inn i feil format. For eksempel er bokstaver lagt inn i stedet for tall. Verdifeil kan også forekomme. Dette kan skje hvis en feil verdi legges inn til tross for at formatet er gyldig. Et eksempel på dette kan være at verdien 34 legges inn på Tag for datoen. Meldingen lyder da for eksempel: "Mars måned har 31 dager. Vennligst skriv inn Tag på nytt".

En annen type feil er ugyldig input. Her angir utvikleren verdier som er ugyldige. Til slutt har vi feiltypen som oppstår når obligatoriske felt ikke er fylt ut. Dette skjer for eksempel når e-postadressen er et obligatorisk felt og oppføringen ble glemt. Dette skjer imidlertid også ofte med de generelle vilkårene og betingelsene. På mange nettsteder kan du ikke gå videre uten å godta denne erklæringen.

Obligatoriske felt

Skjemaer inneholder ofte obligatoriske felter. Disse må markeres som obligatoriske. Et symbol som ofte brukes for å indikere et obligatorisk felt, er en "*", som vises ved siden av skjemafeltet. I dette tilfellet bør det imidlertid påpekes allerede i begynnelsen av skjemaet at de feltene som er merket med en stjerne, er obligatoriske. En annen mulighet er å vise disse obligatoriske feltene i en annen farge eller skyggelegging. Disse er imidlertid ikke tilgjengelige for alle. For at skjermleserbrukere også skal kunne gjenkjenne dem, bør også attributtet required eller aria-required brukes. Dette forteller skjermleseren at det er et obligatorisk felt.

Plassholder

En måte å gjøre skjemaer enda mer forståelige og brukervennlige på er å bruke plassholdere i skjemafeltene. Plassholdere er midlertidige tekster som vises i et skjemafelt for å indikere for brukeren hva slags informasjon som skal legges inn. Disse tekstene forsvinner så snart det klikkes eller fokuseres på skjemafeltet, og kan erstattes av det faktiske innholdet i skjemafeltet. Plassholdere kan enkelt settes inn i HTML-inntastingselementet i et skjemafelt ved hjelp av plassholder-attributtet.

Lagre oppføringer

Alle brukere bør kunne lagre det de har skrevet inn. Det oppstår stadig problemer med lengre skjemaer. For å unngå tap av data kan de lagres. Til dette formålet kan det implementeres en knapp som lagrer gjeldende status. Dette gjør det enklere å fylle ut komplekse skjemaer. Det har også den fordelen at manglende oppføringer kan fylles ut på et senere tidspunkt. En gjentakelse av disse oppføringene fører nemlig til at noen brukere ikke fortsetter å fylle ut skjemaet. Dette kan være irriterende både for den som driver nettstedet og for brukeren.

Autentisering og tidsbegrensning

Autentisering øker sikkerheten på Internett. Men det er også en av barrierene som dukker opp igjen og igjen. Disse oppstår ofte på nettsteder som krever innlogging. Men for at disse skal være tilgjengelige for alle, må skjemaene utformes slik at de er barrierefrie. I mange tilfeller er nemlig autentiseringsprosedyrene tidsbegrensede. Da har folk svært kort tid på seg til å logge inn. Ofte er det bare 30 eller 60 sekunder. For mange funksjonshemmede er dette ikke nok tid til å logge inn. Derfor er det viktig å ikke begrense innloggingen med et klokkeslett.

Captchas utgjør et annet problem. De brukes til å identifisere brukeren som et menneske og ikke som en datamaskin. Her blir brukeren bedt om å identifisere et forvrengt bilde og skrive inn resultatet i et skjemafelt. Ofte må man imidlertid klikke på alle bildene, for eksempel de som viser en bil. Disse er imidlertid ikke alltid tilgjengelige. Blinde og svaksynte kan ikke gjenkjenne disse bildene. For å omgå denne barrieren bør det tilbys et lydalternativ.

 

Oppsummert er universell utforming av skjemafelt et viktig skritt på veien mot et tilgjengelig digitalt miljø. Bruk av korrekte betegnelser, en tydelig og strukturert layout samt betjening via tastaturet og tilhørende feilmeldinger øker sannsynligheten for at også personer med nedsatt funksjonsevne kan fylle ut skjemaene på egen hånd.

Enkelt for alle

Er du interessert? Vi hjelper deg gjerne.

Med mer enn 25 funksjoner for digital tilgjengelighet hjelper Eye-Able deg også med å redusere barrierene på lang sikt. På denne måten gjør du informasjonen din tilgjengelig for alle og ekskluderer ingen besøkende - kort sagt: du får tilgang til en ny målgruppe uten store markedsføringsvolumer.

Ikonet viser tilgjengelighetstall

Konsultasjon

Ikke-bindende høring om digital tilgjengelighet generelt

Ikonet viser tilgjengelighetstall

Analyse

Diskusjon om mulig optimaliseringspotensial på nettstedet ditt

Ikonet viser tilgjengelighetstall

Live demo

Presentasjon av assistanseprogramvaren direkte på nettstedet ditt

Flere bidrag

Hvis det kan være litt mer: