Appt Evaluatie Methodiek (Appt-EM)

Huidige versie: V1.0.0

De Appt Evaluatie Methodiek biedt ondersteuning bij de evaluatie van mobiele applicaties (apps) conform de Europese richtlijn EN 301 549 V3.2.1 (2021-03). In de Europese richtlijn is een apart hoofdstuk gewijd aan software. Apps vallen onder dit hoofdstuk. Appt-EM is relevant omdat er nog geen passende evaluatie methode is voor apps. 

De Europese richtlijn verwijst naar de Web Content Accessibility Guidelines 2.1 (WCAG 2.1). Toch is de WCAG 2.1 standaard net als de Website Accessibility Conformance Evaluation Methodology (WCAG-EM) geschreven voor websites. In de Europese richtlijn worden voor apps bijvoorbeeld niet alle succescriteria overgenomen. Ook zijn er aanpassingen gedaan ten aanzien van de inhoud voor diverse WCAG succescriteria. 

In dit artikel willen we een samenvatting geven voor de app specifieke afwijkingen van de WCAG 2.1 standaard voorgeschreven door de Europese richtlijn. De structuur van WCAG-EM is zo veel mogelijk als basis gebruikt.

1. App specifieke afwijkingen van WCAG 2.1

In dit hoofdstuk wordt een samenvatting voor de app specifieke afwijkingen van de WCAG 2.1 standaard gegeven. Dit is geen onderdeel van de evaluatiemethode. Maar wel relevant omdat er voor apps veelal nog tegen alle 50 succescriteria wordt geaudit.

Voor de evaluatie van apps conform de Europese richtlijn EN 301 539 V3.2.1 (2021-03) is er nog geen evaluatie methode beschikbaar. De Europese richtlijn verwijst naar de WCAG 2.1. De WCAG 2.1 is net als de WCAG-EM geschreven voor websites. 

Afwijkingen WCAG 2.1 voor apps

Voordat de Appt Evaluatie Methode (APPT-EM) begrepen kan worden zullen eerst de app specifieke afwijkingen van de WCAG 2.1 bekend moeten zijn. In de Europese richtlijn is hoofdstuk 11 gewijd aan software. Mobiele applicaties vallen onder dit hoofdstuk.

Closed en open functionality

In de Europese richtlijn wordt verwezen naar “Open functionality” en “Closed functionality”. De gegeven definitie voor “Closed functionality” is: “Computers that do not allow end-users to adjust settings or install software are functionally closed.” Aangezien op de mobiele telefoon in de instellingen veel hulpmiddelen voor toegankelijkheid gebruikt kunnen worden zien wij mobiele telefoons met de bijbehorende apps als “Open functionality”.

Succescriteria met afwijking

In totaal zijn er 6 criteria niet van toepassing. Bij 13 succescriteria hebben een kleine aanpassing in de notities of definities. De gedachte en het doel achter het succescriteria is hetzelfde, alleen is “webpage” vervangen door “software”. Kijk dus niet alleen naar de WCAG 2.1 maar ook naar de EN standaard voor het volledige beeld.

Een overzicht van de afwijkingen:

  • 6 succescriteria zijn in zijn geheel niet van toepassing
    • 2.4.1, 2.4.2, 2.4.5, 3.1.2, 3.2.3 en 3.2.4.
  • 13 succescriteria hebben kleine aanpassingen in de notities of definities. Context is veelal hetzelfde.
    • 1.4.2, 1.4.10, 2.1.2, 2.2.1, 2.2.2, 2.3.1, 2.4.3, 2.5.1, 2.5.2, 3.1.1, 3.3.4, 4.1.1 en 4.1.2.
  • 31 succescriteria zijn direct toepasbaar.

Tabel met toelichting specifieke WCAG 2.1 afwijkingen apps ten opzichte van websites conform Europese richtlijn.

NummerNiveauOpmerking uit EN 301 549
1.1.1AGeen afwijkingen
1.2.1AGeen afwijkingen
1.2.2AGeen afwijkingen
1.2.3AGeen afwijkingen
1.2.4AAGeen afwijkingen
1.2.5AAGeen afwijkingen
1.3.1AGeen afwijkingen
1.3.2AGeen afwijkingen
1.3.3AGeen afwijkingen
1.3.4AAGeen afwijkingen
1.3.5AAGeen afwijkingen
1.4.1AGeen afwijkingen
1.4.2AKleine aanpassingen in de notities of definities
1.4.3AAGeen afwijkingen
1.4.4AAGeen afwijkingen
1.4.5AAGeen afwijkingen
1.4.10AAKleine aanpassingen in de notities of definities
1.4.11AAGeen afwijkingen
1.4.12AAGeen afwijkingen
1.4.13AAGeen afwijkingen
2.1.1AGeen afwijkingen
2.1.2AKleine aanpassingen in de notities of definities
2.1.4AGeen afwijkingen
2.2.1AKleine aanpassingen in de notities of definities
2.2.2AKleine aanpassingen in de notities of definities
2.3.1AKleine aanpassingen in de notities of definities
2.4.1ANiet van toepassing op apps
2.4.2ANiet van toepassing op apps
2.4.3AKleine aanpassingen in de notities of definities
2.4.4AGeen afwijkingen
2.4.5AANiet van toepassing op apps
2.4.6AAGeen afwijkingen
2.4.7AAGeen afwijkingen
2.5.1AKleine aanpassingen in de notities of definities
2.5.2AKleine aanpassingen in de notities of definities
2.5.3AGeen afwijkingen
2.5.4AGeen afwijkingen
3.1.1AAKleine aanpassingen in de notities of definities
3.1.2AANiet van toepassing op apps
3.2.1AGeen afwijkingen
3.2.2AGeen afwijkingen
3.2.3AANiet van toepassing op apps
3.2.4AANiet van toepassing op apps
3.3.1AGeen afwijkingen
3.3.2AGeen afwijkingen
3.3.3AAGeen afwijkingen
3.3.4AAKleine aanpassingen in de notities of definities
4.1.1AKleine aanpassingen in de notities of definities
4.1.2AKleine aanpassingen in de notities of definities
4.1.3AAGeen afwijkingen

Voor de volledige toelichting zie hoofdstuk 11 van de Europese richtlijn EN 301 549.

2. Appt-EM

Stichting Appt heeft met de Appt-EM als doel volledige toegankelijkheid van apps te behalen. Volledige toegankelijkheid kan alleen gerealiseerd worden met de juiste hulpmiddelen. Organisaties die apps bouwen en audits uitvoeren moeten dit op een uniforme, reproduceerbare en impactvolle wijze kunnen doen. Vervolgens moet het rapport de overheidsorganisatie en/of het bedrijf en/of de appbouwer voldoende helpen de verbeteringen te kunnen realiseren. De evaluatiemethode met de wijze van rapporteren voor websites is niet zonder meer geschikt voor apps.

Basisvoorwaarden

Om de Appt-EM te gebruiken is er kennis nodig van WCAG 2.1 en EN 301 549 (met de nadruk op hoofdstuk 11). Zonder deze kennis kan deze Appt-EM methode niet succesvol worden gebruikt.

Processtappen Evaluatie

Dit hoofdstuk beschrijft het proces van evalueren. De stappen en activiteiten per stap om te komen tot een correcte evaluatie worden hier beschreven.

Je start met stap 1 waarna je stap voor stap het proces van evalueren vervolgt. Het kan zijn dat je in een stap een of meerdere stappen terug moet doen, omdat de stap nieuwe inzichten heeft opgeleverd.

De processtappen van Appt-EM zijn vergelijkbaar met die van WCAG-EM:

  • Stap 1 – Bepaal scope
  • Stap 2 – Onderzoek app
  • Stap 3 – Bepaal audit sample
  • Stap 4 – Voer audit uit
  • Stap 5 – Rapporteer resultaten

Stap 1 – Bepaal scope

In deze stap wordt de scope van de evaluatie bepaald. Om de scope te bepalen moet duidelijk worden wat binnen en buiten de scope van het onderzoek valt.

Stap 1a – Bepaal scope app

Het bepalen van de scope bestaat allereerst uit het bepalen van de URL waar de app te downloaden is. Daarna moet inzicht worden verkregen welke schermen beschikbaar zijn.

Bepaal URL en versie

Bij een app audit je óf de volledige app óf een deel van de app. De app is vaak via de appstores te downloaden en heeft dan een unieke URL en versie. Hier moet naar verwezen worden. Ieder land heeft namelijk een eigen appstore waar vanuit apps geïnstalleerd kunnen worden. De apps kunnen per land dus verschillen. Er zijn bijvoorbeeld lite versies of de taal van de app is anders. Indien een app (nog) niet gepubliceerd is kan deze ook beschikbaar worden gemaakt via een installatiebestand. Het installatiebestand heet op android een Android Application Package (.apk) is en op iOS een iOS App Store Package (.ipa). Het is van belang de versie van het installatiebestand te benoemen.

Maak één rapport per platform, om verwarring bij de ontwikkelaar en andere lezers te voorkomen.. Bij hybride apps die gebaseerd zijn op 1 codebase zullen de resultaten vergelijkbaar zijn, maar er zijn ook situaties waar afwijkingen mogelijk zijn. 

  • Bepaal unieke URL(’s) of installatiebestand van de app die getest moet worden.
  • Bepaal de versie(s) van app die getest moeten worden.
Bepaal welke schermen in een app aanwezig zijn

Bij apps is er geen sitemap beschikbaar met alle URL’s. Vaak is er geen overzicht van de schermen beschikbaar. Het in kaart brengen van de app zal gedaan moeten worden op een of meerdere van de volgende manieren:

  • In kaart brengen belangrijkste schermen zoals inloggen, onboarding, profiel, homescherm en schermen waar je direct vanuit deze schermen naartoe verwezen wordt. 
  • Via gemaakte ontwerpen kun je een beeld vormen van app. De ontwerpen zijn niet altijd volledig bijgewerkt, maar geven een goede indicatie van de functionaliteiten en schermen in de app.
  • Scherm voor scherm aanklikken en het pad rapporteren.
  • Vanuit analytics de veel gebruikte schermen ophalen.

Note: Bij een app zijn er geen URL’s beschikbaar. Definieer voor een goed overzicht het pad dat je bent doorlopen om op het scherm te komen: Homescherm -> Profiel -> Profiel wijzigen. Hierdoor is het reproduceerbaar. 

  • Bepaal welke schermen/flows onderdeel zijn van het onderzoek
  • Bepaal of content/diensten van derden gebruikt worden
  • Bepaal of er gebruik wordt gemaakt van een webapplicatie als onderdeel van de app. Bijvoorbeeld een administratiepaneel.

Stap 1.b – Bepaal het conformiteitsniveau

Bepaal het conformiteitsniveau dat getoetst wordt: niveau A, AA of AAA van WCAG 2.1. Het conformiteitsniveau AA wordt veel gebruikt. Dit niveau is voor overheden ook waar vanuit de Nederlandse wetgeving wordt verwezen.

Stap 1.c – Bepaal scope hardware/software

Bepaal scope hardware

Afhankelijk van de hardware is het mogelijk dat de app anders reageert. Denk hierbij aan andere schermgroottes en systeeminstellingen.

  • Bepaal schermgroottes waarop moet worden getest.
  • Bepaal type telefoons waarop moet worden getest.
  • Bepaal in welke taal/locatie moet worden getest.
Bepaal scope software

Anders dan bij websites is de hulpsoftware voor een belangrijk deel via de systeemsoftware beschikbaar. Het is belangrijk duidelijk te hebben welke versie van besturingssystemen je gaat gebruiken. Bepaal tevens welke andere instellingen zoals taal/locatie invloed hebben op de mobiele applicatie.

Enkele hulpmiddelen zijn vanuit de richtlijn verplicht om mee te testen. Je zult bijvoorbeeld met groot lettertype moeten testen. Ons advies is om daarnaast met ten minste de schermlezer te testen. Ook kan er met een extern toetsenbord worden getest. Als het werkt met beide hulpmiddelen dan werken de andere hulpmiddelen zoals schakelbediening en stembediening vaak ook.

  • Bepaal versie van besturingssysteem
  • Bepaal overige relevante systeeminstellingen.
  • Bepaal met welke andere hulpmiddelen er getest moet worden.

Nadat een beeld is gekregen van de omvang van de app is verder onderzoek nodig.

Stap 2 – Onderzoek app

In deze stap is het belangrijk een goed idee te krijgen welke schermen in een app beschikbaar zijn en wat daarvan de belangrijkste zijn.

Stap 2.a – Bepaal veelgebruikte schermen

In een app wordt er weinig gebruik gemaakt van herhaalde schermen zoals bij websites. Vaak is er op het scherm dan de mogelijkheid tot filteren. Of het scherm dat wordt getoond is gebaseerd op eerdere instellingen/keuzes/locatie etc.

Als schermen vaak voorkomen of gebruikt worden is het belangrijk deze mee te nemen in het onderzoek. Bepaal of repeterende schermen aanwezig zijn en bepaal welke schermen vaak gebruikt worden door gebruikers.

Neem schermen zoals de onboarding, inlogscherm, profiel en home scherm mee bij de steekproef. Een belangrijke indicator voor veelgebruikte schermen is als vanuit meerdere schermen of vanuit de homepage naar deze schermen verwezen wordt.

Stap 2.b – Bepaal essentiële functionaliteit

Bepaal welke flows belangrijk zijn in een app. Een flow bestaat uit meerdere stappen (schermen) die doorlopen worden om een taak uit te voeren. Vaak zul je functionaliteit/schermen als flow moeten beschouwen. Door de belangrijke flows (functionaliteit) van de app te omschrijven kun je vervolgens alle schermen van deze flows testen.

Stap 2.c – Bepaal veelgebruikte elementen

Bepaal elementen die worden gebruikt in de app. In de onderstaande tabel staan de elementen die in een app gebruikelijk zijn met de benamingen voor Android en iOS.

ElementAndroidiOS
Afbeelding / icoonImageViewUIImageView
VideoMediaPlayerAVPlayer
AudioMediaPlayerAVPlayer
TekstTextViewUILabel
KnopButtonUIButton
SelectievakjeCheckBoxUISwitch
NavigatieNavigationBarUINavigationBar
TabbladenBottomNavigationBar of TabBarLayoutUITabBar
InvoerveldEditText, DatePicker of TimePickerUITextField of UIDatePicker

Stap 2.d – Gebruikte technieken

Bepaal van welke technieken gebruik wordt gemaakt. Wat zijn de programmeertalen. Native, hybride, web of een combinatie van deze.

Stap 2.e – Overige relevante schermen

Bepaal of er functionaliteiten of schermen specifiek voor mensen met een beperking in de app aanwezig zijn. Ook schermen die informatie delen hoe de app gebruikt kan worden zoals onboarding en contactinformatie zijn relevante schermen.

Stap 3 – Bepaal audit sample

Bepaal welke schermen er in de scope meegenomen moeten worden. Als er niet wordt gekozen de gehele app te auditen kan er worden gekozen om een representatieve steekproef te nemen.

Stap 3.a – Gestructureerde steekproef

Selecteer een steekproef met belangrijkste schermen en elementen met minimaal:

  1. In stap 2.a Bepaal veelgebruikte schermen
  2. In stap 2.e Overige relevante schermen
  3. Als de schermen in stap 2.a en 2.e niet voldoende zijn voor een representatieve gestructureerde steekproef, voeg dan schermen toe uit:
    • Stap 2.b Bepaal essentiële functionaliteit
    • Stap 2.c Bepaal veelgebruikte elementen
    • Stap 2.d Gebruikte technieken

Bij een app zullen de belangrijkste schermen en flows een groot deel van de app schermen bevatten. 

Stap 3.b – Voeg willekeurige steekproef toe

Kies een of meerdere willekeurige pagina’s om te verifiëren of de gestructureerde steekproef een goede afspiegeling is van de totale app. Dit moet minimaal 10% van het aantal schermen in de gestructureerde steekproef zijn.

Stap 3.c – Voeg flows toe aan scope

Voeg flows toe aan de scope van de audit. Apps bestaan voornamelijk uit flows. Het kan dus zijn dat je vaak meerdere schermen uit de gehele flow moet testen. 

Bij veel apps zul je dus uitkomen de in een app alle schermen getest zullen worden. Omdat content vaak op 1 scherm staat en door filtering veel aanpassingen kunt maken van de inhoud van dat scherm zal er vaak ook een steekproef genomen moeten worden van de content.

Stap 4 – Voer audit uit

Doe een audit volgens EN 301 549 en beoordeel de relevante succescriteria uit de WCAG 2.1.

  • Stap 4.a Beoordeel alle schermen
  • Stap 4.b Beoordeel alle flows volledig
  • Stap 4.c Vergelijk structurele steekproef met random sample

Let op: Anders dan bij websites is het bij apps belangrijk om de schermafbeelding mee te sturen. Als je een scherm herlaad dan zal de content wellicht de volgende keer anders zijn waardoor het niet reproduceerbaar is zonder schermafbeelding.

Stap 5 – Rapporteer resultaten

Een auditrapport moet aan bepaalde vormvereisten voldoen. Zie hoofdstuk 5 van WCAG-EM voor verdere toelichting. 

Specifiek voor apps zijn er afwijkingen die hieronder worden toegelicht. Hierdoor voldoen de rapporten aan de minimale kenmerken zodat een opdrachtgever of app ontwikkelaar het rapport specifiek voor apps kan interpreteren.

Benamingen en definities

Een app heeft specifieke benamingen en definities. Er is bijvoorbeeld geen sprake van een webpagina, maar van een scherm. Ook zijn de oplossingen om fouten te herstellen voor apps anders dan voor websites aangezien er gebruikt wordt gemaakt van andere programmeertalen. Deel voldoende app gerelateerde informatie zodat klanten en ontwikkelaars de benodigde verbeteringen kunnen maken.

Rapporteer pad

In een app worden geen URL’s gebruikt voor het identificeren van schermen. Om aan te geven welk scherm wordt beoordeeld kun je dus geen URL opschrijven. Om duidelijk te maken over welk scherm je een opmerking maakt moet je dus een pad-omschrijving opschrijven. Dus, via welke andere schermen vanaf het startscherm je op dit scherm terecht bent gekomen.

Sterke aanbevelingen

Naast de Appt-EM specifieke aanpak zijn ook de volgende sterke aanbevelingen van toepassing op apps. Hieraan voldoen zorgt voor optimale impact van het auditrapport.

Geef voldoende context

Anders dan bij websites is het bij apps belangrijk om de schermafbeelding mee te sturen. Als je een scherm herlaad dan zullen de afbeeldingen wellicht de volgende keer anders zijn waardoor het niet reproduceerbaar is zonder schermafbeelding. Bij een app is het ook niet eenvoudig mogelijk om een lokale kopie te maken zoals bij een website wel mogelijk is. Natuurlijk kan een tekst alternatief ook een volwaardig alternatief bieden, maar zorg dan dat je verder gaat dan de afbeelding beschrijven als “vrouw met hoed”. Want op een webshop met hoeden heb je wellicht meer afbeeldingen die hieraan voldoen.

Rapporteer fouten ook per scherm

Verbeteringen worden door ontwikkelaars per scherm gedaan. Als er gerapporteerd wordt per succescriterium is dit minder bruikbaar voor een app ontwikkelaar. Er zal veel tijd besteed moeten worden om een goed overzicht van verbeteringen te genereren. Het is aangeraden om beide te rapporteren, dus rapporteer de fouten per scherm en per succescriterium.