Reinquadrare l’accessibilità per il Web

E comunque, chi sarebbero queste “persone con disabilità”?#section1

Parliamo di stereotipi e pregiudizi.

Per prima cosa, dobbiamo riconosce che la maggior parte di noi ha un pregiudizio di punto cieco: anche se pensiamo di non avere stereotipi sulle “persone con disabilità”, c’è una buona probabilità che li abbiamo ma non ce ne rendiamo conto. (Se non li avete, buon per voi! Continuate a giocare con noi però).

Per definizione, uno stereotipo è “un’immagine o un’idea largamente diffusa ma fissa ed eccessivamente semplificata di un particolare tipo di persone o cose”. Sono comuni gli stereotipi negativi delle persone con disabilità e sono un sintomo di abilismo: la convinzione che le persone con un corpo abile siano la norma e le persone con disabilità dovrebbero o cercare di “essere normali” o di tenersi a distanza.

Un blogger che si fa chiamare “Bookwormblues” descrive questo fenomeno nel saggio “I am not broken: the language of disability” [Non sono rotto: il linguaggio della disabilità, ndr].

Sembra che viviamo in un mondo in cui le persone con un corpo abile tra noi siano considerate normali e tutti gli altri devono lottare per arrivare a quel livello. Questo pensiero inonda i libri che leggiamo, il modo in cui vediamo gli altri, il modo in cui parliamo tra noi e le parole che usiamo. Questa forma mentale crea uno sbarramento ridicolo per le persone che, per qualunque motivo, potrebbero richiedere un modo atipico per andare dal punto A al punto B. Il problema dell’abilismo è che è ovunque ed è così incredibilmente comune che non ce ne rendiamo nemmeno conto.

Diamo uno sguardo al linguaggio che usiamo per descrivere le persone che hanno bisogno di siti web accessibili.

Un numero di siti web influenti, inclusi WebAIM e Wikipedia, cominciano le loro discussioni sulle questioni di accessibilità con una lista categorizzata di disabilità per cui dobbiamo sviluppare: visiva, uditiva, fisica, di linguaggio, cognitiva e neurologica. Di sicuro, se non avete alcuna esperienza di quello che significa accessibilità e chi ne è affetto, questo è un buon punto di partenza. Tuttavia, dobbiamo riconoscere che cominciamo le nostre conversazioni di accessibilità classificando i modi in cui “loro” non siamo “noi”.

Quando abbiamo una visione deviata dal pregiudizio di un gruppo di cui non facciamo parte, tendiamo a vedere “loro” come più simili dei gruppi di cui facciamo parte. In altre parole, vediamo i gruppi a cui “noi” apparteniamo come pieni di individui diversi, ma “loro” sono tutti simili. Questa si chiama omogeneità del gruppo esterno.

Abbiamo semplificato il gruppo esterno delle “persone con disabilità” in termini di circostanze a lungo termine, gravi e che alterano la vita. Tendiamo a pensare a queste come aventi ovvi segnali esterni: il bastone bianco e gli occhiali del cieco, la sedia a rotelle per chi ha disabilità motorie, la capacità di parlare alterata ed enormi aiuti per l’ascolto per i sordi. I membri della famiglia di chi soffre per un lungo periodo stanno loro intorno, prendendosene cura. L’ispirazione “di super-uomo” di una persona di successo con una disabilità.

Anche questo è sbagliato.

Riesco a pensare ad almeno 26 modi per definire un bisogno di accessibilità, molti dei quali sono invisibili, temporanei o al di là del solito radar degli scenari di accessibilità.

WebAIM discute un fenomeno nel quale viene chiesto a grandi gruppi di persone se qualcuno di loro ha disabilità visive. Pochissimi membri del gruppo rispondono di averle, anche se un numero considerevole di loro indossa occhiali o lenti a contatto. Indipendentemente dal fatto che loro (e io) indossiamo tecnologie assistive per vedere, non ci vediamo come “persone con una disabilità”.

Potrebbe essere più efficace vedere i vari livelli di abilità come uno spettro piuttosto che come un’ambientazione. Ci sono persone che identificheranno sempre sé stesse come aventi una disabilità. Ci sono altre persone che non si vedranno mai come disabili, nonostante abbiano bisogno di tecnologie assistive come gli occhiali, un bastone o una track ball. Nel mezzo, c’è un’infinita combinazione di bisogni, alcuni dei quali durano solo alcuni momenti e altri che durano per tutta la vita di una persona.

Se scegliessimo di considerare tutti come “una persona nello spettro dell’abilità” invece che separare gli “abili” dai “disabili”, la smetteremmo di trattare le persone con diverse abilità come membri di un gruppo esterno e possiamo cominciare a trattarli come parte del nostro variegato gruppo.

Nota: se chiedete a un gran numero di persone con diversi tipi di disabilità come vogliono essere chiamati, vi verrà data una gran varietà di risposte. Alcuni preferiscono “persone con disabilità”, altri preferiscono “disabili”, altri preferiscono che si nomini la propria situazione specifica, alcuni preferirebbero che non venisse affatto menzionata. Per questo articolo, ho scelto “persone con disabilità” perché è il modo in cui i miei amici indicano loro stessi. Come sempre, dovreste chiedere a una persona cosa preferisce e rispettarla usando il termine che vi indica.

Perché siamo fissati col giustificare l’esistenza di persone con disabilità?#section2

Ditemi se avete già sentito questa storia. Sta per partire un grande cambiamento nel design di un sito web e qualcuno del vostro team ha appena scoperto un bug che causerà dei problemi di accessibilità. Una delle persone che prendono le decisioni, quella che ha la responsabilità del budget, chiede: “Quanto è importante? Voglio dire, quante persone non vedenti usano il nostro sito?”

Ho sentito troppe persone di solito molto ragionevoli giustificare la mancanza di spesa per riparare un problema di accessibilità perché non c’è un numero di “disabili” sufficienti da giustificarlo. Stranamente, queste stesse persone non hanno problemi nello spendere soldi per gli “expert users” o per rendere le proprie applicazioni “feature-rich”, fintanto che lo si fa per i “clienti principali” – non realizzando che un sottoinsieme di questi clienti principali sono persone con disabilità. Per quanto ci faccia sentire a disagio ammetterlo, quando prendiamo la decisione di non supportare le persone con disabilità solo perché è costoso o difficile, siamo abilisti.

I nostri clienti, i nostri utenti, sono tutte persone. Hanno tutti gli stessi bisogni come clienti, indipendentemente da quali siano questi bisogni come clienti. Hanno tutti soldi da spendere allo stesso modo. Sono tutti proprio come voi, tranne quando non lo sono. Meritano tutti il nostro rispetto. L’unica differenza tra questi gruppi di persone è l’attitudine che abbiamo nel servirli.

Francamente, non sono affari nostri perché qualcuno vuole che il vostro sito funzioni senza una tastiera o con un mouse o uno screen reader o con un display Braille. Quando entrate nel vostro negozio di alimentari, nessuno vi saluta alla porta e vi dice che il negozio non funziona per voi perché indossate gli occhiali. Né voi né il vostro business dovreste aspettarvi che il vostro pubblico vi dica volontariamente quale tecnologia assistiva usano o perché o qualunque aspetto della loro storia medica, così che voi possiate vendergli calze, un fondo di investimento a tasso variabile o una casa.

Quindi, creiamo siti accessibili e parliamo di accessibilità, ma facciamolo in termini di insiemi di feature e di tecnologia, non di quantità (o valore) di un insieme di utenti rispetto all’altro. Insegniamo ai nostri contatti di business e ai nostri manager e ai nostri tech lead e ai nostri Scrum master che stiamo creando del software per tutti i nostri utenti e non gli daremo più un’esperienza disgustosa perché hanno una disabilità così come non lo faremmo per la loro razza, credo o genere.

Re-inquadrare l’accessibilità come una sfida tecnologica#section3

Non possiamo permettere che gli stereotipi e i pregiudizi alterino il valore percepito del nostro pubblico. Smettiamola di quantificare le persone e cominciamo invece a quantificare le esperienze. Giustifichiamo l’accessibilità mettendo l’enfasi sulle tecnologie invece che sugli utenti.

Cominciamo con l’espandere la nostra visione di cosa può connettersi al web. Cominciamo con l’hardware, l’interfaccia tra le persone e i bit. Cosa potrebbero usare le persone? Che combinazioni potrebbero verificarsi? Questa ricerca è tanto semplice quanto creare un foglio di calcolo.

Creare una matrice di test per l’accessibilità#section4

Ecco come creare metodicamente una matrice di test che definisca una strategia di accessibilità combinando gli scenari di accessibilità con altri tipi di test. Il risultato è che non avrete più bisogno di giustificare i vostri problemi di test di accessibilità basandovi sulla dimensione relativa o sui meriti del pubblico proprio come non dovete giustificare i test su diverse dimensioni di schermo o diversi browser. Questa matrice rende i test di accessibilità un fattore in più nei test che fate normalmente.

1. Leggete questa lista di input devices per computers.
2. Leggete questa lista di output devices for computers.
3. Create una matrice di questi device nel vostro formato spreadsheet preferito. (Se scrivete normalmente i vostri test case come elenco o in qualche altro formato invece che in una matrice, va bene anche quello! Creare la matrice e poi trasferirne i risultati nel vostro altro formato probabilmente renderà più semplice la transizione).



4. Determinate cautamente la probabilità che esista una certa combinazione.

   • Non ho mai sentito di una tecnica per navigare il web il cui input sia costituito da un metro laser e l’output sia costituito da una stampante plotter, quindi possiamo rimuoverlo (almeno finché qualcuno non se lo inventa leggendo questo articolo).
   • Potreste essere tentati di eliminare il Wii Remote e la TV, ma per farlo dovreste ignorare il crescente uso di console come device web.
   • Avevo pensato che l’input con il mouse e l’output con lo screen reader non avessero senso insieme e non dovessero trovarsi nella matrice di test, ma poi ho scoperto Find the Invisible Cow.
   • Ricordatevi che questa non è una lista di quello che usano oggi i vostri utenti: è una lista di ciò che esiste. Se il vostro attuale sito web è così inaccessibile che gli screen reader non funzionano, beh, ovviamente i vostri dati vi mostreranno che non avete utenti che utilizzano uno screen reader. Li avete cacciati!
5. Cercate opportunità per combinare altri elementi dei vostri test cases, come sistemi operativi diversi, browser o risoluzioni di schermo. È importante coprire quanti più scenari possibili con pochi test case.
6. Una volta che avete impostato la matrice, mantenetela come un template e createne una nuova copia ogni volta che fate dei test su un sito web.
7. Per ciascuna applicazione sul vostro sito, identificate se funziona, se non funziona o se non si applica, annotando i risultati nello spreadsheet.

Per esempio, se stessi leggendo un articolo su un sito di notizie, con un video di accompagnamento, potrei vedere i risultati del test così:

Applicare la matrice alle personas#section5

Questo metodo può facilmente essere integrato nelle personas o nelle Agility Use Stories assicurandoci che almeno uno tra tutti i blocchi risulti nella descrizione di almeno una delle vostre personas.

Per esempio, ecco una persona per un supervisore di processo in una fittizia azienda farmaceutica:

Harold è un membro di Processing Manager che ha lavorato con PharmaCo per sedici anni. Ha cominciato come Processing Associate e si è fatto strada, per cui conosce bene quanto loro i ruoli e le responsabilità dei membri del suo team. La principale responsabilità di Harold consiste nell’essere sicuro che i membri del suo team svuotino le code di posta il più rapidamente possibile. La sua responsabilità secondaria consiste nell’aiutare il suo team a plasmare la propria carriera e a salire di rango, proprio come ha fatto lui. È anche responsabile per due progetti all’interno del dipartimento ed è un membro del Diversity Committee.

Harold passa la gran parte del suo tempo nelle riunioni. I componenti del suo team lo raggiungono via email o chat se ha bisogno di qualcosa. Una settimana ogni quattro deve gestire le cose rigettate dal QA e discuterne con i membri del team toccati dalla cosa. Questi gli arrivano attraverso WebApp3, ma deve usare WebApp2 per contattare il membro del team interessato. Dal momento che Harold è “on-the- go”, usa un tablet con un touchscreen come suo computer primario.

Harold ha cominciato a perdere la vista sei anni fa, ma non è completamente cieco. Il testo sullo schermo del suo tablet è completamente zoomato, ma è soggetto a mal di testa se cerca di leggere per troppo tempo. Harold usa lo screen reader del tablet per farsi leggere le email o i messaggi lunghi. Porta con sé degli auricolari così da non disturbare gli impiegati che lavorano vicino a lui.

Il punto qui è che le personas non sono delle personas extra definite “persone disabili”: sono personas di persone con scenari reali e bisogni reali che contemporaneamente usano delle feature di accessibilità che inseriamo nei nostri siti. Dal momento che ogni persona ha un aggancio nella matrice di test, la tentazione di tagliare Harold dal budget è molto più difficile da prendere: tagliare Harold significa tagliare i test per WebApp3 a WebApp2, tagliare i test per le dimensioni di schermo del tablet e tagliare i test per uno screen reader.

Controllare il contenuto rispetto alla matrice#section6

Infine, questo metodo fornisce controlli e oggettività rispetto alla content strategy. Contemporaneamente, spinge i vostri autori verso del “contenuto conciso, appropriato, utile” e fornisce delle opportunità in più per rivedere il contenuto in più formati. Lo fa assicurandosi che vediate il vostro contenuto in diversi contesti, diversi layout, diversi formati, diversi metodi di consegna. Vediamo il nostro contenuto sotto una luce diversa attraverso ciascuno di questi. Queste revisioni ci offrono l’opportunità di identificare i problemi che una singola revisione in una singola location non rivelerebbe.

Se il contenuto non ha senso quando viene ascoltato, allora probabilmente non sarà chiaro quando lo si leggerà. Se il contenuto non ha senso senza le immagini, allora potrebbe essere necessario riscriverlo o rielaborarlo.

Testare oltre l’ovvio#section7

Scoprirete rapidamente (come ho fatto io) che creare siti web accessibili è più difficile che crearne di non accessibili. L’HTML semantico, le pagine bene progettate e standard-compliant, un’architettura dell’informazione solida, una voce chiara per il contenuto, una buona suite di test e una comprensione meticolosa dei problemi di accessibilità sono tutti requisiti per rendere accessibili i siti web. Speriamo che questi siano tutti obiettivi per cui vi state già battendo e che migliorare l’accessibilità del vostro sito sia solo una ragione in più per perseguirli.

Utilizzare una matrice di test e personas che includa problemi di accessibilità vi aiuterà anche a prevenire la “visuale limitata” che a volte si sviluppa se state osservando solo le questioni di accessibilità più ovvie. Una volta, ho lavorato con un team per creare dei video formativi sulle spese e sapevamo che i video richiedevano la trascrizione per essere accessibili. Abbiamo creato la trascrizione, l’abbiamo inserita nell’architettura del sito e vi abbiamo perfino aggiunto i diagrammi e i grafici presi dal video così che fosse facile comprendere. Poi, più in là nel progetto, un collega daltonico segnalò che non riusciva a distinguere i colori nei grafici. Avevamo gestito le questioni più ovvie ed eravamo riusciti a produrre un design inaccessibile. Eravamo caduti nella trappola del pensiero che “solo i sordi” avrebbero avuto problemi con un video.

Persone invece di processi, a meno che i processi non giovino alle persone#section8

L’accessibilità non riguarda la definizione del vostro pubblico e la realizzazione rispettando i loro bisogni. L’accessibilità è un tratto del sito web stesso. Il sito web è usabile su questo hardware e software o non lo è e, come vi ho mostrato, si tratta di qualcosa che potete creare oggi stesso nel processo di testing. Se il vostro pubblico non riesce ad accedere all’informazione di cui ha bisogno sulla maggior parte delle combinazioni di input e output, allora non state venendo incontro ai loro bisogni.

È importante incentrare le nostre discussioni di accessibilità sull’hardware e sul software invece che sul pubblico che usa quell’hardware e quel software. Il nostro processo attuale per la definizione dei bisogni del nostro pubblico basato sulle limitazioni fisiche degrada troppo rapidamente nel processo di creazione di stereotipi, catalogando i membri del nostro pubblico e poi decidendo quali bisogni soddisfare basandoci sul costo del task.

Nessuna persona dovrebbe essere trattata come se il suo valore per il vostro business fosse basato sulle spese di creazione di software che usa metodi di input e output a cui non avevate mai pensato prima. Nessuno dovrebbe giustificare il motivo per cui sta usando un hardware o un software che gli permette di avere successo.

Le persone sono persone. Hanno molte condizioni, forme e abilità. Le interfacce dei computer sono hardware in ingresso e in uscita. Aiutano le persone a comunicare con il software. I siti web sono software che aiuta le persone a raggiungere i propri obiettivi, indipendentemente dalla combinazione di hardware e software, indipendentemente dalla condizione e dalla forma delle loro persone. Questa è l’accessibilità.

Illustrazioni: {carlok}