Toegankelijke apps ontwikkelen voor overheid en gemeentes.

Wettelijke verplichting omtrent Digitale Toegankelijkheid

Sinds september 2020 moeten volgens het Besluit Digitale Toegankelijkheid Overheid alle websites van gemeenten, overheden en semi-overheden aan de richtlijnen van WCAG 2.1 voldoen (niveau A + AA), we noemen dit ook wel: Digitoegankelijk. Sinds juni 2021 geldt deze verplichting ook voor mobiele apps (iOS en Android) en er is op Europees niveau bepaald dat vanaf 2025 alle publieke diensten hieraan dienen te voldoen (European Accessibility Act, EAA).

In het kort betekent dit dat digitale voorzieningen gebruikt moeten kunnen worden door iedereen, ongeacht digitale vaardigheid en eventuele beperking. Met als resultaat een toegankelijke digitale overheid.

Toegankelijke apps

Wat houdt digitale toegankelijkheid precies in? Waarom is het belangrijk? Waaraan moet worden voldaan? Waar moet je op letten en hoe gaan wij als ontwerpers en ontwikkelaars van YipYip aan de slag wanneer we een Native iOS, Android of Flutter app digitoegankelijk maken? We leggen het uit in dit artikel.

Terminologie

Wanneer we een app maken die volledig moet voldoen aan alle eisen van digitoegankelijk betreden we een speelveld waar verschillende termen worden gebruikt. Ook in dit artikel worden verschillende termen toegepast, vandaar dat we hieronder een korte toelichting hebben geschreven:

Digitoegankelijkheid

Toegankelijkheid (in Nederland ook wel Digitoegankelijk genoemd) gaat over het mogelijk maken dat iedereen – ongeacht leeftijd, geslacht, afkomst, digitale vaardigheid en/of een eventuele lichamelijke of geestelijke beperking – gebruik kan maken van mobiele apps en websites om informatie te raadplegen of diensten te gebruiken.

Kortom: ook iemand die blind is moet zijn of haar belastingaangifte kunnen doen via het desbetreffende formulier en ook iemand die slechthorend of doof is moet een uitleg video in (bijvoorbeeld) een app van de overheid kunnen raadplegen.

De Engelse term “accessibility” of de afkorting “a11y” worden ook vaak gebruikt om hetzelfde onderwerp aan te duiden.

WCAG

De WCAG (Web Content Accessibility Guidelines) zijn de richtlijnen waaraan gerefereerd wordt in de wet en dienen als uitgangspunt te worden genomen. De WCAG zijn echter gericht op het web (de W in WCAG) en is dus vooral geschikt voor websites en webapplicaties. Voor het ontwikkelen van toegankelijke apps dienen de richtlijnen te worden geïnterpreteerd en vertaald naar een zo goed mogelijk alternatief. De richtlijnen zijn ontwikkeld door het W3C (World Wide Web Consortium), een internationale organisatie die de verantwoordelijkheid draagt over alle webstandaarden. Momenteel is versie 2.1 van de WCAG de meest recente (en daarmee geldende) versie.

De richtlijnen bestaan uit drie conformiteitsniveaus (A, AA en AAA) die worden ingedeeld op basis van de impact op de functionaliteit van de website of app. Waarbij A het laagste niveau is en AAA het hoogste. Nederlandse overheidsorganisaties moeten minimaal voldoen aan niveau A én AA van WCAG 2.1.

Naast de niveaus bestaat de richtlijn uit vier principes:

  1. Waarneembaarheid: de informatie en componenten moeten waarneembaar zijn met de voor de voor de persoon beschikbare zintuigen (zicht, gehoor, etc.).
  2. Bedienbaarheid: alle componenten moeten bruikbaar en bedienbaar zijn voor de gebruiker.
  3. Begrijpelijkheid: alle informatie moet begrijpelijk zijn voor de gebruiker.
  4. Robuustheid: de app of website moet technisch goed genoeg gebouwd zijn voor gebruik met technische hulpmiddelen.

Toegankelijkheidsverklaring

Nadat de app of website toegankelijk gemaakt is door ontwerpers en ontwikkelaars dient deze een verklaring te krijgen waarin aangegeven wordt wat het niveau van het product is, dit noemen we een toegankelijkheidsverklaring. Deze verklaring moet vanuit het product te bereiken zijn en ingevuld worden door iemand die hier geschikt voor is. Hierover later meer.

50% van de Nederlanders gebruikt instellingen voor toegankelijkheid

Volgens een onafhankelijk onderzoek van Stichting Appt gebruikt méér dan de helft van de Nederlanders – zo'n 9 miljoen mensen – tenminste één toegankelijkheidsinstelling op hun telefoon. Bijna 20% van de gebruikers past meerdere van deze instellingen toe. Van de groep die die toegankelijkheidsinstellingen gebruikt kiest ongeveer 35% voor een alternatieve tekstgrootte.

Daarnaast zijn er – voor zover dit bekend is – minimaal 1.3 miljoen Nederlanders met een vorm van kleurenblindheid, gebruikers waarmee rekening gehouden moet worden tijdens het ontwerpproces. Ook zijn er meer dan 6.000 Nederlanders die de tekst op hun scherm laten voorlezen, omdat zij het zelf niet (of niet goed genoeg) kunnen waarnemen.

Al met al zijn deze cijfers een stuk hoger dan vaak verwacht wordt. Reden genoeg om digitale toegankelijkheid hoog op de agenda te plaatsen bij het ontwerpen en ontwikkelen van een applicatie.

Voor wie is het verplicht?

Voldoen aan de WCAG 2.1 A + AA is essentieel met oog op de bovengenoemde cijfers. Momenteel is het dan ook verplicht voor alle staats-, regionale en lokale overheidsinstanties, organisaties die onder het Rijk vallen, waterschappen, provincies en gemeenten om hier rekening mee te houden. De wet geldt ook voor samenwerkingsverbanden, bestaande uit één of meerdere overheidsorganisaties of publiekrechtelijke instellingen, bij afwezigheid van een industrieel of commercieel doel.

Vanaf 28 juni 2025 treedt de European Accessibility Act (EAA) in werking. Vanaf dat moment moeten niet alleen overheidsorganisaties en gemeentes voldoen, maar ook bedrijven en organisaties die goederen of diensten aanbieden aan het brede publiek, zoals webshops, banken, gezondheidsinstellingen en vervoersbedrijven. Bedrijven en organisaties die niet voldoen aan de eisen van de EAA riskeren boetes en juridische gevolgen. Het is daarom van groot belang dat bedrijven en organisaties zich tijdig voorbereiden op de implementatie van de EAA en ervoor zorgen dat hun producten en diensten toegankelijk zijn voor mensen met een handicap.

Aan de slag: waarmee houden de app ontwikkelaars en ontwerpers rekening?

Wanneer we bij YipYip een digitale iOS, Android of Flutter app ontwikkelen volgen we alle richtlijnen uit de WCAG 2.1 A + AA, dit begint al tijdens het maken van het app design. Tijdens het volledige proces zorgen we ervoor dat we de regels zo goed mogelijk worden toegepast. Hieronder leggen we enkele praktijktoepassingen uit.

Kleurcontrasten en kleurenblindheid

Ongeveer 1.3 miljoen Nederlanders hebben een vorm van kleurenblindheid. Ze zien hierdoor kleuren anders dan anderen of kunnen hierdoor mogelijk contrasten tussen verschillende kleuren niet goed waarnemen. Door middel van de contrast checker Sip, de kleurenblindheid simulator Sim Daltonism en de slimme accessibility tools van Stark maken we bij YipYip ontwerpbeslissingen “door de lens” van persoon met kleurenblindheid. We zorgen ervoor dat alle verplichte contrastscores gehaald worden en passen het ontwerp aan wanneer het niet voldoende toegankelijk is voor iemand met bijvoorbeeld Deuteranopia of Tritanopia.

Formaat van lettertypen

Elke geschreven tekst moet volgens de WCAG minimaal 200% te vergroten zijn. Webbrowsers ondersteunen dit standaard, hier hoeft de ontwikkelaar weinig aan te doen behalve controleren of de rest van de website of webapplicatie niet onbruikbaar wordt.

Op smartphones kunnen gebruikers via de toegankelijkheidsinstellingen van hun telefoon het lettertype voor álle mobiele applicaties tegelijkertijd aanpassen. Ondersteuning hiervoor moet voor apps wel zelf ontwikkelt worden. Een goede implementatie waarbij de app bruikbaar blijft voor iedereen is essentieel maar complex, zoals in onderstaand voorbeeld van WhatsApp en Apple Maps zichtbaar is. In de implementatie zit veel tijd (zowel qua ontwikkeling maar ook in de vorm van testen), maar er moet wel aan voldaan worden.

YipYip maakt hiervoor gebruik van de slimme tooling die Apple (voor iOS apps) en Google (voor Android apps) aanbieden. App designers werken aan het ontwikkelen van verschillende tekststijlen en gewenste formaten, en samen met onze ontwikkelaars worden deze gekoppeld aan de instellingen in Xcode en Android Studio, de ontwikkelomgevingen van onze maatwerk apps. Door deze koppelingen te leggen maken we het mogelijk dat het lettertype in de apps procentueel schaalt naar het door de gebruiker ingestelde en gewenste formaat. Om ervoor te zorgen dat de apps ook met (zeer) grote tekst bruikbaar blijven stellen we regels op zoals een maximum grootte voor koppen en plaatsen we bijvoorbeeld vanaf een bepaald formaat knoppen die normaal naast elkaar staan onder elkaar, zoals hieronder voor de StopApp te zien is. Hiermee blijft de app bruikbaar voor iedereen, ongeacht de grootte van het lettertype wat iemand ingesteld heeft.

Ondersteuning voor liggende schermen

Alle schermen binnen een app moeten verplicht ondersteuning bieden voor "landscape modus"; het liggend gebruiken van een telefoon of tablet. Hierbij dient rekening gehouden te worden met de extra horizontale ruimte, maar ook de beperkte verticale ruimte die ontstaat. Om dit te ondersteunen worden navigatiebalken bijvoorbeeld minder hoog, tonen we resultaten naast een invoerveld (in plaats van er onder) en houden we rekening met zogenaamde "safe-area's", "on-screen controls" en de verschillende schermformaten van iPhone- en Android-telefoons.

Het ontwerpen van regels, de implementatie hiervan én het testen van de app op verschillende apparaten tijdens / na ontwikkeling is erg belangrijk: tot 2025 moeten we bijvoorbeeld het zeer kleine iPhone SE device nog steeds ondersteunen en hebben veel Android telefoons een eigen toetsenbord implementatie. Allemaal zaken waar rekening mee moet worden gehouden aangezien deze vaak veel ruimte van het scherm innemen. Deze technische beperkingen zorgen mogelijk voor complexiteit waar vooraf goed over moet worden nagedacht.

Video en audio

Wanneer een smartphone app gebruik maakt van video en/of audio moet dit toegankelijk gemaakt worden. Video en audio dienen transcripties te krijgen die in te zien zijn in de buurt van de mediaspeler. Video dient ondertiteling te krijgen die ook weer voldoet aan de regelgevingen voor tekst en beschrijft ook eventuele belangrijke tekst die visueel in de video getoond wordt.

Kaarten

Implementatie van interactieve kaarten (zoals Google Maps, Apple Maps en Mapbox) zijn niet in alle gevallen toegankelijk aan te bieden voor voorleesfuncties. Daarom is het noodzakelijk om in elke applicatie met een kaart een alternatief te bieden die dezelfde functionaliteit ondersteunt.

Afhankelijk van het doel kan een lijstweergave als alternatief dienen wanneer de kaart een weergave is van verschillende hotspots, of een tekstuele search waarin adressen ingevoerd kunnen worden als er een specifieke plek geselecteerd moeten worden op een kaart.

Voorleesfunctionaliteit

Mobiele telefoons beschikken over een zogenaamde voorleesfunctionaliteit (voice-over) of spraakassistent die geselecteerde onderdelen uitspreekt. Deze functie wordt veel gebruikt door blinden en slechtzienden om een element op het scherm, zoals een knop, te selecteren en voor te laten lezen om erachter te komen wat er in het element geschreven staat en welke eventuele actie er aan dit element gekoppeld is.

iOS en Android genereren hier standaard teksten voor die automatisch voorgelezen worden, hier hoeven geen audiobestanden voor opgenomen te worden door de ontwikkelaar. In onderstaand scherm leest de geautomatiseerde tekst van de informatie-knop linksboven bijvoorbeeld “Icoon, knop” voor, en de knoppen onderaan “Hier, knop” en “Andere locatie, knop” voor. Deze automatisch gegenereerde teksten bieden niet altijd voldoende context voor een slechtziende. Daardoor schrijven de UX designers YipYip hier vaak alternatieven voor wanneer extra context nodig is.

Cognitieve aspect

Ondanks dat binnen de WCAG 2.1 A + AA richtlijnen geen eisen zijn opgesteld voor de cognitieve vaardigheden van een gebruiker vinden wij het wel van belang om dit in ogenschouw te houden. Cognitie houdt in: hoe bekwaam is een gebruiker om een bepaalde taak uit te voeren.

Cognitieve vaardigheden zijn onder meer: taalbeheersing, geheugen, intelligentie en concentratie. Bij het ontwerpen van een app zorgen we er dan ook voor dat we consistent ontwerpen, geen overmatig volle interfaces maken én niet te ingewikkelde tekst gebruiken (idealiter op B1 niveau) voor de gebruiker.

WCAG audit en toegankelijkheidsverklaring

Wanneer de te bouwen applicatie volledig ontworpen, ontwikkeld én (op toegankelijkheid) getest is kan er een audit aangevraagd worden om het juiste niveau van toegankelijkheid te verkrijgen.

Audit / test

Een audit kan door de opdrachtgever intern worden uitgevoerd maar er zijn tevens gespecialiseerde bureaus die we hiervoor kunnen inschakelen. We proberen als app ontwikkelaar niet zélf onze digitale applicaties te testen om te voorkomen dat “een slager zijn eigen vlees keurt”.

Tijdens de audit wordt kritisch gekeken naar de volledige applicatie en wordt iedere richtlijn waaraan voldaan moet zijn er naast gehouden. Omdat de WCAG zich vooral op Web richt en minder op Apps doen auditors veel interpretaties van de richtlijnen waardoor ze vaak ook met suggesties komen.

Toegankelijkheidsverklaring

De audit brengt een rapport voort waarin is beschreven of de applicatie voldoet aan de voorgeschreven standaarden en waar mogelijk nog verbeteringen noodzakelijk zijn. Dit wordt vastgelegd in een zogenoemde 'toegankelijkheidsverklaring'.

Uiteindelijk moet er naar status A (niet te verwarren met de WCAG 2.1 A en AA niveaus) gestreefd worden, maar er kan ook begonnen worden. Wanneer er een lagere status zoals B, C of D wordt behaald is het belangrijk dat er direct aan de slag gegaan wordt met een iteratie op de applicatie, zodat zo snel mogelijk de verplichte status A behaald kan worden. Het belangrijkste hierbij is dat er een verbeterplan klaarligt om de route naar de A status aan te geven.

Het is mogelijk zelfstandig een toegankelijkheidsverklaring te schrijven, dit kan met behulp van de invulassistent op de officiële website: toegankelijkheidsverklaring.nl

Het invullen is echter specialistisch werk waardoor dit ook vaak wordt uitbesteedt. De verklaring dient ieder jaar geüpdatet te worden om er op die manier voor te zorgen dat de applicatie ook na app updates alsnog Digitoegankelijk blijft.

Toegankelijke native app of web-applicatie laten maken?

We zijn altijd enthousiast en gemotiveerd om te praten over nieuwe app ideeën, interessante concepten of vormen van samenwerking. Kom gerust een keer langs voor een vrijblijvend gesprek en een bak koffie!