Tillgänglighetshandbok

II: 1. Inledning

1.1 Syftet med handboken

I första delen av tillgänglighetshandboken gick vi igenom grunderna för tillgänglighet och behandlade olika sätt att använda digitala tjänster. Vi presenterade också de centrala punkterna i det europeiska tillgänglighetsdirektivet och dryftade vilka effekter direktivet kommer att ha på kommunernas webbtjänster.

I den föreliggande andra delen går vi närmare in på hur tillgängligheten säkerställs som en del av projektet att bygga om webbplatser. Framför allt vill vi skapa beredskap för kommunerna att integrera tillgänglighet i upphandling av webbtjänster. I handboken går vi igenom de viktigaste tillgänglighetskraven för att kommunerna bättre ska förstå vad tillgängliga webbtjänster betyder. Vi går också till botten med de krav på tillgängligt innehåll som alla som dagligen uppdaterar webbtjänster måste känna till. Handboken innehåller exempeldokument som kan bifogas anbudsförfrågan vid upphandling av webbtjänster. Vi går i korthet igenom också hur tillgänglighet beaktas i filerna i webbtjänsten.

1.2. Varför är tillgängliga webbtjänster viktiga för kommunen?

Tillgängliga webbtjänster kan användas av en så stor mängd människor som möjligt. Tjänsterna är tydliga, lätta att använda och stöder olika sätt att använda digitala tjänster. För kommunerna, som ska ge service till alla sina invånare, är det särskilt viktigt med tillgängliga webbtjänster och kommunens webbplats är oftast den viktigaste informationskanalen. Genom tillgängliga webbtjänster kan informationskostnaderna hållas nere, eftersom alternativa servicekanaler inte behöver skräddarsys för funktionsbegränsade invånarna.

Kommunernas webbtjänster har inte utvecklats mot större tillgänglighet trots att behovet av tillgänglighet inte är nytt. Den långsamma utvecklingen har berott på bristande kunskaper: man har inte förstått olika människogruppers behov eller vad man ska göra för att webbtjänsterna ska bli tillgängliga. Fenomenet är globalt och tillgänglighet tycks vara ett område där lagstiftningen går i bräschen för att öka medvetenheten och sätta fart på åtgärderna. I USA finns det flera exempel på att lagstiftning bidragit till att tillgänglighet har förankrats som en del av olika processer i organisationer. Därmed fyller den nationella lagstiftningen, som baserar sig på EU:s tillgänglighetsdirektiv och som är förpliktande för kommunerna, ett viktigt behov.

1.3. Hur garanteras tillgängligheten i webbtjänster?

I första delen av tillgänglighetshandboken nämndes de riktlinjer för tillgängligt webbinnehåll som tagits fram av World Wide Web Consortium (W3C), dvs. Web Content Accessibility Guidelines (WCAG) 2.0. Det är en samling viktiga riktlinjer genom vilka tillgängligheten i webbtjänster kan utvärderas och utvecklas.

Riktlinjerna erbjuder en metod för att garantera webbtjänsters åtkomlighet för en så bred mottagargrupp som möjligt.

WCAG 2.0 har status av de facto-standard för webbplatser för det finns ingen annan betydande lista över kravspecifikationer. Riktlinjerna består av tre nivåer: A, AA och AAA, och av dessa är AAA den striktaste. Den mellersta nivån AA används oftast och flera länder hänvisar också till den i sina lagar och standarder. I EU:s nya tillgänglighetsdirektiv hänvisas till den europeiska standarden EN 301 549, som fastställer tillgänglighetskraven också vid offentlig upphandling. Du kan ladda ned den svenskspråkiga översättningen av standarden här: http://www.its.se/standards/ss6363x/Oversattning-EN_301tillgänglighetsk… 549.pdf eller versionen på engelska: Accessibility requirements suitable for public procurement of ICT products and services in Europe, PDF.

För webbtjänster hänvisas i standarden ändå till WCAG 2.0 nivå AA, så den är viktig också i detta sammanhang. I EU har det också inletts ett nytt standardiseringsarbete, Mandate 554 (PDF), för att utvidga standarden EN 301 549 till att omfatta bland annat mobila applikationer.

Tillgänglighetsriktlinjerna WCAG 2.0 är indelade i fyra principer: möjlig att uppfatta, hanterbar, begriplig och robust:

  • Möjlig att uppfatta innehåller riktlinjer för hur information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta. Då ska bland annat bilder ges alternativ i form av text för de användare som inte ser bilderna.
  • Hanterbar innebär att komponenter i ett användargränssnitt och navigering måste vara hanterbara för alla användare. Exempelvis ska tjänsten vara åtkomlig via tangentbord utan mus.
  • Information och hantering av användargränssnitt måste vara begriplig. Det innebär att innehållet är tydligt och strukturerat.
  • Robust beskriver att innehållet måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av hjälpprogram, inklusive skärmläsare och skärmförstorare.

Denna kategorisering är nyttig när det gäller att beskriva riktlinjerna för tillgänglighet på övre nivå. Kategorierna belyser ändå inte alls vem som har nytta av att riktlinjerna uppfylls och vem som ansvarar för att åtgärderna genomförs. 
I regel planerar inte kommunerna själva sina webbtjänster utan upphandlar planeringen av en utomstående leverantör. Exempelvis kan en reklambyrå ansvara för kommunens visuella profil, medan en webbleverantör ansvarar för sidornas struktur och tekniska utformning. Det är också typiskt att innehållsproduktionen i stor utsträckning är utspridd till kommunens olika verksamhetsområden. Då är det viktigt att tänka ut hur riktlinjerna för tillgängligheten ska uppdelas på de olika aktörerna.

De krav på tillgänglighet som presenteras i den här handboken baserar sig på riktlinjerna WCAG 2.0 nivå och är indelade i fyra kategorier med avseende på webbplatser:

  1. Tillgänglighetskriterier för den visuella profilen
  2. Tillgänglighetskriterier för strukturen
  3. Tillgänglighetskriterier för teknisk utformning
  4. Tillgänglighetskriterier för innehåll

Kriterierna som indelats på så sätt kan ligga på olika organisationers ansvar eller i samma organisation på olika personers ansvar. I ett litet leverantörsföretag kan samma person ansvara för allt det ovan nämnda. De centrala rollerna är: grafisk planerare, erfarenhetsexpert, webbutvecklare och innehållsproducent. Grafikerna arbetar exempelvis i reklambyråer och designar kommunens visuella profil.

I leverantörsföretaget ansvarar erfarenhetsexperten för webbtjänstens struktur och den så kallade ståltrådsmodellen, dvs. en lättfattlig struktur. Webbutvecklaren sköter det egentliga tekniska utförandet på en vald publiceringsplattform. Innehållsproduktionen är utspridd till kommunens olika ansvarsområden på så sätt att ansvarspersonerna i kommunens kansli producerar innehållet på det egna ansvarsområdets sidor. Om ansvaret uppdelas så här kommer kraven att hanteras av de rätta aktörerna. Observeras bör att det i allmänhet inte går att dela upp ansvaret för att uppfylla kraven så här pass klart. Alla som deltar i utvecklingsarbetet måste känna till alla krav.

I den här handboken presenteras de viktigaste tillgänglighetskraven. Den lista som presenteras baserar sig på skribenternas tolkning av de viktigaste riktlinjerna i WCAG 2.0 nivå AA och de viktigaste sätten att uppfylla dem. De sätt som presenteras är inte de enda sätten för att uppfylla kraven och nödvändigtvis inte ens de bästa för varje enskilt ändamål. Men de har ändå fungerat bra vid bedömning av tillgängligheten på framför allt kommunernas webbplatser. I listan över kriterierna för tillgänglighet har riktlinjerna WCAG 2.0 nivå AA kombinerats och grupperats. Designen är fritt utformad och strävan är att öppna riktlinjerna för dem som inte har djupare insikter i vad tillgänglighet innebär. På W3C-sidorna finns det en fullständig lista över riktlinjerna för tillgänglighet, och en lista över tillräckliga och rådgivande metoder.

På tillgängliga webbplatser finns det också tilläggselement som enligt WCAG 2.0 nivå AA inte krävs, men som många användare har nytta av. Hit hör teckenspråkiga sidor, lättlästa sidor och tal som stöder läsning. Dessa så kallade design-element har i någon mån behandlats i första delen av handboken. När en högre tillgänglighetsnivå eftersträvas finns det skäl att bekanta sig med riktlinjerna WCAG 2.0 nivå AAA, där tillgängligheten är mycket mer utvecklad.

Saavutettavuus huomioitu -leima
Saavutettavuus huomioitu -leima

Synskadades förbund har lanserar stämpeln Tillgänglighet beaktad, med hjälp av vilken anbudsgivaren kan meddela att tillgängligheten beaktas på webbsidorna. Stämpeln är inte en del av tillsynen i den kommande tillgänglighetslagstiftningen, men ett stöd för att uppfylla de lagstadgade kraven när webbtjänster utvecklas. Stämpeln täcker ett snävare område än lagstiftningen för den omfattar bara webbtjänstens huvudsakliga användningsändamål, inte tjänsten i sin helhet.

1.4. Testning av tillgänglighet på webbplatser

Det finns många sätt att kartlägga hur kriterierna för tillgänglighet uppfylls:

  1. Man går manuellt igenom de sidor som ska ses över. Då kan man till exempel granska tydligheten generellt, hur tydliga blanketterna och språket är osv. Vid behov kopplas stilformateringen CSS och olika slags dynamiska element, s.k. script, bort.
  2. Testning av skärmläsare och tangentbord. Man testar funktionaliteten genom att använda skärmläsare och tangentbord.
  3. Användning av automatiska program för att testa tillgängligheten. Programmen är lämpliga som stöd för både manuella tester och tester med skärmläsare. Automatiska testprogram bör inte användas som huvudsaklig metod.
  4. Användning av hjälpprogram som gäller ett visst specifikt krav. Sådana är exempelvis färgkontrastverktyg samt analys av snabba blänkare.
  5. Genomgång av HTML-sidor med utvecklares verktyg, för att granska exempelvis kodens riktighet osv.

När tillgängligheten testas har skärmläsarna en viktig roll. Olika skärmläsare fungerar på lite varierande sätt i olika webbläsare och operativsystem och därför är det viktigt att testa olika kombinationer.

  • De vanligaste webbläsarna i Windows-baserade datorer är EDGE, Internet Explorer, Chrome och Firefox och de vanligaste skärmläsarna är NVDA och JAWS.
  • I Mac-datorer och mobila enheter ska tester göras åtminstone med browsern Safari och skärmläsaren VoiceOver.
  • I Android-enheter fungerar exempelvis Google TalkBack som skärmläsare. 

Läs användarenkäten om skärmläsare som gjorts av WebAim WebAimiin tekemään käyttäjäkyselyyn. Det är också bra att beakta användarnas erfarenheter i den egna kommunen.

När stora webbplatser som uppdateras ofta utvecklas är det ett krävande företag att testa tjänsternas tillgänglighet. Därför är automatiska tillgänglighetstester ett viktigt mål. Att testa tillgänglighet manuellt kan gott och väl ta flera veckor i anspråk, medan automatiska system kan testa stora webbplatser på några timmar. Med automatiska tester hittar man också problempunkterna snabbare än med manuella tester som måste tidsplaneras så att en betydande helhet av webbtjänsterna redan är klara.

Automatiska tester av tillgänglighet håller tyvärr inte en sådan nivå att man på ett pålitligt sätt kan få reda på hur väl tjänsten uppfyller exempelvis riktlinjerna WCAG 2.0. Endast en liten del av riktlinjerna är så pass entydiga att tjänstens tillgänglighet kan utredas tillförlitligt med automatisk testning.

Mindre än 10 procent av kriterierna i WCAG 2.0 nivå AA kan på ett pålitligt sätt testas automatiskt skriver Dan Holbrooks i artikeln The Power (and Limits) of Automated Accessibility Testing.

Populära program för tillgänglighetstester är till exempel

Programmen kan vara separata, webbläsartillägg eller gränssnittsspecifikationer som kan integreras i den övriga testmiljön.

Två övergripande problem med program som testar tillgänglighet är:

  1. Största delen av kriterierna kan inte testas och vilka som blir otestade anges nödvändigtvis inte av programmet. Om testprogrammet ger tjänsten grönt ljus kan villfarelsen att den är tillgänglig uppstå. Så är det i allmänhet ändå inte. 
  2. De automatiska testprogrammen hittar typiskt inte rätt fel, och då kan bilden av tillgängligheten bli alltför negativ. För att tolka resultaten av automatiska tester krävs det oftast också tillgänglighetskompetens. 

Trots stötestenarna ska automatiska tester användas alltid när det är möjligt. Då blir det mer resurser över för en noggrann manuell testning. I manuella tester är automatisk testning ett gott stöd.

Utöver de egentliga omfattande programmen som testar tillgänglighet finns det många olika typer av hjälpprogram för specialbehov, till exempel för att kontrollera färgkontrasterna eller HTML-kodens riktighet.

Det är typiskt att varje testverktyg utformar en testmiljö för sig själv av olika slags testprogram. För tjänsternas del är det också viktigt att på förhand planera hur tjänsten förblir tillgänglig trots att den uppdateras kontinuerligt. Detta är fallet till exempel i kommunernas webbtjänster som kan få nytt innehåll varje dag.

För testning av mobila applikationers tillgänglighet finns det egna tilläggskrav. Läs mer om kraven i till exempel Paciello Group:s handbok Mobile Testing Guide (PDF).