Riktlinjer

Antal matchande riktlinjer: 66.

Med hjälp av filtreringsfunktionen här intill kan du välja ut de riktlinjer som är mest relevanta för dig.

Prio WCAG Nr. Riktlinje Status
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.
1 R34 Gör länkar, klickbara ytor och menyer användbara för alla
  • 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.
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.
1 R80 Följ kodstandarder
  • Som uppmärkningskod, använd HTML 5 eller HTML 4.01. Se R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare.
  • Validera koden vid förändringar, se R84. Se till att koden validerar.
  • För presentation och layout med stilmallar, använd CSS. Se R82. Separera innehåll från design – använd externa stilmallar för att styra presentation och layout.
  • För prenumerationstjänster, använd RSS eller Atom. Se R87. Gör det möjligt att prenumerera på information.
DOS-krav 4.1.1 (A) R84 Se till att koden validerar
  • Kontrollera att era mallar för funktioner, tjänster och stilmallar validerar i enlighet med er valda standard.
  • Kräv att leverantören vid leverans bifogar valideringsprotokoll för samtliga mallar. Mallar som inte validerar bör inte godkännas för leverans, om inte leverantören har acceptabla argument för alla valideringsfel.
  • Försök att automatisera en regelbunden kodvalidering, eller gör validering till en rutinåtgärd vid all förändring av webbplatsens kod. Det är lätt hänt att tidigare korrekt kod går sönder. Det kan till exempel hända när ni uppdaterar ett tilläggsprogram, när ni infogar en videospelare i ett blogginlägg eller när någon gör ett inlägg i ett kommentarssystem.
DOS-krav 1.4.10 (AA) R91 Skapa en flexibel layout som fungerar vid förstoring eller liten skärm
  • 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.
1 R105 Skapa rubriker med h-element
  • Märk upp rubriker korrekt, med rätt hierarkisk ordning.
  • Välj inte rubriknivå efter textstorleken i webbläsarna. Utgå från semantiken och använd CSS för att styra presentationen.
DOS-krav 2.4.1 (A) R75 Erbjud möjlighet att hoppa förbi återkommande innehåll
  • 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.
DOS-krav 2.1.4 (A) R68 Skapa kortkommandon med varsamhet
  • 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.
DOS-krav 1.4.3 (AA) R126 Använd tillräcklig kontrast mellan text och bakgrund
  • 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
DOS-krav 2.1.1 (A) R129 Utveckla systemet så att det går att hantera med enbart tangentbordet
Testa alla webbplatser och applikationer utan mus och utan pekskärm.
DOS-krav 2.4.7 (AA) R140 Markera tydligt vilket fält eller element som är i fokus
Använd CSS för att tydligt visa vilket element som är i fokus.
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.
DOS-krav 1.4.2 (A) R125 Ge användaren möjlighet att pausa, stänga av eller sänka ljud
  • 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.
DOS-krav 1.3.2 (A) R122 Presentera innehållet i en meningsfull ordning för alla
  • 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) .
DOS-krav 1.4.1 (A) R124 Använd inte enbart färg för att förmedla information
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.
DOS-krav 1.4.4 (AA) R127 Se till att text går att förstora utan problem
  • Kontrollera förstoring vid utveckling av stilmallar och sidmallar
  • Använd relativa mått
DOS-krav 2.2.2 (A) R132 Ge användarna möjlighet att pausa eller stänga av rörelser
  • Om en animation eller dynamisk uppdatering startar automatiskt och pågår i mer än 5 sekunder ska användaren enkelt kunna undvika den.
DOS-krav 2.1.2 (A) R130 Se till att markören inte fastnar vid tangentbordsnavigation
  • Testa alla webbplatser och applikationer utan mus och utan pekskärm, och se till att det går att använda alla funktioner som behövs.
DOS-krav 1.3.1 (A) R121 Ange i kod vad sidans olika delar har för roll
  • 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.
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.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.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.
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 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.
DOS-krav 3.1.2 (AA) R142 Ange språkförändringar i koden
Ange aktuellt språk med lang-attribut på omslutande element när språket i elementet är ett annat än sidans huvudspråk.
DOS-krav 3.1.1 (A) R141 Ange sidans språk i koden
  • Ange huvudspråk med hjälp av lang-attribut på sidans rot-element.
DOS-krav 2.4.3 (A) R136 Gör en logisk tab-ordning
  • Kontrollera ordningen utan pekdon.
  • Säkerställ en logisk ordning med tabindex.
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 1.4.11 (AA) R156 Använd tillräckliga kontraster i komponenter och grafik
  • 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.
DOS-krav 1.4.12 (AA) R157 Se till att det går att öka avstånd mellan tecken, rader, stycken och ord
  • 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.
DOS-krav 1.4.13 (AA) R158 Popup-funktioner ska kunna hanteras och stängas av alla
  • Ö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.
DOS-krav 2.5.1 (A) R160 Erbjud alternativ till komplexa fingerrörelser
  • Se till att all funktionalitet går att utföra med flera fingrar även går att utföra med bara ett finger
DOS-krav 2.5.2 (A) R161 Gör det möjligt att ångra klick
  • 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).
DOS-krav 2.5.3 (A) R162 Se till att text på knappar och kontroller överensstämmer med maskinläsbara etiketter
  • 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.
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 1.3.4 (AA) R153 Se till att allt innehåll presenteras rätt oavsett skärmens riktning
  • 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.
DOS-krav R165 Gör tillgänglighetsfunktioner åtkomliga
  • 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.
DOS-krav R168 Utforma eventuella reglage så att alla kan använda dem
  • 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.
DOS-krav R172 Dokumentera tillgänglighetsfunktioner
  • 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
DOS-krav R170 Respektera användarens inställningar
  • 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
DOS-krav R169 Se till att eventuella samtalsfunktioner är tillgängliga
  • Säkerställ tillräcklig ljudkvalitet vid röstkommunikation.
  • Komplettera röstkommunikation med realtidstext.
  • Presentera den som "ringer" på mer än ett sätt.
  • Säkerställ tillräcklig kvalitet vid videokommunikation.
DOS-krav R167 Bevara tillgänglighet vid konverteringar
  • Kartlägg om någon konvertering av information förekommer i er digitala service.
  • Se till att tillgänglighetsinformation bevaras i konverteringen, om det är möjligt.
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.
2 R54 Optimera webbplatsen för bästa prestanda
  • Acceptera inte långa väntetider
  • Kartlägg utgångsläget och välj ambitionsnivå
  • Identifiera och åtgärda prestandaproblem
  • Gå igenom Fem sätt att förbättra prestandan
2 R56 Låt inte en webbadress sluta fungera
  • Skapa teknikoberoende webbadresser, så att länkarna fungerar över tid även om ni byter publiceringsverktyg.
  • Använd rätt statuskoder när ni flyttar, stänger eller slår ihop webbsidor, så att användarna omdirigeras på rätt sätt.
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.
2 R81 Utveckla webbplatsen enligt en standard, snarare än för en webbläsare
  • Använd HTML5. HTML version 5 är den senaste versionen och har bra stöd i de flesta verktyg.
  • Använd inte XHTML om det inte finns synnerliga skäl till detta. Se blogginlägget HTML eller XHTML?
2 R82 Använd stilmallar för att separera presentationen från innehållet
  • Samla regler för webbplatsens utseende i stilmallar.
  • Definiera stilmallarna i externa stilmallsdokument, i så stor utsträckning som möjligt. Använd inte style-attributet för att definiera stilmallar direkt i HTML-koden, eftersom ni då blandar uppmärkning för semantik och presentation, vilket kan leda till problem för vissa användare och i vissa webbläsare.
2 R86 Basera inte viktig funktionalitet på format som kräver insticksprogram
  • Använd insticksbaserade multimediala format när det är motiverat, men ge bra alternativ. Undersök först om det går att använda mer tillgängliga format.
  • Använd inte insticksbaserade format för grundläggande funktioner som navigering eller formulär.
  • Analysera vad som händer om det saknas stöd för formatet.
  • Ta hänsyn till att insticksbaserade format kan ta lång tid att ladda vid låg bandbredd.
  • Om ni använder script för att kontrollera om era användare använder insticksbaserade format, så se till att scriptet inte ger fel besked om en användare har script avslaget.
  • Infoga det format ni använder i webbsidan på ett sätt som fungerar i så många webbläsare som möjligt.
3 R6 Tillhandahåll e-tjänster på en webbadress som ni kontrollerar
  • Tillhandahåll e-tjänster på adress(er) som er organisation har kontroll över
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.)
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 R87 Gör det möjligt att prenumerera på information
  • Erbjud åtminstone ett sätt att prenumerera på innehåll från webbplatsen.
  • Använd RSS eller Atom för nyhetsflöden.
  • Visa att det finns nyhetsflöden.
  • Gör det enkelt att påbörja och avluta prenumerationen.
  • Ange avsändare och länka till fördjupning.
  • Utgå från vilken typ av innehåll som är mest intressant för användarna.
  • Utsätt inte prenumeranter för irrelevant information.
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.
3 R94 Använd inte ramar
  • Använd i första hand serverbaserade tekniker.
  • Komplettera eventuellt med klientscript (Ajax).
  • Undvik iframes, eller kompensera för nackdelarna.
  • Använd inte ramar (frames).
3 R95 Gör webbadresser bokmärkningsbara
  • Se till att adressen i webbläsarens adressfält alltid leder tillbaka till aktuell sida.
  • På dynamiskt skapade webbsidor är det inte alltid möjligt att komma tillbaka till precis samma innehåll med hjälp av adressen. Låt då den adress som visas i adressfältet, och som används för eventuellt bokmärke, leda till den närmaste lämpliga beständiga delen av webbplatsen.
3 R97 Se till att bakåtknappen fungerar
  • 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.
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 R106 Stryk aldrig under text som inte är länkad
  • Stryk aldrig under text som inte är länkad, eftersom det kan leda användarna att felaktigt tro att texten är en länk.
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.
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.
4 R83 Använd inte tabeller för layout
  • Använd inte tabeller för layout. Det finns i regel ingen anledning att använda tabeller för webbplatsens grundkonstruktion.
  • Använd istället stilmallar (CSS:er) för att styra presentation och layout.
5 R90 Gör det enkelt att ringa upp telefonnummer
  • Markera telefonnummer i koden som telefonlänkar (tel:). Det ger möjlighet att direkt ringa upp numret, på samma sätt som e-postlänkar (mailto:) ger möjlighet att skicka e-post.
  • Ange det fullständiga telefonnumret, inklusive det internationella prefixet, i länken – även om det nummer som visas på sidan bara innehåller den lokala delen. Då fungerar länken oavsett varifrån användaren ringer.
  • Överväg att använda strukturerade data även när telefonnummer inte är länkade.
5 R96 Utnyttja webbläsarnas inbyggda funktioner för utskrift
  • Utnyttja webbläsarens inbyggda funktion för utskrift av innehållssidor på webbplatsen och använd en stilmall för det.
  • Tillhandahåll en utskriftsikon eller liknande om målgruppen saknar kunskap om webbläsarens inbyggda utskriftsfunktion och kortkommandon som Ctrl+P.
  • Knappar, symboler och liknande för att skriva ut kräver JavaScript för att fungera. Låt även knapparna och symbolerna skapas av skriptet. Då kommer användare som inte har JavaScript påslaget inte att se knappen eller symbolen, och får då inte heller en trasig ikon.
  • För utskrift av beräkningar, kvittenser, mottagningsbevis och liknande kan det vara motiverat att tillhandahålla en särskilt utskriftsversion.
  • Använd stilmallen för att ta bort menyer och understrykningar samt styra teckensnitt och sidlayout.
  • Erbjud möjligheten att slå samman sidor till en utskrift.
5 R102 Ange om ett dokument är en del av ett större dokument
  • Använd link-element och rel-attribut för att hänvisa till relaterade dokument.
  • Visa gärna kapitelnummer och namn i sidhuvudet för varje dokument, eller varje sida i dokumentet.
  • Gör det enkelt att navigera mellan de olika delarna av dokumentet.
Exportera urval som csv

Visa som kompakt lista