WCAG 1.4.9: Immagini di testo (nessuna eccezione)

Cosa Significa Questa Regola

WCAG 1.4.9 — Immagini di testo (Nessuna eccezione) è un criterio di livello AAA che porta alle estreme conseguenze i requisiti di WCAG 1.4.5 (Immagini di testo, livello AA). Mentre 1.4.5 consente immagini di testo quando l’immagine è personalizzabile visivamente o quando una specifica presentazione visiva è essenziale, 1.4.9 elimina quasi tutte queste eccezioni. In base a questo criterio, il testo deve essere reso usando vero testo — caratteri reali nel DOM — invece che come immagini raster o vettoriali contenenti testo.

L’unica eccezione consentita in 1.4.9 riguarda il testo puramente decorativo (che non ha alcun valore informativo) o il testo che fa parte di un logo o di un nome di marca in cui il trattamento visivo specifico è inseparabile dall’identità trasmessa. In pratica, ciò significa che screenshot di prodotti contenenti testo, grafiche di banner con copy promozionale, infografiche con dati etichettati, immagini di certificati, card in stile social media con citazioni e documenti scansionati mostrati sul web devono tutti essere sostituiti con, o almeno integrati da, vero testo renderizzato.

Un superamento del criterio 1.4.9 si verifica quando ogni porzione di testo significativo visibile all’utente è resa dal motore di testo del browser — tramite nodi di testo HTML, contenuto generato da CSS dove appropriato o elementi SVG <text> — in modo che l’user agent possa rifluire, ridimensionare, ricolorare e riposizionare il testo. Un fallimento si verifica ogni volta che un <img>, <canvas>, un’immagine di sfondo CSS, un SVG <image>, un PDF incorporato o qualsiasi altra risorsa non testuale viene usata per mostrare testo che ha significato, indipendentemente dal fatto che sia fornito un attributo alt. Si noti che un attributo alt ben scritto soddisfa il criterio 1.1.1 (Contenuti non testuali) ma non soddisfa 1.4.9, perché il testo alternativo non è reso visivamente e l’immagine originale continua a negare agli utenti vedenti la possibilità di adattare la presentazione visiva del testo.

Il criterio riguarda i seguenti pattern HTML comuni: elementi <img> i cui file sorgente contengono testo; proprietà CSS background-image che puntano a immagini con testo incorporato; elementi <canvas> sui quali il testo è stato disegnato via codice; elementi SVG inline che usano <image> invece di <text>; e contenuti incorporati di terze parti come iframe che contengono immagini renderizzate. Anche formati tecnicamente scalabili come SVG sono soggetti a verifica quando il testo è incorporato come tracciato o immagine invece che come nodo SVG <text>.

Perché È Importante

Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva. Una parte significativa di queste persone — incluse persone con ipovisione, deficit della visione dei colori, dislessia e altre disabilità legate alla lettura — si affida a strumenti di personalizzazione del testo a livello di browser o di sistema operativo per rendere i contenuti leggibili. Questi strumenti includono funzioni di zoom, sostituzione dei font, aumento della spaziatura tra lettere e parole, combinazioni di colori ad alto contrasto o personalizzate e motori text-to-speech che operano sul testo DOM renderizzato. Quando il testo è incorporato all’interno di un’immagine, ognuna di queste possibilità di adattamento diventa indisponibile per quel contenuto.

Si consideri un utente con ipovisione che ha impostato il proprio browser per rendere il testo con un grande font sans-serif e colori ad alto contrasto giallo su nero. Quando incontra un banner promozionale che riporta “Summer Sale — 50% Off” incorporato in un JPEG, il browser non può ricolorare o rifluire quel testo. L’immagine può ingrandirsi con lo zoom della pagina, ma diventa rapidamente pixelata e più difficile da leggere invece che più chiara. Se lo stesso messaggio fosse reso come vero testo HTML stilizzato con CSS, le preferenze del browser dell’utente si applicherebbero automaticamente e il contenuto resterebbe nitido, regolabile e accessibile.

Le persone con dislessia installano spesso estensioni del browser o applicano fogli di stile personalizzati che sostituiscono i font con caratteri adatti alla dislessia come OpenDyslexic e aumentano la spaziatura tra caratteri e parole per ridurre l’affollamento visivo. Le immagini di testo aggirano completamente questi adattamenti. Un pulsante di call-to-action reso come immagine invece che come elemento HTML stilizzato è di fatto invisibile a queste personalizzazioni, potenzialmente nascondendo elementi interattivi critici a utenti che dipendono da una resa personalizzata.

Le persone con disabilità motorie che si affidano a sistemi di accesso a scansione o software di eye-tracking possono usare in modo intensivo gli strumenti di zoom per colpire con precisione i bersagli. Immagini di testo sfocate e a bassa risoluzione a livelli di zoom elevati creano ulteriori difficoltà di puntamento. Gli utenti di screen reader che hanno ancora un residuo visivo ma usano comunque un lettore di schermo per la comprensione possono anche scoprire che le immagini di testo vengono annunciate in modo incoerente a seconda che l’autore si sia ricordato o meno di scrivere un attributo alt completo — e anche un testo alt perfetto non ripristina la presentazione visiva di cui hanno bisogno.

Oltre all’accesso per le persone con disabilità, usare vero testo invece di immagini di testo comporta benefici significativi per la SEO. I crawler dei motori di ricerca indicizzano il testo nel DOM in modo molto più affidabile di quanto possano interpretare il contenuto delle immagini, il che significa che titoli promozionali, nomi di prodotti ed etichette di categoria incorporati nelle immagini possono ricevere poco o nessun peso nel ranking di ricerca. Il vero testo è anche più leggero in termini di dimensioni del file per la maggior parte degli usi tipografici, migliorando i punteggi Core Web Vitals e riducendo il consumo di banda per gli utenti su connessioni dati mobili — una preoccupazione particolarmente significativa nei mercati in cui la penetrazione di internet mobile è alta e i costi dei dati restano un fattore.

Regole Axe-core Correlate

WCAG 1.4.9 richiede test manuali perché nessuno strumento automatico può determinare in modo affidabile se un’immagine contiene testo significativo, se quel testo è puramente decorativo o se la sua resa visiva specifica è essenziale. Le seguenti considerazioni si applicano quando si usa axe-core o strumenti correlati:

• Ispezione manuale richiesta (nessuna regola axe dedicata): axe-core non include una regola che rilevi automaticamente le immagini di testo ai sensi di 1.4.9. Gli strumenti automatici possono segnalare elementi <img> privi di attributi alt (la regola image-alt) e immagini di sfondo che potrebbero avere significato, ma non possono analizzare il contenuto dei pixel di un’immagine per determinare se contiene testo, né possono giudicare se quel testo è decorativo. Un tester umano deve ispezionare visivamente ogni immagine e grafica di sfondo nella pagina e decidere se trasmette informazioni testuali che non sono disponibili anche come vero testo renderizzato nel DOM. Questo è un limite intrinseco dell’analisi statica: teoricamente si potrebbe applicare il riconoscimento ottico dei caratteri, ma produrrebbe un numero significativo di falsi positivi su immagini che contengono incidentalmente lettere o trattamenti di logotipo.
• image-alt (regola axe): Pur non essendo un test diretto di 1.4.9, la regola image-alt verifica che tutti gli elementi <img> abbiano un attributo alt non vuoto o siano esplicitamente contrassegnati come decorativi. L’esecuzione di questa regola aiuta gli auditor a identificare le immagini che necessitano di un esame più approfondito: qualsiasi immagine con un attributo alt descrittivo che suona come una frase o contiene copy promozionale è un forte segnale che l’immagine stessa potrebbe essere un’immagine di testo e quindi una candidata per 1.4.9.
• Audit Lighthouse “Image elements do not have [alt] attributes”: Simile a image-alt, questo controllo di Lighthouse mette in evidenza le immagini completamente prive di descrizione. I tester dovrebbero esaminare manualmente le immagini segnalate per valutare se rappresentano testo.

Come Eseguire i Test

1. Esegui una scansione automatizzata come primo passaggio. Apri axe DevTools, l’estensione browser di Deque o Lighthouse in Chrome DevTools ed esegui un audit dell’intera pagina. Esamina eventuali problemi relativi alle immagini che vengono segnalati. Sebbene nessuna regola automatica copra direttamente 1.4.9, questo passaggio mette in evidenza tutti gli elementi <img> e le immagini di sfondo CSS per una successiva revisione manuale. Esporta i risultati e annota ogni immagine che ha un attributo alt non vuoto e simile a una frase o che axe segnala in base a image-alt.
2. Ispeziona visivamente tutte le immagini e le grafiche di sfondo. Scorri la pagina ed esamina ogni immagine, sfondo CSS, elemento canvas e grafica SVG. Chiediti: questa immagine contiene testo? Se sì, quel testo è puramente decorativo (non aggiunge informazioni e potrebbe essere rimosso senza perdita)? È un logotipo in cui lo stile specifico delle lettere è inseparabile dall’identità del marchio? Se nessuna delle eccezioni si applica, l’immagine rappresenta un fallimento rispetto a 1.4.9.
3. Disabilita le immagini nel browser. In Firefox, vai su about:config e imposta permissions.default.image su 2, oppure usa un’estensione come “Disable Images”. Ricarica la pagina. Qualsiasi informazione testuale che scompare e non è sostituita da testo DOM visibile (non solo da un attributo alt annunciato da un lettore di schermo) rappresenta un fallimento rispetto a 1.4.9. Riabilita le immagini dopo il test.
4. Applica un foglio di stile utente personalizzato. In Firefox, posiziona un file nella cartella chrome/userContent.css del tuo profilo e aggiungi una regola come * { font-family: OpenDyslexic, sans-serif !important; color: yellow !important; background-color: black !important; }. Ricarica la pagina. Il testo reso come vero HTML adotterà questi stili; il testo incorporato nelle immagini non cambierà. Qualsiasi contenuto testuale che rimane visivamente invariato e illeggibile sotto questi stili forzati rappresenta un fallimento.
5. Testa con NVDA e Firefox. Naviga nella pagina usando la modalità browse di NVDA. Per ogni immagine, annota ciò che NVDA annuncia. Se NVDA legge un attributo alt che contiene contenuto testuale sostanziale, confronta quel contenuto con ciò che è visualizzato nell’immagine. La presenza di contenuto testuale significativo in un attributo alt è un forte indicatore che l’immagine contiene testo — e conferma un fallimento rispetto a 1.4.9 anche se 1.1.1 è tecnicamente soddisfatto.
6. Testa con VoiceOver e Safari su macOS. Usa VO + Freccia destra per spostarti tra i contenuti. Ascolta le descrizioni delle immagini che narrano frasi complete, intestazioni o testo promozionale. Incrocia con l’ispezione visiva per confermare che la fonte sia un’immagine piuttosto che vero testo.
7. Effettua uno zoom al 400%. WCAG 1.4.4 e 1.4.10 richiedono che il testo rimanga leggibile a livelli di zoom elevati. Le immagini di testo diventano pixelate quando vengono ingrandite con lo zoom del browser; il vero testo reso dal motore del browser rimane nitido. Al 400% di zoom, qualsiasi testo che appare sfocato o pixelato è probabilmente un’immagine di testo e dovrebbe essere esaminato come potenziale fallimento rispetto a 1.4.9.

Come Correggere

Banner promozionale con testo incorporato — Non corretto

<!-- A marketing banner where the headline and CTA are baked into the image.
     Even with alt text, users cannot customize the text rendering. -->
<a href='/sale'>
  <img src='/images/summer-sale-banner.jpg'
       alt='Summer Sale — Up to 50% off all products. Shop Now.'
       width='1200' height='400'>
</a>

Banner promozionale con testo incorporato — Corretto

<!-- The banner uses a real background image for visual decoration,
     while all text is rendered as real HTML so users can resize,
     recolor, and reflow it independently. -->
<a href='/sale' class='sale-banner'>
  <!-- Background image set via CSS: .sale-banner { background-image: url(/images/summer-bg.jpg); } -->
  <h2 class='sale-banner__headline'>Summer Sale</h2>
  <p class='sale-banner__offer'>Up to 50% off all products</p>
  <span class='sale-banner__cta'>Shop Now</span>
</a>

Infografica con punti dati etichettati — Non corretto

<!-- An infographic where category labels and percentages are drawn
     into the PNG. Screen reader users hear the alt; sighted low-vision
     users cannot enlarge or recolor the labels. -->
<img src='/images/market-share-2024.png'
     alt='Market share 2024: Product A 42%, Product B 31%, Product C 27%'
     width='800' height='600'>

Infografica con punti dati etichettati — Corretto

<!-- An accessible SVG chart where all labels are SVG <text> nodes.
     Users can zoom, reflow, and apply high-contrast themes to the text.
     An adjacent <table> provides the same data in tabular form. -->
<figure>
  <svg viewBox='0 0 800 400' role='img'
       aria-labelledby='chart-title chart-desc'>
    <title id='chart-title'>Market Share 2024</title>
    <desc id='chart-desc'>Pie chart: Product A 42%, Product B 31%, Product C 27%</desc>
    <!-- chart paths -->
    <text x='200' y='150' class='chart-label'>Product A — 42%</text>
    <text x='450' y='200' class='chart-label'>Product B — 31%</text>
    <text x='350' y='320' class='chart-label'>Product C — 27%</text>
  </svg>
  <figcaption>
    <details>
      <summary>View data as table</summary>
      <table>
        <caption>Market Share 2024</caption>
        <thead><tr><th>Product</th><th>Share</th></tr></thead>
        <tbody>
          <tr><td>Product A</td><td>42%</td></tr>
          <tr><td>Product B</td><td>31%</td></tr>
          <tr><td>Product C</td><td>27%</td></tr>
        </tbody>
      </table>
    </details>
  </figcaption>
</figure>

Immagine di sfondo CSS contenente un’intestazione ricca di testo — Non corretto

<!-- The page title is set as a CSS background image rather than real text.
     This is a common design pattern from the early 2000s image-replacement era
     that should not appear in modern codebases. -->
<h1 class='logo-header'></h1>
<!-- CSS: .logo-header {
       background: url('/images/page-title-about-us.png') no-repeat;
       width: 400px; height: 80px; display: block;
       text-indent: -9999px;
     } -->

Immagine di sfondo CSS contenente un’intestazione ricca di testo — Corretto

<!-- Real text is rendered by the browser. Custom web fonts reproduce
     the desired typographic style without sacrificing adaptability.
     The background image, if needed at all, is purely decorative texture. -->
<h1 class='page-title'>About Us</h1>
<!-- CSS: .page-title {
       font-family: 'BrandTypeface', serif;
       font-size: 3rem;
       color: #1a1a2e;
       letter-spacing: 0.05em;
     } -->

Errori Comuni

• Supporre che un attributo alt completo soddisfi 1.4.9. Fornire un testo alternativo accurato nell’attributo alt soddisfa WCAG 1.1.1 ma non ha alcun effetto su 1.4.9. Il criterio riguarda specificamente l’accessibilità alla personalizzazione della resa visiva del testo, non gli equivalenti programmati per i lettori di schermo.
• Usare tecniche CSS di image replacement (text-indent: -9999px o metodi basati su clip) su elementi da <h1> a <h6>. Queste tecniche legacy nascondono visivamente il vero testo e lo sostituiscono con un’immagine di sfondo, il che significa che gli utenti vedenti con ipovisione ricevono solo l’immagine mentre gli utenti di screen reader ricevono solo il testo nascosto — una discrepanza che penalizza entrambe le popolazioni in modi diversi.
• Esportare tipografia web come PNG o JPEG perché un font personalizzato non è disponibile come web font. Se un carattere tipografico con licenza non può legalmente essere servito come web font, la soluzione corretta è negoziare i diritti per il web font o scegliere un carattere alternativo, non rasterizzare il testo in immagini.
• Considerare i file SVG intrinsecamente accessibili. Un SVG che incorpora testo come elementi <path> (output comune degli strumenti di grafica come l’opzione “outline text” di Illustrator) è tanto inaccessibile quanto un PNG. L’SVG deve usare elementi <text> per superare il criterio 1.4.9.
• Incorporare testo in elementi <canvas> senza un fallback in vero testo. Il contenuto di canvas è rasterizzato a livello di pixel. Qualsiasi testo disegnato tramite ctx.fillText() non fa parte del DOM e non può essere adattato dagli user agent. È necessario un overlay o un’alternativa in vero testo.
• Lasciare immagini di documenti scansionati (PDF resi come immagini) senza livelli di vero testo basati su OCR. I documenti scansionati presentati in tag <img> o come PDF solo immagine non soddisfano 1.4.9. È necessario eseguire l’OCR e incorporare un livello di testo selezionabile, oppure convertire il documento in HTML correttamente taggato.
• Usare immagini di testo per dati dinamici come prezzi, quantità di stock o contenuti generati dagli utenti. Ogni volta che un server genera un’immagine che contiene dati testuali, tali dati vengono bloccati nel formato immagine. I prezzi nelle liste di prodotti, la disponibilità dei posti sulle piattaforme di prenotazione e i punteggi in tempo reale degli eventi sportivi devono essere resi come vero testo affinché gli utenti possano ridimensionarli e ricolorali.
• Trascurare le immagini delle firme email. I team marketing creano spesso blocchi firma come immagini per preservare il branding visivo. Quando queste email vengono archiviate e collegate dai siti web, le immagini delle firme diventano contenuti web soggetti a 1.4.9.
• Ignorare i contenuti dei widget di terze parti. Widget di chat, badge di social proof e caroselli di recensioni forniti da vendor terzi possono iniettare immagini di testo nella pagina. I proprietari dei siti restano responsabili dell’accessibilità di tutti i contenuti sulle loro pagine; se un fornitore non può offrire una resa basata su testo, è opportuno cercare un altro fornitore.
• Confondere le eccezioni per i logotipi con eccezioni generali per il branding. L’eccezione per il logotipo copre solo il logo o il wordmark in sé — il nome del marchio stilizzato. Non si estende a tagline, etichette di navigazione o qualsiasi altro testo che appare accanto al logo nella stessa immagine.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi di accessibilità web obbligatori per un’ampia gamma di organizzazioni che operano in Turchia. La circolare richiede che i soggetti interessati si conformino almeno a WCAG 2.1 livello AA come baseline minima. I soggetti esplicitamente coperti includono istituzioni pubbliche e organismi governativi, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori privati di servizi sanitari, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale.

WCAG 1.4.9 è un criterio di livello AAA e quindi si colloca al di sopra del minimo obbligatorio stabilito dalla Circolare Presidenziale 2025/10. I soggetti interessati non sono legalmente tenuti a rispettare 1.4.9 per soddisfare gli obblighi di base della circolare. Tuttavia, raggiungere il livello AAA per i criteri applicabili dimostra un impegno esemplare verso l’inclusione e amplia in modo significativo il pubblico che può utilizzare efficacemente il servizio.

Diversi settori coperti dalla circolare hanno incentivi particolarmente forti a perseguire volontariamente la conformità a 1.4.9. Le piattaforme di e-commerce usano frequentemente banner promozionali, grafiche di saldi e intestazioni di categorie di prodotto rese come immagini — tutti pattern comuni di fallimento rispetto a 1.4.9. Per le persone con ipovisione o dislessia che si affidano alla personalizzazione del testo per prendere decisioni di acquisto, questi fallimenti si traducono direttamente in conversioni perse e potenziale esposizione legale nell’ambito dei più ampi quadri turchi di tutela dei consumatori e di non discriminazione. Banche e istituzioni finanziarie presentano in modo analogo tassi di prestito, riepiloghi di conto e prospetti delle commissioni; se una qualsiasi di queste informazioni è incorporata in immagini, i clienti con ipovisione non possono adattare la presentazione per leggerla con sicurezza, sollevando preoccupazioni sia rispetto alla circolare sia rispetto alle norme di tutela dei consumatori nei servizi finanziari. Ospedali e fornitori di servizi sanitari che mostrano istruzioni di dosaggio, dettagli degli appuntamenti o informazioni per i pazienti in forma di immagine creano rischi per la sicurezza dei pazienti che non possono adattare la resa del testo.

Le organizzazioni che intendono rendere a prova di futuro le proprie proprietà digitali rispetto all’evoluzione normativa — o quelle che perseguono appalti pubblici che richiedono una leadership dimostrata in materia di accessibilità — farebbero bene a verificare e correggere i fallimenti rispetto a 1.4.9 come parte di un programma di accessibilità completo. L’SDK overlay di Accsible può aiutare con l’adattamento del testo a runtime per alcuni scenari legacy di immagini di testo, ma una correzione permanente a livello di codice — sostituire le immagini di testo con vero testo HTML stilizzato tramite CSS e web font — rimane la soluzione più robusta e duratura per una conformità a lungo termine.