WAI-Tools dokumentasjon av pilotkontroll

1. Innledning

Direktiv (EU) 2016/2102 har som mål å sikre at offentlige organers nettsteder og mobilapplikasjoner gjøres mer tilgjengelige, på grunnlag av felles tilgjengelighetskrav.

Medlemsstatene skal sikre at offentlige organer treffer nødvendige tiltak for å gjøre sine nettsteder og mobilapplikasjoner mer tilgjengelige ved å gjøre dem mulig å oppfatte, mulig å betjene, forståelige og robuste.

Innhold på nettsteder og i mobilapplikasjoner som oppfyller de relevante kravene i europeisk standard EN 301 549 V2.1.2 eller deler av disse, skal formodes å oppfylle tilgjengelighetskravene. I henhold til EN 301 549 tilsvarer samsvar med nettkravene samsvar med retningslinjene for tilgjengelig webinnhold (WCAG) 2.1 nivå AA. Offentlige organer bør avgi en tilgjengelighetserklæring om hvorvidt nettstedene og mobilapplikasjonene deres oppfyller tilgjengelighetskravene fastsatt ved direktivet.

Overholdelsen av tilgjengelighetskravene fastsatt i direktivet bør kontrolleres regelmessig. Medlemsstatene skal anvende

• en dybdekontrollmetode som grundig kontrollerer om et nettsted eller en mobilapplikasjon oppfyller alle kravene i standardene og de tekniske spesifikasjonene
• en forenklet kontrollmetode som påviser tilfeller av ikke-samsvar med et delsett av kravene i standardene og de tekniske spesifikasjonene

som vises til i artikkel 6 i direktiv (EU) 2016/2102.

WAI-Tools, Advanced Decision Support Tools for Scalable Web Accessibility Assessments, er et Innovation Action-prosjekt, samfinansiert av Europakommisjonen under Horizon 2020-programmet (Grant Agreement 780057). Prosjektet startet 1. november 2017 med en varighet på tre år.

Prosjektet er nært knyttet til europeisk og internasjonal innsats for standardisering av webtilgjengelighet, herunder retningslinjene for tilgjengelig webinnhold (WCAG) 2.1. Det er også svært relevant, tatt i betraktning kontrollmetoden som vises til i direktivet.

Prosjektpartnerne er

• European Research Consortium for Informatics and Mathematics (ERCIM), europeisk vert for World Wide Web Consortium (W3C) ​
• Siteimprove, Danmark​
• Stichting Accessibility (Stiftelsen Accessibility), Nederland​
• Agência para a Modernização Administrativa (Direktoratet for modernisering av forvaltningen), Portugal​
• Universidade de Lisboa (Universitetet i Lisboa), Portugal​
• Deque Research, Nederland​
• Digitaliseringsdirektoratet, Norge​

Noen av målene med prosjektet er å

• bygge et felles sett av ACT-regler fra W3C for å gi en tolkning for evalueringsverktøy og metoder basert på W3C-retningslinjene for tilgjengelig webinnhold (WCAG)​
• bidra til å øke automatiseringsnivået for evalueringen av webtilgjengelighet ved å definere testregler, og ny teknologi som i større grad blir tilgjengelig i dag

ACT-reglene, som formelt publiseres av W3C, sikrer kontroller med autoritativ legitimitet for suksesskriteriene i WCAG 2.1. Gjennom en gruppe bidragsytere er formålene, å redusere forskjellige tolkinger av WCAG, slik at testprosedyrene kan brukes om hverandre, og videre å utvikle et bibliotek med allment aksepterte regler. ACT-reglene fører også til utvikling av automatiske og semi-automatiske testverktøy, som kontrollorganer kan bruke til å gjennomføre kontrollen mer effektivt og hensiktsmessig.

I skrivende stund finnes det 5 slike ACT-regler som formelt er publisert av W3C, med mange flere under utvikling av WAI-Tools-prosjektet, som er innlemmet i godkjennings- og publiseringsprosessen. WAI-Tools-prosjektet tar sikte på å utvikle 70 testregler gjennom en åpen fellesskapsprosess og bidra dem til W3C prosessen for godkjenning og publikasjon. ACT-regler som utvikles av prosjektet er implementert i åpne kildekode-motorer som prosjektpartnerne Deque, FCID (Universidade de Lisboa) og Siteimprove har utviklet og vedlikeholder.

Som en del av WAI-Tools-arbeidspakke 2 i prosjektet har Digitaliseringsdirektoratet utført en pilotkontroll, basert på kravene til kontroll som vises til i direktivet. Piloten bygger på en analyse av kravene i direktivet og omfatter både den forenklede kontrollsprosessen og dybdekontrollprosessen.

For å gjennomføre pilotkontroll, har Digitaliseringsdirektoratet brukt ACT-regelimplementeringer utviklet av Deque, FCID og Siteimprove, som var tilgjengelig på tidspunktet, til å teste et begrenset antall nettsteder. Mobilapplikasjoner og nedlastbare dokumenter ble ikke testet i piloten.

Utfallet av dette arbeidet, kombinert med dokumentasjonen for ACT-reglene utviklet i WAI-Tools, utgjør en «demonstrator» fra Norge slik prosjektet krever. Piloten har gitt verdifull erfaring og dokumentasjon som skal brukes i videre forberedelser til kontroll.

Forberedelsene til piloten startet i september 2019, og piloten ble fullført i mars 2020. Prosjektpartnerne har bidratt til rapporten med verdifulle innspill. Deres kommentarer og endringer er inkludert i sluttrapporten.

2. Sammendrag

I dette kapittelet sammenfatter vi pilotkontrollarbeidet. Målet med piloten har vært å utforske og prøve ut alle trinnene i kontrollprosessen, basert på et utvalg av fire offentlige organer og deres nettsteder, innenfor pilotens tidsramme.

Fokus har ikke vært på å produsere testdata og andre data i den mengden som kreves for analyse og rapportering i samsvar med direktivet, men i stedet å høste erfaring og identifisere hvilke spørsmål som trenger å følges opp for å være forberedt til en faktisk kontroll.

Kontrollprosessen kan anses som en utvalgsundersøkelse som består av følgende trinn:

1. Planlegging og utforming
   • Hva er kravene i direktivet til kontroll og rapportering?
   • Hvilke problemer og forskningsspørsmål bør undersøkes?
   • Hvilke data trenger vi for å dekke forskningsspørsmålene og utføre rapportering?
   • Hvilke krav i standarden er relevante å inkludere i kontrollen?
2. Utvelging
   • Hvordan kan vi gjøre et utvalg av enheter, nettsteder og testsider?
3. Datainnsamling, herunder test
   • Hvilke erfaringer gjorde vi oss i piloten når det gjelder datakilder, metoder og verktøy for datainnsamling?
4. Analyse og rapportering
   • Hvilken erfaring gjorde vi oss i piloten i arbeidet med å fastsette et datasett som var egnet til analyse og rapportering?

I det følgende sammenfatter vi funnene og læringsmomentene fra hver fase eller hvert trinn i kontrollprosessen. Læringsmomentene presenteres også i slutten av de respektive kapitlene.

2.1 Trinn 1: Planlegging og utforming

Planlegging av kontrollen er avgjørende. Dette gjelder særlig for de første par gangene og for den første rapporteringen til EU. Vi må avgjøre hvilke problemer og spørsmål som bør undersøkes i kontrollen, på hvilken måte, basert på kravene til kontroll og rapportering i direktivet.

Derfor utførte vi en analyse av kravene til kontroll og rapportering i direktivet som beskrevet i kapittel 4.1. Basert på kravenes dokumentasjon har vi utledet utvalgets størrelse og sammensetning og dessuten hvilke data vi må samle inn gjennom kontrollprosessen for å utføre nødvendig analyse og rapportering, slik det er beskrevet i kapittel 4.2.

Gjennom planleggingsprosessen valgte vi også hvilke suksesskriterier som skulle inkluderes. I piloten ble dette begrenset av implementeringsstatus for verktøyene per februar 2020.

I en faktisk kontroll vil vi, i tillegg til det som implementeres i verktøy som velges til testing, også ta hensyn til erfaringer fra tidligere kontrollarbeid, og sannsynligvis også utføre semi-automatiske og manuelle tester for å dekke krav med høy risiko for ikke-samsvar. Dette gjelder særlig den forenklede kontrollen. For dybdekontrollen vil alle kravene bli inkludert.

Funn og læringsmomenter:

• Det er avgjørende å analysere direktivet for å identifisere krav til kontroll og rapportering.
• Før testen og annen datainnsamling startes, må vi definere så presist som mulig hvilke forskningsspørsmål som skal undersøkes, og deretter sikre at vi samler inn alle dataene som kreves for analyse og rapportering. Forskningsspørsmålene er angitt i kapittel 4.1.6.
• Kravene til kontroll og rapportering, og listen over forskningsspørsmål ligger til grunn for beslutninger om følgende:
  • utvalget av offentlige organer/enheter, nettløsninger, testobjekter/sider osv. Dette gjelder for utvalgets størrelse og sammensetning, og utvelgingsmetoden for enheter, nettløsninger og sider
  • kontrollmetodene, verktøyene og testmodusen (automatisk, semi-automatisk, manuell)
  • for forenklet kontroll: Hvilke suksesskriterier som skal inkluderes, særlig i og med at automatisk testing er foretrukket
  • databehov, metodene for datainnsamling og datakilder
  • hvilken analyse som må utføres for å rapportere i samsvar med direktivet
• I denne piloten gjaldt følgende:
  • Vi brukte 19 ACT-regler som dekket 13 WCAG 2.1-suksesskriterier. Etter vår mening er det avgjørende at dette arbeidet skrider fram til alle tilgjengelighetskravene i direktivet er dekket. Dette skyldes behovet for en dokumentert, gjennomsiktig og allment akseptert testmetode.
  • Vi oppfylte kravene til forenklet kontroll ved å dekke de 4 prinsippene i WCAG samt 7 av 9 av brukers tilgjengelighetsbehov
  • Ettersom vi brukte de samme ACT-reglene og suksesskriteriene i både den forenklede kontrollen og dybdekontrollen, dekket vi 29 % av suksesskriteriene som var påkrevd i henhold til direktivet (for dybdekontrollen).
  • Selv om vi hadde et litt begrenset omfang når det gjaldt antallet krav som ble inkludert, kom vi nær å oppfylle minstekravene til forenklet kontroll. Basert på funn i tidligere kontroller i Norge var det imidlertid flere suksesskriterier med høy risiko som ikke var omfattet av piloten.
  • Dette var fordi verken utviklingen av testregler eller implementeringen av testregler var fullført da pilottestingen ble utført. Høyrisikokriterier håndteres kontinuerlig i prosjektet.
  • Uavhengig av dette bør man være oppmerksom på at valg (og utelukkelse) av suksesskriterier i kontrollen kan innebære at det kan være betydelige tilgjengelighetsproblemer som ikke er avdekket i kontrollen. Dette gjelder særlig den forenklede kontrollen.
• I overskuelig framtid vurderer vi at det vil være et behov for å supplere automatiske tester med både semi-automatiske og manuelle tester for å dekke alle suksesskriteriene og kravene i standarden. Dette gjelder særlig for dybdekontrollen.

Særlig ved planlegging av den første kontrollen og rapporteringen gjelder følgende:

• Det er et stort behov for å samle inn og lagre data i både den forenklede kontrollen og dybdekontrollen, slik vi har beskrevet i kapittel 4.2. Dataene må samles inn fra diverse datakilder. Vi må fastsette en datamodell for å strukturere dataene, slik at det blir enklere å lagre og gjenfinne data på en effektiv måte. Denne datamodellen er til en viss grad bygget det åpne dataformat for tilgjengelighetstestresultater som ble utviklet av prosjektet, og implementert i verktøyene som en av utdataformatene.
• Vi planlegger å bruke tilgjengelighetserklæringene til å samle inn strukturerte data om de offentlige organene, nettløsningene, tjenesteområdet og individuelle tjenester per enhet. Senere vil vi vurdere å kombinere tilgjengelighetserklæringene med automatiske tester som enhetene kan utføre selv. Et av målene med WAI-Tools-prosjektet var å utvikle en prototype for en storskala datanettleser, som kan samle og analysere data fra tilgjengelighetserklæringene. Dette var imidlertid ikke tilgjengelig da piloten ble gjennomført, og kan muligens vurderes i fremtiden.
• Det bør imidlertid vurderes om kravene til kontroll og rapportering er for omfattende, særlig når det gjelder nødvendige data for å sammenstille utvalgene av enheter, nettløsninger og sider, i samsvar med direktivet (som beskrevet i kapittel 4.2.1–4.2.3). Dette gjelder særlig for antallet tjenester, prosesser, sider og dokumenter som skal testes i dybdekontrollen. Et begrenset utvalg av tjenester kan muligens være nok, i stedet for at alle kontrolleres.

Dessuten har vi identifisert en kort liste over kriterier som bør vurderes når et verktøy velges ut til faktisk kontroll:

• Dekning av WCAG standarden, dvs. verktøyet bør dekke så mange krav/suksesskriterier som mulig
• Verktøyet bør i den grad det er mulig ivareta behovene for gjennomsiktighet, reproduserbarhet og sammenlignbarhet, og
  • det må derfor være basert på en dokumentert tolkning av hvert av kravene i standarden
  • i størst mulig grad være basert på ACT-reglene, ettersom de oppfyller behovet for en dokumentert, gjennomsiktig og allment akseptert testmetode
  • testreglene (og hvordan de implementeres i verktøyene) må dokumenteres for å vise hvilken tolkning av kravene som dekkes av hver test
  • verktøyet bør inkludere eller kombineres med en «crawler» som er egnet til å velge ut de fleste av sidene og innholdet som bør inkluderes i en kontroll
  • testresultatene bør spesifisere utfall av testene, f.eks. samsvar, brudd, ikke forekomst (og ikke testbar)
  • det er å foretrekke at verktøyet gir testresultater både på element- og sidenivå, spesifisert etter suksesskriterier
  • antallet testede elementer og sider, særlig elementer og sider med brudd, bør telles og identifiseres, både per suksesskriterium og totalt
  • testresultatene bør være i et format som egner seg til analyse og rapportering i samsvar med direktivet, og gi nettstedseierne / de offentlige organene nødvendig informasjon i arbeidet med å forbedre nettstedene

2.2 Trinn 2: Utvelging

I dette kapittelet sammenfatter vi funnene og læringsmomentene fra utvelgingen av offentlige organer/enheter, nettsteder og sider.

Utvelging av offentlige organer/enheter:

• Vi vil dra nytte av å utvikle en effektiv metode for å etablere et representativt utvalg i samsvar med direktivet. Dette vil forhåpentlig bidra til at analysen av tilgjengelighetshindringer som kontrollen avdekker, er pålitelig og samfunnsmessig betydningsfull.
• Et representativt utvalg gjør at vi kan generalisere kontrollresultatene og fastsette en nasjonal indikator for graden av samsvar med tilgjengelighetskravene fastsatt i direktivet, en samlet tilgjengelighetsindikator for nettsteder. Dette kan også være egnet til referansemåling.
• For å velge et representativt utvalg trenger vi informasjon om utvalget av offentlige organer. For dette formålet kan Enhetsregisteret (eller lignende) brukes til å velge ut offentlige organer.
• Den institusjonelle sektorgrupperingen og næringsgrupperingen i registeret kan være nyttig for å bestemme forvaltningsnivået (statlig, regionalt, lokalt, offentligrettslig organ). Basert på en kombinasjon av institusjonell sektor- og næringsgruppering kan vi også få en kort indikasjon på tjenesteområdet.
• Det ligger stort potensial i mer automatisering, for eksempel ved å gjøre (i størst mulig grad) et tilfeldig utvalg fra Enhetsregisteret (eller lignende), basert på spesifikasjoner av kriteriene som vises til i direktivet.

Utvelging av nettsteder:

• Det finnes ikke noe register i Norge som er egnet til å gjøre et utvalg av nettsteder. Det totale antall nettsteder er dermed ukjent. For å lokalisere og gjøre et utvalg av nettsteder som passer 100 prosent med kriteriene i direktivet, må vi samle inn data som viser hvilke nettløsninger som tilhører hver valgt enhet.
• Noen enheter har mer enn ett nettsted. I disse tilfellene må vi bestemme hvilket nettsted som skal inkluderes i kontrollen. På den andre siden deler noen enheter nettløsninger med andre, og i slike tilfeller må vi identifisere hvem som er ansvarlig. I piloten måtte vi kombinere informasjon fra registeret med nettsøk etter offentlige organers nettsteder. Dette er tidkrevende.
• En kombinasjon av data fra Enhetsregisteret og datainnmating fra enhetene gjennom tilgjengelighetserklæringene kan være en effektiv metode. Vi kan bruke erklæringene til å samle inn strukturerte data om forvaltningsnivå, tjenesteområde, hvilke nettsteder (og mobilapplikasjoner) som er relevante for kontroll osv.
• Likevel er det viktige spørsmål om utvelgingskravene som ikke er spesifisert i direktivet, f.eks.:
  • om utvelging for forenklet kontroll og dybdekontroll må skje i separate operasjoner
  • om målet med utvelging for henholdsvis forenklet kontroll og dybdekontroll skal være et variert, representativt og geografisk balansert utvalg
  • om dybdekontrollen kan være basert på en utvelging av nettstedene i den forenklede kontrollen

Det ville være svært nyttig dersom dette kunne presiseres.

Utvelging av sider (og dokumenter) – dybdekontroll:

• Det bør vurderes om kravene til utvalget av testsider er for omfattende. Utvelging av nettsider er en kompleks og tidkrevende oppgave som krever manuell innsats. Det kan vurderes om det bør innledes en dialog med nettstedseierne for utvelging av sider og dokumenter. Imidlertid må vi vurdere om dette er kostnadseffektivt.
• Begrepene «type of service» og «process» bør defineres, slik at vilkårlig metode unngås når tjenester og prosesser skal identifiseres. I en faktisk kontroll gjelder dette også for nedlastbare dokumenter, ettersom det i direktivet kreves testing av minst ett relevant nedlastbart dokument, dersom det er aktuelt, for hver type tjeneste som leveres via nettstedet.
• Dersom de utvalgte sidene i dybdekontrollen er del av en prosess, kreves det i direktivet at alle trinn i prosessen kontrolleres. Etter vår erfaring kan prosesser kreve pålogging med et nasjonalt ID-nummer. Det er derfor avgjørende at vi fastsetter en metode til å få innloggingstilgang til disse prosessene/nettsidene.

Utvelging av sider (og dokumenter) – forenklet kontroll:

• Vi trenger en skala eller kriterier for å vurdere hva som vil være et egnet antall testsider, basert på anslått størrelse, og kompleksitet, for nettstedet som skal kontrolleres.
• For forenklet kontroll trenger vi tilgang til en «crawler» for å velge ut nettsider. «Crawler» i de forskjellige verktøyene kan imidlertid bruke forskjellige metoder til å gjennomsøke nettstedene. Man bør derfor være oppmerksom på at dette kan gjøre at verktøyene velger ut forskjellige sider på samme nettsted.
• Gjennomsøkning er også egnet til å anslå størrelsen på et nettsted. Men etter vår erfaring fant (og talte) ikke «crawler» skjulte sider, underdomener eller sider som krever innlogging.
• I mangel på adekvate alternativer vurderer vi fortsatt at bruk av en «crawler» for å velge ut nettsider (og anslå størrelsen), er den mest effektive metoden.

Utvelging av sider (og dokumenter) – både dybdekontroll og forenklet kontroll:

• Vi trenger en metode for å utelukke sider som har tredjepartsinnhold og annet innhold som ikke er omfattet av direktivet.
• Vi må se på om det er mulig å teste nettsider som krever pålogging, ved hjelp av automatiske verktøy. Dette gjelder primært for dybdekontroll, men det er ønskelig å kunne omfatte denne typen innhold i en forenklet kontroll også.

2.3 Trinn 3: Datainnsamling

Dette trinnet dekker både produksjonen av testdata og andre data som er nødvendige for kontroll og rapportering. De viktigste funnene og læringsmomentene er listet opp.

Data om enhetene:

• Vi klarte å samle inn dataene om de offentlige organene slik det er angitt i kapittel 4.2.1. De fleste data kan lastes ned fra Enhetsregisteret (eller lignende).
• Kombinasjonen av institusjonell sektor- og næringsgruppering kan muligens være nok til å bestemme «type of service» som enheten tilbyr (gjennom nettstedet sitt), særlig for den forenklede kontrollen. For dybdekontrollen vil dette muligens være utilstrekkelig.
• I mange tilfeller vil vi måtte gjennomføre en mer omfattende kontroll av det faktiske innholdet på enhetens nettsted. Dette kan være svært tidkrevende, og kvaliteten på dataene kan være utilstrekkelig. Det bør vurderes å bruke tilgjengelighetserklæringene som datakilde for dette formålet. Dette kan være atskillig mer kostnadseffektivt enn manuelle tilsyn. Et av målene med WAI-Tools-prosjektet er å utvikle en prototype for storskala datanettleser, som ville ha kunnet samlet og analysert data fra tilgjengelighetserklæringene. Dette kan vurderes for fremtidig utforskning. Dette var imidlertid ikke tilgjengelig da piloten ble gjennomført, og kan muligens vurderes i fremtiden.

Data om nettstedene:

• I piloten kombinerte vi data fra Enhetsregisteret med søk på internett for å finne de utvalgte offentlige organenes nettadresser. Det bør vurderes å gjøre det obligatorisk å rapportere nettløsningsadressene til registeret, og/eller ordne tilgjengelighetserklæringene slik at disse dataene kan rapporteres direkte til kontrollorganet.
• I noen tilfeller kan data om tjenesteområde registreres på enhetsnivå. I andre tilfeller der enheten tilbyr et bredt utvalg av tjenester og dessuten har forskjellige nettsteder for forskjellige typer tjenester, må tjenesteområdet defineres på nettløsningsnivå. Dette gjelder for eksempel for Digitaliseringsdirektoratet.
• Noen enheter/nettsteder tilbyr et bredt utvalg av tjenester. I piloten valgte vi bare ut noen tjenester fra nettstedet som vi dybdekontrollerte. I en faktisk kontroll vil vi trenge en oversikt over alle tjenestene som tilbys av en enhet / via et nettsted, ettersom det i direktivet kreves kontroll av minst én relevant side for hver type tjeneste som leveres av nettstedet. Vi må derfor samle inn omfattende informasjon om de forskjellige tjenestene som enheten/nettstedet tilbyr. Det bør derfor gjennomgås i hvilket omfang dette er kostnadseffektivt, og om det i stedet bør være mulig å kontrollere et utvalg av tjenester i stedet for å inkludere alle.
• Å identifisere tjenestene som tilbys på et nettsted, er utfordrende. Som tommelfingerregel vil kommunale nettsteder i de fleste tilfeller ha et mer standardisert (lovfestet) sett av tjenestetilbud. Dette vil også være tilfelle for mange av de regionale nettstedene. For de statlige nettstedene og nettstedene som tilhører offentligrettslige organer, er det sannsynligvis brede variasjoner, både i omfang, kompleksitet og tjenestetilbud. Man bør vurdere å bruke tilgjengelighetserklæringene til å samle inn denne slags informasjon, muligens supplert av dialog med de offentlige organene dersom mer informasjon er nødvendig.

Data om sider:

• For den forenklede kontrollen er det bare startsiden som må identifiseres (og dokumenteres). For dybdekontrollen er det et behov for mer data om sidene enn i den forenklede kontrollen.
• Vi klarte å identifisere og registrere data om nettsidene som er nødvendige for dybdekontrollen, forutsatt at de fantes på nettstedet.
• For å vurdere om en side er del av en prosess, og for å kontrollere at vi valgte ut sidene angitt i gjennomføringsbeslutningen, måtte vi inspisere nettstedet manuelt. Det var den eneste måten vi klarte å samle inn dataene om nettsidene på, slik det er angitt i kapittel 4.2.3.
• Prosessen var tidkrevende og avhengig av deltakelse fra nettstedseieren. I en faktisk kontroll kan det vurderes om det er for omfattende å ha dialoger med nettstedseierne for å samle inn data om de utvalgte nettsidene. Det kan derfor være nyttig å gjennomgå om det er nødvendig å velge ut (og dokumentere) testsidene som beskrevet i gjennomføringsbeslutningen.
• Uansett trenger vi informasjon/data som knytter sidene til tjenester og prosesser. Begrepene «type of service» og «process» bør derfor defineres.

Data om kravet:

• Innsamling av data om kravene ble utført ved hjelp av EN-standarden.
• Informasjon om hvilke av brukers tilgjengelighetsbehov som tilsvarer hvert krav/suksesskriterium, finnes nærmere bestemt i standarden EN 301 549, vedlegg B.1. Disse dataene hjelper oss med å analysere hvilke digitale hindringer brukere med forskjellige tilgjengelighetsbehov møter på internett.

Data om testresultatene:

• Ved hjelp av de tre verktøyene fra prosjektpartnerne klarte vi å samle inn testresultater på sidenivå per suksesskriterium for dybdekontrollen, og individuelle testresultater per suksesskriterium, for både den dybde og den forenklede kontrollen.
• Vi brukte to av de tre verktøyene i den forenklede kontrollen. Vi klarte ikke å samle inn testresultater på sidenivå, ettersom vi ikke klarte å fastsette en modell for å konvertere testresultater fra testregelnivået til suksesskriterienivået. Metoden som brukes til dette formålet i dybdekontrollen, var ikke gjennomførbar for den forenklede kontrollen på grunn av det enorme antallet sider som ble testet (inntil 1 000 sider per nettsted).
• Alle de tre verktøyene rapporterte testresultater i kategorien «brudd», mens et av de tre også rapporterte resultater i kategoriene «samsvar» og «ikke forekomst». Etter vår mening er det foretrukket å ha data om testresultatene som dekker alle de tre kategoriene «samsvar», «brudd» og «ikke forekomst».
• For to av verktøyene var det også vanskelig å kontrollere om en nettside var blitt testet.
• Det var utfordrende å få tak i antallet unike sider med brudd per suksesskriterium ved hjelp av verktøyene slik de var under pilotens gjennomføring. I en faktisk kontroll må vi trekke ut testresultater på suksesskriterienivå. En løsning kunne være å ordne eksportfunksjonene fra verktøyene, slik at vi direkte kunne gjenfinne resultater for unike sider per suksesskriterium.
• Vi la ned en betydelig manuell innsats for å trekke ut og presentere dataene. Vi slet også med å eksportere testdata fra verktøyene i et annet format, som var egnet for distribusjon til nettstedseierne.
• Hvis vi hadde hatt muligheten til å utforske disse problemene ytterligere i den tidsrammen vi hadde for piloten, er det mulig at verktøyleverandørene kunne ha hjulpet oss med å produsere og konvertere testresultatene mer effektivt. Denne datamodellen er til en viss grad bygget på et åpent dataformat for tilgjengelighetstestresultater som ble utviklet av prosjektet og implementert i verktøyene som en av utdataformatene.

Data om testresultatene – tilleggskommentarer:

• Dokumentasjon av testmetoder, verktøy (og versjon), er vesentlig for å sikre gjennomsiktighet, reproduserbarhet og sammenlignbarhet. Generelt er det avgjørende å undersøke dokumentasjonen av verktøyene for å ha kontroll over hva som testes, og hvordan testene utføres.
• På grunn av at piloten ble gjennomført under aktiv prosjektutvikling, var det utfordrende å avgjøre hvilken versjon av en ACT-regel som var implementert i hvert av de tre verktøyene, ettersom bare informasjon om når hver ACT-regel sist ble oppdatert er tilgjengelig på nettstedet med ACT-reglene. Nettstedet med ACT-reglene inneholder også en oversikt over de forskjellige implementeringene av ACT-reglene, men det er ikke spesifisert hvilken versjon eller når de forskjellige ACT-reglene ble implementert i verktøyene. Vi forventer at denne situasjonen muligens forbedres når ACT-reglene blir formelt publisert av W3C, og implementasjoner av disse stabiliseres.

Data om kontrollen og rapporteringen:

• Data om kontrollen og rapporteringen kan enkelt samles inn fra planleggingen og dokumentasjonen av kontrollen. Disse dataene er blant annet informasjon om kontrollperioden, organet med ansvar for kontrollen osv. En fullstendig liste vises i tabellen i kapittel 6.6.

2.4 Trinn 4: Analyse og rapportering

Det inngikk ikke i piloten å produsere testdata i nødvendig mengde for å utføre analyse og rapportering slik direktivet beskriver. Sammendraget presenterer derfor våre erfaringer med å fastsette et datasett som var egnet til analyse og rapportering. Vi vil også legge fram våre tanker og refleksjoner om beregningen av samsvarsnivå og andre spørsmål som etter vår mening trenger å presiseres.

Funnene er sammenfattet nedenfor:

• Når det gjelder spørsmålene om
  • utvalg av enheter og nettsteder
  • utvelgingsmetode
  • suksesskriterier og testmetoder
  • brukers tilgjengelighetsbehov
  • vurderes dataene som samles inn i piloten, som tilstrekkelig og egnet til å utføre analysen som kreves for rapportering.
• Sammen med testresultatene er dataene om kontrollen avgjørende for å svare på forskningsspørsmålene.

Videre refleksjoner om analyse og rapportering:

• Vi trenger en dokumentert metode til å velge ut enheter og nettsteder og i størst mulig grad en oversikt over utvalget av enheter og nettsteder. Dette er for å danne et grunnlag for å vurdere i hvilket omfang kontrollen av resultater kan generaliseres. Vi trenger også en konsekvent måte å velge ut testsider på. Dette er avgjørende både for å sammenligne resultater mellom nettsteder, kategoriene av offentlige organer og resultater fra forskjellige kontrollperioder.
• Basert på kravene til rapportering trenger kontrollorganene en metode og en skala for å uttrykke kvantifiserte resultater av kontrollaktiviteten, herunder kvantitativ informasjon om tilgjengelighetsnivået.
• De kvantifiserte testresultatene etter suksesskriterium og tilordningen til brukerens tilgjengelighetsbehov danner grunnlaget for en kvalitativ analyse av resultatet av kontrollen, særlig funnene når det gjelder hyppig eller kritisk ikke-samsvar. Vi trenger derfor en metode for å utføre den kvalitative analysen som beskrevet i direktivet og en mal for å rapportere til EU.
• Det er også et behov for en presisering av begrepet «samsvarsnivå» (eller samsvarsstatus). Kontrollorganene trenger en (enkel) metode og en skala for å uttrykke kvantifiserte resultater av kontrollaktiviteten, herunder kvantitativ informasjon om tilgjengelighetsnivået.
• I henhold til standarden er grunnlaget for å beregne samsvarsnivået testresultater på sidenivå. Vi trenger derfor en måte å trekke ut aggregerte testdata direkte fra verktøyene på som viser både antallet testede sider og antallet unike sider med brudd for hvert suksesskriterium. Dette gjelder både den forenklede kontrollen og dybdekontrollen.
• På grunnlag av standarden kan vi beregne samsvarsnivået som prosentandelen av de testede sidene som samsvarer fullt ut med alle de inkluderte suksesskriteriene, angitt etter dybde og forenklet kontroll.
• Vi stiller også spørsmål ved om det er mulig å beregne samsvarsnivået på elementnivå. Et eksempel:
  • telle antall testede elementer per identifisert suksesskriterium, spesifisert etter resultatet av hvert testet element (samsvar, brudd, ikke forekomst og muligens, ikke testbar)
  • beregne samsvarsnivået som prosentandel testede elementer som oppfyller kravene. Dette kan også legge til rette for referansemåling og måling av trender i samsvarsnivå
• Hver av de ovenfor skisserte tilnærmingene har ulike fordeler og ulemper, som å ikke ta høyde for alvorlighetsgrad i feil. For eksempel, dersom bare 1 av 99 bilder på en side mangler tekstalternativ, og likevel vil det ene bildet føre til at hele siden oppfattes som ikke brukbar. W3Cs forskningsrapport om tilgjengelighetsberegninger på nett, utforsker ulike tilnærminger for å måle nivået av tilgjengelighet.
• Basert på samsvarsnivået på nettstedsnivå kan gjennomsnitt eller aggregert samsvarsstatus for alle nettstedene i hver kontroll beregnes, spesifisert etter dybdekontroll og forenklet kontroll.
• Lignende beregninger bør også utføres
  • etter kategori (forvaltningsnivå) av offentlige organer
  • etter suksesskriterium
• Ettersom det er flere måter å beregne samsvarstatusen på, er det et behov for en presisering av begrepet «samsvar» og hvordan det bør måles.
• Det er også et behov for å rapportere testresultater som identifiserer hvilke elementer på de testede sidene som ikke er i samsvar. Dette er for at nettstedseierne skal få støtte i arbeidet med å rette opp elementer med brudd.

3. Målene med piloten

Medlemsstatene skal kontrollere om offentlige organers nettsteder og mobilapplikasjoner er i samsvar med tilgjengelighetskravene fastsatt i artikkel 4 i direktivet, på grunnlag av metoden fastsatt i Kommisjonens gjennomføringsbeslutning. Dette er igjen på grunnlag av kravene i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktivet.

Direktivet omfatter krav når det gjelder

• utvelging av nettsteder og mobilapplikasjoner som skal kontrolleres
• hvilke typer nettsider og dokumenter som skal kontrolleres i dybdekontrollen
• framlegg og rapportering av kontrollresultatene
• framlegg av resultatene til de offentlige organene som har ansvar for de løsningene som er kontrollert

Målet med piloten er å høste erfaring med hele kontrollprosessen som beskrevet i direktivet og gjennomføringsbeslutningen. Målet er ikke å løse alle problemene som påvises i de forskjellige trinnene av pilotkontrollen, men i stedet å identifisere og påpeke hva som trenger oppfølging for å være forberedt på kontrollen.

Kontrollprosessen kan anses som en utvalgsundersøkelse som består av følgende trinn:

Figur 1: Oversikt over kontrollprosessen. Oversikt over kontrollprosessen med trinn planlegging og utforming, utvelging, datainnsamling, analyse og rapportering.

Basert på en slik forståelse av kontrollprosessen har vi definert følgende spørsmål som skal undersøkes i piloten:

1. Hva er kravene i direktivet til den forenklede kontrollen, dybdekontrollen og rapporteringen?
2. Hvilke spørsmål og forskningsspørsmål bør undersøkes i en kontroll generelt?
3. Hvilke data trenger vi for å dekke forskningsspørsmålene og rapportere i samsvar med direktivet?
4. Hvilke krav i standarden er relevante å inkludere i kontrollen, basert på antakelsen om at testing skal utføres ved hjelp av automatiske testmetoder/verktøy?
5. Hvordan kan vi gjøre et utvalg av enheter, nettsteder og testsider?
6. Hvilke erfaringer gjorde vi oss i piloten når det gjelder datakilder, metoder og verktøy for datainnsamling?
7. Hvilken erfaring gjorde vi oss i piloten i arbeidet med å fastsette et datasett som var egnet til analyse og rapportering?

Funnene er sammenfattet i læringsmomenter for videre oppfølging i våre forberedelser til kontroll i samsvar med direktivet.

Piloten var primært fokusert på å høste erfaring med trinnene i kontrollprosessen, jf. figur 1. Derfor la vi liten vekt på å legge fram data i et omfang som vil være nødvendig for å utføre en statistisk analyse.

I de neste kapitlene utdypes trinnene i kontrollprosessen. Vi sammenfatter deretter hovedfunnene og læringsmomentene fra piloten for hvert trinn i kontrollprosessen.

4. Trinn 1: Pilotkontrollens planlegging og utforming

Planlegging av kontrollen er avgjørende. Dette gjelder særlig for de første par gangene og for den første rapporteringen til EU. I planleggingsprosessen treffer vi beslutning om følgende:

• Hvilke problemer og spørsmål som bør undersøkes i kontrollen. Dette er i høy grad bestemt av kravene til kontroll og rapportering i direktivet. Dette er videre bestemt av hvilke krav/suksesskriterier vi inkluderer i kontrollen.
• Størrelsen og sammensetningen av utvalget av enheter og nettløsninger i kontrollen. Dette følger også av direktivet.
• Hvilke data vi trenger for å svare på spørsmålene som ligger til grunn for kontrollen. Dette vil bli undersøkt basert på punktene ovenfor.
• Hvilke datakilder, metoder og verktøy som er de mest egnede til å samle inn data.
• Hvilken analyse som må utføres for å rapportere i samsvar med kravene i direktivet.

4.1 Krav til kontroll og rapportering i direktivet

Medlemsstatene skal kontrollere om offentlige organers nettsteder og mobilapplikasjoner er i samsvar med tilgjengelighetskravene fastsatt i artikkel 4 i direktivet, på grunnlag av metoden fastsatt i Kommisjonens gjennomføringsbeslutning, på grunnlag av kravene i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktivet.

4.1.1 Kontrollmetoder

Medlemsstatene skal kontrollere samsvaret for offentlige organers nettsteder og mobilapplikasjoner ved hjelp av:

1. en dybdekontrollmetode for å verifisere samsvar
2. en forenklet kontrollmetode for å påvise ikke-samsvar

Dybdekontrollen skal

• grundig kontrollere om et nettsted eller en mobilapplikasjon oppfyller alle kravene angitt i standardene og de tekniske spesifikasjonene i artikkel 6 i direktiv (EU) 2016/2102
• kontrollere alle trinn i prosessene i utvalget, minst i henhold til standardrekkefølgen for fullføring av prosessen
• minst vurdere interaksjonen med skjemaer, grensesnittkontroller og dialogbokser, bekreftelser av dataregistrering, feilmeldinger og andre tilbakemeldinger fra interaksjon med brukeren når det er mulig, samt nettstedets eller mobilapplikasjonens virkemåte når det brukes ulike innstillinger eller preferanser.

Den forenklede kontrollmetoden skal

• påvise tilfeller av ikke-samsvar med et delsett av krav i standardene og de tekniske spesifikasjonene i direktivet
• omfatte tester tilknyttet hvert av kravene: mulig å oppfatte, mulig å betjene, forståelig og robust

Den forenklede kontrollmetoden skal

• undersøke nettstedene for ikke-samsvar
• sikte mot å omfatte ved bruk av automatiske tester, så langt som rimelig mulig, følgende av brukers tilgjengelighetsbehov:
  1. Bruk uten syn
  2. Bruk med nedsatt syn
  3. Bruk uten fargesyn
  4. Bruk uten hørsel
  5. Bruk med nedsatt hørsel
  6. Bruk uten taleevne
  7. Bruk med begrenset motorisk funksjonsevne eller styrke
  8. behov for å minimere faktorer som kan utløse anfall på grunn av lysfølsomhet
  9. Bruk med kognitiv funksjonsnedsettelse

4.1.2 Samsvar og ikke-samsvar

I den forenklede kontrollen skal vi påvise tilfeller av ikke-samsvar, mens vi i dybdekontrollen skal verifisere samsvar. For definisjoner av samsvar og ikke-samsvar henviser direktivet til EN 301 549-standarden.

Standarden angir følgende:

For hvert suksesskriterium skjer derfor kontrollen for samsvar eller ikke-samsvar på sidenivå. For at en nettløsning skal oppfylle kravene i direktivet, må alle testede sider samsvare.

Samsvarsbestemmelse er definert på følgende måte:

For hvert av kravene er forutsetningene og testene angitt slik tabellen nedenfor viser for alle relevante suksesskriterier, når det gjelder sider.

Eksempel: 1.1.1 Ikke-tekstlig innhold

Dette tilsier at samsvarsstatus for en nettløsning er basert på kombinasjoner av resultater/kategorier av testresultater. Samsvar er når en side har fått «passed» (dvs. «samsvar») alle testresultatene, når det er fravær av testresultater i kategorien «failed» (dvs. «ikke-samsvar») og/eller testresultater er i kategorien «inapplicable» (dvs. «ikke forekomst») (f.eks. typen innhold som kontrolleres i en test finnes ikke på den faktiske testsiden).

Det kan bli utfordrende å beregne samsvarstatusen for et nettsted basert på definisjonen av begrepet «samsvar» som beskrevet i standarden. Etter vår erfaring fra tidligere kontrollarbeid vil antallet elementer med brudd på en side, knyttet til hvert av suksesskriteriene der det påvises ikke-samsvar, gi oss et mer nyansert bilde av samsvarsstatus. Dersom vi i tillegg får informasjon om hvor mange elementer som er testet for hvert suksesskriterium, og resultatet for hvert testet element, ville vi kunne beregne samsvarsnivået på en enkel måte. Dette kan også legge til rette for referansemåling og måling av trender i samsvarsnivå.

4.1.3 Utvelging av offentlige organer og nettløsninger

Antallet nettsteder og mobilapplikasjoner som skal kontrolleres i hver kontrollperiode, skal beregnes på grunnlag av størrelsen på medlemsstatens befolkning. Utvelgingen av nettsteder skal ha som mål en variert, representativ og geografisk balansert fordeling. Ved utvelging av mobilapplikasjoner skal målet være et variert og representativt utvalg.

Merknad: I det følgende fokuserer vi på utvelging og kontroll av nettsteder, ettersom nettsteder er tema for piloten.

Utvalget skal omfatte nettsteder fra følgende forvaltningsnivåer:

1. statlige nettsteder
2. regionale nettsteder (NUTS1, NUTS2, NUTS3)
3. lokale nettsteder (LAU1, LAU2)
4. offentligrettslige organers nettsteder som ikke omfattes av kategori a)–c)

Utvalget skal omfatte nettsteder som i størst mulig grad representerer det spekteret av tjenester som ytes av offentlige organer, særlig sosialomsorg, helse, transport, utdanning, sysselsetting og beskatning, miljøvern, fritid og kultur, bolig og nærmiljø samt offentlig orden og sikkerhet.

Medlemsstatene skal rådføre seg med nasjonale berørte parter, særlig organisasjoner som representerer personer med nedsatt funksjonsevne, om sammensetningen av utvalget av nettsteder som skal kontrolleres, og ta behørig hensyn til de berørte partenes synspunkter når det gjelder spesifikke nettsteder som skal kontrolleres.

Merknad: Nasjonale berørte parter ble ikke konsultert i piloten.

4.1.4 Utvelging av sider

Kravene til kontrollen av nettsider er angitt for hver kontrollmetode. Ved bruk av dybdekontrollmetoden skal følgende sider og dokumenter kontrolleres, dersom de finnes:

1. startsiden, innloggingssiden, nettstedkart, siden med kontaktopplysninger, hjelpesiden og siden med juridisk informasjon
2. minst en relevant side for hver «type of service» som leveres via nettstedet eller mobilapplikasjonen, og enhver annen primær tiltenkt bruk, herunder søkefunksjonen
3. sidene som inneholder tilgjengelighetserklæringen eller -retningslinjer for tilgjengelighet, og sidene som inneholder tilbakemeldingsfunksjonen
4. eksempler på sider som har et vesentlig forskjellig utseende, eller som viser en annen type innhold
5. minst ett relevant nedlastbart dokument, dersom det er relevant, for hver «type of service» som leveres via nettstedet eller mobilapplikasjonen, og for enhver annen primær tiltenkt bruk
6. enhver annen side som kontrollorganet anser som relevant
7. tilfeldig utvalgte sider som utgjør minst 10 % av de sidene som er valgt ut i samsvar med bokstav a) til f)

Kravene til forenklet kontroll er mindre spesifikke, idet de sier at et antall sider som er tilpasset nettstedets anslåtte størrelse og kompleksitet, skal kontrolleres i tillegg til startsiden.

4.1.5 Rapportering

Medlemsstater skal legge fram en rapport for Kommisjonen. Rapporten skal inneholde de resultatene av kontrollen som gjelder kravene i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktivet.

Den nevnte rapporten skal inneholde:

1. en utførlig beskrivelse av hvordan kontrollen ble gjennomført
2. en kartlegging, i form av en sammenligningstabell, som viser hvordan de benyttede kontrollmetodene knytter seg til kravene i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktivet, herunder også vesentlige endringer i metodene
3. resultatene av kontrollen for hver kontrollperiode, herunder måledata
4. den informasjonen som kreves i henhold til artikkel 8 nr. 5 i direktiv (EU) 2016/2102

Merknad: Punkt d i ovenstående liste har ikke vært en del av denne piloten.

Medlemsstatene skal i sine rapporter gi den informasjonen som er angitt i instruksjonene i gjennomføringsbeslutningen:

• Rapporten skal redegjøre i detalj for resultatene av kontrollen som er utført av medlemsstaten.
• For hver kontrollmetode som er brukt (dybde eller forenklet, for nettsteder og mobilapplikasjoner), skal rapporten inneholde følgende:
  1. en fullstendig beskrivelse av resultatene av kontrollen, herunder måledata
  2. en kvalitativ analyse av resultatene av kontrollen, herunder:
     • resultatene med hensyn til gjentakende eller kritiske tilfeller av ikke-samsvar med kravene fastsatt i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktiv (EU) 2016/2102
     • om mulig, utviklingen i de kontrollerte nettstedenes og mobilapplikasjonenes samlede tilgjengelighet mellom to kontrollperioder.

«Måledata» er følgende:

• De kvantifiserte resultatene av kontrollen som utføres for å verifisere at offentlige organers nettsteder og mobilapplikasjoner oppfyller tilgjengelighetskravene fastsatt i artikkel 4.
• De dekker både
  1. kvantitative opplysninger om utvalget av nettsteder og mobilapplikasjoner som er testet (antall nettsteder og applikasjoner, eventuelt med antall besøkende eller brukere osv.) og
  2. kvantitativ informasjon om tilgjengelighetsnivået

I Kommisjonens gjennomføringsbeslutning fastsettes også valgfritt innhold for rapporteringen.

4.1.6 Forskningsspørsmål

Basert på analysen av direktivet har vi identifisert et sett forskningsspørsmål for videre undersøkelse i kontrollen (av nettsteder) som skal gjennomføres og rapporteres innen 23. desember 2021. Spørsmålene er angitt nedenfor.

Spørsmål som skal besvares om kontrollen

1. Hvilken størrelse og sammensetning av utvalget av nettløsninger (og mobilapplikasjoner) bør inkluderes både i den forenklede kontrollen og dybdekontrollen?
2. Hvordan velges nettløsningene – og nærmere bestemt – hvilke løsninger velges i dialog med berørte parter? Til senere kontroll. Hvilke nettløsninger har vært inkludert ved tidligere kontroller?
3. Hvilke suksesskriterier er omfattet av kontrollen, og hvordan tilsvarer de prinsippene (mulig å oppfatte, mulig å betjene, forståelig og robust) og brukers tilgjengelighetsbehov i direktivet? Dette gjelder for den forenklede kontrollen.
4. Hvordan identifiserer metoder, tester og verktøy ikke-samsvar (forenklet kontroll) og verifiserer samsvar (dybdekontroll) med kravene i direktivet?

Spørsmål som skal besvares om resultatene

1. Hvordan er generell samsvarsstatus med tilgjengelighetskravene i direktivet?
   1. Hvordan er samsvarsnivået for nettstedene i hver kategori av offentlige organer (statlige, regionale, lokale og andre offentligrettslige organer)?
   2. Til senere kontroll: Hvordan er utviklingen over tid når det gjelder generelt samsvar med kravene i direktivet?
2. Hvordan er generell samsvarsstatus med hvert tilgjengelighetskrav (suksesskriterium)?
   1. Vær særlig oppmerksom på suksesskriteriene der ikke-samsvar er påvist, og i hvilket omfang ikke-samsvar forekommer.
   2. Vær særlig oppmerksom på hvilke av brukers tilgjengelighetsbehov som er knyttet til suksesskriterier med (hyppig) ikke-samsvar.
3. Hvordan er samsvarsstatus for hver av de enkelte nettløsningene som kontrolleres?
   1. Antallet testsider med ikke-samsvar bør rapporteres.
   2. Resultatene bør også spesifiseres per krav/suksesskriterium, per testside der ikke-samsvar påvises.

Merknad: Alle resultatene skal spesifiseres for hver kontrollmetode, både forenklet og dybde.

I direktivet nevnes også tjenesteområde, ikke som et absolutt kriterium for utvelging, men for å dekke viktige tjenester rettet mot mange brukere. Vår tolkning er at det ikke er meningen at prøven skal være representativ for tjenesteområdet. Vi bør imidlertid tenke på at det skal være mulig å spesifisere resultatene for hvert område, selv om de sannsynligvis ikke er sammenlignbare.

Resultatene bør også identifisere hvilke elementer på de testede sidene som ikke er i samsvar. Det er for at nettstedseierne skal få støtte i arbeidet med å rette opp elementer med brudd.

4.2 Datakrav til rapportering

Direktivet har detaljerte krav til utvelging og rapportering. Direktivet danner dermed grunnlag for hvilke data vi vurderer som nødvendige å samle inn. I det følgende legger vi fram hvilke data som må samles inn om

• offentlige organer
• nettløsninger
• testsider (og nedlastbare dokumenter)
• suksesskriterium/krav, herunder brukers tilgjengelighetsbehov
• testresultater på sidenivå (og elementnivå)
• ordninger for kontroll og rapportering

De ulike kategoriene av data er sammenfattet i tabellene nedenfor.

Merknad: Dette er bare en oversikt. Tabellene beskriver ikke den logiske strukturen til en database.

4.2.1 Data om enheten (offentlig organ)

4.2.2 Data om ikt-løsningen (nettsted eller mobilapplikasjon)

4.2.3 Data om siden (nettside eller skjerm i mobilapplikasjon)

4.2.4 Data om nedlastbart dokument

Merknad: Dette avsnittet gjelder bare for dybdekontroll.

4.2.5 Data om kravet (WCAG-suksesskriterium)

4.2.6 Data om testresultatet for testet side

Det følger av EN 301 549-standarden at kontrollen for samsvar eller ikke-samsvar skjer på sidenivå.

4.2.7 Data om testresultatet for testet element

I tillegg til å produsere testresultater på sidenivå, ønsker vi å utforske muligheten til å produsere testresultater på elementnivå. Begrepet «elementnivå» kan forklares som de individuelle delene eller innholdet som testes, dvs. et skjemaelement, et bilde, en tabell eller til og med en hel side, avhengig av hvilke element testreglene gjelder for. Etter vår mening vil dette hjelpe offentligrettslige organer å korrigere feilene som finnes på deres nettsteder.

4.2.8 Data om kontroll og rapportering

4.3 WCAG-suksesskriterier, ACT-regler og testverktøy

Medlemsstatene skal samkjøre kontrollen i henhold til kravene angitt i de standardene og tekniske spesifikasjonene som vises til i artikkel 6 i direktiv (EU) 2016/2102:

• en dybdekontrollmetode som grundig kontrollerer om et nettsted eller en mobilapplikasjon oppfyller alle kravene
• en forenklet kontrollmetode som påviser tilfeller av ikke-samsvar på et nettsted med et delsett av kravene (…) så langt det er rimelig mulig med bruk av automatiske tester

En del av planleggingsprosessen er derfor å bestemme hvilke suksesskriterier som skal inkluderes i den forenklede kontrollen, og hvordan testene skal utføres i både den forenklede kontrollen og dybdekontrollen.

4.3.1 Verktøy som er brukt i piloten

Et av målene med piloten var å utføre testene ved hjelp av prosjektpartnernes verktøy. I desember 2019 hadde vi et møte med prosjektspartnerne Deque, FCID og Siteimprove for å bestemme hvilke testverktøy vi skulle bruke i pilotkontrollen. Mer informasjon om verktøyene finnes i vedlegget.

ACT-reglene som ble utviklet i prosjektet, og implementeringene i verktøyene, er et pågående arbeid. Selv om ACT-reglene ble fullført av prosjektet, oppfyller de ikke nødvendigvis ACT-målene for konsistens ennå. Likevel besluttet vi å bruke ACT-regler på tidspunktet for piloten, ettersom målet var å prøve ut de forskjellige trinnene i kontrollprosessen, i stedet for en kontroll av de faktiske ACT-reglene og deres implementeringer.

Implementering av en testregel vil si hvordan en testregel tolkes og operasjonaliseres når den integreres i et testverktøy. En enkelt implementering kan teste flere ACT-regler. Et verktøy eller en metode kan også ha flere implementeringer som kombinert tilordnes en enkelt ACT-regel.

Verktøyene ble brukt i det aktuelle utviklingstrinnet på tidspunktet for testing i piloten. På grunn av dokumentasjonen fra verktøyleverandørene ble testreglene i denne rapporten fullført av prosjektet og implementert i verktøyene. Under piloten holdt vi kontakten med prosjektpartnerne, i tilfelle spørsmål eller behov for støtte. Verktøyet sto til Digitaliseringsdirektoratets rådighet, vederlagsfritt så lenge piloten varte og med tilgang til relevant støttedokumentasjon.

Et av verktøyene ble ikke brukt i den forenklede kontrollen, ettersom verktøyet ikke hadde en «crawler» for utvelging av testsider da piloten ble gjennomført.

4.3.2 WCAG-suksesskriterier dekket av piloten

I piloten ble vi begrenset til å dekke suksesskriterier som hadde tilhørende ACT-regler som ble fullført og implementert i prosjektpartnernes (Deque, FCID og Siteimprove) verktøy på tidspunktet for testing (januar/februar 2020). Vi inkluderte derfor i alt 19 ACT-regler i piloten. Dette gjelder både den forenklede kontrollen og dybdekontrollen. WAI-Tools-prosjektet skrider fram, og målet er å utvikle 70 ACT-regler innen utgangen av oktober 2020. Reglene som utvikles av prosjektet blir kontinuerlig sendt inn til W3C for videre vurdering og endelig godkjennelse som W3C ACT-regler. Vi forventer at implementeringer av disse formelt publiserte reglene vil være mer stabile og konsistente.

De utvalgte suksesskriteriene omfatter kravene: mulig å oppfatte, mulig å betjene, forståelig og robust.

Basert på

• hvilke suksesskriterier som var dekket av ACT-regler i verktøyene på tidspunktet for piloten
• de fire prinsippene i WCAG og
• hvilke av brukers tilgjengelighetsbehov som skal vurderes,

har vi valgt følgende 13 suksesskriterier for piloten:

• 1.1.1 Ikke-tekstlig innhold
• 1.2.2 Teksting (forhåndsinnspilt)
• 1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt)
• 1.3.1 Informasjon og relasjoner
• 1.3.4 Orientering
• 1.3.5 Identifisere Inndataformål
• 2.2.1 Justerbar hastighet
• 2.4.2 Sidetitler
• 2.4.4 Formål med lenke (i kontekst)
• 3.1.1 Språk på side
• 3.1.2 Språk på deler
• 4.1.1 Parsing (oppdeling)
• 4.1.2 Navn, rolle, verdi

Følgende av brukers tilgjengelighetsbehov (eller erklæring om funksjonsytelse) har en primærrelasjon til suksesskriteriet i piloten:

• Bruk uten syn
• Bruk med nedsatt syn
• Bruk uten hørsel
• Bruk med nedsatt hørsel
• Bruk med motorisk funksjonsnedsettelse eller begrenset styrke
• Bruk med kognitiv funksjonsnedsettelse

I direktivet spesifiseres det ikke om suksesskriteriet må ha en primærrelasjon til brukers tilgjengelighetsbehov. Dersom sekundærrelasjon mellom suksesskriteriet og brukers tilgjengelighetsbehov vurderes, dekker vi også bruk uten taleevne.

På grunn av begrensningen av dekning av suksesskriterier som hadde tilhørende ACT-regler som var fullført og implementert i alle tre verktøyene på tidspunktet for testing, dekket vi ikke brukers tilgjengelighetsbehov for bruk uten fargesyn og behovet for å begrense faktorer som kan utløse anfall på grunn av lysfølsomhet. I prosjektet tar vi hensyn til alle brukers tilgjengelighetsbehov når vi skal avgjøre hvilke ACT-regler som skal prioriteres.

Det er ytterligere suksesskriterier som kan være relevante å inkludere i en forenklet kontroll. Basert på resultater fra Digitaliseringsdirektoratets (den gang Difi – Direktoratet for forvaltning og ikt) kontroll i 2018 og tilsyn i 2019 har vi identifisert flere suksesskriterier i WCAG 2.0 med en høy risiko for å avdekke feil på de testede nettstedene.

Noen eksempler på suksesskriterier i tillegg til kriteriene inkludert i piloten, som også bør inkluderes i en kontroll, er:

• 1.4.3 Kontrast (minimum)
• 2.2.2 Pause, stopp, skjul
• 3.3.1 Identifikasjon av feil
• 3.3.2 Ledetekster eller instruksjoner

På tidspunktet for testing (februar 2020) er det ACT-regler under utvikling for suksesskriterium 1.4.3, 2.2.2 og 3.3.1, men disse ACT-reglene er ennå ikke implementert i verktøyene. Nye ACT-regler blir fortløpende utviklet og implementert, og dekningen vil øke etter hvert.

4.3.3 ACT-regler som er brukt i piloten

Alle ACT-reglene som ble utviklet i WAI-Tools-prosjektet, er knyttet til suksesskriteriene i WCAG.

Ettersom piloten var begrenset av utviklingen og implementeringen av testregler i prosjektpartnernes verktøy, ble følgende 19 ACT-regler brukt i både den forenklede kontrollen og dybdekontrollen:

*Alle ACT-reglene er originalt på engelsk og dette er en uoffisiell oversettelse.

Etter hvert som prosjektet skrider fram og antallet ACT-regler øker, bygger prosjektet og ACT-reglene opp et bibliotek over allment aksepterte regler. Dette vil være svært viktig for medlemsstatene, på grunn av behovet for en veldokumentert og gjennomsiktig tolkning av tilgjengelighetskravene som grunnlag for kontroll.

4.4 Læringspunkter

Funnene og læringsmomentene fra alle aspektene av planleggingen er sammenfattet nedenfor:

• Det er avgjørende å analysere direktivet for å identifisere krav til kontroll og rapportering.
• Før testen og annen datainnsamling startes, må vi definere så presist som mulig hvilke forskningsspørsmål som skal undersøkes, og deretter sikre at vi samler inn alle dataene som kreves for analyse og rapportering.
• Kravene til kontroll og rapportering og listen over forskningsspørsmål ligger til grunn for beslutninger om følgende:
  • utvalget av offentlige organer/enheter, nettløsninger, testobjekter/sider osv. Dette gjelder for utvalgets størrelse og sammensetning, og utvelgingsmetoden for enheter, nettløsninger og sider
  • kontrollmetodene, verktøyene og testmodusen (automatisk, semi-automatisk, manuell)
  • for forenklet kontroll: Hvilke suksesskriterier som skal inkluderes, særlig i og med at automatisk testing er foretrukket
  • databehov, metodene og for datainnsamling og datakildene
  • hvilken analyse som må utføres for å rapportere i samsvar med direktivet
• I denne piloten gjaldt følgende:
  • Vi brukte 19 ACT-regler som dekket 13 WCAG 2.1-suksesskriterier. Etter vår mening er det livsviktig at arbeidet med å utvikle ACT-regler fortsetter til alle tilgjengelighetskravene i direktivet er dekket. Dette er på grunn av behovet for en dokumentert, gjennomsiktig og allment akseptert testmetode.
  • Vi oppfylte kravene til forenklet kontroll ved å dekke de 4 prinsippene i WCAG samt 7 av 9 av brukers tilgjengelighetsbehov
  • Ettersom vi brukte de samme ACT-reglene og suksesskriteriene i både den forenklede kontrollen og dybdekontrollen, dekket vi bare 29 % av suksesskriteriene som var påkrevd i henhold til direktivet (for dybdekontrollen).
  • Selv om vi hadde et litt begrenset omfang når det gjaldt antallet krav som ble inkludert, kom vi nær å oppfylle minstekravene til forenklet kontroll. Basert på funn i tidligere kontroll i Norge var det imidlertid flere suksesskriterier med høy risiko som ikke var dekket av piloten. Dette var fordi verken utviklingen av testregler eller implementeringen av testregler var fullført da pilottestingen ble utført.
  • Samtidig håndteres høyrisikokriterier kontinuerlig i prosjektet. Uavhengig av dette bør man være oppmerksom på at valg (og utelukkelse) av suksesskriterier i kontrollen kan innebære at det kan være betydelige tilgjengelighetsproblemer som ikke er avdekket i kontrollen. Dette gjelder særlig den forenklede kontrollen.
• I overskuelig framtid vurderer vi at det vil være et behov for å supplere automatiske tester med både semi-automatiske og manuelle tester for å dekke alle suksesskriteriene og kravene i standarden. Dette gjelder særlig for dybdekontrollen.

Særlig ved planlegging av den første kontrollen og rapporteringen gjelder følgende:

• Det er et stort behov for å samle inn og lagre data i både den forenklede kontrollen og dybdekontrollen, slik vi har beskrevet i kapittel 4.2. Dataene må samles inn fra diverse datakilder. Vi må fastsette en datamodell for å strukturere dataene, slik at det blir enklere å lagre og gjenfinne data på en effektiv måte. Denne datamodellen bygger til en viss grad på det åpne dataformat for tilgjengelighetstestresultater som ble utviklet av prosjektet og implementert i verktøyene som en av utdata formatene.
• Vi planlegger å bruke tilgjengelighetserklæringene til å samle inn strukturerte data om de offentlige organene, nettløsningene, tjenesteområdet og individuelle tjenester per enhet. Senere vil vi vurdere å kombinere tilgjengelighetserklæringene med automatiske tester som enhetene kan utføre selv. Et av målene i WAI-Tools-prosjektet er å utvikle en prototype for storskala datanettleser, som kan samle og analysere data fra tilgjengelighetserklæringene. Dette var imidlertid ikke tilgjengelig da piloten ble gjennomført, og kan muligens vurderes i fremtiden.
• Det bør imidlertid vurderes om kravene til kontroll og rapportering er for omfattende, særlig når det gjelder nødvendige data for å sammenstille utvalgene av enheter, nettløsninger og sider, i samsvar med direktivet (som beskrevet i kapittel 4.2.1–4.2.3). Dette gjelder særlig for antallet tjenester, prosesser, sider og dokumenter som skal testes i dybdekontrollen. Det bør vurderes om et utvalg av tjenester kan være nok, i stedet for å kontrollere alle.

Dessuten har vi identifisert et sett kriterier som bør vurderes når et verktøy velges ut til testing (og produksjon av testresultater) i en faktisk kontroll:

• Dekning av WCAG, dvs. verktøyet bør dekke så mange av kravene/suksesskriteriene som mulig
• Verktøyet bør så vidt mulig ivareta behovene for gjennomsiktighet, reproduserbarhet og sammenlignbarhet, og
  • det må derfor være basert på en dokumentert tolkning av hvert av kravene i standarden
  • testreglene (og hvordan de implementeres i verktøyene) må dokumenteres for å vise hvilken tolkning av kravene som omfattes av hver test
  • verktøyet bør inkludere eller kombineres med en «crawler» som er egnet til å velge ut de fleste av sidene og innholdet som bør inkluderes i en kontroll
  • testresultatene bør spesifisere resultatet av testene, f.eks. samsvar, brudd, ikke forekomst (og ikke testbar)
  • det er å foretrekke at verktøyet gir testresultater både på element- og sidenivå, spesifisert etter suksesskriterier
  • antallet testede elementer og sider, særlig elementer med brudd og sider, bør telles og identifiseres, per suksesskriterium og totalt
  • testresultatene bør være i et format som egner seg til analyse og rapportering i samsvar med direktivet, og gi nettstedseierne / de offentlige organene nødvendig informasjon i arbeidet med å forbedre nettstedene.

5. Trinn 2: Utvelging

I dette kapittelet presenterer vi erfaringene vi har gjort oss ved utvelging av offentlige organer, nettsteder og sider. Målet er å dokumentere metoder og datakilder for å velge offentlige organer, nettsteder og nettsider og stille forberedt til å skape et utvalg i en faktisk kontroll i samsvar med direktivet. Direktivet beskriver også utvelgingskriterier for mobilapplikasjoner. De faktiske dataene vi samlet inn gjennom utvelgingen, er videre presentert i kapittel 6.

Merknad: På grunn av pilotens omfang har vi valgt ut og kontrollert bare nettsteder.

5.1 Offentlige organer og nettsteder

Antallet nettsteder (og mobilapplikasjoner) som skal kontrolleres i hver kontrollperiode, skal beregnes på grunnlag av størrelsen på medlemsstatens befolkning.

Basert på en befolkning på 5 367 580 skal kontrollen i Norge inkludere antallet nettsteder angitt i tabellen.

Utvelgingen av nettsteder skal:

• ha som mål en variert, representativ og geografisk balansert fordeling
• omfatte nettsteder fra følgende forvaltningsnivåer
  • statlige nettsteder
  • regionale nettsteder
  • lokale nettsteder
  • offentligrettslige organers nettsteder
• omfatte nettsteder som i størst i mulig grad representerer det spekteret av tjenester som ytes av offentlige organer, særlig sosialomsorg, helse, transport, utdanning, sysselsetting, beskatning, miljøvern, fritid og kultur, bolig og nærmiljø samt offentlig orden og sikkerhet
• gjenspeile oppfatningene til nasjonale berørte parter om spesifikke nettsteder som skal kontrolleres, særlig fra organisasjoner som representerer personer med nedsatt funksjonsevne

Merknad: For piloten valgte vi bare fire nettsteder eid av offentlige organer, ett per kategori som kreves i henhold til direktivet (statlig, regionalt, lokalt, offentligrettslig organ).

Med et slikt lite utvalg var ikke målet en balansert geografisk fordeling og dekning av de varierte tjenestene, men vi prøvde i en viss grad å ta hensyn til disse faktorene. Vi involverte heller ikke nasjonale berørte parter, noe vi vil gjøre i en faktisk kontroll.

I piloten hadde vi et forhåndsvalgt utvalg av enheter. For å få erfaring med å samle inn nødvendig informasjon for å gjøre et utvalg i samsvar med direktivet søkte vi imidlertid i Enhetsregisteret etter følgende:

• navn
• nettadresse (dersom den er registrert)
• adresse (geografisk beliggenhet)
• organisasjonsnummer
• antall ansatte
• gruppering av institusjonell sektor
• standard for næringsgruppering

Institusjonell sektor- og næringsgruppering kan være nyttig for å:

• bestemme forvaltningsnivået (statlig, regionalt, lokalt, offentligrettslig organ):
  • For statlige, regionale og lokale enheter søkte vi etter enheter med den institusjonelle sektorgrupperingen statsforvaltning og kommuneforvaltning (som også inneholder regionalt nivå).
  • For offentligrettslige organer søkte vi etter enheter med den institusjonelle sektorgrupperingen enheter med forretningsvirksomhet på statlig eller regionalt/kommunalt nivå
• Å få en indikasjon på tjenesteområdet basert på en kombinasjon av institusjonell sektor- og næringsgruppering:
  • Et eksempel er næringen «transport av passasjerer» kombinert med den institusjonelle sektoren «kommunale foretak».
  • Et alternativ eller et supplement er å inspisere enhetenes nettsteder for å få informasjon om tjenesteområdet.

Imidlertid er utgangspunktet for å velge ut nettsteder, andelen offentlige organer som er nettstedseiere. Dette skyldes kriterier for utvelging, som geografi og forvaltningsnivå. Og ikke minst er det nettstedseierne som er ansvarlige for å overholde bestemmelsene.

Vi har ikke et register over nettsteder i Norge som er egnet til å velge et utvalg som omfatter både enhetene og deres nettsteder. Hovedkilden til utvelging for kontroll i Norge vil derfor sannsynligvis være Enhetsregisteret. For noen enheter er nettstedenes nettadresse angitt i registeret.

To av de fire valgte enhetene for piloten fikk nettstedene sine registrert. For de andre søkte vi på Internett for å finne nettstedene.

Et alternativ for å søke etter et enormt antall nettsteder er å ha en dialog med enhetene for å bestemme nettstedene som skal kontrolleres. En slik dialog kan utføres gjennom en undersøkelse, eller kanskje helst samle inn denne informasjonen gjennom tilgjengelighetserklæringene.

I piloten samarbeidet vi med nettstedseieren om den utvalgte enheten på statlig nivå for å identifisere hvilket nettsted som skal kontrolleres. Dette offentlige organet har mer enn 20 nettsteder i porteføljen. Som et eksempel har Digitaliseringsdirektoratet nesten 10 forskjellige nettsteder. Vi har opplevd lignende tilfeller i tidligere statusundersøkelser. Vi har også tidligere undersøkt at ca. 1/3 av enhetene deler nettløsninger med andre enheter. Ett eksempel er Departementenes sikkerhets- og serviceorganisasjon, som administrerer nettstedene for alle de norske departementene.

Dette er særlig viktig å være oppmerksom på i oppfølging og kommunikasjon med enhetene om kontrollresultatene.

For piloten kontrollerte vi ett nettsted per enhet. Alle fire nettstedene ble testet i den forenklede kontrollen, mens det statlige nettstedet også ble dybdetestet. Vi har anonymisert dataene om enhetene og nettstedene i piloten.

En fullstendig oversikt over dataene vi samlet inn om enhetene og nettstedene, finnes i kapittel 6 Datainnsamling.

5.2 Nettsider

Kravene til kontrollen av nettsider er angitt for hver kontrollmetode. Ved bruk av dybdekontrollmetoden skal følgende sider og dokumenter kontrolleres, dersom de finnes:

1. startsiden, innloggingssiden, nettstedkart, siden med kontaktopplysninger, hjelpesiden og siden med juridisk informasjon
2. minst en relevant side for hver «type of service» som leveres via nettstedet eller mobilapplikasjonen, og enhver annen primær tiltenkt bruk, herunder søkefunksjonen
3. sidene som inneholder tilgjengelighetserklæringen eller -retningslinjer for tilgjengelighet, og sidene som inneholder tilbakemeldingsfunksjonen
4. eksempler på sider som har et vesentlig ulikt utseende, eller som viser en annen type innhold
5. minst ett relevant nedlastbart dokument, dersom det er anvendbart, for hver «type of service» som leveres via nettstedet eller mobilapplikasjonen, og for enhver annen primær tiltenkt bruk
6. enhver annen side som kontrollorganet anser som relevant
7. tilfeldig utvalgte sider som utgjør minst 10 % av de sidene som er valgt ut i samsvar med bokstav a)–f)

Kravene til forenklet kontroll er mindre spesifikke, idet de sier at et antall sider som er tilpasset nettstedets anslåtte størrelse og kompleksitet, skal kontrolleres i tillegg til startsiden.

Vi valgte ikke ut, og testet ikke, nettsider som krever innlogging i pilotkontrollen, ettersom disse nettsidene er både vanskelige å lokalisere og umulige å teste automatisk. I både den forenklede pilotkontrollen og dybdepilotkontrollen testet vi tredjepartsinnhold og annet innhold som ikke var omfattet av direktivet. Vi vurderte at en analyse av nettsidene for å utelukke dette innholdet fra utvalget ble ansett å være for ressursintensivt for piloten.

5.2.1 Dybdekontroll

Utvalget av nettsider for dybdekontrollen ble gjort i samarbeid med nettstedseieren på statlig nivå. I dialog med det faktiske offentlige organet oppdaget vi snart at de mest relevante sidene og tjenestene krevde at vi logget inn ved hjelp av et nasjonalt ID-nummer. Innloggingsprosessen krevde også totrinnsverifisering. Verktøyene som ble brukt i piloten, klarte ikke å teste disse sidene. Vi testet heller ikke nedlastbare dokumenter, ettersom dette var utenfor omfanget av piloten.

En alternativ måte å velge ut nettsider til dybdekontroll på er å bla gjennom nettstedet og bruke søkefunksjonen til å finne nettsider som er relevante for kravene i direktivet.

Direktivet krever kontroll av minst én relevant side for hver «type of service», og dersom noen av sidene er en del av et trinn i en prosess, skal alle trinnene i prosessen verifiseres. For enorme og komplekse nettsteder kan dette føre til et stort antall sider som må kontrolleres i dybdekontrollen, der alle kravene/suksesskriteriene skal inkluderes.

Det er nokså utfordrende at begrepene «type of service» og «process» ikke er definert i direktivet:

• I piloten vurderte vi sider som er en del av en interaktiv prosess på nettstedet, til å vurderes som en «prosess».
• Vi hadde en kort dialog med den statlige enheten om hva slags tjenester som tilbys gjennom nettstedet deres. Det var nokså utfordrende å identifisere tjenestene som ble tilbudt via nettstedet, særlig i og med at begrepet tjeneste ikke er definert, og derfor kan det være litt tilfeldig hva man vurderer som en tjeneste. At vi uansett ikke kunne teste sider som krever innlogging, ga en vesentlig begrensning i antallet testbare prosesser.

En fullstendig oversikt over dataene vi samlet inn om de utvalgte nettsidene og prosessen for dybdekontrollen, finnes i kapittel 6 Datainnsamling.

5.2.2 Forenklet kontroll

På grunn av begrensede ressurser i pilotkontrollen valgte vi ut et likt antall sider – 1 000 nettsider – herunder startsiden, for hvert av de utvalgte nettstedene. Vi brukte verktøyene fra Deque og Siteimprove. Disse verktøyene muliggjorde automatisk utvelging av nettsidene ved hjelp av en «crawler». FCIDs QualWeb Core ble ikke brukt i den forenklede kontrollen, ettersom verktøyet ikke hadde en «crawler» på det tidspunktet.

Som det følger av direktivet skal utvalget av sider gjenspeile nettstedets anslåtte størrelse og kompleksitet. Det er mulig å bruke en «crawler» eller en søkemotor til å anslå størrelsen, men ikke kompleksiteten.

Med søkemotor for å få anslåtte tall, var antallet sider for hvert av de fire utvalgte nettstedene følgende:

• NN Offentlig organ på statlig nivå: 24 600 sider (herunder 5740 PDF-dokumenter)
• NN Offentlig organ på regionalt nivå: 3 240 sider (herunder 1510 PDF-dokumenter)
• NN Offentlig organ på lokalt nivå: 26 500 sider (herunder 5580 PDF-dokumenter)
• NN Offentligrettslig organ: 2 630 sider (herunder 345 PDF-dokumenter)

Imidlertid var det vanskelig å bestemme nøyaktig størrelse på og antall nettsider på et nettsted. Søkemotoren talte ikke nettsidene og tjenestene som krever innlogging. Når en søkemotor brukes til å bestemme nettstedets størrelse, ble nedlastbare dokumenter også talt med i søkeresultatene.

Å bestemme størrelsen på prøven i den forenklede kontrollen er komplekst. Noen mulige løsninger er angitt i tabellen nedenfor:

Ettersom disse utvelgingsmetodene krever at nettstedets størrelse og kompleksitet er kjent, kan kontrollorganene finne det nyttig å fastsette en dialog med de kontrollerte enhetene. Dette kan imidlertid snart bli en manuell og ressursintensiv prosess når den involverer mange berørte parter.

For å vurdere nettstedets kompleksitet er det mulig å bruke en «crawler» til å samle inn informasjon om typene innhold og elementer som finnes på nettsidene. Vi kan bruke «crawler»-resultatene til å sikte oss inn på nettsider med innhold som er relevant for videre testing. Ulenkede sider og sider bak innlogging blir ikke funnet av en «crawler».

Merknad: Utviklingen av en «crawler» er ikke en del av WAI-Tools-prosjektet.

5.3 Læringspunkter

Utvelging av offentlige organer/enheter:

• Vi vil dra nytte av å utvikle en effektiv metode for å etablere et representativt utvalg i samsvar med direktivet. Dette vil forhåpentlig bidra til at analysen av tilgjengelighetshindringer som kontrollen avdekker, er pålitelig og samfunnsmessig betydningsfull.
• Et representativt utvalg gjør at vi kan generalisere kontrollresultatene og fastsette en nasjonal indikator for graden av samsvar med tilgjengelighetskravene fastsatt i direktivet, en samlet tilgjengelighetsindikator for nettsteder. Dette kan også være egnet til referansemåling.
• For å velge et representativt utvalg trenger vi informasjon om utvalget av offentlige organer. Enhetsregisteret (eller lignende) kan brukes til å gjøre et utvalg av offentlige organer.
• Den institusjonelle sektorgrupperingen og næringsgrupperingen i registeret kan være nyttig for å bestemme forvaltningsnivået (statlig, regionalt, lokalt, offentligrettslig organ). Basert på en kombinasjon av grupperingene av institusjonell sektor og næring kan vi også få en indikasjon på tjenesteområdet.
• Det ligger stort potensial i mer automatisering, for eksempel ved å gjøre (i størst mulig grad) et tilfeldig utvalg fra Enhetsregisteret (eller lignende), basert på spesifikasjoner av kriteriene som vises til i direktivet.

Utvelging av nettsteder:

• Det finnes ikke noe register i Norge som er egnet til å gjøre et utvalg av nettsteder. Det totale nettstedsutvalget er dermed ukjent. For å lokalisere og gjennomføre et utvalg av nettsteder som passer 100 prosent med kriteriene i direktivet, må vi samle inn data som viser hvilke nettløsninger som tilhører hver valgt enhet.
• Noen enheter har mer enn ett nettsted. I disse tilfellene må vi bestemme hvilket nettsted som skal inkluderes i kontrollen. På den annen side deler noen enheter nettløsninger med andre, og i slike tilfeller må vi identifisere hvem som er ansvarlig. I piloten måtte vi kombinere informasjon fra registeret med nettsøk etter offentlige organers nettsteder. Dette er tidkrevende.
• En kombinasjon av data fra Enhetsregisteret og inndata fra enhetene gjennom tilgjengelighetserklæringene kan være en effektiv metode. Vi kan bruke erklæringene til å samle inn strukturerte data om forvaltningsnivå, tjenesteområde, hvilke nettsteder (og mobilapplikasjoner) som er relevante for kontroll osv.
• Likevel er det viktige spørsmål om utvelgingskravene som ikke er spesifisert i direktivet, f.eks.:
  • om utvelging for forenklet kontroll og dybdekontroll må skje i separate operasjoner
  • om målet med utvelging for henholdsvis forenklet kontroll og dybdekontroll skal være et variert, representativt og geografisk balansert utvalg
  • om dybdekontrollen kan være basert på en utvelging av nettstedene i den forenklede kontrollen

Det ville være svært nyttig dersom denne saken kunne presiseres av EU.

Utvelging av sider (og dokumenter) – dybdekontroll:

• Det bør vurderes om kravene til utvalget av testsider er for omfattende. Utvelging av nettsider er en kompleks og tidkrevende oppgave som krever manuell innsats. Det kan vurderes om det bør innledes en dialog med nettstedseierne for utvelging av sider og dokumenter. Imidlertid må vi vurdere om dette er kostnadseffektivt.
• Begrepet «type of service» og «process» bør defineres, slik at en tilfeldig metode unngås når tjenester og prosesser skal identifiseres. I en faktisk kontroll gjelder dette også for nedlastbare dokumenter, ettersom det i direktivet kreves testing av minst ett relevant nedlastbart dokument, dersom det er relevant, for hver type tjeneste som leveres via nettstedet.
• Dersom de utvalgte sidene i dybdekontrollen er del av en prosess, kreves det i direktivet at alle trinn i prosessen kontrolleres. Etter vår erfaring kan prosesser kreve pålogging med et nasjonalt ID-nummer. Det er derfor avgjørende at vi fastsetter en metode til å få innloggingstilgang til disse prosessene/nettsidene.

Utvelging av sider (og dokumenter) – forenklet kontroll:

• Vi trenger en skala eller kriterier for å vurdere hva som vil være et egnet antall testsider, basert på hvor stort og komplekst nettstedet som skal kontrolleres, anslås å være.
• For forenklet kontroll trenger vi tilgang til en «crawler» for å velge ut nettsider. «crawler»-en i de ulike verktøyene kan imidlertid bruke forskjellige metoder til å gjennomsøke nettstedene. Dette kan gjøre at verktøyene velger ut forskjellige sider på samme nettsted.
• «Crawling» er også nødvendig for å anslå størrelsen på et nettsted. Her bør man være oppmerksom på at «crawling» ikke finner skjulte sider, underdomener eller sider som krever innlogging.
• I mangel på adekvate alternativer vurderer vi fortsatt at bruk av en «crawler» for å velge ut nettsider er den mest effektive metoden.

Utvelging av sider (og dokumenter) – både dybde og forenklet:

• Vi trenger en metode til å utelukke sider som har tredjepartsinnhold og annet innhold som ikke er omfattet av direktivet.
• Vi må se på om det er mulig å teste nettsider som krever pålogging, ved hjelp av automatiske verktøy. Dette gjelder primært for dybdekontroll, men det er ønskelig å kunne omfatte denne typen innhold i en forenklet kontroll også.

6. Trinn 3: Datainnsamling

I piloten samlet vi inn data om enhetene, nettstedene og nettsidene, i tillegg til testresultater fra kjøring av verktøyene. Datainnsamlingen er basert på datakravene til kontroll angitt i kapittel 4.

For nettstedene i utvalget var målet å samle inn data om hver nettside og hvert testet element for å gi resultater for samsvar og ikke-samsvar for hvert tilgjengelighetskrav i direktivet.

De innsamlede dataene er angitt i dette kapittelet.

6.1 Data om enheter

Følgende tabell sammenfatter hvert dataelement vi samlet inn om enhetene som ble valgt ut i piloten, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 4.2.1.

Basert på ovenstående kilder samlet vi inn data om de utvalgte enhetene. Dataene er angitt i tabellen nedenfor.

6.2 Data om ikt-løsninger (nettsteder)

Følgende tabell sammenfatter hvert dataelement vi samlet inn om nettstedene som ble valgt ut i piloten, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 4.2.2.

Merknad: Vi forhørte oss ikke med nasjonale berørte parter om sammensetningen av utvalget av enheter og nettløsninger, ettersom dette er en pilot som bare omfatter noen få nettsteder.

De fullstendige dataene som ble samlet inn om utvalget av nettsteder, er angitt i følgende tabell:

6.3 Data om sider

Følgende tabell sammenfatter hvert dataelement vi samlet inn om nettsidene som ble valgt ut i piloten, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 4.2.3.

6.3.1 Dybde

Dataene som ble samlet inn om utvalget av nettsider for nettstedet som ble testet i dybdekontrollen, er angitt i følgende tabell. Hver side var knyttet til type tjeneste og prosess, dersom det var relevant.

Vi valgte ut alle de relevante typene sider som fantes på nettstedet, og sider som er inkludert i en prosess som ikke krever innlogging.

6.3.2 Forenklet

I den forenklede kontrollen ble bare startsiden angitt. De andre sidene trenger ikke å kategoriseres. I tillegg til startsiden gjennomsøkte vi inntil 1 000 sider per nettsted i piloten.

Ettersom det vil være for omfattende å angi inntil 1 000 sider per nettsted for hvert verktøy, har vi angitt samlet antall sider (herunder startsiden) som ble «crawled» og testet per nettsted, i følgende tabell:

Slik det framgår av tabellen, var det forskjeller mellom verktøyene ved søk etter nettsider. Av praktiske grunner fastsatte vi et fast antall nettsider i piloten, noe som tilsier at dekning av nettstedene varierer mye. I en faktisk kontroll skal antallet testsider gjenspeile nettstedets størrelse og kompleksitet. I piloten undersøkte vi ikke nettstedets kompleksitet, ettersom begrepet ikke er definert i direktivet.

6.4 Data om kravet

Følgende tabell sammenfatter hvert dataelement vi samlet inn om hvert krav (WCAG-suksesskriterium) i piloten, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 3.2.4.

Den fullstendige listen over krav i piloten er beskrevet i kapittel 3.3.2. Som et eksempel ble dataene om et enkelt krav strukturert på følgende måte:

Kravene er basert på standarden EN 301 549 V2.1.2. Vi samlet inn og dokumenterte data om kravene som presentert i tabellen nedenfor:

6.5 Data om testresultater

I dette kapittelet presenterer vi testresultater og data om testresultatene, for henholdsvis sider og elementer, spesifisert etter dybdekontroll og forenklet kontroll. Direktivet krever testresultater på sidenivå. For å sikre at de offentlige organene har data og informasjon om samsvar og ikke-samsvar med tilgjengelighetskravene, er det også behov for detaljerte testresultater for hvert testet element. Dette vil hjelpe de offentlige organene med å rette feilene som blir funnet på nettstedene deres.

Det er også vesentlig å kontrollere samsvar (og ikke-samsvar) med det faktiske kravet i direktivet. Resultatene må derfor spesifiseres per suksesskriterium, og ikke bare per testregel.

I det følgende begynner vi med å presentere hvilke dataelementer vi samler inn og beregner. Etterpå følger de faktiske resultatene og funnene.

6.5.1 Testresultater på sidenivå

Følgende tabell sammenfatter hvert dataelement vi samlet inn om testresultatene for en testet side i piloten, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 4.2.6.

6.5.2 Testresultater på elementnivå

Følgende tabell sammenfatter hvert dataelement om testresultatene for et testet element i piloten og kilden til dataene. Dette datakravet er beskrevet i kapittel 4.2.7.

Ettersom vi ikke effektivt klarte å samle inn data for hvert testet element, talte vi antallet elementer med brudd basert på aggregerte data fra verktøyene. Vi gjorde dette ved å trekke ut «elementer med brudd» per testregel. Deretter aggregerte vi dataene for å vise antallet elementer med brudd per suksesskriterium

Dette gjelder for både dybde og forenklet kontroll.

Merknad: Det er viktig å merke at EN 301 549, ikke oppstiller krav på elementnivå.

Resultater på elementnivå vil imidlertid, etter vår mening, øke verdien av veiledning til offentligrettslige organene når de forsøker å forbedre sine nettsteder. Tellingen av resultater er imidlertid for øyeblikket avhengig av de enkelte verktøyimplementeringer og hvordan de utfører testingen. Videre veiledning om tilordning av resultater for individuelle sideelementer er nødvendig.

6.5.3 Testresultater fra dybdekontroll

Vi brukte verktøyene fra Deque, FCID og Siteimprove i dybdekontrollen. I dybdekontrollen testet vi 9 sider som ble valgt ut fra nettstedet på statlig nivå.

Tabellene nedenfor viser antallet unike nettsider med elementer med brudd, som rapportert av verktøyene. Testresultatene har vært aggregert fra antallet unike sider med et av flere elementer med brudd for hvert suksesskriterium. Antallet elementer med brudd vises i parentes.

Som nevnt i kapittel 4.3 kan verktøyene ha forskjellige måter å implementere ACT-reglene på, selv om implementeringene tilordnes til de samme ACT-reglene. For eksempel, hadde ett av verktøyene flere interne regler som tilordner til en ACT-regel, mens et annet verktøy hadde en en-til-en tilordning. Dette påvirker testresultatene som genereres av verktøyene og gjør det vanskeligere å aggregere testresultater til suksesskriterienivå og spesifisere resultatene for hver unike testside uten ekstra prosessering av dataen.

6.5.4 Testresultater fra forenklet kontroll

Innen pilotens tidsramme klarte vi ikke å ordne dataene fra den forenklede kontrollen på sidenivå, for presentasjon i denne rapporten. For å presentere data for antallet unike sider med elementer med brudd for de testede suksesskriteriene måtte vi manuelt registrere og lagre testdata for hver utvalgt side. Vi registrerte denne informasjonen for hver testet side i dybdekontrollen, som presentert ovenfor. Dette ville være for tidkrevende for de (opptil) 1 000 sidene per nettsted som ble testet i den forenklede kontrollen.

Utfordringen kan sammenfattes på følgende måte:

• Verktøyene som ble brukt i den forenklede kontrollen, rapporterte unike sider med elementer med brudd per testregel, og ikke direkte per suksesskriterium. Videre prosessering vil være nødvendig for å kombinere de individuelle resultatene.
• Ettersom verktøyene i mange tilfeller hadde flere testregler per suksesskriterium (ikke 1 til 1), ble det svært vanskelig å beregne samsvarsstatus per suksesskriterium uten videre veiledning.
• Ved å aggregere resultatene på testregelnivået klarte vi derfor ikke å beregne antallet unike sider som ble underkjent for et gitt suksesskriterium. Andre verktøy, som muligens bygger på slike testmotorer, kan være i stand til å tilføre en slik aggregering funksjonalitet.
• Verktøy «crawl»-er også nettstedene på ulik måte, som påvirker resultater som skapes av verktøyene. For å effektivt sammenligne resultater, må man bruke en enkelt «crawler» for å teste det samme utvalget av sider parallelt.

Dette kan forklares med et eksempel:

• Suksesskriterium 1.1.1 implementeres i et testverktøy etter testregel 1 og testregel 2.
• Dersom en side får brudd både på testregel 1 og testregel 2, og disse bruddene legges til, vil det virke som om to sider fikk brudd for suksesskriterium 1.1.1, mens det egentlig bare var én unik side som ble testet.

Vi klarte å trekke ut individuelle testresultater for den forenklede kontrollen.

Det er vesentlige variasjoner i antallet elementer som ble testet med resultatet «brudd». Dette knytter seg til de individuelle implementeringene av verktøyene, og inkluderer hvordan verktøyet «crawl»-er nettstedet. Vi legger fram resultatene her for å understreke at det er svært viktig å undersøke dokumentasjonen av verktøyene for å ha kontroll over hva som testes, og hvordan testene utføres.

Tabellen nedenfor viser antallet elementer med brudd hvert testede nettsted, slik verktøyet rapporterte det.

6.6 Data om kontroll og rapportering

Følgende tabell sammenfatter hvert dataelement vi samlet inn om kontrollen, kilden til dataene og hvordan vi samlet inn dataene. Dette datakravet er beskrevet i kapittel 3.2.8.

De fullstendige dataene som ble samlet inn om pilotkontrollen, er angitt i følgende tabell:

6.7 Læringspunkter

Data om enhetene:

• Vi klarte å samle inn alle dataene om de offentlige organene, slik det er angitt i kapittel 4.2.1. De fleste data kan lastes ned fra Enhetsregisteret (eller lignende).
• Kombinasjonen av institusjonell sektor- og næringsgruppering kan være nok til å bestemme type tjeneste som enheten tilbyr (gjennom nettstedet sitt), særlig for den forenklede kontrollen. For dybdekontrollen kan dette være utilstrekkelig.
• I mange tilfeller vil vi måtte gjennomføre en mer omfattende kontroll av det faktiske innholdet på enhetens nettsted. Dette kan være svært tidkrevende, og kvaliteten på dataene kan være utilstrekkelig. Det bør vurderes å bruke tilgjengelighetserklæringene som datakilde for dette formålet. Dette kan være atskillig mer kostnadseffektivt enn manuelle tilsyn. Et av målene med WAI-Tools-prosjektet var å utvikle en prototype for en storskala datanettleser, som ville kunne samle og analysere data fra tilgjengelighetserklæringene. Dette var imidlertid ikke tilgjengelig da piloten ble gjennomført, og kan muligens vurderes i fremtiden.

Data om nettstedene:

• I piloten kombinerte vi data fra Enhetsregisteret med søk på internett for å finne de utvalgte offentlige organenes nettadresser. Det bør vurderes å gjøre det obligatorisk å rapportere nettløsningsadressene til registeret, og/eller ordne tilgjengelighetserklæringene slik at disse dataene kan rapporteres direkte til kontrollorganet.
• I noen tilfeller kan data om tjenesteområde registreres på enhetsnivå. I andre tilfeller der enheten tilbyr et bredt utvalg av tjenester og dessuten har forskjellige nettsteder for ulike typer tjenester, må tjenesteområdet defineres på nettstedsnivå. Dette gjelder for eksempel for Digitaliseringsdirektoratet.
• Noen enheter/nettsteder tilbyr et bredt utvalg av tjenester. I piloten valgte vi bare ut noen tjenester fra nettstedet vi kontrollerte i dybdekontrollen. I en faktisk kontroll vil vi trenge en oversikt over alle tjenestene som tilbys av en enhet eller via et nettsted, ettersom det i direktivet kreves kontroll av minst én relevant side for hver type tjeneste som leveres av nettstedet. Vi må derfor samle inn omfattende informasjon om de forskjellige tjenestene som enheten/nettstedet tilbyr. Det bør derfor gjennomgås i hvilket omfang dette er kostnadseffektivt, og om det i stedet bør være mulig å kontrollere et utvalg av tjenester i stedet for å inkludere alle.
• Å identifisere tjenestene som tilbys på et nettsted, er utfordrende. Som tommelfingerregel vil kommunale nettsteder i de fleste tilfeller ha et mer standardisert (lovfestet) sett av tjenestetilbud. Dette vil også være tilfelle for mange av de regionale nettstedene. For de statlige nettstedene og nettstedene som tilhører offentligrettslige organer, er det sannsynligvis brede variasjoner, både i omfang, kompleksitet og tjenestetilbud. Man bør vurdere å bruke tilgjengelighetserklæringene til å samle inn denne slags informasjon, muligens supplert av dialog med de offentlige organene dersom mer informasjon er nødvendig.

Data om sider:

• For den forenklede kontrollen er det bare startsiden som må identifiseres (og dokumenteres). For dybdekontrollen er det et behov for mer data om sidene enn i den forenklede kontrollen.
• Vi klarte å identifisere og registrere data om nettsidene som er nødvendige for dybdekontrollen, forutsatt at de fantes på nettstedet.
• For å vurdere om en side er del av en prosess, og for å kontrollere at vi valgte ut sidene angitt i gjennomføringsbeslutningen, måtte vi inspisere nettstedet manuelt. Det var den eneste måten vi klarte å samle inn dataene om nettsidene på, slik det er angitt i kapittel 4.2.3.
• Prosessen var tidkrevende og avhengig av deltakelse fra nettstedseieren. I en faktisk kontroll kan det vurderes om det er for omfattende å ha dialoger med nettstedseierne for å samle inn data om de utvalgte nettsidene. Det kan derfor være nyttig å gjennomgå om det er nødvendig å velge ut (og dokumentere) testsidene som beskrevet i gjennomføringsbeslutningen.
• Uansett trenger vi informasjon eller data som knytter sidene til tjenester og prosesser. Begrepene «type of service» og «process» bør derfor defineres.

Data om kravet:

• Innsamling av data om kravene ble utført ved å rådføre seg med EN-standarden.
• Informasjon om hvilke av brukers tilgjengelighetsbehov som tilsvarer hvert krav eller suksesskriterium, finnes nærmere bestemt i standarden EN 301 549, vedlegg B.1. Disse dataene hjelper oss med å analysere hvilke digitale hindringer brukere med forskjellige tilgjengelighetsbehov møter på internett.

Data om testresultatene:

• Ved hjelp av de tre verktøyene fra prosjektpartnerne klarte vi å samle inn testresultater på sidenivå per suksesskriterium for dybdekontrollen, og individuelle testresultater per suksesskriterium for både dybdekontrollen og den forenklede kontrollen.
• Vi brukte to av de tre verktøyene i den forenklede kontrollen. Vi klarte ikke å samle inn testresultater på sidenivå, ettersom vi ikke klarte å fastsette en modell for å konvertere testresultater fra testregelnivået til suksesskriterienivået. Metoden som brukes til dette formålet i dybdekontrollen, var ikke gjennomførbar for den forenklede kontrollen på grunn av det enorme antallet sider som ble testet (inntil 1 000 sider per nettsted).
• Alle de tre verktøyene rapporterte testresultater i kategorien «brudd», mens et av de tre også rapporterte resultater i kategoriene «samsvar» og «ikke forekomst». Etter vår mening er det foretrukket å ha data om testresultatene som dekker alle de tre kategoriene samsvar, brudd og ikke forekomst.
• For to av verktøyene var det også vanskelig å kontrollere om en nettside var blitt testet.
• Det var utfordrende å få tak i antallet unike sider med brudd per suksesskriterium ved hjelp av verktøyene i deres daværende tilstand. I en faktisk kontroll må vi trekke ut testresultater på suksesskriterienivå. En løsning kunne være å ordne eksportfunksjonene fra verktøyene, slik at vi kunne gjenfinne resultater for unike sider etter suksesskriterium direkte.
• Vi la ned en betydelig manuell innsats for å trekke ut og presentere dataene. Vi slet også med å eksportere testdata fra verktøyene i et annet format som var egnet for distribusjon til nettstedseierne. Dessuten trenger vi også et dataformat som er egnet til videre analyse.
• Dersom vi hadde hatt mulighet til å utforske disse problemstillingene videre innen pilotens frist, er det mulig at verktøyleverandørene kunne ha hjulpet oss med å produsere og konvertere testresultater mer effektivt. Denne datamodellen er til en viss grad bygget på et åpent dataformat for tilgjengelighetstestresultater som ble utviklet av prosjektet og implementert i verktøyene som et av utdata formatetene.

Merknad: Det er viktig å påpeke at hvis vi hadde hatt muligheten til å grave dypere i disse problemkompleksene under piloten, ville de ansvarlige prosjektpartnerne for verktøyene sannsynligvis ha hjulpet oss med å produsere, eksportere og konvertere testresultatene mer effektivt.

Data om testresultatene – tilleggskommentarer:

• Dokumentasjon av testmetoder, verktøy (og versjon), er vesentlig for å sikre gjennomsiktighet, reproduserbarhet og sammenlignbarhet. Generelt er det avgjørende å undersøke dokumentasjonen av verktøyene for å ha kontroll over hva som testes, og hvordan testene utføres.
• Gitt at denne piloten ble utført under aktiv prosjektutvikling, var det utfordrende å bestemme hvilken versjon av en ACT-regel som var implementert i hvert av de tre verktøyene, ettersom bare informasjon om når hver ACT-regel sist ble oppdatert, er tilgjengelig på nettstedet med ACT-reglene. Nettstedet med ACT-reglene inneholder også en oversikt over de forskjellige implementeringene av ACT-reglene, men det er ikke spesifisert hvilken versjon eller når de forskjellige ACT-reglene ble implementert i verktøyene. Vi forventer at denne sitasjonen vil forbedre seg når ACT-reglene blir formelt publisert av W3C, og implementeringer av disse stabiliseres.

Data om kontrollen og rapporteringen:

• Data om kontrollen og rapporteringen kan enkelt samles inn fra planleggingen og dokumentasjonen av kontrollen. Disse dataene er blant annet informasjon om kontrollperioden, organet med ansvar for kontrollen osv. En fullstendig liste vises i tabellen i kapittel 6.6.

7. Trinn 4: Analyse og rapportering

I dette kapittelet vurderer vi om dataene vi la fram i kapittel 6, er egnet til analyse og rapportering i samsvar med kravene beskrevet i direktivet og gjennomføringsbeslutningen. Piloten fokuserte på å høste erfaring med kontrollprosessen, i stedet for å samle inn datamengder i det omfang som er nødvendig for å utføre den kvalitative og kvantitative analysen slik det er påkrevd.

Rapporten fra kontrollen skal i korte trekk inneholde følgende:

• en beskrivelse av hvordan kontrollen ble gjennomført
• en kartlegging, i form av en sammenligningstabell, som viser hvordan de benyttede kontrollmetodene knytter seg til kravene i standardene og de tekniske spesifikasjonene
• resultatene av kontrollen, herunder måledata

Begrepet «måledata» betyr (i piloten) de kvantifiserte

• resultatene av den utførte kontrollaktiviteten for å verifisere samsvar
• opplysningene om utvalget av nettsteder
• opplysningene om tilgjengelighetsnivået
• opplysningene om utvalget av testede nettsteder
• resultatene av kontrollaktiviteten

Måledataene skal også beskrive resultatet av kontrollen ved å gi

• en fullstendig beskrivelse av resultatene
• en kvalitativ analyse av resultatene av kontrollen, herunder funn når det gjelder hyppig eller kritisk ikke-samsvar

Kravene til rapportering er operasjonalisert i et sett forskningsspørsmål, slik vi har beskrevet i kapittel 4.1.6.

I de følgende avsnittene legger vi fram vår vurdering av i hvilket omfang vi klarte å fastsette data som var egnet til analyse og rapportering.

7.1 Spørsmål som skal besvares om kontrollen

Vi identifiserte fire spørsmål som skal besvares om kontrollen:

1. Hvilken størrelse og sammensetning av utvalget av nettløsninger (og mobilapplikasjoner) bør inkluderes både i den forenklede kontrollen og dybdekontrollen?
2. Hvordan velges nettløsningene – og nærmere bestemt – hvilke løsninger velges i dialog med berørte parter? Til senere kontroll: Hvilke nettløsninger har vært inkludert ved tidligere kontroll?
3. Hvilke sett suksesskriterier er omfattet av kontrollen, og i hvilke grad sammenfaller de med WCAG-prinsippene (mulig å oppfatte, mulig å betjene, forståelig og robust) og brukers tilgjengelighetsbehov i direktivet? Merknad: Dette gjelder for den forenklede kontrollen.
4. Hvordan metoder, tester og verktøy, identifiserer ikke-samsvar (forenklet kontroll), og hvordan verifiseres samsvar (dybdekontroll), med kravene i direktivet?

Dessuten må vi gi noe generell informasjon om kontrollperioden og kontrollorganet. I henhold til omfang av piloten er følgende avsnitt bare basert på nettsteder (ikke mobilapplikasjoner).

7.1.1 Utvalgets størrelse og sammensetning

Ettersom det ikke finnes et register over nettsteder i Norge som egner seg til kontrollformål, er summen av antall nettsteder ukjent. Grunnlaget for utvelging av nettsteder er derfor utvalget av enheter. Vi må også håndtere det forhold at mange enheter har flere nettsteder, mens noen deler sitt nettsted med andre offentlige organer. Størrelsen på utvalget kan enkelt beregnes basert på befolkningen i hvert land.

Dataene vi samlet inn i piloten, er egnet til en presentasjon av

• antall nettsteder som kontrolleres i dybdekontrollen og den forenklede kontrollen
• antall nettsteder fra hver kategori offentlig organ / forvaltningsnivå
• geografisk fordeling av nettstedseiere basert på deres beliggenhet

I et lite utvalg som piloten er det ikke relevant å kommentere representativitet og fordeling. I en faktisk kontroll må vi kunne beskrive hvor representativt utvalget av enheter er, særlig når det gjelder forvaltningsnivå og geografisk beliggenhet. Geografisk balanse gjelder særlig for de lokale og regionale organene. De statlige og offentligrettslige organene ligger i mange tilfeller i Oslo, men tilbyr riksdekkende tjenester.

Tjenesteområde er litt mer komplisert. Tjenesteområde kan av og til være relevant på enhetsnivå, og i andre tilfeller på nettstedsnivå (f.eks. dersom et offentlig organ tilbyr en rekke tjenester og har flere nettsteder). Vi har ikke en formell gruppering som grunnlag for utvelging på grunnlag av tjenesteområde, men vi vil sikre at alle tjenesteområder er representert i utvalget.

Vi kan også presentere hvilke tjenesteområder som er inkludert i kontrollen. En kombinasjon av institusjonell sektor- og næringsgruppering kan være nok til å bestemme typen tjeneste som enheten tilbyr, særlig for den forenklede kontrollen. For dybdekontrollen må vi gjennomføre en mer omfattende kontroll av det faktiske innholdet på enhetens nettsted.

En kort oversikt over dataene som er vesentlige å presentere i rapporten, finnes i tabellen nedenfor.

I en faktisk kontroll trengs flere observasjoner. I det minste vurderer vi det som viktig å gi en beskrivelse av hvordan fordelingen blant forvaltningsnivåer i utvalget var sammenlignet med fordelingen av utvalget av offentlige organer. Dette er viktig for å generalisere resultatene av kontrollen.

7.1.2 Utvelgingsmetoden

Vi har tolket dette spørsmålet dithen at vi skal dokumentere hvilke nettløsninger

• som må velges i dialog med berørte parter
• som har vært inkludert ved tidligere kontroll

Dataene som er vesentlige for rapportering, er beskrevet i kapittel 4.2.2. Som nevnt i kapittel 6.2 var ikke dialog med berørte parter, omfattet av piloten. Det er heller ikke kommentarer om tidligere kontroll som er relevant for piloten.

I en faktisk kontroll vil data imidlertid bli samlet inn som beskrevet i kapittel 4.2 for å rapportere kontroll, i samsvar med kravene i direktivet og tilsvarende gjennomføringsbeslutning.

Selv om det ikke er uttrykkelig påkrevd, vil en faktisk kontrollrapport også beskrive hvilken metode og hvilke datakilder vi brukte da vi

• først gjorde et utvalg av enheter og
• deretter valgte det tilknyttede nettstedet for kontroll

Utvelgingsmetoden, jf. kapittel 5.1 og 5.2, vil påvirke i hvilket omfang resultatene kan generaliseres. Derfor er dette en viktig del av en kontrollrapport.

7.1.3 Suksesskriteriene inkludert i den forenklede kontrollen

Utvelgingen av suksesskriterier for piloten var begrenset til ACT-regler implementert i verktøyene da testingen ble utført (januar/februar 2020). Vi inkluderte derfor i alt 19 ACT-regler i piloten. Dette gjelder både den forenklede kontrollen og dybdekontrollen. WAI-Tools-prosjektet er i utvikling, og målet er å utvikle 70 ACT-regler innen utgangen av oktober 2020.

ACT-reglene er tilordnet suksesskriteriet. Alle suksesskriteriene er tilordnet tilsvarende retningslinjer og prinsipper i WCAG 2.1. Dessuten er disse suksesskriteriene også tilordnet brukers tilgjengelighetsbehov (Functional Performance Statements) som beskrevet i standarden. I piloten dekket vi sju av de ni av brukers tilgjengelighetsbehovene (Functional Performance Statements) ved hjelp av de tilgjengelige verktøyene og implementeringene.

Dataene som ble samlet inn om kravene som beskrevet i kapittel 6.4, er tilstrekkelige og egnet til utvelging av suksesskriterier i pilotrapporteringen i samsvar med direktivet. Dataene presenteres i tabellen.

P angir en primærrelasjon med brukers tilgjengelighetsbehov, mens S angir en sekundærrelasjon.

7.1.4 En kartlegging av metoder og tester for å identifisere ikke-samsvar og verifisere samsvar

I piloten brukte vi de samme metodene, testene og verktøyene for både dybdekontrollen og den forenklede kontrollen. Alle testene ble utført ved hjelp av automatisk testing. I en faktisk kontroll vil vi bruke en kombinasjon av automatiske, semi-automatiske og manuelle metoder. Kontrollrapporten vil redegjøre ytterligere for dette, både for dybdekontrollen og den forenklede kontrollen.

Tabellen nedenfor presenterer relasjonen mellom WCAGs prinsipper, retningslinjer, suksesskriterier og ACT-regler.

Som nevnt i kapittel 6.5.4 trenger vi en nokså detaljert beskrivelse av hvordan og hva verktøyene tester i henhold til hvert suksesskriterium.

Etter vår mening må vi også se på tolkningen av suksesskriteriene som testreglene er basert på. Dette vil gi oss viktig informasjon om i hvilket omfang hvert suksesskriterium i en kontroll er omfattet av disse testreglene.

Dette er ikke omfattet av piloten, men omfattet av et annet prosjektresultat i WAI-Tools-arbeidspakke 2, som Digitaliseringsdirektoratet er ansvarlig for. Dokumentet «WCAG tolkning og testregel dokumentasjon» dokumenterer tolkningen av suksesskriteriene som er underforstått i ACT-reglene, og vil være vår hovedkilde til en vurdering av i hvilket omfang hvert suksesskriterium er dekket av kontrollen.

7.2 Spørsmål som skal besvares om resultatene

Vi identifiserte tre hovedspørsmål som skal besvares om kontrollresultatene:

1. Hvordan er generell samsvarsstatus med tilgjengelighetskravene i direktivet?
   1. Hvordan er samsvarsnivået for nettstedene i hver kategori av offentlige organer (statlige, regionale, lokale og offentligrettslige organer)?
   2. Til senere kontroll. Hvordan er utviklingen over tid når det gjelder generelt samsvar med kravene i direktivet?
2. Hvordan er generell samsvarsstatus med hvert tilgjengelighetskrav (suksesskriterium)?
   1. Vær særlig oppmerksom på suksesskriteriene der ikke-samsvar er påvist, og i hvilket omfang ikke-samsvar forekommer.
   2. Vær særlig oppmerksom på hvilke av brukers tilgjengelighetsbehov som er knyttet til suksesskriterier med (hyppig) ikke-samsvar.
3. Hvordan er samsvarsstatus for hver av de enkelte nettløsningene som kontrolleres?
   1. Antallet testsider med ikke-samsvar bør rapporteres.
   2. Resultatene bør også spesifiseres per krav/suksesskriterium, per testside der ikke-samsvar påvises.

Merknad: Alle resultatene skal spesifiseres for hver kontrollmetode, forenklet og dybde.

7.2.1 Generell samsvarsstatus

På grunnlag av standarden (som nevnt i kapittel 4.1.2) skjer kontrollen for samsvar eller ikke-samsvar på sidenivå. For at en nettløsning skal oppfylle kravene i direktivet, må alle testede sider samsvare.

En vurdering av generell samsvarsstatus er derfor basert på testresultatene på sidenivå. Det generelle samsvarsnivået kan beregnes på følgende måte:

En beregning som presentert i tabellen ovenfor vil ikke skille mellom nettsteder som er svært nært samsvar, og nettsteder med omfattende tilgjengelighetshindringer. Erfaring med tidligere kontrollarbeid basert på eksisterende norske forskrifter angir at nesten alle nettstedene vil være kategorisert som «delvis samsvar», tross vesentlige variasjoner i resultatene.

For å illustrere presenterer vi dataene bare for nettstedet som vi dybdekontrollerte.

• Antall testede sider: 9
• Antall sider med forekomst av ikke-samsvar: 9
• Samsvarsstatusen er: Ikke-samsvar
• Prosentandelen testede sider som har fullt samsvar: 0 %

Hvis kategoriene fullt samsvar, delvis samsvar og ikke-samsvar brukes, vil vi ikke avdekke

• variasjonene og antallet tilgjengelighetshindringer og/eller
• hvilke tilgjengelighetshindringer som påvises i kontrollen og
• brukssituasjoner som er særlig berørt

Vi trenger derfor en litt mer detaljert (men fortsatt enkel) måte å vurdere samsvarsnivået på. Et alternativ er å beregne samsvarsnivået på elementnivå. Dette er en mer nyansert metode. Et eksempel:

• telle antall testede elementer per identifisert suksesskriterium, spesifisert etter resultatet av hvert testet element (samsvar, brudd, ikke forekomst og kanskje, ikke testbar)
• beregne samsvarsnivået som prosentandel testede elementer som oppfyller kravene. Dette kan også legge til rette for referansemåling og måling av trender i samsvarsnivå.

Ettersom vi ikke klarte å beregne samsvarsstatus for nettstedene som ble testet i den forenklede kontrollen, har vi ikke grunnlag for å beregne samsvarsnivået som ble målt i piloten. Vi har derfor ikke data for å sammenligne resultater mellom nettsteder og kategorier av offentlige organer.

7.2.2 Overordnet samsvarsstatus etter suksesskriterium

Beregningen av samsvarstatus per suksesskriterium er også basert på testresultater på testsidenivå. Som nevnt ovenfor har vi testresultater bare på sidenivå for nettstedet i dybdekontrollen.

Resultatene vises i tabellen. For å illustrere har vi brukt resultatene fra bare ett av verktøyene i piloten. For å gjøre det enklere forutsetter vi at alle de ni sidene ble testet på hvert suksesskriterium.

Forutsatt at sider viser samsvar dersom ikke-samsvar ikke påvises, presenterer vi følgende resultater fra piloten:

Dette gir et litt mer nyansert bilde av samsvarsstatus som blir målt i piloten:

• Vi påviste ikke-samsvar for 4 av de 13 suksesskriteriene, noe som innebærer samsvar med 9 av de 13 suksesskriteriene, lik 69 prosent.
• Vi målte delvis samsvar for 3 av de 13 suksesskriteriene, lik 23 prosent.
• Vi påviste ikke-samsvar på alle de testede sidene for et av suksesskriteriene (1.1.1 Ikke-tekstlig Innhold), lik 8 %.

Suksesskriteriet som vi påviste ikke-samsvar for, påvirker brukers tilgjengelighetsbehov i tabellen nedenfor.

Resultatene må analyseres videre i en faktisk kontroll. For eksempel er et viktig resultat at ikke-samsvar er påvist for suksesskriterium 1.1.1 på sju av de i alt ni testsidene, kombinert med det forhold at dette suksesskriteriet er ment å dekke en rekke av brukers tilgjengelighetsbehov. Dette kan fungere som et eksempel på et funn «når det gjelder hyppig eller kritisk ikke-samsvar». Tilsvarende bør vi også gjennomføre ytterligere analyse av resultatene for suksesskriterium 1.3.1 og 4.1.2.

Som nevnt er pilotdataene altfor begrenset til å bli brukt til analyse og kan bare fungere som et eksempel i denne rapporten. For å generalisere resultatene må vi legge fram data som viser testresultater for unike sider, også for den forenklede kontrollen. Dessuten må testresultatene spesifiseres for hvert suksesskriterium for å svare på forskningsspørsmålene. Dessuten bør det vurderes å beregne resultatene på elementnivå.

7.2.3 Samsvarstatusen for de individuelle nettløsningene

Beregningen av samsvarsnivået på hvert nettsted er også basert på testresultater på testsidenivå. Som nevnt ovenfor har vi testresultater bare på sidenivå for nettstedet i dybdekontrollen.

I en faktisk kontroll kan man beregne samsvarsnivået basert på hva som presenteres i kapittel 7.2.1 og 7.2.2:

• prosentandelen (eller andelen) av de testede sidene på nettstedet som viser fullt samsvar med alle suksesskriteriene i kontrollen
• prosentandelen suksesskriterier i kontrollen som alle de testede sidene på nettstedet samsvarer med

Ettersom vi ikke har informasjon om antallet testede elementer på hvert nettsted, er det ikke mulig å beregne samsvarsnivået på elementnivå.

Samsvarsnivået som ble beregnet for nettstedet som ble dybdekontrollert i piloten, presenteres i tabellen.

Slik det framgår av tabell 33 (kapittel 7.2.2), kan resultatene videre beskrives per suksesskriterium, basert på kunnskap om hvor mange sider som er testet mot hvert individuelt suksesskriterium.

For å gi de offentlige organene nødvendige data for å rette opp elementer med brudd må vi trekke ut testresultater på elementnivå, jf. kapittel 6.5.2. Det ville være en stor fordel om resultatene på elementnivå lar oss påpeke nøyaktig hvilke elementer som må rettes opp.

7.3 Læringspunkter

Det inngikk ikke i pilotens omfang å produsere testdata i nødvendig mengde for å utføre analyse og rapportering slik direktivet beskriver. Sammendraget presenterer derfor våre erfaringer med å fastsette et datasett som var egnet til analyse og rapportering. Vi vil også legge fram våre tanker og refleksjoner om beregningen av samsvarsnivå og andre spørsmål som etter vår mening trenger å presiseres.

Funnene er sammenfattet nedenfor:

• Når det gjelder spørsmålene om
  • utvalg av enheter og nettsteder
  • utvelgingsmetode
  • suksesskriterier og testmetoder
  • brukers tilgjengelighetsbehov
• Sammen med testresultatene er dataene om kontrollen avgjørende for å svare på forskningsspørsmålene.

Vurderes dataene som samles inn i piloten, som tilstrekkelig og egnet til å utføre analysen som kreves for rapportering.

Videre refleksjoner om analyse og rapportering:

• Vi trenger en dokumentert metode til å velge ut enheter og nettsteder og i størst mulig grad en oversikt over utvalget av enheter og nettsteder. Dette er for å danne et grunnlag for å vurdere i hvilket omfang kontrollen av resultater kan generaliseres. Vi trenger også en konsekvent måte å velge ut testsider på. Dette er avgjørende både for å sammenligne resultater mellom nettsteder, kategoriene av offentlige organer og resultater fra forskjellige kontrollperioder.
• Basert på kravene til rapportering trenger kontrollorganene en metode og en skala for å uttrykke kvantifiserte resultater av kontrollaktiviteten, herunder kvantitativ informasjon om tilgjengelighetsnivået.
• De kvantifiserte testresultatene etter suksesskriterium og tilordningen til brukerens tilgjengelighetsbehov danner grunnlaget for en kvalitativ analyse av resultatet av kontrollen, særlig funnene når det gjelder hyppig eller kritisk ikke-samsvar. Vi trenger derfor en metode til å utføre den kvalitative analysen som beskrevet i direktivet og en mal for å rapportere til EU.
• Det er også et behov for en presisering av begrepet «samsvarsnivå» (eller samsvarsstatus). Kontrollorganene trenger en (enkel) metode og en skala for å uttrykke kvantifiserte resultater av kontrollaktiviteten, herunder kvantitativ informasjon om tilgjengelighetsnivået.
• I henhold til standarden er grunnlaget for å beregne samsvarsnivået testresultater på sidenivå. Vi trenger derfor en måte å trekke ut aggregerte testdata direkte fra verktøyene på som viser både antallet testede sider og antallet unike sider som underkjennes for hvert suksesskriterium. Dette gjelder både den forenklede kontrollen og dybdekontrollen.
• På grunnlag av standarden kan vi beregne samsvarsnivået som prosentandelen av de testede sidene som samsvarer fullt ut med alle de inkluderte suksesskriteriene, angitt etter dybdekontroll og forenklet kontroll.
• Vi stiller også spørsmål ved muligheten til å beregne samsvarsnivå på elementnivå. Et eksempel:
  • telle antall testede elementer per identifisert suksesskriterium, spesifisert etter resultatet av hvert testet element (samsvar, brudd, ikke forekomst og kanskje, ikke testbar)
  • beregne samsvarsnivået som prosentandel testede elementer som oppfyller kravene. Dette kan også legge til rette for referansemåling og måling av trender i samsvarsnivå.
• Hver av tilnærmingene som skisseres ovenfor har ulike fordeler og ulemper, som å ikke ta høyde for alvorlighetsgrad av feil. For eksempel, dersom bare 1 av 99 bilder på en side mangler tekstalternativ, vil likevel det ene bildet føre til at hele siden oppfattes som ikke brukbar. W3Cs forskningsrapport om «Web Accessibility Metrics», utforsker ulike tilnærminger for å måle nivået av tilgjengelighet.
• Basert på samsvarsnivået på nettstedsnivå kan gjennomsnitt eller aggregert samsvarsstatus for alle nettstedene i hver kontroll beregnes, spesifisert etter dybdekontroll og forenklet kontroll.
• Lignende beregninger bør også utføres
  • etter kategori (forvaltningsnivå) av offentlige organer
  • etter suksesskriterium
• Ettersom det er flere måter å beregne samsvarstatusen, er det et behov for en presisering av begrepet «samsvar» og hvordan det bør måles.
• Det er også et behov for å rapportere testresultater som identifiserer hvilke elementer på de testede sidene som ikke er i samsvar. Det er for at nettstedseierne skal få støtte i arbeidet med å rette opp elementer med brudd.

Vedlegg: Verktøy som er brukt i piloten

I dialog med hver av de tre prosjektpartnerne Deque, FCID og Siteimprove besluttet vi å bruke følgende verktøy:

ACT-regler utviklet i prosjektet ble implementert i verktøyene. Verktøyene ble brukt i det aktuelle utviklingstrinnet på tidspunktet for testing i piloten. FCIDs QualWeb Core ble ikke brukt i den forenklede kontrollen, ettersom verktøyet ikke hadde en «crawler».

Prosjektpartnerne (Deque, FCID og Siteimprove) ga oss svar på følgende spørsmål:

Svarene fra prosjektpartnerne (Deque, FCID og Siteimprove) presenteres i tabellen nedenfor.

Referanser

• ACT Rules Community (2020). ACT-implementeringer. Hentet 03.04.2020, fra https://act-rules.github.io/pages/implementations/overview/
• ACT Rules Community (2020). Regler. Hentet 03.04.2020, fra https://act-rules.github.io/rules/
• Altinn (2019). Obligatoriske og frivillige registre. Hentet 17.03.2020, fra https://www.altinn.no/starte-og-drive/starte/registrering/obligatoriske-og-frivillige-registre/
• Brønnøysundregistrene (2019). Om Enhetsregisteret. Hentet 17.03.2020, fra https://www.brreg.no/om-oss/registrene-vare/om-enhetsregisteret/
• ETSI, CEN og CENELEC (2018). Europeisk standard EN 301 549 V2.V2.1.2 (2018-08) Tilgjengelighetskrav for IKT-produkter og -tjenester
• Europakommisjonen (2018) Kommisjonens gjennomføringsbeslutning (EU) 2018/1523 av 11. oktober 2018 om fastsettelse av en mal for tilgjengelighetserklæringer i samsvar med europaparlaments- og rådsdirektiv (EU) 2016/2102 om tilgjengeligheten av offentlige organers nettsteder og mobilapplikasjoner
• Europakommisjonen (2018) Kommisjonens gjennomføringsbeslutning (EU) 2018/1524 om fastsettelse av en kontrollmetode og ordninger for medlemsstatenes rapportering i samsvar med europaparlaments- og rådsdirektiv (EU) 2016/2102 om tilgjengeligheten av offentlige organers nettsteder og mobilapplikasjoner
• Europakommisjonen (2018) Kommisjonens gjennomføringsbeslutning (EU) 2018/2048 av 20. desember 2018 om den harmoniserte standarden for nettsteder og mobilapplikasjoner utarbeidet til støtte for europaparlaments- og rådsdirektiv (EU) 2016/2102
• Europakommisjonen (2017) Støtteavtale nummer 780057 – WAI-Tools
• Europakommisjonen 2016). Europaparlaments- og rådsdirektiv (EU) 2016/2102 av 26. oktober 2016 om tilgjengeligheten av offentlige organers nettsteder og mobilapplikasjoner
• Digitaliseringsdirektoratet (2019). Digitale barrierar på norske nettstader 2018. Hentet 17.03.2020, fra https://www.uutilsynet.no/statusmalingar/digitale-barrierar-pa-norske-nettstader-2018
• Digitaliseringsdirektoratet (2020). Tilsynsrapporter. Hentet 03.04.2020, fra https://www.uutilsynet.no/tilsynsrapporter/tilsynsrapporter
• Regjeringen.no (2014). Statlige virksomheter, selskaper og andre organer. Hentet 17.03.2020, fra https://www.regjeringen.no/no/tema/statlig-forvaltning/forvaltningsutvikling/statlige-virksomheter-selskaper-og-andre-organer/id2344647/
• Statistisk sentralbyrå (2012). Gruppering av institusjonell sektor. Hentet 17.03.2020, fra https://www.ssb.no/klass/klassifikasjoner/39
• Statistisk sentralbyrå (2009). Standard for næringsgruppering. Hentet 17.03.2020, fra https://www.ssb.no/klass/klassifikasjoner/6
• Statistisk sentralbyrå (2020). Befolkning. Hentet 03.04.2020, fra https://www.ssb.no/befolkning/statistikker/folkemengde
• W3C, Web Accessibility Initiative (2020). Web Accessibility Initiative - Advanced Decision Support Tools for Scalable Web Accessibility Assessments (WAI-Tools) Project. Hentet 03.04.2020, fra https://www.w3.org/WAI/about/projects/wai-tools/