Accessibilità delle Email HTML: Strumenti, Prezzi e Checklist per Sviluppatori

Per un team di sviluppo che vuole controllare ogni tabella e ogni attributo, la scelta più solida è MJML: il markup compilato è tabellare e leggibile, il sorgente resta nel repository e il modello è self-hosted, quindi non risultano piani a pagamento nella pagina prezzi consultata. Per un team che deve verificare anteprime e accessibilità prima dell’invio, il piano Premium di Email on Acid costa 199 US$ al mese e include test di accessibilità e analisi dell’HTML.

Questa guida non stabilisce quale strumento sia il migliore in assoluto. Spiega che cosa cambia, dal punto di vista dell’accessibilità, tra un framework che genera HTML, un editor visuale che lo esporta e una piattaforma di invio che lo rielabora. Ogni sezione parte da una domanda concreta: quale attributo deve esserci, chi lo inserisce e come lo si controlla.

Perché lo strumento decide l’accessibilità

Un’email accessibile è un documento HTML con una struttura che un lettore di schermo può seguire. Il problema è che la maggior parte delle email è ancora costruita con tabelle, perché diversi client di posta interpretano male il CSS moderno. Le tabelle di layout sono necessarie per il rendering, ma senza indicazioni esplicite possono confondere chi ascolta la pagina, perché il lettore annuncia righe e colonne che nel messaggio non hanno alcun significato.

Lo strumento che usi decide quattro cose:

• se le tabelle di layout ricevono automaticamente role="presentation";
• se il campo testo alternativo è obbligatorio o può restare vuoto senza avviso;
• se puoi scegliere il livello dei titoli o se tutti i blocchi di testo diventano paragrafi;
• se l’attributo lang viene esportato nel documento finale.

Non esiste un’impostazione universale. Con un framework controlli il markup riga per riga, ma sei responsabile di ogni scelta. Con un editor visuale guadagni velocità, ma devi ispezionare l’HTML esportato, perché il codice generato non sempre coincide con l’intenzione di chi ha costruito il blocco. Con una piattaforma di invio che importa l’HTML, il controllo va ripetuto dopo l’importazione, non solo prima.

Confronto tra gli strumenti

La tabella seguente mette a confronto i sei strumenti di costruzione più citati per le email e tre fornitori che entrano nel flusso come verifica o come piattaforma di invio. I prezzi sono quelli pubblicati nelle pagine ufficiali dei fornitori, consultate il 7 ottobre 2026. Dove il listino non è pubblicato, la tabella lo dichiara.

Nella tabella, la colonna del prezzo riporta sempre il piano, il costo mensile e il volume a cui il costo si applica. Dove il sito del fornitore non pubblica un importo, la voce indica “prezzo su richiesta”: in questi casi il confronto va fatto con un preventivo, non con una stima.

Quanto costa a diverse dimensioni di lista

Il costo di una piattaforma di invio dipende quasi sempre dalla dimensione della lista o dal numero di profili. Gli strumenti di costruzione, invece, non hanno un costo per contatto: il prezzo è dell’infrastruttura o della licenza, quando esiste. Per questo la tabella seguente confronta le piattaforme a tre soglie realistiche di lista, e indica dove il listino non copre quella soglia.

Il confronto tra i due piani di Email on Acid mostra un dettaglio utile. Il piano Basic costa 99 US$ per 1.000 anteprime, cioè 0,099 US$ a anteprima. Il piano Premium costa 199 US$ per 2.000 anteprime, cioè 0,0995 US$ a anteprima. Il costo unitario è praticamente lo stesso, quindi la scelta tra i due piani non dipende dal risparmio sulle anteprime: dipende dal fatto che ti servano i test di accessibilità e l’analisi dell’HTML.

Per Vero il piano Starter è adatto a un database piccolo con invii regolari. Se il database supera i 5.000 profili, il piano non è più un confronto diretto e va richiesto il preventivo del piano Professional. Per SARE il listino è riferito a 10.000 destinatari: se il tuo database è più piccolo o più grande, la cifra va chiesta al fornitore prima di decidere, perché il selettore cambia il prezzo.

Come scegliere lo strumento in base al problema

La domanda utile non è quale builder sia il più accessibile, ma chi nel tuo team è responsabile dell’HTML finale. Se la risposta è uno sviluppatore, un framework come MJML o Maizzle ti dà il controllo completo sul markup. Se la risposta è un responsabile marketing, un editor visuale riduce i tempi, a condizione che qualcuno ispezioni il codice esportato. Se il codice viene rielaborato da una piattaforma di invio, il test va fatto anche dopo l’importazione.

La tabella seguente riassume le scelte più comuni.

Strumento per strumento

MJML

MJML è un linguaggio a componenti che viene compilato in HTML compatibile con le email. Per l’accessibilità il vantaggio è la trasparenza: il markup finale è tabellare, quindi puoi controllare che ogni tabella di layout abbia role="presentation" e che ogni immagine abbia un testo alternativo. Il limite è che MJML genera tabelle di layout e il controllo degli attributi di accessibilità resta a carico del team. Il modello è self-hosted e la pagina prezzi, su mjml.io/pricing, non indica piani a pagamento. Il costo reale è quindi il tempo di chi mantiene la build e l’infrastruttura su cui gira.

React Email

React Email permette di scrivere le email come componenti React, che vengono poi resi in HTML. Per un team che già lavora in React è il modo più naturale di riutilizzare un blocco di testo, un’immagine con testo alternativo o una lista semantica in più template. Il rischio è che la comodità nasconda le scelte di markup: un componente può produrre una struttura diversa da quella attesa, quindi conviene fissare una serie di controlli sull’HTML renderizzato, non sul sorgente JSX. Non c’è un listino da confrontare nella pagina consultata; il prezzo è su richiesta, e il costo reale è quello dell’hosting e del tempo di sviluppo.

Maizzle

Maizzle è un framework che usa Tailwind per scrivere gli stili e genera CSS in linea durante il build. Per chi conosce già Tailwind la velocità di lavoro è alta e gli stili restano leggibili. Dal punto di vista dell’accessibilità la sfida è nel dettaglio: le classi di utilità non dicono nulla sul significato di un blocco, quindi il titolo di livello 2 e il paragrafo vanno scelti esplicitamente. Le classi moderne non sempre si traducono in stili accettati da tutti i client, perciò il controllo nei client di destinazione resta un passaggio obbligatorio. Il prezzo è su richiesta.

Stripo

Stripo è un editor visuale con blocchi e template, pensato per team marketing che devono produrre molte email senza passare dagli sviluppatori. Il punto di forza è la rapidità con cui una campagna può essere costruita e modificata. Il punto debole, per l’accessibilità, è che l’editor espone scelte visive e non rende sempre evidente la struttura del codice. Prima di ogni invio occorre ispezionare l’HTML esportato: controllare i titoli, il testo alternativo delle immagini, l’ordine dei blocchi e la lingua del documento. Il prezzo è su richiesta.

BEE

BEE è un editor visuale che lavora bene con i template ricorrenti: newsletter settimanali, comunicazioni di servizio, aggiornamenti di prodotto. Quando il template è stabile, puoi fissare una volta per tutte la struttura dei titoli e i blocchi con il testo alternativo obbligatorio, e lasciare il lavoro quotidiano al marketing. Il limite è lo stesso degli altri editor visuali: un blocco non controllato può introdurre un titolo sbagliato o un link senza testo descrittivo. Il prezzo è su richiesta.

Unlayer

Unlayer è pensato per essere incorporato in un’applicazione, così che i tuoi utenti possano costruire le proprie email. Per un prodotto SaaS la responsabilità dell’accessibilità si divide: il fornitore dell’editor definisce i blocchi, ma tu decidi quali blocchi esporre e quali controlli imporre prima del salvataggio. Se il testo alternativo non è obbligatorio nella tua interfaccia, un utente può inviare un’immagine senza descrizione. Il prezzo è su richiesta, e va chiesto insieme alle condizioni di utilizzo dell’editor incorporato.

Email on Acid

Email on Acid non costruisce né invia email: le verifica. Il piano Basic, a 99 US$ al mese, offre 1.000 anteprime al mese su oltre 100 client e dispositivi, con accesso API. Il piano Premium, a 199 US$ al mese, aggiunge 2.000 anteprime, test di accessibilità e analisi dell’HTML. È il piano più utile quando un team ha già un flusso di costruzione e vuole un controllo prima dell’invio. Il limite è che la verifica segnala dove si trova il problema, ma non lo corregge: la correzione resta nel builder o nel framework.

Vero

Vero è una piattaforma di email, push e automazioni basate su eventi. Per un team di e-commerce o di prodotto il piano Starter, a 54 US$ al mese, copre fino a 5.000 profili utente e 10.000 email al mese, con 20.000 messaggi push e 160.000 eventi tracciati al mese. Per l’accessibilità il punto da controllare è il codice che arriva dal builder: se l’HTML viene importato, titoli, testi alternativi e lingua devono sopravvivere all’importazione. Il piano Professional è a preventivo e dipende dai volumi di profili, email, push, eventi e SMS.

SARE

SARE è una piattaforma di invio con prezzi in złoty netti e un selettore basato sul numero di destinatari. Il piano Standard costa 315 PLN netto al mese, Advanced 529 PLN netto e Premium 859 PLN netto, tutti riferiti a un database di 10.000 destinatari. Il sito del fornitore indica anche una prova gratuita. Per chi lavora in Polonia la fatturazione in PLN è un vantaggio concreto. Anche qui l’HTML va testato dopo l’importazione, perché la piattaforma può modificare il markup del template. Il pricing page del fornitore è sul sito di SARE.

Come impostare il flusso di lavoro

Un flusso accessibile non dipende da un singolo controllo finale. Funziona meglio quando ogni fase ha un controllo proprio, e quando il responsabile di ciascuna fase è chiaro. La tabella seguente propone una sequenza che si adatta a un framework o a un editor visuale.

La fase più trascurata è l’invio di prova dopo l’importazione. Se la piattaforma riscrive il markup, il controllo fatto sul file originale non basta: va ripetuto sul messaggio che il destinatario riceverà davvero.

Titoli, testo alternativo e lingua nel codice

Gli elementi più importanti sono anche quelli più facili da sbagliare. Un titolo deve essere un vero elemento di intestazione, con uno stile in linea se serve al client, ma con un livello coerente con la struttura del documento. Ecco un esempio di gerarchia.

<h1 style="font-size: 24px; margin: 0;">Benvenuti nel nuovo servizio</h1>
<p>Breve introduzione al cambiamento.</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Novità</h2>
<p>Descrizione della funzione principale.</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Per iniziare</h2>
<p>Istruzioni passo passo.</p>

Per le tabelle di layout, il ruolo presentazionale evita che il lettore di schermo annunci una navigazione tra righe e colonne che nel messaggio non esiste:

<table role="presentation" width="100%">
  <tr>
    <td>
      Contenuto del layout
    </td>
  </tr>
</table>

Per il testo alternativo, la regola pratica è descrivere la funzione dell’immagine nel messaggio, non il nome del file. Un’immagine di prodotto va descritta per il prodotto. Un’immagine che contiene un’offerta va descritta con il testo dell’offerta. Un divisore decorativo usa alt="": vuoto ma presente, non omesso.

<!-- Immagine informativa: descrivi il contenuto -->
<img src="scarpe.jpg" alt="Scarpe da corsa blu con suola bianca" />

<!-- Immagine decorativa: alt vuoto -->
<img src="divisore.png" alt="" />

<!-- Immagine con testo: includi il testo -->
<img src="banner-saldi.jpg" alt="Sconto del 50% su tutti i prodotti questo weekend" />

Per la lingua, il documento dichiara la propria lingua principale, e i passaggi in un’altra lingua ricevono un attributo dedicato. Il lettore di schermo usa queste informazioni per scegliere la pronuncia corretta.

<html lang="it">
...
<p>Il termine inglese <span lang="en">onboarding</span> indica il percorso di benvenuto.</p>

Migrare un archivio di template

Molti team non partono da zero: hanno un archivio di template costruiti anni fa, spesso con tabelle annidate e stili copiati da un messaggio all’altro. La migrazione conviene farla per famiglie di template, non per singole email. Scegli il template più usato, ricostruiscilo nello strumento scelto mantenendo la struttura originale e confronta l’HTML prodotto con quello vecchio. Se la nuova versione ha più titoli, meno testi alternativi o un ordine diverso dei blocchi, il problema va risolto prima di trasferire gli altri template.

Durante la migrazione annota i blocchi che ripetono gli stessi errori. Un’intestazione costruita come paragrafo in grassetto invece che come titolo, o un pulsante fatto di sola immagine, compaiono di solito in molti template. Correggere il blocco una volta è più efficace che correggere decine di email una per una, e il blocco corretto va poi condiviso con tutta la squadra.

Errori frequenti da evitare

Alcuni errori ricorrono quasi in tutti i progetti. Il primo è affidarsi solo al colore per indicare un errore o un’azione richiesta. Un messaggio “campo obbligatorio” in rosso non è comprensibile per chi non percepisce il colore: serve anche un testo. Il secondo è il link generico, come “clicca qui” ripetuto tre volte nello stesso messaggio. Un lettore di schermo che elenca i link mostra solo quella frase, senza alcun contesto.

Il terzo errore è pensare che un’immagine di sfondo basti. Se il messaggio dipende da un’immagine con il testo dell’offerta, chi ha le immagini disattivate non vede l’offerta. Il testo deve esserci nel corpo dell’email. Il quarto è non controllare i campi che l’utente può modificare: un titolo inserito a mano può saltare un livello o usare un tono che non si adatta al resto del messaggio.

Come scegliere e cosa controllare nel tempo

Scegli lo strumento in base al team, non in base a una lista di funzioni. Se il codice è responsabilità di sviluppatori, prendi un framework e stabilisci una revisione per ogni modifica al markup. Se il marketing deve lavorare da solo, scegli un editor visuale e assegna a una persona la responsabilità di controllare l’HTML esportato prima dell’invio. In entrambi i casi, un test con un lettore di schermo e un’anteprima senza immagini rivela più problemi di qualunque elenco di regole.

I listini cambiano e i limiti dei piani si spostano. Per questo il confronto va rifatto a ogni rinnovo, partendo dalla pagina prezzi ufficiale del fornitore. Le cifre di questo articolo riflettono le pagine consultate il 7 ottobre 2026.

Domande frequenti

MJML rende le email accessibili automaticamente?

No. MJML genera HTML tabellare che puoi controllare, ma l’accessibilità dipende ancora dai contenuti che inserisci: titoli, testi alternativi, link e lingua. Il framework rende il controllo più semplice perché il markup è visibile nel repository e può passare in revisione come qualunque altro codice.

Quale piano di Email on Acid serve per i test di accessibilità?

Il piano Premium, a 199 US$ al mese, include test di accessibilità e analisi dell’HTML oltre a 2.000 anteprime al mese. Il piano Basic, a 99 US$ al mese, copre 1.000 anteprime su oltre 100 client e dispositivi, con accesso API, ma non include i test di accessibilità indicati nella pagina prezzi.

Posso usare un editor visuale senza sviluppatori?

Sì, ma serve una persona che controlli l’HTML esportato. Un editor visuale riduce il lavoro quotidiano, però non garantisce che titoli, testi alternativi e lingua siano corretti in ogni blocco. Il controllo va fatto prima del primo invio di ogni template e dopo ogni modifica strutturale.

Il role="presentation" va messo su tutte le tabelle?

Va messo sulle tabelle usate per il layout. Le tabelle che contengono dati, come un elenco di ordini con colonne e intestazioni, restano tabelle dati e devono avere intestazioni corrette. La distinzione va fatta caso per caso.

Quanto costa il piano SARE se ho un database diverso da 10.000 destinatari?

I prezzi indicati, 315, 529 e 859 PLN netti al mese, sono riferiti al selettore di 10.000 destinatari. Per un database di dimensioni diverse la cifra va chiesta direttamente al fornitore, perché il prezzo cambia con il numero di destinatari.

Serve un test con un lettore di schermo se uso già un builder accessibile?

Sì. Un builder può produrre codice corretto e un messaggio ancora confuso, per esempio con un link generico o con un ordine dei blocchi poco logico. Il test con un lettore di schermo mostra che cosa sente davvero chi ascolta il messaggio, e nessun elenco di regole lo sostituisce.

Il prezzo di Vero cambia con il numero di profili?

Il piano Starter, a 54 US$ al mese, è indicato per fino a 5.000 profili utente e 10.000 email al mese. Oltre questi volumi il piano Professional è a preventivo, perché dipende dalla combinazione di profili, email, push, eventi e SMS.