Skip to main content

Methodologie

De audit is het product. Hoe de audit wordt uitgevoerd is het waardevoorstel. Op deze pagina wordt per dag uitgelegd waar de 2 weken durende EAA Readiness Audit feitelijk uit bestaat. Alles wat in de vaste prijs van €2.400 staat, staat hieronder; alles wat niet in deze lijst staat, valt expliciet buiten de scope.

Voor de audit - Intake (async)

Een schriftelijke vragenlijst van 10 items die een week voor de kickoff wordt teruggestuurd. Hierop staan:

  • URL's en sjablonen binnen het bereik
  • Talen en locale varianten
  • Breakpoints om te testen (meestal 320 px / 768 px / 1280 px)
  • Eerdere beoordelingen of audits (intern of extern)
  • Specifieke conformiteitsclaims die de klant geverifieerd wil hebben
  • PDF's, video, audio of niet-webdocumenten in het bereik
  • Regelgevende deadlines (aanbesteding, RFP, EAA handhavingsvenster)
  • Demografische gegevens van de primaire gebruiker (gebruik van hulptechnologie, indien bekend)
  • Het framework van het engineeringteam + CI-tooling
  • Alles waarvan de klant al weet dat het kapot is

Het terugsturen van de vragenlijst maakt van de kickoff op dag 1 een bevestiging van de scope in plaats van een ontdekking van de scope - dat is het verschil tussen een kickoff die 30 minuten duurt en een kickoff die 90 minuten duurt.


Binnen de audit - 10 werkdagen

Dag 1 - Kickoff (ochtend) + geautomatiseerde triage start (middag)

Aftrapgesprek van een half uur. Scope brief ondertekend in het gesprek (één paragraaf met vermelding van in-scope eigenschappen, talen, breekpunten en pagina's die expliciet uitgesloten zijn). Het uitleesgesprek op dag 10 is gereserveerd op de kalender voordat ander werk begint, dus de engineering hand-off is vanaf dag één vastgelegd.

Middag: axe-core geconfigureerd tegen elke in-scope sjabloon. Triage van problemen begint.

Dag 2 - Geautomatiseerde triage + catalogiseren van componenten

axe-core triage voortgezet - problemen geclusterd op succescriterium, niet op URL, zodat de SC opsommingstabel van dag 9 goed in kaart kan worden gebracht. Problemen met duplicaten zijn samengevoegd tot één SC-item met de betreffende URL's in de lijst.

Onderdelencatalogus gemaakt: elk interactief onderdeel op de site (modals, accordeons, tabbladen, carrousels, dropdowns, datumkiezers, bestandskiezers, aangepaste selecties, automatische invoer). Elk onderdeel wordt een eenheid voor handmatig testen in dagen 6-7.

Dagen 3-5 - Handmatige schermlezer passeert

Drie platforms, drie lezers, drie dagen:

  • VoiceOver + Safari op macOS - elke pagina in het zicht, leesvolgordepas + interactieve-controlepas
  • VoiceOver + Safari op iOS - elke pagina in het zicht op 320 CSS px breedte, tap-target controle
  • NVDA + Firefox op Windows - dezelfde in-scope set
  • TalkBack + Chrome op Android - voor elke eigenschap waarvan de gebruikersanalyse ≥ 10 % mobiel Android-verkeer laat zien

Bevindingen geregistreerd op basis van de EN 301 549 § 5.7 / WCAG 2.2 vereiste, niet op basis van "de schermlezer zei niets" in het algemeen.

Dag 6 - Formulieren + interactieve componenten

Formulieren eerst: etikettering (SC 1.3.1, 3.3.2), instructies, verplichte-veldaanduiding, foutidentificatie (SC 3.3.1), foutsuggestie (SC 3.3.3), foutpreventie voor juridische / financiële / gegevenswijzigingsstromen (SC 3.3.4), invoerdoel / autoaanvullen (SC 1.3.5).

Vervolgens werd elke gecatalogiseerde component getest aan de hand van de relevante SC's: focusbeheer, toetsenbordondersteuning, ARIA-statuswijzigingen, live-regio-aankondigingen (SC 4.1.3), verminderde bewegingsafhandeling voor geanimeerde componenten (SC 2.3.3).

Dag 7 - Toetsenbord + focus + ARIA-semantiek

Navigeren met alleen toetsenbord in elke flow binnen het bereik. Focusvolgorde (SC 2.4.3), focusvallen in elk modaal/dialoogvenster, focus terugkeren bij sluiten dialoogvenster, focuszichtbaarheid (SC 2.4.7 + 2.4.11), tabindexcontrole (geen waarden boven 0), skip-link-verificatie.

ARIA semantiekcontrole: rol / status / eigenschap correctheid, veelvoorkomend misbruik gemarkeerd (bijv. aria-label op niet-interactieve elementen, overbodige aria-haspopup, ontbrekende aria-expanded op openbaarmakingswidgets, role overschrijvingen die impliciete semantiek bestrijden).

Dag 8 - Multimedia, taal, inhoud artefacten

  • Video: bijschriften (SC 1.2.2), transcripties (SC 1.2.3), audiobeschrijving (SC 1.2.5), autoplay + audioregeling (SC 1.4.2)
  • Audio: transcripties (SC 1.2.1), mediabediening (SC 1.4.2)
  • Taal: lang attribuut op root (SC 3.1.1), inline taalwijzigingen (SC 3.1.2)
  • Contrast + zoom: 4.5:1 AA / 7:1 AAA-in-getest-scope voor elk interactief besturingselement + body-tekstelement; controle op lay-out-verloop bij 320 CSS px en 200 % zoom (SC 1.4.10); controle op afstandswijziging (SC 1.4.12)
  • Cookie-toestemmingsstroom: elke binnen het bereik van de gebruiker zichtbare status van de toestemmingsbanner - dit is de meest voorkomende controlebevinding op EU-sites en wordt behandeld als een afzonderlijk oppervlak
  • Help-/ondersteuningsdocumentatie: EN 301 549 clausule 12 (documentatie + ondersteuning) - vaak weggelaten uit audits, hier standaard binnen bereik

Dag 9 - EN 301 549 SC opsomming + toegankelijkheidsverklaring

Vergelijk alle bevindingen met de EN 301 549 V3.2.1 succes-criterium mapping. Maak de SC-opsommingstabel - de documentopdracht vraagt naar: elke SC die van toepassing is, de goedkeurings- / afkeurings- / n.v.t.-status ervan in het geteste toepassingsgebied, en de specifieke bevindingen die deze status ondersteunen.

Opstellen van de EN 301 549 § 9.6 / Uitvoeringsbesluit (EU) 2018/1523 toegankelijkheidsverklaring, klaar om te publiceren op de /accessibility URL van de klant op dag 11. Zie de Urenvoorwaardenverklaring voor het formaat.

Dag 10 - Uitlezen (60 min) + overdracht

Eén schermdeling met engineering. Doorloop de bevindingen in volgorde van prioriteit, beantwoord vragen, markeer welke SC's het team van plan is intern te herstellen vs. door te verwijzen.

Het pakket met deliverables overhandigen: SC-opsommingstabel, geprioriteerde saneringsrichtlijnen, conceptverklaring, axe-core CI-configuratie klaar om in de pijplijn van de klant te plaatsen.


Wat elke bevinding inhoudt

Elke bevinding in de SC opsommingstabel bevat:

  • SC referentie: de specifieke WCAG 2.2 + EN 301 549 succescriterium identifier en het niveau (A / AA / AAA)
  • Severity: kritiek / ernstig / matig / licht - in kaart gebracht aan de hand van het bestaande P0-P3 / S1-S4 schema van de klant tijdens de kickoff
  • Gebruikersimpact: welke gebruikersgroepen worden beïnvloed (gebruikers met schermlezers, gebruikers met alleen een toetsenbord, slechtziende gebruikers, gebruikers met cognitieve beperkingen, gebruikers met motorische beperkingen)
  • Geschatte inspanning: ontwikkelaar-uren, in bandbreedte (≤ 1 h / 1-4 h / 4-8 h / 8+ h)
  • Betrokken URL's of onderdelen: de specifieke oppervlakken waarop de bevinding van toepassing is
  • Minimaal reproduceerbaar voorbeeld: voldoende HTML / CSS / JS om afzonderlijk te reproduceren
  • Aanbevolen fix: code om te plakken, gekoppeld aan het framework dat in de intake wordt genoemd (React + ARIA, Vue + ARIA, gewone HTML, enz.)

Dit is de deliverable-vorm die het vaakst ontbreekt bij goedkopere audits - er wordt een PDF overhandigd; bij deze audit wordt een issue tracker geïmporteerd.


Wat er niet in de methodologie staat

Het negatieve vermelden maakt deel uit van het contract. Het volgende valt buiten het bereik van de 2-weekse audit en is gedocumenteerd in Wat ik niet verkoop:

  • Gebruikerstests met gehandicapte gebruikers - andere opdracht, doorverwezen naar een specialist
  • Penetratietesten / beveiligingsaudit - buiten het bereik, andere specialiteit
  • Schrijven van sanerings-PR's - dat is de saneringssprint, die ik niet verkoop
  • Her-audit na sanering - aparte opdracht, ingepland tijdens de read-out call
  • Meerdaagse teamtraining - doorverwezen naar een Nederlandse a11y-training specialist. De Day-10 read-out (een uur, screen-sharing met engineering, doornemen van bevindingen) is inbegrepen in elke audit
  • Native mobile - doorverwezen (zie scope pagina)
  • AI / ML-gemedieerde UX - doorverwezen (zie scope pagina)

Scope-uitbreidingen (geprijsd bij kickoff)

Deze zijn in scope tegen het dagtarief van de audit als u ze bij de kickoff toevoegt:

  • PDF's: €1.200 per cluster van maximaal 10 documenten (PDF/UA-tagcontrole, semantische structuur, alt-tekst, leesvolgorde)
  • Multi-language: elke extra taal die wordt gecontroleerd kost €600 per locale (gaat uit van gelijke inhoud; nieuwe onderdelen per locale zijn extra)
  • Multiregio/multimerk: tegen €1.200 / dag, bepaald bij de kickoff

Hoe de prijs uitpakt

Een vaste prijs van € 2.400 dekt de 10 werkdagen die hierboven beschreven staan voor één enkel object in de scoop, één enkele taal, één enkel merk, alleen voor het webplatform. De intakevragenlijst en de start op dag 0 worden niet apart in rekening gebracht.

€1.200 / dag voor meerdere domeinen, meerdere regio's of meerdere talen. Het aantal dagen wordt bepaald bij het startgesprek. Alles in dit nummer is wat er op deze pagina staat.

Twee weken. Eén auditor. Eén rapport. Vergelijk met een audit van een bureau: een gemiddelde offerte in het middensegment is €15.000-30.000 voor een vergelijkbare reikwijdte, waarbij het grootste deel naar projectmanagers, accountdirecteuren en de overhead van het bureau gaat. Ik reken niets voor het organigram.


Laatst beoordeeld

Methodologie voor het laatst herzien 2026-05-18. Als een stap in de dag-voor-dag hierboven verandert, wordt de datum hier bijgewerkt en blijft de vorige versie in de git geschiedenis staan.