Stikprøven er 50 Figma-filer fra 28 produktteams inden for SaaS, detailhandel, fintech, den offentlige sektor og edtech. Vi forhandlede adgang til at se filer på ikke-attributions­basis: intet i denne artikel identificerer et brand, et team eller en designer. Filerne blev udvalgt til at afspejle, hvad en ingeniør faktisk ville modtage ved overdragelse — ikke et poleret case study fra et portefølje­websted — så vi bad hvert team dele filen, som den seneste feature blev leveret fra, ikke den fil de var stoltest af. Tolv af filerne kom fra teams med en dedikeret design-systempraksis; de øvrige 38 var produkt­niveau­filer, der importerede et system­bibliotek eller rullede deres egne komponenter inline.

Vi gennemgik hver fil med fokus på fem tilgængeligheds­egenskaber: fokustilstand-design på hver interaktiv komponent, alternativ tekst-annotationer på hvert billede eller ikke-dekorativt ikon, læserækkefølge-dokumentation på tværs af layoutet, bevægelses­præference­håndtering for ethvert animeret eller overgående element og mørk-tilstand-kontrastspecifikation for enhver komponent leveret til både lys og mørk tema. For hver egenskab scorede en fil “dokumenteret” kun, hvis en kompetent ingeniør kunne implementere designet uden selv at opfinde svaret. “Nævnt i en sticky note” talte ikke. “Hex specificeret i én hover-tilstand” talte ikke. Standarden var: er beslutningen i filen i en form, ingeniøren kan handle på uden at spørge?

Hovedfundet er, at overdragelsen, efter denne standard, mangler tilgængeligheds­beslutningerne langt oftere end den inkluderer dem. Fokustilstand-design forekom på ca. 40% af interaktive komponenter i korpus’et. Alternativ tekst-annotationer forekom på ca. 22% af de billeder, der havde brug for dem. Læserækkefølge var eksplicit dokumenteret i 16% af filerne. Bevægelses­præferencer var adresseret i 10%. Mørk-tilstand-kontrast — for de 31 filer, der leverede begge temaer — var specificeret for 30% af komponenterne. Gabet sidder ikke i én enkelt egenskab. Det sidder i alle fem, og ingeniøren overlades til at lukke dem ét skøn ad gangen.

Af de ca. 1.800 interaktive komponenter berørt i korpus’et — knapper, links, inputfelter, checkbokse, kontakter, faner, comboboxes, menupunkter, kort-som-knapper, alt en tastaturbruger kan nå — leverede ca. 40% et designet fokustilstand. De øvrige 60% leverede en standard-, en aktiv- og en hover-tilstand og stoppede der. Den ingeniør, der bygger komponenten, vælger en fokuskontur ved implementeringstidspunktet, som regel ved at kopiere browser­standarden, som regel uden at kontrollere, at standarden har 3:1-kontrast mod komponentens flade i begge de lys- og mørke temaer, filen leverer.

Hvordan ser “intet fokustilstand-design” ud i praksis? Det ser ud som en knapkomponent med tre varianter på canvasset — hvile, hover, trykket — og ingen fjerde variant. Det ser ud som et inputfelt med en stilet kant og ingen anden kantstil for fokus­tilstanden. Det ser ud som et checkbox-primitiv med en fokusring kun på hvile-varianten, hvor ingeniøren overlades til at gætte, om den samme ring skal vises på den markerede eller den ubestemte variant. Mønsteret gentager sig på tværs af komponenter, teams og sektorer. Det er det største enkelt­tilgængeligheds­gab i korpus’et og det letteste at designe ind.

De teams, der designede fokus­tilstande godt, havde én af to ting med sig. Det første var en eksplicit design-systemregel: enhver interaktiv komponent skal levere en variant, hvis navn starter med focus-, og komponenten frigives ikke i biblioteket, inden den variant eksisterer. Det andet var en Figma-komponent­egenskab kaldet state med focus, focus-visible og focus-within som oplistede værdier, så filens komponent­browser synliggør de manglende varianter. Teams uden én af de to stillads­strukturer overlod fokus­tilstanden til ingeniøren ca. ni gange ud af ti.

Af filerne i korpus’et, der indeholdt indholdsbilleder — produktfoto, hero-illustrationer, ikon-only-knapper, infografik­figurer — havde 78% ingen alternativ tekst-annotationer på billedlagene. Billedet var placeret, størrelsessat og stilet; den tekstmæssige ækvivalent, som ingeniøren forventedes at sætte på det renderede <img>, var ikke i filen. Otte af de 50 filer havde alternativ tekst på nogle billeder men ikke alle, normalt med hero-illustrationen annoteret og indholds­billederne i brødteksten tomme. Tre filer havde alternativ tekst på hvert billede. Ingeniøren, i 47 ud af 50 filer, forventedes at opfinde alternativ teksten — og arvede i praksis den ofte fra filnavnet, figcaption’en eller en hvilken som helst streng, der passede den visuelle rytme.

Gabet er strukturelt betinget af Figmas billede­primitiv. Der er ingen native “alt”-egenskab på en billedfyldning eller et billedlag; alternativ tekst skal bæres som et lagnavn, en kommentar, en sticky note, et separat specifikations­dokument eller et plugin-tilføjet felt. Ingen af disse bæres gennem inspektions­panelet som standard, så den ingeniør, der læser filen i inspektions­visningen, ikke ser alternativ teksten, selv om designeren har skrevet den et andet sted. Teams, der konsekvent lukkede gabet, brugte én af tre løsninger: plugin-styrede alternativ tekst-felter på enhver billedvariant, en dokumenteret konvention om at lagnavnet er alternativ teksten, eller et separat alternativ tekst-regneark nøglet til billedfilnavne, der fulgte med filen.

Ikon-only-knapper var en delfejl inden for denne fejltilstand. I 41 ud af 50 filer havde ikonknapper — søge­luppen, hamburger-menuen, luk-X’et, dele-pilen — ingen tilgængeligt-navn-annotation, der overlod ingeniøren til at skrive aria-label=“Søg” ud fra den visuelle kontekst uden bekræftelse af, at “Søg” var det rette ord i brandets stemme (var det “Find”? var det “Opslag”? var det ingenting, fordi knappen åbner et panel, der er mærket et andet sted?). Ikon­navngivning er præcis den slags mikrotekst­beslutning, der har gavn af en designers pen, og præcis den slags, overdragelsen mister.

De resterende tre egenskaber havde distinkte fejlformer. Læserækkefølge — den rækkefølge, hvori en skærmlæser vil fortælle siden, som i moderne responsive layouts ikke længere er garanteret at svare til den visuelle top-til-bund-rækkefølge — var dokumenteret i 16% af filerne. Dokumentationen, hvor den fandtes, var normalt et nummereret overlay på canvasset (1, 2, 3 …) tilføjet med et plugin. De øvrige 84% overlod ingeniøren til at mappe læserækkefølgen fra den DOM-rækkefølge, de tilfældigvis skrev, som på et CSS Grid-layout med eksplicit række-og-kolonne-placering kan afvige fra det visuelle layout med en hel kolonne.

Bevægelses­præferencer klarede sig dårligst. Ti procent af filerne nævnte prefers-reduced-motion overhovedet. De resterende 90% specificerede animationer og overgange — modal-indgange, accordion-udvidelser, snackbar-slides, side­overgange — uden at specificere, hvad den samme komponent skal gøre, når brugeren har reduceret bevægelse aktiveret. Ingeniøren byggede enten det reducerede bevægelses­tilfælde ved implementeringstidspunktet (ofte uden en visuel reference) eller leverede den samme animation til alle, hvilket er standarden og som overtræder 2.3.3 Animation from Interactions for brugere, der har indstillet præferencen.

Mørk-tilstand-kontrast var specificeret for 30% af komponenterne i filer, der leverede begge temaer. De øvrige 70% specificerede lys-tema-kontrasten — normalt med en Stark- eller kontrasttjekker-annotation i filen — og udgav derefter det mørke tema med en hex-vendt palette, der overlod ingeniøren til at kontrollere, om det vendte par stadig oversteg 4,5:1 på brødtekst og 3:1 på UI-komponenter. I ca. en femtedel af de 31 temaer med to udgaver faldt mindst én komponent under kontrasttærsklen i det mørke tema, fordi den mørke flade og den mørke tekst begge var tunet til lys-temaets kontrastregning, ikke det mørke temas.

De to plugins, der oftest dukker op i korpus’et, er Stark og Able. Begge er modne, begge er velrenommerede, og begge leverer funktioner, der lukker flere af de ovennævnte gab. Stark tilføjer en kontrasttjekker, et fokus­rækkefølge­overlay, en reduceret bevægelses­forhånds­visning og et alternativ tekst-annotationsfelt på billedlag. Able tilføjer en farve­kontrast­inspektor, et syns­simulerings­overlay og en berørings­mål­tjekker. Ethvert af pluginsene, brugt konsekvent i en fil, ville løfte den fil ud af det nederste kvartil i korpus’et.

Brugt konsekvent er den operative frase. På tværs af de 50 filer var Stark installeret og synligt brugt i 18, og Able i 11. I de filer, hvor pluginet var brugt, blev det normalt brugt på hero-komponenten og den primære CTA — de komponenter, der sandsynligvis var på canvasset, da designeren åbnede pluginet — og kun sparsomt andetsteds. Seks filer brugte Stark i en global gennemgang; én brugte Able i en global gennemgang. Mønsteret er: plugins eksisterer, designere kender til dem, de hentes frem til spot-checks, og spot-checket stopper ved de komponenter, designeren tilfældigvis kiggede på, da pluginet var åbent.

De to teams, der lukkede auditen på plugin­brug, gjorde én ting anderledes: de kørte pluginets audit-funktion på hver side af filen som et release-gate-trin, inden filen blev delt med engineering. Auditen kørte i filen, producerede en rapport, og rapporten skulle være tom (eller dens undtagelser dokumenterede), inden filen gik fra “under design” til “klar til engineering”. Dette er plugin-som-workflow frem for plugin-som-spot-check, og det er forskellen mellem 80% dækning og 20% dækning i vores stikprøve.

Auditen producerer en tjekliste og en kontrakt. Tjeklisten er, hvad en designer skal kunne sætte kryds ved, inden filen deles med engineering. Kontrakten er formen på de design-tokens, der følger med filen, så ingeniøren mapper Figma-variabler til CSS custom properties uden at opfinde mellemliggende værdier. Begge er korte med vilje: hvert punkt på tjeklisten er en egenskab, auditen målte, og hvert token i kontrakten er en værdi, der lukkede et gab i korpus’et.

50-fil-auditen slutter med et simpelt fund. Overdragelsen svigter tilgængelighed — ikke fordi designere ikke bekymrer sig, og ikke fordi ingeniører ikke bekymrer sig — men fordi filen, Figma-filen, det eneste artefakt, alle parter læser, ikke bærer tilgængeligheds­beslutningerne som første­klasses egenskaber. Fokus­tilstande, alternativ tekst, læserækkefølge, bevægelses­præferencer, mørk-tilstand-kontrast: hver af dem er en designbeslutning, hver hører hjemme i filen, og hver befinder sig i øjeblikket et andet sted. I en sticky note, i en Slack-besked, i et separat regneark, i ingeniørens hoved fredag klokken 16.

Rettelsen er ikke en heroisk designer eller en heroisk ingeniør. Det er en workflow-ændring på team­niveau: enhver interaktiv komponent leverer en fokusvariant, hvert billede bærer alternativ tekst ét plugin-styret sted, læserækkefølge lægges over på alle ikke-trivielle sider, animationer specificerer deres reducerede-bevægelses-modpart, mørk-tilstand-kontrast kontrolleres separat fra lys, og filen leveres med en token-kontrakt, der navngiver alle variabler, implementeringen binder til. Ingen af disse trin er nye, ingen kræver et værktøj, vi ikke allerede har, og ethvert team, der vedtager dem som release-gate-trin, vil lukke de fleste af de gab, vi målte, i ét release­cyklus.

Det dybere fund er, at design-systemteams allerede gør dette med ca. dobbelt så høj rate som produktteams. Det løft, design-systemteamene giver, er præcis det løft, disciplinen i at bygge et system pålægger: komponenter navngives, egenskaber opregnes, varianter gøres synlige, tokens gøres eksplicitte. At bringe den samme disciplin til produkt­niveau­filer — selv uden et fuldt design­system nedenunder — lukker størstedelen af overdragelses­gabet. Det er ikke længere et værktøjsproblem. Det er et workflow-valg.