Formulär & felhantering

De här riktlinjerna är särskilt relevanta för digitala tjänster där användaren behöver mata in information, till exempel myndigheters e-tjänster och beställningar i e-handel. De kallas ibland självbetjäningstjänster.

Visa som kompakt lista

Prio Motsvarar i WCAG Nr. Riktlinje Status
2 R7 Använd en krypterad anslutning för e-tjänster
  • Använd en krypterad anslutning, https, till alla e-tjänster som innehåller inloggningsinformation eller personliga eller ekonomiska uppgifter.
  • Skicka inloggningsinformation över en krypterad kanal.
  • Överväg om hela webbplatsen bör kunna användas över en krypterad anslutning.
  • Använd ett certifikat från en certifikatutfärdare som förekommer i de vanligaste webbläsarna. Annars kan användarna få ett felmeddelande om att utfärdaren inte är betrodd.
  • Se till att era certifikat är giltiga så att användarna slipper felmeddelanden och varningar.
  • Se till att alla webbplatsens resurser kan laddas över en krypterad kanal, även om de inkluderas från en tredje part. Annars kan användaren få felmeddelanden och varningar.
  • Omdirigera användare till den krypterade kanalen om de försöker nå en sida över en okrypterad kanal.
  • Skriv gärna länkar till externa webbplatser med https:// om webbplatsen har stöd för det. Det gör att användarna hamnar rätt från början.
3 R93 Använd Javascript för att öka tillgängligheten – inte tvärtom
  • Använd gärna Javascript, men se till att även de som inte använder Javascript kan använda de viktigaste funktionerna. Följ principen om progressiv förbättring, det vill säga bygg först all funktionalitet som vanlig html. Använd sedan Javascript som ett förhöjande tillägg.
  • Se upp så att Javascript inte gör webbplatsen otillgänglig. Denna riktlinje ger flera råd som du bör tänka på om du använder Javascript.
  • I undantagsfall kan faktorer utanför din kontroll göra att besökare måste använda Javascript. Upplys då användaren om att Javascript krävs för att använda tjänsten.
  • Om vissa användare utestängs på grund av att de saknar Javascript kan ni eventuellt ha skyldighet att erbjuda fullgoda alternativ. Detta gäller särskilt myndigheter.
4 R58 Använd standardutseendet på formulärens element
  • Låt formulärelementen behålla standardutseendet.
  • Gör användningstester för att kontrollera att formulären fungerar, om ni trots allt ändrar utseendet.
  • Anpassa storleken på textfält till förväntat innehåll.
DOS-krav 3.2.4 (AA) R146 Benämn funktioner konsekvent
  • Använd samma termer för återkommande funktioner såsom knappar och ikoner, eftersom vissa användare saknar till exempel layout och formgivning som annars kan användas för orientering.
3 R71 Bestäm om e-tjänsten behöver e-legitimation och signering
  • Kräv identifiering i e-tjänster som visar integritetskänslig information.
  • Visa ärendets uppgifter sammanställda i slutet av e-tjänstflödet, så att användarna kan kontrollera att uppgifterna är korrekta.
  • Var tydlig med att när användaren ”signerar” sitt ärende med sin e-legitimation har signeringen samma juridiska status som en signatur med namnteckning.
4 R52 Fyll formulär med kända uppgifter
  • Överväg att automatiskt fylla i uppgifter i formulär. Det kan ske om en användare redan tidigare har lämnat uppgifter till er, eller om uppgifterna kan hämtas från annat håll.
  • Ta hänsyn till riskerna med färdigifyllda uppgifter.
  • Ge användarna möjlighet att ta bort eller ändra uppgifterna själv i formuläret eller gör det enkelt för dem att ta kontakt med er för att påpeka om uppgifterna är inaktuella eller felaktiga.
DOS-krav 2.2.1 (A) R131 Ge användarna möjlighet att justera tidsbegränsningar
  • För vissa användare och i vissa sammanhang behövs gott om tid för att använda digitala tjänster. Ge därför användare möjlighet att stänga av, anpassa eller utöka eventuella tidsbegränsningar, om det inte är orimligt för att uppnå sajtens syfte.
3 R76 Ge e-tjänster namn utifrån användarnas perspektiv
  • Använd till exempel ”ansök om...” istället för ”e-tjänst för...” när du bestämmer namn på din e-tjänst.
  • Blanketter och e-tjänster fyller samma behov för användarna, och bör därför finnas på samma ställe, behandlas parallellt i informationsmaterial och så vidare.
DOS-krav 3.3.3 (AA) R149 Ge förslag på hur fel kan rättas till
  • R52. Fyll formulär med kända uppgifter
  • R57. Låt användarna fylla i information i valfritt format
  • R101. Markera obligatoriska fält i formulär
  • R112. Ge ordförslag i sökning och inmatningsfält
DOS-krav 3.3.4 (AA) R150 Ge möjlighet att ångra, korrigera eller bekräfta vid viktiga transaktioner
Erbjud användarna minst en, men gärna fler, av följande skyddsåtgärder:
  • Möjlighet att ångra sin åtgärd.
  • Möjlighet att rätta till möjliga fel som systemet identifierat.
  • Möjlighet att förhandsgranska sina uppgifter och rätta eventuella fel innan åtgärden slutligen bekräftas.
3 R112 Ge ordförslag vid sökning och inmatning
  • Ge dynamiska ordförslag i sök- och inmatningsfält
  • Ge förslag på alternativa sökord och stavningar efter sökning
  • Ge statiska ordförslag på rätt sätt
2 R77 Ge tydlig återkoppling i e-tjänster
  • Välj lämpliga kanaler för att meddela användarna att status i ett ärende har ändrats.
  • Användarna ska kunna granska sina uppgifter och få en kvittens. Kvittensen bör kompletteras med ett e-brev.
  • Användarna ska få ett mottagningsbevis från den organisationen som fått deras uppgifter.
3 R53 Gruppera formulärets fält
  • Tänk igenom vilka beroenden som finns mellan uppgifterna som ska fyllas i. Placera fält med uppgifter som användaren har nytta av när han eller hon fyller i andra fält på samma sida. Även ska information som krävs för att kunna fatta ett beslut finnas på samma sida samt uppgifter som styr övrig information som ska fyllas i.
  • Dela upp formuläret på flera sidor om det är omfattande och innehåller många fält som användaren ska fylla i.
  • Visa vilket steg användaren befinner sig på samt hur många steg som återstår när formuläret sträcker sig över flera sidor, till exempel ”Steg 1 av 3: Dina kontaktuppgifter”. (Se även R63. Hjälp användaren att förstå var hon befinner sig i en process.)
DOS-krav 1.3.3 (A) R123 Gör inte instruktioner beroende av sensoriska kännetecken
Använd gärna sensoriska kännetecken (färg, form med mera) för instruktioner eftersom det kan vara en effektiv metod för att underlätta för användarna, inklusive personer med kognitiva begränsningar men kom ihåg att komplettera informationen så att alla kan förstå den.
2 R60 Gör tydliga användbara knappar
  • Namnge knappar så att användarna förstår vad som händer när de klickar på dem.
  • Ge knapparna en logisk och användbar placering.
  • Använd lagom många knappar.
  • Presentera inte knappens text enbart som bild.
3 R57 Låt användarna fylla i information i valfritt format
  • Låt användarna fylla i information i valfritt format.
  • Undvik att visa felmeddelanden om det går att lösa behovet med programmering.
  • Skapa kontrollfunktioner som ger informationen rätt format.
  • Låt systemet ta bort oönskade tecken.
3 R101 Markera obligatoriska fält i formulär
  • Använd en bild av en asterisk (*) för att markera ett obligatoriskt fält i ett formulär. Den ska placeras före inmatningsfältet, i label-elementet. Låt bilden ha textekvivalenten alt=”obligatoriskt”.
  • Informera användarna före formuläret genom att skriva till exempel ”Fält markerade med * är obligatoriska och måste fyllas i”.
  • Använd den uppmärkning av obligatoriska fält som fungerar med den html-version du valt.
3 R50 Minimera antalet fält i formulär
  • Minimera antal fält i formulären genom att slå ihop flera fält till ett, till exempel för- och efternamn eller gatunamn och nummer.
  • Gör det så tydligt som möjligt vilka fält som är obligatoriska. Gruppera dem gärna, så att användarna sedan enkelt kan hoppa över frivilliga fält.
Ett annat upplägg är att först bara visa de obligatoriska fälten. När användaren har fyllt i dem visas de frivilliga fälten.
DOS-krav 1.3.5 (AA) R154 Märk upp vanliga formulärfält i koden
  • Använd attributet autocomplete på inmatningsfält.
  • Beskriv förväntat innehåll med attributet autocomplete, om det finns en standardiserad benämning.
  • Ange autocomplete=”off” om det gäller känslig information eller om servern erbjuder ordförslag.
DOS-krav 4.1.3 (AA) R164 Se till att hjälpmedel kan presentera meddelanden som inte är i fokus
  • Markera med aria-kod de områden där statusmeddelanden kan presenteras.
  • Använd gärna samma teknik även för andra viktiga förändringar.
  • Använd aria med försiktighet så att du inte stör användaren.
DOS-krav 4.1.2 (A) R152 Se till att skräddarsydda komponenter fungerar i hjälpmedel
  • Använd i första hand standardkomponenter som finns i html. Då uppfyller du automatiskt detta krav. Bara när det finns starka skäl och tillräckliga resurser för test och utveckling bör skräddarsydda komponenter utvecklas.
  • Vid val av tilläggsprogram eller kodplattformar (till exempel olika javascript-bibliotek) behöver ni undersöka om eventuella komponenter som bygger på dessa plattformar har ett bra stöd för tillgänglighet.
DOS-krav 3.3.2 (A) R55 Skapa tydliga och klickbara fältetiketter/ledtexter
  • Skriv tydliga och informativa fältetiketter/ledtexter
  • Koppla ihop fältetikett/ledtext och inmatningsfält så att även etiketten blir klickbar.
  • Placera fältetiketterna där användarna lätt ser dem.
  • Skriv utförliga instruktioner före formuläret, när sådana behövs.
  • Lösningen ska inte vara beroende av title-attribut och placeholder-texter.
4 R70 Skydda användaren mot att oavsiktligt förlora påbörjat arbete
  • Låt om möjligt användaren själv avgöra när information som redigerats eller matats in i ett formulär ska överges.
DOS-krav 3.2.1 (A) R143 Utför inga oväntade förändringar vid fokusering
  • Utför bara förändringar (till exempel öppning av fönster eller förändring av värde) när användaren förväntar sig dem.
DOS-krav 3.2.2 (A) R144 Utför inga oväntade förändringar vid inmatning
  • Utför bara förändringar (till exempel öppning av fönster eller förändring av värde) när användaren har anledning att förvänta sig dem.
4 R73 Var tydlig med förutsättningar för att kunna använda e-tjänsten
  • Beskriv vid tjänstens ingång vad användaren måste ha tillgång till för att kunna slutföra tjänsten.
  • Ge möjlighet att titta igenom hela tjänsten utan att logga in, och utan att få varningar för att obligatoriska fält inte är ifyllda. Gärna via en speciell ingång, där det inte är möjligt att fylla i uppgifter. Detta minskar risken för att användaren ändå börjar fylla i formuläret men inte kan slutföra transaktionen.
DOS-krav 3.3.1 (A) R2 Visa var ett fel uppstått och beskriv det tydligt
  • 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.
3 R63 Visa var i en process användaren befinner sig
  • Visa och beskriv för användarna var de befinner sig i processen.
  • Använd tydliga bilder och pilar, till exempel en så kallad processfisk, så att användarna får en överblick av processen.
Exportera urval som csv