Toegankelijkheids-API: hoe software communiceert met schermlezers en andere hulpmiddelen
Wie weleens gezien heeft hoe iemand die blind is een smartphone bedient, ziet vaak een scherm dat uit blijft terwijl een gejaagde, mechanische stem razendsnel opsomt wat er gebeurt. Dat lijkt op magie, maar erachter zit een saai stukje techniek dat wel onmisbaar is: de toegankelijkheids-API (accessibility API). Dat is een verzameling regels en functies waarmee een besturingssysteem of app aan hulpsoftware, zoals een schermlezer, precies doorgeeft welke knoppen, teksten en menu's er op het scherm staan, wat hun functie is en in welke staat ze verkeren.
Een handige vergelijking: stel je een tolk voor die naast een dove bezoeker in een theater staat en fluisterend vertelt wat er op het toneel gebeurt en wie er spreekt. De toegankelijkheids-API is die tolk, maar dan tussen een grafische interface en software zoals VoiceOver op de iPhone of NVDA op een Windows-pc. Zonder die tolk zou een schermlezer alleen pixels zien, geen betekenis. Met de API krijgt hij een gestructureerde, onzichtbare laag informatie: dit is een knop met de naam "Verzenden", dit tekstvak is leeg, dit vakje staat aangevinkt.
Wat is het precies?
Elk besturingssysteem bouwt, naast het scherm dat je ziet, een tweede, onzichtbare structuur op: de toegankelijkheidsboom (accessibility tree). Dat is een soort inhoudsopgave van alle onderdelen van een app: vensters, knoppen, tekstvelden, afbeeldingen, menu's. Elk onderdeel krijgt in die boom een aantal vaste eigenschappen mee.
De belangrijkste eigenschappen zijn de rol (is dit een knop, een schuifbalk, een kopje?), de naam (welke tekst hoort erbij, bijvoorbeeld "Zoeken"), de waarde (bij een schuifbalk: op welke stand staat hij?) en de status (is het aangevinkt, uitgeschakeld, geselecteerd?). Dit "naam, rol, waarde"-principe vormt al decennia de basis van vrijwel elke toegankelijkheidsstandaard.
Een schermlezer, een braille-leesregel of spraakbesturingssoftware praat niet rechtstreeks met een app. Het praat met de toegankelijkheids-API van het besturingssysteem, die op zijn beurt bij de app de actuele boom opvraagt. Verandert er iets op het scherm, bijvoorbeeld doordat een foutmelding verschijnt, dan moet de app dat doorgeven via een gebeurtenis in die API, zodat de schermlezer het meteen kan melden.
Op het web werkt dit net iets anders. Browsers bouwen zelf een toegankelijkheidsboom op basis van de HTML-code van een pagina. Gewone HTML-elementen zoals een knop of een link krijgen automatisch de juiste rol mee. Voor zelfgebouwde interface-onderdelen, bijvoorbeeld een op maat gemaakt uitklapmenu, moeten ontwikkelaars zelf aanvullende informatie toevoegen. Daarvoor bestaat de webstandaard WAI-ARIA (Accessible Rich Internet Applications), waarmee je met extra attributen in de HTML kunt aangeven welke rol, naam en status een onderdeel heeft. De browser vertaalt die informatie vervolgens naar de toegankelijkheids-API van het besturingssysteem waarop hij draait.
Wat wil men ermee bereiken?
Het doel is simpel te omschrijven: mensen met een beperking moeten dezelfde software kunnen gebruiken als iedereen, zonder dat daarvoor een aparte, verarmde versie van een app of website gebouwd hoeft te worden. In plaats van voor elke doelgroep apart software te schrijven, zorgt de toegankelijkheids-API ervoor dat één app tegelijk bruikbaar is via het scherm, via een schermlezer, via een braille-leesregel, via spraakbesturing of via een schakelaar die met één vinger of met de mond wordt bediend.
Daarachter zit ook een praktische reden: onderhoud. Als hulptechnologie zelf zou moeten gokken wat er op een scherm staat, bijvoorbeeld door schermafbeeldingen te analyseren met beeldherkenning, dan zou dat traag en foutgevoelig zijn. Door software haar eigen structuur netjes te laten rapporteren via één gedeelde interface, hoeft dat gokwerk niet en werkt hulpsoftware sneller en preciezer.
Er is ook een juridische drijfveer. In de Verenigde Staten verplicht Section 508 van de Rehabilitation Act overheidssoftware al sinds 1998 tot toegankelijkheid. In de Europese Unie geldt sinds 28 juni 2025 de European Accessibility Act, die bedrijven verplicht om onder meer websites, apps, bankautomaten en e-boeken toegankelijk te maken. Toegankelijkheids-API's zijn het technische fundament waarop ontwikkelaars die eisen kunnen waarmaken.
Voorbeelden uit de praktijk
Microsoft Active Accessibility en UI Automation. Microsoft introduceerde in 1997 de eerste brede toegankelijkheids-API voor Windows, Microsoft Active Accessibility (MSAA). Die werd vanaf het midden van de jaren 2000 geleidelijk vervangen door de rijkere UI Automation (UIA), die tegenwoordig de basis vormt onder Windows' eigen schermlezer Narrator en onder externe programma's zoals JAWS en NVDA.
Apple's Accessibility-frameworks. macOS kreeg zijn NSAccessibility-API in de jaren 2000, en met de komst van VoiceOver op de iPhone in 2009 volgde een vergelijkbare API voor iOS, UIAccessibility. Doordat Apple deze API's centraal in het besturingssysteem heeft ingebouwd, werkt VoiceOver in de praktijk in vrijwel elke standaard-app, van Mail tot de Camera.
Android AccessibilityService. Google bouwde voor Android een vergelijkbaar systeem, waarmee de eigen schermlezer TalkBack, maar ook diensten als Voice Access (spraakbesturing) en Switch Access (bediening met externe schakelaars) toegang krijgen tot de interface van andere apps.
WAI-ARIA en NVDA. Op het web is WAI-ARIA, ontwikkeld door het World Wide Web Consortium (W3C), sinds de eerste officiële versie in 2014 de gangbare standaard. Een concreet gebruiksvoorbeeld: de gratis, open source schermlezer NVDA (NonVisual Desktop Access), gebouwd door de Australische organisatie NV Access sinds 2006, leunt zowel op de Windows UI Automation-API als op de ARIA-informatie die browsers zoals Chrome en Firefox aanleveren.
GNOME's ATK/AT-SPI. Ook in de Linux-wereld bestaat een vergelijkbaar systeem: het Accessibility Toolkit (ATK) en de bijbehorende dienst AT-SPI, die onder meer de schermlezer Orca van informatie voorzien binnen de GNOME-desktopomgeving.
Hoe ver is de techniek?
Toegankelijkheids-API's zijn geen nieuwe technologie meer; de basisprincipes staan al zo'n 25 jaar overeind en worden breed ondersteund door alle grote besturingssystemen en browsers. In die zin is het een volwassen, stabiel stuk techniek. Het knelpunt zit tegenwoordig minder in de API's zelf en meer in de vraag of ontwikkelaars ze correct gebruiken.
Vooral moderne, interactieve webapps zijn een terugkerend probleem. Websites die volledig zijn opgebouwd met JavaScript-frameworks bouwen hun eigen knoppen, schuifbalken en menu's vaak vanaf nul, zonder de juiste ARIA-rollen mee te geven. De non-profit WebAIM scant jaarlijks de miljoen populairste websites automatisch op toegankelijkheid, en die metingen laten al jaren zien dat verreweg de meeste homepages meetbare fouten bevatten, vaak gerelateerd aan ontbrekende of foutieve labels bij knoppen en formuliervelden.
Er lopen ook verbeteringen door. Het W3C werkt aan aanvullingen op WAI-ARIA, en browserbouwers investeren in een snellere, betrouwbaardere koppeling tussen hun interne toegankelijkheidsboom en de API's van het onderliggende besturingssysteem. Testtools zoals axe van Deque Systems en de ingebouwde Lighthouse-toets van Google Chrome maken het inmiddels relatief eenvoudig om automatisch een deel van de fouten op te sporen, al blijft handmatige controle met een echte schermlezer nodig: geen enkele tool herkent alle problemen.
Een ander obstakel is dat toegankelijkheids-API's per platform verschillen. Een ontwikkelaar die een app zowel voor Windows, macOS, iOS, Android als het web wil aanbieden, moet in de praktijk met meerdere verschillende API's rekening houden. Cross-platformframeworks zoals Flutter en React Native proberen dat te vereenvoudigen door zelf de vertaling naar elk platform te verzorgen, maar die vertaling verloopt niet altijd foutloos.
Wie werken eraan?
Bij het onderhouden van de webstandaard WAI-ARIA speelt de Accessible Rich Internet Applications Working Group van het World Wide Web Consortium (W3C) de hoofdrol, met deelnemers van onder meer Apple, Google, Microsoft, Mozilla en gespecialiseerde toegankelijkheidsbedrijven.
De grote platformbeheerders bouwen en onderhouden elk hun eigen API: Microsoft voor UI Automation op Windows, Apple voor de Accessibility-frameworks op macOS en iOS, en Google voor de Accessibility-API op Android en voor de toegankelijkheidsboom in de Chrome-browser en Chromium, de open source basis waarop ook Microsoft Edge en veel andere browsers draaien.
Daarnaast is er een laag van gespecialiseerde bedrijven en stichtingen die op deze API's voortbouwen. NV Access in Australië ontwikkelt het gratis NVDA. Freedom Scientific, een Amerikaans bedrijf, maakt de veelgebruikte betaalde schermlezer JAWS. Deque Systems en TPGi (voorheen The Paciello Group) leveren testtools en advies aan bedrijven die hun software toegankelijk willen maken.
Op onderzoeksvlak heeft het Trace Research & Development Center, historisch verbonden aan de University of Wisconsin-Madison en later verhuisd naar de University of Maryland, al sinds de jaren zeventig een voortrekkersrol gespeeld in fundamenteel onderzoek naar toegankelijke technologie, en meegewerkt aan basisprincipes die later in standaarden als WAI-ARIA en Section 508 zijn verwerkt.