Come incorporare l'accessibilità nei processi del team.
Rendere un sito più accessibile può essere un'attività scoraggiante. Se ti stai avvicinando all'accessibilità per la prima volta, l'estrema portata dell'argomento può lasciarti chiedere da dove iniziare. Dopotutto, lavorare per soddisfare una vasta gamma di abilità significa dover prendere in considerazione una gamma altrettanto diversificata di problemi.
Ricorda, l'accessibilità è un lavoro di squadra. Ogni persona ha un ruolo da svolgere. Questo articolo delinea i criteri per ciascuna delle principali discipline (project manager, designer UX e sviluppatore) in modo che possano impegnarsi per incorporare le best practice di accessibilità nel proprio processo.
Project manager
Un obiettivo prioritario per qualsiasi project manager è provare a includere il lavoro di accessibilità in ogni punto saliente, assicurandosi che sia una priorità quanto altri argomenti, come il rendimento e l'esperienza utente. Di seguito sono riportati alcuni elementi dell'elenco di controllo da tenere presenti durante la procedura.
- Rendi disponibile al team la formazione sull'accessibilità.
- Identifica i percorsi critici degli utenti nel sito o nell'applicazione.
- Prova a integrare un elenco di controllo per l'accessibilità nel processo del team.
- Se possibile, valuta il sito o l'applicazione con studi sugli utenti.
Formazione sull'accessibilità
Esistono numerose risorse senza costi per imparare l'accessibilità web. Riservare del tempo al tuo team per studiare l'argomento può semplificare l'inclusione dell'accessibilità nelle prime fasi del processo.
Alcune risorse fornite da Google includono:
Accessibilità web di Google: un corso di formazione interattivo di più settimane.
Nozioni di base sull'accessibilità: guide scritte e best practice per l'accessibilità.
Linee guida sui materiali: accessibilità - un insieme di best practice per l'esperienza utente per la progettazione inclusiva.
Identificazione dei percorsi critici degli utenti
Ogni applicazione ha un'azione principale che l'utente deve eseguire. Ad esempio, se stai creando un'app di e-commerce, ogni utente dovrà poter aggiungere un articolo al proprio carrello degli acquisti.
Alcune azioni possono essere di importanza secondaria e forse essere eseguite solo occasionalmente. Ad esempio, cambiare la foto dell'avatar è utile, ma potrebbe non essere importante per tutte le esperienze.
Identificare le azioni primarie e secondarie nella tua applicazione ti aiuterà a dare priorità al lavoro di accessibilità. In seguito, puoi combinare queste azioni con un elenco di controllo per l'accessibilità per tenere traccia dei tuoi progressi ed evitare regressioni.
Includere un elenco di controllo per l'accessibilità
L'argomento dell'accessibilità è piuttosto ampio, quindi avere un elenco di controllo delle aree importanti da prendere in considerazione può essere utile per assicurarsi di coprire tutte le basi.
Sono disponibili numerosi elenchi di controllo per l'accessibilità; alcuni esempi di settore sono:
Elenco di controllo per le WCAG WebAIM Linee guida per l'accessibilità Vox
Con un elenco di controllo, puoi dare un'occhiata alle azioni principali e secondarie per iniziare a individuare le azioni da eseguire. Puoi adottare misure piuttosto tattiche riguardo a questo processo, persino creare una matrice di azioni primarie e secondarie e determinare per ogni passaggio di questi processi, se mancano dei bit di accessibilità.
Valutazione con studi sugli utenti
Non c'è niente di meglio di trovarsi davanti a utenti reali e di osservarli mentre provano a usare la tua app. Se stai aggiornando l'accessibilità in un'esperienza esistente, questo processo può aiutarti a identificare rapidamente le aree da migliorare. E se stai iniziando un nuovo progetto, i primi studi sugli utenti possono aiutarti a evitare di dedicare troppo tempo allo sviluppo di una funzionalità difficile da usare.
L'obiettivo è incorporare il feedback di una popolazione di utenti il più diversificata possibile. Prendi in considerazione gli utenti che navigano principalmente con la tastiera o si affidano a tecnologie per la disabilità come gli screen reader o le lenti di ingrandimento.
progettista UX
Poiché le persone tendono a progettare in base ai propri pregiudizi, se non hai una disabilità e non hai colleghi con disabilità, è possibile che tu stia progettando involontariamente solo per alcuni utenti. Mentre lavori, chiediti "Quali sono tutti i tipi di utenti che potrebbero affidarsi a questo design?" Ecco alcune tecniche che puoi provare per rendere il tuo processo più inclusivo.
- Il contrasto di colore dei contenuti è sufficiente.
- L'ordine delle schede è definito.
- I controlli hanno etichette accessibili.
- Esistono diversi modi per interagire con l'interfaccia utente.
I contenuti hanno un buon contrasto di colore
L'obiettivo principale della maggior parte dei siti è fornire all'utente alcune informazioni tramite testo scritto o immagini. Tuttavia, se il contrasto di questi contenuti è basso, potrebbe essere difficile leggere alcuni utenti, in particolare quelli con problemi di vista. Ciò potrebbe influire negativamente sulla sua esperienza utente. Per risolvere questo problema, cerca di fare in modo che tutti i testi e le immagini abbiano un contrasto di colore sufficiente.
Il contrasto viene misurato confrontando la luminanza di un colore in primo piano e di uno sfondo. Per il testo di dimensioni inferiori a 18 pt o in grassetto di 14 pt, si consiglia un rapporto minimo di 4,5:1. Per testi più grandi, queste proporzioni possono essere regolate su 3:1.
Nell'immagine seguente, il testo sulla sinistra soddisfa i valori minimi di contrasto, mentre il testo sul lato destro ha un contrasto basso.
Esistono diversi strumenti per misurare il contrasto cromatico, come lo strumento Material Color di Google, l'app Contrast Factor di Lea Verou e l'aXe di Deque.
L'ordine delle schede è definito
L'ordine delle schede è l'ordine in cui gli elementi sono attivi quando l'utente preme il tasto Tab. Per gli utenti che navigano principalmente con la tastiera, il tasto Tab è il mezzo principale per raggiungere tutti gli elementi sullo schermo. È come il cursore del mouse.
Idealmente, l'ordine delle schede dovrebbe seguire l'ordine di lettura e scorrere dalla parte superiore della pagina verso il basso, con gli elementi più importanti che compaiono più in alto nell'ordine. In questo modo, chiunque usi una tastiera può raggiungere rapidamente questi elementi in modo più efficiente.
L'interfaccia simulata sopra è numerata per mostrare l'ordine delle schede. Creare una simulazione come questa può essere utile identificando l'ordine delle schede previsto. Questa informazione può essere condivisa con sviluppatori e tester del QA per verificare che sia implementata e verificata correttamente.
I controlli hanno etichette accessibili
Per gli utenti di tecnologie per la disabilità, come gli screen reader, le etichette forniscono informazioni che altrimenti sarebbero solo visive. Ad esempio, un pulsante di ricerca che è solo un'icona di una lente d'ingrandimento può avere un'etichetta accessibile di "Cerca" per compilare l'offerta visiva mancante.
Ecco alcuni semplici suggerimenti da seguire per progettare etichette accessibili:
- Sii breve: ascoltare descrizioni lunghe può essere noioso.
- Cerca di non includere il tipo o lo stato di controllo. Se il controllo è codificato correttamente, uno screen reader lo annuncerà automaticamente.
- Concentrati sui verbi d'azione: utilizza "cerca" anziché "lente d'ingrandimento".
Potresti creare una simulazione con tutti i controlli etichettati. Questa informazione può essere condivisa con il team di sviluppo e il team QA per l'implementazione e i test.
Diversi modi per interagire e comprendere l'interfaccia utente
È facile supporre che tutti gli utenti interagiscano con la pagina principalmente utilizzando il mouse. Durante la progettazione, valuta in che modo si interagirà con un controllo usando una tastiera.
Pianifica gli stati di interesse. Ciò significa che determina l'aspetto di un controllo quando l'utente lo attiva con Tab o preme i tasti freccia. È utile pianificare questi stati in anticipo, anziché cercare di inserirli in un secondo momento.
Infine, per ogni punto di interazione, devi assicurarti che l'utente disponga di più modi per comprendere i contenuti. Cerca di non usare il colore da solo per trasmettere informazioni, perché questi segnali sottili potrebbero non essere sfuggiti a un utente con una carenza di visione dei colori. Un esempio classico è un campo di testo non valido. Invece di una sottolineatura rossa per indicare un problema, valuta la possibilità di aggiungere un testo di supporto. In questo modo, coprirai più basi e aumenti la probabilità che un utente rilevi il problema.
Sviluppatore
Lo sviluppatore ricopre il ruolo di gestione dell'attenzione e semantica per formare un'esperienza utente solida. Di seguito sono riportati alcuni elementi che gli sviluppatori possono tenere a mente mentre lavorano al loro sito o alla loro applicazione:
- L'ordine delle schede è logico.
- Messa a fuoco è gestita e visibile correttamente.
- Gli elementi interattivi supportano la tastiera.
- I ruoli e gli attributi ARIA vengono applicati in base alle esigenze.
- Gli elementi sono etichettati correttamente.
- I test sono automatizzati.
Ordine logico delle schede
Gli elementi nativi come input, button e select vengono attivati senza costi nell'ordine delle schede e possono essere attivati automaticamente con la tastiera. Ma non tutti gli elementi ricevono lo stesso comportamento. In particolare, gli elementi generici come div e span non sono attivati nell'ordine delle schede. Ciò significa che se utilizzi un div per creare un controllo interattivo, dovrai effettuare ulteriori operazioni per renderlo accessibile dalla tastiera.
Le due opzioni sono:
- Assegna un
tabindex="0"al controllo. In questo modo sarà almeno attivabile, ma probabilmente dovrai svolgere ulteriori operazioni per aggiungere il supporto della pressione dei tasti. - Se possibile, valuta la possibilità di utilizzare
buttonanzichédivospanper qualsiasi controllo simile a un pulsante. È molto facile applicare uno stile all'elementobuttonnativo e ricevere supporto della tastiera senza costi.
Gestione obiettivo
Quando modifichi i contenuti della pagina, è importante indirizzare l'attenzione dell'utente spostando lo stato attivo. Un classico esempio di utilità di questa tecnica è l'apertura di una finestra di dialogo modale. Se un utente che utilizza una tastiera preme un pulsante per aprire una finestra di dialogo e lo stato attivo non viene spostato sull'elemento della finestra di dialogo, l'unica cosa che fa è scorrere l'intero sito finché non trova il nuovo controllo. Spostando l'attenzione sui nuovi contenuti non appena vengono visualizzati, puoi migliorare l'efficienza delle esperienze di questi utenti.
Supporto da tastiera per gli elementi interattivi
Se vuoi creare un controllo personalizzato come un carosello o un menu a discesa, dovrai svolgere delle attività aggiuntive per aggiungere il supporto della tastiera. La guida alle esercitazioni per la creazione di ARIA è una risorsa utile che identifica vari pattern dell'interfaccia utente e i tipi di azioni da tastiera che si prevede supportino.
Per scoprire di più sull'aggiunta del supporto della tastiera a un elemento, consulta la sezione Tabindex mobile nei documenti sull'accessibilità di Google.
I ruoli e gli attributi ARIA vengono applicati in base alle esigenze
Non solo i controlli personalizzati richiedono un adeguato supporto della tastiera, ma anche una semantica appropriata. Dopo tutto, div, semanticamente, è solo un container di raggruppamento generico. Se utilizzi div come base per il menu a discesa, dovrai
servirti su
ARIA
per integrare altri elementi semantici in modo che il tipo di controllo possa essere trasmesso alla
tecnologia assistiva. Anche in questo caso, la guida alle pratiche di creazione ARIA può aiutarti a identificare i ruoli, gli stati e le proprietà che dovresti utilizzare.
Come bonus aggiuntivo, molte delle spiegazioni nella guida ARIA includono anche un codice campione.
Etichettatura degli elementi
Per etichettare gli input nativi, puoi utilizzare l'elemento <label> integrato come descritto su MDN. In questo modo, non solo potrai creare un'affinità visiva
sullo schermo, ma assegni anche un nome accessibile all'input nella
struttura dell'accessibilità. Questo nome viene poi scelto dalle tecnologie per la disabilità (come uno screen reader) e annunciato all'utente.
Purtroppo <label> non supporta l'assegnazione di un nome accessibile a controlli
personalizzati (come quelli creati utilizzando Elementi personalizzati
o da elementi div e sezioni semplici). Per questi tipi di controlli, devi utilizzare gli attributi aria-label e aria-labelledby.
Test automatici
Essere pigri può essere positivo, soprattutto quando si tratta di test. Dove possibile, cerca di automatizzare i test di accessibilità in modo da non dover fare tutto manualmente. Attualmente esistono numerosi ottimi strumenti di test del settore che consentono di verificare in modo facile e veloce i problemi di accessibilità più comuni:
aXe, creata dai sistemi Deque, è disponibile come estensione di Chrome e un modulo Node (ideale per ambienti di integrazione continua). Questo breve A11ycast spiega diversi modi per incorporare aXe nel tuo processo di sviluppo.
Lighthouse è un progetto open source di Google per il controllo delle prestazioni delle tue app web progressive. Oltre a verificare se la tua PWA supporta, ad esempio, Service worker e un file manifest delle app web, Lighthouse eseguirà anche una serie di test di best practice, tra cui test per i problemi di accessibilità.
Conclusione
L'accessibilità è un lavoro di squadra. Tutti hanno un ruolo da svolgere. Questa guida illustra alcuni elementi chiave che ogni membro del team può utilizzare per approfondire rapidamente l'argomento e, speriamo, migliorare l'esperienza complessiva dell'app.
Per scoprire di più sull'accessibilità, assicurati di dare un'occhiata al nostro corso senza costi di Udacity e sfoglia i documenti sull'accessibilità disponibili qui su web.dev.