Moduli di contatto accessibili e l’Atto europeo sull’accessibilità

Un modulo di contatto è spesso l’unica porta tra un visitatore e la Sua attività. Se quella porta si apre solo con un mouse, una buona vista e la pazienza di risolvere un rompicapo con un’immagine sfocata, alcune persone restano semplicemente fuori. Dalla metà del 2025 non è più solo una questione di usabilità: per molte imprese che vendono ai consumatori nell’UE è diventata una questione giuridica.

Che cosa riguarda l’Atto europeo sull’accessibilità

L’Atto europeo sull’accessibilità (direttiva (UE) 2019/882) si applica dal 28 giugno 2025. Stabilisce requisiti di accessibilità per determinati prodotti e servizi offerti ai consumatori – tra cui commercio elettronico, servizi bancari per i consumatori, libri elettronici, comunicazioni elettroniche e parti del trasporto passeggeri. Per un sito web, ciò significa il negozio online o il servizio bancario nel suo insieme, compresi i moduli che i clienti usano per contattarLa, porre domande o presentare reclami. Le microimprese che forniscono servizi sono esentate: imprese con meno di dieci dipendenti e un fatturato annuo o un totale di bilancio non superiore a 2 milioni di EUR. Le offerte rivolte esclusivamente ad altre imprese sono in genere al di fuori del suo ambito di applicazione.

Ogni Stato membro ha recepito la direttiva nel diritto nazionale. In Germania si tratta del Barrierefreiheitsstärkungsgesetz (BFSG), in Polonia di una legge del 2024 volta a garantire che determinati prodotti e servizi soddisfino i requisiti di accessibilità. Autorità di vigilanza e sanzioni variano da paese a paese, ma il parametro tecnico è sostanzialmente lo stesso: nella pratica la norma europea EN 301 549, che a sua volta si basa sulle Web Content Accessibility Guidelines (WCAG).

Perché conviene anche senza obbligo di legge

Forse la Sua impresa è esentata, oppure serve solo altre aziende. I moduli accessibili valgono comunque la pena, per una ragione semplice: ogni persona che rinuncia a metà è una richiesta che non riceverà mai. Gli interventi che aiutano chi usa uno screen reader aiutano anche chi compila il modulo sullo smartphone in treno, sotto il sole, con un polso rotto o in una seconda lingua. Etichette chiare e messaggi di errore utili significano meno moduli abbandonati per tutti – e nessuno di questi interventi indebolisce la Sua protezione antispam.

Una checklist pratica con riferimenti alle WCAG 2.2

• Etichette visibili collegate ai relativi campi (1.3.1, 3.3.2): ogni campo ha un’etichetta visibile collegata tramite for/id. Un placeholder da solo non è un’etichetta – scompare non appena si inizia a digitare.
• Messaggi di errore che spiegano come correggere (3.3.1, 3.3.3): indichi il campo, dica che cosa non va e come correggerlo – con un testo, non solo con un bordo rosso. “Inserisca un indirizzo e-mail come nome@example.com” è meglio di “Inserimento non valido”.
• Utilizzo completo da tastiera (2.1.1, 2.1.2): ogni campo, casella di controllo, CAPTCHA e il pulsante di invio possono essere raggiunti e utilizzati con Tab, Spazio e Invio, senza trappole per la tastiera.
• Focus visibile (2.4.7): si vede sempre quale campo è attivo. Rimuovere il contorno di focus del browser senza sostituirlo non soddisfa questo criterio.
• Contrasto sufficiente (1.4.3): testi, etichette e messaggi di errore hanno un rapporto di contrasto di almeno 4,5:1 rispetto allo sfondo (3:1 per il testo di grandi dimensioni).
• Dimensione dei target (2.5.8): pulsanti, caselle di controllo e link misurano almeno 24 × 24 pixel CSS, oppure hanno sufficiente spazio attorno.
• Alternative ai CAPTCHA (1.1.1) e autenticazione accessibile (3.3.8): l’1.1.1 richiede un’alternativa testuale e il CAPTCHA in più di una forma sensoriale; il 3.3.8 riguarda in senso stretto le fasi di accesso, ma la sua idea è trasferibile – un rompicapo come ridigitare lettere distorte o risolvere una somma non dovrebbe essere l’unica strada. Offra un’alternativa o utilizzi un metodo che non richieda alcun rompicapo.
• Honeypot nascosti alle tecnologie assistive: il campo trappola riceve aria-hidden="true" sul suo contenitore e tabindex="-1", così che gli utenti di screen reader e tastiera non vi finiscano mai.

CAPTCHA e honeypot: dove la protezione antispam incontra l’accessibilità

A rigore, il criterio 3.3.8 riguarda le fasi di accesso e autenticazione, non i moduli di contatto. L’idea che vi sta dietro, però, è ben trasferibile: digitare lettere distorte, risolvere una somma o individuare semafori in una griglia di immagini esclude completamente alcune persone. Le opzioni che di solito funzionano senza alcun rompicapo – come Cloudflare Turnstile, Friendly Captcha, un honeypot combinato con un controllo dei tempi o un filtro lato server come Akismet – tengono lontano lo spam senza chiedere ai visitatori di dimostrare nulla. Un honeypot è accessibile solo se è davvero invisibile, anche per gli utenti di screen reader e di tastiera:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Lasciare vuoto questo campo</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Testi il Suo modulo in quindici minuti

1. 1Metta da parte il mouse e compili l’intero modulo usando solo la tastiera. Riesce a raggiungere ogni campo e il pulsante di invio, e vede sempre dove si trova?
2. 2Invii il modulo vuoto, poi con un indirizzo e-mail errato. Gli errori compaiono come testo accanto al campo giusto, ed è chiaro che cosa fare?
3. 3Apra la pagina su uno smartphone o ingrandisca il browser al 200%. È tutto leggibile, i pulsanti sono facili da toccare, e un banner dei cookie o un widget di chat coprono il pulsante di invio?
4. 4Attivi uno screen reader (VoiceOver, NVDA o TalkBack) e ascolti: ogni campo viene annunciato con la sua etichetta, e l’honeypot resta muto?
5. 5Esegua un controllo automatico come axe-core. Trova rapidamente etichette mancanti e problemi di contrasto, ma non tutto – i passaggi manuali descritti sopra restano necessari.

Se preferisce iniziare con una panoramica, formexposed esamina i Suoi moduli pubblici dall’esterno, senza inviare nulla. I suoi controlli di accessibilità eseguono axe-core su ciascun modulo, segnalano CAPTCHA privi di un’alternativa accessibile e honeypot annunciati dagli screen reader, ed esaminano il modulo su smartphone – target di tocco, elementi sovrapposti che coprono il pulsante di invio, scorrimento orizzontale. La verifica gratuita mostra il livello complessivo; questi dettagli sono nel report completo. È un buon punto di partenza per la lista qui sopra, non un sostituto dei test con persone reali.