De richtlijn zelf noemt geen vaste termijn voor het "toegankelijk maken" van een webshop. Wat wél vaststaat, is de datum waarop de verplichting geldt: sinds 28 juni 2025 is de eis afdwingbaar voor diensten die eronder vallen. Hoe lang het daadwerkelijke traject duurt om van een huidige website naar een site te gaan die voldoet aan EN 301 549 (in de praktijk WCAG 2.1 niveau AA), hangt af van de omvang van de site, het aantal knelpunten en de snelheid waarmee een organisatie intern kan schakelen.
In de praktijk valt een traject uiteen in vier fases: inventariseren, prioriteren, technisch herstellen en vastleggen. Een kleine webshop met een standaard cms-thema en een beperkte bestelstap doorloopt die fases doorgaans sneller dan een platform met een eigen inlogomgeving, een maatwerk-checkout en meerdere talen. Er is geen getal dat voor elke organisatie klopt; wel is er een patroon in waar trajecten vertraging oplopen.
Wat de wet regelt en wat niet
De verordening beschrijft welke diensten onder de scope vallen, welke technische norm van toepassing is en welke informatie een toegankelijkheidsverklaring moet bevatten. Een concrete deadline voor "eerst scannen, dan binnen X weken verbeteren" staat er niet in. Toezichthouders kijken naar de actuele staat van een dienst en naar de vraag of een organisatie aantoonbaar en structureel werkt aan naleving, niet naar een vaste doorlooptijd die overal hetzelfde zou zijn. Voor de precieze eisen per onderdeel van een site is het raadzaam de tekst zelf te raadplegen; per onderwerp is uitgezocht wat de regels precies inhouden en waar ze in de officiële tekst staan.
Waar trajecten in de praktijk vastlopen
De eerste vertraging ontstaat vaak niet bij de techniek maar bij het overzicht: bedrijven weten niet welke pagina's, formulieren en flows onder de scope vallen en welke niet. Een tweede knelpunt is de afrekenstap en de inlogomgeving; dat zijn vaak maatwerkonderdelen die niet in een standaardthema zitten en dus niet automatisch meeliften met een cms-update. Een derde knelpunt is de afhankelijkheid van een externe leverancier voor het cms of de betaalmodule, waarbij een wijziging soms wacht op een release van die partij. En een vierde knelpunt is intern: een lijst met bevindingen in technische taal blijft liggen omdat niemand weet wie welke regel oppakt.
Vier fases en waar ze op stuklopen
De inventarisatiefase gaat over vaststellen wat er niet klopt, op welke pagina's, en hoe ernstig dat is voor iemand die met een schermlezer of alleen een toetsenbord werkt. Dit is de fase waarin een geautomatiseerde scan het meeste werk verzet, maar ook de fase waarin duidelijk moet zijn wat zo'n scan niet kan zien; niet elk WCAG-criterium is machinaal te toetsen.
De prioriteringsfase zet bevindingen om in een volgorde: wat blokkeert een bestelling volledig, en wat is een kleinere hindernis. Dit stokt vaak omdat een technische bevindingenlijst niet vertelt wie binnen de organisatie verantwoordelijk is voor welk onderdeel.
De herstelfase is de fase met de meeste doorlooptijd, en de duur ervan hangt sterk af van of aanpassingen in eigen beheer zijn te maken of via een leverancier moeten lopen. Formulierlabels en kleurcontrast zijn vaak snel op te lossen; een bestelstap die technisch niet met alleen een toetsenbord te bedienen is, vraagt meer ontwikkelwerk.
De laatste fase is vastleggen: de toegankelijkheidsverklaring opstellen, een verbeterplan met deadlines vastleggen, en bewijsbaar maken dat er een eigen beoordeling is gedaan. Dit is geen fase die je overslaat als de techniek eenmaal klopt; de verklaring hoort de actuele stand te weerspiegelen, ook als die stand nog niet perfect is.
Wat de doorlooptijd wél beïnvloedt
Een organisatie die vooraf weet welke pagina's onder de scope vallen en welke knelpunten het zwaarst wegen, verliest minder tijd aan heen-en-weer geschakel tussen techniek en besluitvorming. In een paar vragen is gratis te zien waar een site nu staat, zonder dat daar een account voor nodig is. Voor het vervolg, dus de volledige scan van bestelstap en inlogflow plus een geprioriteerde actielijst in gewone taal, geldt dat de uitwerking per verplichting met de bijbehorende termijnen onderdeel is van het betaalde traject; wat daarin zit staat overzichtelijk op een rij.
Een laatste factor die de doorlooptijd raakt: toegankelijkheid is geen project met een einddatum maar een staat die na elke wijziging aan de site opnieuw geldt. Een nieuwe checkout-stap of een vernieuwd contactformulier kan een probleem terugbrengen dat eerder al was opgelost. Wie wil weten waar de informatie in een rapport vandaan komt en hoe vaak die wordt bijgewerkt, vindt dat terug op de pagina die uitlegt hoe het proces werkt.
Voor de eigen situatie, met de eigen cms, leverancier en interne planning, blijft het lastig om vooraf een harde termijn te noemen. Wie twijfelt of een traject realistisch te plannen is, doet er goed aan eerst scherp te krijgen wat er precies moet gebeuren voordat er een planning omheen wordt gebouwd. De gratis quick-scan is daarvoor een logisch startpunt, zonder dat er meteen een account of betaling bij komt kijken.