WCAG 3.3.5: Aiuto

Cosa Significa Questa Regola

\n

Il Criterio di Successo WCAG 3.3.5 Help (Livello AAA) afferma: \"È disponibile un aiuto sensibile al contesto.\" Questo significa che ovunque una pagina web o un’applicazione chieda agli utenti di inserire informazioni, deve essere fornito un aiuto appropriato per chiarire cosa è richiesto. L’aiuto deve essere contestuale — cioè deve riferirsi direttamente al campo, al compito o al processo con cui l’utente sta interagendo in quel momento, invece di essere una pagina di aiuto generica nascosta da qualche parte nella navigazione.

\n

Il criterio si applica a qualsiasi componente dell’interfaccia utente che richieda un input: campi di testo, menu a discesa, selettori di data, controlli di caricamento file, caselle di controllo, pulsanti di opzione e moduli a più passaggi. L’aiuto sensibile al contesto può assumere molte forme, tra cui istruzioni in linea, etichette descrittive, indicazioni nei placeholder, tooltip, icone di aiuto che espandono spiegazioni, link ad articoli di aiuto pertinenti o persino supporto via chat dal vivo — purché l’aiuto sia disponibile in prossimità dell’input che lo richiede.

\n

Si ottiene un superamento quando è presente almeno uno dei seguenti elementi per ogni input che potrebbe causare confusione all’utente: un’etichetta chiaramente scritta che spiega completamente l’input previsto; testo descrittivo supplementare adiacente al campo (non solo un placeholder, che scompare durante la digitazione); un link di aiuto visibile o un tooltip espandibile che fornisce ulteriori spiegazioni; oppure un meccanismo di aiuto facilmente accessibile (come un’icona con un punto interrogativo) che rivela indicazioni specifiche per il contesto corrente. L’aiuto non deve essere identico per tutti i campi — il requisito fondamentale è che ovunque l’utente possa essere incerto su cosa inserire, l’aiuto sia realmente disponibile e accessibile.

\n

Si ha un fallimento quando i campi non forniscono alcuna spiegazione su ciò che è richiesto, quando l’aiuto è disponibile solo dopo l’invio e il verificarsi di un errore, quando i tooltip o i testi di aiuto non sono accessibili agli utenti di tastiera o di screen reader, o quando i link di aiuto portano a una pagina FAQ generale invece che a contenuti pertinenti allo specifico input. È fondamentale capire che affidarsi esclusivamente ai messaggi di errore a posteriori non soddisfa questo criterio — l’aiuto deve essere disponibile prima o durante l’inserimento, non solo dopo che è stato commesso un errore.

\n

WCAG 3.3.5 non definisce un unico metodo di implementazione rigido. Riconosce che l’aiuto sensibile al contesto può essere implementato in molti modi validi, offrendo flessibilità agli sviluppatori, ma l’intento è inequivocabile: gli utenti non dovrebbero mai essere lasciati a indovinare cosa si aspetta un campo di un modulo. Non esistono eccezioni ufficiali a questo criterio — si applica universalmente ovunque venga richiesto un input da parte dell’utente.

\n\n

Perché È Importante

\n

I moduli sono tra le parti più impegnative di qualsiasi interfaccia digitale. Per gli utenti con disabilità cognitive — inclusi coloro con dislessia, disturbi dell’attenzione, disabilità intellettive o deficit di memoria — campi di modulo ambigui possono costituire una barriera insormontabile. Senza un aiuto chiaro e contestuale, questi utenti possono fallire ripetutamente nel completare i compiti, provare una notevole frustrazione o abbandonare del tutto il processo. Secondo l’Organizzazione Mondiale della Sanità, circa 1 persona su 6 nel mondo vive con una forma significativa di disabilità, e le compromissioni cognitive rappresentano una parte sostanziale di questa popolazione.

\n

Gli utenti con bassa alfabetizzazione digitale o con esperienza limitata delle interfacce web traggono anch’essi enormi benefici dall’aiuto sensibile al contesto. Un utente alla prima esperienza con un portale di servizi e-government, una persona anziana che fa domanda online per un sussidio sanitario o un piccolo imprenditore che compila un modulo fiscale potrebbero non sapere quale formato sia richiesto per un numero di identificazione fiscale, quali tipi di file siano accettati per il caricamento dei documenti o cosa rappresenti la differenza tra due campi con nomi simili. Senza una guida nel contesto, questi utenti sono esposti a errori e all’ansia di non sapere cosa abbiano sbagliato.

\n

Consideriamo uno scenario concreto: una persona con una disabilità cognitiva sta facendo domanda per un abbonamento agevolato ai trasporti tramite il portale web dell’autorità di trasporto municipale. Il modulo chiede un “Numero di riferimento” senza alcuna spiegazione. L’utente ha più documenti — la carta d’identità nazionale, la tessera di trasporto e una precedente conferma di domanda — ciascuno con diversi identificativi numerici. Senza un aiuto sensibile al contesto che indichi quale documento specifico o quale formato sia richiesto, è probabile che l’utente inserisca il numero sbagliato, attivi un errore di validazione e potenzialmente rinunci. Se fosse stata presente una semplice icona di aiuto o una descrizione in linea — “Inserisci il numero di 10 cifre nell’angolo in alto a destra della tua tessera di trasporto” — l’intera interazione avrebbe avuto successo al primo tentativo.

\n

Per gli utenti che sono ciechi o ipovedenti, l’aiuto sensibile al contesto è altrettanto importante. Gli screen reader possono annunciare il testo di aiuto associato, le descrizioni aria-describedby o i contenuti di aiuto collegati, ma solo se questi sono implementati correttamente. Quando l’aiuto è trasmesso esclusivamente in modo visivo (come un indicatore di colore o un’icona senza testo accessibile), gli utenti di screen reader vengono esclusi. Garantire che l’aiuto sia sia presente sia accessibile rafforza l’inclusività per tutti i gruppi di persone con disabilità.

\n

Oltre all’accessibilità, l’aiuto sensibile al contesto migliora l’usabilità complessiva e i tassi di conversione. I siti web con indicazioni chiare nei moduli registrano tassi di abbandono più bassi, meno richieste di supporto e tassi di completamento dei moduli più elevati. In particolare per i siti di e-commerce, ogni punto percentuale di miglioramento nel completamento del checkout ha un impatto diretto sui ricavi. I motori di ricerca premiano anche le pagine con contenuti chiari e strutturati, e moduli ben etichettati e ben descritti contribuiscono positivamente ai segnali di qualità della pagina.

\n\n

Regole Axe-core Correlate

\n

WCAG 3.3.5 richiede test manuali perché la sua conformità dipende dalla qualità, dalla pertinenza e dall’adeguatezza contestuale dei contenuti di aiuto — fattori che gli strumenti automatizzati non possono valutare. Uno scanner automatico può confermare che esiste un’etichetta o che un attributo aria-describedby punta a un elemento reale, ma non può determinare se il contenuto di quell’etichetta o descrizione sia effettivamente utile, accurato o sufficiente per un determinato input.

\n

\n
• Revisione manuale — Presenza di aiuto sensibile al contesto: Gli strumenti automatizzati non possono valutare se il testo di aiuto risponde davvero alle probabili domande dell’utente su uno specifico campo. Uno strumento può rilevare che esiste un elemento <label>, ma non può giudicare se “Inserisci il tuo numero” sia sufficientemente descrittivo per un campo che si aspetta un numero di partita IVA in un formato specifico. I tester manuali devono valutare se ogni input che potrebbe causare confusione è accompagnato da indicazioni che riducono in modo significativo tale confusione.
\n
• Revisione manuale — Accessibilità dell’aiuto: Anche se l’aiuto è visivamente presente, gli strumenti automatizzati potrebbero non segnalare i casi in cui tale aiuto non è accessibile alle tecnologie assistive. Ad esempio, un tooltip attivato solo al passaggio del mouse, senza un equivalente accessibile da tastiera, supera molti controlli automatizzati ma fallisce per gli utenti reali. I tester devono verificare che tutti i meccanismi di aiuto — tooltip, sezioni espandibili, link di aiuto — siano raggiungibili e utilizzabili tramite tastiera e siano annunciati correttamente dagli screen reader.
\n
• Revisione manuale — Posizionamento e prossimità dell’aiuto: Le scansioni automatizzate non possono valutare se il testo di aiuto è posizionato abbastanza vicino al campo pertinente da essere associato in modo significativo ad esso. Un paragrafo di aiuto in fondo alla pagina, o in una finestra modale che richiede più interazioni per essere raggiunta, può esistere tecnicamente ma non soddisfa lo spirito dell’aiuto sensibile al contesto. La revisione manuale deve confermare che l’aiuto sia disponibile nel punto in cui serve.
\n
• Revisione manuale — Completezza rispetto alla complessità del modulo: I moduli complessi e a più passaggi introducono ulteriori sfide. Gli strumenti automatizzati controllano i singoli campi in isolamento ma non possono valutare se l’insieme degli aiuti forniti lungo un wizard multi-step sia sufficiente a guidare un utente attraverso un processo complesso. Sono necessari walkthrough manuali per identificare lacune nella guida che diventano evidenti solo vivendo il modulo nel suo complesso.
\n

\n\n

Come Eseguire i Test

\n

\n
1. Esegui una scansione automatizzata di accessibilità come base. Usa axe DevTools (estensione del browser o CLI), Lighthouse in Chrome DevTools o IBM Equal Access Checker sulla pagina che contiene il modulo. Sebbene questi strumenti non segnaleranno direttamente violazioni del 3.3.5, faranno emergere problemi correlati come etichette mancanti (elemento label non associato a un input), destinazioni aria-describedby mancanti o implementazioni di tooltip inaccessibili. Risolvere prima questi problemi di base garantisce che, quando viene aggiunto l’aiuto sensibile al contesto, esso sia anche tecnicamente accessibile.
\n
2. Verifica manualmente ogni campo del modulo per la disponibilità di aiuto. Per ciascun campo di input, chiediti: (a) L’etichetta da sola spiega completamente quale input è richiesto, incluse eventuali esigenze di formato? (b) È presente un testo di aiuto supplementare visibile adiacente al campo? (c) C’è un’icona di aiuto, un tooltip o una sezione espandibile che fornisce ulteriori indicazioni? (d) C’è un link a contenuti di aiuto pertinenti? Se la risposta a tutte queste domande è no, e il campo presenta qualsiasi ambiguità, si tratta di un fallimento del 3.3.5.
\n
3. Verifica l’accessibilità da tastiera di tutti i meccanismi di aiuto. Spostati nel modulo usando solo la tastiera (senza mouse). Verifica che ogni tooltip, icona di aiuto, descrizione espandibile o link di aiuto sia raggiungibile e attivabile tramite tastiera. I tooltip dovrebbero apparire sia al focus sia al passaggio del mouse. I pulsanti di aiuto dovrebbero essere attivabili con Invio o Barra spaziatrice. Qualsiasi meccanismo di aiuto raggiungibile solo con il mouse fallisce questo test.
\n
4. Testa con NVDA + Firefox. Naviga fino a ciascun campo del modulo usando Tab. Ascolta cosa annuncia NVDA per ogni campo — annuncia l’etichetta? Annuncia eventuali descrizioni associate (tramite aria-describedby)? Attiva eventuali icone di aiuto o tooltip e conferma che il loro contenuto venga annunciato. Prova a raggiungere i contenuti di aiuto collegati e verifica che siano pertinenti al campo corrente.
\n
5. Testa con VoiceOver + Safari (macOS o iOS). Usa VoiceOver per navigare nel modulo. Su macOS, usa Tab per spostarti tra i campi e ascolta l’annuncio completo per ciascuno. Su iOS, usa la navigazione tramite swipe. Verifica che tutti i contenuti di aiuto associati agli input vengano letti ad alta voce e che i trigger di aiuto (pulsanti, link) siano accessibili e correttamente etichettati da VoiceOver.
\n
6. Testa con JAWS + Chrome. Usa la modalità moduli di JAWS (attivala con Invio quando sei su un elemento del modulo). Naviga tra i campi con Tab e verifica che JAWS legga le istruzioni e le descrizioni associate. Usa il cursore virtuale di JAWS per controllare che anche i contenuti di aiuto posizionati al di fuori delle associazioni standard delle etichette siano raggiungibili.
\n
7. Conduci un walkthrough cognitivo. Chiedi a una persona non familiare con il modulo (o simula questo effetto rivedendo il modulo dopo una pausa) di provare a completarlo senza alcuna guida esterna. Annota ogni punto in cui esita, fa una domanda o commette un errore a causa di aspettative poco chiare. Ciascuno di questi punti è un candidato per un miglioramento dell’aiuto sensibile al contesto ai sensi del 3.3.5.
\n

\n\n

Come Correggere

\n

Campo di testo ambiguo senza spiegazione — Non corretto

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Campo di testo ambiguo con aiuto in linea — Corretto

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Tooltip dell’icona di aiuto inaccessibile agli utenti di tastiera — Non corretto

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Tooltip dell’icona di aiuto accessibile a tutti gli utenti — Corretto

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Modulo complesso a più passaggi senza guida a livello di passaggio — Non corretto

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Modulo complesso a più passaggi con aiuto contestuale per il passaggio — Corretto

\n\n

(Content truncated due to token limit — please retry this article.)