- 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à di tutti i menu di navigazione all’interno di una piattaforma digitale, inclusi link di primo livello, menu a discesa e sottomenu. Questo test è progettato per essere eseguito dopo una scansione di accessibilità automatizzata e mira a scoprire problemi complessi relativi alla navigazione da tastiera, alla gestione del focus, alle relazioni semantiche e a comportamenti imprevisti che gli strumenti automatizzati spesso non rilevano. Garantire che i menu di navigazione siano pienamente operativi, chiaramente etichettati e semanticamente corretti è fondamentale per tutti gli utenti, in particolare per coloro che si affidano alla navigazione solo da tastiera o agli screen reader, consentendo loro di trovare e accedere in modo efficiente ai contenuti sulla piattaforma. Senza un’implementazione adeguata, la navigazione può diventare un ostacolo significativo, portando all’abbandono da parte dell’utente.
Criteri WCAG coperti #
Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi ai menu di navigazione:
- 2.1.1 Tastiera – A
Questo criterio fondamentale richiede che tutte le funzionalità del contenuto siano gestibili tramite un’interfaccia da tastiera, senza richiedere tempi di pressione specifici per i singoli tasti. Per i menu di navigazione, ciò significa che ogni voce di menu, trigger a discesa e collegamento ai sottomenu deve essere raggiungibile e utilizzabile solo tramite tastiera.
Rilevanza/Test:
Navigheremo sistematicamente tra tutte le voci del menu utilizzando Tab, Maiusc + Tab, Invio, Barra spaziatrice e tasti freccia (per i menu a discesa/sottomenu). Ci assicureremo che tutte le voci del menu siano in primo piano e possano essere attivate, e che i sottomenu siano completamente controllabili.
- 4.1.2 Nome, ruolo, valore – A
Per tutti i componenti dell’interfaccia utente (inclusi gli elementi del menu e i relativi contenitori), il nome e il ruolo possono essere determinati a livello di programmazione; stati, proprietà e valori impostabili dall’utente possono essere impostati a livello di programmazione; e la notifica delle modifiche a questi elementi è disponibile per gli user agent, incluse le tecnologie assistive. Questo è fondamentale per gli screen reader per comprendere la struttura e lo stato dei menu.
Rilevanza/Test:
Esamineremo il markup HTML delle voci di menu per garantire che abbiano ruoli semantici corretti (ad esempio, role=”menuitem”, role=”menu” per i contenitori) e nomi accessibili. Verificheremo l’uso degli attributi ARIA (ad esempio, aria-haspopup, aria-expanded) per comunicare la presenza e lo stato di menu a discesa o sottomenu. Gli annunci degli screen reader saranno verificati per verificarne l’accuratezza e la chiarezza.
- 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 in formato testo. Per i menu di navigazione, ciò significa che la relazione gerarchica tra le voci del menu principale e i relativi sottomenu deve essere programmaticamente chiara e che le voci del menu devono essere raggruppate logicamente.
Rilevanza/Test:
Verificheremo che le voci di menu siano correttamente annidate e che le loro relazioni siano esposte a livello di programmazione (ad esempio, un sottomenu correttamente associato alla voce di menu principale). Gli screen reader dovrebbero trasmettere la struttura (ad esempio, “Home, link”, “Prodotti, voce di menu, ha un pop-up, è compresso”, “Elettronica, voce di sottomenu”).
- 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 i menu di navigazione che potrebbero essere fissi/fissi o avere contenuti sovrapposti.
Rilevanza/Test:
Testeremo i menu, in particolare le barre di navigazione fisse o i menu a discesa, per garantire che quando una voce di menu riceve il focus della tastiera, la voce stessa e il suo indicatore di focus visivo siano sempre completamente visibili e non coperti da altri elementi (ad esempio, altre intestazioni/piè di pagina fissi, sovrapposizioni di contenuto dinamico o persino l’overflow del menu stesso).
- 3.2.1 Sulla messa a fuoco – A
Questo criterio stabilisce che quando un componente dell’interfaccia utente riceve il focus, non si verifica un cambio di contesto. Un cambio di contesto include modifiche significative al contenuto della pagina web, l’apertura di una nuova finestra o lo spostamento del focus su un altro componente in modo tale da disorientare l’utente.
Rilevanza/Test:
Verificheremo che il semplice passaggio del mouse su una voce di menu o il passaggio del mouse su di essa non attivi automaticamente la navigazione della pagina o l’apertura di una nuova finestra. Le modifiche di contesto dovrebbero verificarsi solo tramite attivazione esplicita (ad esempio, premendo Invio o cliccando). I menu a discesa che si aprono automaticamente quando si attiva il focus sono generalmente accettabili, purché il focus rimanga all’interno del menu e non comportino un aggiornamento della pagina.
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:
Elenca sistematicamente ogni istanza di un menu di navigazione, inclusi: - Comprendere il comportamento del menu:
Per ogni menu identificato, determinare:- Come viene attivato (ad esempio, passaggio del mouse, clic, messa a fuoco).
- Come vengono visualizzati e chiusi i menu a discesa/sottomenu.
- Che si tratti di un menu di primo livello o di un sottomenu.
- Quali elementi interattivi sono presenti al suo interno.
- Revisione delle specifiche/documentazione di progettazione:
Se disponibile, consultare la documentazione relativa alla progettazione del menu, all’utilizzo di ARIA e all’accessibilità della tastiera per i componenti di navigazione. - 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, 2.4.11 e 3.2.1, nonché le comuni pratiche di creazione ARIA per i menu (ad esempio, role=”menu”, role=”menuitem”, aria-haspopup=”true”, aria-expanded=”true/false”). - Configurare gli screen reader:
Assicurati che il software di lettura dello schermo sia installato e configurato correttamente. Esercitati a navigare e interagire con i vari tipi di menu 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 ciascun menu di navigazione identificato, sia su desktop che su dispositivi mobili/tablet (con una tastiera esterna, se applicabile). Documentare meticolosamente le osservazioni.
PASSO 1 – Procedura generale per l’operatività della tastiera (WCAG #
Accesso al menu (ad esempio, menu Hamburger): #
- Caso di prova:
è possibile mettere a fuoco e attivare l’elemento trigger (ad esempio, l’icona dell’hamburger, il pulsante “Menu”) per i menu nascosti o fuori area di disegno utilizzando Tab e Invio/Barra spaziatrice? - Caso di prova:
quando viene aperto, il focus della tastiera si sposta automaticamente sul primo elemento interattivo all’interno del menu?
Navigazione tra le voci del menu di primo livello: #
- Utilizzare il tasto Tab per spostarsi tra tutti i collegamenti del menu di livello superiore.
- Caso di prova:
ogni voce del menu di primo livello riceve il focus della tastiera? - Caso di prova:
è possibile attivare ogni voce di menu selezionata utilizzando Invio o la barra spaziatrice? - Caso di prova (navigazione con i tasti freccia, se applicabile):
se il menu è un sistema basato su role=”menubar” o role=”menu”, verificare che i tasti freccia sinistra/freccia destra spostino lo stato attivo tra le voci del menu di livello superiore.
Navigazione nei menu a discesa/sottomenu: #
- Quando una voce di menu di primo livello ha un menu a discesa/sottomenu, per accedervi usare il tasto Tab.
- Passare a ciascun campo del modulo.
- Caso di prova:
il sottomenu viene visualizzato quando la voce di menu principale riceve il focus della tastiera o viene attivata tramite Invio/Barra spaziatrice? - Caso di prova (navigazione con i tasti freccia, se applicabile):
è possibile utilizzare i tasti freccia giù/freccia su per navigare verticalmente tra le voci del sottomenu? È possibile utilizzare i tasti freccia sinistra/freccia destra per aprire/chiudere i sottomenu o per passare ai sottomenu correlati? - Caso di prova:
tutti gli elementi interattivi all’interno del sottomenu (ad esempio, collegamenti, pulsanti) possono essere attivati e attivati tramite tastiera? - Caso di prova:
il focus rimane bloccato nel sottomenu attivo finché non viene chiuso o non viene effettuata una scelta? (Nessun blocco della tastiera). - Caso di prova:
è possibile chiudere il sottomenu premendo il tasto Esc o premendo il tasto Tab?
Chiusura del menu (fuori area di lavoro): #
- Caso di prova:
è possibile attivare il pulsante “Chiudi” per i menu off-canvas tramite tastiera? - Caso di prova:
quando il menu si chiude, il focus torna all’elemento che lo aveva aperto originariamente?
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: #
- Utilizzando gli strumenti di sviluppo, ispeziona il markup HTML del menu di navigazione.
- Caso di test (elementi semantici):
la navigazione principale è in genere racchiusa in un elemento <nav>? Il menu è un elemento <ul> con <li> voci contenenti link <a>? - Caso di test (ruolo del menu di primo livello):
il contenitore del menu principale ha role=”menu” se si tratta di un menu dinamico che utilizza i tasti freccia per la navigazione oppure è un elenco di link standard? (La maggior parte delle navigazioni principali sono elenchi di link e non necessitano di role=”menu”). - Caso di prova (ruoli/nomi delle voci di menu):
le singole voci di menu hanno ruoli corretti (ad esempio, role=”menuitem” per i menu dinamici o ruoli predefiniti per link/pulsanti)? Hanno nomi chiari e accessibili?
Semantica del menu a discesa/sottomenu: #
- Caso di prova (aria-haspopup):
per le voci di menu padre che aprono menu a discesa/sottomenu, l’elemento trigger ha aria-haspopup=”true” (o aria-haspopup=”menu” per i menu)? - Caso di test (aria-expanded):
l’elemento trigger per menu a discesa/accordion aggiorna correttamente il suo attributo aria-expanded (true quando aperto, false quando chiuso)? - Caso di prova (aria-controls):
l’elemento trigger è collegato all’ID del contenuto controllato (menu a discesa/sottomenu) tramite aria-controls? - Caso di prova (ruolo del sottomenu):
il contenitore del sottomenu ha il ruolo=”menu”?
Verifica dello screen reader: #
- Attiva uno screen reader.
- Navigare nel menu.
- Caso di prova:
lo screen reader annuncia il blocco di navigazione principale e il suo scopo (ad esempio, “Area di navigazione”)? - Caso di prova:
per gli elementi di primo livello: annuncia il nome accessibile e il ruolo dell’elemento (ad esempio, “Collegamento Home”, “Voce di menu Prodotti, ha un pop-up”)? - Caso di prova:
per i trigger dei menu a discesa/sottomenu: annuncia correttamente lo stato aria-expanded (ad esempio, “Prodotti, voce di menu, ha un pop-up, compresso” e poi “espanso” quando aperto)? - Caso di prova:
quando si apre un sottomenu, lo screen reader annuncia che è apparso un sottomenu e legge correttamente le voci del sottomenu e i relativi ruoli/nomi? - Caso di prova:
lo screen reader trasmette correttamente la gerarchia (ad esempio, indicando “sottomenu” o “menu annidato”)?
PASSO 3 – Procedura generale per la visibilità del focus (WCAG 2.4.11) #
Presenza dell’indicatore di messa a fuoco visiva (WCAG 2.4.7): #
- Mentre si passa da una voce di menu all’altra, osservare l’indicatore di messa a fuoco visiva.
- Caso di prova:
un indicatore di messa a fuoco visivo distinto e chiaramente percepibile appare attorno a ogni voce di menu e attiva l’elemento quando riceve il focus. - Caso di prova:
l’indicatore di messa a fuoco è coerente nello stile e nel comportamento nell’intero sistema di menu? - Caso di prova:
l’indicatore di messa a fuoco ha un contrasto sufficiente (almeno 3:1) rispetto a tutti gli sfondi su cui potrebbe apparire (WCAG 1.4.11)?
Messa a fuoco non oscurata (WCAG 2.4.11): #
- Testare i menu, in particolare le barre di navigazione fisse e i menu a discesa/sottomenu che si sovrappongono ai contenuti.
- Caso di test (scorrimento):
se il menu è fisso/permanente, scorri la pagina mentre passi da una voce di menu all’altra. La voce di menu evidenziata o il suo indicatore vengono mai nascosti o parzialmente oscurati da altri contenuti (ad esempio, il contenuto principale della pagina, un widget di chat, un altro elemento permanente)? - Caso di test (menu a discesa):
quando si apre un menu a discesa, oscura una parte della voce di menu principale o del suo indicatore di focus? Le voci del sottomenu (e i relativi indicatori di focus) sono completamente visibili all’interno del menu a discesa? - Caso di prova (menu off-canvas):
quando è aperto un menu off-canvas, la voce di menu evidenziata è completamente visibile all’interno della finestra e il suo indicatore di messa a fuoco è chiaro?
PASSO 4 – Procedura generale per On Focus (WCAG 3.2.1) #
Messa a fuoco di prova senza attivazione: #
- Per passare da una voce di menu all’altra, utilizzare solo il tasto Tab (senza premere Invio o la barra spaziatrice).
- Caso di prova:
il semplice fatto di ricevere lo stato attivo della tastiera su una voce di menu o su un trigger a discesa provoca un cambiamento di contesto inaspettato (ad esempio, passa a una nuova pagina, apre una nuova finestra o invia un modulo)? - Caso di prova:
se un menu a discesa o un sottomenu si apre automaticamente quando si attiva il focus, il focus rimane all’interno di quel menu, consentendo l’interazione, senza uscire dalla pagina corrente? (Questo è generalmente accettabile, purché non violi le trappole della tastiera e si evitino modifiche di contesto).
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, 2.4.11 e 3.2.1. Esempi di problemi comuni includono:
- Inoperabilità della tastiera (errore WCAG 2.1.1):
- Blocco della tastiera (errore WCAG 2.1.1/2.1.2):
il focus rimane bloccato all’interno di un menu a discesa o di un menu esterno, impedendo di tornare alla pagina principale o ad altre voci di menu. - Ruoli mancanti/errati (errore WCAG 4.1.2):
i contenitori o gli elementi del menu non dispongono dei ruoli ARIA appropriati (ad esempio, role=”menu”, role=”menuitem”) oppure i ruoli vengono utilizzati in modo errato. - Nomi accessibili mancanti/errati (errore WCAG 4.1.2):
le voci di menu (in particolare quelle con sole icone) non hanno nomi accessibili chiari che ne descrivano lo scopo. - Stato mancante/non corretto (errore WCAG 4.1.2):
gli attributi aria-expanded o aria-haspopup sono mancanti o non vengono aggiornati correttamente, portando gli screen reader a interpretare male gli stati dei menu. - Relazioni mancanti (errore WCAG 1.3.1):
i sottomenu non sono associati a livello di programmazione alle voci di menu principali oppure la gerarchia non è chiara per gli screen reader. - Ordine di messa a fuoco illogico:
la messa a fuoco della tastiera salta in modo irregolare all’interno del menu o tra il menu e il contenuto della pagina, senza seguire un ordine logico visivo o di lettura. - Indicatore di messa a fuoco mancante (errore WCAG 2.4.7):
le voci di menu ricevono il focus della tastiera, ma non viene visualizzato alcun indicatore visivo chiaro. - Indicatore di messa a fuoco scarsamente percepibile (errore WCAG 2.4.7, 1.4.11):
l’indicatore di messa a fuoco è presente ma troppo sottile, ha un contrasto insufficiente o è incoerente. - Indicatore di messa a fuoco oscurato (errore WCAG 2.4.11):
la voce di menu evidenziata o il suo indicatore sono nascosti o parzialmente coperti da altri contenuti (ad esempio, intestazioni fisse, sovrimpressioni, sottomenu sovrapposti al menu principale). - Cambiamento di contesto al focus (errore WCAG 3.2.1):
una voce di menu attiva automaticamente la navigazione di una pagina, apre una nuova finestra o esegue un’altra azione disorientante semplicemente ricevendo il focus della tastiera, senza un’attivazione esplicita. - Il menu a discesa/sottomenu scompare troppo rapidamente (errore WCAG 1.4.13):
quando viene aperto tramite focus sulla tastiera, un menu a discesa/sottomenu scompare prima che l’utente possa leggerne o interagire con il contenuto. - Impossibile chiudere un menu a discesa/sottomenu (errore WCAG 1.4.13):
nessun meccanismo (ad esempio, tasto Esc, tabulazione) per chiudere un menu a discesa/sottomenu aperto. - Menu a discesa/sottomenu solo touch:
i menu a discesa/sottomenu sono utilizzabili solo tramite tocco/clic del mouse e non completamente tramite tastiera.
Classificazione di gravità #
Assegnare un livello di gravità a ciascun problema identificato in base al suo impatto sull’accessibilità dell’utente:
- Critico:
la navigazione principale è completamente inaccessibile tramite tastiera oppure è presente un blocco della tastiera all’interno di un menu che impedisce agli utenti di andare avanti o indietro. (Violazione diretta del Livello A, blocco grave). - Alto:
la maggior parte dei menu di navigazione non è utilizzabile tramite tastiera o comprensibile dagli screen reader a causa della mancanza di ruoli semantici o nomi. Frequenti problemi di visibilità del focus o menu a discesa/sottomenu molto difficili da usare. Violazione del livello A o AA delle WCAG. - Medio:
causa disagi o frustrazioni moderati. Le voci del menu sono accessibili, ma con notevoli difficoltà (ad esempio, utilizzo incoerente di ARIA, piccoli problemi di ordine di messa a fuoco). L’indicatore di messa a fuoco è presente, ma non ottimale. - Basso:
piccoli problemi estetici o leggere inefficienze (ad esempio, nome leggermente meno accessibile dell’ideale ma comunque comprensibile, piccoli problemi di allineamento visivo nei menu).
Nota finale #
I menu di navigazione sono fondamentali per l’orientamento dell’utente e l’accesso ai contenuti. Questo test di accessibilità manuale fornisce un quadro completo per garantire che i menu non siano solo visivamente accattivanti, ma anche completamente navigabili, comprensibili e utilizzabili da tutti, in particolare da coloro che utilizzano solo la tastiera e gli screen reader. Occupandosi meticolosamente della gestione del focus, della chiarezza semantica e dell’operatività della tastiera, i team possono creare un’esperienza utente inclusiva ed efficiente su tutta la loro piattaforma digitale.
