{"id":38463,"date":"2019-10-31T22:23:52","date_gmt":"2019-10-31T19:23:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/po-napravleniyu-k-dostupnosti\/"},"modified":"2019-10-31T22:23:52","modified_gmt":"2019-10-31T19:23:52","slug":"po-napravleniyu-k-dostupnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/po-napravleniyu-k-dostupnosti","title":{"rendered":"Verso l'accessibilit\u00e0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Verso
\n
\nVenerd\u00ec \u2013 la fine della giornata lavorativa. Le cattive notizie arrivano sempre di venerd\u00ec verso la fine della giornata lavorativa.<\/p>\n

Stai per lasciare l'ufficio, \u2018ding\u2019 \u00e8 appena arrivata una nuova e-mail riguardante un'altra riorganizzazione.<\/p>\n

Grazie xxxx, yyy da oggi in poi riferirai a zzzz
\n\u2026
\nE il team di Hugh garantir\u00e0 l'accessibilit\u00e0 dei nostri prodotti per le persone con disabilit\u00e0.<\/i>\n<\/p><\/blockquote>\n

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\u00e0 sicuramente un fallimento\u2026<\/p>\n

Cos\u00ec era l'accessibilit\u00e0 alcuni anni fa. Alcuni poveretti ottenevano lavoro per \u2018ripulire\u2019 l'interfaccia utente per cercare di renderla accessibile alle persone con disabilit\u00e0.
\n<\/a><\/noindex>
\nQuello che significava effettivamente era piuttosto vago \u2013 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\u2026<\/p>\n

Ma all'improvviso i \u2018bug\u2019 hanno cominciato a moltiplicarsi a una velocit\u00e0 impressionante.<\/p>\n

Diversi screen reader (inglese.<\/i> Screen Readers) e browser si comportavano in modo assolutamente diverso.<\/p>\n

Gli utenti si lamentavano che l'applicazione non era utilizzabile.<\/p>\n

Appena un errore veniva corretto in un punto, un altro si presentava in un altro.<\/p>\n

E semplicemente cambiare e correggere gli errori dell'interfaccia utente richiedeva uno sforzo titanico.<\/p>\n

Ci sono stato. Ho sopravvissuto, ma non siamo \u2018riusciti\u2019 \u2013 tecnicamente abbiamo ripulito molto, aggiunto molte descrizioni ai campi, ruoli e raggiunto un certo livello di conformit\u00e0 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 \u2018soluzione\u2019 chiaramente definita che funzionasse in tutti i casi.<\/p>\n

Sul mio cammino verso la comprensione dell'accessibilit\u00e0 ci sono stati alcuni momenti davvero rivelatori.
\nForse, la prima comprensione \u00e8 stata che aggiungere funzionalit\u00e0 di accessibilit\u00e0 a un prodotto gi\u00e0 pronto \u00e8 complicato. E convincere i manager che \u00e8 incredibilmente difficile \u00e8 ancora pi\u00f9 complicato! No, non si tratta solo di \"aggiungere qualche tag\" e l'interfaccia utente funzioner\u00e0 alla grande. No, non \u00e8 possibile completarlo in tre settimane; anche tre mesi non saranno sufficienti.
\nIl mio prossimo momento chiave \u00e8 arrivato quando ho visto di persona come gli utenti non vedenti utilizzano effettivamente la nostra applicazione. \u00c8 cos\u00ec diverso rispetto a vedere i messaggi di errore.<\/p>\n

Torner\u00f2 su questo punto ripetutamente, ma quasi tutte le nostre \u00abipotesi\u00bb su come le persone utilizzassero la nostra applicazione erano sbagliate.<\/p>\n

Navigare in un'interfaccia utente complessa usando i tasti Tab\/Shift+Tab<\/code> \u00e8 terribile! Abbiamo bisogno di qualcosa di meglio. Combinazioni di tasti, intestazioni.<\/p>\n

La perdita di focus durante la modifica dell'interfaccia utente non \u00e8 un grande problema? Ripensiamoci: \u00e8 incredibilmente confuso.<\/p>\n

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\u00e0 giusta questa volta.<\/p>\n

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!<\/p>\n

Abbiamo rapidamente raggiunto alcune conclusioni:<\/p>\n

    \n
  1. 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\u00e0 fosse integrata fin dall'inizio.<\/li>\n
  2. Accessibilit\u00e0 == Usabilit\u00e0 \u2013 ovvero, non \u00e8 solo una questione tecnica. Dovevamo cambiare l'intero processo di progettazione e assicurarci che l'accessibilit\u00e0 fosse presa in considerazione e discussa prima dell'inizio della progettazione dell'interfaccia utente. \u00c8 necessario riflettere fin dall'inizio su come gli utenti possono scoprire qualsiasi funzionalit\u00e0, come si muoveranno e come funzioner\u00e0 il \"clic destro del mouse\" dalla tastiera. L'accessibilit\u00e0 deve essere parte integrante del processo di progettazione: per alcuni utenti \u00e8 qualcosa di molto pi\u00f9 importante dell'aspetto dell'applicazione.<\/li>\n
  3. Sin dall'inizio volevamo ottenere feedback da utenti non vedenti e da altri utenti con disabilit\u00e0 sulla facilit\u00e0 d'uso dell'applicazione.<\/li>\n
  4. Avevamo bisogno di modi veramente efficaci per catturare la regressione dell'accessibilit\u00e0.<\/li>\n<\/ol>\n

    \nBeh, 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 \u00e8 stato.<\/p>\n

    Facendo un passo indietro e guardando gli esempi ARIA<\/a><\/noindex> E pensando a questo come a un problema di design, e non come a 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 seguenti abbiamo un semplice elenco non ordinato. Aggiungendo 'comportamento' all'elenco, vengono aggiunti i ruoli corrispondenti affinch\u00e9 funzioni come un elenco. Facciamo lo stesso per il menu.<\/p>\n

    \"Verso
    \n
    \nIn realt\u00e0, qui si aggiungono non solo i ruoli, ma anche i gestori di eventi per la navigazione tramite tastiera.<\/p>\n

    Questo appare gi\u00e0 pi\u00f9 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\u00e0.<\/p>\n

    In azione, questo pu\u00f2 essere visto all'indirizzo https:\/\/stardust-ui.github.io\/react\/<\/a><\/noindex> \u2013 la libreria UX React<\/a><\/noindex>, progettata e implementata con l'accessibilit\u00e0 fin dall'inizio.<\/p>\n

    La seconda parte \u2013 cambiare l'approccio e i processi attorno al design mi spaventava inizialmente: ingegneri modestamente cercando di spingere cambiamenti organizzativi, ci\u00f2 non finisce sempre bene, ma si \u00e8 rivelata una delle aree pi\u00f9 interessanti in cui abbiamo dato un contributo significativo al processo. In poche parole, il nostro processo era il seguente: una nuova funzionalit\u00e0 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\u00e0 di accessibilit\u00e0, poich\u00e9 doveva risolvere tutti i problemi ad essa correlati.<\/p>\n

    All'inizio \u00e8 stata un'impresa piuttosto difficile spiegare che accessibilit\u00e0 e usabilit\u00e0 sono indissolubilmente legate e che questa considerazione deve essere integrata fin dalle fasi di progettazione; altrimenti, ci\u00f2 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\u00e0 e usabilit\u00e0 prima di essere presentati alla direzione.<\/p>\n

    E questi feedback sono stati estremamente preziosi per tutti \u2013 \u00e8 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.<\/p>\n

    Potremmo fare questo lavoro ancora meglio se a questi (o ai successivi) incontri ci fossero utenti ciechi e utenti con disabilit\u00e0 \u2013 \u00e8 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 \u2013 sia a livello di componente che a livello di flusso di esecuzione.<\/p>\n

    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\u00f2 che trascuravamo costantemente \u2013 come possiamo fermare la regressione. Analogamente, le persone possono utilizzare test di integrazione o end-to-end per verificare la funzionalit\u00e0 di cui abbiamo bisogno per rilevare modifiche nelle interazioni e nei flussi di esecuzione \u2013 sia visivi che comportamentali.<\/p>\n

    La definizione di regressione visiva \u00e8 un compito abbastanza specifico e c'\u00e8 poco da aggiungere a questo processo, se non forse la verifica che il focus sia visibile durante la navigazione tramite tastiera. Sono pi\u00f9 interessanti due tecnologie relativamente nuove per lavorare sull'accessibilit\u00e0.<\/p>\n

      \n
    1. Accessibility Insights<\/a><\/noindex> \u00e8 una serie di strumenti che possono essere eseguiti sia nel browser che all'interno del ciclo di build\/test, per identificare problemi.<\/li>\n
    2. La verifica della correttezza del funzionamento dei lettori di schermo \u00e8 stata particolarmente difficile. Con l'introduzione dell'accesso a Accessibility DOM<\/b>, finalmente abbiamo la possibilit\u00e0 di catturare schermate dell'applicazione dal punto di vista dell'accessibilit\u00e0, molto simili a come le facciamo per i test visivi, e di controllarle per la regressione.<\/li>\n<\/ol>\n

      \nQuindi, nella seconda parte della storia - siamo passati dalla modifica del codice HTML a lavorare a un livello di astrazione pi\u00f9 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\u00e0 e ci\u00f2 che significa lavorare in questo campo.
      \nMa questo \u00e8 solo l'inizio.<\/p>\n

      La prossima \"comprensione\" \u00e8 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\u00f9 semplice e comprensibile. Pu\u00f2 essere letto ad alta voce, la struttura della frase \u00e8 grammaticalmente separata e anche i significati delle parole sono visualizzati graficamente. Questo non si inserisce affatto nella vecchia comprensione di \"renderlo accessibile\" - \u00e8 una funzione di usabilit\u00e0 che aiuta tutti.<\/p>\n

      Con ML\/AI emergono modalit\u00e0 completamente nuove di interazione e lavoro, e siamo entusiasti di far parte dei prossimi passi di questo percorso pionieristico. L'innovazione \u00e8 guidata da un cambiamento di mentalit\u00e0 - l'umanit\u00e0 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>\n

      P.S. L'articolo \u00e8 stato tradotto con alcune deviazioni dall'originale. Essendo coautore di questo articolo, ho concordato queste deviazioni con Hugh.<\/p>\n

      Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

      State presti attenzione all'accessibilit\u00e0 delle vostre applicazioni?<\/h2>\n