Il campione è composto da 50 file Figma di 28 team di prodotto in ambito SaaS, retail, fintech, settore pubblico ed edtech. L’accesso in sola visualizzazione è stato negoziato su base non attribution: nulla in questo articolo identifica un brand, un team o un designer. I file sono stati scelti per riflettere ciò che un ingegnere riceverebbe effettivamente all’handoff — non uno studio di caso rifinito da un portfolio — quindi a ogni team è stato chiesto di condividere il file da cui è stata consegnata la funzionalità più recente, non il file di cui erano più orgogliosi. Dodici dei file provenivano da team con una pratica dedicata di design system; gli altri 38 erano file a livello di prodotto che importavano una libreria di sistema o gestivano i propri componenti inline.

Ogni file è stato esaminato alla ricerca di cinque proprietà di accessibilità: design dello stato focus su ogni componente interattivo, annotazioni del testo alternativo su ogni immagine o icona non decorativa, documentazione dell’ordine di lettura nel layout, gestione delle preferenze di movimento per qualsiasi elemento animato o in transizione, e specifica del contrasto in dark mode per qualsiasi componente consegnato sia in tema chiaro che scuro. Per ogni proprietà, un file ha ricevuto il punteggio «documentato» solo se un ingegnere competente potesse implementare il design senza dover inventare la risposta autonomamente. «Menzionato in un post-it» non contava. «Colore esadecimale specificato in un singolo stato hover» non contava. Il livello era: la decisione è nel file in una forma su cui l’ingegnere può agire senza chiedere?

Il risultato principale è che l’handoff, secondo questo parametro, manca le decisioni di accessibilità molto più spesso di quanto le includa. Il design dello stato focus è apparso su circa il 40% dei componenti interattivi nel corpus. Le annotazioni del testo alternativo sono apparse su circa il 22% delle immagini che ne avevano bisogno. L’ordine di lettura era esplicitamente documentato nel 16% dei file. Le preferenze di movimento erano affrontate nel 10%. Il contrasto in dark mode — per i 31 file che consegnavano entrambi i temi — era specificato per il 30% dei componenti. Il divario non riguarda una singola proprietà. Riguarda tutte e cinque, e l’ingegnere è lasciato a colmarle un giudizio alla volta.

Degli circa 1.800 componenti interattivi toccati nel corpus — pulsanti, link, input, checkbox, switch, tab, combobox, voci di menu, card-come-pulsante, qualsiasi elemento raggiungibile da un utente da tastiera — circa il 40% consegnava uno stato focus progettato. Il restante 60% consegnava uno stato predefinito, uno attivo e uno hover, e poi si fermava. L’ingegnere che costruisce il componente sceglie un outline di focus al momento dell’implementazione, di solito copiando il default del browser, di solito senza verificare che il default abbia un contrasto 3:1 rispetto alla superficie del componente sia nel tema chiaro che in quello scuro consegnati dal file.

Come appare «nessun design dello stato focus» nella pratica? Appare come un componente pulsante con tre varianti nel canvas — riposo, hover, premuto — e nessuna quarta variante. Appare come un campo input con un bordo stilizzato e nessun secondo stile di bordo per lo stato con focus. Appare come un primitivo checkbox con un anello di focus solo sulla variante di riposo, con l’ingegnere lasciato a indovinare se lo stesso anello debba apparire sulla variante selezionata o indeterminata. Lo schema si ripete tra componenti, tra team, tra settori. È il singolo divario di accessibilità più grande nel corpus e il più semplice da progettare.

I team che hanno progettato bene gli stati focus avevano uno di due elementi a loro favore. Il primo era una regola esplicita del design system: ogni componente interattivo deve consegnare una variante il cui nome inizia con focus-, e il componente non viene rilasciato nella libreria finché quella variante non esiste. Il secondo era una proprietà di componente Figma chiamata state con focus, focus-visible e focus-within come valori enumerati, così che il browser dei componenti del file evidenzi visivamente le varianti mancanti. I team senza uno di questi due scaffold lasciavano lo stato focus all’ingegnere circa nove volte su dieci.

Dei file nel corpus che includevano immagini di contenuto — fotografie di prodotto, illustrazioni hero, pulsanti solo icona, figure infografiche — il 78% non aveva annotazioni del testo alternativo sui livelli immagine. L’immagine era posizionata, dimensionata e stilizzata; l’equivalente testuale che ci si aspettava l’ingegnere inserisse nell’<img> reso non era nel file. Otto dei 50 file avevano il testo alternativo su alcune immagini ma non su tutte, di solito con l’illustrazione hero annotata e le immagini di contenuto nel corpo vuote. Tre file avevano il testo alternativo su ogni immagine. L’ingegnere, in 47 file su 50, era tenuto a inventare il testo alternativo — e nella pratica spesso lo ereditava dal nome del file, dalla didascalia o da qualsiasi stringa si adattasse al ritmo visivo.

Il divario è strutturale al primitivo immagine di Figma. Non esiste una proprietà «alt» nativa su un riempimento immagine o un livello immagine; il testo alternativo deve essere portato come nome del livello, un commento, un post-it, un documento di specifica separato o un campo aggiunto da un plugin. Nessuna di queste opzioni passa attraverso il pannello di ispezione per impostazione predefinita, quindi l’ingegnere che legge il file nella visualizzazione di ispezione non vede il testo alternativo anche se il designer lo ha scritto altrove. I team che hanno colmato il divario in modo coerente utilizzavano uno dei tre approcci: campi di testo alternativo gestiti da plugin su ogni variante immagine, una convenzione documentata secondo cui il nome del livello è il testo alternativo, oppure un foglio di calcolo separato con il testo alternativo indicizzato per nome file che veniva consegnato insieme al file.

I pulsanti solo icona erano un sotto-fallimento all’interno di questo schema. In 41 dei 50 file, i pulsanti icona — la lente di ingrandimento, l’hamburger menu, la X di chiusura, la freccia di condivisione — non avevano alcuna annotazione del nome accessibile, lasciando all’ingegnere il compito di scrivere aria-label=“Cerca” dal contesto visivo senza conferma che «Cerca» fosse la parola giusta nel tono del brand (era «Trova»? era «Ricerca»? era nulla perché il pulsante apre un pannello già etichettato altrove?). La nomenclatura delle icone è esattamente il tipo di decisione redazionale micro che beneficia della penna di un designer, ed esattamente il tipo che l’handoff perde.

Le restanti tre proprietà presentavano forme distinte di fallimento. L’ordine di lettura — l’ordine in cui uno screen reader narrerà la pagina, che nei layout responsive moderni non è più garantito corrispondere all’ordine visivo dall’alto verso il basso — era documentato nel 16% dei file. La documentazione, dove esisteva, era di solito una sovrapposizione numerata nel canvas (1, 2, 3 …) aggiunta con un plugin. L’altro 84% lasciava all’ingegnere la mappatura dell’ordine di lettura dall’ordine DOM che si trovava a scrivere, che su un layout CSS Grid con posizionamento esplicito riga-colonna può divergere dal layout visivo di un’intera colonna.

Le preferenze di movimento hanno avuto i risultati peggiori. Il dieci percento dei file menzionava prefers-reduced-motion tout court. Il restante 90% specificava animazioni e transizioni — entrate modali, espansioni accordion, slide di snackbar, transizioni di pagina — senza specificare cosa avrebbe dovuto fare lo stesso componente quando l’utente ha abilitato il movimento ridotto. L’ingegnere o costruiva il caso di movimento ridotto al momento dell’implementazione (spesso senza un riferimento visivo) o consegnava la stessa animazione a tutti, che è il default e che viola il criterio 2.3.3 Animazione da interazioni per gli utenti che impostano la preferenza.

Il contrasto in dark mode era specificato per il 30% dei componenti nei file che consegnavano entrambi i temi. L’altro 70% specificava il contrasto del tema chiaro — di solito con un’annotazione Stark o di un verificatore di contrasto nel file — e poi rilasciava il tema scuro con una palette con colori invertiti, lasciando all’ingegnere il compito di verificare se la coppia invertita superasse ancora il 4,5:1 per il testo del corpo e il 3:1 per i componenti UI. In circa un quinto dei 31 file dual-theme, almeno un componente scendeva sotto la soglia di contrasto nel tema scuro perché la superficie scura e il testo scuro erano entrambi calibrati per la matematica del contrasto del tema chiaro, non di quello scuro.

I due plugin che compaiono più spesso nel corpus sono Stark e Able. Entrambi sono maturi, entrambi sono ben considerati, ed entrambi offrono funzionalità che colmano diversi dei divari documentati sopra. Stark aggiunge un verificatore di contrasto, una sovrapposizione dell’ordine di focus, un’anteprima del movimento ridotto e un campo di annotazione del testo alternativo sui livelli immagine. Able aggiunge un ispettore del contrasto cromatico, una sovrapposizione di simulazione visiva e un verificatore delle dimensioni dei target di tocco. Entrambi i plugin, usati in modo coerente su un file, porterebbero quel file fuori dal quartile inferiore del corpus.

Usati in modo coerente è la frase operativa. Nei 50 file, Stark era installato e visibilmente usato in 18, e Able in 11. Nei file in cui il plugin era usato, veniva di solito usato sul componente hero e sul CTA principale — i componenti più probabilmente sul canvas quando il designer ha aperto il plugin — e solo sporadicamente altrove. Sei file usavano Stark su un passaggio globale; uno usava Able su un passaggio globale. Lo schema è: i plugin esistono, i designer li conoscono, vengono utilizzati per controlli spot, e poi il controllo spot si ferma ai componenti che il designer stava guardando quando il plugin era aperto.

I due team che hanno chiuso l’audit sull’utilizzo dei plugin hanno fatto una cosa diversa: hanno eseguito la funzionalità di audit del plugin su ogni pagina del file come passaggio di release-gate prima che il file fosse condiviso con l’ingegneria. L’audit girava nel file, produceva un rapporto, e il rapporto doveva essere vuoto (o le sue eccezioni documentate) prima che il file passasse da «in design» a «pronto per l’ingegneria». Questo è il plugin-come-flusso-di-lavoro piuttosto che il plugin-come-controllo-spot, ed è la differenza tra l’80% di copertura e il 20% di copertura nel campione.

L’audit produce una checklist e un contratto. La checklist è ciò che un designer dovrebbe essere in grado di spuntare prima che il file venga condiviso con l’ingegneria. Il contratto è la forma dei design token che accompagnano il file affinché l’ingegnere mappi le variabili Figma sulle custom property CSS senza inventare valori intermedi. Entrambi sono brevi per scelta: ogni voce della checklist è una proprietà misurata dall’audit, e ogni token nel contratto è un valore che ha colmato un divario nel corpus.

L’audit su 50 file si chiude con una semplice osservazione. L’handoff sta fallendo l’accessibilità non perché i designer non si preoccupino e non perché gli ingegneri non si preoccupino, ma perché il file — il file Figma, il singolo artefatto che ogni parte legge — non porta le decisioni di accessibilità come proprietà di primo livello. Stati focus, testo alternativo, ordine di lettura, preferenze di movimento, contrasto in dark mode: ciascuna di esse è una decisione di design, ciascuna appartiene al file, ciascuna si trova attualmente da qualche altra parte. In un post-it, in un messaggio Slack, in un foglio di calcolo separato, nella testa dell’ingegnere alle 16 di un venerdì.

La soluzione non è un designer eroico o un ingegnere eroico. È un cambiamento del flusso di lavoro a livello di team: ogni componente interattivo consegna una variante focus, ogni immagine porta il testo alternativo in un’unica posizione gestita da plugin, l’ordine di lettura viene sovrapposto su qualsiasi pagina non banale, le animazioni specificano la loro controparte con movimento ridotto, il contrasto in dark mode viene verificato separatamente da quello chiaro, e il file viene consegnato insieme a un contratto di token che nomina ogni variabile a cui l’implementazione si associa. Nessuno di questi passaggi è nuovo, nessuno richiede uno strumento che non si abbia già, e qualsiasi team che li adotti come passaggi di release-gate colmerà la maggior parte dei divari misurati in un singolo ciclo di rilascio.

Il risultato più profondo è che i team con design system lo fanno già a circa il doppio del tasso dei team di prodotto. Il contributo che i team con design system forniscono è esattamente il contributo che impone la disciplina di costruire un sistema: i componenti sono nominati, le proprietà sono enumerate, le varianti sono visibili, i token sono espliciti. Portare la stessa disciplina ai file a livello di prodotto — anche senza un design system completo alla base — colma la maggior parte del divario dell’handoff. Non è più un problema di strumenti. È una scelta di flusso di lavoro.