--- title: "Toegankelijkheid van mobiele apps: praktijkgids | GoodBarber" description: "U kunt niet aan de hand van een preview of contrastscore bewijzen dat een app toegankelijk is. U kunt echter wel verrassend veel barrières wegnemen voordat form" canonical_url: "https://nl.goodbarber.com/blog/toegankelijkheid-van-mobiele-apps-zo-maakt-u-uw-app-toegankelijker-a1428/" lang: nl date: 2026-08-20 last_updated: 2026-08-20 --- # Toegankelijkheid van mobiele apps: praktijkgids | GoodBarber [Terug](/blog/maak-het-waar-r13/) # Toegankelijkheid van mobiele apps: zo maakt u uw app toegankelijker Written by [Marc Leonardi](https://nl.goodbarber.com/blog/author/marc-leonardi/) on Donderdag 20 Augustus 2026 ## Toegankelijkheid van mobiele apps helpt mensen met een visuele, auditieve, motorische of cognitieve beperking om content waar te nemen, de interface te begrijpen en belangrijke taken uit te voeren. We maakten een kopie van Lotus Yoga, een van onze showcase-apps, bewust moeilijker in gebruik, bouwden deze vervolgens opnieuw op in GoodBarber en onderzochten wat de preview wel — en niet — kon aantonen. ## Mobiele toegankelijkheid begint met een systeem ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053413.jpg?v=1787262348.1782138) U kunt niet aan de hand van een preview of contrastscore bewijzen dat een app toegankelijk is. U kunt echter wel verrassend veel barrières wegnemen voordat formele tests beginnen. Toegankelijkheid van mobiele apps gaat veel verder dan kleurcontrast. Typografie, witruimte, navigatie, aanraakdoelen, labels, beweging, media en het gedrag met ondersteunende technologie bepalen allemaal of iemand een taak kan voltooien. WCAG is geschreven voor webcontent. De [WCAG2Mobile-richtlijnen](https://www.w3.org/TR/wcag2mobile-22/) van het W3C leggen uit hoe de criteria van WCAG 2.2 niveau A en AA kunnen worden toegepast op native, web- en hybride mobiele apps. Dit document is informatief en vormt geen afzonderlijke normatieve mobiele standaard. Op zichzelf volstaat het evenmin om vast te stellen dat een app toegankelijk is. Deze checklist maakt onderscheid tussen wat u centraal kunt configureren en wat u nog in het gepubliceerde product moet controleren: | Toegankelijkheidsgebied | Eerste controle | Wat u moet configureren of testen | | ----------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------- | | Kleurcontrast | Tekst, achtergronden, bedieningselementen en statussen | Stel globale kleuren in en controleer elk contrastpaar | | Typografie en witruimte | Leesbare standaardwaarden, tekstomloop en vergroting | Configureer de globale typografische hiërarchie en marges | | Navigatie | Duidelijke bestemmingen en labels | Configureer de appstructuur, labels en navigatie | | Aanraakdoelen | Bedieningselementen zijn eenvoudig te gebruiken | Controleer de gegenereerde app op apparaten | | Schermlezers | Namen, rollen, statussen en focusvolgorde | Test de gegenereerde iOS- en Android-apps | | Beweging | Effecten blijven nuttig en optioneel | Configureer animaties en haptische feedback en test daarna de systeemvoorkeuren | | Media | Ondertiteling, transcripties en tekstalternatieven | Voeg alternatieven toe tijdens het maken en redigeren van content | | PWA-interactie | Toetsenbord, zoom, focus en responsieve lay-outs | Test de gepubliceerde PWA in browsers | ## Lotus Yoga: verzorgd op het eerste gezicht, kwetsbaar in gebruik ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053414.jpg?v=1787262350.2782245) Niets in dit eerste scherm leek duidelijk defect. Dat was juist het nuttige aan deze oefening. Toegankelijkheidsproblemen zijn niet altijd spectaculair; ze gaan vaak schuil achter smaakvolle ontwerpkeuzes. We gaven Lotus Yoga lichte tekst op een lichte achtergrond, verkleinden de lopende tekst tot 10 px, verwijderden de globale marges en behielden algemene navigatielabels zoals ‘Videos’ en ‘Podcasts’. Het resultaat oogde nog steeds rustig in een presentatie. Op een telefoon stortte de hiërarchie echter in: secundaire tekst vervaagde, kaarten kwamen dicht tegen de schermranden te staan en de onderste navigatie werd veel moeilijker te scannen. De les is niet dat u nooit pastelkleuren mag gebruiken of alles groot moet maken. Merkkeuzes hebben een leesbaar onderliggend systeem nodig. ## Stap 1: verbeter kleurcontrast als systeem ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053415.jpg?v=1787262352.2262342) We begonnen in **Mijn App > App-Stijl > Kleuren** en wezen kleuren toe op basis van hun rol. De warme achtergrond bleef behouden. Wat veranderde, was het verschil tussen elke voorgrondkleur en de bijbehorende achtergrond: | Element | Voorgrond | Achtergrond | Verhouding | | ----------------------- | --------- | ----------- | ---------- | | Hoofdtekst | `#17332F` | Warm wit | 13,3:1 | | Secundaire tekst | `#4E6A65` | Warm wit | 5,8:1 | | Tekst van primaire knop | `#FFFFFF` | `#1F6D63` | 6,1:1 | | Titel in header | `#17332F` | Lichtgroen | 11,6:1 | [WCAG 2.2 stelt voor niveau AA een minimale contrastverhouding vast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) van 4,5:1 voor normale tekst en 3:1 voor grote tekst. Voor de belangrijkste tekst kozen we bewust meer marge dan het minimum: een combinatie die op papier slaagt, kan nog steeds zwak ogen bij een dun lettertype, een klein formaat of een helder scherm buitenshuis. Met GoodBarber kunt u vertrekken van een ingebouwd thema, een palet genereren of er zelf een maken. Het nuttige zit niet in het aantal kleurstalen, maar in het hergebruik ervan. Headertekst, lopende tekst, scheidingslijnen, knoppen en navigatiestatussen kunnen in alle secties consistente rollen krijgen. De [documentatie over App-Stijl](https://www.goodbarber.com/help/shop/app-style-and-branding-r87/app-style-essential-design-settings-a317/) legt uit hoe deze globale keuzes worden doorgevoerd. Een leesbaar palet is een sterk vertrekpunt, geen toegankelijkheidscertificaat. Controleer elk werkelijk voorgrond-achtergrondpaar, inclusief geselecteerde statussen, overlays, afbeeldingen en overschrijvingen op sectieniveau. ## Stap 2: stel leesbare typografie en witruimte in ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053416.jpg?v=1787262354.1902442) Door het contrast werden de woorden zichtbaar. Door formaat en witruimte werden ze comfortabel leesbaar. We selecteerden het lettertypethema Formateca, dat Work Sans voor koppen combineert met Manrope voor lopende tekst. Vervolgens gebruikten we de globale typografieschuifregelaar om de hiërarchie opnieuw op te bouwen: de lopende tekst ging van 10 px naar 16 px, de hoofdtitel werd 30 px en de hoofdcontent kreeg opnieuw marges van 16 px. De globale typografieschaal van GoodBarber past acht tekstniveaus proportioneel aan. Daardoor blijft een consistente hiërarchie op verschillende schermen eenvoudiger behouden, maar een toegankelijk resultaat is niet gegarandeerd. Controleer de resulterende groottes, tekstomloop en regelafstand in de gegenereerde app. WCAG schrijft geen universele minimale lettergrootte voor lopende tekst voor. De waarde van 16 px is de standaard die wij voor deze interface kozen, geen conformiteitsdrempel. Grotere tekst heeft ook meer ruimte nodig; zonder die ruimte worden kaarten krap en breken labels onhandig af. Test de app ten slotte met de tekstgrootte die de gebruiker verkiest. [Apple raadt ondersteuning voor tekstvergroting en Dynamic Type aan](https://developer.apple.com/design/human-interface-guidelines/accessibility), terwijl webcontent bruikbaar moet blijven wanneer tekst wordt vergroot. Een gebalanceerde editorpreview is slechts de eerste toestand die u moet controleren. ## Stap 3: laat navigatielabels de bestemming beschrijven ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053417.jpg?v=1787262356.0102534) In deze vergelijking vóór en na luidde de oorspronkelijke TabBar ‘Videos’, ‘Podcasts’ en ‘Navigation’. Die labels beschreven formaten of de werking van de interface. Ze maakten niet duidelijk wat een yogalid vervolgens kon doen. We hernoemden ze naar **Classes**, **Audio** en **More**. De structuur veranderde niet, maar de keuze werd eenvoudiger: een les volgen, een audiosessie kiezen of de overige secties openen. [De toegankelijkheidsrichtlijnen van Android](https://developer.android.com/guide/topics/ui/accessibility/views/principles-views) adviseren nuttige, beschrijvende labels voor interactieve elementen, omdat diensten zoals TalkBack hun toegankelijkheidsnamen kunnen uitspreken. Het wijzigen van de zichtbare titel verbetert de visuele navigatie; u moet nog steeds controleren wat het gegenereerde component daadwerkelijk aan VoiceOver en TalkBack doorgeeft. Houd labels kort, uniek en taakgericht. Combineer pictogrammen waar mogelijk met tekst. Een eenvoudige test: als de pictogrammen verdwenen, zouden de woorden een gebruiker dan nog steeds vertellen waar elke tik naartoe leidt? ## Stap 4: maak bedieningselementen en content bruikbaar Toegankelijkheid schiet tekort wanneer content zichtbaar is maar een bedieningselement moeilijk aan te tikken is, of wanneer essentiële media één zintuiglijk kanaal uitsluiten. Begin met aanraakdoelen. [Android adviseert voor interactieve elementen een focusbaar gebied van minstens 48 × 48 dp](https://developer.android.com/guide/topics/ui/accessibility/views/apps-views). Voor de PWA stelt het criterium [Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) van WCAG 2.2 op niveau AA een minimum van 24 × 24 CSS-pixels vast, met bepaalde uitzonderingen. Het zichtbare pictogram mag kleiner zijn dan het bedienbare gebied, maar naburige doelen moeten duidelijk van elkaar gescheiden blijven. Controleer vervolgens hoe betekenis wordt overgebracht. Fouten, voortgang en beschikbaarheid hebben duidelijke signalen nodig die gebruikers kunnen waarnemen. Informatieve afbeeldingen hebben zinvolle tekstalternatieven nodig; betekenisvolle video heeft ondertiteling nodig; audio zonder beeld heeft een transcriptie of gelijkwaardig alternatief nodig. Dit zijn redactionele beslissingen, dus een consistent appontwerp kan ze niet voor u automatiseren. GoodBarber centraliseert de hiërarchie, kleuren en vorm van knoppen via App-Stijl. Gebruik deze instellingen om inconsistenties te verminderen en controleer vervolgens de grootte van aanraakdoelen, focus, labels en statussen in de gegenereerde iOS-, Android- en PWA-versies. ## Stap 5: gebruik beweging en haptiek doelgericht Lotus Yoga gebruikte zowel haptische feedback als een openingsanimatie. In **Mijn App > App-Stijl** schakelden we het decoratieve openingseffect uit, terwijl we haptische feedback in de native apps behielden. GoodBarber biedt in hetzelfde gedeelte ook scrolleffecten; de [aanvullende opties voor App-Stijl](https://www.goodbarber.com/help/app-style-and-branding-r87/app-style-additional-design-options-a412/) leggen uit waar u deze instellingen vindt. Die keuze is geen universeel toegankelijkheidsvoorschrift. Beweging kan een statuswijziging verduidelijken en haptiek kan een actie bevestigen zonder extra visuele drukte. De vraag is of het effect nuttige informatie draagt. Is dat niet het geval, dan is een rustigere standaard eenvoudiger te verantwoorden. Ga er niet van uit dat een wijziging in de editor bewijst dat de voorkeur voor minder beweging wordt ondersteund. Controleer de gepubliceerde app met de bewegingsvoorkeuren van het apparaat ingeschakeld en bevestig dat volledige taken zonder het effect nog steeds begrijpelijk zijn. ## Stap 6: test volledige trajecten in native apps en de PWA ![](https://cmsphoto.ww-cdn.com/superstatic/2962774/art/grande/97759888-68053420.jpg?v=1787262357.882263) Deze uiteindelijke versie is eenvoudiger te lezen en te navigeren zonder het rustige karakter van het merk te verliezen. Belangrijker nog: de verbeteringen zijn systemisch. Eén palet, typografieschaal en witruimtesysteem kan veel schermen tegelijk verbeteren. De preview kan kleur, hiërarchie, witruimte, labels en zichtbare statussen tonen. Hij kan u niet vertellen of elke aankondiging van een schermlezer nuttig is, of de focus logisch beweegt of een volledig traject bruikbaar blijft met een alternatieve invoermethode. Vóór publicatie: - Doorloop de belangrijkste iOS-trajecten met VoiceOver en de Android-trajecten met TalkBack, zonder naar het scherm te kijken. - Vergroot de systeemtekst en controleer op afsnijding, overlap, verborgen bedieningselementen en ontbrekende content. - Controleer knoppen, links, formulieren en menu’s op duidelijke namen, rollen, statussen en focusvolgorde. - Test de PWA met toetsenbordnavigatie, browserzoom en meerdere viewportformaten. Geautomatiseerde tools vinden nuttige problemen. Ze begrijpen niet of een label logisch is, een instructie cognitief duidelijk is of een volledige taak frustrerend aanvoelt. Handmatig testen — idealiter met mensen met een beperking — blijft essentieel. ## Hoe GoodBarber helpt een toegankelijkere basis te creëren Het voordeel van een designsysteem is het hefboomeffect. GoodBarber bouwt schermen op uit gedeelde fundamenten en herbruikbare componenten. Kleur, typografie, witruimte, vorm en navigatie zijn regels die in de hele app worden hergebruikt, geen losstaande decoraties. U kunt het [GoodBarber Design System ontdekken](https://nl.goodbarber.com/uxdesign/) om te zien hoe deze lagen samenhangen. Dat hefboomeffect zorgt ook voor een duidelijke verantwoordelijkheidsverdeling: | GoodBarber helpt centraliseren | Wat u nog moet controleren | | ----------------------------------------- | --------------------------------------------------------------------- | | Globale kleurrollen | Werkelijke contrastparen en signalen die niet alleen op kleur steunen | | Typografische hiërarchie met acht niveaus | Tekstvergroting, tekstomloop en afsnijding | | Marges, witruimte en knopstijlen | Bruikbaarheid van aanraakdoelen op echte apparaten | | Navigatiestructuur en zichtbare labels | Toegankelijkheidsnamen, rollen, statussen en focusvolgorde | | Animaties en native haptische feedback | Gedrag met de toegankelijkheidsvoorkeuren van het systeem | | iOS-, Android- en PWA-output | Volledige trajecten, content en integraties van derden | Het Design System van GoodBarber neemt een deel van het repetitieve toegankelijkheidswerk weg door gedeelde regels voor typografie, kleur, witruimte en componenten in de hele app toe te passen. U moet de resulterende interface en content nog steeds op elk platform valideren. ## FAQ **Is WCAG van toepassing op native mobiele apps?** WCAG is geschreven voor webcontent, maar de principes en succescriteria worden op grote schaal gebruikt bij mobiele toegankelijkheid. De WCAG2Mobile-conceptrichtlijnen van het W3C leggen uit hoe de criteria van WCAG 2.2 niveau A en AA kunnen worden toegepast op native, web- en hybride mobiele apps. De richtlijnen zijn informatief en vormen geen afzonderlijke normatieve mobiele standaard of garantie op naleving van de wet. **Kan een app builder een app automatisch toegankelijk maken?** Nee. Herbruikbare componenten, leesbare standaardwaarden en globale ontwerpregels kunnen een sterkere basis bieden, maar toegankelijkheid hangt ook af van de configuratie, content, functies van derden en volledige gebruikersroutes. De gegenereerde app moet nog steeds worden getest. **Wat moet ik als eerste testen in een bestaande mobiele app?** Begin met de trajecten die gebruikers niet kunnen vermijden: de app openen, navigeren, inloggen, content vinden en de hoofdactie voltooien. Test deze met een schermlezer, vergrote tekst en minder beweging en controleer vervolgens aanraakdoelen, formulierfouten en media-alternatieven. **Wat is het minimale tekstcontrast voor een mobiele app?** WCAG 2.2 niveau AA stelt een minimale contrastverhouding vast van 4,5:1 voor normale tekst en 3:1 voor grote tekst. Deze drempels worden via de WCAG2Mobile-richtlijnen ook vaak gebruikt bij de beoordeling van mobiele interfaces. Beschouw ze als een ondergrens en niet als ontwerpdoel. **Waar wijzig ik deze instellingen in GoodBarber?** Open **Mijn App > App-Stijl** om globale kleuren, lettertypen, marges, knoppen, animaties en haptische feedback te beheren. Navigatielabels en lay-outs worden in de appstructuur geconfigureerd. Bekijk tijdens het werken het resultaat in de preview en test vóór publicatie de gegenereerde iOS-, Android- en PWA-versies. Een toegankelijke app is geen bijzondere visuele stijl. Het is een reeks beslissingen waardoor meer mensen de content kunnen waarnemen, de interface kunnen begrijpen en de taak kunnen voltooien. [Maak uw app met GoodBarber](https://nl.goodbarber.com/create), bouw die basis één keer op en verbeter haar met inzichten van echte gebruikers. ![Marc Leonardi](https://blog.goodbarber.com/_public/profile/d4/d4a7d2d89eb08037d76fc10910f1f708ee738ec4-default.jpg) Over de auteur[Marc Leonardi](https://nl.goodbarber.com/blog/author/marc-leonardi/)Backend & DevOps Engineer Ik ben Backend & DevOps Engineer bij GoodBarber en werk aan de systemen en infrastructuur waarop ons no-codeplatform voor het bouwen van apps draait. Ik ontwikkel en beheer backendservices, API's en infrastructuur, met de nadruk op betrouwbaarheid, schaalbaarheid en automatisering. Ik schrijf over backend engineering, DevOps, infrastructuur en de technische uitdagingen van het beheren van een platform op grote schaal. [Lees meer](https://nl.goodbarber.com/blog/author/marc-leonardi/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/marc-leonardi-7bbab321b/)