WCAG 1.3.3: Caratteristiche sensoriali

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 1.3.3 — Caratteristiche Sensoriali (Livello A) stabilisce che le istruzioni fornite per comprendere e utilizzare i contenuti non devono basarsi esclusivamente su caratteristiche sensoriali di componenti come forma, dimensione, posizione visiva, orientamento o suono. In altre parole, se la tua interfaccia dice a un utente di interagire con qualcosa facendo riferimento solo al suo aspetto, a dove appare sullo schermo o a come suona, quella istruzione sarà priva di significato per gli utenti che non possono percepire quelle particolari proprietà sensoriali.

La parola chiave qui è esclusivamente. Il criterio non vieta l’uso di riferimenti sensoriali — vieta che essi siano l’unico mezzo di identificazione. Un’istruzione come "fai clic sul pulsante rotondo verde a sinistra" fallisce quando un utente non può distinguere il verde, non può vedere la forma del pulsante o non può distinguere la sinistra dalla destra a causa di un layout a riflusso. Tuttavia, "fai clic sul pulsante Invia (il pulsante rotondo verde a sinistra)" è conforme perché l’etichetta testuale "Invia" fornisce un identificatore non sensoriale che funziona indipendentemente da colore, forma e posizione.

Le istruzioni interessate da questo criterio includono qualsiasi contenuto testuale, audio o visivo che indirizza gli utenti a compiere un’azione o a individuare informazioni. Modelli di errore comuni includono:

• "Fai clic sul pulsante a destra per continuare" — si basa esclusivamente sulla posizione visiva.
• "Seleziona l’icona quadrata per aprire le impostazioni" — si basa esclusivamente sulla forma.
• "I campi obbligatori sono mostrati in rosso" — si basa esclusivamente sul colore.
• "Quando senti il segnale acustico, procedi al passaggio successivo" — si basa esclusivamente sul suono.
• "Tocca il riquadro grande per espandere la sezione" — si basa esclusivamente sulla dimensione.

Un’istruzione conforme include sempre almeno un identificatore non sensoriale — tipicamente un’etichetta testuale, un nome programmatico o un’intestazione — in modo che gli utenti che si affidano a tecnologie assistive o che operano in condizioni in cui gli indizi sensoriali non sono disponibili possano comunque seguire le indicazioni. Nota che questo criterio riguarda specificamente le istruzioni; non richiede che ogni elemento dell’interfaccia utente venga riprogettato, ma richiede che qualsiasi guida testuale o vocale relativa a tali elementi sia percepibile senza discriminazione sensoriale.

Non esistono eccezioni ufficiali definite all’interno del 1.3.3 stesso, sebbene il documento Understanding chiarisca che i contenuti che utilizzano caratteristiche sensoriali in aggiunta a identificatori non sensoriali sono pienamente conformi. Il criterio inoltre integra, ma è distinto da, 1.4.1 (Uso del Colore), che affronta specificamente il solo colore; 1.3.3 ha un ambito più ampio che copre tutte le modalità sensoriali.

Perché È Importante

Le istruzioni basate solo su caratteristiche sensoriali creano barriere significative per un’ampia gamma di utenti. Consideriamo ciascun gruppo interessato:

Utenti ciechi e ipovedenti si affidano a screen reader o software di ingrandimento. Quando un’istruzione dice "fai clic sull’icona nell’angolo in alto a destra", un utente di screen reader che naviga per ordine di tabulazione o struttura delle intestazioni non ha alcun concetto di "angolo in alto a destra" nel layout visivo. Allo stesso modo, un utente con grave ipovisione che ha effettuato uno zoom al 400% può vedere solo una piccola porzione dello schermo alla volta, rendendo i riferimenti posizionali come "pannello di sinistra" o "sezione inferiore" completamente inaffidabili. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno una qualche forma di disabilità visiva, rendendolo uno dei gruppi più numerosi interessati.

Utenti daltonici — che riguardano circa 1 uomo su 12 e 1 donna su 200 — non possono distinguere determinate coppie di colori. Un’istruzione che recita "i campi evidenziati in rosso sono obbligatori" è invisibile come indizio distintivo per una persona con daltonismo rosso-verde. Sebbene il criterio 1.4.1 affronti questo aspetto per l’elemento dell’interfaccia utente in sé, 1.3.3 garantisce che anche il testo delle istruzioni fornisca un’alternativa.

Utenti sordi e ipoacusici sono penalizzati dagli indizi esclusivamente audio. Se una piattaforma di e-learning istruisce gli utenti a "procedere quando senti la campana", gli utenti che non possono sentire la campana vengono esclusi. Questo modello compare in presentazioni interattive, tutorial basati su video e valutazioni a tempo.

Utenti con disabilità cognitive e di apprendimento possono avere difficoltà con il linguaggio direzionale, soprattutto quando la loro tecnologia assistiva rende i contenuti in forma linearizzata che elimina la posizione visiva. Una persona che utilizza un dispositivo a scansione o un sistema di tracciamento oculare naviga inoltre in sequenze che possono non avere alcuna relazione con il layout bidimensionale immaginato da un designer vedente.

Consideriamo uno scenario concreto reale: un portale di e-servizi del governo turco istruisce i cittadini a "compilare i campi contornati in blu e poi premere il pulsante triangolare per inviare la domanda". Un utente cieco che naviga per campi del modulo ascolta le etichette dei campi tramite il proprio screen reader ma non ha modo di sapere quali campi sono contornati in blu, né può identificare un pulsante dalla sua forma triangolare. Il processo di richiesta è di fatto bloccato. Aggiungere le effettive etichette dei campi (ad esempio, "Nome, Numero di Identità e Data di Nascita sono obbligatori") e l’etichetta testuale del pulsante ("Invia domanda") risolve immediatamente la barriera.

Oltre all’accessibilità, rimuovere le istruzioni basate solo su caratteristiche sensoriali migliora l’usabilità per tutti. I design responsive fanno rifluire i contenuti, quindi i riferimenti posizionali diventano imprecisi su mobile. La modalità scura o i temi ad alto contrasto modificano la resa dei colori. Gli assistenti vocali che leggono ad alta voce le istruzioni della pagina eliminano tutto il contesto visivo. Costruire le istruzioni attorno a etichette programmatiche stabili anziché a proprietà sensoriali transitorie rende i contenuti più robusti su tutti i dispositivi e in tutti i contesti — con un beneficio diretto anche per SEO e manutenzione.

Regole Axe-core Correlate

WCAG 1.3.3 richiede test manuali perché gli strumenti automatici non possono interpretare in modo affidabile il significato o l’intento delle istruzioni in linguaggio naturale. Un motore di analisi statica può rilevare che esiste un pulsante o che viene usato un colore, ma non può leggere un paragrafo di testo istruzionale, capire che si riferisce a un pulsante e poi determinare se tale riferimento è esclusivamente sensoriale. Si tratta di un giudizio semantico e contestuale che richiede una revisione umana.

• È richiesta una revisione manuale — non esiste una regola axe-core dedicata per 1.3.3. Regole axe-core come color-contrast e label possono far emergere problemi correlati (per esempio, un pulsante senza nome accessibile), ma affrontano criteri diversi. Per 1.3.3, un tester umano deve leggere ogni frase istruzionale sulla pagina, identificare eventuali riferimenti sensoriali (forma, colore, dimensione, posizione, orientamento, suono) e verificare che ogni riferimento sia accompagnato da almeno un identificatore non sensoriale. Gli strumenti automatici non segnaleranno una frase come "fai clic sul pulsante verde qui sotto" come violazione perché l’analisi dell’intento del linguaggio naturale va oltre le capacità dell’automazione basata su regole attuale.
• Perché l’automazione fallisce in questo caso: Considera che "fai clic sul pulsante grande" contiene la parola "pulsante", che uno strumento automatico potrebbe interpretare come riferimento a un ruolo accessibile. Ma l’istruzione si basa comunque esclusivamente sulla dimensione ("grande") per distinguere questo pulsante dagli altri. Gli strumenti automatici non possono determinare se "grande" sia l’unica caratteristica distintiva o se esista un solo pulsante sulla pagina (rendendo "grande" ridondante ma non dannoso). Il giudizio umano è essenziale per valutare queste sfumature nel contesto.
• Regole axe complementari da eseguire insieme alla revisione manuale: L’esecuzione dei controlli color-contrast, label, button-name e aria-label aiuterà a garantire che gli elementi dell’interfaccia utente a cui si fa riferimento nelle istruzioni abbiano effettivamente nomi programmatici — un prerequisito per scrivere istruzioni non sensoriali. Se un pulsante non ha un nome accessibile, nessuna istruzione può farvi riferimento in modo significativo senza ricorrere a indizi sensoriali.

Come Testare

1. Esegui prima una scansione automatizzata (axe DevTools o Lighthouse): Apri la pagina in Chrome, attiva l’estensione axe DevTools ed esegui una scansione dell’intera pagina. Sebbene nessuna regola mappi direttamente a 1.3.3, esamina eventuali problemi segnalati nelle categorie "color", "label" e "name". Questi risultati forniscono una base — se gli elementi dell’interfaccia utente non hanno nomi accessibili, il testo istruzionale che li cita si affida quasi certamente a indizi sensoriali. Esporta i risultati e annota tutti gli elementi interattivi privi di etichette programmatiche.
2. Identifica manualmente tutto il testo istruzionale: Leggi ogni frase sulla pagina che indirizza un utente a compiere un’azione o a individuare informazioni. Questo include testo di aiuto, suggerimenti per i moduli, tooltip, overlay di tutorial, messaggi di errore e flussi di onboarding. Crea un elenco di ogni istruzione ed evidenzia eventuali riferimenti sensoriali: parole di colore (rosso, blu, verde), parole di forma (rotondo, quadrato, triangolare), parole di dimensione (grande, piccolo, grande), parole posizionali (sinistra, destra, alto, basso, sopra, sotto, angolo), parole di orientamento (orizzontale, verticale) e riferimenti al suono (segnale acustico, beep, suono di avviso).
3. Valuta ogni riferimento sensoriale per identificatori aggiuntivi non sensoriali: Per ogni riferimento sensoriale trovato, determina se è presente anche un identificatore non sensoriale. Un identificatore non sensoriale include un’etichetta testuale che corrisponde all’etichetta visibile dell’elemento o al suo nome accessibile, un’intestazione, un passaggio numerato, un ruolo programmatico univoco o un’etichetta ARIA. Se l’unico modo per identificare l’elemento a cui si fa riferimento è tramite la percezione sensoriale, l’istruzione non è conforme al 1.3.3.
4. Testa con uno screen reader (NVDA + Firefox): Naviga nella pagina usando solo la tastiera e NVDA. Spostati con il tasto Tab tra tutti gli elementi interattivi e ascolta come NVDA annuncia ciascuno di essi. Poi leggi il testo istruzionale sulla pagina e chiediti: un utente che ascolta solo questi annunci potrebbe seguire le istruzioni? Se un’istruzione dice "fai clic sull’icona a destra" ma NVDA annuncia l’elemento come "Impostazioni, pulsante", allora il riferimento posizionale dell’istruzione è superfluo ma l’etichetta rende l’istruzione navigabile. Se NVDA annuncia l’elemento come "pulsante" senza nome, l’istruzione che si basa sulla posizione visiva fallisce completamente.
5. Testa con VoiceOver + Safari (macOS/iOS): Abilita VoiceOver e naviga nella pagina. Usa il rotor per esplorare per pulsanti, link e controlli dei moduli. Verifica che ogni elemento a cui si fa riferimento in un’istruzione sia raggiungibile e identificabile dal solo nome annunciato, senza fare affidamento sulla sua posizione nel layout visivo.
6. Testa con JAWS + Chrome: Apri la pagina in Chrome con JAWS attivo. Usa la Forms Mode per navigare tra gli input e ascoltare gli annunci dei campi. Confronta con eventuali istruzioni a livello di modulo che usano colore o posizione per indicare i campi obbligatori.
7. Testa in modalità ad alto contrasto e in modalità scura: Imposta il sistema operativo in modalità ad alto contrasto e ricarica la pagina. Le istruzioni codificate a colori che si riferiscono a colori specifici possono diventare ambigue o invisibili quando la resa dei colori cambia. Questo aiuta a far emergere un affidamento nascosto sul colore come unico indizio sensoriale.
8. Testa su una vista mobile con zoom o riflusso: Ridimensiona la finestra del browser a 320px di larghezza o usa un dispositivo mobile. Le istruzioni che usano un linguaggio posizionale come "barra laterale sinistra" o "navigazione superiore" dovrebbero rimanere significative quando il layout è rifluito in una singola colonna.

Come Correggere

Istruzioni per i campi del modulo basate solo sul colore — Non corretto

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Istruzioni per i campi del modulo basate solo sul colore — Corretto

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Riferimento posizionale al pulsante — Non corretto

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Riferimento posizionale al pulsante — Corretto

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Navigazione tramite icona basata solo sulla forma — Non corretto

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Navigazione tramite icona basata solo sulla forma — Corretto

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Segnale di avanzamento basato solo sull’audio — Non corretto

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Segnale di avanzamento basato solo sull’audio — Corretto

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Errori Comuni

• Scrivere "il pulsante rosso" o "il campo verde" come unico identificatore nelle istruzioni dei moduli o nel testo di aiuto, senza fornire anche l’etichetta visibile del pulsante o il nome del campo — questo viola sia 1.3.3 che 1.4.1.
• Usare frasi posizionali come "il menu a sinistra" o "il pannello in alto" nella documentazione di aiuto o nei flussi di onboarding senza nominare il menu o il pannello, rendendo le istruzioni inutili dopo che il riflusso responsive ha compattato il layout in una singola colonna.
• Descrivere le icone solo per forma ("fai clic sul pulsante di riproduzione triangolare") invece di usare il nome accessibile o l’etichetta dell’icona, che un utente di screen reader potrebbe effettivamente individuare tramite la navigazione da tastiera.
• Indicare i campi obbligatori del modulo esclusivamente tramite il colore del bordo o lo sfondo nelle istruzioni in linea ("i campi arancioni devono essere compilati") senza un simbolo, un suffisso nell’etichetta o l’attributo aria-required='true' per trasmettere la stessa informazione in modo programmatico.
• Fornire feedback solo audio per processi interattivi (caricamento di file, invio di moduli, scadenza di timer) senza un corrispondente aggiornamento visibile dello stato testuale tramite role='status' o aria-live='polite'.
• Usare la dimensione come unico indizio distintivo — istruzioni come "fai clic sulla scheda grande per espandere" falliscono quando l’utente effettua lo zoom, quando le schede vengono renderizzate con dimensioni identiche su viewport più piccoli o quando un utente di screen reader non ha alcun concetto delle dimensioni relative delle schede nel DOM.
• Fare affidamento su indizi di orientamento come "scorri orizzontalmente per navigare" senza fornire un metodo di interazione alternativo e un’etichetta non basata sull’orientamento per il carosello o lo slider descritto.
• Dimenticare che i messaggi di errore sono anch’essi istruzioni — un errore che dice "i campi evidenziati di seguito contengono errori" si basa sull’evidenziazione visiva e sulla prossimità posizionale, e sarà inutile per un utente di screen reader a meno che ogni campo errato non sia anche nominato esplicitamente nel messaggio di errore.
• Dare per scontato che aggiungere il testo alternativo di un’icona risolva l’istruzione — se il testo istruzionale continua a dire solo "fai clic sull’icona circolare", il fatto che l’icona abbia un testo alternativo sull’elemento immagine non rende l’istruzione conforme; il testo istruzionale stesso deve includere un identificatore non sensoriale.
• Trascurare le istruzioni iniettate dinamicamente nelle single-page application — tooltip, modali e passaggi guidati iniettati tramite JavaScript contengono spesso indicazioni basate solo su caratteristiche sensoriali che sfuggono alla revisione QA perché non sono visibili in un audit statico della pagina.

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 requisiti obbligatori di accessibilità web per un’ampia gamma di soggetti pubblici e privati operanti in Turchia. La circolare impone la conformità alle WCAG 2.1 Livello AA come standard di base, e WCAG 1.3.3 — in quanto criterio di Livello A — è quindi pienamente obbligatorio per tutti i soggetti interessati.

I soggetti coperti dalla circolare includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori 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 (MoNE). Le istituzioni pubbliche devono raggiungere la piena conformità entro un anno dalla data di pubblicazione della circolare, mentre ai soggetti del settore privato è concesso un periodo di due anni.

WCAG 1.3.3 è particolarmente rilevante per i servizi digitali turchi dato l’ampio uso di indicazioni nei moduli codificate a colori e di schemi di navigazione basati solo su icone nei portali di e-government turchi, nelle applicazioni bancarie e nei flussi di checkout dell’e-commerce. Ad esempio, un modulo di domanda online di un’istituzione pubblica che istruisce i cittadini a "compilare i campi contrassegnati in rosso" e a inviare "premendo il pulsante nell’angolo in basso a destra" sarebbe in diretta violazione del 1.3.3 e costituirebbe un mancato rispetto della Circolare Presidenziale. Allo stesso modo, l’interfaccia web mobile di una banca che guida gli utenti attraverso transazioni multi-step usando solo indizi posizionali e cromatici dovrebbe essere rivista prima della scadenza biennale prevista per il settore privato.

La non conformità comporta rischi reputazionali e legali man mano che l’ambiente normativo turco in materia di accessibilità digitale matura. I soggetti interessati dovrebbero considerare la conformità al 1.3.3 non come una piccola correzione redazionale, ma come una revisione sistemica di tutti i contenuti istruzionali — inclusi testo di aiuto, messaggi di errore, flussi di onboarding e documentazione di supporto — per garantire che i riferimenti sensoriali siano sempre accompagnati da identificatori stabili, programmatici e basati su testo. L’SDK di overlay di Accsible può aiutare a far emergere e a correggere molti problemi correlati, sebbene la revisione manuale dei contenuti richiesta dal 1.3.3 debba in ultima analisi essere eseguita da un revisore umano qualificato che lavori insieme agli strumenti automatici.