axessia.eu

Hoe lang duurt het om een app toegankelijk te maken volgens WCAG?

De doorlooptijd om een app te laten voldoen aan WCAG 2.1 AA verschilt sterk per platform en aanpak; dit artikel laat zien waar de tijd in de praktijk naartoe gaat en waar planningen vastlopen.

Er is geen vaste termijn die voor elke app geldt. Een kleine app met een beperkt aantal schermen en een opgeruimde codebasis is in enkele weken op het gewenste niveau te krijgen; een app met veel maatwerkcomponenten, meerdere platforms en een lange geschiedenis aan technische schuld kost eerder maanden. De grootste variabele is niet de hoeveelheid schermen, maar hoeveel van de bediening buiten de standaardcomponenten van iOS of Android om is gebouwd.

Als ruwe indicatie: een app die grotendeels uit standaard UI-elementen bestaat en waarvan het team al met toegankelijkheid bekend is, laat zich in de praktijk vaak binnen zes tot tien weken aanpassen. Een app met veel eigen bediening, animaties, custom gebaren of ingesloten SDK's van derden loopt al snel op tot drie tot zes maanden, simpelweg omdat elk onderdeel apart moet worden onderzocht en soms opnieuw gebouwd. Dit zijn geen harde grenzen maar een indruk van waar de meeste trajecten in de praktijk uitkomen.

Wat de doorlooptijd echt bepaalt

De tijd die een traject kost, hangt minder af van de wet zelf en meer van drie praktische factoren. Ten eerste: is de bediening opgebouwd uit standaardcomponenten van het besturingssysteem, of grotendeels custom gebouwd? Standaardcomponenten geven toegankelijkheid vaak al voor een groot deel cadeau; eigen componenten moeten stuk voor stuk worden voorzien van de juiste labels, focusvolgorde en aankondigingen voor schermlezers. Ten tweede: hoeveel externe onderdelen zitten er in de app, zoals betaalmodules, kaartweergaven of chatvensters van derden? Die vallen vaak buiten de directe controle van het eigen team, en het navragen bij een leverancier kost doorgaans meer tijd dan het testen zelf. Ten derde: is er al een testroutine met een schermlezer op het echte apparaat, of moet die nog worden opgezet? Dat laatste kost bij de eerste ronde de meeste tijd, maar betaalt zich bij volgende updates terug.

Waar planningen in de praktijk vastlopen

De meeste vertraging ontstaat niet bij het aanpassen van tekst of kleurcontrast, maar bij interactie die niet met toetsenbord of schermlezer te bedienen blijkt: een sleepbeweging zonder alternatief, een modaal venster dat de focus niet vasthoudt, of een formulier waarvan foutmeldingen niet worden aangekondigd. Dit soort problemen wordt vaak pas zichtbaar bij handmatig testen met een schermlezer, iets wat een geautomatiseerde scan niet volledig kan vervangen. Wie alleen op een automatische controle vertrouwt, ontdekt deze knelpunten doorgaans te laat in het traject, wat de doorlooptijd alsnog verlengt. Een goed vertrekpunt is daarom in een paar vragen een eerste indicatie krijgen van waar de app op dit moment staat, zodat de tijdrovende onderdelen vroeg in beeld komen in plaats van vlak voor oplevering.

Ook app store review-cycli spelen mee: een aanpassing die de toegankelijkheid verbetert, moet nog steeds door de gebruikelijke reviewtermijn van de betreffende store heen voordat gebruikers er iets van merken. Dat zit buiten de invloed van het ontwikkelteam en hoort in elke planning als vaste tijdsbuffer te staan.

Toegankelijk blijven na oplevering

Een app die vandaag voldoet, kan dat na de volgende update niet meer doen. Elke nieuwe functie, elk nieuw scherm en elke aangepaste flow verdient dezelfde aandacht als de eerste ronde, anders sluipt het probleem terug. Dat is ook waarom de verplichting niet stopt bij één keer testen: de eigen beoordeling moet actueel blijven, en dat vraagt om een terugkerend ritme in plaats van een eenmalig project. Voor de achtergrond bij wat daarbij precies van u wordt verwacht, is de per situatie uitgezochte achtergrond een geschikt startpunt.

Wat axessia.eu wel en niet doet in dit traject

Axessia toetst, prioriteert, legt vast en bewaakt: de scan laat zien waar de app op dit moment staat, het rapport zet de bevindingen in gewone taal op een geprioriteerde lijst, en de verklaring en het verbeterplan leggen vast wat er is gedaan en wat nog moet gebeuren. Handmatige audits en reparatiewerk aan de app zelf horen daar niet bij; dat blijft bij het ontwikkelteam of de partij die de app bouwt. Hoe die scan precies tot stand komt en welke bronnen daarbij worden gebruikt, staat toegelicht op de pagina over hoe de informatie tot stand komt. Wat een volledig traject inclusief rapport en verklaring kost, staat op het overzicht van de abonnementen.

Wie wil weten waar een concrete app op dit moment staat, begint het beste met de gratis quick-scan van axessia.eu. Die geeft binnen een paar minuten een eerste beeld, zonder dat daar een account voor nodig is.

Dit artikel is algemene informatie en geen juridisch advies.