Descrizione immagine: una designer a una scrivania regolabile in altezza, vista da dietro, con due monitor che mostrano una libreria di componenti di un design system con stati di focus — il marcatore visivo per il profilo della designer dell’accessibilità su scala.

Tempo di lettura: 10 minuti

Nota della redazione. La designer qui profilata è un personaggio composito. «Maya Okafor» non è una singola persona reale; la biografia è costruita a partire da interviste registrate con cinque senior accessibility-design lead che, tra il 2019 e il 2025, hanno guidato programmi di accessibilità di più trimestri in aziende internet consumer con basi di utenti nell’intervallo di circa 80–300 milioni. Ogni numero, ogni artefatto, ogni sconfitta nella cronologia che segue è reale e proviene da uno dei cinque professionisti; la sintesi — l’arco di una carriera attraverso un programma — è la libertà editoriale.

Anche il prodotto è mascherato. Ciò che si nomina con precisione è la sua scala (circa 200 milioni di utenti attivi mensili all’inizio, circa 240 milioni alla chiusura), il suo stack (un front-end React e TypeScript con app native iOS e Android che condividono lo stesso linguaggio di design) e la superficie del design system che Maya ha ereditato (circa 410 componenti, di cui circa 90 «primari»). Queste sono le variabili che determinano la difficoltà del lavoro.

Il lunedì in cui è entrata

Maya Okafor è entrata in azienda un lunedì piovoso di fine gennaio 2022 come Staff Product Designer nel team Design Systems. Aveva trentaquattro anni. Aveva trascorso i sei anni precedenti nella divisione digitale di un grande editore, dove era diventata — quasi per caso — quella che sapeva come dovrebbe apparire un anello di focus e perché il rapporto di contrasto di 2,6:1 imposto dal brand sui pulsanti terziari non era, di fatto, accettabile. Non aveva credenziali formali sull’accessibilità. Diceva sempre di aver imparato tutto nel modo più difficile: essere la designer in chiamata quando un utente di screen reader presentava un ticket di supporto e nessun altro sapeva come riprodurre il problema.

Nella nuova azienda non esisteva un mandato sull’accessibilità. Non esisteva un team dedicato all’accessibilità. Esisteva un Accessibility Working Group, che si riuniva ogni altro mercoledì alle 16 ora del Pacifico e che, al primo mercoledì di Maya, contava sei partecipanti. Aveva una pagina Confluence aggiornata l’ultima volta nel 2020, un canale Slack con circa 140 membri e tre messaggi a settimana, e — Maya lo capì in seguito — esattamente un punto di leva: un backlog di quarantuno ticket di supporto correlati all’accessibilità aperti, di cui sette provenienti da una singola organizzazione per i diritti dei disabili che inviava e-mail all’azienda trimestralmente dal 2019.

«La prima cosa che ho fatto è stata leggere tutti e quarantuno quei ticket. La seconda cosa è stata stamparli e metterli in un raccoglitore. Non perché qualcuno avesse bisogno di un raccoglitore — perché avevo bisogno di un oggetto fisico da mettere sulla scrivania di un VP tra tre mesi, quando la conversazione si fosse fatta difficile.»

Maya Okafor, composito, sul suo primo mese

Costruire il caso: volume dei reclami, rischio legale, quota di mercato

I primi tre mesi non furono lavoro di design. Fu lavoro investigativo. Maya fece tre cose in parallelo.

Quantificò la pipeline dei reclami. Lavorando con il Support, estrasse tutti i ticket degli ultimi ventiquattro mesi contenenti una dozzina di termini segnalatori — «screen reader», «VoiceOver», «TalkBack», «JAWS», «NVDA», «contrasto», «solo tastiera», «WCAG», «ADA», «EAA», «non riesco a leggere». Trovò circa 1.470 reclami distinti, di cui circa 280 non risolti da più di novanta giorni. Li mappò alle superfici del prodotto: circa il 38% sul checkout, circa il 22% sulla messaggistica, circa il 14% sulla creazione del profilo, circa il 9% sul player video. Quella distribuzione avrebbe deciso, sei mesi dopo, quali componenti sarebbero stati riscritti per primi.

Quantificò il rischio legale. L’azienda era stata nominata in due cause ADA Title III nei precedenti diciotto mesi, entrambe concluse con una transazione. Maya non riusciva a vedere i valori delle transazioni — il team legale non glieli avrebbe forniti — ma poteva vedere la curva della frequenza delle controversie nel registro pubblico per il suo settore. Costruì un foglio di calcolo che prendeva la superficie di esposizione dell’azienda e produceva una stima dell’intervallo del costo annuale atteso di transazione e correzione in uno scenario di non intervento. Il punto medio di quell’intervallo era di diversi milioni di dollari all’anno.

Quantificò l’opportunità di mercato. Questa fu la riga che mosse la stanza. Maya integrò i dati di ricerca sugli utenti dell’azienda con il sondaggio sugli utenti di screen reader di WebAIM, le statistiche sulla disabilità dei CDC e i dati Eurostat sulla prevalenza della disabilità per i mercati europei che il prodotto serviva. Produsse una singola slide: degli circa 200 milioni di utenti attivi mensili dell’azienda, si stimava che tra 14 e 22 milioni stessero utilizzando il prodotto con qualche forma di tecnologia assistiva o impostazioni non predefinite. Le analitiche mostravano che questo segmento aveva un tasso di abbandono circa 1,8 volte superiore rispetto alla base complessiva. Se la retention su questo segmento potesse essere portata alla parità, l’impatto netto annuale sulle entrate era un numero che Finance riconosceva.

«Non ho mai mostrato il numero di Legal a Marketing, e non ho mai mostrato il numero di Marketing a Legal. A ciascuno di loro ho mostrato il numero che aveva importanza per loro. Al CFO ho mostrato entrambi, su una slide, fianco a fianco. Fu quella la riunione in cui il programma ottenne il finanziamento.»

Maya Okafor, composito, sul caso di finanziamento

Il programma fu approvato alla fine del Q2 2022. Organico: sette persone, con crescita a undici nell’arco di dodici mesi — tre designer, quattro ingegneri, due specialisti QA, un program manager, un ricercatore con esperienza nel reclutamento nella comunità dei disabili. Budget per le partnership di test esterni: una voce a sei cifre all’anno. Autorità: approvazione su qualsiasi nuovo componente del design system, con potere di veto sui componenti che non superavano una checklist di accessibilità. Quest’ultima clausola — il veto — era quella che Maya aveva negoziato con maggiore determinazione. Era la differenza tra un programma e un esercizio di richiesta di permessi.

La revisione del design system: token, focus, movimento

Il lavoro tecnico iniziò nel Q3 2022 e si protrasse per i successivi quattordici mesi. Maya lo strutturò in tre fasi, che chiamava — nelle slide e nelle standup — Fondamenta, Componenti, Pattern. La disciplina di quell’ordinamento, diceva spesso, fu la singola decisione architettonica più importante del programma.

Fase 1 — Fondamenta

I primi sei mesi ricostruirono i design token. Il sistema legacy aveva circa 84 token di colore senza denominazione semantica — «Blue/600», «Grey/400», «Brand/Primary» — e nessun metadato sul contrasto. Il team di Maya li sostituì con una palette semantica di circa 40 token organizzati per funzione: content-primary, content-secondary, surface-base, border-default, più una scala interattiva (action-primary, action-primary-hover, action-primary-pressed) e una scala di stati. Ogni token portava, nei suoi metadati, il rapporto di contrasto rispetto alla superficie su cui era approvato ad essere applicato, e un flag per quale livello di conformità WCAG superava. Gli strumenti lo imponevano: un designer non poteva assegnare content-tertiary su surface-base in Figma senza che il linter lo segnalasse.

La stessa fase standardizzò l’anello di focus. I componenti legacy avevano — Maya li contò — circa diciassette trattamenti diversi per l’anello di focus, che andavano da un contorno puntato da 1 pixel che scompariva sugli sfondi chiari a un anello blu solido da 2 pixel che rompeva il layout nelle liste compatte. Il nuovo anello era un singolo token: un contorno da 2 pixel sfalsato di un gap trasparente da 2 pixel dal bordo del componente, in modo che l’anello fosse leggibile su qualsiasi superficie. Ogni componente interattivo lo adottava per impostazione predefinita; non era possibile optare per una rinuncia.

Le preferenze di movimento furono il terzo fondamento. Il sistema legacy rispettava prefers-reduced-motion in circa un posto — una singola animazione di onboarding — e le app native non lo rispettavano da nessuna parte. Il nuovo fondamento trasformò il movimento in un token, con tre valori (nessuno, ridotto, completo) collegati a ogni primitiva di animazione. Un designer che tentasse di sovrascrivere la preferenza doveva allegare una giustificazione scritta che il responsabile del programma esaminava.

Fase 2 — Componenti

Con le fondamenta stabili, il team si dedicò ai circa 90 componenti primari. L’elenco era ordinato in base ai dati della pipeline dei reclami che Maya aveva estratto nel primo mese: checkout prima, poi messaggistica, poi profilo, poi video. Ogni componente passò attraverso una ricostruzione standardizzata: mappa di navigazione da tastiera, semantica per screen reader, ordine di focus, verifica del contrasto in ogni stato, variante a movimento ridotto, variante RTL, e — su insistenza di Maya — una fixture di test documentata che il team QA poteva eseguire ad ogni release.

Il campo di inserimento del numero di carta di credito, nella sua forma precedente, era un singolo <input> con JavaScript di formattazione automatica che interrompeva l’annuncio da parte dello screen reader dei caratteri digitati; la ricostruzione utilizzò quattro input separati con etichette esplicite, errori collegati tramite aria-describedby e validazione inline annunciata attraverso una live region di cortesia. Richiese sei settimane per un designer e un ingegnere. I ticket di accessibilità relativi al checkout calarono di circa il 70% nel trimestre successivo — perché la maggior parte dei nuovi ticket smise semplicemente di essere depositata.

Fase 3 — Pattern

L’ultima fase fu quella che Maya descrisse come la più semplice nell’esecuzione e la più difficile nel coordinamento. Il team documentò i pattern compositivi — come costruire un flusso modale accessibile sui componenti ricostruiti; come comporre un elenco di elementi con media misti; come strutturare una pagina di impostazioni in modo che la navigazione funzionasse con il controllo vocale. I pattern entrarono nel sito di documentazione del design system come esempi di codice eseguibili. La parte difficile non fu scriverli. La parte difficile fu convincere ogni team di prodotto a utilizzarli invece di inventarne di propri.

Il rollout tecnico

Un design system ridisegnato è una libreria; non è, di per sé, un rollout. Il lavoro di project management più difficile del programma — Maya era categorica su questo — fu la migrazione. Il prodotto aveva circa quaranta squad, ciascuna responsabile di due-cinque superfici, ciascuna libera in pratica di adottare il design system al ritmo consentito dal proprio roadmap. Un piano ingenuo avrebbe chiesto a ogni squad di migrare entro un trimestre. Quel piano avrebbe fallito.

La soluzione di Maya fu un mandato graduato. I nuovi componenti venivano distribuiti come predefiniti; i vecchi rimanevano dietro un feature flag, ma ogni release di una superficie che ancora utilizzava un componente legacy apriva automaticamente un ticket P2 nel backlog di quella squad. Il ticket si escalava automaticamente a P1 dopo novanta giorni e a P0 dopo centottanta. Nel giro di quattro trimestri, circa il 78% dell’utilizzo legacy dei componenti primari era migrato. Nel giro di sei trimestri, quella cifra era circa il 94%.

«La parte difficile non era il design system. La parte difficile era un organigramma di quaranta squad e un ciclo di budget non costruito per questo. I componenti furono tre mesi di lavoro. Il rollout fu tre anni.»

Maya Okafor, composito, sulla migrazione

Quanto costò il programma — e cosa restituì

Maya era scrupolosa nel tracciamento. Quando il programma chiuse la sua fase formale nel Q4 2024, la spesa totale ammontava — nel corso di due anni e mezzo, undici risorse dedicate e test esterni — a qualcosa nell’ordine delle singole cifre alte dei milioni. Il flusso in entrata di ticket correlati all’accessibilità era diminuito di circa il 73% rispetto alla baseline del 2022, nonostante una base di utenti cresciuta di circa il 20%. I due procedimenti legali relativi all’ADA aperti durante la finestra del programma furono entrambi chiusi senza procedere in giudizio, a condizioni che l’azienda descrisse nelle sue comunicazioni annuali come irrilevanti. La retention del prodotto sul segmento di utenti di tecnologie assistive — il segmento che Maya aveva identificato nella proposta di finanziamento — si era ridotta da un rapporto di abbandono 1,8 volte superiore alla base complessiva a circa 1,15 volte. Finance registrò la differenza. Maya non disse quale fosse il numero.

Registrò anche cose che non compaiono nei fogli di calcolo. Il supporto al rotor VoiceOver dell’app iOS nativa, che era notoriamente malfunzionante da anni, divenne — in un audit indipendente all’inizio del 2025 — uno dei più performanti nel suo settore. Il tema ad alto contrasto che Maya aveva spinto nonostante le obiezioni del team del brand divenne il predefinito nelle regioni dove i regolatori locali iniziarono ad applicare l’EAA. Il sito di documentazione del design system, visitato circa 4.000 volte al mese all’inizio del 2022, aveva una media di circa 38.000 visualizzazioni di pagina mensili a metà del 2025. Era stata costruita una pratica; sarebbe sopravvissuta al suo mandato.

Cosa dice ai designer di organizzazioni più piccole

Nel 2025, Maya stava facendo meno turni di terapia intensiva sul proprio prodotto e più lavoro di consulenza per designer di aziende un ordine di grandezza più piccole — team di prodotto di venti persone, di cinquanta persone, la dimensione di organizzazione in cui un singolo designer deve essere per default il responsabile dell’accessibilità. Aveva un piccolo insieme di cose che diceva in ogni incontro informale. Vale la pena elencarle.

Primo. La pipeline dei reclami è la leva. Non si ha bisogno di un milione di utenti per avere una pipeline di reclami; si ha bisogno di una casella di posta di Support e della volontà di leggerla. Stampare i ticket. Metterli in un raccoglitore. Portare il raccoglitore alla riunione. Il raccoglitore funziona.

Secondo. Il caso di finanziamento ha tre colonne. Rischio legale, opportunità di mercato e volume dei reclami. Non si ha bisogno di numeri esatti per nessuna delle tre. Si ha bisogno che la stessa persona veda tutte e tre in un unico posto, perché nessuna singola colonna conquista la stanza.

Terzo. Fondamenta prima dei componenti, componenti prima dei pattern. Un team che inizia riscrivendo i componenti per primi trascorrerà un anno a farlo e arriverà con una bellissima libreria di componenti su una palette di colori non semantica, e il designer successivo riscriverà tutto daccapo.

Quarto. Negoziare il veto. Il singolo maggior punto di leva in un’azienda di prodotto con più team è la capacità di dire «questo nuovo componente non viene distribuito finché non supera la checklist». Il veto, esercitato due volte in due anni, è sufficiente. È la credibilità del veto, non la sua frequenza, a fare il lavoro.

Quinto. Assumere il ricercatore con esperienza nel reclutamento nella comunità dei disabili. La singola riga nel budget del programma di Maya che avrebbe difeso con maggiore determinazione era la posizione del ricercatore. Senza utenti con disabilità nel ciclo, il lavoro è teatro.

Sesto. Il timer sui componenti legacy non è negoziabile. Le migrazioni senza timer non avvengono. Le migrazioni con timer avvengono al ritmo che il timer consente.

Settimo. Prendere la vittoria e andarsene. Maya abbandonò il programma nel Q1 2025 e passò alla consulenza. Il fondatore di un programma di accessibilità è la persona sbagliata per gestirlo a regime. Il compito del fondatore è far esistere il programma. Il compito a regime è essere noioso. Temperamento diverso; persona diversa.

Una nota sul raccoglitore

Maya ha ancora il raccoglitore. Lo tira fuori alle conferenze a volte, quando un senior designer le chiede — di solito con imbarazzo, spesso dopo un panel — cosa fare con i propri quarantuno ticket aperti. Il raccoglitore è spesso mezzo centimetro. L’adesivo sulla copertina dice, con una scrittura sans-serif che Maya acquistò in una cartoleria nel 2022, «Giorno Uno». I quarantuno ticket al suo interno sono stati tutti chiusi. I nomi delle persone che li hanno presentati sono oscurati con un pennarello nero. Non mostra i nomi. Mostra le pagine, e dice: questo è l’aspetto del lavoro, e qui è dove inizia.