Alla nyheter

22 juni, 2017

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.

20 maj, 2017

Utkast till ny version av riktlinje 54 om prestanda

Här följer ett utkast till ny version av riktlinjen R54. Optimera webbplatsen för bästa prestanda.

Kommentera gärna med hjälp av kommentarsfunktionen sist på sidan eller i Facebookgruppen webbriktlinjer eller med 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 till servern

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. För varje http-anrop upprättas en anslutning till servern, och varje sådan anslutning tar tid.

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 alla besökare 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. Två aktuella exempel (2017) är WebP för bilder och Brotli för generell komprimering. Även http/2 komprimerar data. Nya format tar dock en stund innan de fungerar i all tänkbar 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 (till exempel Javascript-biblioteket jQuery) går ofta att hämta från centrala lagringsplatser, som Google Libraries API. 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. Men 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. 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.

Exempel på hur verktyg för prestandaoptimering på webben kan se ut.
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:

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

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. Användaren upplever en mycket hög prestanda, men det är inte en standardlösning och den fungerar 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”.

15 maj, 2017

Ö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. En fördel med detta är att flikarna kan uppfattas som ett mer välordnat sätt att ha många webbsidor framme samtidigt. Det kan vara värdefullt för en läsare att behålla ett antal flikar öppna med referensartiklar eller liknande. 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!

15 maj, 2017

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.

 

13 april, 2016

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.

14 mars, 2016

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

5 juni, 2015

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?

21 maj, 2015

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!

19 december, 2014

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.

5 december, 2014

Välbesökt seminarium om Tillgänglig webb

Den 2 december arrangerade E-delegationen, Användningsforum och Post- och telestyrelsen kursdagen Tillgänglig webb. Frågan om tillgänglighet är högaktuell, eftersom bristande tillgänglighet för personer med funktionsnedsättning införs som en ny form av diskriminering i diskrimineringslagen från den 1 januari 2015.

Sex föreläsare fyllde eftermiddagen med matnyttig kunskap om varför tillgänglighet är viktigt.

Ta del av Tillgänglig webb nu i efterhand

Mikael Holmgren och Ulrika Gani från den nya Myndigheten för delaktighet berättade om den nybildade myndigheten och dess uppdrag som bygger på FN:s konvention om mänskliga rättigheter

Pär Lannerö, E-delegationen, berättade bland annat om E-delegationens vägledning för webbutveckling dit webbplatsen www.webbriktlinjer.se tillhör.

Stina Johansson från ETU delade med sig av 7 tips för att skapa mer tillgängliga webbplatser.

Stefan Johansson från projektet Begripsam berättade om hur man kan sänka de kognitiva trösklarna för att skapa en inkluderande webb.

Johan Gustafsson från Arbetsförmedlingen föreläste om hur man på Arbetsförmedlingen arbetar med tillgänglighetsarbete i sina digitala kanaler.

Moderator Pia Flodquist presenterade ett nytt webbverktyg för att testa graden av tillgänglighet på webbplatser. Verktyget finns på webbriktlinjer.se/testa

På Twitter kan du diskutera tillgänglighet på webben med hjälp av hashtag #webbföralla.

25 juni, 2014

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…

1 april, 2014

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!

3 december, 2012

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.

28 juni, 2012

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.

28 juni, 2012

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.

27 juni, 2012

Ändringar i riktlinjer

Ett antal riktlinjer har uppdaterats.

10 juni, 2012

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.

6 juni, 2012

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.

6 juni, 2012

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.

25 maj, 2012

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.