Webtilgængelighed

Webtilgængelighed

Metode

I det følgende kan du læse om vores metode for forenklede og dybdegående analyser, analyse af apps, værktøjer, samt opbygning af rapporten.

Strategi

Vi tror på, at forudsætningen for at forbedre tilgængeligheden på et website, kræver at webredaktører og andre ansvarlige opnår en god forståelse for, hvilke brud på tilgængelighedskravene der findes på sitet. Derfor gør vi meget ud af at rapporteringen skal være overskuelig og forståelig. Hertil kommer at testen skal udføres professionelt, grundigt og med god forståelse for tilgængelighedsprincipper.

Det er jo i det daglige, redaktionelle arbejde og i samarbejde med tekniske leverandører, at tilgængeligheden sikres. For bedst at kunne skabe tilgængeligt indhold, har vi sørget for at samle viden om hvordan indhold og tekniske rammer tilgængeliggøres, i vores WCAG 2.1 guide. Her gøres viden konkret og let forståelig for webmastere, webredaktører, designere og tekniske leverandører.

WCAG testmetode

Testmetode for WCAG 2.1 succeskriterier

Nedenfor kan du se en oversigt over de 50 succeskriterier der er indeholdt i WCAG 2.1. For hvert succeskriterie er det beskrevet hvilken metode vi bruger til at teste det. De markerede kriterier er dem der er indeholdt i den forenklede analyse. 

Der er desuden angivet en score for hver af de tre parametre; Alvorlighed, Impact og Automatisering, som beskrevet i afsnittet om den forenklede analyse. Det er denne score  der udgør grundlaget for hvilke succeskriterier, der er udvalgt til den forenklede monitorering.

 

Score (1-5)

       

Succeskriterie

Alvorlighed

Impact

Automatisering

Total

Sådan testes succeskriteriet

1.1.1 Ikke-tekstbaseret indhold

3

3

5

11

AXE test af alt-tekster

1.2.1 Rent lydindhold (audio only) og rent videoindhold (video only) (forudindspillet)

2

4

1

7

AXE test af alt-tekster samt manuel test af, om der forefindes et alternativt lydspor

1.2.2. Undertekster (forudindspillet)

2

3

1

6

Manuel test af, om der forefindes undertekster

1.2.3 Synstolkning eller mediealternativ (forudindspillet)

2

3

1

6

Manuel test af, om der forefindes synstolkningsspor

1.2.4 Undertekster (direkte)

2

3

1

6

Manuel test af, om der forefindes undertekster

1.2.5 Synstolkning (forudindspillet)

2

3

1

6

Manuel test af, om der forefindes synstolkningsspor eller tekstalternativ

1.3.1 Information og relationer

5

5

3

13

Styling slås fra i WAVE, og der tjekkes om siden kan læses

1.3.2 Meningsfuld rækkefølge

4

4

4

12

Headline order tjekkes i AXE

1.3.3 Sensoriske egenskaber

3

3

2

8

Manuel test af bl.a. tekst, som beskriver visuelle elementer og andre elementer som kræver sensoriske egenskaber

1.3.4 Retning

5

2

1

8

Manuel test af device retning i Google Chromes udviklerværktøj

1.3.5 Identificering af inputformål

3

4

3

10

Manuel test ved udfyldning af formularer, samt automatisk test i AXE ift. compliant HTML

1.4.1 Anvendelse af farve

3

3

1

7

Manuel kontrasttest vha. https://webaim.org/resources/contrastchecker/

1.4.2 Kontrol af lyd

4

2

1

7

Manuel test af lyd- og videoafspillere

1.4.3 Kontrast (minimum)

4

4

4

12

AXE test af kontrast

1.4.4 Ændring af tekststørrelse

4

3

3

10

Manuel test af reponsivitet på siden

1.4.5 Billeder af tekst

5

3

1

9

Manuel test af billeder

1.4.10 Ombrydningsvisning

4

3

1

8

Manuel test vha. mobildevice 

1.4.11 Kontrast for ikke-tekstbaseret indhold

4

3

4

11

Manuel test af billeder, infografikker mm.

1.4.12 Tekstafstand

3

3

1

7

Manuel test af tekstelementer (stikprøve af brødtekst, overskrifter, manchettekst mm.)

1.4.13 Indhold ved svævepegning(hover) eller fokus

3

3

1

7

Manuel test af hover- og popup-elementer

2.1.1 Tastatur

5

3

1

9

Manuel tastaturnavigation

2.1.2 Ingen tastaturfælder

5

3

1

9

Manuel tastaturnavigation

2.1.4 Genvejstaster

1

3

1

5

Manuel test og scanning af, om der findes genvejstaster. Derefter tastatur- og skærmlæsernavigation med genvejstasterne, hvis de findes.

2.2.1 Justerbar tastehastighed

4

3

1

8

Manuel test af, om der findes pauseknapper til indhold som afspiller automatisk

2.2.2 Pause, stop, skjul

4

4

1

9

Manuel test af, om der findes pause- eller stopknapper til indhold som afspiller automatisk

2.3.1 Grænseværdi på tre glimt eller derunder

3

3

2

8

Manuel test af, om der findes elementer som blinker i mere end tre gange på et sekund

2.4.1 Spring over blokke

2

3

3

8

Skærmlæser test af, om der findes skip-links og andre spring over blokke

2.4.2 Sider har titler

1

2

1

4

Manuel test af, om sider har titler

2.4.3 Fokusrækkefølge

3

3

2

8

Tab-navigationstest af fokusrækkefølgen og vurdering af, om den er logisk

2.4.4 Formål med links (i kontekst)

3

3

3

9

WAVE test af alt-tekst på links, manuel stikprøve af linktekster

2.4.5 Flere måder

3

4

1

8

Manuel test af navigations- og søgeelementer

2.4.6 Overskrifter og etiketter

3

3

1

7

Manuel stikprøvetest af overskrifter og etiketter.

2.4.7 Synligt fokus

3

3

1

7

Manuel tastaturnavigations test.

2.5.1 Pegebevægelser (Pointer Gestures)

5

1

1

7

Manuel test med pegeværktøj (trackball mus)

2.5.2 Pege-annullering

4

2

2

8

Manuel test med pegeværktøj (trackball mus) samt test af, om der findes annulleringsknapper

2.5.3 Etiket i navn

2

3

2

7

Skærmlæsertest af ligheden mellem tekst og HTML i knapper og etiketter.

2.5.4 Betjening via bevægelse

4

3

1

8

Manuel test af, om der findes alternativer til særlige, sensoriske bevægelser (hvis disse findes på sitet)

3.1.1 Sproget på siden

5

3

5

13

AXE test af “lang” attributten i HTML’en

3.1.2 Sprog, der anvendes til dele af indhold

3

3

1

7

Skærmlæsertest af artikler, hvor der optræder andre sprog end det primært angivne sprog i HTML’en

3.2.1 I fokus

3

4

1

8

Manuel test af elementer, der modtager fokus med tab-navigation

3.2.2 Ved input

3

3

2

8

Manuel test af formularer

3.2.3 Konsekvent navigation

4

5

2

11

Manuel test af navigationselementer

3.2.4 Konsekvent identifikation

3

3

2

8

Manuel test af ikoner, knaptekster mm.

3.3.1 Identifikation af fejl

3

5

1

9

Manuel test af formularer

3.3.2 Etiketter eller instruktioner

3

4

1

8

Manuel test af formularer

3.3.3 Fejlforslag

2

4

1

7

Manuel test af formularer

3.3.4 Forhindring af fejl (juridisk, økonomisk, data)

4

3

1

8

Manuel test af formularer

4.1.1 Parsing

5

5

5

15

Automatisk HTML parser test vha. https://validator.w3.org/

4.1.2 Navn, rolle, værdi

4

5

5

14

AXE test af HTML’en på sitet

4.1.3 Statusbeskeder

3

3

1

7

Manuel test af steder på sitet, som giver feedback i form af statusbeskede

Anvendte værktøjer til analyse

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:

  1. brug uden syn
  2. brug med nedsat syn
  3. brug uden farveopfattelse
  4. brug uden hørelse
  5. brug med nedsat hørelse
  6. brug uden taleevne
  7. brug med begrænset bevægelsesfrihed eller styrke
  8. behovet for at minimere udløsning af anfald som følge af lysfølsomhed
  9. 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:

  1. Forside
  2. Op til tre yderligere sideskabeloner
  3. Kontakside eller -formular (eller begge)
  4. Op til to selvbetjeningssider
  5. Tre sider som kvalitativt vurderes at have mest trafik
  6. 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:

  1. Sider til test udvælges og oplistes
  2. De udvalgte sider scannes med de automatiserede værktøjer. Hver af de fundne fejl vurderes og indsættes herefter i rapporten.
  3. 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.
  4. 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:

  1. Sider til test udvælges og oplistes
  2. De udvalgte sider gennemgås for dialogbokse, brugergrænsefladekontroller, fejlmeddelelser og anden systemfeedback fra interaktion med brugeren
  3. De udvalgte sider scannes med de automatiserede værktøjer. Hver af de fundne fejl vurderes og indsættes herefter i rapporten.
  4. 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.
  5. Siderne gennemgås med skærmlæser og evt. andre assisterende teknologier for at de vigtigste fejl er fundet
  6. Et udvalg af succeskriterierne efterprøves med variation af teknologi og præferencer
  7. 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:

  1. Indledning:
    Kort introduktion til rapporten og dens indhold
  2. 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.
  3. 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. 
  4. 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. 
  5. Gennemgang af fejl:
    Herefter følger listen over alle succeskriterierne, som websitet ikke lever op til. Ved hvert succeskriterie beskrives følgende: 
    1. Hvordan bryder sitet med kriteriet?
      Her beskrives det kort hvordan og hvor websitet fejler på succeskriteriet.
    2. Link til fejlen:
      Herunder indsættes et direkte link til en side på websitet hvor fejlen forekommer.
    3. HTML:
      For at sikre at en leverandør forstår specifikt hvor i HTML’en fejlen, findes indsættes en HTML snippet.
    4. Visuelt eksempel:
      Hvis det er muligt indsættes et visuelt eksempel fra websitet, hvori fejlen findes.
    5. 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.
    6. 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.
    7. 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.