Accessibilità per i team

Come incorporare l'accessibilità nel processo del tuo team.

Rendere un sito più accessibile può essere un'impresa ardua. Se ti stai approcciando per la prima volta all'accessibilità, la vastità dell'argomento può farti chiederti da dove iniziare. Dopotutto, lavorare per soddisfare una vasta gamma di abilità significa che esistono una serie di problemi da considerare.

Ricorda che l'accessibilità è un lavoro di squadra. Ogni persona ha un ruolo da svolgere. Questo articolo illustra i criteri per ciascuna delle principali discipline (project manager, UX designer e sviluppatore) in modo che possano lavorare per incorporare le best practice per l'accessibilità nella loro procedura.

Project manager

Un obiettivo prioritario per qualsiasi project manager è cercare di includere i lavori di accessibilità in ogni traguardo, assicurandosi che abbiano la stessa priorità di altri argomenti come il rendimento e l'esperienza utente. Di seguito sono riportati alcuni elementi della lista di controllo da tenere presenti durante la procedura.

  • Rendi disponibile la formazione sull'accessibilità per il team.
  • Identifica i Critical User Journey nel sito o nell'applicazione.
  • Prova a integrare un elenco di controllo per l'accessibilità nella procedura di gruppo.
  • Se possibile, valuta il sito o l'applicazione con studi sugli utenti.

Formazione sull'accessibilità

Esistono diverse ottime risorse senza costi per saperne di più sull'accessibilità web. Se il tuo team ha tempo di studiare l'argomento, può essere più facile includere l'accessibilità all'inizio del processo.

Alcune risorse fornite da Google includono:

Accessibilità web di Google: un corso di formazione interattivo di più settimane.

Concetti fondamentali sull'accessibilità: guide e best practice sull'accessibilità.

Linee guida di Material: accessibilità: un insieme di best practice UX per un design inclusivo.

Identificazione dei Critical User Journey

Ogni applicazione ha un'azione principale che l'utente deve eseguire. Ad esempio, se stai creando un'app di e-commerce, ogni utente dovrà essere in grado di aggiungere un articolo al carrello degli acquisti.

Percorso utente principale: un utente può aggiungere un articolo al carrello degli acquisti.

Alcune azioni potrebbero essere di importanza secondaria e forse eseguite solo occasionalmente. Ad esempio, la modifica della foto dell'avatar è una funzionalità interessante, ma potrebbe non essere fondamentale per ogni esperienza.

Identificare le azioni principali e secondarie nella tua applicazione ti aiuterà a dare la priorità al lavoro di accessibilità che ti aspetta. In un secondo momento, puoi combinare queste azioni con un elenco di controllo per l'accessibilità per tenere traccia dei tuoi progressi ed evitare regressioni.

Integrazione di un elenco di controllo per l'accessibilità

L'argomento dell'accessibilità è piuttosto ampio, quindi avere un elenco di controllo delle aree importanti da considerare può aiutarti ad assicurarti di non tralasciare nulla.

Esistono diversi elenchi di controllo per l'accessibilità. Ecco alcuni esempi del settore:

Elenco di controllo WCAG di WebAIM Linee guida per l'accessibilità di Vox

Con un elenco di controllo a portata di mano, puoi esaminare le azioni principali e secondarie per iniziare a valutare il lavoro che deve ancora essere svolto. Puoi adottare un approccio molto tattico a questa procedura e persino creare una matrice di azioni principali e secondarie e determinare per ogni passaggio di queste procedure se mancano elementi di accessibilità.

Una tabella con i casi d'uso principali come righe e gli elementi dell'elenco di controllo come colonne.

Valutazione con studi sugli utenti

Non c'è niente di meglio che sedersi con gli utenti reali e osservarli mentre tentano di usare la tua app. Se stai eseguendo il retrofit dell'accessibilità in un'esperienza esistente, questa procedura può aiutarti a identificare rapidamente le aree che richiedono miglioramenti. Inoltre, se stai avviando un nuovo progetto, gli studi sugli utenti iniziali possono aiutarti a evitare di dedicare troppo tempo allo sviluppo di una funzionalità difficile da utilizzare.

Cerca di incorporare i feedback di un gruppo di utenti il più diversificato possibile. Prendi in considerazione gli utenti che navigano principalmente con la tastiera o si affidano a tecnologie per la disabilità come screen reader o funzionalità di ingrandimento dello schermo.

Designer UX

Poiché le persone tendono a progettare in base ai propri pregiudizi, se non hai disabilità e non hai colleghi con disabilità, potresti involontariamente progettare solo per alcuni dei tuoi utenti. Mentre lavori, chiediti "quali sono tutti i tipi di utenti che potrebbero fare affidamento su questo design?" Ecco alcune tecniche che puoi provare per rendere il tuo processo più inclusivo.

  • I contenuti hanno un contrasto di colore 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

Lo scopo principale della maggior parte dei siti è trasmettere alcune informazioni all'utente tramite testo scritto o immagini. Tuttavia, se questi contenuti hanno un contrasto ridotto, alcuni utenti (in particolare quelli con problemi di vista) potrebbero avere difficoltà a leggerli. Ciò potrebbe influire negativamente sulla loro esperienza utente. Per risolvere questo problema, cerca di avere un contrasto di colore sufficiente per tutto il testo e le immagini.

Il contrasto viene misurato confrontando la luminanza di un colore di primo piano e di sfondo. Per i testi più piccoli (inferiori a 18 pt o 14 pt in grassetto), è consigliato un rapporto minimo di 4,5:1. Per il testo di dimensioni maggiori, questo rapporto può essere modificato in 3:1.

Nell'immagine di seguito, il testo a sinistra soddisfa questi minimi di contrasto, mentre il testo a destra ha un basso contrasto.

Esempi di testo affiancati. Uno ha un contrasto sufficiente, l'altro un basso contrasto.

Esistono diversi strumenti per misurare il contrasto dei colori, come lo strumento Colore Material di Google, l'app Ratio di contrasto di Lea Verou e aXe di Deque.

L'ordine delle schede è definito

L'ordine di tabulazione è l'ordine in cui gli elementi ricevono lo stato attivo quando l'utente preme il tasto Tab. Per gli utenti che navigano principalmente con una tastiera, il tasto Tab è il mezzo principale per raggiungere tutti gli elementi sullo schermo. Pensalo come al cursore del mouse.

Idealmente, l'ordine delle schede dovrebbe seguire l'ordine di lettura e procedere dalla parte superiore della pagina verso il basso, con gli elementi più importanti visualizzati più in alto nell'ordine. In questo modo, chiunque utilizzi una tastiera può accedere rapidamente a questi elementi.

Un comp di design con controlli interattivi numerati.

L'interfaccia simulata sopra è numerata per mostrare l'ordine delle schede. La creazione di un mock come questo può essere utile per identificare l'ordine delle schede previsto. che può essere poi condivisa con gli sviluppatori e i tester QA per assicurarsi che sia implementata e testata 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 costituito solo da un'icona a forma di lente d'ingrandimento può avere un'etichetta accessibile "Cerca" per aiutare a colmare l'affordance visiva mancante.

Ecco alcuni semplici suggerimenti da seguire per progettare etichette accessibili:

  • Sii conciso: ascoltare descrizioni lunghe può essere noioso.
  • Cerca di non includere il tipo o lo stato del controllo. Se il controllo è codificato correttamente, un'apposita funzionalità lo annuncerà automaticamente.
  • Concentrati sui verbi di azione: utilizza "cerca" anziché "lente d'ingrandimento".
Un comp di design con i controlli contrassegnati dalle relative etichette accessibili.

Ti consigliamo di creare un mock con tutti i controlli etichettati. Questi dati possono essere condivisi con il team di sviluppo e il team QA per l'implementazione e i test.

Diversi modi per interagire con l'interfaccia utente e comprenderla

È facile presumere che tutti gli utenti interagiscano con la pagina principalmente utilizzando un mouse. Durante la progettazione, considera in che modo un utente interagirà con un controllo utilizzando una tastiera.

Pianifica gli stati di messa a fuoco. Ciò significa determinare l'aspetto di un controllo quando l'utente lo mette a fuoco con Tab o preme i tasti freccia. È utile pianificare in anticipo questi stati, anziché cercare di inserirli nel design in un secondo momento.

Infine, per qualsiasi punto di interazione, devi assicurarti che l'utente abbia diversi modi per comprendere i contenuti. Cerca di non utilizzare solo il colore per trasmettere informazioni, poiché questi sottili indizi potrebbero non essere percepiti da un utente con discromatopsia. Un esempio classico è un campo di testo non valido. Invece di un semplice testo sottolineato in rosso per indicare un problema, ti consigliamo di aggiungere anche del testo di supporto. In questo modo, coprirai più basi e aumenterai le probabilità che un utente noti il problema.

Sviluppatore

Il ruolo dello sviluppatore è quello in cui la gestione dell'attenzione e la semantica si combinano per formare un'esperienza utente solida. Di seguito sono riportati alcuni elementi che gli sviluppatori possono tenere presente mentre lavorano sul proprio sito o sulla propria applicazione:

  • L'ordine delle schede è logico.
  • Il fuoco è gestito e visibile correttamente.
  • Gli elementi interattivi sono supportati dalla 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 nell'ordine delle schede senza costi e possono essere attivati automaticamente con la tastiera. Tuttavia, non tutti gli elementi hanno lo stesso comportamento. In particolare, gli elementi generici come div e span non sono attivati nell'ordine di tabulazione. Ciò significa che se utilizzi un div per creare un controllo interattivo, dovrai eseguire ulteriori operazioni per renderlo accessibile alla tastiera.

Ecco due opzioni:

  • Assegna un tabindex="0" al controllo. In questo modo, almeno sarà possibile attivare il relativo stato attivo, anche se probabilmente dovrai eseguire ulteriori operazioni per aggiungere il supporto per le pressioni dei tasti.
  • Se possibile, utilizza un button anziché un div o un span per qualsiasi controllo simile a un pulsante. L'elemento button nativo è molto facile da stilare e supporta senza costi la tastiera.

Gestione della messa a fuoco

Quando modifichi i contenuti della pagina, è importante attirare l'attenzione dell'utente spostando lo stato attivo. Un esempio classico di quando questa tecnica è utile è quando si apre una finestra di dialogo modale. Se un utente che utilizza una tastiera preme un pulsante per aprire una finestra di dialogo e l'elemento di dialogo non viene attivato, l'unica opzione a sua disposizione è scorrere l'intero sito fino a trovare il nuovo controllo. Spostando l'attenzione sui nuovi contenuti non appena vengono visualizzati, puoi migliorare l'efficienza delle esperienze di questi utenti.

Supporto della tastiera per gli elementi interattivi

Se stai creando un controllo personalizzato come un carosello o un menu a discesa, dovrai svolgere alcuni passaggi aggiuntivi per aggiungere il supporto della tastiera. La Guida alle pratiche di authoring ARIA è una risorsa utile che identifica vari pattern di UI e i tipi di azioni da tastiera che dovrebbero supportare.

Un estratto dalla guida sulle pratiche di creazione di ARIA che spiega come creare un gruppo di pulsanti di opzione.

Per scoprire di più su come aggiungere il supporto della tastiera a un elemento, consulta la sezione tabindex mobile della documentazione di Google sugli aspetti fondamentali dell'accessibilità.

I ruoli e gli attributi ARIA vengono applicati in base alle esigenze

I controlli personalizzati non richiedono solo il supporto della tastiera, ma anche una semantica corretta. Dopotutto, semanticamente, un div è solo un contenitore di raggruppamento generico. Se utilizzi un elemento div come base per il menu a discesa, devi fare affidamento su ARIA per applicare una semantica aggiuntiva in modo che il tipo di controllo possa essere trasmesso alla tecnologia per la disabilità. Anche in questo caso, la guida alle pratiche di authoring ARIA può aiutarti a identificare i ruoli, gli stati e le proprietà da utilizzare. Inoltre, molte delle spiegazioni nella guida ARIA sono accompagnate da codice di esempio.

Elementi di etichettatura

Per etichettare gli input nativi, puoi utilizzare l'elemento integrato <label> come descritto su MDN. In questo modo non solo creerai un'affordance visiva sullo schermo, ma assignerai anche un nome accessibile all'input nell'albero di accessibilità. Questo nome viene poi rilevato dalla tecnologia per la disabilità (ad esempio uno screen reader) e annunciato all'utente.

Purtroppo <label> non supporta l'assegnazione di un nome accessibile ai controlli personalizzati (come quelli creati utilizzando gli elementi personalizzati o da semplici div e span). Per questi tipi di controlli, dovrai utilizzare gli attributi aria-label e aria-labelledby.

Test automatici

Essere pigri può essere un bene, soprattutto quando si tratta di test. Ove possibile, cerca di automatizzare i test di accessibilità in modo da non dover fare tutto manualmente. Esistono oggi numerosi strumenti di test di settore che consentono di verificare in modo facile e veloce la presenza di problemi di accessibilità comuni:

aXe, creato da Deque Systems, è disponibile come estensione di Chrome e come modulo Node (ideale per gli ambienti di integrazione continua). Questo breve A11ycast spiega alcuni modi diversi per incorporare aXe nel processo di sviluppo.

Lighthouse è il progetto open source di Google per il controllo del rendimento delle app web progressive. Oltre a verificare se la tua PWA supporta elementi come Service Worker e un manifesto dell'app web, Lighthouse eseguirà anche una serie di test delle best practice, inclusi i 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 acquisire rapidamente familiarità con l'argomento e, auspicabilmente, migliorare l'esperienza complessiva della propria app.

Per scoprire di più sull'accessibilità, consulta il nostro corso senza costi di Udacity e sfoglia la documentazione sull'accessibilità disponibile qui su web.dev.