De sex vanligaste bristerna när DIGG granskar webbplatser

Den 23 september 2020 blev det ett krav för alla offentliga aktörer att ha webbplatser som lever upp till lagen om tillgänglighet till digital offentlig service. Under det gångna året har DIGG utfört tillsyn för att se så att kraven efterlevs. Här hittar du de sex vanligaste bristerna.

För de webbplatser som inte klarat kraven på tillgänglighet är det oftast några brister som är återkommande:

De sex vanligaste bristerna i DIGG:s ingående övervakning

• Fel på HTML-kod. Det gör att skärmläsare, ett verktyg som läser upp vad som står, inte kan tolka sidan och tappar bort sig. Läs mer på sidan: Se till att koden validerar
• Otydligt vad som är vad. Vad är huvudrubrik eller vad är underrubrik? Är det text, en punktlista eller en tabell? Märk upp texten så att en skärmläsare kan läsa så det blir begripligt. Läs mer på sidan: Ange i kod vad sidans olika delar har för roll
• Vad är i fokus? Om man använder tangentbordet för att navigera på en sida så behöver det vara tydligt vad som är i fokus. Annars vet man inte vad som händer när man trycker Enter. Läs mer på sidan Använd tillräckliga kontraster i komponenter och grafik
• Vilket språk är det? Låneord är vanliga och om man inte anger vilket språk ordet kommer ifrån kommer en skärmläsare uttala ordet fel. Läs mer på sidan: Ange språkförändringar i koden
• Dålig kontrast. Om det är dålig kontrast mellan till exempel textfärg och bakgrund så syns det inte så bra vad det står om man har synnedsättning eller nedsatt färgseende. Läs mer på sidan: Använd tillräcklig kontrast mellan text och bakgrund
• Alt-texter saknas. Om bilden inte bara är dekorativ utan innehåller information så behöver bilden en alt-text. Den som inte kan se bilden får då den uppläst. Läs mer på sidan Beskriv med text allt innehåll som inte är text

Resultat från ingående övervakning

Under en tillsynsperiod granskar DIGG webbtillgängligheten på ett antal offentliga aktörers webbplatser. Under perioden 2020-2021 granskar DIGG 24 webbplatser ingående. Vilka aktörerna är och deras resultat är finns på Resultat från ingående övervakning (digg.se)

Textalternativ för bilder – information när inte bilden kan visas

Att skriva bra textalternativ (alt-texter) för bilder är inte lätt. De flesta webbplatser har brister när det gäller den text som visas när bilden inte går att uppfatta.

Nedan beskrivs några vanliga fel och hur de kan rättas till.

• Det saknas textalternativ.
• För lite text till komplex bild.
• För mycket text när bilden egentligen är dekorativ.
• Felaktig beskrivning av vad bilden förmedlar.
• Onödig information i textalternativet.

Det saknas textalternativ

En bild ska aldrig sakna textalternativ. En bild som är dekorativ och egentligen bara finns som utsmyckning ska istället ha ett tomt textalternativ. Tomt är alltså inte samma sak som utelämnat eller saknat. Tomt textalternativ ser ut såhär i koden (alt=””). Genom att skriva (alt=””) talar man om för uppläsande hjälpmedel att bilden är dekorativ och därför inte värd att nämna.

För lite text till komplex bild

En komplex bild som t.ex. ett diagram innehåller ofta en stor mängd information. Om ett diagram visar smittspridningen över tid räcker det inte med att textalternativet till bilden är ”Diagram över smittspridningen.” Textalternativet ger ju inte någon information om själva smittspridningen. Ett bättre textalternativ är att beskriva det diagrammet förmedlar, t.ex. ”Antal sjuka per dag var 2000 i slutet av maj, nära noll under sommaren och ökade till 8000 i november.”

Om diagrammet innehåller för mycket information föra att beskrivas i textalternativet, kan informationen istället presenteras i tabellform och textalternativet till diagrammet kan då vara ”Diagram över smittspridningen, se tabell.”

För mycket text när bilden egentligen är dekorativ

Bilder som inte tillför någon information och som egentligen är till för att ”vila ögonen” på kallas för dekorativa bilder. Dessa ska inte beskrivas med textalternativ alls, de ska ha tomma text-alternativ, dvs. (alt=””). Personer som använder uppläsande hjälpmedel slipper på så vis lyssna till ovidkommande beskrivningar av bilder som inte tillför innehållet något.

Felaktig beskrivning av vad bilden förmedlar

Att använda en röd triangel som varningsikon för viktig varningsinformation innebär att det ikonen förmedlar ska beskrivas, dvs. ”Varning”. Många gånger beskrivs ikonens utseende istället t.ex. ”röd triangel.”

Onödig information i textalternativet

Exempel på onödig information i textalternativet:

• ”Bild av…” Ett uppläsande hjälpmedel talar om att det är en bild så det behöver inte skrivas ut.
• ”Exempelmyndighetens logotyp.” eller som textalternativ för myndighetens logotyp längst upp på sidan. Skriv istället enbart ”Exempelmyndigheten”.
• ”Exempelmyndigheten – länk till startsidan”. Det uppläsande hjälpmedlet talar om att det är en länk och det är kutym att logotypen längst upp på webbplatsen länkar till webbplatsens startsida.
• ”……….. Foto: Förnamn Efternamn.” Information om upphovsmakare till en bild ska förmedlas i bildtext eller informationsruta (tooltip), inte i textalternativet för bilden.

Att tänka på när du skriver textalternativ till bilder

• Tänk att textalternativet ska förmedla information, inte motiv.
• Vad skulle du säga om du beskrev webbsidans innehåll för någon? Om du hoppar över bilden är den troligen dekorativ och ska ha (alt=””).
• Undvik värderade ord – skriv hellre ”en svart bil” istället för ”en snygg bil”.
• Fundera över hur en eventuell bildtext fungerar tillsammans med textalternativet.

Testa textalternativen

Web Developer Toolbar är ett gratis tilläggsprogram som installeras i webbläsaren (finns för Firefox, Chrome, Opera och Vivaldi t.ex.). I tillägget finns möjlighet att ersätta bilder med bildernas textalternativ. Det ger möjlighet att se hur sidan läses upp av t.ex. en skärmläsare.

Läs mer

På sidan Beskriv med text allt innehåll som inte är text finns mer information om textalternativ för bilder.

Vi testar en ny videospelare – vad tycker du?

Vi testar videospelar-komponenten AblePlayer och skulle gärna vilja ha synpunkter på hur den fungerar!

Spelaren är utvecklad med ambitionen att vara tillgänglig, och har bland annat knappar för aktivering av syntolkning, undertexter och teckenspråkstolkning. Dessutom finns en funktion för så kallad ”textbaserad syntolkning”, det vill säga en skriven syntolkning som läses upp av skärmläsare.

Använd gärna kommentarsfunktionen i slutet av sidan, eller skicka dina synpunkter med e-post till info@webbriktlinjer.se. Ange gärna vilken webbläsare, vilket operativsystem och vilka eventuella hjälpmedel du använder, om det är något som inte fungerar så bra.

Tack!

Exempelfilm med syntolkning, teckenspråkstolkning, undertexter, transkription och tangentbordsnavigering

Obs! Symbolen för syntolkning ser ut som ett öga med bågar ovanför.

Exempelfilm med teckenspråkstolkning och experiment med textbaserad syntolkning

Aktivera textbaserad syntolkning med hjälp av syntolkningsikonen (den ser ut som ett öga med bågar). Eventuellt behöver du även aktivera din skärmläsare manuellt för att få denna textremsa uppläst. Bara filmens första minut har sådan syntolkning.

Denna spelare kan även hantera flera olika textremsor (exempelvis på olika språk) och knappar för ökad eller minskad uppspelningshastighet, men dessa funktioner är inte för närvarande aktiva här.

Öppen källkod

AblePlayer är utvecklad av University of Washington och delas kostnadsfritt med MIT-licens.
Källkoden finns att hämta på GitHub, men där finns ännu ingen svensk version. Du kan dock ladda hem den svenska översättningsfilen (javascript) som vi gjort.

Presentation om webbtillgänglighet och lagen om tillgänglighet till digital offentlig service

Post- och telestyrelsen (PTS) har tagit fram en powerpoint-presentation som kan användas relativt fritt för att vägleda andra till vad webbtillgänglighet är och vad lagen om tillgänglighet till digital offentlig service innebär. Läs sidorna 2-3 i presentationen för detaljer om hur den får användas.

OBS! Vissa bilder i presentationen får enbart användas för att informera om webbtillgänglighet och/eller lagen om tillgänglighet till digital offentlig service. De får alltså inte kopieras och användas i andra presentationer med annat syfte. Presentationen kan dock förbättras och kompletteras under eget ansvar.

Presentationen är indelad i fyra kapitel:

• Övergripande om digital tillgänglighet
• Standarden för webbtillgänglighet (WCAG)
• Webbtillgänglighetsdirektivet och lagen om tillgänglighet till digital offentlig service
• Kom igång med digital tillgänglighet

Post- och telestyrelsen ansvarade för Vägledningen för webbutveckling mellan år 2015 och 2018. Under de åren har en mängd informationsinsatser gjorts om webbtillgänglighet och det så kallade webbtillgänglighetsdirektivet. Direktivet har nu implementerats i lagen om tillgänglighet till digital offentlig service (pdf 1 MB). Myndigheten för digital förvaltning, DIGG, har övertagit ansvaret för Vägledningen för webbutveckling.

Presentationen Webbtillgänglighet och Lagen om tillgänglighet till digital offentlig service (pptx 5 MB).

Introduktioner till kognitiv digital tillgänglighet

Nu finns det inspelningar från ett seminarium om kognitiv tillgänglighet i digital offentlig service publicerade. Det var en träff med nätverket för myndighetssamverkan i IT-tillgänglighet (MITT). Efter nätverksträffen publicerade PTS även ett blogginlägg som introducerar begreppet kognitiv digital tillgänglighet.

DIGG och PTS samarbetar kring webbriktlinjer.se

Vägledningen för webbutveckling har funnits i olika former sedan 2002, och har genom åren varit mycket uppskattad. Ansvaret har gått i arv mellan flera olika myndigheter, och fram till i somras hade Post- och telestyrelsen regeringens uppdrag att ansvara för vägledningen.

I sin proposition 2017/18:299 om genomförande av webbtillgänglighetsdirektivet skriver regeringen att ”Från och med den 1 september 2018 är det Myndigheten för digital förvaltning som har som permanent uppgift att ansvara för vägledningen.” Myndigheten för digital förvaltning (DIGG) inrättades just den 1 september 2018.

Enligt en överenskommelse med DIGG fortsätter PTS att hålla i den praktiska förvaltningen under resten av 2018, i nära samarbete med den nya myndigheten.

Vägledningen behöver ständigt vidareutvecklas för att kunna vara relevant. Har du förslag på hur den borde vidareutvecklas framöver för att möta dina behov? Hör i så fall gärna av dig! Du kan exempelvis använda adressen info@webbriktlinjer.se eller någon annan kontaktinformation som du hittar på sidan Om webbplatsen.

Tillgänglig presentation av statistisk information

Vid träffen med MITT-nätverket den 19 september pratade vi om hur diagram, kartor, tabeller och andra presentationsformat för stora datamängder kan göras tillgängliga.

Eftersom människors förutsättningar kan variera på väldigt många olika sätt är digital tillgänglighet för personer med funktionsnedsättning ett brett område, som tar sin tid att sätta sig in i. När det gäller dataintensiv information som exempelvis statistik finns dessutom extra utmaningar. Till exempel används ofta visualiseringar för att skapa förståelse och överblick. Men som ordet antyder är ”visualiseringar” starkt förknippat med visuell förmåga. Hur kan visualiseringar göras tillgängliga för personer med nedsatt syn? Och, för den delen, hur kan stora och komplexa datamängder göras tillgängliga för personer med kognitiva funktionsnedsättningar?

Att presentera statistisk information på ett sätt som fungerar för personer med bredast tänkbara variation av egenskaper och förmågor kan vara svårt – men ofta går det att komma längre än du kanske tror! Och värdet av att kunna ta del av tabeller, diagram och inte minst kartor utan att behöva be om hjälp kan vara oerhört stort.

Tre grundläggande rekommendationer:

• Tillämpa de generella riktlinjer som finns för digital tillgänglighet, i den mån det är möjligt.
• Erbjud flera olika alternativa presentationsformat.
• Beskriv, om möjligt, innehållet med text.

Men det finns också en del mer specifika åtgärder som kan göras för olika typer av innehåll. Vi har börjat sammanställa några konkreta tips för tillgänglig presentation av statistik (pdf, 3MB). Det är fortfarande inget heltäckande eller kvalitetssäkrat material, men blir successivt bättre. Ladda gärna ner materialet och återkoppla gärna så att vi kan förbättra det. Kanske kan delar av materialet så småningom omarbetas till webbriktlinjer.

Förslag på utformning av tillfälligt tillgänglighetsutlåtande

Enligt webbtillgänglighetsdirektivet ska myndigheter publicera utlåtanden som bland annat redovisar i vilken utsträckning man uppfyller direktivets krav. EU-kommissionen arbetar med att ta fram en mall för sådana utlåtanden. Mallen förväntas vara klar i slutet av året. Myndigheten Digg kommer troligen att så småningom även ge ut föreskrifter som beskriver hur utlåtanden ska utformas och vad de ska innehålla.

I väntan på mallar och föreskrifter har PTS och Bolagsverket tagit fram en mycket enkel mall för tillgänglighetsutlåtanden som skulle kunna användas tillfälligt, till dess att det kommer officiella riktlinjer.

Hjälp att börja tillämpa WCAG 2.1

Nu finns utkast till webbriktlinjer som förklarar, illustrerar och exemplifierar kriterier från WCAG på svenska även för de 12 nya kriterierna från WCAG 2.1.

Kom gärna med synpunkter!

Referensgruppen för webbriktlinjerna avgör när vi kan ta bort markeringen ”utkast”. Observera dock att den underliggande standarden WCAG 2.1 redan är färdig.

Utkast ny webbriktlinje 81 om HTML-versioner

Här följer ett utkast till ny version av riktlinjen Utveckla webbplatsen enligt en standard snarare än för en webbläsare (R81).
OBS! Gå till riktlinjen. Utkastet finns bara kvar av historiska skäl.

Utveckla webbplatsen enligt en standard, snarare än för en webbläsare

Följ en webbstandard när ni utvecklar er webbplats, så kan ni vara mer säkra på att koden kommer att fungera även i kommande webbläsare. Testa med de kombinationer av utrustning som är vanligast i målgruppen.

Halvdag om tillgänglig video på webben

Om textning, syntolkning och teckenspråkstolkning
(använd gärna symbolerna)

Den 1 januari 2019 kommer EU:s webbdirektiv att bli svensk lag. På sikt innebär detta bland annat att videoinspelningar som offentlig sektor sprider digitalt ska vara textade och syntolkade. Det gäller både på webben och så långt som möjligt även på videoplattformar och i sociala medier.

Detta kan bli oerhört värdefullt för personer med nedsatt syn och hörsel, och även för många andra. Teckenspråk berörs inte av samma reglering, men får snarlika konsekvenser i produktion och planering. För att på ett bra sätt kunna möta de ökande kraven behöver vi dela erfarenheter med varandra. Därför ordnade PTS tillsammans med Malmö stad en halvdagsträff om tillgänglig webbvideo (textning, syntolkning och teckenspråkstolkning) den 20 april 2018.

Inspelningar

Du hittar de teckenspråkstolkade och live-syntolkade inspelningarna här. Hela inspelningen är 4 timmar lång och finns på YouTube. Här följer direktlänkar till respektive presentation, i diverse olika format.

1. Välkommen och kort om webbvideo i offentlig sektor
   Mikael Hellman, Malmö stad
2. Kort om MITT-nätverket och om webbdirektivet
   Pär Lannerö, projektledare webbriktlinjer.se på PTS. Mikaels och Pärs inledande bilder (pdf, 542 kByte).
3. Textning av webbvideo
   • Mattias Lundekvam, ordförande för Hörselskadades riksförbund presenterade ämnet ur ett användarperspektiv. Direktlänk till YouTube-inspelningen.
   • Richard Gatarski producent på WestreamU presenterade ämnet ur ett produktions- och beställarperspektiv. Richard har även publicerat sina presentationsbilder och en artikel om textning. Direktlänk till YouTube-inspelningen
   • kommentarer och frågor från deltagare
4. Syntolkning av webbvideo
   • Henrik Götesson, handläggare IT- och konsumentfrågor på Synskadades riksförbund, presenterade ämnet ur ett användarperspektiv. Direktlänk till YouTube-inspelningen. Henriks presentationsbilder (pdf, 600 kByte). Mer om syntolkning från SRF.
   • Magnus Johansson, syntolkningsproducent på Iris media, presenterade ämnet ur att produktions- och beställarperspektiv. Direktlänk till YouTube-inspelningen.
   • Kommentarer och frågor från deltagare
5. Vad kan webbansvariga lära av SVT:s tillgänglighetsarbete?
   Lars Samuelsson, tillgänglighetsansvarig för SVT online
6. Teckenspråkstolkning av webbvideo
   • Isabella Hagnell, generalsekreterare Sveriges dövas riksförbund, presenterade ämnet ur ett användarperspektiv. Direktlänk till YouTube-inspelningen.
   • Mindy Drapsa, företagsledare Dramaski, presenterade ämnet ur att produktions- och beställarperspektiv. Direktlänk till YouTube-inspelningen.
   • Kommentarer och frågor från deltagare
7. Tillgänglig webbvideo, erfarenheter och framtidsspaning
   Mia Ahlgren, policyhandläggare, Funktionsrätt Sverige. Mias presentationsbilder (pdf, 800 kByte)
8. Kommunen och tillgängligheten
   Nils Karlsson, kommunalråd (MP) Malmö stad. Ordförande för Funktionsstödsnämnden samt ordförande för Beredningen för demokrati, jämställdhet och mänskliga rättigheter.

Övrig dokumentation

Mattias Skoog från Halmstads kommun publicerade en fin film på 7 minuter om träffen och om tillgänglig video, och startade ett upprop om textning i en Facebookgrupp om videokommunikation i offentlig sektor.

Inför träffen tog syntolken Helena Frank fram ett informationsblad till alla talare, med tips på hur föreläsningar kan göras mer tillgängliga för synskadade.

Några kommentarer från deltagare och andra finns på #webbvideo på Twitter, och du får gärna använda den taggen för att ställa fler frågor eller komma med fler kommentarer. Eller så kan du använda kommentarsfunktionen i slutet av denna sida.

Kommande träffar och konferenser

Nätverket för myndighetssamverkan i IT-tillgänglighet (MITT) träffas ungefär fem gånger per år. Nästa träff är planerad till den 13 juni och har tema tillgänglighet i interna system.

Deltagare på vår träff har tipsat om kommande konferenser med angränsande teman:

1. The Forum of Equality in Culture – Collect, Connect, Create handlar om användning av teknik för inkluderande kultur och vetenskap och äger rum i Stockholm den 23-24 maj 2018
2. Symposium on Subtitling technology (SubTech1) Tar upp bland annat nya tekniska format, AI-textning och textning av VR-miljöer. 24 maj 2018 i München.
3. VideoKonf – Rörlig bild i offentlig sektor arrangeras av Malmö stad och Kommunförbundet Skåne i november 2018.
4. 8th Media for All International Conference (M4A8). En bred konferens om tillgänglig media med forskare och praktiker från hela världen. Stockholms universitet, juni 2019.

En första genomgång av WCAG 2.1

2018-06-11: uppdaterat sidan i och med att WCAG 2.1 blivit rekommenderad version.

Från och med 5 juni 2018 är den nya versionen av tillgänglighetsstandarden WCAG 2.1 en rekommenderad version.

Den nya versionen ändrar ingenting från WCAG 2.0, som ända sedan 2011 varit den första och mest centrala webbriktlinjen (R1). Men WCAG 2.1 utökar WCAG 2.0 med 17 nya kriterier.  12 av dessa krävs för nivå AA. Uppdateringen förväntas bidra bland annat till bättre kognitiv och mobil tillgänglighet.

Sannolikt kommer även en uppdatering av den Europeiska standarden EN 301 549 som hänvisar till WCAG 2.1 AA istället för 2.0 AA. Det kan i så fall innebära att kriterier på nivå A och AA i WCAG 2.1 blir en del av tillgänglighetskraven i webbdirektivet.

PTS har gjort en översiktlig genomgång av WCAG 2.1 (PDF, 842kB) för den som vill orientera sig.

Uppdatering 2018-08-21: Nu finns utkast till webbriktlinjer som förklarar, illustrerar och exemplifierar kriterier från WCAG på svenska även för de 12 nya kriterierna från WCAG 2.1.

Uppdatering 2018-08-30: Nu finns den nya versionen av EN 301 549 publicerad, och den förväntas få status som harmoniserad standard (HEN) inom kort. Då blir det den som gäller för webbdirektivet.

Korta introduktioner om lagkrav som berör utformning av webbplatser

I intervjuer med webbriktlinjernas målgrupper, det vill säga designers, innehållsskapare, utvecklare och digitalt ansvariga, framkom att många önskar vägledning till reglering som berör deras arbete. För att möta denna efterfrågan har vi skrivit korta introduktionstexter om lagkrav som berör utformning av webbplatser och andra digitala tjänster.

Bland annat har vi fått hjälp av Språkrådet att göra en översikt av reglering på språkområdet och av Arbetsmiljöverket att göra en introduktion till reglering på arbetsmiljöområdet. Sedan tidigare finns även information om webbdirektivet och om diskrimineringslagens relevans för digital tillgänglighet.

Det finns ingen möjlighet för oss att ge fullständig information om all relevant lagstiftning, men vi kan åtminstone bidra med början till en översikt.

Webbplatsen förändras sommaren 2017

Under sommaren 2017 publicerar vi utdrag med förklaringar, exempel och illustrationer till kriterier på nivå AA i tillgänglighetsstandarden WCAG 2.0. Anledningen är att senast den 23 september 2018 kommer lagstiftning som gör att myndigheter och många andra måste uppfylla standarden, som inte alltid är så lätt att läsa.

Observera att detta inte innebär att antalet riktlinjer blir fler. Tvärtom blir det färre riktlinjer att hålla koll på eftersom vi i samband med arbetet rationaliserar bort några webbriktlinjer som har ett stort överlapp med kriterier från WCAG.

Vi jobbar också med designen, strukturen, mobil presentation, sökfunktionen med mera. Vi hoppas att det ska bli lättare att få överblick och att hitta rätt innehåll.

Riktlinjernas adresser förändras, men äldre länkar ska ändå fortsätta fungera.

Kom gärna med kommentarer, felrapporter och förslag, både när det gäller innehåll, utformning och funktion!
Använd till exempel kommentarsfunktionen eller skicka e-post till info@webbriktlinjer.se.

Utkast till ny version av riktlinje 54 om prestanda

Här följer ett tidigare utkast till ny version av riktlinjen R54. Optimera webbplatsen för bästa prestanda. OBS! Riktlinjen är nu uppdaterad så denna version finns endast kvar som dokumentation av diskussionen kring utkastet.

Diskussioner skedde i kommentarsfunktionen sist på sidan och i Facebookgruppen webbriktlinjer samt genom epost till info@webbriktlinjer.se.

Optimera tjänsten så att den laddar snabbt, svarar snabbt på interaktion och kräver så lite som möjligt av användarens utrustning och uppkoppling. Dålig prestanda leder till negativa användarupplevelser, hinder för användning, försämrat genomslag (till exempel genom sämre rankning i sökmotorer) och slöseri med resurser. Bra prestanda kan till exempel uppnås genom att inte överföra mer data än nödvändigt.

Rekommendationer för god prestanda

• Acceptera inte långa väntetider
• Kartlägg utgångsläget och skapa en prestandabudget
• Identifiera och åtgärda prestandaproblem
• Gå 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ånga webbplatser och appar låter användare vänta i onödan. Du själv har kanske bra uppkoppling till din nya snygga sajt och är motiverad nog att vänta när den laddas, men andra besökare är ofta otåliga och på väg någon annanstans. 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 undvika dåligt optimerade webbplatser eftersom de ofta har begränsad bandbredd och ibland måste betala extra för varje megabyte data.

Eftersom sökmotorer premierar webbplatser med en god användarupplevelse leder ökad prestanda även till bättre sökmotoroptimering.

Optimering innebär också minskad belastning på servrarna, vilket kan ge lägre kostnader för hårdvara och bandbredd eftersom befintlig infrastruktur kan 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 ni behöver åtgärda.
• Ta reda på vilka prestandabrister som användarna upplever som mest besvärande och åtgärda de problemen först.
• Gör en nollmätning, det vill säga mät prestanda innan förbättringarna gjorts och upprepa mätningarna efteråt så blir det enkelt att utvärdera era insatser.

Oavsett om det gäller förvaltning eller nyutveckling kan det vara bra att ta fram en prestandabudget som dokumenterar organisationens ambition kring prestandaoptimering, mätvärden med mera. Ett exempel på prestandabudget finns hos Västra Götalandsregionen.

Vad är tillräckligt bra prestanda?

Forskning har visat att användare av datorsystem tappar koncentrationen om de får vänta för länge. Nielsen-Norman har redovisat följande 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ärksam och vill göra något annat under tiden.

Behovet av snabba svarstider beror på användarens förväntan och exakt vad hen försöker åstadkomma. För användare med muspekare är den första tidsgränsen om 0,1 sekunder avgörande för om responsen uppfattas som omedelbar, exempelvis om musmarkören placeras över något och det orsakar en mouseover-effekt. Om användaren istället klickar på en länk är det troligt att den andra tidsgränsen om en sekund är mer relevant. Tio sekunder är någon form av bortre gräns för en användare att kunna behålla fokus.

I ETSI-standarden för kognitiv mobil tillgänglighet (pdf, se avsnitt 12.4.6) rekommenderas att applikationen ska ge någon sorts respons efter max 0,1 sekunder.

Identifiera och åtgärda prestandaproblem

Det finns ett flertal möjliga anledningar till att en webbplats upplevs som långsam. Mest uppenbart är att antingen webbplatsen i sig, eller anvä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å grund av en överbelastningsattack eller för att för många användare efterfrågar ett visst innehåll.

En webbplats kan också uppfattas som långsam på grund av tekniska brister, bland annat:

• Underdimensionerade servrar. De flesta webbplatser består av flera olika sorters servrar, bland annat för databas, bakomliggande system och webbredaktörernas publiceringssystem.
• Inte tillräcklig bandbredd mellan servrarna och internet. Jämför med tjockleken på en vattenslang vid vattnande av en gräsmatta: en tjockare slang kan potentiellt bära mer vatten.
• Programmeringsfel till exempel vid sökningar i databaser kan göra att servern tvingas arbeta onödigt mycket för att leverera efterfrågat innehåll.
• Inte optimal konfiguration, till exempel brister på hur en cache är inställd, att databasers index inte återspeglar efterfrågat material eller att behoven varierar på ett sådant sätt att det ändå inte fungerar optimalt.

Fem sätt att förbättra prestandan

Begränsa antalet anrop

Att hämta en webbsida på en webbplats innebär i princip alltid att klienten behö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-anrop tar 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. Detta sker med automatik om ni använder http-versionen HTTP/2. Gör gärna det om ni har möjlighet, men eftersom inte riktigt alla besökare ännu har stöd för HTTP/2 så behöver ni också stödja någon annan http-version. Då kan antal anslutningar minskas genom att till exempel slå ihop flera resurser i en och samma fil.

Kombinera flera separata stilmallar till en enda istället för att leverera flera separata stilmallar: en för färger, en för teckensnitt, en för övergripande layout och så vidare.

Detsamma gäller script. Även bilder kan kombineras till så kallade CSS image sprites. Det passar dock inte för alla typer av bilder, och kräver sä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 multimedia

Bilder, videofilmer, ljudklipp och liknande står ofta för större delen av datatrafiken från en modern webbplats. Här finns stora prestandavinster att göra, ofta med ganska enkla medel:

• Välj rätt filformat för bilder, exempelvis JPEG för fotografier eller PNG fö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 desto större blir filerna.
• Använd inte bilder eller videofilmer i större dimensioner/upplösning än nödvändigt.

Komprimera bilderna för att minska storleken. Använd en bildkomprimerare för att ta bort onödig bildinformation som många bildhanteringsprogram sparar. Exempel på verktyg är Tiny PNG och SVGOMG.

Minska datamängden genom att komprimera filer och minifiera eller städa i kod

Ett effektivt sätt att minska datamängden mellan servern och klienten är att komprimera 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ör textbaserade filtyper (HTML-dokument, stilmallar, script).

Det dyker nu och då upp nya komprimeringsformat som är bättre än tidigare, till exempel på grund av högre komprimeringsgrad, snabbare komprimering eller mer öppet format. Ett exempel på detta är WebP som kan användas för komprimering av bilder. Även HTTP/2 komprimerar (header-)data. Nya format tar dock en stund innan de fungerar i all utrustning. Utnyttja gärna de bättre formaten om ni har kapacitet att samtidigt erbjuda äldre format så länge det behövs för att inte utestänga användare.

Även om det tar tid att komprimera och dekomprimera filer tjänar både server 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 vill säga bearbetas på ett sätt som gör att onödiga mellanslag och annat innehåll som inte påverkar presentationen rensas bort eller ersätts av kompaktare alternativ. Det finns verktyg som minifierar kod automatiskt. Nackdelen är att koden brukar bli svårare att läsa, men det är inte alltid ett problem. Dessutom finns verktyg som kan indentera och göra minifierad kod någorlunda läsbar igen.

Det är tyvärr fortfarande vanligt att såväl publiceringsverktyg som utvecklarramverk genererar mycket onödig kod, och även manuellt skapad kod kan ha innehåll som inte behövs. Ofta kan en städning av koden minska filstorleken och dessutom göra den lättare att underhålla.

Utnyttja cache-funktioner på rätt sätt

Principen för cache-funktioner är enkel: se till att klienten inte behöver hämta samma resurs flera gånger, om det inte behövs! Det finns många olika 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ändande användare ladda ner oförändrade filer på nytt om återbesöket är inom tidsspannet 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 att hantera som små paket, vars filnamn kan numreras. När en ny fil dyker upp på webbplatsen förbigår den tidigare cachade filer, vilket gör att dessa filer kan ha riktigt lång giltighet. En sida som genereras dynamiskt (till exempel utifrån innehåll i en databas) kan bara vara giltig så länge som alla beståndsdelar är oförändrade. Helt statiskt innehåll kan vara giltig mycket längre (månader).

Skicka korrekta statuskoder enligt HTTP-standarden. Exempelvis HTTP-kod 304 som berättar för webbläsaren att filen på servern har ett identiskt innehåll som den fil användaren redan har tagit emot och som därmed inte behöver skickas igen.

Generella resurser går ofta att hämta från centrala lagringsplatser. Exempelvis finns Javascript-biblioteket jQuery att hämta från Google Libraries API, Microsoft AJAX CDN och jQuery CDN. Genom att hänvisa till sådana ökar sannolikheten något för att klienten redan har resursen i sin cache, och därmed inte behöver hämta den på nytt. Dessutom minskar det datatrafiken ö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ösningar anvä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 ett alternativ.

Observera att det finns olika grader av beroende: I vissa sammanhang kan sidan besökas även om den externa resursen inte går att hämta (eller är förändrad), medan det i andra sammanhang bara påverkar en del av sidans funktionalitet.

Läs mer om tredjepartsinnehåll i R67 Se till att infogade externa tjänster följer webbriktlinjerna.

Tänk på hur sidan laddas

Många webbplatser är uppbyggda så att användaren inte kan börja interagera med en sida förrän hela sidan har laddats in och renderats. Ofta beror det på Javascript och CSS-selektorer som gör att webbläsaren måste rita om sidan flera gånger. Tänk därför igenom hur användaren påverkas av renderingen och om en del av beräkningarna istället kan göras på servern istället för i webbläsaren. Se även R93. Använd Javascript för att öka tillgängligheten – inte tvärtom.

Mätbarhet

De flesta moderna webbläsare har inbyggda utvecklarverktyg som kan visa hur lång tid det tar att hämta olika resurser som ingår i en webbsida. Ofta finns 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. En brant lutning bör eftersträvas eftersom det innebär kort väntetid.

Exempel på gratisverktyg som kan ge en bild av hur välbyggd en webbplats är utifrån prestandasynvinkel:

• Google Pagespeed Insights
• Pingdom Website Speed Test
• Sajtkollen – pedagogiskt nybörjarverktyg från Internetstiftelsen.
• Sitespeed.io
• WebPagetest – särskilt funktionen Visual Comparison

Som underlag för jämförelse kan nämnas att en undersökning av drygt 500 webbplatser inom svensk offentlig sektor gjordes i oktober 2016 med utgångspunkt i Google Pagespeed 2.0. Mätt med en mobilanvändares behov var genomsnittet 62 poäng av 100 möjliga. Googles riktlinje för bra webbprestanda är 85 av 100.

Fler tips på mätverktyg och kommentarer om prestandamätning.

Fördjupning

• CSS Sprites: Image Slicing’s Kiss of Death
• Caching Tutorial for Web Authors and Webmasters
• Google PageSpeed
• Brotli för att komprimera udda teckensnitt
• HTTP/2 förklarat
• Video: Fast and resilient web apps
• Video: Om hur man bygger webbplatser som inte är så beroende av uppkoppling till nätet och använder webbläsarens cacheminne fullt ut
• Förklaring: Vad är en cache?

Terminologi

Robusthet i webbsammanhang har två olika betydelser. Dels är det en av principerna i WCAG 2.0 (som handlar om kompatibilitet med största tänkbara variation av user agents), dels handlar det i prestandasammanhang om den infrastruktur som behövs för att en webbplats varken ska bli långsam eller gå ner.

Resilient innebär att konstruera en webbplats som är motståndskraftigt mot en hög belastning.

Cache är det som på svenska kallas buffer. Det är ett sätt att mellanlagra information på strategiska platser. När det gäller webben brukar cache ofta exemplifieras genom det cacheminne som finns i besökarens egen dator, den så kallade webbläsarcachen. Det gör upplevelsen snabbare om material som inte uppdaterats istället återanvänds från den egna datorns minne istället för att hämta på nytt över internet.

CDN står för Content Delivery Network, ibland Content Distribution Network. CDN används ibland för att öka prestanda genom att bygga upp en cache-funktion i nätet så att flera webbplatser kan hänvisa till samma filer. Om besökaren varit på webbplats A och laddat ner den senaste Jquery-filen behöver den inte laddas ner på nytt vid besök på webbplats B – förutsatt att webbplatserna använder samma CDN. Ytterligare en fördel med CDN är att resurser kan hämtas från servrar som geografiskt befinner sig närmare användaren, vilket också påverkar svarstiden.

CMS står för Content Management System, det vill säga publiceringssystem. Vissa publiceringssystem har omfattande funktioner för till exempel automatisk anpassning av bildfilers upplösning till mottagarens skärm eller uppkoppling, avancerad cachning och så vidare.

WebP är ett exempel på bildformat som är skräddarsytt för webben. Brotli är ett exempel på generellt komprimeringsformat.

AMP står för Accelerated Mobile Pages och är ett Googleprojekt som tagit fram en sorts begränsade webbsidor (där bara delar av html, css och javascript används) som kan laddas mycket snabbt i mobilen. AMP ger god prestanda, men nackdelen är att det inte är en standardlösning. Dessutom fungerar AMP i dagsläget bara i omedelbar anslutning till Googlesökning.

TTL betyder Time To Live och används i olika tekniska sammanhang för att ange hur länge en viss resurs (till exempel en fil, en uppkoppling eller ett datapaket) ska anses vara giltig. När tiden passerat byter systemen strategi, oftast genom att ”börja från början”.

Öppna länkar i nya fönster och flikar, eller inte?

WCAG 2.0 lösningsförslag G200 och webbriktlinjen R97. Se till att bakåtknappen fungerar rekommenderar att länkar inte ska öppnas i ett nytt fönster eller en ny flik, förutom i undantagsfall. Men rekommendationerna ifrågasätts ibland, och det finns webbplatser som regelmässigt öppnar alla externa länkar i nya fönster. Vi har gjort en sammanställning av för- och nackdelar som kommit fram när frågan diskuterats. Förhoppningsvis hjälper det dig att ta ställning till hur ni ska göra i er organisation.

Argument mot att öppna länkar i nya fönster

• WCAG 2.0, riktlinje 3.2 anger att webbsidans beteende ska vara förutsägbart, och i ett lösningsförslag anges försiktighet med att öppna nya fönster som ett sätt att följa riktlinjen.
• Attributet target, som används för att öppna länk i nytt fönster, kan inte användas i alla versioner av html om koden ska validera (men är ok i html5).
• Att öppna länkar i nya flikar kan innebära säkerhetsrisker.
• Låt användaren själv bestämma hur de vill öppna länkar och dokument – i en ny flik eller ett nytt fönster. Framför allt i en mobiltelefon kan det bli besvärligt med många nya öppna fönster.
• Försök inte tvinga användare att vara kvar på webbplatsen om informationen de söker finns någon annanstans. Att göra så bryter mot principen att skapa en webbplats som utgår från användarnas behov.
• Om man råkar stänga ett fönster eller en flik av misstag kan man öppna den igen genom webbläsarens historik. Alla användare kanske inte känner till det, men det fungerar.
• Bakåt-knappen är en av de mest använda funktionerna i en webbläsare och ska fungera i alla situationer, vilket den inte gör om sidan öppnats i ett nytt fönster eller ny flik.
• Webbstatistiken riskerar att bli felaktig. Om det finns länkar till en pdf som öppnats i nytt fönster vet inte exempelvis Google Analytics om du är kvar på sidan eller om du har öppnat pdf:en.

Argument för att öppna länkar i nya fönster

• Användaren riskerar att förlora information som inte är sparad (till exempel i ett formulär) genom att följa en länk som öppnas i samma fönster.
• Det kan förhindra besvär om användaren har påbörjat uppspelning av musik eller till exempel en podcast på din sida, och det kan bli svårt att hitta tillbaka till den om en länk som öppnas i samma fönster gör att spelningen upphör.
• Att öppna externa länkar i nya fönster kan öka sannolikheten för att besökaren ska återuppta sitt besök när det nya fönstret stängs.
• Alla vet inte att man kan högerklicka och själv välja om man vill öppna i ny flik eller nytt fönster.
• Genom att öppna externa länkar i nya fönster blir det tydligare att användaren har lämnat sajten. Det skulle till exempel kunna minska risken att användaren avslöjar information för den länkade webbplatsen som egentligen bara borde avslöjas för din webbplats.
• Att klicka på en länk handlar inte alltid om att en person vill bort från webbplatsen, det kan lika gärna handla om nyfikenhet. Att klicka går av bara farten. Då kan det vara bra om den ursprungliga sidan finns kvar.
• Vissa användare upptäcker inte att webbplatsen eller dokumentet öppnas i samma fönster och hinner stänga det med krysset innan de inser det.

Men öppna i nya flikar då?

Istället för att öppnas i nya fönster kan länkar öppnas i nya flikar. Men i grunden gäller samma argumentation som för nya fönster, och framför allt är det inte säkert att du kan välja om en länk ska öppnas i en flik eller i ett fönster. I vissa fall är det tekniskt möjligt, men generellt är det ett val som användaren förväntas göra, antingen i webbläsarens inställningar eller i samband med att länken följs.

Ange tydligt vart länken går

Oavsett vad ni väljer, var tydlig och tala om i länktexten vart länken leder och tala om att den öppnas i nytt fönster om ni har valt det. Visa gärna med en symbol att användaren kommer till en ny webbplats. Följande bild visar hur det kan se ut när en länk leder till en annan webbplats (exempel kommer från regeringens webbplats):

Länka till nytt fönster – eller hämta hem samma information?

Webbriktlinjernas grundrekommendation är alltså att vara försiktig med att öppna nya fönster eller flikar, med några undantag. Webbriktlinje 97 räknar upp ett antal undantag. Det gäller till exempel när användaren är i ett flöde som inte bör brytas och länkarna leder till innehåll som kompletterar flödet såsom hjälpinstruktioner, en kalenderbaserad datumväljare i ett formulär et cetera.

Ett alternativ det läget är att visa den kompletterande informationen i sitt sammanhang istället för att öppna nytt fönster. Det fungerar oftast bra, till exempel om informationen delas upp i mindre bitar.

Vad tycker du?

Huruvida länkar bör öppnas i nya fönster/flikar eller inte är en fråga som återkommer nu och då, och tenderar att väcka ett starkt engagemang. Frågan har bland annat diskuterats i Facebookgruppen Webbriktlinjer. Fortsätt gärna på den diskussionen om du har nya infallsvinklar, förslag och frågor!

Utkast till ny version av riktlinje om kontaktinformation

Här följer ett utkast till ny version av riktlinjen R4. Gör det lätt att komma i kontakt med er.

2017-07-02: Uppdatering: Riktlinjen är uppdaterad i enlighet med detta utkast. Synpunkten om sociala medier i kommentarsfältet tar vi upp igen senare.

Gör det lätt att komma i kontakt med er

Må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 att ange samtliga möjliga kontaktvägar såsom adresser, sociala mediekanaler, telefonnummer och öppettider.

Rekommendationer för tydliga kontaktsidor

• Gör det lätt att hitta kontaktinformationen.
• Se till att ha grundläggande information på kontaktsidan.
• Erbjud kontaktformulär och informera om övriga kontaktvägar.
• Informera om fysisk tillgänglighet.

Gör det lätt att hitta kontaktinformationen

Fö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 i sidfoten, så att den blir lätt nå från webbplatsens samtliga sidor. För mobila besökare ska kontaktinformationen vara lätt åtkomlig via navigeringen och sidfot. Säkerställ också att kontaktinformationen är tillgänglig från andra digitala tjänster som till exempel e-tjänster eller meddelanden som når användaren via en digital brevlåda.

Se till att ha grundläggande information på kontaktsidan

Webbplatsens kontaktsida ska innehålla:

• Organisationens namn
• Information om organisationen
• Adresser
• Telefonnummer till växeln eller kundtjänst
• E-postadress till registrator, om det finns i organisationen

Markera telefonnummer i koden som telefonlänkar (tel:). Det ger möjlighet att direkt ringa upp numret, på samma sätt som e-postlänkar (mailto:) ger möjlighet att skicka e-post. Se även R90. Gör det enkelt att ringa upp telefonnummer 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 information om det är öppet just i den stund användaren läser informationen och hur lång tid det är kvar tills ni stänger. Upplys också om tidpunkter under dagen då trycket på er kundservice är lägre.
• Besöksadress, karta och vägbeskrivning (både för bil, gång, cykel och med kollektivtrafik). Fotografi på entrén underlättar också för användaren.
• Sociala mediekanaler.
• Om ni vill att användaren identifierar sig med e-legitimation vid personliga ärenden, exempelvis för att få svar via en chatt eller per telefon.

Erbjud kontaktformulär och informera om övriga kontaktvägar

Underlätta även för de användare som föredrar andra kontaktvägar, till exempel genom att erbjuda ett kontaktformulär. Låt exempelvis användaren välja ärendekategori och sen beskriva sitt ärende i ett fritextfält. Ge användaren tydlig återkoppling på att ärendet mottagits och när hen kan fö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, mina sidor 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, till exempel 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 inte har 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 av funktionsnedsättning inte kan använda vanlig telefoni:

• Personer med behov av teckenspråkstolkning kan använda sig av bildbaserad kommunikation som till exempel bildtelefoni.net eller videomö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 chatt och texttelefoni.se.
• personer med behov av tal-, minnes- och anteckningsstöd (på grund av nedsatt tal- eller minnesfunktion) kan använda teletal.se.

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

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

Informera om lokalers tillgänglighet

På kontaktsidan bör ni även informera om den tillgängligheten om användaren väljer att besöka er. Upplys exempelvis hur entrén är utformad och om det finns en ramp, teleslinga, om det finns speciella avsedda parkeringsplatser eller toaletter för personer med funktionsnedsättning. Läs gärna Myndigheten för delaktighets riktlinje för tillgänglighet, Riv hindren (pdf, 1,2 MB).

Exempel

Kontaktsida på Pensionsmyndigheten

Mätbarhet

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

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

Fördjupning om kontaktinformation

Andra webbriktlinjer som kan vara aktuella för era kontaktsidor är R38. Möjliggör synpunkter, frågor och dialog och R20. Informera om hur personuppgifter, kakor (cookies) mm hanteras.

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

Evig bläddring / oändlig scroll – användbart och tillgängligt?

Evig bläddring eller oändlig scroll är en teknik som gör att innehållet laddas in kontinuerligt allt eftersom användaren scrollar ner på sidan. Fördelen med tekniken är bland annat att det eliminerar behovet av sidnumrering och är lätt att använda på pekskärmar. På så vis underlättar det antagligen för personer med begränsad motorisk precision.

Tekniken är vanlig på sociala medie-sajter som till exempel Twitter eller Facebook där det hela tiden fylls på med mer innehåll. Innehållet får en platt struktur eftersom varje del läggs på samma nivå och ges samma prioritet som övrigt innehåll. På så sätt får olika delar av innehållet lika stora chanser att bli intressant för användarna.

Tekniken fungerar ofta bra på sidor som presenterar olika produkter, till exempel kläder. Men tänk på att det kan vara svårt för en användare att hitta tillbaka till en produkt eller ett innehåll som hen hittat tidigare eftersom det inte finns några sidor att hänga upp minnet på.

Däremot fungerar inte tekniken så bra för webbplatser där målet är att användaren ska lösa vissa uppgifter, för tjänster eller webbplatser som kräver att användarna ska hitta eller kanske jämföra specifik information. Då är det bättre att lyfta innehållet på ett annat sätt, till exempel genom att gruppera information på ett traditionellt sätt genom en hierarkisk struktur eller paginering. Det ger också användarna mer kontroll över innehållet kan bestämma om de vill ha mer innehåll eller inte, eller när de ska fortsätta till nästa sida eller en annan del av webbplatsen.

Det finns några nackdelar med evig bläddring.

Bakåt-knappen och bokmärkning kan förlora sin funktion

Om en användare har klickat sig från en sida med evig bläddring till en annan sida och använder bakåt-knappen hamnar hen ofta överst på sidan och inte vid det innehållet hen var vid. Det har kan bli ett användbarhetsproblem för de flesta. För en person med en kognitiv funktionsnedsättning kan det ställa till ännu större problem om hen inte hamnar vid det innehåll man var vid tidigare och tänkt komma tillbaka till. Ofta går inte heller innehåll att bokmärka på ett enkelt sätt.

Det här kan lösas med exempelvis kakor eller med Javascript History Api, men det å andra sidan kan ställa till det för personer som valt att inte acceptera kakor eller stängt av Javascript i sin webbläsare.

Svårt att veta hur mycket innehåll som finns

Rullningslisten är en indikation till användaren om hur mycket innehåll som finns på sidan. På en sida som använder evig bläddring förlorar användaren den kunskapen och kan bli lurad när man tror att man kommer till botten av sidan och helt plötsligt kastas högt upp på sidan igen när nytt innehåll laddas in.

Evig bläddring kan ta processorkraft eller minne från webbläsaren

Om inte tekniken implementeras på rätt sätt kan evig bläddring orsaka prestandaproblem. Och om sidan är mycket lång laddas mer och mer innehåll in som kan påverka minnet hos webbläsaren.

Var tog sidfoten vägen?

I sidfoten förväntar sig användare att hitta information såsom kontaktuppgifter, sociala medie-länkar och andra länkar på webbplatsen. Med evig bläddring skjuts sidfoten bara längre och längre utom räckhåll för användaren. Det finns de som jämför det med åsnan som försöker få tag på en morot – den är alltid liiiite utom räckhåll. För att lösa problemet kan man använda en så kallad ”sticky” sidfot, men det tar å andra sidan skärmutrymme.

Webbanalys kan bli svårare

Evig bläddring kan försvåra webbanalysen. I grundutförandet kommer inte statistiken att ge dig som webbplatsägare insikt hur dina besökare använder webbplatsen. Du kommer att behöva en skräddarsydd lösning för ditt statistikprogram.

Ge användaren möjlighet att välja

Om du ändå vill använda evig bläddring på grund av att du har ett innehåll som passar för det, ge användarna möjlighet att välja evig bläddring eller inte. Om de vill, ge dem möjlighet att istället få en Ladda in mer-innehåll-knapp.

Tangentbordsnavigering kan bli tröttsamt

För personer som enbart använder tangentbordet och kortkommandon för att navigera kan evig bläddring ställa till problem. Om en användare till exempel försöker använda tangentkommandot ctrl + end för att komma till botten på sidan kommer det oftast inte att fungera eftersom webbplatsen hela tiden laddar in mer innehåll eller struntar i kommandot och istället placerar användaren i toppen av sidan.

Förvirrande för skärmläsare?

Det kan bli förvirrande för en person som använder en skärmläsare om en sida utan förklaring bara fortsätter i alla oändlighet men om man använder aria-taggar som talar om för skärmläsaren att nytt innehåll läggs in på sidan kontinuerligt borde det också gå att lösa.

Som så ofta går många användbarhets- och tillgänglighetsproblem att lösa om man tänker efter i förväg och implementerar tekniken på ett tillgängligt sätt. Eller vad tror ni?

Vi tar gärna emot dina synpunkter på det här inlägget. Kommentera eller använd någon av de kommunikationsvägar vi hänvisar till i sidfoten.

PTS ansvarar för Vägledningen för webbutveckling

Post- och telestyrelsen har regeringens uppdrag att ansvara för Vägledning för webbutveckling. Idag 2016-03-14 flyttades webbplatsen från E-delegationens webbhotell till PTS. Eventuella problem de närmaste dagarna beror troligen på serverbytet. Meddela oss gärna om du upplever problem, så ska vi försöka åtgärda så snart som möjligt! Kontaktuppgifter finns i sidfoten och på sidan om webbplatsen.

Pär Lannerö, projektledare

Webbriktlinjer på ditt format

Nu kan du hämta hela Vägledningen för webbutveckling till en kommaseparerad textfil som du själv kan konvertera till lämpligt format.

Dynamisk exportfunktion

Gör helt enkelt ett urval på sidan för sökning/filtrering av riktlinjer och tryck sedan på länken ”Exportera urval som csv” som du hittar nedanför sökresultatet. Då laddas motsvarande riktlinjer ner som kommaseparerad textfil. Den filen kan du sedan öppna och bearbeta i valfritt program (t.ex. Google Drive Kalkylark, Apple Numbers, eller MS Excel).
Du kan till exempel lägga till kolumner som status, egen prioritering, ansvarig osv, och anpassa kolumnbredd mm efter dina behov. Eller importera filen i ett ärendehanteringssystem eller att-göra-program.

Öppna data med sökbart api

Förutom att du manuellt kan göra utdrag finns det möjlighet att hämta data maskinellt. API:et finns dokumenterat på adressen webbriktlinjer.se/psidata/. I praktiken innebär detta att (åtminstone delar av) webbriktlinjerna finns som öppna data, något som för övrigt uppmuntras i riktlinjen R89. Gör det möjligt för andra att återanvända webbplatsens innehåll.

Bakgrund

När myndigheten Verva tidigare ansvarade för Vägledningen för webbutveckling publicerades materialet inte bara som webbplats utan även som tryckt bok och som kalkylark (t.ex. Excel). Det var länge sedan senaste tryckning, men de senaste åren har den som vill kunnat ladda ner eller skriva ut alla riktlinjer på PDF-format. Själv har jag dock saknat kalkylarket, eftersom det är ett smidigt verktyg när man t.ex. systematiskt försöker stämma av en webbplats mot webbriktlinjerna.

Men precis som med trycksaker blir statiska kalkylark undan för undan inaktuella. Riktlinjerna uppdateras och förbättras ju kontinuerligt. Därför har vi lagt resurserna på att istället göra en dynamisk exportfunktion.

Utveckling pågår

Vi har lite snabbt skapat exportfunktionen, men betraktar den inte som färdig. Det finns t.ex. tankar på att erbjuda fler utmatningsformat. Till exempel RSS eller något format med formgivning, kryssrutor osv. Vi vill gärna ha dina synpunkter. Hur vill du använda webbriktlinjerna?

Skapa medvetenhet om tillgänglighet

Idag är den internationella tillgänglighetsmedvetenhetsdagen (global accessibility awareness day – GAAD) och du är inbjuden!

Ungefär en femtedel (beroende på hur man räknar) har någon funktionsnedsättning, och alla har särskilda behov ibland. Till exempel på grund av stress, trötthet, buller, rörelse eller tillfälliga åkommor. Ändå är det vanligt att digitala miljöer fungerar dåligt för användare med en annan funktionsuppsättning än vad utvecklaren själv har. Webbansvariga är i alltför liten utsträckning medvetna om hur stora variationer som finns mellan människors förmågor och behov.

Det finns mycket du kan göra för att hjälpa till att öka medvetenheten. Här är några förslag:

• Provlyssna på din egen webbplats med en skärmläsare. Till exempel VoiceOver som finns i Apples system eller TalkBack som finns på Android-plattformen.
• Testa tillgängligheten på din webbplats med ett automatiskt testverktyg eller helst även manuellt eftersom inte alla aspekter går att testa med automatik.
• Anmäl dig till PTS innovationsdag. Där kommer ett stort antal satsningar för mer tillgänglig IT att presenteras.
• Testa att använda din sajt med endast tangentbord och få insikter om hur det är att inte kunna använda mus (pga t.ex. förslitningsskada).
• Titta på filmerna #webbföralla där olika personer berättar vad en tillgänglig webb kan betyda för dem.
• Skriv ett blogginlägg om tillgänglighet eller använd hashtaggen #gaad i sociala medier.

Det finns fler förslag på den internationella sajten för GAAD och du får gärna skriva in ytterligare ideer i kommentarsfältet om du vill. Det viktiga är att göra någonting. Gärna idag!

Ny, mer användbar prioritering på riktlinjerna

Vi har valt att överge den tidigare prioriteringen som gick från 1-3 och istället valt en prioritering som numera går från 1-5. Orsaken är att vi fått kritik för att nästan alla riktlinjer hade prioritet 1 och att det då blev svårt att veta i vilken ände man skulle börja.

Webbriktlinjerna har tidigare haft myndigheter som huvudsaklig målgrupp, men vänder sig nu till alla som har en webbplats. Många av dem är små aktörer med begränsade resurser. Alla har inte ens möjlighet att läsa igenom alla riktlinjer. Det är bättre att börja i någon ände och göra någonting än att bli överväldigad av webbriktlinjernas omfattning och inte göra något alls.

Om ni har begränsade resurser eller behöver prioritera av någon annan anledning, börja med de riktlinjer som har prioritet 1. Därefter riktlinjer med prioritet 2 till 5 i fallande ordning. Observera att riktlinjerna med prioritet 2-5 också är viktiga. Vissa av dem kan till och med vara nödvändiga för din målgrupp, även om de inte hamnar först i vår prioritering. Anpassa därför detta förslag efter aktuella förutsättningar.

Som underlag för vårt förslag har vi bedömt varje riktlinje utifrån följande aspekter:

• Hur många personer berörs av riktlinjen?
• Hur mycket påverkas de som berörs om riktlinjen inte följs?
• Är det vanligt med ”brott” mot riktlinjen?
• Är riktlinjen central inom sitt område?

Prova gärna själv den nya prioriteringen.

Vi tar gärna emot dina synpunkter på den nya prioriteringen. Använd någon av de kommunikationsvägar vi hänvisar till i sidfoten.

Nu skriver vi om webbriktlinjerna

Vi skriver om webbriktlinjerna för att de ska bli tydligare, enklare och mer begripliga.

Denna vecka publicerar vi de första riktlinjerna som

• bearbetats enligt principer för klarspråk
• anpassats för att lättare kunna hittas med hjälp av sökmotorer
• från och med nu riktar sig till alla som har webbplatser – inte bara till myndigheter.

Vi gör samtidigt några andra mindre justeringar. Till exempel uppdaterar vi kategorisering och taggar, och i några fall kommer vi att slå ihop riktlinjer. Syftet med just denna bearbetning är inte att ändra på riktlinjernas innebörd. Sådana förändringar planeras också, men oberoende av den språkliga revideringen. Till exempel kommer vi att behandla mobil tillgänglighet mer utförligt inom kort.

Arbetet sker i samarbete med språkkonsulter från Expressiva och Metamatrix och beräknas vara klart i början av hösten 2014.

Klarspråk

”Begriplig” är en grundprincip i den internationella standarden för tillgängligt webbinnehåll (WCAG 2.0). Den första och kanske mest centrala riktlinjen i Vägledningen för webbutveckling är en hänvisning till just WCAG 2.0, och vi har även flera andra riktlinjer relaterade till klarspråk. Självklart vill vi leva som vi lär, och därför bearbetar vi nu både språk och dokumentstruktur för att riktlinjerna ska bli så begripliga som möjligt.

Det innebär till exempel att vi anpassar verb till uppmaningsform, skriver ut förkortningar och använder mellanrubriker och punktlistor som stöd för användare som snabbt vill ta till sig det viktigaste. Till exempel kommer varje riktlinje att innehålla en punktlista med rekommendationer som sammanfattar riktlinjen.

Sökbarhet

Många använder sökmotorer för att hitta relevant innehåll på nätet. En förutsättning för att du ska hitta en relevant sida med hjälp av en sökmotor är att sidan, eller någon sida som länkar till den, innehåller (någon variant av) de ord du skriver in i sökrutan. Ofta finns det flera olika ord som beskriver samma sak, och för att ingen som behöver hitta en riktlinje ska missa den på grund av att vi valt ett annat ord kommer vi framöver att räkna upp vanliga synonymer när vi känner till sådana. Det gör vi längst ner på sidan, under rubriken Terminologi. Samma avsnitt förklarar också ord som vi tror kan vara okända eller svåra för vissa besökare.

Breddad målgrupp

Tidigare har webbriktlinjerna i huvudsak vänt sig till myndigheter, men under 2014 är ambitionen att även nå andra som vill hålla en hög kvalitet på sina webbplatser. Därför ändrar vi tilltalet i riktlinjerna så att det inte står ”myndigheten skall…” på var och varannan sida. Ett fåtal riktlinjer är dock riktade främst till just myndigheter (till exempel de som har med arkivlagen att göra), och där kan den sortens formulering kvarstå. Om du vill filtrera bort riktlinjer som inte berör dig som privat aktör kan du använda den filtreringsfunktion som samtidigt är under utveckling.

Tidigare versioner finns i pdf-utdragen

Du hittar en datumstämpel och en kort kommentar om ”klarspråksbearbetning” på varje riktlinje som vi hunnit skriva om. Om du vill jämföra de nya versionerna med äldre kan du till exempel läsa en äldre upplaga av den pdf-version av vägledningen som genereras varje månad.

Kommentera gärna!

Vägledningen för webbutveckling är ett ganska stort material, och självklart kan det finnas felaktigheter i riktlinjerna. Hör gärna av dig, antingen till info@webbriktlinjer.se, med hjälp av kommentarsfälten på varje sida, eller via facebookgruppen Webbriktlinjer, om du hittar fel eller på annat sätt vill kommentera riktlinjerna! Eller anmäl oss till närmsta språkpolis, så kanske riktlinjerna kan få litet extra uppmärksamhet…

Vidareutveckling under 2014

Sedan senhösten 2013 pågår ett samarbete mellan E-delegationen och Post- och Telestyrelsen (PTS) vars huvudsakliga syfte är att öka tillgängligheten på svenska webbplatser för personer med funktionsnedsättningar. En viktig del av detta arbete är att vidareutveckla och marknadsföra Vägledningen för webbutveckling.

Vi genomför just nu en klarspråksbearbetning av hela webbriktlinjer.se. Förutom att göra texterna mer lättlästa är syftet att förbättra sökbarheten, och att anpassa tilltalet även till andra än myndigheter. Nya texter är också på gång som tar upp webbutveckling för användare med t.ex. mobila webbläsare. En hel del andra förbättringsåtgärder är påbörjade eller planerade, och vi kommer att presentera webbriktlinjerna och lyfta frågor om tillgänglighet på webben på ett antal konferenser och möten under året.

Kontakta oss gärna (t.ex. med epost till info snabel-a webbriktlinjer.se) om du har förslag eller frågor, eller gå med i Facebookgruppen Webbriktlinjer!

Vägledningen som pdf

Nu kan du ta del av Vägledningen för webbutveckling som pdf. Varje månad skapas en ny pdf utifrån innehållet på webbriktlinjer.se som du kan ladda ner och använda samt referera till vid upphandling. Länken finns under ”Riktlinjer” i menyn ovan.

HTML eller XHTML?

Tommy Olsson, ledare för arbetet med teknik och standarder i arbetsgruppen som tagit fram den nya versionen av Vägledningen för webbutveckling och även tidigare versioner av den har broderat ut texten lite kring HTML och XHTML. Till vardags arbetar Tommy på Bolagsverket och han har skrivit böcker med fokus på webbstandarder.

Vägledningen för webbutveckling är godkänd

Idag skrev Edelegationens ordförande Annika Bränström, också generaldirektör på Bolagsverket, under Vägledningen för webbutveckling. Vägledningen gäller alltså officiellt från och med idag. Under hösten kommer Edelegationen skapa en förvaltningsgrupp för vägledningen med syfte att ta hand om synpunkter, utöka och korrigera vägledningen vid behov samt att skapa stödmaterial som checklistor och liknande.

Ändringar i riktlinjer

Ett antal riktlinjer har uppdaterats.

Vägledningen för webbutveckling på öppen remiss

Arbetet med Vägledningen för webbutveckling har pågått under ett par år och är nu äntligen klart för remissbehandling.

Följ kommentarer på riktlinjer via twitter

Tack vare Isac Lagerblad (@icaaq på twitter) kan du nu följa kommentarer på riktlinjer på webbriktlinjer.se genom @vlkommentar på twitter.

Små uppdateringar på riktlinjer

Ett antal riktlinjer har idag ändrats för att vara lättare att läsa och i några fall förtydligats eller ändrats något innehållsmässigt.

Webbriktlinjer.se lanseras på webbsänd fördjupningsdag 29 maj

Den 29 maj presenteras webbriktlinjer.se på konferensen Offentliga rummet i Uppsala. Vägledningen för webbutveckling har en egen fördjupningsdag som kommer webbsändas på http://edelegationen.se/sidor/webbtv.