Determinare se il tuo sito web o la tua applicazione è accessibile può sembrare un compito scoraggiante. Se ti stai approcciando all'accessibilità per la prima volta, la vastità dell'argomento può farti chiederti da dove iniziare. Dopotutto, lavorare per soddisfare una vasta gamma di abilità significa che esistono una gamma corrispondentemente ampia di problemi da considerare.
Questo post suddivide questi problemi in una procedura logica e passo passo per esaminare l'accessibilità di un sito esistente.
Inizia con la tastiera
Per gli utenti che non possono o scelgono di non utilizzare un mouse, la navigazione con tastiera è il mezzo principale per accedere a tutti gli elementi sullo schermo. Questo segmento di pubblico include gli utenti con disabilità motorie, come lesioni da stress ripetitivo (RSI) o paralisi, nonché gli utenti di screen reader.
Per un'esperienza ottimale con la tastiera, cerca di avere un ordine di tabulazione logico e stili di messa a fuoco ben distinguibili.
Per iniziare, passa da una scheda all'altra del tuo sito. L'ordine in cui gli elementi vengono attivati deve seguire l'ordine DOM. Se non sai con certezza quali elementi devono ricevere il fuoco, consulta il modulo sul fuoco del corso Impara l'accessibilità. La migliore pratica è che qualsiasi controllo con cui un utente può interagire o fornire input deve essere attivabile e deve mostrare un indicatore di attivazione (ad esempio un anello di attivazione).
I controlli interattivi personalizzati devono essere accessibili. Se utilizzi JavaScript per trasformare un
<div>
in un menu a discesa elaborato, questo non verrà inserito automaticamente nell'ordine delle schede. Per rendere un controllo personalizzato attivabile, assegnagli untabindex="0"
. I valoritabindex
maggiori di 0 modificano l'ordine di tabulazione e possono creare confusione per gli utenti degli screen reader.Rendi attivabili solo i contenuti interattivi. L'aggiunta di
tabindex
a elementi non interattivi come le intestazioni rallenta gli utenti che usano la tastiera e possono vedere lo schermo e non aiuta gli utenti di screen reader perché lo screen reader sa già di doverli annunciare.Se aggiungi nuovi contenuti a una pagina, attira prima l'attenzione dell'utente su questi contenuti in modo che possa intervenire. Per alcuni esempi, consulta Gestire lo stato attivo a livello di pagina.
Progetta il tuo sito in modo che l'utente possa sempre mettere in primo piano l'elemento successivo quando vuole. Fai attenzione ai widget di completamento automatico e ad altri contesti che possono bloccare il fuoco della tastiera. Puoi bloccare temporaneamente il fuoco quando vuoi che l'utente interagisca con una finestra modale e non con il resto della pagina, ma devi sempre fornire un modo accessibile dalla tastiera per uscire dalla finestra modale. Per un esempio, consulta Modali e trappole da tastiera.
Rendere utilizzabile il controllo dell'attenzione
Se hai creato un controllo personalizzato, consenti agli utenti di accedere a tutte le sue funzionalità utilizzando solo la tastiera. Leggi Gestire lo stato attivo nei componenti per conoscere le tecniche per migliorare l'accesso alla tastiera.
Gestire i contenuti offscreen
Molti siti presentano contenuti fuori schermo che sono presenti nel DOM ma non risultano visibili, come link all'interno di un riquadro a scomparsa adattabile o un pulsante dentro una finestra modale ancora da visualizzare. Se lasciati nel DOM, questi elementi possono creare un'esperienza di digitazione confusa, specialmente per gli screen reader, che annunciano i contenuti fuori schermo come se facessero parte della pagina.
Consulta la sezione Gestione dei contenuti fuori schermo per suggerimenti su come gestire questi elementi.
Eseguire il test con uno screen reader
Il miglioramento del supporto generale della tastiera getta le basi per il passaggio successivo, ovvero controllare la pagina per verificare che le etichette e la semantica siano corrette e che non ci siano ostacoli alla navigazione con lo screen reader.
Se non hai dimestichezza con il modo in cui il markup semantico viene interpretato dalla tecnologia di assistenza, leggi l'articolo Struttura dei contenuti.
- Controlla che in tutte le immagini sia presente il testo
alt
corretto. L'eccezione a questa prassi si verifica quando le immagini sono principalmente a scopo di presentazione e non sono elementi essenziali dei contenuti. Per indicare che gli screen reader devono saltare un'immagine, imposta il valore su una stringa vuota:alt=""
. - Controlla tutti i controlli per verificare la presenza di un'etichetta. Per i controlli personalizzati, potrebbe essere necessario l'uso di
aria-label
oaria-labelledby
. Per esempi, consulta Etichette e relazioni ARIA. - Controlla tutti i controlli personalizzati per verificare la presenza di un
role
appropriato e di eventuali attributi ARIA obbligatori che comunichino il loro stato. Ad esempio, una casella di controllo personalizzata richiede unrole="checkbox"
e unaria-checked="true|false"
per trasmettere correttamente il suo stato. Consulta Introduzione ad ARIA per una panoramica generale di come ARIA può fornire la semantica mancante per i controlli personalizzati. - Rendi coerente il flusso di informazioni nella pagina. Poiché gli screen reader navigano nella pagina in ordine DOM, annunceranno gli elementi che hai riposizionato visivamente utilizzando il CSS in un ordine senza senso. Se hai bisogno che qualcosa venga visualizzato all'inizio della pagina, spostalo fisicamente all'inizio del DOM.
- Cerca di supportare la navigazione con lo screen reader per tutti i contenuti della pagina. Assicurati che nessuna sezione del sito sia nascosta o bloccata definitivamente per l'accesso da screen reader.
- Se i contenuti devono essere nascosti a uno screen reader, ad esempio se sono fuori schermo o solo di presentazione, impostali su
aria-hidden="true"
. Per una spiegazione più dettagliata, consulta la sezione Nascondere i contenuti.
- Se i contenuti devono essere nascosti a uno screen reader, ad esempio se sono fuori schermo o solo di presentazione, impostali su
Acquisire familiarità con gli screen reader
Può sembrare difficile imparare a usare uno screen reader, ma in realtà sono piuttosto intuitivi. In genere, la maggior parte degli sviluppatori può svolgere questa operazione con pochi semplici comandi chiave.
Se utilizzi un Mac, guarda questo video su VoiceOver, lo screen reader fornito con macOS. Se utilizzi un PC, guarda questo video su NVDA, uno screen reader open source supportato da donazione per Windows.
aria-hidden
non impedisce il focus della tastiera
È importante capire che ARIA può influire solo sulla semantica di un elemento. Non ha alcun effetto sul comportamento dell'elemento. Puoi nascondere un elemento agli screen reader con aria-hidden="true"
, ma questo non cambia il comportamento del fuoco per quell'elemento. Per i contenuti interattivi fuori schermo, usa l'attributo inert
per assicurarti che vengano effettivamente rimossi dal flusso della tastiera. Per i browser meno recenti, combina aria-hidden="true"
con tabindex="-1"
.
Gli elementi interattivi devono indicare il loro scopo e il loro stato
Fornire suggerimenti visivi, o affordance, su cosa farà un controllo aiuta un'ampia gamma di persone su una vasta gamma di dispositivi a utilizzare e navigare nel tuo sito.
- Gli elementi interattivi, come link e pulsanti, devono essere distinguibili dagli elementi non interattivi. È difficile per gli utenti navigare in un sito o in un'app quando non sanno se un elemento è cliccabile. Esistono molti modi validi per indicare gli elementi interattivi. Una pratica comune è sottolineare i link per distinguerli dal testo circostante.
- Analogamente al requisito di messa a fuoco, gli elementi interattivi come link e pulsanti
richiedono uno stato
hover
per indicare agli utenti che usano il mouse quando il cursore si trova sopra qualcosa che può essere selezionato. Tuttavia, per rendere questi elementi accessibili ad altri metodi di immissione, devono essere distinguibili senza uno statohover
.
Sfrutta intestazioni e punti di riferimento
Le intestazioni e gli elementi di riferimento forniscono alla pagina una struttura semantica e aumentano notevolmente l'efficienza di navigazione degli utenti delle tecnologie per la disabilità. Molti utenti di lettori dello schermo affermano che, quando arrivano per la prima volta su una pagina sconosciuta, tipicamente cercano di navigare tramite le intestazioni.
Analogamente, gli screen reader offrono anche la possibilità di passare a punti di riferimento importanti come <main>
e <nav>
. Per questi motivi, è importante considerare in che modo la struttura della pagina può essere utilizzata per guidare l'esperienza dell'utente.
- Utilizza la gerarchia
h1-h6
. Considera le intestazioni come strumenti per creare un riassunto della pagina. Non fare affidamento sullo stile integrato delle intestazioni. Trattali invece come se avessero tutte le stesse dimensioni e utilizza il livello semanticamente appropriato per i contenuti principali, secondari e terziari. Poi, utilizza CSS per fare in modo che le sezioni rispettino il tuo design. - Utilizza elementi e ruoli di punto di riferimento in modo che gli utenti possano ignorare i contenuti ripetitivi. Molte tecnologie per la disabilità forniscono scorciatoie per passare a parti specifiche della pagina, come quelle definite dagli elementi
<main>
o<nav>
. Questi elementi hanno ruoli di punto di riferimento impliciti. Puoi anche utilizzare l'attributorole
ARIA per definire esplicitamente le regioni nella pagina, come in<div role="search">
. Per altri esempi, consulta Semantica e navigazione nei contenuti. - Evita
role="application"
, a meno che tu non abbia esperienza con questo tipo di formato. Il ruolo punto di riferimentoapplication
indica alla tecnologia per la disabilità di disattivare le sue scorciatoie e di trasmettere tutte le pressioni dei tasti alla pagina. Ciò significa che i tasti che gli utenti di screen reader utilizzano in genere per spostarsi nella pagina non funzionano più e dovrai implementare tutta la gestione della tastiera.
Rivedi le intestazioni e i punti di riferimento con uno screen reader
Gli screen reader, come VoiceOver e NVDA, forniscono un menu contestuale per passare alle regioni importanti della pagina. Quando esegui il test di accessibilità, puoi utilizzare questi menu per avere una panoramica della pagina e determinare se i livelli di intestazione sono appropriati e quali elementi di riferimento sono in uso.
Per saperne di più, consulta questi video didattici sulle nozioni di base di VoiceOver e NVDA.
Automatizza il processo
Testare manualmente l'accessibilità di un sito può essere noioso e soggetto a errori. È consigliabile automatizzare i test il più possibile. Puoi utilizzare le estensioni del browser e le suite di test di accessibilità della riga di comando.
- La pagina supera tutti i test delle estensioni del browser aXe o WAVE? Sono disponibili altre opzioni, ma queste estensioni possono essere un'aggiunta utile a qualsiasi processo di test manuale perché possono rilevare problemi sottili come rapporti di contrasto non validi e attributi ARIA mancanti.
- Se preferisci lavorare sulla riga di comando, axe-cli offre le stesse funzionalità dell'estensione del browser aXe, ma può essere eseguita dal terminale.
- Per evitare regressioni, in particolare in un ambiente di integrazione continua, incorpora una libreria come axe-core nella suite di test automatici. axe-core è lo stesso motore alla base dell'estensione aXe per Chrome, ma in un'utilità a riga di comando.
- Se utilizzi un framework o una libreria, fornisce i propri strumenti di accessibilità? Ad esempio, il plug-in protractor-accessibility-plugin per Angular. Sfrutta gli strumenti disponibili, se possibile.
Utilizzare Lighthouse per testare le PWA
Lighthouse è uno strumento che misura le prestazioni della tua app web progressiva (PWA). Inoltre, utilizza la libreria axe-core per eseguire i test di accessibilità.
Se utilizzi già Lighthouse, cerca i test di accessibilità con problemi nel report. Correggi gli errori per migliorare l'esperienza utente complessiva del tuo sito.