Sådan testes en webshop, og mod hvilke standarder

W3C udgiver Web Content Accessibility Guidelines (WCAG 2.1, WCAG 2.2). ETSI udgiver EN 301 549. Standardens afsnit 9 indarbejder WCAG’s succeskriterier på niveau A og AA som krav til webindhold. Afsnittenes numre består af 9 efterfulgt af kriteriets nummer: Kriterium 1.1.1 er afsnit 9.1.1.1. Et kriterium, som WCAG 2.2 har tilføjet, for eksempel 2.5.8 Target Size (Minimum), har kun et afsnit i V4.1.1, den version, hvis webkrav er tilpasset WCAG 2.2.

Validiscan arbejder efter WCAG 2.2 AA, fordi det er den nyere version og den, som EN 301 549 V4.1.1, udgivet af ETSI i september 2026, er tilpasset. W3C’s arbejdsgruppe Accessibility Guidelines Working Group, som skriver WCAG, anbefaler, at websteder gør WCAG 2.2 til deres nye mål for overensstemmelse, også selv om formelle forpligtelser nævner tidligere versioner (WCAG 2.2). Resultaterne angives også for WCAG 2.1 AA, fordi EN 301 549 V3.2.1 indarbejder det niveau. Det er den version, hvis henvisning er offentliggjort i EU-Tidende under webtilgængelighedsdirektivet.

De to versioner overlapper næsten helt. Hvert succeskriterium i WCAG 2.1 på niveau A og AA findes også i WCAG 2.2, undtagen 4.1.1 Parsing, som WCAG 2.2 har fjernet. WCAG 2.2 tilføjer seks kriterier på de to niveauer:

• 2.4.11 Focus Not Obscured (Minimum), niveau AA
• 2.5.7 Dragging Movements, niveau AA
• 2.5.8 Target Size (Minimum), niveau AA
• 3.2.6 Consistent Help, niveau A
• 3.3.7 Redundant Entry, niveau A
• 3.3.8 Accessible Authentication (Minimum), niveau AA

Hvert kriterium vurderes én gang. Remediation Evidence Package viser derefter resultaterne to gange, i én tabel for WCAG 2.1 AA og én for WCAG 2.2 AA. For 4.1.1 Parsing, som kun står i tabellen for WCAG 2.1, registrerer pakken kriteriet som understøttet med grundlaget »Altid opfyldt for HTML-indhold (WCAG 2.1-errata)«.

Pakken beskriver, hvad den omfatter, med denne sætning: »Overensstemmelse med succeskriterierne i WCAG 2.1 AA og WCAG 2.2 AA, som de er vurderet på de anførte sider og datoer.« Den siger også: »Denne pakke er dokumentation for en vurdering og for udbedringsarbejde. Den er ikke et certifikat og udtaler sig ikke om, hvorvidt lovkrav er overholdt.«

Validiscans scanner indlæser hver side i en rigtig browser, Chromium styret af Playwright, og kører to slags regler på den: reglerne i axe-core, en open source-motor til test af tilgængelighed, og Validiscans egne kontroller af barrierer, der er typiske for webshops. Hvert fund angiver sin regel, de elementer og sider, hvor fejlen optræder, og de WCAG-kriterier og afsnit i EN 301 549, som reglen svarer til.

Mange succeskriterier i WCAG kræver en persons vurdering. Validiscans manuelle tjekliste har 35 punkter, hvert for ét succeskriterium på niveau A eller AA, som automatiske kontroller ikke fuldt ud kan bevise. Af de 55 succeskriterier i WCAG 2.2 på niveau A og AA testes 22 ikke af nogen regel, der køres, og dækkes kun af denne tjekliste. De øvrige 33 testes af mindst én regel, der køres. For nogle af dem, for eksempel tastaturbetjening, fokusrækkefølge og undertekster, har tjeklisten også et punkt, fordi en regel kun tester dem delvis. For resten har den intet.

Tjeklisten beder blandt andet om disse kontroller:

• vejen til kurven kun med tastaturet: menuerne, en produktside, valg af en variant, tilføjelse til kurven og derefter ændring af antallet og fjernelse af en vare;
• hvert modalvindue og cookiebanneret med tastaturet: fokus flyttes ind, Escape lukker, fokus vender tilbage;
• søgning, produktvarianter, kurven og felterne i kassen med en skærmlæser;
• formularfejl: læses op, når de vises, nævner feltet og siger, hvordan fejlen rettes;
• siden zoomet til 400 %;
• videoer: undertekster og synstolkning.

Tjeklisten angiver de skærmlæsere, der skal bruges ved disse gennemgange: NVDA med Chrome på Windows og VoiceOver med Safari på en Mac. For hvert punkt registrerer Validiscan bestået, ikke bestået eller ikke relevant med noter og dokumentation. Resultatet afgør, hvordan kriteriet rapporteres i Remediation Evidence Package.

En fuld scanning, som er et projekts udgangsscanning, indlæser et udvalg af hver sidetype i webshoppen, som standard op til 150 sider i stikprøven: forsiden, produktlister, produktsider og de andre sidetyper, den finder. Oveni kommer kurven, det første trin i kassen, søgeresultater, siden til login eller oprettelse af konto, kontaktsiden og de juridiske sider, når scanningen finder dem. Som standard indlæses hver side i desktopstørrelse (1440 × 900 pixels) og i mobilstørrelse (390 × 844 pixels, med touch-input), og alle kontroller køres i begge størrelser.

For at nå kurven og kassen lægger scanningen ét produkt, der er på lager, i kurven, åbner kurven og åbner det første trin i kassen. Den gennemfører aldrig et køb og indtaster aldrig betalingsoplysninger.

Et cookiebanner testes først som en del af siden. Som standard accepterer scanningen det derefter, så resten af siden kan testes. Kendte analyse-, annonce-, chat- og anmeldelsestjenester blokeres som standard under en scanning, så resultaterne ikke afhænger af dem. Samtykkeværktøjer blokeres ikke, fordi cookiebanneret er en del af det, der testes.

Validiscan scanner kun en webshop fuldt ud med ejerens tilladelse. En fuld scanning, en verifikationsscanning og en kørsel af regressionsbeskyttelsen kræver webshopejerens skriftlige tilladelse, som registreres i Validiscans applikation sammen med tidspunktet og navnet på den person, der registrerede den. Uden den registrering afviser applikationen at sætte scanningen i kø, og en planlagt kørsel af regressionsbeskyttelsen springes over.

En fuld scanning følger webshoppens robots.txt som standard. Den kan kun indstilles til at ignorere robots.txt for en webshop, hvor ejerens tilladelse er registreret.

Det gratis tjek køres uden den tilladelse, inden for faste grænser. Det indlæser højst 15 sider, lægger aldrig noget i en kurv og åbner aldrig kassen. Det følger robots.txt for webshoppens host og lader mindst 1 s gå mellem de forespørgsler, det selv starter, med kendte undtagelser: Dets første forespørgsel, til forsiden, sendes, før robots.txt er læst, og når webshoppen besvarer en sideindlæsning i browseren med en omdirigering, følger browseren den med det samme, uden den pause og uden at kontrollere robots.txt. Siden om det gratis tjek beskriver alle grænser og undtagelser.

Automatiske kontroller finder kun en del af alle tilgængelighedsbarrierer, og en scanning beskriver de sider, den indlæste, på de datoer, den kørte. Remediation Evidence Package anfører sine egne begrænsninger. Listen nedenfor nævner også mangler, som Validiscan har registreret i sin scanner og endnu ikke har rettet.

• Automatiske kontroller beviser kun en del af WCAG. En regel kan ikke vurdere, om et tekstalternativ beskriver sit billede, om en fejlmeddelelse giver mening, når den læses op, eller om underteksterne er rigtige. Den manuelle tjekliste dækker de sidste to. Kvaliteten af tekstalternativer har i dag intet punkt på tjeklisten, så resultatet »Understøtter« for 1.1.1 Non-text Content hviler alene på automatiske kontroller. De fejl, en scanning rapporterer, er en nedre grænse, ikke et samlet antal.
• Siderne er en stikprøve. En scanning kontrollerer en stikprøve af hver sidetype. Andre sider, der er bygget ud fra de samme skabeloner, forventes at opføre sig ens, men de kontrolleres ikke enkeltvis.
• En scanning er et øjebliksbillede. Resultaterne beskriver webshoppen på datoerne for scanningerne. Senere ændringer af tema, apps eller indhold er ikke dækket før den næste scanning; regressionsbeskyttelse scanner webshoppen igen efter en tidsplan.
• Testen af kassen stopper ved første trin. Der afgives ingen ordre, og der indtastes ingen betalingsoplysninger, så de senere trin i kassen testes ikke automatisk.
• Andre frames og lukket shadow DOM. Indhold i frames fra en anden origin og i lukket shadow DOM, som betalingsfelter og visse samtykkeværktøjer og widgets, vurderes ikke automatisk. Validiscans kontrol af cookiebannere vurderer ikke et banner, der ligger i shadow DOM eller i en frame fra en anden origin.
• Blokerede tjenester testes ikke. De analyse-, annonce-, chat- og anmeldelsestjenester, som en scanning blokerer, testes ikke. At rette indlejret tredjepartsindhold, for eksempel betaling og chat, er heller ikke en del af et projekt.
• Resultater, der kræver gennemgang, rapporteres endnu ikke. Når axe-core eller en af Validiscans kontroller ikke kan afgøre et resultat, markerer den resultatet til gennemgang i stedet for at rapportere en fejl. Scanneren gemmer ikke disse resultater i dag, så de optræder ikke som fund. Det gælder links til PDF-filer og andre dokumenter, som Validiscans kontrol af dokumenter kun markerer til gennemgang, og resultater for cookiebanner, fokus, tastatur og formularer, som en kontrol ikke kunne afgøre. Nogle få regler, der køres, kan derfor ikke give et fund i dag. Indtil scanneren gemmer disse resultater, kontrollerer Validiscan cookiebanneret manuelt og registrerer resultatet i den manuelle tjekliste. Selve PDF-filerne er ikke en del af et projekt.
• Skærmbilleder viser den første skærm. Scanneren tager et skærmbillede af hver side i skærmens størrelse, ikke i hele dens længde. Et skærmbillede til et fund længere nede på en side viser toppen af siden. Indtil scanneren tager skærmbilleder af hele sider eller af enkelte elementer, kontrollerer Validiscan figurerne i hver Remediation Evidence Package manuelt, før pakken udstedes.