Struttura semantica e integrità dei dati delle tabelle

Scopo #

Lo scopo principale di questo test di accessibilità manuale è valutare meticolosamente la struttura semantica e l’integrità dei dati di tabelle e contenuti tabellari all’interno di una piattaforma digitale. Questo test è progettato per essere eseguito dopo una scansione di accessibilità automatizzata e mira a scoprire problemi complessi relativi a relazioni programmatiche, sequenze significative e interazione con la tastiera che gli strumenti automatizzati spesso non rilevano. Garantire che le tabelle siano strutturate correttamente e trasmettano le relazioni a livello di programmazione è fondamentale per gli utenti che utilizzano screen reader o altre tecnologie assistive, consentendo loro di comprendere relazioni complesse tra i dati, navigare in modo efficiente e percepire le informazioni in un ordine logico. Senza un corretto markup semantico, le tabelle possono diventare incomprensibili o innavigabili per questi utenti.

Criteri WCAG coperti #

Questo test affronta specificamente i seguenti criteri di successo WCAG 2.2 relativi all’accessibilità delle tabelle:

• 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 le tabelle, ciò significa che la relazione tra le intestazioni di tabella (<th>) e le celle di dati associate (<td>) deve essere definita esplicitamente ed esposta alle tecnologie assistive. Implica inoltre l’utilizzo di elementi semantici appropriati come <table>, <caption>, <thead>, <tbody> e <tfoot>.

Rilevanza/Test:
Esamineremo meticolosamente il markup HTML di tutte le tabelle per verificare il corretto utilizzo di per le celle di intestazione, degli attributi di ambito (scope=”col”, scope=”row”) per le tabelle semplici e degli attributi id e headers per le tabelle complesse con più livelli di intestazione o strutture irregolari. Utilizzeremo screen reader per confermare che le intestazioni di colonna e di riga vengano annunciate correttamente durante la navigazione tra le celle della tabella.

• 1.3.2 Sequenza significativa – A

Questo criterio richiede che, quando la sequenza in cui il contenuto viene presentato ne influenza il significato, sia possibile determinare programmaticamente una sequenza di lettura corretta. Per le tabelle, questo è fondamentale. Se il layout visivo di una tabella (ad esempio, l’ordine delle colonne, l’unione delle celle) ne determina il significato, l’ordine HTML (DOM) sottostante deve corrispondere a questa sequenza logica, soprattutto quando il contenuto viene riadattato o linearizzato tramite tecnologie assistive.

Rilevanza/Test:
Confronteremo l’ordine di lettura visivo del contenuto della tabella con il suo ordine nel Document Object Model (DOM). Questo è particolarmente importante per le tabelle con celle unite, colonne ordinabili dinamicamente o layout reattivi in ​​cui il contenuto potrebbe essere riordinato. Utilizzeremo screen reader per scorrere la tabella in modo lineare e verificare che le informazioni siano presentate in una sequenza logica e comprensibile.

• 4.1.2 Nome, ruolo, valore – A

Per tutti i componenti dell’interfaccia utente (inclusi gli elementi interattivi all’interno delle tabelle), 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. Sebbene sia un criterio fondamentale per tutti i componenti dell’interfaccia utente, per le tabelle garantisce che i ruoli degli elementi della tabella (tabella, riga, cella, cella di intestazione) siano correttamente esposti. Per strutture personalizzate simili a tabelle, ciò implica l’utilizzo di ruoli ARIA appropriati (ad esempio, ruolo=”tabella”, ruolo=”riga”, ruolo=”intestazionecolonna”, ruolo=”intestazioneriga”, ruolo=”cella”, ruolo=”griglia”).

Rilevanza/Test:
Analizzeremo i ruoli semantici degli elementi della tabella, in particolare per le tabelle personalizzate o quelle che utilizzano elementi div per simulare i layout delle tabelle. Verificheremo che gli elementi interattivi all’interno delle celle della tabella (ad esempio, pulsanti, link) abbiano nome, ruolo e valore correttamente esposti alle tecnologie assistive.

Ambiente di prova #

Questo test richiede una combinazione di ispezione visiva, ispezione dettagliata del codice tramite strumenti per sviluppatori e un’ampia 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, alberi di accessibilità e proprietà calcolate).
• Metodi di input:
  • Mouse standard (per l’ispezione visiva)
  • Tastiera (per la navigazione negli strumenti di sviluppo e nei comandi dello screen reader).
• Tecnologie assistive: Lettore di schermo (ad esempio, NVDA, JAWS su Windows; VoiceOver su macOS) con comandi specifici per la navigazione nelle tabelle (ad esempio, comandi di navigazione nelle tabelle NVDA/JAWS come Ctrl + Alt + tasti freccia, VoiceOver Table Rotor).

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 (per l’ispezione visiva)
  • Tastiera fisica esterna (USB o Bluetooth) per la navigazione di base nella tabella, ove applicabile.
• Tecnologie assistive: lettori di schermo integrati (VoiceOver su iOS, TalkBack su Android) per verificare gli annunci e la navigazione del tavolo.
• Strumenti per sviluppatori: funzionalità 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 (per valutare come si ridispongono i layout delle tabelle e se vengono mantenute le relazioni semantiche).

Preparazione al test #

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

1. Identificare tutte le tabelle e il contenuto tabulare:
   Elencare sistematicamente ogni istanza di dati presentata in formato tabellare. Ciò include:
   • Elementi HTML <table> nativi (ad esempio, griglie di dati, tabelle finanziarie, pianificazioni).
   • Strutture simili a tabelle personalizzate utilizzando elementi div con CSS (ad esempio, componenti con stili che li rendono simili a tabelle).
   • Tabelle che hanno uno scopo di impaginazione (che in genere andrebbero evitate per motivi di accessibilità).
2. Comprendere la complessità e lo scopo della tabella:
   Per ogni tabella identificata, determinare:
   • Si tratta di una tabella semplice (una riga di intestazioni di colonna, una colonna di intestazioni di riga)?
   • Si tratta di una tabella complessa (più righe/colonne di intestazione, celle unite, struttura irregolare)?
   • Qual è lo scopo principale dei dati contenuti nella tabella?
   • Contiene elementi interattivi (pulsanti, link) all’interno delle celle?
3. Revisione delle specifiche/documentazione di progettazione:
   Se disponibile, consultare la documentazione relativa alla progettazione delle tabelle, alla presentazione dei dati e all’implementazione dell’accessibilità, in particolare per le griglie di dati complesse.
4. Familiarizzare con i criteri WCAG e i modelli di menu ARIA:
   Rileggere e assimilare i requisiti specifici delle WCAG 1.3.1, 1.3.2, 4.1.2 e 2.1.4. Comprendere l’uso corretto di:
   • tabella>, <didascalia>, <testa>, <corpo>, <piede>
   • <esimo>, <td>
   • ambito=”col”, ambito=”row”
   • attributi id sugli elementi <th> per gli attributi header sugli elementi <td>
   • Ruoli ARIA per strutture tabulari (role=”table”, role=”row”, role=”columnheader”, role=”rowheader”, role=”cell”, role=”grid”).
5. Configurare gli screen reader:
   Assicurarsi che il software di lettura dello schermo sia installato e configurato correttamente. Familiarizzare con i comandi avanzati di navigazione delle tabelle dello screen reader, poiché la lettura lineare standard non sarà sufficiente per le tabelle strutturate.
6. Preparare dati/scenari di prova:
   Preparare vari scenari per testare l’ordinamento, il filtraggio, la paginazione e gli aggiornamenti dinamici all’interno delle tabelle.

Processo di test passo dopo passo #

Eseguire i seguenti passaggi per ogni tabella o contenuto tabulare identificato, sia su desktop che su dispositivi mobili/tablet. Documentare meticolosamente le osservazioni.

PASSO 1 – Procedura generale per informazioni e relazioni (WCAG 1.3.1) e nome, ruolo, valore (WCAG 4.1.2) #

Ispezione visiva della struttura del tavolo: #

• Osserva visivamente la tabella. La struttura è chiara? Riesci a identificare facilmente le intestazioni di colonna e di riga?

Ispezione del codice del markup della tabella (Strumenti per sviluppatori): #

• Caso di test (<table> e <caption>):
  individua l’elemento <table>. Contiene un elemento <caption> che fornisce un riepilogo chiaro e conciso del contenuto della tabella?
• Caso di test (<thead>, <tbody>, <tfoot>):
  gli elementi <thead>, <tbody> e <tfoot> vengono utilizzati in modo appropriato per raggruppare logicamente le righe?
• Caso di test (utilizzo di <th> e <td>):
  all’interno di <thead> (e <tbody> per le intestazioni di riga), verificare che gli elementi <th> (intestazione di tabella) siano utilizzati solo per le celle di intestazione e gli elementi <td> (dati di tabella) siano utilizzati solo per le celle di dati. Verificare la presenza di un uso improprio comune in cui <td> viene formattato in modo da apparire come un’intestazione, o viceversa.
• Caso di test (tabelle semplici – attributo scope):
  per le tabelle semplici (un livello di intestazioni), verificare che gli elementi <th> abbiano scope=”col” per le intestazioni di colonna e scope=”row” per le intestazioni di riga.
• Caso di test (tabelle complesse – attributi id e intestazioni):
  per tabelle complesse con più livelli di intestazioni di colonna/riga o strutture irregolari:
  • Verificare che ogni <th> abbia un attributo id univoco.
  • Verificare che ogni <td> associato a tali intestazioni abbia un attributo headers che elenca gli ID di tutte le intestazioni rilevanti (separati da virgole).
• Caso di test (strutture simili a tabelle personalizzate – ruoli ARIA):
  per contenuti tabulari basati su div (non consigliato, ma se presente):
  • Verificare che il contenitore principale abbia role=”table” o role=”grid”.
  • Verificare che i contenitori di riga abbiano il ruolo=”row”.
  • Verificare che le celle di intestazione abbiano role=”columnheader” o role=”rowheader”.
  • Verificare che le celle dati abbiano role=”cell”.
  • Assicurarsi che aria-labelledby o aria-describedby siano utilizzati per associare le intestazioni alle celle se non viene utilizzata la semantica HTML nativa.
• Caso di test (elementi interattivi all’interno delle celle – WCAG 4.1.2):
  per tutti i pulsanti, i collegamenti o i controlli dei moduli all’interno delle celle della tabella, assicurarsi che abbiano nomi, ruoli e stati accessibili corretti (come da test generale degli elementi interattivi).

Verifica dello screen reader (relazioni): #

• Attiva uno screen reader.
• Vai alla tabella.
• Caso di prova:
  lo screen reader annuncia la didascalia/riepilogo della tabella (se presente)?
• Caso di prova:
  utilizzare i comandi di navigazione della tabella specifici dello screen reader (ad esempio, Ctrl + Alt + tasti freccia per NVDA/JAWS, Table Rotor per VoiceOver).
• Caso di prova:
  mentre ci si sposta tra le celle di dati, lo screen reader annuncia correttamente le intestazioni di riga e/o di colonna associate? (ad esempio, “Riga 2, Colonna 3: Quantità, 5”).
• Caso di prova:
  per le tabelle complesse, verificare che tutte le intestazioni rilevanti vengano annunciate mentre ci si sposta all’interno di una cella, anche se si tratta di intestazioni multilivello.
• Caso di prova:
  lo screen reader identifica correttamente righe, colonne e celle (ad esempio, “Tabella con 5 righe e 3 colonne”, “Riga 1 di 5”)?

PASSO 2 – Procedura generale per una sequenza significativa (WCAG 1.3.2) #

Confronta l’ordine visivo e DOM: #

• Osservare visivamente l’ordine logico di lettura delle celle all’interno di una riga e delle righe all’interno della tabella.
• Utilizzando gli strumenti per sviluppatori, esaminare l’ordine DOM degli elementi <tr> e <td>/<th>.
• Caso di prova (ruolo):
  l’ordine DOM delle celle all’interno di una riga corrisponde all’ordine visivo da sinistra a destra (o da destra a sinistra per le lingue RTL)?
• Caso di prova (nome accessibile):
  l’ordine delle righe nel DOM corrisponde all’ordine visivo dall’alto verso il basso?
• Caso di test (celle unite):
  per le tabelle con rowspan o colspan, assicurarsi che l’ordine DOM consenta comunque una sequenza di lettura logica quando linearizzata.
• Caso di test (ordinamento/filtraggio dinamico):
  se le colonne di una tabella possono essere ordinate o le righe possono essere filtrate, verificare che quando l’ordine visivo cambia, l’ordine DOM sottostante (o l’ordine dell’albero di accessibilità programmatica) venga aggiornato per riflettere la nuova sequenza logica.

Verifica dello screen reader (lettura lineare): #

• Attiva uno screen reader.
• Passare alla tabella e provare a leggerne il contenuto in modo lineare (ad esempio, premendo ripetutamente il tasto Freccia giù, anziché utilizzare i comandi di navigazione della tabella).
• Caso di prova:
  l’ordine di lettura lineare dello screen reader ha senso e scorre logicamente, anche per tabelle visivamente complesse?

PASSO 3 – Procedura generale per le scorciatoie da tastiera dei caratteri (WCAG 2.1.4 – per scorciatoie specifiche per tabella) #

Identificare le scorciatoie da tastiera dei caratteri specifici della tabella: #

• Consultare la documentazione della piattaforma o cercare visivamente eventuali istruzioni sui tasti di scelta rapida con un singolo carattere che funzionano all’interno delle tabelle (ad esempio, ‘S’ per ordinare una colonna, ‘E’ per modificare una riga).

Contrasto dell’indicatore di messa a fuoco (WCAG 1.4.11 – implicito nella percepibilità): #

• Per elementi con stili di messa a fuoco personalizzati o elementi che appaiono su sfondi diversi:
• Caso di prova:
  l’indicatore di messa a fuoco ha un rapporto di contrasto di almeno 3:1 rispetto allo stato predefinito dell’elemento e rispetto ai colori di sfondo adiacenti?

Opzione Verifica controllo/Rimappatura: #

• Se esiste una scorciatoia del genere:
• Caso di prova:
  è disponibile un meccanismo per disattivare la scorciatoia?
• Caso di prova:
  esiste un meccanismo per rimappare la scorciatoia in modo da includere tasti non carattere (ad esempio, Ctrl + S invece di solo ‘S’)?
• Caso di test:
  la scorciatoia è attiva solo quando la tabella specifica o un componente al suo interno ha il focus sulla tastiera (non a livello di sito)? Questo è il metodo preferito se non è disponibile alcuna opzione di disattivazione/rimappatura.

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:

• Intestazioni mancanti o errate (errore WCAG 1.3.1):
  • Gli elementi <th> non vengono utilizzati per le intestazioni visive delle tabelle.
  • Gli elementi <td> vengono utilizzati in modo errato al posto di <th>.
  • Attributi di ambito mancanti su <th> nelle tabelle semplici.
  • Attributi id/header mancanti o errati nelle tabelle complesse.
  • Lo screen reader non annuncia le intestazioni di colonna/riga durante la navigazione tra le celle.
• Didascalia della tabella mancante (errore WCAG 1.3.1):
  un elemento <caption> è assente per una tabella dati, rimuovendone il riepilogo.
• Tabella utilizzata per il layout (cattiva pratica WCAG 1.3.1):
  un elemento <table> viene utilizzato esclusivamente per il posizionamento visivo del contenuto, non per la presentazione di dati tabellari. Ciò crea inutili complessità per gli utenti di screen reader.
• Ordine di lettura illogico (errore WCAG 1.3.2):
  l’ordine DOM delle celle o delle righe della tabella non corrisponde all’ordine di lettura visiva, causando confusione per gli utenti di lettori di schermo lineari.
• Le celle unite interrompono la logica (errore WCAG 1.3.2):
  rowspan o colspan vengono utilizzati in un modo che crea un ordine di lettura illogico o interrompe l’associazione dell’intestazione per i lettori dello schermo.
• Markup di tabella personalizzato inaccessibile (errore WCAG 4.1.2):
  i layout simili a tabelle creati con div non dispongono dei ruoli ARIA appropriati (role=”table”, role=”row”, role=”columnheader”, ecc.), rendendoli incomprensibili per gli screen reader.
• Elementi interattivi nelle tabelle privi di semantica (errore WCAG 4.1.2):
  i pulsanti, i collegamenti o i controlli dei moduli all’interno delle celle della tabella non hanno nomi, ruoli o stati accessibili corretti.
• Contenuto della tabella dinamica non accessibile:
  l’ordinamento, il filtraggio o la paginazione riordinano visivamente il contenuto, ma l’albero di accessibilità o gli annunci dello screen reader non riflettono il nuovo ordine logico.
• Problemi con i tasti di scelta rapida dei caratteri (errore WCAG 2.1.4):
  i tasti di scelta rapida dei singoli caratteri sono attivi globalmente all’interno di una tabella e interferiscono con i comandi dello screen reader o con l’input di testo, senza un’opzione per disattivarli/riassegnarli.
• Nessuna associazione programmatica:
  intestazioni e celle sono associate visivamente, ma non a livello di programmazione (ad esempio, utilizzando solo CSS per lo stile delle intestazioni, ma non <th> o scope/header).

Classificazione di gravità #

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

• Critico:
  impedisce agli utenti di comprendere i dati principali o le relazioni all’interno di una tabella, oppure rende una tabella completamente innavigabile per gli utenti di screen reader (ad esempio, mancano tutte le intestazioni, le tabelle vengono utilizzate esclusivamente per il layout). Violazione diretta del criterio 1.3.1 di Livello A.
• Alto:
  impedisce in modo significativo agli utenti di comprendere o navigare in modo efficiente in tabelle complesse (ad esempio, ambito o intestazioni errati per tabelle complesse, discrepanze importanti tra l’ordine visivo e quello DOM, tabelle personalizzate essenziali prive di ruoli ARIA). Violazione diretta del Livello A.
• Medio:
  causa un moderato disagio o confusione (ad esempio, didascalia della tabella mancante, piccole incongruenze nella marcatura dell’intestazione per una tabella semplice, piccoli problemi con gli annunci dello screen reader per gli aggiornamenti dinamici all’interno delle tabelle).
• Basso:
  Problemi minori che causano lievi inconvenienti ma non ostacolano in modo significativo la comprensione o la funzionalità (ad esempio, una leggera ridondanza nel testo dell’intestazione).

Nota finale #

La struttura semantica e l’integrità dei dati delle tabelle sono fondamentali per garantire che informazioni complesse siano accessibili e comprensibili a tutti gli utenti, in particolare a coloro che si affidano a tecnologie assistive. Questo test manuale fornisce un quadro rigoroso per andare oltre i controlli automatici e scoprire le sottili problematiche strutturali e relazionali che possono rendere inutilizzabile il contenuto tabulare. Affrontando meticolosamente queste problematiche, i team possono garantire che i loro dati siano presentati in modo realmente inclusivo e accessibile.