Venerdì – la fine della giornata lavorativa. Le cattive notizie arrivano sempre di venerdì verso la fine della giornata lavorativa.
Stai per lasciare l'ufficio, ‘ding’ è appena arrivata una nuova e-mail riguardante un'altra riorganizzazione.
Grazie xxxx, yyy da oggi in poi riferirai 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 cerca di correggere gli errori degli altri. Sarà sicuramente un fallimento…
Così era l'accessibilità alcuni anni fa. Alcuni poveretti ottenevano lavoro per ‘ripulire’ l'interfaccia utente per cercare di renderla accessibile alle persone con disabilità.
Quello che significava effettivamente era piuttosto vago – probabilmente, se potevi vedere l'indicatore di messa a fuoco e navigare nei campi con il tasto Tab, avere qualche testo alternativo e un paio di descrizioni per i campi, veniva considerato che la tua applicazione fosse accessibile…
Ma all'improvviso i ‘bug’ hanno cominciato a moltiplicarsi a una velocità impressionante.
Diversi screen reader (inglese. Screen Readers) e browser si comportavano in modo assolutamente diverso.
Gli utenti si lamentavano che l'applicazione non era utilizzabile.
Appena un errore veniva corretto in un punto, un altro si presentava in un altro.
E semplicemente cambiare e correggere gli errori dell'interfaccia utente richiedeva uno sforzo titanico.
Ci sono stato. Ho sopravvissuto, ma non siamo ‘riusciti’ – tecnicamente abbiamo ripulito 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 per il flusso costante di errori. Gli ingegneri si lamentavano di una scorretta definizione del compito, senza una ‘soluzione’ chiaramente definita che funzionasse in tutti i casi.
Sul mio cammino verso la comprensione dell'accessibilità ci sono stati alcuni momenti davvero rivelatori.
Forse, la prima comprensione è stata che aggiungere funzionalità di accessibilità a un prodotto già pronto è complicato. E convincere i manager che è incredibilmente difficile è ancora più complicato! No, non si tratta solo di "aggiungere qualche tag" e l'interfaccia utente funzionerà alla grande. No, non è possibile completarlo in tre settimane; anche tre mesi non saranno sufficienti.
Il mio prossimo momento chiave è arrivato quando ho visto di persona come gli utenti non vedenti utilizzano effettivamente la nostra applicazione. È così diverso rispetto a vedere i messaggi di errore.
Tornerò su questo punto ripetutamente, ma quasi tutte le nostre «ipotesi» su come le persone utilizzassero la nostra applicazione erano sbagliate.
Navigare in un'interfaccia utente complessa usando i tasti Tab/Shift+Tab è terribile! Abbiamo bisogno di qualcosa di meglio. Combinazioni di tasti, intestazioni.
La perdita di focus durante la modifica dell'interfaccia utente non è un grande problema? Ripensiamoci: è incredibilmente confuso.
Ho continuato, lavorando su vari progetti, e poi abbiamo avviato un nuovo progetto con un'interfaccia utente complessa e l'impegno chiaro di ottenere finalmente l'accessibilità giusta questa volta.
Quindi, abbiamo fatto un passo indietro e abbiamo visto come potevamo realizzare questo in modo diverso e avere successo, e fare in modo che il processo stesso fosse divertente!
Abbiamo rapidamente raggiunto alcune conclusioni:
- Non volevamo che coloro che sviluppano l'interfaccia utente si occupassero di annotazioni/ruoli aria e, naturalmente, della struttura HTML dei componenti. Dovevamo fornire loro componenti adeguati, in cui l'accessibilità fosse integrata fin dall'inizio.
- Accessibilità == Usabilità – ovvero, non è solo una questione tecnica. Dovevamo cambiare l'intero processo di progettazione e assicurarci che l'accessibilità fosse presa in considerazione e discussa prima dell'inizio della progettazione dell'interfaccia utente. È necessario riflettere fin dall'inizio su come gli utenti possono scoprire qualsiasi funzionalità, come si muoveranno e come funzionerà il "clic destro del mouse" dalla tastiera. L'accessibilità deve essere parte integrante del processo di progettazione: per alcuni utenti è qualcosa di molto più importante dell'aspetto dell'applicazione.
- Sin dall'inizio volevamo ottenere feedback da utenti non vedenti e da altri utenti con disabilità sulla facilità d'uso dell'applicazione.
- Avevamo bisogno di modi veramente efficaci per catturare la regressione dell'accessibilità.
Beh, da un punto di vista ingegneristico, la prima parte suonava piuttosto divertente: sviluppare l'architettura e implementare la libreria di componenti. E in effetti lo è stato.
Facendo un passo indietro e guardando e pensando a questo come a un problema di design e non a un problema di 'adattamento', abbiamo introdotto alcune astrazioni. Un 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. Quando si aggiunge 'comportamento' all'elenco, si aggiungono i ruoli pertinenti in modo che funzioni come un elenco. Facciamo di conseguenza per il menu.
In realtà, qui si aggiungono non solo i ruoli, ma anche i gestori di eventi per la navigazione tramite tastiera.
Questo appare già più ordinato. Se riuscissimo a ottenere una netta separazione tra di essi, non importerebbe come fosse stata creata la struttura, potremmo applicare comportamenti ad essa e ottenere una corretta accessibilità.
In azione, questo può essere visto all'indirizzo – la libreria UX , progettata e implementata con l'accessibilità fin dall'inizio.
La seconda parte – cambiare l'approccio e i processi attorno al design mi spaventava inizialmente: ingegneri modestamente cercando di spingere cambiamenti organizzativi, ciò non finisce sempre bene, ma si è rivelata una delle aree più interessanti in cui abbiamo dato un contributo significativo al processo. In poche parole, il nostro processo era il seguente: una nuova funzionalità veniva sviluppata da un team, poi il nostro gruppo di leadership analizzava/iterava questa proposta e, dopo l'approvazione, generalmente il design veniva passato 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 correlati.
All'inizio è stata un'impresa piuttosto difficile spiegare che accessibilità e usabilità sono indissolubilmente legate e che questa considerazione deve essere integrata fin dalle fasi di progettazione; altrimenti, ciò porta a notevoli modifiche e ridefinizioni di alcuni ruoli. Tuttavia, con il supporto della direzione e dei principali collaboratori, siamo riusciti a trasmettere questa idea e a metterla in pratica, facendo in modo che i design venissero controllati per accessibilità e usabilità prima di essere presentati alla direzione.
E questi feedback sono stati estremamente preziosi per tutti – è stato straordinario, come esercizio di condivisione delle conoscenze / trasferimento di informazioni su come gli utenti interagiscono con le applicazioni web. Abbiamo identificato numerosi problemi dell'interfaccia utente prima che venissero costruiti, le squadre di sviluppo hanno ora specifiche molto migliori non solo per gli aspetti visivi, ma anche per quelli comportamentali del design. Le discussioni reali sono dibattiti vivaci, energici e appassionati sugli aspetti tecnici e le interazioni.
Potremmo fare questo lavoro ancora meglio se a questi (o ai successivi) incontri ci fossero utenti ciechi e utenti con disabilità – è stato complesso organizzarlo, ma ora collaboriamo davvero sia con le organizzazioni locali di ciechi sia con aziende che forniscono test esterni per verificare il flusso di esecuzione nelle prime fasi di sviluppo – sia a livello di componente che a livello di flusso di esecuzione.
Ora gli ingegneri hanno specifiche piuttosto dettagliate, componenti accessibili che possono utilizzare per l'implementazione e un metodo per verificare il flusso di esecuzione. In parte, l'esperienza ci ha insegnato ciò che trascuravamo costantemente – come possiamo fermare la regressione. Analogamente, le persone possono utilizzare test di integrazione o end-to-end per verificare la funzionalità di cui abbiamo bisogno per rilevare modifiche nelle interazioni e nei flussi di esecuzione – sia visivi che comportamentali.
La definizione di regressione visiva è un compito abbastanza specifico e c'è poco da aggiungere a questo processo, se non forse la verifica che il focus sia visibile durante la navigazione tramite tastiera. Sono più interessanti due tecnologie relativamente nuove per lavorare sull'accessibilità.
- è una serie di strumenti che possono essere eseguiti sia nel browser che all'interno del ciclo di build/test, per identificare problemi.
- La verifica della correttezza del funzionamento dei lettori di schermo è stata particolarmente difficile. Con l'introduzione dell'accesso a Accessibility DOM, finalmente abbiamo la possibilità di catturare schermate dell'applicazione dal punto di vista dell'accessibilità, molto simili a come le facciamo per i test visivi, e di controllarle per la regressione.
Quindi, nella seconda parte della storia - siamo passati dalla modifica del codice HTML a lavorare a un livello di astrazione più elevato, cambiando il processo di sviluppo del design e introducendo test accurati. Nuovi processi, nuove tecnologie e nuovi livelli di astrazione hanno completamente cambiato la concezione dell'accessibilità e ciò che significa lavorare in questo campo.
Ma questo è solo l'inizio.
La prossima "comprensione" è che gli utenti non vedenti spingono per tecnologie avanzate - sono 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 permette agli utenti di visualizzare il testo in modo più semplice e comprensibile. Può essere letto ad alta voce, la struttura della frase è grammaticalmente separata e anche i significati delle parole sono visualizzati graficamente. Questo non si inserisce affatto nella vecchia comprensione di "renderlo accessibile" - è una funzione di usabilità che aiuta tutti.
Con ML/AI emergono modalità completamente nuove di interazione e lavoro, e siamo entusiasti di far parte dei prossimi passi di questo percorso pionieristico. L'innovazione è guidata da un cambiamento di mentalità - l'umanità esiste da millenni, le macchine da centinaia di anni, i siti web da qualche decina di anni e gli smartphone da ancora meno, la tecnologia deve adattarsi alle persone e non viceversa.
P.S. L'articolo è stato tradotto con alcune deviazioni dall'originale. Essendo coautore di questo articolo, ho concordato queste deviazioni con Hugh.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
State presti attenzione all'accessibilità delle vostre applicazioni?
Sì
No
È la prima volta che sento parlare di accessibilità delle applicazioni.
Hanno votato 17 utenti. 5 utenti si sono astenuti.
Fonte: habr.com
