WEBBTILLGÄNGLIGHETSDIREKTIVET : Fallstudie för framtagning av verktyg för att uppfylla kraven i direktivet

(1)

Akademin f¨

or innovation, design och teknik

V¨

aster˚

as, Sverige

Examensarbete f¨

or kandidatexamen i datavetenskap - 15.0 hp

WEBBTILLG ¨

ANGLIGHETSDIREKTIVET:

FALLSTUDIE F ¨

OR FRAMTAGNING AV VERKTYG

F ¨

OR ATT UPPFYLLA KRAVEN I DIREKTIVET

Erika Weilander

ewr15002@student.mdh.se

Examinator: Daniel Hedin

M¨

alardalens H¨

ogskola, V¨

aster˚

as, Sverige

Handledare: Rikard Lindell

M¨

alardalens H¨

ogskola, V¨

aster˚

as, Sverige

F¨

oretagshandledare: Frida Engman

HiQ M¨

alardalen AB, V¨

aster˚

as, Sverige

(2)

Sammanfattning

I Januari 2019 s˚a verkställdes lagen för Webbtillgänglighetsdirektivet. Detta innebär att samtli-ga webbplatser som inkluderas inom den offentlisamtli-ga sektorn ska anpassas efter särskilda riktlinjer. Webbtillgänglighetsdirektivet är en effekt av en lagstiftning fr˚an Europeiska Unionen som vill skapa en harmoniserad tillgänglighetsstandard bland dess medlemsstater. M˚anga företag som arbetar med webbutveckling omfattas av detta direktiv men brister i deras arbetssätt p˚a hur de ska täcka de punkter som direktivet vill att deras webbplatser ska uppn˚a. Därför är högst lägligt att undersöka hur företag kan f˚a in de krav direktivet ställer i sin arbetsprocess. Att göra detta skulle gynna företag ekonomiskt men även öka tillgängligheten för alla olika typer av användare.

M˚alet med detta arbete är att se över hur företag som är omfattade av direktivet arbetar med tillgänglighet i dagsläget samt hur direktivet kommer förändra hur de arbetar i framtiden. Utöver detta s˚a ska arbetet undersöka hur anställda p˚a företagen ser p˚a tillgänglighet och om det finns en medvetenhet kring direktivet hos de personer som arbetar med webbutveckling. Arbetet ska även se över ifall det finns n˚agot verktyg som kan hjälpa företag uppfylla de krav som direktivet ställer innan en webbplats publiceras.

För att besvara dessa fr˚ageställningar genomfördes en litteraturstudie p˚a Webbtillg¨ anglighetsdir-ektivet. Efter att ha identifierat kärnan i direktivet och de riktlinjer s˚a lades en grund att genomföra intervjuer med anställda p˚a företag som arbetar inom webbutveckling och tillgänglighet p˚a webb för att kunna f˚a ta del av deras syn p˚a tillgänglighet samt medvetenhet kring direktivet. För att sedan identifiera hur direktivet kommer p˚averka framtida arbeten genomfördes analyser av tv˚a webbplatser som är utvecklade efter en tidigare upplaga av de riktlinjer som ska följas enligt direktivet. Verktyget som företag ska använda resulterade i en checklista där samtliga krav som direktivet ställer finns listade. Utifr˚an denna checklista kan företag undvika missar av de krav direktivet ställer och därmed dra en ekonomisk vinst men även tidigare se till att alla användare kan använda webbplatsen p˚a samma villkor.

(3)

Inneh˚

all

1. Inledning 1

2. Bakgrund 2

2.1. Tillg¨anglighet . . . 2

2.1..1 Funktionshinder & funktionsneds¨attning . . . 2

2.2. Web Content Accessibility Guidelines - WCAG . . . 3

2.2..1 WCAG 1.0 . . . 3

2.2..2 WCAG 2.0 & 2.1 . . . 3

2.3. Webbtillg¨anglighetsdirektivet . . . 4

2.3..1 EN 301 549 V2.1.2 (2018-08) . . . 4

2.3..2 Krav f¨or att uppfylla direktivet . . . 5

2.3..3 Krav p˚a webbtillg¨anglighet utanf¨or Sverige . . . 5

3. Tidigare relaterat arbete 6 3.1. Tillg¨anglighet inom den offentliga sektorn . . . 6

3.2. M¨ata tillg¨anglighet . . . 6

3.3. Medvetenhet om tillg¨anglighet hos utvecklare . . . 7

4. Problemformulering 8 4.1. Avgräsningar . . . 8 5. Fr˚ageställningar 8 6. Metod 9 6.1. Litteraturstudie . . . 9 6.2. Intervjuer . . . 9 6.3. Analys av webbplatser . . . 9 7. Etiska aspekter 10 8. Sammanställning av direktiv 11 9. Genomförande av intervjuer 11 9.1. Transkribering och analysarbete . . . 12

10.Genomf¨orande av analys av webbplats 13 10.1. Val av webbplatser . . . 14

10.2. Checklista f¨or analysering . . . 14

10.3. Analyseringsprocessen . . . 14

10.3..1 Analyseringsverktyg . . . 15

11.Resultat av intervjuer 16 12.Resultat p˚a analys av webbplatser 17 12.1. Hemsida 1 . . . 17 12.1..1 Startsida . . . 18 12.1..2 Navigeringssida . . . 18 12.1..3 Informationssida . . . 19 12.1..4 Sökresultat . . . 19 12.2. Hemsida 2 . . . 20 12.2..1 Startsida . . . 21 12.2..2 A till Ö-sida . . . 22 12.2..3 Sökresultat . . . 23 12.2..4 Lediga jobb . . . 24 12.2..5 Samlingssida . . . 24

(4)

13.Framställning av verktyg för företag 26

14.Diskussion 27

14.1. Direktivet . . . 27

14.1..1 Tekniska problem med direktivet . . . 27

14.2. Intervjuer . . . 28

14.3. Webbplatser . . . 28

14.4. Checklistan och dess betydelse f¨or f¨oretag . . . 29

14.5. Begr¨ansningar och framtida arbeten . . . 29

15.Slutsatser 30 Referenser 33 Bilaga A Intervjuguide 34 Bilaga B Checklista för granskning av webbplats 35 Bilaga C Samtliga analyserade sidor 43 Bilaga D Checklista för företag 51

Tabeller

1 Exempel p˚a olika funktionsneds¨attningar. K¨alla: [1] . . . 2

2 Val av fr˚agor och dess syfte . . . 12

3 Sammanst¨allning av transkribering av intervju. . . 13

4 Resultat av intervjuer . . . 16

5 Resultat av intervjuer, forts¨attning. . . 16

6 Sammanfattning av antal godkända, underkända samt ej tillgängliga punkter i ana-lysen av webbplatser. . . 25

7 Antal f¨orekomster per icke godk¨and punkt . . . 25

Figurer

1 Oversikt ¨¨ over WCAG 2.1. Godkänd av Specialpedagogiska skolmyndigheten att använda bilden i detta arbete. Källa: [2] . . . 4

2 Huvudmeny p˚a Hemsida 1 s webbplats . . . 17

3 S¨okfunktion p˚a Hemsida 1 s webbplats . . . 17

4 Bild p˚a startsida f¨or Hemsida 1 s webbplats . . . 18

5 Attribut tillh¨orande bild p˚a startsida . . . 18

6 L¨ankar placerade p˚a bilden p˚a startsidan . . . 18

7 Rubrik som använder p-element istället för h2 . . . 19

8 Rubrik som har ett button-element . . . 19

9 Samma rubrik p˚a resultat efter s¨ok p˚a ordet ”skola” . . . 20

10 F¨orslag p˚a placering av h1 rubrik . . . 20

11 Tillgänglighetsredogörelse för Hemsida 2 . . . 20

12 S¨okfunktion f¨or Hemsida 2 . . . 21

13 Bilder p˚a Hemsida 2 s startsida . . . 21

14 Attribut tillh¨orande bilder p˚a startsida . . . 21

15 Bilder p˚a Hemsida 2 startsida . . . 22

16 Attribut tillh¨orande bild p˚a startsida . . . 22

17 h1-element vid underrubrik . . . 22

18 Repetitivt val av l¨anknamn . . . 22

19 Exempel p˚a kursiv text under l¨ank p˚a A till ¨O-sida . . . 23

(5)

21 Rubrik f¨or s¨okresultat . . . 24

22 Annons f¨or lediga jobb . . . 24

23 span ist¨allet f¨or h2 . . . 24

24 Oppen lista med avdelningar¨ . . . 24

F¨

orekommande f¨

orkortningar

AD Art Director

CSS Cascading Style Sheet EU Europeiska Unionen

HTML Hyper Text Markup Language PDF Portable Document Format UX User Experience

W3C World Wide Web Consortium WAI Web Accessibility Initiative

(6)

1. Inledning

I Januari 2019 trädde Webbtillgänglighetsdirektivet i kraft men lagstiftades redan i September 2018 [3]. I och med direktivet innebär det att samtliga webbplatser, intranät och mobila applikationer tillhörandes den offentliga sektorn m˚aste se över sin tillgänglighetsanpassning. Offentliga sektorn innefattar offentliga myndigheter och offentliga organ. Direktivet gäller inte endast i Sverige utan är ett krav fr˚an Europeiska Unionen (EU) för att skapa en harmoniserande standard mellan samtliga medlemsstater. Direktivet i sig inneh˚aller femton artiklar ang˚aende huruvida en ska agera för att uppfylla de krav som ställs. Bland dessa artiklar finns det även rekommenderade riklinjer som i sin tur förklarar mer specifikt hur exempelvis en webbplats m˚aste utformas för att vara tillgänglig för alla. Kraven som finns i direktivet bygger till största del p˚a World Wide Web Consortium (W3C)s framtagna riktlinjer Web Content Acessibility Guidelines (WCAG) 2.1 [4] [5]. Dessa riklinjer best˚ar av flertalet punkter och direktivet kräver att de 50 specifika krav som finns i WCAG 2.1 ska uppfyllas för att webbplatsen ska klassas som tillgänglig.

Tidigare forskning har visat att genom analyser av webbplatser för offentliga myndigheter är det f˚a av dessa som faktiskt upplever de krav som WCAG-riktlinjerna ställer och forskningen drar slutsatsen att vi är i största behov av en gemensam standard för tillgänglighetsanpassning [6]. Problemet med analyserna i denna undersökning är att alla webbsidor som testades, testades med hjälp av programvaror. En Norsk studie visade att m˚anga programvaror i snitt endast kunde iden-tifiera 50% av de krav som WCAG-riktlinjerna ställde och hade även sv˚art att p˚avisa vilken av riktlinjerna som inte uppfyllts. Det är dessutom tidigare p˚avisat att det finns en brist i medveten-het hos b˚ade studenter och arbetande inom mjukvaruutveckling ang˚aende tillgänglighet och vad tillgänglighetsanpassning innebär [7].

Detta arbetet genomfördes i samarbete med HiQ Mälardalen med m˚al att hjälpa att säkerställa att de uppfyller de krav som direktivet ställer innan de publicerar eller skickar in en webb-plats för granskning. Därför kommer det här arbetet att identifiera hur personer som arbetar inom webb ser p˚a tillgänglighet men även se ifall det finns en medvetenhet kring det nya Webb-tillgänglighetsdirektivet. Eftersom direktivet är n˚agot nytt för HiQ men även andra företag är det ¨

aven av intresse att undersöka huruvida direktivet kommer p˚averka företagens arbetssätt. Kärnan i självaste arbetet ligger i att komma p˚a ett sätt som kan säkerställa att samtliga riktlinjer uppfylls eller öka antal uppfyllda riktlinjer av de som direktivet ställer. Att genomföra det här arbetet s˚a ges HiQ men även andra företag möjligheten att undvika kommande missar i deras utvecklingsprocess som i sin tur kan leda till ekonomiska förluster.

Genom att intervjua och undersöka hur anställda inom webb-branschen ser p˚a tillgänglighet i dagsläget var det möjligt att se om företag kommer behöva att ställa sig till att utbilda anställda inom tillgänglighet. Intervjuerna möjliggjorde även för att se vilket sätt som hade varit det mest lämpligt för personer inom branschen att i deras arbetsprocess f˚a in ett verktyg som underlättar för dem att uppfylla direktivet. Utöver intervjuer gjordes även analyser av webbplatser som HiQ Mälardalen utvecklat. Dessa webbplatser är utvecklade för de tidigare riklinjerna WCAG 2.0 och därmed gjorde det möjligt att se hur direktivet p˚averkar den tidigare arbetsprocessen.

Att undersöka och genomföra arbetet gynnas inte endast företag utan m˚anga människor som använder sig av webbplatser. Människor fungerar olika och har därmed inte alltid samma föruts¨ attn-ingar till att använda en webbplats. Att innan publicering av en webbplats minska antalet icke uppfyllda krav kommer öka tillgängligheten för m˚anga människor och därmed ger människan rätten att s˚a m˚anga som möjligt ska f˚a fungera p˚a samma villkor.

De viktigaste resultaten som framkom i arbetet är att det förekommer en brist i medvetandet om vad Webbtillgänglighetsdirektivet hos individer som dagligen arbetar med webb trots det att direktivet numera är lagfört. Arbetet visade även att med hjälp av en checklista var det möjligt att p˚a webbplatser hitta punkter som eventuellt glömts bort eller missats under utvecklingen av webbplatser. Dessa missar hade kunnat blivit kostsamma för dels företag samt den myndighet som ¨

ager webbplatsen. För att företag ska kunna arbeta vidare med att säkerställa direktivet s˚a togs en mer detaljerad checklista fram som slutprodukt.

Arbetet var begränsat till tio veckor och därmed var det omöjligt att hinna testa den checklista som framtogs för företag. Det finns förhoppningar om att resultatet av detta arbete ska tillföra mer kunskap om tillgänglighet och Webbtillgänglighetsdirektivet för de personer som arbetar med b˚ade webbutveckling och tillgänglighet.

(7)

2. Bakgrund

Under hösten 2018 gick det nya Webbtillgänglighetsdirektivet igenom som lagförslag. Direktivet är en förordning som gäller inom hela EU. Anledningen att direktivet togs fram var för att skapa en harmoniserand tillgänglighetsanpassning hos samtliga medlemsstater. Kortfattat innebär det-ta att exempelvis webbplatser m˚aste vara tillgänglighetsanpassade och därmed uppfylla riktlinjer ang˚aende tillgänglighetsanpassning. De som omfattas av direktivet är offentliga myndigheter [4]. Dessa myndigheter presenterar och delar information som människor oavsett förm˚aga ska kunna ta del av. Det finns inga exakta siffror p˚a hur m˚anga människor i Sverige som har n˚agon form av funk-tionsnedsättning. Dock är funktionsnedsättning ett väldigt brett begrepp som m˚anga människor inkluderas av. Även om tillgänglighet är ett ämne som varit p˚a tapeten under flertalet ˚ar s˚a är det fortfarande n˚agot som m˚anga utvecklare upplever är sv˚art att arbeta med [8]. Utvecklingen av webbplatser g˚ar snabbt fram˚at och kravet ligger ofta p˚a att skapa dynamiska och visuellt attraktiva webbplatser snarare än att fokusera p˚a den funktionella aspekten.

2.1. Tillg¨

anglighet

Tillgänglighet innefattar mer än bara hur ett användargränssnitt fungerar [9]. När personer arbetar med tillgänglighet ser en över vilka användarna är men ser ocks˚a till användarnas olika behov och hur de interagerar med systemet. Det är även viktigt att ha koll p˚a hur systemet är uppbyggt men ¨

aven hur koden är strukturerad. En ökad tillgänglighet ser till att minska det gap som idag finns mellan omgivningens krav och de människor som lever med n˚agon form av funktionsnedsättning [10]. Därför är det väldigt viktigt att fr˚an början i designprocessen tänka p˚a tillgängligheten. P˚a s˚a vis läggs en grund för att inkludera s˚a m˚anga människor som möjligt.

När det kommer till att utveckla tillgänglighetsanpassade webbplatser glöms aspekten bort tidigt i arbetsprocessen. Men vad som vanligtvis glöms bort är att tillgänglighetsanpassningen ocks˚a m˚aste underh˚allas i den takt som webbplatser uppdateras [11]. Under uppdateringar av webbsidor kan riktlinjer komma att glömmas bort, förbises eller ha förnyat sina krav och i och med detta försvinner tillgänglighetanpassningen fr˚an webbplatsen. N˚agot som ocks˚a ofta glöms bort i utvecklingsprocessen är att under testfasen även testa tillgängligheten. Test är en otroligt viktig aspekt i utvecklandet av ny mjukvara och även i utvecklandet av nya webbplatser. I dagsläget ligger dock fokus mer p˚a att f˚a en responsiv och snygg design vilket därmed riskerar att tillgängligheten utesluts helt och h˚allet.

2.1..1 Funktionshinder & funktionsneds¨attning

Det är viktigt att poängtera att funktionsnedsättning och funktionshinder inte är samma sak [10]. Funktionshinder är det som stoppar människor med funktionsnedsättningar att fungera tillsam-mans med den ofta enligt normen fungerande omgivningen. Funktionsnedsättningar finns hos indi-viden och kan vara antingen situationella, temporära eller permanenta. Funktionsnedsättningar kan ¨

aven vara antingen synliga eller osynliga. Situationsbaserade problem kan exempelvis vara tillfälligt nedsatt hörsel vid resande p˚a en buss med bullerljud, mobilanvändare, teknikovana, tillfälliga be-svär men även ˚aldrandet hos människan. Permanenta funktionsnedsättningar kan exempelvis vara medfödd blindhet eller förlust av en arm. Temporära funktionsnedsättningar kan vara när en indi-vid tillfälligt drabbats av en sjukdom och därmed inte kan fungera enligt normen. I Tabell 1 finns konkreta exempel p˚a situationsbaserade-, temporära-, samt permanenta funktionshinder.

Permanent Tempor¨ar Situationell

Kroppsligt En arm Bruten arm Nybliven förälder med bebis i famnen Syn Blind Starr Ofokuserad (inte uppmärksamma omgivning) Hörsel Döv Oroninfektion¨ Arbete i högljudd miljö

Tal Icke-verbal Strupkatarr Sv˚ar brytning (ej möjlighet att göra sig först˚add) Tabell 1: Exempel p˚a olika funktionsnedsättningar. Källa: [1]

(8)

2.2. Web Content Accessibility Guidelines - WCAG

För nu 20 ˚ar sedan under 1999 publicerade W3Cs Web Accessibility Initiative (WAI) första uppla-gan av WCAG, idag kallat WCAG 1.0 [5]. WCAG är kort för Web Content Accessibility Guidelines och kan p˚a svenska översättas till Riktlinjer för tillgängligt inneh˚all p˚a webben. Innebörden av den-na riktlinje var att se till hur material publicerat p˚a internet skulle anpassas och göras tillgängligt för människor med funktionsnedsättningar. Under 2008 publicerades WCAG 2.0 som en omar-betad version av WCAG 1.0 med ännu mer fokus p˚a tillgänglighet. WCAG riktar sig till alla former av webbdesigners, webbutvecklare, utvecklare av hjälpverktyg för webben, utvecklare av programvara som ser över tillgänglighet p˚a webben samt andra som vill eller behöver n˚agon form av standardisering för webb [12].

2.2..1 WCAG 1.0

I Maj 1999 publicerades första upplagan av WCAG [5]. Denna upplaga blev en rekommendation som innefattade riktlinjer huruvida internet skulle kunna tillgänglighetanpassas och därmed göras användarvänligt för individer med fuktionsnedsättningar [4]. WCAG 1.0 kom att bli väldigt omdis-kuterat och sv˚artolkat d˚a riktlinjerna var öppet för tolkning [13]. Tekniken utvecklades snabbare ¨

an vad riktlinjerna gjorde och därmed blev det väldigt sv˚art att tillämpa p˚a modernare teknik. 2.2..2 WCAG 2.0 & 2.1

Efter problemen och förvirringen kring WCAG 1.0 lanserades en omarbetad version kallat WCAG 2.0 ˚ar 2008 [13]. Denna uppdatering inneh˚aller klarare och mer specifika riktlinjer om hur en ska tänka för att utveckla tillgängligt. Dessa riktlinjer är uppdelade i tre olika niv˚aer, A, AA samt AAA. För att exempelvis en webbplats ska uppn˚a niv˚a A m˚aste samtliga kriterier för A-niv˚an vara uppfyllda [14] [15]. För att klassas som en webbplats p˚a niv˚a AA s˚a m˚aste samtliga krav för niv˚a A och AA vara uppfyllda. För AAA m˚aste samtliga kriterier vara uppfyllda.

Mycket har hänt med tekniken och vilka plattformar vi använder oss av under de elva ˚ar som g˚att sedan WCAG 2.0 publicerades. S˚a sent som 2018 uppdaterades riktlinjerna ytterligare en g˚ang med fokus p˚a fler funktionsnedsättnignar men även nya plattformar som exempelvis mobiltelefoner och surfplattor [16]. Denna upplaga kom att kallas WCAG 2.1 och är den senaste av upplagan av W3Cs WAI riktlinjer. Grundläggande s˚a innefattar WCAG 2.1 fyra olika principer för att utveckla tillgängligt [4]. Nedan listas de fyra principer som ligger i grund för WCAG 2.1, varje princip följs av ett konkret exempel.

1. M¨ojligg¨ora att en webbplats ska vara enkel att uppfatta.

• Text ska vara möjlig att anpassa till större font eller punktskrift för de med synsv˚arigheter. 2. Komponenterna i ett användargränssnitt ska vara användarvänliga.

• Anv¨andaren ska med hj¨alp av exempelvis endast datormus eller tangentbord kunna navigera mellan olika komponenter.

3. Informationen kring hanteringen av användargränssnitt m˚aste finnas lättillgängligt.

• Skärmläsare (som läser upp text p˚a exempelvis en webbplats för personer med syn-nedsättning) ska via källkoden i HTML:en hitta sidans spr˚ak s˚a att uttalet sker korrekt. 4. Webbplatsen ska vara p˚alitlig nog för att kunna tolkas av olika användarprogram samt

hj¨alpmedel.

(9)

Figur 1: Översikt över WCAG 2.1. Godkänd av Specialpedagogiska skolmyndigheten att använda bilden i detta arbete. Källa: [2]

2.3. Webbtillg¨

anglighetsdirektivet

Fr˚an och med september 2018 gäller nya riktlinjer i utvecklingen av webbplatser, intranät samt applikationer för och hos offentliga myndigheter [4]. För att förtydliga innebörden av offentliga myndigheter s˚a innefattas statliga, regionala eller lokala myndigheter men även offentligrättsliga organ. Lagar liknande Webbtillgänglighetsdirektivet gäller i hela EU. Sverige har tidigare saknat lagstiftning när det kommer till tillgänglighet p˚a webbplatser och i applikationer. M˚anga andra länder runt om i världen har sedan länge haft egna lagstiftningar som exempelvis följer olika niv˚aer av WCAG 2.0 eller 2.1. Genom att tillämpa direktivet inom EU kommer flertalet länder avkrävas att h˚alla samma standard. I Sverige trädde lagen i kraft 1 Januari 2019.

Grundprincipen med direktivet är att exempelvis webbplatser och mobila applikationer ska utvecklas till att vara mer tillgängliga för alla typer av användare, med största fokuset p˚a individer med olika funktionsnedsättningar [4]. Direktivet best˚ar av 15 artiklar som Europaparlamentet och Europar˚adet kommit överens om. Dessa artiklar behandlar punkter s˚a som förtydligande om vad som räknas som offentlig myndighet samt att medlemsstater m˚aste uppn˚a WCAG 2.1 niv˚a A och AA.

Direktivet fr˚an EU trycker p˚a att det är upp till varje medlemsstat att säkerställa att direktivet följs. Medlemstaterna ska även underlätta tillämpningen av direktivet. Dessutom ska alla medlems-stater öka medvetenheten om tillgänglighetsanpassning samt förse med utbildningsprogram inom tillgänglighet. M˚alet med direktivet är att samtliga medlemsstater ska följa en gemensam europeisk standard kallad EN 301 549 V2.1.2 (2018-08) (se nästa stycke) och uppfylla dess krav som finns i EN-standarden kapitel 9, 10, 11[3] [17].

2.3..1 EN 301 549 V2.1.2 (2018-08)

Under december 2005 fick tre europeiska standardiseringsorgan uppdraget att tillsammans fram-ställa en europeisk standard som täcker tillgänglighet i användningen av offentliga upphandlingar.

(10)

Resultatet blev det vi idag kallar EN 301 549 v. 1.1 2 (2015:04) [4]. EN är en förkortning och st˚ar för europeiska normer (översatt fr˚an engelskans European Norms, härefter refererat till EN-standarden) [18]. EN-standarden inneh˚aller diverse krav p˚a webbplatser samt p˚a dokument och liknande inneh˚all som specifikt inte är webbplatser. Dessutom inneh˚aller standarden specifika krav p˚a funktionen hos vissa programvaror. Under 2018 uppdaterades EN-standadern ungefär samti-digt som WCAG 2.1 lanserades och blev EN 301 549 V2.1.2 (2018-08) Själva kravet i den nya EN-standarden motsvarar de som g˚ar att finna i WCAG 2.1 och kraven är detsamma som finns i A samt AA-niv˚an.

I dokumentationen för EN-standarden g˚ar det att läsa om de kapitel som finns i direktivet samt deras innebörd [19]. Webbtillgänglighetsdirektivet inriktar sig specifikt p˚a kapitel 9, 10 samt 11 i EN-standarden. Dessa kapitel handlar om webb, icke-webb-dokument samt programvara. Här framg˚ar det tydligt att kraven för webb är densamma som standarden för A & AA-niv˚an i WCAG 2.1. Kapitlen inkluderar även utöver vanliga webbsidor dokument i webbformat, dokument inbäddade i webbsidor, programvara i form av webbsida samt programvara inbäddad i webbsidor. För icke-webb-dokument samt programvara listas kraven till största del specifikt i dokumentationen för EN 302 549 [19].

2.3..2 Krav f¨or att uppfylla direktivet

För att uppfylla kraven som ställs i Webbtillgänglighetsdirektivet m˚aste produkten uppn˚a minst niv˚a AA p˚a samtliga punkter i WCAG 2.1 [20]. I Figur 1 g˚ar det att utläsa att det sammanlagt är 50 krav som g˚ar under niv˚aerna A och AA.

Utöver kravet p˚a att uppfylla de olika WCAG-kriterierna m˚aste även webbplatsen, intranätet el-ler applikationen tillgodose ett kommentarsfält[4]. I kommentarsfältet ska användare kunna ˚ aterko-ppla ifall de upplever n˚agonting som är otillgängligt eller f˚a en möjlighet att föresl˚a förbättringar. Dessutom m˚aste det även finnas en tillgänglighetsredogörelse tillgänglig som förklarar hur den of-fentliga myndigheten uppfyller de krav som ställs fr˚an direktivet och som specificerar de delar som utelämnats och varför dessa delar inte har tagits i hänsyn. Genom att ha en tillgänglighetsredogörelse f˚ar personer med en funktionsnedsättning möjlighet att först˚a varför exempelvis en viss kompo-nent inte uppfyller de krav som ställs och varför den inte tillgänglighetanpassas för deras be-hov och varför de därmed exkluderats. Tillgänglighetsredogörelsen ska även tillgodose en tydlig förklaring vart användaren skulle kunna ˚aterkoppla upplevda förhinder. Med andra ord, vart kom-mentarsfunktionen finns tillgänglig.

2.3..3 Krav p˚a webbtillg¨anglighet utanf¨or Sverige

I skrivande stund (Maj 2019) är genomförandet av Webbtillgänglighetsdirektivet i Sverige endast n˚agra m˚anader gammalt. Liknande regleringar har tidigare genomförts i andra länder [4]. Under 2007 införskaffade sig Danmark regleringar huruvida offentliga myndigheters webbplatser m˚aste uppfylla niv˚a AA i WCAG 2.0. Samma ˚ar röstades det genom ett liknande genomförande i Spa-nien som fr˚an 2012 följt samma standarder för offentliga myndigheter och dess webbplatser som Danmark. Även Norge är ett av dessa länder som redan genomfört tillgänglighetsanpassning. Deras diskrimineringslagstifning riktar sig till informationteknologi som allmänheten kan tänkas använda. Denna teknologi inkluderar webbplatser, mobila applikationer och självbetjäningsautomater. En-ligt Norsk lag m˚aste dessa uppfylla minst niv˚a AA i WCAG 2.0.

(11)

3. Tidigare relaterat arbete

Vikten av att webbsidor ska tillgänglighetanpassats har funnits under en längre tid. Ofta framkom-mer det att även om webbutvecklare eller ägare av webbsidor konstaterar att det som utvecklats ¨

ar tillgänglighetsanpassat s˚a är det ofta inte fallet. Detta resulterar i att människor med funktions-nedsättningar förbises under webbutvecklingsproessen och därmed även utesluts fr˚an att använda vissa webbplatser. WCAG ger stabila och grundliga riktlinjer till hur utvecklare kan bli mer in-kluderande. I dagsläget sker oftast automatiserade tester när webbtillgänglighet ska undersökas. Dessa tester är l˚angt fr˚an korrekta och oftast sv˚ara att säkerställa att de testar alla aspekter som krävs för att kunna kalla en webbplats tillgänglig.

3.1. Tillg¨

anglighet inom den offentliga sektorn

Att uppn˚a en god tillgänglighet har inte alltid varit den högsta prioriteten vid skapandet av nya webbplatser. En studie visade att genom att analysera 100 olika europeiska webbplatser var det möjligt att dra slutsatsen att endast ett f˚atal av dessa uppfyllde den grundläggande WCAG 2.0 A-niv˚an [6]. Webbplatserna som analyserades i denna studie var en blandning av webbplatser med b˚ade tillgänglighetscertifikat samt webbplatser som själva deklarerat sig som tillgänglighetsanpassade. 76 av dessa hemsidor tillhörde regeringar och andra delar av den offent-liga sektorn och de resterande 24 var för kommersiellt bruk.

¨

Aven om det hävdades i studien att det bästa tillvägag˚angssättet för denna analys skulle vara att manuellt testa hemsidorna i kombination med att l˚ata människor med funktionsnedsättning testa sidorna valdes det att istället testas med ett automatiserat verktyg. Ett antal av dessa webb-platser gick inte att köra med verktyget och fick därmed uteslutas ur studien. Detta resulterade i att endast 3% av de webbplatser inom den offentliga sektorn som testades uppfyllde kraven för A-och AA-niv˚an för WCAG 2.0. Slutsatsen av denna undersökning blev att det krävs en gemensam standard för medlemsländer i EU för tillgänglighetsanpassning.

Precis som författarna av studien nämnt ovanför [6] s˚a är en EU-förordning mer än läglig för att säkerställa att medlemstater följer en standardiserad modell för tillgänglighetsutveckling. Därför är det lämpligt att i samband med det nya Webbtillgänglighetsdirektivet bygga vidare p˚a denna studie och se hur den nya förordningen kan säkerställa att webbplatser faktiskt tillgänglighetsanpassas. Författarna nämnde att det dels är lämpligt att analysera webbplatser manuellt. Att analysera 100 hemsidor manuellt skulle ta ofantligt mycket tid och därmed gjorde de rätt i att begränsa sig till automatiserad analys med hjälp av mjukvara. Eftersom direktivet nu finns p˚a plats är det av extra vikt att analysera noggrant huruvida direktivet appliceras p˚a webbplatser som omfattas av de nya kraven.

3.2. M¨

ata tillg¨

anglighet

Genom att mäta tillgängligheten p˚a en webbplats g˚ar det att skaffa en uppfattning huruvida webbplatsen kommer att uppfylla de krav som kommer med direktivet. Skulle punkter ur direktivet glömmas bort skulle det därmed innebära efterräkningar för den offentliga sektorn webbplatsen tillhör. Dessa har idag inte fullt ut bestämts men skulle tänkas vara n˚agon form av böter. Därför är det av extra stor vikt att mätningarna garanterar 100% säkerhet att den är korrekt. För att mäta tillgänglighet används oftast automatiserade programvaror som resulterar i siffror att analysera.

En norsk studie fr˚an 2017 menar att de programvaror som i dagsläget används för att mäta tillgänglighet är en viktig del av arbetet för att kunna upptäcka brister i tillgängligheten [21]. De belyser vikten av att ha tillförlitliga program när tillgänglighet mäts för att undvika viktiga misstag i utvecklingsprocessen. Samtidigt lyfter texten även fram att dessa program kan ungefär endast identifiera ungefär 50% av de olika kriterierna som krävs för WCAG 2.0 under själva ana-lysprocessen. Vidare i studien visar det sig att exempelvis programvaran de använder även har sv˚art att visa vilka restriktioner i WCAGs riktlinjer som webbplatsen brister.

Likt dessa tv˚a studier kommer även denna studie göra tester och analyser p˚a webbplatser. Den största skillnaden är att dessa analyser kommer att göras manuellt för att säkerhetställa att inga punkter i WCAG 2.1 niv˚a AA kommer att förbises. Självklart krävs det noggrannhet och precision när en manuellt ska se över de 50 krav som direktivet ställer och vid oförsiktighet är det lätt att

(12)

g˚a miste om en eller flera punkter. Därför är det viktigt att ha tillg˚ang till n˚agon form av överblick p˚a de krav som ställs p˚a webbplatsen, dels för att säkerställa att alla krav är uppfyllda men även veta exakt var webbplatsen brister i tillgänglighet.

3.3. Medvetenhet om tillg¨

anglighet hos utvecklare

Ett förekommande problem är att utvecklare och designers saknar insyn i hur en ska tänka tillgängligt [7]. Lopes et al,. undersökte med hjälp av intervjuer samt onlinebaserade formulär hur människor som arbetar eller studerar inom mjukvaruutveckling upplevde sin medvetenhet om tillgänglighet. 85% av alla deltagare upplevde att de behövde fördjupa sin kunskap inom omr˚adet ”tillgänglighet p˚a webb och mobila plattformar” och därmed uttryckte ett behov av f˚a möjlighet att göra detta. Bland deltagarna i undersökningen var endast 40% medvetna om att det fanns riktlinjer som förklarade hur en skulle g˚a tillväga för att tillgänglighetsanpassa det som de utvecklar.

Det m˚aste bli en självklarhet att utvecklare ska vara medvetna om tillgänglighet och veta hur det ska appliceras p˚a webbsidor nu när direktivet träder i kraft. Därför är det viktigt att i denna undersökning se hur utvecklare p˚a olika företag är medvetna om de tillgänglighetskrav som kommer att ställas p˚a framtida arbeten. Undersökningen ovan riktade inte in sig p˚a Sverige specifikt och därav behövs det en fördjupning i hur det fungerar här i dagsläget. Möjligheten finns att denna studie kommer n˚a samma resultat som Lopes et al,. men förhoppningsvis har medvetenheten ökat hos utvecklare sedan 2010 när föreg˚aende undersökning gjordes. Om inte bör det läggas ett stort fokus p˚a att möjliggöra medvetenheten kring tillgänglighet för utvecklare idag.

(13)

4. Problemformulering

Att kunna utveckla tillgänglighetsanpassat kräver mer än bara förm˚agan att kunna skriva bra kod. Det gäller att ta in användarna i perspektiv redan tidigt i planeringsprocessen av en ny webbplats eller applikation och därefter fortsätta följa standarden. Till hjälp finns flertalet olika riktlinjer att följa. Riktlinjerna garanterar inte att alla tillgänglighetskrav följs. Däremot kan riktlinjerna underlätta för de personer som arbetar med tillgänglighetsanpassning. Slutar personer följa dessa riktlinjer s˚a kommer tillgänglighetsaspekten förmodligen att glömmas bort. Alla användare har olika möjligheter och behov och därmed är det viktigt att möjliggöra att s˚a m˚anga som möjligt kan ta del av viktig information som finns tillgängligt p˚a webbplatsen eller i applikationen. Tidigare studier visar p˚a brist i medvetenhet om tillgänglighet p˚a webben hos utvecklare [7]. I samband med genomförandet av en ny lagstiftning ang˚aende tillgänglighet p˚a webben är det av största vikt att öka denna medvetenhet.

Idag finns det m˚anga företag som ofta arbetar med att utveckla kommunala webbplatser, därav omfattas de av det nya direktivet som tidigare är nämnt. Ett av dessa företag är HiQ Mälardalen och ¨

ar det företag som detta arbete kommer ha i fokus därmed utföra en fallstudie p˚a. I september 2018 träddes Webbtillgänglighetsdirektivet igenom och därmed innebär att det m˚aste ske förändringar i hur företag väljer att arbeta med tillgänglighet. Hos HiQ Mälardalen likt andra företag finns det redan ett standardkoncept som de arbetar med för att se till att de utvecklar tillgängligt. Däremot garanterar det inte att detta koncept uppfyller de krav som kommer med direktivet. Att inte följa direktivet kan enligt lag f˚a konsekvenser. Därför är det av största vikt att deras arbetsprocess ses över och ocks˚a se hur de kan inkludera samtliga aspekter av direktivet samt hur de kan säkerhetsställa att direktivets krav är uppn˚adda. Därmed blir syftet för detta arbete att se till hur företaget kan arbeta för att uppfylla de kriterier som direktivet har.

4.1. Avgr¨

asningar

Direktivet riktar sig till offentliga myndigheters mobila applikationer, intranät samt webbplatser. För att avgränsa arbetet kommer fokus endast ligga p˚a webbplatser. Eftersom HiQ Mälardalen arbetar med utvecklandet av olika sorters webbplatser kommer arbetet endast fokusera p˚a de kommunala webbplatser som företaget utvecklar och förvaltar. Detta eftersom direktivet endast innefattar de webbplatser som hör till offentliga myndigheter, kommuner samt webbplatser som ger samhällsinformation som ska vara tillgängliga för alla.

5. Fr˚

agest¨

allningar

Denna studie kommer se över och besvara följande fr˚ageställningar: 1. Hur ser personer som arbetar med webbutveckling p˚a tillgänglighet?

2. Finns det en medvetenhet ang˚aende Webbtillgänglighetsdirektivet hos anställda p˚a företag som hanterar webbutveckling idag?

3. Hur kommer Webbtillgänglighetsdirektivet p˚averka hur företag arbetar med tillgänglighet idag?

4. Kan företag med hjälp av ett verktyg upptäcka missade punkter i direktivet innan publicering av webbplats?

(14)

6. Metod

För att kunna besvara samtliga fr˚ageställningar behövdes flera olika metoder kombineras. Arbetet gjordes som en fallstudie med fokus p˚a HiQ Mälardalen AB. De metoder som användes i det här arbetet är en litteraturstudie, intervjuer samt tv˚a analyser av webbplatser HiQ Mälardalen tidigare utvecklat. Anledningen att samtliga metoder genomfördes var för att ge en bred grund för att säkerställa svar p˚a fr˚ageställningarna. Nedanför kommer dessa förklaras mer ing˚aende.

6.1. Litteraturstudie

Det viktigaste för att kunna skapa först˚aelse och ge en möjlighet att sätta sig in i vad Webb-tillgänglighetsdirektivet innebär var att genomföra en grundlig litteraturstudie av direktivet. Denna studie skulle resultera i god först˚aelse kring samtliga artiklar som direktivet inneh˚aller. Litteratur-studien la grund för delar av bakgrunden till det här arbetet. Litteraturstudien underlättade ocks˚a för vidare arbete med att kunna besvara fr˚ageställningarna. Att tillägga kom litteraturstudien att lägga en grund för de intervjuer som genomfördes samt för hur analysen av webbplatserna gick till. Direktivet hämtades fr˚an Regeringskansliet i form av ett rättsligt dokument som inneh˚aller in-formation om dels varför direktivet ska genomföras, p˚aföljder om direktivet inte följs samt en bilaga av Europaparlamentets och r˚adets direktiv (EU) om tillgänglighet avseende offentliga myndigheters webbplatser och mobila applikationer.

6.2. Intervjuer

Eftersom HiQ Mälardalen redan arbetar med tillgänglighet i sin utvecklingsprocess var det viktigt att identifiera vad deras fokusomr˚ade var samt efter vilka riktlinjer de anpassar sig i dagsläget. För att enklast ta reda p˚a det genomfördes intervjuer anställda p˚a företaget som arbetar specifikt med just tillgänglighet. Dessa personer arbetar inom design (exempelvis Art Director (AD)), User Experience (UX) och FrontEnd-omr˚adet. M˚alet var att intervjua s˚a m˚anga som möjligt som är anställda p˚a HiQ Mälardalen för att skapa en s˚a bred först˚aelse som möjligt av företaget. För att komplettera och validera det som framkom i intervjuerna hos företaget genomfördes även intervjuer hos andra referensföretag tills det att det uppst˚att mättnad. Intervjuerna med andra företag gjordes för att säkerställa resultat och för att enklare dra slutsatser.

Intervjuerna utformades efter en framtagen intervjuguide som baserats p˚a de aspekter som Webbtillgänglighetsdirektivet lyfter samt p˚a fr˚agor som gav underlag för en först˚aelse av deras nuvarande arbetsprocess. Intervjuerna spelades in för att sedan transkriberas. Att spela in inter-vjuerna gjorde det möjligt att g˚a tillbaka i intervjuerna för att se om det finns detaljer som missats. Intervjuerna följde forskningsetiska principer och g˚ar att läsa mer ing˚aende om i sektionen ”Etiska aspekter”i detta arbete.

6.3. Analys av webbplatser

Offentliga webbplatser är inte n˚agot nytt för HiQ Mälardalen. Därför analyserades företagets tidi-gare utvecklade webbplatser. P˚a s˚a vis var det möjligt att identifiera vilka aspekter som redan tas till hänsyn under utvecklingsprocessen men ocks˚a även vilka delar av direktivet som inte ännu till-godoses. För att genomföra analyserna krävdes en god litteraturstudie som underlag men behövde ¨

aven en litteraturstudie kombinerat med resultaten fr˚an intervjuerna. Genom att ha lagt upp ar-betet p˚a detta sätt var det möjligt att se hur de anställda som är delaktiga i utvecklingsprocessen förh˚aller sig till tillgänglighet kontra vad som faktiskt sker i praktiken. När analyserna var klara gick att se vad företaget skulle behöva att lägga mer fokus p˚a för att uppfylla de krav som direktivet bär med sig.

Till analysen valdes tv˚a hemsidor ut, Hemsida 1 samt Hemsida 2. P˚a starkt önskem˚al fr˚an HiQ Mälardalen är namnen p˚a sidorna utelämnade. Dessa tv˚a webbplatser blev utvalda eftersom de kommer att omfattas av den nya förordningen. För att göra omfattningen av arbetet rimligt s˚a analyserades fyra till fem sidor för varje webbplats. Hade ett urval inte skett s˚a skulle arbetet blivit för stort men även blivit ett onödigt repetitivt arbete. Flertalet sidor använder sig av samma sidmall och därmed räcker det med att granska en sida som använder sidmallen istället för flera.

(15)

7. Etiska aspekter

Denna studie använder sig av intervjuer med personer. Det är en självklarhet att de personer som deltar i intervjuerna garanteras fullständig anonymitet. Data som samlas in fr˚an intervjuerna kommer att förvaras säkert och inte vara ˚atkomligt för andra människor. Informationen som samlas in kommer endast användas till att besvara fr˚ageställningarna i detta arbete. Inga namn eller andra personuppgifter kommer att framg˚a i arbetet. Efter att arbetet är avklarat och godkänt kommer all information som samlats in raderas. Samtliga deltagare har rätten att avbryta sitt deltagande när som helst under arbetets g˚ang. Om deltagarna vill f˚ar de ta del av resultatet och detta arbete. Arbetet kommer gynna företag dels ekonomiskt men även ge social utveckling. Genom att undersöka hur utvecklare, designers och UX:are förh˚aller sig till tillgänglighet samt hur väl företag utvecklar webbplatser kommer arbetet gynna företag i deras utvecklingsprocess för att undvika vanliga missar och fallgropar. Dessa missar kan enligt det nya direktivet komma ha p˚aföljder. Genomförandet av denna studie kan resultera i att s˚adana utfall kan undvikas.

Ur ett socialt perspektiv kommer arbetet förhoppningsvis gynna de i samhället som själva inte n˚ar upp till de krav p˚a som omgivningen ställer vid användadet av webbplater. Genom att säkerställa att webbplatser tillgänglighetanpassas enligt de krav som direktivet ställer kommer barriären mellan omgivningens krav och funktionsnedsättningen att planas ut och webben kommer bli mer tillgängligt för alla.

(16)

8. Sammanst¨

allning av direktiv

För att kunna skapa en konkret bild av den lag som började gälla tidigare i ˚ar s˚a genomfördes en litteraturstudie p˚a direktivet och dess tillhörande lagparagrafer. Direktivet g˚ar att finna i det dokument som Finansdepartementet har publicerat [4]. Majoriteten av häftet förklarar mestadels vad som ska utföras snarare än hur det ska utföras. Direktivet i sig inneh˚aller inte de konkreta riktlinjer som ska uppfyllas utan refererar vidare till standard kallad EN 301 549 v.2.1 2 som i sin tur förklarar att de krav som ska uppfyllas är WCAG 2.1. Därför har fokus även varit p˚a att först˚a de niv˚aer av krav som WCAG ställer.

För att hitta vidare information om vad som WCAG 2.1 mer konkret innebär och bredda min först˚aelse för samtliga kriterier och niv˚aer samlades information in fr˚an W3Cs webbplats [12]. Där gavs det möjlighet att mer specifikt sätta sig in i samtliga niv˚aer och kriterier som WCAG 2.1 innebär. Denna webbplats valdes eftersom det är W3Cs WAI som tagit fram de riktlinjer som gäller och därmed ans˚ags som grunden till källan för det som rör WCAG.

Majoriteten av denna litteraturstudie gjorde grunden för detta arbete och g˚ar att finna i bak-grunden i sektion 2.3.. Denna litteraturstudie kom även att lägga en viktig grund för utformningen av slutprodukten av arbetet.

9. Genomf¨

orande av intervjuer

För att kunna besvara fr˚ageställningarna genomfördes ˚atta semistrukturerade intervjuer med per-soner inom yrkesrollerna AD, UX-designers samt webbutvecklare. Dessa yrken valdes d˚a de är högst relevanta för detta arbete och omfattas redan eller kommer omfattas av de krav som direktivet ställer. Intervjuerna skedde enskilt med anställda p˚a HiQ Mälardalen som p˚a n˚agot vis arbetar relaterat med webbplatser som kommer omfattas av direktivet. För att verifiera de resultat som framkom fr˚an HiQ genomfördes även intervjuer med utvecklare och UX-designers och designers p˚a andra företag. Ytterligare en anledning att anställda p˚a andra företag inkluderades var för att stärka anonymiteten hos de anställda p˚a HiQ.

Majoriteten av deltagarna arbetar mot den offentliga sektorn i n˚agon form även om vissa deltagare jobbar inte specifikt mot offentliga sektorn men däremot för en bred m˚algrupp där tillgänglighetsanpassning spelar en viktigt roll. De anställda p˚a HiQ Mälardalen handplockades av företaget medan de personer som arbetar p˚a andra företag har hittats via kontakter. Det viktigaste var att fokusera p˚a att de hade rätt yrkesroll för att passa in i den eftersökta m˚algruppen.

Intervjuerna skedde enskilt och följde en framtagen intervjuguide men anpassades även mycket efter vad som framkom i intervjuerna och därav den semistrukturerade intervjustilen. Genom att använda denna struktur för intervjuer var det möjligt att f˚a ett bra flöde i intervjun men även för att skapa en samtalskänsla snarare än en formell intervju. Intervjuerna inleds med fr˚agor som säkerställer att de som deltar tagit del av syftet med intervjun, om de tagit del av de forskningsetiska principerna samt vilken ˚alder och vilken specifik yrkestitel deltagarna har. Efterföljande fr˚agor delades in i tv˚a olika grupper, Tillgänglighet och Webbtillgänglighetsdirektivet för att skilja p˚a de tv˚a olika omr˚adena. Syftet med fr˚agorna i de olika grupperingarna g˚ar att se nedanför i Tabell 2. För att öka tillförlitligheten och säkerställa att deltagaren f˚att allt hen velat f˚a sagt s˚a avslutades samtliga intervjuer med fr˚agan om det finns n˚agot ytterligare de skulle vilja tillägga.

(17)

Fr˚

agor ang˚

aende

Syfte

˚

Alder och yrke

Identifiera m˚

algrupp

Tillg¨

anglighet

Identifiera erfarenhet & medvetenhet,

f¨

orst˚

aelse av begreppet tillg¨

anglighet samt

se om arbetsplats ger tillr¨

ackligt med st¨

od

f¨

or att f¨

orst˚

a vad tillg¨

anglighet ¨

ar

Webbtillg¨

anglighetsdirektivet

Identifiera erfarenhet,

medvetenhet kring de krav direktivet st¨

aller,

om tillr¨

acklig information ges fr˚

an f¨

oretaget,

hur arbetet kring direktivet sker samt vad som

personligen skulle underl¨

atta s¨

akerst¨

allandet av

att de f¨

oljer direktivet

Tabell 2: Val av fr˚agor och dess syfte

Intervjuguiden följdes för samtliga intervjuer där deltagarna fick berätta och svara p˚a olika fr˚agor ang˚aende tillgänglighet och webbtillgänglighetsdirektivet. Majoriteten av fr˚agorna var öppna och fria medan det även förekom n˚agra specifika fr˚agor som krävde mer detaljerade svar. De specifika fr˚agorna kring intervjun g˚ar att se i Bilaga A. Hälften av intervjuerna skedde under fysiskt möte medan den andra hälften tog plats online via Skype. Eftersom hälften av intervjudeltagarna befann sig p˚a annan ort blev Skype en bra lösning s˚a att de p˚a annan ort fortfarande kunde befinna sig p˚a sin arbetsplats. För att underlätta kommande arbete och säkra anonymiteten fick varje enskild intervjuperson ett unikt nummer mellan 1 till och med 8. Det unika numret har inget att göra med vilken ordning intervjuerna skedde i.

Efter att f˚att fr˚agan om samtycke spelades majoriteten av intervjuerna in digitalt för att dels underlätta det framtida arbetet men även för att säkerställa att inga viktiga delar i intervjun missats. N˚agra f˚atal anteckningar togs p˚a papper men största fokus under intervjun l˚ag p˚a att lyssna och ta in den informationen och svar som deltagaren gav. Att göra p˚a detta sätt framst˚ar en som närvarande men även ger även en trygghet för de personer som deltar i intervjuprocessen. De intervjuer som inte spelades in var p˚a grund av tekniska problem. Under dessa intervjuer togs fysiska anteckningar istället.

9.1. Transkribering och analysarbete

Efter genomförandet av intervjuerna l˚ag fokuset p˚a att transkribera samtliga intervjuer och därefter kunna identifiera kärnan som g˚ar att finna i varje enskild intervju. Längden p˚a intervjuerna hade ett varierande spann p˚a allt fr˚an 7 minuter upp till 115 minuter. Transkriberingen bestod av att lyssna igenom samtliga inspelade intervjuer och sedan antecknades ordagragrant vad som sas under intervjun. Just denna del av processen tog väldigt mycket tid d˚a intervjuerna behövde genomlyssnas flera g˚anger för att säkerställa att transkriberingen skett korrekt. För de intervjuer som inte gick att spela in s˚a renskrevs anteckningarna noggrant.

Efter att ha genomfört transkriberingen s˚a skulle anteckningar samt transkriberingarna analy-seras. Alla intervjuer under analysarbetet koncentrerades genom att ta bort irrelevant information och därefter fylldes den koncentrerade transkriberingen i en tabell som g˚ar att se i Tabell 3 p˚a nästa sida. (Tabellen är i denna rapport ifylld med text utan mening och endast för att visa ta-bellens struktur). Vad som klassas som irrelevant information var exempelvis sm˚aprat och annat som inte rörde själva kärnfr˚agorna i intervjuerna. Tabellen användes för att ge en god överblick av vad samtliga deltagare faktiskt sagt för respektive fr˚aga i intervjun och för att enklare kunna identifiera kärnan och liknelser mot andra intervjuer. Varje rad i tabellen representerar en snar-likt formulerad fr˚aga som g˚ar att finna i intervjuguiden (Bilaga A). Dessa sammanfattningar blev sammanlagt cirka en till tv˚a A4 per intervjuad person.

(18)

Intervjuperson X ˚

Alder x

Yrke Lorem ipsum.

Vad är tillgänglighet? Lorem ipsum dolor sit amet, consectetur adipiscing elit. Arbetat med tillgänglighet? Lorem ipsum dolor sit amet, consectetur adipiscing elit. Koll p˚a riktlinjer? Lorem ipsum dolor sit amet, consectetur adipiscing elit. Tillgänglighet i ˚atanke Lorem ipsum dolor sit amet, consectetur adipiscing elit. Viktigaste aspekter Lorem ipsum dolor sit amet, consectetur adipiscing elit. Tillräckligt material kring tillgänglighet Lorem ipsum dolor sit amet, consectetur adipiscing elit. Koll p˚a webbtillgänglighetsdirektivet Lorem ipsum dolor sit amet, consectetur adipiscing elit. Koll p˚a krav i direktivet Lorem ipsum dolor sit amet, consectetur adipiscing elit. Information kring direktiv fr˚an arbetsplats Lorem ipsum dolor sit amet, consectetur adipiscing elit. Effektivaste sättet att säkerställa direktivet Lorem ipsum dolor sit amet, consectetur adipiscing elit.

¨

Ovrigt Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Tabell 3: Sammanst¨allning av transkribering av intervju.

Genom att sammanställa samtliga deltagares intervjuer enligt tabellen ovan var nästa steg att hitta kärnan i dessa intervjuer. Sammanställningen var ett tidskrävande arbete d˚a det krävdes flera genomläsningar för varje enskild intervju. För att koncentrera det hela valdes det att fokuseras p˚a att tolka rad för rad. I varje rad som representerade en fr˚aga fetmarkerades ord och meningar som gav konkreta svar p˚a fr˚agan utan att p˚a n˚agot vis tas ur perspektiv. Dessa svar sammanställdes i en tabell med följande kolumner:

• Intervjuperson • Yrke • Tillgänglighet • Erfarenhet • Webbtillgänglighetsdirektivet • Information fr˚an arbetsplats • Säkerställa direktivet.

Denna tabell är en mycket mer komprimerad version av Tabell 3 och fyller i princip samma grund-funktion. I kolumnen för Intervjuperson fylldes det unika ID:t i. I Yrke fylldes den relevanta yr-kesrollen i, i detta fall var det primärt UX, AD eller webbutvecklare. Kolumnen för Tillgänglighet behandlade personernas uppfattning om vad tillgänglighet innebär för dem. Erfarenhet summe-rar erfarenhet kring att arbeta med just tillgänglighet. Webbtillgänglighetsdirektivet behandlar b˚ade perception om vad direktivet faktiskt är och de krav som direktivet innefattar. Information fr˚an arbetsplats sammanfattar om intervjupersonen f˚att stöd eller information ang˚aende Webb-tillgänglighetsdirektivet. Säkerställa direktivet behandlar fr˚agor huruvida intervjupersonen resone-rar kring det mest effektivaste sättet att säkerställda direktivet. Genom att sammanställa resultaten p˚a angivet sätt möjliggör det att samtliga deltagare f˚ar vara en del av arbetet. Tabellen g˚ar att finna i Tabell 4 & 5. Fr˚an de sammanfattande tabellerna blev det enkelt att hitta gemensamma mönster och därefter kunna läsa mina resultat. Viktigt att tillägga är att för att bibeh˚alla ano-nymiteten hos deltagarna s˚allades information som skulle kunna koppla deltagaren till sina svar bort. Var svaret relevant för detta arbete formulerades svaret om s˚a att det förmedlar samma sak utan att p˚a n˚agot vis bryta anonymiteten.

10. Genomf¨

orande av analys av webbplats

För att skapa en bredare grund till den produkt som senare ska framställas s˚a analyserades tv˚a webbplatser. Analysen baserades till största del p˚a den litteraturstudie som genomfördes tidigare i arbetet. Under denna fas l˚ag fokus p˚a att hitta vanliga missar som företag kan göra när de utvecklar webbplatser som ska uppfylla de krav som Webbtillgänglighetsdirektivet ställer.

(19)

10.1. Val av webbplatser

Valet av webbplatser skedde i samr˚ad med HiQ Mälardalen. Tv˚a hemsidor valdes ut d˚a dessa omfattas av de krav som Webbtillgänglighetsdirektivet ställer och är utvecklade av HiQ Mälardalen. För att undvika repetitivt arbete samt undvika att arbetet inte blev för brett valdes specifika sidor för respektive webbplats. För Hemsida 1 valdes följande typer av sidor ut för analys:

• Startsida • Navigeringssida • Informationssida • S¨okresultat

För Hemsida 2 valdes följande typer av sidor ut för analys: • Startsida

• A till ¨O-sida • S¨okresultat • Lediga jobb • Samlingssida

Ovannämna sidor valdes mer specifikt för att samtliga sidor har olika sidstrukturer samt är olika typer av sidor och därmed presenterar inneh˚allet p˚a olika sätt. I och med detta blir det viktigt att se över s˚a m˚anga typer av sidor med olika sidstruktur som möjligt för att f˚a en bred analys. Sidor med samma struktur s˚ags ej över.

B˚ada webbplatserna har tidigare blivit granskade externt utanför HiQ Mälardalen och ska vara utvecklade efter att följa standarden AA för WCAG 2.0. Även om dessa webbplatser eventuellt följer standarden för WCAG 2.0 är dessa även viktiga att se över därför att de kommer omfattas av de kraven som WCAG 2.1 ställer och m˚aste anpassas innan den 23 September 2020. Dessutom ger det en möjlighet att se vilka annorlunda krav som Webbtillgänglighetsdirektivet kommer att ställa jämfört med tidigare arbeten.

10.2. Checklista f¨

or analysering

För att lägga en stabil grund för analyserna av webbplatserna s˚a skapades en checklista (se Bi-laga B). Denna checklista baserades p˚a den litteraturstudie som tidigare gjordes av direktivet. Meningen med denna litteraturstudie var dels att underlätta för just denna specifika delen av arbetet. Baserat p˚a detta fick checklistan tre huvudrubriker, Tillgänglighetsredogörelse, Kommen-tarsfunktion och WCAG 2.1. Under huvudrubriken Tillgänglighetsredogörelse kräver checklistan att en tillgänglighetsredogörelse finns tillgängligt samt att denna tillgänglighetsredogörelse har en förklaring vart det är möjligt att rapportera upplevda hinder p˚a hemsidan. Under andra rubriken Kommentarsfunktion är det möjligt att checka av om en kommentarsfunktion är tillgänglig. Den tredje rubriken skiljer sig väldigt mycket fr˚an de tv˚a föreg˚aende. Under WCAG 2.1 listas samtliga krav som riktlinjen ställer. För varje riktlinje finns även en fr˚aga som besvaras med antingen Ja eller Nej. Utöver svartalternativen finns möjlighet att lämna n˚agon kommentar, exempelvis om elementet inte förekommer eller förbättringsförslag etc. Dessutom s˚a har samtliga riktlinjer även en förtydligande text kring vad som mer specifikt ska ses över p˚a samtliga punkter. Förutom den tidigare sammanställningen s˚a användes även Webbriktlinjers mer detaljerade förklaring för varje specifik punkt [20].

10.3. Analyseringsprocessen

Efter att noggrant följt checklistan och stämt av samtliga punkter mot sidan som ska analyseras s˚a markerades punkter som inte uppfyllde kravet med röd färg, grön för de som uppfyllde kravet samt gul färg p˚a de irrelevanta punkterna. Genom att göra p˚a det sättet s˚a skapades en enklare ¨

(20)

10.3..1 Analyseringsverktyg ¨

Aven om majoriteten av analysen skedde manuellt fanns det delar av analysen som krävde n˚agon form av hjälpmedel för att underlätta analyseringsprocessen. Dessa hjälpmedel användes för att ex-empelvis mäta kontrastvärden, förenkla diverse avst˚and ang˚aende text samt för att se ifall HTML1 och CSS2-filerna validerar. Samtliga verktyg är gratis och finns tillgängliga via internet att använda i en webbläsare. Följande verktyg användes för att genomföra detta arbete:

• WebAIM Color Contrast Checker 3 _{- Anv¨}_{andes f¨}_{or att j¨}_amf¨_{ora kontraster och m¨}_ata kon-trastvärde mellan olika färger. I verktyget anger användaren färgerna som ska jämföras och slutligen resultera i det exakta kontrastvärdet mellan färgerna.

• HTML5Accessibility Text Spacing Bookmarklet 4 _{- Anv¨}_{andes f¨}_{or att ¨}_{oka avst˚}_{and mellan} textkomponenter. Verktyget sparas som ett bokmärke som vid aktivering kör ett JavaScript som ökar de radavst˚and som är godkänt krav. Efter att kört scriptet g˚ar det enkelt att urskilja huruvida webbsidan uppfyller det kravet eller inte.

• W3C:s CSS-valideringstjänst 5 - Användes för att se om webbplatsens CSS-kod validerades. Resultatet presenteras i antal fel och varningar samt var koden inte valdierade.

• The W3C Markup Validation Service 6

- Anv¨andes f¨or att se om sidans HTML-kod valide-rades. Resultatet presenteras i antal fel och varningar samt var koden inte valdierade.

1_{Hyper Text Markup Language (HTML), anv¨}_{ands vid webbutveckling} 2_{Cascading Style Sheet (CSS), andv¨}_{ands f¨}_{or att piffa upp HTML-filerna} 3_{https://webaim.org/resources/contrastchecker/}

4_{https://www.html5accessibility.com/tests/tsbookmarklet.html} 5_{http://jigsaw.w3.org/css-validator/}

(21)

11. Resultat av intervjuer

Sammanlagt genomfördes ˚atta intervjuer med anställda inom arbetsomr˚aden som är relevanta re-levanta och berörda av Webbtillgänglighetsdirektivet. Utöver fr˚agor ang˚aende ˚alder och yrkesgrupp inleddes intervjuerna med fr˚agor kring hur intervjupersonerna upplevde vad tillgänglighet var för dem samt om de har n˚agon erfarenhet inom att arbeta med tillgänglighet. Näst intill samtliga deltagare ans˚ag att tillgänglighet var n˚agot som skulle möjliggöra användandet för alla människor och att det ska r˚ada samma villkor för alla typer av användare. Däremot var det endast en av deltagarna som uppgav sig arbetat med tillgänglighet i mer än ett ˚ar. I de vanligaste av fallen rörde det sig endast om n˚agra m˚anader eller ingen erfarenhet över huvud taget. Dessutom g˚ar det inte att urskilja om det gäller för ett specifikt yrkesomr˚ade utan ser ut att vara oberoende av yrkes-omr˚ade. Intervjuerna gav generellt en tydlig bild av att de personer som arbetar inom AD, UX och webbutveckling har en gemensam syn p˚a innebörden tillgänglighet. Detta helt oberoende av deras erfarenhet av att arbeta med tillgänglighet och tillgänglighetsanpassning. I Tabell 4 nedanför g˚ar det att läsa hur varje enskild person ser p˚a tillgänglighet samt deras uppfattade erfarenhet inom omr˚adet.

Intervjuperson Yrke Tillg¨anglighet Erfarenhet

1 UX/AD Information tillgängligt ˚at alla Arbetat med tillgänglighet i 1.5 ˚ar 2 UX/AD Möjlighet att använda samma app p˚a samma villkor Fyra m˚anader

3 Webbutvecklare Att allt ska vara tillgängligt I ett projekt p˚a företaget 4 UX Att webb och material är tillgängligt för alla Ingen erfarenhet

5 AD Alla människor ska kunna ta del och det ska vara kravlöst Endast i projekt p˚a företaget, nyss anställd

6 Webbutvecklare Vem som helst ska kunna använda Alla projekt p˚a företaget har inneburit arbete med tillgänglighet 7 UX Det ska fungera för alla och alla ska kunna först˚a Ingen erfarenhet

8 Webbutvecklare När allt fungerar s˚a är det tillgängligt Ingen erfarenhet

Tabell 4: Resultat av intervjuer

Intervjuperson Webbtillgänglighetsdirektivet Information fr˚an arbetsplats Säkerställa direktivet

1 Upplever sig ha koll p˚a direktivet men ej specifika krav Behöver mer stöd/information - Checklista efter yrkesgrupp_{- Samtliga deltagare i projektet ser ¨}_{over samtliga krav tillsammans} 2 Upplever sig ha lite koll p˚a direktivet Inte s˚a mycket stöd - Checklista i varje fas av projektet

- N˚agon intern granskar innan publicering 3 Upplever sig ha ingen koll p˚a direktivet Delvis, hade beh¨ovt mer - Automatiserade kodcheckar innan arbetet

pushas upp p˚a GitHub eller liknande

4 Upplever sig ha okej koll p˚a direktivet Behöver mer stöd/information - Grundlig unders¨_{- Checklista} okning i hur företaget arbetar med tillgänglighet 5 Upplever sig ha d˚alig koll p˚a direktivet Delvis, mest stöd fr˚an kollegor i samma omr˚ade

- Checklista

- Individuellt ansvar att h˚alla sig uppdaterad - S¨akerst¨alla kompetens

6 Upplever sig ha ingen koll p˚a direktivet - - Kodkolla varandra internt i varje deluppgift av_sj¨_{alva projektet} 7 Upplever sig ha grundl¨aggande kunskaper om direktivet Ingen information alls - Ha en ansvarig inom omr˚_{- Checklista} adet

8 Upplever sig ha lite koll p˚a direktivet Ingen information alls - Checklista innan publicering

Tabell 5: Resultat av intervjuer, forts¨attning.

Endast tre av de intervjuade personerna upplevde sig ha en uppfattning av Webbtillg¨ anglighetsdirek-tivet och vad direkanglighetsdirek-tivet faktiskt innebär (Intervjuperson 1, 4 samt 7). Dessa tre personer delar dessutom samma yrkesroll (UX). Men över lag brast det i medvetenhet kring direktivet hos de flesta av de intervjuade personerna oavsett yrkesroll. Samtliga deltagare utom en som inte uppgav ett konkret svar p˚a fr˚agan upplevde en brist p˚a information om direktivet fr˚an sin arbetsplats. Vissa av deltagarna hade p˚a egen hand eller med företaget varit p˚a kortare föreläsning om ämnet men inte mer än s˚a. Därav visar resultaten tydligt att det finns en brist p˚a material hos företag att dela med anställda för att öka kunskapen om de krav som ställs av direktivet.

Eftersom det är personer inom dessa yrkesroller som kommer arbeta med att se till att de faktiskt uppfyller de krav som direktivet ställer kändes det viktigt att se vad de upplevde som ef-fektivaste sättet att säkerställa direktivet. Sex personer av ˚atta svarade att n˚agon form av checklista hade kunnat vara ett alternativ. Det gavs varierande svar p˚a hur checklistan skulle vara utformad men tv˚a deltagare gav svar som änd˚a kan kopplas ihop. Dessa svar var att checklistan ska utfor-mas efter yrkesgrupp eller att en checklista ska användas för varje fas i projektet: det vill säga design och UX-fas samt en implementationsfas. P˚a s˚a vis g˚ar det även att koppla ihop tillsammans med yrkesroll. Andra svar som framkom var intern granskning, automatiserade kod-checkar innan publicering p˚a GitHub7_{, ha en anst¨}_{alld ansvarig samt ha individuellt ansvar.}

(22)

12. Resultat p˚

a analys av webbplatser

Samtliga utvalda sidor fr˚an Hemsida 1 och Hemsida 2 s webbsidor analyserades enligt checklistan framtagen tidigare i arbetet. Checklistan finns tillgänglig i Bilaga B. Sammanlagt finns 52 punkter att stämma av och är i följande text refererade till numreringen i checklistan. Viktigt att notera ¨

ar att alla punkter inte finns tillgängliga för mätning p˚a sidan d˚a det inte finns n˚agot element som faller inom ramen för det kravet som ställs. Exempelvis punkter som kräver att det finns ljudmaterial, videofiler, eller liknande p˚a sidan för att kunna analyseras. Bilder p˚a samtliga sidor av webbplatserna finns tillgängliga i Bilaga C. Dessa bilder är avbildade av webbplatserna i Maj 2019.

12.1. Hemsida 1

F¨or Hemsida 1 sida fanns det punkter som var ˚aterkommande under analysen f¨or samtliga sidor. ¨

Overlag saknade webbplatsen en tillgänglighetsredogörelse samt en kommentarsfunktion. Utöver dessa tv˚a p var ett förekommande problem p˚a samtliga sidor att i deras navigeringsmeny högst upp p˚a sidorna (se Figur 2) inte uppfyller krav nummer 1.4.3 som säger att kontrasten mellan text och bakgrund ska minst vara 4.5:1. I menyraden finns länken *** växer (markerat med vit rekangel) som har en mörkrosa ton (i hexadecimal färgkod #FF7246) p˚a en gr˚aare bakgrund (i hexadecimal färgkod #333333). Jämförs dessa färger f˚ar de kontrastskillnad 3.79:1 vilket är under lägsta rekommendation fr˚an WCAG 2.1.

Figur 2: Huvudmeny p˚a Hemsida 1 s webbplats

Ytterligare ett problem som förekommer p˚a samtliga sidor är att sökfunktionen saknar tydli-ga fältetiketter 8_{. Enligt krav 3.3.2 ska f¨}_{altetiketter vara tydliga och f¨}_{orklarande och d¨}_{armed ge} användaren en möjlighet att först˚a vad som ska matas in. Figur 3 nedanför visar tydligt att det inte finns n˚agon fältetikett vid sidan av sökfältet. Dessutom för att förtydliga hade det varit lämpligt att ha n˚agon förklarande text vid eller innuti sökrutan s˚a användaren tydligt kan först˚a att det här är fältet där sökningen sker.

Figur 3: S¨okfunktion p˚a Hemsida 1 s webbplats

Punkt 2.4.1 samt 2.4.3 berör bland annat tab-navigation. Det vill säga att användaren genom tab-tangenten ska kunna navigera sig genom sidan utan att stöta p˚a förhinder. För personer som använder sig av denna typ av navigation eller annan alternativ navigation ska istället för att använda musrörelser kunna hoppa över repetitivt inneh˚all p˚a sidan genom alternativa genvägar. För samtliga sidor m˚aste användaren tabba igenom allt inneh˚all för att komma till slutet. Ingen genväg finns tillgänglig samt ingen möjlighet att kunna hoppa över repetetativt inneh˚all.

(23)

Ingen av de analyserade sidorna godkändes under punkt 4.1.1 där riktlinjerna säger att koden m˚aste validera. Med andra ord att koden m˚aste vara robust s˚a hjälpmedel kan förlita sig p˚a att koden är korrekt. Med hjälp av W3Cs HTML- och CSS-validerare fick samtliga sidor felmeddelanden.

Vissa punkter p˚a checklistan berör inte sidorna p˚a webbplatsen alls. Därför var det möjligt att stryka punkter som var irrelevanta. De punkter p˚a checklistan som uteblev för samtliga sidor hos Hemsida 1 s webbplats var 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.3.3, 1.3.5, 1.4.13, 1.4.2, 2.1.4, 2.2.1, 2.2.2, 2.3.1, 2.5.1, 2.5.4, 3.2.4, 3.3.4, 4.1.2 samt 4.1.3.

12.1..1 Startsida

För startsidan p˚a Hemsida 1 s webbplats kunde, utöver de 19 icke-mätbara punkterna, 23 godkännas och 10 underkännas. Utöver de problem som är nämnt ovanför s˚a saknar den större bilden p˚a start-sidan n˚agon form av bildtext. Bildtexter ska finnas tillgängligt för att underlätta för exempelvis synskadade. Genom att inspektera elementet i webbläsaren var det inte möjligt att finna n˚agon alternativ bildtext. P˚a grund av det uppfyller startsidan inte krav 1.1.1. I Figur 4 g˚ar det att se bilden samt i Figur 5 g˚ar det att utläsa att det inte finns n˚agot attribut, alternativt ett namn med bildtext tillhörande bilden.

Figur 4: Bild p˚a startsida f¨or Hemsida 1 s webbplats

Figur 5: Attribut tillh¨orande bild p˚a startsida

Ett annat förekommande problem är vid ökandet av teckenavst˚and samt av radavst˚and s˚a kompli-ceras användaruppevelsen d˚a texten p˚a den tredje länken i Figur 7 som infinner sig p˚a startsidan f˚ar en pil över textfältet. P˚a s˚a vis uppfyller sidan inte krav 1.4.12 som säger att avst˚and mellan bokstäver, ord, text och rader ska kunna ökas utan att information försvinner eller försv˚arar för användaren.

Figur 6: L¨ankar placerade p˚a bilden p˚a startsidan

Sidnamnet p˚a startsidan är ”Välkommen till *** - *** kommun”. Det framg˚ar ingenstans i sidnam-net att sidan användaren befinner sig p˚a är startsidan. Enligt punkt 2.4.2 ska sidan ha beskrivande sidtitlar. Detta hade enkelt kunnat korrigeras med Startsida - *** kommun”.

12.1..2 Navigeringssida

För navigeringssidan av Förskola och skola förekom det ˚atta ej godkända punkter samt 25 godkända punkter. Precis som p˚a startsidan saknade den stora bilden n˚agon form av alternativ bildtext för de personer som inte kan tyda eller se bilden över huvud taget. Utöver avsaknaden av bildtext var de förekommande problemen densamma som de som tidigare listade gemensamma problem för samtliga sidor.

(24)

12.1..3 Informationssida

Endast sju punkter p˚a informationssidan föll under kategorin ej godkända. Dessutom kunde, utöver de punkter som nämndes för samtliga sidor, punkt 1.4.1 samt 1.4.5 hoppas över vilket i sin tur resulterar i 24 godkända punkter. Till skillnad fr˚an de tv˚a tidigare nämnda sidor saknar denna sida n˚agon form av stor bild p˚a sidan och därmed är inte i samma behov av exempelvis bildtexter. 12.1..4 Sökresultat

P˚a sökresultatsidan kunde ytterligare tre punkter bortses d˚a inget element fanns att analysera. Dessa punkter var 1.1.1, 1.4.1 samt 1.4.5 d˚a sidan inte behandlar n˚agot bildmaterial eller förmedlar information med hjälp av färg. Utöver nämna punkter s˚a godkändes sidan p˚a totalt 19 punkter. Dock fanns det element p˚a sidan som inte uppfyllde punkter som inte förekommit p˚a tidigare sidor. Sökresultatsidan brister i punkt 1.3.1 d˚a vissa HTML-element inte används p˚a korrekt sätt. P˚a vänstersidan om sökresultaten g˚ar det att finna en meny där användaren kan välja att filtrera sina resultat. Rubriken för Filtrera resultat använder sig av ett paragraf-element (p) (se Figur 7). Textstycket är en rubrik och det skulle passa bättre med att använda ett rubrikelement, exempelvis h29) för att förtydliga för de användare som exempelvis inte ser skärmen.

Figur 7: Rubrik som använder p-element istället för h2

Figur 8: Rubrik som har ett button-element Under paragrafen för Filtrera resultat är det möjligt att sortera sökresultaten mer detaljerat. Dessa kategorier som finns tillgängliga är Typ av resultat, sektion samt spr˚ak. Ett nuvarande problem p˚a webbsidan är att dessa rubriker som är ovanför de sorterande knapparna ocks˚a är deklarerad som en knapp (med HTML-elementet button). Även detta hade kunnat bytas ut mot ett rubrikelement, exempelvis ett h3 element d˚a det skulle komma efter en h2 rubrik.

Enligt punkt 2.4.4 ska länkar vara tydligt formulerade och ett tryck p˚a länken ska stämma ¨

overens med vad användaren förväntar sig ska ske. Efter att ha sökt p˚a ordet skola i sökfältet kommer flertalet resultat upp med samma namn, exempelvis länkar till sidorna Skapande skola (se Figur 9). Dessa tv˚a länkar har samma namn och leder till olika sidor vilket kan upplevas förvirrande för användaren. Därför bör det förtydligas att dessa länkar inte leder till samma sida. Samma problem förekommer även för andra sökresultat.