WAI-Tools dokumentasjon av pilotkontroll

Som en del av WAI-Tools-prosjektet, har Digitaliseringsdirektoratet gjennomført en pilotkontroll på et utvalg av fire offentligrettslige organer og deres nettsteder basert på kravene om kontroll som følger av Direktivet (EU) 2016/2102.

08. des 2020

På denne siden

    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: Kontrollprosessen består av fire trinn. Trinn én er planlegging og utforming, og handler om å identifisere forskningsspørsmål og definere omfang og metoder. Trinn to er utvelging av enheter, nettsteder og nettsider. Trinn tre er datainnsamling, og handler om å utføre test, og å samle inn testdata og andre data. Trinn fire er analyse og rapportering, og handler om å gjøre kvalitativ og kvantitativ analyse, i tillegg til rapportering.
    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:

    "En side oppfyller et WCAG-suksesskriterium når suksesskriteriet ikke vurderes til brudd når det anvendes på siden. Dette tilsier at dersom suksesskriteriet setter vilkår for en spesifikk funksjon og den spesifikke funksjonen ikke forekommer på siden, oppfyller siden suksesskriteriet."

    EN 301 549-standarden

    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:

    "Samsvar oppnås enten når forutsetningen er sann og den tilhørende testen [i vedlegg C i EN 301 549] godkjennes, eller når forutsetningen er usann (dvs. forutsetningen er ikke oppfylt eller ikke gyldig)."

    EN 301 549-standarden

    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

    Tabell 1: Eksempel på bestemmelse av samsvar
    Type vurdering Tilsyn
    Forutsetninger 1. Ikt er en side
    Framgangsmåte 1. Kontroller at siden ikke får underkjent WCAG 2.1 Suksesskriterium 1.1.1 ikke-tekslig innhold
    Resultat

    Samsvar: Kontroller at 1 er sann

    Brudd: Kontroller at 1 er usann

    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)

    Tabell 2: Data om enheten (offentlig organ)
    Dataelement Beskrivelse Kilde til datakrav
    Enhetens navn Enhetens navn
    Organisasjonsnummer Nummer fra Enhetsregisteret
    Adresse (geografisk beliggenhet) Full adresse, som angir enhetens geografiske plassering Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.2.1
    Institusjonell sektorgruppering Nummer og beskrivelse fra Enhetsregisteret

    Det er ikke nødvendig i henhold til direktivet å samle inn disse dataene, men

    institusjonell sektorgruppering og

    standard næringsgruppering

    er nyttig for å bestemme

    forvaltningsnivået og

    tjenesteområdet

    Standard næringsgruppering Nummer og beskrivelse fra Enhetsregisteret
    Forvaltningsnivå Forvaltningsnivået enheten tilhører (statlig, regionalt (NUTS), lokalt (LAU) eller offentligrettslig organ). Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.2.2

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

    Tabell 3: Data om ikt-løsning (nettsted eller mobilapplikasjon)
    Dataelement Beskrivelse Kilde til datakrav
    Adresse Nettadresse URL eller adresse i mobilapplikasjonsbutikk
    Ikt-navn Navn eller tittel på ikt-løsningen
    Ikt-type Type ikt-løsning (nettsted, mobilapplikasjon, muligens også spesifisere intranett og ekstranett) Direktiv (EU) 2016/2102, artikkel 1. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1
    Tjenesteområde Spekteret av tjenester som enheten leverer, f.eks. sosialomsorg, helse, transport, utdanning, sysselsetting og beskatning, miljøvern, fritid og kultur, bolig og nærmiljø, offentlig orden og sikkerhet eller andre relevante typer grupperinger. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.2.3
    Type tjenester (bare dybde) En liste over individuelle tjenester som ikt-løsningen leverer. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (3.2)
    Ofte lastet ned? For eksempel antall nedlastinger fra Google Play og App Store. Dette gjelder ikke for nettsteder. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.3.2
    Operativsystem Operativsystem som kreves for å kjøre mobilappen (f.eks. Android, iOS eller annet). Dette gjelder ikke for nettsteder. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.3.3
    Siste versjon Versjonsnummer i mobilappens siste oppdaterte versjon. Dette gjelder ikke for nettsteder. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.3.4
    Prioritert av nasjonale berørte parter? Har relevante berørte parter angitt ikt-løsningen som noe som skal prioriteres for kontroll? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.2.4
    Sist kontrollert Dato for når ikt-løsningen sist ble kontrollert og typen kontroll. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 2.4

    4.2.3 Data om siden (nettside eller skjerm i mobilapplikasjon)

    Tabell 4: Data om siden (nettside eller skjerm i mobilapplikasjon)
    Dataelement Beskrivelse Kilde til datakrav
    Sidetype

    Dybde:

    Type side, f.eks. startside, innloggingsside, nettstedkart, side med kontaktopplysninger, hjelpeside og side med juridisk informasjon, tilgjengelighetserklæring eller retningslinjer for tilgjengelighet, side som inneholder tilbakemeldingsfunksjonen, annen eller tilfeldig utvalgt side.

    Forenklet:

    For forenklet kontroll må bare startsiden spesifiseres. De andre testsidene trenger ikke å kategoriseres.

    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (3.2)
    Type tjeneste (bare dybde) Identifisering av den individuelle tjenesten nettsiden, eller skjermen i mobilapplikasjonen, er knyttet til. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (3.2)
    Prosess (bare dybde) Indikasjon av om siden er del av en prosess og kort beskrivelse av prosess Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.2.2
    Adresse Nettadresse eller annen beskrivelse av sidens plassering

    4.2.4 Data om nedlastbart dokument

    Merknad: Dette avsnittet gjelder bare for dybdekontroll.

    Tabell 5: Data om nedlastbart dokument
    Dataelement Beskrivelse Kilde til datakrav
    Type tjeneste Identifikasjon av den individuelle tjenesten som det nedlastbare dokumentet er knyttet til. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (3.2)
    Prosess Indikasjon av om det nedlastbare dokumentet er del av en prosess og kort beskrivelse av prosessen Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.2.2

    4.2.5 Data om kravet (WCAG-suksesskriterium)

    Tabell 6: Data om kravet (WCAG-suksesskriterium)
    Dataelement Beskrivelse Kilde til datakrav
    Standard Standardens nummer og navn Artikkel 6 i direktiv (EU) 2016/2102
    Versjon Standardens versjonsnummer. Artikkel 6 i direktiv (EU) 2016/2102
    Krav Kravets nummer, navn og samsvarsnivå i standarden Artikkel 6 i direktiv (EU) 2016/2102
    Prinsipp i WCAG Informasjon om det tilhørende hovedprinsippet i WCAG (mulig å oppfatte, mulig å betjene, forståelig, robust). Direktiv (EU) 2016/2102, artikkel 6. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.3.2
    Retningslinje i WCAG Informasjon om tilhørende retningslinje i WCAG.
    Suksesskriterium Suksesskriteriets nummer og navn i WCAG 2.1 nevnt i standarden EN 301 549 V2.1.2
    Brukers tilgjengelighetsbehov

    Tilordning til erklæringer om funksjonsytelse (brukers tilgjengelighetsbehov) i EN 301 549.

    Det er bruk uten syn, bruk med begrenset syn, bruk uten fargesyn, bruk uten hørsel, bruk med nedsatt hørsel, bruk uten taleevne, bruk med motorisk funksjonsnedsettelse eller begrenset styrke, behov for å begrense faktorer som kan utløse anfall på grunn av lysfølsomhet, bruk med kognitiv funksjonsnedsettelse.
    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.3.2

    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å.

    Tabell 7: Data om testresultatet for testet side
    Dataelement Beskrivelse Kilde til datakrav
    Side eller dokument Nettadresse eller annen identifikasjon av nettside (for nettsted) eller skjerm (for mobilapplikasjon) som testes.
    Krav Kravets nummer, navn og samsvarsnivå i standarden som ble testet. Artikkel 6 i direktiv (EU) 2016/2102
    Testmetode Informasjon om testmetode, testregler, verktøy, testmodus (automatisk, semi-automatisk, manuell) og når testmetoden sist ble oppdatert. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg II nr. 2.3 bokstav b, nr. 1.2.4 og 1.3.3
    Samsvarstatus

    Status tilsvarende samsvar eller ikke-samsvar for den testede siden basert på resultatet av de testede elementene.

    Elementer med brudd fører til ikke-samsvar, mens alle samsvarende, ikke forekommende eller ikke testbare elementer fører til samsvar.
    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 5
    Elementer med brudd Antall elementer med brudd som er funnet på siden. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 7
    Testdato Dato da testen ble utført.
    Testet av

    Navn på enheten eller kontrollorganet som utførte testen.

    Vi registrerer dette dersom vi i (en senere versjon av) tilgjengelighetserklæringen vil samle inn testdataene fra enhetene og derfor må kunne identifisere hvilke tester som er utført av enheten, og hvilke som utføres av kontrollorganet.
    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.2.5

    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.

    Tabell 8: Data om testresultatet for testet element
    Dataelement Beskrivelse Kilde til datakrav
    Testet element Identifikasjon av det aktuelle elementet som er testet på siden. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 7
    Side eller dokument Nettadresse URL eller annen identifikasjon av nettside (for nettsted) eller skjerm (for mobilapplikasjon) som testes.
    Krav Testet krav (suksesskriterium i WCAG 2.1).
    Resultat

    Utfall av hver enkel test:

    samsvar

    brudd

    ikke forekomst

    ikke testbar

    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 7
    Testdato Dato da testen ble utført
    Testet av

    Navn på enheten eller kontrollorganet som utført testen.

    Vi registrerer dette dersom vi i en senere versjon av tilgjengelighetserklæringen vil samle inn testdataene fra enhetene og derfor må kunne identifisere hvilke tester som er utført av enheten, og hvilke som utføres av kontrollorganet.

    Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.2.5

    4.2.8 Data om kontroll og rapportering

    Tabell 9: Data om kontroll og rapportering
    Dataelement Beskrivelse Kilde til datakrav
    Kontrollmetode Typen kontroll som er utført (forenklet eller dybde) Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 5
    Kontrollerte ikt-løsninger Hvilke typer ikt-løsninger er kontrollert (nettsteder eller mobilapplikasjoner) Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 8 nr. 1
    Rapporteringsperiodens start Rapporteringsperiodens startdato. Direktiv (EU) 2016/2102, artikkel 8 nr. 4
    Rapporteringsperiodens slutt Rapporteringsperiodens sluttdato. Direktiv (EU) 2016/2102, artikkel 8 nr. 4
    Kontrollperiodens start Kontrollperiodens startdato. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 2 nr. 2, vedlegg II nr.2.1 bokstav a
    Kontrollperiodens slutt Kontrollperiodens sluttdato. Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 2 nr. 2, vedlegg II nr. 2.1 bokstav a
    Organ ansvarlig for kontroll Myndighetsorganet med ansvar for kontrollen Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 2 nr. 2, vedlegg II nr. 2.1 bokstav b
    Testede krav Kravene i EN 301 549 som er verifisert/kontrollert i kontrollen Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I nr. 1.3.1
    Utvalgsstørelse for forenklet kontroll Antall nettsteder som kontrolleres i forenklet kontroll Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (2.1)
    Utvalgsstørrelse for dybdekontroll Antall nettsteder som kontrolleres i dybdekontroll Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (2.1)
    Utvalgsstørrelse for dybdekontroll av mobilapplikasjoner Antall mobilapplikasjoner som kontrolleres i dybdekontroll Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg I (2.1)

    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:

    Tabell 10: ACT-regler som er brukt i piloten
    Suksesskriterium ACT-regel-ID ACT-regelnavn
    1.1.1 23a2a8 Bildet har tilgjengelig navn
    1.1.1, 4.1.2 59796f Bildeknappen har tilgjengelig navn
    1.2.2 eac66b Lydinnhold i videoelement har tilgjengelig alternativ
    1.2.3 c5a4ea Visuelt innhold i videoelement har tilgjengelig alternativ
    1.3.1, 4.1.2 6cfa84 Elementet med aria-hidden har ikke fokuserbart innhold
    1.3.4 b33eff Orientering av siden er ikke begrenset med CSS-transform egenskap
    1.3.5 73f2c2 Autocomplete-attributt har gyldig verdi
    2.2.1 (2.2.4, 3.2.5 på nivå AAA) bc659a Meta elementet har ingen oppdateringsforsinkelse
    2.4.2 2779a5 HTML-siden har tittel
    2.4.4, 4.1.2 (2.4.9 på nivå AAA) c487ae Lenken har tilgjengelig navn
    3.1.1 b5c3f8 HTML-siden har lang-attributt
    3.1.1 5b7ae0 HTML-sidens lang- og xml:lang-attributter har samsvarende verdier
    3.1.1 bf051a HTML-sidespråket er gyldig
    3.1.2 de46e4 Elementet innenfor organet har gyldig lang-attributt
    4.1.1 3ea0c8 Id-attributtverdien er unik
    4.1.2 97a4e1 Knappen har tilgjengelig navn
    4.1.2 4e8ab6 Elementet med role-attributt har nødvendige tilstander og egenskaper
    4.1.2 e086e5 Skjemakontrollen har tilgjengelig navn
    4.1.2 cae760 Iframe-elementet har tilgjengelig navn

    *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.

    Tabell 11: Antallet nettsteder og mobilapplikasjoner som skal kontrolleres
    Nettsteder År 1 og 2 Fra år 3 og deretter
    Forenklet 182 236
    Dybde 19 22

    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:

    Tabell 12: Mulige løsninger for å bestemme størrelsen på utvalget i den forenklede kontrollen
    Utvelgingsmetode Fordeler Ulemper
    Et fastsatt antall sider per nettsted, f.eks. 1 000 nettsider eller alle nettsider. Dersom nettstedet består av mindre enn 1 000 nettsider, vil alle nettsidene være en del av utvalget. «Crawl»-en er fastsatt til et fast antall, og det er ikke behov for å bestemme størrelsen på nettstedet. Nettstedets størrelse og kompleksitet vurderes ikke ved utvelging av antallet testsider.
    Fastsatte intervaller av nettsider, bestemt ved nettstedets størrelse.

    For et lite nettsted vil X sider bli valgt ut.

    For et mellomstort nettsted vil Y nettsider bli valgt ut.

    For et stort nettsted vil Z nettsider bli valgt ut.

    Nettstedene er klassifisert, og det er et nærmere forhold mellom nettstedets størrelse (og kompleksitet) og antallet utvalgte nettsider.

    Hele nettstedet må gjennomgås med en «crawler» for å bestemme nettstedets størrelse og kompleksitet.

    Intervallene må fastsettes.
    En prosentandel samlet antall nettsider på nettstedet. Det er en fastsatt prosentandel av nettsider som er testet for alle kontrollerte nettsteder, noe som gir en jevnere tilnærming til nettstedenes størrelse (og kompleksitet).

    Hele nettstedet må gjennomgås med en «crawler» for å bestemme nettstedets størrelse og kompleksitet.

    Prosentandelen må fastsettes.

    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.

    Tabell 13: Innsamling av data om enheten (offentlig organ)
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Enhetens navn Enhetsregisteret

    I piloten hadde vi et forhåndsdefinert utvalg av enheter, og navnet på enhetene var allerede kjent.

    I en faktisk kontroll vil vi ta et utvalg av enheter fra Enhetsregisteret.
    Organisasjonsnummer Enhetsregisteret Søk etter enheten i registeret.
    Adresse (geografisk beliggenhet) Enhetsregisteret Søk etter enheten i registeret.
    Institusjonell sektorgruppering Enhetsregisteret Søk etter enheten i registeret.
    Standard næringsgruppering Enhetsregisteret Søk etter enheten i registeret.
    Forvaltningsnivå Enhetsregisteret Institusjonell sektorgruppering tilbyr informasjon om enheter, noe som gjør det mulig å plassere enheten i en av de fire kategoriene beskrevet i direktivet.

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

    Tabell 14: Data som er samlet inn om enhetene (offentlige organer)
    Dataelement Statlig Regional (NUTS3) Lokal (LAU) Offentligrettsligorgan
    Enhetens navn NN Offentlig organ – statlig nivå NN Offentlig organ – regionalt nivå NN Offentlig organ – lokalt nivå NN Offentligrettslig organ
    Organisasjonsnummer 889 *** *** 817 *** *** 940 *** *** 960 *** ***
    Adresse (geografisk beliggenhet) NN NN NN NN
    Institusjonell sektorgruppering 6100 Statsforvaltning 6500 Kommuneforvaltning 6500 Kommuneforvaltning 3900 Statlige låneinstitutter mv.
    Standard næringsgruppering 84.120 Offentlig administrasjon tilknyttet helsestell, sosial virksomhet, undervisning, kirke, kultur og miljøvern 84.110 Generell offentlig administrasjon 84.110 Generell offentlig administrasjon 64.920 Annen kredittgiving
    Forvaltningsnivå Statlig Regional (fylke) Lokal (kommune) Offentligrettslig organ

    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.

    Tabell 15: Innsamling av data om ikt-løsninger (nettsteder)
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Ikt-adresse

    Enhetsregisteret, deretter

    internettsøk
    To av de fire offentlige organene hadde nettadresser oppført i Enhetsregisteret. For de andre søkte vi etter enhetens nettsted og undersøkte det for å bestemme adresse.
    Ikt-navn

    Enhetsregisteret og/eller

    internettsøk
    To av de fire offentlige organene hadde nettadresser oppført i Enhetsregisteret. For de andre søkte vi etter enhetens nettsted og undersøkte det for å bestemme navnet.
    Ikt-type Nettstedet I piloten inngikk bare nettsteder.
    Tjenesteområde

    Nettstedet i kombinasjon med

    Enhetsregisteret

    Vi brukte

    en kombinasjon av institusjonell sektorgruppering og næringsgruppering, og

    søkte på nettstedet

    for å bestemme hvilket tjenesteområde nettstedet kunne kategoriseres til.

    I piloten brukte vi listen over tjenesteområder angitt i gjennomføringsbeslutningen til kategorisering. Disse var sosialomsorg, helse, transport, utdanning, sysselsetting og beskatning, miljøvern, fritid og kultur, bolig og nærmiljø, offentlig orden og sikkerhet.

    Type tjenester (bare dybde) Nettstedet

    Vi hadde en dialog med det offentlige organet om hvilke tjenester det tilbød, og hvilke som var egnet til piloten.

    Dessuten søkte vi på nettstedet for å finne ut hvilke tjenester som tilbys.

    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:

    Tabell 16: Data som er samlet inn om ikt-løsningene (nettsteder)
    Dataelement Statlig Regional (NUTS3) Lokal (LAU) Offentligrettsligorgan
    Ikt-navn NN Offentlig organ på statlig nivå NN Offentlig organ på regionalt nivå NN Offentlig organ på lokalt nivå NN offentligrettslig organs nettsted
    Adresse www.***.no www.***.no www.***.no www.***.no
    Ikt-type Nettsted Nettsted Nettsted Nettsted
    Tjenesteområde Sosialomsorg, sysselsetting Helse, transport, utdanning, fritid og kultur. Sosialomsorg, helse, utdanning, fritid og kultur, bolig og nærmiljø. Utdanning.
    Type tjenester (bare dybde)

    Tjenestene som ble inkludert i piloten, var foreldreytelser og søknad om førerhund og tjenestehund.

    Merknad: Dette er bare et lite delsett av tjenestene som tilbys av nettstedet.
    Ikke relevant i forenklet kontroll. Ikke relevant i forenklet kontroll. Ikke relevant i forenklet kontroll.

    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.

    Tabell 17: Innsamling av data om sider
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Sidetype Nettsiden

    Dybde:

    Vi undersøkte innholdet på nettsiden for å kategorisere siden i et av eksemplene på kategorier som er beskrevet i gjennomføringsbeslutningen. Dette var for eksempel startside, innloggingsside, nettstedkart, side med kontaktopplysninger, hjelpeside og side med juridisk informasjon, tilgjengelighetserklæring eller retningslinjer for tilgjengelighet, side som inneholder tilbakemeldingsfunksjonen, annen eller tilfeldig utvalgt side.

    Forenklet:

    For forenklet kontroll må bare startsiden spesifiseres. De andre testsidene trenger ikke å kategoriseres.
    Type tjeneste (bare dybde) Nettsiden Vi hadde dialog med nettstedseieren og inspiserte siden for å undersøke hvilken tjeneste som enheten tilbød gjennom nettsiden.
    Prosess (bare dybde) Nettsiden Vi undersøkte siden for å identifisere om den hadde tegn på å være del av en prosess som omfattet flere sider. Slike indikasjoner var neste/forrige-knapper eller nummerering av sidene.
    Adresse Nettstedet/nettsiden Vi gjennomsøkte nettstedet for å finne nettsiden.

    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.

    Tabell 18: Sider i dybdekontrollen
    Sidetype Type tjeneste Prosess Adresse
    Startside Ikke anvendbart Ingen https://www.***.no/no/person
    Kontakt Ikke anvendbart Nei https://www.***.no/person/kontakt-oss/
    Hjelp Ikke anvendbart Nei https://www.***.no/no/***-og-samfunn/kontakt-***/teknisk-brukerstotte/hjelp-til-personbruker
    Tjeneste Søknad om førerhund og tjenestehund Ja https://www.***.no/soknader/nb/person/hjelpemidler-og-tilrettelegging/forerhund-og-servicehund#***100750
    Tjeneste Søknad om førerhund og tjenestehund Ja https://www.***.no/soknader/nb/person/hjelpemidler-og-tilrettelegging/forerhund-og-servicehund/***%2010-07.50/brev
    Tilgjengelighetserklæring Ikke anvendbart Nei https://www.***.no/no/***-og-samfunn/kontakt-***/teknisk-brukerstotte/nyttig-a-vite/tilgjengelighet-og-universell-utforming
    Tilbakemeldingsfunksjon Ikke anvendbart Nei https://www.***.no/person/kontakt-oss/tilbakemeldinger/feil-og-mangler
    Side med vesentlig forskjellig utseende Arbeidsavklaringspenger Nei https://www.***.no/no/Person/Arbeid/Arbeidsavklaringspenger
    Side med vesentlig forskjellig utseende Arbeidsavklaringspenger Nei https://www.***.no/no/person/arbeid/arbeidsavklaringspenger/arbeidsavklaringspenger-aap

    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:

    Tabell 19: Sider i den forenklede kontrollen
    Enhet Anslått størrelse Antall sider som er valgt ut til test – verktøy 1 Antall sider som er valgt ut til test – verktøy 2
    NN Offentlig organ – statlig nivå 24 600 sider (herunder 5 740 PDF-er) 912 991
    NN Offentlig organ – regionalt nivå 3 240 sider (herunder 1 510 PDF-er) 796 964
    NN Offentlig organ – lokalt nivå 26 500 sider (herunder 5 580 PDF-er) 948 979
    NN Offentligrettslig organ 2 630 sider (herunder 345 PDF-er) 991 999

    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.

    Tabell 20: Innsamling av data om kravene
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Standard Direktiv (EU) 2016/2102 og Kommisjonens gjennomføringsbeslutning (EU) 2018/2048 Vi brukte standarden som vises til i direktivet. På tidspunktet for gjennomføring av piloten var nyeste versjon av standarden som ble nevnt i Den europeiske unions tidende, versjon 2.1.2 av EN 301 549. I henhold til EN 301 549 v2.1.2 tilsvarer samsvar med nettkravene også samsvar med nivå AA i retningslinjer for tilgjengelig webinnhold (WCAG) 2.1.
    Versjon Direktiv (EU) 2016/2102 og Kommisjonens gjennomføringsbeslutning (EU) 2018/2048 Vi brukte standarden som vises til i direktivet. På tidspunktet for piloten var nyeste versjon av standarden som ble nevnt i Den europeiske unions tidende, versjon 2.1.2 av EN 301 549. For WCAG var den relevante versjonen WCAG 2.1.
    Krav EN 301 549 V2.1.2, kapittel 9 Kravets (suksesskriteriets) nummer, navn og samsvarsnivå var spesifisert i EN-standarden.
    Prinsipp i WCAG EN 301 549 V2.1.2, kapittel 9 Tilsvarende prinsipp i WCAG var spesifisert i EN-standarden.
    Retningslinje i WCAG EN 301 549 V2.1.2, kapittel 9 Tilsvarende retningslinje i WCAG var spesifisert i EN-standarden.
    Brukers tilgjengelighetsbehov EN 301 549 V2.1.2, vedlegg B Brukers tilgjengelighetsbehov (Functional Performance Statements) ble tilordnet til hvert krav i standarden.

    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:

    Tabell 21: Eksempel på data om et krav
    Dataelement Data som ble samlet inn i piloten
    Standard EN 301 549 / Retningslinjer for tilgjengelig webinnhold (WCAG)
    Versjon V2.1.2 / 2.1
    Krav 9.1.1.1 Ikke-tekstlig innhold
    Prinsipp i WCAG 1. Mulig å oppfatte
    Retningslinje i WCAG 1.1 Tekstalternativer
    Brukers tilgjengelighetsbehov

    Primærrelasjon:

    Bruk uten syn

    Bruk med nedsatt syn

    Bruk uten hørsel

    Sekundærrelasjon

    Bruk med nedsatt hørsel

    Bruk med kognitiv funksjonsnedsettelse

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

    Tabell 22: Data som er samlet inn om kravene
    Krav Prinsipp i WCAG Retningslinje i WCAG Suksesskriterium Brukers tilgjengelighetsbehov (Erklæring om funksjonsytelse)
    9.1.1.1 Ikke-tekstlig innhold 1. Mulig å oppfatte 1.1 Tekstalternativer 1.1.1 Ikke-tekstlig innhold (nivå A)

    Primærrelasjon:

    Bruk uten syn

    Bruk med nedsatt syn

    Bruk uten hørsel

    Sekundærrelasjon

    Bruk med nedsatt hørsel

    Bruk med kognitiv funksjonsnedsettelse

    9.1.2.2 Teksting (forhåndsinnspilt) 1. Mulig å oppfatte 1.2 Tidsbaserte medier 1.2.2 Teksting (forhåndsinnspilt) (nivå A)

    Primærrelasjon

    Bruk uten hørsel

    Bruk med nedsatt hørsel

    Sekundærrelasjon

    Bruk med kognitiv funksjonsnedsettelse

    9.1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt) 1. Mulig å oppfatte 1.2 Tidsbaserte medier 1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt) (nivå A)

    Primærrelasjon

    Bruk uten syn

    Sekundærrelasjon

    Bruk med nedsatt syn

    Bruk med kognitiv funksjonsnedsettelse

    9.1.3.1 Informasjon og relasjoner 1. Mulig å oppfatte 1.3 Tilpasningsdyktig 1.3.1 Informasjon og relasjoner (nivå A)

    Primærrelasjon

    Bruk uten syn

    Sekundærrelasjon

    Bruk med nedsatt syn

    Bruk med kognitiv funksjonsnedsettelse

    9.1.3.4 Orientering 1. Mulig å oppfatte 1.3 Tilpasningsdyktig 1.3.4 Orientering (nivå AA)

    Primærrelasjon

    Bruk med motorisk funksjonsnedsettelse eller begrenset styrke

    Sekundærrelasjon

    Bruk med kognitiv funksjonsnedsettelse

    9.1.3.5 Identifisere inndataformål 1. Mulig å oppfatte 1.3 Tilpasningsdyktig 1.3.5 Identifisere inndataformål (nivå AA)

    Primærrelasjon

    Bruk med nedsatt syn

    9.2.2.1 Justerbar hastighet 2. Mulig å betjene 2.2 Nok tid 2.2.1 Justerbar hastighet (nivå A)

    Primærrelasjon

    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

    9.2.4.2 Sidetitler 2. Mulig å betjene 2.4 Navigerbar 2.4.2 Sidetitler (nivå A)

    Primærrelasjon

    Bruk uten syn

    Bruk med nedsatt syn

    Bruk med motorisk funksjonsnedsettelse eller begrenset styrke

    Bruk med kognitiv funksjonsnedsettelse

    9.2.4.4 Formål med lenke (i kontekst) 2. Mulig å betjene 2.4 Navigerbar 2.4.4 Formål med lenke (i kontekst) (nivå A)

    Primærrelasjon

    Bruk uten syn

    Bruk med nedsatt syn

    Bruk med motorisk funksjonsnedsettelse eller begrenset styrke

    Bruk med kognitiv funksjonsnedsettelse

    Sekundærrelasjon

    Bruk uten taleevne

    9.3.1.1 Språk på siden 3. Forståelig 3.1 Leselig 3.1.1 Språk på siden (nivå A)

    Primærrelasjon

    Bruk uten syn

    Sekundærrelasjon

    Bruk med nedsatt syn

    Bruk uten hørsel

    Bruk med nedsatt hørsel

    Bruk med kognitiv funksjonsnedsettelse

    9.3.1.2 Språk på deler av innhold 3. Forståelig 3.1 Leselig 3.1.2 Språk på deler av innhold (nivå AA)

    Primærrelasjon

    Bruk uten syn

    Sekundærrelasjon

    Bruk med nedsatt syn

    Bruk uten hørsel

    Bruk med nedsatt hørsel

    Bruk med kognitiv funksjonsnedsettelse

    9.4.1.1 Parsing (oppdeling) 4. Robust 4.1 Kompatibel 4.1.1 Parsing (oppdeling) (nivå A)

    Primærrelasjon

    Bruk uten syn

    Sekundærrelasjon

    Bruk med nedsatt syn

    9.4.1.2 Navn, rolle, verdi 4. Robust 4.1 Kompatibel 4.1.2 Navn, rolle, verdi (nivå A)

    Primærrelasjon

    Bruk uten syn

    Bruk med nedsatt syn

    Sekundærrelasjon

    Bruk med motorisk funksjonsnedsettelse eller begrenset styrke

    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.

    Tabell 23: Innsamling av testresultater på sidenivå
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Side eller dokument Utdata fra verktøy Alle testrapportene fra verktøyene viste hvilke nettsider som var blitt testet.
    Krav Utdata fra verktøy

    To av verktøyene tilordnet testresultatet til ACT-reglene. Dette måtte deretter tilordnes til suksesskriterium ved hjelp av dokumentasjonen for ACT-reglene.

    Et av verktøyene tilordnet testresultatet direkte til suksesskriterium.

    Testmetode Dokumentasjon om verktøyet og testreglene

    Vi samlet inn informasjon om verktøyet og testreglene fra prosjektpartnernes verktøydokumentasjon.

    For å sikre en tilordning mellom testmetode, ACT-regler og suksesskriterier ba vi om ytterligere dokumentasjon fra prosjektpartnerne. Da denne piloten ble gjennomført var det ikke mulig å få denne informasjonen bare ved å undersøke verktøyene.

    Informasjon om når testmetoden sist ble oppdatert, følger av verktøyets versjonsnummer.

    Som for testmåte brukte vi bare automatiske testregler i piloten.
    Samsvarsstatus Utdata fra verktøy

    Vi beregnet samsvar for hver testet side per suksesskriterium som ble inkludert i testen.

    Testrapport fra et av verktøyene rapporterte de faktiske resultatene (spesifisert etter brudd, samsvar og ikke forekomst) for alle testede elementer.

    Fra to av verktøyene klarte vi bare å gjenfinne rapporter om elementer med brudd.

    Vi beregnet samsvarsstatus basert på forekomst av elementer med brudd på siden.

    Elementer med brudd førte til ikke-samsvar, mens alle samsvar, ikke forekomst eller ikke testbare elementer førte til samsvar.
    Elementer med brudd Utdata fra verktøy

    Vi brukte testresultatene til å telle antallet elementer med brudd på siden.

    Alle de tre verktøyene rapporterte elementer med brudd, per testregelimplementering, per side.

    Videre beregning er nødvendig for å telle elementer med brudd på suksesskriterienivå.
    Testdato Utdata fra verktøy Denne informasjonen ble dokumentert i rapportene fra hvert verktøy.
    Testet av Enheten som utførte testen

    Testing ble gjennomført av Digitaliseringsdirektoratet.

    Vi dokumenterte dette i tilfelle vi i framtiden vil lenke data fra tilgjengelighetserklæringene til kontrollresultatene.

    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.

    Tabell 24: Innsamling av testresultater på elementnivå
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Testet element Utdata fra verktøy

    Vi klarte ikke effektivt å samle inn disse dataene i piloten for noen av verktøyene som ble brukt.

    Dette var fordi vi ikke klarte å eksportere dataene fra verktøyene uten vesentlig manuell innsats. I stedet talte vi samlet antall elementer med brudd per suksesskriterium på hvert nettsted.

    Bare et av verktøyene rapporterte status for elementer med resultatene «samsvar» og «ikke forekomst».
    Side eller dokument Utdata fra verktøy
    Krav Utdata fra verktøy
    Resultat Utdata fra verktøy
    Testdato Utdata fra verktøy
    Testet av Enheten som utførte testen

    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.

    Tabell 25: Testresultater fra dybdekontroll
    Antall unike nettsider der det ble påvist resultat med brudd
    (Antallet resultater med brudd vises i parentes)
    WCAG-suksesskriterium Verktøy 1 Verktøy 2 Verktøy 3
    1.1.1 Ikke-tekstlig innhold 9 (18) 9 (18)
    1.2.2 Teksting (forhåndsinnspilt)
    1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt)
    1.3.1 Informasjon og relasjoner 7 (28)
    1.3.4 Orientering
    1.3.5 IIdentifisere inndataformål
    2.2.1 Justerbar hastighet
    2.4.2 Sidetitler
    2.4.4 Formål med lenke (i kontekst)
    2.5.3 Ledetekst i navn
    3.1.1 Språk på side
    3.1.2 Språk på deler
    4.1.1 Parsing (oppdeling) 1 (1) 1 (10) 1 (10)
    4.1.2 Navn, rolle, verdi 2 (8) 7 (29)

    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.

    Tabell 26: Testresultater fra forenklet kontroll
    Verktøy 1 Verktøy 2
    WCAG-suksesskriterium Statlig Regional Lokal Offentligrettslig Statlig Regional Lokal Offentligrettslig
    1.1.1 Ikke-tekstlig innhold 1544 161 4453 6978 36 26 1205 3
    1.2.2 Teksting (forhåndsinnspilt)
    1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt)
    1.3.1 Informasjon og relasjoner 1 2
    1.3.4 Orientering
    1.3.5 Identifisere Inndataformål
    2.2.1 Justerbar hastighet
    2.4.2 Sidetitler 168 1 142 16 1
    2.4.4 Formål med lenke (i kontekst) 9 1457 20 21 6 2015 141 74
    2.5.3 Ledetekst i navn
    3.1.1 Språk på side 168 991 143 72 5 938
    3.1.2 Språk på deler 2
    4.1.1 Parsing (oppdeling) 498 296281 418 277 168 148736 68
    4.1.2 Navn, rolle, verdi 18 1462 1238 45 15 2051 155 92

    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.

    Tabell 27: Innsamling av data om kontroll og rapportering
    Dataelement Datakilde Hvordan samlet vi inn data i piloten?
    Kontrollmetode Kontrollens planlegging og utforming Vi utførte en pilot med både forenklet kontrollog dybdekontroll
    Kontrollerte ikt-løsninger Kontrollens planlegging og utforming Vi kontrollerte bare nettsteder i piloten.
    Rapporteringsperiodens start Direktivet Gjelder ikke for piloten.
    Rapporteringsperiodens slutt Direktivet Gjelder ikke for piloten.
    Kontrollperiodens start Kontrollens planlegging og utforming Dette ble forhåndsdefinert i planen for pilotkontrollen.
    Kontrollperiodens slutt Kontrollens planlegging og utforming Dette ble forhåndsdefinert i planen for pilotkontrollen.
    Organ ansvarlig for kontroll Organet som utførte kontrollen Kontroll ble gjennomført av Digitaliseringsdirektoratet.
    Testede krav Kontrollens planlegging og utforming

    Kravene (suksesskriteriene) som ble testet, ble angitt i pilotens planleggingsfase. Utvalget av suksesskriterier ble avledet av de fullførte og implementerte ACT-reglene på tidspunktet for testing.

    Suksesskriteriene inkludert i piloten er angitt i kapittel 4.3.
    Utvalgsstørrelse for forenklet kontroll Kontrollens planlegging og utforming I piloten hadde vi et forhåndsdefinert utvalg av 4 nettsteder.
    Utvalgsstørrelse for dybdekontroll Kontrollens planlegging og utforming

    I piloten hadde vi et forhåndsdefinert utvalg av 4 nettsteder.

    Utvalgsstørrelse for dybdekontroll av mobilapplikasjoner Kontrollens planlegging og utforming Ikke anvendbart, ettersom bare nettsteder ble testet i piloten.

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

    Tabell 28: Data som er samlet inn om kontroll og rapportering
    Dataelement Data som ble samlet inn i piloten
    Kontrollmetode Forenklet og dybde
    Kontrollerte ikt-løsninger Nettsteder
    Rapporteringsperiodens start Gjelder ikke for piloten
    Rapporteringsperiodens slutt Gjelder ikke for piloten
    Kontrollperiodens start November 2019
    Kontrollperiodens slutt April 2020
    Organ ansvarlig for kontroll Digitaliseringsdirektoratet
    Testede krav

    Følgende krav til nett fra kapittel 9 i EN 301 549 V2.1.2:

    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

    Utvalgsstørrelse for forenklet kontroll 4 nettsteder
    Utvalgsstørrelse for dybdekontroll 1 nettsted.
    Utvalgsstørrelse for dybdekontroll av mobilapplikasjoner Ikke anvendbart i piloten.

    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.

    Tabell 29: Kort oversikt over vesentlige data som skal presenteres i rapporten
    Utvalgets størrelse og sammensetning i piloten Forenklet kontroll Dybdekontroll
    Antall nettsteder 4 nettsteder 1 nettsted (også inkludert i forenklet kontroll)
    Forvaltningsnivå

    Alle kategorier eller forvaltningsnivåer

    1 lokal

    1 regional

    1 statlig

    1 offentligrettslig

    En av kategoriene eller et av forvaltningsnivåene:

    1 statlig

    Geografisk beliggenhet

    3 av 11 fylker:

    Oslo

    Trøndelag

    Troms og Finnmark

    1 av 11 fylker:

    Oslo

    Representert tjenesteområde

    Representert:

    sosialomsorg, helse, transport, utdanning, sysselsetting, fritid og kultur, bolig og nærmiljø

    Ikke representert:

    beskatning, miljøvern, offentlig orden og sikkerhet

    Representert:

    sosialomsorg, sysselsetting

    Ikke representert:

    helse, transport, utdanning, beskatning, miljøvern, fritid og kultur, bolig og nærmiljø, offentlig orden og sikkerhet

    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.

    Tabell 30: Oversikt over suksesskriterier og brukers tilgjengelighetsbehov i piloten
    Suksesskriterium Bruk uten syn Bruk med nedsatt syn Bruk uten hørsel Bruk med nedsatt hørsel Bruk uten taleevne Bruk med motorisk funksjonsnedsettelse eller begrenset styrke Bruk med kognitiv funksjonsnedsettelse
    1.1.1 Ikke-tekstlig innhold P P P S S
    1.2.2 Teksting P P S
    1.2.3 Synstolking eller mediealternativ P S S
    1.3.1 Informasjon og relasjoner P S S
    1.3.4 Orientering P S
    1.3.5 Identifisere Inndataformål P
    2.2.1 Justerbar hastighet P P P P P P
    2.4.2 Sidetitler P P P P
    2.4.4 Formål med lenke P P S P P
    3.1.1 Språk på side P S S S S
    3.1.2 Språk på deler P S S S S
    4.1.1 Parsing (oppdeling) P S
    4.1.2 Navn, rolle, verdi P P S

    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.

    Tabell 31: Forhold mellom WCAGs prinsipper, retningslinjer, suksesskriterier og ACT-reglene
    WCAG Prinsipp Retningslinje Suksesskriterium ACT-regel ID og navn
    1. Mulig å oppfatte – informasjon og brukergrensesnittkomponenter må presenteres for brukere på måter som de kan oppfatte. 1.1 Tekstalternativer: Gi tekstalternativer til alt ikke-tekstlig innhold, slik at det kan konverteres til formater som brukerne har behov for, for eksempel stor skrift, blindeskrift, tale, symboler eller enklere språk 1.1.1 Ikke-tekstlig innhold

    23a2a8 - Bildet har tilgjengelig navn

    59796f - Bildeknappen har tilgjengelig navn

    1.2 Tidsbaserte medier: Gi alternativer til tidsbaserte medier. 1.2.2 Teksting (forhåndsinnspilt)

    59796f - Lydinnhold i videoelement har tilgjengelig alternativ

    1.2.3 1.2.3 Synstolking eller mediealternativ (forhåndsinnspilt)

    c5a4ea - Visuelt innhold i videoelement har tilgjengelig alternativ

    1.3 Tilpasningsdyktig: Lag innhold som kan presenteres på forskjellige måter (for eksempel med enklere layout) uten at informasjon eller struktur går tapt 1.3.1 Informasjon og relasjoner

    6cfa84 -

    Elementet med aria-hidden har ikke fokuserbart innhold

    (ACT-regelen gjelder også for SC 4.1.2)

    1.3.4 Orientering

    b33eff - Orientering av siden er ikke begrenset med CSS transform property

    1.3.5 Identifisere Inndataformål

    73f2c2 - Autocomplete-attributt har gyldig verdi

    2. Mulig å betjene - det må være mulig å betjene brukergrensesnittkomponenter og navigeringsfunksjoner.

    2.2 Nok tid: Gi brukerne nok tid til å lese og bruke innhold. 2.2.1 Justerbar hastighet

    bc659a - Metaelement har ingen oppdateringsforsinkelse

    2.4 Navigerbar: Gjør det mulig for brukerne å navigere, finne innhold og vite hvor de befinner seg 2.4.2 Sidetittel

    bc659a - HTML-siden har tittel

    2.4.4 Formål med lenke (i kontekst)

    c487ae - Lenken har tilgjengelig navn

    (ACT-regelen gjelder også for SC 4.1.2)

    3. Forståelig – det må være mulig å forstå informasjon og betjening av brukergrensesnitt. 3.1 Leselig: Gjør tekstlig innholdet leselig og forståelig. 3.1.1 Språk på siden

    b5c3f8 - HTML-siden har lang-attributt

    5b7ae0 - HTML-sidens lang- og xml:lang-attributter har samsvarende verdier

    bf051a - HTML-sidespråket er gyldig

    3.1.2 Språk på deler av innhold

    de46e4 - Elementet innenfor body har gyldig lang-attributt

    4. Robust – innholdet må være robust nok til at det kan tolkes på en pålitelig måte av brukeragenter, herunder datahjelpemidler. 4.1 Kompatibel: Sørg for best mulig kompatibilitet med aktuelle og framtidige brukeragenter, inkludert datahjelpemidler. 4.1.1 Parsing (oppdeling)

    3ea0c8 - Id-attributtverdien er unik

    4.1.2 Name, Role, Value

    97a4e1 - Knappen har tilgjengelig navn

    4e8ab6 - Elementet med role-attributt har nødvendige tilstander og egenskaper

    e086e5 - Skjemakontrollen har tilgjengelig navn

    cae760 - Iframe-elementet har tilgjengelig navn

    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:

    Tabell 32: Samsvarsnivå
    Samsvarsstatus Vilkår
    Fullt samsvar Alle testede sider er i samsvar med suksesskriteriene
    Delvis samsvar Ikke alle, men mer enn én, testside er i samsvar med suksesskriteriene
    Ikke-samsvar Ingen av testsiden er i samsvar med suksesskriteriene

    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:

    Tabell 33: Samsvarsstatus som ble målt i piloten
    Samsvarsstatus Suksesskriterium Prosentandel av suksesskriteriene etter samsvarsstatus Antallet testsider der ikke-samsvar er påvist Prosentandel testede sider med samsvar
    Fullt samsvar 1.2.2 Teksting 69 % 0 100 %
    1.2.3 Synstolking eller mediealternativ 69 % 0 100 %
    1.3.4 Orientering 69 % 0 100 %
    1.3.5 Identifisere inndataformål 69 % 0 100 %
    2.2.1 Justerbar hastighet 69 % 0 100 %
    2.4.2 Sidetittel 69 % 0 100 %
    2.4.4 Formål med lenke 69 % 0 100 %
    3.1.1 Språk på siden 69 % 0 100 %
    3.1.2 Språk på deler av innhold 69 % 0 100 %
    Delvis samsvar 1.3.1 Informasjon og relasjoner 23 % 7 22 %
    4.1.1 Parsing (oppdeling) 23 % 1 78 %
    4.1.2 Navn, rolle, verdi 23 % 7 22 %
    Ikke-samsvar 1.1.1 Ikke-tekstlig innhold 8 % 9 0 %

    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.

    Tabell 34: Påvirket brukers tilgjengelighetsbehov basert på påvist ikke-samsvar
    Suksesskriterier som ikke-samsvar er påvist for 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
    1.1.1 Ikke-tekstlig innhold P P P S S
    1.3.1 Informasjon og relasjoner P S S
    4.1.1 Parsing (oppdeling) P S
    4.1.2 Navn, rolle, verdi P P S

    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.

    Tabell 35: Samsvarsnivå i dybdekontrollen
    Beregning av samsvarsstatus Prosent
    Prosentandelen av de testede sidene som fullt samsvarer med suksesskriteriene 0 %
    Prosentandelen av de suksesskriteriene som de testede sidene samsvarer med 69 %

    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:

    Tabell 36: Verktøy som er brukt i piloten
    Prosjektpartner Verktøy Versjon Plattform Brukes til forenklet? Brukes til dybde?
    Deque WorldSpace Comply, basert på Axe-core v6.4.0.19914 Skyplattform (programvare som en tjeneste – SaaS) Ja Ja
    FCID QualWeb Core

    0.3.8

    Lokal installasjon, kjørt hos Digitaliseringsdirektoratet. Nei Ja
    Siteimprove Siteimprove Alfa (forhåndsversjon av Siteimproves nye, åpen-kilde motor) Ingen informasjon Skyplattform (programvare som en tjeneste – SaaS) Ja Ja

    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:

    Tabell 37: Spørsmål om verktøyene
    # Spørsmål om verktøyene Krav i direktivet
    1. Rapporterer verktøyet samlet antall nettsider som er testet, samt antallet nettsider med samsvar, brudd og ikke forekomst per nettsted? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg II (3.1 b)
    2. Rapporterer verktøyet antall elementer med samsvar, brudd og ikke forekomst per nettsted? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg II (3.1 b)
    3. Rapporterer verktøyet hvilke nettsider som har resultater med samsvar, brudd og ikke forekomst? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, artikkel 7
    4. Viser verktøyet en direkte forbindelse mellom hvert testresultat og det testede suksesskriteriet? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg II (3.1 b)
    5. Er det mulig å eksportere testresultatene i et format som er egnet til videre analyse? Kommisjonens gjennomføringsbeslutning (EU) 2018/1524, vedlegg II (3.1 b)

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

    Tabell 38: Svar fra Deque, FCID og Siteimprove
    Prosjektpartner Deque FCID
    (Mernad 1)
    Siteimprove
    1. Rapporterer verktøyet samlet antall nettsider som er testet, samt antallet nettsider med samsvar , brudd og ikke forekomst per nettsted?
    Rapporterer verktøyet antall sider med brudd per nettsted? Ja Nei Ja
    Rapporterer verktøyet antall sider med samsvar per nettsted? Ja Nei Ja (merknad 2)
    Rapporterer verktøyet samlet antall sider testet per nettsted? Ja Nei Ja
    Rapporterer verktøyet antall sider med «ikke forekomst» per nettsted? Nei Nei Ja (merknad 2)
    2. Rapporterer verktøyet antall elementer med samsvar, brudd og ikke forekomst per nettsted?
    Rapporterer verktøyet samlet antall elementer med brudd per nettside? Ja Nei Ja
    Rapporterer verktøyet samlet antall elementer med samsvar per nettside? Ja Nei Ja (merknad 2)
    Rapporterer verktøyet samlet antall elementer med «ikke forekomst» per nettside? Nei Nei Nei
    3. Rapporterer verktøyet hvilke nettsider som har resultatene samsvar, brudd og «ikke forekomst»?
    Rapporterer verktøyet hvilke nettsider som har resultater med brudd? Ja Ja Ja
    Rapporterer verktøyet hvilke nettsider som har resultater med samsvar? Ja Ja Ja (merknad 2)
    Rapporterer verktøyet hvilke nettsider som har resultater av «ikke forekomst»? Nei Ja Ja (merknad 2)
    4. Viser verktøyet en direkte forbindelse mellom hvert testresultat og det testede suksesskriteriet?
    Viser verktøyet en direkte forbindelse mellom hvert testresultat og det testede suksesskriteriet? Ja For det meste ja, men også for noen typer bestepraksis Ja
    5. Er det mulig å eksportere testresultatene i et format som er egnet til videre analyse?
    Hvilket filutdataformat støtter verktøyet? CSV, Excel-regneark, JSON JSON, EARL HTML, PDF, CSV, Excel-regneark, JSON
    Gir verktøyet tilgang til en API for tilpasset eksport av testresultater? Ja Nei Ja

    Referanser