Come progettare deliverable accessibili
Strumenti e modalità per un approccio inclusivo
Il legame tra inclusione e accessibilità
Nella discussione legata alla diversità, all’equità e all’inclusione (sintetizzate dall’acronimo DE&I), nei contesti sia sociali sia lavorativi, un tema ancora fortemente trascurato è quello della disabilità.
Il concetto di disabilità è ampio e sfaccettato. Si riferisce a qualsiasi limitazione o perdita (conseguente a una menomazione) – su base duratura – di capacità fisiche, psichiche e/o sensoriali che, a vario titolo, può derivare da una condizione congenita, svilupparsi nel tempo anche in modo progressivo o essere associata a una ferita o trauma. Nell’interagire con barriere di diversa natura, le persone che presentano questa condizione, che peraltro non sempre è visibile, sono ostacolate nello svolgimento delle attività e nella loro piena partecipazione al contesto sociale.
Nel mondo più di un miliardo di persone [1] – circa il 16% della popolazione – vive con una disabilità, ma solo il 4% delle aziende che affermano di dare priorità alla diversità considera effettivamente la disabilità [2] nelle proprie iniziative.
Costruire un ambiente organizzativo inclusivo passa necessariamente anche attraverso l’impegno a garantire alle persone con disabilità la possibilità di vivere appieno la loro esperienza lavorativa, senza alcuna limitazione. Esperienza che è costituita da cultura, ambienti, servizi, strumenti e contenuti.
Oltre che da una motivazione etica, questa assunzione viene consolidata dal Curb Cut Effect [3], il principio per cui la progettazione di un prodotto o un servizio a misura di disabilità può essere apprezzato da una popolazione più estesa che possa trarne beneficio e constatarne una migliore user experience.
Da questa riflessione e in risposta a esigenze concrete incontrate in molteplici progettualità, in OpenKnowledge ci siamo interrogati su come rendere il nostro approccio più inclusivo e abbiamo colto l’occasione per sperimentarci in particolare nella produzione di deliverable accessibili.
Nei prossimi paragrafi vedremo quali approcci e strumenti abbiamo sviluppato per supportare internamente il processo di creazione e realizzazione dei contenuti in ottica accessibile.
L’accessibilità informatica
Quando parliamo di accessibilità intendiamo la caratteristica di un ambiente, un servizio, un dispositivo o una risorsa di essere fruibile da qualsiasi tipologia di utente, in maniera diretta o indiretta grazie alla compatibilità con le tecnologie assistive della persona.
Se diverse e molteplici sono le tipologie di disabilità (visiva, uditiva, fisica, vocale, cognitiva, di linguaggio, di apprendimento e neurologica) e, conseguentemente, di accessibilità, i new ways of working sempre più digitalizzati hanno fortemente acuito l’attenzione da porre all’accessibilità informatica e l’esigenza di ridurre il Web Accessibility Divide, che oggi non consente a persone con disabilità un paritario accesso alle risorse informatiche rispetto al resto dell’utenza.
Da un punto di vista normativo, in Italia solo le amministrazioni pubbliche, gli enti pubblici e le organizzazioni che offrono servizi di pubblica utilità hanno un esplicito obbligo di conformità ai requisiti di accessibilità informatica (Legge Stanca, 01-2004). Tuttavia, il tema è sempre più rilevante per qualsiasi realtà ed è dimostrato dall’esistenza e dalla continua evoluzione delle WCAG, Web Content Accessibility Guidelines [4], le linee guida internazionali per l’accessibilità di siti e contenuti web redatte dal W3C, il World Wide Web Consortium.
Rendere un deliverable accessibile: una checklist di controllo
È proprio dalle linee guida internazionali (la cui versione attualmente più aggiornata è la 2.1, risalente al 2018) che in OpenKnowledge siamo partiti per porre le prime basi di un approccio inclusivo e accessibile da adottare ogniqualvolta ci troviamo a produrre deliverable digitali di vario tipo.
Lo abbiamo fatto muovendoci nel perimetro delimitato dai 4 principi cardine, che determinano l’accessibilità di contenuti web e interfacce utente, ed estendendone l’applicazione a diversi output che, spesso, abbiamo l’esigenza di produrre in molteplici progettualità.
A partire da questi principi, abbiamo costruito una checklist che sintetizza alcuni requisiti fondamentali da rispettare e che ci ha guidato internamente nel rendere materiali come documenti testuali, manuali formativi, presentazioni d’aula, grafiche e video fruibili anche da persone con disabilità e, quindi, accessibili all’interno del contesto organizzativo nel quale di volta in volta stavamo operando.
Questa checklist – che nasce in seno alle linee guida internazionali – è diventata così un primo utile strumento di orientamento e di controllo per aumentare la conformità dei contenuti prodotti agli standard WCAG.
Non è, chiaramente, l’unico: la sua applicazione e il controllo della compatibilità dei contenuti con le tecnologie assistive (come, nel nostro caso, i software di screen reading per la disabilità visiva) si sono rivelati fondamentali benché non esaustivi, inserendosi solo nelle attività di verifica svolte a valle della progettazione dei materiali.
Precisazioni metodologiche e take away
In questa prima sperimentazione, abbiamo acquisito la consapevolezza che l’approccio con cui ci si relaziona ai temi della disabilità e dell’accessibilità è spesso manchevole, anche solamente nell’ambito dell’accessibilità informatica che – peraltro – non dipende solo da contenuti accessibili, ma anche da browser Web e altri programmi utente accessibili (per cui gli strumenti di sviluppo rivestono un ruolo importante).
Questo sia perché gli aspetti tecnici sono molteplici e per nulla banali, sia perché le tipologie di disabilità sono svariate e devono essere considerate con un approccio non generalista: difatti, quando parliamo di disabilità possiamo intendere sia la limitazione – in gradi diversi – della capacità fisica, psichica e/o sensoriale, sia la sua totale perdita.
Quindi, non bisognerebbe tanto chiedersi se si è accessibili oppure no (nella produzione di output digitali ma non solo), bensì quanto sia possibile diventarlo per un numero sempre più ampio di persone con disabilità, consapevoli che costruire un modello esaustivo per tutte le esigenze di tali persone sia sforzo notevole.
Proprio in quest’ottica, diventa fondamentale analizzare approfonditamente le esigenze della popolazione aziendale, per co-progettare soluzioni e deliverable conformi ai diversi livelli e tipologie di accessibilità necessari in quello specifico contesto organizzativo.
In altre parole, solo una metodologia progettuale basata sull’ascolto e un approccio agile di continuous improvement permettono di gestire in modo adattivo un ambito così fluido all’interno di diverse progettualità.
L’accessibilità deve diventare sempre di più un tema culturale, di mindset. Lo scarto vero e proprio sta nel perseguirla by design in tutte le fasi di un progetto: non dovrebbe trattarsi tanto di rendere accessibili ex post ambienti, strumenti, servizi e contenuti, quanto più di progettarli ex ante in modo che siano fruibili da qualsiasi utente. Questo anche quando la rappresentatività delle persone con disabilità è bassa all’interno del target a cui ci rivolgiamo.
Per applicare questo approccio olistico e integrato, volto a garantire libertà espressiva a tutte le persone, indipendentemente dalla presenza di una o più disabilità, il nostro suggerimento è quello di partire da un assessment complessivo dell’accessibilità della propria organizzazione, analizzandola attraverso molteplici lenti e per aree di competenza.
Per approfondimenti in tal senso, consigliamo l’articolo sul framework di autovalutazione dell’accessibilità nelle organizzazioni nel nostro inserto “Parole, Segni, Culture” per Harvard Business Review Italia.
Per esplorare ulteriori strumenti e pratiche inclusive nell’era della collaborazione digitale, segnaliamo anche l’articolo sulle golden rules da adottare nell’interazione con persone sorde, nate da un’altra nostra sperimentazione sul campo.
Autori
Silvia Basilico, Giuseppe Giordano