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 en geen wachtrij: als klant met een rapport van ons heb je een direct kanaal naar de auditor die het geschreven heeft.

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.

Vragen stel je met een strippenkaart: één strip is één vraag over één onderwerp. Dat werkt voor een losse vraag tussendoor en voor structureel meer, denk aan sprint-testing, code reviews op pull requests of mini-audits op nieuwe componenten. Zo hoeven we per vraag geen offerte te sturen.

De strippenkaart is geen verplichte vervolgstap. Veel klanten ronden hun audit af zonder hem, en komen pas terug bij een hercontrole 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 en beheren geen content. Geen toegankelijkheids-widgets, geen overlay, geen abonnement waarmee je “in één klik compliant” wordt. We keuren dus nooit ons eigen werk, en we hebben geen belang bij een uitkomst.

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.