Förenklad beskrivning av WCAG-kriteriet 3.3.1

Visa var ett fel uppstått och beskriv det tydligt

Hjälp dina användare när det blir fel. Det måste vara tydligt för användaren var felet finns och felet behöver beskrivas med text. Välformulerade felmeddelanden ger användarna möjlighet att fylla i så felfria data som möjligt i formulären. De minskar också risken för att användarna ska bli irriterade när systemet inte förstår eller kan tolka den felaktigt inmatade informationen.


Sammanfatta felen och använd en layout som tydligt separerar felmeddelanden från resten av webbplatsens designLänk hit

Ju snabbare en användare upptäcker ett felmeddelande desto lättare är det att åtgärda felet och fortsätta fylla i formuläret. Ett sätt att göra det på är att tydligt separera felmeddelanden från webbplatsens övriga design. Det gör man genom att:

  • Placera felmeddelanden väl synligt och i direkt anslutning till det fält där felet inträffat. Tala också om för användarna vad som gått fel. Ange i sidans titel (i title-element) att ett fel inträffat.
  • Samla alla felmeddelanden i början av sidan så att användarna får en överblick över vad de måste göra för att korrigera felen. Om flera fel har inträffat bör du ange i texten hur många fel användarna måste åtgärda för att komma vidare.

Exempel på sammanfattning av fel

Skatteverkets felmeddelande skiljer sig tydligt i utformning från övriga webbplatsen.

Skärmdump med texten "Du måste alltid ange Telefonnummer dagtid eller Mobilnummer" i ruta som användaren måste stänga för att komma vidare.

Felmeddelanden på Mina vårdkontakter lägger sig som ett lager ovanpå formuläret. Det innehåller tydlig information om vilka fält som måste fyllas i. När användaren klickar på stäng hamnar hen på rätt fält automatiskt.

Exempel på markering av felmeddelande

Ett ofullständigt ifyllt inmatningsfält (inklusive etikett och felmeddelande) markeras med en röd ram och en avvikande bakgrundsfärg.

Felmeddelanden på Migrationsverkets webbplats har en tydlig markering runt varje felaktigt eller ofullständigt ifyllt fält och en text som beskriver felet.


Skriv välformulerade felmeddelanden så ökar chansen att användarna gör rättLänk hit

Underlätta för användarna genom att använda en artig ton i felmeddelanden och beskyll dem inte för att ha gjort något dumt eller fel. Det kommer bara att skapa irritation. Tänk på att inmatningsfel ofta beror på de krav du ställer på användarna utifrån tekniska krav eller brister i den tekniska plattformen, exempelvis att personnummer måste skrivas på ett visst sätt för att systemet ska godkänna det. Det finns flera sätt man kan underlätta för användarna:

  • Skriv begripliga felmeddelanden. Använd inte ord och formuleringar som är svåra att förstå. De ord som används i felmeddelandet ska stämma överens med de ord som används i formuläret.
  • Vägled användarna till den del av formuläret där de kan åtgärda felet. Använd länkar i felmeddelandetexten för att underlätta navigationen från felmeddelandet till de relaterade inmatningsfälten.
  • Om det finns flera olika sätt att mata in uppgifterna, låt användaren välja i en lista över de olika möjligheterna.
  • Ge konkreta råd om hur de kan lösa problemen och undvika nya fel.

Exempel på formulering av felmeddelande

Exemplet nedan visar ett artigt tilltal som man kan använda i ett felmeddelande och hur man kan beskriva och länka till de fält som inte har fyllts i på rätt sätt.

Vi har två problem med din anmälan

Vänligen ändra dessa delar. Klicka sedan på ”Skicka anmälan” igen.

  1. Fältet ”namn” får inte vara tomt. Ange ditt namn.
  2. Fältet ”ålder” får inte vara tomt. Ange din ålder.


Markera fel och felmeddelanden med ARIA så att de uppfattas tydligt av användare med hjälpmedelLänk hit

För användare som till exempel lyssnar igenom sidan kan det vara mycket svårt att hitta ett fel. Ett sätt att säkerställa att användare med skärmläsare blir informerade om identifierade fel är att markera både fel och felmeddelande i koden, med hjälp av ARIA:

Attributet aria-invalid kan sättas dynamiskt på ett formulärelement för att indikera att det innehåller ett fel (till exempel att värde saknas trots att fältet är obligatoriskt, eller att formatet på angiven data är fel).

Aria-attributet role med värdet alertdialog kan användas för att indikera med kod att ett felmeddelande presenteras. Då skapas en notifiering som gör att användaren inte missar meddelandet.


Spara det som inte är felLänk hit

Bevara så mycket av den inmatade informationen som möjligt, så att bara det som blivit fel behöver matas in igen. Det riskerar att skapa irritation hos användarna om de måste börja om från början igen trots att bara ett fält behöver korrigeras.


Utdrag från WCAG-standardenLänk hit

Riktlinje 3.3 Inmatningsstöd: Hjälp användare att undvika misstag och rätta till misstag.

3.3.1 Identifiering av fel: Om ett inmatningsfel upptäcks automatiskt så ska det som är fel markeras och felet beskrivas för användaren med text. (Nivå A)


Mätbarhet: användningstesterLänk hit

Utvärdera felmeddelanden i användningstester.


TerminologiLänk hit

Utvecklare brukar använda engelskans form validation för att beskriva den process som sker när systemet kontrollerar att användarna har matat in korrekt formaterad information i ett webbformulär, till exempel att det är siffror och inte bokstäver i ett fält för telefonnummer. Validering och valideringsfel är också vanliga ord i sammanhanget.

Kommentarer till denna riktlinje

Kommentarer (5)

  • Besökare skriver:

    Tycker detta borde gälla även när användaren tappat anslutningen till nätet. Precis som en bra 404-sida är viktig borde man erbjuda offline-sidor som förklarar att användaren tappat kopplingen till nätet.

    Behöver inte vara så svårt, se exempelvis detta projekts kod:
    https://github.com/TalAter/UpUp/

  • Besökare skriver:

    I den avslutande sektionen ”Terminologi” står:

    Utvecklare brukar använda engelskans form validation för att beskriva …

    Kan göras lite tydligare genom att särskilt markera det engelska uttrycket:

    Utvecklare brukar använda den engelska termen ”form validation” för att beskriva …

    Då undviker man att folk vid läsning, av det som just nu står, uppfattar det som:

    Utvecklare brukar använda engelskans [språk-]form ”validation” för att beskriva …

    • Andreas skriver:

      Det är nog enbart folk som inte kan webbutveckling som missförstår detta. Vi läser ju inte svenska källor när vi lär oss, eftersom att de engelskspråkiga är mycket mer detaljerade och välskrivna, som exempelvis https://developer.mozilla.org/, w3c.org eller https://www.w3.org/WAI/ så de svenska termerna är aldrig närmast i huvudet. Exempelvis, vem säger ”maskinläsbar ettikett” som webbriktlinjer myntat? Ingen. Alla säger accessable name, eftersom att det handlar om accessibility, dvs tillgänglighet. Man kan undra om webbriktlinjer tyckte att ”accessable name” såg ut som orden ”machine readable label” med tanke på deras märkliga översättning.

  • Besökare skriver:

    Tack Olle för ditt förslag. Jag håller med. Det blir tydligare så.

  • Ilias Bennani skriver:

    I skärmdumpen ifrån Migrationsverkets (dåvarande?) webbplats visas felmeddelandet nedanför/efter inmatningsfältet.

    Väljer man istället att lägga felmeddelandet mellan label och inmatningsfält så vinner man två saker:

    – Användaren får läsa den fullständiga instruktionen (label och felmeddelande) innan användaren skall fylla i fältet.

    – På mobila enheter minskar risken för att felmeddelandet täcks över av mobilens tangentbord.

    Mitt förslag är att ändra riktlinjen så att ett felmeddelande ALLTID visas nedanför labeln och ovanför inmatningsfältet.


Om denna riktlinje

Den är relevant för DOS-lagen.

Status på vår webbplats


(Då uppdateras status i checklistorna.)

Om WCAG

WCAG (Web Content Accessibility Guidelines) är den standard som bland annat webbdirektivet och DOS-lagen bygger på. Se sidan Följ standarder för tillgänglighet.

WCAG 2.1 saknar ännu svensk översättning, men för de formuleringar som är identiska i version 2.0 och 2.1 citeras den officiella översättningen av version 2.0. Utdraget kan dock innehålla fel. Den version som är mest giltig vid uttolkning är det engelskspråkiga originalet på W3C:s webbplats.

Där finns även de officiella förklaringarna och lösningsförslag till riktlinjen (på engelska).