Il venerdì è la fine della giornata lavorativa. Le cattive notizie arrivano sempre alla fine della giornata lavorativa, il venerdì.
Stai per lasciare l'ufficio, è appena arrivata per posta una nuova lettera su un'altra riorganizzazione.
Grazie xxxx, yyy da oggi segnalerai zzzz
...
E il team di Hugh garantirà che i nostri prodotti siano accessibili alle persone con disabilità.
Oh no! Perché me lo sono meritato? Vogliono che me ne vada? Preparati a un duro lavoro ingrato e al tentativo di correggere gli errori degli altri. Questo è sicuramente un fallimento...
Questa era la disponibilità qualche anno fa. Ad alcune povere anime è stato affidato il compito di "ripulire" l'interfaccia utente per cercare di renderla accessibile alle persone con disabilità.
Ciò che ciò significava in realtà era piuttosto vago: presumibilmente se potessi vedere un indicatore di messa a fuoco e una scheda attraverso i campi, avere del testo alternativo e un paio di descrizioni dei campi, verrebbe considerato che la tua applicazione è accessibile...
Ma all'improvviso gli “insetti” cominciarono a moltiplicarsi alla velocità di una valanga.
Vari lettori di schermo (Ing. Screen Reader) e i browser si comportavano in modo completamente diverso.
Gli utenti si sono lamentati del fatto che l'app è inutilizzabile.
Non appena un errore veniva corretto in un punto, ne appariva un altro in un altro.
E semplicemente cambiare e correggere gli errori dell’interfaccia utente ha richiesto sforzi titanici.
Ero lì. Sono sopravvissuto, ma non "abbiamo avuto successo": tecnicamente abbiamo ripulito molto, aggiunto molte descrizioni di campi, ruoli e raggiunto un certo livello di conformità, ma nessuno era contento. Gli utenti si lamentavano ancora di non poter navigare nell'applicazione. Il manager si lamentava ancora del flusso costante di errori. Gli ingegneri si lamentavano del fatto che il problema era stato posto in modo errato, senza una soluzione “giusta” chiaramente definita che avrebbe funzionato in tutti i casi.
Ci sono stati alcuni momenti decisamente illuminanti durante il mio viaggio verso la comprensione dell’accessibilità.
Forse il primo è stata la consapevolezza che aggiungere funzionalità di accessibilità a un prodotto finito era difficile. Ed è ancora più difficile convincere i manager che è incredibilmente difficile! No, non è solo "aggiungi qualche tag" e l'interfaccia utente funzionerà perfettamente. No, non è possibile realizzarlo in tre settimane; neppure tre mesi basterebbero.
Il momento successivo della verità è arrivato quando ho visto in prima persona come gli utenti non vedenti utilizzavano effettivamente la nostra app. Questo è COSÌ diverso dal guardare i messaggi di errore.
Torneremo su questo argomento ancora e ancora, ma quasi tutte le nostre "ipotesi" su come le persone utilizzavano la nostra app erano sbagliate.
Navigazione in un'interfaccia utente complessa utilizzando la sequenza di tasti Tab/Shift+Tab – questo fa schifo! Abbiamo bisogno di qualcosa di meglio. Scorciatoie da tastiera, intestazioni.
Perdere la concentrazione quando si cambia l'interfaccia utente non è un grosso problema, vero? Ripensiamoci: questo è incredibilmente confuso.
Ho continuato, lavorando su diversi progetti per un po', e poi abbiamo iniziato un nuovo progetto, con un'interfaccia utente complessa e un'installazione chiara, per ottenere finalmente l'accessibilità giusta questa volta.
Quindi, abbiamo fatto un passo indietro e abbiamo esaminato come potevamo implementarlo in modo diverso e avere successo, rendendo il processo meno noioso!
Abbastanza rapidamente siamo arrivati ad alcune conclusioni:
- Non volevamo che chi sviluppava l'interfaccia utente interferisse con le etichette/ruoli dell'aria e, ovviamente, con la struttura HTML dei componenti. Avevamo bisogno di fornire loro i componenti giusti per creare accessibilità fin dal primo utilizzo.
- Accessibilità == Facilità d'uso – ad es. Questa non è solo una sfida tecnica. Avevamo bisogno di modificare l'intero processo di progettazione e garantire che l'accessibilità fosse presa in considerazione e discussa prima che iniziasse la progettazione dell'interfaccia utente. È necessario pensare in anticipo a come gli utenti scopriranno le funzionalità, a come navigheranno e a come funzionerà il clic con il pulsante destro del mouse sulla tastiera. L'accessibilità dovrebbe essere parte integrante del processo di progettazione: per alcuni utenti è molto più del semplice aspetto dell'applicazione.
- Fin dall'inizio, abbiamo voluto ricevere feedback dagli utenti non vedenti e da altri disabili sulla facilità d'uso dell'applicazione.
- Avevamo bisogno di modi davvero efficaci per rilevare le regressioni dell’accessibilità.
Ebbene, da un punto di vista ingegneristico, la prima parte sembrava piuttosto divertente: sviluppare un'architettura e implementare una libreria di componenti. E in effetti fu così.
Fare un passo indietro, guardare e considerandolo un problema di progettazione piuttosto che un problema di "adattamento", abbiamo introdotto alcune astrazioni. Un componente ha una "Struttura" (costituito da elementi HTML) e un "Comportamento" (come interagisce con l'utente). Ad esempio, negli snippet seguenti abbiamo un semplice elenco non ordinato. Aggiungendo "comportamenti" i ruoli corrispondenti vengono aggiunti all'elenco per farlo funzionare come un elenco. Facciamo lo stesso per il menu.
In effetti, qui non vengono aggiunti solo i ruoli, ma anche i gestori di eventi per la navigazione da tastiera.
Questo sembra più pulito. Se potessimo ottenere una separazione netta tra loro, non importerebbe come è stata creata la struttura, potremmo applicarvi i comportamenti e ottenere la giusta accessibilità.
Puoi vederlo in azione su – Libreria UX , che è stato progettato e implementato tenendo presente l'accessibilità fin dall'inizio.
La seconda parte: cambiare l'approccio e i processi attorno alla progettazione inizialmente mi ha spaventato: gli ingegneri di basso livello che cercano di portare avanti il cambiamento organizzativo non sempre finiscono 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: la nuova funzionalità veniva sviluppata da un team, quindi il nostro gruppo dirigente rivedeva/reiterava la proposta e infine, una volta approvata, il progetto veniva generalmente consegnato al team di ingegneri. In questo caso, il team tecnico “possedeva” effettivamente la funzionalità di accessibilità perché era sua responsabilità risolvere eventuali problemi ad essa associati.
All’inizio è stato un lavoro piuttosto difficile spiegare che accessibilità e usabilità sono indissolubilmente legate e che questo doveva essere fatto in fase di progettazione, altrimenti avrebbe portato a grandi cambiamenti e ridefinizioni di alcuni ruoli. Tuttavia, con il supporto del management e degli attori chiave, abbiamo preso l'idea e l'abbiamo messa in pratica in modo che i progetti venissero testati in termini di accessibilità e usabilità prima di essere presentati al management.
E questo feedback è stato estremamente prezioso per tutti: è stato fantastico come esercizio di condivisione/comunicazione delle conoscenze su come gli utenti interagiscono con le applicazioni web, abbiamo identificato numerose aree problematiche dell'interfaccia utente prima che venissero create, i team di sviluppo ora hanno specifiche molto migliori di non aspetti solo visivi, ma anche comportamentali del design. Le vere discussioni sono discussioni divertenti, energiche e appassionate su aspetti tecnici e interazioni.
Potremmo farlo ancora meglio se avessimo utenti non vedenti e disabili a questi (o successivi) incontri: è stato difficile da organizzare, ma ora lavoriamo sia con organizzazioni e aziende locali di non vedenti, che forniscono test esterni per verificare il flusso di esecuzione nelle prime fasi sviluppo, sia a livello di componente che di flusso di esecuzione.
Gli ingegneri ora dispongono di specifiche abbastanza dettagliate, di componenti disponibili che possono utilizzare per l'implementazione e di un modo per convalidare il flusso di esecuzione. Parte di ciò che l’esperienza ci ha insegnato è ciò che ci è sempre mancato: come possiamo fermare la regressione. Allo stesso modo, le persone possono utilizzare test di integrazione o end-to-end per testare la funzionalità, di cui abbiamo bisogno per rilevare i cambiamenti nelle interazioni e nei flussi di esecuzione, sia visivi che comportamentali.
Determinare la regressione visiva è un compito abbastanza definito, c'è molto poco da aggiungere al processo oltre a controllare se il focus è visibile durante la navigazione con la tastiera. Più interessanti sono due tecnologie relativamente nuove per lavorare con l'accessibilità.
- è un insieme di strumenti che possono essere eseguiti sia nel browser che come parte del ciclo di creazione/test per identificare i problemi.
- Verificare che gli screen reader funzionino correttamente è stato un compito particolarmente impegnativo. Con l'introduzione dell'accesso a DOM sull'accessibilità, siamo finalmente in grado di acquisire istantanee di accessibilità dell'app, proprio come facciamo per i test visivi, e testarle per la regressione.
Quindi, nella seconda parte della storia, siamo passati dalla modifica del codice HTML al lavoro a un livello di astrazione più elevato, abbiamo modificato il processo di sviluppo del design e introdotto test approfonditi. Nuovi processi, nuove tecnologie e nuovi livelli di astrazione hanno completamente cambiato il panorama dell’accessibilità e cosa significa lavorare in questo spazio.
Ma questo è solo l'inizio.
La successiva “comprensione” è che gli utenti non vedenti stanno guidando una tecnologia all’avanguardia: sono loro che traggono i maggiori benefici non solo dai cambiamenti che abbiamo descritto in precedenza, ma anche dal fatto che nuovi approcci e idee sono resi possibili dal ML/AI. Ad esempio, la tecnologia Immersive Reader consente agli utenti di presentare il testo in modo più semplice e chiaro. Può essere letto ad alta voce, la struttura della frase è scomposta grammaticalmente e anche i significati delle parole vengono visualizzati graficamente. Questo non rientra affatto nella vecchia mentalità del "renderlo accessibile": è una funzionalità di usabilità che aiuterà tutti.
Il machine learning e l'intelligenza artificiale stanno consentendo modalità completamente nuove di interagire e lavorare e siamo entusiasti di far parte delle prossime fasi di questo viaggio all'avanguardia. L’innovazione è guidata da un cambiamento nel modo di pensare: l’umanità esiste da millenni, le macchine da centinaia di anni, i siti web da diversi decenni e gli smartphone ancor meno, la tecnologia deve adattarsi alle persone e non viceversa.
PS L'articolo è stato tradotto con lievi deviazioni dall'originale. In qualità di coautore di questo articolo, ho concordato queste divagazioni con Hugh.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Presti attenzione all'accessibilità delle tue applicazioni?
-
Sì
-
No
-
Questa è la prima volta che sento parlare di accessibilità delle app.
17 utenti hanno votato. 5 utenti si sono astenuti.
Fonte: habr.com