Andiamo al cuore dell’accessibilità digitale

Al volo: qual è la prima cosa che vi viene in mente pensando alle parole “developer” o “coder”? Forse un maschio bianco di vent’anni circa che vive in una metropoli movimentata, con indosso una t-shirt da nerd e una felpa col cappuccio? Qualcuno in qualche modo simile a Mark Zuckerberg? O forse un giovane Bill Gates o un Sergey Brin? Oppure uno dei tizi della serie della HBO Silicon Valley? Di sicuro nessuno come me.

Per gli standard tech, sono vecchia. Inoltre, sono donna e madre. Vivo in una cittadina del midwest che non avete mai sentito nominare e che non visiterete mai: una città in cui le mucche sono molto più numerose delle persone. Il colore dei miei capelli è (quasi) naturale e non fa più parte della collezione ROYGBIV, quindi non godo di alcuna reputazione. Ho circa un migliaio di t-shirt da geek, ma in realtà non le indosso mai in pubblico, optando per un abbigliamento più “femminile” (come è stato sottolineato da un collega maschio). In superficie, sembro più adatta a prendere appunti durante una riunione insegnanti-genitori che a scrivere codice. Sono un po’ una outsider. Una tech misfit.

Perciò, quando mia figlia di 11 anni dopo la fine del coding camp a cui ha partecipato di recente ha dichiarato tutta contenta “Mamma, adesso sono una vera developer, proprio come te!” c’è stato un po’ di solito orgoglio genitoriale, ma anche una smorfia da parte di una piccola parte di me perché, per quanto io supporti i settori STEM e voglia che la prossima generazione di ragazze conti nei propri ranghi delle maghe del codice/unicorni/ninja, non voglio realmente che mia figlia sia una developer. La motivazione che sta dietro a questa affermazione pesante (e magari controversa) deriva da un istinto di protezione: il mondo tech in cui viviamo oggi è ben lungi dall’essere perfetto. Io stessa ho dovuto sopportare la mia parte di misoginia, insicurezza e molestie sessuali. Perché non dovrei proteggerla da tutto questo?

L’elefante (della diversità) nella stanza (del computer)#section1

Avete già sentito questa storia: non c’è sufficiente diversità nel settore tech. Questo trend sconcertante sembra protrarsi anno dopo anno, nonostante numerosi studi abbiano mostrato che includendo più persone dalle comunità meno rappresentate, un’azienda può far crescere il proprio tasso di innovazione, la propria employee retention e il proprio bilancio. Anche con la recente spinta e il presunto sostegno alla diversità e all’inclusività da parte di molte aziende Fortune 500, le donne e le persone che si identificano come donna detengono ancora solo il 20% di tutti i lavori tecnologici più importanti.

I dati di FY 2018 mostrano che la percentuale di donne nei ruoli tecnici nelle tre top aziende giganti del tech è stata pari al 24% in Adobe, 26% in Google e 22% in Facebook. Sebbene questi numeri mostrino che non ci sia ancora abbastanza rappresentanza delle donne, riflettono anche un leggero incremento rispetto all’anno precedente (FY 2017: Adobe 22%, Google 25%, Facebook 15%). Ma nonostante questo trend di crescita nell’assunzione delle donne nei ruoli tech, il tasso di crescita marginale non ha tenuto il passo con il mondo reale. La forza lavoro tech ha seriamente perso il contatto con la realtà se, nel 2019, un segmento della popolazione (le donne) che rappresenta più delle metà della popolazione globale viene ancora considerato una minoranza.

A volte, viene data la colpa di questa mancanza di diversità ai piani superiori a una questione di “pipeline”. Il ragionamento sottostante è: “Se non c’è un numero sufficiente di ragazzine che vogliono imparare a programmare, allora non ci sarà un numero sufficiente di donne che vorrà programmare”. Tuttavia, negli ultimi anni sono schizzati alle stelle i progetti che hanno come scopo l’insegnamento della programmazione alle ragazze. Le ragazze adesso costituiscono circa la metà delle iscrizioni nelle classi di programmazione alle superiori e hanno risultati praticamente identici ai loro compagni di classe maschi nei test standardizzati di matematica e scienze, però le giovani donne costituiscono solo il 18% di tutti i titoli di laurea in Informatica. Devo chiedermi se questo drastico calo di interesse abbia più a che fare con la mancanza di rappresentanza nella sfera tech piuttosto che col fatto che le ragazze e le giovani donne semplicemente non siano “sufficientemente intelligenti” o “non interessate” a lavorare con il codice. Come minimo, la mancanza di rappresentanza di sicuro non aiuta.

Ovviamente, il quadro della diversità diventa ancor più terribile quando si considerano altri gruppi sotto-rappresentati come le persone di colore, le persone della comunità LGBTQ e le persone con disabilità. E mentre non mi piace sorvolare su tali questioni più profonde di diversità nel mondo tech, perché sono fallimenti più abbondanti e molto più grotteschi rispetto alla percentuale maschio/femmina, non mi sento nemmeno qualificata per parlare di questi problemi. Vi incoraggio a osservare e a dare valore alle voci di altri che possono parlare con maggior autorità su queste problematiche più profonde nell’ambito della diversità, come Ire Aderinokun, Taelur Alexis, Imani Barbarin, Angie Jones, Fatima Khalid, Tatiana Mac, Charlie Owen, Cherry Rae e molti altri. E per quei lettori che sono digiuni del tema della diversità nel settore tech, guardate la recente talk di Tatiana Mac “How Privilege Defines Performance”: vale proprio 35 minuti della vostra vita.

I quattro stadi del viaggio dell’accessibilità digitale#section2

In qualsiasi modo lo si guardi, i numeri non mentono. Ci sono alcune questioni di diversità piuttosto significative nel settore tech. Ma allora come sistemiamo questa cosa prima che la successiva ondata di giovani sviluppatori si unisca alla forza lavoro tech? Semplice: insegnate agli sviluppatori a scrivere codice accessibile.

Ad alcuni potrebbe sembrare uno scherzo e ad altri potrebbe sembrare un po’ stiracchiato, ma ascoltatemi. Quando parliamo di codice accessibile, quello di cui in sostanza stiamo realmente parlando è inclusività. L’effettivo processo di scrittura di codice accessibile implica regole e standard, test e tool, ma lo sviluppo inclusivo è più astratto di così. È un cambiamento nel modo di pensare. E quando ripensiamo il nostro approccio allo sviluppo, andiamo oltre il semplice livello base della semplice funzionalità del codice. Al contrario pensiamo al modo in cui viene consumato questo codice. Come possiamo renderlo più intellegibile e semplice da usare per le persone? Sviluppo inclusivo significa fare qualcosa che abbia valore, non solo accessibile, per quante più persone possibile.

Questo modo di pensare è un po’ astratto, quindi vediamo un esempio. Supponiamo che vi sia dato il compito di aggiornare il contrasto di colore tra il testo su una pagina web o in un’app e lo sfondo. Cosa succede nei vari stage del viaggio di accessibilità?

Stage 1: Consapevolezza. Siete dei novellini dell’accessibilità digitale e state ancora cercando di comprende cosa sia e come potete implementare dei cambiamenti nel vostro workflow quotidiano. Potreste essere a conoscenza del fatto che ci sia un insieme di linee guida per l’accessibilità digitale che vengono seguite da altri sviluppatori, ma avete le idee un po’ confuse su cosa significhi tutto ciò in senso pratico.

Stage 2: Conoscenza. Sapete qualcosa di più sull’accessibilità digitale e vi sentite a vostro agio nell’usare qualche tool di test, così fate un test di accessibilità automatizzato sul vostro sito, che evidenza un possibile problema con il contrasto dei colori. Basandovi sulla vostra consapevolezza delle linee guida, sapete che il rapporto di contrasto dei colori tra il testo e lo sfondo deve essere un certo numero e che vi serve un tool per testarlo.

Stage 3: Practice — Feeling more confident in your knowledge of digital accessibility rules and best practices, you use a tool to measure the color contrast ratio between the text and the background. Then based on the output of the tool, you modify the hex code to meet the color contrast ratio guidelines and retest to confirm you have met the accessibility requirements for this issue.

Stage 3: Pratica. Sentendovi più sicuri nella vostra conoscenza delle regole dell’accessibilità digitale e delle best practice, usate un tool per misurare il rapporto del contrasto dei colori tra il testo e lo sfondo. Poi, basandovi sull’output del tool, modificate il codice hex perché soddisfi il rapporto di contrasto dei colori dettato dalle linee guida e ritestate il tutto per confermare di aver soddisfatto i requisiti di accessibilità per questa problematica.

Stage 4: Comprensione. Capite che le linee guida e i tool di accessibilità sono creati tenendo a mente le persone e che il codice è secondario a tutto questo. Uno è il mezzo, l’altro il fine. Nell’esempio del contrasto di colore, capite che le persone con problemi di vista o daltoniche hanno bisogno di questi cambiamenti nel contrasto per vedere effettivamente le parole sulla vostra pagina web.

Si tratta di un’eccessiva semplificazione del processo. Ma spero che ne abbiate colto l’essenza: ci sono vari stage della conoscenza e della comprensione dell’accessibilità digitale. I veri principianti potrebbero non trovarsi nemmeno allo stage 1, ma di questi tempi trovo sempre più raramente quel gruppo. Pare che si sia sparsa la voce sull’accessibilità digitale! Il che è ottimo, ma è solo il primo ostacolo. Quello che adesso vedo è che molte persone si fermano allo Stage 2: Conoscenza o allo Stage 3: Pratica, in cui si è consci delle linee guida dell’accessibilità digitale, si sanno usare alcuni strumenti di test e si sa come sistemare alcuni problemi segnalati ma non si sono ancora uniti del tutto i puntini con gli umani su cui hanno un impatto.

Dal punto di vista del portare a termine le cose da fare ogni giorno, gli stage 2 e 3 vanno bene come punti a cui fermarsi. Ma cosa succede quando le cose che dovete fare sono troppo complesse per una riparazione rapida o nessuno dei vostri pari o del management vi sostiene? Credo che una volta che si arriva allo Stage 4: Comprensione e si capisce davvero il motivo per cui questo tipo di cambiamenti è necessario, le persone saranno più motivate a fare quei cambiamenti indipendentemente dalle sfide che comportano. Quando arrivate allo stage 4, siete andati oltre la conoscenza delle regole base, i test e la programmazione. Riconoscete che l’accessibilità digitale non è solo un “nice to have” ma un “must have” ed è una questione di qualità della vita per persone reali. Questa è la digital inclusion. È qualcosa che non si può non vedere, non si può disimparare e non si può ignorare.

Fare dell’accessibilità digitale una priorità, non un requisito#section3

In my role as an accessibility trainer, I like to kick-off each session with the question: “What are you hoping to learn today about digital accessibility?” I ask this question to establish a rapport with the audience and to understand where everyone is in their accessibility journey, but I am also evaluating the level of company and individual buy-in too. There is nothing worse than showing up to teach a group that does not care to be taught. If I hear the words “I am only here because I have to be” — I know it will be an uphill battle to get them anywhere close to Stage 4: Understanding, so I mentally regroup and aim for another stage.

Nel mio ruolo di accessibility trainer, mi piace fare il kick-off di ogni sessione con la domanda: “Cosa sperate di imparare oggi sull’accessibilità digitale?”. Pongo questa domanda per stabilire un rapporto con il pubblico e per capire a che punto si trova ognuno nel proprio viaggio nell’accessibilità, ma contemporaneamente sto anche valutando il livello di buy-in dell’azienda e della singola persona. Non c’è nulla di peggio del presentarsi a insegnare a un gruppo a cui non interessa nulla di ciò che insegnerete. Se sento le parole “Sono qui solo perché devo”, so che sarà una strada tutta in salita per arrivare anche solo nei paraggi dello Stage 4: Comprensione, quindi mi riorganizzo mentalmente e mi dirigo verso un altro stage.

Nella mia esperienza, quando le aziende e i loro leader dicono “L’accessibilità digitale è un requisito”, nove volte su dieci c’è un fattore che motiva questa dichiarazione generica (per esempio, un processo imminente o almeno la paura di un processo). Quando i cambiamenti sono inquadrati come obbligatori o confezionati come direttive dall’alto con poco altro contesto, le persone possono fare resistenza e troveranno delle scuse per obiettare o sfidare la dichiarazione e ogni cambiamento diventerà una battaglia in salita. Etichettare qualcosa come “obbligatorio” parla solo allo Stage 1: Consapevolezza.

Sostituendo una parola dalla dichiarazione originaria e dire “L’accessibilità digitale è una priorità”, le aziende e i loro leader hanno reinquadrato la conversazione con i propri impiegati. Quando i cambiamenti sono inquadrati come “lavorare verso una soluzione” e vengono apertamente e collaborativamente discussi, la gente si sente parte di un processo ed è più aperta al cambiamento. A lungo andare, adottare un cambiamento diventa parte della cultura aziendale e porta all’innovazione (e sì, all’inclusione) a tutti i livelli. Definire qualcosa come una priorità parla allo Stage 4: Comprensione.

Alcune delle scuse che sento spesso dai clienti per non assegnare una priorità all’accessibilità è che è troppo difficile, troppo costosa e/o prende troppo tempo: ma è davvero così? Nello stesso training sull’accessibilità, faccio fare un esercizio in cui guardiamo un sito web con un tool per testare l’accessibilità e facciamo una revisione di qualunque problema si presenti. Con l’aiuto del gruppo delineiamo l’“impatto sull’utente” rispetto al “lavoro per rimediare” da parte del team. Da gruppo a gruppo, sebbene i grafici siano leggermente differenti, hanno tutti in comune che circa l’80% degli errori delineati ricade nel quadrante “semplice da sistemare” per il team e contemporaneamente nel “grande impatto” sull’utente. Basandomi su questi dati empirici non mi bevo più le scuse dei clienti che dicono che l’accessibilità è troppo difficile e costosa e che richiede troppo tempo. Si riduce tutto all’essere una priorità, per ogni singolo individuo e per l’azienda nel suo insieme.

Quale sarà la vostra eredità in fatto di codice?#section4

Il teorema della scimmia instancabile dice che una scimmia che prema a caso i tasti di una tastiera per un tempo infinitamente lungo quasi certamente riuscirà a comporre qualsiasi testo prefissato, come l’intera opera di William Shakespeare. Quindi, seguendo questa stessa logica, un programmatore che prema tasti a caso su un computer per un tempo infinitamente lungo quasi sicuramente produrrà un sito web accessibile. Ma dov’è il processo riflessivo? Dov’è l’elemento umano? Sebbene tutte le cose di cui abbiamo già parlato (consapevolezza, istruzione e priorità all’accessibilità sono passi importanti nel rendere il mondo digital più inclusivo per tutti – senza intenzione finiremo proprio con il premere tasti a caso sul nostro computer, ripetendo ogni volta gli stessi errori. L’intento che sta dietro al codice deve far parte del processo, altrimenti l’accessibilità è solo un altro task senza significato.

Sarò ingenua, ma mi piace pensare che siamo giunti ad un punto nella nostra società in cui vogliamo che le nostre vite lavorative abbiano un significato e che non vogliamo solo sentir parlare del cambiamento positivo che è in atto, ma vogliamo farne parte. L’accessibilità digitale è dove questo può accadere! Non solo comprendere e scrivere codice guidato da uno scopo aiuta le persone con disabilità a breve termine, ma io credo fermamente che sia la chiave per risolvere la questione complessiva della diversità nel settore tech a lungo termine. Gli sviluppatori che raggiungono lo Stage 4: comprensione e che danno priorità al codice accessibile perché capiscono che fondamentalmente stiamo parlando di persone, saranno anche coloro i quali aiuteranno a creare e coltivare un ambiente inclusivo in cui alle persone dai background più disparati venga data la priorità e vengano accettati nel mondo tech.

Perché quando si tolgono tutti gli stili, tutto il markup, tutte le feature fichissime da un sito web o da un’app, cosa rimane? Le persone. E onestamente, più imparo sull’accessibilità digitale, più realizzo che non riguarda proprio per niente il codice. L’accessibilità digitale ha le sue radici nell’utente e, mentre io (e un’infinità di altre persone) posso sicuramente insegnarvi a scrivere codice accessibile e a costruire i vostri tool, pattern e librerie da usare, realizzo che non posso insegnarvi a essere solidali: è una scelta che dovete fare voi stessi. Quindi, fermatevi un attimo a pensare: cosa sto lasciando alla prossima generazione di developer con tutto questo codice inaccessibile su cui non ho ragionato molto? È questa l’eredità nell’ambito della programmazione che voglio lasciare? Vi sfido a fare di meglio per mia figlia, per i suoi pari e per l’infinità di altre persone che non sono completamente rappresentate nell’odierna community tech.