Se il tuo sito è accessibile, le AI ti trovano e ti consigliano di più
“Se il tuo sito è accessibile, le AI ti trovano e ti consigliano di più.” È l’affermazione che gira più spesso nel marketing dell’accessibilità, ed è più forte di quello che i dati reali dimostrano.
La versione che posso sostenere con fonti dirette è più modesta: un sito accessibile viene navigato e utilizzato meglio da un agente AI che deve compiere un’azione, comprare, prenotare, compilare un modulo. Sul fatto che venga anche raccomandato più spesso, non ho trovato una ricerca che lo misuri: è un’ipotesi ragionevole, non un dato.
Tre modi diversi in cui un sito viene “letto”: un mio ragionamento, non una fonte
Quello che segue è una categorizzazione che ho costruito io stesso per chiarire il tema, non un framework preso da uno studio o da una fonte autorevole. Non esistono, al momento, dati certi che la confermino punto per punto: è la logica del funzionamento tecnico che porta a distinguere questi tre casi, non una ricerca che li misura separatamente.
- Crawler dei motori di ricerca (Googlebot e simili) leggono per indicizzare: struttura semantica, contenuto testuale, dati strutturati. Non interagiscono, non cliccano.
- Agenti AI di navigazione (Claude con computer use, ChatGPT con browsing, Perplexity) leggono e agiscono, ed è qui che entra in gioco l’accessibility tree nella sua forma più completa, con ruoli, nomi accessibili, stati.
- Modelli linguistici che rispondono su un brand non navigano il sito in tempo reale: rispondono in base a cosa hanno “studiato” o recuperato tramite ricerca. Su questo terzo livello non ho verificato dati specifici, lo cito solo per completezza del ragionamento, non come affermazione.
Un quarto fronte, distinto dagli agenti AI: le tecnologie vocali
Con fonte diretta: su iPhone, il comando “Hey Siri, leggi questo” funziona tramite la modalità Reader di Safari, ed estrae meglio il contenuto da pagine con struttura semantica chiara. (Fonte: Six Colors, reportage diretto sulla funzione in iOS 17.)
Con fonte diretta: Amazon Alexa non naviga siti web generici per leggerli o completare azioni: funziona tramite “Skills”, applicazioni vocali costruite appositamente da ogni azienda, separate dal sito web stesso. (Fonte: documentazione ufficiale Amazon Developer.) Un’affermazione come “chiedi ad Alexa di riordinare un prodotto sul tuo sito” non è tecnicamente accurata, a meno che l’azienda non abbia costruito una Skill dedicata, un caso raro, non generalizzabile.
Con fonte diretta, verificata con più fonti indipendenti: software di riconoscimento vocale come Dragon NaturallySpeaking e Voice Control (macOS/iOS) permettono di navigare un sito dicendo ad alta voce comandi come “clicca [nome link]”, oppure mostrando un numero sovrapposto a ogni elemento cliccabile della pagina. (Fonte: WebAIM; confermato anche da Pega Academy e dai forum ufficiali Apple su Voice Control.) Quando un campo di un form non è etichettato correttamente nel codice, questi sistemi non riescono a riconoscerlo: l’utente deve ricorrere a un workaround manuale, una casella di dettatura separata, poi copiata a mano nel campo. (Fonte: Fable, organizzazione specializzata in test di accessibilità con tecnologie assistive reali.) È lo stesso identico problema, un’etichetta form mancante, che affligge chi usa uno screen reader.
Come funziona tecnicamente: qui la fonte è diretta
Nella sua guida per costruire siti compatibili con gli agenti AI, Google dichiara esplicitamente che questi sistemi leggono una pagina in tre modi: screenshot, HTML grezzo, e l’accessibility tree, definito da Google come “una mappa ad alta fedeltà che ignora il rumore visivo del CSS”. Se un elemento cliccabile è un <div> con un gestore di click invece di un <button> reale, quella mappa non registra che è interattivo. (Fonte: documentazione ufficiale Google sulle linee guida per siti agent-friendly, ripresa da Attract Group.)
Un caso reale, con nome e data verificabili
Un benchmark del 26 agosto 2026, condotto con il nuovo “agentic browsing audit” di Google Lighthouse su siti reali, ha testato Airbnb, Stripe e Shopify. Stripe ha ottenuto punteggio pieno (3/3). Shopify ha ottenuto 2/3, fallendo il controllo di ruolo ARIA e nome dei bottoni. (Fonte: Attract Group, benchmark diretto con Lighthouse 13.4.1.)
Il tuo sito è accessibile?
Un dato quantitativo sul funzionamento degli strumenti di automazione
Il framework open source browser-use, costruito per far navigare agenti AI sui siti web, dichiara un punteggio dell’89,1% sul benchmark WebVoyager utilizzando un approccio basato sull’accessibility snapshot invece che sul rendering visivo. (Fonte: documentazione pubblica del progetto browser-use.) Questo dimostra che chi costruisce questi strumenti sceglie deliberatamente l’accessibility tree come base tecnica, non dimostra da solo quanto un sito inaccessibile faccia fallire un agente in percentuale.
Un errore che gira spesso nel settore, anche su siti specializzati
Uno studio del 2026 (UC Berkeley/Università del Michigan) misura che un agente AI completa il 78% dei compiti in condizioni normali, contro il 42% se costretto a navigare solo da tastiera, e il 28% con zoom al 150%. (Fonte primaria citata da più aggregatori; il dato numerico è verificabile, l’interpretazione seguente è dov’è nato il problema.)
Diversi articoli di settore citano questo dato come prova che “i siti inaccessibili fanno fallire gli agenti AI”. Non è quello che lo studio misura. Lo studio testa se un agente riesce a comportarsi come un utente con disabilità, con navigazione solo da tastiera o schermo ingrandito, per capire se potrebbe supervisionare o assistere una persona reale: una domanda di ricerca diversa da “questo sito specifico è accessibile o no”. (Correzione segnalata da una fonte critica, blog.tsd.digital, che ha verificato la metodologia originale dello studio.)
Cosa posso affermare con certezza, e cosa è solo un mio ragionamento
Con fonte diretta, verificabile
- Gli agenti AI usano l’accessibility tree per interagire con una pagina: dichiarato da Google.
- Un elemento senza ruolo o nome accessibile non viene riconosciuto come interattivo: dimostrato dal caso Shopify su Lighthouse.
- Gli strumenti di automazione browser sono costruiti per leggere l’accessibility tree, non il rendering visivo: documentato da browser-use.
- Le tecnologie di riconoscimento vocale falliscono sugli stessi campi non etichettati che bloccano uno screen reader: documentato da WebAIM e Fable.
Mio ragionamento, basato sulla logica tecnica, non su un dato misurato:
Un sito con problemi di accessibilità probabilmente blocca un agente AI nello stesso punto in cui bloccherebbe un utente con screen reader. Non esiste, al momento, uno studio che confronti direttamente i due casi fianco a fianco: questa conclusione nasce dal fatto che entrambi leggono la stessa identica struttura tecnica, quindi è logico aspettarsi che un difetto in quella struttura li penalizzi allo stesso modo. Ma è una deduzione mia, non una misurazione.
Cosa cambia per il tuo sito, in pratica
I punti dove un agente AI rischia di più (un checkout, un form senza etichette, un bottone senza testo accessibile) sono, per mio ragionamento tecnico basato sul meccanismo condiviso, probabilmente gli stessi punti critici per chi naviga con uno screen reader o con un software di riconoscimento vocale. Non è ancora un fatto misurato: è una conseguenza logica di come sappiamo che funziona la tecnologia. Sistemarli, in ogni caso, resta lo stesso lavoro che rende il sito utilizzabile da una persona reale, con il vantaggio aggiuntivo, probabile ma non garantito da nessuno studio, che oggi chi naviga il tuo sito potrebbe sempre più spesso non essere un umano.
