Toegankelijkheid van mobiele apps: WCAG 2.2-vereisten voor iOS en Android

Meer dan 72% van de volwassenen met een beperking bezit een smartphone, en volgens één onderzoek vertrouwt ongeveer 86% van de schermlezergebruikers op een mobiel apparaat — een hoger aandeel dan desktop- of laptopgebruikers. Toch hebben dezelfde organisaties die hun websites nauwgezet laten auditen vaak mobiele apps die nog nooit tegen één enkele toegankelijkheidsrichtlijn zijn getest. Dat gat wordt snel kleiner, gedreven door veranderende regelgeving, toenemende rechtszaken en — vooral — de expliciete richtlijnen van het W3C die WCAG 2.2 rechtstreeks koppelen aan native iOS- en Android-applicaties.

Waarom WCAG 2.2 van toepassing is op uw mobiele app

Er bestaat een hardnekkige mythe dat WCAG een standaard is die alleen voor het web geldt. Dat is niet zo. Het W3C heeft geen aparte richtlijnen voor mobiele toegankelijkheid — in plaats daarvan wordt mobiele toegankelijkheid behandeld binnen het bestaande WCAG-raamwerk, en de Mobile Accessibility Task Force (MATF) van het W3C heeft specifieke richtlijnen opgesteld met de titel Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile), waarin elk Level A- en AA-succescriterium wordt gekoppeld aan native mobiele apps, mobiele webapps en hybride apps.

De praktische implicatie is aanzienlijk. Wanneer u een WCAG-succescriterium leest dat verwijst naar een "web page", vervangt het WCAG2Mobile-document die term door "screen" of "view". Wanneer een criterium een "user agent" bespreekt, wordt daarmee het mobiele besturingssysteem bedoeld. De vier POUR-principes — Perceivable, Operable, Understandable, Robust — vertalen zich rechtstreeks naar hoe een gebruiker interacteert met een SwiftUI-view in iOS of een Jetpack Compose-layout op Android.

Vanuit juridisch oogpunt is de druk niet langer theoretisch. Onder Title II van de ADA vereisen bijgewerkte DOJ-regels, gepubliceerd in april 2024, expliciet dat overheden op staats- en lokaal niveau hun mobiele applicaties toegankelijk maken op WCAG 2.1 AA-niveau. Zorgorganisaties die Medicare of Medicaid accepteren, worden geconfronteerd met vergelijkbare vereisten onder HHS-regels die in mei 2024 zijn afgerond. En hoewel rechtszaken over mobiele apps in de private sector nog steeds minder frequent zijn dan zaken over websites, heeft ten minste één veel procederende eiser zich specifiek gericht op mobiele applicaties vanwege het gebrek aan gelijke toegang onder de ADA, waarbij wordt verwacht dat die trend zal versnellen naarmate de Title II-nalevingstermijnen in 2026 dichterbij komen.

De European Accessibility Act (EAA), die op 28 juni 2025 in werking is getreden en EN 301 549 als veronderstelde technische standaard hanteert, vereist eveneens conformiteit met WCAG 2.2 voor digitale producten en diensten, waaronder mobiele apps die worden verkocht of aangeboden op EU-markten. Voor elke organisatie met een wereldwijd gebruikersbestand is WCAG 2.2 op mobiel geen toekomstig streven — het is een huidige verplichting.

Wat er in WCAG 2.2 is veranderd dat vooral belangrijk is voor mobiel

WCAG 2.2, gepubliceerd als W3C Recommendation in oktober 2023, voegt negen nieuwe succescriteria toe en verwijdert het inmiddels verouderde 4.1.1 Parsing. De standaard is volledig achterwaarts compatibel: conformiteit met 2.2 impliceert conformiteit met 2.1 en 2.0. Verschillende van de nieuwe criteria zijn expliciet geschreven met mobiele interactiepatronen in gedachten, en zelfs de criteria die rond toetsenbordgebruik zijn geformuleerd, hebben directe tegenhangers in ondersteunende technologie voor iOS en Android.

Het is de moeite waard om de ontstaansgeschiedenis te begrijpen. Na 2018 zorgde de Mobile Accessibility Task Force ervoor dat mobiele overwegingen zowel WCAG 2.1 als 2.2 vormgaven. Criteria zoals 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A), en de nieuwe 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) en 3.3.7 Redundant Entry (A) weerspiegelen allemaal specifieke mobiele gebruikspatronen die zijn geïdentificeerd via tests in de praktijk met gebruikers met een beperking op smartphones en tablets.

De negen nieuwe succescriteria die in WCAG 2.2 zijn geïntroduceerd, richten zich op specifieke barrières waar echte gebruikers tegenaan lopen: inlogflows die iedereen met geheugenproblemen benadelen, interfaces die een vaste hand vereisen voor precieze tikken, helpfuncties die op verschillende plekken op elk scherm verstopt zitten, en focusindicatoren die verdwijnen achter sticky navigatiebalken. Elk criterium dicht een concreet gat — en bijna allemaal hebben ze een directe toepassing op mobiel.

De nieuwe WCAG 2.2-criteria en hoe ze van toepassing zijn op iOS en Android

2.5.8 Target Size Minimum (Level AA)

Dit is waarschijnlijk het meest impactvolle nieuwe criterium voor mobiele teams. Het vereist dat interactieve targets — knoppen, links, formuliervelden, selectievakjes, toggles — een minimale grootte hebben van 24 × 24 CSS-pixels, of dat er een offset van 24 pixels tussen aangrenzende targets bestaat als het target zelf kleiner is. De reden is eenvoudig: gebruikers met handtremoren, de ziekte van Parkinson of beperkte motoriek vinden het echt onmogelijk om betrouwbaar een pictogramknop van 16 pixels te raken, en zelfs gebruikers zonder beperking maken aanzienlijk meer fouten bij kleine targets.

Voor native mobiele ontwikkeling is de 24 × 24-minimumwaarde van WCAG 2.2 eigenlijk een ondergrens, geen bovengrens. De Human Interface Guidelines van Apple bevelen een minimale aanraakdoelgrootte van 44 × 44 punten aan op iOS en iPadOS. Google's Material Design beveelt 48 × 48 density-independent pixels (dp) aan op Android. Als uw app voldoet aan de platformrichtlijnen van Apple of Google, overschrijdt u de WCAG 2.2-minimumwaarde al — maar veel apps doen dat niet. Die kleine sluitknoppen op modale sheets, de flinterdunne selectievakjes in instellingen, en de alleen-pictogram-acties in toolbars die 20 × 20 dp meten, zijn allemaal complianceproblemen die wachten om in een audit aan het licht te komen.

Een praktische kanttekening: de WCAG-eis gaat over het interactieve raakvlak, niet de visuele grootte van het pictogram. Een pictogram van 16 punten dat aan elke zijde is omgeven door 14 punten padding, heeft een effectieve tikdoelgrootte van 44 × 44 punten. Dit betekent dat ontwikkelaars aan het criterium kunnen voldoen zonder elementen visueel te vergroten — maar ze moeten die padding bewust instellen en niet vertrouwen op het systeem om dit automatisch te doen.

2.5.7 Dragging Movements (Level AA)

Dit criterium vereist dat elke functionaliteit die via een sleepgebaar wordt geïmplementeerd — sliders, drag-and-drop-herordening, pull-to-refresh, carrousel-scrubbing — ook bereikbaar moet zijn via een actie met één pointer die geen slepen vereist. Op iOS en Android gaan de eigen ondersteunende technologieën van het platform op een andere manier om met bepaalde gebaren, maar de app zelf moet niet-sleepalternatieven bieden voor elke aangepaste sleepfunctionaliteit die wordt geïmplementeerd.

In de praktijk betekent dit dat een lijst die via slepen kan worden herordend, een alternatief moet bieden, zoals een "omhoog/omlaag"-stapknop. Een aangepaste bereikslider die alleen reageert op een sleepgebaar, moet ook reageren op tikken op specifieke punten of knoppen voor verhogen/verlagen bieden. Het criterium is niet van toepassing als het onderliggende besturingssysteem of de ondersteunende technologie het alternatief automatisch biedt, maar ontwikkelaars moeten dit expliciet testen in plaats van ervan uit te gaan dat dit altijd voor hen wordt geregeld.

2.4.11 Focus Not Obscured — Minimum (Level AA) en 2.4.12 (Enhanced, Level AAA)

Deze criteria pakken een patroon aan dat extreem vaak voorkomt in zowel web- als native mobiele apps: het gefocuste element dat gedeeltelijk of volledig wordt verborgen door sticky UI — een permanente navigatiebalk onderaan, een floating action button, een bovenste toolbar die over het scrollgebied heen valt. Het minimumcriterium (Level AA) vereist dat wanneer een component focus krijgt, ten minste een deel ervan zichtbaar blijft. De verbeterde versie (Level AAA) vereist dat de volledige gefocuste component zichtbaar is.

Voor native mobiel wordt "toetsenbordfocus" ruim geïnterpreteerd om de focusring te omvatten die wordt gebruikt door Switch Control of Switch Access, Full Keyboard Access (iOS 15+) en Voice Control/Access. Een app waarin het gefocuste element tijdens een Switch Control-sweep onder een navigatiebalk onderaan schuift, voldoet niet aan dit criterium, ook al is er geen fysiek toetsenbord in het spel. App-UI moet voorkomen dat gefocuste bedieningselementen worden bedekt door overlays die door de auteur zijn gemaakt, sticky balken of tijdelijke oppervlakken.

2.4.13 Focus Appearance (Level AA)

Dit criterium stelt minimumeisen aan de visuele kenmerken van de focusindicator: deze moet een minimale oppervlakte hebben die gelijk is aan de omtrek van de component × 2 CSS-pixels, en een contrastverhouding van ten minste 3:1 ten opzichte van aangrenzende kleuren. Op native mobiele platforms wordt de focusring voor VoiceOver en TalkBack beheerd door het besturingssysteem, en ontwikkelaars kunnen niet wijzigen hoe deze eruitziet — wat betekent dat ontwikkelaars doorgaans een uitzondering krijgen voor dit specifieke criterium. De styling van de app mag de focuszichtbaarheid echter niet actief verminderen door bijvoorbeeld een doorschijnende scrim over gefocuste bedieningselementen te leggen.

3.3.8 Accessible Authentication — Minimum (Level A)

Dit criterium is een grote stap voor cognitieve toegankelijkheid. Het vereist dat authenticatieprocessen niet uitsluitend steunen op een cognitieve functietest — wat betekent dat de gebruiker niet verplicht mag worden om een wachtwoord te onthouden, een puzzel op te lossen of een CAPTCHA over te typen — tenzij de app een toegankelijk alternatief biedt. Op iOS betekent dit ondersteuning voor Apple's Keychain en Sign in with Apple, zodat gebruikers zich kunnen authenticeren zonder inloggegevens te hoeven onthouden. Op Android betekent het ondersteuning voor het Autofill-framework van Google, biometrische authenticatie en het niet blokkeren van het gebruik van wachtwoordmanagers van derden.

Concreter: als uw app plakken in wachtwoordvelden blokkeert, is de kans groot dat deze niet voldoet aan 3.3.8. Als uw tweefactorauthenticatieflow vereist dat de gebruiker handmatig een OTP-code uit een melding overtypt zonder een kopieer-plakmechanisme te bieden, introduceert dit een onnodige cognitieve belasting. De Berichten-app van Android biedt al een "code kopiëren"-knop in OTP-meldingen, precies om deze reden — in lijn met de intentie van het criterium.

Belangrijk inzicht: Ondersteuning voor biometrische authenticatie (Face ID, Touch ID, Android Biometric API) is niet alleen een UX-verbetering — het is een WCAG 2.2-compliancemechanisme voor gebruikers met cognitieve beperkingen die wachtwoorden niet betrouwbaar kunnen onthouden.

3.3.7 Redundant Entry (Level A)

Als een flow in meerdere schermen in uw app — checkout, onboarding, een intakeformulier in de zorg — de gebruiker vraagt om dezelfde informatie meer dan één keer in te voeren, moet u ofwel de eerder ingevoerde waarde automatisch invullen, of een manier bieden om deze uit eerdere invoer te selecteren. Dit criterium is direct van toepassing op native mobiele apps. De klassieke faalmodus is een formulier voor het verzendadres dat later om een factuuradres vraagt zonder optie "hetzelfde als verzendadres", waardoor gebruikers met motorische beperkingen of cognitieve beperkingen gedwongen worden dezelfde tekst meerdere keren opnieuw te typen.

3.2.6 Consistent Help (Level A)

Als uw app een helpmechanisme biedt — een supportchatknop, een help-pictogram, een "contact"-link — moet dit op een consistente locatie verschijnen op alle schermen binnen de app. Gebruikers met cognitieve beperkingen zijn afhankelijk van voorspelbare plaatsing van navigatie- en ondersteuningsmechanismen. Het helpknopje op sommige schermen in de header plaatsen en op andere in de tabbar, of het in bepaalde flows verstoppen in een instellingenmenu, is in strijd met dit criterium.

WCAG 2.1-criteria die cruciaal blijven voor mobiel

De nieuwe WCAG 2.2-criteria krijgen de meeste aandacht, maar verschillende WCAG 2.1-vereisten die specifiek met mobiel in gedachten zijn geïntroduceerd, worden nog steeds regelmatig geschonden in native apps, en compliance-managers mogen deze tijdens audits niet over het hoofd zien.

1.3.4 Orientation (AA) verbiedt het vergrendelen van een app in portret- of landschapsmodus, tenzij die oriëntatie essentieel is voor de functie van de content. Veel apps vergrendelen naar portret tijdens onboardingflows of in videospelers in de app zonder rechtvaardiging. Dit treft in het bijzonder gebruikers met apparaten die op een rolstoel zijn gemonteerd en niet kunnen worden gedraaid. 1.4.10 Reflow (AA) vereist dat content kan worden weergegeven zonder horizontaal scrollen wanneer deze wordt getoond op 320 CSS-pixels breed (het equivalent van 400% zoom), wat in mobiele termen betekent dat Dynamic Type en systeemtekstgrootte-scaling worden ondersteund zonder dat de layout breekt of content wordt afgekapt.

2.5.1 Pointer Gestures (A) vereist dat elke functionaliteit die multipoint- of padgebaseerde gebaren gebruikt — een pinch-to-zoom, een veeg met twee vingers — ook een alternatief met één pointer heeft. 2.5.4 Motion Actuation (A) vereist dat functionaliteit die wordt geactiveerd door het schudden of kantelen van het apparaat ook kan worden bediend via standaard UI-bedieningselementen, en dat gebruikers bewegingsgebaseerde triggers kunnen uitschakelen om onbedoelde activering te voorkomen.

Voor visuele presentatie vereist 1.4.3 Contrast Minimum (AA) een verhouding van ten minste 4,5:1 voor normale tekst en 3:1 voor grote tekst. Veel apps falen hier nog steeds omdat placeholdertekst in invoervelden, labels van uitgeschakelde knoppen en tekst op fotografische achtergronden onder het minimum vallen. Ontwikkelaars moeten ervoor zorgen dat alle tekst, bedieningselementen en content werken met Dynamic Type, Bold Text, dark mode en systeemniveau-contrastopties op zowel iOS als Android.

Platformspecifieke implementatierichtlijnen

iOS en SwiftUI / UIKit

Apple biedt uitgebreide native toegankelijkheidsondersteuning via de UIAccessibility-API en, in SwiftUI, via accessibility modifiers. Voor VoiceOver-ondersteuning moet elk interactief element een betekenisvol accessibility label, hint en value hebben. Aangepaste controls die niet erven van standaard UIKit-componenten, moeten expliciet een passend accessibility trait aannemen — .isButton, .isHeader, .isLink — zodat VoiceOver ze correct aankondigt. De Xcode Accessibility Inspector kan helpen om ontbrekende labels en trait-mismatches tijdens de ontwikkeling aan het licht te brengen.

Voor Dynamic Type schalen de systeemfonts UIKit's UIFont.preferredFont(forTextStyle:) en SwiftUI's .font(.body) automatisch mee met de voorkeurslettergrootte van de gebruiker. Hardgecodeerde lettergroottes in punten die geen gebruikmaken van scaledValue(for:), zullen falen op 1.4.4 Resize Text. Voor targetgroottes kunt u het tikbare gebied van een klein pictogram vergroten met contentEdgeInsets in UIKit of de .contentShape()-modifier in SwiftUI zonder de visuele presentatie van het element te wijzigen.

// SwiftUI: tikgebied vergroten zonder visuele grootte te wijzigen
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android en Jetpack Compose / Views

De toegankelijkheid van Android wordt ontsloten via de AccessibilityNodeInfo-API, die TalkBack en Switch Access gebruiken. In Jetpack Compose kunt u met het blok Modifier.semantics contentbeschrijvingen, rollen, statusbeschrijvingen instellen en semantiek van onderliggende elementen samenvoegen. Voor op Views gebaseerde UI's maakt ViewCompat.setAccessibilityDelegate() programmatische manipulatie van toegankelijkheidseigenschappen op elke view mogelijk.

Voor de grootte van aanraakdoelen beveelt de Material Design-richtlijn minimaal 48 × 48 dp aan. Als een composable of view visueel kleiner is, kunt u Modifier.minimumInteractiveComponentSize() in Compose (geïntroduceerd in Material3) gebruiken om automatisch een minimum van 48 dp af te dwingen, of een kleine view in een TouchDelegate wikkelen om het raakvlak in het legacy View-systeem te vergroten. Voor tekstschaalbaarheid moet u ervoor zorgen dat alle tekstgroottes worden opgegeven in sp (scale-independent pixels), niet in dp, zodat ze de lettergroottevoorkeuren van de gebruiker respecteren die zijn ingesteld in de weergave-instellingen van Android.

// Jetpack Compose: toegankelijke icon button met minimale grootte
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // dwingt minimaal 48dp af
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // beschreven door ouder
    )
}

Uw app testen tegen WCAG 2.2

Het testen van mobiele toegankelijkheid vereist een combinatie van geautomatiseerde tooling en handmatige tests met echte ondersteunende technologieën. Geautomatiseerde tools — waaronder Deque's axe DevTools Mobile, Google's Accessibility Scanner voor Android en Apple's Accessibility Inspector in Xcode — kunnen ontbrekende labels, onvoldoende contrast en aanraakdoelen onder de platformminimums opsporen. Geautomatiseerde tools detecteren echter slechts een fractie van de echte toegankelijkheidsproblemen. Handmatig testen met VoiceOver op iOS en TalkBack op Android is essentieel om de juiste leesvolgorde, betekenisvolle labels en logische focusafhandeling in complexe flows te verifiëren.

Voor WCAG 2.2-specifieke criteria is handmatig testen bijzonder belangrijk. Om 2.5.8 (Target Size) te testen, gebruikt u uw eigen vinger — niet een muiscursor in de iOS Simulator — om interacties met kleine controls te proberen. Om 3.3.8 (Accessible Authentication) te testen, verifieert u dat uw inlogflow plakken in wachtwoordvelden toestaat, wachtwoordmanagers (1Password, Bitwarden, systeemkeychain) ondersteunt en biometrische authenticatie ondersteunt. Om 2.4.11 (Focus Not Obscured) te testen, navigeert u uw app volledig via Switch Control op iOS of Switch Access op Android en bevestigt u dat geen enkel gefocust element verdwijnt achter een navigatiebalk, modale overlay of zwevende knop.

Een uitgebreid toegankelijkheidstestplan moet tests omvatten op ten minste twee fysieke apparaten — één iPhone en één Android-apparaat — bij de standaardlettergrootte van de gebruiker en bij de maximale systeemlettergrootte, met respectievelijk VoiceOver en TalkBack ingeschakeld. Alleen testen in een simulator zal verschillen in rendering in de praktijk en het gedrag van ondersteunende technologie missen.

Overweeg om toegankelijkheidscontroles in uw CI/CD-pijplijn in te bouwen. Zowel Espresso (Android) als XCUITest (iOS) ondersteunen het schrijven van geautomatiseerde UI-tests die toegankelijkheidseigenschappen verifiëren — contentbeschrijvingen, traits en ingeschakelde statussen — zodat regressies worden opgevangen voordat code wordt gemerged in plaats van ontdekt in een productie-audit.

De juridische en zakelijke argumenten om nu te handelen

Naast de morele plicht tot inclusie is de zakelijke case voor mobiele toegankelijkheid concreet. Bedrijven die vooroplopen in inclusie van mensen met een beperking genereren 1,6 keer meer omzet en 2,6 keer meer nettowinst dan branchegenoten. Mensen met een beperking in de VS beschikken over bijna een half biljoen dollar aan vrij besteedbaar inkomen. En aangezien 69% van de online consumenten met een beperking apps en websites verlaat die ze moeilijk te gebruiken vinden, is elke toegankelijkheidsbarrière een conversie die nooit plaatsvindt.

Het juridische risico neemt toe. Rechtszaken tegen bedrijven met tekortschietende digitale toegankelijkheid blijven jaar op jaar groeien. De adoptie van WCAG door de DOJ als technische standaard voor ADA-naleving, de handhavingstermijnen van Title II in 2026 en de inwerkingtreding van de EAA in juni 2025 creëren samen een multijurisdictie-nalevingsvereiste die nu expliciet native mobiele applicaties omvat. Een eerdere WCAG 2.1-audit toont niet automatisch aan dat aan WCAG 2.2 wordt voldaan — authenticatieflows, formuliervelden, interactieve componenten en focusbeheer moeten allemaal opnieuw worden beoordeeld aan de hand van de negen nieuwe succescriteria.

Cruciaal is dat toegankelijkheid in mobiel geen feature is die goedkoop achteraf kan worden ingebouwd na de lancering. Het oplossen van WCAG-fouten in een uitgebrachte app betekent bijgewerkte assets, herbouwde componenten, herziene layouts, opnieuw geteste flows en mogelijk gerefactorde authenticatiesystemen. Teams die WCAG 2.2-conformiteit vanaf het begin in hun design systems en componentbibliotheken inbouwen — door minimale aanraakdoelgroottes, contrasttokens, semantische rollen en authenticatiepatronen op componentniveau af te dwingen — betalen een fractie van de kosten vergeleken met het herstellen van een ontoegankelijke app na de lancering.

Belangrijkste punten

• WCAG 2.2 is van toepassing op native iOS- en Android-apps. De WCAG2Mobile-richtlijnen van het W3C koppelen elk Level A- en AA-succescriterium aan mobiele schermen en views, wat betekent dat uw native app binnen scope valt — niet alleen uw mobiele website.
• De grootte van aanraakdoelen is de meest voorkomende nieuwe faalreden in mobiele audits. De 24 × 24-minimumwaarde van WCAG 2.2 is de ondergrens; Apple beveelt 44 × 44 pt aan en Google 48 × 48 dp. Vergroot raakvlakken met padding en platform-native API's, niet door pictogrammen visueel te vergroten.
• Het blokkeren van plakken in wachtwoordvelden schendt waarschijnlijk 3.3.8 Accessible Authentication. Ondersteun systeemkeychains, wachtwoordmanagers, biometrie en automatische OTP-invulling om te voldoen aan de cognitieve toegankelijkheidseisen voor inlogflows op beide platforms.
• Handmatig testen met VoiceOver en TalkBack is ononderhandelbaar. Geautomatiseerde tools detecteren slechts een fractie van de toegankelijkheidsproblemen. Test op fysieke apparaten bij maximale lettergrootte, met ondersteunende technologieën ingeschakeld, in elke kritieke gebruikersflow.
• Bouw toegankelijkheid nu in uw design system in, niet na de lancering. Het herstellen van ontoegankelijke apps na de lancering is veel duurder dan vanaf dag één toegankelijke componentstandaarden afdwingen. Met de handhavingstermijnen van DOJ, HHS en EAA in 2025–2026 sluit het venster voor goedkope nalevingsmaatregelen zich snel.