Urvalet är 50 Figma-filer från 28 produktteam inom SaaS, handel, fintech, offentlig sektor och edtech. Vi förhandlade läsbehörighet på icke-attributeringsbasis: ingenting i denna artikel identifierar ett varumärke, ett team eller en designer. Filerna valdes för att spegla vad en ingenjör faktiskt skulle ta emot vid överlämning — inte en polerad fallstudie från en portfoliosajt — så vi bad varje team dela filen som den senaste funktionen levererades från, inte den fil de var stoltast över. Tolv av filerna var från team med en dedikerad designsystemspraktik; de övriga 38 var produktnivåfiler som importerade ett systembibliotek eller rullade sina egna komponenter inline.

Vi gick igenom varje fil och letade efter fem tillgänglighetsegenskaper: fokusstatus-design på varje interaktiv komponent, alternativtextanteckningar på varje bild eller icke-dekorativ ikon, läsordningsdokumentation över layouten, rörelseinställningshantering för animerade eller övergångselement, och mörktlägeskontrastspecifikation för alla komponenter som levererades till både ljust och mörkt tema. För varje egenskap fick en fil poängen “dokumenterad” enbart om en kompetent ingenjör kunde implementera designen utan att behöva uppfinna svaret själv. “Nämns i en klistislapp” räknades inte. “Hex specificerat i ett enda hover-tillstånd” räknades inte. Ribban var: är beslutet i filen i en form som ingenjören kan agera på utan att fråga?

Huvudfyndet är att överlämningen, enligt denna ribba, saknar tillgänglighetsbesluten långt oftare än den inkluderar dem. Fokusstatus-design förekom på ca 40% av interaktiva komponenter i korpusen. Alternativtextanteckningar förekom på ungefär 22% av bilderna som behövde dem. Läsordning var explicit dokumenterad i 16% av filerna. Rörelseinställningar behandlades i 10%. Mörktlägeskontrast — för de 31 filerna som levererade båda teman — specificerades för 30% av komponenterna. Gapet finns inte i någon enskild egenskap. Det finns i alla fem, och ingenjören lämnas att stänga dem ett omdöme i taget.

Av de ca 1 800 interaktiva komponenterna i korpusen — knappar, länkar, inmatningsfält, kryssrutor, switchar, flikar, kombofält, menyobjekt, kort-som-knappar, allt en tangentbordsanvändare kan nå — levererade ungefär 40% en designad fokusstatus. De övriga 60% levererade en standardstatus, en aktiv och en hoverstatus, och stannade sedan. Ingenjören som bygger komponenten väljer en fokuskontur vid implementeringstillfället, vanligtvis genom att kopiera webbläsarens standard, vanligtvis utan att kontrollera att standarden har 3:1-kontrast mot komponentens yta i båda de ljusa och mörka teman filen levereras i.

Hur ser “ingen fokusstatus-design” ut i praktiken? Det ser ut som en knappkomponent med tre varianter på duken — vila, hover, nedtryckt — och ingen fjärde variant. Det ser ut som ett inmatningsfält med en stilad kantlinje och ingen andra kantstil för det fokuserade tillståndet. Det ser ut som ett kryssrutaprimitiv med en fokusring enbart på vilovarianten, med ingenjören lämnad att gissa om samma ring ska visas på den markerade eller obestämda varianten. Mönstret upprepas över komponenter, team och sektorer. Det är det enskilt största tillgänglighetsgapet i korpusen och det enskilt lättaste att designa in.

De team som designade fokusstatus väl hade en av två saker som hjälpte dem. Den första var en explicit designsystemsregel: varje interaktiv komponent måste leverera en variant vars namn börjar med focus-, och komponenten släpps inte in i biblioteket förrän den varianten finns. Den andra var en Figma-komponentegenskap kallad state med focus, focus-visible och focus-within som uppräknade värden, så att filens komponentbläddrare synliggör de saknade varianterna visuellt. Team utan någon av dessa två scaffolds lämnade fokusstatusen till ingenjören ungefär nio gånger av tio.

Av filerna i korpusen som inkluderade innehållsbilder — produktfotografi, hjälteillustrationerna, ikonknappar, infografikfigurer — hade 78% inga alternativtextanteckningar på bildlagren. Bilden var placerad, dimensionerad och stilad; den textuella motsvarighet som ingenjören förväntades sätta på det renderade <img>-elementet fanns inte i filen. Åtta av 50 filer hade alternativtext på några bilder men inte alla, vanligtvis med hjälteillustrationens anteckning och innehållsbildernas tomma. Tre filer hade alternativtext på varje bild. Ingenjören, i 47 av 50 filer, förväntades uppfinna alternativtexten — och i praktiken ärvde den ofta från filnamnet, bildtexten eller vilken sträng som passade det visuella rytmet.

Gapet är strukturellt knutet till Figmas bildprimitiv. Det finns ingen inbyggd “alt”-egenskap på en bildfyllning eller ett bildlager; alternativtext måste bäras som ett lagernamn, en kommentar, en klistislapp, ett separat specdokument eller ett plugin-tillagt fält. Inget av dessa bärs genom inspektionspanelen som standard, så ingenjören som läser filen i inspektionsvyn ser inte alternativtexten ens om designern har skrivit den på annan plats. Team som konsekvent stängde gapet använde ett av tre lösningar: plugin-hanterade alternativtextfält på varje bildvariant, en dokumenterad konvention att lagernamnet är alternativtexten, eller ett separat alternativtextkalkylblad kopplat till bildfilnamn som levererades vid sidan av filen.

Ikonknappar var en delbrister inuti detta bristmönster. I 41 av 50 filer hade ikonelement — sökglaset, hamburgermenyn, stäng-X, dela-pilen — ingen anteckning om tillgängligt namn, vilket lämnade ingenjören att skriva aria-label=“Sök” från det visuella sammanhanget utan bekräftelse på att “Sök” var rätt ord i varumärkets röst (var det “Hitta”? var det “Slå upp”? var det ingenting för att knappen öppnar en panel märkt på annat håll?). Ikonnamnsättning är exakt den typ av mikrokopibeslut som gynnas av en designers penna, och exakt den typ som överlämningen förlorar.

De återstående tre egenskaperna hade distinkta bristmönster. Läsordning — ordningen i vilken en skärmläsare berättar sidan, som i moderna responsiva layouter inte längre är garanterad att matcha den visuella uppifrån-och-ned-ordningen — dokumenterades i 16% av filerna. Dokumentationen, där den fanns, var vanligtvis ett numrerat lager på duken (1, 2, 3 …) tillagt med ett plugin. De övriga 84% lämnade ingenjören att mappa läsordningen från den DOM-ordning de råkade skriva, vilket på en CSS Grid-layout med explicit rad-och-kolumnplacering kan avvika från den visuella layouten med en hel kolumn.

Rörelseinställningar klarade sig sämst. Tio procent av filerna nämnde prefers-reduced-motion överhuvudtaget. De återstående 90% specificerade animeringar och övergångar — modalinträden, akkordexpansioner, snackbarsglidningar, sidövergångar — utan att specificera vad samma komponent ska göra när användaren har reducerad rörelse aktiverat. Ingenjören byggde antingen det reducerade-rörelse-fallet vid implementeringstillfället (ofta utan en visuell referens) eller levererade samma animering till alla, vilket är standard och vilket bryter mot 2.3.3 Animation from Interactions för användare som ange inställningen.

Mörktlägeskontrast specificerades för 30% av komponenterna i filer som levererade båda teman. De övriga 70% specificerade kontrastens ljusa tema — vanligtvis med en Stark- eller kontrastredigeringsanteckning i filen — och släppte sedan det mörka temat med en hex-vänd palett, och lämnade ingenjören att kontrollera om det vända paret fortfarande klarade 4,5:1 på brödtext och 3:1 på UI-komponenter. I ungefär en femtedel av de 31 dubbeltema-filerna sjönk minst en komponent under kontrasttröskeln i det mörka temat för att den mörka ytan och den mörka texten båda var inriktade på det ljusa temats kontrastmatematik, inte det mörka temats.

De två pluginer som dyker upp mest i korpusen är Stark och Able. Båda är mogna, båda är väl ansedda, och båda levererar funktioner som stänger flera av de ovan dokumenterade gapen. Stark lägger till en kontrastkontroll, ett fokusordningslager, en förhandsgranskning för reducerad rörelse och ett alternativtextanteckningsfält på bildlager. Able lägger till en färgkontrastinspektion, ett synsimuleringsvisningslager och en berörmålskontroll. Endera plugin, använt konsekvent i en fil, skulle lyfta den filen ur korpusens bottenkvartal.

Använt konsekvent är den avgörande frasen. Av de 50 filerna var Stark installerat och synligen använt i 18, och Able i 11. I de filer där pluginet användes var det vanligtvis på hjältekomponenten och den primära CTA — de komponenter som troligast befinner sig på duken när designern öppnade pluginet — och bara sparsamt på annat håll. Sex filer använde Stark på en global genomgång; en använde Able på en global genomgång. Mönstret är: plugins finns, designers vet om dem, de tas in för punktkontroller, och sedan stannar punktkontrollen vid de komponenter designern råkade titta på när pluginet var öppet.

De två team som stängde granskningen på pluginanvändning gjorde en sak annorlunda: de körde pluginets granskningsfunktion på varje sida av filen som ett releasegatesteg innan filen delades med ingenjörsavdelningen. Granskningen kördes i filen, producerade en rapport, och rapporten behövde vara tom (eller dess undantag dokumenterade) innan filen gick från “under design” till “klar för ingenjör.” Detta är plugin-som-arbetsflöde snarare än plugin-som-punktkontroll, och det är skillnaden mellan 80% täckning och 20% täckning i vårt urval.

Granskningen producerar en checklista och ett kontrakt. Checklistan är vad en designer ska kunna bocka av innan filen delas med ingenjörsavdelningen. Kontraktet är formen på de designtokens som åtföljer filen så att ingenjören mappar Figma-variabler till CSS-egna egenskaper utan att uppfinna mellanliggande värden. Båda är avsiktligt korta: varje punkt i checklistan är en egenskap som granskningen mätte, och varje token i kontraktet är ett värde som stängde ett gap i korpusen.

50-filsgranskningen avslutas med ett enkelt fynd. Överlämningen misslyckas med tillgänglighet inte för att designers inte bryr sig och inte för att ingenjörer inte bryr sig, utan för att filen — Figma-filen, den enda artefakt alla parter läser — inte bär tillgänglighetsbesluten som förstklassiga egenskaper. Fokusstatus, alternativtext, läsordning, rörelseinställningar, mörktlägeskontrast: vart och ett är ett designbeslut, vart och ett hör hemma i filen, vart och ett befinner sig för tillfället på annan plats. I en klistislapp, i ett Slack-meddelande, i ett separat kalkylblad, i ingenjörens huvud fredagen klockan 16.

Lösningen är inte en hjältedesigner eller en hjälteingenjör. Det är en arbetsflödesförändring på teamnivå: varje interaktiv komponent levererar en fokusvariant, varje bild bär alternativtext på en plugin-hanterad plats, läsordning är lagd ovanpå varje icke-trivial sida, animeringar specificerar sin reducerade-rörelse-motsvarighet, mörktlägeskontrast kontrolleras separat från ljus, och filen levereras bredvid ett tokenkontrakt som namnger varje variabel implementeringen binder till. Inget av dessa steg är nytt, inget kräver ett verktyg vi inte redan har, och varje team som antar dem som releasegatesteg stänger det mesta av de gap vi mätte på en enda releasecykel.

Det djupare fyndet är att designsystemsteam redan gör detta ungefär dubbelt så ofta som produktteam. Lyftet som designsystemsteamen ger är exakt det lyft som disciplinen att bygga ett system pålägger: komponenter namnges, egenskaper räknas upp, varianter görs synliga, tokens görs explicita. Att ta med samma disciplin till produktnivåfiler — även utan ett fullständigt designsystem under — stänger det mesta av överlämningsgapet. Det är inte ett verktygsproblem längre. Det är ett arbetsflödesval.