Call to action su WordPress: progettate caso per caso, gestite con un solo componente

In sintesi: una CTA (call to action) è uno degli elementi più importanti di un sito web: è il punto in cui un visitatore decide se diventare un contatto, un cliente, un lettore fidelizzato. Per questo in PaperPlane progettiamo le CTA caso per caso: copy, posizionamento, gerarchia visiva e timing cambiano per ogni progetto. Sotto la parte progettuale, però, c’è un’infrastruttura unica. Flying, il nostro tema WordPress, gestisce con un componente unico tutti i sei comportamenti che una CTA può avere risolvendo a monte accessibilità, sicurezza e tracciamento:

• link interni ed esterni;
• download;
• mailto;
• copia-testo;
• aprire una modal;

Una call to action è il momento più delicato di una pagina. Tutto quello che viene prima — il copy, le immagini, la struttura dei contenuti, il design — serve a portare il visitatore fino a quel bottone. Lì si decide se la pagina ha funzionato. Eppure, su molti siti WordPress, le CTA sono trattate come un dettaglio tecnico: un pulsante inserito di fretta, con il colore del tema e poco altro pensiero attorno.

Per noi è esattamente il contrario. La progettazione delle CTA è una parte centrale del nostro lavoro di web design, e ogni progetto la affronta da capo.
Per un’impresa sociale, una CTA “Diventa volontario” ha un peso emotivo e una posizione molto diversi da un “Aggiungi al carrello” di un e-commerce o da un “Prenota una call” di una landing di servizi. Cambia il copy, cambia la gerarchia visiva, cambia il numero di CTA in pagina, cambia il momento in cui compaiono. Sono decisioni che prendiamo con il cliente, non con il tema.
Ma una volta prese, c’è una parte tecnica che non ha senso reinventare ogni volta: come quel bottone funziona davvero. Lì entra in scena Flying.

Cosa serve davvero a una CTA per funzionare bene

Pensa a una pagina tipica di un sito. C’è un bottone “Scopri il servizio” che porta a un’altra pagina. Più sotto, “Scarica il PDF” apre un documento. Nella sidebar, “Iscriviti alla newsletter” fa comparire un form in una finestra modale. In fondo, “Scrivici” lancia il client di posta.
Quattro bottoni, quattro comportamenti diversi. Su molti siti WordPress questi quattro bottoni vengono inseriti in quattro modi diversi: un plugin per le modal, uno shortcode per i download, un blocco Gutenberg per i pulsanti standard, magari un widget per il mailto.
Quattro interfacce di compilazione da imparare, quattro fonti di possibili errori, quattro cose da aggiornare separatamente. E ognuna fa l’accessibilità a modo suo — quando la fa.
Il risultato è un sito poco coerente: il bottone “Iscriviti” è giallo nella homepage e arancione nella sidebar perché viene da un plugin diverso, “Scarica” non fornisce informazioni puntuali per le tecnologie assistive, il link esterno non si apre come dovrebbe.
Piccole incoerenze che, sommate, raccontano un sito poco curato. E un sito poco curato converte meno.

Sei tipi di CTA, una sola interfaccia per chi pubblica

Su Flying tutte queste situazioni passano per lo stesso componente. Chi modifica una pagina vede sempre gli stessi campi: cosa deve dire il bottone (e se necessario con un testo dedicato per screen reader), dove deve portare, come deve aprirsi, che aspetto deve avere tra quelli previsti dal design del progetto. Il resto è automatico.

I sei comportamenti che il componente gestisce coprono quello che negli anni abbiamo imparato realizzando siti WordPress per i clienti:

• Link interno: porta a un’altra pagina, articolo o contenuto del sito. Chi pubblica seleziona il contenuto da un elenco a tendina, non scrive URL;
• Link esterno: porta a un altro sito. Si incolla l’URL e si sceglie se aprire nella stessa finestra o in una nuova;
• Download: scarica un file caricato nella libreria di WordPress. Tipicamente PDF, ma anche immagini, documenti, archivi;
• Mailto e copia-testo: il primo apre il client di posta dell’utente con l’indirizzo precompilato; il secondo copia negli appunti una stringa qualunque — IBAN, codici sconto, riferimenti fiscali, comandi tecnici nelle pagine di documentazione. Casi d’uso poco glamour ma sorprendentemente frequenti;
• Modal: apre una finestra di dialogo sopra la pagina. Tipicamente contiene un form, un video, un avviso, o un contenuto a comparsa che non vale una pagina intera;

Chi pubblica sceglie una di queste sei destinazioni da un menu, compila i due o tre campi che servono per quella destinazione specifica, e ha finito. Il bottone è online e funziona come deve, con il design pensato per quel progetto specifico e con la stessa solidità tecnica.

Le decisioni tecniche che chi pubblica non deve prendere

Qui sta il punto. Dietro la scelta apparentemente semplice di “dove porta questo bottone” ci sono almeno quattro decisioni tecniche che, su un sito fatto male, vengono lasciate a chi pubblica — o peggio, vengono saltate.

È un link o è un’azione? Un bottone che porta a un’altra pagina è semanticamente un link e deve essere un tag <a>. Un bottone che apre una modal o copia del testo è un’azione e deve essere un <button>. Sembra una sottigliezza, ma per chi naviga con tastiera o tecnologie assistive fa una differenza enorme: i link e i bottoni si comportano diversamente, e usare quello sbagliato confonde lo screen reader e rompe la navigazione da tastiera.

Sul componente di Flying, questa decisione la prende il codice in base alla destinazione scelta. Un link interno o esterno è un <a>; un’apertura di modal o una copia-testo è un <button>. Chi pubblica non è costretto a dover fare scelte tecniche.

Si apre nella stessa finestra o in una nuova? Per i link interni la risposta è quasi sempre “stessa finestra”: un sito che si apre in tab nuove a ogni clic interrompe la navigazione e abbassa le conversioni. Il componente lo gestisce automaticamente: se hai scelto un link interno, il target="_blank" nemmeno compare come opzione.

Servono attributi di sicurezza? I link a domini esterni che si aprono in una nuova finestra devono avere rel="noopener noreferrer", altrimenti il sito di destinazione può, in certi scenari, manipolare la pagina di origine. È una buona pratica documentata da anni, ma in tantissimi siti WordPress manca perché deve essere aggiunta a mano e ci si dimentica. Il componente la aggiunge automaticamente quando rileva un dominio diverso da quello del sito.

Come viene tracciato? Le CTA sono uno dei punti di misurazione più importanti di un sito. Sapere quali bottoni vengono cliccati, quanto e da dove, è la base per capire se la pagina sta funzionando e dove intervenire. Spesso le agenzie aggiungono il tracking degli eventi su Google Analytics a colpi di JavaScript inserito a mano in GTM, una CTA alla volta. Il nostro componente prevede un campo dedicato per la classe di tracciamento, che chi gestisce il sito può valorizzare per ogni singola CTA senza toccare GTM. Ogni bottone, se necessario, diventa misurabile per default.

Sull’accessibilità — la quarta grande decisione tecnica che chi pubblica non dovrebbe dover prendere — vale la pena spendere una sezione intera.

L’accessibilità che succede da sola

Immagina di pubblicare un link a un documento PDF su un sito istituzionale esterno, da aprire in una nuova finestra. Una situazione comunissima. Sul sito di un’agenzia governativa potrebbe essere “Scarica il modulo di domanda”.

Chi usa uno screen reader, quando arriva su quel bottone, dovrebbe sentire qualcosa di più di “Scarica il modulo di domanda, link”. Dovrebbe sentire anche che il link aprirà una nuova finestra, e che porta a un sito diverso da quello su cui si trova. Senza quell’informazione, il bottone è una piccola trappola: ci clicchi sopra e all’improvviso ti ritrovi in un contesto diverso, con la pagina di partenza scomparsa o nascosta in un altro tab che non sai gestire.

Il componente di Flying compone questo messaggio automaticamente. Genera uno span nascosto visivamente ma letto dagli screen reader:

<span class="screen-reader-text"> Si apre in una nuova finestra su un sito esterno</span>

Il testo cambia in base al contesto reale: “Si apre in una nuova finestra” se è una nuova finestra sullo stesso dominio, “Si apre su un sito esterno” se è un dominio diverso ma nella stessa finestra, “Si apre in una nuova finestra su un sito esterno” se entrambe le cose. Chi pubblica non scrive niente di tutto questo. Sceglie il dominio di destinazione e il comportamento della finestra, il componente costruisce il messaggio giusto.

La stessa cosa vale per le modal: quando il componente rende un bottone che apre una finestra di dialogo, aggiunge automaticamente l’attributo aria-haspopup="dialog", che avvisa le tecnologie assistive che quel bottone non porta a un’altra pagina ma apre un dialogo sovrapposto.

Sono dettagli. Ma sono i dettagli che separano un sito accessibile da un sito che dichiara di esserlo — e che, conversion-wise, separano una CTA che funziona per tutti da una che esclude silenziosamente una fetta dei tuoi visitatori.

Perché le modal sono native HTML5

Le finestre modali sono storicamente il caso più rognoso. Per anni si sono gestite con plugin WordPress dedicati o librerie JavaScript come Magnific Popup o Fancybox: codice in più da caricare, JavaScript che gira anche su pagine senza modal, gestione dell’accessibilità che varia da plugin a plugin.

Dal 2022 i browser moderni supportano nativamente l’elemento <dialog>, e le modal del nostro componente sono solo <dialog>, aperte con una riga: showModal(). Niente librerie da caricare, niente CSS di terze parti da sovrascrivere. La gestione del focus, la chiusura con il tasto Esc, l’overlay che oscura la pagina dietro: tutto gestito dal browser.

Il risultato è meno JavaScript trasmesso a ogni visita, pagine più leggere e un footprint ambientale più basso. Il discorso sui Core Web Vitals non si fa solo ottimizzando le immagini: si fa anche scegliendo strumenti che non aggiungono peso inutile.

Il design delle CTA: una decisione progettuale, non una scelta di tema

Vale la pena chiarire un punto, perché potrebbe sembrare che con un componente unico le CTA finiscano per somigliarsi tutte.
Non è così. Quello che Flying standardizza è la parte invisibile: il markup HTML, gli attributi di accessibilità, la sicurezza, il tracciamento.
Quello che non standardizza è l’aspetto, il copy, la posizione in pagina, il numero di CTA, il momento in cui compaiono, la gerarchia tra primarie e secondarie.
Tutta questa parte la progettiamo da capo per ogni progetto.

Per un sito istituzionale, può voler dire una sola CTA molto evidente per pagina, con un copy che invita a un dialogo.
Per un e-commerce, una struttura più articolata con primaria (acquista), secondaria (aggiungi alla wishlist) e terziaria (condividi).
Per una landing di servizi, una CTA fissa che segue lo scroll.
Per un sito del terzo settore, due CTA equilibrate — donazione e partecipazione — che convivono senza una vera gerarchia perché entrambe sono importanti.

Anche queste sono decisioni che nascono dalla nostra progettazione e dalla co-progettazione con il cliente: le validiamo nella fase di design, e poi le implementiamo nel tema custom del progetto.
Flying ci dà un componente solido che gestisce tutti i comportamenti possibili ma la casa la disegniamo ogni volta da capo.

Un limite reale: il primo setup richiede uno sviluppatore

Essere onesti fa parte del nostro modo di lavorare, quindi lo diciamo: questo approccio è semplicissimo da usare, ma il primo setup richiede uno sviluppatore.

I campi che chi pubblica vede nell’editor di WordPress — destinazione, URL, target, classe di tracciamento, aspetto grafico — li abbiamo modellati noi usando Advanced Custom Fields. Per aggiungere un settimo comportamento di CTA (immaginiamo: “apri WhatsApp con un messaggio precompilato”) non basta spuntare una casella in un pannello di amministrazione: serve toccare il codice del tema. Allo stesso modo, per cambiare l’aspetto grafico dei bottoni o aggiungere una nuova classe di stile, serve passare dal CSS del tema.

Per chi gestisce contenuti in autonomia, è la cosa più semplice del mondo. Per chi vuole costruire da zero un nuovo comportamento o uno stile inedito, serviamo noi. È un trade-off coerente con il nostro modello: i clienti che lavorano con noi a lungo non sono bloccati nel nostro tema, sono comodi nel nostro tema. È una differenza importante.

Semplicità per chi pubblica, manutenibilità per chi mantiene

Un componente unico per tutte le CTA del sito significa una cosa molto concreta dal punto di vista della manutenzione nel tempo: c’è un solo posto da aggiornare.

Quando le linee guida WCAG cambiano e introducono una nuova best practice, ed già successo più volte negli ultimi anni, ci basta intervenire su una funzione.
Quando un browser introduce un nuovo attributo di accessibilità, lo aggiungiamo in un punto e ne beneficiano tutte le CTA.
Quando vogliamo aggiungere un nuovo aspetto grafico previsto dal design di un progetto, lo aggiungiamo a un solo elenco di classi CSS.

Per i nostri clienti questo si traduce in qualcosa di poco visibile ma molto concreto: niente sorprese. Le CTA non si rompono quando aggiorniamo il sito, perché c’è un solo flusso da testare. Non c’è una pagina con le modal “vecchie” e una con le modal “nuove”, perché non esistono due implementazioni: ne esiste una sola, e si comporta allo stesso modo ovunque. Un sito coerente è un sito che invecchia meglio — e una CTA che funziona oggi continua a funzionare tra tre anni.

Da dove iniziare se hai un sito WordPress

Quattro domande concrete per valutare se le CTA del tuo sito stanno facendo bene il loro lavoro.

Primo: le tue CTA sono progettate, o sono “il bottone di default del tema”? Le CTA hanno un peso visivo coerente con la loro importanza? C’è una gerarchia chiara tra primarie e secondarie? Il copy parla a chi sta leggendo o è generico (“Invia”, “Clicca qui”)? Se la risposta è “sono uguali ovunque”, c’è probabilmente un margine di conversione lasciato sul tavolo.

Secondo: i bottoni che aprono qualcosa sono <button> o <a>? Fai clic destro su una CTA che apre una modal o copia del testo, e guarda l’HTML. Se è un <a href="#"> con del JavaScript appiccicato sopra, il sito sta trattando le azioni come navigazione: è un problema di accessibilità reale.

Terzo: chi usa uno screen reader sa che un link aprirà in una nuova finestra? Cerca uno span con classe screen-reader-text o equivalente accanto al testo del link. Se non c’è e il link apre _blank, lo screen reader leggerà solo il testo visibile, e l’utente si troverà spiazzato dall’apertura inattesa.

Quarto: per ogni tipo di CTA hai un plugin diverso? Apri l’elenco dei plugin attivi. Quanti riguardano bottoni, modal, popup, form, download manager? Se sono più di due, c’è probabilmente spazio per consolidare.

Le CTA si progettano, l’infrastruttura si costruisce una volta sola

Le call to action sono uno degli elementi più importanti per il successo di un sito web. Sono il punto in cui un visitatore decide se fare quel passo che il sito gli sta proponendo.
Per questo le trattiamo con la stessa cura con cui trattiamo il copy della homepage o la fotografia della pagina chi siamo: ogni progetto è un progetto a sé, ogni CTA è pensata per quel cliente e i suoi utenti.
Quello che cambia, da noi, è cosa succede sotto. La parte tecnica delle CTA — accessibilità, sicurezza, tracciamento, gestione delle finestre modali, semantica HTML — non la reinventiamo ogni volta. La risolve Flying, e si vede solo nel fatto che funziona.

Se vuoi capire come stanno performando le CTA del tuo sito attuale, e dove c’è margine di miglioramento — sia nel design che nella parte tecnica — scrivici. Una mezz’ora di chiacchierata può chiarire più di quanto pensi.