317
Teman TEMA. Inköpare och beställare TEMA. Bevarande och gallring TEMA. Skriva texter TEMA. Standarder för webbplatser Riktlinjer R1. Följ WCAG 2.1 nivå AA R2. Visa var ett fel uppstått och beskriv det tydligt R3. Beskriv ert uppdrag eller er affärsidé R4. Gör det lätt att komma i kontakt med er R5. Skriv tydliga länkar R6. Tillhandahåll e-tjänster på en webbadress som ni kontrollerar R7. Använd en krypterad anslutning för e-tjänster R8. Bestäm målgrupp och syfte för webbtexterna R9. Ge dokument filnamn som beskriver innehållet R10. Ge all information på begriplig svenska R11. Kombinera skrift med ljud, bild och film R12. Ge information på lättläst svenska R13. Ge information på svenskt teckenspråk R14. Ge information på de nationella minoritetsspråken R15. Ge information på engelska och andra språk R16. Håll god kvalitet på översättningarna R17. Anpassa webbplatsen för flerspråkighet R18. Följ MSB:s rekommendationer för krisinformation på webben R19. Beskriv hur webbplatsen fungerar och vad den innehåller R20. Informera om hur personuppgifter, kakor (cookies) mm hanteras Vägledning för webbutveckling Genererad från webbriktlinjer.se 2019-09-01

Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TemanTEMA. Inköpare och beställareTEMA. Bevarande och gallringTEMA. Skriva texterTEMA. Standarder för webbplatser

RiktlinjerR1. Följ WCAG 2.1 nivå AAR2. Visa var ett fel uppstått och beskriv det tydligtR3. Beskriv ert uppdrag eller er affärsidéR4. Gör det lätt att komma i kontakt med erR5. Skriv tydliga länkarR6. Tillhandahåll e-tjänster på en webbadress som ni kontrollerarR7. Använd en krypterad anslutning för e-tjänsterR8. Bestäm målgrupp och syfte för webbtexternaR9. Ge dokument filnamn som beskriver innehålletR10. Ge all information på begriplig svenskaR11. Kombinera skrift med ljud, bild och filmR12. Ge information på lättläst svenskaR13. Ge information på svenskt teckenspråkR14. Ge information på de nationella minoritetsspråkenR15. Ge information på engelska och andra språkR16. Håll god kvalitet på översättningarnaR17. Anpassa webbplatsen för flerspråkighetR18. Följ MSB:s rekommendationer för krisinformation på webbenR19. Beskriv hur webbplatsen fungerar och vad den innehållerR20. Informera om hur personuppgifter, kakor (cookies) mm hanteras

Vägledning förwebbutvecklingGenererad från webbriktlinjer.se 2019-09-01

Page 2: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R21. Riktlinjen hopslagen med R4R22. Ange vilken organisation som är avsändare av webbplatsenR23. Ange när webbsidorna har publicerats eller uppdateratsR24. Ange tydligt om viss information är inaktuellR25. Förvaltningsorganisationen och dess kunskap ska stå i proportion tillwebbplatsens storlek och ambitionerR26. Uppdatera webbplatsens innehåll och länkar regelbundetR27. Visa tydligt var användaren befinner sigR28. Gör det lätt att hitta det viktigasteR29. Var konsekvent i navigation, struktur och utformningR30. Använd startsidan för att ge en introduktion till webbplatsenR31. Länka alla sidor till startsidanR32. Erbjud användarna flera olika sätt att navigeraR33. Låt genomgångssidor orientera användarnaR34. Gör länkar, klickbara ytor och menyer användbara för allaR35. Se riktlinje 87R36. Kontrollera besöksstatistiken och sökbeteendet regelbundetR37. Följ upp hur webbplatsen användsR38. Möjliggör synpunkter, frågor och dialogR39. Ge webbplatsen en god läsbarhetR40. Se riktlinje 38R41. Använd funktionsbrevlådorR42. Redovisa vilka register som myndigheten för och vilka regler somgäller för tillgång till demR43. Gör register och databaser med publik information sökbaraR44. Gör det möjligt att läsa och söka i diarietR45. Planera för långsiktigt bevarande redan vid utveckling av webbplatsenR46. Publicera i format som är lämpade för långsiktigt bevarandeR47. Undvik oavsiktlig gallring vid ändringar och uppdateringarR48. Samla in informationen regelbundet för att säkerställa bevarandetR49. Gör det möjligt att få ut avpublicerat materialR50. Minimera antalet fält i formulärR51. Lyft fram det viktigaste i textenR52. Fyll formulär med kända uppgifterR53. Gruppera formulärets fältR54. Optimera webbplatsen för bästa prestandaR55. Skapa tydliga och klickbara fältetiketterR56. Låt inte en webbadress sluta fungeraR57. Låt användarna fylla i information i valfritt formatR58. Använd standardutseendet på formulärens elementR59. Anpassa textfältens storlek till det förväntade innehålletR60. Gör tydliga användbara knapparR61. Skriv beskrivande rubriker och etiketterR62. Gör texterna överskådligaR63. Visa var i en process användaren befinner sigR64. Skriv lättbegripliga texterR65. Använd ord och termer konsekventR66. Skriv datum och andra sifferuppgifter konsekventR67. Se till att infogade tjänster följer webbriktlinjerna

Vägledning förWebbutveckling Sida 1 /

316

Page 3: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R68. Skapa kortkommandon med varsamhetR69. Ta fram en policy för domännamnR70. Skydda användaren mot att oavsiktligt förlora påbörjat arbeteR71. Bestäm om e-tjänsten behöver e-legitimation och signeringR72. Kräv inte säkrare inloggning än vad informationen kräverR73. Var tydlig med förutsättningar för att kunna använda e-tjänstenR74. Integrera externa tjänster så att de smälter inR75. Erbjud möjlighet att hoppa förbi återkommande innehållR76. Ge e-tjänster namn utifrån användarnas perspektivR77. Ge tydlig återkoppling i e-tjänsterR78. Brödsmulor eller länkstigar i e-tjänsterR79. Se riktlinje 23R80. Följ standarderR81. Utveckla webbplatsen enligt en standard, snarare än för enwebbläsareR82. Använd stilmallar för att separera presentationen från innehålletR83. Använd inte tabeller för layoutR84. Se till att koden validerarR85. Se riktlinje 60R86. Basera inte viktig funktionalitet på format som kräver insticksprogramR87. Gör det möjligt att prenumerera på informationR88. Publicera i första hand dokument i html och skapa tillgängliga pdf:erR89. Gör det möjligt för andra att återanvända webbplatsens innehållR90. Gör det enkelt att ringa upp telefonnummerR91. Skapa en flexibel layout som fungerar vid förstoring eller liten skärmR92. Se till att webbplatsen kan användas även utan stilmallarR93. Använd Javascript för att öka tillgängligheten – inte tvärtomR94. Använd inte ramarR95. Gör webbadresser bokmärkningsbaraR96. Utnyttja webbläsarnas inbyggda funktioner för utskriftR97. Se till att bakåtknappen fungerarR98. Skriv rubriker till tabellerR99. Skapa korta webbadresser för sidor som ska spridasR100. Utforma webbadresser med omsorgR101. Markera obligatoriska fält i formulärR102. Ange om ett dokument är en del av ett större dokumentR103. Märk upp citat i kodenR104. Använd rätt html-element när ni gör listorR105. Skapa rubriker med h-elementR106. Stryk aldrig under text som inte är länkadR107. Analysera hur webbplatsen kommer att användas, och av vemR108. Ta fram designförslagR109. Testa och utvärdera designförslagR110. Stäm av resultat av utvärderingen med ansvarigR111. Anpassa webbplatsen även för små skärmarR112. Ge ordförslag vid sökning och inmatningR113. Använd webbvideo för att öka tillgänglighetenR114. Grundläggande rekommendationer för apparR115. Beskriv med text allt innehåll som inte är text

Vägledning förWebbutveckling Sida 2 /

316

Page 4: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R116. Erbjud alternativ om en inspelning enbart består av ljud eller videoR117. Texta inspelad rörlig media (video, ljud, animationer…)R118. Syntolka eller erbjud alternativ till videoinspelningarR119. Texta direktsändningarR120. Syntolka videoinspelningarR121. Ange i kod vad sidans olika delar har för rollR122. Presentera innehållet i en meningsfull ordning för allaR123. Gör inte instruktioner beroende av sensoriska känneteckenR124. Använd inte enbart färg för att förmedla informationR125. Ge användaren möjlighet att pausa, stänga av eller sänka ljudR126. Använd tillräcklig kontrast mellan text och bakgrundR127. Se till att text går att förstora utan problemR128. Använd text, inte bilder, för att visa textR129. Utveckla systemet så att det går att hantera med enbarttangentbordetR130. Se till att markören inte fastnar vid tangentbordsnavigationR131. Ge användarna möjlighet att justera tidsbegränsningarR132. Ge användarna möjlighet att pausa eller stänga av rörelserR133. Orsaka inte epileptiska anfall genom blinkandeR135. Skriv beskrivande sidtitlarR136. Gör en logisk tab-ordningR140. Markera tydligt vilket fält eller element som är i fokusR141. Ange sidans språk i kodenR142. Ange språkförändringar i kodenR143. Utför inga oväntade förändringar vid fokuseringR144. Utför inga oväntade förändringar vid inmatningR146. Benämn funktioner konsekventR149. Ge förslag på hur fel kan rättas tillR150. Ge möjlighet att ångra, korrigera eller bekräfta vid viktigatransaktionerR152. Se till att skräddarsydda komponenter fungerar i hjälpmedelR153. Se till att allt innehåll presenteras rätt oavsett skärmens riktningR154. Märk upp vanliga formulärfält i kodenR156. Använd tillräckliga kontraster i komponenter och grafikR157. Se till att det går att öka avstånd mellan tecken, rader, stycken ochordR158. Popup-funktioner ska kunna hanteras och stängas av allaR160. Erbjud alternativ till komplexa fingerrörelserR161. Gör det möjligt att ångra klickR162. Se till att text på knappar och kontroller överensstämmer medmaskinläsbara etiketterR163. Erbjud alternativ till rörelsestyrningR164. Se till att hjälpmedel kan presentera meddelanden som inte är i fokus

Inköpare och beställareDet ställs en rad krav på offentliga webbplatser. Dessa riktlinjer ger dig stödatt uppfylla kraven i praktiken. Service måste utformas så att allaprivatpersoner och företag både vill och kan använda den. Om webbplatsen

Tema

Vägledning förWebbutveckling Sida 3 /

316

Page 5: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

är krånglig och svårbegriplig kommer färre personer att vilja använda den.Service är inte bara en fråga om vad som […]

Det ställs en rad krav på offentliga webbplatser. Dessa riktlinjer ger dig stödatt uppfylla kraven i praktiken.

Service måste utformas så att alla privatpersoner och företag både vill ochkan använda den. Om webbplatsen är krånglig och svårbegriplig kommerfärre personer att vilja använda den.

Service är inte bara en fråga om vad som erbjuds utan också hur deterbjuds. Offentliga webbplatser ska vara tillgängliga för alla och ge tillgångtill samma eller likvärdig information, oavsett faktorer såsom ålder, kön,funktionshinder och etnisk och kulturell bakgrund. Det är en viktigdemokratifråga, men även viktigt för att myndigheterna ska kunnatillgodogöra sig effektiviseringsvinsterna av sina investeringar iwebbplatserna.

Gemensamt för både interna och externa webbgränssnitt är det viktigt att deär lätta att använda och bidrar till nytta.

Som beställare har du ett särkilt ansvar att verka för att ett webbprojekt fårrätt förutsättningar att bli framgångsrikt.

Riktlinjerna ur ett beställarperspektivAlla riktlinjer är inte att betrakta som underlag till en upphandling. Många avdem berör det arbete som sker löpande på en webbplats och där arbetetvanligtvis utförs av din egen organisation.

Ur ett beställarperspektiv är följande riktlinjer och teman särskilt viktiga.

Temaområdet Standarder för webbplatser sammanfattar varför det ärviktigt att ställa krav utifrån tekniska standarder.Riktlinje R1, Utgå från WCAG 2.1 nivå AA, ställer krav på tillgänglighetutifrån den internationella tillgänglighetsstandarden WCAG 2.0. Dennastandard har ett omfattande stödmaterial för implementatörer.Riktlinjerna R107-R110 om användbarhet ställer krav påutvecklingsprocessen.

Senast uppdaterad: 2012-05-28

Bevarande och gallringSidan har flyttat till https://webbriktlinjer.se/lagkrav/bevarande-och-gallring/.

Sidan har flyttat till https://webbriktlinjer.se/lagkrav/bevarande-och-gallring/.

Tema

Vägledning förWebbutveckling Sida 4 /

316

Page 6: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2012-05-25

Skriva texterEn webbplatsbesökare har ofta bråttom och vill uträtta sitt ärende så snabbtsom möjligt. Det är därför extra viktigt att texter på webben är överskådliga,lättlästa och informativa. Språket och sättet att strukturera informationen påen webbplats har stor betydelse för hur användaren upplever och kan ta tillsig informationen. Dåliga texter kan göra en […]

En webbplatsbesökare har ofta bråttom och vill uträtta sitt ärende så snabbtsom möjligt. Det är därför extra viktigt att texter på webben är överskådliga,lättlästa och informativa.

Språket och sättet att strukturera informationen på en webbplats har storbetydelse för hur användaren upplever och kan ta till sig informationen.Dåliga texter kan göra en i övrigt bra webbplats svår att använda.

Se riktlinjer inom ämnesområdena flerspråkighet och begripligt språk.

Senast uppdaterad: 2012-05-25

Standarder för webbplatserFör att webbplatser ska bli så enhetliga, användbara och tillgängliga sommöjligt är det viktigt att de följer standarder. Med standarder avser vi intebara tekniska standarder utan även standarder som påverkar webbplatsensutformning gällande struktur, navigation och form. En webbplats som följerstandarder bidrar till: Ökade möjligheter att möta medborgare och företag pådet […]

För att webbplatser ska bli så enhetliga, användbara och tillgängliga sommöjligt är det viktigt att de följer standarder. Med standarder avser vi intebara tekniska standarder utan även standarder som påverkar webbplatsensutformning gällande struktur, navigation och form. En webbplats som följerstandarder bidrar till:

1. Ökade möjligheter att möta medborgare och företag på det sätt somde föredrar genom att samma innehåll enklare kan presenteras i olikakanaler, plattformar och hjälpmedel.

2. Mindre skillnader mellan hur informationen presenteras i olikawebbläsare.

3. Ökad användningsgrad eftersom en konsekvent, enhetlig ochvälstrukturerad webbplats blir lättare att använda.

4. Minskad risk för att premiera eller låsa fast sig vid enskildaleverantörers lösningar.

Tema

Tema

Vägledning förWebbutveckling Sida 5 /

316

Page 7: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Använd riktlinjerna och de checklistor och kravdokument som finns somkomplement till kapitlet för att ställa krav på leverantörer. Genom att driva påutvecklingen tillsammans kan vi bidra till att de tjänster som utvecklas ioffentlig sektor gör största möjliga nytta för medborgare och företag.

RiktlinjerPrio 1

R1. Utgå från WCAG 2.0 nivå AAR80. Följ standarderR81. Utveckla webbplatsen enligt en standard snarare än för enwebbläsare

Senast uppdaterad: 2012-05-25

Prio 1

Följ WCAG 2.1 nivå AAFölj Web Content Accessibility Guidelines (WCAG) för att göra webbplatsen,innehållet och era tjänster tillgängliga för en bred mottagargrupp, inklusivepersoner med olika typer av funktionsnedsättningar. Detta maximerar värdetpå de resurser ni lägger på webbutveckling och ökar samtidigt möjlighetenför alla att delta i samhället på lika villkor.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: Inköpare och beställare, Standarder för webbplatser,TillgänglighetNär i utvecklingsprocessen?: Systemutveckling, Testning

Rekommendation för nivå av tillgänglighetFölj den internationella standarden för tillgänglighet, Web ContentAccessibility Guidelines (WCAG) 2.1 åtminstone på nivån AA.Ställ krav på att utvecklingen ska utgå från WCAG 2.1 nivå AA när dubeställer en ny webbplats så leverantören bygger tillgängligt frånbörjan.

Följ den internationella standarden förtillgänglighetWeb Content Accessibility Guidelines (WCAG) är internationellt etableraderekommendationer för tillgängligt innehåll på webben. Standarden ärframtagen av standardiseringsorganet World Wide Web Consortium (W3C)och sammanställer kunskaper från ett stort antal användare och experter.Den innehåller 78 kriterier som är indelade i tolv riktlinjer som i sin turkategoriseras inom fyra övergripande principer: möjlig att uppfatta,

Riktlinje nr 1

Vägledning förWebbutveckling Sida 6 /

316

Page 8: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

hanterbar, begriplig och robust.

Det finns många fördelar med tillgängligt webbinnehåll. Framförallt ärdet nödvändigt för många personer med funktionsnedsättning, som annarsriskerar utestängas eller drabbas av funktionshinder.

Som beställare av en webbplats bör du ställa krav på att utvecklingsarbetetska utgå från WCAG 2.1 åtminstone nivå AA. Därmed uppmärksammar duproduktutvecklare och andra leverantörer på behovet att bygga tillgängligalösningar redan från början.

Så här följer du WCAG 2.1Då standarddokumentet (liksom den svenska översättningen av WCAG 2.0)kan upplevas lite svårtolkat har vi, efter samråd med W3C, valt att publiceraförenklade beskrivningar av WCAG-kriterierna med förklarande text,illustrationer och exempel. Varje sådan webbriktlinje innehåller citat frånstandarden, och länkar vidare till W3Cs förklaringar och lösningsförslag. Idagsläget finns sådana förenklingar av alla kriterier i WCAG 2.1 på nivå Aoch AA. Dessa riktlinjer finns även i form av en checklista.

Det finns även introduktionsmaterial på engelska från W3C om hur mankommer igång med webbtillgänglighet och WCAG och en snabbreferensöver kriterier och lösningsförslag. Den presenterar bland annat tekniker ochkodexempel för hur man kan uppfylla de olika riktlinjerna och hur man kanmäta att de är implementerade.

Nivåer i WCAGKriterierna i WCAG är indelade i tre olika nivåer:

Nivå A är den lägsta ambitionsnivån, det vill säga de högstprioriterade kriterierna finns på denna nivå.Nivå AA är den basnivå som behöver uppfyllas av webbplatser ochmobila applikationer inom EU, se nedan. När vi skriver WCAG 2.1 nivåAA ingår både kriterier på nivå A och på nivå AA.Nivå AAA är den högsta ambitionsnivån. Överväg att uppfylla ävendessa kriterier.

Ytterligare information om nivåerna i WCAG (på engelska) finns i hos W3C.

EU-direktivet om tillgänglighet avseende offentliga myndigheterswebbplatser och mobila applikationer innebär, något förenklat, att offentligsektor behöver uppnå nivå AA, alltså den näst högsta nivån avtillgänglighet. Läs gärna mer i vår översikt av webbdirektivet.

Nya versioner av WCAG

WCAG 2.1 blev en färdig standard (W3C Recommendation) den 5 juni 2018.Den versionen innehåller 17 nya kriterier, varav 12 på nivå AA, ochförväntas bidra bland annat till bättre kognitiv och mobil tillgänglighet. I

Vägledning förWebbutveckling Sida 7 /

316

Page 9: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

augusti 2018 kom även en ny version av den Europeiska standarden EN301 549 som hänvisar till WCAG 2.1 AA istället för 2.0 AA. Webbdirektivets”presumtion om överensstämmelse” baseras på den europeiskastandarden. Förutom att denna hänvisar till WCAG 2.1 AA tar den uppytterligare några tillgänglighetskrav. Se standardens Annex A.

PTS har gjort en preliminär genomgång av WCAG 2.1 (PDF, 842kB) för densom vill orientera sig, och en översiktlig tabell på en enda sida medförenklade förklaringar av alla kriterier på nivå AA. Hela standardenpresenteras även på svenska i Per Axboms e-bok om digital tillgänglighet.Under sommaren 2018 har PTS tagit fram förklaringar, förenklingar,illustrationer och exempel på de tolv nya kriterierna från WCAG 2.1 på nivåAA. Dessa hittar du (som utkast) bland övriga webbriktlinjer baserade påWCAG-kriterier.

Version 3.0 ligger betydligt längre framåt i tiden och innehållet är än sålänge oklart. Den versionen kommer troligen att kallas AG (AccessibilityGuidelines) och alltså ha ett bredare perspektiv på digital tillgänglighet änwebbinnehåll.

Mätbarhet: validera och granskaUtvärdera tillgänglighet med en kombination av manuell och automatiseradgranskning, eftersom tillgängligheten även avgörs av många faktorer sominte kan kontrolleras automatiskt. Glöm inte bort att det kan finnas hindersom inte går att hitta med hjälp av checklistor och standarder. Därför är detviktigt att ha ett användarcentrerat arbetssätt och att ta del av användaressynpunkter.

TerminologiPå engelska heter tillgänglighet accessibility. Det förkortas ibland a11y, där11 är antalet tecken mellan a och y. (På svenska förekommer påmotsvarande sätt förkortningen t12t, men den är inte lika vanlig.) WCAG ärvad som brukar kallas för webbstandard och är en rekommendation frånstandardiseringsorganet Worldwide Web Consortium (W3C). WCAG hartagits fram i arbetsgruppen Web Accessibility Initiative (WAI).

Webbdirektivet kallas ibland även webbtillgänglighetsdirektivet (på engelska”web accessibility directive”) och det händer att dessa förkortas Wtdrespektive WAD.

Senast uppdaterad: 2018-12-21

Prio 1

Visa var ett fel uppstått och beskrivdet tydligt

Riktlinje nr 2

Vägledning förWebbutveckling Sida 8 /

316

Page 10: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Hjälp dina användare när det blir fel. Väl formulerade felmeddelanden geranvändarna möjlighet att fylla i så felfria data som möjligt i formulären. Deminskar också risken för att användarna ska bli irriterade när systemet inteförstår eller kan tolka den felaktigt inmatade informationen.

Om denna riktlinjePrioritet: 1Principer: Användbar, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Systemutveckling, Testning

Hjälp dina användare när det blir fel. Det måste vara tydligt för användarenvar felet finns och felet behöver beskrivas med text. Välformuleradefelmeddelanden ger användarna möjlighet att fylla i så felfria data sommöjligt i formulären. De minskar också risken för att användarna ska bliirriterade när systemet inte förstår eller kan tolka den felaktigt inmatadeinformationen.

Rekommendationer för tydliga felmeddelandenSammanfatta felen och använd en layout som tydligt separerarfelmeddelanden från resten av webbplatsens design.Skriv välformulerade felmeddelanden så ökar chansen att användarnagör rätt från början.Markera fel och felmeddelanden med WAI-ARIA så att de uppfattastydligt av användare med hjälpmedel.Spara det som inte är fel.

Sammanfatta felen och använd en layout somtydligt separerar felmeddelanden från resten avwebbplatsens designJu snabbare en användare upptäcker ett felmeddelande desto lättare är detatt åtgärda felet och fortsätta fylla i formuläret. Ett sätt att göra det på är atttydligt separera felmeddelanden från webbplatsens övriga design. Det görman genom att:

Placera felmeddelanden väl synligt och i direkt anslutning till det fältdä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 felhar 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

Vägledning förWebbutveckling Sida 9 /

316

Page 11: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Skatteverkets felmeddelande skiljer sig tydligt i utformning frånövriga webbplatsen.

Felmeddelanden på Mina vårdkontakter lägger sigsom ett lager ovanpå formuläret. Det innehållertydlig 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å Migrationsverketswebbplats har en tydlig markering runt varje

Vägledning förWebbutveckling Sida 10 /

316

Page 12: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

felaktigt eller ofullständigt ifyllt fält och en textsom beskriver felet.

Skriv välformulerade felmeddelanden så ökarchansen att användarna gör rätt

Underlätta för användarna genom att använda en artig ton i felmeddelandenoch beskyll dem inte för att ha gjort något dumt eller fel. Det kommer baraatt skapa irritation. Tänk på att inmatningsfel ofta beror på de krav du ställerpå 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 systemetska godkänna det. Det finns flera sätt man kan underlätta för användarna:

Skriv begripliga felmeddelanden. Använd inte ord och formuleringarsom är svåra att förstå. De ord som används i felmeddelandet skastä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 navigationenfrån felmeddelandet till de relaterade inmatningsfälten.Om det finns flera olika sätt att mata in uppgifterna, låt användarenvä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 felmeddelandeExemplet nedan visar ett artigt tilltal som man kan använda i ettfelmeddelande och hur man kan beskriva och länka till de fält som inte harfyllts i på rätt sätt.

Vi har två problem med din anmälanVänligen ändra dessa delar. Klicka sedan på ”Skicka anmälan” igen.

1. Fältet ”namn” får inte vara tomt. Ange ditt namn.2. Fältet ”ålder” får inte vara tomt. Ange din ålder.

Markera fel och felmeddelanden med ARIA så attde uppfattas tydligt av användare med hjälpmedel

För användare som till exempel lyssnar igenom sidan kan det vara mycketsvårt att hitta ett fel. Ett sätt att säkerställa att användare med skärmläsareblir informerade om identifierade fel är att markera både fel ochfelmeddelande 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 attfä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 ennotifiering som gör att användaren inte missar meddelandet.

Vägledning förWebbutveckling Sida 11 /

316

Page 13: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Spara det som inte är fel

Bevara så mycket av den inmatade informationen som möjligt, så att baradet som blivit fel behöver matas in igen. Det riskerar att skapa irritation hosanvändarna om de måste börja om från början igen trots att bara ett fältbehöver korrigeras.

Utdrag från WCAG-standarden

Riktlinje 3.3 Inmatningsstöd: Hjälp användare att undvikamisstag och rätta till misstag.

3.3.1 Identifiering av fel: Om ett inmatningsfel upptäcksautomatiskt så ska det som är fel markeras och felet beskrivasför användaren med text. (Nivå A)

Mätbarhet: användningstester

Utvärdera felmeddelanden i användningstester.

Fördjupning: användbara felmeddelandenR101. Markera obligatoriska fält i formulärR59. Låt användaren fylla i information på valfritt formatR149. Ge förslag på hur fel kan rättas tillPå WebAims webbplats kan du läsa mer om tillgängliga ochanvändbara felmeddelanden. Informationen är på engelska.

Terminologi

Utvecklare brukar använda engelskans ”form validation” för att beskriva denprocess som sker när systemet kontrollerar att användarna har matat inkorrekt formaterad information i ett webbformulär, till exempel att det ärsiffror och inte bokstäver i ett fält för telefonnummer. Validering ochvalideringsfel är också vanliga ord i sammanhanget.

Senast uppdaterad: 2018-12-05

Prio 4

Beskriv ert uppdrag eller er affärsidéInformera om organisationens uppdrag eller företagets affärsidé och mål föratt öka webbplatsens trovärdighet. Utgå från era prioriterade målgrupperoch vad som är viktigast för dem att veta.

Om denna riktlinje

Riktlinje nr 3

Vägledning förWebbutveckling Sida 12 /

316

Page 14: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prioritet: 4Principer: Användbar, FörtroendeingivandeRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign, Målgruppsanalys, Prototypning

Rekommendationer: om ossBeskriv vilket uppdrag er myndighet, organisation eller verksamhet haroch hur ni utför det.Presentera viktiga styrdokument och andra underlag såsomverksamhetsplaner och remisser.

Beskriv vilket uppdrag er myndighet, organisationeller verksamhet har och hur ni utför detAnvänd ord som är tydliga och begripliga för era prioriterade målgrupper närni beskriver er verksamhet. Den här typen av information är viktig förwebbplatsens trovärdighet och för att användarna ska kunna sättawebbplatsen i ett sammanhang.

Myndigheter och organisationer bör beskriva sitt uppdrag och målen medverksamheten medan privata företag bör beskriva sin affärsidé, vision ochövergripande affärsmål. Placera beskrivningen under menyingången ”Omoss” eller till exempel ”Om Arbetsförmedlingen”. Beskriv:

vilken service eller vilka tjänster användarna kan förvänta sig att få ochvilka rättigheter och skyldigheter de harandra organisationer med närliggande uppdrag, och länka till dem. Dåkan era besökare lättare förstå hur er verksamhet ingår i ett störresammanhang.

Presentera viktiga styrdokument och andraunderlag såsom verksamhetsplaner och remisserÄven om det inte är information som användare allra först efterfrågar är detbra att presentera viktiga styrdokument och andra underlag som styr erverksamhet. Det ger en signal till användarna att ni inte har något att döljaoch att ni gärna ser att andra har insyn i verksamheten. Presentera

årsredovisningar, budgetunderlag, verksamhetsplaner, remissvar ochviktiga beslutde planer ni är skyldiga att ha, till exempel planer för jämställdhet ochmångfaldeventuella underverksamheter. Sammanfatta det viktigaste på er sidaoch hänvisa vidare för den som vill fördjupa sig.

Myndigheter bör presentera regleringsbrev och andra regeringsbeslutlängre ner i strukturen, eftersom det är få besökare som letar efter dem iförsta hand.

Vägledning förWebbutveckling Sida 13 /

316

Page 15: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Exempel

Statskontorets sida ”Om oss”.

Mätbarhet

Kontrollera att det finns en sida på webbplatsen där det tydligt framgårvarför organisationen finns och vilket uppdrag den har.Stäm av sidan mot rekommendationerna ovan.

Senast uppdaterad: 2015-08-26

Prio 2

Gör det lätt att komma i kontakt mederMånga besöker en webbplats för att komma i kontakt med en organisation.Gör det därför lätt för användarna att komma i kontakt med er genom attange samtliga möjliga kontaktvägar såsom adresser, sociala mediekanaler,telefonnummer och öppettider.

Om denna riktlinjePrioritet: 2Principer: Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för kontaktinformationGör det lätt att hitta kontaktinformationen.Se till att ha grundläggande information på kontaktsidan.Gör det enkelt att ta kontakt med den som är ansvarig för varje sida.Erbjud kontaktformulär och informera om övriga kontaktvägar.Informera om fysisk tillgänglighet.

Gör det lätt att hitta kontaktinformationenFör att möta användarnas behov ska kontaktinformationen vara lätt att nåfrån såväl mobil enhet som desktop. Döp kontaktinformationen till ”Kontakt”eller ”Kontakta oss”, och placera den gärna högst upp i sidhuvud och isidfoten, så att den blir lätt nå från webbplatsens samtliga sidor. För mobilabesökare ska kontaktinformationen vara lätt åtkomlig via navigeringen ochsidfot. Säkerställ också att kontaktinformationen är tillgänglig från andradigitala tjänster som till exempel e-tjänster eller meddelanden som nåranvändaren via en digital brevlåda.

Riktlinje nr 4

Vägledning förWebbutveckling Sida 14 /

316

Page 16: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se till att ha grundläggande information påkontaktsidanWebbplatsens kontaktsida ska innehålla:

Organisationens namnInformation om organisationenAdresserTelefonnummer till växeln eller kundtjänstE-postadress till registrator, om det finns i organisationen

Markera telefonnummer i koden som telefonlänkar (tel:). Det ger möjlighetatt direkt ringa upp numret, på samma sätt som e-postlänkar (mailto:) germöjlighet att skicka e-post. Se även R90. Gör det enkelt att ringa upptelefonnummer och R41. Använd funktionsbrevlådor.

Om det är relevant ska även följande uppgifter finnas på kontaktsidan:

Telefon-, öppet- och besökstider. Komplettera gärna med informationom det är öppet just i den stund användaren läser informationen ochhur lång tid det är kvar tills ni stänger. Upplys också om tidpunkterunder dagen då trycket på er kundservice är lägre.Besöksadress, karta och vägbeskrivning (både för bil, gång, cykel ochmed kollektivtrafik). Fotografi på entrén underlättar också föranvändaren.Sociala mediekanaler.Vem som har det övergripande ansvaret för webbplatsen, även omdet inte finns en ansvarig utgivare. Denna information kan eventuelltpassa bättre på sidan Om webbplatsen. Se Beskriv hur webbplatsenfungerar och vad den innehåller (R19).Om ni vill att användaren identifierar sig med e-legitimation vidpersonliga ärenden, exempelvis för att få svar via en chatt eller pertelefon.

För e-handlare är viss kontaktinformation obligatorisk på webbplatsen.

Gör det enkelt att kontakta sidansvarigaAnge på varje enskild sida vem som är innehållsansvarig och hur man tarkontakt med personen. I vissa sammanhang går det att namnge personen,vilket ofta uppskattas av användarna och kan ge ett ökat ansvarstagande förinnehållet. I andra sammanhang är det på grund av praktiska, juridiska ellersäkerhetsmässiga skäl inte möjligt eller lämpligt. Det går därför även bra atthänvisa till en funktionsbrevlåda eller generella kontaktvägar till exempelvisett kontakt- eller servicecenter. Skriv ut adressen eller erbjud ettkontaktformulär och telefonnummer. För- och nackdelar med e-postlänkarrespektive formulär kan du läsa mer om nedan.

Erbjud kontaktformulär och informera om övrigakontaktvägar

Vägledning förWebbutveckling Sida 15 /

316

Page 17: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Underlätta även för de användare som föredrar andra kontaktvägar, tillexempel genom att erbjuda ett kontaktformulär. Låt exempelvis användarenvälja ärendekategori och sen beskriva sitt ärende i ett fritextfält. Geanvändaren tydlig återkoppling på att ärendet mottagits och när hen kanförvänta sig att få ett svar. Skicka även med användarens egen formulering iåterkopplingen. Informera även om hur hen kommer att få svar på sittärende exempelvis per e-post, sms-avisering, mina meddelanden, minasidor med mera.

Var tydlig med alla övriga vägar att kontakta er, till exempel

länkar till, eller andra funktioner för att komma i kontakt med er, tillexempel chatt, videomöten, virtuella assistenter, kontaktformulär, e-post, teknisk support och pressjour.vilka möjligheter det finns att få samtalet tolkat för personer som intehar svenska som modersmål och tillvägagångssätt för det.

Informera gärna om följande möjligheter för den som på grund avfunktionsnedsättning inte kan använda vanlig telefoni:

Personer med behov av teckenspråkstolkning kan använda sig avbildbaserad kommunikation som till exempel bildtelefoni.net ellervideomöte.Personer med behov av förmedling av text (till exempel döva som inteär teckenspråkiga eller personer med dövblindhet) kan använda chattoch texttelefoni.se.personer med behov av tal-, minnes- och anteckningsstöd (på grundav nedsatt tal- eller minnesfunktion) kan använda teletal.se.

Informera också om att dessa så kallade förmedlingstjänster innebärtrepartssamtal där en förmedlare eller tolk (som har tystnadsplikt) deltar. Dekostar inte mer att använda än ett vanligt samtal. Post- och telestyrelsenupphandlar tjänsterna med skattefinansiering.

Även om ni på webbplatsen erbjuder till exempel en chatt-funktion är det braatt informera om texttelefoni.se, eftersom det via texttelefoni går att nå allasom kan nås med telefon, medan chatten bara brukar gå till enkundtjänstfunktion.

E-postlänk eller kontaktformulär?Fördelen med e-postlänkar är att de är enkla för användaren att användaoch att de inte ställer krav på vilken information användaren måste lämna.Nackdelen är att e-postlänkar kräver att användaren har en e-postadressoch en e-postklient installerad i systemet, eller webbmejl, för att skickameddelanden. En annan nackdel är att det är svårt att styra vilkeninformation som användaren ska ange i meddelandet. Om du behöversådana styrmöjligheter kan det istället vara bra med ett formulär.

Genom att använda ett formulär på sidan kan du vägleda användaren ochbestämma vilken information användaren ska lämna. Informationen som

Vägledning förWebbutveckling Sida 16 /

316

Page 18: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

användaren lämnar kan också automatiskt granskas (valideras) av systemetinnan den skickas iväg till servern. Valideringen kan till exempel säkerställaatt fält för siffror innehåller rimliga siffror och inte andra tecken, eller attangivna postnummer och datum faktiskt existerar. Detta ökar kvaliteten påinformationen vilket i sin tur kan minska svarstider och kostnader förhandläggning. En annan fördel med formulär är att det går att skickameddelanden via ett formulär utan krav på särskild programvara ellerpersonliga e-postklienter. En nackdel är att användare kan uppleva att detär krångligt att fylla i formuläret. Det finns fler rekommendationer för hurformulär bör utformas på annan plats i Vägledningen.

Genom att erbjuda både en e-postlänk och ett formulär kan ni låtaanvändarna själva välja hur de vill kontakta er.

Rekommendationer för utformning av e-postlänkar finns i R5. Skriv tydligalänkar.

Informera om lokalers tillgänglighetPå kontaktsidan bör ni även informera om den tillgängligheten omanvändaren väljer att besöka er. Upplys exempelvis hur entrén är utformadoch om det finns en ramp, teleslinga, om det finns speciella avseddaparkeringsplatser eller toaletter för personer med funktionsnedsättning. Läsgärna Myndigheten för delaktighets riktlinje för tillgänglighet, Riv hindren(pdf, 1,2 MB).

ExempelKontaktsida på Pensionsmyndigheten

På Göteborgs stads webbplats finns både e-postadress och kontaktformuläri sidfoten. Det finns också e-postbrevlådor för olika områden, så kalladefunktionsbrevlådor, som gör det tydligare vem som är mottagare avinformationen.

MätbarhetSe till att det går att komma åt kontaktuppgifter direkt från webbplatsensstartsida. Det ska också finnas länkar till kontaktsidan på webbplatsenssamtliga sidor. Se dessutom till att det finns särskilda kontaktuppgifter påsidor där användarna kan vilja eller behöva kontakta enskilda medarbetareeller specifika delar av verksamheten.

Med hjälp av webbstatistik och till exempel heatmaps kan du följa upp hurefterfrågade kontaktuppgifterna är. Intressant är också att identifiera omvissa webbsidor eller tjänster genererar fler klick till kontaktuppgifter och tareda på varför det i så fall ser ut så.

Fördjupning om kontaktinformationAndra webbriktlinjer som kan vara aktuella för era kontaktsidor är R38.Möjliggör synpunkter, frågor och dialog och R20. Informera om hur

Vägledning förWebbutveckling Sida 17 /

316

Page 19: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

personuppgifter, kakor (cookies) mm hanteras.

Många myndigheter använder sociala medier som kontaktvägar. Socialamedier är ett stort ämne som för närvarande inte behandlas avwebbriktlinjerna. E-samverkansprogrammet har publicerat riktlinjer förmyndigheters användning av sociala medier som framför allt tar uppjuridiska frågor.

Senast uppdaterad: 2018-09-07

Prio 1

Skriv tydliga länkarSkriv länkarna så att användarna förstår vart länken leder även när den ärlyft ur sitt sammanhang. På webben skummar vi ofta igenom informationoch blicken fastnar på avvikelser såsom rubriker, markerade ord och länkar.Tydliga och informativa länkar gör att besökarna snabbare hittar deninformation de söker.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Tydliga länkar underlättar för alla, men är särskilt viktigt för personer somanvänder vissa hjälpmedel. Skärmläsaranvändare kan till exempel välja attnavigera genom att enbart läsa upp länkarna på en sida, och för användaremed nedsatt motorisk förmåga kan varje interaktion kräva mycket tid ellerenergi.

Hjälp därför användarna genom att låta syftet med varje länk vara så tydligtatt användaren kan avgöra om hen ska följa länken eller inte. Försök, omdet är möjligt, att skriva länktexten så att det går att förstå vart länken lederäven om den är tagen ur sitt sammanhang.

I vissa situationer passar det bättre att placera en del av beskrivningen avlänkens syfte i den omgivande texten än att ha en fullständig beskrivning isjälva länktexten. Försök så långt det är möjligt att ge användaren en chansatt förstå vart länken leder utan att flytta fokus från själva länken. Det uppnårdu genom att placera beskrivningen av länken innan själva länken och idirekt anslutning till länken: i samma mening, stycke, listobjekt ellertabellcell som är nära förknippad med länken. Ett annat alternativ är attanvända WAI ARIA-teknik för att ytterligare förknippa text med länken.

Exempel när länken beskrivs i den omgivande texten:En lista över rapporter där varje rapport finns i tre format; html, pdf och mp3

Riktlinje nr 5

Vägledning förWebbutveckling Sida 18 /

316

Page 20: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

(inspelning). I det här fallet är det onödigt att upprepa titeln på rapporten ivarje länk utan låt den första länken tala om titeln och låt de övriga länkarnavara “pdf” och “mp3”.

Exempel lista med rapporter:

Rapport html-versionPdf-version förnedladdning

Mp3 föruppspelning

Granskningsrapport omtillgänglighet Pdf (2 MB) Mp3 (57 MB)

Rekommendationer för tydliga länkarFormulera länktext med omsorg. Användaren måste kunna förutsevad som händer vid klick på länken.Låt sammanhanget och syftet med länken avgöra om den exempelvisska placeras i brödtexten eller utanför.Utforma länkar till dokument och länkar till e-post så att användarenfår rätt förväntningar.

Formulera länktext med omsorgLänka ord som säger något om vart länken leder. Skriv hellre”Information om nätverksträffen” än ”För information omnätverksträffen, klicka här”. Användare vet att det går att klicka pålänkar, det behöver du inte tala om. Av samma anledning är detonödigt att inleda länkar med sådant som ”Läs mer om …” och ”Gå till…”Skriv det viktigaste i länken först.Använd en och samma länktext för alla länkar som leder till sammasida. Och omvänt: Låt inte länkar på samma sida med samma länktextleda till olika sidor. Ett vanligt exempel är ”Läs mer”-länkar somupprepade gånger används i listor med nyhetspuffar på en och sammasida. Ett alternativ är att istället skriva ”Fler nyheter”, ”Flererbjudanden” eller något liknande.Använd gärna den länkade sidans titel och/eller rubriktext somlänktext. Detta förutsätter en tydlig och informativ rubrik. (Se ävenR135 Skriv beskrivande sidtitlar.) Om du inte kan använda sammalänktext som i rubriken, se till att länktexten och rubriken skiljer sig sålite åt som möjligt. Risken är att besökarna annars tror att de hamnatpå fel sida.(Se R61 Skriv beskrivande rubriker och etiketter.)Om du i länktexten vill ange att länken går till en annan webbplats kandu skriva ut organisationens eller webbplatsens namn i slutet avlänktexten, till exempel:"Information om barns hälsa på Sjukvårdsrådgivningens webbplats.""Regler för kontroll av livsmedel hos Livsmedelsverket."

Vägledning förWebbutveckling Sida 19 /

316

Page 21: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Låt sammanhanget och syftet med länken avgöraom den exempelvis ska placeras i brödtexten ellerutanför

Det finns både fördelar och nackdelar med att lägga länkar i brödtexten,liksom med alternativet att lägga dem separat, till exempel i en punktlistaefter texten eller mellan textblock. Här är några exempel:

Fördelar med länkar i brödtextDet blir tydligt vilken länk som knyter an till vilken del av texten.Användare kan missa att det erbjuds möjlighet till fördjupning omlänkarna ligger separat. Detta är särskilt relevant när länken går till enordförklaring.Det blir möjligt för skribenten att direkt i texten antyda vad som äregna påståenden och vad som baseras på källor.Genom att markera eller följa länken kan användaren direkt underläsningen få hjälp att bedöma referensens värde och relevans. Iblandräcker det att undersöka vems adress länken leder till.

Bokstavsförkortningen ”ht” i webbstandarderna html och http står förhypertext, som betyder just text med länkar. Detta stycke är ett exempel påhypertext. Hypertextens popularitet var en av anledningarna till webbensgenombrott. Men det är inte alltid optimalt att ha länkarna inbakade i texten.

Nackdelar med länkar i brödtextFramför allt handlar det om att läsbarheten blir sämre.En separat länklista kan bli överskådlig på ett annat sätt än en brödtextmed infällda länkar.Avsändaren riskerar att tappa läsare innan texten hunnit ”tala tillpunkt”, det vill säga att användaren följer länken omedelbart ochmissar en del av budskapet.I löpande text är det ofta svårt att formulera länktexter som beskriverlänkmålet på ett rättvisande sätt utan att bli krystade.

Ofta fungerar det bra att lägga länkar omedelbart efter ett textavsnitt, vilketexemplifieras här. Om det är fler än en länk kan det bli tydligare med enpunktlista.

En studie från universitetet i Hamburg (2003) visar att länkar i brödtextminskar läsbarheten. (pdf, 276kB)

Det finns en risk – framförallt i brödtext, men även i listor – att länkar hamnarså nära varandra att vissa användare av misstag väljer fel länk. Läs mer omutformning av länkar i R34. Gör länkar, klickbara ytor och menyeranvändbara för alla.

Länkar till dokument

Vägledning förWebbutveckling Sida 20 /

316

Page 22: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När du länkar till dokument som är i annat format än html, tänk på detta:

Ange dokumentets format: pdf, doc eller något annat. Då blir dettydligare att länken inte går till en webbsida.Filens storlek bör framgå av länktexten. Då kan besökarna lättareavgöra hur lång tid det tar att ladda ner dokumentet.

Se även R9. Ge dokument filnamn som beskriver innehållet.

Tidigare har denna riktlinje förespråkat att dokument ska öppnas i nyafönster. Efter omfattande diskussioner om argument för och mot att öppnalänkar i nya fönster/flikar har vi valt att ta bort den rekommendationen.Däremot kan sidor som kodas med html5 med fördel använda attributetdownload när avsikten är att det länkade dokumentet ska sparas snarare

än öppnas för visning.

Kodexempel:<a href="rapport.pdf" download>Ladda ner rapporten</a>

E-postlänkar

Om du väljer att ha e-postlänkar (se avsnittet E-postlänk ellerkontaktformulär? i R5. Gör det lätt att komma i kontakt med er) bör du skrivadem så att det tydligt framgår vem som är mottagare av e-postmeddelandet.E-postlänken bör innehålla e-postadressen till mottagaren, annars kan detvara svårt för användaren att förstå vad som händer när man följer länken.(WCAG 2.1 3.2.2 säger att förändring av sammanhang, till exempel öppningav e-postprogram, bara får göras om användaren kan förvänta sig det.)

E-postadresser med tydliga mottagare är till [email protected] eller [email protected] (seR41. Använd funktionsbrevlådor). När e-postadressen är utskriven ilänktexten kan användaren antingen kopiera länkadressen och själv välja ettprogram för att skicka meddelandet eller klicka på länken för att använda ettförvalt e-postprogram.

Ett argument för att inte skriva ut e-postadresser på webbsidor (synligt eller ikod) är att adresserna då kan fångas upp av robotar och hamna iadresslistor för skräppost. Vanliga försök att minimera den risken är attskriva ut e-postadresser som bilder, byta ut @-tecknet eller skriva utadressen med JavaScript. Det finns dock ingen garanti att dessa lösningarfungerar, och de försämrar ofta både tillgängligheten och användbarheten,till exempel eftersom skärmläsare inte läser upp bilder som saknaralternativtext. Om det inte finns särskilt starka skäl bör sådana lösningardärför undvikas. Ett modernt och uppdaterat skräppostfilter brukar räcka.

Ibland är det nödvändigt att komplettera e–postadressen med annan text föratt syftet med länken ska bli tydligt för användaren. Ett exempel är omwebbsidan informerar om ett evenemang och syftet med länken är attanvändaren ska anmäla sig. Då är inte länktexten

Vägledning förWebbutveckling Sida 21 /

316

Page 23: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

[email protected]” längre tydlig utan behöverkompletteras med exempelvis: ”Skicka e-post [email protected] för att anmäla dig.”

Kodexempel för e-postlänkarAnvänd mailto-attributet i html-koden för alla e-postlänkar. Då öppnas ett e-postprogram och ett e-postmeddelande skapas med mottagarfältet förifylltnär användaren klickar på länken. Detta förutsatt att användaren har en e-postklient installerad och konfigurerad. Om användaren inte har en e-postklient installerad eller inte valt e-postklient brukar de flestaoperativsystem fråga vad användaren vill göra.

Kodexempel 1: <a

href="mailto:[email protected]">[email protected]</a>

Kodexempel 2: <a href="mailto: ...">Skicka e-post till

[email protected] för att anmäla dig

till evenemanget</a>

Det finns flera parametrar som kan användas för e-postlänkar för att fylla iinformation i förväg i e-postmeddelanden:

subject anger meddelandets ämnesrad

body anger själva meddelandetexten

cc anger synlig mottagare av kopia

bcc anger för mottagare osynlig mottagare av kopia

Kodexempel 3: <a href="mailto:[email protected]?

subject=Fakturafråga&[email protected]">Skicka

fakturafrågor till oss på adressen

[email protected]</a>

Relaterat: Följ riktlinjer om utformning ochinteraktionsdesign för länkar

Det är inte bara länktextens formulering som avgör hur väl en länk fungerar,utan även formgivning och interaktionsdesign.Länkar (även till andra webbplatser) ska till exempel endast undantagsvisöppnas i nytt fönster. Se R97. Se till att bakåtknappen fungera.Se R34. Gör länkar, klickbara ytor och menyer användbara för alla.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.4 Syftet med en länk (i sammanhanget): Syftet med varjelänk framgår av länktexten i sig själv eller av länktextentillsammans med sitt automatiskt tydliggjorda länksammanhang,

Vägledning förWebbutveckling Sida 22 /

316

Page 24: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

utom då syftet med länken skulle vara tvetydigt för användare iallmänhet. (Nivå A)

Mätbarhet: lyft länken ur sitt sammanhang

Testa att läsa varje länk lyft ur sitt sammanhang. Går det att förstå vartlänken leder enbart med hjälp av länktexten?

Exempel på tydliga länkar

1177 Vårdguiden har bra exempel på länkar till bådetelefonnummer och e-post.

Terminologi

Skräppost kallas på engelska för spam eller ”junk mail”.

Senast uppdaterad: 2018-12-05

Prio 3

Tillhandahåll e-tjänster på enwebbadress som ni kontrollerarUnderlätta för användare att kontrollera vilken organisation som står bakomtjänsten genom att t.ex. visa information om certifikat.

Om denna riktlinjePrioritet: 3Principer: FörtroendeingivandeRoller/arbetsuppgifter: Inköpare och beställareNär i utvecklingsprocessen?: Informationssäkerhet, Målgruppsanalys,Process, Säkerhet

Rekommendationer för adresser i e-tjänsterTillhandahåll e-tjänster på adress(er) som er organisation har kontrollöver

Varför är adressen viktig?När e-tjänster hanterar personlig information är det viktigt att användarenhar förtroende för att den hanteras på ett korrekt sätt och upplever att det ärtydligt vem som tar emot informationen. Webbadressen är en del av den

Riktlinje nr 6

Vägledning förWebbutveckling Sida 23 /

316

Page 25: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

information som beskriver vilken organisation det är användaren interagerarmed.

En förutsättning för detta är att e-tjänsten, oavsett om den driftas av denegna organisationen eller av en extern leverantör, är nåbar på enwebbadress ni har kontroll över.

Detta gäller för samtliga sidor i en process.

Om ni själva förfogar över domännamnet är det även möjligt att bytaleverantör utan att förändra adressen som en tjänst tillhandahålls på.

ExempelStockholms stad tillhandahåller e-tjänster för barnomsorg på adressenhttps://barnomsorg.stockholm.se/

Bolagsverket, Skatteverket och Tillväxtverket tillhandahåller tjänsterför företagare på adressen https://www.verksamt.se/

MätbarhetSäkerställ att de webbadresser som används för e-tjänster ägs av dinorganisation.

FördjupningSe även R69 Ta fram en policy för domännamn och R7 Använd en krypteradanslutning för e-tjänster.

Senast uppdaterad: 2014-11-01

Prio 2

Använd en krypterad anslutning för e-tjänsterAnvänd en krypterad anslutning, https, till alla webbaserade e-tjänster för attminimera risken att användarnas information avlyssnas.

Om denna riktlinjePrioritet: 2Principer: FörtroendeingivandeRoller/arbetsuppgifter: Inköpare och beställare, Standarder för webbplatserNär i utvecklingsprocessen?: Säkerhet

Rekommendationer för säker httpAnvänd en krypterad anslutning, https, till alla e-tjänster sominnehåller inloggningsinformation eller personliga eller ekonomiskauppgifter.

Riktlinje nr 7

Vägledning förWebbutveckling Sida 24 /

316

Page 26: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Skicka inloggningsinformation över en krypterad kanal.Överväg om hela webbplatsen bör kunna användas över en krypteradanslutning.Använd ett certifikat från en certifikatutfärdare som förekommer i devanligaste webbläsarna. Annars kan användarna få ett felmeddelandeom att utfärdaren inte är betrodd.Se till att era certifikat är giltiga så att användarna slipperfelmeddelanden och varningar.Se till att alla webbplatsens resurser kan laddas över en krypteradkanal, även om de inkluderas från en tredje part. Annars kananvä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:// omwebbplatsen har stöd för det. Det gör att användarna hamnar rätt frånbörjan.

Exempel på krypterad webbplats

Skatteverket använder en krypterad anslutning, https, till alla sina e-tjänster.Bilderna visar hur det ser ut i olika vanliga webbläsare:

MätbarhetSe till att webbplatsen kan nås utan säkerhetsfelmeddelanden närbesökarna har angett https i stället för http i adressfältet iwebbläsaren.Navigera till en undersida utan https. Verifiera att du blir omdirigeradtill samma sida fast över en krypterad kanal.

FördjupningInformationssäkerhet.se ger bra övergripande vägledning, framförallt

Vägledning förWebbutveckling Sida 25 /

316

Page 27: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

för myndigheter.

Terminologi: https, http2, tls och ssl

Http (hypertext transfer protocol) är den teknik som används närwebbläsaren hämtar webbinnehåll över internet. Https är en förkortning avHypertext transfer protocol secured, alltså säker http. Det protokoll förkryptering som används för säker http heter tls (transport layer security). Entidigare version hette ssl (secure socket layer).

Http2 är en ny standard för krypterad http som kan ge prestandavinster.Protokollet beskrivs utförligt i http2 förklarat av Daniel Stenberg.

Senast uppdaterad: 2017-09-22

Prio 2

Bestäm målgrupp och syfte förwebbtexternaBestäm vilka användare ni främst vänder er till i webbtexterna, och vadanvändarna ska göra efter att ha läst varje text. Anpassa texten till de somska läsa den, så att de uppfattar att de har kommit rätt, och så att deeffektivt kan göra det de kom dit för.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys

Rekommendationer: skriv för målgruppenKartlägg och analysera målgrupperna och deras behov. Användanalysen som underlag när du producerar texter och annat innehåll tillwebbplatsen.Tänk igenom vilka användare texten ska vända sig till, vad syftet medtexten är ur deras perspektiv.Tänk igenom vilka situationer användarna är i när de läser texterna.Skriv det viktigaste först.Använd riktlinjerna för klarspråk för att se till att språket blir tydligt ochbegripligt.Be någon annan läsa igenom din text innan du publicerar den.

Vem är den huvudsakliga mottagaren?Bestäm vilka användare ni i första hand vänder er till i webbtexterna. Vem är

Riktlinje nr 8

Vägledning förWebbutveckling Sida 26 /

316

Page 28: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

den huvudsakliga mottagaren?

Bestäm vad dessa användare ska veta, känna eller göra efter att ha lästvarje text.

Disponera texten på ett logiskt sätt för de som ska läsa den. Användarenmåste enkelt förstå om det är rätt text, sett till dennes behov vid besöket.Det måste därför som exempel vara enkelt att hitta den del av texten som ärlösningen på ett problem som användaren står inför.

Risken är att användaren annars ger upp och går någon annanstans. Dinanalys av läsarnas behov ska påverka både ditt val av innehåll ochtonaliteten. Språket ska alltid vara så enkelt som sammanhanget tillåter.

MätbarhetDet krävs manuell granskning och användningstester för att utvärdera omsidan fungerar för målgruppen och fyller sitt syfte.

Fördjupning i klarspråkKlarspråksråd från Språkrådet.

Se även R64. Anpassa språket till läsaren.

Terminologi

Klarspråk definieras som ett språk som dels är tydligt, dels är begripligt förde mottagare texten vänder sig till. Ett tydligt språk har en enkelmeningsbyggnad och tydliga samband. Ett begripligt språk är anpassat tillmottagarna och deras sammanhang och behov.

Senast uppdaterad: 2017-10-30

Prio 4

Ge dokument filnamn som beskriverinnehålletSe till att dokument du länkar till har så tydliga filnamn att man förstår avfilnamnet vad dokumentet innehåller. Använd inte interna arbetsnamn somfilnamn. Undvik att döpa dokument efter artikelnummer, diarienummer,blankettnummer eller liknande. Om artikel- eller blankettnumren är kändahos användarna bör de dock vara en del av filnamnet.

Om denna riktlinjePrioritet: 4Principer: Användbar, Tillgänglig

Riktlinje nr 9

Vägledning förWebbutveckling Sida 27 /

316

Page 29: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för tydliga filnamnGe dokumentet ett filnamn som beskriver innehållet i dokumentet.Exempel: semesterlista-sommar-2017.pdfVar försiktig med specialtecken, mellanslag och understreck i filnamn.Ange vilket filformat dokumentet har.

Ange vilket filformat dokumentet harLåt filnamnet sluta med en punkt följt av filformatets förkortning, till exempel.docx eller .pdf.

Då blir det tydligare att länken inte går till en webbsida. Det är också lättareför användaren att öppna filen om det genom filändelsen framgår vilketprogram som behövs. Ofta avgör filnamnets ändelse vilken innehållstyp(Mime content-type) webbservern anger när den skickar filen. Det gör att rättfiländelse ofta medför att webbläsaren automatiskt kan öppna filen med rättprogram.

Var försiktig med specialtecken, mellanslag ochunderstreck i filnamnVar medveten om följande nackdelar och risker:

understreck, ”_” kan förväxlas med mellanslag om de visas i en länkadadress (när webbadresser förekommer i epostmeddelanden ellerordbehandlingsdokument presenteras de ofta automatiskt somunderstrukna länkar)mellanslag kan ge svårlästa webbadresser eftersom de ofta kodas omtill %20specialtecken eller svenska tecken som å, ä och ö kan också kodasom och bli svårlästa, och kan även hanteras dåligt i äldreprogramvaror och i internationella sammanhangom två filnamn endast skiljer sig åt genom skillnader i stora och småbokstäver kan de i mycket gamla system förväxlas.

Att länka till filer från webbsidorMöjligheten att länka till andra sidor och dokument är en grundförutsättningför en bra webbplats. De grafiskt markerade länkarna drar blicken till sig ochbidrar till att skapa ett sammanhang för besökarna. Det viktigt att länkar ärtydligt och informativt formulerade, så att de hjälper användarna att hitta rätt.

Det är oftast bäst för användarna om du kan lägga ut information i form aven webbsida i stället för att stänga in den i ett dokument. Ibland kan detdock vara nödvändigt att lägga ut dokument, exempelvis långa rapportereller dokument som är designade för att skrivas ut, som checklistor.

Se även R5. Skriv tydliga länkar, särskilt avsnittet om länkar till dokument.

Vägledning förWebbutveckling Sida 28 /

316

Page 30: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Relaterade riktlinjer

Det finns ganska många webbriktlinjer som berör länkar och adresseringeftersom detta är en viktig del av webbens konstruktion.

ExempelFör rapporten Diarier på Internet – vägledning för myndigheter, utgiven medpublikationsnummer 2003:3, är följande filnamn lämpligt: ”rapport-2003-3-diarier-pa-internet.pdf”.

Senast uppdaterad: 2017-12-15

Prio 1

Ge all information på begripligsvenskaAll information på webbplatsen ska skrivas på begriplig svenska. Målet är attså många personer som möjligt ska kunna tillgodogöra sig innehållet, ävenpersoner med funktionsnedsättningar och personer med svenska somandraspråk.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för begripliga texterAnpassa textens språk och innehåll till målgruppens behov.Skriv tydliga sammanfattningar av innehållet.Förklara ord och uttryck som inte är självklart begripliga för alla, inomparentes direkt efter ordet eller, om det rör många uttryck, i en separatordlista.Förklara ord och uttryck som är centrala för er verksamhet, och samladem i en ordlista. Myndigheter har till och med skyldighet att utvecklaoch tillgängliggöra svenska termer för sitt verksamhetsområde enligt §12 i språklagen.

Ge all information på begriplig svenskaSkriv alla texter på begriplig svenska. Ge dessutom tekniskt stöd för att görainformationen tillgänglig för personer med särskilda behov.

Ett tydligt och begripligt språk gör det lättare för alla att ta till sig innehålletpå en webbplats (se Skriva texter), även för personer som har

Riktlinje nr 10

Vägledning förWebbutveckling Sida 29 /

316

Page 31: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

lässvårigheter eller är ovana läsare. För myndigheter är det lag på attmedborgare alltid ska kunna använda det svenska språket i kontakten medmyndigheten. Språket i offentlig verksamhet ska dessutom vara vårdat,enkelt och begripligt, enligt språklagens § 11.

Tänk även på språket i dokumentation av olika slag (handledningar,användarmanualer med mera.

Vid behov kan det också vara nödvändigt att göra delar av webbplatsentillgänglig på särskilt lättläst svenska (Se R12. Ge information på lättlästsvenska). De texterna ska anpassas till personer med lässvårigheter ochkognitiva funktionsnedsättningar.

Tillhandahåll tekniskt stöd för att görainformationen tillgänglig för personer medsärskilda behovSe till att det finns tekniskt stöd och texter i andra format för att görainformationen tillgänglig för personer med särskilda behov. Uppfyll detta såhär:

Gör innehållet tillgängligt på andra sätt, till exempel genom attkombinera skrift med ljud, bild och film (R11) eller genom att geinformation på lättläst svenska (R12) eller i punktskrift.Använd automatisk textuppläsning (talsyntes) eller ljudfiler för att görainformation tillgänglig för personer med synnedsättning. Detta är oftatill hjälp för personer som inte har tillgång till egna verktyg, men somändå har nytta av dem. Det är också ett stöd för dyslektiker och andrasom har svårt att läsa svensk text.Informera om hur man beställer texter i alternativa format, till exempeli punktskrift eller med Daisy-teknik. Det finns rekommendationer ochen lista med vanliga alternativa format hos Myndigheten fördelaktighet.

Tänk på att det svenska teckenspråket är ett eget språk, inte en tecknadform av svenska. För mer information om hur man gör innehåll tillgängligtpå teckenspråk, se R13. Ge information på svenskt teckenspråk.

ExempelSpecialpedagogiska skolmyndigheten har begriplig information påsvenska i olika former på sin webbplats.Statens Tjänstepensionsverk, SPV, har en ordlista på webbplatsenmed förklaringar av centrala begrepp.

Mätbarhet: begripliga och tillgängliga texterUtvärdera texterna med hjälp av användningstester för att se hur begripligaoch tillgängliga de är. Testa gärna med personer som har särskilda behov,för att se hur de uppfattar texterna.

Vägledning förWebbutveckling Sida 30 /

316

Page 32: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningRiv hindren – riktlinjer för tillgänglighet från Myndigheten fördelaktighet innehåller riktlinjer för tillgänglig information.Klarspråkstestet hjälper dig ta reda på hur begriplig en text är.Språkrådet på Institutet för språk och folkminnen ger information ochstöd till myndigheter om klarspråk.Projektet Begriplig text har publicerat ett kompendium om vad som görläsningen lättare för personer med kognitiva funktionsnedsättningar.Punktskriftsnämnden vid Myndigheten för tillgängliga mediersamarbetar med myndigheter och organisationer inom områdetpunktskrift.Terminologicentrum, TNC ordnar kurser och samordnar myndighetersterminologiarbete.Vägledningen för flerspråkig information från Språkrådet ger merinformation om hur du anpassar webbplatsen till människors olikaspråkliga och kommunikativa behov.

Senast uppdaterad: 2018-02-15

Prio 2

Kombinera skrift med ljud, bild ochfilmKombinera skriven text med ljud, bild och film för att göra informationen mertillgänglig och lättare för alla att förstå. Särskilt viktigt är detta för personermed olika typer av lässvårigheter. Personer med synnedsättning behöverinformation i talad form.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Inköpare och beställare, Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys

Rekommendationer för tillgänglig informationVisa gärna informationsstödjande bilder och filmer på webbplatsen.Se till att det går att lyssna på innehålletTänk på att hålla information i ljud, bild och film uppdaterad.

Visa gärna informationsstödjande bilder och filmerpå webbplatsen

Bildillustrationer och filmer är särskilt värdefulla för viktig

Riktlinje nr 11

Vägledning förWebbutveckling Sida 31 /

316

Page 33: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

samhällsinformation, information i form av instruktioner och liknande.Använd film för att nå personer som har svårt att läsa eller inte kan läsa,men som förstår talspråk med stöd av visuell information.

Se till att det går att lyssna på innehållet

En skärmläsare kan göra textinnehåll mer tillgängligt för personer medlässvårigheter eller nedsatt syn eller med annat modersmål än svenska.Men det fungerar bara om texter är rätt uppmärkta och det finnstextbeskrivningar av innehåll som inte är text. Det finns ganska mångawebbriktlinjer som berör skärmläsare. Till de mer centrala hör R121. Ange ikod vad sidans olika delar har för roll, R141 Ange sidans språk i koden ochR115. Beskriv med text allt innehåll som inte är text.

Enklare skärmläsarprogram (VoiceOver, Narrator, Talkback med flera) finnsinbyggda i de flesta moderna datorer och mobiltelefoner. Personer medvissa funktionsnedsättningar kan även få kommersiella program förskärmläsning (Dolphin, ClaroRead, Jaws, ZoomText med flera.) somförskrivna hjälpmedel.

Erbjud gärna även en skärmläsarfunktion direkt på webbplatsen (tillexempel SpeakIt, ReadSpeaker eller Talande webb). Se då helst till attanvändaren själv kan markera vilken text som ska läsas upp. Allra tydligastblir det med en textuppläsningsfunktion som också fortlöpande markerar vari texten uppläsningen sker.

Skolverket erbjuder en lyssnafunktion på sin webbplats. Detgår att spela upp hela sidan eller enbart ett markerat stycke.

Komplettera eventuellt den automatiska textuppläsningen mednedladdningsbara ljudfiler för texter med höga krav på uppläsningen.

Exempel på webbsidor som kombinerar fleraformat

Om att läsa på många sätt har informationsfilmer på flera språk omanpassade medier.Skolverket erbjuder användare en funktion för automatisk uppläsningav webbplatsens textinnehåll. (Länken ”Lyssna” finns högt upp påsidorna.)Sveriges radio kompletterar sina ljudinslag med text och bild på

Vägledning förWebbutveckling Sida 32 /

316

Page 34: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

webben:

Fördjupning om ljud, bild och videoDenna riktlinje angränsar till flera andra webbriktlinjer om ljud, bild ochvideo.Några förslag på hur kartor, tabeller, diagram och andra typer avvisualiseringar kan göras tillgängliga finns i vår genomgång avtillgänglig presentation av statistisk information.Myter och sanningar om läsning. Om samspelet mellan språk och bildi olika medier av Jana Holsanova från 2010. Språkrådets skrifter 12.Norstedts.

Terminologi

Skärmläsare heter screen reader på engelska. De baseras på en teknik somkallas talsyntes. Skärmläsarfunktion på webbplatser kallas iblandlyssnafunktioner.

Vissa typer av lässvårigheter kallas för dyslexi.

Senast uppdaterad: 2018-10-23

Prio 3

Ge information på lättläst svenskaDen som har lässvårigheter kan ha svårt att tillgodogöra sig texter, även omde är skrivna på ett klart och begripligt språk. Därför kan ni behöva geinformation på lättläst svenska. Lättläst svenska är anpassad efter läsaren.Språket är enklare och texterna kortare, men all viktig information ska ändåfinnas med. Även layout och bilder bör anpassas till läsaren.

Om denna riktlinje

Riktlinje nr 12

Vägledning förWebbutveckling Sida 33 /

316

Page 35: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prioritet: 3Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys

Rekommendationer för lättlästUtforma alla texter på webbplatsen så att de är begripliga för såmånga som möjligt i den tänkta målgruppen. Se riktlinje 10, Ge allinformation på begriplig svenska.Klargör genom en målgruppsanalys om det finns personer medsärskilda behov av lättlästa texter och hur ni bäst anpassar texternaför att nå dem. Personer som har lässvårigheter eller är otränadeläsare behöver särskilt lättlästa texter, som är enkla och välstrukturerade.Gör delar av webbplatsen tillgänglig på lättläst svenska ommålgruppsanalysen visat att det finns behov av det.Gör webbplatsens mest besökta sidor tillgängliga i lättläst form, omdet finns behov av det.Markera tydligt de delar av webbplatsen som finns på lättläst svenskaoch länka till sidans motsvarande sida på lättläst.Tänk att hålla informationen på de lättlästa sidorna uppdaterad.

För myndigheter gäller att ge åtminstone följande information på lättlästsvenska:

En kort beskrivning av vad organisationen gör.Information av centralt samhällsintresse, till exempel vilka rättigheteroch skyldigheter man som medborgare har inom ertverksamhetsområde.Information om hur man kontaktar organisationen.

Råd för att skriva lättlästa texter

Att skriva lättlästa texter handlar i grunden om att anpassa texterna eftermottagarnas behov, kunskap och läsförmåga. Texterna ser därför olika utberoende på vem texten riktar sig till. När man skriver lättlästa texter är detextra viktigt att anpassa texten till läsarnas behov och situation.

Myndigheten för tillgängliga medier ger följande råd:

Lättläst svenska handlar om att välja enklare ord framför svåra,ovanliga ord. Det handlar om att skriva kort, utan att missa viktiginformation.Lättläst handlar också om vilket typsnitt och vilken storlek man skavälja och om hur bilder och text kan samspela för att öka läsbarheten.Det handlar även om att förstå vad läsaren vill och behöver veta.

Informera om att lättläst alternativ finns

Vägledning förWebbutveckling Sida 34 /

316

Page 36: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Informera användare om ni erbjuder separata lättlästa textalternativ. Ett sättatt underlätta för användare som behöver hitta de lättlästa texterna är attanvända en symbol som målgruppen kan förväntas känna igen.

Ikoner för lättläst. Längst till vänster: Den kanske vanligast förekommandesymbolen i Sverige (som vi tror kommer från företaget Funka). Därefterpictogram för lättläst från SPSM, en europeisk symbol för lättläst och slutligenden finska standardsymbolen för lättläst .

Exempel: Boverkets lättlästa sidorBoverket har bra information på lättläst svenska.

MätbarhetUtvärdera sidorna med lättlästa texter med användargrupper som har behovav att få information på lättläst.

FördjupningMyndigheten för tillgängliga medier (MTM) informerar om lättläst.Projektet Begriplig text har publicerat ett kompendium om vad som görläsningen lättare för personer med kognitiva funktionsnedsättningar(pdf, 1,7 MByte).

Senast uppdaterad: 2018-02-09

Prio 2

Ge information på svensktteckenspråkMånga döva och hörselskadade har svenskt teckenspråk som förstaspråkoch svenska som andraspråk. Teckenspråkiga personer behöver fåinformation på sitt förstaspråk, på samma sätt som andra minoritetsgrupper.Nyinflyttade teckenspråkiga personer lär sig i regel det svenskateckenspråket ganska snabbt. Däremot tar det längre tid för dem att lära sigskriven svenska.Tänk på att det svenska teckenspråket är ett annat språk än svenska. Detär inte en tecknad representation av svenska. Det finns många olikateckenspråk i världen.

Om denna riktlinjePrioritet: 2Principer: Tillgänglig

Riktlinje nr 13

Vägledning förWebbutveckling Sida 35 /

316

Page 37: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys

Rekommendationer: information på teckenspråkVälj ut vilken information som behöver översättas, utifrånorganisationens uppdrag och utifrån vad målgruppen förväntas viljagöra på webbplatsen.Markera de delar av webbplatsen som är översatta till teckenspråkmed en teckenspråkssymbol.

Välj ut vilken information som behöver översättasGör en målgruppsanalys för att ta reda på målgruppens behov, och anpassawebbplatsen och informationen som ska översättas efter behoven.

Låt även organisationens uppdrag styra vilken information som skaöversättas. Detta gäller i synnerhet om möjligheten till andrakommunikationsvägar är begränsade, till exempel bildtelefoni via enförmedlingstjänst eller fysiska besök med teckenspråkstolk.

Välj ut vad som ska översättas i samråd med målgruppen och personersom har kännedom om målgruppen. Det kan till exempel vara informationom

organisationen och dess verksamhetservice för välfärdstjänster såsom barnomsorg, äldrevård och skolanyheterviktiga e-tjänster som beställningstjänster, databassökningar ellerblanketterinformation om hur man kontaktar organisationen i olika ärenden.

Översättningen ska göras utifrån teckenspråkets villkor, utan att styras avkälltextens skriftspråkliga form. Den mest effektiva strukturen i svensktteckenspråk kan skilja sig från skriftspråkets, vilket gör att en översättningbehöver frigöras från originaltextens skriftspråkliga prägel.

Markera de delar av webbplatsen som är översattatill teckenspråk med en teckenspråkssymbol.Markera både i skrift och visuellt vilka delar av webbplatsen som äröversatta till teckenspråk. Gör det så här:

Placera en teckenspråkssymbol som är länkad till teckenspråkiginformation väl synlig på startsidan.

Symbol för information på teckenspråk. För licensinfo, se avsnittetåteranvändning av symboler i R113. Använd webbvideo för att öka

Vägledning förWebbutveckling Sida 36 /

316

Page 38: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

tillgängligheten.Nämn på sidan som informerar om olika språk att webbplatsen harinformation på svenskt teckenspråk.Gör en samlingssida över de delar av webbplatsen som är översattatill teckenspråk, så att användarna snabbt hittar all teckenspråkiginformation på webbplatsen.Presentera teckenspråksfilmer intill motsvarande textinnehåll på enwebbsida så att användarna kan överblicka det översatta innehållet.

Videoformat för teckenspråksfilmEn teckenspråksfilm på webben måste möta flera krav. Läsbarheten berorbland annat på bildupplösning och bildväxlingsfrekvens.

Se till att filmerna har god bildkvalitet (hd-kvalitet) och inte är för hårtkomprimerade.Se till att filmerna går att visas i fullskärmsläge.Låt filmerna vara korta, gärna 2–3 minuter långa. Dela upp långa filmeroch organisera dem under tydliga rubriker för att göra det lättare attvälja film efter innehåll.

Exempel på myndighetsinformation på svensktteckenspråk

Arbetsförmedlingens teckenspråkiga serviceAle kommun

Pensionsmyndigheten och andra myndigheter har grundläggandeinformation på teckenspråk. Gör en målgruppsanalys för att ta reda på vilkeninformation som ska översättas.

Mätbarhet: utvärdera med teckenspråkigaanvändare

Vägledning förWebbutveckling Sida 37 /

316

Page 39: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Utvärdera teckenspråksfilmernas användbarhet med teckenspråkigaanvändare, även med dem som har synnedsättning.

Fördjupning om teckenspråksfilmerBroschyren Inför upphandling av teckenspråksfilmer från Sveriges DövasRiksförbund.

Kravprofil för teckenspråksfilmer på webbsidor från Sveriges DövasRiksförbund.

Handledningen Produktion av information på teckenspråk från föreningenFinlandssvenska teckenspråkiga.

Handledningen Hur ser en bra teckenspråksöversättning ut? av FinlandsDövas Förbund.

WCAG 2.1 har ett kriterium (på nivå AAA) för teckenspråkstolkning avljudinnehåll i inspelat material.

Det finns en handfull andra webbriktlinjer som berör teckenspråk på någotsätt.

Två föreläsningar om teckenspråk på webbenHär följer en inspelning av två föreläsningar om svenskt teckenspråk påwebben. Isabella Hagnell, generalsekreterare Sveriges dövas riksförbund,tar upp ämnet ur ett teckenspråkigt användarperspektiv och Mindy Drapsasom jobbar bland annat med presentation av teckenspråk på webben tarupp det perspektivet.Det finns även separat syntolkad ljudversion av inspelningen.

Download videoDownload captions

Textinnehåll

Senast uppdaterad: 2018-12-07

Prio 2

Ge information på de nationellaminoritetsspråkenPersoner som talar något av våra fem nationella minoritetsspråk harsärskilda rättigheter till sina språk. Minoritetsspråkstalare ska till exempelkunna använda sitt modersmål i kontakt med myndigheter. De nationellaminoritetsspråken i Sverige är finska, samiska, meänkieli, romska (romanichib) och jiddisch.

Riktlinje nr 14

Vägledning förWebbutveckling Sida 38 /

316

Page 40: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Målgruppsanalys

Rekommendationer för nationella minoritetsspråkGe grundläggande information på alla nationella minoritetsspråk. Dettaär en lagstadgad skyldighet för myndigheter.Ge viktig information och service på finska, meänkieli och samiska tillnationella minoriteter inom förvaltningsområdena.Välj vad som ska översättas i samråd med berörda grupper.

Ge grundläggande information på alla nationellaminoritetsspråkAlla myndigheter har en lagstadgad skyldighet att upplysa om de nationellaminoriteternas rättigheter på minoritetsspråken. Gör detta till exempelgenom att hänvisa till befintliga lagtexter och informationsblad påminoritetsspråken. Lägg också ut kontaktuppgifter till personal som talarnågot av minoritetsspråken. För myndigheter med anknytning tillförvaltningsområdena är detta ett krav. Andra myndigheter ska lämnakontaktuppgifter om det finns personal som talar minoritetsspråket.Alla myndigheter bör lägga ut grundläggande information på sin webbplatspå minoritetsspråken, till exempel

information om den egna verksamhetenkontaktinformationinformation som rör den aktuella minoritetsgruppen.

Man bör också så långt det är möjligt lägga ut den viktigaste och den mestefterfrågade informationen på webbplatsen, till exempel

central samhällsinformationofta använda blankettervanliga e-tjänster.

Observera att rätt språkkod behöver anges i html-koden för attinformationen ska läsas upp korrekt av skärmläsare, avstavas rätt osv. Läsmer om språkkoderna i R17. Anpassa webbplatsen för flerspråkighet.

Koder för de nationella minoritetsspråken

Språketsnamn påsvenska

VariantSpråkets egetnamn

Värde på lang-attribut

Finska Suomeksi fi

Jiddisch שידיי yi

Vägledning förWebbutveckling Sida 39 /

316

Page 41: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Meänkieli Meänkieli fit

Romska Romani čhib rom

Romska är ett samlingsnamn för flera varianter. Hör medmålgruppen om vilken kod som fungerar bäst. Vid osäkerhet,använd “rom”.

Arli Romani arli rmn

Gurbeti Romani gurbeti rmy

Kalderaš Romani kalderaš rmy

Kálo Romani kálo rmf

Lovara Romani lovara rmy

Resanderomska Tavringer rmu

Samiska Sámigiella smi

Samiska är ett samlingsnamn för flera varianter. Hör medmålgruppen om vilken kod som fungerar bäst. Vid osäkerhet,använd ”smi”.

Nordsamiska Davvisámigiella se

Lulesamiska Julevsámegiella smj

Sydsamiska Åarjelsaemien sma

Observera att det inte finns stöd för alla språk och dialekter i allaskärmläsare. Använd gärna kommentarsfunktionen på denna sida om duhar tips på skärmläsare/röster med bra stöd för något svensktminoritetsspråk (förutom finska där befintliga språkstöd fungerar i de flestafall).

Ge viktig information och service på finska,meänkieli och samiska till nationella minoriteterinom förvaltningsområdenaInom vissa förvaltningsområden har medborgare rätt att användaminoritetsspråket i muntlig och skriftlig kontakt med förvaltningsmyndigheteroch domstolar. Det i sin tur leder till att enskilda personer ska kunna fåinformation på minoritetsspråket vid kontakt med myndigheten viawebbplatsen. Ett förvaltningsområde är ett administrativt område som styrsav regeringen.

Finsk-, meänkieli- och samisktalande personer har starkast rättigheter inomvissa förvaltningsområden där dessa språk använts länge, medan jiddischoch romska har ett mer allmänt formulerat skydd.

Observera att denna rekommendation i första hand gäller kommuners,landstings och rikstäckande myndigheters webbplatser.

Välj vad som ska översättas i samråd med berördagrupper

Vägledning förWebbutveckling Sida 40 /

316

Page 42: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Välj ut vad som ska översättas i samråd med berördaminoritetsspråkstalare. Informera också alltid om att det går att begäraöversättningar när sådana saknas.

Tänk på följande när ni väljer vad som ska översättas: Samiska och romskainnefattar flera olika språk, varav flera inte är ömsesidigt begripliga. Närman översätter till dessa språk måste man välja vilka varianter som skaöversättas till i samråd med översättare, minoritetsorganisationer ochberörda invånare.

Översättningar till romska bör göras i kommuner med många romsktalande,men i möjligaste mån även på nationell nivå. Romska är inte bara ettnationellt minoritetsspråk utan också ett relativt stort invandrarspråk blandnyanlända i Sverige.

Jiddisch har mycket få modersmålstalare i Sverige, men språket behöverprecis som de andra nationella minoritetsspråken synliggöras och främjas.En del i detta är att myndigheter översätter vissa grundtexter till språket.Observera att språket när det skrivs med hebreiska tecken läses från högertill vänster. Läs mer om språkriktning i Anpassa webbplatsen förflerspråkighet (R17).

Exempel: Stockholms kommuns finska sidorStockholms kommun ingår i det finska förvaltningsområdet och harinformation på finska.

Mätbarhet: utvärdera med användarnaUtvärdera webbplatsen med användare som har behov av och rättigheter attanvända de nationella minoritetsspråken i sina kontakter med myndigheten.

Fördjupning för flerspråkig informationI Vägledningen för flerspråkig information från Språkrådet finns merinformation om hur du anpassar webbplatsen med hänsyn till denationella minoriteternas språkliga behov och rättigheter.Länsstyrelsen i Stockholms län och Sametinget (samiska) ansvarar församordning av minoritetsspråkspolitiken och uppföljning av lagen omnationella minoriteter och minoritetsspråk.Språkrådet besvarar frågor om finska, romska och teckenspråk.De nationella minoriteternas officiella webbplats minoritet.se.

Senast uppdaterad: 2017-07-04

Prio 4

Ge information på engelska ochandra språk

Riktlinje nr 15

Vägledning förWebbutveckling Sida 41 /

316

Page 43: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Många som inte har svenska som modersmål behöver få information på sitteget språk. Det är allra viktigast för personer som inte behärskar svenskaalls, som nyanlända invandrare, men är ofta till stor hjälp även för den somkan lite svenska. Utöver kraven på begriplig svenska för alla (se R10) ochinformation på nationella minoritetsspråk (se R14), bör myndigheter ochandra offentliga organ därför översätta delar av sin information till andraspråk.

Om denna riktlinjePrioritet: 4Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys

Rekommendationer för information på olika språkVälj språk utifrån tillgänglig språkstatistik och en målgruppsanalys.Välj vad som behöver översättas utifrån ert uppdrag och vadmålgrupperna antas vilja göra på webbplatsen.Översätt inte bara texten utan anpassa även innehållet.

Välj språk utifrån tillgänglig språkstatistik och enmålgruppsanalysVilka språk ni ska översätta till beror på vilka målgrupper ni har. För enkommun eller en privat aktör kan det innebära att se över vilka språk somtalas i kommunen. För en förvaltningsmyndighet kan det innebära attfundera över vilka språkliga målgrupper som är berörda av er verksamhet.Om ni har hela befolkningen som målgrupp är språkens storlek i Sverigeintressant, men tänk på att språkens storlek kan skilja sig mycket mellanolika delar av landet och att de förändras över tiden. Gör därföråterkommande målgruppsundersökningar för att klargöra vilka behov somfinns.Ange gärna särskilda kontaktpersoner för olika språk i kontaktinformationenpå webbplatsen.

Välj vad som behöver översättas utifrån ert uppdrag och vad målgruppernaantas vilja göra på webbplatsen. Utgå från organisationens uppdrag ikombination med vilka ärenden målgrupperna antas ha på webbplatsen föratt välja ut vad som behöver översättas. Välj också gärna ut vilkeninformation som ska översättas i samråd med berörda målgrupper, och setill att hålla en god kvalitet på översättningarna (R16). Om det saknasöversättningar bör ni upplysa om att ni kan ta fram översättningar påbegäran. Kom ihåg att skriva ut detta på de främmande språken.

Information som kan behöva översättas är

grundläggande samhällsinformation för nyanländainformation om service för välfärdstjänster som barnomsorg, äldrevårdoch skola

Vägledning förWebbutveckling Sida 42 /

316

Page 44: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

viktiga e-tjänster: beställningar, databassökningar och blanketterinformation om organisationen och dess verksamhethur man kontaktar organisationen i olika ärenden och får informationoch service på olika språk.

Översätt inte bara texten utan anpassa äveninnehålletAnvändare från andra språkområden kan ha andra behov änsvenskspråkiga användare. Utgå inte från att alla har samma grundkunskapom det svenska samhället och dess institutioner; ni kan behöva förklarasådant som framstår som självklarheter i de svenska texterna. Kom ocksåihåg att

hålla informationen uppdaterad på alla språken.undersöka om andra närliggande verksamheter, till exempel andramyndigheter, har översatt relevant material som ni kan återanvändaeller länka till.ge information i andra format än enbart text. Även för främmandespråk kan man behöva kombinera skrift med ljud, bild och film (R10),eller informera om att man kan ringa någon som talar det egnaspråket.

Observera att rätt språkkod behöver anges i html-koden för attinformationen ska läsas upp korrekt av skärmläsare, avstavas rätt osv. Läsmer om språkkoderna i R17. Anpassa webbplatsen för flerspråkighet.

Exempel på presentation av flerspråkiga sidor

Migrationsverket har översatt delar av sin webbplats till ett flertal olika språk.I sidhuvudet markeras detta med en jordglob och texten Other Languagesefter.

Försäkringskassan har information på en rad främmande språk. Varjetextrad förekommer både på svenska och det främmande språket, vilket

Vägledning förWebbutveckling Sida 43 /

316

Page 45: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

underlättar för redaktörerna. Observera att vissa språk presenteras frånhöger till vänster.

Mätbarhet: utvärdera med användarna

Utvärdera webbplatsen med grupper som har behov av information ochservice på andra språk än svenska.

Fördjupning kring flerspråkig informationI Vägledningen för flerspråkig information från Språkrådet finns merinformation om hur du anpassar webbplatsen för andra språk än svenska.Där finns också statistik över de vanligaste modersmålen i Sverige.

I boken Sveriges språk i siffror av Mikael Parkvall (Språkrådet och Morfemförlag 2016) görs omfattande bedömningar av vilka språk som talas iSverige och av hur många. I appendix finns uppgifter om drygt hundra språkoch beskrivningar av språksituationen i landets 290 kommuner.

Senast uppdaterad: 2017-11-15

Prio 4

Håll god kvalitet på översättningarnaSpråklagens krav på vårdat, enkelt och begripligt språk (se R10) gäller allaspråk som används i offentlig verksamhet, även svenskt teckenspråk. Härföljer några råd med syfte att upprätthålla kraven på begriplighet också iöversatta texter.

Om denna riktlinjePrioritet: 4Principer: AnvändbarRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?:

RekommendationerSe till att översatta texter håller god kvalitet och följer språklagens kravpå vårdat, enkelt och begripligt språk.Anpassa texterna till målgruppen innan de översätts, både vad gällerspråknivå och innehåll.Anlita professionella översättare och tänk på att även beställa sättningoch ombrytning till din layout, om du behöver översättning till ett språkdu inte kan läsa alls. Du kan även beställa språkgranskning avöversättningarna.Samarbeta med andra och utnyttja gemensamma översatta källtexter.Det spar tid och pengar. Andra organisationer kan redan ha översatt

Riktlinje nr 16

Vägledning förWebbutveckling Sida 44 /

316

Page 46: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

motsvarande text, som ni kanske kan återanvända eller länka till.Låt gärna rubriker på webben, blanketter och liknande stå både påsvenska och på det främmande språket. Det underlättar för densvenskspråkig personal som ska hjälpa personer med annatmodersmål.

Se till att även översatta texter håller god kvalitetoch följer språklagens krav på vårdat, enkelt ochbegripligt språkAlla läsare är hjälpta av ett språk som är vårdat, enkelt och begripligt. Hjälpdärför översättaren genom att leverera källtexter som redan från början ärskrivna på tydlig och begriplig svenska. Var generös med förtydligandesambandsord och ge tydliga instruktioner om hur texten ska användas.

Texterna som ska översättas kan behöva skrivas på ett sätt som gör att dehåller längre än de svenskspråkiga texterna på webbplatsen, som kanskeuppdateras oftare. Det gäller även underlag för teckenspråksfilmer.

Ge översättaren tydliga instruktioner om hur texten ska användas. Det gerbättre texter på det språk ni översätter till. Överväg att låta en annan personmed språket som modersmål korrekturläsa och språkgranskaöversättningarna.

Anlita gärna en formgivare som behärskar språket, eftersom det kan varasvårt med till exempel radbrytning på ett främmande språk.

Var medveten om riskerna med att bygga in funktioner för automatisköversättning på webbplatsen. Risken är stor att texterna översätts felaktigtoch att användarna tror att ni står bakom översättningen.

Anpassa texterna till målgruppen innan deöversätts, både vad gäller språknivå och innehållSkapa förutsättningar för en god kvalitet på översättningen och en bragrundtext:

Förklara eventuella kultur- och samhällsspecifika uttryck i texten eller ispeciella ordlistor.Använd väldefinierade termer och deras exakta motsvarigheter på detfrämmande språket. Behåll gärna svenska ord inom parentes vidcentrala begrepp, så att kopplingen till det svenska uttrycket blir tydligäven om texten är översatt.Kontrollera översatta fack- och samhällstermer i källor som Lexin(samhällstermer), Rikstermbanken och IATE (Inter-Active Terminologyfor Europe) för fackuttryck.

En läsare som kommer från ett annat språkområde än det svenska kan haandra behov än svenskspråkiga, och dessutom sakna grundkunskap om detsvenska samhället och dess institutioner. Därför kan man behöva förklara

Vägledning förWebbutveckling Sida 45 /

316

Page 47: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

sådant som i det svenska materialet är självklarheter och ta bort innehållsom är irrelevant för målgruppen. Fundera på om det är motiverat attöversätta grundtexten eller om det är bättre att skapa en ny text från början.Välj strategi utifrån vilket innehåll som måste finnas med i den nya texten.

Exempel: Riksdagens översatta informationRiksdagen.se har översatt information om riksdagen och det demokratiskasystemet i Sverige till flera språk med hjälp av auktoriserade översättare.

Mätbarhet: utvärdera med användareUtvärdera översättningarna med användare som talar det aktuella språket.

Fördjupning: översättare och SpråkrådetsrekommendationerKammarkollegiet har en lista över auktoriserade översättare.

Språkrådets vägledning för flerspråkig information.

Handledningen Hur ser en bra teckenspråksöversättning ut? Av FinlandsDövas Förbund.

Senast uppdaterad: 2018-01-29

Prio 3

Anpassa webbplatsen förflerspråkighetFlerspråkiga webbplatser behöver både tekniskt stöd och en bra struktur föratt fungera optimalt. Riktlinjen sammanställer erfarenheter av hurwebbplatser kan anpassas för flerspråkighet.

Om denna riktlinjePrioritet: 3Principer: AnvändbarRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Målgruppsanalys, Prototypning

Rekommendationer för flerspråkighetSe till att publiceringsverktyget har stöd för att hantera flera språk ochteckenuppsättningar på ett korrekt, enkelt och effektivt sätt. Valet avpubliceringsverktyg kan sätta gränser för vad som är möjligt att göra iett flerspråkigt perspektiv.Översätt grundläggande navigeringselement som sök och kontakt om

Riktlinje nr 17

Vägledning förWebbutveckling Sida 46 /

316

Page 48: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ni har omfattande avdelningar på olika språk.Ange aktuellt språk i html-kod och kontrollera att den automatiskatextupplä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 sidanoch komma med synpunkter.

Skapa tydliga ingångar till olika språk

Placera språkingångarna tydligt och konsekvent på alla webbsidor, gärna isidhuvudet eller på någon annan central plats som är åtkomlig från alla sidorpå webbplatsen.

Skriv länktexter på det språk du länkar till, alltså ”français” och inte”franska”, när du länkar till sidor på franska. Använd inte flaggor somspråkindikation, eftersom länder ofta har flera officiella språk. Däremot kandu gärna använda en ikon som föreställer en jordglob och komplettera medlänktexten ”Other languages” när du länkar till en samlingssida där man kanvälja olika språk.

Om webbplatsen har en särskild sida med översättningar till olika språk börsvenskt teckenspråk nämnas där. Sätt gärna upp en samlingssida med allateckenspråksfilmer på webbplatsen och markera de delar av webbplatsensom är översatta till teckenspråksfilm med en särskild teckenspråkssymbol.Se R13 Ge information på svenskt teckenspråk.

Det finns olika vägar att gå när det gäller strukturen på en flerspråkigwebbplats. Välj en enklare lösning med separata ingångssidor för olikaspråk, eller en mer ambitiös med flerspråkiga parallella versioner av sammatext. Oavsett lösning är det viktigt att användarna snabbt och enkelt kan sevilka texter på webbplatsen som finns översatta till vilket språk.

Ange aktuellt språk i html-kodSidans huvudspråk (som används i menyer, sidhuvud mm) bör anges medhjälp av lang-attributet i sidans rot-element:

<html lang=”sv”>

Se R142. Ange sidans språk i koden.

Om det finns innehåll på sidan som har ett annat språk än sidanshuvudsakliga språk bör element som omsluter detta innehåll förses medlang-attribut:

<div lang=”fit”>Sinulla on oikeus käyttää kansallisia

minoriteettikieliä</div>

Se R142. språkförändringar i koden.

Vägledning förWebbutveckling Sida 47 /

316

Page 49: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Koder för de svenska minoritetsspråken finns i R14. Ge information på denationella minoritetsspråken.

Ange språkriktning för innehåll som läses frånhöger till vänster

Tänk på att vissa språk har en annan språkriktning än svenskan. Andraspråk, till exempel arabiskan läses från höger till vänster. Det finns ävenspråk som läses vertikalt, men dessa kan och brukar presenteras vågrätt iwebbsammanhang.

Ibland fungerar det att utan särskild åtgärd skriva in sådan text i webbsidan,eftersom webbläsaren vet vilka tecken som ska läsas i vilken riktning. Mendet händer att exempelvis siffror, frågetecken, utropstecken mm (somförekommer både i höger- och vänster-riktade språk) hamnar på fel sida iförhållande till texten.

Förutom att du alltid bör ange språkförändringar i koden (R142) bör därförhtml-attributet dir=”rtl” sättas på element vars innehåll ska läsas från

höger till vänster. Förkortningen dir står för ”direction” och rtl står för ”right toleft”. Om det inte redan finns ett element som innehåller det textavsnitt somhar en viss språkriktning så kan du omsluta textpartiet med exempelviselementet span.

Om det är hela stycken och inte bara enstaka ord som ska läsas från högertill vänster så kan stycket behöva högerställas med css (text-align:

right;).

När vänster- och högerriktade språk blandas i samma textavsnittrekommenderar vi att du även sätter dir=”ltr” (left-to-right) på alla

vänster-höger-texter som ligger infällda i avsnitt med motsatt riktning. Dettakan exempelvis gälla information från myndigheter där svenska begreppbehöver presenteras i texter på främmande språk.

Observera att det är svårt för en person som inte behärskar ett främmandespråk att upptäcka felaktigheter i presentationen. Detta gäller särskilt förspråk som läses från höger till vänster. Därför rekommenderar vi någonmed språkkunskaper granskar sådana sidor. Se Håll god kvalitet påöversättningarna (R16).

ExempelI följande text ska allt utom länken översättas till arabiska:

På sidan Hur ansöker jag? finns mer information (på svenska).Skiljetecken riskerar att hanteras fel när vänsterriktat innehåll, som i dettafall, omges av högerriktat innehåll utan att riktningsförändringen anges ikod:

HTML

Vägledning förWebbutveckling Sida 48 /

316

Page 50: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

<a href="#" ةحفصلا يف <span lang="ar" dir="rtl">

نم ديزم ىلع روثعلا lang="sv">Hur ansöker jag? </a>

(. ةيديوسلا ةغللاب ) تامولعملا</span>

Presentation(. ةيديوسلا ةغللاب ) تامولعملا نم ديزم ىلع روثعلا ?Hur ansöker jag ةحفصلا يف

Om länken med avvikande riktning använder attributet dir="ltr" så

hamnar skiljetecken rätt:

HTML<a href="#" ةحفصلا يف <span lang="ar" dir="rtl">

ىلع روثعلا dir="ltr" lang="sv">Hur ansöker jag? </a>

(. ةيديوسلا ةغللاب ) تامولعملا نم ديزم </span>

Presentation(. ةيديوسلا ةغللاب ) تامولعملا نم ديزم ىلع روثعلا ?Hur ansöker jag ةحفصلا يف

Det går även att använda css-egenskaperna direction och bidi-

override för att ange läsriktning:

CSS.svenska

direction: ltr;

unicode-bidi: bidi-override;

HTML<a href="#" ةحفصلا يف <span lang="ar" dir="rtl">

روثعلا class="svenska" lang="sv">Hur ansöker jag? </a>

(. ةيديوسلا ةغللاب ) تامولعملا نم ديزم ىلع </span>

Presentation(. ةيديوسلا ةغللاب ) تامولعملا نم ديزم ىلع روثعلا ?Hur ansöker jag ةحفصلا يف

Lägg helst informationen i html om det är möjligt, eftersom det händer attcss inte tillämpas (Se webbriktlinjen Se till att webbplatsen kan användasäven utan stilmallar (R92)). Men om du inte har behörighet eller kunskap föratt redigera html så kan css vara ett alternativ. Kanske kan du med hjälp avditt publiceringssystem lägga till en viss css-klass på de avsnitt som har enavvikande språkriktning.

Läs mer om språkriktning hos W3C.

Språk- och läsriktning kan ha betydelse för interaktionsdesignen och hurwebbplatsen uppfattas i ett responsivt läge. Exempelvis kan placeringen av

Vägledning förWebbutveckling Sida 49 /

316

Page 51: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

knappar behöva anpassas när användaren läser sidan från höger tillvänster. Kontrollera att de översatta sidorna fungerar med erinteraktionsdesign, och se till att det fungerar bra för användare med en litenskärm.

Exempel: flerspråkiga webbplatser1177.se har information på många olika språk. En bakomliggandebehovs- och målgruppsanalys (pdf) är offentligt publicerad.Internationella biblioteket har en flerspråkig webbplats med flera språkmed icke-latinska alfabet, som ryska, kinesiska och arabiska.De respektive sidorna om minoritetsspråk hos Institutet för språk ochfolkminnen är kodade med lang-attribut.Information Sverige är ett annat bra exempel på en fullt flerspråkigwebbplats.

MätbarhetUtvärdera webbplatsens kod mot tekniska standarder som berörflerspråkighet. W3C har ett valideringsverktyg som utför sådankontroll.Utvärdera strukturen och navigationen för flerspråkiga användaregenom att göra användningstester med personer som talar de olikaspråken.

FördjupningI Vägledningen för flerspråkig information från Språkrådet finns merinformation om hur du anpassar webbplatsen för andra språk änsvenska.W3C:s internationaliseringsgrupp har detaljerad information, råd ochresurser som rör flerspråkiga webbplatser.Blogginlägg om myndighetsinformation på språk som läses från högertill vänster.

Terminologi

Tänk på att det är skillnad mellan en internationell webbplats och enflerspråkig webbplats. En internationell webbplats är skapad för eninternationell publik, medan en flerspråkig webbplats är en som innehållersidor på flera språk.

Att anpassa ett system så att det fungerar internationellt kallas på engelskaför internationalization, vilket brukar förkortas i18n (bokstaven ”i” följt av 18tecken och därefter ”n”). Att anpassa för en specifik region(land/språk/kultur) kallas för localization, vilket med en liknande så kalladnumeronym kan förkortas l10n.

När det gäller teckensnitt används även orden typsnitt eller fonter. Ettteckensnitt är en uppsättning bokstäver, siffror och tecken med ettgenomgående utseende och ett gemensamt namn, till exempel Helvetica

Vägledning förWebbutveckling Sida 50 /

316

Page 52: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

eller Times New Roman. Font är ett engelskt lånord som ofta används närman på svenska avser en teckensnittsfil i en dator, medan det på engelskaäven kan betyda typsnitt.

Meänkieli kallas ibland för tornedalsfinska.

ptext-align:right;//–>

Senast uppdaterad: 2018-11-28

Prio 2

Följ MSB:s rekommendationer förkrisinformation på webbenWebben ökar möjligheterna till en snabb och samordnadkriskommunikation. Hur ni kommunicerar med era målgrupper under eneventuell kris är grundläggande för hur ni hanterar krisen i sin helhet. Nibehöver ha god beredskap inom både teknik, information och organisationför att ni lätt ska kunna anpassa informationen på webbplatsen utifrånkrisens natur och utveckling.

Om denna riktlinjePrioritet: 2Principer: FörtroendeingivandeRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Förvaltning, Informationssäkerhet,Innehållsproduktion, Säkerhet

Rekommendationer för kriskommunikationGe tydlig, snabb, tillgänglig och korrekt information när något allvarligthar inträffat.Följ rekommendationer från Myndigheten för samhällsskydd ochberedskap, MSB, för krisinformation på webben.Se till att det finns en teknisk krisberedskap.Se även webbriktlinjer som är extra viktiga vid kriser.

Ge tydlig, snabb, tillgänglig och korrekt informationnär något allvarligt har inträffat

Kriskommunikation bygger på den enskildes rätt till information och öppensamhällsdialog när det extraordinära inträffar. Det är då det är som viktigastmed tydlig, snabb, tillgänglig och korrekt kommunikation.

Försök besvara följande frågor när något allvarligt har inträffat:

Riktlinje nr 18

Vägledning förWebbutveckling Sida 51 /

316

Page 53: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Vad har hänt?Får det konsekvenser för mig?Vad gör ansvariga myndigheter/organisationer (hur hanteras krisen)?Hur ska jag förhålla mig till det som har hänt (vad ska jag göra)?Vem ska jag vända mig till för att få mer information/vem gör vad?

Följ rekommendationer från Myndigheten församhällsskydd och beredskap för krisinformationpå webben

När en allvarlig händelse inträffar använder människor oftast flera olikakällor och kanaler för att få information. De använder inte enbart webben,utan även sociala medier för att hitta information och för att kommunicerasjälva. Därför går det inte längre att enbart planera för kommunikation viawebben vid en kris, man måste se kriskommunikation i olika kanaler som enhelhet.

Webben är generellt myndigheters främsta kontaktyta gentemotomgivningen för att både i vardag och kris sprida, kommunicera och lagrasamhälls- och krisinformation. Men de flesta myndigheter har även dialogmed sina målgrupper i sociala medier.

I MSB:s skrift ”Sociala medier och webb vid kris” (pdf) – finns råd kring hurmyndigheter och organisationer kan utveckla strategier och taktiker förwebbanvändning och användning av sociala medier före, under och efterkriser.

Krisinformation.se, som drivs av MSB, har också en guide för kommunersriskkommunikation.

Mer information om samhällets krishantering finns på Krisinformation.se.Följ rekommendationer på den webbplatsen och lägg gärna länkar till denfrån er egen webbplats så att den blir lätt för användare att hitta.

Se till att det finns en teknisk beredskap förkriskommunikation

När man planerar för sin kriskommunikation på webben är det även viktigtatt förbereda sig på att även själva webplatsen kan drabbas. Det är därförviktigt att organisationens rutiner beskriver hur organisationen skyddar sigmot intrång, skyddar sin information och förbereder sig på t exöverbelastningsattacker. Varje organisation behöver också planera för att dekanaler som används för krisinformation klarar en större belastning av trafikoch att det även finns alternativa kanaler, eftersom mängden samtidigabesök alltid kan öka vid en allvarlig händelse.

Myndigheten för samhällsskydd och beredskap (MSB) har råd om hur dukan utveckla organisationens internet- och informationssäkerhet och vad du

Vägledning förWebbutveckling Sida 52 /

316

Page 54: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bör tänka på. Vid IT-incidenter kan svenska myndigheter få stöd och rådfrån CERT-SE vid Myndigheten för samhällsskydd och beredskap.

https://www.informationssakerhet.sehttps://cert.se/

Se även webbriktlinjer som är extra viktiga vidkriser

Vid en allvarlig händelse när människor drabbas eller påverkas är detnödvändigt att informationen går att förstå, att det är tydligt vem som äravsändare, att informationen är tydlig och går lätt att hitta. Några av deriktlinjer som är extra viktiga vid en kris är därför:

Ange vem som är innehållssansvarig för varje sida (R21)Ge all information på begriplig svenska (R10)Möjliggör synpunkter, frågor och dialog (R38)Informera om myndighetens uppdrag och kontaktvägar (R3-4)Gör det lätt att hitta det viktigaste (R28)Skriv tydliga länkar (R5)Bestäm målgrupper och syften för webbtexterna (R8)Information på svenskt teckenspråk, de nationella minoritetsspråkensamt engelska och andra språk (R13-15)

Senast uppdaterad: 2016-04-26

Prio 5

Beskriv hur webbplatsen fungerar ochvad den innehållerBeskriv hur användarna kan anpassa webbplatsen efter sina behov, hur dekan använda den och vad den innehåller, till exempel om det finnsintegrerade externa tjänster. Samla informationen under Om webbplatsen.Samlingssidan Om webbplatsen ska gå att komma åt från alla webbplatsenssidor.

Om denna riktlinjePrioritet: 5Principer: Användbar, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för Om webbplatsenGör en sida som heter ”Om webbplatsen” och som går att nå från allawebbplatsens sidor.

Riktlinje nr 19

Vägledning förWebbutveckling Sida 53 /

316

Page 55: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Beskriv hur webbplatsen fungerar under ”Om webbplatsen”.Beskriv hur användarna kan anpassa innehållet och webbplatsensinställningar under ”Om webbplatsen”.Samla juridisk information om till exempel personuppgifter och kakorunder ”Om webbplatsen”.

Beskriv hur webbplatsen fungerarVad kan era användare behöva veta om just er webbplats, för att den skafungera så bra som möjligt? Beskriv under ”Om webbplatsen” hurwebbplatsen är uppbyggd, eftersom det underlättar för användarna att hittadet de söker. Beskriv också vilka funktioner som finns på webbplatsen, hurde fungerar och vad som krävs för att de ska fungera så bra som möjligt.Beskriv

webbplatsens strukturvilka webbstandarder webbplatsen följerwebbplatsens funktioner, om webbplatsen använder script, och vilkakonsekvenser det får om användarna har script avslagna i sinwebbläsare. Ni kan inte kräva att användarna ska ha stöd förjavascript eller Flash för att webbplatsen ska fungera. (Se R93.)vilka eventuella externa tjänster som är integrerade i webbplatsen ochvad det kan få för konsekvenser för användarna, se R67. Ta reda påkonsekvenserna av att använda externa tjänster i din webblösning.om användarna måste ha något särskilt program för att användainnehåll eller tjänster på webbplatsen; beskriv också var det går attladda ner programmet eller tillägget samt vad användarna kan göraom de får problem med programmet.

Beskriv hur användarna kan anpassa innehålletoch webbplatsenAnvändarna kan behöva ändra inställningar och utseende i sin webbläsareför att kunna använda webbplatsens innehåll. Beskriv hur de bäst anpassarwebbplatsen efter sina behov:

att det finns funktioner i de flesta webbläsare som kan användas föratt ändra utseende (till exempel teckenstorlek).vilket ytterligare stöd för tillgänglighet webbplatsen har, till exempelvilka snabbkommandon som finns och hur man använder dem i olikawebbläsare och operativsystem. Se R68. Skapa snabbkommandonvid behov.vilka möjligheter man har att beställa information i alternativa format,exempelvis Daisy eller punktskrift.

Samla juridisk information om personuppgifter,kakor m.m. under ”Om webbplatsen”Samla juridisk information under ”Om webbplatsen”. Beskriv där till exempelhur ni hanterar personuppgifter och kakor, se R20. Upplys hur juridiskinformation och kakor hanteras.

Vägledning förWebbutveckling Sida 54 /

316

Page 56: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Skriv vem användarna ska kontakta för att lämna synpunkter påwebbplatsen, och hur de ska göra.

Andra relevanta riktlinjer

Ange vilken organisation som är avsändare av webbplatsen (R22)Gör det lätt att komma i kontakt med er (R4)

Exempel

Riksarkivets sida ”Om webbplatsen”.

Samlingssidan Om webbplatsen bör finnas tillgänglig från alla sidor på webbplatsen. Lägggärna länken i sidfoten. Exemplet i bilden kommer från Konsumentverket.

Mätbarhet

Kontrollera att sidan ”Om webbplatsen” finns och stäm av den motpunkterna ovan.

Senast uppdaterad: 2018-04-10

Prio 2

Informera om hur personuppgifter,kakor (cookies) mm hanterasDet finns lagar som reglerar vad du som ansvarig för en webbplats ärskyldig att informera besökarna om. Bland annat ska du upplysa om hurpersonuppgifter och kakor hanteras på webbplatsen.

Om denna riktlinjePrioritet: 2Principer: FörtroendeingivandeRoller/arbetsuppgifter:När i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Systemutveckling

Rekommendationer för kakor, dataskydd medmera

Informera om vilka delar av webbplatsen som använder kakor (Lag(2003:389) om elektronisk kommunikation).

Riktlinje nr 20

Vägledning förWebbutveckling Sida 55 /

316

Page 57: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se till att få besökarens samtycke till att du använder kakor.Följ dataskyddsregleringen.

Informera också om

hur elektroniska anslagstavlor används, till exempel chatt ellerdiskussionsforum (Lag (1998:112) om ansvar för elektroniskkommunikation).myndigheten har utgivningsbevis, ger ut periodiska skrifter ellerradioprogram.vilka bestämmelser som är tillämpliga på verksamheten, ombesökaren kan sluta avtal, eller beställa varor eller tjänster påwebbplatsen. (lag 2002:562) om elektronisk handel och andrainformationssamhällets tjänster.

Beskriv hur kakor används på webbplatsenMer utförlig vägledning om kakor och liknande teknik finns i vår artikelKaklagen i praktiken.

Alla som besöker en webbplats eller utnyttjar en tjänst som använder kakormåste få tillgång till information om att kakor används och ändamålet medanvändningen av dem (Lag (2003:389) om elektronisk kommunikation). Allasom besöker en webbplats med kakor ska få information om attwebbplatsen innehåller kakor, vem eller vilka som information utbyts medoch ändamålet med användningen av kakorna. Presentera detta ianslutning till informationen eller tjänsten, så att användaren kan se dettainnan tjänsten börjar användas.

Se till att få besökarens samtycke till att du använder kakorSom webbplatsägare måste du se till att besökaren samtycker till att duanvänder kakor. Som huvudregel gäller att du måste få besökarenssamtycke innan kakor lagras i webbläsaren eller hämtas från webbplatsen.

Reglerna gäller inte bara för vanliga kakor utan även för annan jämförbarteknik som till exempel Flash-kakor och html5 local storage. Europeiskadataskyddsmyndigheter m.fl. rekommenderar att även så kallade digitalafingeravtryck (fingerprinting) hanteras på samma sätt.

Samtycket ska vara individuellt, frivilligt och särskilt. Kravet på att samtycketska vara särskilt innebär att ett generellt samtycke till behandling avuppgifter inte kan godtas. Samtycket ska gälla behandling för ett eller flerapreciserade ändamål. Det krävs därför specifik information om den tänktaanvändningen av kakor.

Det finns inte en teknisk lösning och inte heller en standardtext för attinformera om eller hämta in samtycke som passar alla. Det är upp till digsom webbplatsägare att i varje enskilt fall bedöma vad som fungerar förwebbplatsen och era användare.

Det finns två undantag från kravet på samtycke. Det ena är när hanteringen

Vägledning förWebbutveckling Sida 56 /

316

Page 58: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

är nödvändig för att det ska vara möjligt att tillhandahålla den funktion somanvändaren uttryckligen begär. Till exempel går det inte att ”lägga en vara ikorgen” i en webbutik om inte servern och webbläsaren lagrar och hämtardenna information om varukorgen med hjälp av kakor eller liknande teknik.Det andra undantaget är när kakor behövs ”för att överföra ett elektronisktmeddelande via ett elektroniskt kommunikationsnät”. Det kan till exempelröra sig om funktioner för lastbalansering eller likande teknik.

Följ dataskyddsregleringenOm du behandlar personuppgifter behöver du följa dataskyddsregleringen.Det kan till exempel innebära att användare behöver informeras om sinarättigheter och samtycka till behandlingen innan den får inledas. Läs merom dataskyddsförordningen hos Datainspektionen.

FördjupningMer utförlig vägledning om kakor och liknande teknik finns i vår artikelKaklagen i praktiken.Lag (2003:389) om elektronisk kommunikation (6 kap. 18§ kallasinformellt för ”kaklagen”.)Lag (1998:112) om ansvar för elektroniska anslagstavlor.Lag (2002:562) om elektronisk handel och andrainformationssamhällets tjänster.Läs mer om dataskyddsreformen hos Datainspektionen

MätbarhetSätts kakor när någon besöker din webbplats?Har besökaren möjlighet att ge ett informerat samtycke?Finns sidan ”Om webbplatsen”, ”Om kakor (cookies)” ellermotsvarande?

Terminologi

Digitala fingeravtryck (fingerprinting) är en metod för att med relativt godsäkerhet känna igen en besökare på en webbplats. Metoden baseras på attwebbläsaren lämnar ett stort antal tekniska detaljer (skärmstorlek,webbläsarversion med mera) varje gång en webbsida eller annan resurshämtas från en server. I och med att mängden detaljer är stor blir det oftast(men inte riktigt alltid) en unik uppsättning information för varje besökare.Därmed kan servern känna igen en besökare, vilket ger nästan sammamöjligheter som kakor.

Kakor kallas ibland webbkakor eller http-kakor (http cookies). Regleringenkring kakor har sin bakgrund i EU-direktivet 2009/136/EG, som är enändring av ePrivacy directive.

Dataskyddsförordningen bygger på en EU-förordning som kallas GDPR(General Data Protection Regulation). Tidigare gällde personuppgiftslagen(PUL) på detta område.

Vägledning förWebbutveckling Sida 57 /

316

Page 59: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-06-27

PrioInaktiv

Riktlinjen hopslagen med R4Riktlinjen som tidigare hade nr 21 är nu en del av Gör det lätt att komma ikontakt med er (R21).

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Senast uppdaterad: 2018-02-15

Prio 5

Ange vilken organisation som äravsändare av webbplatsenInformera om vilken organisation som står bakom webbplatsen och vemsom har ansvar för den. Placera informationen i sidfoten eller sidhuvudet såatt den är åtkomlig från alla sidor.

Om denna riktlinjePrioritet: 5Principer: Användbar, FörtroendeingivandeRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer om avsändarinformationFör att en användare ska känna sig trygg med en webbplats är detviktigt att visa vem som är avsändare.Placera informationen i sidfoten eller i sidhuvudet somkontaktinformation.Komplettera er logotyp med en alt-text som innehåller namnet på erorganisation.

Ange ocksåorganisationens namn, i sidans titel och metadatavilken organisation som är avsändare av webbplatsen, iutskriftsversionen och i alla nedladdningsbara dokument.

Riktlinje nr 21

Riktlinje nr 22

Vägledning förWebbutveckling Sida 58 /

316

Page 60: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Relaterade riktlinjerGör det lätt att kontakta er (R4)Beskriv hur webbplatsen fungerar och vad den innehåller (R22)

Exempel på avsändare i sidfoten

Göteborgs Stad anger i sidfoten vem som är avsändare av sidan. I närhetenplaceras även med fördel annan kontaktinformation.

Senast uppdaterad: 2018-04-10

Prio 2

Ange när webbsidorna har publiceratseller uppdateratsGör det tydligt hur pass aktuell informationen på webbplatsen är genom attange ett datum på sidan. I vissa fall är det också relevant att ange ettklockslag.

Om denna riktlinjePrioritet: 2Principer: Användbar, Förtroendeingivande, Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Bevarande och gallringNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign

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

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

Riktlinje nr 23

Vägledning förWebbutveckling Sida 59 /

316

Page 61: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Undantag

Följande sidor behöver inte ha datum:

Sidor vars huvudsyfte inte är att förmedla information, till exempelformulär eller steg i en webbapplikation.Sidor där sidans delar redan anger tidpunkter, till exempel löpsedlar,nyhetsarkiv och nyhetssidor.

Exempel

Fördjupning

Se även R24. Ange tydligt om viss information är inaktuell.

Senast uppdaterad: 2017-11-05

Prio 1

Ange tydligt om viss information ärinaktuellGör det tydligt för användarna om det finns innehåll på webbplatsen sominte längre är giltigt. Ett exempel är om ni i referenssyfte har kvar tidigareriktlinjer eller juridisk information, som har blivit ersatta av nyare material.

Om denna riktlinjePrioritet: 1Principer: Användbar, FörtroendeingivandeRoller/arbetsuppgifter: Bevarande och gallring, Skriva texterNär i utvecklingsprocessen?: Förvaltning, Informationssäkerhet,Innehållsproduktion

Rekommendationer för inaktuell informationGör en hänvisning till mer aktuell information om det finns.Använd inte enbart bild eller färg för att förmedla att informationeninaktuell. Det måste vara tydligt även i texten. Placera informationen

Riktlinje nr 24

Vägledning förWebbutveckling Sida 60 /

316

Page 62: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

tidigt i materialet och högt upp på sidan.Säkerställ att er webbserver och ert publiceringsverktyg är korrektkonfigurerade så att de levererar rätt cache-instruktioner, för attminska risken att inaktuella versioner presenteras för användare. SeR54. Optimera webbplatsen för bästa prestanda.Låt användarna själva välja om de vill få upp träffar även på inaktuelltmaterial när de söker efter något på webbplatsen. Informera direkt isökresultatet om någon träffpost är inaktuell.

Exempel på hur inaktuell information visas

Skatteverket talar, på olika sätt, i sin Rättsliga vägledning att informationenändrats, se bild ovan.

Bilden ovan visar hur Halmstad kommun signalerar om att en nyhet kan

Vägledning förWebbutveckling Sida 61 /

316

Page 63: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

vara inaktuell genom att tydligt skriva ut det ovanför nyhetens rubrik.

Tullverket markerar med röd text att en författning har upphört, se ovan.

Standardiserad uppmärkning av inaktuellinformationMed HTML5 kan du med standardiserad uppmärkning (elementen s och del)ange att text är inaktuell. I och med att det finns standardelement så är detbättre att använda dessa än enbart en css-klass för att märka upp inaktuelltext, men kom ihåg att det är viktigt att informationens status framgår även ipresentationen. Båda elementen visas som genomstruken text om du intemed hjälp av css förändrar presentationen.

Innehåll som inte är aktuellt men ändå viktigt att presentera, till exempelordinarie pris vid rea, kan märkas upp med elementet s:

Ordinarie pris: <s>30kr</s>

Ordinarie pris: 30kr

Innehåll som redigerats bort, vilket behöver kommuniceras, kan märkas uppmed elementet del. Till exempel i ny version av lagförslag:

Gäller för företag <del datetime="2018-05-01"

cite="https://data.riksdagen.se/fil/800D4385-047B-

4261-9D69-27E1742CF18B">med minst 10 anställda</del>.

Gäller för företag med minst 10 anställda.

Attributet datetime är frivilligt och anger förstås när redigeringen skedde.Attributet cite kan användas för att hänvisa till dokumentation avförändringen.

Läs mer i html5doctors artikel om element för uppmärkning av förändringar.

Mätbarhet

Utvärdera med hjälp av användningstester om besökarna uppfattar vad somär inaktuell information och vad som inte är det.

Vägledning förWebbutveckling Sida 62 /

316

Page 64: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Fördjupning

Se även R23. Ange när webbsidorna har publicerats eller uppdaterats.

Terminologi

För föråldrad och inte längre giltig information används ibland ordet obsolet.På engelska förekommer ofta ordet ”expired” som motsvarar utgångetdatum.

Senast uppdaterad: 2018-11-28

Prio 3

Förvaltningsorganisationen och desskunskap ska stå i proportion tillwebbplatsens storlek och ambitionerSe till att ni har den tid och kunskap som krävs för att planera och samordnaförvaltningen av webbplatsen. Det är en förutsättning för att det publiceradematerialet ska kunna hålla en hög nivå av användbarhet och tillgänglighet.

Om denna riktlinjePrioritet: 3Principer: Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Inköpare och beställareNär i utvecklingsprocessen?: Förvaltning, Process

RekommendationerAvsätt resurser för att hålla en hög och god kvalitet på förvaltningen avwebbplatsen. De som ska förvalta webbplatsen behöver ha rättkunskap och kompetens redaktionellt, pedagogiskt och tekniskt.Ta fram en uppdateringsplan där ansvaret är tydligt fördelat.

Kompetenser i en förvaltningsorganisationDet krävs en mängd kompetenser i en förvaltningsorganisation för att hållaen löpande hög nivå på redaktionellt material, interaktionsdesign ochfunktioner. Man behöver även försäkra sig om att webbplatsen håller godkvalitet vad gäller användbarhet och tillgänglighet.

En förvaltningsorganisation behöver ha kunskap om bland annat

användningsmönster och beteenden på webbenanvändbarhet och tillgänglighethtml och databaser

Riktlinje nr 25

Vägledning förWebbutveckling Sida 63 /

316

Page 65: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

informationsstruktureringdokument och dokumentformatkompletterande kanalerarkivering och gallring (gäller framför allt myndigheter).innehållet på webbriktlinjer.se

Vidare krävs normalt specifik redaktionell kompetens för webb, inomexempelvis

journalistisk nyhetsvärderingeffektiv rubriksättningtillgängliga länkarhantering av bilderformatering och övrig informationshantering, så att webbplatsen ärtillgänglig för alla grupper.

Senast uppdaterad: 2014-11-01

Prio 2

Uppdatera webbplatsens innehåll ochlänkar regelbundetSkapa tydliga rutiner för hur innehållet på webbplatsen ska uppdateras ochgallras. Se till att borttagna sidor inte längre indexeras av sökmotorerna.

Om denna riktlinjePrioritet: 2Principer: Användbar, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: Bevarande och gallring, Skriva texterNär i utvecklingsprocessen?: Förvaltning, Informationssäkerhet,Innehållsproduktion

Rekommendationer att uppdatera innehållSkapa rutiner för hur innehållet ska granskas och uppdateras medjämna mellanrum. De flesta webbpubliceringsverktyg har inbyggdafunktioner för att påminna om när det är dags att granska en sida.Skapa rutiner för att granska och uppdatera sidor på lättläst svenska,nationella minoritetsspråk och på andra språk. Det gäller ocksåteckenspråksfilmer eller annan information i form av ljud, bild och film.Dessa sidor kan utformas så att de får längre hållbarhet än övrigatexter, som kanske uppdateras oftare. Vissa webbpubliceringsverktyghar funktioner för att hantera flerspråkig information parallellt vilketunderlättar uppdateringen av sidor på olika språk.Se till att borttagna sidor genererar en korrekt svarskod, det vill säga404 (Not found), så att sökmotorerna tar bort dem ur sökresultatet.

Riktlinje nr 26

Vägledning förWebbutveckling Sida 64 /

316

Page 66: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Andra kanalerMånga organisationer finns representerade även på andra ställen påinternet än på den egna webbplatsen, till exempel i sociala medier. Ta framrutiner för att hålla även denna information uppdaterad. Se Riktlinjer försociala medier från E-samverkansprogrammet.

Om myndigheters gallringsbeslut

Myndigheter måste ha ett gallringsbeslut för att kunna plocka bortexempelvis olämplig information. Ta fram manuella eller inbyggda rutiner såatt ingen information gallras utan ett gallringsbeslut. Se vidare R47. Undvikoavsiktlig gallring vid ändringar och uppdateringar. Var tydlig i era riktlinjerför gallring med att olika regler gäller för hur olika typer av informationen skahanteras efter att den avpublicerats.

FördjupningOm du byter namn eller flyttar på sidor, se även Låt inte enwebbadress sluta fungera (R56).Glöm inte bort att uppdatera datum när du granskat eller uppdateraten sida. Se Ange när webbsidorna har publicerats eller uppdaterats(R23).Glöm inte att Ange tydligt om viss information är inaktuell (R24) omden ska ligga kvar på sajten ändå.

Terminologi

Att en webbsida indexeras av en sökmotor betyder att ett program (oftakallat sökrobot) hämtar sidan och lägger in adressen till sidan på relevantaställen i sökmotorns index (register). Ett index är en tabell som kananvändas för att snabbt hitta adresser (referenser) till sidor som berör t.ex.ett visst nyckelord. Sökmotorerna brukar återkomma regelbundet till sidor isina index för att undersöka om sidorna har förändrats eller försvunnit, och iså fall uppdateras index.

En svarskod kallas även response code eller http status code och är enstandardiserad sifferkod som en webbserver skickar till en webbläsare föratt sammanfatta resultatet av en förfrågan. ”404 Not found” kanske är denmest kända av alla svarskoder som W3C definierat, eftersom den brukarvisas för användare när en länk pekar fel. Den vanligaste statuskoden ärförhoppningsvis ”200 OK”, men eftersom den indikerar att allt gick bra såvisas den sällan för användaren.

Senast uppdaterad: 2017-10-30

Prio 3

Riktlinje nr 27

Vägledning förWebbutveckling Sida 65 /

316

Page 67: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Visa tydligt var användaren befinnersigAnvändarna behöver hjälp att förstå var på webbplatsen de befinner sig.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign

Rekommendationer som hjälper användaren attorientera sig

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

Låt menyer och navigation ange var användarenbefinner sigNär en webbplats är lätt att hitta på och navigeringen är tydlig, enkel ochsmidig kommer användarna uppleva hela webbplatsen som mer användbar.För att navigering ska bli användbar och tillgänglig behöver de olikanavigationsnivåerna vara begripliga för användarna.

Använd ord som är naturliga för användarna när du formulerar rubriker ochlänkar. Använd samma ord i menyn eller länktexten och på sidananvändaren kommer till efter att ha klickat på länken. Se Skriv beskrivandesidtitlar (R135).

Markera i menyn vilken menyingång användaren har valt. Ett sätt att göradetta är att använda fetstil.

Länka inte det menyalternativ som leder till sidan där användaren redanbefinner sig.

Skapa en visuellt tydlig navigering genom indrag eller markeringar i färg,form eller kontrast, men använd inte enbart färg och inte enbart andrasensoriska kännetecken eftersom vissa användare inte kan uppfatta sådant.

För tillgänglighetens skull, använd en korrekt html-kod förnavigationselement, till exempel genom att

det syns i koden att menyvalet är aktivtanvända punktlistor för att bygga navigeringsnivåernaanvända elementet <nav> för att markera att det är en navigation(gäller vid HTML5).

Vägledning förWebbutveckling Sida 66 /

316

Page 68: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Givetvis behöver navigationen även följa övriga riktlinjer om tillgänglighet.Se särskilt Erbjud besökaren alternativa orienteringsstöd (R32).

Underlätta navigeringen med länkstigarLänkstigar, eller så kallade brödsmulor, kan användas för att göra det extratydligt var i strukturen användaren befinner sig.De brukar placeras direkt ovanför huvudinnehållet och visar den synligasökvägen ner genom den hierarkiska strukturen. Länkstigar används ofta avanvändarna för att navigera uppåt i strukturen. De ger också en överblick avi vilket sammanhang innehållet befinner sig.

Inled alltid länkstigen med en länk till startsidan. Detta första led kan avutrymmesskäl kallas ”Start”.Avsluta länkstigen med namnet på den sida användaren befinner sig på.Den aktuella sidan ska inte vara länkad, däremot ska de föregåendenivåerna i länkstigen vara det. Undvik att förkorta posterna i länkstigen omden blir lång. Då kan det bli svårt att förstå var man befinner sig. Radbrythellre länkstigen.

Länkstigar i e-tjänsterSträva efter att länkstigar fungerar även inne i tjänster. Om innehållet är sådynamiskt att länkstigar inte tillför något kan ni välja att låta stigen sluta vidingångssidan till tjänsten och då se likadan ut för alla sidor i tjänsten.

Exempel på navigering och brödsmulor

Brödsmulor, eller länkstigar, gör det tydligt var användaren befinner sig påwebbplatsen. Brödsmulor är ett bra komplement för att kunna se innehålletsstruktur och snabbt navigera till överliggande sektioner. Exemplet ovan ärfrån Migrationsverket.

Exemplet från Strängnäs visar hur både brödsmulestigen och sökvägen isidans webbadress kan användas för att förtydliga sidans sammanhang.Läs mer om webbadressers struktur i Utforma webbadresser med omsorg(R100).

Relaterade riktlinjer

Erbjud besökaren flera olika sätt att navigera (R32)Visa var i en process användaren befinner sig (R63)

MätbarhetUtvärdera navigeringen med hjälp av användningstester.

Vägledning förWebbutveckling Sida 67 /

316

Page 69: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TerminologiSökstigar, länkstigar, brödsmulor och brödsmulestigar är olika uttryck somsyftar på samma sak. På engelska kallas de ”bread crumbs” eller ”breadcrumb trails”. Uttrycket är hämtat från sagan om Hans och Greta, som la utbrödsmulor längs stigen för att kunna hitta hem igen.

Landningssidor, genomgångssidor, ingångssidor ochstartsidorEn landningssida är en webbsida som är uppbyggd speciellt för en kampanjeller för att få en användare att göra något speciellt. På en landningssidapresenterar man ett specifikt erbjudande och försöker få besökaren attkonvertera, det vill säga göra det som krävs för att nå webbplatsenseffektmål, vilket kan vara allt ifrån att beställa en produkt till att bli medlem ien klubb.

En genomgångssidas främsta uppgift är att bekräfta att användaren är pårätt väg ner i strukturen. Det gör att information om vad som INTE finns påunderliggande sidor också kan vara värdefull där.

Datatermgruppen definierar ingångssida som webbplatsens förstasida(startsidan). I webbanalys-sammanhang brukar man dock prata omingångssidor när man menar de webbsidor som användarna först hamnarpå när de går in på webbplatsen, vilket kan vara precis vilken sida somhelst, till exempel när en användare kommer via en sökträff i en sökmotor.

På engelska brukar termerna landing page eller lead capture pageanvändas. Ibland skiljer man även på reference landing page som enbartinnehåller väsentlig information som text och bilder, och transactionallanding pages som oftast innehåller ett formulär som besökarna ska fylla iför att slutföra konverteringen.

Senast uppdaterad: 2018-10-31

Prio 3

Gör det lätt att hitta det viktigasteGör det lätt för användarna att hitta rätt på webbplatsen. Utgå från derasbehov och perspektiv när ni strukturerar information och skriver rubriker,länkar och menyer.

Om denna riktlinjePrioritet: 3Principer: AnvändbarRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Målgruppsanalys, Process

Riktlinje nr 28

Vägledning förWebbutveckling Sida 68 /

316

Page 70: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

RekommendationerTa reda på vad på webbplatsen som är viktigast för användarna, ochvilka 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 ärlogiskt för användarna. Använd ord som besökarna är bekanta med imenyer, 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 iR32. Erbjud besökaren alternativa orienteringsstöd.

Effektkartläggning, customer carewords ochkortsorteringEffektkartläggning och customer carewords är två etablerade metoder somanvänds för att ta reda på vad en webbplats behöver kunna hjälpaanvändarna med. Inom båda dessa metoder används kortsortering för att tareda hur användarna vill ha informationen sorterad.

I en effektkartläggning fokuserar man på vilken effekt webbplatsen skauppnå, såväl internt i organisationen som externt för användarna.Användarna delas upp i målgrupper, och varje målgrupp representeras aven så kallad persona. En persona är en fiktiv användare som skapas utifrånkunskap om faktiska användare med hjälp av intervjuer, besöksstatistik ochsökord. Varje personas behov blir det som webbplatsen måste erbjuda föratt den avsedda effekten ska uppnås. Varje beslut under utvecklingen kansedan stämmas av mot de personor och behov man tagit fram ieffektkartläggningen.

Customer carewords är en metod som fokuserar på individens behov ochden konkreta användningen av en webbplats. Man samlar in och analyserarfakta från olika datakällor, som intervjuer, enkäter, besöksstatistik, sökordoch jämförelser med andra webbplatser. Analysen ger grunden för vilkabehov webbplatsen ska uppfylla. Användarna får själva bestämma vilkabehov som är viktigast, och utifrån statistiska samband får webbplatsägarenbeslutsunderlag till vad som behöver utvecklas, vilket innehåll som måstefinnas och hur enkelt det ska vara att hitta det.

Kortsortering är en metod för att undersöka hur användare grupperarinnehåll för olika typer av it-system. Metoden används ofta för externawebbplatser, men fungerar lika bra för intranät. Vid en kortsortering fårrepresentanter för målgrupperna gruppera ett antal innehållskort efter hur detycker att informationen hör ihop. Därefter ber man deltagarna att sättarubriker på de olika grupperna med kort och eventuellt dela in dem iundergrupper. Resultatet från kortsorteringen används som stöd för attskapa webbplatsens informationsstruktur och organisera innehållet imenyerna.

Vägledning förWebbutveckling Sida 69 /

316

Page 71: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

MätbarhetUtvärdera informationsstrukturen med representanter från deanvändargrupper som webbplatsen vänder sig till.Ge testarna konkreta uppgifter som ska slutföras.Kortsortering går att genomföra online.

ExempelPå Arbetsförmedlingens startsida kan du söka efter lediga jobb direkt. Dettaär vad de flesta som besöker webbplatsen vill göra, och därför liggerfunktionen så centralt placerad.

Startsidan hos Försäkringskassan har tydliga ingångar för det som är viktigt för användarna.

Under varje enskild huvudingång på Avesta kommuns webbplats finns detmest populära innehållet som tydliga genvägar till innehåll längre ned istrukturen.

Dela utveckling och lösningar

Sök på informationsstruktur på Deladigitalt.se (kräver konto, som du som

Vägledning förWebbutveckling Sida 70 /

316

Page 72: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

arbetar inom offentlig sektor kan få).

FördjupningTidningen Boxes and Arrows artikel om kortsortering (på engelska).Mer om customer carewords (på engelska).Optimal workshop har ett online-verktyg för att utföra kortsorteringar,testa en hierarkisk struktur och utföra enklare tester avinteraktionsdesign.Se även R51. Lyft fram det viktigaste i textenSe även R112. Ge ordförslag vid sökning och inmatning

Senast uppdaterad: 2017-12-29

Prio 1

Var konsekvent i navigation, strukturoch utformningKonsekvens är mycket viktigt för att användarna ska förstå hur webbplatsenfungerar. Det betyder inte att alla sidor måste se likadana ut, men liknandeuppgifter ska utföras på samma sätt oavsett var på webbplatsen manbefinner sig.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning

Konsekvens är viktigt för att användarna ska förstå hur webbplatsenfungerar. Det betyder inte att alla sidor måste se likadana ut, men liknandeuppgifter ska utföras på samma sätt oavsett var på webbplatsen manbefinner sig.

Vissa blinda användare memorerar strukturen på en webbplats, och om denförändras mellan sidorna blir det besvärligt för dessa användare, liksom förpersoner med vissa kognitiva funktionsnedsättningar.

Rekommendationer för konsekvent navigeringLåt gränssnittselement ha samma utseende, funktionalitet ochplacering på hela webbplatsen.

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

Riktlinje nr 29

Vägledning förWebbutveckling Sida 71 /

316

Page 73: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Som gränssnittselement räknas till exempel menyer, sidhuvud, sidfot,knappar och andra kontroller.

Om webbplatsens layout är konsekvent kan färgerna skilja sig mellanavdelningarna utan att påverka enhetligheten, så länge de enskildaelementen beter sig likadant och återfinns på samma ställe.

Ibland passar inte innehållet på en viss webbsida in i den generellautformningen. Gör avsteg om de är motiverade utifrån användningen ochsyftet med sidan.

Undvik att placera viktigt innehåll långt till höger på innehållssidor. Mångaanvändare missar information som ligger där eftersom det är en vanlig platsför reklam.

Utdrag från WCAG-standarden

Riktlinje 3.2 Förutsägbart: Säkerställ att webbsidor presenterasoch fungerar på ett förutsägbart sätt.

3.2.3 Konsekvent navigering: Navigeringsmetoder/funktionersom upprepas på flera webbsidor inom en uppsättning avwebbsidor presenteras i samma inbördes ordning varje gång deupprepas, om inte användaren initierar en ändring. (Nivå AA)

Relaterade riktlinjerR34. Gör länkar, klickbara ytor och menyer användbara för alla,särskilt avsnittet om utformning av länkar i menyer.R146. Benämn funktioner konsekvent

Mätbarhet

Utvärdera om webbplatsen upplevs som konsekvent medanvändningstester.

Senast uppdaterad: 2018-12-05

Prio 4

Använd startsidan för att ge enintroduktion till webbplatsenStartsidan används ofta av besökare som inte är bekanta med webbplatsenoch som inte vet så mycket om hur organisationen är uppbyggd. Den ärockså en naturlig plats att återvända till om användarna gått vilse istrukturen. Se startsidan som en innehållsdeklaration, där de osäkraanvändarna får hjälp att hitta det de söker.

Riktlinje nr 30

Vägledning förWebbutveckling Sida 72 /

316

Page 74: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 4Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning

Rekommendationer för innehållet på startsidan

Använd webbplatsen startsida för att

visa vilken organisation som är avsändarevägleda användarna till webbplatsens olika delarlyfta de uppgifter som är viktigast för användarna, så att de går att hittaså enkelt som möjligt.

Utformning av startsidanUtforma startsidan utifrån vad era prioriterade användare letar efter, snarareän att utgå från era interna indelningar eller behov. Det är vanligt att det blir”krig om startsidan” mellan olika delar av organisationen som vill synas väl.Utgå i stället från besöksstatistik, användningstester och enkäter, och väljfokus på startsidan utifrån fakta i stället för interna åsikter.

Använd inte animeringar och onödiga introduktionssidor som visas innananvändarna kommer till webbplatsens startsida. De upplevs ofta som etthinder för det användarna vill göra.

Landningssidor

På kommersiella webbplatser är det vanligt att man skapar skräddarsydda”startsidor” för vissa typer av besök – så kallade landningssidor. Ofta harman till exempel en landningssida som matchar en annonskampanj, så attde som lockas av annonsen hamnar på en sida som tar upp precis sammatema som annonsen. Därigenom hoppas man öka chansen att besöketleder till konvertering, alltså att besökaren genomför det som annonsensyftade till (till exempel köper en produkt, blir medlem, blir prenumerant ellerhelt enkelt tar del av viss information).

Mätbarhet

Låt användare testa olika versioner av startsidan i så kallade A/B-tester, ochavgör genom användningstester, enkäter eller webbstatistik vilken versionsom fungerar bäst.

FördjupningSe även R28. Gör det lätt att hitta det viktigaste och R31. Alla sidor ska ha

Vägledning förWebbutveckling Sida 73 /

316

Page 75: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

länkar till startsidan och andra sidor som är viktiga för orienteringen.

Mer om A/B-testning.

Terminologi

A/B-testning kallas ibland split test. När effekten av flera olika variabler skastuderas kan man använda det engelska begreppet multivariate testing.Landningssidor heter landing page på engelska.

Senast uppdaterad: 2014-08-29

Prio 4

Länka alla sidor till startsidanDet går inte att förutse på vilken webbsida användarna börjar sina besök,eller när de behöver hjälp för att leta vidare. Se därför till att alla sidor påwebbplatsen har länkar till sidor och funktioner som är viktiga förnavigeringen.

Om denna riktlinjePrioritet: 4Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

Rekommendationer för länkar till viktiga sidorSe till att alla sidor har länkar till startsidan och andra sidor som ärviktiga 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 webbplatsenstartsida. Om logotypen är en bild, ange i alt-texten att länken går tillstartsidan.

Relaterad riktlinjeLäs även R30. Använd startsidan för att ge en introduktion till webbplatsen.

Exempel: Boverkets och Konsumentverketsgemensamma webbplats omboende.se

På Boverkets och Konsumentverkets gemensamma webbplatsomboende.se ligger länken till webbplatsens startsida i sidhuvudet. De bådaorganisationernas logotyper ligger länkade till respektive organisation i

Riktlinje nr 31

Vägledning förWebbutveckling Sida 74 /

316

Page 76: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

sidfoten.

På Konsumentverkets webbplats kan användaren gå till startsidangenom att antingen klicka på brödsmulorna som inleds med Start ellerklicka på logotypen som är länkad till startsidan.

Mätbarhet

Testa genom att undersöka ett representativt urval av sidor på webbplatseneller alla sidmallar. Se till att det går att navigera från var och en tillwebbplatsen startsida och till andra sidor som är viktiga för orienteringen.

Senast uppdaterad: 2018-02-12

Prio 1

Erbjud användarna flera olika sätt attnavigeraAnvändare har många olika strategier för att hitta på webbplatser. Erbjuddärför fler sätt att navigera utöver sökfunktionen och den primäranavigeringen/menyn.

Om denna riktlinjePrioritet: 1Principer: Användbar, Effektiv, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

Användare har många olika strategier för att navigera i digitala system. Enperson med synnedsättning kanske föredrar en sökfunktion, medan enperson med en kognitiv funktionsnedsättning föredrar eninnehållsförteckning eller ett alfabetiskt index.Erbjud därför fler sätt att navigera.

Rekommendationer för navigeringErbjud flera olika navigeringsstöd på webbplatsen.

Riktlinje nr 32

Vägledning förWebbutveckling Sida 75 /

316

Page 77: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Utgå från användarnas behov och webbplatsens komplexitet när niväljer navigeringsstöd.Erbjud en sökfunktion.

Exempel på kompletterande navigeringsstödSökfunktion. Förutom webbplatsens menysystem brukar det främstanavigeringsstödet vara en funktion för fritextsökning. Se R112. Geordförslag vid sökning och inmatning för förslag på hur sökfunktionen kangöras tillgänglig och användbar.

Innehållsöversikt (webbplatskarta eller webbkarta) är ett sätt att presenterawebbplatsens hierarkiska struktur, och ge en översiktsbild av hurinformationen är strukturerad. Tänk igenom hur många nivåer nerinnehållsöversikten ska sträcka sig. Den slutar att vara ett stöd föranvändarna om den blir för djup eller för detaljerad. En innehållsöversikt skainte bestå av en enda stor bild, eftersom tekniska hjälpmedel inte kan tolkainnehållet i bilden.

A–Ö-index presenterar ett urval av innehållet i alfabetisk ordning. Det kanvara ett funktionellt och bra sätt att lyfta fram webbplatsens viktigaste delar.För att upprätthålla en god kvalitet på ett A–Ö-index är det oftast bäst attsköta det manuellt. Se till att ha med de ord och uttryck som är naturliga föranvändarna. Synonymer kan visas till exempel så här:

F

<Förskola>

D

Dagis, se <Förskola>

< xxx > visar att det ska vara en länk direkt till sidan som innehållerinformation om det aktuella ordet.

Vanliga frågor och svar. Denna formulering är att föredra framför det vanligtförekommande ”FAQ” som står för frequently asked questions. Många letarefter en sammanställning av frågor och svar, men ha först och främstambitionen att tydligt besvara alla vanliga frågor i huvudmaterialet påwebbplatsen.

Rullgardinsmenyer (”drop down menu” på engelska) används ibland för atterbjuda genvägar till en lista med populära sidor. När användarna aktiverar(klickar på) en stängd rullgardinsmeny fälls de olika snabbvalen ner som omden vore en rullgardin.

Steg-för-steg-guider lotsar användarna genom en uppgift.

Taggmoln med taggar eller etiketter används ofta på webbplatser för attanvändarna ska kunna navigera mellan olika kategorier.

Länkstigar, så kallade brödsmulor (”bread crumbs” på engelska) kan medfördel användas för att visa var användaren befinner sig i en hierarkisk

Vägledning förWebbutveckling Sida 76 /

316

Page 78: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

struktur. Se avsnittet om länkstigar i R27. Hjälp användarna förstå var de ärpå webbplatsen.

ExempelInnehållsöversikt på Upplands-Väsbys kommunwebbplatsA-ö på Naturvårdsverkets webbplats.Patent- och registreringsverket har tydliga länkstigar.Fototjänsten Flickr kan navigeras via populära taggar.Skatteverket har ”Frågor och svar” som alternativ ingång till flera avwebbplatsens avdelningar. Till exempel Vanliga frågor om deklaration.Migrationsverket har en rullgardinsmeny där användarna kan väljaspråk.

Bilden visar Skatteverkets tre olika navigeringssätt: Sökfunktion, huvudnavigering ochlänkstigar/brödsmulor.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.5 Flera olika sätt: Det finns mer är ett sätt att hitta enwebbsida inom en uppsättning av webbsidor, utom närwebbsidan är ett resultat av eller ett steg i en process. (Nivå AA)

Terminologi

Rullgardinsmenyer skapas oftast med html-elementet SELECT. De kallaspå engelska för ”drop-down menu”, ”dropdown list” eller liknande, och påsvenska ibland för valboxmenyer.

Steg-för-steg-guider kan liknas vid en kokbok, som presenterar de momentanvändaren ska genomföra i en viss ordning. De kan också fungera som en”wizard”, som är en sekvens av instruktioner eller frågor där användarnaleds vidare till rätt bild i systemet beroende på vad de svarat. I vissa fall kanman även ledas vidare av systemet med hjälp av en meny som består avpilar, som ligger på en rad efter varandra med text i (så kalladeprocessfiskar).

Taggmoln kommer av engelskans ”tag cloud”. I system som låteranvändarna själva skapa nya taggar (etiketter) utgör den sammanlagdamängden etiketter en sorts folklig taxonomi, och kallas därför folksonomi.Taggmoln har fördelen att de kan rangordnas eller filtreras efter hur vanligt

Vägledning förWebbutveckling Sida 77 /

316

Page 79: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

förekommande taggarna eller termerna är, och därmed anpassasfolksonomin automatiskt när språkbruket eller området förändras. Å andrasidan kan de behöva modereras, eftersom till exempel stavfel ochalternativa böjningsformer kan göra dem stökiga och svåra att överblicka.

Webbplatskarta kallas ibland även för sajtkarta eller på engelska sitemap.

Senast uppdaterad: 2018-12-05

PrioInaktiv

Låt genomgångssidor orienteraanvändarnaRiktlinjen har upphört

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Riktlinjen om genomgångssidor upphör.

Terminologin för genomgångssidor, ingångssidor, landningssidor, startsidormed mera är flyttad till riktlinjen Visa tydligt var användaren befinner sig(R27).

Senast uppdaterad: 2018-03-08

Prio 1

Gör länkar, klickbara ytor och menyeranvändbara för allaKlickbara ytor, till exempel textlänkar, bildobjekt och knappar, spelar enviktig roll på webben. Användarna behöver lätt kunna förstå vad som ärklickbart. Se därför till att markera samma typ av länkar på samma sätt överhela webbplatsen.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Tillgänglighet

Riktlinje nr 33

Riktlinje nr 34

Vägledning förWebbutveckling Sida 78 /

316

Page 80: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När i utvecklingsprocessen?: Interaktionsdesign

Rekommendationer för länkar och klickbara ytorGör de klickbara ytorna tillräckligt stora. Det underlättar föranvändarna.Framhäv länkarna grafiskt så att användarna förstår vad som ärlänkad text.

Gör de klickbara ytorna tillräckligt storaDet är alltid lättare att träffa en stor yta med en muspekare än en liten. Detär dessutom extra viktigt för användare med sämre precision och finmotorikatt klickbara ytor (knappar, ikoner, länkar med mera) är tillräckligt stora.Även de som surfar på mobiltelefoner är hjälpta av att de klickbara ytorna ärstora. Fingrarnas storlek gör det svårt att träffa en liten yta med ett finger.Tänk på detta:

Placera inte länkar för nära varandra.Förstora den klickbara ytan genom att inkludera ett område runt detsom är länkat.Gör en enda länk (ett A-element) av ikon och text i en sammansattlänk.Gör ikoner som är en del av navigeringen klickbara. När dukombinerar text och bildelement i till exempel menyalternativ bör bådetexten och bilden vara klickbar.

Framhäv länkarna grafisktAnvändarna måste enkelt kunna skilja en textlänk från text som inte ärlänkad. Se därför till att länkar skiljer sig grafiskt från övrig text, till exempelgenom understrykning, placering, färg eller storlek.Aktiva länkar kan göras tydligare till exempel genom ändrad bakgrundsfärg.Det hjälper alla användare men framför allt personer som navigerar medtangentbordet.

Oavsett vilket sätt ni väljer för att lyfta länkar grafiskt, tänk på detta:

Ge textlänkar samma färg på hela webbplatsen.Skapa god kontrast mellan länktext och bakgrundsfärg.Använd olika färger för besökta och icke-besökta länkar.

Länkar i listor behöver inte vara understrukna, eftersom det kan göra detsvåra att läsa.

Undantag för länkar i menyerLänkar i menyer behöver inte vara understrukna, så länge användarnaförstår att de är klickbara. Det är inte heller nödvändigt att skilja på besöktaoch icke-besökta länkar i menyer.Användarna ska kunna ändra textstorleken i menyer och andra delar avnavigeringen med hjälp av webbläsarens inbyggda funktioner.

Vägledning förWebbutveckling Sida 79 /

316

Page 81: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Exempel

Fagersta kommun markerar vad som är klickbart i sin huvudnavigeringgenom att den färgade plattan ändrar nyans när användaren förmuspekaren över. Hela plattan är dessutom klickbar, vilket skapar en storklickbar yta.

MätbarhetGör en expertgranskning eller användningstester för att säkerställa attriktlinjen uppfylls.Kontrollera att endast text som är länkad är understruken.

Relaterade riktlinjerR5. Skriv tydliga länkarR140. Markera tydligt vilket fält eller element som är i fokusR106. Stryk aldrig under text som inte är länkad

Senast uppdaterad: 2018-06-29

PrioInaktiv

Se riktlinje 87Se riktlinje 87

Om denna riktlinjePrioritet: InaktivPrinciper: EffektivRoller/arbetsuppgifter:När i utvecklingsprocessen?:

Rekommendationer för prenumerationerErbjud åtminstone ett sätt att prenumerera på innehåll frånwebbplatsen.Utgå från vilken typ av innehåll som är mest intressant föranvändarna.

Ta reda på vilken typ av innehåll som är mest intressant för användarna

Riktlinje nr 35

Vägledning förWebbutveckling Sida 80 /

316

Page 82: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

genom en behovsanalys. Det mest intressanta innehållet är även relevantför en prenumerationstjänst. Erbjud användarna åtminstone ett sätt attprenumerera, men eftersom olika användare föredrar olika verktyg ochkanaler, är det bättre ju fler alternativ ni erbjuder.

Se även R89. Gör det möjligt för andra att återanvända webbplatsensinnehåll.

ExempelStaffanstorps kommun erbjuder prenumeration via RSS.På goteborg.se kan besökare välja mellan att prenumerera på aktuellahändelser i Göteborg eller på stadens pressmeddelanden via RSS.Göteborgs stad erbjuder e-postprenumeration på nämndhandlingar.Regeringskansliet erbjuder flera olika sätt att prenumerera, inommånga olika områden.

FördjupningW3C:s valideringsverktyg för RSS-format

Terminologi

I ett RSS-flöde (även RSS-kanal eller RSS-fil) presenteras informationensom en XML-fil. Alternativt används engelskans motsvarigheter, RSS feed,RSS stream eller RSS channel. RSS står för Really Simple Syndication.Förutom RSS används ibland även formatet Atom, som är snarlikt.

Senast uppdaterad: 2014-10-31

PrioInaktiv

Kontrollera besöksstatistiken ochsökbeteendet regelbundetJu mer ni vet om era användares beteende, desto lättare kan ni anpassainnehållet till deras behov. Kontrollera vilka delar av webbplatsen sombesöks mest respektive minst, och hur webbplatsens sökfunktion används.

Om denna riktlinjePrioritet: InaktivPrinciper: EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion, Process,Utvärdering

Rekommendationer om besöksstatistik

Riktlinje nr 36

Vägledning förWebbutveckling Sida 81 /

316

Page 83: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Samla in och analysera webbstatistiken löpande, för att få en bättreförståelse för era användare och hur de rör sig på webbplatsen.Använd statistik och webbanalys som underlag för att förbättra ochanpassa webbplatsen efter användarnas behov.Se till att den mest eftersökta informationen är enkel att nå.Kom ihåg att informera om och inhämta samtycke om kakor användsför webbanalysen.

Analysera statistikenMed hjälp av användningsstatistik går det att se bland annat:

Hur användarna rör sig. Detta kan underlätta förståelse av hurwebbplatsen används i praktiken.Vilka sökord användarna matar in i sökfunktionen. Det ger informationom vad de förväntar sig att hitta på webbplatsen och vilka ord deföredrar att använda. Använd samma ord och uttryck i menyer ochövriga texter.Hur stor genomslagskraft olika aktiviteter har, till exempel kampanjereller utbildningar.Vilka ord användarna har sökt på i externa sökmotorer innan de hittattill webbplatsen, och vilka relaterade termer som är vanliga sökord.Det senare hittar du till exempel med hjälp av verktyget GoogleTrends. Det ger dig större möjlighet att låta fler nyckelord ge sökträff.

Redovisa separat eller räkna bort ur statistiken de besök som görs från eregen organisation och från sökmotorernas robotar. Robotar utgör ibland enbetydande andel av trafiken.

Relaterade riktlinjer R20. Informera om hur personuppgifter, kakor (cookies) mm hanteras R37. Följ upp hur webbplatsen används

Mätbarhet

Ni kan använda olika analysverktyg för att få fram hypoteser om hurwebbplatsen används. Det går aldrig med säkerhet att säga hur mångabesökare en webbsida har. Däremot går det att slå fast om antalet ökar ellerminskar, var användarna har varit före besöken och vart de tar vägenefteråt, hur långa besöken varit och så vidare.

Olika verktyg för statistikanalys använder olika metoder för att samla in data.Data från två olika verktyg kan därför skilja sig ganska mycket frånvarandra. Besöksstatistik innehåller dessutom många felkällor. Koncentreradig därför inte så mycket på absoluta tal i dessa sammanhang. Fokuseraistället på trender, tendenser och mönster.

Det är viktigt att komma ihåg att en analys alltid är byggd på teorier.Besökarnas faktiska beteende mäts bättre genom andra metoder, som

Vägledning förWebbutveckling Sida 82 /

316

Page 84: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

observationer, djupintervjuer och A/B-tester.

Terminologi

Inom webbanalys och sökmotoroptimering, engelskans web analytics ochsearch engine optimization, finns en mängd termer som kan vara värda attnämnas.

Termen SEO, search engine optimization, används ofta även på svenska försökmotoroptimering eller sökoptimering, både när man pratar om analys avden externa söktrafiken till webbplatsen, och inom webbplatsen – så kalladintern sökanalys.

När man pratar om att mäta kampanjer, flöden eller händelsekedjor påwebbplatser brukar man använda termerna funnel, sales funnel eller tratt påsvenska när man mäter en tänkt exakt väg som användarna bör gå på sinväg mot konverteringen. Man lägger in den tänkta vägen i statistikverktygetsfunnel och kan sedan se var på vägen flest besökare lämnar webbplatseneller hoppar av flödet för att analysera vilka sidor som behöver förbättras.

Multivariabla tester (multivariate testing) och A/B-tester är tekniker förjämföra olika varianter av ett flöde med varandra. A/B-tester är antagligenden vanligaste metoden för webbplatser, och innebär att man testar tvåolika varianter av en sida för att se vilken av sidorna som bäst fungerar bästför användarna.

I statistiken är multivariata tester eller multivariabeltester en teknik för atttesta hypoteser om komplexa flervariabelsystem. Den används särskilt närman vill testa marknadens uppfattning.

Senast uppdaterad: 2018-05-22

PrioInaktiv

Följ upp hur webbplatsen användsEn förutsättning för att upprätthålla en bra webbplats med hög kvalité påfunktionalitet och innehåll är att löpande följa upp och utvärdera hur denanvänds. Några vanliga metoder för uppföljning är användningstester,expertutvärderingar, trafik- och sökordsanalys.

Om denna riktlinjePrioritet: InaktivPrinciper: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Process, Utvärdering

Riktlinje nr 37

Vägledning förWebbutveckling Sida 83 /

316

Page 85: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Rekommendationer för uppföljning och utvärderingGenomför uppföljning och utvärdering med jämna mellanrum när enwebbplats är i förvaltningsfasen.Se till att ha en kontinuerlig trafik- och sökordsanalysFörsök ordna så att projektteamet själva har kompetens att genomföraanvändningstester under en utvecklingsfas. Ju tidigare testernakommer igång under utvecklingsfasen desto bättre.

Några vanliga metoder för uppföljning användningstesterexpertutvärderingtrafikanalyssökordanalysA/B-tester och multivariabla tester

Här följer några rekommendationer kring respektive metod:

AnvändningstesterGenomför användningstester med jämna mellanrum.Testa med användare från de mest prioriterade målgrupperna. Utföräven tester med personer med funktionsnedsättning och andra medsärskilda behov.Genomför användningstester redan under utvecklingsfasen, gärna påett tidigt skede. Se artikeln Testa och utvärdera designförslag.

Börja med att definiera vilka uppgifter som ska testas på webbplatsen ochvad som krävs för att testet ska anses lyckat. Exempelvis: fyra av sexanvändare ska klara av att lämna sin deklaration på webbplatsen eller femav sex besökare ska hitta kontaktuppgifter inom 60 sekunder.

Användningstester ska genomföras med riktiga användare och realistiskauppgifter. Det är vanligt att testerna utförs individuellt med varje testperson.Under testet uppmanas testpersonen att tänka högt medan hon göruppgifterna så att testledaren bättre ska förstå varför hon interagerar somhon gör med webbplatsen.

Du behöver inte ha någon avancerad utrustning för att genomföraanvändningstester. Du kommer långt genom att enbart sitta bredvid ochobservera testpersonen och ta anteckningar. Det går också att genomföraanvändningstester på distans med hjälp av digitala verktyg.

Att göra ett begränsat test är bättre än att inte göra något test alls. Det är tillexempel bättre att utvärdera användbarheten med ett fåtal användare änmed inga alls.

ExpertutvärderingEn expertutvärdering innebär att en eller flera personer/experter gör enöversyn av webbplatsen eller delar av webbplatsen för att kartläggapotentiella användbarhetsproblem och föreslå åtgärder för hur problemen

Vägledning förWebbutveckling Sida 84 /

316

Page 86: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

kan lösas. Det går inte att ersätta användningstester med enexpertutvärdering, men det kan vara ett bra komplement, exempelvis i ettstartskede vid en större förändring på en webbplats eller för att identifieraolika problemområden på webbplatsen.

Vid en expertutvärdering går man igenom både webbplatsens innehåll ochutformning för att se hur väl den stödjer målgruppernas behov och för attförsäkra sig om att den följer standarder. Det är också vanligt att granskarnaställer de frågor som de tror att användarna har samtidigt som de utför devanligaste uppgifterna på webbplatsen för de mest prioriterademålgrupperna.

En expertutvärdering resulterar i ett antal förslag på åtgärder.

Trafikanalys och sökanalysAtt analysera trafiken på webbplatsen och användarnas sökbeteenden är ettbra sätt att löpande utvärdera innehållet. Se Kontrollera besöksstatistik ochsökbeteende regelbundet.

Resultatet och siffrorna från en trafikanalys kan dock inte användas som enabsolut sanning utan bör kombineras med andra former av utvärderingar.Insamlingsmetoderna innehåller alltför många osäkra faktorer för att tolkasbokstavligt.

Glöm inte bort att följa regleringen om kakor, om verktyget för webbanalysanvänder sådana eller jämförbar teknik. Se avsnittet om samtycke till kakori webbriktlinje R20.

A/B-tester och multivariabla testerA/B-tester och multivariabla tester är tekniker som kan användas för attjämföra olika varianter av ett flöde med varandra. A/B-tester är antagligenden vanligaste metoden för webbplatser, och innebär att man testar tvåolika varianter av en sida, eller en del av en sida, för att se vilkenvariant som fungerar bäst för användarna. I multivariabla tester skapar manflera varianter av en eller flera sidor, som sedan varvas i själva testet. Dåkan man testa många olika varianter och kombinationer. För ett statistisktsäkert resultat krävs ett stort antal besök.

Mätbarhet

Kontrollera hur ni uppfyller riktlinjen genom att svara på: Sker trafik- ochsökordsanalys kontinuerligt? Sker användningstester regelbundet? Harutvecklingsteamet tillgång till personer som kan testa?

FördjupningMetoder för användningstester (usability.gov)Användningsforums Designprincip nr 3: Låt användningsdata styradesignvalenOm trafikanalys (idg.se)

Vägledning förWebbutveckling Sida 85 /

316

Page 87: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Wikipedias artikel om användbarhetstestning

TerminologiSynonymer till testa är till exempel granska, validera och undersöka.Användningstester kallas ofta (något missvisande) användartester, menäven användbarhetstester, user testing, usability testing med mera.

Webbanalys, engelskans web analytics är de metoder som används för attsamla in kvantitativa data om hur webbplatser används, och göra analyserav dessa data. Trafik- och sök- eller sökordsanalys är två delar avwebbanalysen.

Senast uppdaterad: 2018-05-22

Prio 3

Möjliggör synpunkter, frågor ochdialogGe användarna möjlighet att lämna förslag och rapportera in felaktigheterom er webbplats och verksamhet. Då får du värdefull information om hurwebbplatsen kan förbättras, bygger förtroende och ger er möjlighet attutveckla verksamheten.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Interaktionsdesign, Process,Utvärdering

Rekommendationer för att underlätta dialog omwebbplatsen och verksamheten

Ange hur användare kan lämna synpunkter på webbplatsen ochverksamheten.Informera användarna om hur ärendet kommer att behandlas.Ta fram rutiner för att ta emot och hantera alla inkomna synpunkter.Svara användare som inte valt att vara anonyma.

Ange hur användare kan lämna synpunkter påwebbplatsen och verksamhetenDet finns olika verktyg och tjänster för att hantera synpunkter, frågor ochdialog. Vissa erbjuder en öppen hantering av kommentarer. Ibland med

Riktlinje nr 38

Vägledning förWebbutveckling Sida 86 /

316

Page 88: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

möjlighet till dialog mellan användare. Ett annat sätt är att användafunktionsbrevlådor till handläggare i organisationen. Placera gärna enåterkopplingsfunktion, eller länk till sådan, på varje sida.

Informera användarna om hur ärendet kommer attbehandlasInformera om när användaren kan förvänta sig ett svar, och att ingenbekräftelse kommer att skickas om avsändaren valt att vara anonym.

Ta fram rutiner för att ta emot och hantera allainkomna synpunkter

Ta fram rutiner för att snabbt åtgärda fel på webbplatsen.Ta fram rutiner för hur frågor om verksamheten ska besvaras ochskickas vidare till rätt mottagare i organisationen.Se till att informationen hanteras enligt lagar och regler, och ta framrutiner för att hantera stötande material om användarnas synpunkterhanteras i en extern tjänst.

Svara användare som inte valt att vara anonymaBekräfta att ni tagit emot meddelandet. Bekräftelsen bör innehållainformation om hur ni kommer att hantera frågan, när avsändaren kanförvänta sig ett svar, via vilken kanal ni kommer att svara och hur nihanterar eventuella personuppgifter. Bifoga dessutom texten från detursprungliga meddelandet. Då kan avsändaren spara sitt meddelande ochgå tillbaka för att se vad var och en har skrivit.

Relaterade riktlinjerR4. Gör det lätt att komma i kontakt med erR41. Använd funktionsbrevlådor

ExempelStockholm stads utvecklingsblogg möjliggör för besökare att lämnasynpunkter på funktionalitet innan den är lanserad.Här på webbriktlinjer.se kan användarna kommentera varje riktlinje.

Vägledning förWebbutveckling Sida 87 /

316

Page 89: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Arbetsmiljöverket underlättar för användarna att lämna förslag och rapportera in felaktigheterpå webbplatsen i två steg. När användaren klickar på Ja eller Nej i första steget fälls ettformulär ut där användaren kan ge återkoppling.

Senast uppdaterad: 2018-02-12

Prio 2

Ge webbplatsen en god läsbarhetTypsnittet och luftigheten i texten påverkar webbplatsens läsbarhet. Textenbör vara så stor att den är bekväm att läsa. Alltför liten text, stora textmassoroch många olika typsnitt gör texterna svårlästa. Begränsa därför antalettypsnitt på webbplatsen och använd alltid flexibla måttenheter, till exempelem eller procent, så att det går att att påverka storleken på texten medwebbläsarens inbyggda funktionalitet.

Den största delen information på en webbplats är vanligtvis textbaserad.Underlätta för alla användare genom att anpassa webbplatsen för olikahjälpmedel och ge löptext och övriga textelement god läsbarhet.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Tillgänglighet

Riktlinje nr 39

Vägledning förWebbutveckling Sida 88 /

316

Page 90: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning, Testning

Rekommendationer för god läsbarhetVä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.

Ange typsnitt i stilmallenMed hjälp av CSS-regeln @font-face kan man visa vilka typsnitt man vill,

även sådana som användaren inte har installerade på sin dator. Ibland kandet dock vara nödvändigt att frångå organisationens grafiska profil påwebbplatsen, eftersom text på skärm ställer andra krav på läsbarhet äntryckt text. Typsnitt som linjärerna Verdana, Tahoma och Trebuchet ochantikvan Georgia är speciellt framtagna för läsning på skärm, och ger därförgod läsbarhet på webbplatsen. Times New Roman är å andra sidan specielltframtaget för smala dagstidningsspalter och därför mindre lämpligt attanvända på en webbplats.

Använd sparsamt med grafiska markeringar som kursiv och fetstil i löptextenpå webbplatsen. Fetstil används framför allt för att markera nyckelord i entext. Kursiv text kan precis som i tryckt text användas för att markerabetoning. Vill man ge titlar på skrifter och liknande en grafisk markering ärcitattecken att föredra framför kursiv text.

Ange i stilmallen vilka typsnitt som ska användas för olika objekt.Laborera inte med flera olika typsnitt och teckengrader för samma typav textelement (exempelvis brödtext).Tänk på att om teckensnitt hämtas från andra servrar så kan det läckainformation om dina besökare till den servern. Se Se till att infogadeexterna tjänster följer webbriktlinjerna (R67).

Undvik helt versala rubriker och texter

Samma konventioner gäller för menyrubriker och andra rubriker som förvanlig löptext: de bör skrivas med stor begynnelsebokstav och i övrigtgement. Helt versala rubriker och texter försämrar läsbarheten helt enkeltför att vi inte är vana vid det (utom när det används för speciella syften, tillexempel för varningstext som ”SVAG IS” eller i förkortningar som ”CIO” och”EU”).

Anpassa radavståndetGrundinställningen i webbläsarna visar text med ett radavstånd på 120procent av storleken för typsnittet. Ju bredare spalter som används förbrödtexten, desto större måste radavståndet vara. Då hittar ögat lättare tillbörjan av nästa rad.

Vägledning förWebbutveckling Sida 89 /

316

Page 91: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Radavståndet kan behöva ökas till minst 150 procent inom textstycken, ochavståndet mellan stycken är minst 1,5 gånger större än radavståndet. Görinställningen med hjälp av CSS.

Avståndet mellan punkterna i punktlistor bör vara större än självaradavståndet. Då blir det lättare att se skillnaden på en ny punkt och enpunkt som sträcker sig över flera rader. Gör inställningen med hjälp av CSS.

Vissa användare har behov av större avstånd i text än andra. Därför är detviktigt att Se till att det går att öka avstånd mellan tecken, rader, stycken ochord (R157).

Vänsterjustera löptext och menyerLåt alltid löptexten vara vänsterjusterad, det vill säga texten ska ha en rakoch jämn vänsterkant och en ojämn högerkant. Det underlättar läsningen.Undvik att avstava ord annat än för mycket långa uttryck som ger svårlästaradbrytningar.

Vänsterställ även texten i vänstermenyer eller andra vertikala menyer. Dåblir det lättare för användarna att skumma menyposterna, eftersom blickenkan vandra längs menyns vänsterkant

Ange maximal spaltbredd och anpassa radlängden

Skapa en design som anpassar sig efter den textstorlek som användarenhar valt i sin webbläsare. Många användare har behov av att kunna ökastorleken på texten. Större textstorlek kan medföra bredare layout ochdärmed längre rader. Och eftersom långa radlängder försämrar läsbarhetenär det viktigt att designen anpassar sig efter textstorleken.

Se till att ha en layout där textens rader anpassas till storleken påfönstret och undvik horisontella rullningslister på sidan.Ange en maximal spaltbredd för sidan, så att raderna inte blir för långaom användarna har breda webbläsarfönster. Spaltbredden bör intevara mer än 80 tecken. Vilken maximal spaltbredd 80 teckenmotsvarar i en viss måttenhet i stilmallen varierar beroende på layout,typsnitt och radavstånd.

Se även Skapa en design som fungerar oavsett fönster- och skärmstorlek(R91).

MätbarhetTypsnitt och storlek bestäms ofta i layouten och den grafiska profilen, mentesta gärna andra vanliga typsnitt på webbplatsen. Kontrollera attläsbarheten är god även för de användare som får upp dem i stället.

Prova också att förstora texten, för att kontrollera att läsbarheten fortfarandeär god för dem som förstorar texten med hjälp av webbläsarens inbyggdafunktioner. Texten ska kunna förstoras till 200 procent utan att innehållet

Vägledning förWebbutveckling Sida 90 /

316

Page 92: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

eller funktionaliteten på webbplatsen påverkas.

Relaterade riktlinjerStryk aldrig under text som inte är länkad (R106)Se till att det går att öka avstånd mellan tecken, rader, stycken och ord(R157)Skapa en design som fungerar oavsett fönster- och skärmstorlek(R91)

TerminologiTeckensnitt och typsnitt

Teckensnitt och typsnitt är likvärdiga termer. Många personer med tekniskbakgrund använder ofta teckensnitt, medan det för andra är naturligt attanvända typsnitt.

Ordet font är ett engelskt lånord. På svenska använder man ordet font dåman avser en teckensnittsfil i en dator, medan det på engelska även kanbetyda typsnitt.

Antikvor och linjärer

Typsnitt brukar delas in i antikvor och linjärer.

Antikvor har seriffer eller ”fötter”, det vill säga de står på en liten linje.Antikvor är ofta svårlästa på bildskärmar och används därför inte gärna ilöptext på en webbplats. Om webbsidorna finns i en utskriftsfunktion kan dudock med fördel använda en antikva. Exempel på sådana typsnitt är TimesNew Roman och Georgia.

Linjärer är jämnt tjocka typsnitt som inte har några seriffer, vilket gör demlätta att läsa på en bildskärm. Linjärer används ofta till löptext påwebbplatser. Exempel på linjärer är Verdana, Arial, Helvetica och Tahoma.

Stilmallar och CSS

Stilmallar eller CSS (Cascading Style Sheets) presenteras i R92.Webbplatsen ska kunna användas även utan stilmallar.

Rendering

I webbsammanhang innebär rendering att webbläsaren tolkar html-kodenoch beräknar var olika element och liknande ska placeras eller presenteraspå webbplatsen.

TextväggLånga avsnitt med enbart text kan utgöra hinder för bland annat dyslektiker.Lätta gärna upp med mellanrubriker, punktlistor och bilder.

Vägledning förWebbutveckling Sida 91 /

316

Page 93: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-08-23

PrioInaktiv

Se riktlinje 38Tidigare riktlinje 40 är sammanslagen med riktlinje 38.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Se R38. Möjliggör synpunkter, frågor och dialog.

Senast uppdaterad: 2014-09-01

Prio 4

Använd funktionsbrevlådorE-post är en vanlig och viktig kontaktväg för användare som villkommunicera med organisationer. Skapa funktionsbrevlådor för eravanligaste kontaktvägar för att undvika problem när medarbetare slutar påarbetsplatsen eller är tillfälligt frånvarande.

Om denna riktlinjePrioritet: 4Principer: Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Prototypning

Rekommendation för funktionsbrevlådorSkapa funktionsbrevlådor för de kontaktvägar som är viktigast för eraanvändare.

Vad är en funktionsbrevlåda?En funktionsbrevlåda är inte knuten till en särskild person utan till enavdelning, en enhet eller en funktion, exempelvis [email protected] [email protected]. Funktionsbrevlådor gör det möjligt att automatisktvidarebefordra inkommande e-post till en eller flera personer, i stället för atten person ska behöva vara på plats för att tömma brevlådan. Det underlättarockså vid organisationsförändringar, eftersom ni slipper byta e-postadresseri tryckt material och på andra ställen där e-postadresserna sprids.

Riktlinje nr 40

Riktlinje nr 41

Vägledning förWebbutveckling Sida 92 /

316

Page 94: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ExempelBolagsverket använder adressen [email protected] somkontaktväg till den som just nu är ansvarig för webbplatsensutformning.Örebro kommun använder adressen [email protected] för dem somvill komma i kontakt med kommunen

Livsmedelsverket använder en rad funktionsbrevlådor. De upplyser ävenanvändaren om att meddelanden till myndigheten blir allmänna handlingar.Detta skriver vi om i riktlinjer om Bevarande och gallring.

Referenser

Se även R4. Gör det lätt att komma i kontakt med er och R38. Möjliggörsynpunkter, frågor och dialog.

Terminologi

En funktionsbrevlåda kallas ibland för gemensam eller delad brevlåda. Påengelska används exempelvis ”shared mailbox”. Ibland används så kalladedistributionslistor för att skapa funktionsbrevlådor. Då skickas inkommandepost vidare till alla adresser i listan.

Senast uppdaterad: 2018-07-11

PrioInaktiv

Redovisa vilka register sommyndigheten för och vilka regler somgäller för tillgång till demI enlighet med Personuppgiftslagen (PUL 26 §) ska information om registerbeskriva vilka typer av uppgifter som lagras, syften, användningsområden,varifrån uppgifterna kommer och i vilka fall informationen samkörs medandra organisationers register.

Om denna riktlinjePrioritet: InaktivPrinciper: Effektiv, Förtroendeingivande

Riktlinje nr 42

Vägledning förWebbutveckling Sida 93 /

316

Page 95: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Riktlinjen inaktuellFrån och med idag 2018-05-25 gäller dataskyddsförordningen istället förpersonuppgiftslagen, och därmed är denna riktlinje inte längre aktuell. Förrekommendationer om hur behandling av personuppgifter bör redovisashänvisar vi till Datainspektionen.

Rekommendationer för redovisning av registerPå webbplatsen ska det finnas information om hur man gör för att begära utregisterinformation som man har rätt att ta del av. Placera beskrivningen ianslutning till informationen om respektive register. Beskrivningen ska ge enpraktisk vägledning kring processen för att få registerutdrag och innehålladetaljer om regler för tillgång, eventuella avgifter och vart ett utdrag skickas.

Relaterade riktlinjer

Se även R20. Upplys hur juridisk information och kakor hanteras.

ExempelSkatteverket beskriver vilka register de har

Senast uppdaterad: 2018-05-25

Prio 3

Gör register och databaser medpublik information sökbaraAnvändarna har ofta stor nytta av att själva kunna söka i publika register ochdatabaser. Överväg därför att göra sådana sökbara, men ta hänsyn till vilkarisker och behov som finns.

Om denna riktlinjePrioritet: 3Principer: Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Inköpare och beställareNär i utvecklingsprocessen?: Innehållsproduktion, Målgruppsanalys,Systemutveckling

Rekommendationer för sökbara registerÖverväg att göra register och databaser sökbara för allmänheten.Ta hänsyn till både behov och risker.Kommuner och landsting ska ha en särskild webbaserad anslagstavla.

Riktlinje nr 43

Vägledning förWebbutveckling Sida 94 /

316

Page 96: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Vilka register behöver vara sökbara?

Det finns inga generella riktlinjer för vilken information ni bör göra sökbar.Det styrs av vilken information som är tillåten för er att lämna ut, vilka riskersom finns och vilken nytta det kan ge. En risk kan till exempel vara missbruksom drabbar enskilda individer.

Kommuner och landsting ska ha en särskildwebbaserad anslagstavlaEnligt 3 kap. 30 § Kommunallagen (1991:900) ska vissa protokoll och andrauppgifter hos kommuner, landsting och kommunalförbund publiceras påwebben istället för på en fysisk anslagstavla som tidigare. Beslutet gällerfrån och med 1 januari 2018.

Sveriges kommuner och landsting (SKL) har publicerat en sammanfattning,och skriver bland annat så här i sitt cirkulär:”Den webbaserade anslagstavlan ska placeras väl synlig och vara lätt atthitta. I propositionen rekommenderas att anslagstavlan läggs påwebbplatsens startsida. Är det av någon anledning inte lämpligt börstartsidan under alla förhållanden innehålla en tydlig anvisning om huranslagstavlan nås.”

I 3 kap. 30 § Kommunallagen (1991:900) finns detaljerade krav på denwebbaserade anslagstavlan.

Exempel på sökbara register och databaserDet statliga personadressregistret (SPAR) gör det möjligt för företagatt mot betalning göra registerutdrag som bland annat används fördirektreklam.Statistiska centralbyrån (SCB) ger allmänheten tillgång till sinadatabaser och verktyg som gör det möjligt för var och en att få framspecifika statistikuppgifter.Det är också fritt att söka i Arbetsförmedlingens databaser medplatsannonser.

FördjupningSe även R89. Gör det möjligt för andra att återanvända webbplatsensinnehåll.

Senast uppdaterad: 2017-12-15

Prio 4

Gör det möjligt att läsa och söka idiariet

Riktlinje nr 44

Vägledning förWebbutveckling Sida 95 /

316

Page 97: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om din organisation har ett offentligt diarium kan ni öka er transparensgenom att publicera diariet på webben. Innan ni gör diariet sökbart föranvändarna måste dock intresset av ökad insyn ställas mot skyddet av denpersonliga integriteten.

Om denna riktlinjePrioritet: 4Principer: Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Målgruppsanalys, Process, Prototypning

Rekommendationer för diarier på internetBesvara dessa frågor innan ni publicerar diariet på webbplatsen:

Hur ska sekretessbelagd information döljas vid webbpublicering?I vilken utsträckning bör information om till exempel handläggaresnamn finnas i diariet?Hur lång tid bakåt i tiden ska informationen i diariet vara tillgänglig?Hur ska informationen och sökmöjligheterna i diariet utformas så att deblir begripliga för användarna, utan att hindra organisationens internaarbete?

Vilka uppgifter ska publiceras?Vilka diarieuppgifter som ska publiceras på webben skiljer sig mellan olikaorganisationer. Några vanliga poster i ett publikt diarium brukar vara:

diarienummerärendemening eller ärenderubrikenhet och/eller handläggareföretag, part eller motsvaranderegistreringsdatum.

Exempel på publika diarierStatskontorets diariumPTS diarium

Fördjupning

Datainspektionen har publicerat en checklista för webbpublicering avprotokoll och diarier för kommuner och landsting.

Se även R43. Möjliggör sökning i register och databaser med publikinformation.

Senast uppdaterad: 2017-12-08

Vägledning förWebbutveckling Sida 96 /

316

Page 98: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 2

Planera för långsiktigt bevaranderedan vid utveckling av webbplatsenPlanera redan i utvecklingsfasen för att bevara och göra informationen påwebbplatsen tillgänglig över tid. Det kan innebära lägre kostnad och högreeffektivitet för verksamheten.

Om denna riktlinjePrioritet: 2Principer: Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallringNär i utvecklingsprocessen?: Prototypning

Rekommendationer för långsiktigt bevarandeTa ställning till hur det som publiceras ska bevaras och hållasåtkomligt över tid, redan när ni planerar webbplatsen.Om din organisation inte är en myndighet, ta reda på vilka krav ochbehov som finns när det gäller långsiktigt bevarande.

Vilka organisationer berörs av vilka krav påbevarande?Alla myndigheter är ansvariga för att bevara och göra sina webbplatsertillgängliga över tid, enligt den strategi för bevarande av elektroniskahandlingar som varje myndighet måste upprätta enligt Riksarkivetsföreskrifter, RA-FS 2009:1. För kommuner och landsting gäller fullmäktigesarkivreglemente, men Riksarkivets föreskrifter kan fungera rådgivande.

Utveckling och planering av webbplatserGå igenom nedanstående frågor och rekommendationer innan utvecklingenbörjar. De är hämtade från Riksarkivets föreskrifter och allmänna råd omelektroniska handlingar (RA-FS 2009:1):

Vilken eller vilka standarder ska webbplatsen följa enligtriktlinjerna Följ standarder (R80) och riktlinje Utveckla webbplatsenenligt en standard snarare än för en webbläsare (R81)?Vilka format ska användas för dokument, bilder, ljud, video ochfristående databaser på webbplatsen? Det bästa är om ni kan väljabevarandeformat redan från början. Se vidare Publicera i format somär lämpade för långsiktigt bevarande (R46).Vilka format ska användas för handlingar som kommer in via e-tjänster? Det är bra om det är möjligt att välja bevarandeformat redanfrån början. Se vidare Publicera i format som är lämpade förlångsiktigt bevarande (R46).Vilka informationstyper ska bevaras och vilka kan gallras enligt

Riktlinje nr 45

Vägledning förWebbutveckling Sida 97 /

316

Page 99: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

författning och tillämpningsbeslut?När, hur och av vem ska gallring ske?Hur, när, hur ofta och av vem ska insamling ske enligt riktlinje Samlain informationen regelbundet för att säkerställa bevarandet (R48)?Vilka format ska vara tillåtna vid insamlingen enligt riktlinje Samla ininformationen regelbundet för att säkerställa bevarandet (R48)?Använd endast tillåtna bevarandeformat, se Publicera i format som ärlämpade för långsiktigt bevarande (R46).Ska organisationen, för att säkerställa bevarandet över tid, överförainformationen till ett system för bevarande (e-arkiv) eller i stället väljabevarandeexemplar (se definitioner i Riksarkivets Rapport angåendeelektroniska arkiv (e-arkiv), bevarandeexemplar och system förbevarande)? Och hur ska informationen hanteras efter överföringen(RA-FS 2009:1)?Hur och när ska informationen på webbplatsen kopplas tillmyndighetens arkivredovisning (RA-FS 2008:4)? Om möjligt, tillföruppgifter om processtillhörighet redan vid publicering eller då enhandling inkommer via e-tjänst.Vilka andra metadata behöver tillföras informationen inför publiceringför att tillgodose sökbehoven över tid?Vilken dokumentation ska upprättas (RA-FS 2009:1, 5 kap)?Hur kan informationen skyddas över tid (RA-FS 2009:1, 6 kap)?

Kravställning

Kravställ hur webbplatsen ska konstrueras utifrån de beslut som tas ipunkterna ovan. Rutiner som är fastställda på ett tidigt stadium iutvecklingsprocessen är ofta lättare att införa som automatiska regler i ettsystem. Med tidigt införda automatiska regler kan informationen bevaraslångsiktigt på ett smidigt sätt och ni kan undvika resurskrävande efterarbete.Undvik manuella rutiner så får ni bättre effektivitet.

FördjupningFöreskrifter om elektroniska handlingar

RA-FS 2009:1 – Riksarkivets föreskrifter och allmänna råd omelektroniska handlingar (pdf-fil, nytt fönster)RA-FS 2009:2 – Riksarkivets föreskrifter och allmänna råd omtekniska krav för elektroniska handlingar

Föreskrifter om arkivredovisningRA-FS 2008:4 – Riksarkivets föreskrifter om ändring i Riksarkivetsföreskrifter och allmänna råd (RA-FS 1991:1) om arkiv hos statligamyndigheter

RapporterRapport angående elektroniska arkiv (e-arkiv), bevarandeexemplaroch system för bevarande. Rapport 2008-12-11, Riksarkivet, dnr RA22-2007/3552 (pdf-fil, nytt fönster)

Vägledning förWebbutveckling Sida 98 /

316

Page 100: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Regelkommentar för Riksarkivets föreskrifter om arkivredovisning RA-FS 2008:4 (version 0.9, 2009-07-02), Riksarkivet, dnr 20-2009/1265 (pdf-fil, nytt fönster)CODA-WEBB. Slutrapport 2009-05-05. LDB-centrum (pdf-fil, nyttfönster)

Senast uppdaterad: 2014-09-24

Prio 4

Publicera i format som är lämpade förlångsiktigt bevarandeInnehåll på myndigheters webbplatser är allmänna handlingar. Därförbehöver de kunna bevaras under lång tid. Det gäller både text och bilder,ljud eller video.

Om denna riktlinjePrioritet: 4Principer: Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallringNär i utvecklingsprocessen?: Process, Systemutveckling

Rekommendationer för format för långsiktigtbevarande

Följ de kriteriet som finns för bevarandeformatPublicera textbaserad information som htmlVälj rätt format för databaser, register, bilder, ljud och videoSkapa regler för publicering.

Följ de kriterier som finns för bevarandeformatOm det är möjligt att publicera i ett format som är lämpligt för långsiktigtbevarande behöver man inte lika snabbt konvertera innehållet när detkommer nya format. Det underlättar både själva bevarandet och kan på siktinnebära en effektivisering och kostnadsminskning för organisationen.

Det finns några grundläggande kriterier för att ett format ska anses lämpatför långsiktigt bevarande. Se till att de:

följer öppen standard och har publikt tillgängliga specifikationerär leverantörsoberoendeär fritt från kryptering och DRM-kopieringsskydd (digital rightsmanagement)är vanligt förekommande bland organisationer i Sverigeom möjligt är okomprimerande eller icke-destruktivt komprimerande(gäller bild, ljud och video).

Riktlinje nr 46

Vägledning förWebbutveckling Sida 99 /

316

Page 101: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Utifrån dessa kriterier har Riksarkivet utfärdat föreskrifter om lämpligabevarandeformat för olika typer av elektroniska handlingar, RA-FS 2009:2.De här föreskrifterna är bindande för statliga myndigheter och ska, i denmån det är möjligt, tillämpas redan när man tar fram eller publicerar enelektronisk handling..

Föreskrifterna omfattar än så länge inte bevarandeformat för ljud och video,men som myndighet ska man ändå ta ställning till vilka format man tänkeranvända för långsiktigt bevarande av såväl ljud som video.

Publicera textbaserad information som htmlEnligt Riksarkivet föreskrifter (RA-FS 2009:2) ska textbaserat innehåll iförsta hand publiceras i standardformatet för webbplatser som är HTML. Påså vis underlättar man dessutom för alla användare (Publicera i första handdokument i HTML (R88)). Det underlättar även bevarandeprocessen, i ochmed att HTML-sidor är lätta att spara ner som statiska sidor.

Välj rätt format för databaser, register, bilder, ljudoch videoInnehåll i fristående databaser och register som har gjorts tillgängliga påwebbplatsen, som till exempel ett diarium eller adressregister, kan ofta intebevaras som HTML på lång sikt. För dem krävs bevarandeformatanpassade för databaser och register (RA-FS 2009::2). Eftersom dessaformat inte stämmer överens med dem för publicering på webbplatsenmåste överföringen till ett lämpligt bevarandeformat istället ske när det ärmöjligt ur ett verksamhetsperspektiv. Se Samla in informationen regelbundetför att säkerställa bevarandet (R48).

För bilder, ljud och video finns det format som både uppfyller kriterier förbevarandeformat och som är lämpliga för publicering på webbplatser. Detgäller även dokument som av olika skäl inte kan publiceras i HTML(se Publicera i första hand dokument i HTML (R88)).

Det är upp till er i organisationen att själva fatta beslut om vilka format somska användas med hänsyn till kriterierna för bevarandeformat ochRiksarkivets föreskrifter.

Skapa regler för publiceringNär ni planerar eller utvecklar en webbplats bör ni alltid planera för detlångsiktiga bevarandet av informationen.

Utred vad som ska bevaras och vad som kan gallras, när, hur och avvem.Utred vilka format som lämpar sig bäst att använda vid publicering urbevarandesynpunkt med hänsyn till verksamhetens behov (sekriterierna för bevarandeformat samt Riksarkivet föreskrifter (RA-FS2009:2)).Inför regler om vilka format som ska tillåtas när informationen

Vägledning förWebbutveckling Sida 100 /

316

Page 102: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

publiceras, utifrån den genomförda utredningen. Reglerna kan varaautomatiska eller manuella. Undersök om det finns möjlighet att styra iert publiceringsverktyg vilka format som får användas på webbplatsen.Inför regler och rutiner, utifrån utredningen, för hur olika typer avinformation på webbplatsen ska hanteras när den tas bort ellerändras. Även dessa regler kan vara automatiska eller manuella.

Se även riktlinje Planera för långsiktigt bevarande redan vid utveckling avwebbplatsen (R45).

Mätbarhet

Kontrollera vilka format som finns på webbplatsen och jämför medRiksarkivets föreskriftskrav i RA-FS 2009:2 samt kriterierna förbevarandeformat.

FördjupningFöreskrifter

RA-FS 2009:1 – Riksarkivets föreskrifter och allmänna råd omelektroniska handlingar (upptagningar för automatiserad behandling)RA-FS 2018:7 – Föreskrifter om ändring av Riksarkivets föreskrifter(RA-FS 2009:1) och allmänna råd om elektroniska handlingar(upptagningar för automatiserad behandling)RA-FS 2009:2 – Riksarkivets föreskrifter och allmänna råd omtekniska krav för elektroniska handlingar (upptagningar förautomatiserad behandling)

RapporterRapport från LDB-centrum om kriterier för bevarandeformat: CODA-FORM. Slutrapport 2007. LDB-centrum (pdf)

Terminologi

En öppen standard är, enkelt uttryckt, en standard som vem som helst kananvända. Den är alltså inte hemlig eller omgärdad av hindrande licenser.Med hjälp av öppna standarder minskar beroendet av enstaka leverantörer.

När en fil komprimeras icke-destruktivt innebär det att den ursprungliga filengår att återställa helt. Ingen information har alltså gått förlorad, utan den harbara kodats på ett mindre utrymmeskrävande sätt.

Senast uppdaterad: 2019-02-18

Prio 3

Undvik oavsiktlig gallring vid

Riktlinje nr 47

Vägledning förWebbutveckling Sida 101 /

316

Page 103: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ändringar och uppdateringarInnehåll på myndigheters webbplatser är allmänna handlingar som skabevaras enligt arkivlagstiftningen. Man får ta bort information och gallra,men bara om det finns stöd i en författning.

Om denna riktlinjePrioritet: 3Principer: Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallringNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion, Process

Rekommendationer för gallringFölj de regler som finns för gallring.Gallra viss information när den blivit inaktuellVälj rätt metod för bevarande vid ändring och uppdatering

Följ de regler som finns för gallringAtt gallra definieras som att förstöra allmänna handlingar eller uppgifter iallmänna handlingar eller vidta andra åtgärder med handlingarna sommedför någon form av oåterkallelig informationsförlust. Gallring påmyndigheters webbplatser får bara göras om det finns stöd för det i enförfattning.

En grundläggande förutsättning för att gallring ska få ske är attallmänhetens rätt till insyn inte åsidosätts och handlingarna har bedömtssakna värde för rättsskipning, förvaltning och forskning.

För statliga myndigheter gäller Riksarkivets föreskrifter och vissaregisterförfattningar. För kommuner och landsting gäller fullmäktigesarkivreglemente och de beslut om gallring som fattas i kommunen ellerlandstinget.

Gallra viss information när den blivit inaktuellEn del information får gallras direkt när den blivit inaktuell. Statligamyndigheter har till exempel med stöd av RA-FS 1997:6 möjlighet att gallravissa tillfälliga uppgifter såsom adress, telefon- och öppettider direkt när deersätts av nya uppgifter. Detta under förutsättning att myndigheten redovisarvilka handlingar som avses i ett eget tillämpningsbeslut.

Välj rätt metod för bevarande vid ändring ochuppdateringInformation som ska bevaras och inte kan gallras direkt vid en ändring elleruppdatering, måste vara åtkomlig och hållas oförändrad under den tid denska bevaras. Det innebär att när informationen avpublicerats ska den kunnaplockas fram när någon frågar efter den.

Vägledning förWebbutveckling Sida 102 /

316

Page 104: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Vilken metod ni väljer för att bevara avpublicerad information beror blandannat på hur länge den ska bevaras. Om det är fråga om information sombara ska bevaras under en kort tid för att sedan gallras enligt beslut, kan deträcka med att använda publiceringsverktygets funktion för att hanteraändringar, om den kan användas för att gå tillbaka till tidigare versioner aven webbsida.

Om informationen däremot ska bevaras under längre tid krävs andraåtgärder. Ett bra sätt att få kontroll över bevarandet av informationen är attredan vid publiceringen av varje ny version av en sida, se till att en statiskversion av sidan sparas ner i lämpligt bevarandeformat för webbsidor (RA-FS 2009:2, 3 kap, 9 §). Om ni på det viset kan använda er av en automatiskbevarandefunktion blir inte processen tidskrävande eller komplicerad. Påsamma sätt kan man lägga till nödvändig metadata på informationen redanvid publiceringen. Kom ihåg att den avpublicerade informationen alltid skagå att koppla till det sammanhang och den plats i strukturen där denursprungligen publicerades.

FördjupningMer information om Riksarkivets generella och myndighetsspecifikaföreskrifter, RA-FS och RA-MS.Samrådsgruppens gallringsråd för kommuner och landsting.Om gallring – från utredning till beslut. Rapport 1999:1. Riksarkivet(pdf-fil, öppnas i nytt fönster)RA-FS 2009:1 – Riksarkivets föreskrifter och allmänna råd omelektroniska handlingarRA-FS 2009:2 – Riksarkivets föreskrifter och allmänna råd omtekniska krav för elektroniska handlingarRA-FS 1997:6 – Föreskrifter om ändring i Riksarkivets föreskrifter(1991:6) och allmänna råd om gallring av handlingar av tillfällig ochringa betydelse

Senast uppdaterad: 2014-09-24

Prio 3

Samla in informationen regelbundetför att säkerställa bevarandetFör att innehållet på webbplatsen ska kunna bevaras och finnas tillgängligtäven på lång sikt måste det samlas in och sparas ner från webbplatsenregelbundet. Denna riktlinje är en av fem som gäller arkivering, och berörframför allt myndigheter.

Om denna riktlinjePrioritet: 3Principer: Åtkomlig över tid

Riktlinje nr 48

Vägledning förWebbutveckling Sida 103 /

316

Page 105: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter: Bevarande och gallringNär i utvecklingsprocessen?: Förvaltning, Process

Rekommendationer för regelbunden insamlingKombinera olika insamlingsmetoder eftersom ingen metod ärheltäckandeGör insamling så ofta att information som ska bevaras inte går förloradmellan insamlingstillfällena.

Kombinera flera insamlingsmetoder, eftersomingen metod är heltäckande

Allt som en gång publicerats på en myndighets webbplats är allmännahandlingar om det inte finns stöd för gallring (se R47, undvik oavsiktliggallring vid ändringar och uppdateringar). Det gäller även sidor meddynamiskt innehåll som fristående databaser och registerinformation,avpublicerad information och sidor som kräver inloggning. En vanliginsamlingsmetod är att använda en så kallad webbcrawler men eftersomexempelvis dynamiskt innehåll inte kan fångas upp med en webbcrawler börman alltid kombinera olika insamlingsmetoder för få en heltäckandeinsamling. Vilka metoder som ska användas och i vilken omfattning beror påhur webbplatsen är uppbyggd, vilken information den består av, vad somska gallras och när.

Här rekommenderar vi en kombination av insamlingsmetoder, men varjemyndighet måste själv planera och skapa rutiner för vilka metoder som skatillämpas, vad som ska samlas in, hur ofta, och av vem. Alla beslut börgrunda sig på en utredning som myndigheten bör genomföra enligtriktlinje Planera för långsiktigt bevarande redan vid utveckling avwebbplatsen (R45).

Rekommendationerna utgår från Riksarkivets föreskrifter om elektroniskahandlingar, RA-FS 2009:1 och RA-FS 2009:2, som är bindande för statligamyndigheter. För kommuner och landsting gäller först och främstfullmäktiges arkivreglemente, men Riksarkivets föreskrifter kan fungerarådgivande.

Samla systematisktAnvänd en webbcrawler för att regelbundet samla in ögonblicksbilder avhela eller delar av webbplatsen. Samla inte in externa länkar, mendokumentera vart de ledde.

Konvertera dokument-, bild-, ljud- och videofiler till lämpligabevarandeformat innan insamlingen med webbcrawlern startar. Dessa filerska helst vara i bevarandeformat redan vid publicering (se Publicera i formatsom är lämpade för långsiktigt bevarande (R46)).

Samla in fristående databaser och register som är sökbara på webbplatsen,

Vägledning förWebbutveckling Sida 104 /

316

Page 106: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

till exempel ett ärendehanteringssystem. Använd ett lämpligtbevarandeformat för databaser och register (RA-FS 2009:2, 3 kap, 1 §).Spara även databasens grafiska gränssnitt genom att samla in statiskaversioner i lämpligt bevarandeformat för webbsidor (RA-FS 2009:2, 3 kap, 9§). Dokumentera också relationen mellan det grafiska gränssnittet och denunderliggande databasen.

Fånga upp de ändringar som ska bevaras. Det kan man göra genom attredan i samband med publiceringen av en sida, och varje ny version avsidan, spara ner en statisk version i lämpligt bevarandeformat för webbsidor(RA-FS 2009:2, 3 kap, 9 §) med tillhörande metadata. Det går att ordnamed automatik så det inte tar tid i anspråk i den dagliga hanteringen.Information som ska gallras behöver inte samlas in (se Undvik oavsiktliggallring vid ändringar och uppdateringar (R47)).

I insamlingen ingår att:

Kontrollera att gallring inte kommer att ske vid insamlingen. Se Undvikoavsiktlig gallring vid ändringar och uppdateringar (R47)).Överför filer till ett system för bevarande (e-arkiv) ellerbevarandeexemplar (RA-FS 2009:1).Kontrollera att den insamlade informationen i alla delar ärdokumenterad (RA-FS 2009:1, 5 kap).

För- och nackdelar med en webbcrawlerEn webbcrawler är ett verktyg som kan samla in och spara ner en statiskavbild av en webbplats. Insamlingen sker från användarens sida,klientsidan. En förutsättning för att insamlingen ska fungera är attwebbplatsen följer standarder och att tilläggsprogram undviks så långt detär möjligt.

Fördelarna med en webbcrawler är att den ger en övergripandeögonblickbild av webbplatsen. Länkarna kommer fortfarande vara klickbara iden nedsparade versionen, och utseendet och strukturen kommer varadesamma som på den aktiva webbplatsen.

Nackdelen är att allt innehåll på en webbplats inte kan samlas in med enwebbcrawler. Det är till exempel svårt eller omöjligt att samla in:

1. Sidor med dynamiskt innehåll som fristående databaser ochregister. I den nedsparade versionen kommer det inte vara möjligt attsöka i till exempel ett ärendehanteringssystem eller adressregistersom lagts ut på webbplatsen.

2. Avpublicerad information. Information som både hunnit publicerasoch därefter avpublicerats mellan insamlingstillfällena, samlas inte ineftersom insamlingen sker från klientsidan.

3. Sidor som kräver inloggning. För att de ska samlas in krävs attwebbcrawlern får behörighet till sidorna, men eftersom det ofta ärwebbplatsägaren som gör insamlingen brukar det inte vara någotproblem.

Vägledning förWebbutveckling Sida 105 /

316

Page 107: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningRiksarkivets föreskrifter

Mer information om Riksarkivets generella och myndighetsspecifikaföreskrifter, RA-FS och RA-MS, finns på Riksarkivets webbplats.RA-FS 2009:1 – Riksarkivets föreskrifter och allmänna råd omelektroniska handlingarRA-FS 2009:2 – Riksarkivets föreskrifter och allmänna råd omtekniska krav för elektroniska handlingar

Bevarande och insamlingsmetoderBrown, Adrian (2008), Archiving websites. A practical guide forinformation management professionals. Bodmin, Cornwall,Storbritannien.CODA-WEBB. Slutrapport 2009-05-05. LDB-centrum (pdf-fil, nyttfönster)Bevara webbplatser – information på Riksarkivets webbplats.Att tänka på vid IT-leveranser av webbsidor – Lathund för digitaltlångtidsbevarande av webbsidor. Enheterna Elektroniska arkiv ochTeknikberoende medier (2008-02-11), Riksarkivet.Rapport angående elektroniska arkiv (e-arkiv), bevarandeexemplaroch system för bevarande. Rapport 2008-12-11, Riksarkivet, dnr RA22-2007/3552 (pdf-fil, nytt fönster)

GallringOm gallring – från utredning till beslut. Rapport 1999:1. Riksarkivet(pdf-fil, nytt fönster)Gallringsråd för kommuner och landsting finns på Samrådsgruppen förkommunala arkivfrågors webbplats.

Senast uppdaterad: 2014-09-24

Prio 3

Gör det möjligt att få ut avpubliceratmaterialOm ni är en myndighet och publicerar något på webbplatsen upprättasallmänna handlingar. För att allmänhetens rätt till insyn ska kunnatillgodoses över tid krävs att ni kan tillhandahålla även den information sominte längre finns tillgänglig på den aktiva webbplatsen.

Om denna riktlinjePrioritet: 3Principer: Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallring, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion, Process

Riktlinje nr 49

Vägledning förWebbutveckling Sida 106 /

316

Page 108: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Rekommendationer för att tillhandhållaavpublicerad information

Var beredd att lämna ut information som inte längre finns tillgänglig påmyndighetens webbplats, såvida den inte är gallrad.Publicera myndighetens arkivredovisning på den aktiva webbplatsenför att underlätta för användaren att identifiera avpubliceradinformation.

Handlingar som får lämnas utHandlingar som får lämnas ut utan prövning (TF 2 kap, 12 §) blir vanligtvisutlämnade med automatik eftersom informationen är tillgänglig påwebbplatsen. Avpublicerat material behöver däremot, om det inte finnsgallringsbeslut, kunna lämnas ut när någon frågar efter den. För att dettaska bli enklare att kan ni genomföra vissa förberedelser.

Förbered er för att lämna ut avpublicerat materialTillför metadata och annan nödvändig dokumentation som ska följa medhandlingarna redan vid publiceringen och under hela bevarandetiden så attde kan läsas, förstås i sitt sammanhang och behålla sin äkthet (För statligamyndigheter gäller Riksarkivets föreskrifter om elektroniska handlingar, RA-FS 2009:1, 5 kap.).

Se till att det finns funktioner för återsökning så att ni kan lämna utinformation på begäran ur det system (e-arkiv) som myndigheten använderför att bevara information, se Samla in informationen regelbundet för attsäkerställa bevarandet (48).

Redovisa informationen i er arkivredovisning så att den blir sökbar. (Förstatliga myndigheter gäller Riksarkivets föreskrifter omarkivredovisning, RA-FS 2008:4). När en sida publiceras, eller när enhandling kommer in via e-tjänst, kan den tillföras uppgifter om till exempelprocesstillhörighet.

Ge användarna möjlighet att söka även eftergammalt materialOm ni inte bara vill kunna tillhandahålla informationen på sikt utan även göraden tillgänglig på ett mer aktivt sätt kan ni göra det möjligt att låtaanvändaren själv söka efter äldre webbmaterial i ett e-arkiv via webbplatsen.Då är det viktigt att det tydligt framgår att informationen som presenteras ärinaktuell (se Tydliggör om informationen är inaktuell (R24)). Handlingarna ie-arkivet måste vara insamlade enligt riktlinje Samla in informationenregelbundet för att säkerställa bevarandet (R48).

Mätbarhet

Gör stickprov och låt en användare testa att begära ut webbsidor och annaninformation som avpublicerats.

Vägledning förWebbutveckling Sida 107 /

316

Page 109: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningTryckfrihetsförordningen (1949:105) 2 kapFöreskrifter om elektroniska handlingar: RA-FS 2009:1 – Riksarkivetsföreskrifter och allmänna råd om elektroniska handlingarFöreskrifter om arkivredovisning: RA-FS 2008:4 – Föreskrifter omändring i Riksarkivets föreskrifter och allmänna råd (RA-FS 1991:1)om arkiv hos statliga myndigheterAtt tänka på vid IT-leveranser av webbsidor – Lathund för digitaltlångtidsbevarande av webbsidor. Enheterna Elektroniska arkiv ochTeknikberoende medier (2008-02-11), Riksarkivet.CODA-WEBB. Slutrapport 2009-05-05. LDB-centrum (pdf-fil, nyttfönster)

Senast uppdaterad: 2018-03-23

Prio 3

Minimera antalet fält i formulärAnvänd så få fält som möjligt i formulär. Det ökar läsbarheten ochanvändbarheten. Minimera särskilt antalet obligatoriska fält. Endast de somär absolut nödvändiga för att ni ska få in tillräckligt med uppgifter bör varaobligatoriska.

Om denna riktlinjePrioritet: 3Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign

Rekommendationer för få fält i formulärMinimera antal fält i formulären genom att slå ihop flera fält till ett, tillexempel för- och efternamn eller gatunamn och nummer.Gör det så tydligt som möjligt vilka fält som är obligatoriska. Grupperadem gärna, så att användarna sedan enkelt kan hoppa över frivilligafält.

Ett annat upplägg är att först bara visa de obligatoriska fälten. Näranvändaren har fyllt i dem visas de frivilliga fälten.

Relaterade riktlinjerDet finns flera andra riktlinjer för formulär. Se särskilt R52. Förpopuleraformulär

Riktlinje nr 50

Vägledning förWebbutveckling Sida 108 /

316

Page 110: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2014-09-24

Prio 1

Lyft fram det viktigaste i textenSe till att det viktigaste i varje text och avsnitt lyfts upp och lyfts fram tydligt.Se till att texter inte är onödigt långa, och att de inte har viktigt innehålllängre ner. Risken är att användarna missar det viktiga, eller får läggaonödigt lång tid på att hitta det.

Om denna riktlinjePrioritet: 1Principer: AnvändbarRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Innehållsproduktion

Rekommendationer för effektiva texterInled gärna med en sammanfattning av innehållet. Då kan användarnasjälva bedöma om de är på rätt ställe, och hur mycket av en text de villläsa.Börja alltid med det innehåll som är viktigast för den viktigastemålgrupp texten riktar sig till.Ge gärna det viktigaste på en sida ett utmärkande utseende.Skriv vägledande text om hur innehållet är strukturerat.

Utgå från användarnas behovUtgå från det användarna ska kunna göra med hjälp av texten, och lyft uppdet viktiga. Ta bort det som inte är nödvändigt för att texten ska varaanvändbar.

Olika målgrupper ska normalt ha olika mycket stoff, till exempel tar man oftabort mycket information när man skriver om texter till lättläst svenska.

Sammanfattningar och vägledande introduktioner är till stor hjälp om en textär svår eller omfattande. Se även R28. Gör det lätt att hitta det viktigaste.

MätbarhetDenna riktlinje kräver manuell granskning och användningstester.

FördjupningKlarspråksråd på Språkrådet, Institutet för språk och folkminnen.

Skrivråd från Centrum för lättläst

Senast uppdaterad: 2014-10-02

Riktlinje nr 51

Vägledning förWebbutveckling Sida 109 /

316

Page 111: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 4

Fyll formulär med kända uppgifterGör det enkelt för användarna att fylla i formulär genom att i förväg fylla i deuppgifter du redan har.

Om denna riktlinjePrioritet: 4Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion, Process,Systemutveckling

Rekommendationer för preliminära uppgifter iformulär

Överväg att automatiskt fylla i uppgifter i formulär. Det kan ske om enanvändare redan tidigare har lämnat uppgifter till er, eller omuppgifterna 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 iformuläret eller gör det enkelt för dem att ta kontakt med er för attpåpeka om uppgifterna är inaktuella eller felaktiga.

Överväg att inhämta viss information automatiskt

Många gånger är det möjligt att inhämta information från befintligadatabaser istället för att be användaren att mata in informationen igen. Dettakan underlätta och spara tid och energi för alla användare. Ibland kan detäven innebära ökad informationskvalitet.

Men det är viktigt att vara medveten om och ta hänsyn till vissa fallgropar:Till exempel finns det en risk att gammal information som inte längre äraktuell fortsätter att användas. Det kan också finnas risk att uppgifter lämnasut till personer som inte borde ha tillgång till dem.

Var därför noga med att endast exponera information till personer som ärbehöriga, och utforma formuläret på ett sätt som säkerställer att användaregranskar och, om det är lämpligt, bereds möjlighet att uppdatera informationsom kan vara inaktuell.

Ett alternativ om vissa uppgifter redan är kända är att plocka bortmotsvarande fält från formuläret. Se även R50. Minimera antalet fält iformulär.

Det kan även finnas fler aspekter att ta hänsyn till. Exempelvis vad avserdataskydd och ansvar för inlämnade uppgifter. Gör därför en juridisk

Riktlinje nr 52

Vägledning förWebbutveckling Sida 110 /

316

Page 112: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bedömning.

Ha gärna begreppet privacy by design i bakhuvudet. Det innebär att hänsyntas till användarnas integritet under systemets hela livscykel.

Fördjupning och relaterade riktlinjerMärk upp vanliga formulärfält i koden (R154)Ge ordförslag vid sökning och inmatning (R112)Förenklat och minskat uppgiftslämnandeDatainspektionens kommentar i ett fall där automatiskt inhämtadinformation inte borde ha exponerats

TerminologiDen engelska termen ”pre-populate” (bokstavligen: för-befolka) översättsibland till förpopulera eller förpopulering. Även uttrycket ”default value”syftar på förifyllda värden i formulär. På svenska motsvaras default avstandardvärde eller skönsvärde.

Senast uppdaterad: 2018-11-28

Prio 3

Gruppera formulärets fältFormulär med många inmatningsfält blir tydligare och enklare att förstå omman delar upp dem i flera delar. Delarna kan antingen presenteras i olikagrupper på en webbsida eller delas upp på flera sidor.

Om denna riktlinjePrioritet: 3Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Systemutveckling

Att naturligt grupperna fält hjälper användaren att fylla i rätt uppgifter. Börjamed att lista all data som ska samlas in med hjälp av formuläret och delaupp listan i grupper. Försök att slå ihop alternativ eller skapa mellanrubrikersom delar upp listan i logiska grupper om den är lång. Ett vanligt exempelpå gruppering är ”Postadress” med fält för Adress/Box, Postnummer ochOrt.

Rekommendationer för gruppering av formulärfältTänk igenom vilka beroenden som finns mellan uppgifterna som skafyllas i. Placera fält med uppgifter som användaren har nytta av närhan eller hon fyller i andra fält på samma sida. Även ska information

Riktlinje nr 53

Vägledning förWebbutveckling Sida 111 /

316

Page 113: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

som krävs för att kunna fatta ett beslut finnas på samma sida samtuppgifter som styr övrig information som ska fyllas i.Dela upp formuläret på flera sidor om det är omfattande och innehållermå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 ”Steg1 av 3: Dina kontaktuppgifter”. (Se även R63. Hjälp användaren attförstå var hon befinner sig i en process.)

Kod för gruppering av formulärfält

Använd elementet fieldset för att gruppera inmatningsfält på en sida. Ge

gruppen en tydlig rubrik med legend-elementet. Grupper av radioknappar

och kryssrutor är lämpliga att gruppera med fieldset.

Mätbarhet

Utvärdera formuläret genom användbarhetstester.

Fördjupning

Det finns flera andra riktlinjer som berör formulär.

Senast uppdaterad: 2014-10-02

Prio 2

Optimera webbplatsen för bästaprestandaOptimera tjänsten så att den laddar snabbt, svarar snabbt på interaktion ochkräver så lite som möjligt av användarens utrustning och uppkoppling. Dåligprestanda leder till negativa användarupplevelser, hinder för användning,försämrat genomslag (till exempel genom sämre rankning i sökmotorer) ochslöseri med resurser. Bra prestanda kan till exempel uppnås genom att inteöverföra mer data än nödvändigt.

Om denna riktlinjePrioritet: 2Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Prototypning, Systemutveckling

Rekommendationer för god prestandaAcceptera inte långa väntetider

Riktlinje nr 54

Vägledning förWebbutveckling Sida 112 /

316

Page 114: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Kartlägg utgångsläget och välj ambitionsnivåIdentifiera och åtgärda prestandaproblemGå igenom Fem sätt att förbättra prestandan

Acceptera inte långa väntetider

Ingen skulle köpa en bil som alltid skapar köer bakom sig, men mångawebbplatser och appar låter användare vänta i onödan. Du själv har kanskebra uppkoppling till din nya snygga sajt och är motiverad nog att vänta närden laddas, men andra besökare är ofta otåliga och på väg någonannanstans. Det kan även gälla personer med vissa funktionsnedsättningar,till exempel koncentrationsstörningar och kort arbetsminne.

Användare med mobil uppkoppling har extra stor anledning att undvikadåligt optimerade webbplatser eftersom de ofta har begränsad bandbreddoch ibland måste betala extra för varje megabyte data.

Eftersom sökmotorer premierar webbplatser med en godanvändarupplevelse leder ökad prestanda även till bättresökmotoroptimering.

Optimering innebär också minskad belastning på servrarna, vilket kan gelägre kostnader för hårdvara och bandbredd eftersom befintlig infrastrukturkan ta hand om fler användare.

Godtagbar prestanda är alltså ingen lyx, utan nödvändigt för att uppnåsyftet med sajten.

Kartlägg utgångsläget och välj ambitionsnivå

Om det redan finns ett system:

Kartlägg nuläget och identifiera vilka brister i prestandan som nibehöver åtgärda.Ta reda på vilka prestandabrister som användarna upplever som mestbesvärande och åtgärda de problemen först.Gör en nollmätning, det vill säga mät prestanda innan förbättringarnagjorts och upprepa mätningarna efteråt så blir det enkelt att utvärderaera insatser.

Oavsett om det gäller förvaltning eller nyutveckling kan det vara bra att tafram en prestandabudget som dokumenterar organisationens ambition kringprestandaoptimering, mätvärden med mera. Ett exempel påprestandabudget finns hos Västra Götalandsregionen. Medvetenhet ombetydelsen av prestanda får gärna finnas med redan i UX- och design-fasennär webbplatsen tas fram.

Vad är tillräckligt bra prestanda?Forskning har visat att användare av datorsystem tappar koncentrationenom de får vänta för länge. Nielsen-Norman har redovisat följande

Vägledning förWebbutveckling Sida 113 /

316

Page 115: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

konsekvenser av väntetider på webben:

0,1 sekunders svarstid slutar uppleva att svaret är omedelbart.1 sekunds svarstid börjar tankeflödet hindras av en upplevd väntan.10 sekunders svarstid har användaren svårt att vara uppmärksamoch vill göra något annat under tiden.

Behovet av snabba svarstider beror på användarens förväntan och exaktvad hen försöker åstadkomma. För användare med muspekare är denförsta tidsgränsen om 0,1 sekunder avgörande för om responsen uppfattassom omedelbar, exempelvis om musmarkören placeras över något och detorsakar en mouseover-effekt. Om användaren istället klickar på en länk ärdet troligt att den andra tidsgränsen om en sekund är mer relevant. Tiosekunder är någon form av bortre gräns för en användare att kunna behållafokus.

Applikationer bör ge användaren omedelbar respons efter en inmatning.Responsen bör komma inom 0.1 sekunder efter användarens inmatning.

Om applikationen är upptagen med att utföra en åtgärd som tar längre tid –visa det gärna för användaren med hjälp av ett timglas, förloppsindikator(progress meter) eller liknande. Allra bäst är om det går att indikera hur långtid som återstår.

Identifiera och åtgärda prestandaproblem

Det finns ett flertal möjliga anledningar till att en webbplats upplevs somlångsam. Mest uppenbart är att antingen webbplatsen i sig, elleranvändaren, har en långsam uppkoppling till internet. Det kan också bero påatt servern eller uppkopplingen har en hög belastning, till exempel på grundav en överbelastningsattack eller för att för många användare efterfrågar ettvisst innehåll.

En webbplats kan också uppfattas som långsam på grund av tekniskabrister, bland annat:

Underdimensionerade servrar. De flesta webbplatser består av fleraolika sorters servrar, bland annat för databas, bakomliggande systemoch webbredaktörernas publiceringssystem.Inte tillräcklig bandbredd mellan servrarna och internet. Jämför medtjockleken på en vattenslang vid vattnande av en gräsmatta: entjockare slang kan potentiellt bära mer vatten.Programmeringsfel till exempel vid sökningar i databaser kan göra attservern tvingas arbeta onödigt mycket för att leverera efterfrågatinnehåll.Inte optimal konfiguration, till exempel brister på hur en cache ärinställd, att databasers index inte återspeglar efterfrågat material elleratt behoven varierar på ett sådant sätt att det ändå inte fungeraroptimalt.

Vägledning förWebbutveckling Sida 114 /

316

Page 116: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Fem sätt att förbättra prestandanBegränsa antalet anropAtt hämta en webbsida på en webbplats innebär i princip alltid att klientenbehöver hämta flera olika resurser från servern: själva html-dokumentet,stilmallar, script, bilder, videofilmer med mera. Kom ihåg att varje http-anroptar tid. Om anropen sker till olika domännamn kan även fler dns-uppslagningar behövas.

Prestanda kan alltså förbättras genom att minska antal anslutningar. Dettasker med automatik om ni använder http-versionen HTTP/2. Gör gärna detom ni har möjlighet. Eftersom inte riktigt all mjukvara ännu har stöd förHTTP/2 så är det lämpligt att tills vidare säkerställa godtagbar prestandaäven för användare med äldre http-versioner. För äldre http-versioner kanantal anslutningar minskas genom att till exempel slå ihop flera resurser i enoch samma fil.

Kombinera flera separata stilmallar till en enda istället för att leverera fleraseparata stilmallar: en för färger, en för teckensnitt, en för övergripandelayout och så vidare.

Detsamma gäller script. Även bilder kan kombineras till så kallade CSSimage sprites. Det passar dock inte för alla typer av bilder, och kräversärskild eftertanke för att inte orsaka tillgänglighetsproblem.

Läs mer om olika http-versioner i R7. Använd en krypterad anslutning för e-tjänster.

Välj rätt format för bilder och multimediaBilder, videofilmer, ljudklipp och liknande står ofta för större delen avdatatrafiken från en modern webbplats. Här finns stora prestandavinster attgöra, ofta med ganska enkla medel:

Välj rätt filformat för bilder, exempelvis JPEG för fotografier eller PNGför bilder som innehåller färre färger eller är transparenta.Använd inte högre bildkvalitet än nödvändigt; ju högre kvalitet destostörre blir filerna.Använd inte bilder eller videofilmer i större dimensioner/upplösning ännödvändigt.

Komprimera bilderna för att minska storleken. Använd en bildkomprimerareför att ta bort onödig bildinformation som många bildhanteringsprogramsparar. Exempel på verktyg är Tiny PNG och SVGOMG.

Minska datamängden genom att komprimera filer och minifiera ellerstäda i kodEtt effektivt sätt att minska datamängden mellan servern och klienten är attkomprimera den. Ställ in webbservern på att använda gzip-komprimering(via content negotiation, eftersom inte alla klienter har stöd för tekniken) förtextbaserade filtyper (HTML-dokument, stilmallar, script).

Det dyker nu och då upp nya komprimeringsformat som är bättre än

Vägledning förWebbutveckling Sida 115 /

316

Page 117: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

tidigare, till exempel på grund av högre komprimeringsgrad, snabbarekomprimering eller mer öppet format. Ett exempel på detta är WebP somkan användas för komprimering av bilder. Även HTTP/2 komprimerar(header-)data. Nya format tar dock en stund innan de fungerar i allutrustning. Utnyttja gärna de bättre formaten om ni har kapacitet attsamtidigt erbjuda äldre format så länge det behövs för att inte utestängaanvändare.

Även om det tar tid att komprimera och dekomprimera filer tjänar bådeserver och klient på tekniken eftersom det blir mindre data att föra över,vilket vanligen är det som utgör flaskhalsen.Kod på webben (html, css, javascript) kan i många fall ”minifieras”, det villsäga bearbetas på ett sätt som gör att onödiga mellanslag och annatinnehåll som inte påverkar presentationen rensas bort eller ersätts avkompaktare alternativ. Det finns verktyg som minifierar kod automatiskt.Nackdelen är att koden brukar bli svårare att läsa, men det är inte alltid ettproblem. Dessutom finns verktyg som kan indentera och göra minifierad kodnågorlunda läsbar igen.

Det är tyvärr fortfarande vanligt att såväl publiceringsverktyg somutvecklarramverk genererar mycket onödig kod, och även manuellt skapadkod kan ha innehåll som inte behövs. Ofta kan en städning av koden minskafilstorleken och dessutom göra den lättare att underhålla.

Utnyttja cache-funktioner på rätt sättPrincipen för cache-funktioner är enkel: se till att klienten inte behöverhämta samma resurs flera gånger, om det inte behövs! Det finns mångaolika typer av cachning: i webbpubliceringsverktyget (CMS-system), påwebbservern, framför webbservern, i så kallade Content Delivery Network(CDN), i användarens webbläsare och så vidare.

Använd cacheminnet i användarens webbläsare genom att sätta bäst före-datum på samtliga av webbplatsens filer. Då behöver inte en återvändandeanvändare ladda ner oförändrade filer på nytt om återbesöket är inomtidsspannet för filens bäst före-datum.

Tänk på att olika typer av resurser kan behöva olika cache-inställningar.Eftersom stilmallar och skript bara uppdateras ibland är de lämpliga atthantera som små paket, vars filnamn kan numreras. När en ny fil dyker upppå webbplatsen förbigår den tidigare cachade filer, vilket gör att dessa filerkan ha riktigt lång giltighet. En sida som genereras dynamiskt (till exempelutifrån innehåll i en databas) kan bara vara giltig så länge som allabeståndsdelar är oförändrade. Helt statiskt innehåll kan vara giltig mycketlängre (månader).

Skicka korrekta statuskoder enligt HTTP-standarden. Exempelvis HTTP-kod304 som berättar för webbläsaren att filen på servern har ett identisktinnehåll som den fil användaren redan har tagit emot och som därmed intebehöver skickas igen.

Vägledning förWebbutveckling Sida 116 /

316

Page 118: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Generella resurser går ofta att hämta från centrala lagringsplatser.Exempelvis finns Javascript-biblioteket jQuery att hämta från GoogleLibraries API, Microsoft AJAX CDN och jQuery CDN. Genom att hänvisa tillsådana ökar sannolikheten något för att klienten redan har resursen i sincache, och därmed inte behöver hämta den på nytt. Dessutom minskar detdatatrafiken över era servrar.

För webbplatser med höga krav på robusthet, säkerhet och integritetsskydd(till exempel många myndigheters webbplatser) bör sådana lösningaranvändas med försiktighet, eftersom de skapar beroende av externa parter,ofta i andra länder. Att istället själv drifta ett CDN kan eventuellt vara ettalternativ.

Observera att det finns olika grader av beroende: I vissa sammanhang kansidan besökas även om den externa resursen inte går att hämta (eller ärförändrad), medan det i andra sammanhang bara påverkar en del av sidansfunktionalitet.

Läs mer om tredjepartsinnehåll i R67 Se till att infogade externa tjänsterföljer webbriktlinjerna.

Tänk på hur sidan laddasMånga webbplatser är uppbyggda så att användaren inte kan börjainteragera med en sida förrän hela sidan har laddats in och renderats. Oftaberor det på Javascript och CSS-selektorer som gör att webbläsaren måsterita om sidan flera gånger. Tänk därför igenom hur användaren påverkas avrenderingen och om en del av beräkningarna istället kan göras på servernistället för i webbläsaren. Se även R93. Använd Javascript för att ökatillgängligheten – inte tvärtom.

MätbarhetDe flesta moderna webbläsare har inbyggda utvecklarverktyg som kan visahur lång tid det tar att hämta olika resurser som ingår i en webbsida. Oftafinns en tidslinje som visar vilka filer som tar lång tid att ta emot.

Schematisk bild av tidslinje-visning som finns i många utvecklarverktyg. Enbrant lutning bör eftersträvas eftersom det innebär kort väntetid.

VerktygDet finns också bra verktyg som kan ge en bild av hur välbyggd enwebbplats är utifrån prestandasynvinkel. Några exempel finns på vår sidamed tips på verktyg för automatisk granskning.

Som underlag för jämförelse kan nämnas att en undersökning av drygt 500webbplatser inom svensk offentlig sektor gjordes i oktober 2016 medutgångspunkt i Google Pagespeed 2.0. Mätt med en mobilanvändaresbehov var genomsnittet 62 poäng av 100 möjliga. Googles riktlinje för brawebbprestanda är 85 av 100.

Vägledning förWebbutveckling Sida 117 /

316

Page 119: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningCSS Sprites: Image Slicing’s Kiss of DeathCaching Tutorial for Web Authors and WebmastersGoogle PageSpeedBrotli för att komprimera udda teckensnittHTTP/2 förklarat av Daniel Stenberg finns på svenskaHigh performance browser networking är en relevant bok av IlyaGrigorik som finns att läsa gratis på nätet.Designing for performance är en mindre teknisk bok på samma temaav Lara Callender Hogan. Också den finns att läsa på nätet.ETSI-riktlinjer för kognitiv mobil tillgänglighet (pdf, i avsnitt 12.4.6 finnsrekommendationer om svarstider)Video: Fast and resilient web appsVideo: Om hur man bygger webbplatser som inte är så beroende avuppkoppling till nätet och använder webbläsarens cacheminne fullt utFörklaring: Vad är en cache?

Terminologi

RobustI webbsammanhang har robusthet två olika betydelser. Dels är det enav principerna i WCAG 2.1 (som handlar om kompatibilitet medstörsta tänkbara variation av user agents), dels handlar det iprestandasammanhang om den infrastruktur som behövs för att enwebbplats varken ska bli långsam eller gå ner.

ResilientEn resilient webbplats är motståndskraftig mot hög belastning.

LastSå många användare med genomsnittligt beteende som webbplatsenkan hantera.

CacheDet är ett sätt att mellanlagra information på strategiska platser. Närdet gäller webben brukar cache ofta exemplifieras genom detcacheminne som finns i besökarens egen dator, den så kalladewebbläsarcachen. Det gör upplevelsen snabbare om material som inteuppdaterats istället återanvänds från den egna datorns minne iställetför att hämta på nytt över internet. Cache kan kallas för buffert påsvenska, men det engelska ordet är nog vanligare än det svenska itekniska sammanhang.

CDNCDN står för Content Delivery Network, eller ibland ContentDistribution Network. CDN används ibland för att öka prestandagenom att bygga upp en cache-funktion i nätet så att flera webbplatserkan hänvisa till samma filer. Om besökaren varit på webbplats A ochladdat ner den senaste Jquery-filen behöver den inte laddas ner pånytt vid besök på webbplats B – förutsatt att webbplatserna användersamma CDN. Ytterligare en fördel med CDN är att resurser kanhämtas från servrar som geografiskt befinner sig närmare användaren,

Vägledning förWebbutveckling Sida 118 /

316

Page 120: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

vilket också påverkar svarstiden.CMS

Content Management System, det vill säga publiceringssystem. Vissapubliceringssystem har omfattande funktioner för till exempelautomatisk anpassning av bildfilers upplösning till mottagarens skärmeller uppkoppling, avancerad cachning och så vidare.

WebPEtt exempel på bildformat som är skräddarsytt för webben. Brotli är ettexempel på generellt komprimeringsformat.

AMPAccelerated Mobile Pages är ett Googleprojekt som tagit fram en sortsbegränsade webbsidor (där bara delar av html, css och javascriptanvänds) som kan laddas mycket snabbt i mobilen. AMP ger godprestanda, men nackdelen är att det inte är en standardlösning. (SeR80. Följ standarder.) Dessutom fungerar AMP i dagsläget bara iomedelbar anslutning till Googlesökning.

StressHur väl fungerar systemet när man belastar det så mycket att det intelängre kan hantera mängden anrop. (Det man främst kontrollerar vidstresstest är att systemet inte levererar felaktiga data alternativtöppnar upp för intrång.)

TTLTime To Live. Används i olika tekniska sammanhang för att ange hurlänge en viss resurs (till exempel en fil, en uppkoppling eller ettdatapaket) ska anses vara giltig. I webbsammanhang motsvaras dettaibland av max-age. När tiden passerat byter systemen strategi, oftast

genom att ”börja från början”.

Senast uppdaterad: 2018-05-03

Prio 1

Skapa tydliga och klickbarafältetiketterFör varje fält i ett formulär där användarna ska fylla i information, skapa entydlig fältetikett (label) som förklarar fältets funktion.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign

För varje fält i ett formulär där användarna ska fylla i information, skapa entydlig fältetikett (vanligtvis elementet label) som förklarar fältets funktion.

Men skriv inte mer information än vad som är nödvändigt, eftersom det kan

Riktlinje nr 55

Vägledning förWebbutveckling Sida 119 /

316

Page 121: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

göra att formuläret upplevs som rörigt och komplicerat.

Genom att i kod (med hjälp av for-attributet på label-elementet) koppla

etiketten till fältet kan användare markera fältet även genom att klicka påetiketten, vilket ökar den klickbara ytan. Genom kopplingen blir det ävenmöjligt för en person som saknar en visuell presentation att veta vilkenetikett som hör till vilket fält, eftersom skärmläsare läser upp etiketten närfältet får fokus.

Om det behövs utförliga instruktioner, placera dessa i första hand iinledningen av formuläret.

Rekommendationer för fältetiketter/ledtexter iformulär

Skriv tydliga och informativa fältetiketterKoppla ihop fältetikett och inmatningsfält så att även etiketten blirklickbar.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.Undvik att göra lösningen beroende av title-attribut och placeholder-texter.

Skriv tydliga och informativa fältetiketterMålet är att det ska vara enkelt för användarna att förstå vilken informationde ska fylla formulärets fält med, och hur de ska göra det. Se R61. Skrivbeskrivande rubriker och etiketter.

Särskilt viktigt är att tydligt ange vilka fält som är obligatoriska. Se R101.Markera obligatoriska fält i formulär.

Skriv fältetiketter till kryssrutor så att det tydligt framgår vad det innebär omkryssrutan är ifylld respektive tom. Skriv i jakande form, till exempel ”Ja, jagvill få nyhetsbrevet via e-post”. Undvik kryssrutor där användaren ska väljabort någonting, till exempel ”Nej tack, jag vill inte ha nyhetsbrevet via e-post”.

Koppla ihop fältetikett och inmatningsfältFör de flesta webbläsare kan ni koppla ihop fältetiketten ochinmatningsfältet så att etiketten blir klickbar. Då räcker det att användarenklickar på etiketten för att fokus ska hamna på inmatningsfäletet (för textfältinnebär det att markören hamnar i skrivfältet). Därmed blir den klickbaraytan för fältet större, vilket underlättar för användarna. Dessutom blir detmöjligt för hjälpmedel, till exempel skärmläsare, att koppla rätt etikett tillrespektive fält. Det vanligaste är att använda label-element för att skriva

fältetiketter. Koppla etiketten till rätt inmatningsfält genom att i for-attributet

för label-elementet ange id för fältet den ska kopplas till.

Ibland kan det istället vara bättre att ange en gemensam etikett (legend)

Vägledning förWebbutveckling Sida 120 /

316

Page 122: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

för en grupp av inmatningsfält (fieldset). Då kan det vara nödvändigt att

komplettera denna med individuella (eventuellt visuellt osynliga) etiketter förvarje enskilt fält. Det kan göras till exempel med aria-labelledby eller

title-attribut. (Se även R121. Ange i kod vad sidans olika delar har för

roll.)

Placera fältetiketterna där användarna lätt ser demTextfält och rullgardinsmenyer: sätt etiketten ovanför eller till vänsterom fältet.Radioknappar och kryssrutor: sätt etiketten till höger om knappen ellerrutan.Personer som använder förstoringshjälpmedel har lättare att seetiketter som placeras nära fältet.Vänsterjustera fältetiketterna.

Skriv utförliga instruktioner före formuläret, när detbehövsUndvik att skriva instruktioner mellan fältetiketten och fältet, eller efter fältet.

Längre textbeskrivningar kan kopplas till rätt inmatningsfält med hjälp avARIA-attributet aria-describedby. Då kan exempelvis en skärmläsare

berätta mer detaljer om ett inmatningsfält när användaren så önskar.

Undvik att göra lösningen beroende av title-attributoch placeholder-texterTitle-texter visas sällan för användare med exempelvis pekskärm.

Placeholder-texter har fördelen att de är sparsamma med utrymme, men

även den stora nackdelen att texten inte längre syns när användaren börjatfylla i någon information i fältet. Använd gärna dessa attribut, men gör intelösningen beroende av informationen.

Utdrag från WCAG-standarden

Riktlinje 3.3 Inmatningsstöd: Hjälp användare att undvikamisstag och rätta till misstag.

3.3.2 Ledtexter/etiketter eller instruktioner: Det finnsLedtexter/etiketter eller instruktioner när innehåll kräverinmatning från användaren. (Nivå A)

Relaterade riktlinjerR50. Minimera antalet fält i formulärR52. Fyll formulär med kända uppgifterR101. Markera obligatoriska fält i formulärR61. Skriv beskrivande rubriker och etiketter

Vägledning förWebbutveckling Sida 121 /

316

Page 123: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Mätbarhet

Gör användningstester på pappersprototyper för att enkelt och billigtundersöka om fältetiketterna är tydliga.

Terminologi

I html kallas formulär för form. Inmatningsfält heter oftast input. Etiketter /ledtexter kallar vi för fältetiketter när de beskriver inmatningsfält.

Senast uppdaterad: 2018-12-05

Prio 2

Låt inte en webbadress sluta fungeraDet finns ett stort värde i de länkar som leder till er webbplats, både föranvändarna som vill kunna hitta den, och för er i sökmotorernas rankning.Se därför till att länkarna fortsätter att fungera även på lång sikt. De ska intesluta fungera om ni byter publiceringsverktyg.

Om denna riktlinjePrioritet: 2Principer: Effektiv, Förtroendeingivande, Åtkomlig över tidRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Bevarande och gallringNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion, Process,Systemutveckling, Testning

Rekommendationer för hållbara webbadresserSkapa teknikoberoende webbadresser, så att länkarna fungerar övertid även om ni byter publiceringsverktyg.Använd rätt statuskoder när ni flyttar, stänger eller slår ihopwebbsidor, så att användarna omdirigeras på rätt sätt.

Skapa teknikoberoende webbadresser

Skapa webbadresserna på ett teknikoberoende sätt så långt det går.Teknikoberoende webbadresser göra det enklare att byta den tekniskaplattformen utan att det påverkar adresserna.

ExempelExempel på teknikberoende länkar:

http://organisationensnamn.se/page.php?id=398&s=49

Riktlinje nr 56

Vägledning förWebbutveckling Sida 122 /

316

Page 124: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

http://organisationensnamn.se/produkter/default.aspx

Exempel på teknikoberoende länkar:

http://organisationensnamn.se/personal/kontaktuppgifter/

http://organisationensnamn.se/produkter/

Använd rätt statuskoder när ni flyttar, stänger ellerslår ihop webbsidor

Om adresser ändå måste bytas är det viktigt att säkerställa att en korrektomdirigering sker från den gamla adressen till den nya. Använd destatuskoder som http-protokollet erbjuder, för att ge webbläsare ochsökmotorer information om vart en sida har flyttats eller om den har tagitsbort. Då kan verktygen dirigera användarna rätt.

Några vanliga statuskoder200 OK – Allt gick bra

301 Moved Permanently – När ni flyttar innehållet permanent.

403 Forbidden – Besökaren har inte rätt att se sidan.

404 Not Found – Innehållet/webbsidan hittades inte.

410 Gone – Innehållet är borttaget, för gott. Gäller även när du slår

ihop två sidor till en.500 Internal Server Error – Internt fel på webbservern.

MätbarhetVerifiera att rätt statuskod skickas för omdirigerade webbsidor. Verktyg somtill exempel LiveHTTPHeaders kan användas.

FördjupningR95 Gör bokmärkningsbara webbadresserR100 Utforma webbadresser med omsorgR99 Skapa korta webbadresser för sidor som ska spridasMer information om statuskoder i standarden RFC 2616.Temasidan om bevarande och gallring.En kartsida från företaget Kodapan visar för kommuners webbplatserhur stor andel av inlänkarna från Wikipedia som fungerar. Det är ingetheltäckande eller vetenskapligt underlag, men påminner om värdet avatt undvika så kallad länkröta, det vill säga inaktuella adresser.

Terminologi

Beständiga webbadresser heter persistent url:s på engelska. Ävenbegreppet permalink förekommer. Omdirigering kallas på engelskaför redirect.

Vägledning förWebbutveckling Sida 123 /

316

Page 125: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-02-08

Prio 3

Låt användarna fylla i information ivalfritt formatAnvändarna ska enkelt kunna fylla i information som efterfrågas påwebbplatsen, utan att få upp felmeddelanden som går att undvika genomprogrammering. Ett vanligt exempel är alla de sätt man kan skriva ettpersonnummer, till exempel 630125-0000 eller 196301250000. Skapafunktioner som ger det ifyllda det format som systemet behöver.

Om denna riktlinjePrioritet: 3Principer: AnvändbarRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Informationssäkerhet, Interaktionsdesign,Systemutveckling, Testning

Rekommendationer för format på indataLåt användarna fylla i information i valfritt format.Undvik att visa felmeddelanden om det går att lösa behovet medprogrammering.Skapa kontrollfunktioner som ger informationen rätt format.Låt systemet ta bort oönskade tecken.

Script kan förenkla för användaren

Skapa funktioner som automatiskt gör att ifylld information formateraskorrekt, i stället för att visa ett felmeddelande när en användare fyllt iinformationen på fel sätt.

Genom programmering går det också att formatera bort oönskadeskiljetecken och liknande som användaren kan ha fyllt i, som mellanslag ochbindestreck.

Tänk dock på att R94. Använd Javascript för att öka tillgängligheten – intetvärtom.

ExempelGör inte som nedanstående bild visar. Låt användarna fylla i valfritt formatoch programmera så att systemet kan ta emot det användaren fyller i.

Riktlinje nr 57

Vägledning förWebbutveckling Sida 124 /

316

Page 126: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningMärk upp vanliga formulärfält i koden (R154)Ge ordförslag vid sökning och inmatning (R112)En anekdot som illustrerar hur hårda krav på rätt format för indata kanupplevas av användare.

Terminologi

Att kontrollera information som användarna fyllt i kallas för att valideraindata. De flesta webbprogrammeringsplattformar har färdiga funktioner(validators) för validering.

Senast uppdaterad: 2018-07-06

Prio 4

Använd standardutseendet påformulärens elementUndvik att ändra utseende på formulärelement som textfält och kryssrutor,så att användarna lätt kan känna igen dem.

Om denna riktlinjePrioritet: 4Principer: Användbar, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

Rekommendationer för utseende påformulärelement

Låt formulärelementen behålla standardutseendet.Gör användningstester för att kontrollera att formulären fungerar, omni trots allt ändrar utseendet.Anpassa storleken på textfält till förväntat innehåll.

Riktlinje nr 58

Vägledning förWebbutveckling Sida 125 /

316

Page 127: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Använd standardkontroller så långt det är möjligtUndvik att ändra färg och form på textrutor och andra formulärelement medcss. Låt alltså webbläsaren eller operativsystemet visa formulärfälten medstandardutseendet. Det är lättare för användarna att inse vad de ska göraom fälten ser ut som de brukar. Dessutom får webbläsarna med html 5 merkontroll över hur till exempel datumväljare och videospelare ser ut.

Att hålla sig till standarden är också det mest kostnadseffektiva.

Det går bra att ha formulärfält i flera spalter, så länge inte utseendet på deenskilda fälten ändras.

Om det finns starka skäl till att ändra på utseendet, gör det med försiktighet,och gör användningstester för att kontrollera att formulären fungerar föranvändarna. Ibland kan till exempel storleken behöva justeras:

Anpassa storleken på textfält till förväntat innehållStorleken på fältet ska anpassas till den information som användarnabehöver fylla i. Låt också användarna tydligt se vad de har skrivit in. Medhjälp av skript kan användarna också få möjlighet att själva öka storleken påtextfältet genom att dra nere i högra hörnet. En del webbläsare har dennafunktion inbyggd. Kontrollera att skriptet fungerar som det ska, och att detinte krockar med någon befintlig funktionalitet.

Kriminalvårdens publikationsbeställning har formulär där storleken på deenskilda fälten är anpassade efter det förväntade innehållet.

Terminologi

Formulärelement är formulärets olika rutor och knappar, till exempel textfält,kryssruta eller OK-knapp.

Senast uppdaterad: 2018-07-11

Vägledning förWebbutveckling Sida 126 /

316

Page 128: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

PrioInaktiv

Anpassa textfältens storlek till detförväntade innehålletDenna riktlinje har slagits ihop med R58. Använd standardutseendet påformulärets element.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Denna riktlinje har slagits ihop med R58. Använd standardutseendet påformulärets element.

Senast uppdaterad: 2017-10-31

Prio 2

Gör tydliga användbara knapparSe till att knappar är lätta att förstå och använda. Namnge knapparna tydligt,och på vedertagna sätt.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning, Testning

Rekommendationer för knapparNamnge knappar så att användarna förstår vad som händer när deklickar på dem.Ge knapparna en logisk och användbar placering.Använd lagom många knappar.Presentera inte knappens text enbart som bild.

Namnge knappar så att användarna förstår vadsom händer när de klickar på dem

Riktlinje nr 59

Riktlinje nr 60

Vägledning förWebbutveckling Sida 127 /

316

Page 129: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Använd gärna verb såsom ”Spara” eller ”Skicka”, ”Beräkna slutpension”eller ”Lägg till ny inkomst”.Om webbplatsen erbjuder olika sökfunktioner, till exempel i databaser, börsök-knapparna vara tydligt och informativt namngivna utifrån sitt syfte.En knapp kan då till exempel heta ”Sök på webbplatsen” och en annan ”Sökblankett”.

Ge knapparna en logisk och användbar placeringPlacera knappar visuellt och flödesmässigt i en logisk ordning, så attanvändarna enkelt kan navigera även med hjälp av tangentbordet.Markera extra tydligt den knapp som tar användaren till nästa steg.Den knapp som tar användaren till nästa steg ska ligga sist påformulärsidan.Se till att ha tillräckligt avstånd mellan knapparna så att det enkelt gåratt skilja dem åt.

Använd lagom många knapparAnvänd inte onödigt många knappar i formulär. Många användare harsvårare att använda komplexa formulär. (Se även Minimera antalet fält iformulär (R50)).

Överväg till exempel att avstå från rensa-knappar i formulär. Risken att enanvändare av misstag rensar alla fält är ofta större än behovet att kunnarensa alla fält.

Men givetvis behövs vissa knappar. Om ett formulär består av flera sidor,bör det finnas knappar för att navigera mellan sidorna. Namnge dem“Föregående” och “Nästa”. Om det finns en ”avbryt”-knapp där ska denavbryta hela flödet, inte bara gå tillbaka till föregående sida i formuläret.I regel ska en sökfunktion för hela webbplatsen finnas med på alla sidor, iglobalmenyn, och ha en tydlig sök-knapp.

Presentera inte knappens text enbart som bildSe Använd text, inte bilder, för att visa text (R128). Ni kan göra undantag omni bedömer att det blir tydligast med en bildknapp, till exempel föraktionsknappar som tydligt visar huvudflödet genom en webbapplikation. Iså fall ska texten i knappen vara 12 px eller större.

Bildbaserade knappar ska ha textalternativ, som behöver formuleras medomsorg, se Möjliggör röststyrning av knappar och kontroller (R162).

FördjupningETSI standard EG 203 150: Guidelines for the design of mobile ICT devicesand their related applications for people with cognitive disabilities (pdf 2,11MB)

Senast uppdaterad: 2018-09-03

Vägledning förWebbutveckling Sida 128 /

316

Page 130: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 1

Skriv beskrivande rubriker ochetiketterBra rubriker hjälper läsaren att hitta i texten. Rubrikerna är särskilt viktiga förpersoner som använder skärmläsare, som kan läsa upp en lista överrubrikerna på en sida. Rubrikerna ska vara lagom långa och sammanfattavad sidan eller avsnittet handlar om. Alltför korta och allmänna rubriker gerinte användarna så mycket hjälp, till exempel ”Inledning” eller ”Aktiviteter”.

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

Beskrivande rubriker, ledtexter och etiketter hjälper användarna att förstå ensidas innehåll och syfte. Rubriker och ledtexter behöver inte vara långa.Ofta kan ett enda ord vara tillräckligt för att beskriva innehållet.

Tydliga beskrivningar är bra för alla användare, men framför allt förpersoner som har lässvårigheter och försämrat korttidsminne eftersom detger det en möjlighet att förutse vad varje del av webbplatsen innehåller. Förpersoner som navigerar med tangentbordet och/eller använder skärmläsareger det en möjlighet att hoppa till olika delar av innehållet.

Rekommendationer för att skriva tydliga rubrikerAnvä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.

MätbarhetRubriker kräver manuell granskning och användningstester. Testa att läsarubrikerna utanför sitt sammanhang och se om det går att förstå vadavsnitten handlar om.

Utdrag från WCAG-standarden

Riktlinje 2.4: Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.6 Rubriker och ledtexter/etiketter: Rubriker ochledtexter/etiketter beskriver ämne eller syfte. (Nivå AA)

Relaterade riktlinjer

Riktlinje nr 61

Vägledning förWebbutveckling Sida 129 /

316

Page 131: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Konkreta rekommendationer för utformning av etiketter/ledtexter i formulärfinns i R55. Skapa tydliga och klickbara fältetiketter.

Se även R98. Skriv rubriker till tabeller och R105. Skapa rubriker med h-element, R135. Skriv beskrivande sidtitlar och R64. Anpassa språket tillläsaren.

FördjupningWebbredaktörens ABCInternetstiftelsen .SE: Att skriva för webben (PDF)Att skriva klarspråk

Senast uppdaterad: 2018-12-05

Prio 3

Gör texterna överskådligaIngångssidan och andra huvudsidor på webbplatsen bör vara relativt korta,för att ge användarna en överblick över innehållet. Undersidor kan innehållalite längre texter.

Om denna riktlinjePrioritet: 3Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texterNär i utvecklingsprocessen?: Innehållsproduktion

Rekommendationer för överskådliga texter påwebben

Låt det som hör ihop stå i ett stycke, som ett resonemang, entanke eller en sakfråga. Stycken kan variera i längd, men tre till tiomeningar är vanligt. Använd alltid blankrad som styckemarkör förwebbtexter.Inled stycket med det viktigaste.Låt gärna den första meningen sammanfatta stycket och utvecklasedan resonemanget med förklaringar och exemplifieringar.Använd gärna bilder, kant- och mellanrubriker, punktlistor och andragrafiska 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 deviktigaste listpunkterna först.I längre texter kan fetade nyckelord underlätta läsningen.

Långa texter

Riktlinje nr 62

Vägledning förWebbutveckling Sida 130 /

316

Page 132: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Ibland kan längre texter bli lättare att överblicka om de delas upp på flerasidor. Längre texter kan också presenteras som ett sammandrag, med denfullständiga texten i en separat nedladdningsbar fil.

MätbarhetDetta kräver manuell granskning och användningstester. Gå igenom texten,kontrollera styckeslängd och styckesindelning och leta efter uppräkningarsom kan göras om till punktlistor.

Fördjupning

Se även R39. Ge webbplatsen en god läsbarhet och R104. Gör listor medde html-element som är till för att skapa listor.

Webbredaktörens ABCInternetstiftelsen .SE: Att skriva för webben (PDF)Skrivråd från Centrum för lättläst

TerminologiEnligt Centrum för lättläst är behovet av enklare texter är stort. Drygt 13procent av Sveriges vuxna befolkning är svaga läsare. De har ett stortbehov av mer lättillgängliga texter.

Lättlästa och begripliga texter är bra för personer som är läsovana eller somhar ett annat modersmål än svenska. En funktionsnedsättning eller sjukdom,som till exempel adhd, afasi eller demens kan också göra att man har behovav enklare texter.

Senast uppdaterad: 2014-09-25

Prio 3

Visa var i en process användarenbefinner sigVisa användarna tydligt var de befinner sig, när de tar sig igenom enprocess, till exempel om de håller på att göra en anmälan eller beställning iflera steg. Risken är annars att de blir osäkra och frustrerade, och i värstafall väljer att avbryta processen.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Tillgänglighet

Riktlinje nr 63

Vägledning förWebbutveckling Sida 131 /

316

Page 133: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning

Rekommendationer för processflödenVisa 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.

ExempelStockholm stads tjänst för att anmäla matförgiftning visar användarna var iprocessen de befinner sig.

Process som visar användaren befinner sig

Relaterade riktlinjerErbjud besökaren alternativa orienteringsstöd (R32)Visa tydligt var användaren befinner sig (R27)

Senast uppdaterad: 2018-03-08

Prio 2

Skriv lättbegripliga texterTexter på webbplatser bör skrivas på ett så enkelt och begripligt språk sommöjligt, för att vara effektiva att läsa, och för att kunna förstås av ett stortantal läsare.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Målgruppsanalys

RekommendationerSkriv korta raka meningar, där det viktigaste verbet kommer tidigt.Undvik långa och invecklade meningar och långa, informationstätafraser.Välj aktiva verbfraser med tydliga subjekt. Skriv hellre”miljöförvaltningen behandlar 200 anmälningar per år” än ”200anmälningar per år behandlas”.Använd ett personligt tilltal. Använd verb med uppmaningsform, eller”du”.Välj vanliga, välkända och entydiga ord och formuleringar.

Riktlinje nr 64

Vägledning förWebbutveckling Sida 132 /

316

Page 134: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Var konkret, undvik bildspråk.Använd förtydligande sambandsord, till exempel eftersom, men, därföroch alltså.Använd de facktermer som era läsare behöver, och förklara vadtermerna betyder. Gör gärna en separat ordlista intill texten om ni harbåde kunniga och nya läsare.Använd svenska termer. Myndigheter är enligt § 12 i språklagenskyldiga att utveckla och tillgängliggöra svenska termer för sittverksamhetsområde.Skriv ut förkortningar. De stör läsningen. Förkortningar kan dessutomvara svåra att tolka för skärmläsare och andra talsyntestjänster.Låt alltid någon annan ge återkoppling på texten före publicering.

Utgå från användarnas behovTänk på att användarnas förmåga att läsa och ta till sig text varierar kraftigt.Texterna kan behöva anpassas till målgrupper med särskilda behov, tillexempel personer med fysiska eller kognitiva funktionsnedsättningar,personer med annat modersmål än svenska och nationella minoriteter. Detkan ofta vara en god idé att komplettera text med till exempel bilder, filmeroch tal.

Läs mer om detta i R11. Kombinera skrift med ljud, bild och film.

För offentliga verksamheter gäller språklagen som säger att språket ioffentlig verksamhet ska vara vårdat, enkelt och begripligt. Detta gäller allaspråk som används på webbplatsen, inte bara svenska.

Använd punkter i de förkortningar som behövsOm ni trots allt behöver använda förkortningar, skriv dem med punkter, intemed mellanslag: ”t.ex.”, inte ”t ex”. Då delas de inte när de råkar hamna islutet av en rad. Förkortningar som inte är självklart begripliga för alla böralltid förklaras första gången de nämns i en text. Förkortningar kan markerasi html-koden med hjälp av elementet abbr och förklaras med attributet

title.

För kodning av förkortningar i tabeller, se förkorta långa rad- ochkolumnrubriker (R98).

Mätbarhet

Denna punkt kräver manuell granskning och användningstester. Granskagärna texter med stöd av Klarspråkstestet, en webbchecklista för begripligatexter, som finns hos Språkrådet.

FördjupningSkriva för webbenSvenska skrivreglerMyndigheternas skrivregler

Vägledning förWebbutveckling Sida 133 /

316

Page 135: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Klarspråksråd”Klarspråk på nätet” av Helena Englund och Karin Guldbrand (2009),Pagina.Språklag (2009:600)

Terminologi

I Rikstermbanken definieras klarspråk som ”språk som dels är tydligt, delsär begripligt för de avsedda mottagarna”, med en längre anmärkning om hurdetta bör tolkas.

Det finns en internationell arbetsgrupp, International Plain LanguageWorking group (IPLWG), som arbetar för att hitta en gemensam standardför och definition av klarspråk.

Senast uppdaterad: 2014-09-25

Prio 3

Använd ord och termer konsekventVar konsekvent med hur ni använder ord och termer, för att undvikafeltolkningar. Kontrollera konsekvensen i ert ordval på webbplatsen, både itexter och i navigation och funktioner.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

Rekommendationer för konsekvent språkAnvänd konsekvent samma ord för samma sak.Ange gärna hur ni definierar viktiga ord.Sammanställ gärna en ordlista som är gemensam för helawebbplatsen eller organisationen.

Om enhetlighet mellan webbplatserAnvänd de benämningar som denna vägledning rekommenderar. Det bidrartill en ökad enhetlighet mellan webbplatser.

För begrepp som inte tas upp i vägledningen, undersök gärna vilkabenämningar som används hos er och hos andra närliggandeorganisationer, till exempel organisationer inom samma sakområde. Segärna till att ansvaret för terminologin är tydligt inom organisationen.

Myndigheter har enligt språklagen ett särskilt ansvar för att svensk

Riktlinje nr 65

Vägledning förWebbutveckling Sida 134 /

316

Page 136: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

terminologi inom deras olika fackområden finns tillgänglig, används ochutvecklas.

Se även R29. Var konsekvent i navigation, struktur och utformning.

Mätbarhet

Denna punkt kräver manuell granskning och användningstester.

Fördjupning

Se även R64. Skriv lättbegripliga texter och R66. Skriv datum och andrasifferuppgifter konsekvent.

Terminologicentrum har verktyg och kunskap om termer och definitioner:www.tnc.se

Rikstermbanken innehåller många facktermer med definitioner.

Senast uppdaterad: 2014-09-25

Prio 4

Skriv datum och andra sifferuppgifterkonsekventAnvänd ett konsekvent sätt att skriva datum och andra sifferuppgifter. Omdatum presenteras på flera olika sätt kan det vara förvirrande för läsaren,särskilt för personer som får innehållet uppläst av ett hjälpmedel.

Om denna riktlinjePrioritet: 4Principer: AnvändbarRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texterNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign

Rekommendationer för datum och andrasifferuppgifter

Använd publiceringsverktyg och applikationer som tillåter dedatumformat 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.

Riktlinje nr 66

Vägledning förWebbutveckling Sida 135 /

316

Page 137: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Exempel på utformning av sifferuppgifterSkriv i första hand datum enligt mönstret ”(den) 13 december 2013”. Skrivalltid så i löptext. När utrymmet är begränsat, skriv datum med siffror enligtmönstret ”2013-12-13” eller ”13.12.2013”. Ange alltid helt årtal; skriv tillexempel inte ”11-12-13”. Se till att publiceringsverktyg och applikationersom används på webbplatsen tillåter dessa format.

I klockslag ska punkt användas, i andra hand kolon, för att separera timme,minut och sekund. Klockslag och tidsangivelser skrivs i vanlig löptext enligtmönstret ”kl. 9.00–15.30”. Vid hela timmar behöver minuter inte sättas ut:”kl. 9–15”, ”kl. 9–15.30”. Nattider föregås normalt av en förtydligande nolla:”kl. 01–06”.

I listor och tabeller med många tidsuppgifter kan tydlighet och grafiskkonsekvens kräva att alla klockslag har samma format med lika antal siffror:”18.30”, ”01.35”, ”09.00”.

För mycket detaljer kan göra information svårare att ta till sig. Var därförlagom exakt och avrunda normalt tal, till exempel för filstorlekar ochklockslag. För saker som inte inträffat i dag räcker det oftast med datum,utan klockslag. Undantag kan göras när en större precision förväntas, tillexempel för saldo på ett konto, tidtabeller och skattesatser.

Mätbarhet

Denna punkt kräver manuell granskning.

FördjupningSvenska skrivreglerMyndigheternas skrivreglerDatatermgruppen

Senast uppdaterad: 2014-09-25

Prio 3

Se till att infogade tjänster följerwebbriktlinjernaSe till att tjänster som infogas på webbplatsen är användbara, tillgängligaoch följer de lagar och rekommendationer som gäller för webbplatsen iövrigt.

Om denna riktlinjePrioritet: 3Principer: Förtroendeingivande, Tillgänglig

Riktlinje nr 67

Vägledning förWebbutveckling Sida 136 /

316

Page 138: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Det finns gott om tjänster som kan integreras i en webbplats. Statistik- ochsökverktyg, kommentarsfunktioner, kartfunktioner, enkätverktyg ochautomatisk översättning är exempel på tjänster som kan skapa nytta föranvändarna, ofta till en låg kostnad.

Många är noga med att funktioner och innehåll på den egna webbplatsen ärväl testade, men det är lätt att glömma bort att testa sådant som infogas frånexterna tjänster.

Rekommendationer för infogade tjänsterNär en extern tjänst infogas, eller förändras, tänk särskilt på följande:

Utvärdera om tjänsten eller verktyget är användbart och tillgängligt.Informera användarna om vilka tjänster och verktyg som används påwebbplatsen.Kontrollera om information lagras av en extern part och hur denanvänds.Lås inte in information så att det blir svårt att byta verktyg.Använd inte ramar.

Utvärdera om tjänsten eller verktyget äranvändbart och tillgängligtKontrollera för externa tjänster att:

gränssnittet uppfyller grundläggande krav på tillgänglighet ochanvändbarhet.tjänsten är plattformsoberoende. Kan den exempelvis används av enanvändare med en liten skärm? Se vidare R111. Anpassawebbplatsen även för små skärmartjänsten inte avbryter ett flöde som användaren påbörjat, till exempelgenom att visa störande popup-fönster.

Informera användarna om vilka tjänster ochverktyg som används på webbplatsenEn webbplats i offentlig sektor saknar ofta konkurrens. Användarna är därförmer eller mindre tvingade till att använda den för att utföra vissa typer avärenden eller hitta offentlig information. Därför är det extra viktigt att dessawebbplatser respekterar användare som till exempel vill undvika att blispårade av molntjänster som tillhör tredje part.

Informera därför användarna om vilka verktyg som integrerats påwebbplatsen genom att skriva om det på sidan ”Om webbplatsen”. Se R19.Beskriv hur webbplatsen fungerar och vad den innehåller.

Kontrollera om information lagras av en extern part

Vägledning förWebbutveckling Sida 137 /

316

Page 139: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

och hur den användsMånga verktyg lagrar information om användaren och det kan svårt attavgöra om information som samlas in används, delas eller sparas av någonannan än er. Ta reda på hur verktyget eller tjänsten hanterar informationensom samlas in. Vilka får tillgång till informationen? Kom ihåg att informeraom hur informationen lagras på webbplatsen. R20 Informera om hurpersonuppgifter, kakor (cookies) mm hanteras.

Ta också reda på om tjänsten loggar information om användaren somtillsammans med ditt webbinnehåll skulle kunna skapa problem för deraspersonliga integritet. Påverkar till exempel tjänsten eller verktygetmöjligheterna att använda en krypterad anslutning för e-tjänster (R7)

Lås inte in informationen så att det blir svårt för eratt byta verktygKontrollera att eventuell information som sparas i tjänsten går att överföra tillett annat verktyg eller tjänst om ni skulle vilja det. Risken finns annars att nisitter fast i en lösning som kanske plötsligt blir dyrare att använda ellerutvecklas mot ett håll som ni inte vill.

Kontrollera också om användarna måste godkänna något avtal för attanvända tjänsten. Eller om verktyget kräver medlemskap i någon annantjänst. Är det i så fall rimligt att anta att användarna kommer att teckna ettmedlemskap eller att de redan är medlemmar?

Använd inte ramarAnvänd i första hand serverbaserade tekniker för att infoga innehåll i sidor.Använd inte ramar (frames). Ramar orsakar nämligen en rad problem medanvändbarhet och tillgänglighet. Läs mer om hur tjänster och innehåll kaninfogas i webbsidor i R94 Använd inte ramar

Mätbarhet och verktyg för att undersökatredjepartstjänsterUtvärdera den externa tjänsten eller verktyget med hjälp av övriga relevantawebbriktlinjer och genomför användningstester med dina målgrupper för attsäkra tjänstens användbarhet.

På sidan om automatiska testverktyg finns några tips som kan hjälpa dig attta reda på hur tredjepartstjänster används på dina webbplatser.

Fördjupning: kartläggning av spårningsfunktionerI september 2015 gjorde Dagens nyheter (DN) en kartläggning avspårningsfunktioner på kommuners, myndigheters och landstingswebbplatser. Ett halvår efter granskningen hade många byggt om sinawebbplatser och slutat använda framför allt tredjepartsfunktionen AddThis.Dagens nyheters artikel berättar om såväl kartläggningen som hurspårningen fungerar.

Vägledning förWebbutveckling Sida 138 /

316

Page 140: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TerminologiAtt infoga en extern tjänst kallas ibland för att integrera eller bädda in(integrate respektive embed på engelska). Funktionerna kallas ibland för“widgets”, men sker integrationen på serversidan förekommer termer som“portlet” och “plug-in”. Tredjepartsleverantörer heter på engelska third partyproviders. Det handlar i regel om så kallade molntjänster (cloud services).

Senast uppdaterad: 2018-09-03

Prio 1

Skapa kortkommandon medvarsamhetKortkommandon kan göra att det går snabbare att navigera på webbplatsen,men de bör användas med försiktighet.

Det finns en risk att webbplatsens kortkommandon förväxlas medkortkommandon som användarens webbläsare, operativsystem ellerhjälpmedel erbjuder. Kortkommandon som bara består av ett tecken kandessutom orsaka problem för personer som använder röststyrning ellerråkar klicka på fel tangent, exempelvis på grund av skakningar i händerna.

Riktlinjen påverkar inte funktioner såsom listboxar och rullgardinsmenyerdär användare kan göra sitt val genom att en eller flera tangenter trycksned, eftersom detta bara går att göra när komponenten är i fokus.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

Rekommendationer för kortkommandonAnvä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 barabestår av ett tecken.

Använd kortkommandon sparsamtHTML ger med attributet accesskey möjlighet att skapa kortkommandonsom ger besökare möjlighet att med en enda knappkombination hoppadirekt till huvudinnehåll, sökfunktion eller liknande centrala funktioner.Kortkommandon kan även skapas på andra sätt. Till exempel medjavascript.

Riktlinje nr 68

Vägledning förWebbutveckling Sida 139 /

316

Page 141: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Kortkommandon kan vara en stor fördel för personer som använderskärmläsare och inte vill lyssna igenom samma menyer för varje ny sidautan kunna hoppa direkt till huvudinnehåll och andra viktiga funktioner.

För de delar av webbsidor som är allra vanligast (huvudinnehåll,sökfunktion, navigation och några till) behöver du inte längre skapa någraskräddarsydda kortkommandon. Använd istället så kallade landmärken. SeErbjud möjlighet att hoppa förbi återkommande innehåll (R75). Dessutomfinns det risk för förvirring när kortkommandon som webbplatsen erbjuderkrockar med kortkommandon som användarens dator erbjuder.

Informera om vilka kortkommandon ni erbjuderDokumentera och berätta för användaren vilka kortkommandon somfungerar på webbplatsen, och hur de aktiveras. Informationen kanpresenteras exempelvis efter första tab-tryck eller på sidan ”Omwebbplatsen”.

Se till att samma kortkommandon fungerar på samtliga av webbplatsenssidor.

Använd vedertagna tangentkombinationer omsådana finnsOm webbplatsen saknar något av innehållet i listan nedan, koppla ingetkortkommando till motsvarande tecken.

Flera webbläsare använder bokstäver för kortkommandon. Till exempelanvänds S för menyalternativet Visa i den svenska versionen av InternetExplorer. Användaren kan dock använda S både för att menyalternativetVisa och för att hoppa direkt till innehållet. För Visa trycker användaren förstpå tangenten alt, släpper denna och trycker sedan S. För att hoppa tillinnehållet trycker användaren alt + S (samtidigt) och aktiverar sedan valetmed enter.

Lista över kortkommandon

Kortkommando Objekt (sida) Kommentar

SHoppa över navigering,gå direkt tilltextinnehållet

Använd hellre standard-märkning (elementet eller rollen”main” för huvudinnehåll).

0 Om webbplatsen,tillgänglighetsinformation

Ge en förteckning översnabbkommandon

1 Startsida

2 Nyheter Samlingssida för nyheter

3 Innehållsöversikt Webbkarta, i andra hand A-Ö

4 SökfunktionKopplas till sökfältet som sökerpå hela webbplatsen. Användhellre rollen ”search”.

Vanliga frågor och svar

Vägledning förWebbutveckling Sida 140 /

316

Page 142: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

5 (FAQ)

6 Hjälp Till exempel om en specifiktjänst.

7 Kontakta ossSida med kontaktuppgifter tillviktiga funktioner påmyndigheten.

8 Juridisk informationSida som beskriver hurpersonuppgifter hanteras påwebbplatsen (se R20.).

Gör det möjligt att stänga av eller byta utkortkommandon som bara består av ett teckenDen som exempelvis använder röststyrning kan oavsiktligt råka aktiverakortkommandon om dessa endast består av ett tecken. Exempelvisbokstaven “I” motsvarar ju det engelska ordet för “jag” och därför är detolyckligt om detta ljud kopplas till ett kortkommando.

Utdrag från WCAG-standarden

Riktlinje 2.1 Tillgängligt via tangentbord: All funktionalitet skavara åtkomlig med ett tangentbord.

2.1.4 Character Key Shortcuts If a keyboard shortcut isimplemented in content using only letter (including upper- andlower-case letters), punctuation, number, or symbol characters,then at least one of the following is true:

Turn offA mechanism is available to turn the shortcut off;

RemapA mechanism is available to remap the shortcut to use one ormore non-printable keyboard characters (e.g. Ctrl, Alt, etc);

Active only on focusThe keyboard shortcut for a user interface component is onlyactive when that component has focus.

(Nivå A)

Exempel

För att ge ett objekt ett snabbkommando, lägg till attributet accesskey, tillexempel till en länk eller ett formulärfält.

<a href="kontakt.html" accesskey="7">Kontakta oss</a>

Mätbarhet

Vägledning förWebbutveckling Sida 141 /

316

Page 143: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Kontrollera att samtliga snabbkommandon går till respektive objekt.

TerminologiKortkommando, på engelska shortcut, kallas även ibland försnabbkommando. Det innebär att en tangent, ensam eller i kombinationmed andra, ger användaren möjlighet att direkt utföra en funktion utan attleta upp den i ett menysystem. I windows kan man till exempel trycka in ctrl+ c för att kopiera.

Senast uppdaterad: 2018-12-28

Prio 4

Ta fram en policy för domännamnValet av domännamn har betydelse för att användarna enkelt ska kunnahitta och ta sig till er webbplats. Ta fram en domännamnspolicy. Utred vilkadomännamn som kan vara relevanta för er organisation, så undviker ni attregistrera domännamn i onödan och hjälper användare att hitta till erinformation.

Om denna riktlinjePrioritet: 4Principer: Effektiv, Förtroendeingivande, Åtkomlig över tidRoller/arbetsuppgifter: Inköpare och beställare, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Målgruppsanalys, Process

Rekommendationer för domännamnRegistrera i första hand domännamn under den svenska toppdomänen.se.Registrera domänen för det fulla organisationsnamnet både med ochutan svenska tecken, till exempel örebrokommun.se ochorebrokommun.se.Registrera det vanligt förekommande kortnamnet med och utansvenska tecken, till exempel orebro.se och örebro.se.Skyddsregistrera inte felstavningar och andra toppdomäner om detinte är nödvändigt för att minimera risker för användarna.Bevaka registreringstiden för domännamnet och se till att det finnsrutiner för att förnya registreringar av domännamn.Beskriv vem som är ansvarig för hantering av domännamn i erorganisation.

Huvudsakligt domännamn

Bestäm vilket av era registrerade domännamn som ska användas som

Riktlinje nr 69

Vägledning förWebbutveckling Sida 142 /

316

Page 144: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

huvudsakligt domännamn och omdirigera övriga mot denna. Dethuvudsakliga domännamnet bör ha formen utan å, ä och ö eftersomanvändare i vissa situationer fortfarande kan ha problem med att skriva indomännamn med svenska tecken. Se även R100. Använd kortabokmärkningsbara adresser som berör detta ämne.

Senast uppdaterad: 2014-09-25

Prio 4

Skydda användaren mot att oavsiktligtförlora påbörjat arbeteEtt särskilt problem med e-tjänster är att användaren inte är ”inlåst” igränssnittet på samma sätt som i en vanlig applikation. Tvärtom är det påwebben lätt att av misstag lämna en inmatning man påbörjat, utan attavsluta eller uttryckligen avbryta den. För att motverka det kan e-tjänsteranvända sig av skyddsnät eller tunnlar.

Om denna riktlinjePrioritet: 4Principer: Användbar, Effektiv, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Rekommendation för att undvika förlust avarbetsinsats

Låt om möjligt användaren själv avgöra när information som redigeratseller matats in i ett formulär ska överges.

Så skyddar du användaren från att förlora inmatadinformation

Den mest sofistikerade lösningen är att hänga upp ett skyddsnät kringanvändaren. Det är ett javascript som märker om användaren är på väg attlämna ett påbörjat arbete och då visar en dialogruta som frågar användarenom hon verkligen vill avbryta.

Eftersom skyddsnätet är en hjälpfunktion bryter det inte mot rådet att intevara beroende av javascript (i R93. Använd Javascript för att ökatillgängligheten – inte tvärtom).

En mindre bra lösning är en tunnel som fungerar på samma sätt som envägtunnel – när man kört in i den finns det inget sätt att lämna vägen, manmåste följa den tills man kommer ut i andra änden. Detta sker genom att e-tjänsten rensas från alla länkar och knappar utom dem som behövs för att

Riktlinje nr 70

Vägledning förWebbutveckling Sida 143 /

316

Page 145: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

styra den.

Eftersom avsikten inte är att låsa in användaren, bara att hindra henne frånatt av misstag förlora jobb hon gjort, måste det också finnas en Avbryt-funktion, som låter henne lämna tunneln.

Relaterade riktlinjer

Läs mer om Avbryt-knappar i R60. Gör tydliga användbara knappar. Dennametod medför dock en hel del av de risker som tas upp i R74. Integreraexterna tjänster så att de smälter in.

Exempel

En dialog-ruta varnar användaren att hen är på väg att avbryta sin anmälanav en stöld. Exemplet är från polisen.se.

Senast uppdaterad: 2018-07-06

Prio 3

Bestäm om e-tjänsten behöver e-legitimation och signeringOm era webbtjänster hanterar personlig information, kan användarnabehöva identifiera sig och signera med en e-legitimation. Ta beslut om detinnan ni bestämmer hur flödet genom e-tjänsten ska se ut.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,

Riktlinje nr 71

Vägledning förWebbutveckling Sida 144 /

316

Page 146: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Inköpare och beställareNär i utvecklingsprocessen?: Informationssäkerhet, Interaktionsdesign,Process, Prototypning, Säkerhet

Rekommendationer för identifiering och signeringKräv identifiering i e-tjänster som visar integritetskänslig information.Visa ärendets uppgifter sammanställda i slutet av e-tjänstflödet, så attanvä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 signaturmed namnteckning.

Identifiering i e-tjänster som visar integritetskänsliginformationMånga e-tjänster visar integritetskänsliga uppgifter om användarna – tillexempel lön eller hur långt handläggningen i deras ärende har kommit.Innan tjänsten visar sådana uppgifter måste den säkerställa att personen viddatorn verkligen är den hon utger sig för att vara. Användarna måstelegitimera sig med en e-legitimation för att bli säkert identifierade. Omtjänsten inte visar integritetskänslig information behövs inte en sådanidentifiering.

Visa en sammanställningNär användaren gjort i ordning sitt ärende och ska skicka in det, är det braatt först visa en sammanställning, så att hon kan kontrollera att de ifylldauppgifterna är korrekta. Se R150. Ge möjlighet att ångra, korrigera ellerbekräfta vid viktiga transaktioner

Signatur med juridisk statusNär användaren granskat och är nöjd, ”signerar” hon sitt ärende genom attåterigen identifiera sig, så att tjänsten verkligen är säker på att användarenär rätt person. För att det ska räknas som en signatur i juridisk meningmåste användaren vara medveten om att det sker. Den förstaidentifieringen räcker alltså inte som signatur även om det rent teknisktkanske är samma sak som sker vid både identifiering och signatur. Slutligenskickar användaren in handlingen. Ofta kan ”att underteckna” och ”attskicka” slås ihop. I så fall använder ni bara signera-symbolen.

FördjupningLäs mer om e-legitimation på E-legitimationsnämndens webbplats.

Referenser

Esamverkansprogrammets juridiska vägledning för verksamhetsutveckling

Terminologi

Vägledning förWebbutveckling Sida 145 /

316

Page 147: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Termen e-legitimation syftar på att man som användare kan legitimera sigelektroniskt med en signatur, till exempel när man använder en e-tjänst sominnehåller sekretessbelagda uppgifter. Svensk e-legitimation är namnet påett så kallat tillitsramverk för e-legitimation som E-legitimationsnämnden harskapat. Man ska som användare vara säker på att man använder en säkerelektronisk signering och/eller identifiering om man använder sig av ensvensk e-legitimation. I skrivande stund är BankID den största e-legitimationen i Sverige.

Senast uppdaterad: 2017-06-24

PrioInaktiv

Kräv inte säkrare inloggning än vadinformationen kräverNär ni väljer om en e-tjänst ska ha stöd för identifiering eller signering ska nita hänsyn till vilken information det gäller. Ha inte en för hög säkerhetsnivå.Det blir onödigt krångligt för användarna. Ha givetvis heller inte en för lågsäkerhet som kan få negativa konsekvenser för användarna.

Om denna riktlinjePrioritet: InaktivPrinciper: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Informationssäkerhet, Interaktionsdesign,Process, Prototypning, Säkerhet

Riktlinjen är tillfälligt inaktiveradDen kommer att moderniseras och troligen återpubliceras senare. Just nufinns riktlinjen inte med i checklistor och sökresultat, och ska inte indexerasav sökmotorer.

Rekommendationer för identifiering vid e-tjänsterUtred vilken säkerhet ni behöver, inför ert val av skyddsnivå förinloggningen. Analysera vilka typer av information tjänsten skahantera, vad som kan vara känsligt i dem och vad eventuella relevantalagar kräver. Fråga också era målgrupper hur pass känslig deupplever att informationen är.Om en e-tjänst inte kräver säker identifiering för inloggning, erbjudmöjligheten att vara helt anonym.Även om en e-tjänst inte kräver inloggning kan ni välja att geanvändaren möjlighet att logga in så att vissa uppgifter i formuläretfylls i automatiskt.

Olika typer av identifiering

Riktlinje nr 72

Vägledning förWebbutveckling Sida 146 /

316

Page 148: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

E-legitimation är en vanlig metod för identifiering med hög säkerhet vidinloggning. Det finns dessutom ett stort antal andra möjligheter föridentifiering – med varierande säkerhet. Ett exempel är Facebook-inloggning.

Referenser

Se E-legitimationsnämndens webbplats för information om Svensk e-legitimation.Se även R71. Bestäm om e-tjänsten behöver e-legitimation och signering.

Senast uppdaterad: 2017-12-18

Prio 4

Var tydlig med förutsättningar för attkunna använda e-tjänstenAnvändarna ska inte behöva avbryta en process för att de inte har förberettinformation som krävs för att slutföra processen. Var tydlig med vilkeninformation som tjänsten kommer att begära.

Om denna riktlinjePrioritet: 4Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texterNär i utvecklingsprocessen?: Interaktionsdesign, Process, Prototypning

Rekommendationer om information till e-tjänsterBeskriv vid tjänstens ingång vad användaren måste ha tillgång till föratt kunna slutföra tjänsten.Ge möjlighet att titta igenom hela tjänsten utan att logga in, och utanatt få varningar för att obligatoriska fält inte är ifyllda. Gärna via enspeciell ingång, där det inte är möjligt att fylla i uppgifter. Dettaminskar risken för att användaren ändå börjar fylla i formuläret meninte kan slutföra transaktionen.

ExempelInformation för ansökan om bygglov på orebro.se:

Riktlinje nr 73

Vägledning förWebbutveckling Sida 147 /

316

Page 149: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-07-06

PrioInaktiv

Integrera externa tjänster så att desmälter inTjänster som utvecklas och driftas externt blir allt vanligare. Även tjänstersom utvecklas internt utvecklas ofta i separata system, och är skilda frånwebbplatsen. Sträva efter att integrera dem på webbplatsen så pass mycketatt användaren inte upplever att de är fristående och så att de inte sermärkbart annorlunda ut. De ska smälta in i det grafiska formspråket och inteha andra interaktionsmönster än webbplatsen i övrigt. På så vis förbättrar nianvändarupplevelsen och tillgängligheten på webbplatsen.

Om denna riktlinjePrioritet: InaktivPrinciper: Användbar, Effektiv, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

Riktlinjen inaktivSe istället de närbesläktade riktlinjerna

Se till att infogade externa tjänster följer webbriktlinjerna (R67)Använd inte ramar (R94)

Beslutat efter samråd med referensgruppen 2018-05-28.

Rekommendationer för att integrera tjänster och

Riktlinje nr 74

Vägledning förWebbutveckling Sida 148 /

316

Page 150: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

applikationerSträva alltid efter att integrera enklare informations-, sök- och e-tjänster iwebbplatsen. Det är inte lika nödvändigt för tekniskt avanceradewebbapplikationer.

Informationstjänster: Tekniskt enkla tjänster som främst består avtext och bilder. Sträva alltid efter att integrera dem i webbplatsen.Enkla söktjänster: Funktioner som ”sök personer” eller ”sökhandlingar”. Sträva alltid efter att integrera dem i webbplatsen.E-tjänster: Användarna utför något, och ofta skickas informationvidare till handläggare i organisationen. Sträva efter att integrera e-tjänster, om de inte kan klassas som egna webbapplikationer.Webbapplikationer: Större tjänster som kan liknas vid egnaverksamhetssystem. I många fall är det inte rimligt att integrera dessa,då de är för avancerade för att placeras i innehållsytan i webbplatsensmallar. Till exempel ett webbaserat e-postsystem är kanske inte rimligtatt integrera i ett intranät. Utgå ifrån användarnas behov. Blir detenklare att navigera och använda applikationen om den är integrerad,eller blir det svårare för att tjänsten begränsas av att integreras?

ExempelInnan integration av evenemangslista på orebro.se:

Efter integration av evenemangslista:

Vägledning förWebbutveckling Sida 149 /

316

Page 151: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

FördjupningR94. Använd inte ramar tar upp tekniska perspektiv på integration.Se till att infogade externa tjänster följer webbriktlinjerna (R67).Steve Krugs bok ”Don’t make me think” (Pearson ProfessionalEducation 2005) ger en bra förståelse för problematiken.

Senast uppdaterad: 2018-05-29

Prio 1

Erbjud möjlighet att hoppa förbiåterkommande innehållBygg in genvägar i strukturen. Det kan ta lång tid att ta sig till olika delar avett dokument när man navigerar med tangentbord, eftersom man normaltmåste stega sig förbi varje länk. Webbplatser som har ett omfattande ochkomplext menysystem med många länkar kan försvåra avsevärt för mångaanvändare.

Riktlinje nr 75

Vägledning förWebbutveckling Sida 150 /

316

Page 152: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: Användbar, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning, Testning

Utkast publicerat 2018-12-28Uppdatering efter diskussion i referensgrupp.

Kom gärna med synpunkter, antingen i kommentarsfunktionen sist på sidan,med epost till [email protected], eller i Facebookgruppen webbriktlinjer.

För användare som lyssnar igenom en sida med skärmläsare, eller somtabbar sig fram med tangentbord eller någon typ av hjälpmedel tar det långtid att komma förbi till exempel en meny. När samma innehåll dessutomupprepas på flera sidor kräver navigationen betydande ansträngning, ochför vissa användare även smärta, om samma rörelse måste upprepas omoch om igen. Därför ska det alltid finnas möjlighet att hoppa förbi sådantupprepat innehåll.

Rekommendationer för att underlätta navigationmellan sidans delar

Skapa genvägar för att hoppa över delar i strukturen till exempelmenyn, för att komma direkt till sidans innehåll.Skapa rubriker med h-element, eftersom skärmläsare låteranvä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ändaremed exempelvis skärmläsare kan navigera mellan sidans olika delarpå 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 sidanhar.R68. Skapa snabbkommandon vid behov.

Gör genvägar som syns

En webbplats med många menygrupper och block med information kanbehöva flera alternativa genvägar. På enklare webbplatser kan det räcka attge användaren möjlighet att hoppa över hela navigationen för att komma tillinnehållet. En annan teknisk lösning är att placera innehållet först i HTML-koden och i stället tillhandahålla en genväg till navigationen.

Gör genvägarna synliga så ökar chansen att de användare som behöverdem förstår att de finns. Om det är svårt att passa in genvägarna iwebbplatsens form kan ni dölja dem med hjälp av stilmallar. Gör i så fallgenvägarna så att de blir synliga och aktiva när man tabbar till dem. Se

Vägledning förWebbutveckling Sida 151 /

316

Page 153: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R34. Gör länkar och klickbara ytor enkla att använda för alla.

Ge också sidans olika delar tydliga rubriker eller etiketter, gjorda med h-rubriker. Detta hjälper främst användare med skärmläsare. Etiketter somseende användare inte är i behov av kan ni dölja eftersom siddelensfunktion framgår av utseende och sammanhang.

Hjälp användare med skärmläsare att bläddramellan sidans delarFör de delar av webbsidor som är allra vanligast – så kallade landmärken –bör du använda de struktur-element som erbjuds i HTML5, eller i andrahand (om sajten exempelvis inte använder HTML5) motsvarande attribut iARIA. Då kan den som använder skärmläsare enkelt hoppa mellanlandmärkena. Här är en översikt över strukturkod och ARIA-attribut:

Funktion/del av sida

HTML5 strukturelement

(med exempel på aria-label)

ARIA-attribut

(på valfritt element)

Sidhuvud/beskrivningav webbplatsen <header> role=”banner”

Sökfunktion Saknas, använd ARIA! role=”search”

Navigation/meny (kanfinnas flera)

<nav aria-label=”huvudmeny”> role=”navigation”

Huvudinnehåll <main> role=”main”

Andra delar som stårför sig själv.Exempelvis en puffsom informerar omannan sida, eller enruta med friståendeinformation. Kanfinnas flera.

<aside> role=”complementary”

Formulär (dock ejwebbplatsenssökfunktion, se ovan).

<form aria-label=”anmälningsformulär”> role=”form”

Sidfot/beskrivning avsidans huvudinnehåll,exempelvisupphovsrätt,användarvillkor

<footer> role=”contentinfo”

Landmärke somanvänds för attidentifiera regioner påen sida. (kan finnasflera, men användbara för delar som ärså viktiga att debehöver finnas isidnavigation)

<section aria-labelledby=”region1″>

<h2 id=”region1″>rubrikför region 1</h2>

… Innehåll för region 1…

</section>

role=”region”

Om du vill kan du kombinera strukturelement med ARIA (t.ex. <main

Vägledning förWebbutveckling Sida 152 /

316

Page 154: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

role=”main”>), men det är inte nödvändigt.

Läs mer om landmärken hos W3C.

Se även R68. Skapa snabbkommandon för viktiga funktioner och R53.Gruppera formulärets fält.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.1 Hoppa över grupperat innehåll: En metod/funktion finnstillgänglig för att hoppa över grupperat innehåll som upprepas påflera webbsidor. (Nivå A)

Exempel

Region Halland, Huddinge med flera har en genväg till innehållet som visasför alla som börjar tabba, se bild nedan. Dold genväg till navigationen finnsbland annat stockholm.se. Stäng av användning av stilmallar i dinwebbläsare eller tabba. Då framträder länken ”Hoppa till navigering” överstpå sidan.

Riksdagens webbplats använder WAI-ARIA landmark roles. Helsingborgswebbplats använder html5 strukturelement.

FördjupningMer om WAI-ARIA landmark roles.R121. Ange i kod vad sidans olika delar har för roll

Mätbarhet

Kontrollera att synliga genvägar fungerar genom att följa dem. Om ingagenvägar är synliga, börja navigera på sidan med hjälp av tangentbordet.Eventuella genvägar bör då visas när de blir aktiva.

Ta bort stilmallarna, och kontrollera att rubrikstrukturen för sidan är vettigoch att det utifrån den går att identifiera alla delar av strukturen på sidan. Nikan behöva analysera koden.

Vägledning förWebbutveckling Sida 153 /

316

Page 155: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

För att testa WAI-ARIA och HTML5 strukturelement, prova att besökawebbsidan med en modern version av ett skärmläsarprogram, till exempelJaws eller NVDA, i kombination med en modern webbläsare. Användskärmläsarens dokumentation för att ta reda på hur du navigerar mellansidans delar.

Senast uppdaterad: 2018-12-05

Prio 3

Ge e-tjänster namn utifrånanvändarnas perspektivFokusera på det användarna vill uppnå, och använd ord som anknyter tilldet, när du namnger en e-tjänst. Det gör det lättare för användarna att hittatill rätt tjänst.

Om denna riktlinjePrioritet: 3Principer: AnvändbarRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Inköpare och beställareNär i utvecklingsprocessen?: Förvaltning, Målgruppsanalys

Rekommendationer för att namn på e-tjänsterAnvänd till exempel ”ansök om…” istället för ”e-tjänst för…” när dubestämmer namn på din e-tjänst.Blanketter och e-tjänster fyller samma behov för användarna, och bördärför finnas på samma ställe, behandlas parallellt iinformationsmaterial och så vidare.

Mätbarhet

Utvärdera webbplatsen med användare för att säkerställa att terminologin ärbegriplig.

Exempel

Huddinge har tjänster med bland annat följande rubriker:

”Sök bygglov via Huddinges e-tjänst””Ansök om lantmäteriförrättning””Beräkna avgift för förskolan”

Senast uppdaterad: 2018-07-11

Riktlinje nr 76

Vägledning förWebbutveckling Sida 154 /

316

Page 156: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 2

Ge tydlig återkoppling i e-tjänsterGe tydlig återkoppling till användarna i ärenden som utförs via webben oche-tjänster. Vanliga automatiserade funktioner för kommunikation ärmeddelande, granskning, kvittens och mottagningsbevis.

Om denna riktlinjePrioritet: 2Principer: EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign, Process, Prototypning

Rekommendationer för kommunikation i e-tjänsterVä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 somfått deras uppgifter.

Meddelande om ärendets status

Meddela användaren när statusen i ett ärende ändras. Låt användaren självvälja hur hen vill ha meddelandet, till exempel via e-post, sms eller någotsocialt medium. Vilka kanaler som är lämpliga beror på målgruppen ochinformationen som ska skickas.

Skicka gärna all information i sin helhet direkt i meddelandet, om den inte ärkänslig. Exempel kan vara bevakning av ett vägbygge i kommunen som nuär avslutat, eller en bok man reserverat som nu finns att hämta påbiblioteket.

Ange i meddelandet var man loggar in för att se hela ärendet ellerinformationen.

Granskning och kvittens

När användarna har fyllt i alla uppgifter som e-tjänsten kräver, ska de kunnagranska uppgifterna innan de skickar in dem.

När de har skickat uppgifterna till organisationen ska de få en kvittens på attderas uppgifter har skickats. Samtidigt bör de få ett e-brev med sammainformation.

Riktlinje nr 77

Vägledning förWebbutveckling Sida 155 /

316

Page 157: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Kvittensen ska ange till vilken organisation uppgifterna har skickats,ärendenumret och kontaktuppgifter. Kvittensen bör även ange vad nästasteg i processen är: Ska de göra något ytterligare eller vänta på synpunktereller beslut från er?

Mottagningsbevis

När ni har mottagit formulärdata från en användare i ett ärende ska ni skickaett mottagningsbevis på den mottagna handlingen till användaren.Observera att ett mottagningsbevis och en kvittens ofta är två olika saker.

Se även R2. Ge begripliga felmeddelanden samt R73. Var tydlig medförutsättningar för att kunna använda e-tjänsten och R71. Bestäm om e-tjänsten behöver e-legitimation och signering.

Exempelwww.biblioteket.stockholm.se vars Mina sidor bland annat skickar ut enförseningsvarning några dagar innan lånetiden går ut.

www.verksamt.se/tillstand kommunicerar med användaren via automatiskafunktioner.

MätbarhetMäts via användningstester.

Senast uppdaterad: 2014-10-06

PrioInaktiv

Brödsmulor eller länkstigar i e-tjänsterSe webbriktlinje 27

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Sidan är hopslagen med Visa tydligt var användaren befinner sig (R27).

Senast uppdaterad: 2018-03-08

PrioInaktiv

Riktlinje nr 78

Riktlinje nr 79

Vägledning förWebbutveckling Sida 156 /

316

Page 158: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se riktlinje 23Riktlinjen har slagits samman med R23.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Se R23. Ange när webbsidorna har publicerats eller uppdaterats.

Senast uppdaterad: 2014-10-06

Prio 1

Följ standarderAnvänd standarder så långt som möjligt. Ett skäl till att webben har blivit såanvändbar är att den bygger på öppna standarder. Tack vare detta kan viutveckla och använda webben med verktyg från olika leverantörer. Öppnastandarder möjliggör konkurrens, underlättar innovationer och är ett skyddmot att en eller ett fåtal aktörer tar över och kontrollerar webben.

Om denna riktlinjePrioritet: 1Principer: Tekniskt oberoende, Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallring, Inköpare och beställare,Standarder för webbplatserNär i utvecklingsprocessen?: Förvaltning, Prototypning, Systemutveckling,Testning

Rekommendationer för webbstandarderSom uppmärkningskod, använd HTML 5 eller HTML 4.01. Se R81.Utveckla webbplatsen enligt en standard snarare än för enwebblä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 styrapresentation och layout.För prenumerationstjänster, använd RSS eller Atom. Se R87. Gör detmöjligt att prenumerera på information.

Val av kodstandardGör en analys av era behov och begränsningar innan ni beslutar om vilkenstandard ni ska använda. Har de publiceringsverktyg ni ska använda stöd

Riktlinje nr 80

Vägledning förWebbutveckling Sida 157 /

316

Page 159: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

för standarden? Vilka standarder stöds av andra system, till exempelärendehanteringssystem med webbaserade gränssnitt, som ska infogas i erwebbplats?

Ta reda på hur ni kan kontrollera att standarderna efterföljs och vilka verktygni kan använda för att verifiera det och kontrollera kvaliteten.

Varför kommer det in kod som inte följer standard?Var uppmärksam på verktyg som automatiskt konverterar material till HTML.Det skapas ofta felaktig uppmärkningskod när man automatkonverterarmaterial från till exempel ett ordbehandlingsprogram till HTML.

Om ni vill återanvända äldre material bör ni analysera materialet så att detinte innehåller uppmärkningskod som inte stöds av standarden. Materialetkan behöva tvättas från felaktig eller gammal uppmärkningskod.

MätbarhetNi kan mäta hur väl webbplatsen följer standarder med hjälp avautomatiserade verktyg. Se till exempel:

http://validator.w3.org/http://validator.w3.org/feed/http://jigsaw.w3.org/css-validator/

Senast uppdaterad: 2014-10-16

Prio 2

Utveckla webbplatsen enligt enstandard, snarare än för enwebbläsareFölj en webbstandard när ni utvecklar er webbplats, så kan ni vara mersäkra på att koden kommer att fungera även i kommande webbläsare.Samtidigt underlättar ni för dem som använder webbplatsen med andraverktyg än de vanligaste.

Om denna riktlinjePrioritet: 2Principer: Tekniskt oberoende, Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallring, Inköpare och beställare,Standarder för webbplatser, TillgänglighetNär i utvecklingsprocessen?: Systemutveckling

Riktlinjen uppdateras

Riktlinje nr 81

Vägledning förWebbutveckling Sida 158 /

316

Page 160: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

2018-05-31: Referensgruppen för webbriktlinjerna överväger att ändra pådenna riktlinje då vi bedömer att HTML5 nu är så moget att alla nyawebbplatser bör utvecklas för att följa den standarden. Ett utkast till nyversion finns publicerat.Kom gärna med synpunkter, antingen i kommentarsfunktionen sist på sidan,med epost till [email protected], eller i Facebookgruppen webbriktlinjer.

Rekommendationer för att välja standardAnvänd HTML version 4.01 eller HTML5. HTML version 5 är den mestmoderna versionen, men stöds ännu inte fullt ut i alla verktyg. Version4.01 är sedan länge en stabil rekommendation.Använd XHTML endast om det finns särskilda skäl till detta. Seblogginlägget HTML eller XHTML?

Att välja en standard är viktigare än vilkenstandard ni väljerOftast är det mindre viktigt vilken standard ni väljer. Det viktiga är att niväljer en standard att följa, eftersom ni då enkelt kan kontrollera att erasidmallar följer kraven.

Ofta påverkar publiceringsverktyget vilka standarder man kan välja mellan.Utvärdera därför vilka möjligheter som finns att följa olika standarder när niska välja publiceringsverktyg.

HTML5 är en ny standardHTML5 blev, efter flera års arbete, en ”W3C Recommendation” i oktober2014. Det innebär att specifikationen är en färdig webbstandard. Standardenstöds redan till största del av de senaste webbläsarna, och skall även kunnafungera med äldre versioner till viss del.

HTML 4.01 finns i två varianterDet flesta webbläsare kan tolka HTML 4.01 på det sätt som standardenavser.

Strict eller transitional?HTML 4.01 finns i två undervarianter, ”strict” och ”transitional”:

”Strict” innebär att man inte får använda några av depresentationselement som tidigare gjorde det möjligt att blandainnehåll och presentationsinformation. Om ni beställer HTML-mallarfrån en extern leverantör bör ni i kravställningen begära att mallarnaska validera mot undertypen ”Strict”. Då vet ni att mallarna inteblandar innehåll med presentationsinformation.”Transitional” tillåter vissa presentationelement. Detta gör det svårareatt testa om din webbplats blandar innehåll med presentation. Detbehöver dock inte påverka tillgängligheten, så länge ni inte användernågra presentationselement.

Vägledning förWebbutveckling Sida 159 /

316

Page 161: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Anpassa till tidigare versioner av webbläsare, men till engränsUtveckla inte bara för de allra senaste versionerna av webbläsare.Webbläsare utvecklas nämligen snabbt. Tillverkarna blir visserligen alltbättre på att följa standarder, men ta det säkra före det osäkra och se till attsidorna fungerar även i tidigare versioner.

Ni är däremot inte skyldiga att stödja webbläsare som kraftigt avviker frånstandarden, till exempel äldre webbläsare. Dessa kan fortfarande visainnehållet, men presentationen och funktionerna kanske inte fungerar somni avsett. Det är sällan kostnadseffektivt att göra anpassningar för dessawebbläsare eller tillhandahålla specialversioner av innehållet för specifikawebbläsare.

MätbarhetFör att kontrollera om en sida följer den standard ni valt föruppmärkningskod kan ni använda W3C:s valideringsverktyg:[http://validator.w3.org]. Verktyget kan utgå från länkar till sidor elleruppladdad HTML-kod för sidor som ännu inte är publikt tillgängliga. För attkontrollera stilmallar finns ett motsvarande verktyg från W3C:[http://jigsaw.w3.org/css-validator/].

Nya webbläsare tillkommer hela tiden, vilket gör det ännu viktigare attutveckla enligt en standard. Det finns fortfarande skillnader i hur välwebbläsarna stöder och tolkar de olika standarderna. Därför bör ni testawebbplatsen i så många som möjligt av de webbläsare som personer i eramålgrupper använder.

I första hand bör ni testa webbplatsen i en av de webbläsare som har bäststöd för standarder. Därefter kan ni göra anpassningar för andrawebbläsare. Ibland får man göra avkall på utseendet för att webbplatsensinformation och tjänster ska vara tillgängliga för alla användare.

FördjupningGenerell statistik om olikawebbläsare: internationellt och i Sverige.Tillgänglighetssupport i olika webbläsare för HTML 5:html5accessibility.com”Senaste versionen av HTML 4.01” w3.org/TR/html401”Senaste versionen av HTML 5” w3.org/TR/html5

Se även R80. Följ standarder, R82. Använd stilmallar för att separerapresentationen från innehållet och R84. Se till att koden validerar.

Senast uppdaterad: 2014-10-30

Riktlinje nr 82

Vägledning förWebbutveckling Sida 160 /

316

Page 162: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 2

Använd stilmallar för att separerapresentationen från innehålletAnvänd stilmallar (cascading style sheets, css:er), där ni samlar alla reglerför webbplatsens utseende: hur textelement ska se ut, var på sidan objektska placeras och hur objektens utseende ska justeras.

Om denna riktlinjePrioritet: 2Principer: Tekniskt oberoende, TillgängligRoller/arbetsuppgifter: Bevarande och gallring, Standarder för webbplatser,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Systemutveckling

Rekommendationer för stilmallarSamla regler för webbplatsens utseende i stilmallar.Definiera stilmallarna i externa stilmallsdokument, i så storutsträckning som möjligt. Använd inte style-attributet för att definierastilmallar direkt i HTML-koden, eftersom ni då blandar uppmärkning försemantik och presentation, vilket kan leda till problem för vissaanvändare och i vissa webbläsare.

Kort introduktion till CSSStilmallar används för att styra hur texter, rubriker och länkar ska se ut i denvisuella presentationen. De innehåller kopplingar mellan visuell ochstrukturell presentation. Om vi tar rubriker som exempel så definierar dudokumentets struktur med hjälp av korrekta rubrikelement (h1, h2 och såvidare) och anger sedan rubrikernas utseende genom att definiera de olikah-elementens utseende i stilmallar. Med h-elementet skapar du denstrukturella och hierarkiska rubrikindelningen, och med stilmallarna talar duom hur varje rubriktyp ska se ut. Båda delarna är lika viktiga.

Ibland behövs rubriker som i strukturell mening är h1:or men som behöverha ett särskilt utseende rent visuellt. Det går att lösa med flera klasser för h-elementen i stilmallarna.

Stilmallar kan länkas samman i en hierarki för att bryta isär stora ochkomplexa definitioner till generella och återanvändbara komponenter. Dåkan besökarna också lättare styra layouten efter sina önskemål och behov,genom egna skräddarsydda stilmallar – user stylesheets – till exempel föratt visa en sida med hög kontrast.

ExempelStilmallsbaserad layout finns bland annat hos Bolagsverket(www.bolagsverket.se) och Södersjukhuset (www.sodersjukhuset.se).

Vägledning förWebbutveckling Sida 161 /

316

Page 163: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Relaterade riktlinjer

R121. Ange i kod vad sidans olika delar har för roll

Mätbarhet

På ett generellt plan kan ni validera ert användande av stilmallar medW3C:s valideringsverktyg. För att utvärdera hur väl stilmallarna används förpresentation och layout behöver ni även gå igenom stilmallskoden manuellt.

Terminologi

Semantisk betyder ungefär meningsfull eller betydelsebärande. Ett exempelpå semantiskt html-element är h1. H står för heading, alltså rubrik, och 1står för högsta nivån. En text som märks upp med ett icke-semantisktelement som t.ex. span och formges med fetstil och stora tecken kanske serut som en rubrik, men om den inte kodas semantiskt med h1 vet till exempelinte ett skärmläsarprogram att det är en rubrik, vilket försvårar navigationen.

Senast uppdaterad: 2014-10-16

Prio 4

Använd inte tabeller för layoutFormge inte er webbplats med hjälp av tabeller. Det finns nämligen en riskatt användare som använder läshjälpmedel får informationen i tabellerna ifel ordning eller inte alls, beroende på hur komplexa tabellstrukturer somanvänds. Även om tabellstrukturen fungerar så kommer vissa hjälpmedel attläsa upp information om tabellerna, vilket gör det svårare för användarna attförstå innehållet.

Om denna riktlinjePrioritet: 4Principer: Användbar, Förtroendeingivande, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning

Rekommendationer för tabeller och layoutAnvänd inte tabeller för layout. Det finns i regel ingen anledning attanvända tabeller för webbplatsens grundkonstruktion.Använd istället stilmallar (CSS:er) för att styra presentation och layout.

Tips för att komma igång

Riktlinje nr 83

Vägledning förWebbutveckling Sida 162 /

316

Page 164: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

För äldre och redan felkonstruerade webbplatser kan det vara svårt att heltkomma ifrån tabeller. Då kan ni som första steg förenkla tabellstrukturen ochundvika tabeller i tabeller. Om en webbplats byggs om helt från grunden, tabort samtliga layouttabeller. Istället för tabeller, använd stilmallar för att styrapresentation och layout, se R82. Använd stilmallar för att separerapresentationen från innehållet.

Vill du komma igång och göra layout utan tabeller finns mycket hjälp att fåfrån andra webbplatser. Flera av dessa har dessutom färdiga paket medtypkonfigurationer för olika layouter som man kan utgå från. Se till exempel:

Incutio CSS LayoutsWebbdesignskolans kapitel om CSS-layout

Det finns även layoutverktyg som skapar en komplett uppsättning HTML ochCSS på det sätt du anger:

CSS Portal: Layout generatorCSS Creator: Layout generator

Tabeller i html-baserad e-postI e-post som formges med html kan tabeller fortfarande ibland vara denenda möjligheten att kontrollera layout (på grund av begränsningar i vissa e-postklienter).

Använd i så fall aria-attributet role=”presentation” på tabeller som

används för layout. Då försvinner den semantik som i vanliga fall följer medelementet table vilket bland annat minskar problem som annars uppstår

exempelvis när informationen läses upp som tabell av skärmläsare.

MätbarhetOm tabeller har använts för layout behöver ni analysera koden och granskawebbplatsen för att vara säkra på att den fungerar. Var noga med attwebbplatsen presenterar informationen logiskt även för användare somanvänder hjälpmedel. Granskningen kan ni till exempel göra med:

Web Developer Extension för FirefoxWeb Accessibilty Toolbar för Internet Explorer. Finns i svensk version.HTML Validator för Firefox. W3C:s valideringsverktyg i en lokalinstallation.

Senast uppdaterad: 2017-12-15

Prio 1

Riktlinje nr 84

Vägledning förWebbutveckling Sida 163 /

316

Page 165: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se till att koden validerarSe till att er webbplats har sidmallar och stilmallar som har en godkodkvalitet och följer standarder. Det ökar chansen att alla användare kankomma åt informationen och tjänsterna på webbplatsen, oavsett vilkaverktyg de använder.

Om denna riktlinjePrioritet: 1Principer: Tekniskt oberoende, Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Bevarande och gallring, Standarder för webbplatser,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Prototypning,Systemutveckling, Testning

Olika användare använder olika verktyg (programversion, hjälpmedel,teknisk utrustning med mera).

Se därför till att er webbplats har sid- och stilmallar som har en godkodkvalitet och följer standarder. Det ökar chansen att alla användare kankomma åt informationen och tjänsterna på webbplatsen, oavsett vilkaverktyg de använder.

Html och annan kod kan valideras automatiskt.

Rekommendationer för att säkerställa godkodkvalitet

Kontrollera att era mallar för funktioner, tjänster och stilmallar validerari enlighet med er valda standard.Kräv att leverantören vid leverans bifogar valideringsprotokoll församtliga mallar. Mallar som inte validerar bör inte godkännas förleverans, om inte leverantören har acceptabla argument för allavalideringsfel.Försök att automatisera en regelbunden kodvalidering, eller görvalidering 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 exempelhända när ni uppdaterar ett tilläggsprogram, när ni infogar envideospelare i ett blogginlägg eller när någon gör ett inlägg i ettkommentarssystem.

Vad betyder robusthet?

En av de grundläggande principerna i tillgänglighetsstandarden WCAG är”robust”, vilket innebär att skapa största möjliga kompatibilitet mednuvarande och framtida användarprogram och hjälpmedel. Att ha korrektvaliderande HTML-kod är en nyckel till robusthet.

Tänk på att även om webbplatsen validerar korrekt kan den vara otillgänglig

Vägledning förWebbutveckling Sida 164 /

316

Page 166: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

på grund av komplex layout, JavaScript och annat som inte stöds avanvändarens webbläsare, liksom av anledningar som inte har med kod ochteknik att göra (till exempel ett språk som inte är begripligt för användarna).

En webbplats som validerar är inte automatiskt användbar och uppfyller inteautomatiskt besökarnas förväntningar och behov. Men en tillgängligwebbplats är en förutsättning för att informationen på webbplatsen ska nå uttill så många användare som möjligt.

Utdrag från WCAG-standarden

Riktlinje 4.1 Kompatibelt: Maximera kompatibiliteten mednuvarande och framtida användarprogram, inklusive hjälpmedel.

4.1.1 Parsing: Innehåll som skapats med kodspråk (markuplanguage) har element med kompletta start- och sluttaggar.Elementen är nästlade enligt deras specifikationer. De innehållerinte dubbla attributangivelser och har unika ID:n – förutom dåspecifikationerna tillåter detta. (Nivå A)

Anmärkning: Start- och sluttaggar som saknar ett obligatoriskttecken såsom ett avslutande ”större än”-tecken eller ettattributvärde med citattecken som inte matchar, är inte komplett.

ReferenserSe även R80 Följ standarder och R81 Utveckla webbplatsen enligt enstandard snarare än för en webbläsare.

MätbarhetFör att kontrollera kod, använd W3C:s valideringsverktyg för de standardersom finns.

W3C:s uppmärkningsspråksvalideringW3C:s stilmallsvalidering

TerminologiValidera (på engelska validate) betyder värdera, och används iwebbsammanhang i betydelsen att man jämför innehåll mot en definition avvad som förväntas. Till exempel att granska html-kod för att se om denöverensstämmer med specifikationen för vald html-version, eller att granskainmatad data i ett formulär för att se om det motsvarar förväntat format. Oftakan validering göras automatiskt.

Senast uppdaterad: 2018-12-05

PrioInaktiv

Riktlinje nr 85

Vägledning förWebbutveckling Sida 165 /

316

Page 167: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se riktlinje 60Om knappar i formulär. Se riktlinje 60.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Se riktlinje 60Denna riktlinje har slagits ihop med R60. Gör tydliga användbara knappar.

Senast uppdaterad: 2014-09-24

Prio 2

Basera inte viktig funktionalitet påformat som kräver insticksprogramFlash, Quicktime och liknande ger ofta problem för de som använderhjälpmedel, eller som inte använder mus, även när webbläsaren har ettinsticksprogram för att hantera dem. Låt därför ert viktigaste innehåll varaanvändbart även utan insticksprogram.

Om denna riktlinjePrioritet: 2Principer: Användbar, Tekniskt oberoende, Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Standarder för webbplatser, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign, Systemutveckling

Rekommendationer för insticksprogramAnvänd insticksbaserade multimediala format när det är motiverat,men ge bra alternativ. Undersök först om det går att använda mertillgängliga format.Använd inte insticksbaserade format för grundläggande funktionersom 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 vidlåg bandbredd.Om ni använder script för att kontrollera om era användare använderinsticksbaserade format, så se till att scriptet inte ger fel besked om enanvändare har script avslaget.Infoga det format ni använder i webbsidan på ett sätt som fungerar i så

Riktlinje nr 86

Vägledning förWebbutveckling Sida 166 /

316

Page 168: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

många webbläsare som möjligt.

Använd insticksbaserade format när det ärmotiverat, men ge bra alternativMånga användare har program som hanterar insticksbaserat innehåll somFlash, Silverlight och Quicktime. Men inte alla. Vissa stänger avinsticksstödet, av säkerhetsskäl, för att slippa reklam eller för att det kräverhög bandbredd. Andra använder en webbläsare eller en plattform som intehar stödet, till exempel många mobiltelefoner.

Använd gärna insticksbaserade multimediala format för göra vissinformation lättare att förstå. Exempelvis kan ni beskriva ett händelseförloppmed hjälp av animering. Ni kan också använda formaten i dekorativt syfte,precis som man kan använda bilder för att förbättra webbplatsens visuellaframtoning. Det viktiga är att ni gör det på ett sätt som inte hindrar någonfrån att använda webbplatsen.

När ni använder insticksbaserade format, ge samtidigt tydliga och likvärdigaalternativ. Till exempel kan en animering ersättas av en stillbild tillsammansmed en beskrivande text.

Använd inte insticksbaserade format förgrundläggande funktionerAnvänd inte insticksbaserade format för funktionalitet som är grundläggandeför webbplatsen, till exempel för navigering eller formulär. Gör även icke-kritiskt innehåll med alternativ till insticksbaserade format i så storutsträckning som möjligt.

När det alternativa innehållet väsentligt skiljer sig från det ursprungliga,tydliggör för användaren att det är ett alternativt innehåll och förklara varfördet visas. Det är också lämpligt att förklara var användarna kan hitta deinsticksprogram, webbläsare och operativsystem som behövs för att ta delav den multimediala presentationen.

MätbarhetTesta webbplatsen med de vanligaste webbläsarna för målgruppen. Provamed insticksprogram påslagna respektive avslagna. Testa att navigera påwebbplatsen och den aktuella informationen utan mus eller någothjälpmedel.

TerminologiInsticksprogram kallas ofta plug-in, add-on eller tilläggsprogram. De ärprogram som hjälper webbläsaren att hantera information på format somwebbläsaren inte är förberedd för. Adobe Flash Player är troligen det mestkända insticksprogrammet, men det finns många andra.

Senast uppdaterad: 2014-10-31

Vägledning förWebbutveckling Sida 167 /

316

Page 169: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prio 3

Gör det möjligt att prenumerera påinformationGör det möjligt att prenumerera på information från er webbplats. Då kananvändarna enkelt hålla sig underrättade om vad som händer inom ertområde.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, Tekniskt oberoendeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Interaktionsdesign, Målgruppsanalys,Systemutveckling

Rekommendationer för prenumerationerErbjud åtminstone ett sätt att prenumerera på innehåll frånwebbplatsen.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öranvändarna.Utsätt inte prenumeranter för irrelevant information.

Vilken information behöver användarnaprenumerera på?Varje prenumerationstjänst bör uppfylla faktiska behov hos era målgrupper.Kartlägg därför först vilken information de är intresserade av attprenumerera på.

Prenumerationer kan delas in i två kategorier: prenumerationer för att bliuppmärksammad om uppdateringar av innehållet på en webbplats, ochprenumerationer på ett nyhetsbrev eller liknande. Exempel på innehåll somni kan erbjuda prenumeration på:

nyheter och pressmeddelandennya rapporter och andra publikationerkalendarium med aktiviteterupphandlingarplatsannonserkrisinformationrättsinformationuppdateringar av innehållet på webbplatsen.

Riktlinje nr 87

Vägledning förWebbutveckling Sida 168 /

316

Page 170: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Nyhetsbrev via e-post

Om prenumerationen är ett nyhetsbrev, utforma breven så att de kan läsasav olika typer av e-postklienter. Om formatet är HTML-baserat ska detfinnas möjlighet att få brevet även i textformat. Om meddelandet skapas iHTML-format, inled med en länk till en webbsida där samma innehåll kanläsas.

Undvik att bifoga Word- eller pdf-filer. Begränsa innehållet i meddelandet såatt filen inte blir för tung för mottagaren att hantera.

Tänk på att många e-postklienter inte visar bilder i nyhetsbrev om deär länkade till en webbplats och inte bifogade i meddelandet. Om ni bifogarbilder, begränsa deras storlek.

Hämta inte in mer information om prenumeranten än nödvändigt. Oftaräcker det med e-postadressen. Ange hur ni kommer att hanterakontaktinformationen: endast för att hantera prenumerationen, eller även förandra situationer. Se R20. Upplys hur juridisk information och kakorhanteras.

Ange avsändare och länka till eventuellfördjupningAnge avsändare tydligt. Skriv namnet på organisationen samt webbadressoch kontaktuppgifter. Använd en giltig avsändaradress eftersomanvändaren kan vilja svara på e-brevet.

Länka tydligt till eventuell fördjupning. Länka till relevanta och uppdateradesidor på er eller andras webbplatser.

Utsätt inte prenumeranter för irrelevant informationVarje post som publiceras i en prenumeration ska vara relevant förmålgruppen. Låt användaren ange ett eller flera avgränsadeämnesområden för sin prenumeration. Välj en ambitionsnivå som ligger ilinje med resurser och framtida innehåll. Med ett specialiserat innehåll är detviktigt att ni uppfyller användarnas förväntningar och inte levererar ett alltförgenerellt innehåll. I en prenumeration på upphandlingsnyheter förväntarman sig inte att få platsannonser bara för att det för tillfället inte pågår någraupphandlingar.

Välj en bra tidpunkt för era utskick. Generellt sett är det svårare att nå uteftermiddagar före helgdagar samt förmiddagar efter helgdagar.

I prenumerationer skummar många användare enbart rubrikerna och deförsta meningarna. Se därför till att varje text har en bra rubrik, och att detviktigaste kommer allra först i texten. Fånga läsarens uppmärksamhetgenom att lyfta relevant innehåll och visa att rubriken är rättvisande. Seäven avsnittet Skriva för webben.

Vägledning förWebbutveckling Sida 169 /

316

Page 171: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Prenumeration via syndikerade nyhetsflödenNi kan också ge möjlighet till prenumeration via syndikerade nyhetsflöden,en teknik för att hämta nyhetsrubriker och sammanfattningar frånwebbplatser. Den innebär att innehåll från webbplatsen återpubliceras i ettsyndikerat nyhetsflöde. Då kan privatpersoner och organisationer som villbevaka ett område eller flera webbplatser enkelt få uppdateringar utan attbesöka de olika webbplatserna. När webbplatsens redaktion publicerarmaterial kan nyhetsflödets prenumeranter automatiskt hämta nyheter i dentakt de har ställt in sin flödesläsare på. Informationen behöver alltså barapubliceras på ett ställe.

Syndikerade nyhetsflöden underlättar även för en del användare medmobila enheter. Nyhetsflödet blir då ett effektivt sätt att ta del av nyheter frånwebbplatsen utan att behöva ladda hela sidan.

De två främsta formaten för syndikerade nyhetsflöden är RSS och Atom.Båda två stöds av de största webbläsarna men kolla detta en extra gång omni vill använda någon speciell funktion. Observera att begreppet RSS oftaanvänds synonymt med både RSS, Atom och andra liknande tekniker.Använd därför begreppet nyhetsflöde när det gäller flera tekniker, angeannars den specifika teknikens benämning.

Använd tekniska lösningar som RSS och Atom förnyhetsflödenMånga publiceringsverktyg kan presentera innehållet på webbsidor inyhetsflöden. Atom går dessutom att utöka med egna element för meravancerade ändamål. För mer information om Atom-specifikationen och hurdu skapar nyhetsflöden i Atom, se:

Atom-specifikationen, RFC 4287 (på engelska)

När du skapar ett nyhetsflöde:

Använd i första hand RSS version 2.0 eller Atom 1.0 för att skapanyhetsflöden.Ange informationen enligt teckenkodstandarden UTF-8. Dennateckenkodstandard ger möjligheter att uttrycka information med andratecken än västerländska.Kontrollera att nyhetsflödets kod validerar med hjälp av ennyhetsflödesvalidator.Ge nyhetsflödet ett namn enligt principen: <organisation> <namn pånyhetsflödet> <eventuellt ämnesområde>. Exempel: E-delegationen –Vägledningen för webbutveckling – Diskussionsforum

Ni kan ge flera nyhetsflöden utifrån samma information, till exempel förmottagare som har intresse av olika delar av er verksamhet. Ni kan ävenanvända nyhetsflöden för att återpublicera innehåll på andra webbplatser,se R89. Gör det möjligt för andra att återanvända webbplatsens innehåll.

Vägledning förWebbutveckling Sida 170 /

316

Page 172: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om URL:en till ett nyhetsflöde byts ut, gör en omdirigering i koden påsamma sätt som för sidor som flyttas, se R56. Låt inte en webbadress slutafungera. Då slipper prenumeranterna ändra sin prenumeration för hand.

Visa att det finns nyhetsflödenAnge att det finns nyhetsflöden genom att ha link-elementet i koden för sidorsom har RSS-kanaler. Då visar webbläsaren normalt att det finns en RSS-kanal kopplad till sidan. En sida kan ha flera nyhetsflöden. Då anger du ettlink-element för varje nyhetsflöde.

<link rel=”alternate” type=”application/rss+xml” title=”organization – namn påkanalen” href=”länk till sidans RSS-kanal” />

Använd gärna RSS-ikonen för att visa att sidan innehåller en länk till ettnyhetsflöde. Länka då ikonen till nyhetsflödet. I anslutning till ikonen, länkatill en beskrivning av hur man startar en prenumeration.

Skapa en sida med en förteckning över webbplatsens nyhetsflöden, medklickbara URL:er till varje kanal. Beskriv innehållet i varje kanal och hur manpåbörjar en prenumeration på nyhetsflöden. Ge sidan kortadressenwww.namn.se/rss och placera den under avdelningen ”Prenumerera”.

Se till att webbplatsens sökfunktion ger träff när användare söker efternyhetsflöden med webbplatsens sökfunktion.

Gör det enkelt att påbörja och avslutaprenumerationenDet ska vara så enkelt som möjligt att påbörja och avsluta enprenumeration. De som prenumererar på ett nyhetsbrev via e-post skakunna avsluta prenumerationen genom att klicka på en länk i brevet.

ReferenserSe även R89 Gör det möjligt för andra att återanvända webbplatsensinnehåll.

ExempelStaffanstorps kommun erbjuder prenumeration via RSS.På goteborg.se kan besökare välja mellan att prenumerera på aktuellahändelser i Göteborg eller på stadens pressmeddelanden via RSS.Göteborgs stad erbjuder e-postprenumeration på nämndhandlingar.Regeringskansliet erbjuder flera olika sätt att prenumerera, inommånga olika områden.

MätbarhetDu kan testa att dina RSS-nyhetsflöden följer standarden med W3C:stestverktyg för nyhetsflöden

Vägledning förWebbutveckling Sida 171 /

316

Page 173: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2014-10-31

Prio 2

Publicera i första hand dokument ihtml och skapa tillgängliga pdf:erPublicera dokument, som rapporter och utredningar, i webbplatsensstandardformat (html). Andra format gör det svårare att komma åtinformationen, eftersom de ofta kräver extra programvara. Om du ändåbehöver lägga ut en pdf, se då till att göra den tillgänglig.

Om denna riktlinjePrioritet: 2Principer: Tekniskt oberoende, Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer om dokumentformatPublicera i första hand dokument i standardformatet html. Då kananvändarna komma åt er information utan att använda en vissdatorplattform, 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 tillatt 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 andra dokumentformat än htmlLåt kommunikationen med era användare ske på deras villkor. Användarnabör inte behöva skaffa en viss produkt för att kunna kommunicera med er.

Överväg noggrant valet av format när du ska publicera något påwebbplatsen. Normalt är det bäst att presentera informationen direkt i html.Om ni lägger ut information i exempelvis pdf- eller wordformat blir denbetydligt svårare att söka och komma åt för användare som till exempelsurfar via en mobiltelefon eller saknar den programvara som behövs.

Använd alternativ till html endast för dokument som är

långa och som i första hand är tänkta att läsas i utskrivet formatstatiska över tid, såsom lagtexter, regleringsbrev och instruktionerberoende av att layout, grafik och innehåll alltid presenteras på

Riktlinje nr 88

Vägledning förWebbutveckling Sida 172 /

316

Page 174: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

samma sättbundna enligt lag att se ut på ett specifikt sättillustrerade med tabeller med flera kolumner, eller innehållermatematiska formler eller andra element som kräver särskildadokumentformat.

Bifoga filer i format som användarna säkert kanöppnaGör filer som ska bifogas i format som följer öppna standarder, till exempelodf och pdf. Ni kan även använda vanliga bildformat och textformat.

Det är upp till er att avgöra vilka format ni vill använda i kommunikationenmed användarna. Ange på webbplatsen och i annat informationsmaterialvilka format ni har bedömt som lämpliga. Om ett e-brev inte går fram för attmottagaren inte kan ta emot bilagan, bör avsändaren få ett förslag på ettannat format att använda.

Skapa tillgängliga PDF-filerStandarden för upphandling av tillgänglig IKT, som bland annat utgör grundför webbdirektivet, ställer i stort sätt samma tillgänglighetskrav på dokumentsom på webbinnehåll: Utgå från WCAG nivå AA.

För att uppnå detta är det smidigt om du använder en formatmall ioriginaldokumentet där rubriker, ingresser, brödtext och bilder är korrektuppmärkta. När du sedan konverterar dokumentet till PDF, kan du behövagöra justeringar beroende på vilken version av till exempel Microsoft Worddu använder. De kompletteringarna görs ofta i Acrobat Professional. Vilkenversion av programmet du använder, liksom med vilket program du skapatPDF-filen, kan påverka resultatet. Säkrast är att konvertera till PDF medAcrobat Professional eller välja ”Spara som PDF” i MS Word.

Det viktigaste vid konverteringen är att texten verkligen är text, och inte textsom skannats in som en bild. Om du har gjort det kan du efteråt analyseraoch omvandla innehållet till text i Acrobat.

Gör så här för att skapa en tillgänglig pdfNär du skapar en tillgänglig pdf bör du göra så mycket som möjligt ioriginaldokumentet, till exempel i Microsoft Word eller Adobe Indesign, iannat fall måste du komplettera med inställningar i Acrobat Professional.Här är några grundläggande riktlinjer:

Filen ska vara försedd med kodade taggar i ett taggträd . I Word gördu det genom att välja ”Visa taggar för dokumentstruktur”. Du kan göradet efter konverteringen genom att välja ”Lägg till taggar i dokumentet”i Acrobat.Tagga rubriker med rubriknivåer (<H1>, <H2>), tabeller (<table>),tabellrubriker (<TH>), kolumner (<TR>), punktlistor (<L>) ochinnehållsförteckning (<TOC>).Förse bilder, diagram och bildbaserade figurer med alternativtexter.

Vägledning förWebbutveckling Sida 173 /

316

Page 175: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Definiera läsordningen. Normalt ska den vara inställd på ”Använddokumentstruktur”.Ange dokumenttitel och författare. Det gör du under”Dokumentegenskaper”. Där definierar du även språket dokumentet ärskrivet i. Insprängd text på andra språk ska ges egen språkkodning.Gör en innehållsförteckning i längre dokument, gärna presenteradsom bokmärken i PDF:en. Klicka på bokmärkessymbolen till vänster iprogramfönstret för att redigera bokmärkena i Acrobat.Se till att kopiering av dokumentet är tillåtet. Det gör du undersäkerhetsinställningar i Acrobat. Vill du ändå låsa dokumentet kan dukryssa i att göra det tillgängligt för skärmläsare.Om filen blivit onödigt stor efter de tillagda inställningarna, kan du väljaatt komprimera den senare.

MätbarhetKontrollera att det finns information om dokumentformat i era internariktlinjer för publicering.

Kontrollera tillgängligheten när filen är klar. Det finns ett inbyggt testverktyg iAcrobat under ”Avancerat/Tillgänglighet/Fullständig kontroll”, men det finnsäven andra tjänster på marknaden. Några exempel på verktyg finns påsidan om automatisk tillgänglighetsgranskning. Automatiska kontroller täckerinte allt. Kontrollera manuellt sådant som alternativtexter, att taggningen ärkorrekt och att rubriker, bilder med mera ligger i rätt läsordning. Felaktigordning justeras i Acrobat med ”Slutredigeringsverktyget för läsordning”.

Testa även själv med talsyntes eller skärmläsare, och låt gärna synskadadepersoner testa att dokumentet läses upp korrekt för deras hjälpmedel.

FördjupningArgumentDen engelska regeringen har i ett blogginlägg redovisat anledningar till attHTML oftast är att föredra framför PDF.

Instruktioner och standarder för tillgängliga pdf:erAdobe, Skapa tillgängliga PDF-filerW3C, PDF Techniques for WCAG 2.0W3C, ”PDF Technology Notes”Adobe, Reading PDFs with reflow and accessibility features

Instruktioner från privata aktörerKriterier för tillgängliga pdf-dokument från ETUOm Pdf och tillgänglighet från FunkaMicrosoft, skapa tillgängliga Word-dokumentPubliread, PDF AccessibilitySkapa och verifiera PDF-tillgänglighet (Acrobat Pro)

Testverktyg

Vägledning förWebbutveckling Sida 174 /

316

Page 176: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Exempel på verktyg finns på sidan om automatisk tillgänglighetsgranskning.

Relaterade riktlinjerGe all information på begriplig svenska (R10) Riktlinjen gällernaturligtvis även pdf-dokument.Utveckla webbplatsen enligt en standard, snarare än för enwebbläsare (R81).Basera inte viktig funktionalitet på format som kräver insticksprogram(R87).

Senast uppdaterad: 2018-07-13

Prio 3

Gör det möjligt för andra attåteranvända webbplatsens innehållGör tjänster och information på er webbplats åtkomliga för andra system, såatt andra kan återanvända ert innehåll. Överväg att själva syndikera ochförädla material för att skapa större nytta åt era användare.

Om denna riktlinjePrioritet: 3Principer: Effektiv, Åtkomlig över tidRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Förvaltning, Målgruppsanalys, Process,Prototypning, Systemutveckling

Rekommendationer för att återanvända ellervidareutnyttjande

Låt sökmotorerna indexera så mycket som möjligt.Utred möjligheterna för, och era användares behov av, syndikering.Gå igenom webbplatsen, och välj ut och gruppera material som kanvara värdefullt att syndikera.Presentera syndikerat material på er webbplats, om era användarekan ha nytta av att ni sammanställer er information med informationäven från andra webbplatser.Följ PSI-lagen – ett krav för myndigheter, en rekommendation till alla.

Låt sökmotorer indexera så mycket som möjligtSe till att sökmotorerna tar del av allt innehåll, så hittar fler er information.Undanta material från indexering endast om det finns mycket starka skäl.Genom att undanta information minskar ni möjligheten till insyn iverksamheten.

Riktlinje nr 89

Vägledning förWebbutveckling Sida 175 /

316

Page 177: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Syndikerat material kan ge ökad nyttaSyndikering är att sammanställa material från flera källor till en presentation.Information och uträkningar från flera olika myndigheter kan på det viset blitill en ny tjänst.

Ert material behöver vara publicerat i ett maskinläsbart format för att andraska kunna syndikera det och presentera det på sina webbplatser ochintranät.

Exempel: när flera organisationer lägger ut sina platsannonser som RSS-flöden, kan arbetsförmedlare syndikera annonserna och presentera demsamlat. Många sammanställer också nyheter, upphandlingar,rättsinformation eller krisinformation.

Utgå från användarnas behov och önskemål. Gå igenom er webbplatsoch välj ut och gruppera material som andra aktörer kan viljasyndikera. Gör materialet känt hos de som har intresse av det.Utred möjligheterna för, och behoven av, att ni själva görsyndikeringar tillsammans med andra organisationer. Använd bådeera egna och andras resurser för att möta era användares behov.Presentera syndikerat material på er webbplats, om ni har tjänster däranvändarna kan ha nytta av information även från andra webbplatser.

Det är den avsändande organisationen som äger och ansvarar för innehålleti en syndikerad kanal, så länge det presenteras oförvanskat, även på någonannans webbplats eller intranät. Avsändaren har dock inget ansvar för ivilket sammanhang dess innehåll återpubliceras.

Den tekniska lösningen för syndikering beskrivs i R87. Gör det möjligt attprenumerera på information. Se till att kanaler som är tänkta att syndikerasenbart innehåller strukturkod. Inga presentationselement bör finnas med, fördå kan mottagaren få svårt att presentera informationen på ett sätt somöverensstämmer med sin grafiska profil.

Förädla er informationInformationsmängder kan förädlas för att tillgodose ett specifikt behov ellerför att åstadkomma en ny produkt eller tjänst. Ett sätt är att koppla ihopinformationsmängder, till exempel statistik med geografisk information.

Ni kan också till exempel erbjuda ett gränssnitt till webbplatsenssökfunktioner som gör att andra verksamheter kan sammanställasökresultat från er och andra källor.

ExempelÖrebro kommun har ett öppet gränssnitt (API) som ger tillgång till deinformationspunkter som finns i kartan på orebro.se.

Fördjupning

Vägledning förWebbutveckling Sida 176 /

316

Page 178: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Sitemaps.org beskriver hur man kan stötta sökmotorer i att hittamaterial på webbplatsen som bara kan nås via sökformulär.e-Exclusion and Bot Rights: Legal aspects of the robots exclusionstandard for public agencies and other public sector bodies withSwedish examples av Nicklas Lundblad.Inom EU uppmanas medlemsstaterna att göra så mycket informationsom möjligt tillgänglig för återanvändning. Med information avses tillexempel registeruppgifter, officiella handlingar av lagstiftningskaraktäroch olika administrativa handlingar. Om möjligt ska detta skeelektroniskt och i ett format som inte är beroende av någon särskildprogramvara.Den 1 juli 2010 trädde lagen (2010:566) om vidareutnyttjande avhandlingar från den offentliga förvaltningen, den så kallade PSI-lagen,i kraft.

Myndigheter bör läsa vägledningen för vidareutnyttjande av offentliginformation.

Senast uppdaterad: 2014-10-31

Prio 5

Gör det enkelt att ringa upptelefonnummerMärk upp telefonnummer med tel-länkar, så att man kan ringa upp etttelefonnummer direkt, genom att klicka på det.

Om denna riktlinjePrioritet: 5Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för länkade telefonnummerMarkera telefonnummer i koden som telefonlänkar (tel:). Det germö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 internationellaprefixet, i länken – även om det nummer som visas på sidan barainnehåller den lokala delen. Då fungerar länken oavsett varifrånanvändaren ringer.

Riktlinje nr 90

Vägledning förWebbutveckling Sida 177 /

316

Page 179: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ExempelkodFöljande kod gör telefonnumret till en länk för att ringa upp det direkt:

<a href="tel:+46855050000">08 – 55 05 00 00</a>

Ni kan styra utseendet på länkarna med stilmallar. I exemplet har länken enegen stilmallsklass.

Vissa mobiltelefoner och webbläsare hittar automatiskt sifferkombinationersom ser ut som telefonnummer. De gör det alltså möjligt att ringa ettnummer även utan kodlänkning. Risken är dock att näraliggande siffror,som inte ingår i telefonnumret, ändå tolkas som en del av numret, tillexempel ett klockslag. Därför är länkar att rekommendera.

För fler rekommendationer om länkar (till exempelvis e-postadresser), seR5. Skriv tydliga länkar.

ExempelPost- och Telestyrelsens kontaktsida har växelnumret länkat.

Mätbarhet

Pröva att ringa telefonnummer genom att klicka på länkarna.

Fördjupning

RFC 3966: URI-schema för telefonnummer (på engelska)

Senast uppdaterad: 2014-10-31

Prio 1

Skapa en flexibel layout som fungerarvid förstoring eller liten skärmSkapa en layout som fungerar på en 320 pixlar bred skärm utan attinformation eller funktionalitet går förlorad, utan scrollning i mer än enriktning. I praktiken innebär det responsiv design och att att riktigt långa ordbehöver avstavas. Att behöva scrolla i sidled är besvärligt och försämrarupplevelsen. Många använder små skärmar och personer som på grund avnedsatt syn förstorar innehållet har liknande behov.

Om denna riktlinjePrioritet: 1Principer: AnvändbarRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,

Riktlinje nr 91

Vägledning förWebbutveckling Sida 178 /

316

Page 180: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning,Systemutveckling, Testning

Rekommendationer för flexibel layoutUndvik 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 ibegränsad bredd.

Undvik horisontell scrollning ner till 320 pixlarsbreddFör att inte skapa besvär för den som använder en liten skärm ellerförstoring bör layouten anpassas så att den inte behöver scrollas i mer änen dimension. Gränsvärdet är satt till skärmbredder ner till 320 pixlar. Förhorisontella skriftspråk som svenska innebär detta att vanlig vertikalscrollning gärna får användas men inte samtidigt som användaren måstescrolla även horisontellt. För vertikala skriftspråk (till exempel japanska)motsvaras detta av att enbart horisontell scrollning ska behövas ifönsterbredd ner till 256 pixlars höjd.

En skärm eller ett fönster ska kunna vara så smal som 320 pixlar utan attinnehållet behöver scrollas i sidled.

Förutom att själva layouten behöver vara flexibelt är det viktigt att tänka påandra aspekter av att presentera information på begränsat utrymme. SeAnpassa webbplatsen även för små skärmar (R111).

Undantag för innehåll som måste sträckas ut i tvådimensionerRiktlinjen gäller inte för delar av innehållet som kräver en tvådimensionelllayout. Viss grafik och video är till sin natur tvådimensionell och det finns falldär innehållet förlorar sin mening om en bild delas upp och innehålletstaplas ovanpå varandra. Exempelvis skulle en karta eller planlösningkunna bli mycket svårläst om den delades upp i olika delar ellerförminskades till 320 pixlars bredd. Undantaget gäller även för komplexadatatabeller som har ett tvådimensionellt förhållande mellan tabellrubrikeroch dataceller. Men ofta fungerar det ganska bra att låta kolumner “falla in”som rader när det horisontella utrymmet minskar.

Använd i första hand responsiv designResponsiv layout är idag det enklaste sättet att följa riktlinjen. Använd såkallade ”media queries” i CSS för att skapa olika grundlayout för olikastorlekar av webbläsarfönster eller skärmar, till exempel kan olika antalspalter visas beroende på fönstrets bredd.

Vägledning förWebbutveckling Sida 179 /

316

Page 181: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Komplettera eventuellt med flytande och/eller elastisk layoutKombinera gärna ”media queries” med olika metoder för att skapa flexibilitetmellan brytpunkterna på de olika skärmstorlekarna för att på så sättanvända skärmutrymmet optimalt.

Flytande layout ger flexibel spaltbreddEn flytande layout använder spaltbredder i procent för att anpassa sig efterwebbläsarfönstrets bredd. Fördelen är att användaren slipper en horisontellrullningslist (scroll bar). Nackdelarna är att extremt smala fönster gör attspalter överlappar varandra, samt att breda fönster ger för långa textradersom är svåra att läsa.

Elastisk layout kontrollerar radlängdenEn elastisk layout använder enheten rem för spaltbredder, vilket gör att

layouten anpassar sig efter webbläsarens textstorlek. Om användarenändrar textstorleken ändras också den maximala radlängden, vilket gör atttextrader består av samma antal tecken oavsett textstorlek. Fördelen ärkontroll över radlängderna. Nackdelen är att ett smalt fönster eller stor textger en horisontell rullningslist.

Hybridlayout blandar flytande och elastisk layoutDet går att kombinera flytande och elastisk layout. Då kan man till exempelgöra vissa spalter elastiska (bredd i rem) och vissa flytande (bredd i

procent). Med hjälp av CSS-egenskaperna för maximal och minimal breddkan man undvika såväl överlapp som för långa rader.

Gör en anpassad mobilversion om responsivdesign är omöjligtOm ni använder äldre system och av någon anledning inte kan bygga omeller uppdatera layouten kan ett alternativ vara att göra en anpassadmobilversion med en fast bredd på 320 pixlar. Huvudprincipen är attwebbinnehållet måste kunna ändra storlek. Om man utgår ifrån enwebbläsare som är 1280 pixlar bred och zoomar 400 % motsvarar det enmobilskärm på 320 pixlar.

WCAG-riktlinjen 1.4.4 Förändring av textstorlek gäller fortfarande, vilketinnebär att det bör finnas ett sätt för användarna att öka enbart textstorlekenmed minst 200 %.

Dokument som inte är webbsidorTänk även på att anpassa även dokument som inte är webbsidor(exempelvis pdf-filer och ordbehandlingsdokument) så att de kan uppfattasutan besvär av användare som förstorar eller har liten skärm.

PDF är i grunden inte ett responsivt format utan tvärtom: Det ger möjlighetatt i detalj anpassa innehållet för ett fast (pappers-) format. Om en PDF-filvisas på någon av de många skärmar som är mindre än de vanligapappersformaten så blir innehållet antingen väldigt litet eller så kan endasten liten del av dokumentet visas, vilket tvingar användaren att scrolla

Vägledning förWebbutveckling Sida 180 /

316

Page 182: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

mycket.

I vissa PDF-program kan dock användaren välja att “omforma flöde”(“reflow” på engelska) till en kolumn. I Acrobat Reader hittar du verktygetomforma flöde genom att välja Visa > Zooma > Omforma flöde. Dettafungerar bara om PDF-filen är sparad med “taggar”. Resultatet blir inte alltidså snyggt, men det ger i bästa fall möjlighet att läsa dokumentets innehållutan besvärlig scrollning i flera ledder. Presentationen kan förbättras av densom sparar filen genom manuell bearbetning av taggarna, men det går inteatt få samma kontroll över presentationen av en PDF-fil med omformat flödesom det går att få över en html-sida som anpassats till exempelvis en smalskärm med hjälp av css media queries.

Enligt W3C kan PDF-dokument uppfylla denna riktlinje om de är kodadeenligt standarden PDF/UA (Universal Accessibility, ISO 14289). Det är envariant av PDF som bland annat kräver taggning, men standarden ställeräven andra tillgänglighetskrav, som till ganska stor utsträckning motsvararWCAG 2.0.

Se även Publicera i första hand dokument i html och skapa tillgängligapdf:er (R88).

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.10 Reflow Content can be presented without loss ofinformation or functionality, and without requiring scrolling in twodimensions for:

Vertical scrolling content at a width equivalent to 320 CSSpixels;Horizontal scrolling content at a height equivalent to 256CSS pixels;

Except for parts of the content which require two-dimensionallayout for usage or meaning.

(Nivå AA)

Relaterade riktlinjerAnpassa webbplatsen även för små skärmar (R111)Se till att text går att förstora utan problem (R127)Presentera innehållet i en meningsfull ordning för alla (R122)

ExempelWebbplatsen mediaqueri.es visar exempel på webbplatser som

Vägledning förWebbutveckling Sida 181 /

316

Page 183: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

använder ”media queries” för att anpassa layouten.Tabeller behöver ofta flöda om i en responsiv design. Ett sätt att lösadet på är att låta varje kolumn blir en egen rad. Exempel på responsivtabell finns i Märk upp vanliga formulärfält i koden.

MätbarhetKontrollera layouten i olika webbläsare, i stora och små (åtminstone ner till320 pixlars bredd) fönster, på olika plattformar (bordsdator, bärbar,surfplatta, smartphone, mobiltelefon och så vidare) och försäkra er om attinnehållet inte överlappar eller blir helt eller delvis oåtkomligt.

Pröva också med olika inställningar för textstorlek eller zoom, beroende påvilka funktioner webbläsaren erbjuder. Många webbläsare låter användarnaändra bastextstorleken eller ställa in en minsta tillåten storlek.

TerminologiDet engelska begreppet scroll eller scrolling kallas på svenska ofta förscrollning eller rullning. Ibland talar man om att bläddra neråt. Vidinteraktion med pekdon används oftast en rullningslist medanpekskärmsgränssnitt brukar kunna panoreras genom en svepande rörelsemed fingret (swipe).

Följsam webbdesign kallas på engelska responsive web design (RWD). Påsvenska används ofta responsiv design. Även uttrycket dynamisk layoutförekommer. När man utvecklar en webbplats skapar man ofta mellan tvåoch fem olika anpassningar för olika skärmbredder: liten stående skärm(smartphone), liten liggande skärm, stående surfplatta, liggandesurfplatta/litet fönster och fullskärm/stort fönster i en eller ett par olikaupplösningar.

Inom både tidningslayout och interaktionsdesign förekommer begreppet “thefold”. En tidning viks ofta på mitten och det innehåll som visas på ovansidan(“above the fold”) får allra mest exponering. På motsvarande sätt får detinnehåll som presenteras innan användaren scrollat överhuvudtaget mestexponering på en webbsida. För användare som förstorar innehållet ellerhar en liten skärm kommer “vecket” tidigare, men om ni inte följer dennariktlinje så får de användarna en betydligt sämre upplevelse och en stor delav innehållet får betydligt minskad exponering.

Dokument som inte är webbsidor kallas i webbtillgänglighetsdirektivet för“filformat för dokument”.

Flexbox och CSS Grid är tekniker som går att använda att använda för attskapa responsiva layouter. Båda teknikerna går att använda var och en försig eller i kombination med varandra.

Med flexbox går det att styra med större precision hur olika element i en radeller kolumn placeras i olika skärmstorlekar i förhållande till varandra, t.ex.Genom att linjera eller justera element vertikalt och horisontellt i layouten.

Vägledning förWebbutveckling Sida 182 /

316

Page 184: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

CSS grid gör det möjligt att skapa mer avancerade layouter med rader ochkolumner och fritt styra placering av element beroende på skärmstorlek föratt exempelvis göra så att ett element hamnar högst upp på sidan på en storskärm men längst ned på en mindre skärm.

Em och rem är relativa måttenheter. Skillnaden mellan dem är att rem anger

ett förhållande till ett basmått för hela sidan, medan em anger ett förhållande

till ett basmått för aktuellt element.

Senast uppdaterad: 2018-12-20

Prio 4

Se till att webbplatsen kan användasäven utan stilmallarGör det möjligt att använda webbplatsen även med webbläsare som intestöder stilmallar, till exempel äldre eller textbaserade webbläsare.Användarna ska kunna ta del av innehållet och använda formulär,navigering och liknande. Presentationen behöver dock inte se likadan utsom i webbläsare med stöd för stilmallar.

Om denna riktlinjePrioritet: 4Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning, Systemutveckling

RekommendationerUndvik att skriva hänvisningar som förutsätter spatiala relationer ellerfärger, till exempel ”rutan till höger” eller ”den gröna knappen”.Sätt innehållet i en innehållsligt logisk ordning, så att det är begripligtäven utan stilmallar och den tänkta synliga ordningen.Använd inte html-element som gör att det krävs css för att görapresentationen begriplig. Ett vanligt exempel är att använda ul/li för attomsluta fält i ett formulär, trots att formuläret blir förvirrande när detpresenteras som en punktlista.

Relaterade riktlinjerSe även R82 Använd stilmallar för att separera presentationen fråninnehållet liksom resonemanget om progressiv förbättring i R93 AnvändJavascript för att öka tillgängligheten – inte tvärtom.

MätbarhetKontrollera att webbplatsen blir läsbar och användbar även om referensen

Riktlinje nr 92

Vägledning förWebbutveckling Sida 183 /

316

Page 185: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

till stilmallskoden tas bort eller ignoreras. Många moderna webbläsare gördet enkelt att tillfälligt stänga av stilmallar.

Senast uppdaterad: 2014-10-31

Prio 3

Använd Javascript för att ökatillgängligheten – inte tvärtomJavascript ger ofta en god användbarhet, och kan bidra till ökadtillgänglighet och effektivitet. Men det finns användare som inte kan eller villanvända Javascript. Se därför till att det går att använda webbplatsensviktigaste funktioner även utan Javascript, och följ riktlinjer för tillgängligJavascript.

Om denna riktlinjePrioritet: 3Principer: Användbar, Tekniskt oberoende, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Standarder för webbplatser, TillgänglighetNär i utvecklingsprocessen?: Informationssäkerhet, Prototypning,Systemutveckling, Säkerhet, Testning

Rekommendationer om JavascriptAnvänd gärna Javascript, men se till att även de som inte använderJavascript kan använda de viktigaste funktionerna. Följ principen omprogressiv förbättring, det vill säga bygg först all funktionalitet somvanlig html. Använd sedan Javascript som ett förhöjande tillägg.Se upp så att Javascript inte gör webbplatsen otillgänglig. Dennariktlinje 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ökaremåste använda Javascript. Upplys då användaren om att Javascriptkrävs för att använda tjänsten.Om vissa användare utestängs på grund av att de saknar Javascriptkan ni eventuellt ha skyldighet att erbjuda fullgoda alternativ. Dettagäller särskilt myndigheter.

Använd gärna JavascriptMed hjälp av script kan bearbetningen av information på webben fördelas påett effektivt sätt mellan webbläsare och webbserver. Tack vare script kanwebbsidor göras snabbare och smidigare, till exempel med sökförslag (seR112. Ge ordförslag vid sökning och inmatning) eller genom att bara deninformation som visas för ögonblicket behöver laddas ner, istället för helasidor. Script bidrar därför ofta till ökad tillgänglighet och användbarhet.Javascript är standardspråket för script som körs i webbläsaren och det

Riktlinje nr 93

Vägledning förWebbutveckling Sida 184 /

316

Page 186: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

finns ett stort utbud av färdig Javascriptkod som webbutvecklare kananvända som halvfabrikat. Detta sparar tid även vid utveckling.

Men alla besökare använder inte Javascript. Vissa äldre webbläsare ochhjälpmedel saknar stöd för Javascript, och vissa användare ocharbetsplatser väljer att stänga av eller blockera script. Anledningen kan varatill exempel integritets- eller säkerhetsskäl, för att slippa reklam eller för attman inte vill eller kan uppgradera sin utrustning.

Grundprincipen bör därför vara att tillämpa principen om ”progressivförbättring”, vilket innebär att man bygger tjänster som i sina grundläggandedelar fungerar utan Javascript och samtidigt ger mervärde för de användaresom har stöd för script.

Det betyder inte att allt måste fungera likadant utan Javascript, men allt somfinns och kan nås ska fungera. En besökare med fullt stöd för Javascriptkanske får möjlighet att bläddra och klicka i en kalender vid inmatning avdatum, medan en besökare utan Javascript får en textruta och informationom önskat datumformat. (I html5 kan kalenderinmatning erbjudas utanJavascript, men inte i tidigare html-versioner.) Ett annat exempel: UtanJavascript kan en länk leda till att besökaren kommer till en ny sida med nyttinnehåll, men med stöd för AJAX görs samma länk om så att innehålletinfogas i befintlig sida.

En grundrekommendation är att undvika att använda script för funktionersom redan finns i webbläsare eller fungerar lika bra utan script.Navigationslänkar bör t.ex. vara just länkar, och inte andra sorters objektmed onclick-event.

I undantagsfall kan det finnas faktorer som står utanför er kontroll som göratt webbplatsen behöver ställa Javascript som ett krav. Till exempel har detfunnits exempel på e-legitimationslösningar som kräver Javascript och sommåste användas av vissa myndigheter. Ett annat exempel är när nödvändigfunktionalitet av ekonomiska eller tekniska skäl endast går att realisera medJavascript (till exempel direktmanipulering av kartvyer) eller därsäkerhetskrav gör det olämpligt att skicka information över nätet till servern.I sådana fall bör användare informeras om att Javascript krävs för attanvända tjänsten. I vissa fall kan det innebära en skyldighet att erbjudafullgoda alternativ, till exempel utgående från diskrimineringslagen.

Tänk på detta om ni använder scriptGör det möjligt att använda de viktigaste funktionerna även utan tillgång tillscript. Om webbplatsen fungerar sämre utan script, informera om detta ianslutning till berörd funktionen eller under avdelningen ”Om webbplatsen”.

Om du använder script för visuella effekter som förmedlar information tillanvändarna, tänk på att förmedla samma information till användare som intekan se innehållet.

Undvik att göra funktioner som kräver en viss typ av inmatningsenhet. Ett

Vägledning förWebbutveckling Sida 185 /

316

Page 187: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

exempel är funktioner som kräver att användaren med musen drar ochsläpper objekt. Funktioner ska utformas så att de fungerar att använda medflera typer av inmatningsenheter.

Förlita dig aldrig enbart på scriptbaserade valideringsfunktioner i formulär.Det måste gå att skicka in ett formulär utan script. Information somanvändare lämnar måste valideras på serversidan, inte minst avsäkerhetsskäl.

Undvik webbläsarspecifik funktionalitet. Använd etablerade standarder somW3C:s dokumentobjektmodell (DOM). Ett sätt att undvika problem kan varaatt använda något av de färdiga bibliotek som finns. Många av dessa äröppen källkod och är redan testade på ett stort antal webbläsare.

Gör det möjligt att skapa länkar till information på din webbplats. Om duanvänder script för att dynamiskt uppdatera sidan med information måstedet vara möjligt att referera till den i andra sammanhang, exempelvis genomvanliga länkar. Observera att det går att med hjälp av script dynamiskt ändrapå den adress som visas i adressfältet. Detta kan användas för att ävenefter interaktion göra det möjligt att använda adressfältets innehåll somreferens.

Med detta arbetssätt kan Javascript göra mycket för att förbättraanvändarupplevelsen, utan att stänga användare ute i onödan.

Se upp så att Javascript inte gör webbplatsen otillgängligBeroende på hur Javascript används kan tillgängligheten på en webbplatspåverkas. Många Javascriptbibliotek innehåller funktioner som gör detenkelt att skapa nya typer av gränssnittselement som skjutreglage eller ytorsom uppdateras dynamiskt. Då dessa inte är en del av html-specifikationen,utan är uppbyggda av andra typer av element, finns det inget standardiseratsätt för hjälpmedel att tolka dem.

Detta kan ställa till problem för vissa användare. En person med synskadakanske missar att information uppdaterats dynamiskt, och en person medrörelsehinder kanske inte kan använda skjutreglaget om det inte går attstyra med tangentbordet.

W3C har publicerat ramverket WAI-ARIA (Web Accessibility Initiative –Accessible Rich Internet Applications), som är en specifikation för hursådana gränssnittselement ska tolkas och utformas.

Stödet för WAI-ARIA är inte riktigt 100% ännu, men när du använderJavascript på webbplatsen bör du även tillämpa relevanta delar av WAI-ARIA.

ReferenserVilka är det som inte använder Javascript, och varför?Om progressiv förbättring (progressive enhancement) från denbrittiska regeringen.

Vägledning förWebbutveckling Sida 186 /

316

Page 188: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

En djupare diskussion hos W3C om att låta webbplatsen fungera bådemed och utan Javascript.På till exempel http://jster.net/ och http://javascripting.com/ kan manhitta tusentals Javascriptbibliotek. Observera att kvaliteten varierarstort.Introduktion till WAI-ARIA från W3C.

ExempelDaniel Malls Progressively Enhanced Stock Table är en bra illustration avprogressiv förbättring. På sin blogg beskriver han (under rubriken ”Casestudy”) hur aktiekurser levereras som en html-tabell och sedan förbättraspresentationen med javascript.

Återvinningssajten SyndAttKasta är byggd med progressiv förbättring. Denfungerar bra med och utan både css och javascript, men är smidigare med.

Kartfunktionen på Örebro kommuns webbplats använder script för attuppdatera adressfältet när användaren navigerar i kartan. Det gör attadressfältets innehåll kan användas för att referera just det användaren serpå kartan.

MätbarhetStäng av Javascript i webbläsaren och kontrollera att allt innehåll äråtkomligt, att alla användargränssnittskomponenter går att använda och atte-tjänster fungerar.

Om ni använder WAI-ARIA kan många av funktionerna testas med enskärmläsare som t.ex. NVDA eller Jaws.

TerminologiOrdet script (eng. script) betyder manus. Ett script består, precis somteatermanus, framför allt av instruktioner om hur innehållet ska presenteras.Men ibland används script även för att tillföra nytt innehåll och funktionalitet.Idag är nästan alla script som körs i webbläsaren skrivna med språketJavascript.

Javascript har under benämningen ECMAScript blivit en internationellstandard genom ISO.

Ajax står för Asynchronous Javascript and XML och är ett samlingsnamn förett antal olika tekniker som kan användas för att bygga webbapplikationermed större interaktivitet än traditionella webbapplikationer.

Progressiv förbättring heter på engelska progressive enhancement, och ärrelaterat till principen om icke-störande (unobtrusive) programmering samt”graceful degradation” vilket är en sorts omvänd progressiv förbättring: Närnågon kapacitet skalas av (t.ex. Javascript) ska detta hanteras på ett smidigt(förlåtande) sätt.

Vägledning förWebbutveckling Sida 187 /

316

Page 189: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2016-12-22

Prio 3

Använd inte ramarAnvänd i första hand serverbaserade tekniker för att infoga innehåll i sidor.Använd inte ramar (frames) för att utforma webbplatsen. Det orsakarnämligen en rad problem med användbarhet och tillgänglighet.

Om denna riktlinjePrioritet: 3Principer: AnvändbarRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning,Systemutveckling

Rekommendationer för att infoga innehållAnvänd i första hand serverbaserade tekniker.Komplettera eventuellt med klientscript (Ajax).Undvik iframes, eller kompensera för nackdelarna.Använd inte ramar (frames).

Ibland är det bättre att infoga innehåll dynamisktän att kopiera

Hämta gärna innehåll dynamiskt, direkt från källan, när användaren besökersidan, om det fungerar med hänsyn till driftsäkerhet, intergitetsskydd,prestanda med mera. För innehåll som förändras ofta eller har interaktivadelar är en dynamisk koppling ofta den enda möjligheten, utöver en vanliglänk till källan. Men även för relativt statisk information kan det vara en bralösning i jämförelse med att kopiera innehållet när sidan skapas, eftersomdet blir enklare att hålla innehållet konsekvent och uppdaterat.

Det finns många sätt att infoga innehåll från olika källor i den html-kod somutgör en webbsida.

Infoga helst på serversidan

Sammanfoga i första hand på serversidan. Då blir resultatet, urwebbläsarens perspektiv, nämligen likvärdigt med vilken HTML-sida somhelst. Att sammanfoga innehåll från olika källor är en av de viktigastefunktionerna med ett webbpubliceringsverktyg (CMS).

Redan på 1990-talet användes server-side includes (SSI) för att till exempelkunna återanvända sidhuvud och navigeringsmeny. Senare har en mängdtekniska lösningar utvecklats, som kan infoga lokalt eller externt, statiskt

Riktlinje nr 94

Vägledning förWebbutveckling Sida 188 /

316

Page 190: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

eller dynamiskt innehåll, till exempel Java beans, PHP include, ASP.NETuser controls och portlets.

Komplettera eventuellt med klientscript

Det går också att låta webbläsaren sammanfoga innehållet. Fördelen är attdet ofta går enkelt och snabbt. Oftast räcker det med att kopiera in en kortsnutt HTML-kod med adressen till källan, vilket ni ofta kan göra utan hjälpav en programmerare. Det påverkar inte heller belastningen på servern.

För webbapplikationer med intensiv interaktion (kallas ibland rich internetapplications – RIA) är det ofta lämpligt att låta webbläsaren, snarare änservern, sköta den dynamiska uppdateringen av innehållet på sidan.Framförallt används då Javascript (AJAX) för att dynamiskt kommuniceramed servern. Läs mer om detta i R93 Använd Javascript för att ökatillgängligheten – inte tvärtom.

Använd inte ramar

Den första tekniska lösningen för infogning på klientsidan var ramar(frames). De användes ofta för navigation och sidhuvud när webben varung. Men de är en dålig lösning, eftersom ramar orsakar en radanvändbarhets- och tillgänglighetsproblem. Ramar gör att det blir

svårt eller omöjligt att spara bokmärken i webbläsaresvårt eller omöjligt att skicka en länk till en sida via e-post eller dela isociala mediersvårt eller omöjligt att kommunicera en länkadress i trycksvårare att skapa en webbplats som indexeras och hittas avsökmotorer på ett optimalt sättsvårare att hantera besökare som kommer till webbplatsen viasökmotorersvårare att använda webbplatsen för användare med skärmläsare ellertextwebbläsaresvårare för användaren att skriva ut webbplatsens innehåll.

IframesEn något nyare, men närbesläktad teknik är iframes. En iframe kanbeskrivas som ett rektangulärt hål i en webbsida, inuti vilket en annanwebbsida visas. I några fall är detta den enda framkomliga vägen, ochdärför vill vi inte helt döma ut alternativet. Men om du överväger iframes såtänk på följande:

I princip alla problemen med ramar gäller även iframes. Några av demgår delvis att kompensera för med script. Till exempel kan adressfältetuppdateras vid interaktion inom ramen på det sättet.Iframes är ofta svåra att hantera på mobilen. Till exempel är det inteuppenbart för användaren om rullning och zoomning gäller ramen elleromgivningen. Och det är svårt att ge ramen rätt storlek i alla typer av

Vägledning förWebbutveckling Sida 189 /

316

Page 191: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

enheter. Ska din webbplats kunna användas med olika skärmstorlekså kanske du behöver skapa flera alternativa storlekar på ramen.Sökmotorer räknar innehållets värde till den inramade sidan ellerwebbplatsen, inte till din sida. Om de överhuvudtaget hittar innehållet.Det är inte troligt att innehåll som ligger i en iframe går att hitta medwebbplatsens egen sökfunktion, om du inte anpassar den särskilt fördetta.

Mätbarhet

Använd en webbläsare som inte har stöd för ramar, till exempel Lynx, ochkontrollera att innehållet ändå är nåbart och begripligt.

Opera ger också möjlighet att enkelt stänga av stöd för ramar och iframes.

Senast uppdaterad: 2014-10-31

Prio 3

Gör webbadresser bokmärkningsbaraSe till att användare som gör bokmärken till sidor kommer tillbaka till rättsida i framtiden.

Om denna riktlinjePrioritet: 3Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Bevarande och gallring, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Interaktionsdesign, Prototypning,Systemutveckling

Rekommendationer för webbadresserSe till att adressen i webbläsarens adressfält alltid leder tillbaka tillaktuell sida.På dynamiskt skapade webbsidor är det inte alltid möjligt att kommatillbaka till precis samma innehåll med hjälp av adressen. Låt då denadress som visas i adressfältet, och som används för eventuelltbokmärke, leda till den närmaste lämpliga beständiga delen avwebbplatsen.

Mer om bokmärkningsbara adresserFörutom traditionella bokmärken i webbläsaren är det vanligt med genvägarfrån datorns skrivbord eller mobiltelefonens startskärm. Detta är också ensorts bokmärken.

Riktlinje nr 95

Vägledning förWebbutveckling Sida 190 /

316

Page 192: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Bokmärkningsbara sidor underlättar även delning via till exempel e-posteller sociala medier.

Vid delning – särskilt i trycksaker och i e-post där utrymmet kan varabegränsat, är korta adresser oftast bättre än långa. Se R99 Skapa kortawebbadresser för sidor som ska spridas.

Denna riktlinje innebär att webbadresser (URL:er) inte ska innehållasessionsinformation som inte ger önskvärt resultat, och att man inte skaanvända ramar, se R94. Använd inte ramar.

Referenser

Det finns mycket att tänka på när det gäller utformning av webbadresser.Därför finns det fler webbriktlinjer inom ämnesområdet länkar ochadressering.

ExempelKartfunktionen på Örebro kommuns webbplats använder skript för attuppdatera adressfältet när användaren navigerar i kartan. Det gör attadressfältets innehåll kan användas för att referera just det användaren serpå kartan.

Senast uppdaterad: 2014-11-01

Prio 5

Utnyttja webbläsarnas inbyggdafunktioner för utskriftAnvänd en stilmall för att låta användarna skriva ut från webbplatsen. Dåkan de förhandsgranska utskrifter via webbläsarens inbyggda funktion ochkontrollera hur tabeller, text och andra sidelement ska sidbryts. Förberäkningar, kvittenser, mottagningsbevis och liknande kan det dock varamotiverat att erbjuda särskilda utskriftsversioner.

Om denna riktlinjePrioritet: 5Principer: EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssättNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning, Testning

Rekommendationer för att underlätta utskriftUtnyttja webbläsarens inbyggda funktion för utskrift av innehållssidorpå webbplatsen och använd en stilmall för det.Tillhandahåll en utskriftsikon eller liknande om målgruppen saknar

Riktlinje nr 96

Vägledning förWebbutveckling Sida 191 /

316

Page 193: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

kunskap om webbläsarens inbyggda utskriftsfunktion ochkortkommandon som Ctrl+P.Knappar, symboler och liknande för att skriva ut kräver JavaScript föratt fungera. Låt även knapparna och symbolerna skapas av skriptet.Då kommer användare som inte har JavaScript påslaget inte att seknappen eller symbolen, och får då inte heller en trasig ikon.För utskrift av beräkningar, kvittenser, mottagningsbevis och liknandekan det vara motiverat att tillhandahålla en särskilt utskriftsversion.Använd stilmallen för att ta bort menyer och understrykningar samtstyra teckensnitt och sidlayout.Erbjud möjligheten att slå samman sidor till en utskrift.

Utnyttja webbläsarens inbyggda funktion förutskrift av innehållssidor på webbplatsen ochanvänd en stilmallMånga användare känner till webbläsarens inbyggda utskriftsfunktion viamenyalternativ och kortkommandon som Ctrl+P. Använd en stilmall för attlåta användarna skriva ut från webbplatsen. Då kan de förhandsgranskautskrifter och kontrollera hur tabeller, text och andra sidelement sidbryts.

Använd attributet ”media” på märkordet ”link” för att koppla en stilmall somanpassar dokument/webbsida för utskrift. Ange värdet ”print” för att peka uten stilmall som webbläsaren ska använda vid utskrift. Ett exempel på hur dukan göra detta:

<link rel=”stylesheet” type=”text/css” href=”/print.css” media=”print”>

I användbarhetstester har det visat sig att en del användare har behov av ensärskild utskriftsversion för utskrift av enstaka delar av en sida, exempelvisnär man presenterar beräkningar, kvittenser, mottagningsbevis ellerliknande. I dessa fall kan det vara motiverat att tillhandahålla en särskildutskriftsversion. Placera utskriftsymbolen i direkt anslutning till det innehållanvändaren förväntas vilja skriva ut.

Använd stilmallen för att ta bort menyer ochunderstrykningar samt styra teckensnitt ochsidlayoutSe till så att stilmallen för utskrift döljer designelement som inte är relevanta,till exempel menyer. Det kan också vara lämpligt att ta bort understrykningfrån länkar, som ändå inte är klickbara på papper. Utskriften bör innehållainformation om

avsändande organisation.var den utskrivna sidan befinner sig i webbplatsens struktur,exempelvis genom att skriva ut länkstigen, så att användaren kan hittatillbaka.hur aktuell informationen på sidan är. De flesta webbläsare skriverautomatiskt ut utskriftsdatum och webbadress.

Vägledning förWebbutveckling Sida 192 /

316

Page 194: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Låt stilmallen också styra teckensnitt och sidlayout:

Ändra till ett teckensnitt anpassat för tryck, i stilmallen för utskrift, omni använder ett teckensnitt som är anpassat för skärm påwebbplatsen. Exempel på teckensnitt som är bra för utskrift är CenturySchoolbook och Georgia.Se till att diagram, bilder och så vidare fortfarande är läsliga i svart, vittoch gråskala eftersom många användare bara kan skriva ut i svartvitt.Om webbplatsen använder en fast sidbredd kan sidlayouten för utskriftbehöva ändras. En läsbar spaltbredd är cirka 75 tecken inklusiveblanksteg. Detta är inte ett problem om webbplatsen använder enflytande layout.Se till att informationen inte påverkas om användaren har valt attbakgrundsbilder, färger eller kantlinjer inte ska skrivas ut.

Erbjud möjligheten att slå samman sidor till enutskriftGör det gärna möjligt att slå samman flera sidor till en enda utskrift. Det kanvara värdefullt när användare behöver skriva ut många sidor frånwebbplatsen, eller läsa sidorna utan uppkoppling. Sammanslagningar kanspara tid för användaren. Du kan slå ihop sidor exempelvis i HTML-, PDF-eller ePub-format.

MätbarhetKontrollera att sidorna får avsett utseende vid förhandsgranskning ochutskrift.Gör användningstester för att se om era användare ha behov avsärskilda utskriftsfunktioner för olika delar av webbplatsen.

Senast uppdaterad: 2014-11-01

Prio 3

Se till att bakåtknappen fungerarWebbläsarens funktion för att backa är en av de mest använda funktionernaför att navigera på webben, både inom en webbplats och mellanwebbplatser. Se därför till att den fungerar.

Om denna riktlinjePrioritet: 3Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning,Systemutveckling, Testning

Riktlinje nr 97

Vägledning förWebbutveckling Sida 193 /

316

Page 195: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Rekommendationer för bakåtknappenLåt bakåtknappen fungera (se undantag nedan).Undvik att öppna nya fönster, särskilt fönster som täcker helaskä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åtknappenfungerar kan nämligen bero på den grundläggande tekniken.

UndantagI följande fall bör bakåtknappen inte fungera:

Om användaren har loggat ut från sidor med känslig information – dåska det inte gå att backa tillbaka till dem, av säkerhetsskäl.När användaren har kommit till en punkt i en process där det intelängre ska gå att ångra sig, till exempel efter en elektronisk underskrift.Om användaren riskerar att oavsiktligt förlora information hen matat ini ett formulär.

Undvik att koda så att länkar automatiskt öppnas i nya fönster/flikar. Detenda sättet att ”gå bakåt” från ett sådant fönster är nämligen att stänga det,och användningstester visar att risken är stor att användaren på en sådanwebbplats blandar ihop bakåt- och stängknapparna och råkar stängaursprungsfönstret när hon egentligen bara vill backa.

Låt användarna själva välja om de vill öppna länkar i nya fönster eller inte.De flesta webbläsare har funktioner för att öppna länkar i nya fönster ellerflikar.

Ett blogginlägg beskriver för- och nackdelar med att öppna länkar i nyafönster/flikar.

MätbarhetTesta bakåtknappens funktion med följande steg:

Navigera till en annan webbplats genom att klicka på en länk somlämnar din webbplats. Testa om det går att gå tillbaka till dinwebbplats genom att trycka på bakåtknappen.Vandra runt på webbplatsen och kontrollera att du alltid kan backa,förutom vid de undantag som nämns ovan.Kontrollera att det inte går att backa på sidor där bakåtknappen inteska fungera, enligt undantagslistan ovan.Kontrollera att användarna förstår felmeddelandet som visas närbakåtknappen inte fungerar.

ReferenserAnvändbarhetsboken – bästa sätten att göra fungerande webb, av TommySundström. Förlag: Studentlitteratur.

Vägledning förWebbutveckling Sida 194 /

316

Page 196: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TerminologiBakåtknappen, alltså webbläsarens funktion för att backa till föregåendesida, ska inte förväxlas med tangentbordets baksteg (som används för attradera föregående tecken). På engelska heter det back button.

Nya fönster som öppnas när en webbsida laddas eller när användarenklickar på en länk kallas ibland för popup-fönster (varianter för sökbarhet:pop-up, pop up).

En ny flik kallas för new tab på engelska, medan fönster förstås heterwindow. Nya fönster eller flikar kan öppnas antingen av användaren själveller genom att attributet target används (med värdet _blank) för länk-

elementet, eller med hjälp av JavaScript.

Senast uppdaterad: 2017-05-15

Prio 4

Skriv rubriker till tabellerTabeller kan vara svåra att tolka – både för användare med skärmläsareoch för andra. Låt html-koden uttrycka vad tabellens olika delar innehåller,och hur de hänger ihop. På så vis blir tabellen tillgänglig för alla. Använd tillexempel th-element för att ange vilka celler som är rad- och kolumnrubriker.

Om denna riktlinjePrioritet: 4Principer: TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

Rekommendationer för tillgängliga tabellerAnvänd tabellrubriker såsom rad- och kolumnrubriker, och framhävdem grafiskt.Använd vid behov abbr-attributet för att ge förkortningar av rad- ochkolumnrubrikers innehåll.Koppla ihop rubrikceller med tillhörande dataceller. Detta gällersärskilt för komplexa datatabeller som har två eller flera logiska nivåermed rad- eller kolumnrubriker.

Använd tabellrubriker såsom rad- ochkolumnrubriker och framhäv dem grafisktFormge alla typer av datatabeller så att det blir enkelt att tolka derasinnehåll. Framhäv alla tabellrubriker, både rad- och kolumnrubriker grafiskt,så att användaren kan skilja dem från tabellens datauppgifter. Tabeller medmånga kolumner och rader blir lättare att läsa om de har tydliga

Riktlinje nr 98

Vägledning förWebbutveckling Sida 195 /

316

Page 197: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

kolumngränser och rader, till exempel med olika bakgrundsfärg för udda ochjämna rader. Många tabeller blir också bättre i utskrift om de förses medthead, tbody och tfoot.

Förkorta långa rad- och kolumnrubrikerSträva alltid efter att ha korta rad- och kolumnrubriker. När en skärmläsareläser upp en tabell, kan den läsa upp tillhörande rad- och kolumnrubrikerföre innehållet i varje datacell. Om rubrikerna är långa tar det tid att höradem upprepas om och om igen. Om det inte är möjligt eller lämpligt att göraen kort rubrik, så använd abbr-attributet för att ange en förkortad version avlånga rad- och kolumnrubriker, som skärmläsare kan använda.

Koppla ihop dataceller med rubrikcellerEn explicit koppling mellan rubrikceller och dataceller gör att skärmläsarekan läsa upp den tillhörande rubriken före innehållet i varje datacell. På såsätt slipper användarna memorera tabellstrukturen. Detta är särskilt bra förtabeller med många kolumner, eller med flera rubriknivåer. Attributet scopepå ett th-element anger för vilka dataceller rubriken gäller. Tillåtna värden ärrow, col, rowgroup och colgroup. Elementet colgroup märker uppkolumngrupper, medan tbody märker upp radgrupper. Ett alternativt sätt attuttrycka relationer mellan celler är att använda attributet id på th-elementenoch attributet headers på td-elementen. Headers kan innehålla en eller fleraidentiteter för rubrikceller. Om du sätter flera så skilj dem åt med mellanslag.

ExempelExempel på användning av abbr:

<th abbr="pris">Nettopris exklusive moms</th>

ReferenserSe även R83 Använd inte tabeller för layout

MätbarhetStäng av CSS i webbläsaren och kontrollera att det är möjligt att se skillnadpå rubrikceller och dataceller.

Senast uppdaterad: 2014-11-01

Prio 4

Skapa korta webbadresser för sidorsom ska spridas

Riktlinje nr 99

Vägledning förWebbutveckling Sida 196 /

316

Page 198: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om adressen till en sida ska spridas, till exempel i annonser eller trycktmaterial, så skapa en kort och tydlig webbadress.

Om denna riktlinjePrioritet: 4Principer: EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texterNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion

Rekommendationer för webbadresser som skaspridas

Skapa webbadresser som är så korta som möjligt, och som relaterartill den information som användarna söker.Använd gärna webbpubliceringssystemets egna funktioner för attskapa kortadresser.Var försiktig med externa tjänster för kortadresser. De kan slutafungera efter en tid.

Fördelar med korta webbadresserKorta adresser är lättare att komma ihåg.Korta adresser är lättare att skriva in i webbläsarens adressfält.Korta adresser tar mindre plats i trycksaker.Relevanta nyckelord i länkadressen ökar chansen till brasökmotorpositionering.

Många webbpubliceringssystem har funktioner för att skapa kortadressersom alias till längre ordinarie adresser som följer webbplatsens logiskastruktur. Sådana funktioner har fördelen att sidan inte behöver placeras pånågon särskild plats i innehållsstrukturen för att kunna ha en kort och enkeladress.

Var försiktig med externa tjänster för kortadresser

Det finns många tjänster på nätet som skapar kortadresser och omdirigerardem till långa adresser. Exempel är korta.nu, bit.ly och shorl.com. Om nianvänder en sådan tjänst ska ni vara medvetna om att tjänstens leverantörfår möjlighet att kartlägga all trafik till adressen och lägga in kakor ianvändarnas webbläsare. Det finns också en risk att tjänsten upphör attfungera efter en tid.

FördjupningDet finns mycket att tänka på när det gäller utformning av webbadresser.Därför finns det fler webbriktlinjer inom ämnesområdet länkar ochadressering. Riktlinjen Utforma webbadresser med omsorg (R100) ärsärskilt relevant.

Vägledning förWebbutveckling Sida 197 /

316

Page 199: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Mätbarhet

Skriv in den korta webbadressen i webbläsarens adressfält och se om rättsida laddas.

Terminologi

QR-kod kallas en speciell typ av kort-adresser som bara kan användas medmjukvarustöd (exempelvis en mobiltelefon med kamera). Det är ett mycketkompakt visuellt mönster som kan översättas till en webbadress.

Senast uppdaterad: 2014-11-01

Prio 4

Utforma webbadresser med omsorgSe till att era webbadresser kommer att vara tydliga och fungera bra, ävenpå papper. Webbadresser behöver vara enkla att uppfatta. De kan behövaanvändas till exempel från utskrivna e-brev eller tryckta material, eller läsasupp i etermedier. Det finns risk att användarna uppfattar dem fel. Utformadärför webbadresserna med omsorg.

Om denna riktlinjePrioritet: 4Principer: Användbar, FörtroendeingivandeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texterNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign, Målgruppsanalys, Prototypning, Systemutveckling

Utkast publicerat 2018-12-20Riktlinjen är omarbetad.

Kom gärna med synpunkter, antingen i kommentarsfunktionen sist på sidan,med epost till [email protected], eller i Facebookgruppen webbriktlinjer.

Rekommendationer för bra webbadresserGe webbadressen en logisk och hållbar struktur.Var försiktig med personuppgifter i webbadresser.Undvik teknikberoende och onödiga delar i webbadresser.Använd domännamnet – utan inledande “www.” – som huvudadress.Var försiktig med skiljetecken, mellanslag och specialtecken iwebbadresser.

Ge webbadressen en logisk och hållbar struktur

Riktlinje nr 100

Vägledning förWebbutveckling Sida 198 /

316

Page 200: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Webbadresser som på ett logiskt sätt återspeglar innehållets sammanhangkan hjälpa användare att orientera sig på webben. Inte bara inomwebbplatsen, utan redan när användaren först ser adressen (exempelvisgenom att hovra över en länk eller läsa adressen i ett mejl eller i entrycksak).

På de flesta webbplatser genereras sidans adress automatiskt när sidanskapas. Det brukar resultera i adresser som återspeglar en hierarkisk ellerkronologisk indelning av webbplatsens innehåll.

Ofta är en sådan ämnesbaserad indelning det mest pedagogiska. Särskiltom indelningen utgår från användarnas behov och inte exempelvisavsändarens interna organisationsstruktur.

Två exempel på tydliga adresser från Helsingborgs webbplats. Adressernassökvägar förtydligar sidans sammanhang:

helsingborg.se/trafik-och-stadsplanering/cykling/

helsingborg.se/uppleva-och-gora/friluftsliv-och-

motion/cykling/

Adress-strukturen brukar motsvaras av en trädstruktur ipubliceringssystemet. Men det är inte nödvändigt att strukturen är strikthierarkisk. Digitala “träd” kan konstrueras så att användaren hittar samma“gren” på alla de ställen i strukturen där den passar in. Exempelvis medhjälp av “genvägar” i trädet, eller genom en navigationsstruktur baserad påtaggar eller nyckelord. Då kan olika användare hitta rätt även om derasbegrepp och perspektiv på världen skiljer sig åt.

I adresser som består av ett flertal nivåer, med snedstreck (“/”) somavgränsare, är det bra om användaren kan att ta sig upp en nivå genom attta bort allt till höger om det sista snedstrecket.

Se även avsnittet om länkstigar i Visa tydligt var användaren befinner sig(R27).

När datum utgör den primära sorteringen (exempelvis för bloggar och andrakronologiskt ordnade samlingar av dokument) kan datumbaseradewebbadresser fungera bra. På motsvarande sätt kan diarienummer ellerliknande användas i webbadresser om det skapar tydlighet för användaren.

Två exempel på adresser som baseras på kronologi:

lagen.nu/prop/2017/18:4

miun.se/press/nyhetsarkiv/2017-12/ny-it-myndighet-

till-sundsvall/

En fördel med adresser som baseras på datum eller löpnummer är attadressen inte behöver ändras om sidan ska finnas kvar även när nyliknande information tillkommer. Då skapas helt enkelt nya adresser för den

Vägledning förWebbutveckling Sida 199 /

316

Page 201: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

nya informationen. Glöm bara inte att ange tydligt om viss information ärinaktuell (R24) i de äldre dokumenten.

I enstaka fall är det lämpligt att använda slumpmässiga koder som är unikamen svåra att förstå och gissa sig till. Exempelvis för tillfälliga adresser somanvänds då en användare ska visa att hen har tillgång till ett visst e-postkonto genom att klicka på en engångslänk som skickats till dennaadress.

Var försiktig med personuppgifter i webbadresserObservera att webbadresser ofta loggas, till exempel för webbanalys. Omdu låter personuppgifter utgöra del av webbadressen riskerar detta alltså attleda till att personuppgifterna läcker och att personuppgiftsbehandling skerpå andra ställen och för andra ändamål än vad du hade räknat med. Tänkefter noga innan du låter personuppgifter vara en del av en webbadress.Detta gäller även den del av webbadressen som kommer efter frågetecknet,alltså den del som brukar kallas query.

Undvik teknikberoende och onödiga delar iwebbadresserDelar av webbadresser är ibland enbart motiverade av den tekniskaplattform som används. Exempelvis filändelser som .aspx och .php. Dessaunderlättar sällan förståelsen för besökare (såvida de inte är ute efter atthacka sajten) och bör därför undvikas. Då underlättar ni dessutom etteventuellt framtida byte av publiceringssystem. Däremot bör du gedokument filnamn som beskriver innehållet (R9) för filer som ska laddas ner.

Många adresser kan bli lite kortare och tydligare genom att attteknikberoende filändelser och andra teckenföljder som upprepas för varjesida (exempelvis “/sidor/”) undviks.

I allmänhet är det viktigare att adresserna är tydliga och hållbara än att de ärkorta, men tänk på att det finns nackdelar med långa adresser:

Långa webbadresser kan vara svåra att presentera snyggt itrycksaker, och tar ganska lång tid att skriva av manuellt – särskilt förpersoner med nedsatt motorik.Om en lång adress skickas med e-post så händer det att den radbryts(ofta efter ca 70 tecken) och när användaren försöker använda länkenkanske bara delen innan radbrytningen kommer med.I andra sammanhang (exempelvis i mobila webbläsare) seranvändaren inte mer än en liten del av webbadressen.

Ett förslag är därför att skapa kortadresser för sidor som ska spridas (R99).

Använd domännamnet utan inledande “www.” somhuvudadressSkriv adressen på ett sådant sätt att den som läser informationen förstår att

Vägledning förWebbutveckling Sida 200 /

316

Page 202: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

det gäller en webbadress och kan använda den för att öppna sidan.

Undvik både ”http://” och ”www.” om det inte finns särskilda skäl att

skriva ut dem. Då blir presentationen kortare och inleds dessutom meddomännamnet, som brukar ge värdefull sammanhangsinformation. Särskilt itrycksaker är det ofta knappt om utrymme, och då är det bra att kunnahoppa över prefixen.

Särskilda skäl att ange hela adressen kan vara exempelvis:

När anropet av säkerhetsskäl redan från början behöver ske krypterat.Då är det viktigt att användaren skriver in just ”https://”.

När det är viktigt att ange adressen exakt, till exempel för att olikavarianter leder till olika versioner av innehållet, eller när adressenanvänds som vetenskaplig eller juridisk referens.När det inte framgår av sammanhanget att det är just en webbadressoch inget annat.När det verktyg du använder för redigering behöver förstå att det är enwebbadress, så att adressen med automatik kan göras klickbar. Dåkan du i och för sig ofta redigera bort prefixet efter att länken skapats.

Domänadressen (host-delen i webbadressen) bör alltså ha formen namn.se.Den äldre formen www .namn.se måste naturligtvis också fungera.Omdirigera därför den senare till den primära domänen. Det är bra om ävenfelskrivningar med två eller fyra w:n fungerar (”ww.” respektive ”wwww.”),som extra service till användarna.

Se till att automatiskt omdirigera från den osäkra versionen av HTTP tillHTTPS när en sådan finns.

Var försiktig med skiljetecken, mellanslag ochspecialtecken i webbadresserUnderstreck (”_”) är svåra att se när adressen visas understruken (tillexempel vid automatisk länkning i e-post, som sedan skrivs ut). Mångaanvändare vet heller inte var tecknet finns på tangentbordet. Däremotfungerar bindestreck, ”-”, bra.

Mellanslag i webbadresser kan du också med fördel ersätta medbindestreck. Annars visas mellanslaget ofta som “%20”, vilket gör det svårt

att läsa adressen i adressfältet.

webbriktlinjer.se/streck-tydligt-

men%20mellanslag%20otydligt

Om användarna kopierar en webbadress som innehåller mellanslag, för atttill exempel skicka den med e-post, finns det risk för att länken bryts ochdärmed blir svår att använda för mottagaren.

Undvik att ha flera skiljetecken (som “-”) efter varandra i adressen.

Vägledning förWebbutveckling Sida 201 /

316

Page 203: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Beroende på teckensnitt kan det vara omöjligt att veta hur många de är.

Undvik att blanda stora och små bokstäver.

Se Ta fram en policy för domännamn (R69) angående användning av desvenska bokstäverna å, ä och ö liksom vissa andra internationella tecken idomännamn.

Exempel på bra och dåliga webbadresserOBS! Exemplen är påhittade.

Länk baserad på internt id-nummer (rekommenderas inte): http://www.skolverket.se/sida.asp?id=1743

Begriplig adress: https://skolverket.se/bedomning/betygskriterier

Kortadress: skolverket.se/betyg

Adress som baseras på meningsfull kod: skolverket.se/diariet/2018/327

ReferenserDet finns mycket att tänka på när det gäller utformning av webbadresser.Därför finns det fler webbriktlinjer inom ämnesområdet länkar ochadressering.

TerminologiUniform Resource Locator (URL), på svenska kallat webbadress, är denteckensträng som används för att hämta eller aktivera en viss resurs pånätet, till exempel en webbsida:http://www.example.org/nyheter/dagens.html. Observera att

det även finns URL:er för e-post (mailto:[email protected]),

för telefonnummer (tel:+4681234567), för filhämtning och många andra

typer av resurser. Alltså inte bara webbsidor.

Uniform Resource Identifier (URI) är ett bredare begrepp än URL. Sammaformat som används för webbadresser kan nämligen även användas för attreferera till resurser som inte går att hämta eller aktivera digitalt (exempelvisISBN-nummer för böcker: urn:ISBN:1-56592-149-6) eller abstrakta

begrepp (exempelvis flygning: http://schema.org/Flight). Fördelen

med att använda URI-formatet för att på detta sätt namnge begrepp är attdet kan ge utökad tydlighet som kan vara nödvändig om informationen skakunna användas automatiskt. Här är ett exempel:

<div itemscope itemtype=”http://schema.org/Flight”>

Du landar i <span itemprop=”iataCode”

value=”MMX”>Malmö</span>

<span itemprop=”arrivalTime” value=”2019-03-

16T14:00+01:00”>klockan två</span></div>.

Vägledning förWebbutveckling Sida 202 /

316

Page 204: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Omdirigering (på engelska redirect) betyder att webbservern automatisktskickar vidare användaren till en annan adress. Detta görs oftast, teknisktsett, med hjälp av http-headern Location, men det går även att användameta-elementet i html eller javascript.

Personuppgifter (på engelska personally identifiable information, PII) ärinformation om en fysisk person. Exempelvis namn, kontaktuppgifter ochpersonnummer.

Query betyder fråga, och i webbadresser är det den del som följer efter ettfrågetecken (men före eventuellt “#”-tecken). Frågedelen i sin tur kan bestå

av en eller flera så kallade cgi-parametrar (cgi står för common gatewayinterface) sinsemellan separerade med tecknet “&”.

IDN står för internationalized domain names, alltså internationaliseradedomännamn. De kan bland annat innehålla å, ä och ö. Läs mer om sådana iTa fram en policy för domännamn (R69).

Senast uppdaterad: 2018-12-20

Prio 3

Markera obligatoriska fält i formulärInformera användaren om vilka fält i ett formulär som är obligatoriska, för attminska risken att onödig tid läggs på rättning av felaktigt eller ofullständigtifyllda formulär.

Om denna riktlinjePrioritet: 3Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning, Testning

Rekommendationer för obligatoriska fältAnvänd en bild av en asterisk (*) för att markera ett obligatoriskt fält iett 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 denhtml-version du valt.

Kodning av obligatoriska fältEn bild är bättre än själva tecknet asterisk, eftersom den som använder

Riktlinje nr 101

Vägledning förWebbutveckling Sida 203 /

316

Page 205: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

skärmläsare får ett begripligt budskap i stället för ordet ”asterisk” uppläst.Vissa skärmläsare är också inställda på att inte läsa upp vissa tecken somhistoriskt har missbrukats som avgränsare, bland annat asterisker.

WAI-ARIA erbjuder attributet aria-required för att markera att ett fält är

obligatoriskt i ett formulär. HTML5 innehåller ett motsvarande attribut,”required”. Använd den uppmärkning som fungerar med den html-versiondu valt.

Se också R2 Ge begripliga felmeddelanden och R50 Minimera antalet fält iformulär.

Mätbarhet i formulärKontrollera att det tydligt framgår vilka fält i ett formulär som är obligatoriska,även för den som använder hjälpmedel som skärmläsare.

TerminologiObligatorisk heter på engelska required eller mandatory.

Senast uppdaterad: 2014-11-01

Prio 5

Ange om ett dokument är en del avett större dokumentOm ett dokument är en del av ett större dokument, eller är nära relaterat tillandra material, länka dit och använd relevanta attribut som beskriverrelationen. Till exempel kan varje kapitel av en rapport ligga på varsin sida,med länkar sinsemellan, som har attributen ”prev” och ”next” . Det finnsockså särskilda attibut för tillhörande ordlistor, upphovsrättsinformation medmera. De underlättar för användare och sökmotorer att förstå att, och hur,dokument hör ihop.

Om denna riktlinjePrioritet: 5Principer: Användbar, EffektivRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texterNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Prototypning, Systemutveckling

Rekommendationer för dokument som hängerihop

Använd link-element och rel-attribut för att hänvisa till relateradedokument.

Riktlinje nr 102

Vägledning förWebbutveckling Sida 204 /

316

Page 206: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

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.

Om metadata för navigationVissa webbläsare, till exempel Opera, kan automatiskt generera ennavigeringsmeny om dokumentet innehåller korrekta link-element. Om”nästa” dokument märks upp på det här sättet kan en Opera-användareockså bekvämt skrolla med mellanslagstangenten. Webbläsaren hämtar dåautomatiskt nästa dokument när skrollningen når slutet av en sida. Påpekskärmar med webbläsare som stödjer link-element användsfingerrörelser för att bläddra.

Vissa webbläsare laddar nästa dokument i förväg medan användaren läser.Det kan innebära en märkbar förbättring av prestanda, särskilt överlångsamma anslutningar.

Sökmotorer använder också information i link-element för att kunnapresentera sökresultat bättre.

Link-elementets rel-attribut kan även användas för andra relateradedokument, till exempel en ordlista, upphovsrättsinformation eller alternativaformat.

Exempelkod<head> <title>Kapitel 5</title> <link rel="first"

href="kapitel-1.html"> <link rel="prev" href="kapitel-

4.html"> <link rel="next" href="kapitel-6.html"> <link

rel="last" href="kapitel-22.html"> <link rel="glossary"

href="ordlista.html"> </head>

MätbarhetAnvänd till exempel Opera för att verifiera att länkarna är korrekta.

ReferenserHur Google tolkar link-element.

TerminologiWebbläsaren Internet Explorer 10 introducerade en funktion kallad “flipahead”, som liknar Operas ”fast forward”. Båda funktionerna använder link-element med attributet rel=”next” om det finns, och gissar annars vilken sidasom följer (baserat på statistik mm).

När webbläsare hämtar sidor eller innehåll i förväg kallas det för”prefetching”. Förutom rel=”next” kan även rel=”prefetch” användas om duönskar förhandshämtning, eller rel=”prerender” som i vissa webbläsare göratt även sidpresentationen beräknas, för att möjliggöra ännu snabbare

Vägledning förWebbutveckling Sida 205 /

316

Page 207: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bläddring.

Senast uppdaterad: 2014-11-01

PrioInaktiv

Märk upp citat i kodenOm ni använder citat i texter ska de märkas upp som citat i koden. Då kan nilätt ge citat ett eget grafiskt utseende via css. Märkningen och utseendettydliggör för användarna vad som är ett citat från viss person, till skillnadfrån vanlig text som ni själva som avsändare står för. Hjälpmedel kan ocksåbehöva korrekt kodade citat för att kunna ange för användarna när något ärett citat.

Riktlinjens innehåll är fortfarande korrekt, men vi har valt att ta bort den frånlistningar eftersom den är relativt lågprioriterad och antalet riktlinjer lätt bliröverväldigande.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

RekommendationerMärk upp längre citat, som består av ett eller flera textstycken, medblockquote.

Märk upp korta citat med q.

Varför är det bra om citat märks upp?

Syftet med html är semantisk uppmärkning. Enbart citattecken räcker inte

för att identifiera ett citat, eftersom citattecken även används för andrasyften inom html. Dessutom varierar bruket av citattecken mellan olikaspråk.

Citat i löpande text markeras ofta grafiskt med citattecken. För blockcitatanvänder man dock av konvention sällan citattecken, utan snarare indragfrån marginalen, så att det citerade stycket ser ut som ett eget block påsidan.

För q-elementet är det webbläsarens ansvar att infoga synliga citattecken

kring q-märkt text. Vilka citattecken som visas kan du styra med css,

exempelvis för att visa olika tecken för olika språk; se kodexempel nedan.Vissa äldre webbläsare (till exempel Internet Explorer före version 8)

Riktlinje nr 103

Vägledning förWebbutveckling Sida 206 /

316

Page 208: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

genererar inte citattecken, och har inte heller stöd för att alstra dem viaCSS.

Använd blockquote och q enbart för faktiska citat, inte för att markera till

exempel ironi.

Attributet ”cite” kan länka till en källa för citatet, men webbläsarstödet är idet närmaste obefintligt.

Relaterade riktlinjer

Riktlinje 121, som motsvarar WCAG 1.3.1, handlar om semantiskuppmärkning av sidans innehåll

Exempel

CSS-kod för att generera citattecken (svenska, brittisk och amerikanskengelska):

:lang(sv) q quotes:”\201d” ”\201d” ”\bb” ”\ab”:lang(en-GB) q quotes:”\2018″ ”\2019” ”\201c” ”\201d”:lang(en-US) q quotes:”\201c” ”\201d” ”\2018” ”\2019”

Senast uppdaterad: 2017-10-01

Prio 4

Använd rätt html-element när ni görlistorEn av poängerna med HTML är att språket kan användas för att märka uppsemantiken i ett dokument. Märk upp listor som listor, och se till att ingetannat än listor är märkta så. Skärmläsare och andra hjälpmedel behöverkorrekt kodade listor för att kunna signalera till användaren att en listafaktiskt är just en lista.

Om denna riktlinjePrioritet: 4Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Prototypning

Rekommendationer för listorMärk upp alla listor som listor med korrekta HTML-element.Använd inte listrelaterade HTML-element för sådant som inte är listor.

Riktlinje nr 104

Vägledning förWebbutveckling Sida 207 /

316

Page 209: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Listor i HTMLDet finns tre olika typer av listor i HTML:

oordnade listor – punktlistorordnade, numrerade, listordefinitionslistor.

En ordnad lista används när punkterna behöver komma i rätt ordning. Detär inte viktigt i en oordnad lista. En lista med ingredienser för en sockerkakaär en oordnad lista: det spelar ingen roll om man nämner vetemjölet föreäggen eller vice versa. Bakinstruktionen är dock en ordnad lista: man måsteblanda ingredienserna innan man gräddar kakan, annars blir det inte ensockerkaka.

Notera att det inte handlar om sortering, utan om inbördes ordning. En listaöver svenska 1900-talsförfattare är en oordnad lista, även om namnen stårsorterade i bokstavsordning. Däremot är en topp-tio-lista medfavoritförfattare en ordnad lista. En navigeringsmeny på en webbplats är i deallra flesta fall en oordnad lista.

En definitionslista (dl) kan användas för olika typer av nyckel- ellervärdelistor, eller för att märka upp till exempel en dialog i ett manuskript.Varje element består av en eller flera nycklar (dt) och ett eller flera värden(dd).

Tyvärr finns det en överdriven användning av listor. En sekvens är intenödvändigtvis en lista. Det är inte ovanligt att se formulär uppmärkta med uleller ol, bara för att författaren vill ha ett ”gratis” li-element runt varjeetikettpar eller fältpar för att de ska presenteras på en egen rad. Det är attanvända HTML på ett sätt det inte är tänkt.

En tumregel kan vara att om man vill trolla bort listpunkter med CSS för attpresentationen ska bli begriplig, borde innehållet förmodligen inte alls görastill en lista. Till exempel är det ytterst få formulär som bör ha en listpunkteller ett ordningsnummer framför varje etikett eller fält.

TerminologiTermen semantik beskrivs i terminologiavsnittet under R82 Användstilmallar för att separera presentationen från innehållet.

Senast uppdaterad: 2014-11-01

Prio 1

Skapa rubriker med h-element

Riktlinje nr 105

Vägledning förWebbutveckling Sida 208 /

316

Page 210: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Märk upp rubriker med h1, h2 och så vidare. Undvik att särskilja en rubrikfrån brödtext enbart genom formgivning. Det gör det nämligen svårare förpersoner med vissa hjälpmedel att navigera på sidan, och svårare försökmotorer att avgöra vad sidan handlar om.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

Rekommendationer för att skapa tillgängligarubriker

Märk upp rubriker korrekt, med rätt hierarkisk ordning.Välj inte rubriknivå efter textstorleken i webbläsarna. Utgå frånsemantiken och använd CSS för att styra presentationen.

Varför är detta viktigt?Korrekt användning av rubriker bidrar till att

presentationen blir enhetlig på webbplatsens alla sidordet blir lättare att läsa dokumentet utan stilmallarsökmotorer hittar relevant information på sidornaanvändaren får en överblick över dokumentetvissa webbläsare och hjälpmedel kan skapa en automatiskinnehållsförteckning.

Hjälpmedel behöver en korrekt strukturkod, för att kunna beskriva föranvändarna vad som är en rubrik. En h1-rubrik ska normalt vara rubriken förhela dokumentet, och bara förekomma en gång i koden, som första rubrik.Dokument som innehåller flera separata ämnen kan dock ha flera h1-rubriker.

Sökmotorer utnyttjar var ett ord finns i dokumentet för att avgöra hurrelevant dokumentet är för en sökning med det ordet. Ord i h1- eller h2-element anses ha högre relevans än ord i brödtext.

Rubrikelement ska givetvis inte missbrukas för sökmotoroptimering.Sökmotorernas algoritmer kan genomskåda sådana försök.

HTML5 erbjuder ett alternativt sätt att strukturera dokument och rubriker, viasection-element. Varje sektion får då sin egen rubrikhierarki med början påh1. Det här är dock inte implementerat i alla webbläsare och hjälpmedelännu, så använd h1–h6 tillsvidare.

MätbarhetOpera har en funktion för att skapa en innehållsförteckning baserad pådokumentets h-rubriker. Då kan du se om det saknas rubriker, för att de inte

Vägledning förWebbutveckling Sida 209 /

316

Page 211: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

är korrekt märkta.

W3C:s HTML-validerare kan också generera en outline av dokumentetutifrån rubrikerna.

ReferenserSe även R82 Använd stilmallar för att separera presentationen fråninnehållet och R61 Skriv tydliga och informativa rubriker

TerminologiTermen semantik beskrivs i terminologiavsnittet under R82 Användstilmallar för att separera presentationen från innehållet.

Senast uppdaterad: 2014-11-01

Prio 3

Stryk aldrig under text som inte ärlänkadNär text är understruken signalerar det till användarna att den är klickbar.

Om denna riktlinjePrioritet: 3Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign

Rekommendationer för understruken textStryk aldrig under text som inte är länkad, eftersom det kan ledaanvändarna att felaktigt tro att texten är en länk.

Relaterade riktlinjerGör länkar och klickbara ytor enkla att använda för alla (R34)Ge webbplatsen en god läsbarhet (R39)

Senast uppdaterad: 2014-11-01

Riktlinje nr 106

Vägledning förWebbutveckling Sida 210 /

316

Page 212: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

PrioInaktiv

Analysera hur webbplatsen kommeratt användas, och av vemDen första fasen i det användarcentrerade arbetssättet är att göra enanvändningsanalys, där ni kartlägger målgrupperna och behoven.Användningsanalysen är grunden för att ni ska kunna skapa en användbarwebbplats med funktioner som blir använda.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?: Målgruppsanalys

Rekommendationer för att analyseraanvändningen

Kartlägg målgruppernaAnalysera användningssituationernaGör en uppgiftsanalysIdentifiera användarbehovenEnas om användningsmålen

Kort beskrivning av aktiviteternaHär följer en mycket kort beskrivning av aktiviteterna.

I många fall kan ni utföra flera av aktiviteterna vid samma tillfälle. Grupperaaktiviteterna utifrån era befintliga metoder för förvaltning och utveckling,samt på det aktuella uppdragets karaktär.

Kartlägg målgruppernaDen första aktiviteten är att identifiera, analysera, kategorisera, prioritera ochbeskriva målgrupperna. Att arbeta med målgrupper på ett genomtänkt sättär grunden för att skapa en användbar webbplats. Se till att ni har godakunskaper om era målgrupper, deras behov och beteenden, kompetens ochi vissa fall även yrkesroll (till exempel kundcenter–handläggare).

Analysera användningssituationernaDen andra aktiviteten är att analysera användningssituationerna. Identifieraoch analysera de sammanhang där er kommande tjänst eller funktion ärtänkt att användas. Genom analysen får du kännedom om avgörandefaktorer som påverkar användbarheten.

Riktlinje nr 107

Vägledning förWebbutveckling Sida 211 /

316

Page 213: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Gör en uppgiftsanalysAtt göra en uppgiftsanalys, den tredje aktiviteten, ger kunskap om hurmålgrupperna utför en viss uppgift i ett givet sammanhang.

Identifiera användarbehovenDen fjärde aktiviteten är att identifera de behov som användarna har, så attni kan utveckla en webbplats som stödjer behoven.

Enas om användningsmålenDen femte aktiviteten är att ni enas om användarnas användningsmål, vadde har för mål med att använda er webbplats. Användningsmålen ska varavägledande för det fortsatta arbetet.

Ett sätt att formulera mål är att formulera dem enligt en metod som kallasSMART, där bokstäverna står för: S = specifikt, M = mätbart, A =accepterat, R = realistiskt och T = tidssatt.

FördjupningVägledning i nyttorealisering från EkonomistyrningsverketAnvändbarhet och användarcentrerat arbetssättR108. Ta fram designförslagR109. Testa/utvärdera designförslagR110. Stäm av resultat med ansvarig

Senast uppdaterad: 2018-04-16

PrioInaktiv

Ta fram designförslagDen andra fasen i det användarcentrerade arbetssättet är att ta framdesignförslag som visar hur en målgrupp utför en viss uppgift. Ettdesignförslag består av en prototyp och en uppgiftsbeskrivning. Dessautvecklas successivt. Börja med en konceptuell design. Förtydliga i eninteraktionsdesign, som sedan ytterligare bearbetas till en detaljerad design.

Om denna riktlinjePrioritet: InaktivPrinciper: AnvändbarRoller/arbetsuppgifter:När i utvecklingsprocessen?:

Rekommendationer för designförslag

Riktlinje nr 108

Vägledning förWebbutveckling Sida 212 /

316

Page 214: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

1. Ta fram en konceptuell design bestående av en prototyp medtillhörande uppgiftsbeskrivning.

2. Ta fram en interaktionsdesign utifrån den konceptuella designen.3. Ta fram en detaljerad design utifrån interaktionsdesignen.

Om designförslagMed ett designförslag kan alla resurser inom ett projekt tidigt lämnasynpunkter på lösningsförslaget. Designförslaget bidrar till att alla i projektettalar om samma sak.

En framgångsfaktor för designförslag är att man har fokus på rätt saker vidrätt tillfälle. Ett designförslag bör utvecklas i tre steg: konceptuell design,interaktionsdesign och detaljerad design. Det är främst prototypen somutvecklas mellan dessa nivåer. Uppgiftsbeskrivningen brukar vara relativtoförändrad.

Utvecklingen av prototyper är inte början på en konstruktion. Det kan varabra att poängtera det, för att undvika att man låter bli att göra ändringar pågrund av att man ”redan byggt det”. En prototyp ska bara ge en förhandstittpå systemet och en chans att tidigt utvärdera designen och komma medsynpunkter.

ExempelNedan visas exempel på olika designfaser i ett system där personuppgifter,adress och information ska matas in.

Konceptuell designDen konceptuella designen ska visa vad och i vilken ordning information skapresenteras, men den kan även visa navigering. Det första utkastet till denkonceptuella designen visar vilken information som ska visas och i vilkenordning den ska visas:

När den konceptuella designen är färdig kan den se ut så här:

Nu syns vilken information som ska matas in och i vilken ordning. Här ärinformationen uppdelad i informationsmängder, inte på olika sidor. Två ellerflera av dessa informationsmängder kan senare hamna på samma sida.

InteraktionsdesignInteraktionsdesignen visar var och hur informationen presenteras. Vi utgårvi från exemplet på konceptuell design ovan.

Vägledning förWebbutveckling Sida 213 /

316

Page 215: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Den första interaktionsdesignen såg ut så här.

När interaktionsdesignen är färdig kan den se ut så här.

Personuppgifter och adressuppgifter presenteras i det nya förslaget påsamma sida. Vissa fält har anpassats till den information de ska innehålla,se till exempel fältet för postnummer. Fältet postort kan inte redigeras.Informationen i fältet ska hämtas automatiskt utifrån det inmatadepostnumret.

Detaljerad design

I den detaljerade designen försöker man visa hur den slutgiltiga sidankommer att se ut. Detta exempel bygger vidare på resultatet frånkonceptuell och interaktionsdesign ovan. Fälten för start- och slutdatum harersatts med period och matas in med hjälp av en rullgardinsmeny.

I den detaljerade designen visas färger, teckensnitt och placering av objekt.I ett tillhörande dokument beskrivs tab-ordning, initiala värden,markörplacering och andra egenskaper för fönstret.

FördjupningTema: Användbarhet och användarcentrerat arbetssättR107. Utför användningsanalysR109. Testa/utvärdera designförslagR110. Stäm av resultat med ansvarig

Senast uppdaterad: 2018-04-16

PrioInaktiv

Testa och utvärdera designförslagDen tredje fasen i det användarcentrerade arbetssättet är att testa ochutvärdera designförslagen. Ordna helst tester och utvärderingar flera gångerunder er arbetsprocess, allt eftersom ni utvecklar designen.Med test menar vi användningstest, där användare testar en prototyp,

Riktlinje nr 109

Vägledning förWebbutveckling Sida 214 /

316

Page 216: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

genom att utföra en eller flera uppgifter. Med utvärdering menar vi att manpresenterar ett designförslag för någon, som ger synpunkter. Det kan varaen användbarhetsexpert som gör en expertutvärdering, eller en fokusgruppsom har synpunkter på förslaget i en workshop.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Rekommendationer för att testa och utvärderadesignförslag

Låt användare testa prototyper med designförslag, se R108 Ta framdesignförslag.Låt en expert eller en fokusgrupp ge synpunkter på designförslag.

Kort om utvärdering av prototyper ochdesignförslagNi kan ha olika syften med testet beroende på vilken detaljnivå ettdesignförslag har. För ett konceptuellt designförslag vill ni kanskekontrollera att användare förstår navigeringen. Ett detaljerat designförslagkan senare testas med slutanvändare, som får arbeta igenom en uppgiftfrån start till mål.

Det finns många olika varianter av tester och utvärderingar. Alla fyller olikamål och syften. Men alla syftar i slutändan till att säkerställa att ni byggerrätt produkt, och att ni i ett tidigt skede kan hitta fel och brister. Ju tidigare niupptäcker fel och brister, desto större är chansen att ni kan åtgärda dem.Det blir dessutom oftast dyrare att åtgärda problem ju längre ni har kommit iutvecklingsprocessen.

FördjupningSe även:

Tema: Användbarhet och användarcentrerat arbetssättR37. Följ upp hur webbplatsen användsR107. Utför användningsanalysR108. Ta fram designförslagR110. Stäm av resultat med ansvarig

Senast uppdaterad: 2018-04-16

PrioInaktiv

Riktlinje nr 110

Vägledning förWebbutveckling Sida 215 /

316

Page 217: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Stäm av resultat av utvärderingenmed ansvarigDen fjärde fasen i det användarcentrerade arbetssättet är att återkopplaresultatet av utvärderingen till uppdragsgivaren, som sedan beslutar omnästa steg.

Om denna riktlinjePrioritet: InaktivPrinciper:Roller/arbetsuppgifter:När i utvecklingsprocessen?: Interaktionsdesign, Målgruppsanalys

Rekommendationer för att stämma avdesignförslag

Ge de ansvariga beslutsunderlag, till exempel uppgifter om hur väldesignförslaget uppfyller användarmålen enligt de senaste testerna,och en beskrivning av nya användarbehov som ni har upptäckt sedanden senaste avstämningen.De ansvariga fattar beslut om vad som ska bli nästa steg i arbetet.Om designförslaget ska omarbetas behövs ett beslut om vilka faser niska gå igenom igen.

Utformning av designförslagDesignförslaget kan se ut på olika sätt beroende på när i arbetsprocessenen viss avstämning sker. Det kan bestå av allt från pappersprototyper tillfungerande, digitala prototyper. Se R107 Ta fram designförslag.

Senast uppdaterad: 2018-04-16

Prio 1

Anpassa webbplatsen även för småskärmarAllt fler använder mobilen eller andra enheter med små skärmar för attbesöka webbplatser och använda tjänster och program. Anpassa därförinformation, funktioner och gränssnitt för alla typer av skärmar.

Om denna riktlinjePrioritet: 1Principer: Användbar, Tekniskt oberoendeRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Inköpare och beställare, Skriva texter, Standarder för webbplatser,

Riktlinje nr 111

Vägledning förWebbutveckling Sida 216 /

316

Page 218: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign,Målgruppsanalys, Testning

Rekommendationer för mobil tillgänglighetVisa 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.

Visa det viktigaste innehållet tidigtTänk på att små skärmar eller fönster, liksom större skärmar med lågupplösning, ställer högre krav på en genomtänkt prioritering av de aktiviteteroch innehåll som användaren ska mötas av. Det som är viktigast föranvändaren måste lyftas fram tidigt i gränssnittet.

Små skärmar ökar också kraven på att rubriker och texter är korta ochbegripliga. Se även R10. Ge all information på begriplig svenska som ärminst lika viktigt i mobila sammanhang som annars.

Anpassa innehållet till små skärmarAnvänd gärna responsiv design (följsam webbdesign). Då anpassaswebbsidan automatiskt efter hur stor skärmen är på användarens enhet (omdenna har stöd för CSS media queries). Se även R91 Skapa en flexibellayout.

Tänk på att:

Skriva så korta texter som möjligt. Gå rakt på sak och undvikinformation som inte behövs. Dubblera inte information på flera ställen,till exempel i brödtext respektive puff. Publicera helst text i html, intesom dokument. Stora filer tar lång tid att ladda ner till mobiler ochpåverkar både bandbredd och surfkostnad för användarna. Beskrivfilerna så bra du kan så att användaren kan ta ställning till om det ärmödan värt att öppna filen. Se R88. Publicera i första hand dokument iHTML.Referera inte till grafiska placeringar. Undvik beskrivningar som ”Läs ipuffen till höger”, ”se texten nedan” och så vidare. Hänvisa istället tillrubriknamn eller gör en ankarlänk inom sidan.Välj att anpassa bilders storlek automatiskt (för olika skärmstorlekaroch upplösningar) och ange mellanrum i procent.Gör inte webbplatsen beroende av att användaren kan föra en pekareöver en yta (motsvarande funktionerna mouseover eller hover)eftersom detta inte alltid är möjligt på till exempel pekskärmar.Testa alltid hur din text kommer att se ut på en liten skärm.

Vägledning förWebbutveckling Sida 217 /

316

Page 219: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Anpassa funktionaliteten till små skärmar

Se till att funktionerna stämmer överens med enheterna. Presentera tillexempel endast den mobila e-legitimationen för mobila användare eftersomdet bara är den lösningen som är relevant. Underlätta gärna genom attstarta den mobila säkerhetsapplikationen vid inloggning och eventuellunderskrift.

Tangentbordet i mobila enheter ska vara anpassat till de inmatningsfält somanvändaren ska fylla i. Förväntas användaren till exempel fylla i en e-postadress och webbadress måste @-tecken och snedstreck finnas med.Om användaren ska fylla i telefonnummer ska tangentbordet innehålla siffrorsamt exempelvis plus-tecken för landsnummer. I HTML5 finns ettstandardiserat sätt att anpassa inmatningsfält efter förväntat innehåll.

Se till att användargränssnittskomponenter (länkar, knappar, kryssrutor ochandra interaktionselement) inte är placerade för tätt intill varandra, eftersomprecisionen vid fingerstyrning inte blir lika hög som med musanvändning.

Se till att det går att zooma

Användaren kan zooma till exempel genom att minska och förstora medhjälp av fingrarna på en pekskärm. Upplys när tjänsten fungerar smidigarepå en större skärm, om tjänsten är så komplex att ni inte kan erbjuda enoptimal lösning för små skärmar.

Använd inte ramar

Det finns många nackdelar med ramar (som i HTML kallas för frames elleriframes). Se R94. Använd inte ramar. När många förväntas använda mobilagränssnitt är detta särskilt aktuellt. Många funktioner och tjänster sominfogas via ramar är inte utvecklade med tanke på små skärmar. Omwebbplatsen trots allt använder ramar bör därför en möjlighet ges att öppnaramens innehåll på ett sätt som gör åtminstone hela skärmen tillgänglig – tillexempel med en vanlig länk.

Gör det enkelt att skapa bokmärke/genväg tillwebbplatsen

Berätta gärna för användarna hur man lägger till ett bokmärke på denmobila enhetens skärm. Det gör att bokmärket upplevs som en app-symbol/ikon och gör det enkelt för användaren att komma åt tjänsten ellerwebbplatsen på samma sätt som en app. Då blir det enklare för användarenatt hitta tillbaka.

Exempel

Skatteverket har anpassat en del av sina e-tjänster, till exempelSkattekonto.

Vägledning förWebbutveckling Sida 218 /

316

Page 220: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Sveriges Television har utvecklat sin webbplats SVTPlay med responsivdesign vilket gör att den fungerar bra i mobila enheter.

MätbarhetAnalysera användarnas beteenden i mobila enheter med hjälp avstatistikprogram. Var dröjer sig användarna kvar? På vilka sidorlämnar användare tjänsten utan att komma till avslut? Harmobilanpassningen lett till ökad användning av tjänsten?Testa användbarheten tidigt i utvecklingen, gärna med hjälp avprototyper och slutanvändare. Kan användarna enkelt navigera ochlösa de viktigaste uppgifterna? Fungerar tjänsten för olikafingerstorlekar? Se vidare R34. Gör länkar och klickbara ytor enkla attanvända för alla.Testa webbplatsen i olika enheter och webbläsare. Det finnswebbaserade verktyg som kan användas för att testa hur enwebbplats ser ut med olika skärmupplösningar.Följ upp med enkäter och gör det lätt för användaren att gesynpunkter i tjänsten.

Terminologi

Datatermgruppen rekommenderar följsam design, men direktöversättningenresponsiv design är än så länge betydligt vanligare.

Uttrycket mobile first innebär att man först designar ett system för mobilaenheter. Tanken är att det medför ett fokus på det viktigaste, vilket ärpositivt även för resten av systemet.

Senast uppdaterad: 2015-09-01

Prio 3

Ge ordförslag vid sökning ochinmatningUnderlätta för användarna genom att ge dem förslag på sökord när de utfören sökning på en webbplats. Funktionen ger bättre sökträffar, underlättar förvissa personer med skrivsvårigheter samt kan spara tid och förenkla för allaanvändare.

Om denna riktlinjePrioritet: 3Principer: Användbar, Effektiv, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning,

Riktlinje nr 112

Vägledning förWebbutveckling Sida 219 /

316

Page 221: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Systemutveckling

Rekommendationer för ordförslagGe dynamiska ordförslag i sök- och inmatningsfältGe förslag på alternativa sökord och stavningar efter sökningGe statiska ordförslag på rätt sätt

Ge dynamiska ordförslag i sök- och inmatningsfält

Förslag på ord eller fraser i ett sök- eller inmatningsfält kan underlätta föranvändaren att fylla i rätt information.

Ibland kan webbläsaren automatiskt ge användaren relevanta förslag påinmatning, tack vare att den känner igen vilken typ av inmatningsfält detgäller och kommer ihåg vad användaren tidigare skrivit i liknande fält. SeMärk upp vanliga formulärfält i koden (R153).

I andra fall kan du som publicerar sidan skapa funktioner som hämtarrelevanta förslag från annat håll:

Utforma funktionen exempelvis med av en rullgardinsmeny så att en rutafälls ned under sökfältet efter att användaren har fyllt i några tecken isökfältet.

Rutan som fälls ner kan innehålla förslag på längre ord eller begrepp sominnehåller de tecken som användaren redan fyllt i. Det är ett sätt att visa vadsom går att söka på, men funktionen fungerar även som interaktivstavningshjälp.

De olika förslagen på sökord kan till exempel hämtas från manuelltförberedda listor med termer som är viktiga i sammanhanget, ellergenereras automatiskt baserat på indexerad text på webbplatsen. Ge gärnaförslag som motsvarar synonymer till inmatade ord, liksom korrigeringar avvanliga felstavningar av de indexerade orden.

Tänk på att användaren förväntar sig att en sökning på de rekommenderadeordförslagen ska resultera i bra sökträffar. Prova själv att söka på devanligaste sökfrågorna och arbeta redaktionellt för att dessa ska leda tillanvändbar information. Kontrollera besöksstatistiken och sökbeteendetregelbundet.

Ordförslag är värdefulla vid sökning, men även inmatningsfält av andra slagkan förbättras med samma typ av lösning. Till exempel kan inmatning i fältför gatuadress kontrolleras mot en adressdatabas. Det minskar risken för attanvändaren registrerar en gatuadress som inte existerar eller är tvetydigeller felstavad.

Vägledning förWebbutveckling Sida 220 /

316

Page 222: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Förutom förslag på sökord kan sökresultat (sidtitlar) presenteras direkt i dendynamiska listan. Det kan gälla till exempel sidor om produkter, dokumenteller nyheter. Se exempel från Västra Götalandsregionen. På så vis slipperanvändaren gå via en särskild sökresultatsida och kan snabbare kommafram till målet. Detta upplägg är mest användbart när sannolikheten för attvisa rätt länk är stor, till exempel då antalet matchande sidor är litet, eller dådet finns matchande sidor som är mycket populära.

Var noga med interaktionsdesign vid dynamiska ordförslag!

Ge förslag på alternativa sökord och stavningarefter sökning

Många användare ändrar sin sökfråga några gånger för att successivtförbättra sökresultatet. Därför är det värdefullt om en ny sökruta med aktuellsökfråga förifylld presenteras i anslutning till sökresultaten.

Användare kan få hjälp att förbättra sin sökfråga (till exempel rätta enfelstavning) genom att alternativa sökord presenteras i anslutning till dennasökruta. Genom att dessa presenteras som länkar eller knappar, tillexempel efter orden ”Menade du”, kan användaren välja dem utan att ensbehöva använda inmatningsfältet.

Ordförslag efter sökning kan i princip skapas på samma sätt som somdynamiska sökförslag under pågående inmatning, men en närmare analysav det aktuella fallet bör avgöra utformningen. Eventuellt kan det varalämpligt att indikera när en felstavning tycks ha inträffat, på ett annat sätt änt.ex. förslag på synonymer.

Ordförslag efter sökning samt markeringar av felstavningar, till exempelgenom röda understrykningar, är särskilt värdefulla för användare som inteser på skärmen under inmatning (utan till exempel tittar på tangentbordet föratt kunna träffa rätt tangent). Men även den som ser inmatningen kanbehöva stavningshjälp.

Exempel: Bilden visar hur man på Myndigheten för delaktighet presenteraralternativa sökningar som länkar för att underlätta för användarna att rättatill felstavningar utan att behöva använda sökfältet.

En sådan funktion underlättar för användaren att rätta till fel, vilketrekommenderas av framgångskriteriet 3.3.3 i WCAG 2.0.

Som underlag för förslag på alternativa sökord kan ordlistor användas, menäven produktdatabaser, synonymordlistor, taxonomier och så kallade

Vägledning förWebbutveckling Sida 221 /

316

Page 223: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ontologier, från vilka under- eller överordnade begrepp kan hämtas.Följande är ett påhittat exempel på hur det kan se ut:

Du sökte efter “volvo”.Prova bilmärken för att bredda sökningen, eller volvo amazon, volvopenta eller volvo geely för att snäva in den. Fler alternativasökningar: Ford, BMW, Toyota.

Använd statiska textförslag på rätt sätt

Statiska exempeltexter kan presenteras i anslutning till inmatningsfältet ellerinuti inmatningsfältet innan användaren själv skrivit in någonting där. Detsistnämnda kallas för platshållartext (placeholder på engelska). Statiskatextförslag kan hjälpa användaren att förstå vilken information eller vilketformat som förväntas i fältet. Det bästa är om systemet kan utformas så attalla tänkbara inmatningsalternativ fungerar (se R57 Låt användarna fylla iinformation i valfritt format). Men när detta inte är möjligt är exempeltexterett bra sätt att hjälpa användaren att undvika misstag i inmatning (vilketriktlinje 3.3 i WCAG 2.0 förespråkar).

Exempel: Statiska textförslag kan visas vid sidan av inmatningsfält eller somplatshållartexter.

Det är viktigt att en eventuell platshållartext inte används istället för etikett(label) eftersom den försvinner när användaren börjat fylla i text. Då blir detsvårt för en användare som är osäker på fältets syfte att ta reda på dettautan att radera inmatad text, alternativt ladda om sidan. Platshållartext börinte användas för information som är nödvändig för användaren, eftersomdet finns situationer då platshållartexten inte presenteras för användarenöverhuvudtaget (till exempel vid användning av vissa skärmläsare). Läsvidare om etiketter i R55 Skapa tydliga och klickbara fältetiketter.

Inte heller bör en platshållartext utformas så att den kan förväxlas med enförifylld sökfråga, eftersom det kan leda till att användaren lämnar fältet utaninformation trots att hen faktiskt skulle haft nytta av att fylla i fältet.

Var noga med interaktionsdesign vid dynamiskaordförslagGe ordförslag vid rätt tillfälleAv effektivitets- och prestandaskäl är det ofta bra att vänta tills användarenmatat in två-tre tecken eller har slutat skriva innan förslagen på sökordpresenteras. Eftersom varje enskilt tecken kan förekomma i mängder avolika sökord riskerar man annars att långa listor med irrelevanta förslag

Vägledning förWebbutveckling Sida 222 /

316

Page 224: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

behöver överföras och presenteras i samband med att sökningen påbörjas. Iundantagsfall kan dock redan det första tecknet användas som grund förförslag på sökord, framför allt om underliggande data inte är så omfattande.

Underlätta för besökare som använder förstoring ochskärmläsareFör användare som använder kraftig förstoring (eller en mycket liten skärm)kan rutan med sökordsförslag befinna sig utanför synligt område. Omordförslagen dyker upp medan användaren skriver finns därför en risk attanvändaren inte alls märker det.

Med hjälp av skärmläsare kan dessa användare bli informerade om dendynamiska förändringen – men bara om sidan innehåller kod som tydligtbeskriver sökfunktionens egenskaper för skärmläsaren. Detta kan görasmed hjälp av tillgänglighetsstandarden WAI-ARIA. Se Se till att hjälpmedelkan presentera meddelanden som inte är i fokus (R164).

För en person som använder skärmläsare kan det dock bli tjatigt att helatiden bli meddelad vid varje tangenttryckning att sökordsförslagen haruppdaterats. Här kan funktionen programmeras med en viss fördröjning såatt sökresultaten först uppdateras när användaren inte tryckt ner en tangentpå en halv sekund.

Se till att det går att navigera med tangentbordetSe till att det går att använda sig av tangentbordet för att navigera, välja ioch stänga listor med ordförslag. Det vanligaste är att användarna förväntarsig att kunna använda piltangenterna, tab, escape och enter/retur för attinteragera med listan. Om användaren väljer att stänga eller gå till ett avförslagen i listan ska tangentbordsfokus hamna i textfältet igen så att henkan navigera sig vidare till nästa del av sidan.

För återkommande användares skull bör det finnas möjlighet att inaktiverafunktionen som ger förslag på sökord. Funktionen kan nämligen upplevassom ett hinder för dessa användare. Den som navigerar med tangentbordkan t.ex. bli stressad av alltför många tangenttryckningar fram till självasökresultatet.

Andra webbriktlinjer som är särskilt viktiga vid dynamiskaordförslagAnvänd landmärken/roller i HTML-koden så att användare kan hoppa direkttill sökresultatet. Läs mer i R75 Gör det möjligt att hoppa förbi delar påsidorna.

Tänk på att inte sänka tillgängligheten för vissa grupper när du höjeranvändbarheten för andra. Följ gärna designprincipen om progressivförbättring för att undvika detta. Läs vidare i R93 Använd JavaScript för attöka tillgängligheten – inte tvärtom.

För att underlätta för personer som använder skärmläsare ska allaformulärfält ha en fältetikett. I undantagsfall kan attributet aria-label

Vägledning förWebbutveckling Sida 223 /

316

Page 225: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

användas på inmatningsfältet istället men ett label-element är att föredra dådet har bättre stöd. Läs mer om etiketter i R55 Skapa tydliga och klickbarafältetiketter.

MätningKontrollera att det går att navigera med tangentbordet även i menynsom presenterar förslag på sökord.Kontrollera att de förslagen på sökord som ni presenterar föranvändarna ger relevanta sökträffar. Se artikeln Följ upp hurwebbplatsen används.

Tips på verktyg

Google Accessibility Developer Tools kan ge förslag på om wai-aria ärfelaktigt (men kan inte verifiera att upplevelsen för användaren blir somtänkt).

Fördjupning och relaterade riktlinjerW3Cs rekommendationer för wai-aria vid sökordsförslagExempel på autocomplete med wai-ariaFyll formulär med kända uppgifter (R52)Designmönster för dynamiska ordförslagOm behovet: Stöd för rättstavning i sök- och inmatningsfält efterlystesav många användare i PTS kartläggning av IKT-behov hos personermed funktionsnedsättning, och betydelsen för dyslektiker har studeratsav forskare.

Terminologi

Dynamiska ordförslag i inmatningsfält kallas ofta ”autocomplete” eller ”typeahead” på engelska. Även uttrycket ”tab completion” förekommer, omanvändaren kan välja ett sökordsförslag genom att trycka på tab-tangenten.

Fältetikett – HTML label-element som förklarar vilken information som ska

anges i till exempel ett inmatningsfält.

Platshållartext kallas på engelska och i html-kod för ”placeholder text”.Ibland placeras motsvarande vägledning i så kallade tooltips, det vill sägahjälptexter som visas när användaren fokuserar på ett element.

Landmärke heter ”landmark” i kod och på engelska.

För att styra format på indata används, förutom exempeltexter, ävenindatakontroll (validering) som till exempel kan kontrollera att indata matcharindatamask/verifieringsuttryck/reguljärt uttryck (regular expression). Iblandgörs även dynamiska uppslagningar som en del av valideringen för attkontrollera att indata motsvarar verkliga förhållanden.

Vägledning förWebbutveckling Sida 224 /

316

Page 226: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Ett viktigt syfte med sökordsförslag är att de kan underlätta rättstavninggenom att erbjuda stavningshjälp. Detta är värdefullt för alla, men kanskesärskilt för personer med dyslexi eller andra läs- och skrivsvårigheter.

WAI ARIA – Web Accessibility Initiative – Accessible Rich InternetApplications. Se sidan med en introduktion till ARIA.

Senast uppdaterad: 2018-08-23

Prio 2

Använd webbvideo för att ökatillgänglighetenAnvänd gärna video som komplement eller alternativ till andrapresentationsformat. Texta och syntolka filmerna så kan fler ta del avinnehållet.

Om denna riktlinjePrioritet: 2Principer: Användbar, TillgängligRoller/arbetsuppgifter: Användbarhet och användarcentrerat arbetssätt,Inköpare och beställare, Standarder för webbplatser, TillgänglighetNär i utvecklingsprocessen?: Förvaltning, Innehållsproduktion,Interaktionsdesign, Målgruppsanalys, Prototypning, Testning

Rekommendationer för tillgänglig videoAnvänd gärna video.Använd undertexter.Erbjud syntolkning eller se till att viktig information framgår av ordinarieljud.Erbjud översättningar (till exempel till svenskt teckenspråk) vid behov.Använd videospelare med bra tillgänglighet.Begränsa blinkande för att inte orsaka krampanfall.Ställ krav på tillgänglighet när ni upphandlar videoproduktion.Planera produktionen med hänsyn till tillgänglighet.

Använd gärna videoMånga gånger kan det vara lättare att ta till sig innehåll i en video än ommotsvarande information skulle finnas i en längre text. Använd gärna videosom komplement till textbaserad information för att nå personer som harsvårt att läsa eller inte kan läsa men som förstår talspråk med stöd avvisuell information.

Den här riktlinjen handlar om hur video kan göras tillgänglig för så mångamänniskor som möjligt, oberoende av t.ex. funktionsnedsättning. Det är en

Riktlinje nr 113

Vägledning förWebbutveckling Sida 225 /

316

Page 227: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

av flera riktlinjer om video och annan rörlig media på webben.

Använd undertexterDigital video ska i princip alltid ha undertexter.

Se R117. Texta inspelad rörlig media (video, ljud, animationer…) och R119.Texta direktsändningar

Erbjud syntolkning eller se till att viktig information framgårav ordinarie ljudOrdna med syntolkning om det behövs för att personer med begränsad synska kunna ta del av videoinnehåll.

Se R120. Syntolka videoinspelningar.

Erbjud översättningar (till andra språk) vid behovVideomaterial kan textas på fler än ett språk, och det går även att lägga inalternativa ljudspår (kallas ibland dubbning) eller fälla in en teckenspråkstolki bild.

Organisationens uppdrag och målgruppernas behov bör avgöra vilkaöversättningar ni erbjuder. Läs mer om minoritetsspråk och översättningar iR13. Ge information på svenskt teckenspråk, R14. Ge information på denationella minoritetsspråken och R15. Ge information på engelska ochandra språk.

Symbol för information på teckenspråk. För licensinfo, se avsnittetåteranvändning av symboler.

På Malmö stads videoportal finns exempel på en video där användaren kanvälja att slå på och av både teckenspråkstolkning och textning. Filmen finnsöversatt till en rad olika språk som användaren kan välja att visa. Annatexempel på infälld teckenspråkstolk på bild kan ses på TV4-tolken.

Använd videospelare med bra tillgänglighetI takt med att webbläsare får bättre stöd för html5 kommer förhoppningsvisen tillgänglig videospelarfunktion automatiskt användas för presentation avinnehåll som infogas med hjälp av html-elementet video. Men än så längebrister tyvärr tillgängligheten i många webbläsares implementation av html5-video. Det kan handla om att användaren inte kan navigera i spelaren medhjälp av tangentbord eller använda den med skärmläsare, eller att textspårinte kan visas. Därför kan man behöva använda tilläggskod (oftastbestående av JavaScript och css, och möjligen komplettera med länk tillnedladdningsbar fil på standardformat). Det finns många olika videospelareatt välja bland.

Vägledning förWebbutveckling Sida 226 /

316

Page 228: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Använd om möjligt relativa mått (till exempel i procent) för att angevideospelarens bredd. Publikationen CSS-tricks beskriver hur detta kanåstadkommas med några vanliga videotjänster. Om bredden anges medfasta pixlar riskerar webbplatsens responsivitet att brytas.

Många organisationer abonnerar på videoplattformar från externaleverantörer. I dessa fall gäller det förstås att ställa motsvarande krav påtillgänglighet vid upphandling.

Ibland fungerar det bra att bädda in (på engelska: embed) video från någongratis distributionsplattform, men tillgängligheten i sådana spelare varieraroch ofta innebär det att användarens intresse kartläggs av tredje part medhjälp av kakor med mera. Läs mer om tredjepartsinnehåll i R67 Se till attinfogade externa tjänster följer webbriktlinjerna.

Många olika exempel på tillgängligt videoinnehåll och hur det kanpresenteras (och kodas) finns på demonstrationssidor från Ableplayer.

Begränsa blinkande för att inte orsaka krampanfallSe R133. Orsaka inte epileptiska anfall genom blinkande.

Ställ krav på tillgänglighet när ni upphandlar videoproduktionDet är viktigt att ställa krav på tillgänglighet vid upphandlingar, eftersommånga vägval avgörs just i detta skede. Förändringar i upphandlingslagarnagör att det från 2017 dessutom är lagkrav på detta. Många produktionsbolagär fortfarande ovana vid krav på tillgänglighet vid videoproduktioner, mentydlig efterfrågan på t.ex. textning och syntolkning bör leda till ökad kunskapoch lägre priser.

Använd alla relevanta webbriktlinjer, inte bara denna, när du ställer krav vidupphandling för webbvideo. Särskilt R1. Följ WCAG 2.1 nivå AA som juäven har konsekvenser för till exempel kontraster i textplattor som kanförekomma som en del av filmerna.

Samma sak gäller förstås vid upphandling av videoplattform.

Planera produktionen med hänsyn till tillgänglighetOm ni tar hänsyn till tillgänglighet redan på planeringsstadiet kan resultatetmed ganska små åtgärder bli betydligt mer inkluderande.

Tips för att ta fram ett bra manus:

Låt personerna i filmen presentera sig. Då kan en person somanvänder hörseln för att uppfatta videon koppla rösten till namnet ochhar på så vis lättare för att skilja på personerna i videon.Byt inte kläder på personer i filmen i onödan. Genom att till exempellåta en person behålla samma tröja genom hela filmen blir det enklareför flera kategorier av tittare att hålla reda på vem som är vem.Presentera händelser med hjälp av en berättarröst och lägg in saker ihandlingen som gör att man kan förstå filmen utan att behöva se

Vägledning förWebbutveckling Sida 227 /

316

Page 229: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bilderna.Tänk igenom de olika ljudmiljöerna och fundera över vilka ljud sombehöver förstärkas och vilka som kanske ska tas bort. Tänk på att intedränka viktiga miljöljud med musik. Miljöljuden ska helst höra ihopmed bilderna och föra berättelsen framåt.Använd kontrast och färg konsekvent.

Fördjupning om webbvideoAndra aspekter än tillgänglighet som också berör video på webben (tillexempel bevarande och prestanda) kan du hitta genom att söka påwebbriktlinjer som innehåller ordet video.Digital video är ett bra verktyg för att skapa tillgängliga onlinemöten.Malmö stad har publicerat en rapport om rörlig bild i kommunalverksamhet (pdf, 2,2 MB).Delar av denna riktlinje är en bearbetning av Åsa Holmbergssammanfattning av ett möte om webbvideo med MITT-nätverket.Myndigheten för tillgängliga medier (MTM) har publicerat en rapportsom belyser syntolkning ur många perspektiv.Det finns både professionell utrustning (inklusive speciella tangentbordför direkttextning) och gratisverktyg för textning av video.

Exempel på kod för tillgänglig webbvideo

Exakt hur din video bör infogas i en webbsida beror på vilka komponenterden består av, vilken html-version du använder (se rekommendationer föratt välja standard, R81), vilken videospelare du använder, hur javascriptanvänds med mera.

Här kommer ett exempel som visar hur det kan se ut i html5 för att infoga enfilm med stängda undertexter på svenska och engelska (där den svenska äruppdelad på två filer – en som innehåller den talade dialogen och en sombeskriver andra viktiga ljud). Dessutom finns länkar för den som inte kanspela upp innehåll i webbsidan men önskar ladda ner det. Audio-elementetmed syntolkning som ligger sist behöver kopplas till videofilmen med hjälpav javascript (som inte finns med här).

<video width="1100" height="800" poster="statisk_bild.jpg"

controls="controls" preload="none" title="Beskrivning av film">

<source type="video/mp4" src="videofil.mp4" />

<track src="dialogundertext.vtt" kind="captions"

srclang="sv" default label="Svenska" />

<track src="engelska.vtt" kind="subtitles" srclang="en"

label="English" />

<track src="textbeskrivningar.vtt" kind="transcript" srclang="sv"

Vägledning förWebbutveckling Sida 228 /

316

Page 230: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

label="Beskrivningar" />

Din webbläsare verkar inte kunna visa upp filmen.

<a href="videofil.mp4">Ladda ner filmen</a>

</video>

<audio preload="none" controls="controls" title="Ljudinspelning med

syntolkning av filmen">

<source src="syntolkning.mp3" type="audio/mp3"/>

Din webbläsare verkar inte kunna spela upp syntolkningen.

<a href="syntolkning.mp4">Ladda ner syntolkningen</a>

</audio>

<a href=”tecken.html”>Version med tolkning till svenskt

teckenspråk</a>

För den som använder äldre html-versioner kan tillgängliga mediealternativsynkroniseras med hjälp av smil-standarden.

MätbarhetGör en expertgranskning eller användningstester för att säkerställa attriktlinjen uppfylls.

Kontrollera även att det går att använda tangentbordet för att

tabba sig fram till videospelarenkontrollera uppspelningen med tangentbordet (och att det är tydligt hurman gör) ochta sig från videospelaren till det övriga innehållet med hjälp avtangentbordet.

Du kan också blunda och lyssna på filmen. Går viktig information förlorad?

Riktlinjen om flimmer går att testa med automatiska verktyg, men oftasträcker en manuell bedömning.

Återanvändning av symboler

Om samma symboler används av många kan det underlätta förståelse.Överväg därför gärna att använda någon av de ikoner vi presenterat här,snarare än att hitta på en egen. Men kom ihåg att symboler, även om de ärstandardiserade, alltid bör kombineras med motsvarande information somtext. Och glöm inte bort att det kan finnas upphovsrättsligt skydd försymbolerna.

symboler för textning

Symbolen för textning som innehåller bokstäverna ”cc” är licensbefriad, den

Vägledning förWebbutveckling Sida 229 /

316

Page 231: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

med ”T” tillhör SVT och får användas fritt. Subtitles-symbolen kommer frånGoogle som publicerat den under Apache License Version 2.0, vilket i storadrag innebär att den är fri men inte får säljas vidare.

Symbolen för syntolkning som består av ett öga med tre bågar tillhör SVToch får användas fritt. Symbolen som innehåller förkortningen AD ärlicensbefriad. Ibland används bara förkortningen, som står för den engelskatermen för syntolkning, alltså audio description.

Symbolen för teckenspråkig information finns att ladda ner fritt i flera olikaformat hos SDR och är standardiserad av SIS.

TerminologiVi använder här uttrycken “video”, “film”, “onlinevideo” och “webbvideo”omväxlande för all form av digital rörlig bild med ljud. I WCAG används detnågot vidare begreppet “tidsberoende media” (eng “time-based media”) somäven innefattar ljudinspelningar utan bild, filminspelningar utan ljud, ochannan “rörlig” media med eller utan interaktivitet. Till exempel spel ochanimationer. Kännetecknande för tidsberoende media är att de behöveråterges i en lämplig takt, därav kopplingen till tid.

För textremsa används på webben ofta formatet WebVTT (web video texttracks), men det finns även andra filformat för lagring och överföring avtextning till video.

OVP är en förkortning av online video platform, det vill säga videoplattform.

Senast uppdaterad: 2018-01-29

Prio 1

Grundläggande rekommendationerför apparKomplettera gärna med en app när webben inte räcker till för att täckamålgruppens behov. Det kan till exempel handla om att viss ny funktionalitetsom fungerar i en app inte går att erbjuda med en responsiv webbplats. Setill att appen följer riktlinjer för tillgänglighet. De flesta riktlinjer som gäller förwebben är även tillämpbara på appar.

Riktlinje nr 114

Vägledning förWebbutveckling Sida 230 /

316

Page 232: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: Användbar, Effektiv, Förtroendeingivande, Tekniskt oberoende,Tillgänglig, Åtkomlig över tidRoller/arbetsuppgifter: Inköpare och beställare, TillgänglighetNär i utvecklingsprocessen?:

Rekommendationer för apparKomplettera med appar när webben inte räcker tillFölj de webbriktlinjer som är tillämpbara även i apparFölj respektive plattforms egna riktlinjer för tillgänglighet

Komplettera med appar när webben inte räcker tillEftersom alla inte har tillgång till appar bör offentliga aktörer användawebben i första hand för grundläggande samhällsinformation och service.När inte webbens funktionalitet räcker till är appar ett bra komplement.

Ni bör ta ställning till de olika för- och nackdelar som finns innan ni utvecklaren app. Här är några exempel, inspirerade av Örebro kommuns vägledningför val mellan app och webb (pdf, 25kB):

Fördelar med apparApp-plattformarna erbjuder ofta nya funktioner flera år innanmotsvarande funktionalitet finns på webben. Några exempel på funktioner som kommit tidigare för appar är platsberoende tjänster(GPS) och notifieringar.Appar fungerar ibland smidigare än webbplatser när uppkoppling tillinternet saknas.En installerad app startar ofta snabbare än en webbplats eftersomdess komponenter redan finns i användarens utrustning och intebehöver hämtas över internet.Inloggning behövs inte lika ofta som på webben, eftersomanvändarens identitet och inställningar lagras av appen i användarensutrustning.En app har oftast bättre tillgång till mobilens övriga resurser, tillexempel bilder, adresskatalog och kalender.Närvaro i app-plattformarnas kataloger (t.ex. AppStore, Google Play)kan erbjuda bra möjligheter för marknadsföring och synlighet.Eftersom människor har olika behov och preferenser är det möjligt attnå totalt sett fler om både app och webb erbjuds.

Nackdelar med appar i jämförelse med webbplatserAnvändaren måste godkänna villkor som dikteras av app-plattformensägare.Innehållet i en app är inte automatiskt länkbart på samma sätt som enwebbsida.Innehållet i en app blir inte automatiskt sökbart i sökmotorer.Det är ofta mer kostnads- och resurskrävande att underhålla en app.

Vägledning förWebbutveckling Sida 231 /

316

Page 233: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Tjänsten behöver anpassas för flera plattformar (I dagslägetframförallt iOS, Android, Windows mobile), och sannolikt ävenwebben. Det finns plattformar för apputveckling som underlättardetta, men de tillför ett lager av komplexitet och ev. kostnad.Att uppdatera innehållet i en app är ofta mer komplicerat ochtidskrävande än på en webbsida. Särskilt om en ny app-versionbehöver distribueras.

Vissa plattformsägare granskar alla appar innan de publiceras iplattformens katalog och det finns alltså en risk att appen, av skäl somni inte styr över, inte kan distribueras till användarna.Appen kräver marknadsföring för att målgrupperna ska hitta och laddaner den.Det kan vara svårt att skriva ut innehåll från en app.Det krävs ett större mått av tillit från användaren för att installera enapp än för att besöka en webbsida, eftersom appen får mer tillgång tillmobilens resurser.För tjänster som används sällan tycker många inte det är värt besväretatt installera en app.

Ta reda på om behoven går att lösa med webbteknikI många fall går det att utforma en webbplats på ett sätt som gör att den avanvändaren uppfattas som en app. Gör det genom att

Anpassa webbplatsen även för små skärmar (webbriktlinje R111).Ange i html-koden hur sajten kan presenteras som app, t.ex. föranvändare som skapar en genväg till webbplatsen från hemskärmen: Ange sökväg till ikon, förvald skärmorientering landskap/porträtt osv.W3C arbetar med ett utkast till specifikation för hur webbapplikationerkan beskrivas i ett manifest. I väntan på att den specifikationen ärstandardiserad finns instruktioner för webbapplikationer i Safari/iOSoch instruktioner för webbapplikationer i Chrome/Android.Använd funktioner i HTML5 för att möjliggöra användning även närinternetuppkoppling saknas, och synkronisering när uppkopplingenåterkommer. Indikera tydligt för användaren om uppkoppling finns ellerej. Om användaren t.ex. försöker läsa nyheter och de inte kan laddasin på grund av att användaren är offline måste orsaken vara tydlig.

Observera att äldre webbläsare inte har stöd för alla ovanståendefunktioner.

Följ de webbriktlinjer som är tillämpbara även iapparNär det gäller tillgänglighet bör samma krav ställas på appar som påwebbplatser och e-tjänster. EUs-direktiv om webbtillgänglighet kommeräven att gälla för appar.

Både webbriktlinjerna och dess viktigaste beståndsdel WCAG 2.1 (R1 FöljWCAG 2.1 nivå AA) är i och för sig framtagna med webben i fokus, och

Vägledning förWebbutveckling Sida 232 /

316

Page 234: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

WCAG 2.0 skrevs innan smarta telefoner och pekskärmar blev populära.WCAG 2.1 är något bättre när det gäller mobil tillgänglighet än version 2.0,men tar inte upp alla aspekter. Arbete pågår som syftar till att ta fram flerspecifikationer som är skräddarsydda för appar. Sådana bör följas när defår standardstatus, så bevaka gärna utvecklingen. Tills dess kan och bör debefintliga riktlinjerna tillämpas på appar. Nästan alla riktlinjer går faktiskt atttillämpa på appar, under förutsättning att formuleringar som till exempelwebbsida läses med en vidare förståelse.

W3C (World Wide Web Consortium) som står bakom WCAG har ävenkonstaterat att vissa frågor blir extra viktiga för mobila enheter på grund avatt skärmarna oftast är mindre än en datorskärm och att enheterna användsi väldigt olika miljöer. Här är en sammanfattning av W3Cs genomgång avtillgänglighetsaspekter som är viktiga i mobila tillämpningar:

Det ska vara möjlighet att zooma innehållet då skärmens storlek oftaär liten.Se till att det är tillräcklig kontrast eftersom enheterna används i olikamiljöer med olika starkt ljus, till exempel i solljus.Mobila enheter har vanligtvis inte tangentbord även om de kananslutas till tangentbord. Det är ändå en god idé att bygga appen såatt den kan navigeras med tangentbord eftersom detta ger en godgrund för tillgänglighet och säkerställer att kontroller i appen inte ärknutna till endast klickhändelser.Var noga med storleken på klickbara ytor och avstånd, eftersomanvändare med små pekskärmar kan ha begränsad precision.Direktoratet for forvaltning og IKT (Difi) i Norge rekommenderar att låtaen klickbar yta uppta cirka en tredjedel av skärmytan på bredden ochen fingertopps storlek på höjden.Användbarheten i appar kan förbättras med rörelsekommandon påpekskärm (t.ex. kan ”att svajpa” vara ett smidigt sätt att bläddra, väljaeller radera). Tänk dock på att inte alla användare känner till dessa.Informera användare om sådana funktioner om de avviker från vadanvändaren kan förmodas vänta sig, eller om de är helt nödvändigaför att kunna använda tjänsten.Placera viktigt innehåll längst upp för att undvika att användarenbehöver scrolla långt ner.Ge användare hjälp att fylla i formulär genom att presentera rätt typ avtangentbord. Undvik krångliga formulär med för många fält.

Följ respektive plattforms egna riktlinjer förtillgänglighetDet finns omfattande dokumentation om hur man ska utveckla för högtillgänglighet för de olika plattformarna. I stor utsträckning innehåller dessasamma rekommendationer som WCAG. Men det finns äventillgänglighetsfunktioner som är specifika för respektive plattform. Det kan tillexempel handla om stöd för nya typer av hjälpmedel, som inte fanns närWCAG 2.0 togs fram, eller plattformsspecifika fysiska knappar. För att varasäker på att dessa funktioner kommer dina användare till del behöver du

Vägledning förWebbutveckling Sida 233 /

316

Page 235: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

som utgivare av en app se till att följa inte bara de generella riktlinjerna förtillgänglighet utan även plattformens egna. Här hänvisar vi till dokumentationför några av de plattformar som dominerar för närvarande:

AndroidAndroid Developers Accessibility har information om hur tillgängliga apparutvecklas, checklistor för utveckling och testning: Android DevelopersAccessibility

iOSFör iOS finns information om transkribering av video och ljud, anpassning avdet visuella gränssnittet, skärmläsare, uppläsning, dokumentation, guideroch exempelkod: Accessibility on iOS

Universal Windows Platform (UWP)Microsoft har information om hur inkluderande appar utvecklas, hur man gårtillväga för att testa tillgänglighet och checklistor för tillgänglighet: MicrosoftDeveloper Network Accessibility overview

ExempelVia Appsök kan du hitta appar som granskats ur tillgänglighetsperspektiv avStockholms läns landsting.

Dela kod och utveckling med andraPå DelaDigitalt.se kan personer som arbetar för offentlig sektor och harsnarlika behov hitta varandra. Kanske finns någon annan som redan harutvecklat den kod du behöver, eller som just tänkt börja utveckla ellerupphandla, eller som har en relevant förstudie att dela med sig av? Börjamed att kika där. Och om ni publicerar era behov på deladigitalt så kanskenågon snart hör av sig som kan dela på kostnaderna.

Du som redan har konto kan använda direktlänk till en sökning på ”app” ideladigitalt.se.

Fördjupning om apparW3C WAI Mobile AccessibilityWCAG 2.0 Techniques that Apply to MobileW3Cs tips för utformning av mobila webbapplikationer (ej specifikt omtillgänglighet)Vägledning om kognitiv tillgänglighet i mobila tillämpningar, frånstandardiseringsorganisationen ETSI

TerminologiDen här riktlinjen handlar om mobilapplikationer, som i dagligt tal kallas förappar. Uttrycket “mobil” innefattar en rad olika typer av enheter, till exempelsmarta telefoner (smartphones), läsplattor (tablets) och ”wearable devices”som smartglasögon och smartklockor. Ordet app kommer från den engelska

Vägledning förWebbutveckling Sida 234 /

316

Page 236: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

termen applikation (tillämpningsprogram) som avser program sominstalleras och körs av ett operativsystem på enheten.

Oftast avses mobila appar då ordet app används, men på senare tidanvänds ordet app även för program som används på en dator, och detfinns app-plattformar för bilar och spelkonsoller m.m. Distributionen av apparsker ofta genom plattformens app-katalog på nätet, till skillnad fråntraditionella applikationer som ofta distribueras genom nedladdning avinstallationsfiler eller fysiska lagringsmedier.

Appar som är specialutvecklade för en mobil plattform (t.ex. för iOS ellerAndroid) kallas för native apps. Webbappar är webbsidor som besöks meden webbläsare men som upplevs som en app. Det finns också hybridapparsom består delvis av plattormsspecifik funktionalitet, delvis av webbinnehåll.

Rörelsekommandon på pekskärm kallas pekskärmsgester (på engelskatouchscreen gestures). Till exempel svajpa, som är ett nytt svenskt ordmotsvarande det engelska swipe.

När det gäller funktionerna i HTML5 för offline-funktionalitet är bl.a. såkallade Service Workers relevanta, men även Application Cache(AppCache). Denna riktlinje erbjuder inte idag några närmare tekniskabeskrivningar eller rekommendationer om hur sådana lösningar börutformas.

Djuplänkning (se t.ex. Wikipedias artikel mobile deep linking) till innehåll iappar är möjligt, men kräver att utvecklaren förbereder för detta.

Senast uppdaterad: 2018-06-20

Prio 1

Beskriv med text allt innehåll som inteär textAnvändare som är beroende av till exempel skärmläsare och punktdisplaybehöver beskrivningar av allt innehåll som inte är text. Det gäller tillexempel:

Bilder (förutom sådana som endast används för dekoration)DiagramAnimationerLjudsignaler

Se därför till att allt sådant innehåll beskrivs med hjälp av text, förutom i deundantagsfall som beskrivs i WCAG-kriteriet. Undantagen gäller framföralltsådana situationer där en beskrivande text skulle motverka innehållets syfte(till exempel när syftet med ett ljud är att testa användarens hörsel).

Riktlinje nr 115

Vägledning förWebbutveckling Sida 235 /

316

Page 237: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Testning

Använd text som är synlig för alla om det passar, eller html-attribut som till

exempel alt och aria-label för kortfattade beskrivningar. När en

textbeskrivning ligger separat kan du knyta id-attributet för det element

som innehåller beskrivningen till det som beskrivs till exempel med hjälp avaria-labelledby eller aria-describedby. En fördel med separat

textbeskrivning är att den – till skillnad från alt-attribut – kan formateras

och innehålla länkar.

Rekommendationer för textalternativVälj detaljnivå efter användarens behovUndvik upprepningar genom att provlyssna

Välj detaljnivå efter användarens behovBeskriv innehållet tillräckligt detaljerat för den som enbart uppfattartextbeskrivningen. Det är ofta bättre att sakligt och kortfattat beskrivainnehållet än att ta upp varje detalj eller att ge subjektiva omdömen. Mendet finns undantag. Ibland är det viktigt att beskriva känslan i en bild för attanvändaren ska få en förståelse för innehållet. Utgå från användarensbehov och innehållets syfte.

Ofta finns det möjlighet att kombinera en kort textbeskrivning genom att tillexempel använda alt-attribut på en bild med en mer utförlig separat text förden som vill fördjupa sig. Använd då till exempel attributet aria-describedbyför att relatera innehållet till en separat text.

Andra riktlinjer (R117 Texta inspelad rörlig media (video, ljud,animationer…) och R119. Texta direktsändningar) tar upp frågor omfullständig textversion av “tidsberoende media” det vill säga inspelningar ochdirektsändningar. Denna riktlinje innebär bara att det behöver finnas ensammanfattande text som beskriver sådant innehåll.

Undvik upprepningar genom att provlyssnaOm det finns en bildtext eller annan brödtext som beskriver bildens innehållbör inte den alternativa textbeskrivningen upprepa textens innehåll. Ett brasätt att bedöma hur bra alternativa textbeskrivningar fungerar är att lyssnapå webbplatsen med hjälp av en skärmläsare.

Därför är textpresentationer viktigaMed hjälp av digital teknik kan de flesta användare ta till sig en text. Den

Vägledning förWebbutveckling Sida 236 /

316

Page 238: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

som ser kan läsa texten, den som hör kan få den uppläst, den kanpresenteras som punktskrift för den som läser med hjälp av känseln. Textkan förstoras och presenteras med olika teckensnitt och färgskalor.Uppläsning kan ske med olika hastighet och röst. I många fall kan text tilloch med översättas automatiskt innan den presenteras för användaren.

Utdrag från WCAG-standarden

Riktlinje 1.1 Textalternativ: Tillhandahåll alternativ i form av texttill allt icke-textbaserat innehåll så att det kan konverteras tillformat som användarna behöver, till exempel stor stil,punktskrift, tal, symboler eller enklare språk.

1.1.1 Innehåll som inte är text: Allt innehåll som inte är text, sompresenteras för användaren har ett textalternativ med sammasyfte, utom i de situationer som anges nedan. (Nivå A)

Navigeringsmetod/funktion, inmatning: Om innehåll sominte är text är en navigeringsmetod/funktion elleraccepterar inmatning från användare så ska den ha ettnamn som beskriver dess syfte. (Se Riktlinje 4.1 förytterligare krav på navigeringsmetod/funktion och innehållsom accepterar inmatning från användare).Tidsberoende media: Om innehåll som inte är text ärtidsberoende media så ger ett textalternativ åtminstone enbeskrivning av det innehåll som inte är text. (Se Riktlinje1.2 för ytterligare krav på media).Test: Om innehåll som inte är text är ett test eller en övningsom inte skulle fungera om det visades som text, så ger etttextalternativ åtminstone en beskrivning av det innehållsom inte är text.Sensorisk: Om innehåll som inte är text främst är avsett föratt ge en specifik sensorisk upplevelse så ger etttextalternativ åtminstone en beskrivning av det innehållsom inte är text.CAPTCHA: Om syftet med innehållet som inte är text är attbekräfta att en människa, snarare än en dator, försökerkomma åt informationen så ska textalternativ somidentifierar och beskriver syftet av innehållettillhandahållas. Alternativa former av CAPTCHA, somanvänder sig av utmatningsmetoder för olika typer avsensorisk upplevelse, tillhandahålls för att tillgodose olikafunktionsnedsättningar.Dekoration, formatering, osynlig: Om innehåll som inte ärtext är rent dekorativt, bara används för visuell formateringeller inte presenteras för användare, så implementeras detpå ett sätt så att det kan ignoreras av hjälpmedel.

Terminologi

Vägledning förWebbutveckling Sida 237 /

316

Page 239: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Formuleringarna alt-text, alt-texter, alt-attribut är vanliga när det gäller

textbeskrivning av bilder på webben. Ibland förekommer attributetlongdesc, som kan användas för att hänvisa till beskrivningar på annan

plats i dokumentet, eller på någon annan sida. Stödet i webbläsare förlongdesc är dock begränsat, och idag är det nog bättre att använda

aria-describedby.

CAPTCHA är en förkortning av ”Completely Automated Public Turing test totell Computers and Humans Apart” vilket innebär att det är ett sätt att avgöraom användaren är en människa eller ett datorprogram (ibland kallad ”bot” idetta sammanhang). Framförallt används CAPTCHAs för att förhindraskräppost och annat missbruk av digitala tjänster, som ofta sker med hjälpav program. Tyvärr finns risk för att även användare som faktiskt ärmänniskor har problem att ta sig förbi testet, eftersom det kan ställa myckethöga krav på syn, kognition eller hörsel. Erbjud sätt att komma förbiCAPTCHA som fungerar oavsett eventuell funktionsnedsättning. Ett inlägg(på engelska) på designbloggen Telepathy beskriver några alternativ tillCAPTCHA.

Senast uppdaterad: 2018-11-30

Prio 1

Erbjud alternativ om en inspelningenbart består av ljud eller videoAnvändare som inte kan ta del av ljud- eller videoinspelningar ska ha enmöjlighet att tillgodogöra sig innehållet med hjälp av en alternativrepresentation.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Användare som inte kan ta del av ljud- eller videoinspelningar ska ha enmöjlighet att tillgodogöra sig innehållet med hjälp av en alternativrepresentation. Det kan till exempel vara ett manus (en text) som redigeratsså att det motsvarar inspelningens verkliga innehåll (det är ju ganska vanligtatt manus frångås). För ljudinspelningar (till exempel ett poddavsnitt) är entranskribering av innehållet en vanlig metod. För videoinspelningar utan ljudkan en ljudinspelning vara en godtagbar alternativ presentation.

Observera att när inspelningen i sig är en alternativ presentation (tillexempel en teckenspråkstolkning) av en text så finns ju redan textversionen.

Riktlinje nr 116

Vägledning förWebbutveckling Sida 238 /

316

Page 240: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Obs! Inspelningar som innehåller både ljud och bild behandlas i riktlinje 117Texta inspelad rörlig media (video, ljud, animationer …).

Rekommendationer för ljudinspelningar och videoutan ljud

Erbjud ett textbaserat manus eller någon annan presentation som inteutestänger användare som saknar förutsättningar att uppfattainspelningen.

Se till att de olika alternativa presentationernahänvisar till varandraAnvändare som hittar den ena presentationen till exempel via en sökmotorbehöver informeras om att den andra versionen existerar. Alternativapresentationsformat kan ha stor betydelse för sökbarhet, men bara om detframgår att de är just alternativa presentationer.

Använd gärna aria-describedby för att i koden koppla samman de

olika versionerna.

Utdrag från WCAG-standarden

Riktlinje 1.2 Tidsberoende media: Tillhandahåll alternativ tilltidsberoende media.

1.2.1 Enbart ljud och enbart video (Förinspelad): För förinspelatljud (enbart) och förinspelad video (enbart) gäller följande, utomnär ljudet eller videon är ett mediealternativ till text och tydligtmärkt som sådant: (Nivå A)

Förinspelat ljud (enbart): Det finns ett alternativ tilltidsberoende media som presenterar informationmotsvarande det förinspelade ljudinnehållet.Förinspelad video (enbart): Det finns antingen ett alternativtill tidsberoende media eller ett ljudspår som presenterarinformation motsvarande det förinspelade videoinnehållet.

Senast uppdaterad: 2018-12-05

Prio 1

Texta inspelad rörlig media (video,ljud, animationer…)Inspelad digital video ska ha undertexter (kallas även textbeskrivningar ellertextremsa) och för ljudinspelningar (till exempel podcasts) med mera bör entextversion erbjudas.

Riktlinje nr 117

Vägledning förWebbutveckling Sida 239 /

316

Page 241: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer:Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Personer som av olika skäl inte tydligt kan uppfatta eller förstå ljud kan imånga fall tillgodogöra sig innehållet om det finns i textformat. Detta berörmånga människor, och kan bero på till exempel hörselnedsättning ellerstörande ljud. Många tittar på videoinnehåll med ljudet avslaget, till exempelför att de inte vill störa personer i omgivningen eller saknar fungerandehögtalare/hörlurar. En del personer med svenska som andraspråk harockså nytta av undertexter, liksom den som vill orientera sig i en inspelninggenom att snabbspola med bild.

Webbdirektivets krav på inspelad video gäller material som publiceras frånoch med 23 september 2020.

Se även R113 Använd webbvideo för att öka tillgängligheten, R116 Erbjudalternativ om en inspelning enbart består av ljud eller video och R119 Textadirektsändningar om det finns möjlighet.

Rekommendationer för textningErbjud stängda undertexter för digital videoInformera användaren om att det finns textBeskriv alla ljud av betydelseErbjud gärna en separat textversion

Erbjud stängda undertexter för digital video

Öppna undertexter (open captions på engelska) syns för alla. Stängdaundertexter kan användaren själv bestämma om de ska visas eller inte. Ivissa fall kan de även läsas upp av skärmläsare. Stängda undertexter ärdärmed att föredra i digitala sammanhang. Ibland kan användaren ävenvälja översättning, teckensnitt, placering av textremsan med mera.

Informera användaren om att det finns text

Glöm inte bort att länka till transkriberingen (eller göra den nåbar på annatsätt) på de platser där videon förekommer, och att länka till videon fråntranskriberingen om den förekommer fristående, så att användaren själv kanvälja version.

Stängda undertexter heter closed captions på engelska, därför användsibland en ikon med ”cc”. I Sverige används ofta symbolen med ett enkelt T.

Vägledning förWebbutveckling Sida 240 /

316

Page 242: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Den tredje symbolen som avbildar textremsor i nederkanten av en bild stårför ”subtitles”. För licensinformation om bilderna se avsnittet återanvändningav symboler.

Beskriv alla ljud av betydelse

Undertexter bör, förutom dialogen, beskriva andra ljud av betydelse, tillexempel ”telefon som ringer”, ”någon hostar”. Texterna behöver i allmänhetinte vara ordagranna, det viktiga är att de förmedlar samma information.

Erbjud gärna en separat textversion

En transkribering (ett dokument som innehåller alla inspelningensundertexter, eller motsvarande) gör det möjligt för personer som använderskärmläsare eller punktskriftsläsare att ta till sig innehållet i sin egen takt.

En transkribering av filmen är också bra för sökmotoroptimeringen eftersomdet ger en möjlighet för sökmotorer och andra verktyg att tolka innehållet.

Texten bör innehålla beskrivningar av miljöer, förklaringar eller kommentarersom kan vara till nytta för att förstå sammanhanget. Det kan till exempelvara någon som skrattar på filmen eller vänder sig och går mot ett visst håll.

Om undertexter finns i separat fil (snarare än inkodat i filmensbildinformation) kan texterna automatiskt hämtas ut och presenteras somtranskribering. På sidan Möt användarna finns ett exempel på sådantextversion som genereras automatiskt från undertextfilen. Där sker det medmed hjälp av JavaScript.

Utdrag från WCAG-standarden

Riktlinje 1.2 Tidsberoende media: Tillhandahåll alternativ tilltidsberoende media.

1.2.2 Textbeskrivningar (Förinspelade): Det finnstextbeskrivningar till allt förinspelat ljudinnehåll i synkroniseradmedia, utom när mediet är ett mediealternativ till text och tydligtär märkt som sådant. (Nivå A)

Vägledning förWebbutveckling Sida 241 /

316

Page 243: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Fördjupning och tips om undertexterDet finns en serie korta (textade) filmade lektioner om undertextningoch några om undertextning med Amara från Moderskeppet.Verktyget Textamig.se kan användas för att automatiskt genereratextning till en inspelning på YouTube eller Vimeo, som sedan kanredigeras vidare för bättre kvalitet. Tjänsten är gratis men ”pre-alpha”,det vill säga den lämnar inga garantier. På sajten beskrivs ocksåuppropet #undertextamera som syftar till att inspirera fler att texta sinainspelningar.Två presentationer på träffen om tillgänglig webbvideo handlade omtextning. Det första utifrån bland annat hörselskadades perspektiv ochden andra utifrån ett produktionsperspektiv.BBC har omfattande riktlinjer för textning (på engelska).

Två föreläsningar om textad video på webbenHär följer en inspelning av två föreläsningar om textning av video påwebben. Mattias Lundekvam, ordförande för Hörselskadades riksförbund,tar upp textning ur ett användarperspektiv och Richard Gatarski som jobbarmed produktion av webbvideo tar upp det perspektivet.Det finns även en teckenspråkstolkad version och en separat syntolkadljudversion av inspelningen.

Download videoDownload captions

Textinnehåll

Terminologi

För textremsa används på webben ofta formatet WebVTT (Web Video TextTracks), men det finns även andra filformat för lagring och överföring avtextning till video.

Senast uppdaterad: 2019-02-18

Prio 1

Syntolka eller erbjud alternativ tillvideoinspelningarDen som inte kan ta del av det visuella innehållet i videoinspelningar, tillexempel på grund av synnedsättning, ska kunna få motsvarande informationantingen i form av syntolkning (ljudbeskrivning) eller presenterad som text.

Om denna riktlinjePrioritet: 1

Riktlinje nr 118

Vägledning förWebbutveckling Sida 242 /

316

Page 244: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Principer:Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

Den som inte kan ta del av det visuella innehållet i videoinspelningar, tillexempel på grund av synnedsättning, ska kunna få motsvarande informationantingen

i form av syntolkning (ljudbeskrivning) ellerpresenterad som text.

Att presentera ett visuellt innehåll som text innebär att ett manus ellerliknande erbjuds som alternativ till videoinspelningen. En fördel med dettaalternativ är att användaren kan tillgodogöra sig innehållet i sitt eget tempo.En annan fördel är att mängden information som hinner presenteras intebegränsas av det ordinarie ljudspåret. En utmaning med syntolkning är ju attdet kan vara svårt att hinna beskriva det visuella i de korta pauserna i endialog. Å andra sidan ger det inte samma upplevelse, och det blir svårare attta del av innehållet gemensamt med seende.

Rekommendationer för alternativ till visuellinformation i video

Informera användaren om att det finns alternativ.

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

Informera användaren om att det finns alternativGlöm inte bort att länka till textbeskrivningen (eller göra den nåbar på annatsätt) på de platser där videon förekommer, och att länka till videon fråntextbeskrivningen om den förekommer fristående. Då kan användaren självvälja version.

Tänk på attWebbdirektivets krav på videoinspelningar gäller material som publicerasfrån och med 23 september 2020.

En textversion är också bra för sökmotoroptimeringen eftersom detunderlättar för sökmotorer och andra verktyg att tolka innehållet.

Utdrag från WCAG-standarden

Riktlinje 1.2 Tidsberoende media: Tillhandahåll alternativ tilltidsberoende media.

1.2.3 Ljudbeskrivning eller mediealternativ (Förinspelat): Detfinns ett alternativ till tidsberoende media eller en ljudbeskrivning

Vägledning förWebbutveckling Sida 243 /

316

Page 245: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

av det förinspelade videoinnehållet i synkroniserad media, utomnär mediet är ett mediealternativ till text och tydligt är märkt somsådant.(Nivå A)

Läs mer om syntolkningDen mest fullständiga webbriktlinjen om syntolkning är R120. Syntolkavideoinspelningar.

Se även R113 Använd webbvideo för att öka tillgängligheten och R116Erbjud alternativ om en inspelning enbart består av ljud eller video.

Senast uppdaterad: 2018-12-05

Prio 1

Texta direktsändningarDigital video ska ha undertexter och för annat ljud bör en textversionerbjudas. Denna riktlinje gäller direktsändningar.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter:När i utvecklingsprocessen?:

Digital video ska ha undertexter (kallas även textbeskrivningar ellertextremsa) och för annat ljud (till exempel radioprogram) bör en textversionerbjudas. Direkttextning är mer värdefullt än om videon textas i efterhandeftersom den som behöver textning annars måste vänta. Förutom personermed nedsatt hörsel finns det många andra som har nytta av undertext. Tillexempel den som inte har högtalare, eller som av något skäl blirdistraherad, eller kanske har ett annat modersmål.

Denna riktlinje gäller direktsändningar, men i övrigt har den sammainnebörd som R117 Texta inspelad rörlig media (video, ljud, animationer …).Läs därför båda riktlinjerna för relevanta rekommendationer.

Se även R113 Använd webbvideo för att öka tillgängligheten, som blandannat innehåller kodexempel och tips inför produktion och upphandling avvideotjänster.

Rekommendationer för direkttextningÖverväg direkttextning trots undantag i webbdirektivetInformera om att det finns textning

Riktlinje nr 119

Vägledning förWebbutveckling Sida 244 /

316

Page 246: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Överväg direkttextning trots undantag iwebbdirektivetEU-lagstiftningen, det så kallade webbdirektivet, gör undantag fördirektsändningar, men om sändningen går att ta del av i efterhand räknasden (enligt skäl 27) som en inspelning efter högst 14 dagar och är inteundantagen. Det innebär att inspelningen måste textas eller kompletterasmed en textversion efter 14 dagar.

WCAG-kriteriet avser i huvudsak enkelriktade direktsändningar(“broadcast”), det vill säga inte bildtelefoni eller videokonferenser. Mengränserna däremellan är flytande, och även i sådana sammanhang finns detibland behov av textning. Fråga gärna deltagarna i förväg vilka behov de harför att kunna delta på lika villkor.

Sidan med tips för att göra möten tillgängliga tar upp flera saker att tänkapå, som är relaterade till direkttextning.

Informera om att det finns textningGör det tydligt för användaren att det finns textning, till exempel genom attvisa en symbol, särskilt när användaren aktivt behöver ta fram texten(stängd undertext).

Stängda undertexter heter closed captions på engelska, därför användsibland en ikon med ”cc”. I Sverige används ofta symbolen med ett enkelt T.Den tredje symbolen som avbildar textremsor i nederkanten av en bild stårför ”subtitles”. För licensinformation om bilderna se avsnittet återanvändningav symboler.

Utdrag från WCAG-standarden

Riktlinje 1.2 Tidsberoende media: Tillhandahåll alternativ tilltidsberoende media.

1.2.4 Textbeskrivningar (direktsända): Det finnstextbeskrivningar av allt direktsänt ljudinnehåll i synkroniseradmedia. (Nivå AA)

TerminologiObservera att det finns en skillnad mellan textning som visas separat frånsändningen, exempelvis på en särskild skärm bredvid en scen (kallas påengelska för CART) och sådan text som är en del av en videoström(realtime captioning). Den senare kräver ett samarbete mellan skrivtolk ochvideoproducent. CART står för Communication Access RealtimeTranslation.

Vägledning förWebbutveckling Sida 245 /

316

Page 247: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

>Velotype, eller veyboard, är en teknisk lösning för direkttextning. Det är ettsärskilt tangentbord som inte utgår från tecken utan från ljud, och sommedger mycket snabb textning, men kräver träning. När vanliga tangentbordanvänds kallas det för skrivtolkning.

Senast uppdaterad: 2018-12-05

Prio 1

Syntolka videoinspelningarOrdna med syntolkning om det behövs för att personer med begränsad synska kunna ta del av videoinnehåll.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter:När i utvecklingsprocessen?:

Ordna med syntolkning om det behövs för att personer med begränsad synska kunna ta del av innehållet.

Illustration: Texten i den övre pratbubblan (“Ada står vänd mot kameran”)visar exempel på syntolkning, medan den nedre bubblan (Ringsignal. “Hejdet är jag!”) beskriver det ordinarie ljudspåret.

I en syntolkad video (kallas även ljudbeskrivning) kan användaren välja ettljudspår där en röst återger det visuella innehåll som inte framgår av dialogoch miljöljud. Syntolkning är viktigt eftersom icke-seende behöver förståsammanhang där visuell information är nödvändig för förståelsen.

Ibland är det möjligt att planera en inspelning så att en separat syntolkadversion inte är nödvändig. Det kanske räcker med att personer som talarinleder med att presentera sig, att föreläsare beskriver eventuellapresentationsbilder med ord, eller att programledare ger tillräcklig muntlig

Riktlinje nr 120

Vägledning förWebbutveckling Sida 246 /

316

Page 248: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

information i ordinarie ljudspår (så kallad verbalisering).

Webbdirektivets krav på inspelad video gäller material som publiceras frånoch med 23 september 2020.

Rekommendationer för syntolkningFölj riktlinjer för syntolkningInformera användare om att det finns en syntolkad version

Följ riktlinjer för syntolkningFör att kunne göra en bra syntolkning krävs kunskap om handling,karaktärer, miljöer mm. Det kan vara viktigare att beskriva sammanhangetän det som för stunden presenteras visuellt. En verklig syntolkning avsekvensen som visas i bildexemplet med Ada skulle till exempel kunna vara”Ada lämnar huset. Stannar upp, ser förväntansfull ut, skyndar vidare tillKarl”. Erfarna syntolkar vet vad som är viktigast att beskriva.

Anlita helst en erfaren syntolk redan på planeringsstadiet. Det är också braom syntolken får kontakt med filmens manusförfattare eller regissör.

Om ni inte kan anlita proffs för produktionen utgå åtminstone från riktlinjerför syntolkning. Det finns länkar till sådana i avsnittet fördjupningslänkar.

Tänk på att syntolkningen inte får krocka med repliker eller viktigainformationsbärande ljud. Om de pauser som finns i ordinarie ljud interäcker för att beskriva all visuell information så behöver syntolkningenprioritera det som är viktigast för förståelsen. På WCAG-nivå AAA måste allavgörande information syntolkas, vilket kan innebära att filmen behöverpausas. Den nivån krävs inte av webbdirektivet, men i vissa sammanhangkan det vara nödvändigt för dina användare.

Informera användare om att det finns en syntolkadversionInformera användarna om att det finns en separat syntolkad version, tillexempel med en länk i direkt anslutning till ordinarie version. Ibland är detmöjligt att lägga in flera alternativa ljudspår i samma video, så attanvändaren själv kan välja. Se kodexempel i riktlinje 113.

Syntolkning heter audio description på engelska och representeras iblandav någon av dessa symboler, eller av förkortningen ”AD” som kommer avdet engelska ”audio description”. För licensinfo, se avsnittet återanvändningav symboler.

Undersök alternativa lösningarOm presentatörer och programledare är noga med att beskriva all viktigvisuell information så kan inspelningen eventuellt göras tillgänglig för

Vägledning förWebbutveckling Sida 247 /

316

Page 249: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

synskadade personer även utan separat syntolkning. Se gärna tips på hurdu kan göra föreläsningar synskadevänliga. Men det är lätt hänt attpresentatörer glömmer bort detta, eller att de inte hinner, eller misslyckasmed att bedöma vad som behöver beskrivas. Därför behövs ofta en riktigsyntolkning.

Som alternativ till talad syntolkning kan eventuellt textbaserad syntolkninganvändas. Då beskrivs det visuella innehållet i en tidssynkroniseradtextremsa som läses upp av skärmläsaren. I dagsläget är det inte säkert attdetta ger en användarupplevelse som är jämförbar med ljudbaseradsyntolkning, men i takt med att tekniken förbättras kan detta bli ett smidigtalternativ, särskilt för produktioner där syntolkning bara behövs i litenomfattning.

Om du erbjuder syntolkning i form av textremsa för uppläsning avskärmläsare bör html5-elementet track märkas upp med attributet kind,

som ska ha värdet ”descriptions”.

Utdrag från WCAG-standarden

Riktlinje 1.2 Tidsberoende media: Tillhandahåll alternativ tilltidsberoende media.

1.2.5 Ljudbeskrivning (förinspelad): Det finns ljudbeskrivningarav allt förinspelat videoinnehåll i synkroniserad media. (Nivå AA)

Exempel på syntolkade inspelningarPå Synskadades Riksförbunds Youtubekanal finns flera exempel påsyntolkade filmer.

FördjupningslänkarSynskadades riksförbund (SRF) har en hel del information omsyntolkning. Bland annat Plattform för syntolkning (pdf, 131 kByte)som innehåller riktlinjer.En 30 minuter lång föreläsning om syntolkning gjordes vid ett möte omtillgänglig video med MITT-nätverket.Tips om teknisk utformning (på engelska)Tips om hur syntolkningen bör utföras (på engelska)

Se även R113 Använd webbvideo för att öka tillgängligheten, R116 Erbjudalternativ om en inspelning enbart består av ljud eller video och R118Syntolka eller erbjud alternativ till videoinspelningar.

Två föreläsningar om syntolkad video på webbenHär följer en inspelning av två föreläsningar om syntolkad video på webben.Henrik Götesson, handläggare på Synskadades riksförbund, tar uppsyntolkning ur ett användarperspektiv och Magnus Johansson som jobbarmed produktion tar upp det perspektivet. Det finns även enteckenspråkstolkad version och en separat syntolkad ljudversion av

Vägledning förWebbutveckling Sida 248 /

316

Page 250: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

inspelningen.

Download videoDownload captionsDownload audio descriptions (MP3)

Textinnehåll

Terminologi

Syntolkning kallas oftast för audio description på engelska, men ibland ävenför video description, descriptive narration. En bredare term som både kaninnebära syntolkning och andra talade meddelanden är voice over.

Senast uppdaterad: 2018-12-05

Prio 1

Ange i kod vad sidans olika delar harför rollÖka chansen att informationen presenteras korrekt oavsett mottagarensverktyg, genom att använda html-elementen på rätt sätt.

Om denna riktlinjePrioritet: 1Principer:Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Digital information har fördelen att den kan presenteras för användaren påmånga olika sätt, beroende på användarens behov, utrustning ochpreferenser. Exempelvis kan information läsas upp eller förstoras ellerpresenteras med annan layout. Du som avsändare behöver se till att ingenviktig information går förlorad när presentationen förändras. Det kan du göragenom att märka upp sidans innehåll på rätt sätt i koden.

Exempel på information som riskerar att förloras vid ändring avpresentationsformat:

att en rubrik är en rubrik, om den särskiljs enbart med hjälp avformatering (till exempel fetstil och större teckengrad)kopplingen mellan en ledtext och ett formulärfält, om detta enbartframgår av textens placeringkolumnindelning om en tabell skapas till exempel med hjälp av tabbaroch mellanslag eller css-positionering

Riktlinje nr 121

Vägledning förWebbutveckling Sida 249 /

316

Page 251: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Utnyttja html-språkets olika element så som de är tänkta, och kompletteramed WAI-ARIA och att uttryckligen beskriva med text sådant som inteframgår av kodningen.

Rekommendationer för semantisk kodning avsidans struktur

R105. Skapa rubriker med h-elementR104. Använd rätt html-element när ni gör listorNamnge formulärfält med kopplade label-element. Se R55. Skapatydliga och klickbara fältetiketter.R98. Skriv rubriker till tabellerR101. Markera obligatoriska fält i formulärBetona 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 vanlightml.

Utdrag från WCAG-standarden

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kanpresenteras på olika sätt (exempelvis med enklare layout) utanatt information eller struktur går förlorad.

1.3.1 Information och relationer: Information, struktur, ochrelationer som förmedlas genom presentation kan bli automatiskttydliggjord eller finnas som text. (Nivå A)

MätbarhetMånga brister kopplade till detta kriterium går att identifiera genom att provaanvändning med skärmläsare och olika skärmstorlekar.

Relaterade riktlinjerR82. Använd stilmallar för att separera presentationen från innehålletR123. Gör inte instruktioner beroende av sensoriska känneteckenR124. Använd inte enbart färg för att förmedla information

Senast uppdaterad: 2019-02-18

Prio 1

Presentera innehållet i en meningsfullordning för allaUtforma innehållet på ett sätt som bevarar den avsedda betydelsen för allaanvändare.

Riktlinje nr 122

Vägledning förWebbutveckling Sida 250 /

316

Page 252: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Alla användare tar inte del av informationen i samma ordning. En visuellpresentation kan till exempel använda kolumner och rutnät för att fördelainnehållet i två dimensioner, medan en skärmläsare presenterar innehålletsekventiellt.

Responsiv design, som anpassar presentationen baserat på skärmstorlek,kan påverka ordningen. Även när språk som läses från vänster till högerblandas med språk som läses från höger till vänster kan betydelsenpåverkas av ordningen.

Utforma innehållet på ett sätt som bevarar den avsedda betydelsen för allaanvändare, alltså även om ordningen skulle förändras.

Ett exempel på när ordningen har betydelse finns faktiskt längre ned på denhär webbsidan:

Intill utdraget från WCAG nedan finns en kort text med fakta om utdraget.För läsare med stor skärm presenteras faktatexten till höger om utdraget.För användare med liten skärm presenteras den nedanför utdraget, och föranvändare med skärmläsare direkt efter utdraget. Därmed är ordningenlogisk för alla. Men för att åstadkomma detta kunde vi inte koda sidan påenklaste sätt med vänsterspalten i ett div-element och därefter högerspalteni ett annat. Då hade nämligen faktatexten hamnat efter hela vänsterspaltenför användare med liten skärm eller skärmläsare. Det skulle kunna fåläsaren att felaktigt tro att faktatexten gällde innehållet längre ner ivänsterspalten, och inte utdraget.

Oftast, men inte alltid, presenteras innehållet i rätt ordning om det

Vägledning förWebbutveckling Sida 251 /

316

Page 253: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

förekommer i rätt ordning i html-koden.

Rekommendationer för läsordningTesta läsordningen genom att granska en sida av varje sidtyp mednågra skärmar i olika storlek och genom att lyssna igenom innehålletmed en skärmläsare.Se till och testa även att läsordningen är logisk i dokument som inte ärhtml (pdf, word med mera) .

Utdrag från WCAG-standarden

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kanpresenteras på olika sätt (exempelvis med enklare layout) utanatt information eller struktur går förlorad.

1.3.2 Meningsfull ordning: När meningen med innehålletpåverkas av ordningen det presenteras i, kan en logiskläsordning bli automatiskt tydliggjord. (Nivå A)

Fördjupning om läsordningR136 Gör en logisk tab-ordningW3C om olika läsriktning på webben

Senast uppdaterad: 2018-11-30

Prio 1

Gör inte instruktioner beroende avsensoriska känneteckenÄven den som inte kan uppfatta form, storlek eller har möjlighet att relateratill höger eller vänster behöver kunna förstå till navigation och instruktioner.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Ge alla användare möjlighet att förstå de instruktioner som krävs för attkunna navigera eller använda en webbplats. Även den som inte kanuppfatta form, storlek eller har möjlighet att relatera till höger eller vänsterbehöver kunna förstå till navigation och instruktioner. Det kan till exempelhandla om personer som använder tekniska hjälpmedel som presenterarinformationen på ett alternativt sätt. Det är exempelvis svårt för en personsom använder skärmläsare att förstå en instruktion som ”klicka på knappen

Riktlinje nr 123

Vägledning förWebbutveckling Sida 252 /

316

Page 254: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

till höger”, eller som icke hörande kunna följa instruktionen “när du hör tonenär det dags att klicka”.

Instruktioner som använder den här typen av sensoriska känneteckenbehöver kompletteras med ytterligare information för att alla ska kunnaförstå.

Rekommendationer för instruktioner medsensoriska kännetecken

Använd gärna sensoriska kännetecken (färg, form med mera) förinstruktioner eftersom det kan vara en effektiv metod för att underlätta föranvändarna, inklusive personer med kognitiva begränsningar men kom ihågatt komplettera informationen så att alla kan förstå den.

Exempel på kompletterande instruktionerInstruktion i hjälptext i webbundersökningOm användarna exempelvis ska navigera i en webbundersökning somsträcker sig över flera sidor används ofta pilar för att markera attanvändaren kan klicka sig framåt och bakåt i undersökningen. Ominstruktionen till användarna är ”Gå till nästa sida genom att klicka på dengröna pilen med texten ”Nästa sida” i nedre högra hörnet”, används bådepositionering, färg och tydlig markering på ikonen för att vägledaanvändarna framåt i undersökningen.

Hänvisning till höger eller vänsterOm det finns behov av att hänvisa till information som ligger till höger ellervänster behöver den också kompletteras med ytterligare information. Ett sättatt göra det skulle kunna vara att hänvisa till rubriken: Vill du veta mer omämnet x, hittar du länkar till fördjupningar i listan till höger under rubrikenRelaterat.

Var dock försiktig med hänvisningar till höger eller vänster eftersom de oftainte gäller när användaren surfar på en mobiltelefon. Det som ligger tillhöger/vänster på en desktop hamnar ofta under eller över i mobiltelefonen.

Hänvisningar ovan eller underPå många språk, inklusive svenskan, är det underförstått att ”ovan” är enhänvisning till innehåll som förekommit tidigare i en text, och ”nedan” avserinnehåll som kommer efter. Om det är otvetydigt till vilken del av sidan ensådan hänvisning pekar kan en hänvisning som ”välj en av länkarna nedan”eller ”såsom nämndes ovan” mycket väl fungera enligt riktlinjen.

Utdrag från WCAG-standarden

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kanpresenteras på olika sätt (exempelvis med enklare layout) utanatt information eller struktur går förlorad.

1.3.3 Sensoriska kännetecken: Instruktioner för att förstå och

Vägledning förWebbutveckling Sida 253 /

316

Page 255: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

styra innehåll är inte enbart beroende av sensoriskakännetecken såsom form, storlek, visuell placering, orienteringeller ljud. (Nivå A)

Anmärkning: För krav som har med färg att göra, se Riktlinje 1.4.

Senast uppdaterad: 2018-11-28

Prio 1

Använd inte enbart färg för attförmedla informationAnvänd gärna färger, men låt inte färgskillnader vara det enda sättet atturskilja information utan komplettera med exempelvis text, mönster ellernågon annan visuell indikation.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Färger är mycket användbara för att förhöja användbarhet och estetik. Menvissa användare kan inte uppfatta färgskillnader, till exempel på grund avfärgblindhet eller för att de använder en monokrom skärm eller skärmläsare.Använd gärna färger, men låt inte färgskillnader vara det enda sättet atturskilja information utan komplettera med exempelvis text, mönster ellernågon annan visuell indikation.

Rekommendationer för användning av färger

Komplettera färgskillnader:

i text med understrykning, ram, fetstil, kursivering eller annatteckensnitt.med ikoner.med mönster i diagram och kartor för att särskilja ytmarkeringar.med beskrivning i text.med semantisk kodning.

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

Exempel

Den amerikanska regeringens stilguide använder en kombination av färger,

Riktlinje nr 124

Vägledning förWebbutveckling Sida 254 /

316

Page 256: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

ikoner och text för att presentera olika kategorier av meddelanden föranvändaren:

På Bredbandskartan presenteras information med hjälp av färgade rutor.Samma information visas även med text när användaren markerar rutan.Vid behovsanalysen framkom det att vissa användare önskade just röd-grönfärgskala, vilket är problematiskt för personer med färgblindhet. Lösningenfick bli att användaren själv kan välja färgschema.

Observera att Bredbandskartan använder mönster för ett andra lager avinformation. Därmed är det svårt att använda mönster för att särskilja rutor idet första lagret.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund från

Vägledning förWebbutveckling Sida 255 /

316

Page 257: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bakgrund.

1.4.1 Användning av färger: Färg används inte som det endavisuella sättet att förmedla information, indikera en handling,fråga om återkoppling eller särskilja ett visuellt element. (Nivå A)

Anmärkning: Detta framgångskriterium tar specifikt uppfärgperception. Andra typer av perception behandlas i Riktlinje1.3 inklusive automatisk åtkomst av kod för färg och annanvisuell presentation.

MätbarhetTesta genom att ställa in din skärm på monokrom presentation ellergråskala.

Verktyg som till exempel RGBlind kan användas för att simulera färgblindhetpå en webbplats.

Senast uppdaterad: 2018-11-28

Prio 1

Ge användaren möjlighet att pausa,stänga av eller sänka ljudDet ska alltid vara möjligt att pausa, stoppa eller sänka sådant ljud somspelas upp automatiskt.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Användare som lyssnar på en sida med hjälp av skärmläsare kanske intekan uppfatta innehållet alls om det samtidigt spelas upp andra ljud.Användare med nedsatt förmåga att fokusera eller filtrera bort intryck kanockså få svårt att använda en tjänst om det inte går att stänga av ljud.Därför ska det alltid vara möjligt att pausa, stoppa eller sänka sådant ljudsom spelas upp automatiskt.

Eftersom skärmläsaren är ljudbaserad räcker det inte med att kunna stängaav allt ljud på enheten, utan det ska gå att stänga av det automatisktuppspelade ljudet separat.

Rekommendationer för kontroll av ljudI de flesta fall är det lämpligt att undvika att spela ljud automatiskt.

Riktlinje nr 125

Vägledning förWebbutveckling Sida 256 /

316

Page 258: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

I andra hand kan det vara lämpligt att erbjuda en pausfunktion i börjanav sidan.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.2 Kontroll av ljud: Om något ljud på en webbsida automatisktspelas i mer än tre sekunder så ska det antingen finnas enmetod/funktion för att pausa eller stoppa ljudet, eller enmetod/funktion för att ändra ljudnivån. Denna kontroll ska varaoberoende av systemets ordinarie volymkontroll. (Nivå A)

Anmärkning: Eftersom innehåll som inte uppfyller dettaframgångskriterium kan hindra en användares möjlighet attanvända hela sidan, så måste allt innehåll på webbsidan uppfylladetta framgångskriterium (oavsett om innehållet används för attuppfylla andra framgångskriterier eller inte). Se Uppfyllnadskrav5: inte störande.

Relaterade riktlinjerR132 Ge användarna möjlighet att pausa eller stänga av rörelser

Senast uppdaterad: 2018-11-28

Prio 1

Använd tillräcklig kontrast mellan textoch bakgrundBra kontrast mellan text och bakgrund är viktigt för läsbarheten, särskilt förpersoner med nedsatt synförmåga.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Personer med nedsatt syn har ofta svårt att läsa text med bristande kontrastmot textens bakgrund. De flesta kan läsa brödtext på skärm om skillnaden iljusintensitet mellan förgrund och bakgrund har förhållandet 4,5:1. Därförhar WCAG-standarden detta förhållande som grundkrav. Kontrastvärdet kanmätas med hjälp av programvara.

Riktlinje nr 126

Vägledning förWebbutveckling Sida 257 /

316

Page 259: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Större text (till exempel rubriker) är lättare att läsa, och för sådan är därförgränsvärdet 3:1.

Logotyper, dekorativa inslag och inaktiva funktioner är undantagna iriktlinjen. Innehåll i diagram och annan grafik som behöver kunna läsas ellertolkas bör dock uppfylla kontrastkraven. Se Använd tillräckliga kontraster ikomponenter och grafik (R156).

Rekommendationer för kontrasterLita 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

Lita inte enbart på automatisk granskning avkontrasterObservera att det inte alltid går att veta vilken position en text kommer att hai förhållande till olika sidelement som finns i bakgrunden (färgade plattor,bilder och så vidare). Den beror på användarens val av textstorlek,skärmbredd, skalning av bilder med mera. Var därför försiktig med tillexempel bakgrundsbilder som vid en olycklig positionering skulle ge dåligkontrast, även om det ser bra ut med just din kombination av tecken- ochskärmstorlek.

Bilden visar en sorts syntavla där kontrasten är sämre längre ner. Allrasvårast är det att urskilja text mot spräcklig bildbakgrund.

Överträffa gärna gränsvärdena för kontrast

Det finns användare som behöver kontrastförhållande ända upp tillförhållandet 7:1 för att klara sig utan hjälpmedel. Där går gränsen för nivåAAA enligt WCAG 2.1. Personer som behöver ännu högre kontrast brukar

Vägledning förWebbutveckling Sida 258 /

316

Page 260: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

använda hjälpmedel för att öka kontrasten eller förstora texten.

Överväg att låta användaren välja kontraster

För vissa användare underlättar låga kontraster eller inverterade färger(exempelvis mörk bakgrund istället för ljus). Överväg därför att låtaanvändarna själva kontrollera kontrastförhållanden och färgskalor. Detta ärinte nödvändigt för att uppfylla WCAG, men kan för vissa personer ökatillgängligheten.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.3 Kontrast (minimum): Den visuella presentationen av textoch text i form av bild har ett kontrastvärde på minst 4,5:1 medföljande undantag: (Nivå AA)

Stor text: Text i stor stil och bilder av text i stor stil har ettkontrastvärde på minst 3:1.Oväsentlig: Text eller text i form av bild som är en del av eninaktiv komponent i ett användargränssnitt, är rentdekorativ, inte är synlig för någon, eller är en del av en bildsom innehåller annat viktigt visuellt innehåll, har inga kravvad gäller kontrast.Logotyper: Text som är en del av en logotyp eller ettvarumärke har inget minimikrav vad gäller kontrast.

MätbarhetTips på gratisverktyg för mätning av kontraster.

Relaterade riktlinjerAnvänd tillräckliga kontraster i komponenter och grafik (R156)Ge webbplatsen en god läsbarhet (R39)

Senast uppdaterad: 2018-11-28

Prio 1

Se till att text går att förstora utanproblemDet ska vara möjligt att förstora texten till åtminstone dubbel höjd och breddutan att problem uppstår (till exempel att text hamnar bakom en bild eller

Riktlinje nr 127

Vägledning förWebbutveckling Sida 259 /

316

Page 261: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

krockar med annan text).

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter:När i utvecklingsprocessen?:

Många personer med nedsatt syn behöver kunna förstora text för att kunnaläsa den. Därför ska det vara möjligt att förstora texten till åtminstonedubbel höjd och bredd utan att nya problem uppstår (till exempel att delar avtexten hamnar bakom en bild eller krockar med annan text, som iexempelbilden).

Observera: De användare som har en modern webbläsare har oftastmöjlighet att zooma hela innehållet till 200 procent, vilket gör att kriterietuppfylls (om det går att scrolla åt sidan om det finns innehåll som hamnarutanför skärmen i inzoomat läge). Men denna funktion finns inte överallt.Vissa webbläsare erbjuder istället förstoring av text, medan övrigt innehållinte förstoras. Detta har fördelen att användaren slipper panorera såmycket, och det ger bättre förutsättningar för överblick än vid zoomning.

I riktlinjen finns ett undantag för “textbeskrivningar”, detta gäller framför allttextremsor i video

Rekommendationer för förstoring av textKontrollera förstoring vid utveckling av stilmallar och sidmallarAnvänd relativa mått

Kontrollera förstoring vid utveckling av stilmallaroch sidmallarDet är svårt, eller omöjligt, att som webbutvecklare förutse vilkenwebbläsare och utrustning användare kommer att ha (förutom i vissaintranät-sammanhang). Såvida du inte vet att alla användare har möjlighetatt zooma så måste sidan kunna förstoras. Det är lämpligt att testa detta vidutformning av stilmallar och sidmallar. Tänk på att inte bara testa att detfungerar med test-innehåll (texter med “lorem ipsum….” till exempel) utantesta sidmallarna med realistiskt innehåll som motsvarar webbplatsens mestkrävande verkliga innehåll.

Använd relativa mått

Vägledning förWebbutveckling Sida 260 /

316

Page 262: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När textstorlek specificerats i absoluta måttenheter som till exempel pixlarblir det i vissa sammanhang omöjligt att förstora texten. Använd iställetrelativa mått som till exempel em eller procent.

Justera kolumnbredder och andra fasta utrymmesbegränsningar så attförstoring fungerar. Eventuellt behöver textrutor och knappar konfigureras såatt de kan växa om texten i dem tar större plats.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.4 Förändring av textstorlek: Förutom för textbeskrivningaroch text i form av bild, så kan text förstoras utan hjälpmedel upptill 200 procent utan att användaren förlorar innehåll ellerfunktionalitet. (Nivå AA)

Relaterade riktlinjerSe till att det går att öka avstånd mellan tecken, rader, stycken och ord(R157)Ge webbplatsen en god läsbarhet (R39)

Senast uppdaterad: 2018-11-28

Prio 1

Använd text, inte bilder, för att visatextAnvändare behöver då och då anpassa texten bland annat genom attförstora eller välja ett annat teckensnitt, ändra förgrund- ochbakgrundsfärger eller linjeavstånd. Om texten utgör en del av en bild saknasofta de möjligheterna.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Många användare behöver anpassa texten bland annat genom att förstoraeller välja ett annat teckensnitt, ändra förgrund- och bakgrundsfärger ellerlinjeavstånd. Som regel har användare goda möjligheter att kontrollera hurdigital text presenteras. Men när texten utgör en del av en bild saknas oftade möjligheterna. Då blir bilden och texten pixlig om den förstoras och det

Riktlinje nr 128

Vägledning förWebbutveckling Sida 261 /

316

Page 263: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

är svårt eller omöjligt att byta teckensnitt eller färger. Använd därför så långtdet är möjligt text för att presentera information i stället för text i form av enbild.

Logotyper är undantagna från detta krav, och även andra bilder där denvisuella presentationen av text är av avgörande betydelse för att bildenssyfte ska uppnås. Det kan till exempel gälla skärmdumpar som syftar till attvisa hur en digital resurs brukar se ut på en skärm.

Ytterligare ett undantag från grundregeln är när text i bild trots allt kananpassas så att den motsvarar användarnas krav. Det kan till exempel gällabildformat baserade på vektorgrafik där användaren genom script kanpåverka presentationen.

Rekommendationer för bilder som innehåller textNär bilder trots allt behöver innehålla text kan denna ofta göras tillgänglig föralla genom att:

Använda CSS för att placera text i bilden, istället för att ha textenavbildad.Generera bilden dynamiskt med hänsyn till användarens preferenserför teckensnitt, storlek och förgrund- eller bakgrund. Observera attdetta kan kräva en del programmering och att sidan kan behövainnehålla kontroller för att ställa in sådana preferenser. Kompletteramed en alt-text.Skriv alt-text till knappar, logotyper, skärmdumpar och diagram somförmedlar samma information som bilden.En bild av ett handskrivet brev kan ha antingen en alt-text som återgerinnehållet eller en kompletterande text med samma funktion.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.5 Text i form av bild: Om den teknik som används kan skapaden visuella presentationen så ska text användas för attförmedla information hellre än text i form av bild, med följandeundantag: (Nivå AA)

Anpassningsbar: Texten i form av bild kan bli visuelltanpassad efter användarens krav.Avgörande betydelse: En utförlig presentation i form av texthar avgörande betydelse för att förmedla informationen.

Anmärkning: Logotyper (text som är en del av en logotyp eller ett

Vägledning förWebbutveckling Sida 262 /

316

Page 264: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

varunamn) anses ha avgörande betydelse.

TerminologiDatorgrafik kan vara baserad på ett rutnät eller på matematiska figurer.Rutnät kallas ofta för pixelgrafik, raster eller bitmap. De matematiskafigurerna kallas ofta vektor eller vektorgrafik. Vektorgrafik innebär att detfinns matematiska beskrivningar av kurvor, ytor med mera. Sådan grafik kanförstoras utan att tappa kvalitet, till skillnad från bitmap-bilder som ihuvudsak består av en färgangivelse för varje pixel. Det finns metoder för attminska pixlighet (sök på till exempel antialias), men om utgångspunkten ären bitmap-bild med låg upplösning (få pixlar) går det inte att komma ifrånproblemet helt. Och om upplösningen istället är hög kan det bli problemmed prestanda. Dessutom är det inte säkert att webbläsaren drar nytta aven hög bildupplösning om användaren förstorar en hel webbsida.

Senast uppdaterad: 2018-11-28

Prio 1

Utveckla systemet så att det går atthantera med enbart tangentbordetDen som bara kan eller vill använda tangentbordet (eller hjälpmedel somkopplas till tangentbords-kommandon) är beroende av att systemet inteförutsätter att användaren har till exempel mus eller pekskärm.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Testning

Den som bara kan eller vill använda tangentbordet (eller hjälpmedel somkopplas till tangentbordskommandon) är beroende av att systemet inteförutsätter att användaren har till exempel mus eller pekskärm.

Se därför till att det går att hantera all funktionalitet med enbart tangentbord,utan krav på hastighet. Det innebär till exempel att ingen funktionalitet skavara beroende av att användaren klickar på en viss koordinat, utför en vissrörelse eller drar ett objekt till någon specifik plats.

Kravet är inte tillämpbart i sådana situationer där det är omöjligt att utföra eninmatning med tangentbord, till exempel vid frihandsteckning ellermanövrering där en exakt rörelsebana är avgörande.

Se även R140 Markera tydligt vilket fält eller element som är i fokus.

Riktlinje nr 129

Vägledning förWebbutveckling Sida 263 /

316

Page 265: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Det är inte bara den som inte ser eller har så kallad musarm som kanbehöva navigera med tangentbord. Även den som är beroende avröststyrning, sug/blås-munstycke eller till exempel knappar som styr ensvepfunktion är beroende av att interaktion kan ske med hjälp avtangentbordskommandon.

Rekommendationer för hantering via tangentbordTesta alla webbplatser och applikationer utan mus och utan pekskärm.

Utdrag från WCAG-standarden

Riktlinje 2.1 Tillgängligt via tangentbord: All funktionalitet skavara åtkomlig med ett tangentbord.

2.1.1 Tangentbord: All funktionalitet är hanterbar via ettgränssnitt för tangentbord utan att det krävs särskild timing förvarje enskild tangenttryckning. Detta gäller med undantag för närden underliggande funktionaliteten kräver inmatning som ärberoende av mönstret som skapas av användarens rörelser ochinte bara slutpunkterna. (Nivå A)

Anmärkning 1: Detta undantag gäller den underliggandefunktionaliteten, inte sättet man matar in information. Om manexempelvis använder handskrift för att mata in text så kräverinmatningstekniken (handskrivning) mönsterberoende inmatning,men den underliggande funktionaliteten (textinmatning) kräverinte det.

Anmärkning 2: Detta förbjuder inte, och ska inte avskräcka från,att också använda styrning via mus eller andrainmatningsmetoder utöver tangentbordsstyrning.

Fördjupning om alternativa inmatningsenheterKnappar, sug-blås och andra hjälpmedel för styrning av digitalaenheter beskrivs i ett blogginlägg från Axess lab (på engelska).R130. Se till att markören inte fastnar vid tangentbordsnavigation

Senast uppdaterad: 2018-11-30

Prio 1

Se till att markören inte fastnar vidtangentbordsnavigationMarkören ska inte fastna vid tangentbordsnavigation. Det kan hindrabesökare att använda webbplatsen eller vissa funktioner.

Riktlinje nr 130

Vägledning förWebbutveckling Sida 264 /

316

Page 266: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Det händer ibland att användare som navigerar enbart med hjälp avtangentbord fastnar i en viss del av skärmen, eftersom ett script ellertilläggsprogram förväntar sig koordinatbaserad interaktion (såsom musklickeller tryck på pekskärm). Eftersom detta hindrar dessa användare från attfortsätta använda tjänsten är det ett allvarligt problem som måste åtgärdas.

Observera! Det är inte bara den som inte ser eller har så kallad musarmsom kan behöva navigera med tangentbord. Även den som är beroende avröststyrning, sug/blås-munstycke eller till exempel knappar som styr ensvepfunktion är beroende av att interaktion kan ske med hjälp avtangentbordskommandon.

Rekommendation för hantering via tangentbordTesta 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.

Undantag

Riktlinjen kräver inte att varje funktion kan nås med tangentbord, men om dekan nås så ska det även gå att komma vidare med tangentbord.

Utdrag från WCAG-standarden

Riktlinje 2.1 Tillgängligt via tangentbord: All funktionalitet skavara åtkomlig med ett tangentbord.

2.1.2 Ingen tangentbordsfälla: Om tangentbordsfokus kan flyttastill en komponent på webbsidan via ett gränssnitt för tangentbordså kan också fokus flyttas bort från samma komponent medhjälp av ett gränssnitt för tangentbord. Om det krävs något merän vanliga piltangenter, tabbtangenter eller andrastandardiserade avslutningsmetoder för att flytta bort fokus såska användaren informeras om hur det går till. (Nivå A)

Anmärkning: Eftersom innehåll som inte uppfyller dettaframgångskriterium kan hindra en användares möjlighet attanvända hela sidan, så måste allt innehåll på webbsidan uppfylladetta framgångskriterium (oavsett om innehållet används för attuppfylla andra framgångskriterier eller inte). Se Uppfyllnadskrav5: inte störande.

Relaterade riktlinjer

Vägledning förWebbutveckling Sida 265 /

316

Page 267: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se även R129 Utveckla systemet så att det går att hantera med enbarttangentbordet.

Senast uppdaterad: 2018-12-05

Prio 1

Ge användarna möjlighet att justeratidsbegränsningarAnvändare behöver ibland möjlighet att justera tidsbegräsningar som finnsinbyggda i systemet, till exempel i en beställningsfunktion. Ge dem det!

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Systemutveckling,Säkerhet, Testning

Många användare med funktionsnedsättning behöver längre tid ängenomsnittligt för att använda en digital tjänst.

Användare med dyslexi kan till exempel behöva längre tid för att läsa ochskriva. Användare med nedsatt syn kan behöva längre tid för att lyssnaigenom sidan och förstå hur den är uppbyggd. Och vissa användare som pågrund av nedsatt rörlighet inte kan använda mus eller liknande använder ensvep- eller skanningsfunktion. Det är styrhjälpmedel som upprepade gångersveper över en skärm eller förbi ett antal alternativ. Användaren kansignalera just när markeringen passerar rätt område eller alternativ.Eventuellt kombineras två signaler (en för höjdled och en för sidled) för attanvändaren ska kunna peka ut en valfri position på skärmen. Detta tar iregel längre tid än att välja en position på skärmen med hjälp av traditionellapekdon som till exempel mus. Det finns även andra skäl änfunktionsnedsättning som gör att användare ibland behöver mer tid.

För att alla användare ska hinna använda en webbplats behöver det finnasmöjlighet att justera eventuella tidsbegränsningar som byggts in i systemet.Det kan till exempel gälla en funktion för reservation av biljetter som har entidsbegränsning på ett visst antal minuter innan platserna släpps till någonannan. För att alla användare ska hinna slutföra beställningen måste detvara möjligt för dem att stänga av eller förlänga tidsbegränsningen.

Det finns ett antal begränsningar och undantag från regeln. Till exempel närdet gäller auktioner och vissa spel, då alla som deltar måste följa sammatidsschema för att det överhuvudtaget ska fungera. I andra fall kan det vara

Riktlinje nr 131

Vägledning förWebbutveckling Sida 266 /

316

Page 268: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

säkerhetsrisker som gör att regeln inte kan tillämpas. Men gör inte undantagutan att först överväga tänkbara alternativ.

Rekommendationer för att ge användare tillräckligtmed tid

För vissa användare och i vissa sammanhang behövs gott om tid föratt använda digitala tjänster. Ge därför användare möjlighet att stängaav, anpassa eller utöka eventuella tidsbegränsningar, om det inte ärorimligt för att uppnå sajtens syfte.

Utdrag från WCAG-standarden

Riktlinje 2.2 Tillräckligt med tid: Ge användaren tillräckligt medtid för att läsa och använda innehållet.

2.2.1 Justerbar tidsgräns: För varje satt tidsgräns gäller minst ettav följande: (Nivå A)

Stänga av: Användaren tillåts stänga av tidsgränsen iförväg, ellerAnpassa: Användaren tillåts justera tidsgränsen i förvägöver ett brett intervall som är minst 10 gånger längden påden ursprungliga inställningen, ellerUtöka: Användaren varnas innan tiden går ut och gesminst 20 sekunder för att förlänga tidsgränsen genom enenkel handling (t ex ”tryck ner mellanslagstangenten”).Användaren tillåts förlänga tidsgränsen åtminstone 10gånger, ellerUndantag: realtid: Tidsgränsen är nödvändig för händelseri realtid (t ex auktioner), och inga alternativ till tidsgränsenär möjliga, ellerUndantag: avgörande betydelse: Tidsgränsen haravgörande betydelse och att förlänga den skulle göra helaaktiviteten ogiltig, ellerUndantag: 20 timmar: Tidsgränsen är längre än 20 timmar.

Anmärkning: Detta framgångskriterium säkerställer attanvändarna kan fullfölja uppgifter utan oväntade förändringar avinnehåll eller sammanhang som är resultatet av en tidsgräns.Detta framgångskriterium ska beaktas i samband medframgångskriterium 3.2.1, vilket sätter gränser för förändringar avinnehåll eller sammanhang som är resultatet av användarnasagerande.

ExempelW3C har publicerat flera exempel på hur kriteriet i WCAG kan uppfyllas. Tillexempel javascriptkod som kan användas för att förlänga entidsbegränsning.

Vägledning förWebbutveckling Sida 267 /

316

Page 269: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-12-05

Prio 1

Ge användarna möjlighet att pausaeller stänga av rörelserPersoner som har svårt att fokusera, läsa eller behålla koncentrationbehöver kunna pausa rörelser eller stänga av visuella distraktioner.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Personer med nedsatt förmåga att fokusera, läsa eller behålla koncentrationkan få problem att använda en sida där innehåll börjar blinka, röra sig elleruppdateras utan att användaren bett om det. Därför måste sådana visuelladistraktioner antingen upphöra efter max 5 sekunder, eller så ska det finnasen möjlighet för användaren att pausa rörelser, stoppa eller dölja dem.Exempel på sådant innehåll är animationer, video, rullande nyhetstext,annonser och statusindikatorer som till exempel en “progress-mätare”.

Kriteriet behöver inte tillämpas när rörelsen eller uppdateringen är avavgörande betydelse. Till exempel när visning av en kort reklamfilm ärobligatorisk för alla användare och ingenting annat presenteras samtidigt.Då finns det ju ingenting att distrahera från.

Rekommendationer för rörliga element ianvändargränssnitt

Om en animation eller dynamisk uppdatering startar automatiskt ochpågår i mer än 5 sekunder ska användaren enkelt kunna undvika den.

Utdrag från WCAG-standarden

Riktlinje 2.2 Tillräckligt med tid: Ge användaren tillräckligt medtid för att läsa och använda innehållet.

2.2.2 Paus, Stopp, Dölj: För information som rör sig, blinkar,rullar eller uppdateras automatiskt gäller samtliga punkter: (NivåA)

Rörelse, blinkning, rullning (scrolling): För varje rörelse,blinkning eller rullning som (1) startar automatiskt, (2)pågår i mer än 5 sekunder, och (3) presenterastillsammans med annat innehåll, finns det en

Riktlinje nr 132

Vägledning förWebbutveckling Sida 268 /

316

Page 270: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

metod/funktion för att pausa, stoppa eller dölja dessa, sålänge inte rörelsen, blinkningen eller rullningen har enavgörande betydelse för en aktivitet, ochAutomatisk uppdatering: För automatiskt uppdateradinformation som (1) startar automatiskt och (2) presenterastillsammans med annat innehåll finns det en metod/funktionför att pausa, stoppa eller dölja den eller en metod/funktionför att kontrollera uppdateringsfrekvensen. Detta gällerförutom om den automatiska uppdateringen har enavgörande betydelse för en aktivitet.

Anmärkning 1: För krav som rör flimmer, se Riktlinje 2.3.

Anmärkning 2: Eftersom innehåll som inte uppfyller dettaframgångskriterium kan hindra en användares möjlighet att använda helasidan, så måste allt innehåll på webbsidan uppfylla dettaframgångskriterium (oavsett om innehållet används för att uppfylla andraframgångskriterier eller inte). Se Uppfyllnadskrav 5: inte störande.

Anmärkning 3: I innehåll som uppdateras av mjukvara inom vissa intervalleller som strömmas till användarprogrammet behöver inte informationensom genererats eller tagits emot under pausen sparas eller presenteras, dådetta kan vara tekniskt omöjligt och i många situationer missvisande.

Anmärkning 4: En animation som är en del av en inladdningsfas ellerliknande, kan betraktas ha avgörande betydelse om användarna inte kaninteragera under den fasen och om utebliven visualisering av processenskulle kunna förvirra användarna eller få dem att tro att innehållet har ”frusit”eller att kopplingen mot innehållet har brutits.

Relaterade riktlinjerR125. Ge användaren möjlighet att pausa, stänga av eller sänka ljudR133. Orsaka inte epileptiska anfall genom blinkande

Senast uppdaterad: 2018-12-05

Prio 1

Orsaka inte epileptiska anfall genomblinkandePersoner med en viss kategori av epilepsi kan få krampanfall om de utsättsför snabbt blinkande “flimmer” som upptar en tillräckligt stor del av synfältet.

Om denna riktlinjePrioritet: 1Principer: Tillgänglig

Riktlinje nr 133

Vägledning förWebbutveckling Sida 269 /

316

Page 271: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter:När i utvecklingsprocessen?:

Personer med en viss kategori av epilepsi kan få krampanfall om de utsättsför snabbt blinkande “flimmer” som upptar en tillräckligt stor del av synfältet.Det skulle till exempel kunna gälla en filmsekvens från ett diskotek medblinkande lampor, en krigsscen med explosioner, eller rörelser från enannons som är utformad för att dra till sig uppmärksamhet.

Rekommendation för att undvika att orsakakrampanfall

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

Hur stora ytor gäller det?Begränsningen gäller ytor som motsvarar mer än 10 grader av synfältet vidtypiskt avstånd mellan skärm och öga. På en datorbildskärm medupplösningen 1024 x 768 pixlar (XGA) motsvaras detta av en rektangel på341 x 256 pixlar eller större (som den svarta bilden nedan). Mobilskärmarvisar ofta så många pixlar på en mindre yta, men de hålls i regel närmareögonen, vilket gör att en så stor rektangel ändå kan vara en lämpligutgångspunkt.

Svart, 341x256 pixlar stor rektangel.

Använd alltså inte snabbt blinkande ytor om de inte är klart mindre ändenna.

Utdrag från WCAG-standarden

Riktlinje 2.3 Krampanfall: Designa inte innehåll på ett sätt somkan orsaka krampanfall.

2.3.1 Tre flimmer eller under tröskelvärde: Webbsidor innehålleringet som flimrar mer än tre gånger under en ensekundsperiod,eller så ligger flimret under de generella tröskelvärdena förflimmer och rött flimmer. (Nivå A)Anmärkning: Eftersom innehåll som inte uppfyller dettaframgångskriterium kan hindra en användares möjlighet attanvända hela sidan, så måste allt innehåll på webbsidan uppfylladetta framgångskriterium (oavsett om innehållet används för attuppfylla andra framgångskriterier eller inte). Se Uppfyllnadskrav5: inte störande.

Relaterade riktlinjerR132. Ge användarna möjlighet att pausa eller stänga av rörelser

Vägledning förWebbutveckling Sida 270 /

316

Page 272: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-12-05

Prio 1

Skriv beskrivande sidtitlarEn bra beskrivande titel sammanfattar sidans ämne eller innehåll. Varje sidapå en webbplats, liksom andra typer av dokument bör ha en unik titel.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter:När i utvecklingsprocessen?:

När du ger sidor en beskrivande sidtitel (title) hjälper du användarna att

orientera sig och lättare hitta innehåll i till exempel listor med sökresultateller bland flikarna i en webbläsare.

Sidtiteln används ofta som rubrik på webbläsarens fönster eller flik, och somrubrik på genvägar till webbsidan. Den används även som rubrik på länkar isökresultat, och när sidan delas i sociala medier (i avsaknad avspecialskrivna metadata för sådana ändamål).

En bra beskrivande titel sammanfattar sidans ämne eller innehåll. Varje sidapå en webbplats, liksom andra typer av dokument bör ha en unik titel. Förmobila applikationer kan det antingen vara aktuellt med en titel för helaapplikationen, en titel per skärm, eller en titel per dokument.

Rekommendationer för bra sidtitlarBeskriv sidans ämne eller innehåll.Formulera en titel som går att förstå på egen hand. Det kan tillexempel innebära att avsändaren eller webbplatsens namn anges islutet av sidtiteln.Titeln bör vara så tydlig och så unik som möjligt utan att bli för lång.

Titel på dokument och webbapplikationerOm sidan är ett dokument eller en webbapplikation är ofta namnet pådokumentet eller webbapplikationen tillräckligt för att beskriva sidan och kanmånga gånger fungera som titel. Men om det inte är det behöver du skrivaen ny titel som bättre sammanfattar innehållet.

Samband mellan länktext och sidtitel

Eftersom många länkar går till andra webbsidor är det en bra princip att sålångt det är möjligt se till att länktexten överensstämmer med målsidans titel

Riktlinje nr 135

Vägledning förWebbutveckling Sida 271 /

316

Page 273: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

och rubrik. Då förstår användaren både vart länken leder och ser direkt atthen har kommit rätt efter att ha klickat på länken. Se även R5 Skriv tydligalänkar.

Skillnad mellan sidtitel och title-attributHtml och xhtml-dokument har ett title-element i sidans head-sektion.

Tänk på att inte blanda ihop title-elementet som enbart förekommer en

gång per sida med title-attribut som kan förekomma på flera ställen.

Title-element bör alltid finnas, men title-attribut är oftast mest till

besvär, förutom när de till exempel används för att förklara förkortningar, ikombination med abbr-elementet.

Skillnad mellan sidtitel och sidrubrikEn webbsida har bara en titel, men kan ha många rubriker på olika nivå.Sidtiteln visas framförallt utanför dokumentet, till exempel iwebbläsarfönstrets ram, medan sidans rubriker presenteras inutidokumentet som en del av layouten. (Se R105. Skapa rubriker med h-element.) För rubriker finns inte samma behov att ange avsändaresammanhang som för sidtitel, eftersom denna information oftast framgår påannat sätt i dokumentet.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.2 Sidans titel: Webbsidor har titlar som beskriver ämne ellersyfte. (Nivå A)

Senast uppdaterad: 2018-12-05

Prio 1

Gör en logisk tab-ordningTesta tab-ordningen genom att granska en sida av varje sidtyp utan hjälp avtryckkänslig skärm, mus eller annat pekdon.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Testning

Vissa användare navigerar med hjälp av tangentbord eller andrainmatningsenheter som i turordning kan flytta fokus mellan sidans olika

Riktlinje nr 136

Vägledning förWebbutveckling Sida 272 /

316

Page 274: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

element (snarare än direkt via koordinater som till exempel mus ellerpekskärm). Det vanligaste är att tab-tangenten används, men i vissa fallanvänds även andra tangenter, till exempel pilar.Del av tangentbord

Bild av tab-tangent (cc-by Kai Hendry)

För dessa användare är det viktigt att fokus-ordningen är logisk i förhållandetill hur innehållet presenteras på skärm eller i skärmläsare. Om fokus flyttartill ett oväntat element kan det vara mycket förvirrande, och orsaka fel.

Antalet missförstånd kan minska något om fokus framhävs visuellt (seR140. Markera tydligt vilket fält eller element som är i fokus). Men dettahjälper inte personer som är beroende av skärmläsare, eller av kraftigförstoring. Och även personer som tydligt kan se vilket element som är ifokus kan få svårt att hänga med om fokus hoppar hit och dit på sidan.

Oftast följer fokusordningen den ordning som innehållet har i html-koden,men det är inte alltid den ordningen överensstämmer med presentationen(Se R122. Presentera innehållet i en meningsfull ordning för alla).

Rekommendationer för tab-ordningKontrollera ordningen utan pekdon.Säkerställ en logisk ordning med tabindex.

Kontrollera ordningen utan pekdon

Testa tab-ordningen genom att granska en sida av varje sidtyp utan hjälp avtryckkänslig skärm, mus eller annat pekdon. Både visuell presentation ochskärmläsarpresentation bör testas, eftersom ordningen kan skilja sig åt.

Säkerställ en logisk ordning med tabindex

Justera ordningen med hjälp av html-attributet tabindex. Det kan anges ihtml-kod eller ändras dynamiskt med javascript. De presenteras i följandeordning för användaren:

1. Element med tabindex 1, 2, 3 och så vidare i nummerordning. (Om tvåelement har samma tabindex presenteras de i den ordning deförekommer i koden.)

2. Element som saknar tabindex eller har tabindex 0. Dessa presenterasi den ordning de förekommer i koden. Om användaren därefterfortsätter hamnar fokus återigen på det element som ligger allra först ifokusordningen.

3. Element med negativt värde på tabindex plockas bort frånfokusordningen. Dit kan användaren alltså inte navigera.

Tangentbordsnavigation i dialogrutor

Vägledning förWebbutveckling Sida 273 /

316

Page 275: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När en så kallad modal dialogruta visas bör fokusordningen enbart innehållade element som ingår i dialogrutan. När dialogen stängs bör fokus återgå tillnärmast efterföljande element eller till det element användaren hade i fokusinnan dialogrutan öppnades.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.3 Fokusordning: Om man kan navigera stegvis på enwebbsida och navigeringsordningen påverkar betydelse elleranvändning, så ska fokuserbara komponenter få fokus i enordning som bevarar betydelse och användning. (Nivå A)

Relaterade riktlinjerR129. Utveckla systemet så att det går att hantera med enbarttangentbordetR143. Utför inga oväntade förändringar vid fokusering

Terminologi

För att den som händelsevis söker efter tabbordning nämner vi denstavningen här, även om vår tolkning av Svenska skrivregler är att tab-ordning är en bättre språklig variant.

Senast uppdaterad: 2018-12-05

Prio 1

Markera tydligt vilket fält eller elementsom är i fokusDen som navigerar med t.ex. tab-tangenten behöver få veta var fokusligger. Standardmarkeringen är ofta en tunn linje som är svår att se.Gör markeringen tydlig, till exempel med en CSS-regel.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Den som navigerar med till exempel tab-tangenten behöver få veta vartangentbordets fokus ligger. Standardmarkeringen är ofta en tunn streckadlinje som är svår att se, särskilt om omgivningen är spräcklig eller på annat

Riktlinje nr 140

Vägledning förWebbutveckling Sida 274 /

316

Page 276: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

sätt gör den streckade linjen mindre uppenbar.

I bilden ovan visas hur ramar och färger kan användas för att markera vilketelement som är i fokus.

Gör markeringen tydlig, till exempel med en CSS-regel.

Rekommendation för markering av fokusAnvänd CSS för att tydligt visa vilket element som är i fokus.

Använd CSS för att tydligt visa vilket element somär i fokusOftast räcker det med en enkel css-regel för att markera vilket element somär i fokus. Följande regel ger till exempel en gul bakgrundsfärg och enkraftig svart ram runt länkar och inmatningsfält som är i fokus:

a:focus, input:focus border: solid black 3px;

background-color:#ffff07;

Jämför detta med standardmarkeringen i webbläsaren (i detta fall InternetExplorer 11):

Ibland kan det passa bättre att använda javascript eller någon annan teknikför att åstadkomma en bra presentation.

Givetvis behöver den visuella presentationen även anpassas till omgivandeformgivning.

Utdrag från WCAG-standarden

Riktlinje 2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarnaatt navigera, hitta innehåll och avgöra var de är.

2.4.7 Synligt fokus: Användargränssnitt som styrs viatangentbord har ett sätt att visa var fokus är vid

Vägledning förWebbutveckling Sida 275 /

316

Page 277: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

tangentbordsnavigering. (Nivå AA)

Relaterade riktlinjerR34. Gör länkar, klickbara ytor och menyer användbara för allaR129. Utveckla systemet så att det går att hantera med enbarttangentbordetR136. Gör en logisk tab-ordningR143. Utför inga oväntade förändringar vid fokusering

Senast uppdaterad: 2018-11-30

Prio 1

Ange sidans språk i kodenFör att öka sannolikheten att till exempel skärmläsare presenterar innehålletkorrekt bör html-koden ange aktuellt språk med hjälp av lang-attribut.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Systemutveckling

För att till exempel underlätta korrekt avstavning, automatisk översättningoch förbättra möjligheten för skärmläsare att presentera innehållet korrekt,ska aktuellt språk anges i html-koden. Detta görs med hjälp av lang-attribut

och språkkod.

Rekommendationer för språkangivelser i kodAnge huvudspråk med hjälp av lang-attribut på sidans rot-element.

Ange huvudspråk med hjälp av lang-attribut påsidans rot-element.Sidans huvudspråk (som används i menyer, sidhuvud med mera) bör angesmed hjälp av lang-attributet i sidans rot-element (html). För svenska kan

koden se ut så här:

<html lang=”sv”>

Om innehållet på en sida är skrivet på flera språk bör lang-attribut

användas för att märka ut de avsnitt som är på andra språk, se R142 Angespråkförändringar i koden.

Riktlinje nr 141

Vägledning förWebbutveckling Sida 276 /

316

Page 278: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Här hittar du rätt språkkod

Svenska har koden ”sv” (eller möjligen ”sv-FI” för finlandssvenska).

Engelska har koden ”en” (eller ”en-GB”/”en-US” och så vidare för den som

vill precisera dialekt/variant).

Den fullständiga listan med språkkoder är aningen svårläst, men det finnsen sökfunktion för språkkoder.

Koder för de svenska minoritetsspråken finns i R14. Ge information på desvenska minoritetsspråken.

Om språket läses från höger till vänster kan det vara nödvändigt att ävenange språkriktning och högerjustering i kod. Läs mer om språkriktning iAnpassa webbplatsen för flerspråkighet (R17).

Utdrag från WCAG-standarden

Riktlinje 3.1 Läsbart: Gör textinnehåll läsbart och begripligt.

3.1.1 Sidans språk: Det huvudsakliga mänskliga språket på varjewebbsida kan tydliggöras automatiskt. (Nivå A)

Fördjupning och relaterade riktlinjerLäs även om andra fördelar med att ange språkkod.

R17. Anpassa webbplatsen för flerspråkighet.

Senast uppdaterad: 2018-12-05

Prio 1

Ange språkförändringar i kodenFör att öka sannolikheten att till exempel skärmläsare presenterar innehålletkorrekt bör html-koden ange aktuellt språk med hjälp av lang-attribut.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: Skriva texter, TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion

För att öka sannolikheten att till exempel skärmläsare presenterar innehålletkorrekt bör html-koden ange aktuellt språk med hjälp av lang-attribut och

Riktlinje nr 142

Vägledning förWebbutveckling Sida 277 /

316

Page 279: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

språkkod. Det finns även andra fördelar med att ange språkkod. Till exempelunderlättas korrekt avstavning och automatisk översättning.

Om det finns innehåll på sidan som har ett annat språk än sidanshuvudsakliga språk bör element som omsluter detta innehåll förses medlang-attribut. Koden kan till exempel se ut så här:

<div lang=”en”>Translation in English</div>

Riktlinjen R141. Ange sidans språk i koden har nästan samma innebörd,men den gäller inte förändringar inom sidan/skärmen/appen utan sidanshuvudsakliga språk. I praktiken innebär detta att den riktlinje du just nu läserfrämst berör redaktörer medan riktlinje 141 vänder sig mer till utvecklare.

Rekommendationer för innehåll på annat språk änomgivande innehåll

Ange aktuellt språk med lang-attribut på omslutande element när är

språket i ett element är ett annat än sidans huvudspråk.

Här hittar du rätt språkkod

Svenska har koden sv (med alternativet sv-FI för finlandssvenska).

Engelska har koden en (eller en-GB/en-US och så vidare för den som vill

precisera variant).

Den fullständiga listan med språkkoder från Iana (den officiellaregisterorganisation som html-standarden hänvisar till) är aningen svårläst,men det finns en sökfunktion för språkkoder på Github som kan underlätta.

Koder för de svenska minoritetsspråken finns i R14. Ge information på desvenska minoritetsspråken.

Om språket läses från höger till vänster kan det vara nödvändigt att ävenange språkriktning och högerjustering i kod. Läs mer om språkriktning iAnpassa webbplatsen för flerspråkighet (R17).

Utdrag från WCAG-standarden

Riktlinje 3.1 Läsbart: Gör textinnehåll läsbart och begripligt.

3.1.2 Språk för del av sida: Det mänskliga språket för varjeavsnitt eller fras i innehållet kan automatiskt tydliggöras utom föregennamn, tekniska termer, ord av obestämbart språk och ordeller fraser som blivit en naturlig del av språket i den omgivandetexten. (Nivå AA)

Relaterade riktlinjer

Vägledning förWebbutveckling Sida 278 /

316

Page 280: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R17. Anpassa webbplatsen för flerspråkighet.

Senast uppdaterad: 2018-12-05

Prio 1

Utför inga oväntade förändringar vidfokuseringUtför ändringar när användaren har anledning att förvänta sig dem.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Prototypning

När ett inmatningsfält, en länk eller annan komponent hamnar i fokus, tillexempel för att användaren tabbat till den eller klickat på den så uppstår detsom på programmeringsspråk kallas för ett event (en programhändelse). Ettevent kan kopplas till olika åtgärder, såsom att komponentens bakgrund fåren annan färg eller att en hjälptext visas. Men det kan också kopplas till meroväntade förändringar, såsom att ett nytt fönster öppnas, att fokusautomatiskt förflyttas någon annanstans, eller att ett formulär skickas in.

Sådana oväntade förändringar av sammanhanget kan orsaka problem föranvändare som inte är förberedda på dem och bör därför undvikas. Utförändringar bara när användaren förväntar sig att dessa ska ske.

Rekommendationer för att inte förvirra användarevid fokusering

Utför bara förändringar (till exempel öppning av fönster eller förändringav värde) när användaren förväntar sig dem.

Utdrag från WCAG-standarden

Riktlinje 3.2 Förutsägbart: Säkerställ att webbsidor presenterasoch fungerar på ett förutsägbart sätt.

3.2.1 Vid fokus: Att en komponent får fokus leder inte till enförändring av sammanhanget. (Nivå A)

Relaterade riktlinjerR129. Utveckla systemet så att det går att hantera med enbarttangentbordetR136. Gör en logisk tab-ordning

Riktlinje nr 143

Vägledning förWebbutveckling Sida 279 /

316

Page 281: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R140. Markera tydligt vilket fält eller element som är i fokusR144. Utför inga oväntade förändringar vid inmatning

Senast uppdaterad: 2018-12-05

Prio 1

Utför inga oväntade förändringar vidinmatningUtför ändringar när användaren har anledning att förvänta sig dem.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

När användaren till exempel redigerar text i ett formulärfält, markerar enkryssruta eller ändrar värde i en flervalsmeny så uppstår det som påprogrammeringsspråk kallas för ett event (en programhändelse). Ett eventkan kopplas till olika åtgärder, såsom att komponentens bakgrund får enannan färg eller att en hjälptext visas. Men det kan också kopplas till meroväntade förändringar, såsom att ett nytt fönster öppnas, att fokusautomatiskt förflyttas någon annanstans, eller att ett formulär skickas in.

Sådana oväntade förändringar av sammanhanget kan orsaka problem föranvändare som inte är förberedda på dem och bör därför undvikas. Utförändringar när användaren har anledning att förvänta sig dem. Ett sätt attgöra ändringen förväntad är att informera om den i förväg.

Rekommendationer för att inte förvirra användarevid fokusering

Utför bara förändringar (till exempel öppning av fönster eller förändringav värde) när användaren har anledning att förvänta sig dem.

Utdrag från WCAG-standarden

Riktlinje 3.2 Förutsägbart: Säkerställ att webbsidor presenterasoch fungerar på ett förutsägbart sätt.

3.2.2 Vid inmatning: Att ändra inställningarna för en komponent iett användargränssnitt orsakar inte automatiskt en förändring avsammanhanget, om inte användaren förvarnats om detta innankomponenten används. (Nivå A)

Riktlinje nr 144

Vägledning förWebbutveckling Sida 280 /

316

Page 282: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Relaterade riktlinjerR143. Utför inga oväntade förändringar vid fokusering

Senast uppdaterad: 2018-12-05

Prio 1

Benämn funktioner konsekventKonsekvent benämning av saker på hela webbplatsen underlättar för allaanvändare att känna igen sig och minskar onödig kognitiv belastning.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Var konsekvent när du beskriver och namnger samma funktionalitet på olikasidor och skärmar. Det innebär till exempel att rubriker, etiketter, ikoner ochalternativtexter som ska beskriva en skicka-knapp ska heta samma sak påhela webbplatsen. Inte Skicka på en sida och Sänd på en annan sida. Elleratt en spara-ikon ska se likadan ut på hela webbplatsen.

Kanske räcker det med layout och formgivning för att seende användare skakänna igen identiska eller snarlika funktioner som finns på flera sidor ochdärmed kunna förutse hur de fungerar. Men för den som inte ser är detviktigt att de även benämns konsekvent.

Rekommendationer för enhetlig benämning avfunktioner

Använd samma termer för återkommande funktioner såsom knapparoch ikoner, eftersom vissa användare saknar till exempel layout ochformgivning som annars kan användas för orientering.

Utdrag från WCAG-standarden

Riktlinje 3.2 Förutsägbart: Säkerställ att webbsidor presenterasoch fungerar på ett förutsägbart sätt.

3.2.4 Konsekvent identifiering: Komponenter som har sammafunktionalitet inom en uppsättning av webbsidor identifieraskonsekvent. (Nivå AA)

Relaterade riktlinjerR64. Skriv lättbegripliga texter

Riktlinje nr 146

Vägledning förWebbutveckling Sida 281 /

316

Page 283: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

R29. Var konsekvent i navigation, struktur och utformningR66. Skriv datum och andra sifferuppgifter konsekvent

Senast uppdaterad: 2018-12-05

Prio 1

Ge förslag på hur fel kan rättas tillNär fel upptäcks automatiskt bör förslag på korrekt inmatning presenterasför användaren om det är möjligt.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Hjälp användaren att undvika misstag, men försök också att hjälpaanvändaren att rätta till misstag när ett inmatningsfel upptäcks. Det kan dugöra genom att ge exempel på inmatning som har det förväntade formatet ifelmeddelandet, eller genom att föreslå en annan stavning som liknar detsom användaren angivit.

Rekommendationer för korrigeringsförslagR52. Fyll formulär med kända uppgifterR57. Låt användarna fylla i information i valfritt formatR101. Markera obligatoriska fält i formulärR112. Ge ordförslag i sökning och inmatningsfält

Utdrag från WCAG-standarden

Riktlinje 3.3 Inmatningsstöd: Hjälp användare att undvikamisstag och rätta till misstag.

3.3.3 Förslag vid felhantering: Om ett inmatningsfel upptäcksautomatiskt och det finns kända korrigeringsförslag så gesförslagen till användaren, utom om det skulle äventyrasäkerheten eller syftet med innehållet. (Nivå AA)

Relaterade riktlinjerR2. Visa var ett fel uppstått och beskriv det tydligtR50. Minimera antalet fält i formulärR61. Skriv beskrivande rubriker och etiketterR150. Ge möjlighet att ångra, korrigera eller bekräfta vid viktigatransaktioner

Riktlinje nr 149

Vägledning förWebbutveckling Sida 282 /

316

Page 284: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-12-05

Prio 1

Ge möjlighet att ångra, korrigera ellerbekräfta vid viktiga transaktionerDen som råkar göra något fel kan slippa mycket besvär om felet kanupptäckas och åtgärdas direkt.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Prototypning

Alla kan göra fel, och för den som har till exempel läs- och skrivsvårighetereller motoriska nedsättningar kan risken för felregistreringar i formulär varastörre än för andra. Vid viktiga transaktioner som till exempel gäller juridik,ekonomi eller hälsa kan konsekvenserna av fel bli stora och besvärliga föralla inblandade. Därför behöver system som används för viktigatransaktioner hjälpa användare att undvika och rätta till misstag.

Rekommendation för att undvika fel i viktigatransaktionerErbjud 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 felinnan åtgärden slutligen bekräftas.

Utdrag från WCAG-standarden

Riktlinje 3.3 Inmatningsstöd: Hjälp användare att undvikamisstag och rätta till misstag.

Riktlinje 3.3.4 Förebyggande av fel (juridiskt, ekonomiskt, data):För webbsidor som leder till att användare ingår rättsligaåtaganden eller utför ekonomiska transaktioner, eller som ändrareller raderar användarstyrd data i datalagringssystem eller taremot användarens provsvar, så ska minst en av följande punktergälla: (Nivå AA)

1. Möjlig att ångra: Åtgärder kan ångras.2. Kontrollerad: Data som matats in av användaren

kontrolleras, och om inmatningsfel hittas ges användaren

Riktlinje nr 150

Vägledning förWebbutveckling Sida 283 /

316

Page 285: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

möjlighet att rätta till dem.3. Bekräftad: Det finns en metod/funktion för att

förhandsgranska, bekräfta och rätta till information innanåtgärden slutförs.

Exempel

Bilden visar exempel på hur Skatteverket ger användaren möjlighet attångra en åtgärd, i det här fallet när användaren har klickat på Logga ut-knappen.

Relaterade riktlinjer

Det finns ganska många riktlinjer som handlar om formulär och felhantering.Se särskilt Visa var ett fel uppstått och beskriv det tydligt (R2)

Senast uppdaterad: 2018-03-09

Prio 1

Se till att skräddarsydda komponenterfungerar i hjälpmedelMånga användare behöver hjälpmedel såsom skärmläsarprogram,förstoringsprogram punktdisplay med mera. Dessa hjälpmedelkommunicerar med operativsystemets tillgänglighets-API. För att det skafungera behöver varje del av en webbsida eller applikation vid varje tillfälleexponera sitt namn, sin roll och sitt aktuella värde. Då kan hjälpmedletpresentera applikationen på ett korrekt sätt för användaren. En skärmläsarebehöver […]

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: Tillgänglighet

Riktlinje nr 152

Vägledning förWebbutveckling Sida 284 /

316

Page 286: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

När i utvecklingsprocessen?:

Många användare behöver hjälpmedel såsom skärmläsarprogram,förstoringsprogram punktdisplay med mera. Dessa hjälpmedelkommunicerar med operativsystemets tillgänglighets-API. För att det skafungera behöver varje del av en webbsida eller applikation vid varje tillfälleexponera sitt namn, sin roll och sitt aktuella värde. Då kan hjälpmedletpresentera applikationen på ett korrekt sätt för användaren. En skärmläsarebehöver till exempel kunna berätta för användaren när förändringar avsidans innehåll sker.

Rekommendationer för skräddarsyddakomponenter

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 ochtillräckliga resurser för test och utveckling bör skräddarsyddakomponenter utvecklas.Vid val av tilläggsprogram eller kodplattformar (till exempel olikajavascript-bibliotek) behöver ni undersöka om eventuella komponentersom bygger på dessa plattformar har ett bra stöd för tillgänglighet.

Utdrag från WCAG-standarden

Riktlinje 4.1 Kompatibelt: Maximera kompatibiliteten mednuvarande och framtida användarprogram, inklusive hjälpmedel.

4.1.2 Namn, roll, värde: För alla komponenter i ettanvändargränssnitt (inklusive, men inte begränsat tillformulärelement, länkar och komponenter skapade med script),kan namnet och rollen automatiskt tydliggöras. Status,egenskaper och värden som kan anges av användaren kan bliautomatiskt tydliggjord, och meddelande om ändringar i dessakomponenter finns åtkomliga för användarprogram, inklusivehjälpmedel. (Nivå A)

Anmärkning: Detta framgångskriterium är främst till förutvecklare som utvecklar egna komponenter eller skapar egnascript för komponenterna i användargränssnittet. Exempelvisuppfyller redan standardkontroller i HTML dettaframgångskriterium när de används enligt specifikation.

ReferenserSe även R80 Följ standarder och R58 Använd standardutseendet påformulärens element.

Terminologi

Vägledning förWebbutveckling Sida 285 /

316

Page 287: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Hjälpmedel kallas på engelska för assistive technologies.

Senast uppdaterad: 2018-12-05

Prio 1

Se till att allt innehåll presenteras rättoavsett skärmens riktningAlla människor har inte möjlighet att vrida på sin skärm. Vissa måste väljaett läge (stående eller liggande) och alltid använda detta, exempelvis medskärmen fast monterad på en rullstol. Skapa därför en design så att innehålloch funktioner är tillgängliga oavsett skärmens riktning. Då kan var och envälja det läge de föredrar.

Det finns inget som hindrar att presentationen av innehållet och funktionernaskiljer sig åt mellan de båda lägena så länge innehållet är tillgängligt ochfunktionerna är åtkomliga och har normal funktion.

I riktlinjen finns undantag för när funktionaliteten är beroende av attanvändaren har skärmen i en viss riktning, till exempel ett pianoprogram därliggande läge är nödvändigt för att alla tangenterna ska få plats. Informeraanvändaren om när en viss riktning av skärmen är nödvändigt.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Testning

Rekommendationer för design oberoende avskärmens riktning

Riktlinje nr 153

Vägledning förWebbutveckling Sida 286 /

316

Page 288: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

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

Lösningar för flexibel skärmriktningPresentationen kan fås att fungera oavsett skärmriktning antingen genomatt en och samma uppsättning css-regler passar för båda ledderna ellergenom att det finns olika css-regler anpassade för olika ledder, och deskärmbredder som kan bli aktuella. Det är till exempel viktigt att allfunktionalitet går att komma åt på något sätt oavsett skärmriktning i enwebbapplikation som inte ska scrollas.

Utdrag från WCAG-standarden

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kanpresenteras på olika sätt (exempelvis med enklare layout) utanatt information eller struktur går förlorad.

1.3.4 Orientation: Content does not restrict its view and operationto a single display orientation, such as portrait or landscape,unless a specific display orientation is essential. (Nivå AA)

Exempel

Skatteverkets e-tjänst Anmäl flyttning inom Sverige kan användas i bådeliggande och stående läge.

Skärmbild av Skatteverkets e-tjänst i liggande läge

FördjupningErbjud alternativ till rörelsestyrning (R163)Anpassa webbplatsen även för små skärmar (R111)Skapa en flexibel layout (R91)

MätbarhetKontrollera att innehåll och funktioner är tillgängliga och fungerar näranvändaren håller skärmen i både stående och liggande läge.

TerminologiStående skärm kallas ofta för porträttläge (portrait mode) medan liggandeskärm kallas landskapsläge (landscape mode).

Vägledning förWebbutveckling Sida 287 /

316

Page 289: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Senast uppdaterad: 2018-11-28

Prio 1

Märk upp vanliga formulärfält i kodenHjälp dina användare att fylla i inmatningsfält genom att i koden ange vilkentyp av innehåll som förväntas. Då kan webbläsare eller hjälpmedel iblandautomatiskt föreslå inmatning (baserat på till exempel tidigare inmatning ifält av samma typ) i vanliga formulärfält (såsom gatu- och postadress).Systemet kan också ytterligare hjälpa användaren genom att presenterafältet på ett sätt (till exempel med en symbol) som användaren känner igen.

Det är bra för alla användare, men kanske framför allt för personer medvissa kognitiva och motoriska funktionsnedsättningar. Det underlättar ocksåför användare som inte behärskar språket så bra.

Om denna riktlinjePrioritet: 1Principer: Effektiv, TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?:

Rekommendationer för uppmärkning avformulärfält

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.

Använd attributet autocomplete på inmatningsfältVissa webbläsare sparar (lokalt) inmatningar som användaren gör iformulärfält. Tack vare detta kan webbläsaren ge förslag på inmatning näranvändaren senare hamnar på inmatningsfält som ser ut att ha sammainnebörd. Google har gjort uppskattningen att användare blir ca 30%snabbare i utcheckning när autocomplete används.

Webbläsare som har autocomplete aktiverat gör sitt bästa för att förslårelevanta inmatningsförslag. De utgår till exempel från att inmatningsfält(input-element) med samma värde på attributen id eller name har samma

typ av innehåll. Men så är inte alltid fallet. Med hjälp av attributetautocomplete kan du som utformar formuläret förbättra möjligheterna för

webbläsaren att ge relevanta förslag.

Beskriv förväntat innehåll med attributet autocomplete, om

Riktlinje nr 154

Vägledning förWebbutveckling Sida 288 /

316

Page 290: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

det finns en standardiserad benämningI HTML5-standarden finns en lista med vanliga ändamål för inmatningsfält.Om ändamålet för ditt inmatningsfält finns med i denna standardlista kan dugenom att använda rätt benämning se till att de förslag som webbläsarenpresenterar för användaren med större sannolikhet är relevanta.

Tanken är att det även ska finnas standardiserade (eller individualiserade)symboler för dessa olika ändamål, som webbläsaren (eventuellt med hjälpav hjälpmedel eller tilläggsprogram) kan presentera för användaren i direktanslutning till inmatningsfältet. Än så länge känner vi dock inte till någonsådan implementation.

Så här skulle ett inmatningsfält för telefonnummer kunna presenteras.

Här är ett utdrag från standardlistan, aningen förenklat och anpassat eftersvenska förhållanden:

Standardiseradbenämning (användssom värde påautocomplete-attribut)

Betydelse Exempel på inmatning

”name” Fullständigt namn Sir Timothy John Berners-Lee, OM,KBE, FRS, FREng, FRSA

Vägledning förWebbutveckling Sida 289 /

316

Page 291: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

”given-name” Förnamn Timothy

”additional-name” Mellannamn John

”family-name” Efternamn Berners-Lee

”nickname” Skärmnamn Tim

”organization-title” Titel Professor

”username” Användarnamn timbl

”new-password”

Nytt lösenord(inmatningsfält däranvändaren skahitta på ettlösenord.)

GUMFXbadyrS3

”current-password” Aktuellt lösenord(vid inloggning) qwerty

”organization” Namn på företageller organisation World Wide Web Consortium

”street-address” Gatuadress (kanha flera rader)

32 Vassar StreetMIT Room 32-G524

”address-level1” Postort MA

”country” Landkod SE

”country-name” Land Sverige

”postal-code” Postnummer 113 00

”cc-name” Namn på kreditkort Tim Berners-Lee

”cc-number” Kreditkortsnummer 4114360123456785

”cc-exp”Giltighetsdatum förkreditkort(Expiration date)

2014-12

”cc-exp-month”Månad i sistagiltighetsdatum förkreditkort

12

”cc-exp-year”Årtal i sistagiltighetsdatum förkreditkort

2014

”cc-csc”Säkerhetskod(CVV) på baksidanav kreditkort

419

”cc-type”Typ av kreditkort(eller annatbetalningsmedel)

Visa

”transaction-currency” Valutakod SEK

”transaction-amount” Penningbelopp 401

”language” Språkkod sv

”bday” Födelsedatum 1955-06-08

”bday-day” Födelsedatum –dag i månaden 8

”bday-month” Födelsedatum –månad 6

Vägledning förWebbutveckling Sida 290 /

316

Page 292: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

”bday-year” Födelseårtal 1955

”sex” Kön Male

”url” Webbadress https://www.w3.org/People/Berners-Lee/

”photo” Foto https://www.w3.org/Press/Stock/Berners-Lee/2001-europaeum-eighth.jpg

<kontaktväg> “tel” Telefonnummer +46 8 678 55 00

<kontaktväg> ”tel-country-code”

Plustecken följt avlandkod itelefonnummer

+46

<kontaktväg> ”tel-national”

Telefonnummerinklusiveriktnummer menutan landkod

08-678 55 00

<kontaktväg> ”email” E-postadress [email protected]

<kontaktväg> ”impp” chat-adress irc://example.org/timbl,isuser

<kontaktväg> betyder att det går att specificera om det gäller hem (“home”),

arbete (“work”), mobiltelefon (“mobile”), fax (“fax”) eller personsökare

(“pager”) genom att inleda autocomplete-attributet med motsvarande kod.

Ange autocomplete=”off” om det gäller känsliginformation eller om servern erbjuder ordförslagDet är olämpligt med inmatningsförslag för inmatningsfält som kan innehållakänslig information. Risken är ju att en person som ser “över axeln” påanvändaren råkar få veta vad användaren tidigare matat in i liknande fält.

Det är onödigt med inmatningsförslag för inmatning som enbart ska görasen gång (till exempel engångskoder för inloggning).

Om webbservern erbjuder förslag på inmatning, baserat på information sominte hämtas från användarens webbläsare utan från en databas (se Geordförslag vid sökning och inmatning (R112)) så är det oftast olämpligt attäven webbläsaren ger ordförslag.

I samtliga dessa fall bör värdet “off” anges i attributet autocomplete.

ExempelGoogle har publicerat en stor formulärsida som använder autocomplete

på nästan alla inmatningsfält. Observera dock att de inte till 100% följerstandarden. Istället för “given-name” används “fname”, och istället för

“family-name” används “lname”. Detta är inte helt ovanligt, av någon

anledning.

Här är exempel på hur det autocomplete kan se ut i kod:

<form >

<input autocomplete="transaction-currency" value="SEK">

Vägledning förWebbutveckling Sida 291 /

316

Page 293: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

<input autocomplete="transaction-amount" value="15.00">

<p><label>Kreditkortsnummer:

<input type="text" autocomplete="cc-number"></label>

<p><label>Kortet giltigt till:

<input type="month" autocomplete="cc-exp"></label>

<p><input type="submit" value="Fortsätt...">

</form>

Utdrag från WCAG-standarden

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kanpresenteras på olika sätt (exempelvis med enklare layout) utanatt information eller struktur går förlorad.

1.3.5 Identify Input Purpose The purpose of each input fieldcollecting information about the user can be programmaticallydetermined when:

The input field serves a purpose identified in the InputPurposes for User Interface Components section; andThe content is implemented using technologies withsupport for identifying the expected meaning for form inputdata.

(Nivå AA)

Relaterade riktlinjerFyll formulär med kända uppgifter (R52)Ge ordförslag vid sökning och inmatning (R112)

TerminologiPrediktiv textinmatning eller autocomplete på engelska innebär att systemeteller webbsidan baserat på pågående textinmatning kan komma medförslag på fortsättning av inmatningen.

I Skatteverkets tjänst flyttanmälan används autocomplete för att föreslå

Vägledning förWebbutveckling Sida 292 /

316

Page 294: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

bland annat gatuadress.

Detta underlättar för den som ska fylla i till exempel sökrutor eller formulär.Funktionen är vanlig och hjälpsam i sökfunktioner där den ger användarenordförslag vid inmatningen R112.

Senast uppdaterad: 2018-11-28

Prio 1

Använd tillräckliga kontraster ikomponenter och grafikPersoner med nedsatt syn har ofta svårt att urskilja visuella kontrastermellan exempelvis en symbol och dess bakgrund, och riskerar därför attmissa information. Designa därför webbplatsen så att komponenter igränssnittet och informationsbärande grafik har tillräckliga kontraster. Somkomponenter räknas till exempel knappar och formulärfält. Som grafiskaobjekt räknas exempelvis ikoner och betydelsefulla delar av illustrationeroch diagram (till exempel kurvor och pilar).

Denna riktlinje liknar Använd tillräcklig kontrast mellan text och bakgrund(R126) (som motsvarar WCAG-kriteriet 1.4.3). Men nu gäller alltsåmotsvarande krav även för innehåll som inte är text.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Innehållsproduktion, Interaktionsdesign

Rekommendationer för kontraster i innehåll sominte är text

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 illustrationeroch annat grafiskt innehåll, så långt det är rimligt.

Ge gränssnittskomponenter tydliga visuellagränserInmatningsfält, knappar och andra komponenter ska ha tydliga visuellagränser med tillräckliga kontraster mot den intilliggande bakgrunden. Dettagäller oavsett om de är skräddarsydda eller skapade med standardelement ihtml.

Kontrastvärdet ska vara minst 3:1.

Riktlinje nr 156

Vägledning förWebbutveckling Sida 293 /

316

Page 295: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om ni använder dynamiska visuella effekter, till exempel för att visa vilketelement som är i fokus, ska även dessa ha tillräckliga kontraster.

Gör helst även inaktiva element urskiljbara för allaKraven i WCAG 2.1 på tillräckliga kontrastvärden gäller inte för inaktivakomponenter och element, alltså sådana som ibland är “utgråade” för attsignalera att de för närvarande inte kan användas. Det kan till exempel gällaen skicka-knapp som inte kan aktiveras förrän ett formulär är ifyllt, ellerfunktionalitet som enbart erbjuds i en dyrare version av en tjänst.

Ibland, till exempel efter en avvägning mellan olika behov av tillgänglighet,kan det vara nödvändigt att använda detta undantag från kontrastkraven:Genom att framhäva vissa och tona ner andra element under olika delar aven process, men alltid låta elementen finnas på samma plats, går det tillexempel att öka igenkänning och därmed kognitiv tillgänglighet. Ettgränssnitt med många komponenter kan vara svårt att använda om inaktivadelar är lika framträdande som aktiva.

Men i enlighet med principen om universell utformning rekommenderar vi attså långt som möjligt även användare med nedsatt syn ska kunna urskiljaoch förstå de element som förekommer i gränssnittet. Indikera därför helstatt ett element är inaktivt på något annat sätt än med dålig kontrast. Tillexempel kan en “utgråad” känsla uppnås även med godtagbara kontraster,ett felmeddelande kan användas för att ge bra information, och det går ävenatt lägga till text eller grafik som visar att ett element är inaktivt.

Några exempelHär är några exempel kodade med html. Deras utförande varierar någotberoende på din plattform. Vilken lösning passar dig?Flera bra bildexempel finns på W3Cs sida om motsvarande kriterium iWCAG.

Inaktiva knappar

Standardutförande.

Dålig kontrast.

Bättre kontrast tack vare CSS-regel.

Text visar att den inte är aktiv.

Pedagogiskt felmeddelande. (Klicka på knappen för att visameddelandet.)

Aktiv knapp, somjämförelse

Använd god kontrast för informationsbärande delarav illustrationer och annat grafiskt innehåll

Vägledning förWebbutveckling Sida 294 /

316

Page 296: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Förutom att interaktiva komponenter behöver vara urskiljbara är det viktigtatt alla användare kan uppfatta budskap som kommuniceras genom ikoner,diagram, flödesscheman, kartor, infografik och andra bilder.

WCAG-kravet på tillräckliga kontraster (3:1) gäller därför, med någraundantag, även för de grafiska objekt som är informationsbärande. Tillexempel symboler, pilar och linjer i en graf. När det gäller enklare grafiksåsom enfärgade ikoner, räknas hela ikonen som ett grafiskt objekt. Grafiksom består av flera linjer, färger och former räknas som flera grafiskaobjekt. Se exempel nedan:

Telefonikonen är en enkel ikon som ligger inuti encirkel. I det här fallet räknas enbart telefonen som grafiskt element eftersomanvändaren kan tolka ikonen utan ringen. Kraven på kontrast gäller endasttelefonen mot den blå bakgrunden. Cirkelns kontraster mot bakgrunden ärinte relevanta i detta fall.

Symbolen för fallande eurokurs kan förstås genomatt tolka nedåtpilen och valutasymbolen för euro. I detta fall behöver detvara tillräckliga kontrastvärden mellan själva pilformen mot den blåbakgrunden och eurosymbolen mot den vita bakgrunden. De grafiskaobjekten är pilformen och eurosymbolen.

I ett diagram behöver användaren kunna skilja på själva linjerna ochpunkterna som markerar ett värde. Av den anledningen är varje linje ochpunkt ett grafiskt objekt och behöver ha ett kontrastvärde på 3:1 motbakgrunden. I exemplet nedan har alla linjer och punkter godtagbarakontraster förutom den heldragna. Om överlappet mellan kurvorna är litet,som i detta fall, är det inte nödvändigt med kontraster färgerna emellan.

För att förstå ett tårtdiagram behöver användaren skilja ut de olikatårtbitarna från varandra. Varje tårtbit i diagrammet är ett grafiskt element isig. När du skapar ett tårtdiagram kan du behöva ta hänsyn både tillkontrasten mellan eventuell text och bakgrunden och till kontrasten mellande olika tårtbitarna. Ett sätt att säkerställa tillräcklig kontrast mellantårtbitarna är att använda en skiljelinje eller mellanrum.

Vägledning förWebbutveckling Sida 295 /

316

Page 297: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Vilka grafiska objekt är undantagna riktlinjen?

En helt svartvit eller “monokrom” webb har förstås utmärkta kontrastvärden,men bara i sällsynta fall är det funktionellt och estetiskt önskvärt. Vi behövernyanserna, även om det finns personer som på grund av exempelvissynskada, dåliga ljusförhållanden eller begränsningar i utrustning harnedsatt förmåga att urskilja alla kontraster. Därför finns det ett antalundantag från kontrastkraven avseende grafiska objekt:

När grafiken endast tillför ett estetiskt värde som inte behöver förståseller uppfattas av användaren.När informationen är tillgänglig i någon annan form, till exempel i texteller tabell i anslutning till grafiken.När objektet är en del av en logotyp eller ett varumärke.När grafiken kan förlora sin innebörd om färgerna ändras. Detta gällertill exempel flaggor eller fotografier av människor eller naturen.Framställningar med syfte att visa hur någonting faktiskt ser ut, somblir missvisande om färgerna förändras. Till exempel skärmdumparoch medicinska diagram som använder färgskalor som finns i naturen.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.11 Non-text Contrast The Visual presentation of the followinghave a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components: Visual information used toindicate states and boundaries of user interfacecomponents, except for inactive components or where theappearance of the component is determined by the useragent and not modified by the author;Graphical Objects: Parts of graphics required to

Vägledning förWebbutveckling Sida 296 /

316

Page 298: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

understand the content, except when a particularpresentation of graphics is essential to the informationbeing conveyed.

(Nivå AA)

Fördjupning och relaterade riktlinjerBlogginlägg om kontraster i inaktiva element.Utkast till presentation om tillgängliga kartor, tabeller och diagram (pdf,0,8 MB).

Beskriv med text allt innehåll som inte är text (R115) (motsvararWCAG-kriterium 1.1.1)Använd tillräcklig kontrast mellan text och bakgrund (R126) (motsvararWCAG-kriterium 1.4.3)Använd inte enbart färg för att förmedla information (R124) (motsvararWCAG-kriterium 1.4.1)Använd text, inte bilder, för att visa text (R128) (motsvarar WCAG-kriterium 1.4.5)

MätbarhetFundera på vilka delar av varje ikon, diagram, illustration och bild sombehöver uppfattas för att kunna förstå budskapet. Se till att dessa delar hartillräcklig kontrast mot intilliggande färger.

Tips på verktyg för mätning av kontraster.

TerminologiI det relevanta WCAG-kriteriet 1.4.11 används termen grafiskt objekt(graphical object) på det sätt som beskrivs ovan, alltså för betydelsebärandedelar av bilder och diagram. I andra sammanhang förekommer det atttermen “grafiskt element” används med samma innebörd. Ordet “element”har dock en specifik innebörd i uppmärkningsspråk som HTML, och därförhar vi valt att inte använda det för något annat här.

Infografik (eng. infographics) kallas en visualisering framtagen med syfte attdet ska gå snabbt och enkelt att få en förståelse och överblick avinformation. Sveriges kommunikatörer har publicerat en infografik ominfografik, med en sammanfattande text på svenska för den som inte kanuppfatta eller förstå bildinnehållet.

Senast uppdaterad: 2019-02-25

Prio 1

Riktlinje nr 157

Vägledning förWebbutveckling Sida 297 /

316

Page 299: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se till att det går att öka avståndmellan tecken, rader, stycken och ordMånga användare, till exempel dyslektiker och personer med nedsatt syn,behöver kunna påverka avståndet mellan stycken, rader, ord och tecken föratt lättare kunna läsa. Gör det därför möjligt för användaren att påverkaavstånden utan att innehåll eller funktionalitet krockar eller gömmer sigbakom annat innehåll.

Denna riktlinje är närliggande riktlinjen Se till att text går att förstora utanproblem (R127) men gäller alltså mellanrummen och inte själva tecknen.

Användaren ska ha möjlighet att öka avstånd åtminstone upp till följanderelativa gränsvärden:

Radavstånd ska kunna ökas minst 1,5 gånger teckensnittets storlek.Teckenavstånd ska kunna ökas minst 0,12 gånger teckensnittetsstorlek.Avståndet mellan ord ska kunna ökas minst 0,16 gångerteckensnittets storlek.Avståndet mellan stycken ska kunna ökas minst 2 gångerteckensnittets storlek.

Förstoring av mellanrum kan ske på olika sätt. Till exempel med hjälp av enbookmarklet som ökar avstånden, med ett förstoringshjälpmedel ellergenom att ställa in webbläsaren att tillämpa användarens egen css-kod.

Riktlinjen gäller inte för öppna undertexter i video och inte heller för text somförekommer i bilder (vilket i och för sig ofta bör undvikas, se Använd text,inte bilder, för att visa text (R128)). För närvarande är även PDFundantaget.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Rekommendationer för anpassningsbaramellanrum i text

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

Placera text i utrymmen som är tillräckligt storaeller som anpassar sig efter innehållet

Vägledning förWebbutveckling Sida 298 /

316

Page 300: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Placera text i ett utrymme (container) som har tillräcklig marginal för atttexten ska kunna förstoras så mycket som riktlinjen kräver, eller i ettutrymme vars storlek anpassas i förhållande till textstorleken exempelvismed hjälp av den relativa enheten em. Läs mer om flexibel layout i Skapa en

flexibel layout (R91) och mer om enheten em i Ge webbplatsen en godläsbarhet (R39).

Tänk på konsekvenserna av ändrade avstånd itext

Här nedan följer några exempel på hur det kan se ut om man inte tarhänsyn till riktlinjen, utan innehåll eller funktioner krockar när användarenpåverkar avstånden i texten.

Innehåll kan döljasDetta inträffar ofta om texten är placerad i en omgivning som inte tar hänsyntill att texten kan behöva mer utrymme. Det kan gälla både i höjd- ochsidled.

Innehåll kan krockaDetta är i princip samma fenomen som ovan, med den enda skillnaden atttexten krockar med innehåll som är delvis transparent, vilket gör att den intedöljs helt.

Ibland är avstånden omöjliga att påverkaDetta kan ibland inträffa om textegenskaperna kontrolleras med absolutamått, i värsta fall med css-regler märkta !important.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.12 Text Spacing In content implemented using markuplanguages that support the following text style properties, no lossof content or functionality occurs by setting all of the followingand by changing no other style property:

Line height (line spacing) to at least 1.5 times the font size;

Vägledning förWebbutveckling Sida 299 /

316

Page 301: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Spacing following paragraphs to at least 2 times the fontsize;Letter spacing (tracking) to at least 0.12 times the font size;Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make useof one or more of these text style properties in written text canconform using only the properties that exist for that combinationof language and script.

(Nivå AA)

MätbarhetProva att förstora all text enligt riktlinjens samtliga gränsvärden, exempelvismed hjälp av en bookmarklet eller med ett förstoringshjälpmedel. Undersökom något av de problem som beskrivs i denna riktlinje uppstår.

Relaterad riktlinjeGe webbplatsen en god läsbarhet (R39)Se till att text går att förstora utan problem (R127)

TerminologiRadavstånd (kägel inom typografin) är avståndet mellan textradens baslinjeoch nästa textrads baslinje. Radavståndet brukar mätas i punkter.

Teckenavstånd är avståndet mellan olika tecken i en rad med text. Inomtypografi pratar man om kerning när man minskar, eller ibland ökaravståndet mellan bokstavspar för att behålla en god ordbild och därmedunderlätta läsningen. Även termen knipning förekommer. Det är att minskaavståndet mellan samtliga tecken i ett ord eller i en mening.

Senast uppdaterad: 2018-11-28

Prio 1

Popup-funktioner ska kunna hanterasoch stängas av allaInnehåll, till exempel popup-rutor, som dyker upp vid tangentbordsfokuseller när användaren för muspekaren (hovrar) över ett visst objekt ska kunnauppfattas och hanteras av alla – även av användare som har förstorat sidaneller tar längre tid på sig att komma till innehållet. Det är särskilt viktigt attinnehållet enkelt kan tas bort eller stängas.

Det kan till exempel gälla undermenyer, inforutor (tooltips) och icke-modalapopup-fönster.

Riktlinje nr 158

Vägledning förWebbutveckling Sida 300 /

316

Page 302: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Tyvärr skapar sådant innehåll annars ofta tillgänglighetsproblem, tillexempel för att:

användaren inte har aktiverat funktionen med avsikt,användaren inte blir medveten om att det har dykt upp nytt innehållellerdet nya innehållet stör användarens förmåga att genomföra en uppgift.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Rekommendationer för tillgängligt popup-innehållÖ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.

Överväg att presentera innehållet på något annatsättDet finns ibland mer förutsägbara och tillgängliga sätt att presentera sammainformation eller funktionalitet. Till exempel genom att länka till en annansida.

Om ni ändå väljer att ha den här typen av innehåll så tänk på följande:

Gör det enkelt att ta bort innehålletInnehållet måste gå att avvisa, så att det inte stör eller blockerar sidansursprungliga innehåll. Det går att lösa till exempel genomtangentbordskommandot Escape eller en stäng-knapp. Ofta går det även attgöra så att ett nytt klick på samma position som öppnade innehållet ävenstänger det. Implementera gärna alla dessa varianter om det går.

Gör det möjligt att hantera innehållet för allaMuspekare måste kunna flyttas: I vissa fall, till exempel om användaren harförstorat själva muspekaren kan denna skymma innehållet i en inforuta. Avden anledningen behöver det gå att föra muspekaren även över det innehållsom presenteras dynamiskt, utan att det försvinner, se exempel nedan.

En knapps tooltip visas men användaren harförstorat pekaren så att innehållet i själva tooltipendöljs av pilen. Användaren kan flytta pekaren övertooltipen utan att den försvinner så att texten blirsynlig.

Vägledning förWebbutveckling Sida 301 /

316

Page 303: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Ge även användare tillräckligt med tid för att de ska kunna ta till sig ochuppfatta innehållet efter att det har blivit synligt. En användare kanskemåste ändra förstoringen eller tar tid på sig för att förflytta sig dit.

Innehållet ska vara synligt tills:

Användaren tar bort muspekaren eller byter tangentbordsfokus fråninnehållet eller det som utlöste händelsen.Användaren avfärdar innehållet genom ett tangentbordskommandoeller stänga-knapp, se ovan.Informationen inte längre är giltigt, till exempel ett meddelande om att“servern är upptagen”.

Riktlinjen gäller inte i de fall användaren själv styr över när innehållet visaseller inte, till exempel när webbläsaren visar title-attributet i HTML som etttooltip. Modala fönster är också undantagna eftersom de inte visas ochtriggas av att muspekaren förs över eller vid tangentbordsfokus. Se ävenWCAG 3.2.1 Vid fokus.

Tänk på att innehåll som triggas genom att muspekaren förs över en visspunkt också ska kunna styras med hjälp av tangentbordet.

Utdrag från WCAG-standarden

Riktlinje 1.4 Urskiljbart: Gör det enklare för användare att se ochhöra innehåll, bland annat genom att skilja förgrund frånbakgrund.

1.4.13: Content on Hover or Focus: Where receiving and thenremoving pointer hover or keyboard focus triggers additionalcontent to become visible and then hidden, the following aretrue:

DismissableA mechanism is available to dismiss the additional contentwithout moving pointer hover or keyboard focus, unless theadditional content communicates an input error or does notobscure or replace other content;

HoverableIf pointer hover can trigger the additional content, then thepointer can be moved over the additional content without theadditional content disappearing;

PersistentThe additional content remains visible until the hover or focustrigger is removed, the user dismisses it, or its information is nolonger valid.

Vägledning förWebbutveckling Sida 302 /

316

Page 304: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Exception: The visual presentation of the additional content iscontrolled by the user agent and is not modified by the author.(Nivå AA)

Teminologi

Mouseover eller hover är när muspekaren flyttas över en triggerpunkt, ettobjekt eller ett teckenavsnitt och utlöser en händelse såsom att byta bildeller visa adressen till en länk (ofta längst ner i webbläsaren).

Inforuta, på engelska tooltip, är en ruta med text som visas när muspekarenförs över ett område. Det kan till exempel röra sig om hjälprutor.

En modal eller en dialogruta, på engelska dialog box, är ett fönster somöppnas ovanpå användargränssnittet och hindrar annan interaktion. Deinnehåller ofta ett felmeddelande eller information som användaren behöverta ställning till genom att avbryta eller stänga fönstret. Termen lightboxförekommer även.

Pop-up window, pop-under window, eller extrafönster, har ett begränsatantal funktioner som öppnas ovanpå eller under ett redan öppnat fönster.De ligger ofta kvar tills de stängs manuellt, men kräver ofta ingen åtgärd avanvändaren.

Senast uppdaterad: 2018-11-28

Prio 1

Erbjud alternativ till komplexafingerrörelserAlla personer kan inte hantera komplexa rörelser på en pekskärm, såkallade fingergester. Detta gäller till exempel att svajpa (swipe) och gestersom kräver flera fingrar (multi-touch) såsom dra isär och nyp ihop. Det kanbero på motoriska eller kognitiva begränsningar, vilket hjälpmedel enanvändare har eller användarens brist på kunskap om gränssnittet.Komplettera därför alltid sådana med enklare interaktion såsom klick,dubbelklick eller tryck, såvida inte rörelsen är avgörande för funktionaliteten.

Observera att riktlinjen bara gäller webbplatsens eller appens gränssnitt.Det gäller inte operativsystemets eller webbläsarens funktioner, såsomhorisontell svepning för att navigera i sidhistoriken.

Riktlinjen undantar funktionalitet som naturligt kräver mer komplexa rörelser,till exempel att skriva sin signatur.

Riktlinje nr 160

Vägledning förWebbutveckling Sida 303 /

316

Page 305: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Rekommendation för tillgängligapekskärmsgränssnitt

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

Exempel på alternativ till komplexa rörelserI många kartfunktioner kan användaren nypa ihop eller dra isär fingrarna föratt zooma in eller ut, eller använda två fingrar för att förflytta sig i kartan.Vanliga alternativ till dessa rörelser är att använda kontroller ianvändargränssnittet, till exempel [+] och [-]-knappar för att zooma in och uteller pilknappar för att förflytta sig i olika riktningar.

På en webbplats ligger notiser till innehåll längs en horisontell axel (karusell)med dolda notiser för att locka användaren till relaterat innehåll. Notisernakan tas fram av användaren genom att svajpa till höger eller vänster, menfunktionen har även pilknappar för navigera framåt och bakåt mellannotiserna.

En bank har en funktion för bolånekalkyl med ett reglage där användarenkan ställa in det belopp som hen behöver låna. Reglaget kan manövrerasmed fingret genom att glida med fingret över reglaget, men det är ocksåmöjligt att klicka längs reglaget för att komma till ett relevant lånebelopp.

Utdrag från WCAG-standarden

Riktlinje 2.5 Input ModalitiesMake it easier for users to operate functionality through variousinputs beyond keyboard.

2.5.1 Pointer Gestures All functionality that uses multipoint orpath-based gestures for operation can be operated with a singlepointer without a path-based gesture, unless a multipoint orpath-based gesture is essential. (Nivå A)

Terminologi

Pekskärm, på engelska touch screen, är en skärm som användarenhanterar genom att röra med ett finger eller en särskild penna. Pekskärmarfinns på till exempel smarta telefoner, datorplattor eller olika former av

Vägledning förWebbutveckling Sida 304 /

316

Page 306: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

automater i offentliga miljöer såsom informationskiosker, biljettautomatereller liknande.

Fingergester är de rörelser som användaren gör mot en pekskärm. Påengelska kallas de touchscreen gestures eller pointer gestures.

Datatermgruppen har gjort en bra genomgång av termer för olikafingergester, på svenska och engelska. Här är några av de viktigaste:

Den engelska termen swipe översätts ofta med svajpa eller svepa. Pinchkallas för “dra ihop” och spread kallas “dra isär”. Tap kallas för trycka. Flick(att sätta ett finger på skärmen och snabbt svepa med det i en riktning, ochsedan lyfta fingret) kallas för snärta.

Multi-touch på en pekskärm är när användare förväntas använda två fingrareller mer för att aktivera eller använda en funktion på en pekskärm.Synskadade personer som till exempel använder Apples inbyggdahjälpmedel VoiceOver för att styra telefonen gör det ofta genom olika multi-touch-rörelser. Det går exempelvis att rotera med två fingrar på skärmen föratt välja hur man ska hoppa mellan olika objekt.

Senast uppdaterad: 2018-12-20

Prio 1

Gör det möjligt att ångra klickDen som använder pekskärm eller pekdon som exempelvis mus behöverkunna ångra sig om knappen eller trycket skedde av misstag. Erbjud därförminst en sådan möjlighet.

Möjligheten att ångra ett påbörjat klick är värdefull därför att den minskarrisken för att aktivera funktioner av misstag. Vem som helst kan råka tryckavid fel plats eller tillfälle, och det är extra lätt hänt för personer med vissafunktionsnedsättningar (exempelvis begränsad motorisk kontroll ellersynnedsättning).

Denna riktlinje berör dig som programmerar användargränssnitt (“front-end”)med exempelvis Javascript, men inte dig som enbart jobbar med text, bildoch formgivning.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Rekommendationer för att undvika oavsiktlig

Riktlinje nr 161

Vägledning förWebbutveckling Sida 305 /

316

Page 307: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

aktivering med pekdon eller pekskärmGe i första hand användaren möjlighet att ångra åtgärden innannedtryckningen 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 knappeneller skärmen (down-eventet).

Ge i första hand användaren möjlighet att ångraåtgärden innan nedtryckningen upphörOm aktivering av en funktion sker när pekdonets knapp (musknappen) ellertrycket på pekskärmen släpps upp (up-eventet) har användaren enmöjlighet att undvika, eller avbryta, händelsen genom att flytta sitt fingereller pekaren (till exempel muspekaren) bort från aktiveringspunkten(knappen, länken eller liknande).

Javascript-eventet click har denna logik inbyggd. Men däremot inväntas inteup-eventet om aktiveringen knyts till eventet mousedown.

Vid “drag-and-drop” kan det markerade objektet dras tillbaka tillursprungsläget eller till en icke aktiv yta för att ångra åtgärden.

Ge i andra hand användaren möjlighet att ångrasig efter up-eventetDetta kan ske exempelvis med hjälp av en bekräftelsedialog som inlederhändelsen ( “Är du säker på att du vill … “) eller en ångra-knapp efter atthändelsen startat.

Koppla bara i undantagsfall aktivering tillnedtryckning av knappen eller skärmenAktivering vid “down-event”, alltså när musknappen eller pekskärmen trycksin, ska bara ske om det är nödvändigt. Detta gäller framför allt vid följandetillfällen:

När användaren interaktivt behöver kunna kontrollerahändelsetidpunkten med stor precision. Till exempel om användarenspelar på ett digitalt piano eller spelar någon form av skjutspel.När det som användaren klickar på ska fungera som en tangent på etttangentbord.När händelsen automatiskt återställs så snart nedtryckningen upphör,oavsett var detta sker.När användaren haft möjlighet att ställa in huruvida händelser skakopplas till ner-eventet.

Utdrag från WCAG-standarden

Riktlinje 2.5 Input ModalitiesMake it easier for users to operate functionality through various

Vägledning förWebbutveckling Sida 306 /

316

Page 308: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

inputs beyond keyboard.

2.5.2 Pointer Cancellation

For functionality that can be operated using a single pointer, atleast one of the following is true:

No Down-Event: The down-event of the pointer is notused to execute any part of the function;Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the functionbefore completion or to undo the function after completion;Up Reversal: The up-event reverses any outcome of thepreceding down-event;Essential: Completing the function on the down-event isessential.

(Nivå A)

TerminologiDown-event är händelser som sker när musknappen eller fingret trycks ner.Kallas även touchstart eller mousedown.

Up-event är händelser som sker när musknappen eller fingret släpps upp.Kallas även touchend eller mouseup.

Senast uppdaterad: 2018-12-20

Prio 1

Se till att text på knappar ochkontroller överensstämmer medmaskinläsbara etiketterSe till att text som är synlig på knappar och andra gränssnittskontrollerockså finns i, och överensstämmer med, den maskinläsbara etikett somrepresenterar kontrollen i exempelvis program för röststyrning.

Den som använder röststyrning säger vanligtvis det som står på en knappför att använda knappen. Detta fungerar om det som står på knappenmotsvarar den maskinläsbara texten. Upplevelsen för seende som använderskärmläsare blir också bättre om uppläst text matchar det som visas påskärmen.

Om denna riktlinjePrioritet: 1Principer: Tillgänglig

Riktlinje nr 162

Vägledning förWebbutveckling Sida 307 /

316

Page 309: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Roller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

Rekommendationer för maskinläsbara etiketterTa 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 degör exakt samma sak.

Ta reda på vilken maskinläsbar etikett somanvänds för kontrollenGenom webbläsarens tillgänglighets-api hämtar både skärmläsare, programför röststyrning och vissa andra hjälpmedel en maskinläsbar etikett(accessible name) för varje kontroll på sidan (till exempel knappar, länkar,sliders och rullgardinsmenyer). Etiketten beräknas enligt en algoritm som tarhänsyn till både synligt textinnehåll och osynliga attribut som exempelvisaria-label, alt, value, title, desc (i SVG) och aria-valuenow. Även koppladeelement (exempelvis label eller element utpekade med aria-labelledby) kananvändas i beräkningen. Algoritmen håller på att standardiseras, men än sålänge varierar den lite mellan olika tekniska plattformar.

Du kan granska den maskinläsbara etiketten med hjälp av en skärmläsareeller med utvecklarverktyg som till exempel aViewer (Windows) ellerAccessibility Inspector (Firefox) eller med F12-Utvecklingsverktyg som finnsinbyggt i webbläsaren Edge (Använd element-väljaren och leta sedan efterNamn under fliken “Hjälpmedel”):

Se till att den maskinläsbara etiketten matchar densynligaIbland kan det vara svårt att räkna ut vilken kombination av all text i html-koden som utgör den maskinläsbara etiketten. Du kan antingen testa digfram eller använda attributet aria-label (som “vinner” över övriga alternativ)för att påverka den maskinläsbara etiketten.

Den maskinläsbara etiketten behöver inte vara identisk med den text somvisas på kontrollen, men den bör inledas på exakt samma sätt:

Exempel på fel: <button aria-label=”Stäng”>X</button>

Bättre: <button aria-label=”X Stäng”>X</button>

Vägledning förWebbutveckling Sida 308 /

316

Page 310: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Använd bara samma maskinläsbara etikett förflera kontroller om de gör exakt samma sakVilken knapp ska aktiveras när användaren med röststyrning sägerknappens namn (maskinläsbar etikett) om det finns flera andra knappar medsamma namn? Risken är att det inte blir den knapp som avsågs. Därför börolika funktioner ha olika namn.

Utdrag från WCAG-standarden

Riktlinje 2.5 Input ModalitiesMake it easier for users to operate functionality through variousinputs beyond keyboard.

2.5.3 Label in Name For user interface components with labelsthat include text or images of text, the name contains the textthat is presented visually. (Nivå A)

Relaterade riktlinjer och fördjupningPaciello group har en bra artikel om maskinläsbara etiketter och Simplyaccessible har en introduktion till tillgänglighets-api:et. Båda är på engelska.

Rekommendationer för utformning av etiketter/ledtexter i formulär finns iSkapa tydliga och klickbara fältetiketter (R55).

TerminologiNär vi skriver maskinläsbara etiketter i denna riktlinje syftar vi på det som irelevanta standarder på engelska heter Accessible name, eller bara name,som i WCAG-specifikationen.

Senast uppdaterad: 2018-11-28

Prio 1

Erbjud alternativ till rörelsestyrningSe till att funktioner som aktiveras genom att användaren till exempelskakar, vrider, rör vid eller viftar framför enheten kan stängas av.Funktionerna ska även kunna aktiveras på något annat sätt.

Detta hjälper personer som till exempel har enheten fastsatt vid en permobileller som av någon annan anledning inte har fysisk möjlighet att utföraliknande rörelser. Det finns också användare som oavsiktligt kan aktiveraden här typen av kontroller på grund av ofrivilliga skakningar (så kallad

Riktlinje nr 163

Vägledning förWebbutveckling Sida 309 /

316

Page 311: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

essentiell tremor) eller andra motoriska störningar.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign

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

Se till att funktioner som kan hanteras medrörelsestyrning även kan hanteras på något annatsättHär är några exempel:

SkakningEn användare skriver in text i ett formulär och skakar därefter enheten.Skakningen aktiverar en dialogruta som erbjuder användaren att ångrainmatningen.

En ångra-knapp kan erbjuda samma funktion.

LutningEn användare lutar enheten för att gå vidare till nästa eller föregående sida.

Knappar eller länkar kan utföra samma sak.

Förflyttning eller vridningEn användare flyttar eller vrider enheten för att panorera eller rotera ettinteraktivt foto.

En kontroll vid sidan av bilden kan utföra samma sak.

Rörelser med kroppenEn användare hoppar och rör på armarna framför enheten för att styra enfigur i ett spel.

För ett dansspel så kanske hela poängen med spelet går förlorad omrörelsestyrningen byts ut. Riktlinjen gör undantag i sådana fall. Men i andratyper av spel kan rörelsen gå att ersätta med exempelvistangentbordsinteraktion eller någon annan typ av inmatning.

Gör det möjligt att stänga av rörelsestyrningenVissa användare kan ofrivilligt göra rörelser eller exempelvis skaka enheten.

Vägledning förWebbutveckling Sida 310 /

316

Page 312: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se därför till att det finns inställningar som tillåter användaren att stänga avall form av rörelsestyrning.

Om möjligt bör sidan eller applikationen anpassa sig efter inställningar somanvändaren gjort i operativsystemet vad gäller rörelsestyrning.

Undantag från riktlinjenDet finns undantag från riktlinjen för funktioner som är beroende avanvändarens rörelser för att fungera. Till exempel är en stegräknareberoende av att enheten förflyttas för att kunna räkna steg. Det finns ävenundantag för rörelser som används för att aktivera funktioner i hjälpmedelför tillgänglighet.

Utdrag från WCAG-standarden

Riktlinje 2.5 Input ModalitiesMake it easier for users to operate functionality through variousinputs beyond keyboard.

2.5.4 Motion Actuation: Functionality that can be operated bydevice motion or user motion can also be operated by userinterface components and responding to the motion can bedisabled to prevent accidental actuation, except when:

Supported Interface: The motion is used to operatefunctionality through an accessibility supported interface;Essential: The motion is essential for the function anddoing so would invalidate the activity.

(Nivå A)

Relaterade riktlinjerErbjud alternativ till komplexa fingerrörelser (R160)Skapa en design som fungerar oavsett skärmens riktning (R153)

TerminologiRörelsestyrning kallas för “motion actuation” på engelska. Enhetens rörelserkan avläsas med hjälp av exempelvis ett gyro. Användarens rörelser kanavläsas med hjälp av exempelvis bildanalys (t.ex. Kinect) eller genom attanvändaren håller i enheten eller i en fjärrkontroll (t.ex. Wii). Sensorer förrörelsestyrning finns inbyggda i många moderna mobiltelefoner och andraenheter.

Senast uppdaterad: 2018-11-28

Prio 1

Riktlinje nr 164

Vägledning förWebbutveckling Sida 311 /

316

Page 313: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

Se till att hjälpmedel kan presenterameddelanden som inte är i fokusSe till att de som använder tekniska hjälpmedel som som exempelvisskärmläsare och förstoringsprogram kan göras uppmärksamma på viktigameddelanden även om de presenteras utanför det område på sidan somanvändaren har i fokus.Ange med hjälp av attributen role eller aria-live var viktiga

meddelanden kan förekomma, så får hjälpmedel kännedom om dessa ochkan presentera dem för användaren vid ett lämpligt tillfälle.Berörda användare riskerar annars att missa varningar, upplysningar ochfelmeddelanden.

Om denna riktlinjePrioritet: 1Principer: TillgängligRoller/arbetsuppgifter: TillgänglighetNär i utvecklingsprocessen?: Interaktionsdesign, Testning

Rekommendationer för kodning av förändringarutanför fokus

Markera med aria-kod de områden där statusmeddelanden kanpresenteras.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.

Markera med aria-kod de områden därstatusmeddelanden kan presenterasTermen statusmeddelande har en specifik betydelse i WCAG: Den syftar påviktiga meddelanden (information om resultat av en åtgärd, om väntetid ellerom felmeddelanden) som presenteras någon annanstans än däranvändarens fokus (tangentbordsfokus, för närvarande uppläst text ellerinzoomat område) för närvarande befinner sig. Se exempel nedan.

Använd aria-kod för att märka upp de områden där sådan information kanpresenteras. Hjälpmedel – framförallt skärmläsare – presenterar dåförändringar för användaren.

Använd i första hand någon av de standardtyper av “levande områden” (påengelska “live regions”) som finns, med hjälp av aria-attributet role:

Attributet role=”alert” används för viktiga brådskande meddelandensom behöver presenteras direkt i sin helhet av hjälpmedel.Attributet role=”status” används för viktiga men inte brådskandemeddelanden som presenteras i sin helhet av hjälpmedel när tidfinnes.Attributet role=”log” används för områden där nya meddelanden

Vägledning förWebbutveckling Sida 312 /

316

Page 314: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

successivt läggs till (i slutet). Enbart det nya innehållet presenteras avhjälpmedel, och detta först när tid finnes.Attributet role=”marquee” används för områden som förändras meninte nödvändigtvis i slutet. Förändringarna presenteras i regel inte avhjälpmedel.Attributet role=”timer” används för områden som innehåller entidsangivelse som kontinuerligt eller regelbundet uppdateras.Förändringarna presenteras i regel inte av hjälpmedel.

Om ingen av dessa passar kan du istället styra i detalj hur förändringar skahanteras i hjälpmedel.

Aria-live används för att ange om och i så fall när informationen skapresenteras:

Attributet aria-live=”assertive” anger att innehållet ska presenterasomedelbart. Det innebär att pågående uppläsning avbryts. Använddetta alternativ enbart om det verkligen är motiverat.Attributet aria-live=”polite” anger att innehållet ska presenteras när detfinns tid, till exempel efter att nuvarande mening lästs färdigt, eller näranvändaren gör en paus under inmatning.Attributet aria-live=”off” anger att innehållet inte ska presenteras avhjälpmedel.

Följande attribut ger ytterligare möjlighet att ytterligare påverkapresentationen:

Attributet aria-atomic=”true” anger att hela innehållet ska presenterasav hjälpmedel (om attributet saknas eller har värdet “false”presenteras endast den del av innehållet i området som förändrats).Attributet aria-busy=”true” anger att förändringar pågår och atthjälpmedel kan vänta med att presentera förändringarna tills värdet(via script) återställs till standardvärdet false.Attributet aria-relevant=”additions” anger att hjälpmedel bara skainformera användaren när nya html-element tillkommer i området.Attributet aria-relevant=”removals” anger att hjälpmedel bara skainformera användaren när innehåll avlägsnas från området.Attributet aria-relevant=”text” anger att hjälpmedel bara ska informeraanvändaren när textförändringar sker i området.Attributet aria-relevant=”all” anger att hjälpmedel ska informeraanvändaren oavsett vilka förändringar det rör sig om.

Använd aria med försiktighet så att du inte störanvändarenDen första riktlinjen i WAI-Aria Authoring Practices kan sammanfattas medatt det är bättre att inte använda aria alls än att skriva dålig aria-kod. Om viexempelvis “för säkerhets skull” sätter aria-live=”assertive” på alla områdensom kan komma att uppdateras dynamiskt så kan det resultera i att den somanvänder hjälpmedel ständigt blir avbruten och i praktiken inte kan använda

Vägledning förWebbutveckling Sida 313 /

316

Page 315: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

sidan.

Var därför försiktig med att använda aria, och fundera på vilken informationsom verkligen måste presenteras för användaren.

Dessutom finns det vissa dynamiska förändringar som inte räknas somstatusmeddelanden och som inte bör ha något annat värde på aria-live änstandardvärdet off. Till exempel följande:

DialogrutorDialogrutor får i regel fokus när de visas, och därmed presenteras innehålletautomatiskt av hjälpmedel.

Dynamiska menyer och “dragspel”När användaren interagerar med gränssnittet och innehåll döljs ellerexponeras, till exempel genom att fälla ut en meny, eller när delar avinnehållet ligger i ett så kallat dragspel (accordion) som kan dras ut eller in,räknas det inte som ett statusmeddelande.

Det är ändå troligt att aria-kodning behöver uppdateras (till exempelattributen aria-expanded och aria-collapsed). Dessutom ska skräddarsyddakomponenter ges en roll, ett, värde och namn enligt WCAG 4.1.2 så attanvändaren ändå får reda på vad som händer.

Använd gärna samma teknik för andra relevantaförändringar i innehålletÖverväg att använda samma teknik till ändringar i innehållet somanvändaren kan tänkas vilja ha upplysningar om men som egentligen intekrävs för att uppfylla riktlinjen. Till exempel:

Ett formulärfält frågar hur många barn en person har och användarenskriver in siffran fem varpå sidan uppdateras med ytterligare fem fältför barnens namn. Skärmläsaren meddelar: Fem fält läggs tillformuläret.En lista med 15 produkter finns på en sida med knappen ”Se flerprodukter” längst ner. När användaren klickar på knappen meddelarskärmläsaren: ”Ytterligare 15 produkter läggs till på sidan.”

Exempel på vad uttrycket “statusmeddelanden”kan innebäraSökresultatSjälva resultatlistan efter en sökning räknas inte som ett statusmeddelande,men om systemet presenterar sökresultaten samtidigt som det visas ettmeddelande ovanför träfflistan “Din sökning resulterade i xx träffar.”, då ärdet meddelandet ett statusmeddelande och skärmläsaren bör läsa upp det.

Uppdatering av kundvagnNär en användare klickar på knappen “Lägg i kundvagnen” ändras en text i

Vägledning förWebbutveckling Sida 314 /

316

Page 316: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

närheten av ikonen till kundvagnen ”5 artiklar”. Skärmläsare meddelaranvändare: ”Fem artiklar” eller ”Kundvagn, fem artiklar”.

Status och felmeddelande i formulärEfter att en användare skickat in en ansökan visas statusmeddelandet: “Dinansökan har skickats in.” Skärmläsaren meddelar samma sak.

Din ansökan har skickats!

Efter att en användare angett ett felaktig värde i formulärfältet“Postnummer”, visas ett felmeddelande ovanför fältet ”Ogiltig postnummer”.Skärmläsaren bör lämna samma information.

Meddelande om upptagen applikationNär en användare aktiverar en process, till exempel hämtar en fil, visas enikon på skärmen som symboliserar att servern är upptagen. Skärmläsarenmeddelar användaren ”Applikationen är upptagen”.

Meddelande i en processEn applikation visar en förloppsindikator för att ange status för en pågåendeuppgradering. Skärmläsaren kan ge användaren återkommande informationom hur långt processen fortskridit, till exempel genom att script medlämpliga intervall uppdaterar värdet på attributet aria-valuenow.

Progressbar som visar 75% klart

Kodexempel:

<div class="progress">

<div class="progress-bar" role="progressbar" aria-

valuenow="75" aria-valuemin="0" aria-valuemax="100">

</div>

</div>

Utdrag från WCAG-standarden

Riktlinje 4.1 Kompatibelt: Maximera kompatibiliteten mednuvarande och framtida användarprogram, inklusive hjälpmedel.

4.1.3 Status Messages In content implemented using markuplanguages, status messages can be programmaticallydetermined through role or properties such that they can bepresented to the user by assistive technologies without receivingfocus. (Nivå AA)

TerminologiFörloppsindikator, på engelska progress bar, progress indicator ellerprogress meter visar användaren hur mycket av en process som är

Vägledning förWebbutveckling Sida 315 /

316

Page 317: Vägledning för webbutveckling · R1. Utgå från WCAG 2.0 nivå AA R80. Följ standarder R81. Utveckla webbplatsen enligt en standard snarare än för en webbläsare Senast uppdaterad:

genomförd genom att en list fylls allt eftersom. Ibland anges samtidigt enprocentsats för att förtydliga processen. Förloppsindikatorn används ofta föratt visa hur långt en nedladdning eller programinstallation har kommit.

Det dragspelsliknande designmönstret accordion skrivs ibland med franskstavning: accordeon.

Senast uppdaterad: 2018-12-20

Vägledning förWebbutveckling Sida 316 /

316