WCAG 3.2.6: Aiuto coerente

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 3.2.6 Aiuto Coerente (livello AA, introdotto in WCAG 2.2) afferma: «Se una pagina Web contiene uno qualsiasi dei seguenti meccanismi di aiuto, e tali meccanismi sono ripetuti su più pagine Web, essi compaiono nello stesso ordine relativo rispetto agli altri contenuti della pagina, a meno che il cambiamento non sia stato avviato dall’utente.» I meccanismi di aiuto coperti da questo criterio sono: dati di contatto umani (come un numero di telefono, un indirizzo email o gli orari di apertura), un meccanismo di contatto umano (come un widget di live chat o un modulo di contatto), un’opzione di auto-aiuto (come una pagina di domande frequenti, un help center o una knowledge base) e un meccanismo di contatto completamente automatizzato (come un chatbot o un assistente virtuale).

Il requisito chiave è la coerenza dell’ordine relativo, non il posizionamento identico in pixel. Se un pulsante di live chat appare nell’angolo in basso a destra della homepage, deve apparire nella stessa posizione in basso a destra in ogni altra pagina in cui è presente. Se un link “Help” è il terzo elemento nella barra di navigazione superiore in una pagina, deve rimanere il terzo elemento — o almeno mantenere la stessa relazione relativa con i contenuti circostanti — in tutte le altre pagine in cui compare quella barra di navigazione.

Una pagina rispetta questo criterio quando: (a) non esiste alcun meccanismo di aiuto sul sito, oppure (b) un meccanismo di aiuto esiste su una sola pagina, oppure (c) ovunque un meccanismo di aiuto sia ripetuto su più pagine, esso appare nello stesso ordine relativo all’interno del layout della pagina. Una pagina non rispetta il criterio quando un meccanismo di aiuto presente su più pagine cambia la sua posizione nell’ordine della pagina da una pagina all’altra senza che l’utente abbia avviato tale cambiamento — per esempio, un widget di chat che fluttua in basso a destra nella pagina di elenco prodotti ma si sposta in basso a sinistra nella pagina di checkout.

Il criterio include un’eccezione esplicita: l’ordine può cambiare se il cambiamento è avviato dall’utente. Per esempio, se un utente trascina e riposiziona un widget di aiuto flottante, o se una preferenza dell’utente sposta il pannello di aiuto da un lato all’altro, quel riposizionamento è avviato dall’utente e non costituisce una violazione. Questa eccezione rispecchia la stessa logica basata sull’azione dell’utente presente nel Criterio 3.2.2 (On Input).

È importante notare che questo criterio non richiede che ogni pagina abbia un meccanismo di aiuto, né che il meccanismo di aiuto sia efficace o facile da usare. Regola solo la coerenza del posizionamento quando il meccanismo è presente su più pagine.

Perché È Importante

Il posizionamento coerente dell’aiuto è pensato principalmente per favorire gli utenti con disabilità cognitive, inclusi coloro con deficit di memoria, difficoltà di attenzione, disturbi dell’apprendimento come la dislessia e condizioni come l’ADHD o la demenza in fase iniziale. Per questi utenti, individuare un elemento di interfaccia familiare richiede uno sforzo cognitivo deliberato. Quando un pulsante di aiuto o un link di contatto appare in una posizione diversa in ogni pagina, devono ripetere continuamente quello sforzo, aumentando il carico cognitivo e il rischio di frustrazione, disorientamento o abbandono del compito.

Gli utenti che sono nuovi al web o hanno una alfabetizzazione digitale limitata — una popolazione significativa in Turchia e a livello globale — si affidano anch’essi in modo marcato a un posizionamento prevedibile. Secondo l’Organizzazione Mondiale della Sanità, oltre 1,3 miliardi di persone nel mondo vivono con qualche forma di disabilità, e le condizioni cognitive e neurologiche rappresentano una quota sostanziale di tale popolazione. Progettare per la coerenza del posizionamento serve quindi un pubblico ampio, ben oltre le persone con disabilità clinicamente diagnosticate.

Consideriamo uno scenario concreto: una donna con Alzheimer in fase iniziale sta cercando di completare una prenotazione di volo online. Ricorda che il sito della compagnia aerea ha un’opzione di live chat che può usare quando si sente confusa. Nella pagina dei risultati di ricerca, l’icona della chat appare nell’angolo in basso a destra. Ma quando passa alla pagina di selezione del posto, il widget di chat è stato spostato nell’angolo in alto a destra all’interno di un pannello di aiuto comprimibile. Non riesce a trovarlo, si sente sopraffatta e abbandona completamente la prenotazione. Questo è un fallimento diretto e prevenibile del Criterio 3.2.6.

Per gli utenti con disabilità motorie che navigano con accesso a scansione, software di eye-tracking o puntatori a testa, il riposizionamento di un meccanismo di aiuto significa dover ri-esplorare e ri-puntare una nuova area dello schermo — un processo faticoso e dispendioso in termini di tempo che un posizionamento coerente elimina.

Gli utenti di screen reader che hanno memorizzato l’ordine di tabulazione o la struttura delle intestazioni di un sito per raggiungere rapidamente la sezione di aiuto sono ugualmente penalizzati quando l’ordine DOM di quel meccanismo cambia da una pagina all’altra, anche se la posizione visiva sembra simile.

Oltre all’accessibilità, esiste un chiaro vantaggio in termini di usabilità e di business: gli utenti che riescono a trovare rapidamente aiuto sono meno propensi ad abbandonare una transazione, riducendo i tassi di abbandono e i costi di supporto. Pattern di interfaccia coerenti rafforzano inoltre la fiducia nel brand e la percezione di professionalità.

Regole Axe-core Correlate

WCAG 3.2.6 è classificato come criterio che richiede solo test manuali e non ha una corrispondente regola automatizzata in axe-core che possa segnalare le violazioni in modo programmatico. Ciò è intenzionale, e comprenderne il motivo aiuta i tester ad apprezzare la natura di questo criterio.

• Ispezione manuale necessaria — nessuna regola axe disponibile: Strumenti automatizzati come axe-core, Lighthouse o IBM Equal Access Checker analizzano una singola pagina in isolamento. Non hanno una comprensione intrinseca di cosa sia un “meccanismo di aiuto”, nessuna capacità di confrontare la posizione relativa nel DOM di un elemento tra più caricamenti di pagina o URL, e nessun modo per determinare se un dato elemento svolge la funzione di fornire aiuto. Un widget di chat, per esempio, può essere implementato come un semplice <div>, un componente shadow DOM, un <iframe> o uno script iniettato da terze parti — nessuno dei quali può essere identificato in modo affidabile come “meccanismo di aiuto” da un motore di regole senza il giudizio umano. Axe-core avrebbe bisogno di consapevolezza dello stato tra pagine e di riconoscimento dell’intento semantico per segnalare questo tipo di problemi, capacità che esulano dall’ambito dell’analisi statica di una singola pagina. Per questo motivo, la stessa WCAG 2.2 classifica il Criterio 3.2.6 come un criterio che richiede valutazione umana tramite audit manuali strutturati e confronto tra pagine.

Come Eseguire i Test

1. Inventariare i meccanismi di aiuto: Prima di testare le singole pagine, crea un elenco di tutti i meccanismi di aiuto presenti sul sito — widget di live chat, numeri di telefono di contatto, link email, link alle FAQ, launcher di chatbot, moduli di contatto e link all’help center. Annota su quali pagine compare ciascun meccanismo. Se un meccanismo appare su una sola pagina, è fuori dall’ambito di questo criterio.
2. Eseguire una scansione automatizzata per un contesto di base: Usa axe DevTools (estensione del browser) o Lighthouse su pagine rappresentative per acquisire snapshot dell’ordine DOM e identificare la posizione strutturale degli elementi correlati all’aiuto. Sebbene nessuna regola axe prenda di mira direttamente il Criterio 3.2.6, l’ordine DOM riportato da questi strumenti può essere confrontato manualmente tra pagine. Esporta o acquisisci screenshot dell’albero di accessibilità per ogni pagina che contiene un meccanismo di aiuto.
3. Confrontare le posizioni relative tra pagine: Apri due o più pagine che condividono lo stesso meccanismo di aiuto affiancate (o in sequenza). Per ciascun meccanismo, identifica la sua posizione rispetto alle regioni di riferimento (<header>, <main>, <footer>, <nav>). Registra se il meccanismo appare nella stessa regione di riferimento e nello stesso ordine relativo (prima o dopo gli elementi adiacenti) in ogni pagina. Un cambiamento di posizione costituisce un potenziale fallimento.
4. Testare con la navigazione da tastiera (tutti i browser): Scorri con il tasto Tab ogni pagina che contiene un meccanismo di aiuto. Conta il numero di pressioni del tasto Tab necessarie per raggiungere il meccanismo di aiuto dall’inizio della pagina. Confronta questo conteggio tra pagine. Una differenza significativa — per esempio, raggiungibile in 5 tab nella homepage ma in 47 tab nella pagina di checkout — indica un cambiamento nell’ordine DOM anche se la posizione visiva sembra simile.
5. Testare con NVDA + Firefox: Apri la lista degli elementi di NVDA (tasto NVDA + F7) e passa alla vista Link o Pulsanti. Individua il meccanismo di aiuto nell’elenco. Annota la sua posizione rispetto agli altri elementi elencati. Ripeti su ogni pagina in cui il meccanismo appare e confronta le posizioni.
6. Testare con VoiceOver + Safari (macOS/iOS): Usa il rotor di VoiceOver (VO + U) per aprire l’elenco Link o Controlli modulo. Naviga fino al meccanismo di aiuto e annota la sua posizione nell’elenco. Confronta tra pagine.
7. Testare con JAWS + Chrome: Usa la lista dei link di JAWS (Insert + F7) per individuare il meccanismo di aiuto. Annota la sua posizione ordinale e gli elementi adiacenti. Ripeti tra pagine.
8. Verificare le eccezioni avviate dall’utente: Se il sito consente agli utenti di riposizionare o nascondere i meccanismi di aiuto (ad esempio un widget di chat trascinabile), verifica che il riposizionamento sia attivato da un’azione esplicita dell’utente e che la preferenza persista in modo logico. Documenta questo come un’eccezione valida ai sensi del criterio.
9. Verificare sui viewport mobili: I layout responsive talvolta riordinano gli elementi del DOM a diverse breakpoint. Esegui i test sia su viewport desktop sia mobili (larghezze di 375px e 1440px come minimo) per confermare che il meccanismo di aiuto mantenga un posizionamento relativo coerente a tutte le dimensioni di schermo più comuni.

Come Correggere

Widget di chat flottante — Non corretto

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Widget di chat flottante — Corretto

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Link di aiuto nella navigazione — Non corretto

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Link di aiuto nella navigazione — Corretto

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Visualizzazione condizionale dell’aiuto — Non corretto

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Visualizzazione condizionale dell’aiuto — Corretta

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Errori Comuni

• Posizionare il widget di chat in angoli diversi su diversi template di pagina: I team di sviluppo spesso applicano il posizionamento fisso dei widget di chat per singolo template anziché tramite un foglio di stile globale, facendo sì che il widget appaia in basso a destra nelle pagine di marketing e in basso a sinistra nelle pagine dell’applicazione. Usa un singolo componente incluso globalmente con una classe di posizione fissa.
• Rimuovere il link di aiuto dalla navigazione nelle pagine di checkout per ridurre il disordine: Alcuni pattern UX eliminano intenzionalmente la navigazione nelle pagine di checkout per ottimizzare le conversioni. Se un meccanismo di aiuto fa parte di quella navigazione, rimuoverlo da questo template di pagina rompe la coerenza. Invece, mantieni il link di aiuto in un header minimale anche nei flussi di checkout semplificati.
• Iniettare meccanismi di aiuto tramite script di terze parti che caricano con posizioni DOM imprevedibili: Molti SDK di live chat iniettano il loro widget nel DOM in modo asincrono, e il punto di inserimento può variare in base all’ordine di caricamento degli script. Questo può far apparire il widget in una posizione diversa nell’albero di accessibilità tra pagine. Configura i widget di terze parti affinché vengano sempre aggiunti a un elemento di ancoraggio DOM fisso e noto.
• Usare la proprietà CSS order o il riordino flexbox/grid per spostare visivamente l’elemento di aiuto senza cambiare l’ordine DOM, quindi modificare quel CSS per pagina: Sebbene la posizione visiva possa sembrare coerente, gli override CSS per pagina che alterano l’ordine visivo di un meccanismo di aiuto cambiano comunque l’ordine percepibile dall’utente e possono confondere gli utenti di screen reader il cui ordine di lettura segue il DOM.
• Affidarsi a strumenti di A/B testing che scambiano la posizione dell’elemento di aiuto tra varianti di test: Se gli utenti nella variante A vedono il pulsante di aiuto nella barra superiore e gli utenti nella variante B lo vedono nel footer, quegli utenti sperimenteranno un posizionamento dell’aiuto incoerente tra pagine all’interno della loro sessione, man mano che il framework di A/B testing applica varianti diverse su pagine diverse. Assicurati che i test A/B che influiscono sul posizionamento dei meccanismi di aiuto applichino la variante in modo coerente su tutte le pagine di una sessione.
• Considerare gli stati autenticato e non autenticato come “siti” diversi e applicare layout di aiuto differenti: Gli utenti che effettuano il login a metà sessione troveranno improvvisamente il meccanismo di aiuto in una nuova posizione. Il cambiamento di stato di autenticazione non è avviato dall’utente nel contesto del posizionamento dell’aiuto, quindi questo viola comunque il Criterio 3.2.6. Applica un layout di aiuto coerente in tutti gli stati di autenticazione.
• Inserire il numero di telefono di aiuto solo all’interno di testo denso nel footer in alcune pagine e in una barra dedicata nell’header in altre: Anche se il numero di telefono è tecnicamente presente in tutte le pagine, un cambiamento significativo nella sua posizione relativa (dal primo elemento interattivo nell’header a un elemento nascosto nel footer dopo centinaia di link) rappresenta una violazione della coerenza dell’ordine.
• Supporre che, poiché un’icona di aiuto è sempre visivamente “nell’angolo”, il criterio sia rispettato: Il criterio misura l’ordine relativo nel contenuto della pagina, non solo le coordinate di pixel assolute. Un’icona di chat che è sempre visivamente in basso a destra ma appare in un punto molto diverso dell’ordine DOM su pagine diverse (ad esempio, immediatamente dopo il tag <body> in una pagina e appena prima del tag di chiusura </body> in un’altra) può comunque rappresentare un problema per gli utenti che usano tastiera e screen reader.
• Dimenticare di verificare le breakpoint responsive: Un meccanismo di aiuto che è coerente alle larghezze desktop può essere nascosto o spostato in un menu hamburger mobile a viewport stretti, risultando in una posizione diversa su mobile. Se gli utenti mobile sperimentano una posizione relativa diversa rispetto agli utenti desktop, questo dovrebbe essere valutato rispetto al criterio — in particolare se il mobile è il metodo di accesso principale per il pubblico di destinazione.
• Non documentare le posizioni dei meccanismi di aiuto nei design system: Senza uno standard documentato su dove devono apparire i meccanismi di aiuto, singoli sviluppatori e designer prenderanno decisioni indipendenti che produrranno incoerenze nel tempo. Aggiungi regole esplicite sul posizionamento dei meccanismi di aiuto alla documentazione del tuo design system o della tua libreria di componenti.

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 un quadro nazionale completo per l’accessibilità digitale. La circolare impone la conformità a WCAG 2.2 livello AA come standard di accessibilità di base per un’ampia gamma di servizi digitali operanti in Turchia. Il Criterio di Successo WCAG 3.2.6 Aiuto Coerente, in quanto criterio di livello AA introdotto in WCAG 2.2, rientra direttamente nell’ambito di questo obbligo legale.

Le tipologie di entità coperte dalla Circolare Presidenziale 2025/10 includono: istituzioni e agenzie pubbliche sia a livello di governo centrale che locale; banche e fornitori di servizi finanziari regolati dall’Agenzia di Regolamentazione e Supervisione Bancaria (BDDK); piattaforme di e-commerce e marketplace online; ospedali e fornitori di servizi sanitari che offrono servizi digitali rivolti ai pazienti; compagnie di telecomunicazioni con 200.000 o più abbonati; agenzie di viaggio con sistemi di prenotazione online; società di trasporto privato che operano servizi di linea; e scuole e istituti di istruzione privati autorizzati dal Ministero dell’Istruzione Nazionale (MoNE). Per tutte queste entità, l’intero set di criteri WCAG 2.2 livello AA — incluso il Criterio 3.2.6 — è lo standard applicabile.

La conformità al Criterio 3.2.6 è anche un prerequisito per ottenere l’Erişilebilirlik Logosu (Logo di Accessibilità) rilasciato dal Ministero turco della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı). Questo logo funge da marchio ufficiale di conformità all’accessibilità ed è sempre più riconosciuto dai consumatori turchi e dai responsabili degli acquisti come segnale di qualità. Le organizzazioni che richiedono il logo devono dimostrare la piena conformità a WCAG 2.2 livello AA su tutte le loro proprietà digitali, il che significa che un posizionamento incoerente dell’aiuto — anche se apparentemente minore — può portare al rigetto della domanda.

Da un punto di vista pratico di conformità, il Criterio 3.2.6 è particolarmente rilevante per i fornitori turchi di servizi di e-commerce e finanziari, i cui siti web e web app mobili presentano tipicamente widget di live chat, link di contatto WhatsApp e sezioni FAQ come principali canali di supporto clienti. Garantire che questi meccanismi di aiuto compaiano in posizioni coerenti tra pagine di elenco prodotti, pagine del carrello, flussi di checkout e sezioni di gestione dell’account è sia un obbligo legale ai sensi della Circolare sia una buona pratica di UX per servire la diversificata base di utenti internet della Turchia — che include una vasta popolazione di utenti alle prime armi e con bassa alfabetizzazione digitale, che traggono il massimo beneficio da pattern di interfaccia prevedibili.

Le organizzazioni soggette alla Circolare che non hanno ancora verificato il posizionamento dei loro meccanismi di aiuto dovrebbero dare priorità a un audit di coerenza tra pagine come parte della loro roadmap di conformità a WCAG 2.2. Poiché questo criterio richiede test manuali, dovrebbe essere incluso sia negli audit di conformità iniziali sia nei cicli di assicurazione qualità continuativi, in particolare dopo importanti redesign o modifiche ai template che potrebbero spostare involontariamente la posizione degli elementi di aiuto.