Criteri di successo WCAG · Level AA
WCAG 1.4.5: Immagini di testo
WCAG 1.4.5 richiede che il testo che trasmette informazioni sia presentato come vero testo piuttosto che come immagine di testo, tranne nei casi in cui una specifica presentazione visiva sia essenziale o l’immagine possa essere personalizzata visivamente dall’utente. Questo criterio è fondamentale per le persone che hanno bisogno di ridimensionare, ricolorare o rifluire il testo per leggerlo comodamente.
Cosa Significa Questa Regola
WCAG 1.4.5 — Immagini di testo (Livello AA) stabilisce che, se la stessa presentazione visiva può essere ottenuta usando vero testo, è necessario usare vero testo invece di un’immagine che contiene testo. Un’immagine di testo è qualsiasi immagine in cui i caratteri testuali sono il contenuto principale trasmesso — per esempio, un JPEG di un’intestazione, un banner PNG con uno slogan, o un logo GIF che scrive il nome di un brand in un font stilizzato.
La distinzione tra superare o fallire il criterio è semplice: se l’informazione potrebbe essere trasmessa marcando i caratteri reali in HTML e stilizzandoli con CSS per ottenere lo stesso aspetto, allora usare un’immagine al suo posto è un errore. La regola non riguarda immagini decorative o fotografie che contengono testo nella scena (come un cartello stradale in una foto). Prende di mira le immagini in cui il testo stesso è il contenuto intenzionale.
WCAG definisce due eccezioni ufficiali in cui le immagini di testo sono consentite:
- Eccezione essenziale: La particolare presentazione visiva è essenziale per l’informazione trasmessa. L’esempio classico è un logotipo — dove la specifica resa delle forme delle lettere è inseparabile dall’identità del brand. Un logo aziendale in cui le forme di lettere stilizzate SONO il brand può rimanere come immagine.
- Eccezione personalizzabile: L’immagine di testo può essere personalizzata visivamente in base alle esigenze dell’utente. Ciò significa che l’utente può cambiare il font, la dimensione, il colore e lo sfondo del testo nell’immagine. In pratica questa eccezione è quasi mai soddisfatta dalle implementazioni reali, perché la maggior parte delle immagini non può essere renderizzata dinamicamente secondo le preferenze dell’utente.
È importante notare ciò che questo criterio NON richiede: non vieta tutte le immagini contenenti testo. Una fotografia di un documento storico, uno screenshot usato come prova, o un’immagine di un grafico in cui le etichette degli assi fanno parte della visualizzazione dei dati non sono il bersaglio principale di questa regola, anche se il testo alternativo (WCAG 1.1.1) deve comunque descriverne il contenuto. L’attenzione è rivolta ai casi in cui un designer ha scelto di rendere testo stilizzato come immagine raster o vettoriale per motivi puramente estetici quando il CSS potrebbe ottenere lo stesso risultato.
Gli elementi HTML più comunemente coinvolti nei fallimenti includono tag <img> usati per intestazioni, banner, pulsanti di call-to-action, etichette di navigazione, citazioni in evidenza e testo promozionale. Anche i file SVG che incorporano testo come tracciati (anziché elementi <text>) sono un problema, poiché quei caratteri non possono essere selezionati, ridimensionati o rifluiti dal browser.
Perché È Importante
Quando il testo è incorporato in un’immagine raster, diventa un bitmap fisso. Il browser può ridimensionare l’immagine in alto o in basso, ma non può rifluire il testo, cambiarne il font, aumentarne il peso o modificarne il contrasto di colore oltre ciò che è già “cotto” nei pixel. Questo crea barriere significative per diversi gruppi di persone con disabilità.
Le persone con ipovisione tipicamente si affidano allo zoom del browser, alla scalatura del testo del sistema operativo o a software di ingrandimento dedicati. Il vero testo si scala in modo nitido a qualsiasi livello di zoom; un’immagine di testo si sfoca e si sgranella, diventando illeggibile ad alti ingrandimenti. Circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva, e molte di loro usano zoom o ingrandimento come strategia principale, piuttosto che un lettore di schermo.
Le persone con dislessia o altri disturbi della lettura usano spesso estensioni del browser o tecnologie assistive per sovrascrivere i font, aumentare l’interspaziatura tra le lettere e passare a schemi di colori ad alto contrasto. Nessuna di queste personalizzazioni funziona sulle immagini di testo — i pixel sono immutabili. Una persona che ha bisogno di OpenDyslexic o di un font sans-serif a spaziatura ampia non può semplicemente applicarlo a un’intestazione resa come PNG.
Le persone che si affidano a schemi di colori personalizzati — incluse quelle con fotofobia, disturbi da emicrania o sensibilità al contrasto — possono impostare il proprio sistema operativo su una modalità ad alto contrasto o a colori invertiti. Il testo CSS risponde a queste sostituzioni a livello di sistema; il testo in immagine no, e può addirittura diventare più difficile da leggere quando i colori vengono invertiti in modo imprevisto.
Consideriamo uno scenario concreto: un sito di e-commerce turco rende le intestazioni delle campagne promozionali come immagini JPEG per preservare il font display personalizzato usato nelle linee guida del brand. Una persona con ipovisione ingrandisce il browser al 200%. Le immagini dei prodotti si scalano in modo accettabile, ma l’intestazione della campagna — un’immagine — diventa una macchia sfocata di pixel. L’utente non riesce a leggere la promozione e perde l’offerta. Se lo stesso font fosse stato fornito tramite @font-face e applicato a un vero elemento <h2>, il testo sarebbe rimasto nitido a qualsiasi livello di zoom, perché il rendering vettoriale dei font si scala all’infinito.
Oltre all’accessibilità, l’uso di vero testo ha misurabili benefici SEO. I crawler dei motori di ricerca indicizzano direttamente i nodi di testo; non possono estrarre in modo affidabile il contenuto testuale delle immagini senza OCR. Un’intestazione incorporata in un PNG è invisibile all’algoritmo di ranking di Google. Passare al vero testo può migliorare l’indicizzazione delle parole chiave e il posizionamento in pagina per lo stesso contenuto.
Regole Axe-core Correlate
WCAG 1.4.5 richiede test manuali. Non esiste una singola regola automatizzata di axe-core che rilevi in modo affidabile le immagini di testo, per i motivi spiegati di seguito.
- Test manuale richiesto — nessuna regola automatizzata dedicata: Gli strumenti automatici possono rilevare che esiste un elemento
<img>e che ha un attributoalt, ma non possono determinare se il contenuto visivo di quell’immagine è principalmente testo renderizzato. Farlo richiederebbe riconoscimento delle immagini / OCR su ogni immagine della pagina, il che è computazionalmente costoso e dipendente dal contesto. Uno strumento che analizza una pagina non può distinguere tra una fotografia che incidentalmente contiene un cartello con parole e un’intestazione deliberatamente resa come immagine. È necessario il giudizio umano per valutare se una data immagine esiste allo scopo di presentare testo stilizzato che potrebbe invece essere marcato come vero testo HTML con stile CSS. - Segnale parziale dalle regole sul contrasto di colore: Le regole axe-core come
color-contrastnon si attivano sul testo incorporato nelle immagini, perché operano sui nodi di testo del DOM e sui valori di colore CSS calcolati. Se un’immagine di testo ha contrasto insufficiente, il controllo automatico del contrasto la ignorerà silenziosamente. Ciò significa che le immagini di testo possono violare contemporaneamente sia 1.4.5 che 1.4.3 (Contrasto minimo) senza alcun avviso automatico — un motivo forte per eseguire audit manuali approfonditi. - Testo SVG come tracciati: Quando un SVG esporta il testo come tracciati di contorno (elementi
<path>) anziché come elementi<text>, axe-core non ha modo di sapere che i tracciati compongono parole. È necessaria un’ispezione manuale del codice sorgente SVG per determinare se il testo è stato convertito in tracciati e se dovrebbe invece essere un vero elemento<text>con un web font applicato.
Come Testare
- Esegui una scansione automatizzata come base. Usa axe DevTools (estensione del browser) o Lighthouse in Chrome DevTools per identificare eventuali problemi segnalati sulla pagina. Sebbene nessuno dei due strumenti abbia una regola 1.4.5 dedicata, l’output della scansione può far emergere problemi correlati come testo alternativo
altmancante sulle immagini o contrasto di colore insufficiente sui nodi di testo. Prendi nota di eventuali immagini segnalate — queste diventano candidate per la revisione manuale. - Ispeziona visivamente tutte le immagini sulla pagina. Apri la pagina in un browser e osserva sistematicamente ogni elemento
<img>, ogni SVG inline, ogni immagine di sfondo CSS e ogni elemento canvas. Chiediti per ciascuno: lo scopo principale di questa immagine è mostrare testo? Se sì, passa al passaggio successivo. - Verifica se il CSS potrebbe ottenere lo stesso risultato. Per qualsiasi immagine identificata nel passaggio 2, chiediti: un web font (
@font-face) combinato con proprietà CSS (colore, text-shadow, letter-spacing, sfondo a gradiente) potrebbe produrre un risultato visivo equivalente? Se la risposta è sì, l’immagine di testo è un errore a meno che non si applichi l’eccezione del logotipo. - Verifica le eccezioni per i logotipi. Se un sito invoca l’eccezione per logotipo, conferma che l’immagine è realmente un logo di brand in cui il design delle forme delle lettere è inseparabile dall’identità del brand, e non semplicemente un’intestazione impostata nel font del brand.
- Testa con lo zoom del browser. Aumenta lo zoom del browser al 200% e al 400% (usando Ctrl/Cmd + o le impostazioni del browser). Osserva se il testo sulla pagina rimane nitido. Le immagini di testo si sfoceranno o si sgraneranno; il vero testo rimarrà nitido. Questo test verifica contemporaneamente le violazioni di 1.4.5 e i problemi correlati di riflusso (WCAG 1.4.4 e 1.4.10).
- Ispeziona il codice sorgente SVG. Fai clic destro su qualsiasi SVG e scegli “View Source” oppure usa gli strumenti di sviluppo del browser per ispezionare il DOM dell’SVG. Conferma che il contenuto testuale usa elementi
<text>anziché elementi<path>che tracciano i contorni delle lettere. Se tutto il testo è stato convertito in tracciati, l’SVG ha lo stesso problema di un’immagine raster di testo. - Testa con un lettore di schermo per comprendere l’impatto combinato. Usa NVDA con Firefox, VoiceOver con Safari su macOS/iOS o JAWS con Chrome. Naviga fino alle immagini di testo e conferma che l’attributo
alttrasmette accuratamente il contenuto testuale. Sebbene un attributoaltsignificativo soddisfi WCAG 1.1.1 (Contenuti non testuali), non risolve la violazione di 1.4.5 — il testo non è comunque personalizzabile dall’utente. Documenta separatamente entrambi i problemi. - Applica un foglio di stile utente personalizzato o un’estensione del browser. Installa un’estensione del browser come Stylus o usa la funzionalità integrata di foglio di stile utente di Firefox per sovrascrivere globalmente le famiglie di font e aumentare la dimensione del font. Il vero testo cambierà; il testo in immagine no. Questo simula direttamente ciò che sperimentano le persone con disturbi della lettura quando applicano i loro font preferiti.
Come Correggere
Intestazione di banner decorativo — Errato
<!-- Failing: A marketing heading is rendered as a JPEG to preserve a custom font -->
<div class='hero'>
<img src='summer-sale-heading.jpg' alt='Summer Sale — Up to 50% Off' />
</div>
Intestazione di banner decorativo — Corretto
<!-- Fixed: The same custom font is delivered via @font-face and applied to a real heading.
The text is now selectable, scalable, and user-customizable. -->
<style>
@font-face {
font-family: 'BrandDisplay';
src: url('/fonts/brand-display.woff2') format('woff2');
font-display: swap;
}
.hero-heading {
font-family: 'BrandDisplay', sans-serif;
font-size: clamp(2rem, 5vw, 4rem);
color: #c0392b;
text-shadow: 2px 2px 4px rgba(0,0,0,0.3);
}
</style>
<div class='hero'>
<h1 class='hero-heading'>Summer Sale — Up to 50% Off</h1>
</div>
SVG con testo convertito in tracciati — Errato
<!-- Failing: Text has been converted to paths in the SVG export,
making the characters inaccessible and non-scalable as text -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'>
<!-- Dozens of <path> elements that trace the letters of 'Accsible' -->
<path d='M10 60 L20 20 L30 60 ...' fill='#003087' />
</svg>
SVG con testo convertito in tracciati — Corretto
<!-- Fixed: SVG uses a real <text> element with a web font reference.
The text is now indexable, selectable, and scalable. -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'
role='img' aria-label='Accsible'>
<defs>
<style>
.svg-label {
font-family: 'BrandDisplay', sans-serif;
font-size: 48px;
fill: #003087;
}
</style>
</defs>
<text class='svg-label' x='10' y='60'>Accsible</text>
</svg>
Immagine di sfondo CSS con etichetta testuale sovrapposta — Errato
<!-- Failing: The button label is part of the background image,
not a real text node -->
<a href='/shop' class='cta-button'></a>
<style>
.cta-button {
display: block;
width: 200px;
height: 60px;
background: url('shop-now-button.png') no-repeat center;
background-size: cover;
}
</style>
Immagine di sfondo CSS con etichetta testuale sovrapposta — Corretto
<!-- Fixed: The button uses a real text node styled with CSS.
The background image is purely decorative (gradient or texture). -->
<a href='/shop' class='cta-button'>Shop Now</a>
<style>
.cta-button {
display: inline-block;
padding: 1rem 2rem;
background: linear-gradient(135deg, #e74c3c, #c0392b);
color: #ffffff;
font-family: 'BrandDisplay', sans-serif;
font-size: 1.25rem;
font-weight: 700;
text-decoration: none;
border-radius: 4px;
}
</style>
Logotipo — Eccezione accettabile
<!-- Acceptable: A logotype where the specific letterform design
IS the brand identity. Alt text accurately conveys the text content.
CSS cannot replicate the hand-drawn letterforms. -->
<a href='/' aria-label='Accsible — Home'>
<img src='accsible-logo.svg'
alt='Accsible'
width='160'
height='48' />
</a>
Errori Comuni
- Usare un JPEG o PNG per le intestazioni di pagina perché il mockup di design usa un font non disponibile su Google Fonts — la correzione appropriata è ospitare autonomamente il font come file WOFF2 usando
@font-face, non incorporare l’intestazione in un’immagine. - Esportare intere sezioni hero come un’unica immagine piatta da strumenti di design come Figma o Photoshop, il che incorpora tutto il testo, i pulsanti e le etichette in un unico file raster. Ogni elemento testuale deve essere un nodo HTML separato.
- Convertire il testo SVG in tracciati durante l’esportazione per evitare dipendenze di caricamento dei font sul server. Questo elimina l’accessibilità e la ricercabilità del testo. Usa elementi
<text>con un riferimento a un font CSS invece. - Inserire testo promozionale o legale (come termini e condizioni, prezzi o regole di concorso) all’interno di un’immagine per preservare il controllo preciso del layout. Qualsiasi testo che le persone devono leggere deve essere vero testo HTML.
- Invocare l’eccezione del logotipo per ogni elemento di testo di brand — l’eccezione si applica solo al vero marchio/logo, non a qualsiasi intestazione o etichetta impostata nel carattere tipografico del brand. Un’intestazione in Helvetica Neue non è un logotipo.
- Fornire un attributo
altaccurato e presumere che ciò risolva la violazione di 1.4.5 — non è così. Il testo alternativo soddisfa WCAG 1.1.1 (Contenuti non testuali) ma non rende il testo in immagine personalizzabile dall’utente, che è il requisito specifico di 1.4.5. - Usare elementi HTML5
<canvas>per rendere testo stilizzato a scopo visivo senza fornire un’alternativa in vero testo nel DOM. Il testo renderizzato su canvas ha tutti gli stessi svantaggi del testo in immagine. - Incorporare testo nelle immagini di anteprima Open Graph o di condivisione sui social e dimenticare che queste immagini compaiono anche sulla pagina (per esempio, come immagine in evidenza in un post di blog). Se l’immagine in evidenza è contesto decorativo, ciò può essere accettabile — ma se è l’intestazione principale dell’articolo, è un errore.
- Ignorare i template delle newsletter email — sebbene i client email siano al di fuori dell’ambito WCAG per i browser, molte organizzazioni pubblicano le loro newsletter come pagine web. Il testo nelle immagini di intestazione delle email incorporato come contenuto web attiva comunque il criterio 1.4.5.
- Presumere che le immagini ad alta risoluzione Retina risolvano il problema — un’immagine di testo a risoluzione 2× o 3× è più nitida di un’immagine 1× ma viola comunque 1.4.5 perché il testo rimane non personalizzabile, non rifluibile e invisibile ai motori di ricerca e alle tecnologie assistive.
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 standard obbligatori di accessibilità web e mobile per un’ampia gamma di soggetti che operano in Turchia. La circolare fa esplicito riferimento a WCAG 2.2 come standard tecnico normativo, e la conformità al Livello AA — che include WCAG 1.4.5 — è richiesta per l’idoneità al Erişilebilirlik Logosu (Logo di Accessibilità), rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı). Questo logo funge da marchio ufficiale di certificazione che indica che un prodotto digitale soddisfa i requisiti di accessibilità definiti nella circolare.
I soggetti coperti dalla circolare comprendono un’ampia sezione trasversale dell’economia digitale turca. Istituzioni pubbliche e agenzie governative a tutti i livelli sono tenute a conformarsi, così come banche e istituzioni finanziarie regolamentate dal BDDK (Banking Regulation and Supervision Agency). Sono inclusi ospedali e fornitori di servizi sanitari, sia pubblici che privati. Nel settore privato, piattaforme di e-commerce, operatori di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto private e scuole private e istituzioni educative autorizzate dal Ministero dell’Istruzione Nazionale (MoNE / Milli Eğitim Bakanlığı) rientrano tutte nell’ambito della circolare.
Per queste organizzazioni, WCAG 1.4.5 ha implicazioni dirette e pratiche. Molti siti di e-commerce e istituzionali turchi usano immagini promozionali, banner con font personalizzati e intestazioni di campagne che incorporano testo come immagini raster — una pratica comune nei flussi di lavoro di web design che hanno origine in strumenti di design visivo. In base alla Circolare Presidenziale, tali implementazioni costituiscono una non conformità al Livello AA e impedirebbero al sito di ottenere o mantenere l’Erişilebilirlik Logosu. Banche che mostrano tabelle dei tassi di interesse come immagini, ospedali che elencano i nomi dei reparti in banner PNG o operatori di telecomunicazioni che presentano tariffe promozionali come file di immagini piatte sarebbero tutti in violazione di questo criterio.
Le organizzazioni che mirano alla conformità dovrebbero esaminare tutte le immagini presenti sulle proprie proprietà web alla ricerca di contenuti testuali incorporati, dare priorità alla conversione delle pagine ad alto traffico (home page, pagine prodotto, pagine di destinazione dei servizi) e stabilire un flusso di lavoro tra design e sviluppo che vieti la consegna di contenuti testuali all’interno di file immagine. Investire in una strategia di web font usando @font-face con formato WOFF2 e valori font-display appropriati consentirà ai designer di ottenere la stessa ricchezza tipografica richiesta dalle linee guida del brand rimanendo pienamente conformi sia a WCAG 2.2 Livello AA sia al mandato di accessibilità turco del 2025.
