Het steekproefkader bestaat uit 50 Figma-bestanden van 28 productteams in SaaS, retail, fintech, publieke sector en edtech. We onderhandelden over alleen-lezen toegang op niet-attributiebasis: niets in dit artikel identificeert een merk, een team of een designer. De bestanden werden gekozen om te weerspiegelen wat een engineer daadwerkelijk zou ontvangen bij overdracht — geen uitgewerkt portfoliostuk — zodat we elk team vroegen het bestand te delen waaruit de meest recente feature was gebouwd, niet het bestand waar ze het meest trots op zijn. Twaalf van de bestanden kwamen van teams met een dedicated design-systeem-praktijk; de andere 38 waren product-level bestanden die een systeembibliotheek importeerden of hun eigen componenten inline uitrolden.

We doorliepen elk bestand op zoek naar vijf toegankelijkheidseigenschappen: focusstatusontwerp op elk interactief component, alternatieve-tekstannotaties op elk afbeelding of niet-decoratief icoon, documentatie van de leesvolgorde over de volledige lay-out, afhandelingsspecificaties voor bewegingsvoorkeur bij elk geanimeerd of overgaand element, en contrastspecificatie voor de donkere modus bij elk component dat in zowel licht als donker thema is uitgebracht. Een bestand scoorde een eigenschap als “gedocumenteerd” uitsluitend als een competente engineer het ontwerp kon implementeren zonder het antwoord zelf te moeten bedenken. “Vermeld in een plaknotitie” telde niet. “Hex opgegeven in één hoverstate” telde niet. De lat was: is de beslissing in het bestand opgenomen in een vorm die de engineer direct kan gebruiken zonder te hoeven vragen?

De hoofdbevinding is dat de overdracht, gemeten aan deze lat, de toegankelijkheidsbeslissingen veel vaker mist dan omvat. Focusstatusontwerp verscheen op ca. 40% van de interactieve componenten in het corpus. Alternatieve-tekstannotaties verschenen op circa 22% van de afbeeldingen die ze nodig hadden. Leesvolgorde was expliciet gedocumenteerd in 16% van de bestanden. Bewegingsvoorkeuren werden behandeld in 10%. Donkere-moduscontrast — voor de 31 bestanden die beide thema’s leverden — was gespecificeerd voor 30% van de componenten. Het gat zit niet in één eigenschap. Het zit in alle vijf, en de engineer wordt overgelaten om ze één oordeel tegelijk te sluiten.

Van de circa 1.800 interactieve componenten die over het corpus werden aangeraakt — knoppen, koppelingen, invoervelden, selectievakjes, schakelaars, tabbladen, comboboxen, menu-items, kaarten-als-knop, alles wat een toetsenbordgebruiker kan bereiken — leverde circa 40% een ontworpen focusstatus. De andere 60% leverde een standaard-, een actieve en een hoverstatus, en stopte daarna. De engineer die het component bouwt, kiest een focusomtrek bij de implementatie, doorgaans door de browserstandaard te kopiëren, doorgaans zonder te controleren of de standaard 3:1 contrast heeft ten opzichte van het componentoppervlak in zowel het lichte als het donkere thema dat het bestand levert.

Hoe ziet “geen focusstatusontwerp” er in de praktijk uit? Het ziet eruit als een knopcomponent met drie varianten op het canvas — rust, hover, ingedrukt — en geen vierde variant. Het ziet eruit als een invoerveld met een gestylede rand en geen tweede randstijl voor de gefocuste staat. Het ziet eruit als een selectievakjeprimitive met een focusring alleen op de rustvariant, waarbij de engineer mag raden of dezelfde ring op de aangevinkte of onbepaalde variant moet verschijnen. Het patroon herhaalt zich over componenten, over teams, over sectoren heen. Het is het grootste single toegankelijkheidsgat in het corpus en het gemakkelijkst te ontwerpen.

De teams die focusstatussen goed hadden ontworpen, hadden één van twee dingen te hun voordeel. Het eerste was een expliciete design-systeemregel: elk interactief component moet een variant leveren waarvan de naam begint met focus-, en het component wordt pas in de bibliotheek uitgebracht als die variant bestaat. Het tweede was een Figma-componenteigenschap genaamd state met focus, focus-visible en focus-within als opgesomde waarden, zodat de componentbrowser van het bestand ontbrekende varianten visueel zichtbaar maakt. Teams zonder een van die twee steigers lieten de focusstatus voor de engineer in circa negen van de tien gevallen.

Van de bestanden in het corpus die inhoudsafbeeldingen bevatten — productfotografie, herohero-illustraties, pictogram-alleen-knoppen, infografische figuren — had 78% geen alternatieve-tekstannotaties op de afbeeldingslagen. De afbeelding was geplaatst, geschaald en gestyleerd; het tekstequivalent dat de engineer geacht werd op de gerenderde <img> te zetten, was niet in het bestand. Acht van de 50 bestanden hadden alternatieve tekst op sommige afbeeldingen maar niet alle, doorgaans met de herohero-illustratie geannoteerd en de hoofdtekstafbeeldingen leeg. Drie bestanden hadden alternatieve tekst op elke afbeelding. De engineer werd, in 47 van de 50 bestanden, geacht de alternatieve tekst zelf te bedenken — en in de praktijk ontleende men die vaak aan de bestandsnaam, het onderschrift of een tekst die bij het visuele ritme paste.

Het gat zit structureel in Figma’s afbeeldingsprimitive. Er is geen native “alt”-eigenschap op een afbeeldingsvulling of afbeeldingslaag; alternatieve tekst moet worden gedragen als laagjaam, commentaar, plaknotitie, een apart specificatiedocument of een door een plugin toegevoegd veld. Geen van deze opties verschijnt standaard in het inspectiepaneel, zodat de engineer die het bestand in de inspectiemodus leest, de alternatieve tekst niet ziet, zelfs als de designer die ergens anders heeft ingetypt. Teams die het gat consequent sloten, gebruikten een van drie omwegen: door plugins beheerde alternatieve-tekstvelden op elke afbeeldingsvariant, een gedocumenteerde conventie dat de laagjaam de alternatieve tekst is, of een apart spreadsheet met alternatieve tekst dat werd opgestuurd naast het bestand.

Pictogram-alleen-knoppen waren een deeltekortkoming binnen dit faalpatroon. In 41 van de 50 bestanden hadden pictogramknoppen — de zoekglas, het hamburgermenu, het sluit-X, de deelpijl — geen toegankelijk-naamannotatie, waardoor de engineer aria-label=“Zoeken” moest schrijven vanuit visuele context zonder bevestiging dat “Zoeken” het juiste woord was in de merkstijl (was het “Vinden”? was het “Opzoeken”? was het niets omdat de knop een elders gelabeld paneel opent?). Pictogrambenaming is precies het soort micro-copy-beslissing dat baat heeft bij een designers pen, en precies het soort dat de overdracht verliest.

De resterende drie eigenschappen hadden afzonderlijke faalpatronen. Leesvolgorde — de volgorde waarin een schermlezer de pagina voorleest, die in moderne responsieve lay-outs niet langer gegarandeerd overeenkomt met de visuele volgorde van boven naar beneden — was gedocumenteerd in 16% van de bestanden. De documentatie, waar aanwezig, was doorgaans een genummerde overlay op het canvas (1, 2, 3…) toegevoegd met een plugin. De andere 84% liet de engineer de leesvolgorde afleiden uit de DOM-volgorde die zij toevallig schreven, die bij een CSS Grid-lay-out met expliciete rij-en-kolomplaatsing een volledige kolom kan afwijken van de visuele lay-out.

Bewegingsvoorkeuren scoorden het slechtst. Tien procent van de bestanden noemde prefers-reduced-motion überhaupt. De resterende 90% specificeerde animaties en overgangen — modaalvenster-intrede, accordeon-uitklappers, snackbar-schuiven, paginaovergangen — zonder te specificeren wat hetzelfde component zou moeten doen wanneer de gebruiker verminderde beweging heeft ingeschakeld. De engineer bouwde de verminderd-beweging-case bij de implementatie (vaak zonder visuele referentie) of leverde dezelfde animatie aan iedereen, wat de standaard is en wat WCAG 2.3.3 Animatie door interacties schendt voor gebruikers die de voorkeur hebben ingesteld.

Donkere-moduscontrast was gespecificeerd voor 30% van de componenten in bestanden die beide thema’s leverden. De andere 70% specificeerde het lichte-thema-contrast — doorgaans met een Stark- of contrastcontrolaannotatie in het bestand — en bracht vervolgens het donkere thema uit met een hex-gespiegeld palet, waarbij de engineer moest controleren of het gespiegelde paar nog steeds 4,5:1 haalde op hoofdtekst en 3:1 op UI-componenten. In circa één vijfde van de 31 dual-thema-bestanden daalde minstens één component onder de contrastdrempel in het donkere thema, omdat zowel het donkere oppervlak als de donkere tekst waren afgesteld op de contrastmathematiek van het lichte thema, niet die van het donkere thema.

De twee plugins die het vaakst opduiken in het corpus zijn Stark en Able. Beide zijn volwassen, beide zijn goed aangeschreven en beide leveren functies die meerdere hierboven beschreven gaten sluiten. Stark voegt een contrastcontrole, een focusvolgorde-overlay, een verminderd-beweging-preview en een alternatieve-tekst-annotatieveld op afbeeldingslagen toe. Able voegt een kleurcontrastinspecteur, een visiesimulatie-overlay en een aanraakdoelcontrole toe. Elke plugin, consequent gebruikt over een bestand, zou dat bestand uit het onderste kwartiel van het corpus tillen.

Consequent gebruikt is de operatieve uitdrukking. Over de 50 bestanden was Stark geïnstalleerd en zichtbaar gebruikt in 18, en Able in 11. In de bestanden waar de plugin werd gebruikt, werd hij doorgaans gebruikt op het herocomponent en de primaire call-to-action — de componenten die het meest waarschijnlijk op het canvas staan wanneer de designer de plugin opende — en spaarzaam elders. Zes bestanden gebruikten Stark voor een globale doorloop; één gebruikte Able voor een globale doorloop. Het patroon is: plugins bestaan, designers weten ervan, ze worden gebruikt voor steekproeven, en dan stopt de steekproef bij de componenten die de designer toevallig bekeek toen de plugin open was.

De twee teams die de audit op plugingebruik sloten, deden één ding anders: ze voerden de auditfunctie van de plugin op elke pagina van het bestand uit als een release-gate stap voordat het bestand werd gedeeld met engineering. De audit liep in het bestand, produceerde een rapport en het rapport moest leeg zijn (of de uitzonderingen ervan gedocumenteerd) voordat het bestand van “in ontwerp” naar “gereed voor engineering” ging. Dit is plugin-als-workflow in plaats van plugin-als-steekproef, en het is het verschil tussen 80% dekking en 20% dekking in onze steekproef.

De audit levert een controlelijst en een contract op. De controlelijst is wat een designer moet kunnen afvinken voordat het bestand wordt gedeeld met engineering. Het contract is de vorm van de ontwerptokens die naast het bestand worden meegeleverd, zodat de engineer Figma-variabelen kan koppelen aan CSS-aangepaste eigenschappen zonder tussenliggende waarden te hoeven uitvinden. Beide zijn bewust kort: elk item op de controlelijst is een eigenschap die de audit heeft gemeten, en elk token in het contract is een waarde die een gat in het corpus heeft gesloten.

De audit van 50 bestanden sluit met een eenvoudige bevinding. De overdracht faalt op toegankelijkheid niet omdat designers er niets om geven en niet omdat engineers er niets om geven, maar omdat het bestand — het Figma-bestand, het enige artefact dat alle partijen lezen — de toegankelijkheidsbeslissingen niet als eersteklas eigenschappen draagt. Focusstatussen, alternatieve tekst, leesvolgorde, bewegingsvoorkeuren, donkere-moduscontrast: elk is een ontwerpbeslissing, elk hoort in het bestand, elk bevindt zich momenteel ergens anders. In een plaknotitie, in een Slack-bericht, in een apart spreadsheet, in het hoofd van de engineer op vrijdagmiddag om 16.00 uur.

De oplossing is geen heldhaftige designer of heldhaftige engineer. Het is een workflowwijziging op teamniveau: elk interactief component levert een focusvariant, elke afbeelding draagt alternatieve tekst op één door plugins beheerde locatie, leesvolgorde wordt als overlay aangebracht op elke niet-triviale pagina, animaties specificeren hun verminderd-beweging-equivalent, donkere-moduscontrast wordt apart van het lichte gecontroleerd, en het bestand wordt geleverd naast een tokencontract dat elke variabele benoemt waaraan de implementatie wordt gekoppeld. Geen van deze stappen is nieuw, geen vereist een tool die we nog niet hebben, en elk team dat ze als release-gate stappen hanteert, zal de meeste gemeten gaten in één releasecyclus sluiten.

De diepere bevinding is dat design-systeemteams dit al doen op ruwweg tweemaal de frequentie van productteams. De lift die de design-systeemteams leveren, is precies de lift die de discipline van het bouwen van een systeem oplegt: componenten zijn benoemd, eigenschappen zijn opgesomd, varianten zijn zichtbaar, tokens zijn expliciet. Dezelfde discipline toepassen op product-level bestanden — zelfs zonder een volledig design-systeem eronder — sluit het grootste deel van het overdrachtskloof. Het is geen toolingprobleem meer. Het is een workflowkeuze.