WCAG 3.3.9: Autenticazione accessibile (avanzata)

Cosa Significa Questa Regola

WCAG 3.3.9 — Accessible Authentication (Enhanced) è la controparte di livello AAA di WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Insieme, costituiscono una coppia di criteri introdotti in WCAG 2.2 progettati per garantire che il processo di verifica dell’identità su un sito web o un’applicazione non diventi esso stesso una barriera di accessibilità.

Al livello AAA, 3.3.9 inasprisce significativamente i requisiti. Il criterio afferma: Non deve essere richiesto alcun test di funzione cognitiva per nessun passaggio di un processo di autenticazione, a meno che quel passaggio non fornisca almeno una delle seguenti condizioni: un metodo di autenticazione alternativo che non si basi su un test di funzione cognitiva; un meccanismo disponibile per assistere l’utente nel completare il test di funzione cognitiva; oppure che il test di funzione cognitiva consista nel riconoscere oggetti. In modo critico, a differenza della versione AA (3.3.8), il criterio AAA rimuove l’eccezione che consentiva il riconoscimento di contenuti non-oggetto (come immagini di elementi non-oggetto selezionati in precedenza dall’utente). A questo livello, solo il vero riconoscimento di oggetti — riconoscere oggetti comuni del mondo reale come immagini di un gatto, una bicicletta o una casa — è consentito come test di funzione cognitiva, e solo se le altre condizioni non sono soddisfatte.

Un test di funzione cognitiva è definito come qualsiasi compito che richieda all’utente di ricordare, manipolare o trascrivere informazioni. Questo include: ricordare un nome utente o una password, risolvere un rompicapo matematico, completare un CAPTCHA che richiede di decifrare testo distorto, rispondere a una domanda di sicurezza sulla storia personale (ad es. "Qual era il nome del tuo primo animale domestico?") o trascrivere una sequenza di caratteri. Tutti questi rappresentano compiti di memoria o trascrizione che molti utenti non possono svolgere in modo affidabile.

Cosa è considerato conforme: Una fase di autenticazione è conforme a 3.3.9 se non richiede alcun test di funzione cognitiva, oppure se soddisfa una di queste condizioni: (1) viene offerto un percorso di autenticazione completamente separato e non cognitivo (ad es. un magic link inviato via email, WebAuthn/passkey, accesso biometrico); (2) un meccanismo assiste nel completamento del test (ad es. il password manager del browser non è bloccato, oppure è consentito il copia-incolla); oppure (3) l’unico test cognitivo coinvolto è il riconoscimento di un oggetto comune del mondo reale da un insieme di immagini.

Cosa è considerato non conforme: Qualsiasi flusso che costringa l’utente — senza bypass o alternativa — a ricordare una password a memoria, trascrivere un codice che non può essere incollato, risolvere un CAPTCHA visivo o audio senza alternativa, rispondere a domande di sicurezza basate sulla conoscenza, o identificare immagini precedentemente selezionate di contenuti non-oggetto (ad es. forme astratte o foto personali) senza un percorso di autenticazione alternativo.

Eccezioni ufficiali: La specifica WCAG stessa osserva che il riconoscimento di oggetti (fotografie di cose del mondo reale) è l’unico compito di riconoscimento di immagini consentito a questo livello AAA. Il criterio AA (3.3.8) consentiva anche il riconoscimento di immagini "non-oggetto" scelte personalmente, ma 3.3.9 rimuove completamente tale eccezione. Non esiste alcuna eccezione per schemi di autenticazione "ampiamente utilizzati" — se uno schema richiede un test cognitivo senza alternativa, non soddisfa 3.3.9.

Perché È Importante

L’autenticazione è spesso la prima interazione significativa che un utente ha con un servizio digitale. Se tale interazione è essa stessa inaccessibile, il resto dell’accessibilità del sito diventa irrilevante — l’utente non riesce nemmeno a entrare. WCAG 3.3.9 affronta direttamente questa barriera, e il suo impatto riguarda un’ampia gamma di gruppi di persone con disabilità.

Utenti con disabilità cognitive — inclusi coloro con dislessia, ADHD, lesioni cerebrali traumatiche, demenza o disturbi dell’apprendimento — possono trovare estremamente difficile o impossibile memorizzare password complesse, trascrivere manualmente codici monouso a tempo limitato o decodificare testo distorto in un CAPTCHA. L’Organizzazione Mondiale della Sanità stima che circa 1 persona su 6 nel mondo sperimenti una qualche forma di disabilità significativa, e le disabilità cognitive rappresentano una delle categorie più grandi e meno servite nell’accessibilità web.

Utenti con disabilità motorie — come persone con morbo di Parkinson, tremore essenziale, lesioni al midollo spinale o condizioni che richiedono accesso tramite switch o tecnologia di eye-gaze — possono avere difficoltà a digitare accuratamente password o trascrivere codici carattere per carattere. Bloccare l’incolla dagli appunti (una misura antifrode comune che è attivamente dannosa) significa che questi utenti devono inserire faticosamente ogni carattere tramite il loro dispositivo assistivo, aumentando drasticamente i tassi di errore e l’affaticamento.

Utenti ciechi o con ipovisione possono fare affidamento completamente su screen reader o strumenti di ingrandimento. I CAPTCHA visivi sono completamente inaccessibili senza un’alternativa audio, e persino i CAPTCHA audio sono notoriamente difficili per utenti con disabilità uditive o disturbi dell’elaborazione uditiva. Le sfide basate su immagini del tipo "seleziona tutti i semafori" possono essere problematiche quando le descrizioni delle immagini sono assenti o fuorvianti.

Utenti sordi o con ipoacusia possono incontrare barriere con metodi di autenticazione che si basano esclusivamente su telefonate per fornire codici monouso, in particolare quando tali chiamate sono solo vocali senza alternativa SMS.

Uno scenario concreto reale: Consideriamo un utente di 72 anni con lieve declino cognitivo che tenta di accedere al proprio portale di home banking. La banca richiede un nome utente (che deve essere ricordato, non l’indirizzo email), una password complessa (l’incolla dagli appunti è bloccato) e un CAPTCHA con testo distorto. L’utente fallisce il CAPTCHA due volte, viene bloccato e deve chiamare il call center della banca — un processo di 40 minuti. Se la banca avesse implementato passkey o un magic link, questo utente si sarebbe autenticato in pochi secondi. Questo scenario si ripete milioni di volte al giorno sul web, ed è completamente prevenibile.

Oltre alla disabilità, un’autenticazione accessibile avvantaggia tutti gli utenti. I password manager, utilizzati da centinaia di milioni di persone, dipendono dalla possibilità di incollare le credenziali. Bloccare l’incolla, richiedere la trascrizione manuale o incorporare CAPTCHA inaccessibili frustra anche gli utenti mainstream. Ci sono anche argomentazioni di sicurezza: forzare l’inserimento manuale di password complesse aumenta la probabilità che gli utenti scelgano password più semplici e deboli o le riutilizzino su più siti. Le passkey e i magic link, le alternative raccomandate, sono sia più accessibili che più sicuri rispetto ai flussi tradizionali password+CAPTCHA.

Regole Axe-core Correlate

WCAG 3.3.9 è classificato come richiedente solo test manuali. A partire da axe-core 4.10, non esiste alcuna regola automatizzata che valuti completamente questo criterio. Comprendere perché gli strumenti automatici non possono rilevare queste violazioni richiede di capire cosa misura effettivamente il criterio.

• Test manuale richiesto — rilevamento dei test di funzione cognitiva: Gli scanner automatici possono rilevare la presenza di determinati elementi HTML (come un <input type='password'> o un iframe che incorpora un widget CAPTCHA di terze parti), ma non possono determinare se un flusso di autenticazione completo richiede un test di funzione cognitiva senza alternativa accessibile. Il criterio riguarda l’intero percorso utente attraverso potenzialmente più passaggi e pagine, non le proprietà di un singolo elemento. Uno scanner non può valutare se l’incolla è bloccato a livello di programmazione tramite JavaScript, se un limite di tempo su un campo di inserimento del codice è ragionevole o se un percorso di autenticazione alternativo evita davvero i test cognitivi. Si tratta di questioni comportamentali e architetturali che richiedono che un valutatore umano percorra effettivamente il processo di autenticazione.
• Test manuale richiesto — verifica dei percorsi alternativi: Anche se uno scanner rileva un widget CAPTCHA, non può verificare se esiste un metodo di autenticazione alternativo accessibile sulla stessa pagina o nello stesso flusso. Non può valutare se un’opzione "usa invece una passkey" sia realmente equivalente o se sia nascosta in una pagina di impostazioni secondaria che richiede a sua volta di superare prima il CAPTCHA inaccessibile. Valutare l’equivalenza dei percorsi alternativi richiede un giudizio umano sulla completezza e l’evidenza di tali alternative.
• Test manuale richiesto — comportamento dell’incolla dagli appunti: Il JavaScript che intercetta gli eventi di paste e li annulla (event.preventDefault() su un listener di paste) è invisibile all’analisi HTML statica. Uno scanner vede un elemento <input> valido; non può sapere che l’incolla in esso è stato disabilitato. Solo il test manuale — provare fisicamente a incollare una password o un codice — può rivelare questo errore.
• Test manuale richiesto — compatibilità con le tecnologie assistive dei widget di autenticazione: Gli SDK di autenticazione di terze parti (pulsanti di social login, provider CAPTCHA, prompt biometrici) possono essere resi in iframe o Shadow DOM che gli scanner automatici non possono penetrare completamente. Il test manuale con screen reader come NVDA, JAWS e VoiceOver è essenziale per confermare che tutti gli elementi interattivi all’interno del flusso di autenticazione siano azionabili e comprensibili.

Come Testare

1. Identificare tutti i punti di ingresso per l’autenticazione: Prima di testare, mappare ogni punto dell’applicazione in cui un utente deve autenticarsi o verificare la propria identità. Questo include login iniziale, creazione account, reset della password, prompt di autenticazione a due fattori, ri-autenticazione dopo timeout di sessione, schermate di conferma pagamento e barriere di verifica dell’età. Ciascuno di questi flussi deve essere valutato in modo indipendente.
2. Eseguire una scansione automatizzata di base: Utilizzare axe DevTools (estensione del browser) o Lighthouse in Chrome DevTools su ogni pagina di autenticazione. Sebbene questi strumenti non segnalino direttamente violazioni di 3.3.9, evidenzieranno problemi correlati — etichette mancanti sui campi del form, contenuto iframe inaccessibile, gestione del focus mancante — che aggravano le barriere di autenticazione. Annotare eventuali problemi segnalati come contesto per la valutazione manuale. In axe DevTools, consultare la scheda "Needs Review" per gli elementi che richiedono giudizio manuale.
3. Verificare la presenza di test di funzione cognitiva: Per ogni passaggio di autenticazione, chiedersi: questo passaggio richiede all’utente di (a) ricordare qualcosa, (b) trascrivere qualcosa o (c) risolvere un rompicapo? In caso affermativo, verificare che sia presente e ugualmente evidente almeno una delle seguenti condizioni: un percorso alternativo non cognitivo; un meccanismo (come l’incolla consentito dagli appunti o un campo compatibile con l’autofill) che assista nel completamento; oppure che l’unico compito cognitivo sia il riconoscimento di un oggetto comune del mondo reale.
4. Testare il comportamento dell’incolla dagli appunti: In ogni campo di inserimento di password e codici, copiare una stringa di testo negli appunti e provare a incollarla usando Ctrl+V (Windows/Linux) o Cmd+V (macOS). Se l’incolla è bloccato, si tratta di un errore. Testare anche se l’autofill del password manager del browser è disattivato (controllare la presenza di autocomplete='off' o JavaScript che cancella i valori di autofill al focus).
5. Testare con NVDA + Firefox: Percorrere l’intero flusso di autenticazione usando solo la tastiera e lo screen reader NVDA. Verificare che tutti i campi del form siano annunciati con etichette significative, che tutti i controlli interattivi (pulsanti, link, sfide CAPTCHA) siano raggiungibili e azionabili e che eventuali messaggi di errore siano associati a livello di programmazione al campo pertinente e annunciati immediatamente senza richiedere ulteriore navigazione.
6. Testare con VoiceOver + Safari (macOS/iOS): Ripetere l’intero flusso di autenticazione. Su iOS, verificare anche che l’autenticazione biometrica (Face ID / Touch ID) sia offerta come alternativa quando viene utilizzata l’autenticazione nativa e che il flusso web sia completamente azionabile con Switch Control se la biometria non è disponibile.
7. Testare con JAWS + Chrome: Ripetere il flusso, prestando particolare attenzione a come vengono annunciati i widget di terze parti (social login OAuth, iframe CAPTCHA). JAWS gestisce alcuni pattern ARIA in modo diverso rispetto a NVDA; entrambi devono essere testati.
8. Valutare la reale equivalenza dei percorsi alternativi: Se esiste un metodo di autenticazione alternativo (ad es. "Accedi con un magic link"), completare l’intero flusso utilizzando solo tale alternativa. Confermare che raggiunga lo stesso stato autenticato senza richiedere alcun test cognitivo. Se il percorso alternativo contiene a sua volta un CAPTCHA o un test di memoria, non è un’alternativa valida ai sensi di 3.3.9.
9. Documentare i risultati con evidenze: Per ogni errore, acquisire una registrazione dello schermo o uno screenshot annotato che mostri esattamente quale passaggio fallisce e perché. Questa documentazione è essenziale per il passaggio alla fase di correzione da parte dei team di sviluppo e per finalità di tracciabilità dell’audit.

Come Correggere

CAPTCHA senza alternativa — Non corretto

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA sostituito con passkey e magic link — Corretto

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Incolla dagli appunti bloccato sul campo OTP — Non corretto

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

Campo OTP con incolla abilitato e suggerimento autocomplete — Corretto

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Domande di sicurezza basate sulla conoscenza — Non corretto

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Verifica dell’identità con alternative non cognitive — Corretto

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Errori Comuni

• Aggiungere autocomplete='off' ai campi password per impedire l’autofill del browser. Questo disabilita il principale meccanismo che consente agli utenti di evitare di memorizzare le password e viola direttamente 3.3.9. Rimuovere autocomplete='off' e utilizzare invece autocomplete='current-password' o autocomplete='new-password'.
• Associare un listener di evento JavaScript paste che chiama event.preventDefault() sui campi di input di autenticazione, credendo che ciò migliori la sicurezza. In realtà, blocca i password manager e le tecnologie assistive e costituisce un requisito di trascrizione ai sensi di 3.3.9.
• Considerare l’alternativa CAPTCHA audio come bypass sufficiente per i CAPTCHA visivi. I CAPTCHA audio costituiscono comunque un test di funzione cognitiva (trascrivere caratteri audio distorti) e non soddisfano 3.3.9. È richiesto un vero percorso alternativo non cognitivo.
• Offrire un’opzione di passkey o social login ma collocarla dietro un CAPTCHA come prerequisito. Se l’utente deve superare un test cognitivo per accedere all’alternativa accessibile, l’alternativa non è realmente equivalente e il flusso non soddisfa 3.3.9.
• Utilizzare sei campi <input> separati a singolo carattere per l’inserimento dell’OTP (uno schema UI comune) senza supportare l’incolla per riempire tutti i campi. Molte implementazioni incollano solo nel primo campo e richiedono l’inserimento manuale, tasto per tasto, degli altri cinque, il che rappresenta una barriera di trascrizione.
• Fare affidamento su "Ricordami" o sui cookie di sessione persistenti come unica accomodation per utenti che non possono autenticarsi ripetutamente. Sebbene ridurre la frequenza dell’autenticazione aiuti, non risolve un processo di autenticazione inaccessibile — gli utenti devono comunque superare il test cognitivo almeno una volta, e le sessioni scadono o vengono cancellate.
• Implementare campi OTP a tempo limitato che si cancellano allo scadere del tempo senza preavviso, costringendo gli utenti a richiedere un nuovo codice e tentare nuovamente la trascrizione. Questo aumenta il carico cognitivo per utenti con velocità motorie o di elaborazione cognitiva ridotte.
• Utilizzare sfide CAPTCHA basate su immagini che richiedono il riconoscimento di contenuti non-oggetto — come pattern astratti, colori o sequenze di foto personali selezionate — e credere che ciò soddisfi 3.3.9. Il criterio AAA consente solo il riconoscimento di oggetti (oggetti del mondo reale come auto, biciclette, semafori); il riconoscimento di immagini non-oggetto non è esente a questo livello.
• Bloccare l’accesso al gestore delle credenziali del browser tramite autocomplete='new-password' sui campi di login (anziché sui campi di registrazione). Il valore new-password segnala ai browser che si tratta di un campo per creare una nuova password, impedendo l’autofill delle credenziali salvate durante il login.
• Non testare i flussi di autenticazione con tecnologie assistive reali e fare invece affidamento esclusivamente sui risultati delle scansioni automatiche. Poiché 3.3.9 è testabile solo manualmente, i team che saltano i test manuali con screen reader e tastiera mancheranno sistematicamente errori relativi a questo criterio in ogni ciclo di rilascio.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale n. 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi completi in materia di accessibilità web e mobile per un’ampia gamma di soggetti pubblici e privati operanti in Turchia. La circolare impone la conformità a WCAG 2.2, rendendola il primo strumento giuridico turco a fare esplicito riferimento alla versione 2.2 dello standard.

I soggetti coperti dalla circolare includono: istituzioni e agenzie pubbliche a tutti i livelli di governo; piattaforme di e-commerce e marketplace online; banche e istituzioni finanziarie; ospedali e fornitori di servizi sanitari; operatori di telecomunicazioni con 200.000 o più abbonati; agenzie di viaggio; aziende di trasporto private; e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per queste organizzazioni, i servizi digitali — inclusi portali di login, portali paziente, dashboard bancari, sistemi di biglietteria e sistemi informativi per studenti — devono soddisfare i requisiti di accessibilità definiti dalla circolare.

WCAG 3.3.9, in quanto criterio di livello AAA, non è un obbligo legale minimo ai sensi della circolare. La base legale obbligatoria corrisponde alla conformità a WCAG 2.2 Livello A e AA. Tuttavia, lo spirito e la portata della circolare rendono 3.3.9 altamente rilevante nella pratica per diversi motivi.

In primo luogo, WCAG 3.3.8 (Accessible Authentication — Minimum) è un requisito di livello AA ed è quindi giuridicamente vincolante per tutti i soggetti coperti. Le organizzazioni che lavorano per conformarsi a 3.3.8 scopriranno che il percorso verso la conformità a 3.3.9 è spesso un piccolo passo incrementale — principalmente la rimozione dell’eccezione sul riconoscimento di immagini che 3.3.8 consente e la garanzia che tutti i test cognitivi abbiano alternative non cognitive, non solo meccanismi di assistenza.

In secondo luogo, per i soggetti che forniscono servizi a popolazioni con tassi più elevati di disabilità cognitive o motorie — in particolare ospedali, portali sanitari pubblici e portali di servizi governativi — raggiungere la conformità AAA sui criteri di autenticazione rappresenta un impegno significativo per l’accesso paritario che si allinea con i più ampi principi costituzionali di uguaglianza della Turchia e con gli obblighi del paese ai sensi della Convenzione ONU sui Diritti delle Persone con Disabilità (CRPD), che la Turchia ha ratificato.

In terzo luogo, le banche turche e i fornitori di servizi fintech sono soggetti a un’attenzione particolare in materia di autenticazione. L’Agenzia di Regolamentazione e Vigilanza Bancaria (BDDK) e l’Unità di Informazione Finanziaria (MASAK) impongono forti requisiti di verifica dell’identità, e le organizzazioni spesso implementano flussi di autenticazione complessi e multi-step per soddisfare tali requisiti. Implementare un’autenticazione conforme a 3.3.9 — utilizzando passkey, WebAuthn o flussi con magic link — è sia più accessibile sia in linea con le moderne best practice di autenticazione sicura approvate dai regolatori finanziari internazionali, rendendola un obiettivo di design che serve contemporaneamente la conformità su più fronti.

Le organizzazioni che desiderano differenziare la propria postura in materia di accessibilità, prepararsi a un possibile irrigidimento normativo futuro o servire gli utenti in modi accessibili e inclusivi sono fortemente incoraggiate a trattare WCAG 3.3.9 come uno standard di progettazione, non semplicemente come un miglioramento opzionale. Implementare percorsi di autenticazione completamente non cognitivi è sempre più fattibile con le moderne API dei browser (WebAuthn/passkey) e gli SDK di autenticazione, rendendo il costo della conformità più basso che mai mentre il beneficio — eliminare una delle barriere di accessibilità più rilevanti in qualsiasi prodotto digitale — è sostanziale.