Contesto descrittivo per elementi interattivi

Scopo #

Lo scopo principale di questo test di accessibilità manuale è valutare meticolosamente se gli elementi interattivi, in particolare pulsanti e link, possiedono nomi programmatici chiari, univoci e significativi che comunichino efficacemente il loro scopo sia dentro che fuori dal contesto. Questo test mira a confermare la conformità ai criteri di successo WCAG 2.2 2.4.4 Scopo del collegamento (nel contesto) (A), 2.4.9 Scopo del collegamento (solo collegamento) (AAA), 4.1.2 Nome, ruolo, valore (A), 2.4.6 Intestazioni ed etichette (AA) e 2.5.3 Etichetta nel nome (A). Fornire etichette descrittive e coerenti per gli elementi interattivi è fondamentale per gli utenti che utilizzano screen reader, controllo vocale o altre tecnologie assistive, consentendo loro di comprendere la funzione di un elemento e prevederne l’esito prima dell’attivazione. Questo processo manuale si basa sull’ispezione visiva, sull’analisi degli strumenti di sviluppo e su un’ampia interazione con lo screen reader per garantire che tutti gli elementi interattivi siano chiaramente identificabili e comprensibili.

Criteri WCAG coperti #

Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi agli elementi interattivi descrittivi:

• 2.4.4 Scopo del collegamento (nel contesto) – A

Questo criterio richiede che lo scopo di ciascun collegamento possa essere determinato dal solo testo del collegamento o dal testo del collegamento insieme al contesto del collegamento determinato programmaticamente. Ciò significa che lo scopo di un collegamento deve essere chiaro anche se un utente lo incontra al di fuori della frase circostante, ad esempio quando naviga in una pagina tramite l’elenco di collegamenti di uno screen reader.

Rilevanza/Test:
Controlleremo tutti i link, in particolare quelli con testo generico come “Clicca qui” o “Leggi di più”, per assicurarci che il loro scopo sia chiaro sia dal testo del link stesso sia dal testo, dal paragrafo o dall’elemento di elenco immediatamente associato precedente/seguente.

• 2.4.9 Scopo del collegamento (solo collegamento) – AAA

Questo criterio estende il punto 2.4.4 richiedendo che sia disponibile un meccanismo che consenta di identificare lo scopo di ciascun collegamento a partire dal solo testo del collegamento, tranne quando lo scopo risulterebbe ambiguo per gli utenti in generale. Si tratta di un livello di conformità più elevato, che mira alla massima chiarezza senza la necessità di un contesto circostante.

Rilevanza/Test:
Per una valutazione AAA, valuteremo specificamente se il testo del link stesso (ad esempio, utilizzando aria-label o testo visivamente nascosto) descrive esplicitamente la destinazione o l’azione del link, senza basarsi su alcun contesto esterno. Questo è fondamentale per gli utenti che navigano tramite l’elenco dei link.

• 4.1.2 Nome, ruolo, valore – A

Per tutti i componenti dell’interfaccia utente (inclusi elementi di form, link e componenti generati da script), 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 agli user agent, incluse le tecnologie assistive. Questo è un criterio fondamentale per tutti gli elementi interattivi.

Rilevanza/Test:
Verificheremo che ogni elemento interattivo (pulsante, collegamento, campo modulo, widget personalizzato) abbia un nome determinabile a livello di programmazione (nome accessibile), un ruolo corretto (ad esempio, “pulsante”, “collegamento”, “casella di controllo”) e che il suo stato (ad esempio, “premuto”, “selezionato”, “espanso”) e il suo valore (per i campi modulo) siano anch’essi esposti a livello di programmazione. Questo spesso comporta l’ispezione degli attributi ARIA e della semantica HTML nativa. La verifica tramite screen reader è fondamentale in questo caso.

• 2.4.6 Titoli ed etichette – AA

Intestazioni ed etichette descrivono l’argomento o lo scopo. Questo vale direttamente per le etichette dei campi dei moduli e indirettamente per le intestazioni delle sezioni che forniscono contesto agli elementi interattivi.

Rilevanza/Test:
Esamineremo tutti i campi di input del modulo per assicurarci che contengano elementi <label> espliciti e associati a livello di codice o attributi aria-label/aria-labelledby che ne descrivano accuratamente lo scopo. Verificheremo anche che le intestazioni (<h1>-<h6>) siano utilizzate in modo appropriato per strutturare il contenuto e fornire un contesto logico agli elementi interattivi all’interno di una sezione.

2.5.3 Etichetta nel nome – A

Per i componenti dell’interfaccia utente con etichette che includono testo o immagini di testo, il nome accessibile include il testo presentato nell’etichetta visiva. Questo garantisce che gli utenti che utilizzano il controllo vocale possano pronunciare l’etichetta visibile per attivare un controllo.

Rilevanza/Test:
Se un pulsante riporta visivamente la dicitura “Invia” e ha un’icona, il suo nome accessibile deve includere “Invia” affinché il comando vocale “clicca su Invia” funzioni. Verificheremo che il testo o l’immagine nell’etichetta visibile di un componente faccia parte del suo nome accessibile. Questo è particolarmente importante per i pulsanti con solo icona o con testo e icona, il cui scopo potrebbe non essere chiaro senza il testo.

Ambiente di prova #

Questo test richiede una combinazione di ispezione visiva, ispezione del codice tramite strumenti per sviluppatori e 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 strumenti per sviluppatori per l’ispezione di HTML, CSS e alberi di accessibilità).
• Metodi di input:
  • Mouse standard (per l’ispezione visiva),
  • Tastiera (per la navigazione degli elementi negli strumenti per sviluppatori)
  • software di controllo vocale (ad esempio, Riconoscimento vocale di Windows, Controllo vocale di macOS) per la verifica 2.5.3.
• Tecnologie assistive: Lettore dello schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) per ascoltare nomi, ruoli e stati accessibili.

Cellulari e tablet #

• Sistemi operativi: iOS (ultime due versioni), Android (ultime due versioni).
• Browser: browser predefiniti (Safari su iOS, Chrome su Android) e altri browser mobili più diffusi.
• Metodi di input:
  • touchscreen (per ispezione visiva e interazione)
  • controllo vocale (ad esempio, controllo vocale iOS, accesso vocale Android) per la verifica 2.5.3.
• Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per verificare nomi e ruoli accessibili.
• Strumenti per sviluppatori: unzionalità di debug remoto (ad esempio, Chrome DevTools per Android, Safari Web Inspector per iOS) per l’ispezione dell’HTML sui dispositivi mobili.
• Orientamento: modalità verticale e orizzontale.

Preparazione al test #

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

1. Identifica tutti gli elementi interattivi:
   Elenca sistematicamente tutti gli elementi interattivi sulla piattaforma, classificandoli come link, pulsanti o controlli dei moduli. Includi tutte le istanze di widget personalizzati che fungono da elementi interattivi.
2. Comprendere lo scopo previsto:
   Per ogni elemento identificato, determina mentalmente (o verbalmente) il suo scopo e l’azione che esegue.
3. Revisione delle specifiche di progettazione:
   Se disponibili, consultare le specifiche di progettazione e la documentazione sull’accessibilità che delineano le etichette previste, il testo dei link e l’utilizzo di ARIA.
4. Familiarizzare con i criteri WCAG e ARIA:
   Rileggere e assimilare i requisiti specifici di tutti i criteri WCAG elencati. Comprendere come gli attributi aria-label, aria-labelledby, title e gli elementi <label> contribuiscono al nome accessibile di un elemento.
5. Configurare le tecnologie assistive:
   Assicurati che il software di lettura dello schermo e di controllo vocale sia installato e configurato correttamente. Esercitati ad ascoltare e interagire con gli elementi utilizzando questi strumenti.
6. 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 elemento interattivo identificato, sia su desktop che su dispositivi mobili/tablet. Documentare meticolosamente le osservazioni.

PASSO 1 – Procedura generale per lo scopo del collegamento (WCAG 2.4.4, 2.4.9) #

Scansione visiva per i collegamenti: #

• Naviga nella pagina e identifica tutti i link (elementi <a>).
• Presta particolare attenzione ai testi dei link comuni e generici, come “Leggi di più”, “Scopri di più”, “Clicca qui”, “Visualizza dettagli”.

Valutare lo scopo del collegamento (nel contesto – WCAG 2.4.4): #

• Per ogni collegamento, leggi il testo del collegamento stesso.
• Quindi, leggi il testo immediatamente circostante (ad esempio, il paragrafo in cui si trova il collegamento, l’elemento dell’elenco a cui appartiene, il titolo che segue).
• Caso di prova:
  lo scopo del collegamento può essere determinato chiaramente dal solo testo del collegamento o dal testo del collegamento combinato con il suo contesto immediato? (ad esempio, “Ulteriori informazioni sulla nostra politica sulla privacy” o “Informativa sulla privacy [link all’Informativa sulla privacy]”).
• Caso di prova:
  il testo del collegamento riflette accuratamente il contenuto o la destinazione del collegamento?
• Caso di prova (link ridondanti):
  se più link portano alla stessa destinazione, hanno tutti un testo coerente e significativo?

Valutare lo scopo del collegamento (solo collegamento – WCAG 2.4.9 – livello AAA): #

• Per ogni collegamento, utilizzare gli strumenti per sviluppatori per ispezionarne il nome accessibile (come lo “vedrebbe” uno screen reader: aria-label, aria-labelledby o contenuto di <a>).
• Caso di prova:
  il solo testo del collegamento (nome determinato a livello di programmazione) fornisce una descrizione chiara e univoca del suo scopo, senza richiedere alcun contesto esterno? (ad esempio, aria-label=”Scopri di più sulla nostra politica di reso” per un collegamento “Scopri di più” accanto a un riepilogo della politica di reso).
• Caso di prova:
  se il collegamento è un collegamento con sola icona, ha un’etichetta aria che ne indica chiaramente lo scopo (ad esempio, aria-label=”Vai al carrello” per un’icona del carrello)?
• Caso di prova:
  lo scopo del collegamento è diverso da quello degli altri collegamenti presenti nella stessa pagina quando vengono letti fuori contesto (ad esempio, se sono presenti più collegamenti “Leggi di più”, i loro nomi accessibili ne differenziano lo scopo)?

PASSO 2 – Procedura generale per nome, ruolo, valore ed etichette (WCAG 4.1.2, 2.4.6) #

Ispeziona tutti gli elementi interattivi (pulsanti, collegamenti, campi modulo, widget personalizzati): #

• Utilizzando gli strumenti di sviluppo, seleziona ciascun elemento interattivo.
• Caso di test (ruolo – WCAG 4.1.2):
  verificare che l’elemento abbia il ruolo HTML semantico corretto (ad esempio, <button>, <a>, <input type=”checkbox”>) o un attributo di ruolo ARIA appropriato se si tratta di un componente personalizzato (ad esempio, role=”button”, role=”link”, role=”checkbox”).
• Caso di test (nome – WCAG 4.1.2):
  verificare che l’elemento abbia un nome accessibile e determinabile a livello di programmazione. Questo può derivare da:
  • Contenuto di testo visibile (per pulsanti/link nativi).
  • Elemento <label> per gli input del modulo (utilizzando l’associazione for/id).
  • attributo aria-label.
  • Attributo aria-labelledby che punta all’ID di un altro elemento.
  • attributo alt per gli elementi <img> all’interno dei controlli funzionali.
• Caso di prova (Valore/Stato – WCAG 4.1.2):
  • Per i campi del modulo: verificare che il valore corrente sia esposto a livello di programmazione.
  • Per interruttori/caselle di controllo/accordion: verificare che il loro stato attuale (ad esempio, aria-checked=”true/false”, aria-pressed=”true/false”, aria-expanded=”true/false”) sia impostato correttamente e si aggiorni in base all’interazione.
• Caso di prova (etichette – WCAG 2.4.6):
  • Per tutti i campi di input del modulo (<input>, <textarea>, <select>): esiste un elemento <label> visibile associato a livello di programmazione all’input (utilizzando for=”id” che corrisponde all’ID dell’input)?
  • L’etichetta è concisa, chiara e descrive accuratamente lo scopo del campo di input?
  • Se non viene utilizzato alcun <label> (ad esempio, a causa di vincoli di progettazione), è presente un’etichetta aria o un’etichetta aria chiara?

Verifica dello screen reader (nome, ruolo, valore, etichette): #

• Attiva uno screen reader.
• Passare a ciascun elemento interattivo.
• Caso di prova:
  lo screen reader annuncia correttamente il nome accessibile, il ruolo e lo stato/valore attuale dell’elemento (ad esempio, “Pulsante di ricerca”, “Indirizzo e-mail, modifica testo”, “Casella di controllo, selezionata”, “Interruttore a levetta, attivato, pulsante”)?
• Caso di prova:
  per i campi del modulo, lo screen reader annuncia l’etichetta quando l’input riceve lo stato attivo?

PASSO 3 – Procedura generale per l’etichetta nel nome (WCAG 2.5.3) #

Identificare i componenti con etichette visive: #

• Identificare visivamente tutti i componenti interattivi (pulsanti, link, elementi del modulo, controlli personalizzati) che hanno un’etichetta di testo visibile o un’immagine di testo come etichetta.

Controlla l’inclusione del nome accessibile: #

• Per ogni componente identificato, utilizzare gli strumenti per sviluppatori per ispezionare il suo nome accessibile (come percepito dalle tecnologie assistive).
• Caso di prova:
  il nome accessibile include il testo esatto (o il testo dell’immagine) presentato visivamente come etichetta?
  • Esempio: se un pulsante riporta visibilmente la dicitura “Applica filtri”, il suo nome accessibile deve includere “Applica filtri”. Un’etichetta aria=”Invia modulo” sarebbe un errore se “Invia modulo” non fosse presente visivamente.
  • Esempio: se un pulsante icona ha un’etichetta di testo visibile “Aiuto”, il suo nome accessibile dovrebbe essere “Aiuto” o “Pulsante Aiuto”.
• Caso di test (controllo vocale):
  utilizzare un software di controllo vocale. Provare ad attivare l’elemento pronunciandone l’etichetta visibile. Risponde come previsto? (ad esempio, “Clicca su Invia”, “Clicca sulla pagina successiva”, “Vai al carrello”).

Verifica dello screen reader (etichetta nel nome): #

• Attiva uno screen reader.
• Passare ai componenti con etichette visibili.
• Caso di prova:
  lo screen reader annuncia un nome che contiene l’etichetta di testo visibile?

Scenari specifici da testare #

Pulsanti/link solo icona: #

assicurati che aria-label o aria-labelledby forniscano una descrizione chiara e pratica (ad esempio, aria-label=”Modifica profilo” per un’icona a forma di matita).

Pulsanti con testo e icona: #

verificare che il nome accessibile includa il testo visibile e chiarisca lo scopo dell’icona, se necessario (ad esempio, <button aria-label=”Aggiungi al carrello – quantità 1″><img src=”cart.png” alt=””>Aggiungi al carrello</button> o semplicemente Aggiungi al carrello se l’icona è decorativa).

Testo del collegamento generico: #

i collegamenti come “Clicca qui”, “Altro”, “Dettagli” dovrebbero avere il loro scopo chiarito nel contesto (2.4.4) o direttamente nel loro nome accessibile (2.4.9).

Pulsanti “Vai” nei campi di ricerca: #

un pulsante “Vai” accanto a un input di ricerca dovrebbe avere un nome accessibile come “Vai ai risultati della ricerca” o aria-label=”Cerca” per fornire contesto.

Segnaposto nei campi del modulo: #

i segnaposto (attributo placeholder) non sono sufficienti come etichette. Verificare che esista un’etichetta visibile o un’etichetta aria-label/aria-labelledby corretta oltre al segnaposto.

Elementi generati dinamicamente: #

se gli elementi vengono visualizzati dopo l’interazione dell’utente (ad esempio, suggerimenti di ricerca, nuovi campi del modulo), assicurarsi che soddisfino anche tutti i criteri di denominazione ed etichettatura.

Intestazioni come etichette: #

assicurati che le intestazioni descrivano chiaramente la sezione introdotta e tutti gli elementi interattivi in ​​esse contenuti.

Etichette nascoste/per ipovedenti: #

se un’etichetta è nascosta visivamente per motivi di progettazione, assicurati che sia ancora presente a livello di programmazione e correttamente associata (ad esempio, utilizzando una classe nascosta visivamente in CSS e for/id o aria-label).

Identificazione dei problemi #

Durante il processo di test, identificare e documentare eventuali deviazioni dal comportamento previsto in base ai criteri WCAG pertinenti. Esempi di problemi comuni includono:

• Testo di collegamento generico (errore WCAG 2.4.4):
  testo di collegamento come “Clicca qui” senza una sufficiente chiarificazione programmatica o contestuale del suo scopo.
• Scopo ambiguo del collegamento (fallimento WCAG 2.4.9):
  collegamenti con testo identico che portano a destinazioni o azioni diverse e i cui nomi accessibili non li differenziano.
• Nome accessibile mancante (errore WCAG 4.1.2):
  un elemento interattivo (pulsante, collegamento, campo modulo) non ha un nome determinabile a livello di programmazione (ad esempio, un pulsante icona senza testo alternativo o etichetta aria).
• Ruolo errato (errore WCAG 4.1.2):
  un componente personalizzato ha un attributo di ruolo errato, che fornisce informazioni errate sulle tecnologie assistive (ad esempio, div con onclick ma senza role=”button”).
• Stato/valore non esposto a livello di programmazione (errore WCAG 4.1.2):
  lo stato corrente di un interruttore o il valore di un campo di un modulo personalizzato non vengono comunicati correttamente alle tecnologie assistive (ad esempio, aria-checked non si aggiorna).
• Etichette del modulo mancanti o errate (errore WCAG 2.4.6):
  i campi di input del modulo non dispongono di un’etichetta <label> associata a livello di programmazione o di un’etichetta aria/labelledby efficace.
• Segnaposto come unica etichetta:
  affidamento esclusivo sull’attributo segnaposto per l’etichetta di un input.
• Etichetta visiva non nel nome accessibile (errore WCAG 2.5.3):
  un componente interattivo ha un’etichetta di testo visibile, ma questo testo non è incluso nel suo nome accessibile, impedendo l’attivazione del controllo vocale.
• Etichettatura incoerente:
  elementi simili sulla piattaforma hanno etichette o nomi accessibili incoerenti, causando confusione.
• Titoli non descrittivi:
  i titoli sono vaghi e non descrivono adeguatamente il contenuto o lo scopo della sezione che introducono.

Etichette ridondanti:
le etichette sono eccessivamente verbose o ripetono le informazioni inutilmente.

Classificazione di gravità #

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

• Critico:
  la funzionalità principale è completamente inaccessibile a causa della mancanza di nomi accessibili sugli elementi interattivi critici (ad esempio, il pulsante “Invia” non ha un nome accessibile). Violazione diretta del criterio 4.1.2 del Livello A.
• Alto:
  impedisce significativamente agli utenti di comprendere lo scopo degli elementi interattivi, causando notevole frustrazione e inefficienza (ad esempio, molti link generici senza contesto, campi importanti dei moduli privi di etichette, pulsanti comuni che non soddisfano la norma 2.5.3). Violazione diretta dei criteri di Livello A o AA.
• Medio:
  causa un moderato disagio o confusione. Le etichette o gli scopi dei link potrebbero essere più chiari, ma l’utente può determinarne lo scopo in seguito. Lievi incongruenze nella denominazione.
• Basso:
  Problemi minori con l’etichettatura o la denominazione che causano un leggero inconveniente ma non ostacolano in modo significativo la funzionalità o la comprensione (ad esempio, aria-label leggermente prolissa ma comunque accurata, problemi di intestazione molto minori).

Nota finale #

Fornire un contesto descrittivo per gli elementi interattivi, attraverso etichette chiare, testi di collegamento significativi e nomi programmatici robusti, è fondamentale per creare una piattaforma digitale intuitiva e accessibile. Questo test manuale consente ai team di valutare rigorosamente questi aspetti critici, garantendo che tutti gli utenti, in particolare quelli che si affidano a tecnologie assistive, possano comprendere e utilizzare con sicurezza ogni componente interattivo. Dando priorità alla chiarezza e all’accuratezza programmatica, le piattaforme possono offrire un’esperienza utente davvero inclusiva ed efficiente.