🤖 AI

The Accessibility Capability Boundary: Operational Limits and Expansion Potential of AI-Generated Browser-Native Accessibility Systems

Dit artikel introduceert het "Accessibility Capability Boundary" (ACB)-kader om de operationele grenzen en het uitbreidingspotentieel van door AI aangedreven toegankelijkheidssystemen te definiëren, met het betoog dat browser-native, single-file artefacten deze grenzen aanzienlijk kunnen uitbreiden door implementatiefrictie te minimaliseren, terwijl resterende computationele en infrastructurele beperkingen worden geïdentificeerd.

Oorspronkelijke auteurs: Rizwan Jahangir, Daisuke Ishii

Gepubliceerd 2026-05-20

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Rizwan Jahangir, Daisuke Ishii

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je het internet voor als een enorme, drukke stad. Voor veel mensen met een beperking is het navigeren door deze stad als proberen er doorheen te lopen met een blinddoek voor de ogen, of met zware kettingen om hun enkels. Traditioneel was het bouwen van een "hellingbaan" of een "geleide" om hen te helpen navigeren, een traag, duur en ingewikkeld bouwproject. Je had gespecialiseerde ingenieurs (ontwikkelaars) nodig, zware machines (complexe software-installaties) en veel tijd om het te laten bouwen.

Dit artikel stelt een grote vraag: Wat als we een superintelligente AI-robot konden gebruiken om direct een op maat gemaakte hellingbaan te bouwen voor iedereen, precies waar ze staan, met alleen de tools die ze al in hun broekzak hebben (hun webbrowser)?

Hier volgt een uiteenzetting van de ideeën uit het artikel met eenvoudige analogieën:

1. Het Probleem: De "Binair" Valstrik

Traditioneel dachten we over toegankelijkheid als een lichtschakelaar: een website staat ofwel "aan" (toegankelijk) of "uit" (ontoegankelijk). De auteurs zeggen dat dit verkeerd is. Toegankelijkheid is geen schakelaar; het is meer als een dimmer of een terreinkaart.

De Terreinkaart: Soms is een website makkelijk te bewandelen (snelle internetverbinding, een krachtige computer). Soms is het een modderige, steile heuvel (traag internet, een oude telefoon, een gebruiker met specifieke behoeften).
Het Doel: We moeten precies weten hoe ver een systeem kan gaan voordat het faalt in het helpen van een gebruiker. De auteurs noemen deze grens de Toegankelijkheids Capabiliteitsgrens (ACB). Denk hierbij aan de rand van een kaart. Binnen de rand kan de gebruiker zich verplaatsen; buiten de rand breekt het systeem samen.

2. De Oplossing: De "Directe Bouwer" Robot

Het artikel introduceert een nieuwe manier om deze hellingbanen te bouwen met Grote Taalmodellen (AI).

Oude Weg: Om een op maat gemaakt toegankelijkheidstool te bouwen, huur je een team in, besteed je weken aan coderen, installeer je een zwaar programma op een computer en hoop je dat het werkt.
Nieuwe Weg (AI-gegenereerd): Je vraagt een AI: "Bouw een tool om een blinde persoon te helpen hun webcam uit te lijnen," en de AI schrijft direct een enkel bestand met code. Je klikt gewoon op een link en het werkt. Geen installatie, geen zware software.

3. De Twee Wereldse Tests (De "Probes")

De auteurs hebben niet alleen over theorie gesproken; ze bouwden twee echte dingen om hun kaart te testen:

Test A: De Nepal-Connectie
- De Situatie: Een blinde gebruiker in Nepal heeft hulp nodig. Het internet is onstabiel en het kopen van dure software is onmogelijk.
- De AI-oplossing: De auteurs gebruikten een AI om een simpele webpagina te genereren die zelfs werkt wanneer het internet uitvalt (eenmaal geladen). Het fungeert als een lichtgewicht, draagbare gids die past in een browser-tabblad.
- Het Resultaat: Het was ongelooflijk snel te "leveren" (slechts een link) en werkte zonder een complexe installatie.
Test B: De Webcam-gids
- De Situatie: Een blinde persoon die probeert deel te nemen aan een videogesprek, kan vaak niet zien of hun gezicht in het cameraframe staat. Ze gissen.
- De AI-oplossing: De auteurs bouwden een browsergebaseerde tool die de camera van de computer gebruikt om het gezicht te "zien" en vervolgens de stem van de computer gebruikt om te zeggen: "Beweeg naar links," of "Je staat gecentreerd!"
- De Magie: Deze tool draait volledig binnen de browser. Hij hoeft niet te worden gedownload. Hij gebruikt de ingebouwde "oren" (spraak) en "ogen" (camera) van de browser om real-time audio-instructies te geven.

4. Waarom Dit De "Kaart" Verandert (De ACB)

Het artikel betoogt dat deze AI-aanpak de Toegankelijkheids Capabiliteitsgrens naar buiten duwt. Hier is hoe:

Snelheid (Implementatielatentie): In plaats van dagen te wachten op een software-update, krijg je een nieuwe tool in seconden. Het is als het bestellen van een pizza versus het bouwen van een huis.
Flexibiliteit (Aanpasbaarheid): Als een gebruiker zegt: "Ik heb dit in het Nepalees nodig," of "Ik heb grotere knoppen nodig," kan de AI de tool direct herschrijven. Traditionele software is als een standbeeld; dit is als klei die zichzelf opnieuw vormt.
Offline Kracht: Omdat deze tools gewoon webpagina's zijn, kunnen ze worden opgeslagen om te werken zonder internet (zoals het opslaan van een kaart voordat je signaal verliest).

5. De Harte Muren (De Grenzen)

De auteurs zijn zeer eerlijk: AI heeft niet alles opgelost. Ze identificeren "harde muren" waar deze aanpak tegen een plafond botst:

De "Hallucinatie" Muur: Soms liegt de AI. Het kan een knop bouwen die voor een schermlezer eruitziet als een knop, maar die eigenlijk niet werkt. Het is als een robot die een deur bouwt die leidt naar een bakstenen muur.
De "Sandbox" Muur: Webbrowsers zijn als veilige, omheinde speeltuinen. Ze zijn geweldig voor veiligheid, maar ze laten je niet toe om de diepe, zware machines van de computer aan te raken (zoals het besturen van gespecialiseerde Braille-displays). Als een tool "buiten het speeltuintje" moet gaan, kan de browser dat niet.
De "Verificatie" Muur: We hebben nog geen perfecte robotinspecteur die kan controleren of een door AI gebouwd tool echt toegankelijk is. We hebben nog steeds menselijke ogen nodig om ervoor te zorgen dat de "hellingbaan" veilig is.

6. Het Grote Plaatje

Het artikel concludeert dat AI, hoewel het toegankelijkheid niet heeft "opgelost", wel de economie ervan heeft veranderd.

Vroeger: Toegankelijkheid was duur, traag en vereiste speciale hardware.
Nu: Met AI en browsers kunnen we op bijna geen enkele manier, direct en overal, op maat gemaakte, lichtgewicht tools genereren.

Kortom: Het artikel stelt voor dat we stoppen met het zien van toegankelijkheid als een vaste checklist en beginnen met het bekijken ervan als een dynamische ruimte. Door AI te gebruiken om tools direct binnen webbrowsers te bouwen, kunnen we meer mensen bereiken, sneller, en in moeilijkere situaties (zoals landelijke gebieden met slecht internet) dan ooit tevoren — maar we moeten voorzichtig blijven met de grenzen van wat AI kan bouwen en de veiligheid van die bouwwerken.

Technische Samenvatting: De Toegankelijkheidsvermogensgrens

Probleemstelling

Het ontwerp en de implementatie van toegankelijke digitale systemen hebben historisch gezien vertrouwd op arbeidsintensieve, compliance-gedreven engineering. Ondanks standaarden zoals WCAG en WAI-ARIA blijft het digitale ecosysteem grotendeels ontoegankelijk voor gebruikers met een beperking, met name in contexten met beperkte middelen waar professionele expertise op het gebied van toegankelijkheid schaars is. Hoewel Large Language Models (LLM's) hebben aangetoond dat ze functionele gebruikersinterfaces kunnen synthetiseren vanuit natuurlijke taal, blijven de operationele grenzen en theoretische randvoorwaarden van door AI gegenereerde toegankelijkheidssystemen ongedefinieerd. Bestaand onderzoek behandelt toegankelijkheid vaak als een binair slaag/val-maatstaf of richt zich op de toegankelijkheid van door AI gegenereerde code, zonder een kader om te redeneren over het vermogen van de resulterende systemen in specifieke operationele omgevingen.

Methodologie

Dit artikel introduceert de Toegankelijkheidsvermogensgrens (ACB), een formeel kader dat toegankelijkheid modelleert niet als een binair kenmerk, maar als een dynamische, multidimensionale ruimte van vermogens. De methodologie omvat:

Formele Definitie: De ACB wordt gedefinieerd als de verzameling van alle gebruikers-omgevingparen $(U, E)$ waarvoor een toegankelijkheidssysteem $S$ een nuttreshoud $\theta$ kan bereiken. Het kader maakt gebruik van een Beperkingvector voor Toegankelijkheid ( $\kappa$ ) die bestaat uit acht meetbare variabelen:
- Implementatietraagheid ( $L_d$ )
- Cognitieve Belasting ( $L_c$ )
- Infrastructuuraafhankelijkheid ( $D_i$ )
- Offline Persistentie ( $P_o$ )
- Interactiecomplexiteit ( $C_x$ )
- Aanpasbaarheid ($Ad$)
- Compatibiliteit met Hulpmiddelen ( $A_c$ )
- Dekking van Lokalisatie ( $L_z$ )
Systeemartifactanalyse: Het theoretische kader is gebaseerd op de analyse van twee real-world exploratieve prototypes:
- Probe 1: Een browser-native toegankelijkheidsinterface gegenereerd voor een blinde gebruiker in Nepal, ontworpen om te functioneren met onderbroken connectiviteit en minimale technische ondersteuning.
- Probe 2: Een volledig functionele, open-source webcam-uitlijnassistent voor visueel gehandicapte gebruikers. Dit systeem maakt gebruik van browser-native API's (MediaDevices, Web Speech) en client-side WebAssembly (WASM) computer vision (MediaPipe FaceMesh) om real-time, gesloten-lus audio-instructies te bieden voor camerapositie.
Evaluatieprotocol: Het artikel stelt een exploratief evaluatiekader voor dat geautomatiseerd auditeren (axe-core, Lighthouse), heuristische evaluatie en voorlopige prestatiebenchmarking omvat over verschillende apparaatprofielen (Desktop, Laptop, Mobiel) om traagheid, CPU-gebruik en geheugenvoetafdruk te meten.

Belangrijkste Bijdragen

Het artikel levert vijf primaire bijdragen:

Het ACB-kader: Een formeel, multidimensionaal model voor het redeneren over de operationele grenzen van toegankelijkheidssystemen, dat verder gaat dan binaire compliance naar een gegradueerde ruimte van vermogens.
Meetbare Beperkingen en Propositions: De definitie van de beperkingvector $\kappa$ en formele proposities die suggereren dat door AI gegenereerde browser-native systemen de implementatietraagheid ( $L_d$ ) en infrastructuuraafhankelijkheid ( $D_i$ ) aanzienlijk kunnen verminderen, terwijl ze de aanpasbaarheid ($Ad$) maximaliseren.
Architectuuranalyse: Identificatie van HTML als een "universeel toegankelijkheidssubstraat". Het artikel beschrijft hoe door AI gegenereerde single-file HTML-artifacten standaard browser-API's (Service Workers, Web Speech, MediaDevices) kunnen benutten om offline-capabele, hulpmiddelen-compatibele systemen te creëren zonder installatie.
Systeemimplementatie: Een gedetailleerde analyse van de webcam-uitlijnassistent, die een gesloten-lus toegankelijkheidsinteractiepijplijn demonstreert waarbij ruimtelijke analyse gedebounce audio-instructies aanstuurt, alles lokaal uitgevoerd binnen de browser-sandbox.
Vergelijkende Evaluatiematrix: Een gestructureerde vergelijking van door AI gegenereerde browser-native systemen met Traditionele Hulpmiddelen (AT) en Native Applicaties, waarbij trade-offs in wrijving, aanpasbaarheid en hardware-toegang worden gekwantificeerd.

Resultaten en Bevindingen

De analyse van de exploratieve prototypes en benchmarks levert de volgende bevindingen op:

Implementatie-efficiëntie: Door AI gegenereerde browser-native systemen verminderen de implementatietraagheid drastisch. De webcam-assistent laadt in minder dan 1 seconde op desktops en in minder dan 1,5 seconde op mobiel, met offline laadtijden die dalen tot ~45ms na de initiële Service Worker-cache. Dit valideert de propositie dat $L_d$ de netwerk-RTT benadert, met ordes van grootte lager dan de installatie van traditionele AT.
Infrastructuuronafhankelijkheid: Door gezichtsdetectie en spraaksynthese client-side uit te voeren via WASM en de Web Speech API, reduceert het systeem de infrastructuuraafhankelijkheid ( $D_i$ ) tot bijna nul na de initiële laadbeurt, waardoor functionaliteit mogelijk is in omgevingen met lage connectiviteit.
Aanpasbaarheid: Het systeem toont een hoge aanpasbaarheid ( $Ad \approx 0,90$ ). Interfaces kunnen binnen enkele minuten worden herbouwd om specifieke gebruikersbehoeften aan te passen (bijvoorbeeld taalwijzigingen, andere logica voor instructies), een vermogen dat alleen wordt beperkt door de generatieve capaciteit van LLM's en niet door ontwikkelcycli.
Prestatiebenchmarks: Op smartphones van de lage klasse met gedempte CPU's handhaaft het systeem een gezichtsdetectietraagheid van ~110ms en vertragingen in spraaksynthese van ~45ms, met geheugenvoetafdrukken onder de 70MB.
Verificatiekloven: Hoewel geautomatiseerde audits (axe-core) 100% scores opleverden voor statische structuur, onthulde handmatige testen dat naïeve continue updates van de door AI gegenereerde code de buffers van schermlezers konden overbelasten, wat leidde tot cognitieve overbelasting. Dit vereiste de implementatie van een strikte 4000ms spraak-debounce-venster, wat de kloof benadrukt tussen syntactische geldigheid en semantische bruikbaarheid.

Betekenis en Claims

Het artikel stelt expliciet dat de centrale bijdrage niet de claim is dat AI toegankelijkheid universeel heeft opgelost. In plaats daarvan biedt het een kader voor redeneren over de vermogens en grenzen van door AI gegenereerde systemen.

Theoretische Verschuiving: Het werk stelt een verschuiving voor van het bekijken van toegankelijkheid als een statische compliance-checklist naar het bekijken ervan als een dynamische operationele ruimte (de ACB).
Uitbreiding van de Grens: De auteurs betogen dat door AI gegenereerde, browser-native systemen de "Toegankelijkheidsgrens" uitbreiden door implementatiewrijving tot bijna nul te reduceren en snelle, contextspecifieke aanpassing mogelijk te maken. Dit is bijzonder significant voor het Global Zuiden, waar traditionele AT vaak kostbaar is en moeilijk te onderhouden.
Identificatie van Harde Grenzen: Het artikel identificeert de "harde beperkingen" die de uiterste grenzen van dit paradigma definiëren:
- Browser Sandboxing: Het onvermogen om diepe hardwarefuncties (bijvoorbeeld aangepaste braille-displays) te benaderen zonder native code.
- AI Hallucinatie: Het risico dat LLM's syntactisch geldige maar semantisch incorrecte toegankelijkheidsattributen genereren (bijvoorbeeld onjuiste ARIA-rollen).
- Verificatie: Het huidige gebrek aan geautomatiseerde tools die in staat zijn de functionele toegankelijkheid van dynamische, door AI gegenereerde interfaces te verifiëren.
Onderzoeksagenda: Het artikel sluit af met een schets van een onderzoeksagenda die zich richt op het ontwikkelen van toegankelijkheidsbewuste AI-compiler, lokale LLM-uitvoering voor offline generatie, en formele methoden voor het meten van de ACB-beperkingvector.

Samenvattend stelt het artikel dat door AI gegenereerde browser-native systemen, hoewel ze nog niet alle native hulpmiddelen kunnen vervangen, een paradigmaverschuiving vertegenwoordigen die het vermogen heeft om de drempel voor het creëren van toegankelijke tools drastisch te verlagen, mits de harde beperkingen van verificatie en hardware-toegang worden aangepakt.