Byg tilgængelige formularer og brugbare fejlbeskeder

Formularen i eksemplet beder om navn, e-mailadresse, og valget “I lokalet” eller “Online”. Før indsendelsen er felterne tomme, etiketterne synlige, og ingen felter markeret som fejl. Alle tre oplysninger kræves, og formularen forklarer, at bekræftelsen sendes til e-mailadressen.

Fra en afvisning til en brugbar besked

Sådan gør du

1. Gør hvert felt forståeligt

   Brug en synlig etiket som “E-mailadresse” over feltet. En hjælpetekst kan forklare: “Vi sender bekræftelsen til denne adresse”. De to tekster har forskellige opgaver: Etiketten navngiver oplysningen, og hjælpeteksten forklarer brugen.

   Lad etiketten blive stående, mens man skriver. Eksempeltekst inde i et tomt felt, også kaldet placeholder, forsvinder ofte ved indtastning. Den kan derfor ikke stå alene som feltets navn.

   Angiv tydeligt, hvilke felter der er obligatoriske. Hvis alle felter kræves, kan du skrive det samlet før felterne. Hvis kun nogle kræves, skal hvert af dem kunne genkendes. Forklar en eventuel stjerne. Bed kun om oplysninger, der er nødvendige for tilmeldingen.

2. Saml valg under det rigtige spørgsmål

   Radioknapperne “I lokalet” og “Online” giver først mening med spørgsmålet “Hvordan vil du deltage?”. Spørgsmålet skal både stå synligt og være knyttet til gruppen i koden. Hver radioknap beholder sin egen etiket.

   Afprøv valgene med piletasterne. Kun én mulighed skal kunne vælges ad gangen. Hvis valget åbner nye felter, skal felterne stå i en meningsfuld rækkefølge og kunne nås med tastaturet. Skjulte felter må ikke stoppe indsendelsen med fejl, som brugeren ikke kan finde.

3. Skriv fejlen dér, hvor den kan rettes

   Skeln mellem et tomt felt og et felt med en forkert oplysning. “Skriv din e-mailadresse” passer til et tomt felt. Når personen har skrevet navn@, forklarer beskeden i eksemplet, hvilken del af adressen der mangler. Brug kun en så præcis besked, når systemet faktisk har konstateret netop den fejl.

   Placér beskeden ved feltet, og behold feltets etiket. Brug tekst, så fejlen kan forstås uden den røde farve. Et ikon eller en farvet kant kan hjælpe med at finde beskeden, men skal ikke bære forklaringen alene.

   Vis ikke en fejl, blot fordi brugeren endnu ikke er færdig med at skrive. En adresse er normalt ufuldstændig under indtastningen. Afprøv, hvornår jeres validering starter, og om gentagne beskeder afbryder arbejdet.

4. Hjælp brugeren tilbage til opgaven

   Ved flere fejl kan en opsummering over formularen vise, hvad der mangler, med links til de relevante felter. Linkteksterne skal nævne feltet og problemet. Bevar oplysningerne i alle felter, så rettelsen ikke bliver en ny tilmelding fra bunden.

   Hvis fejlene vises uden at indlæse en ny side, skal beskeden kunne opdages af hjælpemidler. Et bevidst fokusskift til fejlopsummeringen eller en passende annoncering kan indgå i løsningen. Brug ikke begge dele mekanisk: Den samme lange besked kan ellers blive gentaget. Aftal adfærden med udvikleren, og få den faktiske annoncering afprøvet i den relevante kombination af browser og hjælpemiddel.

   En serverfejl kræver en anden besked end en forkert adresse. Hvis tilmeldingen med sikkerhed ikke er gemt, kan teksten være “Vi kunne ikke gemme tilmeldingen. Dine oplysninger er bevaret. Prøv igen”. Hvis systemet ikke ved, om den er gemt, må beskeden ikke love, at en ny indsendelse er sikker. Forklar i stedet, hvordan brugeren får afklaret status uden dobbelttilmelding.

5. Afprøv fejl og kvittering

   Brug et testmiljø. Send først uden oplysninger, derefter med navn@, og til sidst med gyldige testoplysninger. Prøv også uden at vælge deltagelsesform. Gennemfør rettelserne med tastatur, og se, om de allerede udfyldte oplysninger bevares.

   Læs kvitteringen: Den skal sige, hvilken handling systemet har gennemført, og hvad der sker nu. “Tak” alene efterlader tvivl. I eksemplet kan kvitteringen sige “Du er tilmeldt workshoppen online. Vi har sendt en bekræftelse til navn@example.com”, men kun hvis begge handlinger faktisk er lykkedes.

   Hvis du arbejder i en formularbygger, så undersøg den publicerede formular. Felter, der ser korrekte ud i editoren, kan miste etiketter eller fejlrelationer i skabelonen. Send udvikleren en reproducerbar fejlbeskrivelse, når din editor ikke giver adgang til at rette det.

Teknisk bilag: Etiketter, gruppe, og fejlrelation

HTML-udsnittet viser en afvist indsendelse. Navn, den ufuldstændige adresse, og radiovalget er bevaret. Det viser feltstrukturen; serverbehandling og valideringslogik skal implementeres særskilt. Brug native required og type="email", hvor de passer, og validér også på serveren.

<form method="post">
  <p>Alle felter skal udfyldes.</p>
  <label for="navn">Navn</label>
  <input id="navn" name="navn" autocomplete="name"
    required value="Anne Eksempel">

  <label for="email">E-mailadresse</label>
  <p id="email-hjaelp">
    Vi sender bekræftelsen til denne adresse.
  </p>
  <input id="email" name="email" type="email"
    autocomplete="email" required value="navn@"
    aria-invalid="true"
    aria-describedby="email-hjaelp email-fejl">
  <p id="email-fejl">
    E-mailadressen mangler et domæne efter @.
    Skriv hele adressen, for eksempel navn@example.com.
  </p>

  <fieldset>
    <legend>Hvordan vil du deltage?</legend>
    <label><input type="radio" name="deltagelse"
      value="lokale" required> I lokalet</label>
    <label><input type="radio" name="deltagelse"
      value="online" required checked> Online</label>
  </fieldset>
  <button type="submit">Send tilmelding</button>
</form>

for og id forbinder etiketten med feltet. legend navngiver radiogruppen; et fælles name gør ikke dette alene. aria-describedby forbinder hjælpetekst og fejl med e-mailfeltet. Fjern fejlrelationen og aria-invalid="true", når fejlen er rettet, uden at fjerne den fortsat relevante hjælpetekst.

En fejlopsummering kan få tabindex="-1", så JavaScript kan flytte fokus til den efter en afvist indsendelse. Giv den en overskrift og rigtige links til felternes id’er. Afprøv, at links også flytter tastaturfokus til felterne. Tilføj ikke role="alert" til samtlige feltfejl.

Tjekliste

• Etiketter og nødvendige instruktioner er synlige før og under indtastning.
• Relaterede valg har et fælles spørgsmål, som også findes i den tilgængelige struktur.
• Hver konstateret inputfejl identificeres og forklares med tekst.
• Rettelser kan udføres uden at miste andre indtastede oplysninger.
• Inputfejl, tekniske fejl, og kvittering beskriver den faktiske situation.
• Det fulde forløb er afprøvet, også med tastatur.

Værktøjer og kilder

• Download Forward Accessibility Lens til inspektion af navne og ARIA-oplysninger. Værktøjet kan ikke alene bekræfte, hvordan en fejl annonceres.
• W3C: Etiketter til formularfelter
• W3C: Gruppering af formularfelter
• W3C: Feedback efter indsendelse
• WCAG 2.2, kriterium 3.3.1: Error Identification. Kriteriet foreskriver ikke en bestemt ARIA-teknik; browserens egen fejltekst kan opfylde kravet i den konkrete situation.

Senest gennemgået: 13. oktober 2026.