Login, password reset e CAPTCHA: come rendere accessibile l’autenticazione senza bloccare gli utenti

Parliamo del tuo progetto →

Se il login costringe una persona a ricordare, trascrivere o reinserire dati già forniti, oppure la blocca su un CAPTCHA senza alternativa, il problema non è solo tecnico: è un ostacolo all’accesso. WCAG 2.2, pubblicata come Recommendation il 5 ottobre 2023, ha reso più espliciti proprio i punti che toccano questo flusso: aiuto coerente, assenza di inserimenti ridondanti e autenticazione accessibile (What’s New in WCAG 2.2).

La domanda pratica è semplice: il nostro flusso di accesso aiuta davvero a entrare e recuperare l’account, oppure chiede di rifare passi inutili e di superare test che non tutti possono completare?

Quando questa verifica serve davvero

Questo controllo è utile se il vostro sito, portale o SaaS ha almeno una di queste caratteristiche:

  • login con password e reset separato;
  • verifica email o OTP dopo l’accesso;
  • link di supporto, chat o FAQ che compaiono in più schermate;
  • CAPTCHA o altro test anti-bot nel percorso di autenticazione;
  • dati già inseriti che vengono richiesti di nuovo nella stessa sessione.

Non è solo un tema di conformità. Un flusso di accesso difficile crea più attrito per chi usa tastiera o screen reader, ma anche per chi ha meno familiarità con il prodotto o deve recuperare velocemente un account bloccato.

Cosa chiedono davvero i criteri WCAG 2.2

I criteri più rilevanti per login, reset e recovery sono tre:

  • Consistent Help (3.2.6): se un meccanismo di aiuto compare su più pagine, la sua posizione relativa deve restare coerente (Understanding 3.2.6: Consistent Help).
  • Redundant Entry (3.3.7): non bisogna costringere una persona a reinserire informazioni già fornite nella stessa sessione, salvo i casi ammessi dal criterio.
  • Accessible Authentication (3.3.8): il login non deve dipendere unicamente da un compito cognitivo, come ricordare, trascrivere o risolvere un test, salvo eccezioni previste (Understanding 3.3.8: Accessible Authentication (Minimum)).

Sul CAPTCHA, W3C mantiene una nota storica che spiega perché molti meccanismi di questo tipo possono escludere persone con disabilità visive, uditive, cognitive o di lettura (Inaccessibility of CAPTCHA). La nota è utile per capire il rischio, ma non va letta come un divieto assoluto di ogni CAPTCHA in ogni contesto.

Prima di iniziare: risultato, destinatari e materiali

Risultato finale atteso

Alla fine dovreste avere:

  1. una mappa completa del flusso di login e recupero;
  2. un elenco dei punti che cambiano posizione, si ripetono o bloccano;
  3. una bozza di correzione prioritaria;
  4. una checklist di accettazione riutilizzabile dal team.

Destinatari

  • product owner o responsabile di progetto;
  • UX/UI designer;
  • sviluppatori front-end o full-stack;
  • chi presidia sicurezza, supporto e assistenza utenti.

Strumenti

  • ambiente di test o staging;
  • browser desktop;
  • tastiera soltanto;
  • un lettore di schermo, se disponibile;
  • una scheda per registrare gli esiti.

Prerequisiti

  • accesso a login, reset password e pagina di assistenza;
  • nessun dato reale o credenziale di produzione nel laboratorio;
  • disponibilità di un account di test.

Materiale fornito per il caso simulato

Portale: Area Clienti Demo
Dominio: area-clienti.demo
Utenti test:
- utente A: maria.rossi@example.test
- utente B: account.accessibilita@example.test

Flusso attuale:
1. Login con email + password
2. Dopo 2 errori compare CAPTCHA immagine
3. Link “Hai bisogno di aiuto?” compare in alto a sinistra nella pagina login, ma in basso nella pagina reset password
4. Nel reset viene richiesto di reinserire email, codice cliente e data di nascita
5. Il codice OTP arriva via email ed è valido 10 minuti

Modello minimo per registrare un rilievo

Schermata:
Cosa succede:
Chi si blocca:
Criterio coinvolto:
Correzione minima:
Verifica:

1. Mappa il flusso completo senza toccare ancora il design

Lavorate sulla copia del percorso, non sull’ambiente di produzione.

Cosa fare

Scrivete in ordine tutte le schermate coinvolte:

  • login;
  • errore credenziali;
  • reset password;
  • verifica email o OTP;
  • inserimento nuova password;
  • eventuale CAPTCHA;
  • conferma finale.

Cosa osservare

Il risultato atteso è una mappa lineare. Se una schermata non esiste nella documentazione ma compare nel flusso reale, avete già trovato un problema di tracciabilità.

Se manca un passaggio

Chiedete al team se quel punto avviene via pagina, popup, email o componente esterno. Se non potete descriverlo, non potete correggerlo in modo affidabile.

2. Verifica se l’aiuto resta nello stesso posto

Consistent Help non chiede solo che l’aiuto esista. Chiede che sia riconoscibile e coerente quando compare su più pagine (Understanding 3.2.6: Consistent Help).

Cosa fare

Controllate se il link di assistenza, la chat, il numero di supporto o la FAQ appaiono:

  • nello stesso ordine relativo rispetto al contenuto;
  • con la stessa etichetta;
  • nello stesso punto logico tra login e reset.

Cosa osservare

Se il link “Hai bisogno di aiuto?” è in alto nella pagina login e in fondo nella pagina reset, l’utente deve reimparare il percorso. Non è un dettaglio grafico: è un costo cognitivo reale.

Se trovate una differenza

Annotate se la differenza è intenzionale. Se non c’è una ragione chiara, trattatela come correzione prioritaria.

3. Controlla se il sistema fa reinserire dati già noti

Redundant Entry mira a evitare che una persona debba riscrivere informazioni già fornite nella stessa sessione.

Cosa fare

Nel caso simulato verificate se il reset password richiede di nuovo:

  • email;
  • codice cliente;
  • data di nascita;
  • altri dati già digitati nella schermata precedente.

Cosa osservare

Se i campi vengono ripetuti senza necessità, il flusso è più fragile del necessario. Precompilare, mantenere il valore inserito o passare il dato alla schermata successiva può ridurre errori e abbandoni.

Se il team dice che “serve per sicurezza”

Chiedete quale rischio concreto si sta mitigando. Se il dato è già stato verificato nella stessa sessione, la ripetizione deve essere giustificata con un motivo verificabile, non solo con abitudine interna.

4. Valuta il CAPTCHA come parte dell’autenticazione, non come un dettaglio aggiunto

W3C segnala da tempo che molti CAPTCHA sono problematici perché richiedono una prestazione cognitiva o sensoriale non accessibile a tutti (Inaccessibility of CAPTCHA). WCAG 2.2 non vieta in modo assoluto ogni test anti-bot, ma chiede che l’autenticazione non dipenda solo da quel test (Understanding 3.3.8: Accessible Authentication (Minimum)).

Cosa fare

Chiedete se il CAPTCHA è:

  • un freno aggiuntivo contro gli abusi, oppure
  • l’unica strada per completare login o recovery.

Cosa osservare

Se il CAPTCHA compare dopo due errori ma il sistema offre anche altre vie di accesso o recupero, il rischio è minore. Se invece blocca il recupero account o impedisce di procedere senza risolvere un test visivo o cognitivo, il flusso va ripensato.

Se non esiste alternativa

Segnate il punto come blocco alto: il problema non è solo tecnico, ma di accesso al servizio.

5. Esegui il percorso con tastiera e poi con lettore di schermo

A questo punto non basta leggere il mockup. Serve una prova pratica.

Cosa fare

  1. percorrete il login solo con tastiera;
  2. ripetete il reset password;
  3. se possibile, provate con un lettore di schermo;
  4. annotate ordine del focus, chiarezza delle etichette e visibilità dei messaggi di errore.

Cosa osservare

Il flusso è accettabile se:

  • il focus segue un ordine logico;
  • i campi hanno etichette comprensibili;
  • il link di aiuto è raggiungibile senza scorciatoie strane;
  • il CAPTCHA, se presente, non diventa un vicolo cieco.

Se il focus salta o il messaggio non si legge bene

Non limitatevi a correggere il CSS. Annotate il problema nel punto in cui nasce: struttura, ordine del DOM, etichetta, stato dell’errore o componente esterno.

6. Trasforma l’osservazione in una decisione

Qui si distingue una verifica utile da un audit generico.

Cosa fare

Per ogni problema trovato, scrivete tre righe:

  • cosa succede;
  • chi ne è impattato;
  • quale correzione minima proponete.

Esempio compilato

Problema: il link di aiuto cambia posizione tra login e reset.
Impatto: l’utente deve cercarlo di nuovo e può interrompere il flusso.
Correzione minima: mantenere la stessa posizione relativa e la stessa etichetta.

Problema: il reset richiede email e data di nascita già inserite.
Impatto: aumento errori e ridondanza nella stessa sessione.
Correzione minima: precompilare i campi già noti o ridurre i dati richiesti.

Problema: il CAPTCHA è l’unica via per procedere.
Impatto: autenticazione potenzialmente bloccante per alcune persone.
Correzione minima: offrire una via alternativa accessibile oppure spostare il test fuori dall’unico percorso di accesso.

Caso normale: flusso che passa il controllo

Nel caso simulato, il team applica tre modifiche:

  • il link “Hai bisogno di aiuto?” resta nella stessa posizione relativa;
  • il reset non richiede di reinserire email già confermata nella stessa sessione;
  • il CAPTCHA non è più l’unico modo per sbloccare il recupero account.

Esito atteso

Un utente che naviga con tastiera trova il supporto senza doverlo cercare di nuovo. Un utente che completa il reset non digita due volte gli stessi dati. Chi incontra il controllo anti-bot ha almeno una via alternativa o un percorso che non lo lascia fermo lì.

Caso con errore: cosa fare quando manca un’informazione

Supponiamo che il team non sappia spiegare perché il reset richiede di nuovo il codice cliente, o non sappia se il CAPTCHA abbia un’alternativa.

Come reagire

  1. fermate la valutazione come se fosse incompleta;
  2. chiedete il requisito che giustifica quel passaggio;
  3. se non esiste un requisito scritto, trattatelo come debito di progetto;
  4. aggiornate la checklist prima di approvare la release.

Una guida accessibile non deve fingere che tutto sia chiaro quando manca documentazione. Il “non lo sappiamo” è un risultato valido, purché porti a una decisione.

Checklist finale di accettazione

Prima di considerare il flusso pronto, controllate che siano veri tutti questi punti:

  • l’aiuto è coerente tra login e recovery;
  • i dati già forniti non vengono richiesti senza motivo;
  • il percorso con tastiera è completo;
  • il lettore di schermo legge campi ed errori in modo comprensibile;
  • il CAPTCHA non è l’unica opzione per autenticarsi o recuperare l’accesso;
  • ogni eccezione è documentata.

Se uno solo di questi punti fallisce, il flusso non è ancora pronto per la pubblicazione.

Troubleshooting rapido

Il CAPTCHA è imposto dal provider esterno

Chiedete se il provider consente:

  • un’alternativa non cognitiva;
  • un canale di verifica diverso;
  • un passaggio del CAPTCHA fuori dal percorso di accesso.

Se la risposta è no, il tema non è solo il componente: è la scelta di architettura.

Il team dice che “così è più sicuro”

La sicurezza non va discussa in astratto. Chiedete quale rischio specifico si copre e se la stessa protezione può essere ottenuta con meno attrito per l’utente.

L’aiuto esiste, ma nessuno lo trova

Se il supporto c’è ma cambia posizione o nome, il problema è di consistenza, non di presenza. Uniformare il pattern spesso risolve più di un redesign completo.

Il testo è leggibile ma il flusso resta difficile

Un buon contrasto non compensa una sequenza confusa. Se l’ordine dei passi è ambiguo, il problema è nella struttura del processo, non solo nella grafica.

Cosa cambia per chi decide

Per un product owner o un responsabile IT, questa verifica serve a prendere una decisione concreta:

  • mantenere il flusso con correzioni mirate;
  • sostituire il CAPTCHA o aggiungere una via alternativa;
  • rifare il recovery account prima di un audit o di una release importante.

Il vantaggio è pratico: una checklist come questa separa i problemi di design, di documentazione e di accessibilità, evitando correzioni casuali.

Se il problema riguarda l’intero flusso e non il singolo campo, può aiutare una revisione con la pagina Accessibilità digitale per siti, software e workflow aziendali. Se il team deve trasformare questi controlli in una procedura ripetibile, la pagina Formazione, divulgazione e R&D è un buon passo successivo. Quando invece il tema tocca più team, requisiti e responsabilità, può essere utile anche Consulenza strategica e governance IT.

Fonti