Moduli6 min di lettura
Moduli accessibili: etichette, errori, tastiera
Che cosa rende un modulo online utilizzabile da tutti: etichette, gruppi, messaggi d’errore chiari, tastiera, focus e dimensioni dei target — secondo le WCAG 2.2.

Un servizio Spitex in Valle Maggia riceve le richieste tramite un modulo online: nome, indirizzo, prestazioni desiderate, un campo per le osservazioni. Un giorno telefona la figlia di una cliente. Sua madre vede male e ha provato a compilare il modulo con la lente d’ingrandimento dello schermo. Dopo l’invio la pagina era rossa, ma non è riuscita a capire che cosa non andava — il messaggio era in alto, ben fuori dalla parte ingrandita.
Per uno Spitex la cui clientela è spesso anziana, non è un caso marginale. Molti di questi ostacoli si possono evitare con alcuni principi descritti dal W3C.
Chi usa i moduli in modo diverso
Non tutti compilano un modulo con il mouse e lo sguardo. Alcune persone ascoltano lo schermo con un lettore di schermo, altre fanno tutto con la tastiera, ingrandiscono molto la visualizzazione o hanno bisogno di più tempo per capire le istruzioni. A ciò si aggiungono situazioni che possono capitare a chiunque: un braccio rotto, un telefono sotto il sole cocente, una lingua che non si conosce bene.
Le linee guida per l’accessibilità dei contenuti web (WCAG) del W3C sono il riferimento internazionale in materia. La versione 2.2 è stata pubblicata il 5 ottobre 2023. Il W3C ha pubblicato anche una guida dedicata ai moduli, aggiornata l’ultima volta nel marzo 2026.
Etichette
La guida del W3C parte dal principio di identificare ogni campo del modulo con un’etichetta, di
regola con l’elemento HTML label. L’etichetta è collegata al campo — un lettore di schermo la
legge non appena il campo viene raggiunto, e un clic sull’etichetta porta il cursore nel campo.
Le WCAG chiedono etichette o istruzioni quando è previsto un inserimento (criterio 3.3.2).
Un testo indicativo grigio nel campo, che scompare quando si digita, non sostituisce un’etichetta: appena qualcuno comincia a scrivere, non si vede più a che cosa serviva il campo.
La compilazione automatica
I browser possono inserire nome, indirizzo o indirizzo e-mail da dati salvati, se il modulo dice a che cosa serve un campo. Le WCAG chiedono che lo scopo dei campi relativi alla persona stessa possa essere determinato in modo programmatico (criterio 1.3.5). Per chi fa fatica a digitare, ciò risparmia molto lavoro — e anche gli errori di battitura nell’indirizzo.
Gruppi
Alcuni campi vanno insieme, per esempio la scelta delle prestazioni — Cure di base, Aiuto
domestico, Servizio pasti — o la domanda «Chi compila il modulo?». La guida del W3C raccomanda di
raggrupparli con gli elementi fieldset e legend. Una persona che usa un lettore di schermo
non sente allora solo «Aiuto domestico, casella di controllo», ma anche a quale domanda si
riferisce.
Istruzioni al posto giusto
La guida del W3C raccomanda di dare indicazioni che aiutino a compilare il modulo — per il modulo intero e per i singoli campi. Decisivo è il posto: un’indicazione sul formato di una data va prima del campo, non solo nel messaggio d’errore. E i campi obbligatori sono contrassegnati in modo riconoscibile anche senza colore, per esempio con la parola «obbligatorio».
Messaggi d’errore che aiutano
La madre della donna che ha telefonato si è arenata in un punto tipico. Le WCAG chiedono che un errore di inserimento rilevato venga segnalato e descritto sotto forma di testo (criterio 3.3.1) e che, se possibile, venga proposto un suggerimento per correggerlo (criterio 3.3.3). Inoltre un’informazione non deve essere trasmessa solo attraverso il colore (criterio 1.4.1).
Per lo Spitex, in pratica, significa:
- Il messaggio si trova accanto al campo interessato, non solo in cima alla pagina.
- Dice che cosa manca o che cosa è sbagliato — «Inserisca un NPA di quattro cifre» invece di «Inserimento non valido».
- I campi già compilati restano compilati.
- Un bordo rosso da solo non basta; ci vuole un testo, o un simbolo accompagnato da un testo.
Tastiera e focus
Un modulo deve poter essere usato interamente con la tastiera (criterio 2.1.1): da un campo all’altro con il tasto di tabulazione, le scelte con i tasti freccia, l’invio con il tasto Invio. Dove si trova il focus in quel momento deve essere visibile (criterio 2.4.7).
Le WCAG 2.2 aggiungono un nuovo criterio: quando un elemento riceve il focus della tastiera, dovrebbe essere almeno in parte visibile e non coperto da altri contenuti (criterio 2.4.11) — per esempio da una barra informativa sui cookie o da un’intestazione fissa.
Abbastanza spazio per toccare
Conta anche la dimensione degli elementi di comando. Con il nuovo criterio 2.5.8, le WCAG 2.2 chiedono che i target abbiano una dimensione minima — 24 × 24 pixel CSS — o una distanza sufficiente dagli altri target. Piccole caselle di controllo fitte una sotto l’altra sono difficili da colpire per chi ha le mani tremanti o su uno schermo piccolo.
Non chiedere due volte
Un altro nuovo criterio delle WCAG 2.2 riguarda direttamente i moduli: le informazioni che una persona ha già inserito nello stesso procedimento non dovrebbero essere richieste di nuovo (criterio 3.3.7). Chi ha già indicato l’indirizzo della cliente non deve ridigitarlo per l’indirizzo di fatturazione — basta un «come sopra».
E al momento dell’accesso nessuno dovrebbe dover risolvere un enigma, ricordare qualcosa o ricopiare qualcosa (criterio 3.3.8). Come proteggere i moduli dallo spam senza simili ostacoli lo descrive l’articolo Spam nei moduli di contatto.
Moduli lunghi
Per i moduli lunghi, la guida del W3C raccomanda di suddividerli in più passi più brevi e di informare sull’avanzamento — «Passo 2 di 4». Ciò aiuta tutti, ma soprattutto le persone che hanno bisogno di più tempo o che devono interrompersi a metà.
Che cosa vale in Svizzera
La legge sui disabili chiede alle autorità che le loro prestazioni via internet siano accessibili agli ipovedenti senza difficoltà (art. 14 cpv. 2 LDis) e vieta ai privati che forniscono prestazioni al pubblico di trattare una persona in modo discriminatorio a causa della sua disabilità (art. 6 LDis). Nella versione 3.0, lo standard di governo elettronico eCH-0059 si basa sulle WCAG 2.1 e si applica in primo luogo agli enti pubblici e alle imprese concessionarie. Quali obblighi valgano per una data organizzazione dipende dal suo ruolo.
Per lo Spitex in Valle Maggia
Lo Spitex fa rielaborare il suo modulo: ogni campo ha un’etichetta visibile, le prestazioni sono raggruppate, i messaggi d’errore si trovano accanto al campo e dicono che cosa fare. Il modulo si compila con la tastiera, il focus è ben visibile e l’indirizzo di fatturazione si riprende con un segno di spunta. La figlia della cliente l’ha riprovato con sua madre.
Nell’app Moduli che stiamo sviluppando, le risposte verranno cifrate nel browser di chi risponde e torneranno leggibili solo presso la destinataria. Quali criteri di accessibilità soddisferanno i moduli dell’app lo descriveremo sulla sua pagina non appena sarà lanciata.
Fonti
- 1.W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (verificato il 25 settembre 2026)
- 2.W3C WAI: What’s New in WCAG 2.2 (verificato il 25 settembre 2026)
- 3.W3C WAI: Forms Tutorial (aktualisiert 27. März 2026) (verificato il 25 settembre 2026)
- 4.Behindertengleichstellungsgesetz (BehiG, SR 151.3) (verificato il 25 settembre 2026)
- 5.eCH-0059 Accessibility Standard V3.0 (verificato il 25 settembre 2026)
SchweizerformDa questa idea è nata Schweizerform.
Moduli online crittografati end-to-end, realizzati e ospitati in Svizzera.