• 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.

• Se till att publiceringsverktyget har stöd för att hantera flera språk och teckenuppsättningar på ett korrekt, enkelt och effektivt sätt. Valet av publiceringsverktyg kan sätta gränser för vad som är möjligt att göra i ett flerspråkigt perspektiv.
• Översätt grundläggande navigeringselement som sök och kontakt om ni har omfattande avdelningar på olika språk.
• Ange aktuellt språk i html-kod och kontrollera att den automatiska textuppläsningen fungerar också för andra språk än svenska.
• Ange språkriktning för innehåll som läses från höger till vänster.
• Låt en person som behärskar det aktuella språket läsa igenom sidan och komma med synpunkter.

• Ange datumet för när informationen på en sida publicerades eller senast uppdaterades eller granskades.
• Bedöm om det finns andra datum som är relevanta att ange, till exempel datum då ett nytt regelverk började gälla. Ange tydligt om ett datum gäller något annat än publicerings- eller uppdateringsdatum.
• Ange även klockslag på sidor som uppdateras löpande eller där spårbarheten är viktig, till exempel sidor med krisinformation.

De flesta webbpubliceringsverktyg har inbyggda funktioner för att automatiskt visa tidpunkten för publiceringen på webbsidan.

• Låt menyer och navigation ange var användaren befinner sig.
• Underlätta navigeringen med länkstigar.

• Ta reda på vad på webbplatsen som är viktigast för användarna, och vilka frågor de vill ha svar på. Lägg ingångar till detta redan på startsidan.
• Skapa en informationsstruktur som utgår från användarnas önskemål, behov och processer genom att gruppera innehållet på ett sätt som är logiskt för användarna. Använd ord som besökarna är bekanta med i menyer, länkar och rubriker.
• Erbjud mer än ett sätt att hitta information och navigera på webbplatsen. Gör det enkelt att växla mellan de olika sätten. Se mer i R32. Erbjud besökaren alternativa orienteringsstöd.

• Låt gränssnittselement ha samma utseende, funktionalitet och placering på hela webbplatsen.

• Se till att alla sidor har länkar till startsidan och andra sidor som är viktiga för orienteringen. Det kan vara webbkartan, ”Om webbplatsen”, sökfunktionen och information på andra språk.
• Placera länkarna i sidhuvudet och/eller i sidfoten.
• Länka webbplatsens eller organisationens logotyp till webbplatsen startsida. Om logotypen är en bild, ange i alt-texten att länken går till startsidan.

• Erbjud flera olika navigeringsstöd på webbplatsen.
• Utgå från användarnas behov och webbplatsens komplexitet när ni väljer navigeringsstöd.
• Erbjud en sökfunktion.

• Gör de klickbara ytorna tillräckligt stora. Det underlättar för användarna.
• Framhäv länkarna grafiskt så att användarna förstår vad som är länkad text.

• Välj ett läsvänligt typsnitt och ange det i stilmallen.
• Undvik helt versala rubriker och texter.
• Anpassa radavståndet.
• Vänsterjustera löptext och menyer.
• Ange maximal spaltbredd och anpassa radlängden.

• 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.

• Ö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.

• 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.)

• 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.

• 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.

• 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.

• Låt det som hör ihop stå i ett stycke, som ett resonemang, en tanke eller en sakfråga. Stycken kan variera i längd, men tre till tio meningar är vanligt. Använd alltid blankrad som styckemarkör för webbtexter.
• Inled stycket med det viktigaste.
• Låt gärna den första meningen sammanfatta stycket och utveckla sedan resonemanget med förklaringar och exemplifieringar.
• Använd gärna bilder, kant- och mellanrubriker, punktlistor och andra grafiska medel för att skapa en luftig och lättöverskådlig struktur på varje sida. Var dock konsekvent i användandet av sådana medel, liksom i användningen av färger, typsnitt med mera.
• Skriv informationstäta uppräkningar i punktlisteform. Placera de viktigaste listpunkterna först.
• I längre texter kan fetade nyckelord underlätta läsningen.

• 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.

• Använd publiceringsverktyg och applikationer som tillåter de datumformat som är standard i Sverige: ”(den) 13 december 2013”, ”2013-12-13” eller ”13.12.2013”.
• Var lagom exakt, avrunda tal för till exempel filstorlekar och klockslag.
• Ange alltid årtal.

• Använd kortkommandon sparsamt.
• Använd vedertagna tangentkombinationer om sådana finns.
• Informera om vilka kortkommandon ni erbjuder.
• Gör det möjligt att stänga av eller byta ut kortkommandon som bara består av ett tecken.

• 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.

• Skapa genvägar för att hoppa över delar i strukturen till exempel menyn, för att komma direkt till sidans innehåll.
• Skapa rubriker med h-element, eftersom skärmläsare låter användarna snabbnavigera med hjälp av sidans rubriker.
• Använd WAI-ARIA landmark roles, till exempel main, search, navigation, banner, contentinfo och så vidare. Det gör att användare med exempelvis skärmläsare kan navigera mellan sidans olika delar på ett standardiserat sätt.
• Om du använder HTML5, använd strukturelement som main, aside, header, footer och nav för att definiera vilken roll varje del av sidan har.
• R68. Skapa snabbkommandon vid behov.

• 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.

• Publicera dokument i standardformatet html. Då kan användarna komma åt er information utan att använda en viss datorplattform, eller ett program som kostar pengar, till exempel Word.
• Om ni har dokument i andra format än html, sammanfatta dem i html, så att användarna kan bedöma innehållet utan att ladda ner det.
• Utforma dokument så att de enkelt kan läsas på skärm. Då bidrar ni till att färre användare skriver ut på papper.
• Om ni använder pdf:er, se till att de skapas så att de blir tillgängliga.

• Undvik horisontell scrollning ner till 320 pixlars bredd.
• Använd i första hand responsiv design.
• Gör en anpassad mobilversion om responsiv design är inte är möjligt.
• Även dokument som inte är webbsidor bör kunna presenteras i begränsad bredd.

• 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.

• Låt bakåtknappen fungera (se undantag nedan).
• Undvik att öppna nya fönster, särskilt fönster som täcker hela skärmen; då fungerar inte bakåtknappen.
• Ställ krav på att bakåtknappen ska fungera, när ni upphandlar system, eller tidigt under utvecklingsprocessen. Hur och om bakåtknappen fungerar kan nämligen bero på den grundläggande tekniken.

• 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.

• Stryk aldrig under text som inte är länkad, eftersom det kan leda användarna att felaktigt tro att texten är en länk.

• Visa det viktigaste innehållet tidigt.
• Anpassa innehållet till små skärmar.
• Anpassa funktionaliteten till små skärmar.
• Se till att tjänsten går att zooma.
• Använd inte ramar.
• Gör det enkelt att skapa bokmärke/genväg till webbplatsen.

• 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

• Testa läsordningen genom att granska en sida av varje sidtyp med några skärmar i olika storlek och genom att lyssna igenom innehållet med en skärmläsare.
• Se till att webbplatsen kan användas även utan stilmallar. Vissa webbläsare och tilläggsprogram har funktioner för att avaktivera CSS.
• Se till och testa även att läsordningen är logisk i dokument som inte är html (pdf, word med mera) .

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.

Komplettera betydelsebärande färgskillnader med någon annan synlig skillnad:

• Ikoner eller liknande grafiska element kan ibland passa som komplement till färgskillnader.
• Färgskillnader mellan textelement kan kompletteras med understrykning, ram, fetstil, kursivering eller annat teckensnitt. Var särskilt noga med att framhäva länkar.
• Färgskillnad mellan ytor i bland annat kartor och diagram kan kompletteras exempelvis med mönster, inramning, kontrastskillnad eller text.
• Linjer kan exempelvis göras streckade, prickade, prickstreckade eller dubbeldragna.
• Ibland behöver färgskillnader kompletteras med skriven text som ger motsvarande information.
• Semantisk kodning är ofta ett bra men otillräckligt komplement: Skärmläsare presenterar ofta den semantiska informationen, men det är inte alla användare som har skärmläsare.

Var särskilt försiktig med färgerna grön, röd och brun. Många personer med färgblindhet har svårt att särskilja dessa.

• I de flesta fall är det lämpligt att undvika att spela ljud automatiskt.
• I andra hand kan det vara lämpligt att erbjuda en pausfunktion i början av sidan.

• Lita inte på automatisk granskning av kontraster
• Överträffa gärna gränsvärdena för kontrast
• Överväg att låta användaren välja kontraster

Testa alla webbplatser och applikationer utan mus och utan pekskärm.

• Kontrollera ordningen utan pekdon.
• Säkerställ en logisk ordning med tabindex.

Använd CSS för att tydligt visa vilket element som är i fokus.

• 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.

• 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.

• 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.

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.

• Använd bara i undantagsfall de tekniker som finns för att låsa skärmens riktning (exempelvis Screen Orientation API).
• Se till att allt innehåll presenteras oavsett skärmens riktning.

• 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.

• Ge gränssnittskomponenter tydliga visuella gränser.
• Gör helst även inaktiva element urskiljbara för alla.
• Använd god kontrast för informationsbärande delar av illustrationer och annat grafiskt innehåll, så långt det är rimligt.

• Placera text i utrymmen som är tillräckligt stora eller som anpassar sig efter innehållet.
• Ta hänsyn till att texter kan ändra storlek om du använder absolut positionering av element som riskerar att krocka med texten.

• Överväg att presentera innehållet på något annat sätt.
• Gör det enkelt att ta bort innehållet.
• Gör det möjligt att hantera innehållet för alla.

• Se till att all funktionalitet går att utföra med flera fingrar även går att utföra med bara ett finger

• Ge i första hand användaren möjlighet att ångra åtgärden innan nedtryckningen upphör (up-eventet).
• Ge i andra hand användaren möjlighet att ångra sig efter up-eventet.
• Koppla bara i undantagsfall aktivering till nedtryckning av knappen eller skärmen (down-eventet).

• Ta reda på vilken maskinläsbar etikett som används för kontrollen.
• Se till att den maskinläsbara etiketten matchar den synliga.
• Använd bara samma maskinläsbara etikett för flera kontroller om de gör exakt samma sak.

• Se till att funktioner som kan hanteras med rörelsestyrning även kan hanteras på något annat sätt.
• Gör det möjligt att stänga av rörelsestyrningen.

• 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.

• Undersök vilka tillgänglighetsfunktioner ni erbjuder.
• Säkerställ att de som har nytta av funktionerna kan nå dem.
• Blockera inte operativsystemets tillgänglighetsfunktioner.

• Ställ inte för höga krav på motorisk förmåga.
• Gör det möjligt att avläsa aktuell inställning utan att ändra den.
• Hjälp användaren att undvika oavsiktlig inmatning.

• Kom ihåg att vissa användare behöver skräddarsy presentationen.
• Försök att inte hindra att användarens inställningar slår igenom.
  • Använd relativa måttenheter om det är möjligt
  • Var försiktig med css-uttrycket !important

• Dokumentera tillgängligheten
  • Beskriv tillgänglighetsfunktioner vid behov
  • Gör tillgänglighetsfunktioner lätta att hitta
  • Offentliga aktörer ska ha en tillgänglighetsredogörelse
• Gör dokumentationen tillgänglig
  • Se till att tillgänglighetsdokumentation uppfyller tillgänglighetskrav
  • Gör tillgänglighetsdokumentationen lätt att hitta