Een lezer vroeg me:
Ik ben app-ontwikkelaar. Nu lees ik her en der dat per 28 juni alle apps ’toegankelijk’ moeten zijn voor iedereen, dus ook voor blinden. Betekent dit dat ik al mijn apps van voorleesfuncties moet voorzien? Dat zou een enorme investering zijn.Per 28 juni 2025 wordt de Toegankelijkheidswet van kracht, formeel de Implementatiewet toegankelijkheidsvoorschriften producten en diensten. Dit is de Nederlandse uitwerking van de European Accessibility Act, een van de kernwetten van het Europese Digital Decade programma. Het doel in het kort is het harmoniseren van toegankelijkheidsvoorschriften.
De EAA kent een bijlage met kernvoorschriften voor toegankelijkheid, zoals dat interactie met de gebruiker via meer dan één zintuiglijk kanaal mogelijk is. Dat ligt achter de vraag van de lezer: naast tekst moet voorlezen van die tekst ook mogelijk zijn.
Dit wil echter niet zeggen dat iedereen nu eigen voorleesfuncties moet gaan inbouwen. Zowel Android als Apple iOS hebben ingebouwde schermleesfuncties voor slechtzienden. Zolang je app daar compatibel mee is, voldoe je automatisch aan deze eis. Het is dus meer een kwestie van nagaan wat uniek is voor jouw app dat lastig toegankelijk is voor mensen met een beperking.
Verder moet je goed kijken of je app wel onder het bereik van de Toegankelijkheidswet valt. Veel apps zullen via de Telecommunicatiewet vallen, omdat ze gebruik maken van elektronische communicatiediensten (art. 7a.2) en dan moet je app aan de bijlage voldoen. Voor elektronische handel kom je uit bij art. 6:230fb BW.
De eisen gelden echter niet bij exploitanten van apps die micro-ondernemingen zijn (minder dan tien werknemers en een jaaromzet van maximaal 2 miljoen), en ook niet als de toegankelijkheidseis maakt dat
- je kunt spreken van een fundamentele wijziging van de wezenlijke aard of
- deze een onevenredige last voor de betrokken dienstverlener oplevert (die niet met een subsidiepotje op te lossen is)
Een onevenredige last is een business case analyse: wat zijn de kosten (zowel eenmalig als tijdens productie) en wat zouden de baten zijn als je het wél deed. Alleen als de balans duidelijk negatief is, en je dat dus expliciet hebt uitgezocht vooraf, kun je je hierop beroepen.
De vraagsteller is app-ontwerper. Uiteindelijk krijgt dus niet zij, maar haar opdrachtgever te maken met de toegankelijkheidseisen. Het is wel zaak om in het offertetraject hierbij stil te staan: welke eisen gelden er, hoe vertalen we dat in het ontwerp en wie maakt de eventuele afweging dat sprake is van een van die uitzonderingen?
Ik zeg dit omdat menig klant volstaat met vage zinnen als “leverancier zal zich houden aan toepasselijke wet- en regelgeving” en daar achteraf van maakt dat de leverancier een gratis garantie gaf dat de app EAA compliant is.
Arnoud PS: Meer lezen over de Digital Decade en bijbehorende wet- en regelgeving? Blijf op de hoogte met mijn aankomende boek Wetwijs in het digitale decennium.
Het zou ook kunnen dat TS zelfstandig app ontwerpster is, en die dus in een Appstore verkoopt. En dan een voorlees functie toevoegen in bijvoorbeeld een recepten app kan best duur zijn.
In dat geval geldt toch:
Je hebt helemaal gelijk.
De vraag is of je een voorleesfunctie moet toevoegen aan de app of je app slechts geschikt moet maken voor de native Android- of iOS-functionaliteit qua voorlezen. Dat laatste is wellicht veel minder impactvol.
Aangezien de European Accessibility Act van 2019 is en ‘dus’ ruim daarvoor al bekend was dat er zoiets aankomt, en de 2021 internetconsultatie van de richtlijn van 2021 is, zal dat hier toch geen issue mogen zijn?
Als wel: wat zou jij als klant bij zoiets doen? Klant weet niet wat impact kan hebben en kan dus niet specifiek aangeven welke (aankomende) wet relevant is om op te nemen in een overeenkomst. Het is erg veel waarschijnlijker dat de opdrachtnemer als specialist weet wat er qua wetgeving aan komt dan de opdrachtgever.
Of is de boodschap dan dat het dan beter is om nooit maatwerk te vragen en altijd van de plank te kopen?
Al is het natuurlijk in dit geval niet ‘slechts’ de technische kant maar is er vooral ook inhoudelijk werk aan de winkel.
Wat is er vaag aan van een leverancier te verlangen dat zij zich aan de op haar dienstverlening toepasselijke wetgeving houdt? Dat is toch best een duidelijke afspraak? En wat is het alternatief? Moet je als opdrachtgever dan elke op de dienstverlening mogelijk toepasselijke wet in het contract opnemen? Terwijl je als opdrachtgever een deskundige leverancier inschakelt voor het maken van een product waarvan je mag verwachten dat het voldoet aan erop van toepassing zijnde wet- en regelgeving?
Zou je dus echt de Accessability Act moeten noemen als je een app of webwinkel laat maken door een dienstverlener? En dan dus ook maar gelijk elk denkbaar artikel uit boek 6 BW dat ziet op inrichting van het bestelproces? En de AVG? De AI-Act? De databankenwet voor de zekerheid ook maar noemen? En de Auteurswet? De eIDAS verordening? etc. Als dat écht nodig zou zijn, dan kan niemand meer inkopen zonder met (nogal uitgebreide) algemene inkoopvoorwaarden te werken?
Als je je nichtje die net heeft leren html’en een app of webshop laat bouwen, is het ongetwijfeld raadzaam om uitgebreid functioneel te specificeren en zelf te bedenken welke wet- en regelgeving in acht genomen moet worden. Maar mag je niet gewoon ongevraagd verwachten dat leveranciers die zich actief op de app/webshop etc. markt richten zich ongevraagd al aan alle relevante wet- en regelgeving houden?
Deze wetgeving geldt maar voor een beperkt een aantal doelgroepen. Er is toch niet van een softwareleverancier te verwachten dat hij op de hoogte is van alle specifieke regels voor elke doelgroep? Als jij wilt dat je leverancier voldoet aan specifieke wetgeving, is het wel zo verstandig om die te benoemen in een overeenkomst.
Zorgen dat een app compliant is met wetgeving lijkt mij overigens meer iets waarvoor je een jurist inhuurt dan een ontwikkelaar. Ik vraag mij dan ook af waar “leverancier zal zich houden aan toepasselijke wet- en regelgeving” op slaat. Een ontwikkelaar moet het volgens mij wel heel bont maken voordat dit op hem slaat (misschien wel een leuke voor Arnoud om te kijken wat de praktijk ons leert).
Maar goed, hier heb ik dan ook een beroepsaansprakelijkheidsverzekering voor.
Ik citeer net die clausule omdat ik die vaak zie in inkoopvoorwaarden. De meeste mensen lezen het als een standaardriedel, met als strekking “doe geen illegale dingen bij het maken van het resultaat”. Maar inkopers willen het achteraf wel eens uitleggen als “ieder aspect van het resultaat zal 100% voldoen aan iedere wet die ik tegenkom, ongeacht of we het daar over gehad hebben” en eist dan gratis aanpassing.
Het moge duidelijk zijn dat ik dit niet redelijk vind. Prima natuurlijk om te eisen dat je app EAA compliant is, maar zeg dat dan. En als je pas achteraf ontdekt dat je EAA compliance nodig hebt, pak het dan als meerwerk op in plaats van zo’n truc.
Als fabrikant en verkoper van ovenhandschoenen heb je geen verstand van webwinkels en het daarvoor geldende wettelijke kader. Je wilt een webshop en wilt die laten maken door een professionele leverancier. Hoe specifiek moet je het als opdrachtgevende partij dan maken? Moet je je eerst juridisch laten adviseren over welke wettelijke kaders er voor dat geval allemaal relevant zouden kunnen zijn qua verwachte compliance en die vervolgens opsommen bij je inkoop? Of vindt je dit alleen voor de Accessability Act ineens relevant? En waarom die wet dan wél en de rest (AVG, auteurswet, boek 6 BW, Wet op de omzetbelasting etc.) ineens niet? Mag je die materie wél bekend veronderstellen, maar de EEA niet omdat die wat nieuwer is? En moet je de AI-Act dan ook maar specifiek benoemen voor het geval dat de websitebouwer er iets AI’erigs in stopt? Waarom mag je niet verwachten dat een professional die webwinkels bouwt, weet waar hij rekening mee moet houden? Is het wél voldoende als je overeenkomt dat de webshop zal voldoen aan ‘alle voor het exploiteren van webshops relevante wet- en regelgeving?’.
Als ik Artikel 2 Toepassingsgebied lees, dan zie ik dat het hoofdzakelijk gaat over apparatuur (en het OS in geval van een computer). Wel wordt er verwezen naar e-handelsdiensten en software voor e-boeken.
Het is me totaal niet duidelijk waarom een normaal programma/app hier onder zou vallen. Denk bijvoorbeeld aan Photoshop, Excel, een calculator programma of een game. Onder welk element van artikel 2 zou dit moeten vallen?
Bij die programma’s gaat het als vanzelf goed juist omdat het OS al toegankelijk is. Je kunt prima als blinde met Excel werken, bijvoorbeeld.
Ja en nee. Het OS is in basis toegankelijk, als je de standaard OS componenten gebruikt zal je app ook al 90% (of meer) toegankelijk zijn. Toch kun je er nog flink de fout mee ingaan als je bijvoorbeeld een cross-platform GUI toolkit gebruikt die die toegankelijkheidsfeatures niet implementeert of zelf je GUI componenten bouwt. Zeker bij iets als Excel zal het sheet/tabel component wel maatwerk zijn en kan het dus goed fout gaan. Ook kun je natuurlijk iets simpels fout doen als kleurcombinaties kiezen die niet aan contrasteisen voldoen of afbeeldingen met informatie plaatsen zonder een tekstalternatief.
Als ik het goed zie, heeft Nederland de scope van de EAA een op een overgenomen. In dat geval is het beperkt tot diensten die elektronische communicatie aanbieden, video streaming, transport diensten, bank en financiële diensten, e-book lees software, en e-commerce. Je voorbeelden van Photoshop, Excel, calculator en games vallen er (nog) niet onder.
Het zou voor iedere app ontwikkelaar overigens wel leerzaam zijn om op genoemde platformen ervaring op te doen met gebruik van VoiceOver (iOS), TalkBack (Android) en ingebouwde (verstopte) screenreaderfunctie (Win) i.c.m. toetsenbordnavigatie. Mede vanwege inclusiviteit van mensen met visuele beperkingen op de arbeidsmarkt. Te beginnen met bijv. de app van AFAS. Probeer het eens om deze (on)toegankelijkheid zelf te ervaren!
Heel veel apps en websites tegenwoordig hebben moeite met het ondersteunen van voorlees-software omdat de ‘voorlees’ versie ook gebruikt wordt om advertenties te blokkeren/omzeilen. Technisch gezien kan de app of website het vaak wel, maar weigert de ontwikkelaar het te ondersteunen of wordt tekst bewust geobfusceerd.
Het tegenwerken van een in het OS ingebouwde voorlees- (of andere toegankelijkheids-) functie is wat mij betreft een duidelijke overtreding van de aankomende toegankelijkheidswetgeving. Niet dat het compleet nieuw is, de VS heeft vergelijkbare wetgeving al jaren.
Ik vind dit altijd een interessante discussie. De softwarewereld is wat dit soort regelgeving betreft erg onvolwassen. Je mag verwachten dat een professionele partij waar je een volledige webshop bestelt van deze regelgeving op de hoogte is en je iets levert dat hieraan voldoet met waar nodig de juiste instructies, zoals dat je goede afbeeldingsbeschrijvingen voor je producten moet invullen. Helaas is toegankelijkheid in de praktijk voor veel developers niet iets waar ze mee bezig zijn en wat ook niet in de meeste informatica-opleidingen zit. Bij veel partijen ontbreekt dus simpelweg de kennis om dit goed te doen.
Ik werk al jaren in de technische kant van dit vakgebied en zelfs bij de overheid waar soortgelijke regelgeving al langer geldt is het eigenlijk nog niet zo best gesteld met toegankelijkheid. Hier zitten over het algemeen ook geen consequenties aan voor de overheden of hun leveranciers. Ik vrees dat het met de EAA helaas ook zo zal gaan. Het toezicht is per sector bij de toezichthouder voor die desbetreffende sector ondergebracht en de meeste toezichthouders hebben nog nauwelijks kennis over het onderwerp.