Stap 4: Begeleiding

Een rapport van honderd bevindingen voelt overweldigend zodra het binnenkomt. Waar begin je? Wat eerst? En wat doe je met die ene bevinding waarvan de oplossingsrichting onduidelijk is voor jouw stack?

Daarom is het rapport niet het eindpunt. Tijdens de fase waarin je problemen oplost, blijven we bereikbaar. Geen formeel ticket-systeem, geen wachtrij, geen account manager die jouw vraag doorzet. Gewoon een direct kanaal naar de auditor die je rapport heeft geschreven.

In het HTML-rapport heeft elke bevinding een eigen URL. Je opent het rapport, je ziet een bevinding waar je vragen over hebt, je hovert eroverheen en kopieert de directe link. Die link plak je in je chat-bericht of mail naar ons.

Wij openen de link, zien meteen welke bevinding je bedoelt, inclusief de user story, de voorbeelden, en het succescriterium, en geven antwoord. Vaak met een code-suggestie als het een technische vraag is, of met een uitleg in gewone taal als het een vraag van een redacteur of designer is.

Geen “kun je nog eens de pagina-naam doorgeven” of “in welk hoofdstuk staat dit”. De link doet het werk.

Een rapport met honderd bevindingen los je niet in één sprint op. Bij de eerste vraag die binnenkomt zit vaak ook: “Waar beginnen we?” We denken daarin mee, en kijken naar drie dingen tegelijk.

• Impact op de gebruiker. Een blokkerende bevinding, zoals een formulier dat een schermlezer niet kan invullen, gaat voor een esthetisch probleem zoals een te lichte placeholder-kleur. Het impact-label in het rapport (blokkerend / ernstig / gemiddeld / laag) is je startpunt.
• WCAG-niveau. We toetsen op WCAG 2.2 niveau A en AA, daar blijft het bij. Een veelgebruikte manier om volgorde te bepalen: los eerst alle A-bevindingen op, want die wegen het zwaarst voor een toezichthouder. Daarna pak je AA.
• WCAG 2.1 of 2.2. WCAG 2.1 geldt nog steeds als standaard. Het verschil met WCAG 2.2 zit in vijf nieuwe succescriteria. Een veilige route: los eerst alle bevindingen op die ook al onder WCAG 2.1 vielen, en pak daarna de vijf nieuwe criteria uit WCAG 2.2 aan. Daarmee voldoe je in twee stappen aan de actuele standaard.
• Toetsenbord als hefboom. Veel hulpsoftware werkt via het toetsenbord, bijvoorbeeld schermlezers. Pak je in één keer alle bevindingen rondom toetsenbordbediening, focuszichtbaarheid en focusvolgorde aan, dan maak je je website meteen toegankelijker voor een breed scala aan hulpmiddelen. Vaak een efficiënte volgende stap na de A-bevindingen.
• Kosten van de fix. Sommige bevindingen los je centraal in één component op. Die zijn vaak goedkoper dan ze lijken, ook al staan ze op honderd pagina’s. Andere zijn duur, bijvoorbeeld een framework-keuze die heel diep zit. We helpen dat onderscheid maken voordat je je sprint vult.

Een paar vragen tussendoor zit standaard bij elke audit. Verwacht je structureel meer, denk aan sprint-testing, code reviews op pull requests, mini-audits op nieuwe componenten, dan past een strippenkaart beter. Dat is een vooraf afgesproken aantal uren dat je flexibel inzet, zonder dat we per vraag offertes hoeven te sturen.

De strippenkaart is geen verplichte vervolgstap. Veel klanten ronden hun audit af zonder hem, en komen pas terug bij een heronderzoek of een volgende audit. Maar als je weet dat je ons vaker nodig hebt, is het de simpelste manier om snel te schakelen.

Wij bouwen niet, beheren geen content, verkopen geen software. Geen plug-ins, geen toegankelijkheids-widgets, geen abonnement waarmee je “in één klik compliant” wordt. Wij geven advies: onafhankelijk, zonder belangenconflict.

Dat betekent dat we soms zullen zeggen: hier zou je beter een ontwikkelaar voor inschakelen, hier moet je redactie aan de bak, hier loopt het scheef met je leverancier en moeten zij dit oplossen. Onze begeleiding helpt je de juiste vraag op het juiste bord te leggen, niet om elk probleem in onze eigen agenda te schuiven.