Da Figma a HTML accessibile: una guida pratica

Risposta rapida: l'accessibilità in un flusso di lavoro Figma-to-HTML non è un'impostazione che si attiva — è una manciata di decisioni specifiche: elementi semantici reali invece di <div> stilizzati, un ordine delle intestazioni che rispecchia la struttura dei contenuti (Figma non ha un concetto nativo di livelli di intestazione), campi dei form etichettati e pulsanti solo icona con nome accessibile, stati di focus visibili, contrasto cromatico sufficiente, e un uso parsimonioso di ARIA — solo dove l'HTML semantico non può esprimere da solo l'interazione. Un output automatizzato copre gran parte del lavoro; un breve passaggio manuale intercetta comunque ciò che un file di design non può portare con sé.

Perché l'accessibilità si perde nella traduzione da Figma a HTML

Un file Figma descrive l'aspetto di un design. Non descrive cosa deve annunciare uno screen reader, quale elemento deve ricevere il focus successivo, o se una coppia di colori è leggibile per chi ha una vista ridotta. Questo divario è il vero motivo per cui l'accessibilità si rompe durante la conversione — non per trascuratezza, ma perché parte di ciò di cui l'accessibilità ha bisogno semplicemente non è un'informazione contenuta in un file di design. Una corrispondenza visiva perfetta al pixel può comunque essere un fallimento di accessibilità se il markup sottostante è fatto di <div> generici senza struttura, senza etichette e senza supporto da tastiera.

La soluzione non è un singolo passaggio automatizzato. È capire quali parti dell'accessibilità un buon convertitore gestisce già correttamente generando struttura reale invece di markup solo visivo, e quali parti richiedono sempre una decisione deliberata — di un designer, di uno sviluppatore, o di entrambi — perché il file di design non porta davvero quell'informazione.

Decisioni di design in Figma che influenzano l'accessibilità

Alcune abitudini comuni in Figma creano problemi di accessibilità a valle, ancora prima che entri in gioco qualunque strumento di conversione:

• Il colore come unico segnale. Un campo obbligatorio del form marcato in rosso, o un pulsante disabilitato che è solo una sfumatura più chiara dello stesso colore — entrambi invisibili a chi non riesce a distinguere quelle tonalità. La distinzione ha bisogno di un secondo segnale (un'icona, un'etichetta, un pattern), non solo di un cambio di colore.
• Testo incorporato nelle immagini. Un titolo esportato come PNG appiattito può sembrare identico a un vero livello di testo, ma non può essere letto da uno screen reader, ridimensionato dal browser o indicizzato da un crawler.
• Nessuno stato di focus visivo progettato. La maggior parte dei set di componenti Figma ha uno stato default, uno hover e a volte uno disabled — uno stato di focus (per gli utenti da tastiera che navigano la pagina con Tab) spesso non viene mai progettato, quindi non c'è nulla che la conversione possa riportare.
• Pulsanti solo icona senza alcun nome accessibile da nessuna parte nel file. Un'icona a forma di cestino che significa "elimina" è ovvia visivamente. Nulla nel livello Figma dice a un convertitore — o a uno screen reader — cosa significhi l'icona, a meno che il livello stesso non abbia un nome significativo.
• Dimensioni delle intestazioni incoerenti. Figma non ha un elemento "Heading 2" come un CMS o un elaboratore di testi — i livelli di testo sono solo testo, stilizzato per sembrare di una certa dimensione. Due intestazioni visivamente simili in frame diversi possono rappresentare livelli completamente diversi nella gerarchia reale dei contenuti.

Nessuna di queste è un bug di conversione. Sono decisioni che devono essere prese da qualche parte nella pipeline, ed è utile saperlo in anticipo invece di dare per scontato che uno strumento le dedurrà da solo.

HTML semantico e landmark

Questa è la parte di accessibilità che un buon convertitore da Figma a codice dovrebbe gestire correttamente per impostazione predefinita: elementi <header>, <nav>, <main>, <article>, <section>, <aside> e <footer> reali, invece di una pagina costruita interamente con <div> senza etichetta. I landmark contano perché sono il modo in cui un utente di screen reader salta direttamente al "contenuto principale" o alla "navigazione" invece di scorrere l'intera pagina linearmente con Tab. Vedi Figma to Semantic HTML per capire come si presenta strutturalmente l'output di MarkupGen, e Is Figma-to-HTML Output SEO-Ready? per la sovrapposizione tra markup semantico e crawlability — i due problemi condividono una causa comune e in gran parte anche la soluzione.

Gerarchia delle intestazioni

Un solo <h1> per pagina, e intestazioni che scendono di livello in ordine — un <h3> dovrebbe stare dentro una sezione che ha già un <h2>, non comparire lì solo perché un livello di testo nel design sembrava avere quella dimensione. Come accennato sopra, Figma non ha un concetto nativo di livelli di intestazione, quindi un livello di testo stilizzato in grande non diventa automaticamente un <h1> — vale la pena verificarlo manualmente indipendentemente da quale strumento abbia generato il markup, perché dipende dalla comprensione della struttura reale dei contenuti, non solo dalla loro dimensione visiva.

Pulsanti contro link

Questo è uno degli errori di accessibilità più comuni nel markup convertito, e la struttura dei componenti di Figma non lo risolve per te: un <button> serve per un'azione sulla pagina corrente (inviare, aprire una modale, eliminare un elemento); un <a href> serve per navigare verso un'altra pagina o vista. Un file di design pieno di forme a pillola stilizzate in modo simile non dà alcuna indicazione su quale sia quale — è una decisione semantica, non visiva, e influisce direttamente sia sul comportamento da tastiera (pulsanti e link rispondono a tasti diversi per impostazione predefinita) sia su ciò che uno screen reader annuncia.

Form ed etichette

Ogni campo ha bisogno di una <label> reale, associata programmaticamente — non di un placeholder che ne faccia le veci. Il testo del placeholder scompare non appena l'utente inizia a digitare, ha notoriamente un contrasto scarso per impostazione predefinita, e non viene letto in modo affidabile da tutti gli screen reader come sostituto di un'etichetta. Se un form deve sembrare privo di etichette per motivi di design, usa un'etichetta visivamente nascosta invece di rimuoverla del tutto dal markup. I messaggi di errore devono essere associati al proprio campo (in genere tramite aria-describedby), non semplicemente posizionati nelle vicinanze segnalando il problema solo con il colore.

Immagini e testo alternativo

Le immagini esportate hanno bisogno di attributi alt significativi, non di stringhe vuote o di un nome di file. Questa è un'area in cui un passaggio manuale è davvero inevitabile: a cosa serve un'immagine di sfondo decorativa, rispetto a cosa deve descrivere una foto di prodotto, non è sempre evidente dal solo frame Figma — il file di design non porta con sé l'intento, solo i pixel. Le immagini puramente decorative dovrebbero avere un alt="" vuoto (così gli screen reader le saltano), mentre le immagini significative hanno bisogno di una descrizione reale di ciò che comunicano, non solo di ciò che mostrano.

Navigazione da tastiera

Ogni elemento interattivo — link, pulsanti, campi dei form — deve essere raggiungibile e utilizzabile usando solo la tastiera, in un ordine che corrisponda all'ordine di lettura visivo. È qui che l'Auto Layout aiuta davvero: poiché la struttura dell'Auto Layout si traduce in un ordine DOM logico invece che in frammenti posizionati in modo assoluto, l'ordine di tabulazione tende a seguire automaticamente l'ordine di lettura, invece di saltare in modo imprevedibile come può accadere con layout liberi e posizionati in modo assoluto.

Stati di focus

Dato che i set di componenti Figma raramente includono uno stato di focus progettato, questa è di solito la lacuna di accessibilità più comune in una pagina convertita: un utente da tastiera naviga con Tab nell'interfaccia e non riesce a capire visivamente dove si trova. Come minimo, non rimuovere il contorno di focus predefinito del browser (outline: none) senza sostituirlo con qualcosa di ugualmente visibile — un errore comune e facile da spedire in produzione, commesso in nome della fedeltà a un design che non lo ha mai previsto.

Contrasto cromatico

Figma ti permette di scegliere due colori qualsiasi, indipendentemente dal fatto che siano leggibili insieme, quindi questo richiede una verifica esplicita e non un'assunzione. Il WCAG AA richiede un contrasto di almeno 4.5:1 per il testo normale e di 3:1 per il testo grande (18px+ in grassetto, o 24px+ regolare) e per componenti UI significativi come icone e bordi degli input. Fai passare le coppie di colori reali del design attraverso un controllo del contrasto prima della conversione — è molto più economico correggere un token in Figma che inseguirlo in giro per il markup generato in seguito.

ARIA — quando aiuta e quando fa davvero danno

La prima regola di ARIA resta quella giusta: nessun ARIA è meglio di un ARIA sbagliato. Un <button> nativo ha già il ruolo corretto, è raggiungibile con il focus e risponde a Invio e Barra spaziatrice per impostazione predefinita — aggiungere role="button" non serve a nulla e rischia di entrare in conflitto con la semantica reale dell'elemento. ARIA si guadagna il suo posto specificamente dove l'HTML semantico non può esprimere da solo l'interazione:

• Usalo: aria-label su un pulsante solo icona senza testo visibile (un'icona a cestino che significa "elimina"), aria-expanded su un toggle che controlla una sezione comprimibile, aria-live="polite" su una regione che si aggiorna senza ricaricare la pagina (un messaggio di validazione del form, un contatore del carrello).
• Non usarlo: aggiungere ruoli ARIA a elementi che hanno già la semantica nativa corretta, ARIA decorativo che duplica ciò che è già visibile e annunciato, o aria-live="assertive" su qualsiasi cosa non sia genuinamente urgente — interrompe l'output dello screen reader ed è facile da usare in eccesso.

Accessibilità responsive

I problemi di accessibilità non restano risolti su tutti i breakpoint solo perché sono stati affrontati a una dimensione. I target di tocco devono restare almeno di circa 44×44px su mobile anche quando i layout si comprimono — un pulsante comodamente cliccabile su desktop può diventare troppo piccolo per essere toccato in modo affidabile una volta che i vincoli di ridimensionamento dell'Auto Layout lo riducono. Il testo deve andare a capo invece di essere tagliato o sovrapporsi a larghezze ridotte, e l'ordine dei contenuti non dovrebbe cambiare in modo confuso tra i breakpoint, rompendo l'ordine di lettura logico da cui dipende uno screen reader.

Errori comuni di accessibilità da Figma a HTML

• Ogni elemento cliccabile convertito in un <div onclick> invece di un vero <button> o <a>.
• Pulsanti solo icona senza aria-label, perché il livello Figma si chiamava semplicemente "Icon 4".
• Il colore come unico modo per comunicare uno stato (errore, disabilitato, selezionato).
• outline: none sugli stati di focus senza mettere nulla di visibile al suo posto.
• Testo del placeholder usato come unica etichetta di un campo del form.
• Immagini decorative a cui viene dato come testo alt il nome del file invece di un alt="" vuoto.
• Livelli di intestazione scelti in base alla dimensione del font nel design invece che alla struttura reale dei contenuti.

Prima / dopo: un pulsante solo icona

Prima — visivamente corretto, non accessibile:

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

Dopo — stesso risultato visivo, davvero utilizzabile:

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

La differenza non è affatto visiva — è un vero elemento <button> (raggiungibile con il focus, utilizzabile da tastiera, annunciato correttamente da uno screen reader), un aria-label che dà all'icona un nome accessibile, e aria-hidden="true" sull'SVG decorativo così non viene annunciato due volte.

Checklist pratica di accessibilità

• Un solo <h1> per pagina; le intestazioni scendono di livello in ordine, non in base alla dimensione del font
• Elementi landmark reali (header, nav, main, footer) presenti
• Ogni azione cliccabile è un <button>; ogni link di navigazione è un <a href>
• Ogni campo del form ha una <label> reale e associata — non solo un placeholder
• Le immagini significative hanno testo alt descrittivo; le immagini decorative hanno alt=""
• Gli stati di focus sono visibili su ogni elemento interattivo
• L'ordine di tabulazione corrisponde all'ordine di lettura visivo
• Il contrasto di testo e componenti UI soddisfa il WCAG AA (4.5:1 / 3:1)
• Il colore non è mai l'unico segnale per uno stato o un significato
• ARIA è usato solo dove l'HTML semantico non può esprimere l'interazione
• I target di tocco restano utilizzabili ai breakpoint mobile
• Il layout va a capo senza tagliare o sovrapporre il testo a larghezze ridotte

Come rivedere il codice generato prima della produzione

L'output di MarkupGen privilegia elementi semantici e una struttura reale delle intestazioni per impostazione predefinita, non come opzione facoltativa, e il fatto che la struttura dell'Auto Layout si traduca in un ordine DOM logico è gran parte di ciò che rende possibile un ordine di tabulazione corretto fin dall'inizio. Il punteggio di qualità IA automatico che ogni export riceve è un primo segnale davvero utile — ma è esplicitamente un punteggio di corrispondenza visiva, che confronta l'anteprima renderizzata con il design originale. Non verifica la correttezza di ARIA, i rapporti di contrasto o il comportamento da tastiera, perché nulla di tutto ciò è visibile in un confronto tra screenshot. Considera la checklist qui sopra come il passaggio manuale che arriva dopo un punteggio visivo alto, non al suo posto — vedi How to Evaluate AI-Generated HTML Before You Ship It per lo stesso principio applicato più in generale alla revisione del codice.

Provalo sul tuo design

Il modo più veloce per capire dove un design ha bisogno di un passaggio di accessibilità è convertirlo e aprire il markup reale. Prova MarkupGen gratis, oppure inizia dalla guida completa alla conversione da Figma a HTML per il flusso di lavoro end-to-end su cui si basa questa guida.