Alla nyheter

2 oktober, 2018

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.

 

25 september, 2018

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:

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.

21 augusti, 2018

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.

21 augusti, 2018

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.

31 maj, 2018

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

Kommentera till exempel i kommentarsfunktionen sist på sidan och i Facebookgruppen webbriktlinjer eller genom epost till info@webbriktlinjer.se.

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.


Rekommendationer för HTML-kompatibilitetLänk hit

  • Följ en HTML-standard från W3C
  • Testa och åtgärda problem i de kombinationer av webbläsare, operativsystem och hårdvara som är vanligast i målgruppen.
  • Testa och åtgärda problem med de hjälpmedel (exempelvis skärmläsare) som är vanligast i målgruppen
  • Var lyhörd för användarnas problem och följ upp användningen

Följ en HTML-standard från W3CLänk hit

Grundkravet att webbplatsen ska följa standarder (R80) innebär när det gäller sidans grundläggande kod att det är HTML enligt rekommendation från webbens standardorganisation W3C (the Worldwide web consortium).

För nya webbplatser bör den senaste stabila rekommendationen användas, så snart det finns tillräckligt stöd för den i de webbläsare som används av målgruppen. För närvarande (maj 2018) är detta version 5.2.

Att byta html-version för en befintlig webbplats innebär i praktiken oftast en fullständig omdesign. Eftersom html-specifikationen ställer stora krav på webbläsare att vara bakåtkompatibla så är det sällan nödvändigt att byta version bara för att det  finns en nyare version. Byt istället när det blir naturligt i samband med en större förnyelse av webbplatsen eller när ni behöver använda er av egenskaper som bara finns i en nyare version.

Oavsett val av HTML-version är det viktigt att följa Se till att koden validerar (R84).

Att använda en standardiserad html-version korrekt är en relativt enkel och billig åtgärd som gör att resultatet blir bra för de flesta användarna.


Testa och åtgärda problem i de kombinationer av webbläsare, operativsystem och hårdvara som är vanligast i målgruppenLänk hit

Ni är inte skyldiga att stödja webbläsare som kraftigt avviker från standarden, till exempel äldre webbläsare. Dessa kan fortfarande visa innehållet, men presentationen och funktionerna kanske inte fungerar som ni avsett. Följ webbstatistik och gör en bedömning vilka ni behöver stödja.

Men eftersom vissa organisationer använder gamla webbläsare, och det finns brister även i uppdaterade webbläsare räcker inte grundkravet för att skapa en webbplats som fungerar för precis alla. Varje projekt behöver alltså, förutom att uppfylla grundkravet, se till att resultatet i praktiken blir tillräckligt bra för tillräckligt många. Det finns verktyg för systematisk (delvis automatiserad) testning i olika kombinationer av webbläsare, skärmstorlek och operativsystem men tyvärr är det omöjligt att uppnå 100%. Var gränsen för tillräckligt går behöver därför anpassas efter behov, konsekvenser och resurser:

  • För en webbplats med höga krav (exempelvis Skatteverkets e-tjänst för deklaration) kanske det, förutom grundkravet, är rimligt att varje sida testas och åtgärdas för att fungera i de webbläsare som tillsammans har en marknadsandel på exempelvis 99%.
  • För en webbplats med mer genomsnittliga krav (exempelvis en skolas webbplats) kan det vara rimligt att förutom grundkravet om validerande kod även testa varje sidtyp med de fem vanligaste webbläsarmodellerna på åtminstone tre olika typiska skärmupplösningar.
  • För en webbplats med fokus på budget och snabbhet  (exempelvis en projektsajt) kan det kanske räcka att validera koden, testa all ny funktionalitet med de två webbläsare som är vanligast i målgruppen, och uppmana användare att rapportera in problem.

Det finns webbläsarstatistik på till exempel https://browsersverige.se men kanske får du mer relevant statistik för just din målgrupp i din egen webbanalys.


Testa och åtgärda problem med de hjälpmedel (exempelvis skärmläsare) som är vanligast i målgruppenLänk hit

Även när det gäller test i hjälpmedel måste ambitionsnivå anpassas efter behov, konsekvenser och resurser.

Utifrån statistik om skärmläsare och tips från Synskadades riksförbund föreslår vi följande:

  • För en webbplats med höga krav, testa och åtgärda problem med åtminstone skärmläsarna Jaws, Supernova, VoiceOver, Narrator.
  • För en webbplats med mer genomsnittliga krav, testa och åtgärda problem med skärmläsarna VoiceOver/iOS och Jaws/Windows.
  • Testa alltid med åtminstone EN skärmläsare, förslagsvis VoiceOver på iOS.

Var lyhörd för användarnas problem och följ upp användningenLänk hit

Oavsett kravnivå är det alltid lämpligt att, så långt som resurserna räcker, följa upp användningsstatistik och kundtjänstärenden för att kunna åtgärda återkommande problem. Se artikeln Följ upp hur webbplatsen används.

Och självklart är det viktigt att vara lyhörd för kommentarer från användarna. Se Möjliggör synpunkter, frågor och dialog (R38).


MätbarhetLänk hit

För att kontrollera om en sida följer den standard ni valt för uppmärkningskod kan ni använda W3C:s valideringsverktyg. Verktyget kan utgå från länkar till sidor eller uppladdad HTML-kod för sidor som ännu inte är publikt tillgängliga. W3C har även ett verktyg för att kontrollera stilmallar.


FördjupningLänk hit


TerminologiLänk hit

Webbutvecklare som vill använda funktioner som vissa användares utrustning ännu inte kan hantera väljer ibland att använda så kallade shims eller polyfills. En shim eller polyfill för HTML5 är ett tillägg som tillför funktionalitet som saknas (oftast JavaScript-kod). Metoden har sina fördelar, men tänk på grundprincipen om progressiv förbättring, som beskrivs i webbriktlinjen Använd Javascript för att öka tillgängligheten – inte tvärtom (R93).

20 april, 2018

Halvdag om tillgänglig video på webben

Symboler för tillgänglig video
Om textning, syntolkning och teckenspråkstolkning
(använd gärna symbolerna)

Under 2018 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

Konferensen spelades in. Du kan redan ta del av den teckenspråkstolkade och live-syntolkade inspelningen på YouTube. (Textad och syntolkad version kommer så småningom.) Inspelningen är 4 timmar. Här följer direktlänkar till respektive presentation:

  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 – användarperspektiv
    Mattias Lundekvam, ordförande för Hörselskadades riksförbund
  4. Textning av webbvideo – produktions- och beställarperspektiv
    Richard Gatarski producent på WestreamU. Richard har även publicerat sina presentationsbilder och en artikel om textning.
  5. Textning av webbvideo – kommentarer och frågor från deltagare
  6. Syntolkning av webbvideo – användarperspektiv
    Henrik Götesson, handläggare IT- och konsumentfrågor på Synskadades riksförbund. Henriks presentationsbilder (pdf, 600 kByte). Mer om syntolkning från SRF.
  7. Syntolkning av webbvideo – produktions- och beställarperspektiv
    Magnus Johansson, syntolkningsproducent på Iris media
  8. Syntolkning av webbvideo – kommentarer och frågor från deltagare
  9. Vad kan webbansvariga lära av SVT:s tillgänglighetsarbete?
    Lars Samuelsson, tillgänglighetsansvarig för SVT online
  10. Teckenspråkstolkning av webbvideo – användarperspektiv
    Isabella Hagnell, generalsekreterare Sveriges dövas riksförbund
  11. Teckenspråkstolkning av webbvideo – produktions- och beställarperspektiv
    Mindy Drapsa, företagsledare Dramaski
  12. Teckenspråkstolkning av webbvideo – kommentarer och frågor från deltagare
  13. Tillgänglig webbvideo, erfarenheter och framtidsspaning
    Mia Ahlgren, policyhandläggare, Funktionsrätt Sverige. Mias presentationsbilder (pdf, 800 kByte)
  14. 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.
15 februari, 2018

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.

15 februari, 2018

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.

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

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

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.