GAAD compie 15 anni: accessibilità integrata, non un’aggiunta a posteriori

La maggior parte delle conversazioni sull’accessibilità prende una di due strade. O resta sul piano dell’imperativo morale, la “cosa giusta da fare”, oppure scade nel teatro della conformità: un elenco di normative, la minaccia di sanzioni, un audit una tantum spuntato e dimenticato.

Nessuna delle due versioni è utile a un team di prodotto.

Così quest’anno, per il Global Accessibility Awareness Day (si apre in una nuova scheda), abbiamo fatto qualcosa di diverso. Abbiamo messo sotto i riflettori due persone, Cian Dowling, Accessibility Lead di Synthesia, e Darren Britton, nostro CTO e Co-Founder, e abbiamo chiesto loro di raccontare con franchezza come si presenta davvero questo lavoro dall’interno. Niente slide. Niente risposte preconfezionate. Spazio aperto al confronto.

Ecco cosa si è perso chi non c’era:

La difesa dalle alluvioni che nessuno costruisce finché l’alluvione non arriva

Cian ha un modo di inquadrare l’accessibilità che supera le solite argomentazioni più rapidamente di qualsiasi minaccia normativa.

"Se si hanno le difese contro le alluvioni più perfette e l’alluvione non arriva, chi viene a fare i complimenti? Nessuno. Ma se non le si ha? È la propria testa a finire sul ceppo.

Solo quando l’evento si verifica diventa una questione di soldi. Che cosa succede se qualcuno dice: “Non le affiderò il contratto più grande che abbia mai avuto perché non ha un VPAT”? Perdono tutti, non solo gli ingegneri."

È la conversazione che la maggior parte dei team di prodotto evita. Non perché l’accessibilità non interessi, ma perché il business case non è ancora arrivato a destinazione. L’accessibilità rientra nella stessa categoria del disaster recovery: invisibile quando funziona, catastrofica quando non funziona.

La differenza, oggi, è che l’alluvione è più vicina di quanto pensi la maggior parte dei team.

Della conformità non importa a nessuno finché non è troppo tardi

Quando è entrato in Synthesia, la prima telefonata di Cian non è stata alla comunità dell’accessibilità. È stata all’Head of Infosec.

"Gli ho chiesto: raccontami cosa è successo dieci anni fa con il GDPR. Come hai fatto a far sì che alle persone importasse prima che fosse troppo tardi? Mi ha dato tanti buoni consigli."

L’analogia con il GDPR è la più utile per un pubblico misto. La maggior parte dei team di prodotto ha già attraversato un ciclo di conformità: SOC 2, GDPR, ISO 27001. Conoscono lo schema: all’inizio sembra facoltativo, poi diventa urgente, infine è una condizione per fare affari con chiunque conti. Altrimenti si resta fuori.

L’accessibilità sta attraversando lo stesso ciclo, con due o tre anni di ritardo. Le aziende che oggi la trattano come un’infrastruttura sono quelle che chiuderanno contratti enterprise nel 2026 e nel 2027. Chi aspetta dovrà intervenire a posteriori sotto pressione (e costa caro).

"Preferisco di gran lunga muovermi in modo proattivo e inserire nella roadmap del prossimo trimestre qualcosa che ne risolva il 20%, piuttosto che stare a lamentarmi perché non abbiamo raggiunto il 100%."

Il progresso prima della perfezione.

L’audit non è la revisione dell’auto

Ecco la trappola in cui cade la maggior parte dei team. Commissionano un audit. Ricevono un report. Considerano il report come il lavoro fatto. E se ne dimenticano.

Su questo Cian è diretto: l’audit dice che cosa non andava in un momento preciso, qualche mese fa. Per un’azienda che rilascia più di mille cose al mese, quella fotografia è già superata prima ancora di finire di leggerla.

"Mi interessa molto di più capire come ridurre, mese dopo mese, la quantità di cose non accessibili che rilasciamo, che smaltire un backlog. L’audit non è come la revisione dell’auto: non ci si va una volta all’anno per spuntare la casella. La domanda è: quali sono le cause che hanno prodotto quei problemi, in modo che il prossimo audit ne trovi meno?"

È una questione di definition of done. Non di uno sprint di correzione.

I team che fanno progressi reali sull’accessibilità sono quelli che hanno smesso di trattarla come un progetto e hanno iniziato a trattarla come una pratica. L’accessibilità affidata a un referente (o a più d’uno) inserito nel team di prodotto o di ingegneria. Integrata nel design system, così da essere corretta per impostazione predefinita.

L’IA non risolverà il problema. Anzi, potrebbe peggiorarlo.

La domanda che sentiamo più spesso dai team di prodotto in questo momento: l’IA non risolverà tutto automaticamente? Non basta passare la nostra codebase a Claude o a GPT per risolvere i problemi di accessibilità?

Prima di entrare in Synthesia, Cian ha provato lui stesso a sviluppare uno strumento di accessibilità basato sull’IA. Ecco perché non funziona come la maggior parte delle persone immagina.

"Se si dà in pasto l’intera codebase a un LLM, si stanno regalando i gioielli di famiglia. Non è proprio il caso di inserire il proprio codice proprietario in un modello di terze parti."

Ma il problema più profondo è su che cosa l’IA è stata addestrata.

"Gli LLM sono addestrati su tutto ciò che è stato prodotto finora. Il 97% di internet non è accessibile. Questo significa che l’IA è stata addestrata prevalentemente su codice non accessibile. E l’output lo rispecchia."

I componenti React generati dall’IA tralasciano abitualmente ARIA e l’HTML semantico. Le interfacce generate in fase di esecuzione non possono essere sottoposte ad audit in anticipo. La velocità di rilascio che l’IA consente ai team fa sì che le regressioni di accessibilità arrivino prima che qualcuno le esamini. Gli strumenti che promettono di far lavorare i team più velocemente stanno, per molti di loro, accumulando silenziosamente debito di conformità a ogni release.

Questo non significa che l’IA non abbia alcun ruolo. Significa che il suo ruolo è diverso da quello che la maggior parte delle persone immagina.

"Sfruttare il volume e la scala di ciò che l’IA può fare, aggiungendo però giudizio umano e contesto per ridurre il lavoro: ecco cosa serve. Uno strumento come DevAlly permette a uno specialista di accessibilità, o a un ingegnere attento all’accessibilità, di svolgere 5 volte il lavoro che potrebbe fare altrimenti. Non è un risultato che si ottiene da un LLM generico e preconfezionato."

L’aspetto di cui ancora nessuno parla

C’è un tema che sta appena iniziando a emergere nelle conversazioni tra ingegneri e che ripresenta l’accessibilità al consiglio di amministrazione in una prospettiva che la toglie del tutto dalla colonna della conformità.

Gli agenti di IA sono sempre più spesso utenti dei software. E le stesse qualità strutturali che rendono un prodotto accessibile a chi usa un lettore di schermo (HTML semantico, etichette adeguate, un’architettura dei componenti prevedibile, ruoli ARIA corretti) sono quelle che rendono un prodotto navigabile da un agente di IA.

I team che oggi investono nell’accessibilità stanno, senza volerlo, costruendo le basi per la compatibilità con gli agenti.

Se un prodotto non supera la prova di un lettore di schermo, probabilmente non supererà nemmeno quella di un agente.

L’accessibilità smette di essere un costo di conformità. Diventa parte della Sua strategia di AI readiness.

Cosa fare questa settimana

Il pubblico del GAAD ha chiesto a ciascun relatore un’azione pratica. Ecco cosa hanno indicato.

Darren Britton, CTO e Co-Founder, DevAlly: inizi dai tre percorsi utente principali. Non un audit completo. Automatizzi ciò che può e segnali ciò che richiede uno sguardo umano. Renda visibile qualcosa al team di engineering già in questo sprint.

Cian Dowling, Accessibility Lead, Synthesia: Non vada a parlare prima con la community dell’accessibilità. Parli con il Suo Head of Infosec. Chieda cosa è successo dieci anni fa con il GDPR. Chieda come sono riusciti a sensibilizzare le persone prima che fosse troppo tardi. È questa la conversazione da replicare, per poi trovare la leva giusta per entrare nella pianificazione del team di engineering.

E un consiglio da entrambi: non commissioni un report per poi considerarlo il lavoro in sé. Il report è l’inizio del lavoro.

La versione onesta di questa storia

All’inizio della conversazione Cian ha detto qualcosa su cui vale la pena riflettere.

"Quando si parla di conformità è un compito ingrato. A nessuno importa finché non è troppo tardi. Ma non credo basti starsene seduti a dire che dovremmo farlo. Noi rilasciamo in fretta. Come per molte delle cose migliori della vita, quando si vede l’opportunità bisogna coglierla e buttarsi."

Un’accessibilità integrata fin dall’inizio non è solo la scelta responsabile. Per un’azienda di AI da 4 miliardi di dollari che rilascia oltre mille modifiche al prodotto al mese, è l’unica scelta sensata dal punto di vista commerciale.

Ecco cosa significa davvero un’accessibilità integrata, non aggiunta a posteriori.

DevAlly è una piattaforma per la conformità in materia di accessibilità con sede a Dublino. Aiutiamo i team di prodotto e di engineering a individuare per tempo i problemi di accessibilità, a gestire backlog di correzione con priorità definite e a generare la documentazione di conformità che oggi gli uffici acquisti delle grandi aziende richiedono.

Vuole sapere a che punto è il Suo prodotto? Esegua una scansione gratuita su devally.com