• 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

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

• Erbjud ett textbaserat manus eller någon annan presentation som inte utestänger användare som saknar förutsättningar att uppfatta inspelningen.

• Informera användaren om att det finns alternativ.

Observera att den som uppfyller R120 Syntolka videoinspelningar (som i WCAG 2.1 motsvaras av ett kriterium med den högre ambitionsnivån AA) även uppfyller den här riktlinjen, eftersom syntolkning är ett av alternativen på A-nivå.

• Överväg direkttextning trots undantag i webbdirektivet
• Informera om att det finns textning

• Se till att viktig visuell information framgår även av ljud
• Följ riktlinjer för syntolkning
• Anpassa syntolkningen efter rytmen i ordinarie innehåll
• Gör det lätt att hitta och aktivera syntolkningen
• Undersök alternativa lösningar

• R105. Skapa rubriker med h-element
• R104. Använd rätt html-element när ni gör listor
• Namnge formulärfält med kopplade label-element. Se R55. Skapa tydliga och klickbara fältetiketter.
• R98. Skriv rubriker till tabeller
• R101. Markera obligatoriska fält i formulär
• Betona innehåll med elementet em och inte bara kursivering, eftersom det inte går att kursivera skärmläsarens tal.
• Använd WAI-ARIA för sådant som inte går att uttrycka med vanlig html.

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

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

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

Maximalt tre växlingar från ljus till mörk eller tvärtom inom en sekund är acceptabelt.

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

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

• Använd nyckelord ur texten.
• Skriv de viktigaste orden först.
• Använd aktivt språk, gärna verb.
• Gör inte rubrikerna längre än 5-10 ord.

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

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

• 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

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

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