International Web Association Italia
Traduzione – autorizzata dall’autore – dell’articolo “Fieldsets, Legends and Screen Readers” di Steve Faulkner del 22 novembre 2007
Il raggruppamento e l’etichettatura di controlli correlati all’interno di un form è un aspetto importante nel fornire informazioni di carattere semantico, così che gli utenti possano ben comprendere il form e compilarlo con efficacia.
Eventuali differenze nella qualità e nel supporto di programmi utente possono impedire ad alcuni utenti di beneficiare di queste informazioni. Questo non deve scoraggiare gli sviluppatori, visto che i benefici nell’utilizzare questi elementi sono ben maggiori dei lati negativi.
Ma appare chiaro che alcuni produttori di tecnologie assistive devono migliorare l’implementazione delle funzionalità legate all’HTML in grado di aumentare l’accessibilità, così da garantire ai loro utenti il massimo dei vantaggi.
Usare gli elementi fieldset e legend
La specifica dell’HTML 4 fornisce un metodo per raggruppare ed etichettare i controlli di un form per mezzo degli elementi fieldset e legend:
L’elemento fieldset permette gli autori di raggruppare controlli ed etichette nematicamente correlate. Raggruppare i controlli facilita agli utenti la comprensione del loro scopo e nel contempo agevola la navigazione con il tasto Tab da parte dei programmi utente visuali, ma anche la navigazione a voce per i programmi utente orientati alla voce. L’utilizzo opportuno di questi elementi rende i documenti più accessibili.
Il tag legend permette agli autori di assegnare una didascalia ad un fieldset. L’elemento legend migliora l’accessibilità quando il fieldset è presentato in maniera non visuale.
Ogni volta che serve un’etichetta per fornire informazioni su un insieme di controlli, sarà bene considerare l’uso dei tag legend e fieldset. Essi possono servire a raggruppare controlli logicamente correlati in un form, come le informazioni sull’indirizzo, data di nascita ed insiemi di radio button o caselle di scelta.
Nota: è obbligatorio usare fieldset e legend congiuntamente. Un fieldset non può essere usato senza un legend, e viceversa.
Codice d’esempio:
<fieldset>
<legend>filter by</legend>
<input type=”radio” name=”filter” id=”a”>
<label for=”a”>television</label>
<input type=”radio” name=”filter” id=”b”>
<label for=”b”>radio</label>
<input type=”radio” name=”filter” id=”c”>
<label for=”c”>cinema</label>
</fieldset>
Presentazione agli utenti
Browser visuali
La visualizzazione predefinita degli elementi fieldset e legend è abbastanza uniforme sui principali browser visuali. Fieldset è visualizzato con un bordo continuo ed il testo di legend è posizionato sul bordo in alto a sinistra. Questo fornisce una chiara indicazione visiva dei controlli contenuti nel gruppi e della didascalia (legend) che si riferisce ai controlli raggruppati.
Visualizzazione di default in Internet Explorer, Firefox and Opera
Screen Reader
Per gli utenti in grado di vedere, l’associazione può essere rappresentata dalla posizione di legend e dall’inclusione dei controlli correlati all’interno di un rettangolo. Ma come possono i programmi utente non visuali convogliare le associazioni strutturali fornite dai tag legend e fieldset? La relazione più importante è quella del testo di legend rispetto ai singoli controlli contenuti nel fieldset, visto che legend serve proprio a descrivere il contesto dei dati o delle scelte che l’utente deve effettuare. Visto che il contenuto viene “consumato” linearmente dagli screen reader, l’associazione visuale – apparentemente semplice – non è espressa molto facilmente o chiaramente.
Le UAAG 1.0 (User Agent Accessibility Guidelines) forniscono quest’avvertimento riguardante l’implementazione:
HTML 4 specifica l’elemento FIELDSET, che permette di raggruppare elementi ed etichette logicamente correlate. L’elemento LEGEND assegna una didascalia ad un FIELDSET. Per esempio, l’elemento LEGEND potrebbe identificare un FIELDSET di radio button con il testo “Velocità di connessione”. Ciascuno dei pulsati potrebbe avere un elemento LABEL corrispondente ad una certa velocità, Quando esso riceve il focus, identifica il radio button come “Velocità di connessione: Radio button X di Y: 28.8 kbps”, dove “Y” rappresenta il numero totale di radio button presenti nel raggruppamento, e “28.8kbps” è l’informazione contenuta nel LABEL.
Tenendo presente questo avvertimento implementativo, abbiamo provato due dei più importanti screen readers su un fieldset d’esempio contenente 3 radio button etichettati come “television, radio, cinema”, con un tag legend avente come contenuto “filter by”. Abbiamo scoperto che il risultato è variabile a seconda del software, della modalità di funzionamento e dei tasti di navigazione utilizzati.
JAWS
Col cursore PC virtuale in modalità Forms, legend è pronunciato quando ogni singolo controllo contenuto nel filedset riceve il focus.
Cursore PC virtuale, modalità “browse”
Se l’utente si sposta attraverso il contenuto utilizzando il comando “Pronuncia tutto” (ins + freccia giù) o “Pronuncia il prossimo rigo” (freccia giù), legend viene pronunciato non appena viene inizialmente incontrato, ma non viene fornita alcuna indicazione di associazione ai controlli correlati:
filter by radio button televsion, radio button radio, radio button cinema
Se per spostarsi tra i radio button presenti nel fieldset si utilizza il comando “Spostati al successivo campo del form” (F) (disponibile solo in modalità “browse”), il risultato è diverso:
filter by radio button television, filter by radio button radio, filter by radio button cinema
Modalità Forms
Il risultato è analogo a quello appena riscontrato durante l’uso del comando “Spostati al successivo campo del form”, e quindi il testo di legend viene pronunciato prima di ciascuna label presente nel fieldset.
Window Eyes
Adottando le impostazioni predefinite, fieldset e legend non vengono pronunciate. Affinchè l’utente sia al corrente della presenza di un fieldset, l’utente deve preventivamente modificare le impostazioni di pronuncia di fieldset di Windows Eyes: Insert Beginning / End Message (Fieldsets); in questo caso l’utente riceverà una notifica sia all’inizio che alla fine di un elemento fielsdet.
Modalità browse – opzione “announce fieldset” attivata
Quando è attivata questa opzione, se l’utente si sposta con la freccia in basso, l’inizio ed il termine del fieldset viene notificato, e questo vale anche per il testo di legend.
filter by fieldset start radio button television, radio button radio, radio button cinema filter by fieldset end
L’utente può anche navigare utilizzando i comandi “Prossimo fieldset” (E) e “Precedente Fieldset” (maiuscolo+E), nel qual caso la fine di un fieldset non viene pronunciato. Se vengono utilizzati “Controllo successivo” (C), “Controllo precedente” (maiuscolo+C) o il tasto TAB, fieldset e legend non vengono pronunciati.
Usare Firefox
Se si utilizza Firefox, Windows Eyes non riconosce la presenza degli elementi filedset o legend; quindi, per esempio, quando si usa “Prossimo fieldset” (E) e “Precedente Fieldset” (maiuscolo+E), nessun fieldset viene pronunciato.
Modalità browse disattivata (modalità forms)
Quando l’utente non è in modalità browse (che deve essere disattivata per poter interagire con le caselle di editazione, le text areas e gli elenchi a discesa), si trova a dover navigare nel form con il tasto TAB e nessuna informazione legata a fieldset o legend viene notificata.
Note sui test:
- Per il test sono stati utilizzati JAWS 8 e Window Eyes 5.5. La pagina di test è stata visualizzata in Internet Explorer 7 e Firefox 2 su Windows XP.
- Gli esempi dell’output degli screen reader sono stati editati per includere solo le notifiche pertinenti.
Conclusioni
Gli elementi legend e fieldset rappresentano una utile porzione del set di strumenti a disposizione degli sviluppatori Web per creare forms maggiormente fruibili da parte di utenti con disabilità.
Il supporto in Windows Eyes è molto lontano dall’avvertimento contenuto nelle UAAG 1.0 e perciò i suoi utenti non potranno giovarsi di tutti i benefici provenienti dalle informazioni aggiuntive fornite da questi elementi. Infatti il testo di legend non verrà pronunciato se prima non viene attivata un’apposita opzione; ma anche quando quest’ultima viene attivata, gli utenti di Windows Eyes non riceveranno quest’importante informazione durante l’inserimento di dati nei campi.
Inoltre, se si utilizza Windows Eyes con Firefox il contenuto degli elementi legend e fieldset verrà del tutto ignorato.
La situazione relativa agli utenti di Jaws è di gran lunga migliore. L’implementazione di Jaws è coerente con le UAAG 1.0; il raggruppamento dei controlli con fieldset non viene esplicitamente pronunciato (mentre lo è con Windows Eyes), ma la notifica del fieldset non fa parte della raccomandazione contenuta nelle UAAG, e potrebbe rivelarsi di limitata utilità, se non addirittura fonte di disturbo per gli utenti, il che potrebbe spiegare come mai non è abilitata per default in Windows Eyes.
E’ importante l’associazione del testo di legend ai controlli presenti in un fieldset, e ciò è opportunamente implementato per mezzo della pronuncia di legend insieme all’etichetta testuale di un controllo. Questo comportamento si manifesta quando l’utente naviga o interagisce con i campi di un form all’interno dei browser supportati.
Vista la natura della raccomandazione contenuta nelle UAAG 1.0 e della sua implementazione in Jaws (testo della legenda letto prima del testo dell’etichetta di ogni controllo), gli sviluppatori dovrebbero ben ponderare la lunghezza del testo di legend, dato che legend particolarmente lunghi tendono a complicare l’interazione con i form.
Un altro potenziale problema è rappresentato dal comportamento di Jaws in presenza di intestazioni all’interno di un fieldset; in questo caso Jaws userà il testo nelle intestazioni al posto del testo di legend, chissà se si tratta di una bizzarria o proprio di un bug. In ogni caso questo può portare a conseguenze inattese e problematiche, e deve certamente essere corretto in Jaws. Nel frattempo, meglio minimizzare l’utilizzo delle intestazioni all’interno di fieldset.
I tag fieldset e legend risultano ben supportati da molti programmi utente. Se da una parte è utile conoscere alcune delle stranezze e dei problemi che incontrano alcuni di essi, il limitato supporto in software come Windows Eyes non deve far sì che gli sviluppatori evitino di usare questi elementi o che gli esperti di accessibilità smettano di raccomandarne l’utilizzo.
La loro adozione può rendere più semplice la compilazione di form da parte di un gran numero di utenti con disabilità.
Allo scopo di migliorare l’accessibilità per tutti gli utenti disabili, gli standard del Web devono essere adottati e rispettati, così che gli sviluppatori possano creare codice accessibile con facilità, ed è compito specifico dei produttori di tecnologie assistive far questo ottimizzando le loro implementazioni.