Come condurre una revisione dell’accessibilità?

Comprendere quanto sia accessibile il vostro modulo, tema o sito può sembrare un compito arduo. Se siete nuovi all’accessibilità, l’argomento stesso può sembrare scoraggiante e difficile da affrontare. Adattarsi a un ampio spettro di abilità significa considerare una vasta gamma di fattori. In questa documentazione abbiamo elencato le considerazioni principali in un processo logico e passo per passo per verificare l’accessibilità del vostro modulo, tema o sito Drupal.

Iniziate con strumenti di analisi automatizzata

Molti problemi di accessibilità possono essere individuati eseguendo una pagina con strumenti automatici. Alcuni strumenti utili includono WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove e l’estensione Siteimprove Accessibility Checker per Chrome. Parte del processo può essere automatizzata con axe-core. Questi strumenti aiutano a individuare rapidamente problemi comuni come errori di markup, attributi ARIA mancanti e contrasto cromatico insufficiente.

Navigazione tramite tastiera

La navigazione da tastiera è il principale mezzo di accesso ai contenuti per gli utenti che non possono o non vogliono usare il mouse. Include persone che utilizzano screen reader e utenti con disabilità motorie come RSI (lesioni da sforzo ripetuto) o paralisi. Per offrire una buona esperienza da tastiera, assicuratevi che l’ordine di tabulazione sia logico e che gli stili di focus siano ben visibili. Inoltre, l’utente non dovrebbe dover tabulare attraverso troppi elementi non necessari.

Cosa verificare

• È presente un link “Salta al contenuto”?

Deve esserci un link che consente agli utenti di passare direttamente al contenuto principale della pagina, saltando elementi ripetitivi come i menu di navigazione. Questo link deve essere il primo elemento attivo e visibile al focus.

• Tutti i controlli sono pienamente utilizzabili?

Ogni elemento interattivo deve essere accessibile con la tastiera. Espansioni, alberi, slider, dialoghi e overlay devono poter essere gestiti senza mouse, o deve esistere un’alternativa.

• È possibile tabulare avanti e indietro?

Alcune applicazioni permettono di tabulare solo in avanti, ma non indietro (Shift + Tab), creando una “trappola da tastiera”. Assicuratevi che la navigazione sia possibile in entrambe le direzioni.

• Esistono trappole da tastiera?

Il focus non deve mai restare intrappolato. Gli utenti devono poter chiudere overlay, modali o menu a comparsa usando solo la tastiera. In caso contrario, avete creato una trappola da tastiera.

• Il focus resta confinato nei dialoghi?

Quando è aperto un dialogo, il focus deve rimanere al suo interno, per evitare che l’utente navighi fuori dal contesto visivo.

• Il focus è sempre visibile?

Ogni elemento interattivo deve essere focalizzabile e mostrare un indicatore di focus (come un contorno). Se l’utente non sa dove si trova il focus, non può interagire con la pagina.

• Ci sono elementi nascosti ma accessibili da tastiera?

Assicuratevi che gli elementi nascosti non siano presenti nell’ordine di tabulazione.

• Il contenuto attivato al passaggio del mouse è accessibile da tastiera?

Ogni contenuto visibile solo al passaggio del mouse deve avere un metodo alternativo per essere attivato da tastiera o da schermo touch.

• Ci sono elementi non interattivi che possono ricevere il focus?

Elementi non interattivi non devono essere focalizzabili. Gli utenti si aspettano che il focus indichi un controllo attivo.

Evitate di aggiungere tabindex="0" a elementi non necessari: rende la navigazione più difficile.

• L’ordine di tabulazione è logico?

Modifiche arbitrarie al tabindex o una struttura DOM disordinata possono creare confusione nella navigazione da tastiera.

Verificate le vostre breakpoint

Dopo i test con la tastiera, ingrandite la pagina fino alle diverse breakpoint (tablet, mobile) e testate di nuovo. Gli utenti che usano alti livelli di zoom interagiranno con la versione mobile del sito.

Intestazioni

Le intestazioni (heading) sono la base della struttura del contenuto. Una buona gerarchia riflette la struttura della pagina come l’indice di un libro. Titoli descrittivi e corretti livelli semantici aiutano gli utenti di screen reader a orientarsi.

• C’è un solo elemento H1 per pagina?

Ogni pagina deve avere un solo H1 che descriva il contenuto principale.

• I livelli delle intestazioni sono coerenti?

Usate gli heading in base alla loro gerarchia logica, non alla dimensione del testo. Non saltate livelli.

• I titoli sono descrittivi?

I titoli devono riassumere chiaramente il contenuto che segue.

Colore e contrasto

Contrasto sufficiente

Il contrasto tra testo e sfondo deve avere un rapporto di almeno 4.5:1. Potete usare strumenti di verifica del contrasto per controllare se i colori rispettano lo standard.

Il colore non deve essere l’unico mezzo informativo

Il colore può supportare la comunicazione, ma non può essere l’unico mezzo. Le persone daltoniche potrebbero non percepire differenze di colore.

Utilizzate almeno uno di questi metodi aggiuntivi:

• Usate testo esplicativo (“On/Off”).
• Usate icone riconoscibili per differenziare lo stato.
• Segnalate errori nei moduli con simboli oltre al colore.

Evitate che gli stati di focus si basino solo sul colore: aggiungete un contorno o una forma visibile.

Non solo icone

Le icone importanti devono avere etichette testuali che ne spieghino la funzione. Non tutti comprendono i simboli intuitivamente. Le etichette testuali rendono le icone accessibili anche agli screen reader.

Audio e video

Se una pagina usa audio o video per comunicare informazioni, devono essere presenti didascalie o trascrizioni. Maggiori dettagli su WebAIM.

• I video informativi devono avere trascrizioni testuali per le persone non vedenti.
• I video con audio devono avere sottotitoli per le persone non udenti.
• I video complessi richiedono descrizioni audio aggiuntive.
• Le dirette video devono avere sottotitoli.
• Le dirette audio devono avere una trascrizione testuale.

Riferimento: WCAG 1.2 Time-based Media.

Animazioni e autoplay

Animazioni, video o audio che si avviano automaticamente possono distrarre o impedire la concentrazione. Anche se sembrano innocui, possono disturbare gli utenti con sensibilità visive o cognitive.

• Evitate animazioni o video automatici di durata superiore a 5 secondi.
• Fornite controlli per fermare, mettere in pausa o riprodurre manualmente.

Contenuti dinamici

JavaScript può aggiornare contenuti senza ricaricare la pagina. Gli utenti con disabilità visive devono essere informati di questi cambiamenti. Esempi: aggiornamento dei risultati di ricerca o notifiche dinamiche. L’API Drupal.announce() consente di annunciare questi cambiamenti tramite tecnologie assistive, basandosi sulle regioni ARIA live.

Test con screen reader

Dopo i test automatici e manuali, potete usare uno screen reader per individuare problemi di accessibilità. Gli strumenti più comuni sono VoiceOver (macOS) e NVDA (Windows).

Cosa verificare

• Tutti i controlli hanno un’etichetta descrittiva?

Ogni elemento di controllo deve essere etichettato chiaramente. Se necessario, utilizzate aria-labelledby per associare etichette personalizzate.

• Gli elementi personalizzati hanno ruoli e attributi ARIA appropriati?

Gli utenti devono ricevere le stesse informazioni visive e semantiche fornite agli utenti vedenti. Gli elementi personalizzati devono avere ruoli ARIA corretti (es. slider con aria-valuenow, aria-valuemin, aria-valuemax).

• Il flusso delle informazioni è logico anche per lo screen reader?

Il CSS può alterare l’ordine visivo: verificate che l’ordine del contenuto sia coerente anche per chi usa uno screen reader.

• I testi dei link hanno senso fuori contesto?

I link devono essere chiari anche se letti isolatamente. Evitate testi generici come “clicca qui” o “leggi di più”.

• Tutte le immagini hanno testo alternativo?

Ogni immagine significativa deve avere un attributo alt appropriato. Le immagini decorative dovrebbero avere alt="" per essere ignorate.

Test manuale con screen reader

Alcuni problemi emergono solo testando manualmente con uno screen reader. Guardate il video introduttivo a VoiceOver o il video introduttivo a NVDA. Potete anche leggere la guida di Marco Zehe su NVDA e Firefox.

Quando siete pronti, provate a navigare senza schermo e senza mouse. Serve tempo per abituarsi, ma è il modo migliore per capire davvero l’esperienza degli utenti con tecnologie assistive.