RGAA-audit: het verloop week per week, de voorbereiding en het rapport lezen

Een RGAA-audit meet criterium per criterium in welke mate een website, een app of een softwarepakket voldoet aan het Franse Référentiel général d’amélioration de l’accessibilité (RGAA). In Frankrijk is die audit de verplichte basis van elke toegankelijkheidsverklaring, en het is precies die verklaring die de Franse toezichthouder Arcom bij zijn controles nagaat. De meeste pagina’s over het onderwerp beschrijven de methode; deze gids toont hoe de audit in de praktijk verloopt, week per week, wat uw organisatie moet voorbereiden, hoe de steekproef tot stand komt, wat de opleveringen bevatten en hoe u het rapport leest zonder specialist in digitale toegankelijkheid te zijn.

RGAA-audit: wat hij meet, en wat hij niet meet

De RGAA, vandaag in versie 4.1.2, telt 106 criteria, verdeeld over 13 thema’s: afbeeldingen, frames, kleuren, multimedia, tabellen, links, scripts, verplichte elementen, structuur van de informatie, presentatie van de informatie, formulieren, navigatie en raadpleging. Elk criterium is opgedeeld in precieze tests, die de auditor vertellen wat hij in de code en in de weergave moet controleren. Het referentiekader vertaalt zo de eisen van de WCAG naar een rooster waarmee twee bekwame auditors op dezelfde pagina tot hetzelfde resultaat komen.

Een RGAA-audit levert drie dingen op: een status voor elk criterium op elke beoordeelde pagina (gevalideerd, niet gevalideerd of niet van toepassing), een conformiteitsgraad voor de dienst als geheel, en de gelokaliseerde lijst van fouten die gecorrigeerd moeten worden. Hij beoordeelt niet de esthetiek, niet de algemene gebruiksvriendelijkheid en niet de redactionele kwaliteit. Een website kan een goede graad halen en toch lastig blijven voor een blinde gebruiker, bijvoorbeeld als de trajecten lang en slecht doordacht zijn. Daarom vormt een test met gebruikers met een beperking een nuttige aanvulling op de conformiteitsaudit: daar ziet u of iemand met een schermlezer een aanvraag ook echt tot het einde kan doorlopen.

De audit is evenmin het draaien van een automatische tool. Browserextensies spotten een deel van de technische fouten, maar ze kunnen niet beoordelen of een tekstalternatief relevant is, of de leesvolgorde zinvol is, of een uitklapmenu met het toetsenbord werkt. De officiële pagina over de conformiteitsbeoordeling (Franstalig) beschrijft een beoordeling criterium per criterium, op een representatieve steekproef: die beoordeling, en alleen die, vormt de basis van de graad die in de verklaring wordt gepubliceerd.

Wie een RGAA-audit moet laten uitvoeren

In Frankrijk legt artikel 47 van de wet van 11 februari 2005 de toegankelijkheid en de publicatie van een verklaring op aan publiekrechtelijke rechtspersonen, aan private organisaties die onder voorwaarden een opdracht van openbare dienstverlening of van algemeen belang vervullen, en aan ondernemingen waarvan de in Frankrijk gerealiseerde omzet meer dan 250 miljoen euro bedraagt. Voor die organisaties is de RGAA-audit geen keuze: zonder daadwerkelijke beoordeling kan de verklaring alleen de status “non conforme” (niet conform) vermelden. De reikwijdte en de teksten worden toegelicht op onze pagina digitale toegankelijkheid in Frankrijk en in onze analyse van de Franse verplichtingen.

Voor een Belgische lezer is dat relevant zodra uw organisatie een Franse dienst exploiteert: een Franse dochteronderneming, een webwinkel die zich op de Franse markt richt, een gezamenlijke publieke dienst in een grensregio. Het is de Franse wet die bepaalt of die dienst onder artikel 47 valt, niet de plaats waar uw hoofdzetel of uw webbureau gevestigd is.

Een onderneming die onder de European Accessibility Act valt maar die omzetdrempel niet bereikt, volgt een andere logica: haar verplichtingen vloeien voort uit het Franse consumentenwetboek (code de la consommation), met de Europese norm EN 301 549 als technische referentie, en de Franse consumentenautoriteit DGCCRF ziet erop toe. Een audit op basis van de WCAG en de Europese norm, zoals onze conformiteitsaudit, beantwoordt daar directer aan dan een RGAA-audit in de strikte zin, ook al is de werkwijze zeer gelijkaardig. Ons artikel over de European Accessibility Act verduidelijkt welke diensten betrokken zijn.

Wanneer een RGAA-audit uitvoeren: de zeven situaties die hem uitlokken

De vraag is niet alleen of u moet auditeren, maar ook wanneer. De RGAA legt termijnen op voor het bijwerken van de verklaring, en elk van die termijnen veronderstelt een recente audit. Andere situaties zijn geen verplichting, maar maken een audit onmisbaar om te vermijden dat u een onjuiste status publiceert.

De vierde rij verdient vooruitziendheid. De DINUM, de Franse interministeriële directie voor digitale zaken, heeft de publicatie van de RGAA 5, verwacht eind 2026 (Franstalig) aangekondigd. Die versie integreert de WCAG 2.2 en zal criteria bevatten voor mobiele apps en kantoordocumenten. De DINUM benadrukt dat werkzaamheden op basis van de RGAA 4.1.2 in geen geval mogen worden opgeschort of uitgesteld: een audit die u vandaag uitvoert, blijft nuttig, de correcties blijven geldig, en de verklaring die eruit voortvloeit, geniet de termijn van achttien maanden.

Wacht dus niet op de nieuwe versie om te beginnen. Een organisatie die haar audit een jaar uitstelt in afwachting van de RGAA 5, publiceert intussen een verklaring zonder graad, of een verouderde, en verliest een jaar aan correcties die in elk geval nodig zijn: een veld zonder label of een toetsenbordval blijft een fout, welke versie van het referentiekader ook geldt.

Bij opleveringen door leveranciers neemt de audit de vorm aan van een toegankelijkheidsoplevering: vóór de aanvaarding wordt nagegaan of de geleverde sjablonen en trajecten voldoen aan de criteria die in het contract zijn opgenomen. Dat is veel efficiënter dan de fouten pas bij de volgende conformiteitsaudit te ontdekken, wanneer de leverancier al vertrokken is en elke correctie een nieuwe bestelling vergt.

Een RGAA-audit voorbereiden: de checklist voor de geauditeerde organisatie

De meeste vertragingen bij een audit komen niet van de auditors, maar van toegangen die ontbreken op de dag dat de tests beginnen: een geblokkeerd testaccount, een testomgeving die niet beschikbaar is, een betaalstap die niet te passeren valt. Een voorbereiding van enkele dagen voorkomt dat u een week verliest. Dit vragen wij in de praktijk vóór de startvergadering.

• De exacte scope: adres van de dienst, subdomeinen die wel of niet meetellen, beveiligde zones, mobiele apps, downloadbare documenten;
• de geldende toegankelijkheidsverklaring, het meerjarenplan en het actieplan, ook als ze oud zijn, om het verschil te meten en te hergebruiken wat bruikbaar is;
• de bezoekersstatistieken van de meest geraadpleegde pagina’s, nuttig om de steekproef representatief te maken;
• de lijst van sjablonen of paginatypes (artikel, fiche, lijst met zoekresultaten, formulier, dashboard) en van gedeelde componenten (menu, zoekfunctie, carrousel, modale vensters);
• testaccounts voor elk gebruikersprofiel, met realistische gegevens: een leeg account toont geen dashboard en geen geschiedenis;
• een manier om de gevoelige stappen te passeren: een testbetaalkaart, een code voor sterke authenticatie die een bereikbare contactpersoon doorgeeft, een tijdelijke omzeiling van een captcha in de testomgeving;
• de downloadbare documenten die bij de procedures horen: pdf-formulieren, aanslagbiljetten, facturen, verslagen;
• de lijst van modules van derden (afspraken maken, betaling, kaarten, chatbot) en de naam van hun leverancier;
• een technische contactpersoon die tijdens de tests beschikbaar is, en de datum van de wijzigingsstop: een website die tijdens de audit verandert, levert onsamenhangende resultaten op;
• de kalender van de randvoorwaarden: geplande lancering, controletermijn, stuurgroep waar de resultaten moeten worden voorgesteld.

Twee punten worden vaak onderschat. Eerst de modules van derden: een afsprakentool die u bij een softwareleverancier hebt gekocht, maakt deel uit van uw dienst, want u hebt hem gekozen en u betaalt hem. Hij wordt geauditeerd zoals de rest, en zijn fouten staan in uw verklaring. Vervolgens de omgeving: auditeren in pre-productie is mogelijk en vaak te verkiezen, op voorwaarde dat die versie identiek is aan de versie die gepubliceerd zal worden en dat de verklaring wel degelijk de online dienst aanwijst.

Een praktisch voorbeeld maakt het verschil duidelijk. Een organisatie die een testaccount aanmaakt zonder lopende aanvraag, laat de auditor een leeg dashboard zien: geen tabel met statussen, geen berichten, geen downloadbaar document. De auditor beoordeelt dan een scherm dat geen enkele echte gebruiker zo te zien krijgt, en de moeilijkste onderdelen ontsnappen aan de audit. Vul de testaccounts dus vooraf met enkele aanvragen in verschillende stadia: ingediend, in behandeling, afgerond.

De steekproef van de RGAA-audit samenstellen: de officiële regels en een voorbeeld met toelichting

U auditeert niet alle pagina’s van een website: u auditeert een steekproef, en het resultaat geldt voor de volledige dienst. Daarom is de samenstelling van de steekproef de belangrijkste beslissing van de audit. Een steekproef uit gemakzucht levert een flatterende graad op die niet bestand is tegen de eerste pagina die een controleur willekeurig opent.

Wat de methode oplegt

De officiële methode vraagt eerst om, voor zover ze bestaan, de homepage, de contactpagina, de wettelijke vermeldingen, de pagina Toegankelijkheid, de sitemap, de hulppagina en de aanmeldpagina te auditeren. Daarbij komen minstens één relevante pagina per type dienst, zoekfunctie inbegrepen, minstens één relevant downloadbaar document per type dienst, alle pagina’s van een proces (een formulier of transactie in meerdere stappen) en pagina’s met een duidelijk verschillend uitzicht of een duidelijk verschillende inhoud: tabellen, multimedia, formulieren. Willekeurig gekozen pagina’s moeten minstens 10 % van de pagina’s in de steekproef uitmaken. Er is geen totaal aantal pagina’s vastgelegd; bij een mobiele app geldt elk scherm als een pagina.

Uit die opbouw volgt een regel die voor de trajecten alles verandert: een criterium is voor een pagina van een proces alleen gevalideerd als het voor alle pagina’s van dat proces gevalideerd is. Bevat de derde stap van een online aanvraag een veld zonder label, dan is het betrokken criterium niet gevalideerd voor alle stappen van het traject.

Voorbeeld: de gebruikerszone van een openbare instelling

Neem de website van een openbare instelling die algemene informatie biedt en een beveiligde zone waar gebruikers een steunaanvraag indienen en de behandeling ervan opvolgen. Een verdedigbare steekproef zou er zo kunnen uitzien.

Deze steekproef telt een twintigtal pagina’s en schermen, waaronder de vier stappen van de aanvraag. Er zit een reflex in die u best aanhoudt: elke functie die een gebruiker zelfstandig moet kunnen uitvoeren (aanmelden, indienen, opvolgen, downloaden), komt minstens één keer voor. Wie het dashboard of de pdf weglaat omdat ze moeilijk te testen zijn, haalt precies uit de audit wat de gebruikers blokkeert.

De lijst van geauditeerde pagina’s staat vervolgens in de toegankelijkheidsverklaring, met hun adres. Ze wordt dus openbaar: elke gebruiker, en ook de Arcom, kan nagaan of de steekproef de processen wel bevat. Ons artikel over de toegankelijkheidsverklaring legt uit hoe u die lijst presenteert en welke berekening eruit volgt.

Het verloop van een RGAA-audit, week per week

In ons kantoor bedraagt de gemiddelde doorlooptijd van een audit drie weken tussen de start en de overhandiging van het rapport. Die termijn varieert met de omvang van de steekproef, het aantal trajecten en platformen, en de beschikbaarheid van de toegangen. Het onderstaande verloop geldt voor een website van gangbare complexiteit, met een beveiligde zone.

1. Vóór de start: de afbakening. Een gesprek van een uur of twee legt het referentiekader en de versie ervan vast, de scope, de voorlopige lijst van de steekproef, de testomgeving en de contactpersonen. U bezorgt de elementen van de voorbereidingschecklist. De auditor controleert de toegangen en meldt meteen wat ontbreekt.
2. Week 1: validatie van de steekproef en eerste tests. De steekproef wordt samen met u vastgelegd, willekeurig gekozen pagina’s inbegrepen. De auditor begint met de verplichte pagina’s en de gedeelde componenten (header, menu, footer, zoekfunctie): een fout in een gemeenschappelijke component herhaalt zich op alle pagina’s, en wie ze vroeg identificeert, hoeft ze geen twintig keer te beschrijven.
3. Week 2: trajecten, formulieren en hulptechnologieën. De processen worden stap voor stap geauditeerd, met de testaccounts. De dynamische componenten (uitklapmenu’s, tabbladen, modale vensters, foutmeldingen, inhoud die bij muisaanwijzing verschijnt) worden gecontroleerd met schermlezers en met het toetsenbord. De downloadbare documenten worden nagekeken. Een tussentijds overleg meldt eventuele grote blokkades, zonder op het rapport te wachten.
4. Week 3: consolidatie, rapport en presentatie. De resultaten worden op het niveau van de dienst geconsolideerd, de conformiteitsgraad wordt berekend, en elke non-conformiteit wordt beschreven met een voorbeeld en een aanbeveling. Een interne nalezing controleert of de statussen tussen pagina’s samenhangend zijn. De presentatie licht de resultaten toe aan de business- en technische teams, waarna het rapport, het auditrooster en het ontwerp van verklaring worden overhandigd.
5. Na de overhandiging: de correcties en de hercontrole. Uw teams of leveranciers corrigeren volgens het actieplan. Een kortere hercontrole verifieert de correcties op dezelfde pagina’s, en de verklaring wordt bijgewerkt met de nieuwe graad.

Twee factoren verlengen die planning bijna altijd: een toegang die ontbreekt op het moment van de tests in de tweede week, en een productierelease tijdens de audit. Het eerste lost u op met een goede voorbereiding, het tweede met een wijzigingsstop, of bij gebrek daaraan met de datum van de geauditeerde versie die in het rapport wordt vermeld.

Het tussentijdse overleg in de tweede week is meer dan een formaliteit. Als de auditor dan al vaststelt dat de knop om een aanvraag in te dienen niet met het toetsenbord bereikbaar is, kan uw ontwikkelteam de correctie inplannen terwijl de audit nog loopt. Zo verliest u geen drie weken, en kan de hercontrole sneller volgen.

Wat de auditor echt doet: tests, tools en testomgeving

Voor elke pagina van de steekproef overloopt de auditor de 106 criteria. Een groot deel is op een bepaalde pagina niet van toepassing (geen video, geen tabel, geen frame); de andere worden test per test gecontroleerd, in de code en in de weergave. Zodra één element van de pagina niet slaagt voor een test, is het criterium voor die pagina niet gevalideerd.

Een voorbeeld: het online aanvraagformulier

Op één enkele stap van een formulier controleert de auditor onder meer of elk veld een label heeft (criterium 11.1) en of de knoppen een expliciete benaming hebben (criterium 11.9), of de invoercontrole fouten en verplichte velden waarneembaar aangeeft, ook voor schermlezers (criterium 11.10), of de scripts die velden tonen of verbergen compatibel zijn met hulptechnologieën (criterium 7.1) en met het toetsenbord bruikbaar zijn (criterium 7.3), of de focus zichtbaar blijft (criterium 10.7), of de tabvolgorde logisch is (criterium 12.8) en of de gebruiker nooit vast komt te zitten met het toetsenbord (criterium 12.9). Hij meet de contrasten van de tekst (criterium 3.2) en van de veldranden (criterium 3.3), en controleert of informatie niet alleen met kleur wordt gegeven, bijvoorbeeld een foutief veld dat enkel rood omrand is.

Die opdeling verklaart waarom één enkele fout de graad duur kan komen te staan: een ontbrekende of slecht aan het veld gekoppelde foutmelding maakt criterium 11.10 niet gevalideerd op de pagina, dus op het hele proces, dus voor de dienst. Ze verklaart ook waarom een slecht ontworpen component die in alle formulieren van de website terugkomt, in één keer gecorrigeerd kan worden.

De tools en de testomgeving

De auditor werkt met de code-inspector van de browser, een contrastanalyse-tool, controle-extensies die het opsporen van repetitieve fouten versnellen, en een systematische navigatie met het toetsenbord. Voor dynamische componenten controleert hij de weergave met hulptechnologieën. De RGAA publiceert een referentietestomgeving (Franstalig): op de computer combinaties van NVDA of JAWS met Firefox, en VoiceOver met Safari; op mobiel TalkBack met Chrome onder Android en VoiceOver met Safari onder iOS. Een component wordt als compatibel beschouwd als hij volledig werkt met minstens één combinatie; voor een website voor het grote publiek die op mobiel wordt geraadpleegd, raadt het referentiekader aan in beide omgevingen te testen.

De gebruikte combinaties, de tools en hun versies worden vervolgens in het rapport en in de verklaring vermeld. Dat is een garantie voor u: een resultaat dat met een niet-gedocumenteerde combinatie is verkregen, zou bij de hercontrole moeilijk te reproduceren zijn.

De opleveringen van een RGAA-audit: rapport, auditrooster, actieplan en verklaring

De DINUM stelt een auditkit (Franstalig) ter beschikking met een model van rapport, een model van verklaring en het auditrooster van de RGAA 4.1.2 als spreadsheet; dezelfde pagina stelt Ara voor, een online tool die de invoer van de resultaten structureert en rapport en verklaring genereert. Ara is geen automatische tool: hij veronderstelt een auditor die de 106 criteria kent. Een professionele audit steunt op die modellen of neemt hun structuur over, zodat twee opeenvolgende audits vergelijkbaar zijn.

Het officiële model van auditrapport (pdf, Franstalig) ordent de beschrijving van de fouten per thema. Voor elk niet-conform criterium voorziet het een beknopte voorstelling van het criterium, een representatief geval met zo nodig een schermafbeelding, de beschrijving van het probleem en een technische aanbeveling. De conclusie bevat een advies van de auditor, geschreven voor een niet-technisch publiek, en een prioritering van de correcties volgens drie assen: de essentiële functies en inhoud, de criteria die de toegang blokkeren, en het gemak van uitvoering. Het auditrooster, in bijlage, geeft de resultaten pagina per pagina.

Eis dat elke non-conformiteit gelokaliseerd is (pagina, component, element) en vergezeld gaat van een aanbeveling waar een ontwikkelaar mee aan de slag kan. Een regel als “criterium 1.1 niet conform” zonder voorbeeld dwingt uw teams een deel van de audit over te doen om de fouten terug te vinden.

Let ook op de taal van de opleveringen. Voor een Franse dienst zijn het rapport en de verklaring in het Frans opgesteld, omdat ze bestemd zijn voor Franse gebruikers en de Franse toezichthouder. Werkt uw ontwikkelteam in Vlaanderen of Brussel, vraag dan bij de afbakening of het actieplan of de technische aanbevelingen ook in het Nederlands of het Engels beschikbaar kunnen zijn: dat voorkomt vertaalfouten in de tickets van uw ontwikkelaars.

Een RGAA-auditrapport lezen zonder expert te zijn

Een rapport van vijftig pagina’s kan een directeur of een verkozene afschrikken. Toch leest u het in tien minuten, als u weet waar u moet kijken en in welke volgorde.

1. De globale conformiteitsgraad. Dat is de verhouding tussen de gevalideerde criteria en de toepasselijke criteria, berekend over de hele steekproef: (gevalideerde criteria ÷ toepasselijke criteria) × 100. Een graad van 100 % betekent een volledig conforme dienst, een graad van minstens 50 % een gedeeltelijk conforme dienst, daaronder is hij niet conform. Die graad, en alleen die, staat in de verklaring.
2. De gemiddelde graad. Dat is het gemiddelde van de graden van de afzonderlijke pagina’s. Hij ligt bijna altijd hoger dan de globale graad, omdat een geïsoleerde fout maar op één pagina doorweegt. Nuttig om een vooruitgang op te volgen, maar hij vervangt nooit de globale graad.
3. Het aantal toepasselijke criteria. Een zeer laag aantal toepasselijke criteria moet vragen oproepen: ofwel is de dienst echt eenvoudig, ofwel is inhoud weggelaten. Niet-toepasselijke criteria zijn alleen gerechtvaardigd als de inhoud niet bestaat, als hij vrijgesteld is of als er een afwijking geldt met een toegankelijk alternatief.
4. De blokkades, vóór het aantal fouten. Zoek in de samenvatting naar de fouten die verhinderen een taak uit te voeren: aanmelden, betalen, een aanvraag indienen, een aanslagbiljet downloaden. Een contrastfout op een bijkomende vermelding en een bevestigingsknop die niet met het toetsenbord werkt, tellen elk voor één criterium, maar hebben niet hetzelfde effect.
5. De gedeelde componenten. Spoor de fouten op die uit het sjabloon, het menu of de componentenbibliotheek komen: hun correctie verbetert in één keer alle pagina’s.
6. De inhoud die u niet zelf in de hand hebt. Noteer de fouten die aan een module van een leverancier te wijten zijn. Die pakt u aan via de contractuele relatie, niet via uw eigen ontwikkelaars.

Neem een steekproef waarin 52 criteria van toepassing zijn en 39 gevalideerd: de graad bedraagt 75 %, de dienst is gedeeltelijk conform. Als de gemiddelde graad per pagina 88 % haalt, betekent dat dat de meeste van de 13 falende criteria maar op één of twee pagina’s falen, vaak in hetzelfde traject. De juiste lezing is dus: een dienst die globaal correct is, met één traject dat prioritair moet worden herwerkt. De gedetailleerde berekening en de valkuilen ervan worden uitgewerkt in ons artikel over de toegankelijkheidsverklaring en de conformiteitsgraad.

Voor een stuurgroep werkt een eenvoudige vertaling vaak het best: welke taken kan een gebruiker met een schermlezer of met alleen het toetsenbord vandaag niet zelfstandig uitvoeren, en wanneer is dat opgelost? Wie het rapport zo samenvat, krijgt sneller budget voor de correcties dan wie alleen een percentage toont.

Wat een controle van de Arcom onthult over de kwaliteit van een audit

Sinds 2023 controleert de Arcom de naleving van artikel 47. Haar beslissing nr. 2026-358 van 24 juni 2026 over de website impots.gouv.fr, het portaal van de Franse belastingdienst (gepubliceerd in het Franse Staatsblad, Journal officiel), is leerrijk voor wie een audit voorbereidt, omdat de vastgestelde fouten precies betrekking hebben op de inhoud die steekproeven uit gemakzucht weglaten.

• een aanslagbiljet in pdf, te downloaden vanuit de persoonlijke zone, zonder titel, zonder opgegeven taal, zonder tagging en zonder toegankelijk alternatief (criterium 13.3);
• in de beveiligde berichtendienst een rubriek “Écrire” (Schrijven) die niet met de tabtoets bereikbaar is en waarvan de informatie niet door schermlezers wordt weergegeven (criterium 10.8);
• in dezelfde berichtendienst een uitklapmenu om het aanslagjaar te kiezen dat alleen met de muis verschijnt, en dus niet met het toetsenbord bruikbaar is (criterium 12.11);
• in het formulier voor de online aangifte van de inkomsten (rubriek over niet-professionele gemeubelde verhuur) een tabel waarvan de cellen niet aan hun koppen gekoppeld zijn (criterium 5.7);
• een dienst waarvan de verklaring geen enkele graad vermeldde, bij gebrek aan een audit.

Documenten die uit een beveiligde zone worden gedownload, een berichtendienst, dynamische keuzemenu’s, tabellen in een formulier: al die inhoud zit achter een authenticatie. Een audit die zich tot de openbare pagina’s beperkt, ziet ze niet. De autoriteit gaf negen maanden om de toegankelijkheidsfouten te corrigeren en twee maanden om de toegankelijkheidsverklaringen in orde te brengen en het actieplan van het lopende jaar te publiceren. Voor de publieke sector sluiten die eisen aan bij de overheidsopdrachten en de aansturing die we beschrijven op onze pagina publieke sector.

De les geldt ook buiten Frankrijk. Elke overheid die online aangiftes, aanvragen of berichten aanbiedt, heeft dezelfde soort inhoud achter een aanmelding: een aanslagbiljet, een attest, een beveiligde mailbox. Wie de steekproef van zijn audit samenstelt, begint dus best bij de vraag welke documenten en schermen een gebruiker pas na aanmelding te zien krijgt.

Na de RGAA-audit: correcties, hercontrole en verklaring

De audit verbetert op zich niets; het zijn de correcties die het leven van de gebruikers en de graad veranderen. De periode na de overhandiging van het rapport bepaalt hoeveel de investering waard is.

Meteen een juiste status publiceren

Publiceer zodra het rapport is overhandigd de verklaring die bij de resultaten hoort, ook als ze ongunstig zijn, en stem de vermelding op de homepage daarop af. Een juiste verklaring “gedeeltelijk conform” vervult de transparantieplicht; wachten tot alle correcties klaar zijn om te publiceren, betekent dat er maandenlang een onjuiste status of helemaal geen verklaring online staat.

In de juiste volgorde corrigeren

Begin met de blokkades op de essentiële trajecten, daarna de gedeelde componenten, ten slotte de geïsoleerde fouten. Neem elke correctie op in de normale ontwikkelcyclus, met een acceptatiecriterium dat de test van de RGAA overneemt: zo voorkomt u een terugval bij de volgende versie. Wanneer de fouten in de architectuur van de front-end zitten, voorkomt begeleiding bij toegankelijke ontwikkeling dat u pagina per pagina corrigeert wat in de componentenbibliotheek kan worden opgelost.

Concreet: schrijf voor elk ticket in uw backlog het criteriumnummer, de pagina en de verwachte werking bij gebruik met het toetsenbord en met een schermlezer. Een ticket “toegankelijkheid formulier verbeteren” wordt zelden goed opgelost; een ticket “foutmelding bij het veld Rijksregisternummer programmatorisch aan het veld koppelen en aankondigen aan schermlezers (criterium 11.10)” wel.

Hercontrole en bijwerking

De hercontrole verifieert de correcties op de pagina’s van de oorspronkelijke steekproef. Ze is korter dan de audit, maar moet even rigoureus zijn: een criterium dat op één pagina gecorrigeerd is en op een andere nog faalt, blijft niet gevalideerd. De nieuwe graad wordt in de verklaring opgenomen, met de datum van bijwerking. De niet-gecorrigeerde fouten voeden het actieplan van het jaar, dat aan het meerjarenplan gekoppeld is.

Opleiden om niet opnieuw te beginnen

Een audit brengt bijna altijd fouten aan het licht die met werkwijzen te maken hebben: alternatieve teksten bij afbeeldingen die zonder methode worden geschreven, pdf’s die zonder tagging worden geëxporteerd, componenten die van het ene project naar het andere worden gekopieerd. Opleidingen op maat van elk beroep (redactie, ontwerp, ontwikkeling, aankoop) verminderen duurzaam het aantal fouten bij de volgende audit.

Interne of externe RGAA-audit: hoe kiezen en offertes vergelijken

De officiële methode aanvaardt zowel zelfevaluatie als een audit door een derde, op voorwaarde dat hij betrouwbaar en representatief is: de organisatie waakt met alle middelen over de betrouwbaarheid van haar verklaring, of het nu gaat om een externe dienstverlener, opgeleide interne experts of kruisaudits. De ondernemingen van punt 4° van artikel 47, die de omzetdrempel overschrijden, mogen zelfs een andere testmethode gebruiken, als die op verzoek kan worden meegedeeld, vergezeld gaat van een concordantietabel met de norm en in de verklaring wordt vermeld.

Een interne audit is zinvol als u beschikt over auditors die in de RGAA zijn opgeleid, die met hulptechnologieën werken en die niet zelf de website hebben ontworpen. Een externe blik beperkt het risico op een overschatte graad en levert een bewijs van onafhankelijkheid dat bij een controle nuttig is. Veel organisaties combineren beide: een externe audit om de drie jaar of bij elke vernieuwing, interne controles bij elke versie.

De vragen die u stelt voor u een auditor kiest

• Beoordeelt de audit de 106 criteria manueel, pagina per pagina, of steunt hij op een automatische tool?
• Bevat de voorgestelde steekproef de verplichte pagina’s, de volledige processen, downloadbare documenten en minstens 10 % willekeurig gekozen pagina’s?
• Welke combinaties van hulptechnologieën worden gebruikt, en worden ze in het rapport vermeld?
• Omvatten de opleveringen het volledige auditrooster, een geprioriteerd actieplan en het ontwerp van verklaring?
• Is elke non-conformiteit gelokaliseerd en vergezeld van een correctieadvies?
• Is er een hercontrole voorzien, op welke scope en binnen welke termijn?
• Zijn de auditors onafhankelijk van de teams die de dienst hebben ontworpen of ontwikkeld?

Wat het budget betreft, bestaat er geen referentietarief: de kostprijs hangt af van het aantal pagina’s en sjablonen, de complexiteit van de trajecten, het aantal platformen, de te beoordelen documenten en de bijbehorende diensten. Om twee offertes te vergelijken, gaat u na of ze betrekking hebben op dezelfde steekproef, hetzelfde referentiekader en dezelfde opleveringen. Het eenvoudigst is uw dienst te beschrijven via onze contactpagina: na een afbakeningsgesprek vermelden we de steekproef en de termijn in ons voorstel.

Een offerte die opvallend goedkoper is, beperkt vaak stilzwijgend de steekproef: alleen openbare pagina’s, geen pdf’s, geen hercontrole. Leg de offertes dus naast elkaar aan de hand van de checklist hierboven, en niet alleen aan de hand van het bedrag. Voor een kmo met een eenvoudige website ligt de omvang van een audit uiteraard anders dan voor een overheid met tien e-loketten, maar de vragen blijven dezelfde.

De fouten die een RGAA-audit vertekenen

De volgende fouten komen terug in heel wat rapporten en in gepubliceerde verklaringen. Elk ervan leidt tot een graad die niet overeenstemt met de ervaring van de gebruikers.

1. Alleen de openbare pagina’s auditeren. De procedures, de beveiligde zones en de documenten die daar worden gedownload, concentreren de blokkades.
2. Pagina’s kiezen in plaats van ze willekeurig te trekken. De regel van 10 % willekeurige pagina’s bestaat om vergeten sjablonen aan het licht te brengen.
3. Een proces opsplitsen. De eerste en de laatste stap van een aanvraag auditeren volstaat niet: alle stappen horen bij de steekproef.
4. Het aantal “niet van toepassing” opdrijven. Een criterium is alleen niet van toepassing als de inhoud niet bestaat, als hij vrijgesteld is, of als er een afwijking geldt met een toegankelijk alternatief.
5. Een toolscore verwarren met een conformiteitsgraad. Een automatische score dekt maar een deel van de criteria en beoordeelt de relevantie niet.
6. Modules van derden negeren. Een gekochte en geïntegreerde tool maakt deel uit van de geauditeerde dienst.
7. Een website auditeren die in beweging is. Zonder wijzigingsstop beschrijven de resultaten van een pagina niet langer de online versie.
8. De omgeving niet documenteren. Zonder vermelde testcombinaties kan de hercontrole de resultaten niet reproduceren.
9. De gemiddelde graad publiceren in plaats van de globale graad. De conformiteitsstatus volgt alleen uit de globale graad.
10. De audit als eindpunt beschouwen. Zonder actieplan, correcties en hercontrole geeft de volgende audit hetzelfde resultaat.

RGAA-audit in België, Luxemburg en Zwitserland: wat is het equivalent

De RGAA is een Frans referentiekader. Buiten Frankrijk blijft de werkwijze zeer gelijkaardig, maar het criteriarooster verandert, en een RGAA-audit is niet altijd het beste bewijs van conformiteit.

In Luxemburg neemt de RAWeb de logica van criteria en tests van de RGAA over en past hij die aan de norm EN 301 549 aan; mobiele apps vallen onder de RAAM, die we toepassen in onze RAAM-audit van iOS- en Android-apps. In België is de referentie de Europese norm, in de drie Gewesten. In Zwitserland dient de norm eCH-0059 als referentie voor de overheden. Voor een groep die in meerdere landen actief is, voorkomt een spilreferentiekader dat audits vermenigvuldigd worden: ons artikel over de normen voor digitale toegankelijkheid legt uit hoe u het kiest, en de artikelen over België, Luxemburg en Zwitserland beschrijven de lokale verplichtingen.

Wat dit betekent voor een Vlaamse of Brusselse organisatie

Voor een Vlaamse gemeente, een Brusselse overheidsdienst of een federale instelling is de werkwijze van dit artikel bijna integraal bruikbaar: afbakening, voorbereidingschecklist, steekproef met verplichte pagina’s, volledige processen en willekeurige pagina’s, tests met het toetsenbord en met schermlezers, rapport met gelokaliseerde fouten, actieplan en hercontrole. Wat verandert, is het rooster waartegen de resultaten worden uitgedrukt: in België verwijzen het rapport en de verklaring naar de Europese norm, niet naar de RGAA. Een Belgische verklaring vermeldt dus geen RGAA-graad.

De tests van de RGAA kunnen de auditor wel als werkinstrument dienen, omdat ze de WCAG-criteria in nauwkeurige controlestappen vertalen. Dat is vooral handig voor organisaties die zowel in België als in Frankrijk actief zijn: dezelfde steekproef wordt één keer geauditeerd, en de resultaten worden in beide roosters gerapporteerd. Een conformiteitsaudit volgens EN 301 549 bevat dan het Belgische luik, een RGAA-audit het Franse luik.

Drie praktische punten verdienen extra aandacht bij Belgische websites. Ten eerste de taalversies: een website in het Nederlands, het Frans en soms het Duits of het Engels heeft per taal eigen teksten, alternatieven en documenten. Neem in de steekproef minstens een deel van de pagina’s in elke taalversie op, want tekstalternatieven en pdf’s zijn in de tweede taal vaak minder verzorgd. Ten tweede de documenten: gemeenteraadsbesluiten, reglementen, aanslagbiljetten en attesten in pdf horen in de steekproef, net zoals bij de Franse controle van impots.gouv.fr. Ten derde de gedeelde platformen: veel lokale besturen gebruiken dezelfde softwarepakketten voor e-loketten, afspraken of betalingen. Een fout in zo’n pakket verschijnt dan op tientallen websites tegelijk, en wordt het best via de leverancier aangepakt.

Voor een Vlaamse of Brusselse onderneming die online aan consumenten verkoopt, is het uitgangspunt de European Accessibility Act, met de norm EN 301 549 als technische vertaling. Een RGAA-audit kan nodig zijn voor een Franse vestiging die onder artikel 47 valt, maar bewijst niets over de conformiteit op de Belgische markt. De verplichtingen, de bevoegde instanties en de klachtenroutes per bestuursniveau worden toegelicht op onze pagina digitale toegankelijkheid in België.

Typeplanning: van de beslissing om te auditeren tot de gepubliceerde verklaring

Voor een dienst van gangbare complexiteit ziet een realistische planning er als volgt uit. Ze veronderstelt dat de toegangen bij de start klaar zijn en dat de correcties vanaf de presentatie worden ingepland. Ze past in de algemene aanpak die we beschrijven in onze gids voor digitale toegankelijkheid.

De duur van de correcties varieert veel sterker dan die van de audit: enkele weken als de fouten in een paar componenten geconcentreerd zijn, meerdere maanden als de architectuur van de front-end herwerkt moet worden. Wilt u uw audit plannen, dan beschrijft onze pagina RGAA-audit de inhoud van de dienstverlening, en grote ondernemingen die onder artikel 47 vallen, vinden er dezelfde opleveringen.

Leg de belangrijkste data van deze planning meteen vast in de agenda van de stuurgroep: de presentatie in week 4, de hercontrole in maand 4 of 5 en de volgende volledige audit. Zo wordt digitale toegankelijkheid een terugkerend punt in de aansturing van uw diensten, en niet een project dat om de drie jaar opnieuw van nul begint.

Veelgestelde vragen