- Scopo
- Criteri WCAG coperti
- Ambiente di prova
- Preparazione al test
- Processo di test passo dopo passo
- Identificazione dei problemi
- Nota finale
Scopo #
Lo scopo principale di questo test di accessibilità manuale è valutare meticolosamente l’accessibilità delle finestre di dialogo modali (note anche come pop-up o lightbox) all’interno di una piattaforma digitale. Questo test è progettato per essere eseguito dopo una scansione di accessibilità automatizzata e mira a scoprire problematiche complesse relative alla gestione del focus, ai ruoli semantici e alle relazioni programmatiche che spesso gli strumenti automatizzati non rilevano. Assicurarsi che le finestre di dialogo modali catturino correttamente il focus della tastiera, comunichino correttamente il loro ruolo e scopo alle tecnologie assistive e non oscurino contenuti critici è fondamentale. Senza un’implementazione corretta, le finestre di dialogo modali possono creare gravi inconvenienti da tastiera, disorientare gli utenti di screen reader e rendere inaccessibile il contenuto della pagina sottostante, con conseguente esperienza utente frustrante o impossibile.
Criteri WCAG coperti #
Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi ai dialoghi modali:
- 2.1.1 Tastiera – A
Questo criterio fondamentale richiede che tutte le funzionalità del contenuto siano gestibili tramite un’interfaccia da tastiera. Per le finestre di dialogo modali, ciò significa che la finestra di dialogo stessa deve essere avviabile tramite tastiera, tutti gli elementi interattivi all’interno della finestra modale devono essere gestibili tramite tastiera e la finestra modale deve essere chiudibile tramite tastiera.
Rilevanza/Test:
Verificheremo che l’elemento trigger (ad esempio, un pulsante o un link) che apre la finestra modale sia attivabile e attivabile tramite tastiera. Una volta aperta la finestra modale, ci assicureremo che tutti gli elementi al suo interno (pulsanti, campi del modulo, link) siano navigabili e utilizzabili tramite tastiera.
- 4.1.2 Nome, ruolo, valore – A
Per tutti i componenti dell’interfaccia utente (inclusi i dialoghi modali e i loro elementi interni), il nome e il ruolo possono essere determinati programmaticamente; stati, proprietà e valori impostabili dall’utente possono essere impostati programmaticamente; e la notifica delle modifiche a questi elementi è disponibile per gli user agent, incluse le tecnologie assistive. Questo è fondamentale per gli screen reader per capire cos’è un dialogo modale e come interagire con esso.
Rilevanza/Test:
Esamineremo il contenitore principale della finestra di dialogo modale per assicurarci che abbia il ruolo ARIA corretto (ad esempio, role=”dialog” o role=”alertdialog”) e un nome accessibile (ad esempio, tramite aria-labelledby che punta a un’intestazione visibile all’interno della finestra modale, oppure aria-label). Verificheremo inoltre che gli elementi all’interno della finestra modale (come un pulsante di chiusura) abbiano nomi e ruoli appropriati. Verificheremo anche gli annunci dello screen reader.
- 1.3.1 Informazioni e relazioni – A
Questo criterio stabilisce che le informazioni, la struttura e le relazioni trasmesse tramite la presentazione possono essere determinate programmaticamente o sono disponibili nel testo. Per le finestre di dialogo modali, ciò implica che la relazione tra la finestra modale e il contenuto della pagina principale deve essere chiara (ad esempio, il contenuto della pagina principale è nascosto mentre la finestra modale è aperta) e che all’interno della finestra modale deve essere trasmesso un raggruppamento logico.
Rilevanza/Test:
Verificheremo che il contenitore modale definisca chiaramente il suo ambito. Fondamentale, quando un contenitore modale è aperto, è che il contenuto sottostante, visivamente “dietro” il contenitore, sia nascosto a livello di codice agli screen reader (ad esempio, utilizzando aria-hidden=”true” sugli elementi padre del contenuto principale). Questo garantisce che gli screen reader percepiscano solo il contenuto del contenitore modale.
- 2.4.11 Messa a fuoco non oscurata (minimo) – AA
Questo criterio richiede che, quando un componente dell’interfaccia utente riceve il focus da tastiera, non sia completamente nascosto dal contenuto creato dall’autore. Questo è particolarmente rilevante per le finestre modali in cui la finestra di dialogo stessa potrebbe nascondere parzialmente un elemento al suo interno, oppure un’intestazione/piè di pagina fisso all’interno della finestra modale potrebbe oscurare il contenuto.
Rilevanza/Test:
Faremo in modo che quando il focus si sposta all’interno della finestra modale, l’elemento focalizzato e il suo indicatore visivo di focus siano sempre completamente visibili e non coperti da altri elementi (ad esempio, un pulsante di chiusura, un’intestazione/piè di pagina della finestra modale o un elemento fisso all’interno della finestra modale).
Ambiente di prova #
Questo test richiede l’uso completo della navigazione tramite tastiera e dell’interazione con lo screen reader su vari dispositivi.
Desktop #
- Sistemi operativi: Windows (ultime due versioni), macOS (ultime due versioni).
- Browser: ultime versioni stabili di Chrome, Firefox, Edge, Safari (con solidi strumenti di sviluppo per l’ispezione di HTML, attributi ARIA e albero di accessibilità).
- Metodi di input:
- Tastiera standard (metodo di input principale per tutte le interazioni)
- Mouse standard (per osservare il comportamento ma non per l’interazione durante il test).
- Tecnologie assistive: Lettore dello schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) per confermare ruoli, nomi, stati e modifiche di focus annunciati.
Cellulari e tablet #
- Sistemi operativi: iOS (ultime due versioni), Android (ultime due versioni).
- Browser: browser predefiniti (Safari su iOS, Chrome su Android).
- Metodi di input:
- Tastiera fisica esterna (USB o Bluetooth) collegata al dispositivo (fondamentale per un test completo della tastiera su dispositivi mobili/tablet).
- Touchscreen (per il caricamento iniziale della pagina, ma tutte le interazioni per il test stesso dovrebbero avvenire solo tramite tastiera).
- Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per verificare gli annunci e il comportamento di messa a fuoco.
- Strumenti per sviluppatori: funzionalità di debug remoto (ad esempio, Chrome DevTools per Android, Safari Web Inspector per iOS) per l’ispezione di HTML e ARIA su dispositivi mobili.
- Orientamento: modalità verticale e orizzontale (per valutare come i menu si adattano e mantengono l’accessibilità).
Preparazione al test #
Prima di iniziare il test manuale, assicurarsi di aver completato i seguenti passaggi:
- Identifica tutti i menu di navigazione:
Elencare sistematicamente ogni istanza di una finestra di dialogo modale o di una sovrimpressione che interrompe il flusso dell’utente e copre il contenuto principale. Questo include:- Finestre di dialogo di conferma.
- Messaggi di errore/successo che compaiono in una finestra modale.
- Moduli di accesso/registrazione in una finestra modale.
- Gallerie di immagini in una finestra modale.
- Pannelli delle impostazioni che vengono visualizzati come sovrapposizioni.
- Qualsiasi “pop-up” personalizzato che cattura l’attenzione.
- Comprendere il comportamento del menu:
Per ogni modale identificato, determinare:- Come viene attivato?
- Che contenuto mostra?
- Quali elementi interattivi contiene?
- Come si intende chiuderlo (ad esempio, tramite il pulsante Chiudi, il tasto Esc, cliccando all’esterno)?
- Cosa succede al contenuto in background quando viene aperto?
- Revisione delle specifiche/documentazione di progettazione:
Se disponibile, consultare la documentazione relativa alla progettazione modale, all’utilizzo di ARIA e all’accessibilità della tastiera. - Familiarizzare con i criteri WCAG e i modelli di menu ARIA:
Rileggere e interiorizzare i requisiti specifici di WCAG 2.1.1, 4.1.2, 1.3.1 e 2.4.11, nonché le comuni pratiche di creazione ARIA per le finestre di dialogo modali (ad esempio, role=”dialog”, aria-modal=”true”, aria-hidden=”true” per background, aria-labelledby). - Configurare gli screen reader:
Assicurati che il software di lettura dello schermo sia installato e configurato correttamente. Esercitati a navigare e interagire con le finestre modali utilizzando questi strumenti. - Cancella cache/cookie del browser:
Per garantire un ambiente di test pulito, cancellare la cache e i cookie del browser secondo necessità.
Processo di test passo dopo passo #
Eseguire i seguenti passaggi per ciascuna finestra di dialogo modale identificata, sia su desktop che su dispositivi mobili/tablet (con una tastiera esterna, se applicabile). Documentare meticolosamente le osservazioni.
PASSO 1 – Procedura generale per la gestione della messa a fuoco (WCAG 2.1.1, 2.1.2 – Trappole della tastiera) #
Apertura della finestra modale: #
- Caso di test:
attiva l’elemento che attiva la finestra modale utilizzando il tasto Invio o la barra spaziatrice. La finestra modale si apre come previsto?
Focus iniziale e Focus Trapping all’interno della modalità: #
- Subito dopo l’apertura della finestra modale, osservare lo stato attivo della tastiera.
- Caso di test:
il focus della tastiera si sposta automaticamente sul primo elemento interattivo all’interno della finestra modale (ad esempio, il pulsante di chiusura, il primo campo del modulo o il pulsante di azione principale)?
Una volta che il focus è all’interno della finestra modale, premere ripetutamente il tasto Tab. - Caso di test:
il focus passa ciclicamente solo attraverso gli elementi interattivi all’interno della finestra modale? Passa dall’ultimo elemento interattivo al primo all’interno della finestra modale?
Premere ripetutamente Maiusc + Tab. - Caso di prova:
il focus scorre solo gli elementi interattivi all’interno della finestra modale in ordine inverso? - Caso di test (nessun focus sullo sfondo):
mentre la finestra modale è aperta, prova a usare il tasto Tab per uscire dalla finestra modale e passare agli elementi della pagina sottostante. Il focus non deve uscire dalla finestra modale. Questo verifica il blocco della tastiera.
Chiusura della finestra modale: #
- Caso di prova:
individua il pulsante di chiusura della finestra modale (ad esempio, l’icona “X”, il pulsante “Chiudi”). Può essere attivato tramite Invio o barra spaziatrice? La finestra modale si chiude? - Caso di test:
premere il tasto Esc. La finestra modale si chiude? (Questo è un comportamento standard e previsto per le finestre modali). - Caso di test (clic all’esterno):
se la finestra modale è progettata per chiudersi cliccando all’esterno del suo contenuto, utilizzare il mouse o un tocco per cliccare/toccare all’esterno dell’area modale. Si chiude? (Sebbene il test sia basato solo sulla tastiera, questo garantisce la completezza).
Ritorno allo stato attivo alla chiusura: #
- Dopo la chiusura della finestra modale (con qualsiasi metodo), osservare il focus della tastiera.
- Caso di prova:
il focus della tastiera torna all’elemento che ha attivato originariamente la finestra modale? Questo è fondamentale per mantenere il contesto. - Caso di prova:
se l’elemento trigger non è più disponibile (ad esempio, un elemento è stato eliminato tramite una finestra modale), il focus torna a una posizione di fallback logica e coerente (ad esempio, il primo elemento dell’elenco in cui si trovava l’elemento)?
PASSO 2 – Procedura generale per nome, ruolo, valore (WCAG 4.1.2) e informazioni e relazioni (WCAG 1.3.1) #
Semantica della struttura del menu: #
- Aprire la finestra modale e utilizzare gli strumenti di sviluppo del browser per ispezionare l’elemento contenitore principale della finestra modale.
- Caso di test (ruolo):
il contenitore modale ha il ruolo=”dialog” o il ruolo=”alertdialog”? (Utilizzare alertdialog per i messaggi urgenti che richiedono un’azione immediata da parte dell’utente, dialog per quelli meno urgenti). - Caso di test (nome accessibile):
il contenitore modale ha un nome accessibile? In genere, questo viene fornito da:- aria-labelledby indicando l’ID di un’intestazione visibile all’interno della finestra modale (preferito).
- aria-label fornisce un’etichetta di testo concisa per la finestra modale.
- Caso di test (aria-modal):
il contenitore modale ha aria-modal=”true”? Questo è importante per informare le tecnologie assistive che il resto della pagina è inerte.
Nascondere il contenuto dello sfondo (aria-hidden): #
- Mentre la finestra modale è aperta, ispeziona le sezioni del contenuto principale della pagina sottostante (ovvero il contenuto che non fa parte della finestra modale).
- Caso di test (aria-expanded):
gli elementi di contenuto in background sono contrassegnati con aria-hidden=”true”? Questo garantisce che gli screen reader non possano interagire con i contenuti al di fuori della finestra modale attiva.
Verifica dello screen reader (annuncio modale): #
- Attiva uno screen reader.
- Attiva la modalità.
- Caso di prova:
lo screen reader annuncia immediatamente che si è aperta una finestra di dialogo, incluso il suo nome accessibile (ad esempio, “Finestra di dialogo Nuovo messaggio”, “Finestra di dialogo Avviso di conferma eliminazione”)? - Caso di prova:
lo screen reader legge automaticamente il contenuto iniziale o si concentra sul primo elemento interattivo all’interno della finestra modale? - Caso di test:
mentre la finestra modale è aperta, prova a navigare al di fuori della finestra modale (ad esempio, utilizzando i comandi dello screen reader per leggere tramite intestazione o collegamento). Lo screen reader ignora correttamente il contenuto di sfondo? - Caso di prova:
quando la finestra modale si chiude, lo screen reader indica che è stata chiusa (ad esempio, “finestra di dialogo chiusa”) e l’elemento trigger originale viene annunciato correttamente quando si riacquista lo stato attivo?
Elementi semantici all’interno del modale: #
Per gli elementi interattivi all’interno della finestra modale (ad esempio, pulsante di chiusura, campi del modulo, pulsanti di azione), assicurarsi che abbiano nomi, ruoli e stati accessibili corretti (come da test generale degli elementi interattivi).
PASSO 3 – Procedura generale per la visibilità del focus (WCAG 2.4.11) #
Indicatore di messa a fuoco all’interno della finestra modale: #
- Mentre scorri gli elementi interattivi all’interno della finestra modale, osserva l’indicatore di messa a fuoco visiva.
- Caso di prova:
attorno a ogni elemento interattivo all’interno della finestra modale appare un indicatore di messa a fuoco visivo distinto e chiaramente percepibile? - Caso di prova:
l’indicatore di messa a fuoco rispetta il rapporto di contrasto 3:1 rispetto allo sfondo (WCAG 1.4.11)?
Messa a fuoco non oscurata: #
- Prestate molta attenzione alle finestre modali che hanno intestazioni, piè di pagina fissi o layout complessi.
- Caso di prova:
quando un elemento all’interno della finestra modale riceve lo stato attivo, l’intero elemento attivo, incluso il suo indicatore di stato attivo, è completamente visibile e non coperto dagli elementi dell’interfaccia utente della finestra modale (ad esempio, un pulsante “Chiudi” sovrapposto al pulsante “Invia” attivo o un’intestazione fissa che copre un campo del modulo attivo)? - Caso di test (scorrimento all’interno della finestra modale):
se il contenuto della finestra modale è scorrevole, scorrere fino in fondo premendo il tasto Tab. Assicurarsi che gli elementi evidenziati in basso non siano nascosti dal piè di pagina o dalla barra di scorrimento della finestra modale.
Identificazione dei problemi #
Durante il processo di test, identificare e documentare eventuali deviazioni dal comportamento previsto in base alle WCAG 2.1.1, 4.1.2, 1.3.1 e 2.4.11. Esempi di problemi comuni includono:
- Blocco della tastiera (errore WCAG 2.1.1/2.1.2):
il focus entra nella finestra modale ma non può uscirne tramite la navigazione da tastiera standard (Tab, Maiusc + Tab, Esc). In alternativa, il focus può uscire dalla finestra modale e passare al contenuto in background mentre la finestra modale è visivamente aperta. - Focus iniziale mancante:
quando si apre la finestra modale, il focus della tastiera non si sposta automaticamente nella finestra modale, ma rimane sulla pagina di sfondo. - Ritorno focus errato:
alla chiusura della finestra modale, il focus della tastiera non torna all’elemento che ne ha attivato l’apertura. - Ruolo modale mancante (errore WCAG 4.1.2):
il contenitore modale principale non ha role=”dialog” o role=”alertdialog”. - Nome accessibile mancante per la finestra di dialogo modale (errore WCAG 4.1.2):
il contenitore della finestra di dialogo modale non ha un aria-labelledby (che punta a un’intestazione visibile) o un aria-label per fornirne lo scopo. - Contenuto di sfondo non nascosto da AT (errore WCAG 1.3.1):
mentre la finestra modale è aperta, il contenuto della pagina sottostante non è contrassegnato con aria-hidden=”true”, consentendo agli screen reader di interagire con gli elementi nascosti all’esterno della finestra modale. - Aria-modal=”true” mancante:
il contenitore modale non ha aria-modal=”true”, il che potrebbe causare un comportamento imprevedibile per alcune tecnologie assistive. - Elementi non attivabili tramite tastiera all’interno della finestra modale (errore WCAG 2.1.1):
gli elementi interattivi all’interno della finestra modale non possono essere attivati o attivati tramite tastiera. - Indicatore di messa a fuoco visivo mancante nella finestra modale (errore WCAG 2.4.7):
gli elementi all’interno della finestra di dialogo modale ricevono il focus della tastiera, ma non viene visualizzato alcun indicatore visivo chiaro. - Elementi focalizzati oscurati all’interno della finestra modale (errore WCAG 2.4.11):
l’elemento focalizzato o il suo indicatore di focalizzazione all’interno della finestra modale è nascosto o parzialmente coperto da altre parti dell’interfaccia utente della finestra modale. - Finestra modale non chiudibile tramite il tasto Esc:
la funzionalità standard del tasto Esc per chiudere le finestre modali non è implementata. - Problemi semantici per il contenuto modale:
titoli, elenchi o altri elementi strutturali all’interno della finestra modale non sono contrassegnati semanticamente, confondendo gli utenti di lettori di schermo.
Classificazione di gravità #
Assegnare un livello di gravità a ciascun problema identificato in base al suo impatto sull’accessibilità dell’utente:
- Critico:
qualsiasi forma di blocco della tastiera (fallimento WCAG 2.1.2) che impedisca al focus di entrare o uscire dalla finestra modale, o che renda completamente inaccessibili i contenuti essenziali all’interno della finestra modale tramite tastiera. Questo rappresenta un grave problema. Inoltre, se il contenuto in background non è nascosto tramite aria, si verifica un completo disorientamento per gli utenti di screen reader. - Alto:
Errori significativi nella gestione del focus (ad esempio, il focus non torna al trigger, focus iniziale errato), nome accessibile mancante per la finestra modale stessa o elementi interattivi critici all’interno della finestra modale non utilizzabili tramite tastiera. Indicatori di focus assenti o gravemente inadeguati all’interno della finestra modale. - Medio:
causa un disagio o una frustrazione moderati. Il ruolo o le relazioni del Modal potrebbero essere parzialmente imperfetti, ma la funzionalità di base è ancora raggiungibile. L’indicatore di focus potrebbe essere presente, ma non ottimale. - Basso:
piccoli problemi estetici o leggere inefficienze (ad esempio, aria-label leggermente inferiore all’ideale ma comunque comprensibile, piccoli problemi di allineamento visivo all’interno della modalità).
Nota finale #
Le finestre di dialogo modali, pur essendo visivamente semplici, presentano notevoli difficoltà di accessibilità a causa della loro natura che interrompe il flusso utente e crea contesti temporanei. Questo test manuale fornisce un framework rigoroso per garantire che le finestre di dialogo modali siano progettate e implementate in modo da essere pienamente inclusive, prevenendo le trappole da tastiera, comunicando correttamente il loro scopo e contenuto alle tecnologie assistive e mantenendo la visibilità del focus. Affrontando meticolosamente questi aspetti critici, i team possono garantire che le loro esperienze modali siano fluide e accessibili a tutti gli utenti.
