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.
Rekommendationer för tydliga felmeddelandenLänk hit
- Sammanfatta felen och använd en layout som tydligt separerar felmeddelanden från resten av webbplatsens design.
- Skriv välformulerade felmeddelanden så ökar chansen att användarna gör rätt från början.
- Markera fel och felmeddelanden med WAI-ARIA så att de uppfattas tydligt av användare med hjälpmedel.
- Spara det som inte är fel.
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.
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
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.
- Fältet ”namn” får inte vara tomt. Ange ditt namn.
- 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)
Fördjupning: användbara felmeddelandenLänk hit
- R101. Markera obligatoriska fält i formulär
- R59. Låt användaren fylla i information på valfritt format
- R149. Ge förslag på hur fel kan rättas till
- På WebAims webbplats kan du läsa mer om tillgängliga och användbara felmeddelanden. Informationen är på engelska.
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)
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/
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 …
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.
Tack Olle för ditt förslag. Jag håller med. Det blir tydligare så.
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.
Skriv kommentar
Funktionen för att skriva kommentarer använder kakor. Läs mer om kakorna. Enbart förstapartskakor används. Vill du inte godkänna kakor så kan du ställa in din webbläsare att blockera dem. Funktionen går ändå att använda men den kommer då att ställa vissa frågor om och om igen, och kan inte förhandsvisa dina kommentarer.
För att kunna erbjuda denna funktion behöver vi lagra de uppgifter som du själv skriver in (namn, e-post, eventuell webbadress och själva kommentaren) samt IP-nummer. Den rättsliga grunden är samtycke och informationen ligger kvar så länge DIGG bedömer att den tillför förståelse för riktlinjen, eller tills du begär att den raderas. Läs mer om DIGGs behandling av personuppgifter.