Tilgængelighedsvurdering (WCAG-EM)

Her beskrives den tekniske metode bag TRAQ Blueprint (vores formelle tilstandsrapport og baseline-audit). Metoden følger den internationalt anerkendte evalueringsmetode WCAG-EM og afdækker, hvad der skal til for at efterprøve et websites overholdelse af WCAG 2.1 niveau A og AA.

Formålet med at anvende en offentlig, navngiven metode er enkel: enhver vurdering fra TRAQ skal kunne gentages og efterprøves af en anden fagperson med præcis samme resultat.

Standard og retsgrundlag

Vi vurderer som udgangspunkt efter WCAG 2.1 niveau A og AA (i alt 50 succeskriterier: 30 på niveau A, 20 på niveau AA). Se den komplette gennemgang under Tilgængelighedssucceskriterier (WCAG 2.1).

Vi vurderer efter version 2.1, fordi den europæiske standard EN 301 549, som tilgængelighedsloven henviser til, fortsat har 2.1 som sin normative reference. Én praktisk konsekvens er, at succeskriterium 4.1.1 Parsing er udgået i WCAG 2.2, men fortsat gælder i 2.1 og derfor indgår i vores vurdering. Samtidig registrerer vi observationer mod de seks nye kriterier i WCAG 2.2 som kommende krav, så jeres dokumentation forbliver forberedt på fremtidige opdateringer.

Loven bag kravene er gennemgået under Lovkrav og oplysningspligt (§ 35).

Evalueringsmetoden: WCAG-EM

TRAQ følger W3C’s officielle evalueringsmetode for webtilgængelighed, WCAG-EM (Website Accessibility Conformance Evaluation Methodology).

WCAG-EM er struktureret i fem faser:

1. Fastlæggelse af omfang: Afgrænsning af domæner, miljøer, teknologier og overensstemmelsesmål i et formelt scope-manifest.
2. Udforskning af sitet: Gennemgang af funktioner, nøglesider, dynamiske komponenter og transaktionstyper.
3. Udvælgelse af stikprøve: Fastlæggelse af en repræsentativ stikprøve baseret på strukturel og funktionel variation.
4. Gennemførelse af vurdering: Teknisk gennemgang af alle 50 succeskriterier på de udvalgte enheder.
5. Afrapportering og evidens: Udarbejdelse af rapport med entydige evidens-ID’er, reproduktionstrin og rettelsesvejledninger.

Den frosne stikprøve

En standard TRAQ Blueprint dækker 6 sidetemplates og 2 transaktionsforløb. Dette giver 8 enheder × 50 kriterier, svarende til 400 enkeltvurderinger.

Stikprøven udvælges således:

• Forside (indgang, overordnet struktur, globale elementer).
• Oversigts- eller kategorivisning (produktlister, filtrering, paginering).
• Detaljeside (produktside med købsmulighed og variantvalg).
• Formularside (kontakt, registrering eller forespørgsel).
• Indholdstung side (vilkår, handelsbetingelser eller artikler).
• Den mest funktionelt atypiske side på sitet (fx dynamisk søgeresultat eller interaktivt værktøj).
• To komplette transaktionsforløb (hovedkøbsflow samt sekundært forløb som retur eller support).

Stikprøven fryses og offentliggøres med fulde URL’er i rapporten. En frossen stikprøve er forudsætningen for, at en efterfølgende gentest er sammenlignelig frem for en uforpligtende ny vurdering.

Testsekvens og værktøjer

Vurderingen udføres i fem metodiske trin, fra automatik til specialiseret manuel test:

Testmiljø: Standard Chrome og Firefox på Windows. Skærmlæser: NVDA. Viewports: Desktop (1280 px) og mobil/smal skærm (320 px).

Hvor en teknisk fejl skyldes begrænsninger i en hostet platformskerne (fx en lukket Shopify-checkout), noteres dette tydeligt med koden owner_type: platform. Dermed undgår jeres udviklingsteam at spilde timer på at lede efter rettelser i temaets kildekode, hvor koden er låst fra udbyderens side.

Balancen mellem automatik og manuel test

Kriterierne i WCAG 2.1 AA fordeler sig således efter testbarhed:

• Fuldt automatisk (5 kriterier): Sidetitel (2.4.2), sidens sprog (3.1.1), parsing (4.1.1), autocomplete (1.3.5) og farvekontrast i simpel tekst (1.4.3).
• Værktøj assisterer, fagperson afgør (11 kriterier): Værktøjet finder elementer (fx billeder eller knapper), hvorefter fagpersonen afgør, om teksten faktisk beskriver billedet eller knappen meningsfuldt i sammenhængen.
• Fuld manuel test (34 kriterier): Om fokusrækkefølgen giver mening, om en fejlbesked guider brugeren videre, eller om en modal lukker korrekt med tastaturet.

Fordelingen viser, hvorfor manuel faglig vurdering er nødvendig for en retvisende audit: Hovedparten af standardens krav vedrører dynamisk interaktion, som kun kan verificeres pålideligt gennem en systematisk gennemgang med tastatur og hjælpeteknologi.

Leverancen: Kodediffs til udviklingsteamet

Et centralt princip i TRAQ Blueprint er, at en audit ikke må ende som en passiv rapport. Hvert teknisk fund leveres med en specifik kodediff, som jeres udviklere eller eksterne bureau kan implementere direkte i kildekoden.

Her er et eksempel på en kodediff for en formularvalideringsfejl (WCAG 3.3.1 Fejlidentifikation og 1.3.1 Info og relationer):

--- a/components/CheckoutEmailField.html
+++ b/components/CheckoutEmailField.html
@@ -1,6 +1,8 @@
 <div class="form-group has-error">
   <label for="email">E-mailadresse</label>
-  <input type="email" id="email" name="email" class="input-error" value="ugyldig-mail">
-  <span class="error-text">Indtast en gyldig e-mailadresse (f.eks. [email protected])</span>
+  <input type="email" id="email" name="email" class="input-error" value="ugyldig-mail"
+         aria-invalid="true"
+         aria-describedby="email-error-msg">
+  <span id="email-error-msg" class="error-text" role="alert">Indtast en gyldig e-mailadresse (f.eks. [email protected])</span>
 </div>

Dermed vedhæftes den tekniske løsning direkte til opgaven i jeres task tracker eller pull request, hvilket minimerer genåbninger og reducerer udbedringstiden væsentligt.