Naar inhoud springen Eleven Ways (Home)

Alle artikels

Alles wat je moet weten over de verplichte toegankelijkheid van overheidsapps

Geschreven door Roel Van Gils op 23 juni 2021 (Gemiddelde leestijd: 7 minuten)

Alle apps van de overheid moeten vanaf vandaag een toegankelijkheidsverklaring hebben. Daarin staat in hoeverre de app toegankelijk is voor burgers met een beperking. In dit artikel leg ik je uit wat apptoegankelijkheid inhoudt. Je leert ook hoe de app van jouw organisatie binnenkort kan voldoen.

In 2016 heeft de Europese Commissie aan alle lidstaten gevraagd om toegankelijkheid verplicht te maken voor de digitale kanalen van de (semi-)overheid. Alle lidstaten – waaronder België en Nederland – hebben deze richtlijn sindsdien omgezet in lokale wetten en besluiten. Die gelden voor alle overheidsniveaus. Voor websites geldt al sinds september 2020 dat ze minstens een toegankelijkheidsverklaring moeten hebben. Vanaf 23 juni 2021 geldt dat ook voor nieuwe én bestaande mobiele apps.

Voor een bredere kijk op digitale toegankelijkheid bij de overheid, verwijs ik graag naar het artikel dat ik eerder schreef over dit onderwerp: Nieuwe overheidssites verplicht toegankelijk vanaf 23 september: wat is de impact voor overheidsinstellingen en lokale besturen?

Web- versus app-accessibility

Hoewel mobiele apps functioneel (en onder de motorkap) behoorlijk verschillen van websites, worden ze vaak in één adem genoemd (bijvoorbeeld in het Bestuursdecreet van de Vlaamse overheid). Voor apps en sites geldt bovendien dezelfde technische toegankelijkheidsnorm: WCAG. Dat zorgt wel eens voor verwarring en interpretatieverschillen. Laten we daarom eerst even naar die verschillen kijken.

Apps en websites leven op een verschillende plek

  • Een app moet je installeren op je smartphone of tablet en is speciaal ontworpen voor aanraakschermen. In een app veeg je met je vingers tussen de verschillende schermen.
  • Een typische overheidswebsite bevat tientallen tot duizenden pagina’s. Websites kan je op ieder apparaat met een browser raadplegen, dus ook op je smartphone.

Daarnaast zijn websites, in tegenstelling tot apps, gebouwd met open webstandaarden als HTML, CSS en JavaScript. Dat geeft websites een voorsprong als het gaat om het garanderen van de toegankelijkheid. Toch hoeven apps — mits enkele inspanningen van de bouwer — op dat vlak allerminst onder te doen.

Dynamische gebruikservaring

Een opvallend verschil bij het gebruik van apps — los van de bediening — zit ‘m in de vele dynamische veranderingen die op het scherm te zien zijn.

Als je blind of slechtziend bent, is het bijvoorbeeld essentieel dat een app je waarschuwt wanneer iets op het scherm om je aandacht vraagt. Tegelijkertijd wil je de gebruiker niet bombarderen met gesproken boodschappen. Dit maakt dat app-accessibility een onderwerp is waarin niet enkel bouwers, maar ook UX-ontwerpers zich moeten verdiepen.

Apps voor een specifiek doel

  • Denk aan apps waarmee je een melding of een afspraak kunt maken bij de gemeente of waarmee je dienstregelingen kunt opzoeken. Binnenkort kan je ook met een app bewijzen dat je beschermd bent tegen COVID-19. Met apps als itsme® of DigiD kan je veilig inloggen op overheidssites. Voor veel van deze doeleinden gebruiken apps technische snufjes van je smartphone, zoals je GPS-locatie, je camera of biometrische gegevens.
  • Op overheidswebsites ligt de nadruk veelal op informeren. Je vindt er dan ook vooral gestructureerde inhoud. Ook complexere taken die meer tijd in beslag nemen, zoals het indienen van je belastingaangifte, doe je liever op het web dan in een app.

Het beste van twee werelden

Je merkt het: soms biedt een app een functionaliteit die een ‘gewone’ website je niet kan geven. Andere apps zijn dan weer vooral onderweg erg nuttig. Ten slotte zijn apps over het algemeen laagdrempeliger in het gebruik. Dat spreekt dan weer mensen met beperkte digitale vaardigheden aan.

Dat zijn stuk voor stuk redenen waarom app accessibility net zoveel aandacht verdient als web accessibility.

Dezelfde richtlijnen… of toch niet?

Ondanks de verschillen, gelden voor apps dus dezelfde richtlijnen: de Web (!) Content Accessibility Guidelines. Het toepassen van WCAG in apps is relatief nieuw en er bestaan nog wel wat misverstanden over. Toen de tweede versie van WCAG ontwikkeld werd, werd gekozen voor technologie-onafhankelijke richtlijnen, maar toch blijkt in de praktijk dat WCAG niet één-op-één toegepast kan worden op apps. In het artikel Voor apps gelden maar 44 succescriteria uit WCAG schrijft de Nederlandse Stichting Appt hierover dit:

Allereerst zijn er 6 criteria niet van toepassing voor apps. Ten tweede hebben 13 succescriteria kleine aanpassingen in de WCAG 2.1 notities of definities. (…) Ten slotte zijn de overige 31 succescriteria direct toepasbaar, maar hebben soms notities als extra toelichting.

Dat hebben we bij Eleven Ways ook ondervonden toen we vorige zomer betrokken waren bij het toegankelijk maken van de Belgische CoronAlert-app en de YouFlanders-app van Toerisme Vlaanderen. Hier en daar stoot je op de beperkingen van iOS en Android en moet je creatieve oplossingen bedenken om geen enkele gebruiker uit te sluiten.

Zo begin je eraan

Voor bestaande apps

Het opmaken van een onderbouwde toegankelijkheidsverklaring is voor de meest organisaties de eerste stap. Deze moet je in een toegankelijk formaat publiceren. Aanbieders kunnen zich hiervoor baseren op deze modeltoegankelijkheidsverklaring.

In de federale Wet inzake toegankelijkheid van de websites en mobiele applicaties van overheidsinstanties staat:

De verklaring is beschikbaar op de website van de overheidsinstantie die de betrokken mobiele applicatie heeft ontwikkeld, of samen met andere informatie die bij het downloaden van de applicatie beschikbaar is.

Plaats de toegankelijkheidsverklaring dus op de webpagina waarop verwezen wordt naar de apps in de App Store (iOS) en de Play Store (Google). In de stores zelf is er helaas geen plaats voor een toegankelijkheidsverklaring.

Als best practice kun je de verklaring aanvullend in de app zelf delen, maar dan kunnen bezoekers ‘m pas lezen nadat ze de app hebben geïnstalleerd.

Twee screnshots van apps.

Links: de app YouFlanders van Toerisme Vlaanderen linkt naar een webpagina. Rechts: de Nederlandse app CoronaMelder heeft de verklaring geïntegreerd in de app.

Tijd om te testen

Om een onderbouwde uitspraak te doen over de toegankelijkheid van je app, moet je de app uiteraard testen of laten testen. Je kunt de tests zelf uitvoeren, maar dan is kennis van schermlezers, spraakbesturing en (platformspecifieke) instellingen een must. Wat je minstens nodig hebt voor een test, zijn twee smartphones (een iPhone en een Android-telefoon) en een Bluetooth-toetsenbord.

Enkele voorbeelden van dingen die je zelf kunt testen:

  • Past de app zich aan aan gebruikersvoorkeuren? Bijvoorbeeld: kunnen teksten en knoppen groter gemaakt worden en werkt de app ook in landschapsmodus?
  • Als de app video’s bevat, zijn die dan ondertiteld voor slechthorenden en doven?
  • Als je de inhoud van het scherm laat voorlezen — bijvoorbeeld omdat je slechtziend bent — is er dan een tekstalternatief beschikbaar voor elk onderdeel van de interface?
  • Werkt de app ook goed met andere invoerapparaten (voor mensen die moeite hebben met aanraakbediening)?

Om een volledig zicht te krijgen, kan je aan een gespecialiseerde partij vragen om een volwaardig WCAG-onderzoek of een QuickScan uit te voeren. Het voordeel van het werken met experts is dat ze ook kunnen adviseren over welke problemen prioritair behandeld moeten worden en welke zaken je eventueel kunt uitsluiten in de toegankelijkheidsverklaring.

Voor nieuwe apps

Ga in zee met een app-ontwikkelaar met aantoonbare kennis van WCAG (kijk bijvoorbeeld of zij al een app met een toegankelijkheidsverklaring in het portfolio hebben). Maak ook goede afspraken. Zo kan je bij de lancering van de app meteen uitpakken met een positieve toegankelijkheidsverklaring.

Bij Eleven Ways raden we aanbestedende overheden al jaren aan om in overheidsopdrachten uitdrukkelijk te verwijzen naar de wet en de bijbehorende technische norm. Dat kan door een clausule als deze toe te voegen:

De aanbestedende overheid hecht een groot belang aan toegankelijkheid, waaronder ook de toegankelijkheid van mobiele applicaties, onder andere voor personen met een beperking. De mobiele applicatie die het voorwerp van deze opdracht uitmaakt, moet minstens toegankelijk zijn conform de norm EN 301 549.

Hiermee help je ook bij het sensibiliseren van de markt. Meer tips vind je op de website Overheidsopdrachten en raamcontracten van de Vlaamse overheid, maar het advies geldt uiteraard ook voor overheidsopdrachten binnen andere overheidsniveaus.

Onafhankelijke ondersteuning

Organisaties als DiAX (een netwerk van ervaren gecertificeerde accessibility professionals) kunnen je helpen bij het testen van apps en het opstellen van een onderbouwde toegankelijkheidsverklaring voor bestaande apps.

Voor nieuwe projecten kunnen ze jou en je app-bouwer ondersteunen tijdens de cruciale momenten van het ontwikkelingsproces. Dat is nuttig wanneer je app-bouwer nog niet zoveel ervaring heeft met het ontwerpen van toegankelijke apps en/of wanneer de app een heel breed en divers publiek moet aanspreken.

Als overheid (Vlaams, lokaal of federaal) is de kans groot dat je vandaag zonder aanbestedingsprocedure gebruik kunt maken van de diensten van de partners die deel uitmaken van DiAX. Neem hiervoor een kijkje op de pagina raamcontracten.

Betrek gebruikers

Tijdens de ontwikkeling van een nieuwe app, is het raadzaam om een stapje verder te gaan door de app te testen met de hulp van echte gebruikers met uiteenlopende beperkingen. Zo’n praktijktest levert steeds verrassende inzichten op en helpt ervoor zorgen dat de app niet alleen technisch voldoet aan WCAG, maar ook beantwoordt aan de noden en verwachtingen van mensen met een beperking.

Zo testten we bij Eleven Ways onlangs de nieuwe app van De Lijn. Dat deden we met de hulp van een enthousiast testpanel. Alle verzamelde feedback werd door ons team geprioriteerd en vertaald naar concrete acties. De meest dringende aanpassingen werden meteen doorgevoerd, nog voor de lancering. Vandaag is de app van De Lijn een van de meest toegankelijke OV-apps in ons land.

Conclusie

Het gebruik van mobiele apps zit (nog steeds) in de lift. Lieven De Mare, professor nieuwe communicatietechnologieën aan de UGent, gebruikt hiervoor in de nieuwste Digimeter de term “Appification”:

Het gevolg van de digitale versnelling: de gemiddelde mobiele schermtijd stijgt met een half uur, tot 3 uur en 5 minuten per dag.

Het spreekt voor zich dat ook apptoegankelijkheid hierdoor een onmisbaar requirement is geworden — niet het minst voor apps van de overheid, waar sinds 23 juni 2021 een verplichting geldt.

Al meer dan vijftien jaar trekken experts en gebruikers aan de kar om de digitale overheid toegankelijker te maken. Vandaag vind je op steeds meer overheidssites — naast de verplichte privacyverklaring — dan ook een toegankelijkheidsverklaring. Dat heeft te maken met de wettelijke verplichting, maar ook met het groeiende besef dat de digitalisering niet meer te stuiten is en we daarbij niemand mogen uitsluiten.

Laten we daarom hopen dat we binnenkort ook meer toegankelijke apps in de App Store en de Play Store kunnen downloaden.

Haalbare accessibility-tips in je mailbox

Met onze praktische tips leer je hoe je de website of app van jouw organisatie (of klant) voor iedereen toegankelijk maakt.

Je kunt je met één klik uitschrijven.

Waarmee kunnen we jouw organisatie helpen?

Alle contactgegevens

We moeten wettelijk voldoen aan WCAG. Wat is de omvang van het project?

We willen onze teams trainen in toegankelijkheid. Wie moet worden opgeleid?

We hebben externe expertise nodig. Een tijdelijke versterking, kan dat?

We willen onze applicatie testen met gebruikers met een handicap. Hoe het te organiseren?