L'email HTML è pur sempre HTML, renderizzato da uno user agent — un client webmail è un browser, e il motore di rendering di un'app di posta nativa non è fondamentalmente diverso. I criteri di successo del WCAG non prevedono un'eccezione specifica per l'email, e si applicano altrettanto direttamente a un sondaggio, un quiz o una fisarmonica basati solo su CSS quanto al componente web equivalente. Questa è una checklist pratica per i quattro criteri più rilevanti per l'email interattiva basata sulla tecnica del checkbox hack.
Perché il WCAG si applica qui
Il WCAG 2.2 è scritto in termini di «contenuto» renderizzato da uno «user agent», non specificamente di «pagine web» — non è uno standard formale specifico per l'email, dato che l'email come mezzo non è mai nominata nella specifica, ma il contenuto sottostante è comunque HTML. Per questo la comunità dell'accessibilità tratta i criteri di successo del WCAG come lo standard pratico per il contenuto email, allo stesso modo di questa checklist, invece di trattare l'email come una categoria separata che le linee guida non raggiungono.
1.1.1 Contenuto non testuale — ogni immagine ha bisogno di un alt reale
Foto prodotto, immagini hero, separatori decorativi e pulsanti solo icona hanno tutti bisogno di un attributo alt che uno screen reader possa annunciare — oppure, per immagini genuinamente decorative che non trasportano alcuna informazione, un alt="" esplicito e vuoto, in modo che lo screen reader le salti invece di leggere un nome di file privo di significato. Questo conta di più nei blocchi interattivi che in quelli statici: una ruota spin-to-win o una rivelazione a grattare interamente guidate da immagini, senza un'alternativa testuale che descriva l'esito, non lasciano a un utente di screen reader alcun modo di sapere cosa ha vinto.
1.4.3 / 1.4.11 — Contrasto per testo e controlli interattivi
Il WCAG fissa un rapporto di contrasto minimo di 4.5:1 per il testo normale del corpo (3:1 per il testo grande, secondo il criterio 1.4.3), e un minimo di 3:1 per i confini visivi dei componenti dell'interfaccia e della grafica (1.4.11). Entrambi si applicano direttamente agli elementi interattivi, non solo al testo dei paragrafi — il bordo di un'opzione di sondaggio, lo sfondo del pulsante di una risposta al quiz rispetto al suo contenitore, le cifre di un timer di conto alla rovescia rispetto al proprio sfondo. Un controllo interattivo a basso contrasto non è solo una mancanza estetica; può rendere il controllo del tutto invisibile a un destinatario ipovedente.
2.1.1 Tastiera — il vantaggio genuino della tecnica del checkbox hack
Un vero <input type="radio">/<input type="checkbox"> abbinato a un <label for="..."> è nativamente selezionabile con il focus e utilizzabile con Tab più Spazio o Invio, in qualsiasi client che renderizzi anche solo i controlli di modulo — senza markup aggiuntivo, senza sforzo extra, perché è così che i browser hanno sempre trattato i controlli di modulo reali. Vedi Macchine a stati CSS :checked per come funziona la tecnica stessa. Si tratta di un vantaggio genuino rispetto a ciò che tipicamente fa un carosello web guidato da JavaScript — un <div onclick> senza gestore da tastiera — ed è un vantaggio che l'email interattiva ottiene per costruzione, non con sforzo extra, purché si usino vere coppie <label>/<input> invece di semplici <div> cliccabili.
2.5.8 Dimensione del target (minima) — novità del WCAG 2.2
Il criterio di successo 2.5.8, introdotto nel WCAG 2.2, fissa un minimo di 24×24 pixel CSS per i target interattivi, con eccezioni per il testo inline, i vincoli di layout essenziali o un controllo equivalente più grande disponibile altrove. È particolarmente rilevante su mobile — dove avviene la maggior parte delle aperture email — per i più piccoli elementi interattivi che uno studio rende facile ridurre troppo: i puntini del carosello, le icone di valutazione a stelle, i chip delle risposte del quiz ravvicinati tra loro.
4.1.2 Nome, ruolo, valore — etichettare correttamente i controlli :checked
Uno screen reader annuncia il nome, il ruolo e lo stato attuale di un controllo a partire da un markup semantico reale — che è esattamente ciò che un <label> che racchiude un <input> reale fornisce gratuitamente, ed esattamente ciò che manca a un semplice <div> stilizzato usato al posto di un pulsante. In pratica questo significa che ogni opzione di sondaggio, risposta di quiz e intestazione di fisarmonica ha bisogno di un vero testo di etichetta che uno screen reader possa leggere ad alta voce, non solo di un'immagine di sfondo o di un'icona senza testo di accompagnamento.
Checklist pratica
- Ogni immagine porta un vero
alt, oppure unalt=""esplicito e vuoto se è decorativa. - Il testo e i bordi dei controlli interattivi rispettano il contrasto 4.5:1 (testo) / 3:1 (componente dell'interfaccia).
- Ogni interazione
:checkedusa una vera coppia<input>+<label for="...">— mai un semplice<div>cliccabile. - I target interattivi misurano almeno 24×24 pixel CSS, specialmente nei blocchi orientati al mobile.
- Le etichette di sondaggi/quiz/fisarmoniche portano un testo reale e leggibile — non solo un'immagine o un'icona.