Direktivet selv angiver ingen fast tidsfrist for at "gøre en webshop tilgængelig". Det, der derimod er fastsat, er datoen for, hvornår forpligtelsen træder i kraft: siden 28. juni 2025 er kravet håndhævet for tjenester, der falder ind under direktivet. Hvor lang tid det faktiske projekt tager at gå fra en nuværende websted til et websted, der opfylder EN 301 549 (i praksis WCAG 2.1 niveau AA), afhænger af omfanget af webstedet, antallet af barrierer og den hastighed, hvormed en organisation kan handle internt.
I praksis opdeles et projekt i fire faser: inventarisering, prioritering, teknisk afhjælpning og dokumentation. En lille webshop med et standard cms-tema og en begrænset betalingsproces gennemløber typisk disse faser hurtigere end en platform med et brugerdefineret login-miljø, en specialdesignet checkout og flere sprog. Der er ingen tal, der passer til enhver organisation; der er dog et mønster for, hvor projekter oplever forsinkelser.
Hvad loven regulerer, og hvad den ikke gør
Forordningen beskriver, hvilke tjenester der falder inden for omfanget, hvilken teknisk standard der gælder, og hvilke oplysninger en tilgængelighedserklæring skal indeholde. En konkret deadline for "scan først, forbedring inden for X uger" findes ikke i forordningen. Tilsynsmyndigheder ser på den aktuelle tilstand af en tjeneste og på spørgsmålet om, hvorvidt en organisation dokumenterbar og strukturelt arbejder på at opfylde kravene, ikke på en fast projektvarighed, der skulle være den samme overalt. For de præcise krav for hver del af et websted anbefales det at læse teksten selv; for hvert emne er det undersøgt, hvad reglerne præcist betyder og hvor de findes i den officielle tekst.
Hvor projekter i praksis stivner
Den første forsinkelse opstår ofte ikke ved teknikken, men ved oversigten: virksomheder ved ikke, hvilke sider, formularer og flows der falder inden for omfanget, og hvilke der ikke gør. Et andet problem er betalingstrinnet og login-miljøet; det er ofte specialtilpassede komponenter, der ikke er i et standard cms-tema, og derfor ikke automatisk opdateres med en cms-update. Et tredje problem er afhængigheden af en ekstern leverandør for cms eller betalingsmodul, hvor en ændring nogle gange må vente på en release fra denne part. Og et fjerde problem er internt: en liste med resultater i teknisk sprog bliver liggende, fordi ingen ved, hvem der håndterer hvilken regel.
Fire faser og hvor de går i stå
Inventariseringsfasen handler om at fastslå, hvad der ikke fungerer, på hvilke sider, og hvor alvorligt det er for nogen, der bruger en skærmlæser eller kun tastaturet. Dette er fasen, hvor en automatiseret scanning udfører det meste arbejde, men det er også fasen, hvor det skal være klart, hvad sådan en scanning ikke kan se; ikke alle WCAG-kriterier kan testes maskinelt.
Prioriteringsfasen omsætter resultater til en rækkefølge: hvad blokerer en bestilling fuldstændigt, og hvad er en mindre ulempe. Dette går ofte i stå, fordi en teknisk resultatliste ikke fortæller, hvem inden for organisationen der er ansvarlig for hvilken del.
Afhjælpningsfasen er fasen med den længste projektvarighed, og dens varighed afhænger stærkt af, om tilpasninger kan foretages internt, eller om de skal køre gennem en leverandør. Formular-labels og farvekontrastforhold er ofte hurtige at løse; et betalingstrin, der teknisk ikke kan betjenes med kun et tastatur, kræver mere udvikling.
Den sidste fase er dokumentation: udarbejdelse af tilgængelighedserklæringen, fastlæggelse af en forbeddringsplan med deadlines, og dokumentation af, at der er udført en selvvurdering. Dette er ikke en fase, du springer over, når teknikken først fungerer; erklæringen skal afspejle den aktuelle tilstand, også hvis den endnu ikke er perfekt.
Hvad der påvirker projektvarigheden
En organisation, der på forhånd ved, hvilke sider der hører under anvendelsesområdet, og hvilke flaskehalse der vejer tungest, spilder mindre tid på frem og tilbage mellem teknik og beslutningstagning. Det er gratis at se på et par spørgsmål, hvor et websted står nu, uden at det kræver en konto. For det videre arbejde – altså den fuldstændige scanning af betalingstrin og loginflow plus en prioriteret handlingsliste i almindeligt sprog – gælder det, at udarbejdelsen pr. krav med tilhørende tidsfrister er en del af den betalte proces; hvad der ligger deri, er opstillet klart og tydeligt.
En sidste faktor, som påvirker gennemløbstiden: tilgængelighed er ikke et projekt med en slutdato, men en tilstand, der gælder på ny efter hver ændring af webstedet. Et nyt betalingstrin eller en fornyet kontaktformular kan bringe et problem tilbage, som tidligere var løst. Den, der ønsker at vide, hvor informationen i en rapport kommer fra, og hvor ofte den opdateres, finder det på den side, der forklarer, hvordan processen fungerer.
For egen situation, med eget cms, leverandør og intern planlægning, er det fortsat vanskeligt at navngive en fast frist på forhånd. Den, der er usikker på, om en proces kan planlægges realistisk, gør godt i først at præcisere, hvad der præcist skal ske, før der bygges en tidsplan omkring det. Den gratis quick-scan er et logisk udgangspunkt til det, uden at der straks skal være en konto eller betaling ved.