Perché l’Accessibilità Deve Essere una Priorità Assoluta nel 2025

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Per favore perdonate eventuali errori, in quanto il bot non è corretto al 100% delle volte.

Hannah Clark: Penso sia arrivato il momento di ammettere che parlare di accessibilità tende a metterci a disagio. Nel contesto del prodotto, tendiamo a dare priorità alle funzionalità con il maggiore impatto e la più ampia percentuale di utenti. Quindi, quando parliamo di costruire prodotti accessibili, sembra di sollevare un tema delicato. Dove possiamo inserire nella roadmap funzionalità che hanno un grande impatto su una percentuale relativamente piccola di utenti? Come facciamo a sapere cosa dovrebbe significare accessibilità per il nostro prodotto, quando accessibile vuol dire cose diverse per persone diverse? E come possiamo fare tutto questo senza fare supposizioni o offendere involontariamente gli utenti che cerchiamo di supportare?

La mia ospite oggi è Prerna Ramachandra, Principal Product Manager presso Yahoo. Prima di entrare in Yahoo, Prerna è stata Senior Product Manager presso Slack, dove è stata determinante nella valutazione e nello sviluppo di funzionalità accessibili per la diversificata base utenti del prodotto. Quello che state per ascoltare è in parte uno studio di caso, in parte un manuale sulle ragioni aziendali per l’accessibilità e sui modi più efficienti ed etici per rendere il vostro prodotto più accogliente per tutti. Iniziamo.

Bentornati a The CPO Club Podcast. Siamo qui oggi con Prerna Ramachandra.

Prerna, grazie mille per aver trovato il tempo, nella tua agenda piena, di essere qui oggi con noi.

Prerna Ramachandra: Grazie a voi per avermi invitato. È un piacere essere qui.

Hannah Clark: Puoi raccontarci un po’ del tuo percorso e di come sei arrivata dove sei oggi?

Prerna Ramachandra: Attualmente sono Principal Product Manager presso Yahoo. Sono qui da circa un anno e mezzo. Prima di Yahoo, lavoravo a Slack, e c’ero poco prima che venisse acquisita da Salesforce e poi durante l’acquisizione stessa. A Slack guidavo principalmente il team di accessibilità e sistemi di design, prima di passare al lavoro sulle esperienze core desktop dell’app.

Il mio lavoro da un team all’altro, in qualche modo, si è intrecciato, cosa su cui mi piacerebbe approfondire più tardi. Prima di Slack, lavoravo al Washington Post dove ho guidato la riprogettazione della loro homepage e la reingegnerizzazione dell’esperienza della pagina articolo. Quindi ho avuto esperienza sia nei media che nella big tech.

Mi piace dire che il mio interesse per il prodotto si trova proprio all’incrocio tra prodotto, tecnologia e narrazione. E nei modi in cui le persone usano le storie per comunicare e come la tecnologia può essere un efficace strumento per farlo.

Hannah Clark: Il che è perfetto, visto che oggi sei qui a raccontare la tua storia.

È chiaramente una cosa di cui siamo entrambe appassionate, la narrazione, e oggi ci concentreremo su qualcosa che forse è un po’ più di nicchia, ma sicuramente una questione di cui, secondo me, non si parla abbastanza: l’accessibilità, e in particolare l’incrocio tra accessibilità e onboarding degli utenti.

Per iniziare, dalla tua esperienza in questo campo: perché spesso l’accessibilità viene trattata come un ripensamento? E quale sarebbe la logica aziendale per inserirla fin dall’inizio?

Prerna Ramachandra: Senza dubbio. Vorrei iniziare con una frase in cui credo fermamente: viviamo in un’epoca in cui la tecnologia non è più un lusso.

Sono cresciuta negli anni Novanta, mi sto un po’ datando qui, quando la tecnologia era ancora una novità. Internet era una novità. Non tutti vi avevano accesso, né tutti ne avevano bisogno, ma oggi ogni nostro servizio essenziale è in qualche modo digitalizzato. E questo significa che ogni persona al mondo dovrebbe poterlo usare con facilità.

E le persone con disabilità vengono generalmente considerate solo in un secondo momento nella nostra società. Credo che tanti dei nostri servizi non siano accessibili, ma la tecnologia è nella posizione unica di integrare facilmente l’accessibilità in ciò che fa. E può davvero semplificare molto la vita a tutti, comprese le persone con disabilità.

Questa è una delle ragioni principali, dal punto di vista etico e morale, per cui credo sia importantissimo darle priorità. Il motivo per cui viene trattata come un ripensamento è, in tutta franchezza, perché la maggior parte delle organizzazioni non comprende il vero valore aziendale dell’accessibilità. Questo è il primo punto. E poi, spesso si pensa che l’accessibilità richieda competenze tecniche approfondite.

Quindi non sempre si ritiene di avere quell’expertise, oppure semplicemente non ci si pensa. Non è integrata nei nostri processi. E come risultato la si ignora, finché qualcuno non si preoccupa di poter avere delle cause legali, o di perdere un cliente con richieste di accessibilità.

Ed ecco che improvvisamente i team si affrettano a capire dove sia il problema e come incorporarvi l’accessibilità. Per rispondere alla seconda parte della domanda, ovvero: qual è la logica aziendale per l’accessibilità? L’ho già accennato. La realtà è che per avere successo nella tecnologia vuoi avere più utenti, giusto? E per la maggior parte di noi, veniamo pagati di più quanto più viene utilizzato il nostro prodotto.

E più persone possono usarlo, più cresce l’uso. Quindi, a livello di base. L’accessibilità è fondamentale perché più persone potranno usare i tuoi prodotti e, così, riuscirai a generare più ricavi. Il rovescio della medaglia è il rischio di azioni legali, che significativamente possono costare anche molto.

Quindi, da entrambi gli aspetti, c’è una chiara logica aziendale per puntare sull’accessibilità. E c’è un altro punto che mi sta molto a cuore e su cui tornerò, ossia che spesso limitiamo l’idea di accessibilità al garantire che sia compatibile con gli screen reader, che si possa utilizzare la tastiera. Ma bisogna andare oltre questa definizione e pensare davvero a come fare in modo che chiunque in qualunque circostanza possa usare il prodotto, perché l’accessibilità può essere anche situazionale e condizionale.

Un esempio che porto spesso è quello dei comandi vocali o dell’uso della voce per comandare un prodotto. Pensiamo sempre che serva a chi ha una ridotta vista. Come mio padre, che è più anziano e non riesce a vedere bene i testi piccoli sullo schermo, quindi usa molto la voce per gestire il telefono.

Ma se sei alla guida, non puoi usare le mani, non puoi usare gli occhi nello stesso modo, quindi potresti comunque usare i comandi vocali. Se pensi all’accessibilità in questo modo, come situazione e non solo come cosa che riguarda l’individuo, il tuo raggio si espande notevolmente e ti rendi conto che stai lasciando fuori un enorme caso d’uso e una grande fetta di utenti.

Che non fa bene agli affari. C’è una chiara logica aziendale, quindi, per inserirla tra le priorità principali fin dall’inizio.

Hannah Clark: Credo che questo sia davvero significativo. Penso che si applichi sia ai prodotti digitali che a quelli fisici e agli spazi fisici. Adoro la prospettiva che sia la situazione a dover essere accessibile più che il singolo caso d’uso. L’ho vissuto anch’io, quando spingevo un passeggino e ho notato quanti spazi sono pensati solo per un pedone alla volta.

E ti rendi conto che ci sono tanti contesti diversi in cui si può avere bisogno di una funzione o accomodamento, o che qualcosa sia progettato tenendo conto dell’accessibilità, perché questo ha valore in ogni età e fase della vita. Quindi sì, mi piace molto questo modo di ragionare e tra poco approfondirei volentieri.

Hai detto che volevi parlare della tua esperienza in Slack, e mi piacerebbe entrare nei progetti a cui hai lavorato, in particolare sui workflow di onboarding accessibile.

Raccontami un po’ come hai approcciato un’analisi dello stato di fatto, per valutare l’accessibilità del prodotto e come siete poi andati avanti?

Prerna Ramachandra: Certo. Quando sono arrivata a Slack, uno dei primi progetti fu proprio capire quanto fosse accessibile il prodotto e come potessimo, appunto come hai detto tu, sviluppare dei framework per l’analisi. In realtà, non c’era nulla quando sono arrivata. Slack era in una fase in cui puntava a grandi clienti enterprise dopo il successo nelle PMI. E proprio lavorando con questi clienti enterprise si è accorta di regole severe sull’accessibilità per i fornitori.

Quindi il primo passo fu sviluppare degli standard interni, chiamati Slack Accessibility Standards. Questi erano basati su standard esistenti come le WCAG, ma anche personalizzati sulle specificità di Slack e di cosa l’accessibilità significasse per i suoi prodotti. Abbiamo quindi creato un framework che permetteva di esaminare il prodotto e verificare se rispettava determinati criteri.

Come risultato di questa analisi, abbiamo assegnato dei voti, come A, B o C, alle diverse funzionalità, per valutarne l’accessibilità. Era sia un’analisi quantitativa che qualitativa. Avevamo una lista di criteri: alcuni erano molto semplici, tipo la gestione dei task – tutto è accessibile da tastiera? Compatibile con screen reader? – altri criteri erano invece più intangibili. Ad esempio, Slack è un prodotto di comunicazione e uno dei suoi punti di forza sono le notifiche. Durante la pandemia, molte persone erano in overload di notifiche, e questo colpiva chi si identificava come neurodivergente, che si sentiva sopraffatto e non riusciva a portare a termine il lavoro. Questo è un esempio più intangibile, che di solito non si trova nelle linee guida classiche.

Abbiamo incluso tutto nel framework. Usando questo framework, assegnavamo voti alle varie feature, in base a task e rapidità nell’esecuzione. Questo aiutava a dare un senso di urgenza ai problemi, e ci diceva cosa fosse più importante. Così abbiamo fatto la prima analisi sullo stato del prodotto, poi siamo andati dalla leadership e abbiamo mostrato la situazione e identificato i problemi più urgenti da risolvere, perché fondamentali per l’utilizzo da parte di certi utenti.

Il bello del framework era che non si applicava solo ai prodotti esistenti: anche per i nuovi si poteva usare per capire cosa controllare prima del lancio.

Ho lavorato molto anche con team specifici per aiutarli a sapere su cosa puntare in base al framework. Siccome tutti hanno delle roadmap, nessuno vuole stravolgere i propri piani per una cosa nuova. Quindi lavoravo con i singoli team per mostrare cosa fosse veramente critico per loro. Così, andando in leadership insieme, presentavamo un piano chiaro con trade-off, livello di effort, possibili slittamenti e che impatto avrebbero.

Quindi penso che sull’accessibilità, e non solo, occorra saper bilanciare il lavoro a livello di team e la negoziazione con la leadership per ottenere priorità. Ho avuto la fortuna che i leader di Slack erano davvero impegnati sull’accessibilità. A loro serviva solo chiarezza: quanto tempo serve, quali trade-off, quali impatti, e noi lo abbiamo saputo fornire.

Insomma, si è trattato sia di gestione delle persone sia di collaborazione tecnica con ingegneri per l’analisi necessaria.

Hannah Clark: È davvero fondamentale. L’adesione e il coinvolgimento, come dici tu, sono la chiave per far sì che queste funzionalità vengano effettivamente rilasciate – e fatte come si deve.

Vorrei andare un po’ più sul concreto, sui trade-off. Come li presentavi al team? Un esempio pratico di come contestualizzare il progetto e spiegarne la priorità?

Prerna Ramachandra: Il team più impattato fu quello che lavorava sul core messaging di Slack. Avevano la superficie più estesa, dalla scrittura all’invio e ricezione dei messaggi. Gestivano anche i canali. Se conosci Slack, sai che questa è la parte centrale. Avevano quindi anche più cose da sistemare.

Per fare un esempio concreto, ipotizziamo di andare da loro con una lista di 100 problemi di accessibilità da risolvere per rendere l’area messaging usabile da chi utilizza screen reader, navigazione da tastiera, o ha disabilità. Prima cosa, mi sedevo col PM e dicevo: ecco i problemi. Il PM poteva dirmi che l’80% era davvero critico (e in base ai dati e alle modalità d’uso effettive alcuni flussi potevano avere già soluzioni alternative, quindi non tutto era prioritario). Fare questa analisi insieme al PM del team è fondamentale.

Così riducevamo, ad esempio, da 100 a 80 problemi. Poi si guardava quali aree stessero per essere ridisegnate o dismesse a breve, quindi si decideva di integrarci l’accessibilità direttamente nel redesign e rimandare la correzione. Altre aree invece sarebbero state eliminate a breve e non valeva la pena investire.

Così scendevamo a circa 70 issue. Poi con gli ingegneri e almeno un esperto di accessibilità (noi fortunati ne avevamo uno molto bravo), si faceva una stima del lavoro su ogni issue. Si verificava quante potessero essere incluse nel prossimo sprint senza impatti sulla roadmap, magari 20 su 70. Il resto, altri 50, si analizzava con la leadership se era il caso di far slittare altra progettualità.

Ad esempio, c’era una funzionalità importante per un grande cliente, ma lo stesso cliente voleva anche le correzioni di accessibilità. Quindi si trasmetteva alla leadership il trade-off, coinvolgendo anche l’account manager del cliente, e si chiedeva quale aspetto ritenessero prioritario. In questo modo, alcune issue venivano pianificate per lo stesso quarter, altre per il seguente.

Col tempo, nei cicli di pianificazione trimestrali abbiamo potuto fissare sprint dedicati solo all’accessibilità (ad esempio, durante la giornata mondiale dell’accessibilità), coinvolgendo tutti i team di sviluppo. Era bello e creava coesione.

Abbiamo organizzato anche workshop sull’accessibilità. Insomma, molto lavoro iniziale, e per le grandi priorità vanno coinvolti i leader perché aiutino nella negoziazione.

Hannah Clark: Molto bello! Che bello sentire di team interi coinvolti sull’accessibilità e che ciò abbia anche portato positività al clima interno.

Sempre parlando di collaborazione tra diversi team, come si lavora in aziende che hanno vari prodotti e varie squadre che devono affrontare le problematiche di accessibilità in parallelo?

Prerna Ramachandra: Ottima domanda. Ci sono due pilastri per affrontare questa sfida.

Il primo è strutturale: se l’azienda ha un team centrale di accessibilità (oggi molte ne hanno uno), bisogna vedere dove si colloca all’interno della struttura. Se è chiuso in un solo verticale, sarà difficile lavorare con gli altri team. Bisogna che la posizione sia quella giusta. Se non lo è, il/la PM deve fare la fatica di contattare e conoscere gli altri team e le loro roadmap.

Il secondo aspetto è la comunicazione costante sulle roadmap sia per i responsabili del team centrale sia per i PM dei team funzionali.

Se sai cosa bolle in pentola, questo era la nostra più grande sfida (ma anche opportunità) in Slack. Quando sono passata dal team accessibilità centrale a un team funzionale, la cosa fondamentale era essere coinvolti già nella fase di pianificazione e di design.

L’accessibilità, pur richiedendo expertise tecnica, parte spesso dal design, non dall’ingegneria. Strumenti come Figma hanno delle funzionalità apposta per la progettazione accessibile – il/la designer va coinvolto fin dall’inizio per assicurarsi che tutto funzioni.

Se hai già issue noti, qui torna utilissimo il framework sviluppato: ogni bug può essere categorizzato (critico, medio, basso), così anche chi non ha grandi competenze può capire se sia prioritario o meno intervenire.

Ciò evita che ci sia una sola persona a dover “tirare le fila” a tutti i costi. L’obiettivo non doveva essere fare il “preside” che controlla gli altri, ma fornire strumenti a chi volesse fare bene.

E posso dire che tutti veramente ci tengono: spesso non sanno come fare o se sarà autorizzato/spazio nella roadmap. Dare loro gli strumenti (un framework, delle linee guida) li rende autonomi e responsabili, sia per bug, sia per progettazione di nuove feature. Così si previene il dover poi rincorrere e risolvere problemi più avanti.

Hannah Clark: Interessantissimo! Ora sul tema dell’implementazione e dell’iterazione: man mano che escono nuove funzionalità o altre vengono sostituite, come si può fare in modo che l’analisi sull’accessibilità venga integrata anche sul nuovo sin dal giorno uno?

Prerna Ramachandra: Ottima domanda anche questa. Faccio un esempio specifico: ad esempio, per l’onboarding degli utenti. Dal momento della pianificazione serviva sempre pensare all’accessibilità.

Ma c’è anche una componente di intuizione e di dati: bisogna capire chi tra i clienti può aiutare a testare nuove soluzioni accessibili. Spesso trascuriamo che ci sono già utenti con disabilità che possono partecipare ai test di ricerca. Quindi vanno coinvolti già dall’inizio.

Tornando all’onboarding: avevamo notato lacune, ma anche che il team stava ridisegnando il flusso. Abbiamo quindi potuto essere coinvolti fin dall’inizio, così che il design fosse accessibile da subito. Il nostro designer era parte fissa dell’iter: durante le ricerche utente, i test, la creazione dei mockup in Figma, costruiva le specifiche accessibili in parallelo.

La stessa cosa abbiamo fatto per il redesign dell’app desktop. Abbiamo realizzato un onboarding specifico, sul modello di quello dei Mac di Apple (che sono ottimi sull’accessibilità): all’entrata nell’app, si chiede se si è interessati all’accessibilità. Se sì, si attiva un tutorial step by step con tutti gli strumenti, la navigazione da tastiera, i comandi principali ecc. In base alle risposte, mostravamo anche suggerimenti mirati nel prodotto.

Tutto questo è stato possibile perché, individuando i gap, abbiamo ascoltato i clienti e ci siamo resi conto che mancava un onboarding pensato per chi utilizza funzionalità di accessibilità.

Per la progettazione futura, affidiamoci tantissimo alla ricerca utenti. Parlare con chi usa il prodotto è la fonte migliore di informazioni, molto più che l’AI. Oggi ci sono società, ad esempio Fable, che aiutano a reperire utenti con disabilità per i test (una sorta di usertesting.com ma per l’accessibilità).

Rispetto all’implementazione, occorre che il designer abbia conoscenze di accessibilità o lavori a stretto contatto con chi ne capisce, e che le specifiche accessibili siano parte integrante già del design. Solo così gli ingegneri potranno implementare senza fraintendimenti.

Testare, iterare, ascoltare chi ha esigenze particolari è la chiave per una vera accessibilità proattiva, anziché dover mettere mano in emergenza in seguito.

Hannah Clark: Sai che adoro i consigli pratici! Grazie per aver fornito indicazioni così precise. Solo per chiudere (andiamo verso la fine), parliamo di analytics.

Abbiamo parlato di dati: come misurare il successo delle funzionalità di accessibilità a cui abbiamo lavorato con tanto impegno? Ovviamente, nell’analizzare l’attivazione e altre metriche chiave, bisognerà distinguere fra il successo della funzionalità accessibile e quello dell’intero prodotto. Ci sono strumenti che raccomandi? E altre dritte su come integrare questi dati nelle iterazioni future?

Prerna Ramachandra: Darò una risposta che metterà a disagio molti PM, me compresa: non puoi basarti solo sui dati quantitativi per comprendere se le funzionalità accessibili funzionano davvero.

Anche da un punto di vista etico e morale, è difficile segmentare gli utenti per accessibilità perché dovresti fare ipotesi troppo forti su ciascun individuo. E anche se conti quanti usano la tastiera o lo screen reader, rischi comunque di escludere tante persone (es: le neurodivergenze non sono tracciabili così). Idem per chi disattiva le animazioni per motivi medici.

Insomma, i dati quantitativi aiutano solo fino a un certo punto. Molto meglio puntare sulla ricerca qualitativa: parlare direttamente con gli utenti, chiedere feedback, organizzare interviste e test di usabilità con chi usa le varianti accessibili. È la strada migliore per sapere se si riescono a svolgere realmente le azioni necessarie.

A volte si può misurare anche internamente: ad esempio, a Slack abbiamo creato un’API per facilitare l’integrazione della navigazione da tastiera. Il successo veniva misurato da quante squadre usavano l’API. Ma per l’utente, la misura migliore erano i feedback qualitativi raccolti appositamente da chi aveva richiesto/partecipato al workflow accessibile.

Certamente, bisogna includere attivamente utenti sensibili all’accessibilità durante la validazione. Se a livello generale il prodotto va bene, è già segnale che si è sulla buona strada, ma per l’accessibilità occorre ascoltare utenti specifici e prevedere sessioni di confronto personalizzate.

Una risposta insoddisfacente forse, perché tutti i PM vorrebbero numeri e certezze. Ma bisogna accettare un po’ di incertezza. Nessun prodotto sarà mai perfetto su tutta la gamma delle esigenze, anche situazionali. Ecco perché occorre dialogare costantemente con le persone.

E posso assicurare che chi ha bisogno di accessibilità è di solito molto proattivo nel segnalare problemi, perché spesso resta tagliato fuori dalle soluzioni standard. È stato proprio lavorando sull’accessibilità che ho imparato quanto faccia la differenza ascoltare gli utenti. Nessun algoritmo sostituisce davvero la connessione umana e la ricerca qualitativa.

Hannah Clark: Verissimo. Qui siamo sempre super favorevoli alla ricerca utenti! Qualche tempo fa abbiamo anche fatto un episodio con Steve Portigal su come intervistare gli utenti – è uno dei nostri preferiti in assoluto, proprio per l’importanza di ascoltare davvero le esperienze autentiche e ridurre i bias nello sviluppo prodotto.

Grazie mille, questa è stata una conversazione preziosissima. Apprezzo tantissimo la tua prospettiva approfondita e i casi pratici su un prodotto così noto, che permette a tutti noi di capire bene come queste funzionalità prendano vita.

Dove possiamo seguirti online o metterci in contatto con te?

Prerna Ramachandra: Mi trovate su LinkedIn – solo nome e cognome, Prerna Ramachandra. Potete anche contattarmi tramite il mio sito: PrernaRamachandra.me.

Hannah Clark: Fantastico. Grazie mille per essere stata con noi.

Prerna Ramachandra: Grazie a te, Hannah. È stato un piacere.

Hannah Clark: Grazie per l’ascolto. Per altre guide pratiche, recensioni di strumenti e consigli esclusivi, iscrivetevi alla nostra newsletter su theproductmanager.com/subscribe. Potete ascoltare altre conversazioni come questa iscrivendovi a The CPO Club, ovunque troviate i vostri podcast.