Anvendte værktøjer til analyse
I nedenstående tabel gennemgås de værktøjer vi anvender til monitoreringer, samt hvordan og hvorfor vi anvender netop disse. Det angives desuden hvilke værktøjer der anvendes til henholdsvis forenklede og dybdegående tilgængelighedsanalyser.
Værktøj
|
Begrundelse
|
Forenklet
|
Dybdegående
|
Axe
|
Axe er et værktøj udviklet af Deque, en virksomhed med stor ekspertise inden for tilgængelighed på internettet.
Axe findes som Google Chrome udvidelse, og denne udvidelse er særligt god til automatiserede test, da man hurtigt kan få et overblik over WCAG-fejl og advarsler. Axe indeholder desuden et inspiceringsværktøj, hvor man nemt guides til den pågældende fejl, samt bliver præsenteret for de succeskriterier i WCAG, der er brud på.
Vi anvender derfor AXE som værktøj for at få det hurtige, overskuelige overblik.
|
x
|
x
|
WAVE
|
WAVE er udviklet af WebAIM (Web Accessibility In Mind), en organisation ved Utah State University som har leveret tilgængelighedsløsninger siden 1999.
WAVE leverer på samme vis som AXE automatiserede tilgængelighedstests, men er ikke nær så effektivt til at skabe et overblik over fejl. Til gengæld indeholder WAVE flere tekniske funktioner, såsom at slå stylesheets fra, tjekke headline order, sammenligne kontrastforhold mm.
Vi anvender derfor WAVE i kombination med AXE, for at få mere detaljerede indsigter i fejl.
|
x
|
x
|
JAWS
|
JAWS er en populær skærmlæser udviklet af Freedom Scientific, som specialiserer sig i teknologier, der hjælper mennesker med handicap.
Vi benytter JAWS i tilgængelighedstests, da denne er den foretrukne skærmlæser blandt Windows brugere.
Skærmlæseren bruges i dybdegående tests, da vi med den oplever siden på samme måde som bl.a. en blind person, og opdager eventuelle programmeringsfejl, som læses op i stedet for decideret tekst til skærmlæseren. Derudover giver skærmlæseren os også indsigt i oplæsningsrækkefølgen.
|
|
x
|
SortSite
|
SortSite er en tilgængelighedsscanner udviklet af PowerMapper, som scanner hele eller enkelte websites for tilgængelighedsfejl i WCAG 2.1 niveau A, AA og AAA.
SortSite har den fordel, at den er dybdegående og tjekker alle elementer på et website.
Vi anvender derfor SortSite i dybdegående monitoreringer for at sikre et gennemtjek af hele websitet.
|
|
x
|
Google Audits
|
Google Audits er et værktøj indbygget i Google Chrome’s DevTools, som skaber en simpel rapport over blandt andet et websites tilgængelighedsfejl.
Vi anvender værktøjet til at få et hurtigt overblik over tilgængelighedsfejl.
|
x
|
|
VoiceOver
|
VoiceOver er Apples indbyggede skærmlæser.
Vi tester med VoiceOver, fordi dette er den foretrukne skærmlæser blandt Mac brugere.
Skærmlæseren bruges i dybdegående tests, da vi med den oplever siden på samme måde som bl.a. en blind person, og opdager eventuelle programmeringsfejl, som læses op i stedet for decideret tekst til skærmlæseren. Derudover giver skærmlæseren os også indsigt i oplæsningsrækkefølgen.
|
|
x
|
Color Contrast Checker
|
Vi anvender WebAIMs Color Contrast Checker, da værktøjet kan teste et websites farvekontrastforhold og sammenstille dem med WCAG 2.1 succeskriterierne. Værktøjet tester automatisk også om kontrasten på for- og baggrundsfarver lever op til WCAG 2.1 med normal tekst, stor tekst og grafiske objekter.
|
x
|
x
|
Markup Validation Service
|
Markup Validation Service er et værktøj udviklet af W3C (World Wide Web Consortium), som giver en hurtig, automatiseret test af en hjemmesides HTML.
Vi anvender værktøjet specifikt til at validere websitets HTML, så vi hurtigt kan få et overblik over hvilke dele af sidens HTML, der parser.
|
x
|
x
|
Chrome DevTools
|
DevTools er udviklet af Google, og er Chrome browserens indbyggede udviklerværktøj.
Vi bruger DevTools til at undersøge koden, og trække HTML snippets ud til vores rapporter.
|
x
|
x
|
The Rotor
|
The Rotor er et værktøj udviklet af Apple, der fungerer som et navigationselement i samspil med Apples VoiceOver skærmlæser.
Vi bruger The Rotor til test af f.eks. oplæsningsrækkefølgen, opbygning af menuer mm.
|
|
|
Talkback
|
Talkback er en skærmlæser udviklet af Google, og er Androids modsvar til VoiceOver.
Vi tester med Talkback da dette er den gængse skærmlæser på Android devices.
|
|
|
Xcode Accessibility Inspector
|
Hvis vi har adgang til en mobilapplikations udviklerfiler, laver vi en automatiseret test i Apple’s Xcode Accessibility Inspector. Med dette værktøj får vi rapporter over områder som kontrastforhold, labels, fokusområder, transparens mm.
|
|
|
Android Accessibility Scanner
|
Android Accessibility Scanner er en Android app udviklet af Google. Med denne scanner kan vi udføre automatiserede tests af kontrastforhold, beskrivelser, trykpunkter mm.
|
|
|
Forenklede analyser
I følgende afsnit redegør vi for udvælgelse af succeskriterier, udvælgelse af konkrete sider til monitoreringer og processen for en enkelt monitorering.
Udvælgelse af succeskriterier
Den forenklede monitorering har til opgave at teste effektivt og bredt i WCAG 2.1 succeskriterierne. Metodedesignet er udviklet, så monitoreringen i så vid udstrækning som muligt anvender automatiserede tests. Af den årsag er automatisering medtaget som et selvstændigt udvælgelseskriterie i valg af WCAG succeskriterier der testes for. Derudover har vi vurderet hvert succeskriterie i forhold til alvorlighed og impact. Hvert succeskriterie er scoret fra 1-5 på hvert parameter, og herefter er der udvalgt de 17 succeskriterier med den højeste score, fordelt under underområderne; opfattelig, anvendelig, forståelig og robust.
- Alvorlighed
Er brud på succeskriteriet en showstopper, meningsforstyrrende eller uhensigtsmæssig for flere brugergrupper?
- Impact
Hvor mange brugere/brugergrupper berøres, hvis succeskriteriet ikke opfyldes?
Automatisering
Er det muligt at teste maskinelt (og således omkostningseffektivt) for dette succeskriterie?
Parametrene Alvorlighed og Impact er blandt andet vurderet efter, i hvilken grad en eller flere af følgende målgrupper påvirkes af brud på det givne succeskriterie:
- brug uden syn
- brug med nedsat syn
- brug uden farveopfattelse
- brug uden hørelse
- brug med nedsat hørelse
- brug uden taleevne
- brug med begrænset bevægelsesfrihed eller styrke
- behovet for at minimere udløsning af anfald som følge af lysfølsomhed
- brug med begrænset kognition
De succeskriterier som er udvalgt ud fra vores analyse og scoring ud fra ovenstående parametre, fremgår i oversigten først på siden.
Denne metode opfylder alle krav til udvælgelse af succeskriterierne i den forenklede monitorering, der opsættes i Kommissionens Gennemførelsesafgørelse (EU) 2018/1524, Bilag 1, afsnit 1.3.
Hertil kommer, at denne metode også sikrer, at vi udvælger de krav der har størst betydning for flest mulige brugergrupper, og dermed sikrer færre digitale forhindringer for borgere med funktionsnedsættelser.
Vi er bevidste om, at metoden i mange tilfælde baseres på subjektive vurderinger og vores konkrete erfaringer, da fejl inden for hvert enkelt WCAG 2.1 succeskriterie i sagens natur kan være af meget forskellig art. Vores vurdering beror således også på et skøn, i forhold til hvilke fejltyper vi oftest ser inden for hvert succeskriterie.
Udvælgelse af sider
Når der udvælges sider, er det vigtigt at ramme forskelligartede sidetyper, fordi der her kan optræde forskellige typer af tilgængelighedsbrud. I forlængelse heraf ønsker vi dog også, at bevare fokus på at sikre færrest mulige forhindringer for flest mulige borgere. Derfor har prioriterer vi, at der altid testes på de mest besøgte sider ud fra antagelsen om at dette i de fleste tilfælde er nøglesider. Vi tester på selvbetjening fordi det har stor konsekvens for brugere med funktionsnedsættelser hvis disse ikke kan anvendes. Vi tester altid søgningen og søgeresultaterne da denne i de fleste løsninger er en central funktionalitet og anvendes af mange. Endelig tester vi altid kontaktsiden eller en kontaktformular ud fra antagelsen om at dette i det mindste sikrer at man kan komme i kontakt med myndigheden. Ved at prioritere disse sidetyper sikrer vi, at tilgængelighedsanalysen fokuserer på de sider, der har størst betydning for flest brugere.
Således testes følgende sider:
- Forside
- Op til tre yderligere sideskabeloner
- Kontakside eller -formular (eller begge)
- Op til to selvbetjeningssider
- Tre sider som kvalitativt vurderes at have mest trafik
- Søgeresultatside
Dette betyder at der testes 9-12 sider i en forenklet monitorering.
Udførelse
Den forenklede tilgængelighedsanalyse udføres ud fra følgende proces:
- Sider til test udvælges og oplistes
- De udvalgte sider scannes med de automatiserede værktøjer. Hver af de fundne fejl vurderes og indsættes herefter i rapporten.
- Siderne gennemgås manuelt for de fejl, der kræver kvalitativ vurdering eller som de automatiserede værktøjer evt. ikke har fanget. Fundne fejl tilføjes i rapporten.
- En visuel opsummering af fejl genereres, og der udarbejdes en kvalitativ vurdering af websitets tilstand samt eventuelle anbefalinger til tiltag for at forbedre tilgængeligheden.
Dybdegående tilgængelighedsanalyse
Den dybdegående analyseg tager udgangspunkt i metoden som anvendes i de forenklede monitoreringer, men med yderligere testområder og værktøjer.
Test af alle succeskriterier
I modsætning til den forenklede monitorering testes alle succeskriterier til bunds i den dybdegående monitorering. Der anvendes både automatiske og manuelle metoder, samt kvalitative vurderinger af kvaliteten af websitets tilgængelighed. Se oversigten først på siden, hvor det beskrives, hvilke metoder der anvendes til at teste hvert enkelt succeskriterie.
Udvælgelse af sider
Udvælgelsen af sider for den dybdegående monitorering sker i overensstemmelse med Kommissionens Gennemførelsesafgørelse (EU) 2018/1524, bilag 1, afsnit 3 til 3.3. Alle dybdegående monitoreringer starter med en indledende analyse af websitet. Ud fra denne analyse oplistes de sider og funktionaliteter, der skal indgå i testen. Alle udvalgte sider afsøges for dialogbokse, brugergrænsefladekontroller, fejlmeddelelser og anden systemfeedback fra interaktion med brugeren, for at sikre at tilgængeligheden af disse undersøges.
For den dybdegående monitorering vil vi desuden anbefale, at der udvælges et sæt skønnede nøglesider, ud fra samme princip som i den forenklede monitorering, altså sider der kvalitativt vurderes at have flest besøg. Dette for at sikre at de vigtigste og meste anvendte sider for brugerne indgår i testen.
Forskelligartede enheder, teknologier og præferencer
Ved den dybdegående analyse testes hver side med et bredt udvalg af enheder, teknologier og præferencer for at sikre testens dybdegående karakter. Forskelligartede enheder, teknologier og præferencer anvendes ved de succeskriterier hvor det er relevant.
Udførelse
Ud fra ovenstående metode til udvælgelse af succeskriterier og konkrete sider som skal testes er vi nu klar til at gennemføre monitoreringen.
Testen udføres konkret ud fra følgende proces:
- Sider til test udvælges og oplistes
- De udvalgte sider gennemgås for dialogbokse, brugergrænsefladekontroller, fejlmeddelelser og anden systemfeedback fra interaktion med brugeren
- De udvalgte sider scannes med de automatiserede værktøjer. Hver af de fundne fejl vurderes og indsættes herefter i rapporten.
- Siderne gennemgås manuelt for de fejl, der kræver kvalitativ vurdering eller som de automatiserede værktøjer evt. ikke har fanget. Fundne fejl tilføjes i rapporten.
- Siderne gennemgås med skærmlæser og evt. andre assisterende teknologier for at de vigtigste fejl er fundet
- Et udvalg af succeskriterierne efterprøves med variation af teknologi og præferencer
- En visuel opsummering af fejl genereres, og der udarbejdes en kvalitativ vurdering af websitets tilstand samt eventuelle anbefalinger til tiltag for at forbedre tilgængeligheden.
Rapportformat
Vi har udarbejdet et rapportformat der skaber bedst muligt overblik, og giver klare handlingsanvisninger for, at få rettet eventuelle fejl.
Det primære fokus i rapporten er en klar indikation og overblik over websitets generelle tilstand. Dette inkluderer også en kvalitativ opsamling der anbefaler de vigtigste tiltag, der bør tages for at udbedre eventuelle tilgængelighedsproblemer. Disse tiltag er udvalgt ud fra fejl med den største alvorlighed og/eller hyppighed.
Herefter oplistes alle rapportens resultater fordelt på WCAG kriterier, med præcis beskrivelse af hvordan fejlen viser sig og et link til vores WCAG guide med konkret beskrivelse af hvordan den specifikke type fejl løses.
Rapportens opbygning
Rapporten er opbygget som følger:
- Indledning:
Kort introduktion til rapporten og dens indhold
- Overblik over resultater:
Opsummering af antal brud på succeskriterierne, og en oplistning over succeskriterierne som websitet er blevet testet på. For hvert succeskriterie er tilføjet en let, afkodelig visuel markering af, hvor websitet fejler og hvor det lever op til succeskriterierne.
- Anbefalede første tiltag:
Kort, kvalitativ opsummering af analysen, der sætter den enkelte myndighed i stand til hurtigt og effektivt at kunne påbegynde optimering af tilgængelighed. Dette afsnit kan fx omhandle, at de bør fokusere på uddannelse af redaktører, eller bør gå til deres designbureau og få tilrettet ikke-tilgængelige farver.
- Metode:
Oversigt over hvilke sider på websitet der er testet, samt hvem der har udført testen og hvornår. Herefter følger en kort og forståelig beskrivelse af den metode der er brugt til testen, herunder hvilke krav under WCAG 2.1 der er testet for, og hvilke værktøjer der er anvendt.
- Gennemgang af fejl:
Herefter følger listen over alle succeskriterierne, som websitet ikke lever op til. Ved hvert succeskriterie beskrives følgende:
- Hvordan bryder sitet med kriteriet?
Her beskrives det kort hvordan og hvor websitet fejler på succeskriteriet.
- Link til fejlen:
Herunder indsættes et direkte link til en side på websitet hvor fejlen forekommer.
- HTML:
For at sikre at en leverandør forstår specifikt hvor i HTML’en fejlen, findes indsættes en HTML snippet.
- Visuelt eksempel:
Hvis det er muligt indsættes et visuelt eksempel fra websitet, hvori fejlen findes.
- Hyppighed:
Herunder gives en vurdering af, hvor hyppig fejlen forekommer på websitet. Eksempelvis beskrives det her, om fejlen er enkeltstående, gennemgående på hele websitet eller specifik for særlige sider.
- Url:
Direkte links til de monitorerede sider fejlen er fundet på indsættes her, i en tabel med en angivelse af, hvor mange gange fejlen forekommer på siden.
- Læs mere om succeskriteriet og hvordan du efterlever kravene i WCAG 2.1 guiden:
Sidste punkt er et direkte link til WCAG 2.1 guiden , hvor du finder en uddybende beskrivelse af fejlen, hvordan den opstår, hvilken effekt den har og hvordan man kan løse problemet.