WCAG 3.3.8: Autenticazione accessibile (minimo)

Cosa significa questa regola

WCAG 3.3.8 Accessible Authentication (Minimum) è un criterio di livello AA introdotto in WCAG 2.2. Stabilisce che un test di funzione cognitiva — definito come un compito che richiede all’utente di ricordare, manipolare o trascrivere informazioni — non deve essere l’unico mezzo per completare una fase di autenticazione, a meno che non sia soddisfatta almeno una delle seguenti condizioni:

• Metodo alternativo: È disponibile un altro percorso di autenticazione che non si basa su un test di funzione cognitiva (per esempio, un magic link inviato via email, l’accesso biometrico o una passkey).
• Meccanismo di assistenza: All’agente utente o a uno strumento di terze parti è consentito completare la fase per conto dell’utente — per esempio, un password manager che compila automaticamente le credenziali o un’azione di copia-incolla per un codice monouso.
• Eccezione per il riconoscimento di oggetti: Il test di funzione cognitiva consiste nell’identificare un oggetto in un’immagine (per esempio, selezionare tutte le immagini che contengono un semaforo) — questo tipo di test è consentito al livello Minimum (AA).
• Eccezione per contenuti personali: Il test si basa su contenuti forniti dall’utente stesso, come selezionare da una griglia una foto precedentemente caricata.

In termini pratici, un modulo di accesso che richiede solo nome utente e password è conforme a questo criterio, a condizione che il modulo consenta il riempimento automatico del browser e il funzionamento dei password manager (cioè i campi usano il <input type='password'> standard e non bloccano l’incolla). Un CAPTCHA che richiede di trascrivere testo distorto senza alcun percorso di autenticazione alternativo è una violazione evidente. Un CAPTCHA che chiede agli utenti di selezionare immagini che corrispondono a una categoria (riconoscimento di oggetti) è consentito a livello AA ma è trattato in modo più restrittivo a livello AAA (3.3.9).

Il criterio si applica a tutte le fasi di un processo di autenticazione: accesso iniziale, autenticazione rafforzata, verifica multi-fattore, recupero dell’account e ri-autenticazione della sessione. Si applica anche a qualsiasi processo che protegge l’accesso a funzionalità, non solo alla schermata principale di accesso.

Una implicazione tecnica chiave è che gli sviluppatori non devono usare autocomplete='off' sui campi di autenticazione, non devono disabilitare l’incolla tramite gestori di eventi JavaScript e non devono alterare le semantiche standard degli input che consentono il corretto funzionamento delle tecnologie assistive e del riempimento automatico del browser.

Perché è importante

L’autenticazione è la porta d’accesso a quasi tutti i servizi digitali di cui le persone si avvalgono quotidianamente: servizi bancari, portali sanitari, servizi governativi, e-commerce e piattaforme di comunicazione. Quando questa porta impone ostacoli cognitivi, esclude sistematicamente una parte significativa della popolazione.

Le disabilità cognitive comprendono un ampio spettro: dislessia, discalculia, disturbi da deficit di attenzione, lesioni cerebrali acquisite, demenza, disabilità intellettive e disturbi d’ansia. L’Organizzazione Mondiale della Sanità stima che circa 1 persona su 6 nel mondo sperimenti una forma significativa di disabilità, e le condizioni cognitive e neurologiche rappresentano una delle categorie più grandi. Per questi utenti, compiti come trascrivere correttamente una stringa di caratteri distorti, risolvere un rompicapo visivo sotto pressione temporale o passare da un’app di autenticazione a un modulo di accesso possono essere realmente impossibili o profondamente estenuanti.

Consideriamo uno scenario concreto: una persona con dislessia tenta di accedere al portale della propria assicurazione sanitaria per visualizzare i risultati degli esami. Il sito presenta un CAPTCHA testuale senza alternativa audio e senza possibilità di bypassarlo. Le forme delle lettere distorte sono indistinguibili per questa persona e il campo di input blocca l’incolla. Dopo diversi tentativi falliti, l’account viene bloccato. L’utente non può accedere a informazioni mediche sensibili dal punto di vista temporale. Questo non è un caso limite ipotetico: è un’esperienza abituale per milioni di persone.

Anche gli utenti con disabilità motorie che si affidano a sistemi di accesso a scansione o a dispositivi di eye-tracking sono interessati. Digitare nuovamente un complesso codice monouso da un dispositivo separato o trascinare riquadri di immagini in un ordine specifico può essere fisicamente impossibile con questi metodi di input. Consentire il copia-incolla o l’autenticazione basata su passkey elimina completamente la barriera.

Le persone anziane rappresentano un altro gruppo significativo. Il declino cognitivo legato all’età influisce sulla memoria e sulla velocità di elaborazione, rendendo i CAPTCHA complessi e i compiti di memorizzazione multi-step sproporzionatamente difficili. Con l’invecchiamento della popolazione in Turchia e a livello globale, il caso commerciale e normativo per un’autenticazione accessibile diventa ogni anno più forte.

Dal punto di vista dell’usabilità e della conversione, l’attrito nei flussi di autenticazione aumenta direttamente i tassi di abbandono. Le piattaforme di e-commerce che sostituiscono i CAPTCHA testuali con autenticazione basata sul rischio o passkey riportano costantemente tassi di completamento dell’accesso più elevati e costi di supporto più bassi legati agli account bloccati.

Regole Axe-core correlate

WCAG 3.3.8 è classificato come criterio che richiede test manuali perché gli strumenti automatizzati non possono valutare completamente se un processo di autenticazione impone un test di funzione cognitiva inaccessibile. Determinare se un flusso di accesso non ha percorsi alternativi o se l’incolla è bloccato in modo dipendente dal contesto richiede giudizio umano e interazione con un flusso di autenticazione reale. Detto ciò, alcuni controlli automatizzati supportano questo criterio:

• Revisione manuale — audit del flusso di autenticazione: I tester devono percorrere ogni fase di autenticazione e determinare se è presente un test di funzione cognitiva e, in tal caso, se esiste un’alternativa conforme o un meccanismo di assistenza. Nessuna regola axe-core attualmente viene attivata automaticamente per questo criterio perché la logica dipende dalla comprensione dello scopo e del contesto dei campi del modulo e dell’interfaccia circostante, non solo del loro markup.
• Controlli dell’attributo autocomplete (correlati): La regola autocomplete-valid di axe-core segnala i campi di input i cui valori dell’attributo autocomplete non sono tratti dall’elenco di token di WCAG 1.3.5. Sebbene questa regola prenda di mira direttamente 1.3.5, è un controllo di supporto per 3.3.8: se autocomplete='username' e autocomplete='current-password' mancano o sono impostati in modo errato, i password manager non possono compilare automaticamente, rimuovendo il meccanismo di assistenza che rende conforme l’accesso standard con password ai sensi di 3.3.8.
• Rilevamento del blocco dell’incolla — manuale: Gli scanner automatizzati non possono rilevare in modo affidabile JavaScript che intercetta gli eventi paste e li sopprime sui campi di autenticazione. Un tester manuale deve tentare di incollare una credenziale o un OTP in ciascun campo pertinente e confermare che l’azione vada a buon fine.
• Rilevamento di alternative al CAPTCHA — manuale: Axe-core può rilevare la presenza di widget CAPTCHA comuni (ad esempio iframe reCAPTCHA) ma non può determinare se altrove nella pagina o tramite un percorso diverso sia offerto un metodo di autenticazione alternativo. Questa valutazione richiede un’ispezione manuale dell’intera esperienza di autenticazione.

Come testare

1. Scansione automatizzata (axe DevTools / Lighthouse): Esegui axe DevTools su ogni pagina di autenticazione (accesso, registrazione, recupero account, MFA). Cerca violazioni di autocomplete-valid sui campi nome utente e password. In Lighthouse, esamina l’audit Accessibilità per problemi relativi ai moduli. Nota che nessuna regola automatizzata segnalerà in modo definitivo una violazione di 3.3.8 — i risultati automatizzati sono solo un punto di partenza.
2. Identifica tutti i test di funzione cognitiva: Cataloga manualmente ogni fase del flusso di autenticazione. Annota qualsiasi fase che richiede all’utente di ricordare informazioni non fornite nella schermata corrente, trascrivere caratteri, risolvere un rompicapo o eseguire un calcolo. Verifica se ciascuna di queste fasi ha un’alternativa conforme (riconoscimento di oggetti, contenuti personali, metodo di accesso alternativo o meccanismo di assistenza).
3. Verifica la funzionalità di incolla: Su ogni input di autenticazione (nome utente, password, OTP, codice di recupero), prova a incollare testo usando la scorciatoia da tastiera (Ctrl+V su Windows/Linux, Cmd+V su macOS). Conferma che il contenuto incollato appaia nel campo. Ripeti usando il menu contestuale con clic destro. Se l’incolla è bloccato, si tratta di una violazione a meno che non esista un’alternativa priva di funzione cognitiva.
4. Verifica il riempimento automatico con un password manager: Usando un browser con un password manager (nativo o basato su estensione), salva le credenziali durante la registrazione e poi torna alla pagina di accesso. Conferma che il password manager riesca a rilevare i campi e a compilarli automaticamente. Esegui il test in Firefox con NVDA, Safari con VoiceOver (macOS/iOS) e Chrome con JAWS per coprire le principali combinazioni AT+browser. Se i campi usano markup non standard o JavaScript che cancella i valori compilati automaticamente, si tratta di una violazione.
5. NVDA + Firefox — walkthrough con screen reader: Naviga il modulo di accesso usando solo la tastiera e NVDA. Conferma che ogni campo sia raggiungibile, che le etichette dei campi vengano annunciate correttamente e che qualsiasi widget CAPTCHA abbia un’alternativa accessibile. Se il CAPTCHA è puramente visivo, senza opzione audio e senza percorso di accesso alternativo, registra una violazione.
6. VoiceOver + Safari (iOS): Su un dispositivo mobile, prova ad accedere usando Face ID o Touch ID se il sito offre l’accesso biometrico. Conferma che l’opzione biometrica sia raggiungibile tramite navigazione a scorrimento e che VoiceOver la annunci correttamente. Questo verifica che un’alternativa priva di funzione cognitiva sia operativamente accessibile, non solo presente nominalmente.
7. Verifica la presenza di limiti di tempo nelle fasi cognitive: Se un CAPTCHA o l’inserimento di un OTP impone un limite di tempo, verifica se l’utente può estenderlo o disabilitarlo (rilevante per 2.2.1) e annota separatamente se la fase temporizzata costituisce un test di funzione cognitiva senza alternativa.

Come correggere

CAPTCHA testuale senza alternativa — Non corretto

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

CAPTCHA testuale senza alternativa — Corretto

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

Campo OTP che blocca l’incolla — Non corretto

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

Campo OTP che blocca l’incolla — Corretto

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

CAPTCHA con selezione di immagini senza fallback (problema AAA, conforme AA) — Corretto a livello AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Errori comuni

• Impostare autocomplete='off' sui campi password: Questo disabilita il riempimento automatico dei password manager, rimuovendo il meccanismo di assistenza che rende conforme l’autenticazione standard con password. Usa invece autocomplete='current-password' e lascia che sia il browser a gestire l’archiviazione delle credenziali.
• Bloccare l’incolla con onpaste='return false;' o addEventListener('paste', e => e.preventDefault()): Questo costringe gli utenti a digitare manualmente le credenziali, creando un compito di trascrizione inaccessibile. Rimuovi tutti i gestori che impediscono l’incolla dagli input di autenticazione.
• Offrire un’opzione passkey che non è accessibile da tastiera: Un’alternativa biometrica soddisfa 3.3.8 solo se è raggiungibile e utilizzabile tramite tastiera e tecnologie assistive. Un pulsante per la passkey nascosto dietro un menu attivato al passaggio del mouse o reso come un <div> non focalizzabile non conta come alternativa conforme.
• Usare un CAPTCHA testuale come unica strategia di mitigazione dei bot: Passare al rilevamento dei bot lato server basato sul rischio (analizzando impronta del dispositivo, cadenza di digitazione, reputazione IP) elimina completamente il test di funzione cognitiva senza sacrificare la sicurezza. Affidarsi esclusivamente a un CAPTCHA lato client è sia un fallimento in termini di accessibilità sia una pratica di sicurezza scadente.
• Suddividere un OTP in più input a singolo carattere e bloccare l’incolla tra i campi: Alcune implementazioni usano sei campi separati <input maxlength='1'> per l’inserimento dell’OTP e avanzano automaticamente il focus tramite JavaScript. Questo schema interrompe regolarmente l’incolla dai password manager e viola 3.3.8 a meno che l’implementazione non gestisca esplicitamente l’incolla di un intero codice nel primo campo distribuendo correttamente i caratteri.
• Richiedere un CAPTCHA basato su immagini solo nei flussi di recupero account: I team spesso aggiungono alternative di accesso accessibili alla pagina principale di login ma dimenticano l’autenticazione rafforzata, il reset della password e i flussi di sblocco dell’account. Ciascuno di questi è una fase di autenticazione separata e deve rispettare indipendentemente 3.3.8.
• Considerare il CAPTCHA audio come alternativa completa al CAPTCHA testuale: Un’alternativa audio risponde alle esigenze degli utenti ciechi ma non aiuta gli utenti con disabilità cognitive o chi si trova in ambienti rumorosi. I CAPTCHA audio presentano inoltre un proprio requisito di trascrizione. La correzione corretta è eliminare il CAPTCHA o fornire un percorso che non preveda alcun test di funzione cognitiva.
• Generare dinamicamente ID dei campi di input che impediscono il rilevamento da parte dei password manager: Quando gli attributi id sui campi nome utente e password sono randomizzati a ogni caricamento della pagina (una tecnica anti-bot mal concepita), i password manager non possono identificare in modo affidabile i campi. Questo di fatto disabilita il riempimento automatico e rimuove il meccanismo di assistenza conforme.
• Dare per scontato che i widget CAPTCHA di terze parti siano automaticamente conformi: I servizi CAPTCHA più diffusi possono offrire varianti accessibili, ma non sono abilitate per impostazione predefinita. Gli sviluppatori devono configurare esplicitamente la versione accessibile e devono comunque verificare che soddisfi i requisiti dello standard invece di aggiungere semplicemente un nuovo tipo di test inaccessibile.
• Cancellare i valori compilati automaticamente tramite JavaScript al focus: Alcuni moduli cancellano il contenuto dell’input quando un campo riceve il focus per mostrare testo segnaposto o per richiedere una nuova immissione. Se questo comportamento cancella il valore compilato automaticamente da un password manager, costringe alla reimmissione manuale e viola 3.3.8.

Relazione con la normativa sull’accessibilità in Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi di accessibilità web e mobile allineati a WCAG 2.2. La circolare richiede ai soggetti interessati di raggiungere la conformità di livello AA per i propri prodotti e servizi digitali. WCAG 3.3.8, in quanto criterio di livello AA in WCAG 2.2, rientra quindi direttamente nell’ambito dei requisiti di conformità obbligatori introdotti da questa circolare.

La circolare copre un’ampia gamma di soggetti pubblici e privati. Le istituzioni pubbliche e le agenzie governative devono raggiungere la piena conformità AA. Nel settore privato, la circolare si applica a piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari privati, operatori di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per queste organizzazioni, flussi di autenticazione inaccessibili — come pagine di accesso con CAPTCHA non supportati o campi OTP che bloccano l’incolla — creano un’esposizione normativa diretta.

Il Logo di Accessibilità (Erişilebilirlik Logosu), rilasciato dal Ministero della Famiglia e dei Servizi Sociali, è il marchio ufficiale di certificazione per la conformità all’accessibilità digitale in Turchia. Ottenere questo logo richiede una dimostrata conformità di livello AA, che comprende 3.3.8. Per gli operatori di e-commerce, le banche e altri fornitori di servizi digitali ad alto traffico, il logo funge da segnale di fiducia pubblica e può essere citato nei requisiti di appalto e gara. Flussi di autenticazione che si basano su test cognitivi inaccessibili impedirebbero la certificazione ed esporrebbero l’organizzazione a reclami e azioni di enforcement.

Da un punto di vista pratico di conformità, le organizzazioni turche dovrebbero verificare ogni punto di contatto di autenticazione — inclusi accesso, registrazione, MFA, reset della password e sblocco dell’account — rispetto a 3.3.8 prima di presentare domanda per la valutazione del Logo di Accessibilità. Sostituire i CAPTCHA testuali con controlli lato server basati sul rischio, abilitare autocomplete su tutti i campi delle credenziali e offrire alternative come passkey o magic link sono le azioni di remediation a maggior impatto. Questi cambiamenti soddisfano contemporaneamente il requisito normativo e migliorano l’esperienza di autenticazione per gli stimati 8.5 milioni di persone con disabilità in Turchia che utilizzano servizi digitali.