Tilgængelige formularer: Labels, fejlhåndtering og autocompletion

Formularer og tilgængelighed

En formular, der ikke kan betjenes uden mus — eller hvis fejlmeddelelser udelukkende kommunikeres via farve — er reelt utilgængelig for en bred gruppe borgere. Formularer er det interface, hvorigennem borgerne ansøger om ydelser, indberetter ændringer og indsender erklæringer. Alligevel er de konsekvent én af de kategorier, der genererer flest fejl i Digitaliseringsstyrelsens tilsynsrapporter.

Tre succeskriterier i WCAG 2.1 definerer kravene:

• 3.3.2 — Labels eller instruktioner (Niveau A): Alle formularfelter skal have klare, programmatisk forbundne labels.
• 3.3.1 — Fejl-identifikation (Niveau A): Fejl skal identificeres og beskrives i tekstform.
• 1.3.5 — Formålsidentifikation af input (Niveau AA): Formularfelter, der indsamler personoplysninger, skal bruge standardiserede autocomplete-attributter.

De tre kriterier dækker de hyppigste fejltyper og hænger tæt sammen i praksis.

Labels: Synlighed er ikke nok

WCAG 3.3.2 kræver, at alle interaktive formularfelter har en label — en klar tekstbetegnelse, der forklarer hvad feltet forventer. Det er ikke tilstrækkeligt, at labelen er visuelt til stede: den skal være programmatisk forbundet med feltet, så skærmlæsere og hjælpemidler kan kommunikere feltets formål til brugeren.

I HTML sker dette ved at bruge <label> med et for-attribut, der peger på feltets id:

<label for="cpr">CPR-nummer</label>
<input type="text" id="cpr" name="cpr" autocomplete="off">

Placeholder-tekst er ikke en erstatning for en label. Placeholder-tekst forsvinder, når brugeren begynder at taste — og mange skærmlæsere kommunikerer den ikke som en label. Et felt med kun placeholder-tekst opfylder ikke WCAG 3.3.2, uanset hvor tydeligt designet ser ud visuelt.

Skjulte labels og ARIA

I visse designmønstre ønsker man at skjule den synlige label — f.eks. i søgefelter, hvor feltets formål fremgår af konteksten. Det er acceptabelt at skjule en label visuelt med CSS, så længe den stadig er til stede i DOM’en og korrekt forbundet med feltet. Alternativt kan aria-label eller aria-labelledby bruges til at give feltet en programmatisk label uden en synlig tekstkomponent.

Et felt helt uden label — hverken synlig, CSS-skjult eller via ARIA — er et brud på 3.3.2 og er den hyppigste enkeltfejl i offentlige selvbetjeningsløsninger. Digitaliseringsstyrelsen fremhæver manglende labels som én af de tre mest udbredte tilgængeligheds-fejl på kommunale websteder.

Obligatoriske felter skal markeres, og markeringen skal forklares. Det er ikke tilstrækkeligt blot at tilføje en asterisk (*) uden at angive, hvad den betyder. Mange løsninger placerer forklaringen øverst i formularen — “Felter markeret med * er obligatoriske” — hvilket er acceptabelt, men kræver at forklaringen er tilgængelig for skærmlæserbrugere.

Fejlhåndtering: Mere end rød kant

WCAG 3.3.1 (Fejl-identifikation, Niveau A) kræver, at fejl ved formularindsendelse identificeres og beskrives i tekstform. Det er ikke tilstrækkeligt at markere et felt med en rød kant — farve alene er ikke tilgængeligt (WCAG 1.4.1), og brugere der er farveblinde eller anvender skærmlæser, modtager ingen information om fejlen.

En tilgængelig fejlmeddelelse skal opfylde tre betingelser:

Specificitet: Fejlmeddelelsen skal identificere præcist, hvilket felt der har en fejl, og beskrive hvad der er galt. “Der er fejl i formularen” er ikke tilstrækkeligt. “E-mail-adresse: Formatet er ugyldigt — angiv en adresse med @” giver brugeren information nok til at rette fejlen.

Programmatisk tilknytning: Fejlmeddelelsen skal knyttes til det relevante felt via aria-describedby, eller placeres umiddelbart ved feltet i DOM’en, så skærmlæseren læser den op, når feltet får fokus.

Fokusstyring: Når en formular valideres og afvises, bør fokus flyttes til fejlmeddelelsen eller det første fejlbehæftede felt. Mange løsninger reloader siden og returnerer fokus til toppen — hvilket efterlader tastaturbrugere og skærmlæserbrugere uden orientering om, hvad der gik galt.

Realtids-validering

WCAG 3.3.1 gælder primært ved indsendelse, men mange moderne formularer validerer løbende mens brugeren skriver. Realtids-validering er ikke et krav, men hvis det implementeres, bør fejlmeddelelser vises, når feltet mister fokus (on blur) — ikke mens brugeren stadig er i gang med at taste. Fejlmeddelelser, der vises efter hvert tastetryk, er forstyrrende for skærmlæserbrugere og opfylder sjældent formålet.

WCAG 3.3.3 (Fejl-forslag, Niveau AA) og 3.3.4 (Fejl-forebyggelse, Niveau AA) udvider kravene yderligere: løsninger med juridiske eller økonomiske konsekvenser bør give brugeren mulighed for at gennemse og rette indsendelsen, inden den bekræftes endeligt.

Autocompletion og WCAG 1.3.5

WCAG 1.3.5 (Formålsidentifikation af input, Niveau AA) er et af de kriterier, der oftest overses i offentlige selvbetjeningsløsninger — og et af de mest værdifulde for borgerne.

Kriteriet kræver, at formularfelter, der indsamler personoplysninger, er mærket med standardiserede autocomplete-attributter. Formålet er, at browsere og hjælpemidler kan udfylde felterne automatisk — og at borgere med kognitive funktionsnedsættelser, læsevanskeligheder eller motoriske begrænsninger slipper for at genindtaste de samme oplysninger i formular efter formular.

Eksempler på korrekt brug:

<input type="text"  autocomplete="name"           ...>
<input type="email" autocomplete="email"          ...>
<input type="tel"   autocomplete="tel"            ...>
<input type="text"  autocomplete="street-address" ...>
<input type="text"  autocomplete="postal-code"    ...>
<input type="text"  autocomplete="bday"           ...>

W3C publicerer en komplet liste over godkendte autocomplete-værdier som del af WCAG 2.1-dokumentationen. Felter, der indsamler CPR-numre, fødselsdatoer eller betalingsoplysninger, er eksplicit nævnt i standarden.

autocomplete="off" må ikke bruges til at omgå kravet. Det er kun legitimt at slå autocompletion fra, hvis der foreligger en konkret sikkerhedsmæssig begrundelse — f.eks. et felt til engangskoder eller sessionsbundne tokens.

Formularer i PDF-dokumenter

Mange offentlige myndigheder distribuerer blanketter som PDF-filer — enten som statiske skemaer der printes og underskrives, eller som interaktive PDF-formularer med udfyldbare felter. Begge typer stiller særlige tilgængeligheds-udfordringer.

Interaktive PDF-formularer skal opfylde PDF/UA-kravene for at være tilgængelige: hvert felt skal have en tooltip-baseret label, tabrækkefølgen skal svare til den logiske læserækkefølge, og obligatoriske felter skal markeres programmatisk. Selv velstrukturerede PDF-formularer er generelt vanskeligere at tilgå via tastatur og skærmlæser end HTML-formularer — og understøtter hverken autocomplete eller browser-native fejlvalidering.

For blanketter, der er borgernes eneste adgang til en offentlig ydelse, vejleder Digitaliseringsstyrelsen om, at de enten skal opfylde PDF/UA eller suppleres med en tilgængeligt HTML-version. Se artiklerne om PDF/UA-standarden og PDF til HTML for en gennemgang af de tekniske krav og konverteringsmuligheder.

Tjekliste: Tilgængelige formularer

Brug denne tjekliste til at verificere, at dine formularer opfylder WCAG 2.1 AA:

• Alle formularfelter har en <label> der er programmatisk forbundet med feltet (WCAG 3.3.2)
• Placeholder-tekst bruges ikke som erstatning for labels (WCAG 3.3.2)
• Obligatoriske felter er markeret, og markeringen forklares i tekst (WCAG 3.3.2)
• Fejlmeddelelser identificerer præcist, hvilket felt der har fejl — i tekstform (WCAG 3.3.1)
• Fejl kommunikeres ikke kun via farve eller ikon (WCAG 1.4.1)
• Fokus flyttes til fejlmeddelelsen eller første fejlbehæftede felt ved indsendelse
• Formularfelter med personoplysninger har korrekte autocomplete-attributter (WCAG 1.3.5)
• autocomplete="off" bruges ikke uden sikkerhedsmæssig begrundelse (WCAG 1.3.5)
• Formularen kan betjenes fuldstændigt med tastatur (WCAG 2.1.1)
• Skærmlæsere annoncerer fejlmeddelelser korrekt via aria-describedby eller tilsvarende