🥇Verso l'accessibilità

Venerdì – fine della giornata lavorativa. Le brutte notizie arrivano sempre di venerdì, verso la fine della giornata lavorativa.

Stai per lasciare l'ufficio, «ding» un nuovo messaggio riguardo l'ennesima riorganizzazione è appena arrivato nella posta.

Grazie xxxx, yyy d'ora in poi riporterai a zzzz
…
E il team di Hugh garantirà l'accessibilità dei nostri prodotti per le persone con disabilità.

Oh, no! Per cosa ho meritato questo? Vogliono che me ne vada? Preparati a un lavoro ingrato e difficile e a cercare di correggere gli errori degli altri. Sarà sicuramente un fallimento...

Questa era l'accessibilità alcuni anni fa. Alcuni poveretti si occupavano della «pulizia» dell'interfaccia utente per cercare di renderla accessibile alle persone con disabilità.

Ciò che questo significava in realtà era piuttosto vago – probabilmente, se riuscivi a vedere l'indicatore di messa a fuoco e spostarti nei campi con il tasto Tab, avere un testo alternativo e alcune descrizioni per i campi, questo sarebbe stato considerato il tuo applicativo accessibile...

Ma improvvisamente, i «bug» hanno cominciato a proliferare come una valanga.

Dispositivi di lettura dello schermo (eng. Screen Readers) e browser si comportavano in modo assolutamente diverso.

Gli utenti lamentavano che l'applicazione non fosse utilizzabile.

Non appena un errore veniva corretto in un luogo, ne appariva un altro in un altro.

E semplicemente cambiare e correggere gli errori dell'interfaccia utente richiedeva uno sforzo titanico.

Ci sono stato. Sono sopravvissuto, ma non abbiamo ‘avanzato’ – tecnicamente abbiamo pulito molto, aggiunto molte descrizioni ai campi, ruoli e raggiunto un certo livello di conformità ai requisiti, ma nessuno era felice. Gli utenti continuavano a lamentarsi di non riuscire a orientarsi nell'applicazione. Il manager si lamentava comunque del costante flusso di errori. Gli ingegneri si lamentavano dell'impostazione errata del compito, senza una ‘giusta’ soluzione chiaramente definita che funzionasse in tutti i casi.

Nel mio cammino verso la comprensione dell'accessibilità ci sono stati alcuni momenti decisamente rivelatori.
La comprensione che aggiungere funzionalità di accessibilità a un prodotto già esistente è complicato è stata una delle prime realizzazioni. E convincere i manager che sia incredibilmente difficile è ancora più complesso! Non si tratta semplicemente di "aggiungere alcuni tag" e il'interfaccia utente funzionerà alla grande. No, non è possibile completarlo in tre settimane; anche tre mesi non basteranno.
Il mio prossimo momento di verità è arrivato quando ho visto di persona come gli utenti non vedenti usano effettivamente la nostra applicazione. È TOTALMENTE diverso dal guardare i messaggi di errore.

Tornerò su questo tema ancora e ancora, ma quasi tutte le nostre "ipotesi" su come le persone utilizzassero la nostra applicazione erano sbagliate.

Navigare attraverso un'interfaccia utente complessa usando i tasti Tab/Shift+Tab è frustrante! Abbiamo bisogno di qualcosa di meglio. Combinazioni di tasti, intestazioni.

Perdere il focus durante il cambiamento dell'interfaccia utente non è un problema serio? Ripensiamoci – è davvero disorientante.

Ho continuato a lavorare su vari progetti per un po' di tempo, poi abbiamo iniziato un nuovo progetto, con un'interfaccia utente complessa e un'implementazione chiara, per ottenere finalmente un'accessibilità corretta.

Quindi, abbiamo fatto un passo indietro e abbiamo esaminato come possiamo realizzarlo in modo diverso e avere successo, rendendo il processo di lavoro più interessante!

Abbiamo rapidamente tratto alcune conclusioni:

Non volevamo che le persone che sviluppano l'interfaccia utente si occupassero di etichette aria/ruoli e naturalmente della struttura HTML dei componenti. Avevamo bisogno di fornire loro componenti adeguati, in cui l'accessibilità fosse implementata direttamente dalla fabbrica.
L'accessibilità = Usabilità, cioè non è solo una questione tecnica. Dobbiamo modificare l'intero processo di design e assicurarci che l'accessibilità venga considerata e discussa prima di iniziare a progettare l'interfaccia utente. È necessario riflettere fin dall'inizio su come gli utenti possono scoprire qualsiasi funzionalità, su come si muoveranno e su come funzionerà il "tasto destro del mouse" dalla tastiera. L'accessibilità deve essere parte integrante del processo di design; per alcuni utenti, è qualcosa di molto più importante del semplice aspetto visivo dell'applicazione.
Fin dall'inizio, volevamo raccogliere feedback da utenti non vedenti e altri utenti con disabilità sulla facilità d'uso dell'applicazione.
Avevamo bisogno di modi davvero efficaci per rilevare le regressioni nell'accessibilità.

Bene, dal punto di vista ingegneristico, la prima parte sembrava piuttosto interessante: sviluppare l'architettura e implementare la libreria di componenti. Ed effettivamente è stato così.

Facendo un passo indietro, consideriamo esempi ARIA E considerando questo come un problema di design, piuttosto che come un problema di «adattamento», abbiamo introdotto alcune astrazioni. Il componente ha una 'Struttura' (composta da elementi HTML) e un 'Comportamento' (come interagisce con l'utente). Ad esempio, nei frammenti qui sotto abbiamo un semplice elenco non ordinato. Aggiungendo il «comportamento» all'elenco, vengono aggiunte le corrispondenti funzioni affinché si comporti come un elenco. Facciamo in modo simile per il menu.

In realtà, qui vengono aggiunte non solo funzioni, ma anche gestori di eventi per la navigazione tramite tastiera.

Questo appare già più ordinato. Se potessimo ottenere una netta separazione tra di essi, non importerebbe come sia stata creata la struttura, potremmo applicare a essa i comportamenti e ottenere la giusta accessibilità.

In azione, questo può essere visto all'indirizzo https://stardust-ui.github.io/react/ – alla libreria UX React, progettata e implementata tenendo conto dell'accessibilità sin dall'inizio.

La seconda parte – il cambiamento dell'approccio e dei processi attorno al design inizialmente mi spaventava: ingegneri modesti che cercavano di spingere cambiamenti organizzativi non sempre portano a buone conclusioni, ma si è rivelata essere una delle aree più interessanti in cui abbiamo apportato un contributo significativo al processo. In poche parole, avevamo il seguente processo: una nuova funzionalità veniva sviluppata da un team, successivamente il nostro gruppo di leader analizzava / iterava questa proposta e, dopo l'approvazione, di solito il design veniva trasferito al team di ingegneri. In questo caso, il team di ingegneri «possedeva» effettivamente la funzionalità di accessibilità, poiché doveva risolvere tutti i problemi ad essa associati.

All'inizio è stato un lavoro piuttosto difficile: spiegare che accessibilità e usabilità sono indissolubilmente legate e che questo deve essere affrontato già nella fase di progettazione, altrimenti si traducono in grandi cambiamenti e ridefinizioni di alcuni ruoli. Tuttavia, con il supporto della direzione e dei principali attori coinvolti, siamo riusciti a far passare quest'idea, affinché i design fossero sottoposti a verifiche di accessibilità e usabilità prima di essere presentati alla direzione.

E questi feedback sono stati estremamente preziosi per tutti: è stato fantastico, come esercizio di condivisione delle conoscenze / trasferimento di informazioni su come gli utenti interagiscono con le web app, abbiamo identificato numerosi punti critici dell'interfaccia utente prima che venissero costruiti, i team di sviluppo ora hanno specifiche molto migliori, non solo per gli aspetti visivi, ma anche per quelli comportamentali del design. Le discussioni reali sono vivaci, energiche e appassionate, riguardanti aspetti tecnici e interazioni.

Potremmo migliorare ulteriormente questo lavoro se avessimo utenti non vedenti e persone con disabilità a queste (o a future) riunioni. È stato difficile organizzare, ma ora collaboriamo con organizzazioni locali per non vedenti e aziende che offrono test esterni per verificare il flusso di esecuzione nelle fasi iniziali di sviluppo — sia a livello di componente che a livello di flusso di esecuzione.

Ora gli ingegneri dispongono di specifiche piuttosto dettagliate, di componenti accessibili che possono utilizzare per l'implementazione e di un modo per verificare il flusso di esecuzione. In parte, l'esperienza ci ha insegnato cosa continuavamo a trascurare — come possiamo prevenire la regressione. Analogamente, le persone possono utilizzare test di integrazione o di flusso per controllare le funzionalità necessarie a rilevare modifiche nelle interazioni e nei flussi di esecuzione — sia visivi che comportamentali.

La definizione di regressione visiva è un compito piuttosto specifico; si può aggiungere molto poco a questo processo, a parte, forse, verificare se il focus è visibile durante la navigazione tramite tastiera. Due tecnologie relativamente nuove per lavorare sull'accessibilità sono più interessanti.

Accessibility Insights è un insieme di strumenti che possono essere eseguiti sia nel browser che all'interno del ciclo di build/test per identificare problemi.
La verifica del corretto funzionamento dei lettori di schermo è stata un compito particolarmente difficile. Con l'introduzione dell'accesso al Accessibility DOM, finalmente abbiamo la possibilità di fare snapshot dell'applicazione dal punto di vista dell'accessibilità, molto simili a quelli che facciamo per i test visivi, e verificarli per regressioni.

Quindi, nella seconda parte della storia, siamo passati dalla modifica del codice HTML a lavorare a un livello più alto di astrazione, cambiando il processo di progettazione e introducendo test rigorosi. Nuovi processi, nuove tecnologie e nuovi livelli di astrazione hanno completamente cambiato la concezione di accessibilità e ciò che significa lavorare in questo campo.
Ma questo è solo l'inizio.

La seguente "comprensione" è che gli utenti non vedenti promuovono tecnologie all'avanguardia: sono proprio loro a trarre il massimo vantaggio non solo dai cambiamenti che abbiamo descritto in precedenza, ma anche dal fatto che nuovi approcci e idee diventano possibili grazie a ML/AI. Ad esempio, la tecnologia Immersive Reader consente agli utenti di rappresentare il testo in modo più semplice e chiaro. Può essere letto ad alta voce, la struttura della frase è grammaticalmente suddivisa e anche i significati delle parole vengono visualizzati graficamente. Questo non si inserisce affatto nella vecchia comprensione di "rendere accessibile" – si tratta di una funzionalità di usabilità che aiuterà tutti.

Con ML/AI emergono modalità completamente nuove di interazione e lavoro, e siamo entusiasti di far parte delle prossime fasi di questo percorso all'avanguardia. L'innovazione è guidata da un cambiamento di paradigma: l'umanità esiste da millenni, le macchine da secoli, i siti web da decenni e gli smartphone da ancora meno; la tecnologia deve adattarsi alle persone, e non il contrario.

P.S. L'articolo è stato tradotto con alcune deviazioni dall'originale. In quanto coautore di questo articolo, ho concordato queste deviazioni con Hugh.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.