Toegankelijkheid: Wie is verantwoordelijk?

Het eenvoudige antwoord op deze vraag is: iedereen. Wat in de praktijk vervolgens betekent: niemand. Het enige juiste antwoord is echter een stuk minder eenvoudig. Ook dit antwoord is samen te vatten als ‘iedereen’ maar de nuances zijn absoluut de moeite van het uitschrijven waard.

Toegankelijk bouwen is niet iets dat ‘we er wel even bij doen’. Of wat je vlak voor oplevering nog even bedenkt: “Ohja, het moet wel voldoen aan Drempelvrij, hè?”. Als je in een dergelijke opmerking ‘Drempelvrij’ vervangt voor ‘Webrichtlijnen’ is het past echt een feestje. Helaas hoor ik deze opmerkingen maar al te vaak in de praktijk, en dat is zonde, want eigenlijk is het op dat moment vaak al aan de late kant om het op de juiste manier te implementeren in het project, waardoor het vervolgens prima de vooroordelen bevestigt; het zou tijdrovend en frustrerend zijn om toegankelijk te bouwen. Wat een nonsens!

Onduidelijk rondom toegankelijkheid

Er zijn diverse niveaus van toegankelijk bouwen, en het ene niveau sluit het andere niveau niet uit, er is sprake van overlap tussen diverse richtlijnen en dat zorgt voor de nodige verwarring. Kortweg zijn er drie instanties verantwoordelijk voor de richtlijnen in Nederland. Enerzijds is er het wereldwijde orgaan, het World Wide Web Consortium (W3C), dat 3 prioriteitsniveaus van richtlijnen kent. Stichting Drempelvrij.nl kent in Nederland waarmerken toe aan websites die aan prioriteit 1 of 2 voldoen. De derde organisatie is bij de meeste van u wel bekend: de Nederlandse overheid. In samenwerking met enkele partijen uit de praktijk heeft zij in 2004 de Webrichtlijnen ontwikkeld.

De Webrichtlijnen zijn eigenlijk een uitbreiding op de W3C-richtlijnen waarbij duurzaamheid, platform-compatibiliteit en semantische waarde worden gestimuleerd. Ook op redactioneel niveau wordt beter gelet op toegankelijkheid, bijvoorbeeld of de teksten correct zijn opgebouwd en of ze begrijpelijk zijn geschreven voor een breder publiek.

Een team moet een team zijn (duh!)

Toegankelijkheid heeft eigenlijk invloed op iedere discipline binnen een projectteam, inclusief de webredactie aan de klantzijde. Invloed is echter iets anders dan een rem op de creativiteit of de suggestie dat het dan automatisch een ‘suf’ project wordt. Het vergt alleen wat meer denkwerk bij de start van een project, en wat meer controles tijdens de verschillende stadia. Mijn collega Ferry den Dopper schreef begin dit jaar een artikel over de oplevering van het project Alles Toegankelijk.  Bij dit project was ik betrokken als front-end developer, en heb ik nauw kunnen samenwerken met Stichting Accessibility. We hebben toen in zeer korte tijd een volledig toegankelijke website gebouwd, die er wat mij betreft goed uit ziet, en goed past bij het thema en de huidige trends op het internet. Waarom was dit een succes?

• Al in een vroeg stadium werden templates gecontroleerd op Webrichtlijnen-niveau, waardoor we vanaf sprint 1 al feitelijk wisten dat we konden voldoen aan de eisen.
• Iedereen binnen het team was bekend met de webrichtlijnen, van projectleider tot interactie ontwerper tot de developers die het Content Management Systeem (CMS) opzetten. Wat hier vaak in wordt vergeten is dat niet alleen binnen de muren van het internetbedrijf, maar ook aan de klantzijde een heel team hard aan de slag is voor het project. Ook voor hen is degelijke kennis rondom toegankelijkheid van essentieel belang voor het welslagen van het project; bij Tam Tam hebben we bijvoorbeeld een 2 uur durende cursus voor redacteuren zodat ook bij het invoeren van content rekening wordt gehouden met de geldende regels. Hierbij wordt uitgegaan van het betreffende CMS, want ieder CMS kent haar eigenlijk methodieken om de toegankelijkheid te waarborgen.

“Ik wil een toegankelijke site: waar begin ik?”

De grondbeginselen van een team worden soms pijnlijk evident bij projecten waarbij de Webrichtlijnen de kwaliteitseis zijn. In het team moet iedereen dezelfde doelen nastreven, en dezelfde basiskennis hebben om het project tot een succes te brengen. Iedereen moet op de hoogte zijn van de details en blindelings op elkaar kunnen vertrouwen, inclusief het projectteam aan de klantzijde. Is dit niet het geval, dan kost het project meer tijd dan je had voorzien,  zul je exponentieel meer moeite hebben met het toegankelijk maken van je website en zal de relatie met de bouwpartij danig op de proef worden gesteld.

Realiseer je goed waar je aan begint, kies voor een gevestigde ontwikkelpartij, stel het juiste interne team samen of zorg voor de juiste bagage bij deze mensen. Wees met het toegankelijk bouwen echter ook verzekerd van goede neveneffecten op de lange termijn. Oké, de offerte zal wellicht wat hoger uitvallen dan je had begroot, maar dat verdien je terug door minder onderhoud op de lange termijn en de overige voordelen zijn legio:

• Cross-browser en cross-platform compatibiliteit zijn redelijkerwijs gewaarborgd, ook voor de toekomst.
• De website is beter vindbaar in zoekmachines door semantische opbouw en een heldere en gangbare documentstructuur.
• Door de correcte scheiding van content, opmaak en interactie is het eenvoudiger om een van deze lagen te vervangen, waarmee bijvoorbeeld een huisstijlverandering of een uitbreiding van de website relatief eenvoudig is door te voeren.

In het artikel van Ferry den Dopper worden nog verschillende andere tips en trucs gedeeld.

Conclusie

Iedereen is verantwoordelijk voor de toegankelijkheid binnen een project. De conclusie is dus gelijk aan de algemene indruk. Maar de nuances zitten ‘m vooral ook in het nemen van de verantwoordelijkheid binnen je discipline en het aansturen van de andere disciplines.

• Functioneel ontwerpers moeten bij het bedenken van interactie rekening houden met het ontbreken van plugins (Flash, Silverlight etc.) of ondersteuning van bijvoorbeeld Javascript. Ook zijn zij verantwoordelijk voor het opnemen van essentiële pagina’s zoals een sitemap, en een compacte overzichte navigatiestructuur.
• Grafisch ontwerpers zijn verantwoordelijk voor het in acht nemen van de regels omtrent contrast en moeten er voor zorgen dat de interactie met bijvoorbeeld navigatie en links consistent en herkenbaar is.
• Front-end ontwikkelaars zijn misschien wel belast met de grootste mate van verantwoordelijkheid. Voor deze doelgroep heb ik een lijst met ijkpunten opgesteld.
• De projectleider is verantwoordelijk voor het waarborgen van budget; ja, dit moet absoluut meer zijn dan bij ‘normale’ projecten. Bij Tam Tam hanteren we een percentage-regel voor oudere browsers, maar ook voor toegankelijkheid. Ook is het aan te raden om consequent de opleveringen te testen in samenwerking met bijvoorbeeld Stichting Accessibility, om vroegtijdig inzicht te hebben in het behalen van de doelstellingen.
• De klant moet zich realiseren dat dit een andere manier van werken vereist; dat het meer tijd kost aan de bureauzijde, en dat het ook bij de klant intern meer vereist van de mensen. Als ze geen ervaringen hebben met toegankelijkheid; stuur ze dan op cursus of laat je goed begeleiden door het bureau.