Terugblik op webinar: Wettelijke verplichting toegankelijkheid apps

Op 25 maart vond het webinar plaats over de toegankelijkheid van apps, georganiseerd door DigiToegankelijk en Gebruiker Centraal. Hoe voldoe je aan de wettelijke verplichting (Besluit digitale toegankelijkheid Overheid) die op 23 juni van kracht wordt?

Tijdens dit webinar gaf Kristian Mul (productowner Digitoegankelijk, Logius) een toelichting op de wettelijke verplichtingen, deadlines en wat daarbij komt kijken. Bram Duvigneau (ervaringsdeskundige en onderzoeker en adviseur van Firm Ground) en Paul van Workum (app-ontwikkelaar en oprichter van de Stichting Appt) lieten hulpmiddelen zien om apps te toegankelijk te maken, zoals de schermlezer, stembediening, schakelbediening en toetsenbordbediening.

Wil je het webinar terugkijken? Of wil je de vragen en antwoorden uit de chat lezen? Je vindt alles op deze pagina. Inclusief de links die in het webinar en in de chat werden gedeeld en de presentaties.

Terugkijken webinar

Heb je het webinar gemist of wil je dit nog eens terugkijken?

Presentaties

Handige links

Deze links deelden wij en kijkers in de chat:

 

Kristian Mul aan het woord
Kristian Mul aan het woord

Vragen en antwoorden uit de chat

Veel kijkersvragen zijn door de sprekers in het webinar beantwoord, maar in de chat werden ook veel vragen van kijkers door andere kijkers beantwoord. Die hebben we voor je op een rijtje gezet.

Is er een verschil tussen apps voor interne medewerkers en externe apps? 

Nee. Zowel interne als externe apps moeten toegankelijk zijn. Immers, als 25-30% van de Nederlandse bevolking een beperking heeft, dan is dat voor jouw medewerkers niet anders. Los van wetgeving, zou je je apps toch ook voor je medewerkers toegankelijk willen maken?

Vanaf 2022 moeten lidstaten wetgeving overnemen en op 2025 toepassen. Kan het zijn dat voor 2025 al de verplichting intreedt in NL? Of hoeft de app pas echt in 2025 geheel te voldoen?

Apps van overheden moeten vanaf 23 juni 2021 voldoen.

Is de verklaring en invulassistent hetzelfde als die voor websites?

Ja, in de invulassistent voor toegankelijkheidsverklaringen kun je ook aangeven dat het om een app gaat.

Waar moet de toegankelijkheidsverklaring van de applicaties gepubliceerd worden? Voor de websites moet dit ook op de website zelf. Hoe zit dit met de apps? In de app zelf lijkt me vaak niet heel toegankelijk.

Je kunt de toegankelijkheidsverklaring in de appstore of op de website van de betreffende organisatie plaatsen.

Je komt ook in een centraal register (via de website toegankelijkheidsverklaring.nl kunnen overheidsorganisaties hun toegankelijkheidsverklaringen op 1 centrale plek vastleggen) terecht, daar kun je naar linken.

Over toegankelijkheidsverklaringen voor apps staat het in de Europese richtlijn 2016/2102, artikel 7, lid 1; zie: https://eur-lex.europa.eu/eli/dir/2016/2102/oj?locale=nl#d1e883-1-1 

Is er een soortgelijk auditrapport nodig voor apps als voor de websites?

Ja.

Waar publiceer je het auditrapport? In de app opnemen vinden wij geen optie.

Op de website van de betreffende overheidsinstantie. 

Voor welke apps is de overheid nu verantwoordelijk? Voor alle apps die zij uit haar naam beschikbaar stellen?

Ja.

Als je voor een app een toegankelijke website als alternatief hebt, voldoe je dan?

Nee.

Moeten niet-overheidsinstellingen ook een digitale toegankelijkheidsverklaring hebben op 23 juni 2021? (afgezien van het feit dat dit altijd een goed idee is)

Nee, zie ‘Voor wie is het verplicht?’.

Gaan alle overheidsinstanties de leveranciers dan afzonderlijk benaderen of heeft Logius of de VNG hier ook nog een rol in?

De Vereniging van Nederlandse Gemeenten (VNG) heeft sinds kort het Aanjaagteam. Ook voor gesprekken met leveranciers. Om met een stem te spreken.

De VNG is onlangs ook gestart met een aanjaagteam dat zich specifiek richt op de beslissers en bestuurders bij gemeenten.

Zorg dat de raad (bij gemeenten) het agendeert. Zie toolkit van Ieder(in) om als bewoner of raadslid dit te agenderen.

Hoe kun je controleren of je app wel of niet toegankelijk is?

Je kunt een audit laten doen door een gespecialiseerde partij.

Zijn er tools om apps te checken, zoals voor websites?

Je kunt het best een gespecialiseerde partij hiervoor inhuren, die doen een audit.

De Apptscan is de zelftest om jouw app te testen op toegankelijkheid. Zonder ervaring een app testen op de volledige 50 WCAG punten is erg omvangrijk en complex. Om je app volledig te testen volgens de richtlijnen heb je tevens kennis van de hulpmiddelen nodig. Toch kun je als je zelf al een goede eerste indruk wilt krijgen veel afwijkingen zelf vinden.

Voor Android heb je onder andere de Accessibility Scanner in de Playstore, maar je moet aanvullend wel handmatige testen doen.

Er zijn wel tools voor websites, zoals Wave, Tingtun Page Checker.

Hoe zit het met geografische kaarten, bijvoorbeeld een gebied intekenen in een app, kun je dit überhaupt toegankelijk maken?

Antwoord in webinar, zie ook geo-informatie.

Als ik als gemeente een app van een leverancier afneem voor bijvoorbeeld parkeren, dan is deze leverancier verantwoordelijk voor de toegankelijkheid?

Een app die is gemaakt door een private partij en die wordt gebruikt door een overheidsinstantie, valt binnen de richtlijnen.

Paul van Workum aan het woord, achter hem Bram Duvigneau
Paul van Workum aan het woord, achter hem Bram Duvigneau

Maar als meerdere instanties gebruik maken van die app, gaan die allemaal afzonderlijk met de leveranciers afspraken maken?

Over de toegankelijkheid dien je concrete afspraken te maken in de overeenkomst met de leverancier van de app.

Welke partijen kunnen een goede audit uitvoeren voor apps? Wie lopen hier voorop?

Nomensa helpt met het schrijven van de WCAG guidelines en doet audits.

Vanuit Stichting Appt doen ze ook toegankelijkheidsonderzoeken die voldoen aan de eisen voor een toegankelijkheidsverklaring. De audit van CoronaMelder is door Stichting Accessibility gedaan. 

Er zijn al meerdere partijen goed bezig met audits voor apps. Om er een paar te noemen: Firmground, Stichting Accessibility en Cardan Technobility.

Voorheen stond er een beknopt overzicht met toegankelijkheidseisen per succescriterium op digitoegankelijk.nl. Dit werd later weer verwijderd, maar was voor mij heel waardevolle informatie. Kan ik dit nog ergens terugvinden?

Het overzicht van de WCAG-criteria vind je eenvoudig op https://www.optelecdigitaal.nl/wcag-2-1/succescriteria/ 

En https://www.digitoegankelijk.nl/uitleg-van-eisen

Hoe zit het met regels voor scannen van QR-codes?

Dit is een plaatje, je moet informatie ook op andere manier aanbieden (dus bijvoorbeeld de url eronder zetten). En vergeet niet een alt-tekst toe te voegen.

Is het testplan (document met instructies voor hoe bepaalde bevindingen op te lossen) inzichtelijk voor anderen?

https://appt.nl/kennisbank/testen#test_zelf_op_toegankelijkheid_apptscan

Is een spraakreader verplicht? Dat is een groter investering voor websites.

Spraakondersteuning kan eenvoudig via kosten per aantal hits: https://www.optelecdigitaal.nl/producten/browsealoud/ 

Wat is een gebruiksvriendelijke manier om ervoor te zorgen dat gebruikers de tekst kunnen vergroten?

Door dynamische tekstgrootte te gebruiken in de app. Dan kan de gebruiker zelf de tekstgrootte instellen.

Wat wordt verstaan onder (mobiele) applicatie?

“mobiele applicatie”: toepassingssoftware die is ontworpen en ontwikkeld door of namens overheidsinstanties met het oog op gebruik door het algemene publiek op mobiele toestellen zoals smartphones en tablets. Zij omvat niet de besturingssoftware van die toestellen (mobiele besturingssystemen) noch de hardware;

Bron: https://eur-lex.europa.eu/eli/dir/2016/2102/oj?locale=nl#d1e719-1-1 

Als de app geschikt gemaakt is voor Talkback en VoiceOver kunnen ze dan ook met een keyboard bediend worden?

Nee.

Heel veel aspecten om aan te pakken: voice over, contrast, typografie, schakel/toetsenbordbediening. In welke volgorde kun je deze todo-list het beste prioriteren?

Zorg voor een coördinator voor het geheel en voor specialisten op iedere individuele discipline (design, code en content).

In hoeverre verwachten jullie dat Google en Apple hun a11y-opties komende jaren op dusdanige wijze uitbreiden, dat wanneer je je aan hun dev standaarden (native iOS / android) houdt je al voor een groot deel voldoet aan de nieuwe wetgeving?

Als je je nu aan de native Android- en iOS-development-standaarden houdt, dan voldoe je al. Het gaat vaak fout dat apps niet native gebouwd worden maar met bijvoorbeeld Flutter, Xamarin of React Native. Daar zitten soms functies in dit niet toegankelijk zijn.

En het gaat ook vaak fout bij libraries/code van derde partijen. Houden vaak geen rekening met toegankelijkheid. 

Hoe check je dergelijke labels (naam, rol, waarde) in een app?

Met de schermlezer wordt de naam, rol en waarde voorgelezen.

In de presentatie wordt aangeraden om niet direct te starten met een audit. Maar bij Logius kun je enkel status A, B of C behalen als je een audit laat doen. Hoe kom je dan van status D af?

Niet op een andere manier dan een audit, omdat dat nu eenmaal de wettelijke eis is, maar het kan helpen eerst kennis op te doen en een inventarisatie te maken van de impact voordat je flinke kosten maakt.

Op een bestaande app zou ik wel met een audit starten, als je team geen kennis heeft en/of geen tijd om zich te verdiepen.

Voor overheidsinstanties is het soms gewoon de snelste en meest duidelijke oplossing.

Het doel is om toegankelijkheid in het ontwikkelproces te borgen. Wanneer je een audit doet zonder intern kennis te hebben, blijf je achter de feiten aanlopen. Bij de volgende release van de app zullen er dan weer toegankelijkheidsfouten in zitten. Vandaar dat we aanraden om eerst kennis op te bouwen en de makkelijke problemen op te lossen, voordat je een audit laat doen.

De kennis wordt dan al doende opgedaan, daarna borgen en in regulier ontwikkel- en onderhoudsproces opnemen.

Een audit kan helpen om in de eigen organisatie het te agenderen, maar het is een duur middel. Een audit helpt soms wel om bestuurders te overtuigen.

Audits zijn helemaal niet zo duur in mijn beleving. Manuren om het zelf uit te zoeken zijn vele malen duurder.

Maar zonder auditrapport volgens normen WCAG-EM krijg je je toegankelijkheidsverklaring niet hoger dan status C.

Voor een kleine gemeente zijn audits erg duur. We proberen die kosten bij de aanschaf direct in de begroting op te laten nemen. Helaas lukt dat niet altijd. En dan is er dus ook geen audit. Wel een verklaring, maar inderdaad is dat dan label D.

Op mijn Galaxy S10 is Talkback alleen beschikbaar in Engels. Hoe kunnen we dan toegankelijke Nederlandse apps maken?

Ik ben veel tijd kwijt geweest bij het laten oplezen van postcodes doordat Samsung’s voice assistant dat niet goed deed (en de Google Talkback wel). 

Zijn er voorbeelden van audits van apps beschikbaar online?

De Coronamelder is al ge-audit. Die vind je terug in het centrale register bij de betreffende verklaringen.

In het register van toegankelijkheidsverklaringen kun je sorteren op app.  

Er is momenteel 1 toegankelijkheidsverklaring met een link naar een toegankelijkheidsonderzoek.

Kan iemand de link delen waar staat vastgelegd dat zonder audit alleen label D kan worden behaald?

Status C kan ook zonder rapport. Staat op digitoegankelijk.nl.

Om C te krijgen moet je wel in de verklaring aangeven wanneer je het rapport gaat aanleveren. Je moet in de verklaring aangeven dat je een ‘noodzakelijke verbetermaatregel’ hebt genomen en wanneer die zal zijn uitgevoerd. De ‘noodzakelijke verbetermaatregel’ is in dit geval het laten uitvoeren van een toegankelijkheidsonderzoek. Die maatregel is uitgevoerd als het resultaat van dat onderzoek beschikbaar is; een rapport dus. 

Moet er niet een bijscholing komen voor leveranciers. Of iets dergelijks? Zijn er ook trainingen voor ontwikkelaars (technische know-how)?

Ik spreek binnenkort, als werkveldcommissielid voor Hogeschool Ede, over UX in de ICT opleidingen. Zal dit onderwerp zeker meenemen!

Help ons te verbeteren

Wat vond je van het webinar? Je helpt ons de volgende webinars te verbeteren door deze 3 vragen te beantwoorden.

Meer over Inclusie en digitale toegankelijkheid