WCAG?…Wat?
De feiten op een rij van digitale toegankelijkheid; waar komt het vandaan, waar staan we nu en wat zijn de ontwikkelingen? Randy Semeleer gaat erover in gesprek met Hidde de Vries, Robert Jan Verkade en Janita Top. Zij delen hun quick wins op het gebied van digitale toegankelijkheid. Raph de Rooij, vertelt in zijn column wat er zoal voorafging aan de huidige wettelijke toegankelijkheidsverplichting. Hij stelt dat tegenwoordig digitale toegankelijkheid steeds meer wordt gezien als een organisatorisch vraagstuk. Een goede ontwikkeling want bestuurlijk commitment is belangrijke een randvoorwaarde voor het succes van digitale toegankelijkheid. Maar hoe creëer je draagvlak?
Uitgeschreven tekst
Randy: Beste luisteraars. Welkom bij de podcast van Gebruiker Centraal en Digi Toegankelijk. Een podcast over hoe de overheid de mens centraal kan zetten in haar dienstverlening. Deze reeks gaat over de digitale toegankelijkheid bij de overheid. Mijn naam is Randy Semeleer. Vandaag de aflevering ‘WCAG?…Wat?’ Over toegankelijkheidsrichtlijnen, de achtergrond en waar we naar toe gaan. Mijn eerste gast vandaag is Hidde de Vries. Hidde is accessibility specialist. Hij is freelancer met een technische achtergrond. De afgelopen twee jaar heeft hij gewerkt voor het World Wide Web Consortium, ook wel bekend als W3C. Hij werkte aan het duidelijk maken van de WCAG-standaard. Ook werkte hij aan de standaard e-Tech. Die heeft betrekking op alle tools, waarmee content wordt beheerd. Van contentmanagementsysteem, tot formulieren bouwen. Wat ook belangrijk is om te weten, Hidde is hier vandaag niet te gast als vertegenwoordiger van de W3C, hij spreekt op eigen titel. Welkom Hidde.
Hidde: Dank je wel.
Randy: Mijn volgende gast is Robert Jan Verkade. Robert Jan is oprichter van Eend. Hij kwam zo’n twintig jaar geleden in aanraking met accessibility en het balletje is toen snel gaan rollen. Hij raakte betrokken bij de groep Webrichtlijnen. Voor de tweede versie van de Webrichtlijnen was hij reviewer. Hoe hij de afgelopen decennia op verschillende momenten verschillende gevoelens en ideeën had over de standaard en alles wat daar bij komt kijken, heeft WCAG hem nooit echt losgelaten. Daarom is hij ook hier. Welkom Robert Jan.
Robert Jan: Hai.
Randy: Ook mijn gast vandaag is Janita Top. Janita is zelfstandig onderzoeker en adviseur. In 2008 kwam zij in aanraking met de Webrichtlijnen. Zij werkte toen als developer aan vooral overheidswebsites. Daar de overheid zichzelf al zaken begon op te leggen, kreeg ze als developer snel te maken met richtlijnen. Nu doet Janita vooral onderzoek en adviseert ze andere developers. Ook toetst ze websites, als het gaat om de WCAG. Welkom Janita.
Janita: Dank je wel.
Randy: Tot slot hebben we vandaag een extraatje. We hebben een column van Raph de Rooij, waarover later meer. Robert Jan. Drie… ik heb een onderzoek gelezen, dat 23 procent van de mensen met een beperking nooit online gaat. Dat was wel een onderzoek uit 2016 en het was onder Amerikanen. Maar toch, als ik dat percentage zeg, wat zegt… ja, wat denk jij dan?
Robert Jan: Ja, dat… als ik… dan zou ik eerst willen weten: over welke beperkingen hebben we het? Welke mensen waren dat? Waren ze al heel gelukkig met hun leven zonder überhaupt internet te hebben? Op zich, ja, als het zo is, dat de mensen niet online gaan, omdat ze niet online kunnen, dan is het wel echt een probleem.
Randy: Ja. Ja, het is ook wel een onderzoek van een paar jaar geleden, dus ik kan me voorstellen dat de percentages, ja, iets minder dramatisch zijn geworden. Hoewel, ja, het is wel een kwart van de mensen. Ja, en je hebt natuurlijk ook een punt: willen ze überhaupt online, hebben ze het nodig? Dat heeft ook te maken met, ja, de mate van zelfstandigheid, die iemand heeft met die beperking natuurlijk. Ja, ik noemde net, al in jullie introducties had ik het over Webrichtlijnen. Ik had het over WCAG. Als we het hebben over… ja, ik zei altijd ‘WCAG’, maar in mijn voorbereiding kwam ik er achter dat het ook op andere manieren werd uitgesproken. Ik heb ‘WCAG’ gehoord, ‘WCAG’, of ‘WCAG’, geloof ik. Robert Jan, wat zeg jij altijd?
Robert Jan: Ja, het is of Webrichtlijnen voor mij, of WCAG. Maar dat ‘WCAG’, dat komt voornamelijk, omdat ik in die tijd samen met Steven Hayes heel veel heb gesproken over de toegankelijkheidsrichtlijnen. En Steven Hayes komt oorspronkelijk uit Amerika, dus vandaar ‘WCAG’.
Randy: Ja. En Steven Hayes, die heeft een belangrijke rol gespeeld bij het opstellen ervan, begrijp ik.
Robert Jan: Ja. Ja, die heeft… ik denk al wel bij de eerste versie van de Webrichtlijnen en bij de tweede versie ook. Dat is wel een belangrijke man, naast Raph de Rooij.
Randy: En Janita, wat zeg jij altijd? ‘WCAG’, ‘WCAG’?
Janita : Ja, met Nederlandse organisaties ‘WCAG’. En met developers vaak ook internationaal, dus dan is het ook ‘WCAG’, of…
Randy: Ja.
Janita: Dat is ook altijd een beetje raar, inderdaad.
Randy: Hidde, jij bent ook veel met Engelstalige, of mensen die, ja, vanuit andere landen komen, dat het ook in het Engels gaat, denk ik, bezig. Wat zeg jij meestal dan?
Hidde: Ja, dan is het ook eigenlijk ‘WCAG’, omdat het, ja, het is eigenlijk gewoon de Engelse manier om het uit te spreken.
Randy: Ja. En dan de Webrichtlijnen, hoe verhouden zich die er toe? Bedoelen mensen met ‘Webrichtlijnen’ dan de WCAG, denk je?
Hidde: Ja, het gaat eigenlijk over hetzelfde, maar de Webrichtlijnen zijn dan een Superset van WCAG, dus dat is een aantal extra richtlijnen nog boven op wat daar in WCAG bestaat. En dat was een hele tijd de norm in Nederland. Inmiddels zijn we daar van af gestapt en gebruiken we in Nederland net als in heel veel andere, of eigenlijk alle andere EU-lidstaten, gebruiken we WCAG-standaard voor het grote net.
Randy: M-hm. Oké. Toch als er gesproken wordt over ‘Webrichtlijnen’, denk je dat de meeste mensen dan de WCAG bedoelen, of denk je dat er toch vaak iets anders wordt bedoeld?
Hidde: Ja, dan heb je het vaak over hetzelfde, ja.
Randy: Ja.
Hidde Mensen gebruiken ook nog wel eens Digi Toegankelijk en dan gaat het ook weer over hetzelfde, eigenlijk. Het gaat erom dat het web, bruikbaar is voor mensen met een functiebeperking.
Randy: Precies. Robert Jan, als we kijken van de oorsprong van de richtlijnen, jij bent er al een tijd mee bezig, je was er vrij vroeg bij. Ja, kan je iets vertellen over hoe dat toen gegaan is en hoe je dat toen beleefd hebt?
Robert Jan: Ja, dat kan ik. Ik denk dat ik in, of ik weet zeker dat ik in 2001 een cursus heb gedaan bij Accessibility, en dat ging toen over toegankelijk bouwen. Dat was daags na de aanslag op de Twin Towers, dus vandaar dat ik vrij precies naar boven kan halen. Ja, en toen waren wij al bezig met de Eend, om te kijken van: hoe kunnen we het nou grafisch ook daadwerkelijk op een niveau krijgen, visueel, dat we ook trots kunnen worden op ons werk? Want op dat moment waren de qua toegankelijke websites echt maar heel weinig mooie voorbeelden. En een ander bedrijf, dat daar mee bezig was, was Cinnamon, uit Leeuwarden. En daar zat Stephen Hayes. En die is al daarnet genoemd als één van de grotere mensen achter de Webrichtlijnen. En ook zij waren bezig met echt wel mooie websites maken, en toegankelijk. Ja, en zo gaandeweg kom je dan in beeld bij Raph de Rooij en dan zit je weer bij de andere speler en dan, ja, zo gaat dat balletje een beetje rollen, omdat je vanzelf in die Webrichtlijnen gevlogen wordt.
Randy: Ja. En als je nu terugkijkt op de ontwikkeling van de afgelopen, ja, twee decennia, hoe kijk je daar op terug? Wat vind je daarvan?
Robert Jan: Nou ja, in het begin dacht ik wel al van dat, als je kan laten zien voor wie je het doet en hoe je dat doet, dat iedereen wel mee zou gaan. Dat bleek een beetje positief en ook wel naïef te zijn.
Randy: M-hm.
Robert Jan: Het bleek toch dat het wat moeilijker was, om veel organisaties te overtuigen van toegankelijk bouwen. Op een gegeven moment werd het wetgeving, en toen… en nu zie je dat heel veel overheidsinstanties daar heel druk mee zijn.
Randy: Janita, als ik kijk naar waar we nu staan. Nou, er is nu, is er een stuk wetgeving bij gekomen. Waar vind je dat we nu staan, als het gaat om de richtlijnen in Nederland?
Janita : Nou, de nieuwe wetgeving heeft wel veel veranderd. Het wordt door veel organisaties nu wel serieus opgepakt, ook organisaties die er eerst nog niet echt mee bezig waren.
Randy: M-hm.
Janita : Dus daarin merk ik wel veel verandering. Het is ook wel in die zin professioneler geworden, zeg maar. Er zijn meer mensen mee bezig, er zijn meer organisaties, meer bedrijven mee bezig. Dus het wordt in die zin ook wel makkelijker om, nou ja, er wat mee te doen. Maar tegelijk is er nog wel heel veel, ja, een hele weg te gaan, om al die websites ook echt goed toegankelijk te krijgen. Heel veel websites die hebben nu, waar ze de eerste stappen aan het zetten zijn, ja, dat is een begin, dus dat is mooi. Maar dan zijn er nog steeds wel heel veel dingen die aangepast moeten worden.
Randy: Ja, begrijp ik. En als je praat over die organisaties, heb je het dan voornamelijk over overheidsorganisaties, of bedoel je het dan breder?
Janita : Overheid, maar ook wel semioverheid, zoals zorginstellingen, begint het ook wat te komen, heb ik het idee.
Randy: M-hm. Hidde, als je kijkt, ja, waar we nu staan. Heb je er nog iets op aan te vullen, over de situatie in Nederland op het moment?
Hidde: Ja, ik denk dat naast de overheid daar ook steeds meer grote bedrijven aan het meedoen zijn en echt geïnteresseerd zijn in ‘hoe kunnen we onze websites toegankelijker krijgen?’ En het is natuurlijk om allerlei redenen. Er is nog geen specifieke wetgeving voor commerciële partijen om dat te doen, dat komt er wel aan. Maar het is natuurlijk wel zo, dat een commerciële partij ook commerciële redenen heeft. Ze kunnen natuurlijk meer geld verdienen, als ze meer gebruikers bedienen.
Randy: M-hm.
Hidde: En als je een bedrijf bent wat ontzettend veel verkoopt online, dan kun je een bepaald percentage meer verkopen. En dat is… dat zie ik als freelancer zelfs, dat ik dan wordt gevraagd: ‘hé, kun je misschien helpen, want we willen die doelgroep ook nog aanboren?’
Randy: Oké. Dus het lijkt er op dat bedrijven ook meer die businesscase beginnen te zien? Iets wat misschien, ja, Robert Jan, in de tijd waar jij dan net over sprak, dat dat minder gezien werd.
Robert Jan: Ja, dat zal… ja, geen idee of ze toen al de businesscase zagen, of misschien dat de moeite die ze er in moesten steken zo groot was, ja, dat de businesscase dan verdwijnt als sneeuw voor de zon.
Randy: Ja. Het heeft denk ik ook wel iets te maken met schaalbaarheid. Natuurlijk, een organisatie, laten we als voorbeeld een webwinkel nemen, als je een webwinkel bent die al een flink groot klantenbase heeft, dan zal het aantal mensen wat een beperking heeft, die je ook wil bedienen, dat zal groter zijn dan een webwinkel die, ja, tientallen zaken per producten per maand verkoopt. Dan is het aantal mensen waar je dan moeite voor moet doen, om te zorgen om toegankelijk te zijn, zal inderdaad kleiner zijn, denk ik. Dus ik denk als je opschaalt, dat het voor webwinkels, of andere bedrijven logischer is, om daar dan die case voor te maken. Denk je dat… zie je dat ook zo, Hidde?
Hidde: Ja. Ja, zeker. Ja, het is natuurlijk wel goed om ook in de gaten te houden, we hebben wetgeving, je kunt geld verdienen, maar eigenlijk is natuurlijk de belangrijkste reden om het web toegankelijk te maken, dat het ooit zo bedoeld is en dat het ook niet meer dan normaal is, dat je zorgt dat je website werkt voor iedereen. Zeker als je dienstverlening doet, maar ook als je een winkel hebt. Je zou ook niet bij de deur mensen weigeren in je winkel, dus dat moet je digitaal ook zeker niet doen.
Randy: Zeker, absoluut. Ja, toch denk ik wel dat het, ja, dat voor bedrijven, om dat steuntje in de rug te krijgen van, er zit, ja, een direct aspect aan, waarmee meer verdiend kan worden, dat het wel het belangrijkste is, zolang er geen wetgeving is die ze er toe aanzetten. Misschien dat er wel bedrijven zijn, die het nu aan gaan beginnen te geven vanuit het idee ‘we willen gewoon als bedrijf toegankelijk zijn’. Ja, als je die businesscase kan maken, direct voor, dan zou het toch gemakkelijker zijn om daarheen te drukken, vermoed ik. Janita, als we het hebben over toetsing, nou, natuurlijk, er is wetgeving bij gekomen, mag ik aannemen dat je toen ook een heel verschil zag in hoeveel toetsaanvragen er kwamen.
Janita : Ja, heb ik zeker wel een verschil in gemerkt. En ook met name in dat organisaties ervan bewust zijn, dat al hun websites en apps moeten gaan voldoen.
Randy: M-hm.
Janita : Dus waar voorheen organisaties bijvoorbeeld alleen hun hoofdwebsite misschien lieten onderzoeken, komen ze nu met veel meer websites aanzetten, van: ‘oh ja, we hebben ook nog daar een website van. Die moet ook nog een onderzoek hebben.’
Randy: Ja.
Janita : Dus in die zin is het ook toegenomen.
Randy: Oké, oké. Dus niet alleen de hoofdwebsites, er wordt ook nog breder gekeken.
Janita : Ja.
Randy: Is er nog iets veranderd in hoe je dan toetst? Of heeft dat niet zo veel verschil gemaakt?
Janita : Technisch gezien niet.
Randy: M-hm.
Janita : Maar ja, organisaties moeten natuurlijk wel kijken waar, ja, waar prioriteiten liggen en welke websites belangrijk zijn. Ja, waar ik ook nog wel verschil in merk, is dat het gelukkig ook steeds vaker voorkomt, dat ze al willen toetsen, als een website nog in ontwikkeling is.
Randy: Oh.
Janita : Dus niet als het al live is gezet, wat voorheen vaak zo was, maar ook steeds meer van: ‘nou, we zijn bezig met een app, of ‘we zijn bezig met een site, wil je hem toetsen?’
Randy: M-hm.
Janita : En ja, dat zie ik wel als een hele goede ontwikkeling.
Randy: Want is het ook, zoals bij veel andere testvormen: hoe eerder, hoe beter?
Janita : Ja, zeker. Het liefst al bij het ontwerp. Dat geef ik ook altijd aan, van: ‘als jullie een ontwerp hebben en ook al is het nog lang niet definitief, ik kan er ook gewoon even één of twee uur naar kijken en wat tips geven. En dan kun je daarmee weer verder.’ Dat kan al een hoop schelen.
Randy: Ja, hoe eerder je er bij bent, hoe meer, ja, dingen voorkomen kunnen worden, waar dan weer geld in gaat zitten, die, ja, later toch misschien toch aangepast moet worden dan.
Janita : Ja.
Randy: Ja, het toetsen zelf, je wordt eerder er bij gehaald in sommige gevallen. Durf je daar, dat is misschien een lastige vraag, maar durf je daar een percentage aan te hangen van in welke mate, of in welk percentage van de gevallen je al in ontwikkeling wordt opgebeld? Of is dat te lastig?
Janita : Nou, percentage kan ik niet echt noemen. En het is nog steeds te weinig. Er zijn nog steeds best wel veel aanvragen van, ja: ‘kun je het doen één week voor live-gang?’
Randy: M-hm.
Janita : En dan denk ik altijd: ja, jammer.
Randy: Ja, begrijp ik.
Janita : Dat gebeurt nog steeds heel veel, hoor. Dus ik ben al lang blij met als ze een paar maanden eerder komen.
Randy: Dat is wel een groot verschil ten opzichte van ‘we gaan volgende week live’.
Janita : Ja, precies.
Randy: Begrijp ik. Nou, we hebben het ever gehad over, ja, waar het vandaan komt. Ook wat Robert Jan heeft meegemaakt. Waar het nu staat, is wetgeving gekomen. Nou, er komen meer toetsingsaanvragen, soms nog ook wat eerder. Als we het hebben over de WCAG, wat zie je dan voor toekomst daarvoor? Waar gaan we heen met de WCAG? Hidde, jij zit er misschien dicht bij, kan jij er iets over zeggen?
Hidde: Ja, het is een standaard, die flink wordt doorontwikkeld. De eerste vraagzin was in 1999, kwam dat uit, nadat het werk in ’95 was begonnen. Ja, dat ging dan om versie 1, we zitten inmiddels aan versie 2.1, die in 2018 is uitgekomen. En ja, 2.2 komt er aan, daar wordt nu aan gewerkt.
Randy: M-hm.
Hidde: Dan is het de bedoeling dat die nu ongeveer uit zou zijn, dat heeft een klein beetje vertraging. Maar ja, er wordt gewerkt weer aan in ieder geval een nieuwe versie van WCAG 2. En dan gaat het bijvoorbeeld over dingen, zoals toegankelijke authenticatie, dus als je gaat inloggen, dat dat dan op een toegankelijke manier kan.
Randy: M-hm.
Hidde: Het gaat over dingen als ‘drag and drop’.
Randy: Ah.
Hidde: Dat de knopjes niet te klein zijn. Dus allerlei verschillende dingen eigenlijk, om dingen beter te maken. Vaak gaat het bij een doorontwikkeling ook om zorgen dat er meer verschillende werkingen worden meegenomen. Dus in de eerste versies werden er vaak dingen meegenomen, die makkelijker in het specificatie zijn te vatten. En er werd ook steeds meer geluid kwam er uit de andere hoeken, van: hé, wacht, er zijn nog meer beperkingen, waar we misschien ook iets mee moeten. Want die standaard is er eigenlijk om proberen te garanderen dat het werkbaar is voor mensen met een beperking. Maar, ja, welke beperkingen je nou precies meeneemt, daar kun je natuurlijk nog al in verschillen. En dan gaat het bijvoorbeeld over cognitieve toegankelijkheid, dat is één van de dingen die wat meer achter is gebleven. Waar in de nieuwe versies dan ook weer meer aandacht voor komt.
Randy: En mensen met wat voor soort beperking aan cognitieve beperking? Kan je dat nog wat concreter maken, wat voor beperkingen daarmee in worden meegenomen?
Hidde: Ja, dan kan je bijvoorbeeld denken aan organisaties die te maken hebben met als mensen van tevoren dingen moeten onthouden en dat lastig vinden. Daar is het inloggen bijvoorbeeld een voorbeeld van en toegankelijke authenticatie.
Randy: M-hm.
Hidde: Maar je kan ook denken aan dat iets helder is omgeschreven, zodat mensen het makkelijker kunnen begrijpen. Mensen misschien hersenaandoeningen hebben, of iets dergelijks, en minder makkelijk heel veel teksten op zich kunnen nemen.
Randy: Ja.
Hidde: Dat gaat enorm breed. En het zijn heel vaak dingen, die moeilijker te toetsen zijn, omdat ze soms ook subjectiever zijn.
Randy: Ja, ik kan me voorstellen dat, ja, als je bijvoorbeeld met slechtziendheid heb je ook wel verschillende gradaties, maar op een gegeven moment is het ‘blind is blind’ en dan ziet iemand niks. Of, nou, of zoveel niks, dat we het associëren als blind. Met een verstandelijke, of licht verstandelijke beperking kan dat natuurlijk heel erg verschillen, wat voor hinder iemand ondervindt bij het gebruiken van een website.
Hidde: Ja, en dat kan soms zelfs nog onderling conflicteren, dus daarom wordt voor dat soort dingen ook wel eens gekeken naar: moeten we niet naar een schaal toe, in plaats van een duidelijke ‘ja’ of ‘nee’ ertussen, of het wel of niet voldoet.
Randy: Ja. Ja, dat klinkt nog best complex.
Hidde: Ja. Ja, en dat is dan alleen nog maar de korte termijn. Dus nu, kijk, 2.2 is korte termijn, dat zal misschien eind dit jaar, misschien volgend jaar zal dat komen.
Randy: M-hm.
Hidde: En daarnaast wordt nog gewerkt eigenlijk in een parallelle structuur aan WCAG 3., echt de grote nieuwe versie. En dat gaat nog zeker een aantal jaren duren. Maar daar gaat ook echt een hele hoop op de schop. Dus dat is een beetje het langere termijn perspectief.
Randy: Oké. Dus een aantal jaren, dan 2025?
Hidde: Nee, niet zo veel. Maar ik denk wel zeker drie, vier jaar, misschien nog meer. Omdat het veel tijd kost om dingen uit te denken. En omdat er ook het conformance model wordt aangepast, dus hoe je precies kan voldoen, wordt heel erg anders. En dat betekent gewoon dat er best wel tijd nodig is voor overheden om er iets mee te gaan doen, maar ook voor ontwikkelaars en ook zelfs voor de makers van die standaarden zelf. Want ja, daar moet er nogal wat veranderen en ja, dat is nu nog in een heel vroeg stadium.
Randy: M-hm.
Hidde: Maar het idee is in ieder geval dat het gebruikersvriendelijker is als standaard. Dus dat je er makkelijker mee kan werken en dat het duidelijker is wat alles doet voor welke gebruikers en dat er, ja, dat het allemaal wat duidelijker te gebruiken is. Maar, ja, het is nog in een erg vroeg stadium, in ieder geval.
Randy: De dingen die je noemt over het ‘drag and drop’, knoppen die groter moeten, makkelijker te onthouden, wat hoorde ik nog meer, de log-in, dat zijn eigenlijk ook dingen waar, ja… het klinkt alsof alle gebruikers daar baat bij gaan hebben.
Hidde: Ja, maar dat is natuurlijk een algemeen iets met toegankelijkheid, dat je eigenlijk stiekem heel veel meer mensen bedient. Misschien een goede anekdote is dat de allereerste typmachine ooit bedacht is voor een blinde collega. En later zijn we gaan denken: nou, misschien is het handig, als we allemaal toetsenborden hebben. En zie hier, zitten we nu allemaal achter een toetsenbord deze podcast op te nemen. Dus het is heel vaak zo dat innovaties in toegankelijkheid uiteindelijk leiden tot innovaties voor iedereen. En dat geldt natuurlijk voor heel veel dingen ook. Voor bijvoorbeeld bediening met stem, dat is ook een goed voorbeeld daarvan.
Randy: Ja. Oh, dat van de typmachine wist ik niet. Ik ben zelf wel iemand ook, die in de, ja, gewoon in het dagelijks gebruik veel gebruik maakt van wat toegankelijkheid features in het OS en, ja, ik moet zeggen dat ik daar altijd wel, ja, dan ben ik toch blij dat ze er zijn. En ja, maar ik denk dat ze misschien ook een beetje verstopt zijn voor veel gebruikers. Dat is natuurlijk wat anders dan met web, als het in het OS zit. Maar ja, ik denk wel dat het de algehele ervaring zeker wel beter maakt. Robert Jan, Janita, als we het ook hebben nog even over de toekomst. Je hebt net even gehoord, wat is er, ja, op de relatief korte termijn, wat gaat er gebeuren. Hebben jullie een idee van… wat vind je dat er moet gebeuren? Wat vind je belangrijk om in de komende jaren, of misschien nog wel verder, om aandacht aan te geven? Heb je daar een idee over?
Janita : Nou, wat ik wel merk bijvoorbeeld, is, wat nu begint te komen, is het testen en toegankelijk maken van mobiele apps.
Randy: Ja.
Janita : En dat gaat wel toenemen, denk ik. Maar daar moet ook nog wel een slag in gemaakt worden hoe precies.
Randy: M-hm. Want verbeter me als ik het mis heb, hoor. Ik begrijp dat er ook WCAG-richtlijnen zijn die worden toegepast op apps. Maar ja, het woord ‘W’, ‘w’ staat voor ‘web’, dus het is eigenlijk bedacht voor het web. Is er de WCAG uitgerust, om ook toe te passen op apps?
Janita : Nee, het is inderdaad bedoeld voor web. En het wordt nu ook gebruikt om apps te testen. Maar het is nog, ja, niet helemaal… ja, het is niet helemaal geschikt op alle punten daarvoor.
Randy: Ja.Hidde, ik zag jou hard nee schudden, toen ik die vraag stelde of het geschikt is voor apps. Jij hebt er een sterke mening over?
Hidde: Nou ja, het is lastig, omdat de Europese Commissie heeft op een gegeven moment gezegd: ‘ja, ergens moet het toegankelijk zijn’. Maar eigenlijk was er niet echt een standaard, die daarvoor bestond. En ja, je ziet nu dat eigenlijk door heel Europa WCAG daarvoor zijn gaan gebruiken. En dat is natuurlijk best logisch, omdat er heel veel dingen in WCAG zitten, die ook toepasbaar zijn op mobiele apps. De basisprincipes in ieder geval zijn toepasbaar. En…
Randy: Ja.
Hidde: En ja, het soort problemen is wel ongeveer gelijk. Maar er zijn ook best wel veel dingen, die specifiek voor apps zijn en daar is niet echt een standaard voor, waar je dat tegen kan toetsen.
Randy: Het is ook logisch dat mensen daar op teruggrijpen, als er verder geen andere standaard klaarligt daarvoor, lijkt mij.
Janita : Ja.
Hidde: Ja, en het is wel belangrijk uiteindelijk natuurlijk, dat we apps ook toegankelijk krijgen, want ze worden veel gebruikt. Dus dan moet het ook toegankelijk kunnen.
Randy: Zeker. Nog andere dingen die, als we het hebben over de toekomst van de richtlijnen, dat je denkt: daar zou ik ook graag meer aandacht voor willen, of: dat voorzie ik dat dat een belangrijke rol gaat spelen?
Hidde: Misschien is automatisering nog interessant. Er wordt steeds meer gekeken naar: kunnen we die dingen niet automatisch doen?
Randy: M-hm.
Hidde: Waarbij we dingen toegankelijker krijgen. Er zijn nu al best wel veel dingen, die bijvoorbeeld browsers zouden kunnen oplossen, in plaats van individuele website-eigenaren. En dat betekent dat zij dan hun tijd kunnen vrijmaken voor andere problemen, wellicht ook op toegankelijkheid. Maar er zijn best veel dingen in de basis, die door browsers zouden kunnen worden opgelost. Als je meer kijkt naar de toekomst, dan heb je natuurlijk ook oplossingen in kunstmatige intelligentie, daar wordt ook naar gekeken, van: hoeveel kunnen we daarmee? En waar moeten we voor uitkijken? Dat is natuurlijk ook een hele goede vraag, omdat, ja, kunstmatige intelligentie staat er bekend om, dat er bijvoorbeeld veel risico is op bias en dat ga je dan ook krijgen, als je dat hierop gaat toepassen.
Randy: Algorithmic bias.
Hidde: Ja, ja. Maar er zullen natuurlijk best dingen zijn, die een machine makkelijk kan herkennen. Bijvoorbeeld als je wil weten ‘wat is de navigatie op deze pagina?’ Nou, ik kan me voorstellen dat een machine dat wel kan herkennen en dat het dan daarom minder belangrijk zou zijn voor een webontwikkelaar, om dat soort dingen aan te geven. Dus daar zitten misschien nog interessante dingen in de toekomst, maar op dit moment is het in ieder geval nog niet ver genoeg.
Randy: Hm. En even over die bias, Hidde. Zijn er dingen waar je dan… of is het misschien al eens gebeurd, of zijn er dingen waar je je dan zorgen over maakt, ja, als we dat met kunstmatige intelligentie op gaan lossen, dan moeten we daarvoor waken. Heb je daar een voorbeeld van, dat het wat, ja, meer concreet maakt?
Hidde: Nou, ik denk dat… en bias gaat dan vaak bijvoorbeeld als je gezichten gaat herkennen en dan optimaliseert voor een bepaald soort gezichten en dat er dan heel veel mis gaat.
Randy: Ja, er zijn de laatste jaren veel voorbeelden dat blanke mannen heel goed worden herkend en dan blanke vrouwen minder, donkere mannen nog minder en donkere vrouwen eigenlijk het slechtst. En voor je het weet, wordt er een Amerikaanse studente van haar bed gelicht, omdat ze wordt aangezien voor een terrorist.
Hidde: Precies, dat soort uitkomsten. Het gaat heel vaak om het propageren van iets wat eigenlijk fout was en dat wordt dan steeds groter. En dat zou natuurlijk ook kunnen gebeuren, als je code gaat inzetten, dus broncode van websites. Dat geef je aan aan een AI en dan ga je die AI vragen van: wat is nou de meest toegankelijke oplossing? Dan zou je natuurlijk kunnen krijgen dat slechte codes steeds vaker herkend worden als goed, of iets in die richting. Dus dat er een bias komt naar slechte oplossingen. Want er zijn misschien wel meer slechte oplossingen, dan goede oplossingen. Dus dat soort dingen zijn denk ik voorbeelden van bias die je kunt krijgen in kunstmatige intelligentie.
Randy: Ja. Oké, oké, bedankt. Nou, ik zit even te denken, als de toekomst en nieuwe technologie, ik denk bijvoorbeeld aan virtual reality. Denk je dat dat daar op een gegeven moment ook aandacht voor komt, om dat toegankelijker te maken?
Hidde: Ja, we hebben net, bij het W3C, hebben we net een gepubliceerd hier over, met richtlijnen over hoe je mixed reality toegankelijk kan krijgen, dus virtual reality en dat soort technieken.
Randy: Ja, augmented reality.
Hidde: Ja, ja. En dan gaat het heel vaak over dezelfde basisprincipes, maar er zijn ook best wel wat dingen die echt specifiek zijn aan virtual reality. Ik kan later een linkje opnemen in de show notes.
Randy: Laten we dat doen voor de geïnteresseerden. Ik ga hem zeker lezen. Dan zetten we die links, zetten we in de show notes. Oké. Ik wil even een stelling deponeren. En, ja, wie wil, mag er op reageren. De stelling die ik bedacht heb: vroeger werd Webrichtlijnen, of WCAG, of digitale toegankelijkheid, hoe je het wil noemen, werd vooral als lastig ervaren. Nu is dat minder. Zijn jullie het daarmee eens? Wie is het daarmee eens? Wie is het oneens?
Robert Jan: Het is lastig te beantwoorden. Zal ik aftrappen?
Janita: Voor wie?
Randy: Ga je gang Robert.
Robert Jan: Het eerste gedeelte van je stelling klopt zeker. Het werd als lastig ervaren en ‘ik mag ook niks’ en ‘als ik moet voldoen aan de Webrichtlijnen krijg ik een lelijke site en dan mag ik helemaal niks en dan mag ik niks en mag ik niks. En van jullie mag ik nooit wat’. En nu zitten veel organisaties, die zijn al die tijd nog steeds allemaal PDF’en aan het produceren geweest. En wij komen websites nu tegen met 9000 PDF’en. En PDF’en moeten dan ook toegankelijk worden. Dus ja, ‘mag niks’, ‘kan niks’ is niet helemaal waar. Het is wel zaak om je organisatie goed in te richten, zodat toegankelijkheid onderdeel wordt van je publicatieproces. En als je dat niet doet, dan blijft het lastig, ja.
Randy: Janita, wat denk jij?
Janita : Ik denk dat het afhangt van de rol, bijvoorbeeld voor developers, die er nog weinig van af weten, die zien het vaak nog wel als lastig, als eis die er nog bij komt.
Randy: M-hm.
Janita : Maar bijvoorbeeld…
Randy: Maakt het werk nog complexer.
Janita : Ja. Maar bijvoorbeeld sommige designers die al veel bezig zijn met gebruiksvriendelijkheid, die vinden het dan wel interessant, omdat het hun meer mogelijkheden geeft om er dieper op in te gaan, om gebruikersonderzoek te doen. Ze hebben dan ook nog wettelijke redenen, zeg maar, waarmee ze bij hun manager aan kunnen komen. Dus voor hen biedt het juist wel meer mogelijkheden.
Randy: M-hm.
Janita : Dus ja, ik merk daar echt verschillen in, in ja, tussen bureaus en tussen developers en designers.
Randy: Oké, heel goed. Dan is het nu tijd voor de column. Beste luisteraars, een special segment in deze aflevering. We hebben een gesproken column van Raph de Rooij. En aan het einde heeft hij ook nog een vraag voor de gasten van vandaag. Raph heeft 25 jaar ervaring als internetprofessional. Twintig jaar geleden raakte hij betrokken bij webtoegankelijkheid. Je kunt stellen dat dit onderwerp de rode draad in zijn carrière is geworden. Raph heeft gewerkt aan en voor Drempels Weg, Webrichtlijnen versie 1 en 2, drempelvrij.nl, het verantwoordingsmodel Digitale Toegankelijkheid en de applicatie toegankelijkheidsverklaring.nl. een autoriteit op het gebied van digitale toegankelijkheid, kunnen we wel stellen. Hier volgt zijn column.
Raph: In deze column ga ik het hebben over wat er zoal voorafging aan de huidige wettelijke toegankelijkheidsverplichting. En daarvoor moeten we meer dan twintig jaar terug in de tijd. Want in Nederland staat het onderwerp al sinds 2000 op de kaart. Twee leraren van het blindeninstituut in Zeist publiceerden toen namelijk een boek over het onderwerp, Site Seeing. De auteurs waren Henk Snetselaar en Eric Velleman, een informaticadocent en een aardrijkskundedocent. En ze hadden met hun boek een primeur, want het was namelijk het allereerste Engelstalige boek over webtoegankelijkheid. Een jaar ervoor had het World Wide Web Consortium, het W3C, al een standaard gepubliceerd met richtlijnen voor de toegankelijkheid van webcontent, WCAG. Of zoals de toegankelijkheidsspecialisten het noemen: WCAG. In die tijd was een brancheorgaan er tussen Netscape en Microsoft om het grootste marktaandeel. En websites werden toen ontwikkeld voor één van deze twee browsers. En als je webstandaarden volgde, dan wist je zeker dat de website in geen van de twee goed werkte. Mensen met een functionele beperking hadden het toen extra zwaar, want met hen werd al helemaal geen rekening gehouden. Dat begon te veranderen in 2001 met het programma Drempels Weg van het Ministerie van Volksgezondheid. Daarin werd aandacht gevraagd voor de problemen, waar mensen met een beperking tegenaan liepen, als ze website bezochten. Om een idee te geven: bij veel websites kwamen ze in 2001 niet veel verder dan de homepage. En om daar wat aan te doen, had het blindeninstituut inmiddels een stichting ‘Accessibility’ opgericht. Eric Velleman werd er de adviseur Digitale Toegankelijkheid. Accessibility ontwikkelde zich al snel tot een kenniscentrum, dat veel ervaring op deed met het testen van websites op toegankelijkheid. En ook bij de overheid begon het een onderwerp te worden. Dat werd vooral duidelijk met het kabinetsplan ‘Andere Overheid’ van eind 2003. De kern van dat plan was: de overheid moet transparanter, toegankelijker, effectiever en efficiënter worden. En bovendien is de overheid er voor iedereen. Het was de eerste keer dat in een beleidsplan werd aangegeven dat er een digitale kloof dreigde. Voor het Ministerie van Binnenlandse Zaken was het de aanleiding om een kwaliteitsmodel voor overheidswebsites te laten ontwikkelen, want er waren ambitieuze plannen geformuleerd en die mochten niet in gevaar komen door problemen met de kwaliteit, lees: de toegankelijkheid, van overheidswebsites. Eén van de pijlers van dat plan was namelijk de ontwikkeling van een overheidsbrede zoekmachine. En om alle sites te kunnen indexeren, moesten webpagina’s worden binnen gehaald. Zo’n index moet zo actueel en volledig mogelijk zijn, want anders verliest een zoekmachine snel zijn waarde. Dat binnenhalen gebeurde destijds vooral met wat ‘spiders’ worden genoemd. En laat die zoekmachinetechnologie nou dezelfde problemen hebben met ontoegankelijke webpagina’s als mensen met een functiebeperking. Toen het kwaliteitsmodel in oktober 2004 verscheen, kreeg het de naam ‘Webrichtlijnen’. Duurzaamheid en toegankelijkheid werden geborgd met een gelaagde bouwwijze, een strikte scheiding van vorm en inhoud. Geen afhankelijkheid van wat toen ‘optionele technologie’ werd genoemd, en waarmee vooral javascript en CSS werden bedoeld, en de juiste toepassing van open standaarden. In de webbegeleider was het toegankelijkheidsstandaard ‘WCAG’ verwerkt. En dan niet versie 1, maar de conceptversie WCAG 2, die toen net beschikbaar was. Verder gaan we naar april 2006. Toen diende de Tweede Kamer een motie in, waarin het kabinet werd opgeroepen om haast te maken met de verbetering van de toegankelijkheid. Die motie vormde de aanleiding voor het besluit ‘Kwaliteit Rijksoverheidswebsites’. Dat kabinetsbesluit was volledig gebaseerd op de webbegeleider. En het doel: alle websites van de rijksoverheid moesten eind 2010 aan de Webrichtlijnen voldoen.’ En via convenanten met gemeenten, provincies en wetwaterschappen werden de webbegeleiding in 2008 ook verplicht formele overheden. Dus die verplichting om websites toegankelijk te maken, bestaat eigenlijk al dertien jaar. Alleen heeft die verplichting vandaag de dag een wettelijke status, en dat maakt een groot verschil. In Europa begon webtoegankelijkheid rond 2010 inmiddels ook een onderwerp te worden en er werd gesproken over een Europese richtlijn en die kwam er uiteindelijk in 2016.
Achter de schermen heeft Nederland een belangrijke bijdrage geleverd aan de totstandkoming ervan, want in ons land was al de nodige ervaring voor handen, met wat wel werkt en wat niet. Mede om die reden is nu niet alleen wettelijk verplicht om de toegankelijkheid te verbeteren, maar ook om via een openbare verklaring verantwoording af te leggen over hoe ver een overheidsinstantie ermee is gevorderd. Want alleen eisen dat je volledig aan alle eisen van een standaard moet voldoen, werkt vaak niet, zoals in het verleden al gebleken.
Sinds vorig jaar zijn er voor zo’n 3000 websites en apps toegankelijkheidsverklaringen gepubliceerd en zijn er meer dan 5300 overheidsdomeinen in beeld. Dat zijn er meer dan verwacht, maar het zijn nog lang niet alle websites en apps. Er is dus nog het nodige werk te doen en ook het toegankelijkheidsniveau moet verder verbeteren.
Tegenwoordig wordt webtoegankelijkheid steeds minder gezien als een technische uitdaging en steeds meer als een organisatorische. En dat is een goede ontwikkeling, want bestuurlijke betrokkenheid en commitment blijken een randvoorwaarde te zijn voor succes met toegankelijkheid. De vraag is alleen: hoe krijg je die betrokkenheid en commitment grootschalig en met een langdurig effect voor elkaar? Ik ben benieuwd welke suggesties en ideeën Hidde, Robert Jan en Janita hiervoor hebben.
Randy: Dat was de column van Raph de Rooij. Raph, bedankt voor het inspreken van de column. En ook, ja, er zit natuurlijk een vraag in naar mijn gasten vandaag. Maar voordat we daarnaartoe gaan, hij stelt iets, en dan vraag ik me af: wat vinden jullie daarvan? Hij stelt: digitale toegankelijkheid wordt nu meer, steeds meer gezien als een organisatorische uitdaging, meer dan de technische uitdaging. Robert Jan, wat vind je daarvan? Ben je het daarmee eens?
Robert Jan: Daar ben ik het zeker mee eens, omdat: je kunt het technisch zo goed afregelen, als je de organisatie daarmee niet hebt ingericht, dan zie je gewoon dat er linksom of rechtsom nog steeds heel ontoegankelijke dingen online worden gezet. Dus die organisatie moet eigenlijk over de hele breedte bewust zijn van de toegankelijkheid als basisnorm. Heb je dat niet voor mekaar, dan ben je na twee jaar na de oplevering van je website, ben je nog op hetzelfde punt als wat je eerder had.
Randy: Weer terug bij af.
Robert Jan: Ja.
Randy: Zijn vraag over de suggesties om het organisatorisch in te regelen. Janita heb jij daar een idee bij?
Janita : Ja, nou ja, ik denk dat tegenwoordig organisaties wel steeds meer van bewust zijn dat een website nooit af is en dat je er altijd aan blijft werken. En dat het ook steeds normaler is om bijvoorbeeld elke twee weken, of elke vier weken een nieuwe release te doen van je app of je site. En omdat ook het model zo veranderd is, dat je niet meer zwart-wit een certificaat hebt van ‘je voldoet wel’ of ‘je voldoet niet’, kun je dat gebruiken, om ook dat stapje voor stapje te doen. En ja, ik geef dan ook altijd aan van: nou ja, gebruik die releases ook voor toegankelijkheid, om in elke release iets op te pakken.
Randy: M-hm.
Janita : Zodat je steeds verder daar in komt. Maar het hoeft niet allemaal in één keer.
Randy: Precies.
Janita : En dat kun je prima uitleggen.
Randy: Ja. Ja, dat klinkt ook als een logisch uitgangspunt.
Janita : Ja, dat lijkt mij ook heel werkbaar, omdat het aansluit bij, ja, hoe organisaties nu werken met development.
Randy: Ja, met meer agile werken… noem maar op.
Janita : Ja, precies.
Randy: Oké, nou, dat klinkt als een, ja, als een haalbaar advies.
Hidde / Robert Jan: Als ik mag aansluiten daarover, je ziet ook steeds meer dat… en de toegankelijkheid wordt opgenomen in de Definition of Done. Dus als mensen in agile scrum-achtige situaties werken, dan, nou ja, elk ding wat wordt opgepakt ook wordt gekeken van ‘wat kunnen we hier aan toegankelijkheid aan doen? En is het toegankelijk genoeg?’ En dan wordt er vaak gewerkt met bijvoorbeeld een checklist, die weliswaar niet de hele WCAG gaat wekken, maar wel een aantal belangrijke dingen eruit kan halen, zodat je, als je bijvoorbeeld je jaarlijkse check hebt, dat je dan veel minder problemen tegenkomt. Want dat is het vaak, denk ik, vaak gaan mensen jaarlijks testen bijvoorbeeld, maar je wil tussendoor ook nog zorgen dat alles een beetje op orde blijft, dus dan kan je bijvoorbeeld met checklists werken, die kleiner zijn dan WCAG, maar die wel veel meer mensen kunnen uitvoeren.
Randy: Ja.
Robert Jan: Dus dat zie je ook nog wel eens.
Hidde: Ja, ook als we toch in die hoek zitten over Definition of Done en agile werken, er wordt natuurlijk bij agile werken wordt vaak gesproken over een MVP, een Minimal Viable Product. Ik heb ook wel eens bij organisaties gewerkt, waar ze dan nog een stap verder willen gaan met een Minimal Usable Product, of, wat was die andere, een Minimal Pleasurable Product, iets in die richting, wat wel meer aansluit, denk ik, op de algehele ervaring, waar je ook, als je toch al zulke richtlijnen in je DOD meeneemt, ja, daar ook gewoon rekening mee kan houden, denk ik.
Randy: Ja, er wordt even een pak stellingen tussendoor gegooid, ook gereageerd op de column van Raph. Iets waar ik het ook nog over wil hebben, is over het verschil tussen handmatig en automatisch toetsen. Hidde, heb jij daar een mening over?
Hidde: Ja, ik kan kort uitleggen, denk ik, wat het verschil is.
Randy: Doe dat eerst is.
Hidde: Men wil heel graag automatisch testen, want het zou natuurlijk fantastisch zijn als je een website hebt en je kunt elke minuut kijken hoe toegankelijk het allemaal is. Maar je hoort misschien al aan mijn stem dat dat iets is wat eigenlijk niet mogelijk is, omdat heel veel dingen niet automatisch testbaar zijn.
Randy: M-hm.
Hidde: Dat verschilt een beetje aan wie je het vraagt. Dus aanbidders van automatische test software, roepen wel eens percentages in de richting van 40, 50 procent. En anderen zeggen juist ’10 tot 20 procent’. Het is in ieder geval echte een deel van je issues.
Randy: Ja.
Hidde: En het hangt er erg van af ook wat voor soort website je mee te maken hebt en wat voor soort problemen. Er zijn best wel veel dingen die automatisch vindbaar zijn, maar er zijn ook heel veel dingen die je echt moet laten beoordelen door iemand die veel verstand heeft van WCAG. Dat moet je dus handmatig toetsen. En er zit ook een verschil denk ik in hoe vaak je het kunt doen. Want automatisch toetsen kan je de hele tijd doen, dus elke regel code die erbij komt, kun. Je een automatische toets overheen leggen.
Randy: M-hm.
Hidde: Terwijl een handmatige toets, daar huur je misschien iemand voor in. Hoeft niet altijd, kan ook een checklist zijn, wat ik net noemde. Dat je dat in je team oppakt. Maar dat kun je ook door iemand laten doen en dan heel WCAG langslopen, maar dan krijg je bijvoorbeeld 50 richtlijnen die je gaat nalopen, en dat is wel heel wat anders. Dat is ook een groter project.
Randy: M-hm.
Hidde: En soms wordt het ook gecombineerd, want ik denk dat de meeste mensen die handmatig testen ook, als ze een test van de website doen, een klein deel daarvan met een automatische tool oplossen.
Randy: Ja, begrijp ik.
Hidde: Omdat sommige dingen, ja, te saai zijn, om zelf te gaan opzoeken, zeg maar. dus of je syntax helemaal perfect is, dat kun je heel goed bekijken met een tool.
Randy: Misschien contrast ook, dat soort… een voorbeeld wat automatisch makkelijker kan.
Hidde: Ja, dat is ook een… dat is een formule en dat kun je gewoon uitrekenen, maar dat is veel makkelijker inderdaad, om met een tool te bekijken.
Randy: Ja, ik kan me voorstellen ook, als je het vaak doet, dat die dingen die zo voor de hand liggend zijn, dat je dat graag uitbesteedt aan een tooltje.
Hidde: Ja.
Randy: Toch, als we het hebben over, ja, of het dan 40 procent is, dat kan een hoog percentage, of 10 procent, elk procentje wat kan worden meegenomen door een tool die en continu kan kijken en heel snel de hele website onder de loep neemt, dat is toch weer iets wat uit handen wordt genomen, waardoor je weer meer tijd vrij hebt voor andere zaken.
Hidde: Ja, wat nog wel goed is om daarbij in het achterhoofd te houden, is dat de dingen die automatisch testbaar zijn, zijn niet per se de grootste problemen. Het kan wel zijn dat je ze makkelijk kunt testen, maar dat betekent misschien niet dat ze een grote barrière vormen, terwijl misschien de dingen die moeilijk testbaar zijn wel grote barrières zijn. Dus dat is wel… de impact van de issues is niet altijd gelijk aan hoe makkelijk je ze kan testen.
Randy: M-hm. Dat is een belangrijke om mee te nemen.
Hidde: Zou wel mooi zijn.
Randy: Nou, misschien iets voor de toekomst, nog aan te werken. Hidde, jij hebt ook gewerkt aan een, of je werkt nu nog steeds, moet ik zeggen, aan een standaard voor offering-tools, zoals dat wel genoemd wordt. Tools waarmee content wordt beheerd, die online komt. Wat kan je daar nog over vertellen?
Hidde: Ja, dat rijmt al een klein beetje terug op wat we eerder zeiden. Wat Janita eerder zie, dat ja, hoe eerder je begint met toegankelijkheid, hoe beter.
Randy: Ja, precies.
Hidde: En ook bij de keuze van tools die je gebruikt en met name dan CMS-tools, tools waarmee je formulieren maakt, waarmee je raadsvergaderingen opslaat. Eigenlijk alles waarmee je webcontent maakt en dus alles wat onder WCAG valt.
Randy: M-hm.
Hidde: Dat soort tools, daarmee kun je eigenlijk je toegankelijkheid veel eerder aanpakken. Want als die tool goed is in toegankelijkheid en toegankelijkheid goed meeneemt, dan wordt het uiteindelijke product wordt daar veel beter van. Want ja, dan heb je uiteindelijk misschien veel minder problemen en zo’n tool kan ook helpen met het vinden van problemen. Dus als je… je kan je voorstellen, als je een CMS hebt, waar je een afbeelding in hebt, en je gooit er wat tekst overheen, dan zou dat CMS kunnen detecteren: ‘hé, wacht, er zit niet genoeg contrast in’, en die zou daar iets over kunnen zeggen. Want CMS kan ook stil blijven. En als je een CMS kiest wat dat soort dingen opmerkt, dan is je toegankelijkheidsstrategie ineens iets makkelijker te doen, want dan zijn bepaalde problemen gewoon eerder vindbaar. En ja, daar is een standaard voor, dat is de ATAG standaard. Kunnen we ook een linkje naar opnemen in de show notes.
Randy: Dus je zegt: ‘ETAG’, maar het is… je schrijft ‘ATAG’, geloof ik.
Hidde: Ja, sorry, ik spreek het dan weer op zijn Engels uit. Het is A-T-A-G. En dat is dus een standaard voor alle tools die een webcontent maken. En dan kun je denken aan CMS’en, maar ook bijvoorbeeld aan Learning Management Systems, LMS.
Randy: M-hm.
Hidde: Wat in scholen wordt gebruikt, wat in ziekenhuizen wordt gebruikt. En meestal zijn het ook tools die heel erg een snijvlak hebben met mensen hun dagelijks leven. Dus iemand die naar een dokter moet en medicijnen nodig heeft en een recept krijgt, wat online staat, dat is misschien wel webcontent, dat wordt misschien wel gegenereerd door een of andere tool. En als die tool daar heel goed in is, dan is dat misschien toegankelijker. En ik denk dat we daar heel veel kansen kunnen grijpen. Want als we dat soort tools toegankelijker kunnen maken en toegankelijkheid beter laten embedden, dan kunnen we, ja, zorgen dat dat soort dingen juist toegankelijker worden. En dat geldt natuurlijk ook voor onderwijs. Je wil dat iedereen onderwijs kan volgen. Dus ook daar geldt dat het, ja, als je die tools beter toegankelijk kunt krijgen, dan kan het hele onderwijs daarmee toegankelijker worden, voor veel meer mensen bruikbaar.
Randy: M-hm, m-hm.
Hidde: En daar wordt ook wel veel aandacht aan besteed. En dat komt ook omdat in de Verenigde Staten de wetgeving net wat anders in mekaar zit en daar je voor de rechter kan worden gesleept als school, als je niet zorgt dat al je leerlingen het kunnen volgen. En daardoor zijn heel veel tools daar ook echt mee bezig. En ja, de richtlijn daarvoor is dus de ATAG-standaard. Wordt veel minder op gecheckt. Het komt wel voor in de Europese norm. Niet onder de noemer ‘ATAG’, maar wel onder de noemer ‘offering-tools’.
Randy: Oké.
Hidde: En ja, het is voor iedereen die zo’n tool maakt belangrijk, denk ik, om dat mee te nemen. Dus als je een formulierengenerator verkoopt aan gemeenten en je kunt er bij vertellen ‘die van ons maakt toegankelijke formulieren’, ja, dan… een tip voor iedereen die luistert: ga dat doen. Maar het is natuurlijk ook zo, dat als je een gemeente bent en je gebruikt zo’n tool, dat je daar dan, ja, betere resultaten mee kunt boeken, omdat er, ja, betere output uit komt.
Randy: Als je de… en merk je dan ook dat die fabrikanten van dergelijke tools, dat ze dat als selling point dan willen gaan gebruiken?
Hidde: Ja, vanuit de VUC willen we dat graag zien. Vanuit de Europese commissie, waar ik een project mee doe voor het W3C, willen ze dat ook graag zien. Ik moet zeggen, uit de praktijk kan ik zeggen dat ik het soms zie, maar niet heel vaak. Er zijn ook in Nederland wel fabrikanten die het er bij zeggen en ik denk dat dat een hele goede ontwikkeling is. Maar ik zou het graag meer zien. En ik denk wel dat het echt een mooie kans is, omdat er ongelooflijk veel websites, en Raph noemde het net al, er zijn heel veel websites die toegankelijk moeten zijn en systemen die toegankelijk moeten zijn en blijven. Dus als je dat soort tools ontwikkelt en je hebt je toegankelijkheid goed op orde, dan kun je dat beter verkopen aan je klanten. En dat zou je dan dus kunnen doen aan de hand van de ATAG-standaard. Die gaat in op allerlei verschillende dingen, die te maken hebben met offering-tools, met dat soort systemen.
Randy: Ja, ja. Ik heb zelf dan een achtergrond ook in CMS en ik, ook als ik wat eerder in mijn carrière kijk, dan merkte ik vaak een spanningsveld tussen de gebruikerservaringen en gebruikersvriendelijkheid enerzijds en anderzijds ook wat de opdrachtgever dan graag wil dat qua functionaliteit, meer functionaliteit betekende vaak dan, ja, risico dat de gebruikerservaring voor zowel de contentmanager als de uiteindelijke eindgebruiker dan minder kon worden. Ik kan me voorstellen dat die bedrijven, die die tools maken, ja, wel meekijken met zo’n standaard, maar ja, misschien toch ook hun eigen mening er van hebben. Hoe ga je… ja, hoe is de relatie, als je aan zo’n standaard werkt, met de bedrijven waar het dan uiteindelijk moet op worden toegepast?
Hidde: Ja, iets waar we mee bezig zijn bij W3C, is een lijst van tools, waar organisaties zoals gemeenten, zoals overheden kunnen kijken ‘welke tool moet ik gaan kopen?’ En we willen graag dat iedereen op die lijst komt en we willen graag laten zien wat voor fantastische functionaliteiten erin worden gemaakt bij al die leveranciers. En daar zijn we mee bezig. Maar het gaat wel op basis van de ATAG-standaard, en dat betekent dus dat er wel aan allerlei van dat soort eisen moet worden voldoen. Dus, ja, is het bijvoorbeeld mogelijk om een alternatieve tekst bij een afbeelding toe te voegen? Er zijn sociale netwerken, waar dat tot voor kort gewoon nog niet kon.
Randy: Ja, dat is heel erg.
Hidde: En ja, je ziet wel eens een minister aftreden, zoals vandaag, met een berichtje op Twitter. Een plaatje erbij, een tekst erin. Geen alternatieve teksten. Dat zijn soort dingen die heel erg veel voorkomen. Maar goed, die lijst van offering-tools, die zal dus zijn op basis van die ATAG-standaard en we hopen daarmee dat bedrijven met ons mee willen doen en ook kunnen laten zien wat ze allemaal in huis hebben, of misschien daar dan toch een keer een extra team op zetten. Want ja, ze kunnen een hoop verbeteren. En ja, er zit een soort… er zit een effect achter. Want als je dat één keer goed doet, dan kun je heel veel verschillende sites in één keer oplossen. Dus als jij als leverancier voor honderd gemeenten werkt, dan kun je in eens honderd gemeentes meer toegankelijk maken. En dat is denk ik heel interessant.
Randy: Zeker, ja.
Hidde: Mooi om daar ook even iets over te horen. En laten we ook een aantal van die linkjes naar die lijst, naar de guidelines zelf, laten we dat ook opnemen in de show notes, dat luisteraars dat makkelijk kunnen terugvinden.
Randy: Oké. Ik… ja, we gaan richting de afronding van ons gesprek. Voor dat we, ja, ik heb gekeken van: wat zijn wat take-aways die ik wil meegeven aan de luisteraar, voordat ik daarnaartoe ga, als we het daar hebben over een quick-win, of wat laaghangend fruit, als het gaat om het toepassen van een richtlijn, of als het gaat om hoe je het kan toetsen, of hoe je het kan inbedden in je organisatie, zou ik het mooi vinden om van jullie alle drie iets te horen, wat je dan graag wilt aanstippen. Wie kan ik als eerste het woord geven?
Hidde: Ja…
Randy: Robert Jan.
Robert Jan: Ja.
Randy: Vertel.
Robert Jan: Neem het mee in je aanbesteding, op het moment dat je voor een nieuwe leverancier kiest. Dat kan zijn voor je ontwerp, of voor je CMS. Maakt mij allemaal niet zo veel uit. Maar zorg er ook vooral voor dat je het in je organisatie goed op poten krijgt. Daar zit de grootste crux.
Randy: Oké. Ja, in je organisatie poten krijgen, heeft denk ik wel wat meer voeten in aarde, dan een regel erbij bij een offer, die naar de verschillende partijen gaat.
Robert Jan: Ja.
Randy: Oké, bedankt. Janita.
Janita : Ja, ik denk dat het goed is om te kijken binnen een organisatie wat je al hebt en wat voor toegankelijke sites je al hebt. Ik zie bijvoorbeeld vaak dat gemeentes dan voor een nieuw project een nieuwe site maken in weer een nieuw systeem van weer een nieuwe leverancier. Dat kan goed gaan, maar het gaat vaak qua toegankelijkheid niet goed.
Randy: M-hm.
Janita : Terwijl, ja, je hebt die kennis al. Je hebt al systemen, waar het al wel goed in werkt. Ja, dan lijkt me dat het beter is, om diezelfde tool daar ook voor in te zetten. En ja, dat is uiteindelijk voor de gebruiker ook fijner, als het meer gelijk is, zeg maar, en op de gelijke manier werkt.
Randy: Precies.
Janita : Dan dat het ook qua vormgeving weer anders is.
Randy: Helder. Dank je wel, Janita. Hidde, heb jij een tip? Een tip voor wat laaghangend fruit voor een quick-win?
Hidde: Ja, ik sluit me zeker ook aan bij Janita en bij Robert Jan. Het is belangrijk om bij aanbestedingen die standaarden mee te nemen en misschien ook expliciet te zeggen ‘laat je rapport maar zien, als je bij ons dat werk komt doen. En zeg dat je daar aan kunt voldoen.’ Want er wordt nog wel vaker gezegd dat men voldoet, dan dat het ook echt zo is.
Randy: M-hm.
Hidde: Maar als ik een tip zou moeten geven, dan wil ik misschien eentje doen vanuit mijn achtergrond als ontwikkelaar: als je mensen gaat aannemen als developer, dan ga je natuurlijk kijken wat ze allemaal kunnen. Maar zorg dat ze HTML kunnen. Dat is iets wat heel vaak niet in omschrijvingen staat. Waar ook, als er sollicitaties zijn, niet per se naar wordt gekeken. Het is interessant, als je een laatste framework kunt, of fantastische beeldtools kunt gebruiken en al dat soort dingen. en heel vaak wordt er niet meer gekeken naar of de HTML-kennis in orde is. En ik denk dat dat één van de snelste winst kan zijn. Eén van de mooiste manieren om snel vooruit te komen, is als je ontwikkelaars daar ontzettend goed in zijn. En dat is eigenlijk iets wat je in Nederland niet per se heel veel ziet, dat mensen daar goed in zijn. Dus als je die kunt vinden, dan heb je al gauw een voorsprong. Want dat merk ik in ieder geval, als ik rapporten maak, dat ik heel veel van de problemen die ik vind, dat die eigenlijk in de HTML zitten. En dat ze niet zouden bestaan, als de ontwikkelaar in kwestie heel goed zou zijn in HTML. Dus ga daar op uitzoeken, als je mensen gaat aannemen.
Randy: Een hele mooie tip, denk ik, voor de… ja, een wervingstip eigenlijk en ook voor hiring-managers. Je zegt het zelf al: misschien niet zo’n hele eenvoudige tip, want ja, ze zijn… ja, schijnbaar is, ik neem dat dan even aan van jou, ik heb daar zelf wat minder zicht op, is het niet zo eenvoudig om dan mensen te vinden, die ook HTML goed erbij pakken. Misschien ook een tip voor mensen die zich er dan in willen verdiepen, die aan de ontwikkelkant zitten: zorg ook dat je HTML-kennis op orde is. Zou ik dat zo dan toe kunnen voegen, Hidde?
Hidde: Zeker, ja. En stuur je mensen op workshop, als ze er niet goed in zijn. Want het is niet per se een ingewikkeld centraal om te kunnen.
Randy: Als je al een eind met andere dingen bent, dan ja, zou je zeggen: pak die er ook dan bij.
Hidde: Pak hem erbij, ja.
Randy: Heel goed. Bedankt. Oké. Nou, ik heb dit gesprek… ja, ik heb natuurlijk al jullie meningen en jullie antwoorden gehoord. Er zijn een paar dingen die mij zijn opgevallen, die ik even dan eigenlijk samenvat voor de luisteraars take-away. Als we het hebben over automatisch testen, is zeker een handige aanvulling, maar je kunt er absoluut niet alles mee. Verre van. En ja, de zaken die ook makkelijk automatisch te testen zijn, zijn niet per se de grootste struikelblokken. Dus verwacht niet dat je daar alles mee af kan vangen. We gaan met digitale toegankelijkheid van een meer technische uitdaging naar een meer een organisatorische uitdaging. Het moet in de organisatie goed worden opgepakt, het moet embedded zijn in de organisatie, om te zorgen dat er structureel aandacht voor is. Want alleen met een aanbesteding aandacht voor, of met een project en daarna het weer laten varen, dan ben je zo weer bij nul. En dat is zonde. Offering-tools die toegankelijk content creëren, die zijn er. Er is een lijst van, er is een standaard voor. We zorgen dat die linkjes in de show notes komen. Dus kijk er ook speciaal naar uit, als je een nieuwe tool wilt gaan gebruiken. En dan, ja, ook nog een hele mooie: zorg ervoor, als je, verzeker ook met korte releases, met korte ontwikkelcycli, zorg ervoor dat elke release iets in je release zit, wat met toegankelijkheid te maken heeft, wat de toegankelijkheid verbetert. Dan ben je er toch continu aan bezig en neem het op in je DOD, je Definition of Done. Dan hebben we denk ik een paar mooie, ja, zaken, wat take-aways voor de luisteraar om mee te nemen. Oké. Wil ik jullie heel erg bedanken voor jullie, ja, eigenlijk jullie tijd en jullie inzichten en jullie kennis. Bedankt Raph ook voor je column. Nou, tot zover mijn gesprek met Hidde de Vries, Robert Jan Verkade van Eend en Janita Top. Dat was het dan voor deze aflevering. Bedankt voor het luisteren. Heb je interesse in meer interessante gesprekken als deze, abonneer dan op de podcast via Spotify, Apple Podcast, Google Podcast, of in je favoriete podcast app. Dan kun je eenvoudig de volgende aflevering beluisteren. Het helpt ons ook enorm als je op het platform van je keuze een recensie achter laat. En zit er iets belangrijks in de aflevering voor jouw organisatie, deel het dan met je collega, manager, of product-owner. Wil je meer weten over digitale toegankelijkheid, ga dan naar gebruikercentraal.nl en digitoegankelijk.nl. Tot slot beste luisteraars: soms kijk ik het nieuws en als je alleen daar op af zou gaan, dan zou je denken: wat is er veel verdeeldheid. Ik denk dan graag aan de woorden van het fictieve karakter Iroh. Het is belangrijk om wijsheid te halen van veel verschillende plekken. Als je het één plek haalt, wordt het rigide en muf. En daarop aansluitend, en ik denk ook, mooi toepasbaar als het gaat om digitale toegankelijkheid: soms is een ander helpen de beste manier om je eigen problemen op te lossen. Beste luisteraars, tot de volgende.