Accessibilità dei contenuti nascosti e rivelati

Scopo #

Lo scopo principale di questo test di accessibilità manuale è verificare meticolosamente che tutti i contenuti nascosti, una volta visualizzati, siano pienamente utilizzabili e leggibili con tecnologie assistive e diversi metodi di input. Questo test mira a confermare la conformità ai criteri di successo WCAG 2.2 1.4.13 Contenuto al passaggio del mouse o al focus (AA), 2.1.1 Tastiera (A) e 1.3.1 Informazioni e relazioni (A). Garantire un’adeguata accessibilità per i contenuti visualizzati è fondamentale per gli utenti che utilizzano la navigazione tramite tastiera, screen reader, ingranditori o che hanno disabilità cognitive o motorie. Senza un’implementazione adeguata, gli utenti potrebbero non essere in grado di accedere, comprendere o ignorare informazioni critiche, con conseguente frustrazione, perdita di dati o incapacità di completare le attività.

Criteri WCAG coperti #

Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi ai contenuti nascosti e rivelati:

• 1.4.13 Contenuto su passaggio del mouse o focus – AA

Questo criterio stabilisce che se il contenuto viene visualizzato passandoci sopra il puntatore o spostando il focus della tastiera, allora il contenuto deve essere:

Ignorabile:
È disponibile un meccanismo per ignorare il contenuto aggiuntivo senza spostare il puntatore o il focus della tastiera.

Passante per il mouse:
Se il contenuto viene visualizzato al passaggio del mouse, è possibile spostare il puntatore sul contenuto aggiuntivo senza che questo scompaia.

Persistente:
Il contenuto aggiuntivo rimane visibile finché non si rimuove il trigger di passaggio del mouse o di messa a fuoco, l’utente non lo ignora o le sue informazioni non sono più valide.

Rilevanza/Test:
Testeremo meticolosamente meccanismi come tooltip, menu a discesa, sottomenu e popover personalizzati attivati ​​dal passaggio del mouse o dal focus. Verificheremo la loro esclusione (ad esempio, utilizzando il tasto Esc o cliccando all’esterno), la loro persistenza quando l’utente sposta il puntatore o il focus della tastiera sul contenuto visualizzato e che non scompaiano automaticamente troppo rapidamente, lasciando agli utenti il ​​tempo necessario per percepire e interagire con il contenuto.

• 2.1.1 Tastiera – A

Questo criterio richiede che tutte le funzionalità del contenuto siano gestibili tramite un’interfaccia da tastiera, senza richiedere tempi di pressione specifici per i singoli tasti. Questo è fondamentale per qualsiasi elemento interattivo, compresi quelli che attivano o fanno parte del contenuto visualizzato.

Rilevanza/Test:
Ci assicureremo che l’elemento trigger (ad esempio, pulsante, link, campo modulo) che rivela il contenuto sia attivabile e utilizzabile tramite tastiera. Inoltre, una volta rivelato il contenuto, verificheremo che tutti gli elementi interattivi al suo interno (ad esempio, voci di menu in un menu a discesa, link in una descrizione comandi) siano anch’essi navigabili e utilizzabili tramite tastiera. Ciò include la garanzia di una corretta gestione del focus (nessuna trappola da tastiera) all’interno dell’area rivelata.

• 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 i contenuti nascosti e rivelati, ciò significa che le tecnologie assistive devono essere in grado di comprendere il ruolo, lo stato e la relazione del contenuto rivelato con il suo trigger.

Rilevanza/Test:
Verificheremo il corretto utilizzo degli attributi ARIA (ad esempio, aria-expanded per indicare se una sezione accordion è aperta o chiusa, aria-controls per collegare un trigger al suo contenuto controllato, aria-haspopup per i menu, role=”tooltip” per i tooltip, aria-describedby per associare il contenuto di un tooltip al suo trigger). Utilizzeremo lettori di schermo per confermare che lo stato e le relazioni di questi componenti siano annunciati correttamente, consentendo agli utenti di tecnologie assistive di comprendere e interagire efficacemente con il contenuto visualizzato.

Ambiente di prova #

Questo test richiede una combinazione di ispezione visiva, ispezione del codice tramite strumenti per sviluppatori e verifica tramite 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 strumenti per sviluppatori per l’ispezione di HTML, CSS e alberi di accessibilità).
• Metodi di input:
  • Tastiera standard (per la navigazione e l’attivazione)
  • Mouse standard (per le interazioni tramite passaggio del mouse e la verifica visiva).
• Tecnologie assistive: Lettore di schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) per verificare informazioni e annunci programmatici.

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:
  • Touchscreen (tocchi per l’attivazione, pressioni prolungate per l’emulazione del passaggio del mouse)
  • Tastiera fisica esterna (USB o Bluetooth) per test completi della tastiera.
• Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per la verifica degli annunci.
• Orientamento: modalità verticale e orizzontale (per valutare la scala delle immagini di testo e il comportamento del testo alternativo con layout reattivi).

Preparazione al test #

Prima di iniziare il test manuale, assicurarsi di aver completato i seguenti passaggi:

1. Identifica tutti i contenuti nascosti/rivelati:
   Elenca sistematicamente ogni caso in cui il contenuto viene inizialmente nascosto e poi rivelato in base all’interazione dell’utente. Questo include:
   • Menu a discesa e sottomenu.
   • Tooltip (testo che appare quando si passa il mouse sopra o ci si concentra).
   • Fisarmoniche e sezioni espandibili/pieghevoli.
   • Caselle di selezione personalizzate o suggerimenti di completamento automatico.
   • Pop-up, finestre modali e avvisi ignorabili.
   • Didascalie o descrizioni delle immagini che appaiono quando si passa il mouse sopra.
   • Qualsiasi altro contenuto “popover” o “flyout”.
2. Comprendere la funzionalità prevista:
   Per ogni componente identificato, è necessario comprendere il comportamento previsto, come viene attivato, quale contenuto rivela e come dovrebbe essere ignorato.
3. Revisione delle specifiche/documentazione di progettazione:
   Se disponibili, consultare le specifiche di progettazione e la documentazione sull’accessibilità per comprendere l’implementazione pianificata degli attributi ARIA e delle interazioni tramite tastiera.
4. Familiarizzare con i criteri WCAG e ARIA:
   Rileggere e interiorizzare i requisiti specifici di WCAG 1.4.13, 2.1.1 e 1.3.1, insieme ai modelli ARIA comuni per questi componenti (ad esempio, aria-expanded, aria-haspopup, role=”tooltip”).
5. 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 componente di contenuto nascosto/rivelato identificato, sia su desktop che su dispositivi mobili/tablet. Documentare meticolosamente le osservazioni.

PASSO 1 – Procedura generale per i contenuti visualizzati al passaggio del mouse o al centro dell’attenzione (WCAG 1.4.13) #

Attiva il contenuto tramite il passaggio del mouse (desktop): #

Spostare il puntatore del mouse sull’elemento trigger (ad esempio, un collegamento, un pulsante).

• Caso di prova:
  il contenuto nascosto (ad esempio, suggerimento, menu a discesa) appare come previsto?
• Caso di test (con passaggio del mouse):
  mentre il contenuto viene visualizzato, spostare il puntatore del mouse dal trigger al contenuto visualizzato. Il contenuto visualizzato rimane visibile? Scompare prematuramente?
• Caso di prova (ignorabile):
  è possibile ignorare il contenuto senza spostare il mouse dal trigger? (ad esempio, premendo Esc o cliccando all’esterno del contenuto).
• Caso di prova (persistente):
  il contenuto rimane visibile per un periodo di tempo sufficiente per essere letto e con cui è possibile interagire oppure scompare troppo rapidamente se il mouse si allontana leggermente dal trigger?

Attiva il contenuto tramite il focus della tastiera (desktop e dispositivi mobili con tastiera esterna): #

Utilizzare il tasto Tab per spostare il focus della tastiera sull’elemento trigger.

• Caso di prova:
  il contenuto nascosto (ad esempio, descrizione comandi, menu a discesa) appare come previsto quando il trigger riceve lo stato attivo?
• Caso di test (persistente):
  una volta visualizzato, utilizzare Tab o i tasti freccia per navigare nel contenuto visualizzato (se contiene elementi interattivi). Il contenuto rimane visibile durante la navigazione?
• Caso di prova (ignorabile):
  il contenuto può essere ignorato premendo il tasto Esc? Può essere ignorato premendo il tasto Tab per uscire dal contenuto e dal suo trigger?

Attivazione dei contenuti tramite tocco (dispositivi mobili e tablet):
#

Tocca l’elemento trigger su un dispositivo touchscreen.

• Caso di prova:
  il contenuto appare come previsto? (Nota: al tocco, la funzionalità di passaggio del mouse viene in genere sostituita dal tocco per visualizzare).
• Caso di prova (ignorabile):
  è possibile ignorare il contenuto toccando al di fuori di esso?
• Caso di prova (persistenza):
  il contenuto rimane visibile finché non viene esplicitamente eliminato oppure scompare automaticamente?

PASSO 2 – Procedura generale per l’operatività della tastiera (WCAG 2.1.1) #

Accesso tramite tastiera al trigger: #

• Caso di prova:
  è possibile raggiungere e mettere a fuoco l’elemento che attiva il contenuto nascosto utilizzando il tasto Tab (e Maiusc + Tab per tornare indietro)?
• Caso di prova:
  è possibile attivare l’elemento trigger utilizzando Invio o la barra spaziatrice per visualizzarne il contenuto?

Accesso tramite tastiera nei contenuti rivelati: #

Una volta visualizzato il contenuto, utilizzare Tab e Maiusc + Tab per navigare tra tutti gli elementi interattivi (link, pulsanti, campi modulo) all’interno del contenuto visualizzato.

• Caso di prova:
  ogni elemento interattivo all’interno del contenuto rivelato riceve il focus della tastiera?
• Caso di prova:
  è possibile attivare o manipolare ogni elemento evidenziato all’interno del contenuto rivelato utilizzando i comandi standard della tastiera (Invio, barra spaziatrice, tasti freccia)?
• Caso di prova (blocco della tastiera):
  il focus della tastiera può spostarsi dentro e fuori dall’area del contenuto visualizzato (ad esempio, dall’ultimo elemento nel contenuto visualizzato all’elemento successivo nella pagina principale e viceversa dall’elemento precedente)? ​​Il focus non può spostarsi sul contenuto di sfondo quando una finestra modale è aperta?

PASSO 3 – Procedura generale per informazioni e relazioni (WCAG 1.3.1) e controlli dello screen reader #

Annunci di trigger e stato #

• Attiva uno screen reader.
• Passare all’elemento trigger utilizzando il tasto Tab.
• Caso di prova:
  lo screen reader annuncia correttamente il ruolo dell’elemento (ad esempio, “pulsante”, “collegamento”, “voce di menu”) e il suo stato (ad esempio, “compresso”, “espanso”, “ha pop-up”)? (Verificare gli attributi aria-expanded, aria-haspopup).
• Caso di prova:
  quando il contenuto viene visualizzato, lo screen reader ne annuncia l’aspetto (ad esempio, “sottomenu espanso”, “suggerimento visualizzato”)?

Leggibilità dei contenuti tramite lettore di schermo: #

• Una volta visualizzato il contenuto, è possibile accedervi utilizzando i comandi da tastiera (ad esempio, Tab, tasti freccia).
• Caso di prova:
  lo screen reader legge il contenuto in modo accurato e in ordine logico?
• Caso di prova:
  per i tooltip, il contenuto del tooltip è associato al suo elemento trigger (ad esempio, utilizzando aria-describedby) in modo che lo screen reader legga il contenuto del tooltip quando il trigger è attivo?
• Caso di prova:
  per i menu a discesa e i menu, i ruoli semantici (role=”menu”, role=”menuitem”) e le relazioni (aria-controls) vengono applicati e annunciati correttamente?

Indicatore di messa a fuoco visiva: #

• Caso di prova (desktop):
  è presente un indicatore di messa a fuoco chiaro e visibile (ad esempio, un contorno distinto) attorno all’elemento di attivazione quando riceve il focus della tastiera e attorno agli elementi interattivi all’interno del contenuto rivelato quando ricevono il focus?

Identificazione dei problemi #

Durante il processo di test, identificare e documentare eventuali deviazioni dal comportamento previsto in base alle WCAG 1.4.13, 2.1.1 e 1.3.1. Esempi di problemi comuni includono:

• Il contenuto scompare troppo rapidamente (errore WCAG 1.4.13):
  il contenuto visualizzato (in particolare al passaggio del mouse) scompare prima che l’utente abbia la possibilità di leggerlo o di interagire con esso.
• Impossibile ignorare il contenuto (errore WCAG 1.4.13):
  nessun meccanismo (ad esempio, tasto Esc, clic all’esterno) per ignorare il contenuto visualizzato senza perdere la posizione corrente del puntatore o il focus della tastiera.
• Il contenuto oscura altri elementi (errore WCAG 1.4.13):
  il contenuto mostrato si sovrappone o nasconde altre parti importanti della pagina, rendendole inaccessibili.
• Trigger non accessibile tramite tastiera (errore WCAG 2.1.1):
  l’elemento che rivela il contenuto nascosto non può essere attivato o messo a fuoco utilizzando solo la tastiera.
• Contenuto nell’area rivelata non accessibile tramite tastiera (errore WCAG 2.1.1):
  una volta rivelati, gli elementi interattivi all’interno del contenuto nascosto (ad esempio, le voci del menu a discesa) non possono essere raggiunti o attivati ​​tramite tastiera.
• Blocco della tastiera (errore WCAG 2.1.1/2.1.2):
  il focus rimane bloccato sul contenuto visualizzato, impedendo agli utenti di uscire dalla schermata premendo il tasto Tab. Questo è un problema grave.
• Attributi ARIA mancanti o errati (errore WCAG 1.3.1):
  • Nessun attributo aria-expanded nelle intestazioni accordion o nei trigger dei menu.
  • Attributi di ruolo non corretti (ad esempio, un div che funge da pulsante senza role=”button”).
  • Manca aria-haspopup per menu o menu a discesa.
  • Il contenuto del tooltip non è associato a livello di programmazione al suo trigger (nessun aria-describedby).
• Informazioni errate sullo screen reader:
  lo screen reader annuncia uno stato errato (ad esempio, “compresso” quando un accordion è espanso), non riesce ad annunciare l’aspetto del contenuto o legge il contenuto in modo non logico.
• Mancanza di indicatore di messa a fuoco visivo:
  nessun contorno di messa a fuoco visibile sul trigger o sugli elementi all’interno del contenuto rivelato.
• Dimensioni ridotte del touch target:
  gli elementi interattivi visualizzati su dispositivi mobili/tablet (ad esempio, voci di sottomenu) hanno touch target troppo piccoli o troppo vicini tra loro.
• Contenuto non reattivo:
• il layout del contenuto visualizzato si interrompe o diventa inutilizzabile su schermi di diverse dimensioni o orientamenti.

Classificazione di gravità #

Assegnare un livello di gravità a ciascun problema identificato in base al suo impatto sull’accessibilità dell’utente:

• Basso:
  Problemi minori con i contenuti rivelati (ad esempio, lievi incongruenze visive, attributi ARIA non critici mancanti ma che non interrompono le funzionalità principali).
• Critico (WCAG 1.1.1 A):
  è presente una trappola da tastiera all’interno o attorno al contenuto visualizzato, oppure il contenuto essenziale non è accessibile o non può essere eliminato dagli utenti di tastiera o screen reader. (Violazione diretta del Livello A, che porta al blocco completo).
• Alto (WCAG 1.4.5 AA):
  Parti significative del contenuto visualizzato non sono utilizzabili tramite tastiera o comprensibili dagli screen reader a causa di relazioni programmatiche mancanti o errate. Il contenuto scompare troppo rapidamente, causando gravi problemi di usabilità. (Violazione diretta del Livello A o AA, che ostacola le attività essenziali)
• Medio  (WCAG 1.4.9 AAA):
  Causa disagi o frustrazioni moderati. Il contenuto è accessibile, ma presenta notevoli difficoltà (ad esempio, utilizzo incoerente delle arie, problemi minori nell’ordine di messa a fuoco, persistenza del contenuto al limite).

Nota finale #

Garantire l’accessibilità dei contenuti nascosti e visibili è fondamentale per creare una piattaforma digitale intuitiva e utilizzabile da tutti. Questo test manuale fornisce un framework solido per identificare problemi relativi all’operabilità della tastiera, alla gestione del focus, alla visualizzazione persistente e alle relazioni programmatiche, spesso trascurati dai controlli automatici. Affrontando meticolosamente queste problematiche, i team possono garantire che i contenuti dinamici siano perfettamente accessibili, consentendo a tutti gli utenti di interagire efficacemente con l’interfaccia.