Accessibilità WCAG sui componenti di conversione: tooltip e CTA accessibili senza perdere efficacia

L'accessibilità non è un'aggiunta da fare dopo il design, è un layer che ridefinisce cosa significa "componente ben fatto". Su un sito editoriale italiano, i widget di conversione — tooltip, box prodotto, sticky CTA, modal — sono esattamente i punti dove l'accessibilità può essere facilmente rotta e dove il costo di una violazione WCAG si traduce anche in meno conversion, non solo in compliance a rischio. Con l'European Accessibility Act in vigore dal 28 giugno 2025 e con i CTR incrementali documentati sui siti accessibili, il tema è operativo, non filosofico.

Questa guida copre i criteri WCAG 2.2 che si applicano ai componenti di conversione, come renderli accessibili senza sacrificare efficacia, e il rapporto costo-beneficio reale dell'investimento in accessibilità.

Cosa copre WCAG 2.2 per i componenti di conversione

Criteri principali

1.4.3 Contrast (Minimum), livello AA Testo normale contrast ratio ≥ 4.5:1 contro lo sfondo. Testo large (≥ 18 pt regular o ≥ 14 pt bold) ≥ 3:1.

Tipico errore: link affiliati in sottolineatura dotted, colore grigio chiaro su fondo bianco. Contrast = 3.1:1, fail.

1.4.13 Content on Hover or Focus, livello AA Il contenuto mostrato all'hover/focus (tooltip, popover) deve essere:

• Dismissible: chiudibile con Esc o cliccando fuori, senza spostare il puntatore.
• Hoverable: il puntatore può muoversi sopra il contenuto senza farlo sparire.
• Persistent: rimane visibile finché hover/focus non si sposta o l'utente lo dismette.

Tipico errore: tooltip che sparisce dopo 2 secondi con timer. Fail.

2.1.1 Keyboard, livello A Ogni funzionalità disponibile via mouse deve essere disponibile via tastiera. Tab per navigare tra elementi interattivi, Enter/Space per attivare.

Tipico errore: link affiliato visualizzato come <span> con onclick JavaScript. Non raggiungibile con Tab.

2.4.7 Focus Visible, livello AA L'elemento con focus keyboard deve avere un indicatore visibile. L'outline di default del browser è accettabile; se rimosso (per ragioni estetiche), deve essere sostituito.

Tipico errore: CSS outline: none globale senza replacement.

2.5.8 Target Size (Minimum), livello AA (WCAG 2.2) Tap target ≥ 24 × 24 CSS pixels. Raccomandazione Google Web Fundamentals: ≥ 48 × 48.

Il criterio 2.5.5 Target Size (Enhanced), livello AAA, richiede invece ≥ 44 × 44 CSS pixels senza eccezioni di spaziatura.

Tipico errore: link affiliato in testo fluente senza padding, area tappable < 24 px in altezza.

3.2.1 On Focus, livello A Portare il focus su un elemento non deve causare un cambiamento di contesto (reindirizzamento, submission form, apertura modal).

Tipico errore: focus su un link apre un tooltip che ruba il focus, disorientando lo screen reader.

4.1.2 Name, Role, Value, livello A Ogni componente interattivo ha un nome accessibile, un ruolo, e i suoi stati (espanso/collassato, selezionato) sono esposti a tecnologie assistive.

Tipico errore: <div> con onclick senza role="button" né tabindex. Lo screen reader non lo riconosce come interattivo.

Implementazione accessibile di un tooltip

Markup

<span class="product-trigger"
      tabindex="0"
      role="button"
      aria-describedby="tooltip-sony-xm5"
      aria-expanded="false">
  Sony WH-1000XM5
</span>
<div id="tooltip-sony-xm5"
     role="tooltip"
     class="tooltip"
     hidden>
  Sony WH-1000XM5 — €349 · <a href="/out/sony-xm5">Vedi su Amazon</a>
</div>

Punti importanti:

• tabindex="0" rende il trigger focusable.
• role="button" informa lo screen reader.
• aria-describedby collega trigger e tooltip.
• aria-expanded riflette lo stato.
• Il tooltip ha role="tooltip".
• I link all'interno del tooltip sono nativamente <a> (non div onclick).

Interazione

trigger.addEventListener("click", openTooltip);
trigger.addEventListener("keydown", e => {
  if (e.key === "Enter" || e.key === " ") {
    e.preventDefault();
    openTooltip();
  }
});
document.addEventListener("keydown", e => {
  if (e.key === "Escape" && tooltipOpen) closeTooltip();
});
document.addEventListener("click", e => {
  if (tooltipOpen && !tooltip.contains(e.target) && !trigger.contains(e.target)) {
    closeTooltip();
  }
});

Punti importanti:

• Tastiera: Enter e Space attivano il trigger.
• Esc chiude (WCAG 1.4.13 Dismissible).
• Tap/click fuori chiude (pattern UX standard).
• Il tooltip è hoverable: muovere il mouse dal trigger al tooltip non lo chiude.
• Il tooltip non sparisce per timer.

Focus management

Punti delicati:

• Al click sul trigger, non spostare il focus nel tooltip. Il focus rimane sul trigger. Lo screen reader legge il contenuto via aria-describedby.
• Se il tooltip contiene un link attivo e l'utente vuole visitarlo, il Tab successivo dal trigger porta il focus al link del tooltip (se è aperto).
• Alla chiusura del tooltip, il focus resta sul trigger.

Implementazione di uno sticky CTA accessibile

<div role="complementary"
     aria-label="Acquisto prodotto consigliato"
     class="sticky-cta">
  <a href="/out/sony-xm5"
     class="sticky-cta-button">
    Vedi Sony WH-1000XM5 su Amazon
  </a>
  <button aria-label="Chiudi"
          class="sticky-cta-dismiss">
    ×
  </button>
</div>

• role="complementary" identifica il landmark.
• Il link è un <a> nativo, accessibile via Tab.
• Il pulsante di dismiss ha aria-label descrittivo.
• La X visiva deve essere contrastata ≥ 4.5:1.
• Lo sticky CTA deve essere dismissible con Tab + Enter sulla X.

Focus management nei modal

Se l'articolo apre un modal (es. newsletter signup dopo 80% scroll), il pattern WCAG è:

1. Al trigger, salvare l'elemento con focus precedente.
2. Aprire il modal, spostare il focus sul primo elemento interattivo dentro.
3. "Focus trap": Tab dall'ultimo elemento del modal torna al primo. Shift+Tab dal primo va all'ultimo.
4. Esc chiude il modal.
5. Alla chiusura, ripristinare il focus sull'elemento trigger originale.

Senza focus trap, lo screen reader "scappa" fuori dal modal mentre è ancora aperto visivamente, disorientando l'utente.

Contrast ratio: pattern comuni e numeri

Su siti editoriali italiani visti spesso:

• Link affiliato grigio-blu (#506890) su fondo bianco: ratio 4.7:1 → pass AA.
• Link affiliato grigio chiaro (#A0A0A0): ratio 2.8:1 → fail.
• Sottolineatura dotted 1 px grigia: visivamente debolissima, anche se il testo è contrastato non aiuta l'affordance.
• CTA arancione (#E78500) con testo bianco: ratio 3.6:1 → fail per testo normale, pass se bold 18 pt.

Usa i tool: WebAIM Contrast Checker, axe DevTools. La correzione è spesso uno shade in più di saturazione.

Ciò che AnchorLabs gestisce WCAG by default

AnchorLabs è progettato con questi pattern nativamente:

• Tooltip trigger con tabindex="0" e role="button".
• aria-describedby e aria-expanded esposti e aggiornati.
• Tooltip con role="tooltip", hoverable, persistent, dismissible via Esc e click-outside.
• Tap target ampliato (padding verticale per raggiungere 44-48 px altezza effettiva).
• Link <a> nativi all'interno del tooltip.
• Focus management: il focus rimane sul trigger, non viene rubato.
• Nessun timer di auto-dismiss.

I limiti onesti:

• Il contrast del tooltip dipende dal CSS custom del publisher. Se il publisher sovrascrive lo stile del tooltip con colori non contrastati, il fail è del publisher.
• La sottolineatura del trigger segue lo stile del tema. Se il tema usa dotted 1 px a basso contrast, l'affordance è debole. Può essere sovrascritta via CSS.
• Il publisher è responsabile di non rompere il pattern con CSS che rimuove outline dal :focus.

Per la guida operativa al setup WordPress, che include suggerimenti CSS per preservare WCAG, vedi AnchorLabs su WordPress. Per il contesto generale dei link affiliati e il loro stile, Aumentare il CTR sui link affiliati. Per il confronto tra formati di conversione rispetto alla pulizia UX, Link contestuali vs banner.

Il lato economico dell'accessibilità

Due studi pubblici chiave:

• Click-Away Pound 2019 (UK): gli e-commerce non accessibili perdono 17,1 miliardi di GBP all'anno per abbandono di utenti con disabilità.
• Forrester 2023: i siti con scoring di accessibilità superiore hanno conversion rate +12-24% vs peer non accessibili.

Ragioni pratiche:

• Coverage demografica: ~15% della popolazione ha una disabilità che impatta la fruizione web. Sui siti non accessibili, il 90%+ di questo gruppo abbandona.
• UX spillover: i pattern accessibili (tap target grandi, contrast alto, keyboard navigation) beneficiano tutti. In particolare gli utenti mobile in condizioni difficili (sole, stanchezza, fretta).
• SEO indiretto: Google non penalizza direttamente l'inaccessibilità ma penalizza pattern (mobile-unfriendly) che si sovrappongono.

ROI stimato di un audit WCAG + fix sui componenti principali per un editore medio: break-even in 4-8 mesi grazie al conversion uplift.

Da dove iniziare

1. Installa axe DevTools (Chrome extension, gratuita).
2. Audit di 3 articoli rappresentativi: trova tutti i fail WCAG AA.
3. Lista per priorità di impatto: tooltip broken > contrast fail > tap target > keyboard.
4. Fixa i top 5-10 fail: sono spesso modifiche CSS semplici.
5. Audit mensile delle nuove pubblicazioni.
6. Dopo 60 giorni, verifica il conversion delta.

Se stai costruendo nuovi widget di conversione, impostarli WCAG-compliant dal giorno uno è molto più economico che retrofittare. Se stai valutando widget di terze parti, chiedi esplicitamente ai vendor l'accessibility statement e verifica con axe prima dell'adozione.