Sinds 2020 houd ik me gepassioneerd bezig met digitale toegankelijkheid. Inmiddels weet ik aardig wat over zowel de techniek erachter als de Nederlandse wetgeving eromheen. Afgelopen jaar mochten wij dankbaar zijn voor weer twee audits van het HIOR op digitale toegankelijkheid, en al die ervaring bij elkaar wil ik nu gebruiken om een kort, praktisch advies te geven aan elke gemeentelijke ambtenaar: hoe krijgen we alle digitale werkplekken 100% toegankelijk?
Diede Gulpers
Developer
Aangemaakt op .
Dat is een gewaagd doel, zeker voor wie de geschiedenis kent. Al op 6 februari 2001 werd het doel gesteld om naar een digitaal toegankelijke overheid toe te werken. Begin 2004 stelde stichting accessibility vast dat slechts 10% van de overheidswebsites toegankelijk was. Vandaag is dat volgens digimonitor nog maar 4%. We doen dus al 25 jaar ons best, en boeken nauwelijks vooruitgang. Juist daarom lijkt het me waardevol om concreet en gericht advies te geven, gericht op dat hoge doel.
In dit artikel beschrijf ik vooral hoe je samen met je leveranciers naar toegankelijkheid toe werkt. Vergeet daarbij niet dat een groot deel van de toegankelijkheid door ambtenaren zelf geborgd moet worden: ook alle content, digitale communicatie en documenten moeten immers toegankelijk zijn.
Vind collega's met een beperking
Misschien klinkt dit advies als een open deur, of juist als veel te radicaal. De onderbouwing is echter even evident als elegant.
We willen toegankelijke applicaties zodat mensen met een beperking zo volledig mogelijk meedoen in de samenleving. Daarom voeren we audits uit op zo'n 9000 applicaties en websites. Maar het uiteindelijke doel is dat je, ongeacht je beperking, volledig kunt werken en deelnemen. En precies daarom is mijn advies: neem mensen met een beperking aan, dan krijg je veel sneller toegankelijke applicaties.
Hebben we daar wel genoeg mensen voor? Ruimschoots. In Nederland zijn al 50.000 mensen blind en 200.000 slechtziend, tegenover slechts 9000 applicaties die we monitoren. En zijn er voldoende prikkels om aan het werk te gaan? Ook dat lijkt me duidelijk: 240.000 Nederlanders met een beperking hebben geen financiële ondersteuning, en nog eens 200.000 hebben alleen een bijstandsuitkering.
Er zijn dus genoeg mensen met een goede reden om met de nu nog ontoegankelijke applicaties te werken. Maar levert dat ook iets op? Als leverancier kan ik garanderen dat het voor ons enorm veel zou betekenen. Op dit moment krijgen we zelden tot nooit feedback van gebruikers die aangeven dat ze in hun workflow worden geremd door tekortkomingen in de software. Een audit geeft alleen een beperkt zicht op wat technisch niet correct is. Je weet daarmee niet hoeveel het oplossen van die problemen werkelijk oplevert voor je gebruikers, en evenmin of een technisch correcte oplossing ook praktisch werkbaar is.
Daar komt bij dat mensen met wie je contact hebt, met of zonder beperking, de beste motivatie vormen om applicaties te verbeteren. Je helpt dan niet een anoniem getal van 50.000 mensen, maar Sanne of Thomas van de afdeling Beheer.
Er is dus duidelijke meerwaarde voor je leverancier. Maar wat heeft dit met jou en je eigen werk te maken? Het is natuurlijk altruïstisch en goed om mensen te helpen waar dat past, maar op jouw afdeling is veel vakkennis nodig, moet er hard gewerkt worden en is er weinig budget voor "dat soort dingen". Juist daar zit het sterkste argument. Want precies omdat jij en je collega's vakbekwame, gemotiveerde professionals zijn die efficiënt willen werken, heb je een eigenbelang bij toegankelijkheid. Slechts 2,9% van de Nederlanders wordt geboren met een aandoening, terwijl meer dan 50% van ons een beperking heeft tegen de tijd dat we stoppen met werken. 74% van alle aandoeningen ontwikkelen we tussen ons 16e en 70e levensjaar.
Digitale toegankelijkheid is dus niet alleen een kwestie van inclusie, maar ook van continuïteit: het helpt jou, je collega's en je organisatie om vakbekwame professionals te behouden en effectief te blijven opereren.
Houd vast aan de doelstelling: een gelijk speelveld
Dan de grootste olifant in de kamer, waar zelden iemand naar wijst. De Europese richtlijnen hebben namelijk ook een ondersteunende doelstelling. Als alle overheden in heel Europa bij hun inkoop dezelfde conformiteitseisen zouden neerleggen, zou dat vanzelf leiden tot een volledig digitaal toegankelijke wereld.
Bij consequente handhaving is dat een logisch gevolg. Bij elke verkoop moet je dan kunnen bewijzen dat je applicatie volledig voldoet, en het wordt dus wenselijk om technisch te borgen dat je doorlopend toegankelijk bent. Jij en je concurrenten krijgen allemaal met diezelfde kostenpost te maken, en de wedstrijd verschuift naar de vraag wie zo kostenefficiënt mogelijk volledig toegankelijk kan zijn.
De praktijk pakt echter heel anders uit. In België moet je aan minimaal 25 van de 50 criteria voldoen om aan de wet te voldoen; Nederland kent zo'n ondergrens niet. Er is dus zelfs binnen één taalgebied al geen gelijk speelveld, laat staan binnen Europa. En de cijfers spreken voor zich: onze applicatie HIOR is in acht jaar tijd drie keer geaudit, door in totaal drie van onze 22 klanten. Onze concurrenten zijn nul keer geaudit.
Negentien van onze klanten hechten dus weinig belang aan toegankelijkheid en zien liever nieuwe features. Wanneer wij vervolgens alles op alles zetten om voor die drie klanten volledig toegankelijk te zijn, gaat dat ten koste van de wensen van de overige klanten én van onze concurrentiepositie. Volledige toegankelijkheid brengt immers reële kosten met zich mee, en die zijn pas rendabel als ze leiden tot het winnen van voldoende extra aanbestedingen.
Waar je uiteindelijk naartoe wilt, is een situatie waarin toegankelijkheid de toegangspoort is om überhaupt mee te mogen doen. Iedereen voldoet volledig aan de basislijn, de WCAG, voordat hij aan het spel mag deelnemen.
Focus strategisch en afgestemd op toegankelijkheid
Toegankelijkheid moet dus onderdeel worden van de gewone gang van zaken. Met slechts 4% toegankelijke applicaties onder de actief gemonitorde sites is er nog een flinke weg te gaan. Mijn advies is om daarbij te leunen op twee Nederlandse kwaliteiten: zuinigheid en samenwerkingsvermogen.
Nederland telt 342 gemeenten. Idealiter zouden zij in onderling overleg een perfecte verdeling maken van wie welke applicatie audit, zodat elke leverancier vanzelf toegankelijke software gaat leveren. Omdat dat landelijk lastig te organiseren is, adviseer ik om dichter bij huis te beginnen: bij je buurgemeenten.
Breng eerst in kaart welke software jij en je buren gebruiken, zodat je kunt coördineren wie het voortouw neemt voor welke applicatie. Met een verdeel-en-heers-aanpak kom je zo verrassend snel op toegankelijke applicaties uit. Dat baseer ik op de Gemma-softwarecatalogus: er zijn maar 1076 softwarepakketten in gebruik in gemeentelijk Nederland, tegenover 9000 actief gemonitorde webapplicaties. Dat betekent dat elk pakket gemiddeld door zo'n tien gemeenten wordt gebruikt, een aanname die niet onwaarschijnlijk is als je bedenkt dat alleen al 162 gemeenten het Drupal-CMS gebruiken.
In dat scenario hoeft elke gemeente maar zo'n vier softwarepakketten richting toegankelijkheid te bewegen, waarbij buurgemeenten dezelfde eisen neerleggen, eventueel via een gedeelde buur. Dat dit haalbaar is, laat de gemeente Nijmegen zien, die zich tegenwoordig zeer actief inzet voor digitale toegankelijkheid en daar 64 applicaties en websites binnen de gestelde termijnen monitort. Met die mate van inzet zou je in theorie maar zeventien zulke gemeenten nodig hebben.
Haal het meeste uit de audits
Stel dat je inmiddels werkt aan het binnenhalen en behouden van collega's met een beperking, dat je je inzet voor een gelijk speelveld, en dat je met een aantal leveranciers concrete stappen zet richting volledige toegankelijkheid. Dan resteert de vraag hoe je per audit zoveel mogelijk resultaat boekt. Daarvoor zijn vier dingen van belang.
Zorg dat het belangrijkste wordt geaudit
Een WCAG-audit hoeft maar 10% van een website door te nemen om geldig te zijn. Het is dus zaak om juist de belangrijkste 10% te laten testen, of liefst iets meer. Bepaal die selectie in overleg met de dagelijkse gebruikers binnen je gemeente: welke pagina's bezoeken zij het vaakst, en hoe doorlopen ze de applicatie? Vraag daarbij ook of er e-mails of bestanden in die processen voorkomen, want ook die wil je toegankelijk krijgen.
Leg de beoogde testset vervolgens voor aan de leverancier en vraag om aanvullingen op vier punten:
Zijn er pagina's die zij zelf ook graag getest willen zien?
Zitten er pagina's of onderdelen in de testset die uit dezelfde broncode voortkomen en dus maar één keer getest hoeven worden?
Zijn er interacties die je bij normaal gebruik niet naar boven haalt, zoals lege zoekresultaten of foutmeldingen in formulieren?
Zijn er al audits gedaan of lopende? Wat waren de resultaten, en is er een planning voor het oplossen ervan?
Zorg dat er grondig en inhoudelijk wordt geaudit
Als techneut met enige kennis van toegankelijkheid kost het me op de meeste websites geen kwartier om een issue te vinden, ook bij sites die in een audit de status A hebben gekregen. Dat is niet alleen mijn ervaring; meerdere auditors die ik heb gesproken bevestigen het. Het is daarom verstandig om te zoeken naar een goede auditor, of er zelf een op te leiden, zodat audits werkelijk grondig worden uitgevoerd.
Zorg er bovendien voor dat de auditor goed is ingevoerd in het inhoudelijke proces. Of een screenreader bepaalde onderdelen wel of niet voorleest is belangrijk, maar voor een praktisch bruikbare applicatie moet de screenreader óók de informatie overbrengen die voor ziende gebruikers in lay-out en kleur besloten ligt.
Vraag na afloop van de audit aan de leverancier of zij nog aanvullingen hebben: zien zij, op basis van de gevonden fouten, plekken waar vergelijkbare of andere problemen spelen? Een audit is namelijk niets meer dan een momentopname van de stand van zaken. Het heeft weinig zin om bekende fouten te verzwijgen alleen omdat de auditor ze zelf niet vond; uiteindelijk lopen de gebruikers er toch tegenaan, en juist voor hen wil je een realistisch tijdpad uitstippelen.
Zet niet in op status A, niet op status B, maar op status Beter
Status A betekent dat een audit geen fouten heeft gevonden op de 50 te testen criteria. Bij kleine sites is dat haalbaar, maar bij grote sites met status A vermoed ik vrijwel altijd dat er fouten over het hoofd zijn gezien, of dat er simpelweg geluk was met welke 10% is getest. Status B daarentegen omvat zowel een audit met één fout op één criterium als een audit met duizend fouten over vijftig criteria. In de praktijk valt bijna alles in die categorie, en daarmee zegt de status vrij weinig.
Mijn advies is dan ook om die statussen niet leidend te maken, maar in te zetten op een inhoudelijk gesprek met je leverancier en je gebruikers over drie vragen:
Welke van de gevonden issues levert het meest op als je ze oplost?
Hoeveel inzet verwacht de leverancier nodig te hebben om ze op te lossen?
Hoeveel inzet is er daarna nodig om regressie te voorkomen, zodat een vergelijkbaar issue niet terugkeert?
Maak een hertoets afhankelijk van de planning en releases
Inmiddels is het patroon ontstaan om een leverancier drie maanden de tijd te geven om zoveel mogelijk problemen weg te werken, gevolgd door een hertoets om de voortgang vast te stellen. Die hertoetsen leveren echter weinig op. Wettelijk is er geen verplichting om binnen drie maanden iets te doen, en na de eerste audit heb je sowieso al minimaal status B.
Bovendien zijn deze hertests vaak alleen gericht op de vraag of de gevonden fouten snel zijn weggewerkt, en niet op de vraag of ze overal zijn opgelost en structureel weg blijven. Als leverancier ervaar ik de hertest binnen drie maanden daarom vooral als een verkeerde prikkel: je veegt overhaast je net geaudite straatje schoon, terwijl de rest van je digitale stad onder het vuil blijft zitten.
In plaats van een hertoets na drie maanden adviseer ik om samen met je leverancier een inhoudelijke planning te maken: wanneer worden welke issues opgelost, en onder welke voorwaarden mag de leverancier daarmee schuiven? Zo zorg je ervoor dat hij eerst de punten met de meeste meerwaarde aanpakt, terwijl hij tegelijk zijn overige onderhoud en uitbreidingen kan blijven leveren en stap voor stap toewerkt naar een toegankelijke toekomst.
Tot slot
Honderd procent toegankelijke digitale werkplekken klinken na 25 jaar moeizame vooruitgang misschien als een illusie. Toch wordt dat doel een stuk concreter zodra je het opdeelt in de stappen die ik hier beschreef. Haal mensen met een beperking binnen, zodat toegankelijkheid een dagelijkse, menselijke realiteit wordt in plaats van een abstract auditcijfer. Houd vast aan de oorspronkelijke doelstelling van de Europese richtlijnen, een gelijk speelveld waarin toegankelijkheid de toegangsprijs is om mee te mogen doen. Organiseer de aanpak slim en coöperatief, samen met je buurgemeenten, zodat de last verdeeld wordt en niemand het wiel opnieuw hoeft uit te vinden. En haal ten slotte uit elke audit het maximale, door te testen wat ertoe doet, grondig te werk te gaan en te sturen op echte verbetering in plaats van op een geruststellende letter.
Het mooie is dat geen van deze stappen een revolutie vereist. Ze vragen vooral om nuchtere keuzes, onderlinge afstemming en doorzettingsvermogen, precies de eigenschappen waar we als Nederlanders goed in zijn. Als we die inzetten, is een volledig toegankelijke digitale werkplek geen onhaalbaar ideaal, maar een kwestie van tijd. Wil je hierover doorpraten of samen kijken hoe dit er voor jouw organisatie uitziet, neem dan gerust contact op.
Wij horen graag van je!
Heb jij een fantastisch idee voor een applicatie, zoek je advies of heb je een opmerking? Diede en Bertus gaan graag met je in gesprek!
