Il contesto dell’esperimento di Jemima Abu

Nel panorama attuale dell’intelligenza artificiale generativa, la discussione sull’accessibilità è spesso dominata da statistiche di conformità o dal numero di cause legali intentate. Il dato più significativo, però, è il 58 % di riduzione dei costi che Jemima Abu, product engineer di CAIS e professionista certificata in accessibilità, ha registrato aggiungendo un’unica istruzione di accessibilità al prompt del suo agente IA prima di chiedergli di costruire una pagina web.

Abu ha condotto il test quasi per frustrazione: sentiva ripetutamente le stesse obiezioni – “l’accessibilità richiede troppo tempo”, “i manager non approveranno le ore necessarie”, “i clienti non se ne curano”. La sua ipotesi era l’opposto: costruire prodotti non accessibili è il percorso più costoso. Per verificare, ha chiesto all’agente di implementare lo stesso design Figma due volte: una volta senza alcuna indicazione di accessibilità e una seconda volta con una “skill” di accessibilità da lei stessa scritta.

Limiti dell’esperimento e interpretazione dei risultati

Abu sottolinea subito che il risultato è un “one‑off experiment in a non‑constrained environment”, non una prova empirica su larga scala. Non si può affermare che tutti gli agenti IA producano prodotti più accessibili più velocemente e a costi inferiori. Tuttavia, il claim più ristretto – quando si forniscono agli agenti skill specifiche, questi operano più rapidamente e risparmiano denaro nel lungo periodo – è quello che vale la pena testare, soprattutto in un settore che ora misura i token e contabilizza ogni chiamata al modello.

Abu avvia il suo ragionamento con un’analogia: ogni modello di uso comune (ChatGPT, Claude, Copilot) è stato sviluppato circa tre anni fa e, per quanto migliorino, “sono ancora dei neonati”. Come nel programma giapponese “Old Enough”, dove i bambini piccoli ricevono una mappa, un avvertimento e una lista della spesa prima di andare al supermercato, anche un agente IA ha bisogno di una “mappa” – ovvero istruzioni chiare – per non perdersi in un mare di div inutili.

Chi è responsabile del risultato?

Con istruzioni insufficienti, il modello genera codice “perdersi generando cose con molti div”, mentre la responsabilità finale rimane al sviluppatore, non al modello. Il ruolo del developer diventa quello di dire all’agente “non andare per ciò che è popolare, scegli ciò che è migliore”, una distinzione tecnica che l’esempio dell’accordion illustra perfettamente.

Il ciclo della non‑accessibilità

Abu cita una statistica allarmante: 96 % dei primi 1 milione di siti web presentano problemi di accessibilità. Questo significa che la maggior parte degli utenti con disabilità non può utilizzare pienamente tali risorse. La radice del problema è il mindset “it works for me”. Se un prodotto funziona sul proprio laptop, si è tentati di rilasciarlo senza ulteriori verifiche.

Il ciclo si chiude perché l’IA impara dal codice umano esistente. Il modello osserva il codice attuale, lo interpreta come “buono” e riproduce gli stessi difetti di accessibilità, creando un feedback loop in cui le pratiche non accessibili si amplificano a scala globale, escludendo il 16 % della popolazione mondiale che vive con una qualche forma di disabilità.

Incentivi commerciali nascosti

L’IA tende a “scrivere molto codice”: se una funzionalità può essere realizzata in cinque righe, il modello preferisce 500, perché più token significano più fatturato per i fornitori. La risposta dello sviluppatore è richiedere all’agente di adottare la soluzione più concisa e “migliore”, non la più prolissa.

Metafora della pasticceria: accessibilità sin dall’inizio

Abu utilizza un’immagine memorabile: un muffin ai mirtilli ben cotto ha i frutti incorporati nell’impasto; un muffin con i mirtilli solo sopra è inferiore e verrebbe restituito dal cliente. Retrofittare l’accessibilità su un sito già completato equivale al muffin di seconda scelta. Non basta aggiungere “aria‑label” a caso; l’accessibilità deve essere “cotta” fin dall’inizio.

Lo stesso ragionamento vale per la scelta del codice. Un accordion personalizzato in JavaScript e l’elemento nativo <details> svolgono la stessa funzione, ma <details> è meno verboso, accessibile per difetto e testato dai browser. Poiché il codice personalizzato è più frequente nei dati di addestramento, l’IA lo sceglie per default. Il developer deve quindi guidare l’agente verso l’elemento nativo.

Linee guida moderne

Abu raccomanda la “modern web guidance” pubblicata da Chrome/Google, che indica all’agente di utilizzare <details> per gli accordion e popover per le modali, sfruttando le funzionalità più recenti del web e riducendo la complessità del codice.

Il caso commerciale: perché i clienti scelgono l’accessibilità

Le persone con disabilità si dirigono verso i prodotti che funzionano. Abu racconta un’aneddoto di conferenza: un utente ha abbandonato una app bancaria per un concorrente perché la prima era inaccessibile, anche se aveva funzionalità superiori. L’esperienza negativa ha portato alla perdita di un cliente potenzialmente redditizio.

Le obiezioni commerciali “nessuno dei nostri utenti usa tecnologie assistive” sono smontate con l’argomento logico: se gli utenti non riescono a navigare, non appaiono nelle analytics. È come un negozio senza porta che si lamenta dell’assenza di clienti.

Il contesto legale

Negli Stati Uniti, l’Americans with Disabilities Act (ADA) obbliga i siti pubblici ad essere accessibili. Le cause legali per siti non conformi sono numerose; Abu scherza sul fatto che “gli americani amano fare cause”, ma il messaggio è serio: l’accessibilità è una linea di responsabilità, non un optional.

Il suo approccio prevede anche una nota di cautela: i prompt e le skill non garantiscono al 100 % l’accessibilità, ma migliorano significativamente le probabilità di creare un web realmente inclusivo.

Procedura consigliata per gli agenti IA

Abu elenca una sequenza di passaggi, sottolineando che l’ordine è cruciale. Un agente inserito in una base di codice disordinata assume il disordine come standard. L’analogia del coinquilino: se al primo giorno trova piatti sporchi, non li lava più, pensando “perché dovrei farlo ora?”.

La sua “lightweight accessibility skill” per il web contiene tre istruzioni chiave:

    • Usare HTML semantico.
    • Ricorrere ad ARIA solo quando strettamente necessario.
    • Assicurare che ogni elemento interattivo sia navigabile esclusivamente tramite tastiera.

Questo prompt è adattabile ad altre piattaforme, garantendo coerenza nella filosofia di “costruire accessibile fin dall’inizio”.

Frustrazioni comuni e soluzioni sbagliate

Abu individua due estremi di frustrazione:

    • Team che non si curano affatto dell’accessibilità, omettendo pulsanti, gestori di tastiera e giustificando con “nessuno dei nostri utenti usa tecnologie assistive”.
    • Team che installano overlay di accessibilità – icone che promettono di “correggere” il sito con un click. Abu li definisce “terribili”, paragonandoli al muffin con i mirtilli aggiunti alla fine.

Entrambi gli approcci falliscono: il primo per negligenza, il secondo per illusione di una soluzione rapida.

Conclusioni per investitori e sviluppatori

L’esperimento di Abu arriva in un momento in cui le aziende stanno monitorando il consumo di token e valutando modelli più economici. Se anche un risultato preliminare dimostra che un prompt di accessibilità può ridurre i costi del 58 %, l’investimento in skill specifiche per gli agenti IA diventa una strategia vincente sia dal punto di vista etico che finanziario.

In sintesi, l’accessibilità non è solo un obbligo legale o una buona pratica, ma un fattore di risparmio economico e di competitività. Integrare istruzioni di accessibilità nei prompt degli agenti IA è come “infornare” il muffin fin dal principio: il risultato è più gustoso, più efficiente e più inclusivo per tutti.