Una persona cieca può sviluppare software? -

In questo primo incontro degli Accessibility in Tech Jobs abbiamo cercato di rispondere a questa domanda intervistando due sviluppatori: Luca e Francesco.

Luca Davanzo, cieco dalla nascita e residente ad Udine, dal 2000, dopo la laurea in informatica, è dipendente di una grande azienda del settore in Friuli Venezia Giulia. Sviluppa software in ambito sanitario usando vari linguaggi, in particolar modo Java, SQL, e tecnologie affini in ambito back-end. Si occupa di sviluppare software di integrazione, web app e web services.

Francesco Tranfaglia, anche lui non vedente quasi dalla nascita, residente a Roma, si occupa dello sviluppo di back-end per applicazioni web e mobile, usando J2EE e NodeJS.

Ogni persona con disabilità visiva è unica e vive la propria condizione in maniera diversa, perché diversi sono i fattori che influiscono sul modo di vivere e relazionarsi con le persone, l’ambiente fisico e la società in cui si trova a interagire. Possiamo comunque dire che, nonostante la disabilità visiva sia varia e complessa, l’accessibilità digitale è un bisogno specifico riconducibile a tutte le persone cieche e ipovedenti.

Le tecnologie assistive svolgono una funzione essenziale per poter gestire gli strumenti tecnologici in modo autonomo, ad esempio gli ScreenReader sono software lettori di schermo che identificano ed interpretano ciò che una persona vedente osserva sullo schermo di un computer, attraverso una sintesi vocale o un display braille.

Per poter permettere alle persone di visionare interamente i contenuti delle pagine che vengono navigate è necessario porre alcune attenzioni come per esempio l’inserimento di un testo alternativo (Alt Text) per le immagini che diversamente non sarebbero lette dal lettore di schermo. Quando vengono caricati contenuti visuali su siti/app è fondamentale ricordare di inserire l’Alt text, permettendo così alle persone con disabilità visiva di ricevere informazioni corrette; allo stesso modo, se i siti/app/programmi non sono stati sviluppati in modo accessibile, si creano barriere agli ScreenReader che così non riescono a comunicare il contenuto agli utenti.

Un altro strumento a supporto degli sviluppatori con disabilità visiva è la barra braille. Il contenuto mostrato a video viene riprodotto da questo dispositivo hardware che è dotato di una riga di celle a 8 punti. Da ciascuna cella fuoriesce una combinazione di punti equivalente a un carattere (lettera, numero, segno grafico) del codice Braille letto scorrendo la riga con le dita.

Il testo è riportato sul display braille una riga alla volta in base alla posizione del cursore; l’estensione della barra braille può variare da 20, 40 a 80 celle e ogni persona sceglie la barra Braille più rispondente alle proprie esigenze.

Anche se potrebbe sembrare uno strumento più disagevole rispetto alla sintesi vocale, in realtà per chi sviluppa software esso ha dei vantaggi. Le informazioni vengono infatti acquisite e veicolate attraverso il tatto, consentendo una gestione e interazione che si avvicina di più alla modalità di lettura visiva.

La barra braille permette alla persona che sta sviluppando di avere un controllo rapido ed efficace su ogni singolo carattere del codice, inclusi i simboli di punteggiatura utilizzati per delimitare le istruzioni nel linguaggio di programmazione, come i punti e virgola, parentesi etc.

La sintesi vocale è in grado di identificarli, ma richiede la necessità di definire ciò che viene letto attraverso i livelli di prolissità; la complessità della gestione del processo di sviluppo aumenta poiché tutte le informazioni passano attraverso il canale uditivo.

La difficoltà più grande riscontrata da Francesco è quella di avere le informazioni relative alle interfacce grafiche ben strutturate con una corretta semantica, ci ha riportato infatti un esempio di software che per queste era poco accessibile e quindi rendeva lo svolgimento del suo lavoro meno fluido.

Un paradosso che è emerso durante l’incontro è che le grandi aziende sembrano essere più aperte e sensibili alle questioni dell’accessibilità rispetto a quelle del mondo open source. Probabilmente perché quest’ultime risultano essere molto più frammentate e quindi più difficili da raggiungere e sensibilizzare.

Per esempio, nonostante Telegram sia open source e quindi in teoria dovrebbe essere più attenta alla diversità delle persone che utilizzano lo strumento, per quella che è l’esperienza del team degli Accessibility Days, WhatsApp (che ha alle spalle Facebook) risulta molto più accessibile. Le grandi aziende hanno anche un bacino di utenti maggiore e sicuramente maggiore budget da poter dedicare all’accessibilità.

Un altro ambito interessante della vita lavorativa di uno sviluppatore che è stato approfondito durante l’incontro riguarda la modalità d’interazione fra i vari componenti del team. Strumenti come Microsoft Teams, Google Meet e le rispettive suite che permettono di lavorare in modo condiviso sono molto validi a livello di accessibilità. Non altrettanto si può affermare per board come Miro o Mural, che vengono spesso usati in ambito agile, su cui si possono ancora evidenziare notevoli problematiche di accessibilità.

La metodologia agile è basata su forme di collaborazione che sfruttano aspetti molto visivi: si pensi alle Kanban Board o i Post-it, che se da un lato possono essere considerate smart, dall’altro generano barriere di accesso per le persone con disabilità visiva.

L’accessibilità è veicolo concreto di autonomia. Nei team di Luca e Francesco, gli strumenti non accessibili che avrebbero potuto impedire la gestione degli incarichi affidati, sono stati bypassati dal lavoro di squadra, diventato metodo per superare le barriere di accessibilità.

Queste due aziende hanno compreso che la capacità di sviluppare software di Luca e Francesco va oltre i limiti oggettivi che possono incontrare a causa di strumenti non accessibili.

Chi ricopre il ruolo di developer con disabilità visiva può avere un ruolo molto importante all’interno di un’azienda se il suo coinvolgimento avviene fin dall’inizio nella realizzazione di prodotti accessibili. C’è spesso un conflitto tra designer che puntano a vendere e l’effettiva accessibilità poi di ciò che viene realizzato. Per i clienti la parte di design e grafica tende infatti a prevalere rispetto ai requisiti di accessibilità. Le aziende dovrebbero promuovere ai committenti prodotti più rispondenti alle linee guida WCAG senza per questo rinunciare ad un design accattivante.

Stefano Ottaviani, componente del board Accessibility Days, sostiene che “l’accessibilità, come è stato per il mondo agile, è un processo. È importante che chi si occupa di sviluppo sia consapevole delle modalità d’interazione delle tecnologie assistive per comprendere cosa migliorare collaborando a stretto contatto con persone con disabilità ed esperte di accessibilità”. Questo processo va inserito nella formazione e nella cultura aziendale di developer e designer.

Luca e Francesco hanno infine fatto una dimostrazione pratica di come lavorano.

Nella loro demo hanno fatto vedere come possano sviluppare codice di back-end e seguire buone pratiche di programmazione, come la scrittura di test automatici (unit test, integration test etc.), fondamentali per ottenere un codice di qualità e manutenibile nel tempo.

Purtroppo, sia in Italia che nel resto del mondo, troppe poche aziende sviluppano codice corredandolo di test automatici, poiché preferiscono, a discapito della qualità consegnare applicazioni tagliando sui costi di realizzazione.

Francesco e Luca ci hanno dimostrato che i limiti che una persona con disabilità visiva può avere, nulla hanno a che fare con la professionalità che può acquisire, grazie anche alle tecnologie assistive e alla capacità di scrivere codice di qualità seguendo le best practice per lo sviluppo.

Questo primo incontro è stato molto interessante e ricco. Vi aspettiamo al prossimo!

Tutti i dettagli sulla pagina dedicata degli Accessibility in Tech Jobs.