Requisiti 11, 12, 13, 14

Requisito 11

Enunciato: Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati.

Riferimenti WCAG 1.0: 3.3, 6.1

Riferimenti Section 508: 1194.22 (d)

Motivazione

La separazione del contenuto dalla presentazione è uno dei punti cardine per l’accessibilità. Ciò significa consentire a qualsiasi utente di poter fruire dei contenuti ed allo stesso tempo di gestirne la rappresentazione in diverse modalità. Garantire la fruibilità della pagina disabilitando i fogli di stile significa sviluppare i contenuti e l’impaginazione (layout) in modo che un utente che utilizza tecnologie assistive, e che quindi leggono il codice della pagina (non la sua rappresentazione grafica), possa comunque accedere ai contenuti in un ordine di lettura comprensibile.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web definiti graficamente (impaginati) tramite fogli di stile. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’effettiva fruibilità del contenuto, ad esempio disabilitando i fogli di stile.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 3.3 (Priorità 2). Usare i fogli di stile per controllare l’impaginazione e la presentazione

L’utilizzo dei fogli di stile (CSS) è essenziale per lo sviluppo dei siti Web, in quanto consente di creare siti professionali e maggiormente accessibili: non è più necessario utilizzare i seguenti elementi:

<center>, <font>, <basefont>, <b>, <i>, <tt>, <big>, <small>, <strike>, <s>, <u>

Con i fogli di stile è possibile ottenere i medesimi risultati in modo più efficiente. È importante ricordare che gli elementi di tipo <hn> non vanno utilizzati per ottenere effetti grafici di ridimensionamento del carattere, che potranno essere ottenuti creando delle classi dedicate nel foglio di stile.

.testogrande {
font-family: Georgia, "Times New Roman", Times, serif;
font-size: 1.3em;
color: #000;
background-color: #fff;
border: 1px solid #000;
padding: 0px;
}

L’allineamento, i margini e il posizionamento degli elementi nella presentazione di una pagina vanno gestiti tramite fogli di stile: lo sviluppatore deve garantire la possibilità di lettura dei contenuti della pagina anche in mancanza dei fogli di stile stessi, al fine di garantirne l’accesso e la fruibilità agli utenti che utilizzano lettori solo testo o vocali.

Allineamento: utilizzando gli attributi text-indent, text-align, word-spacing, font-stretch (quest’ultimo eliminato in CSS 2.1) è possibile formattare il testo aumentando/diminuendo gli spazi, definendo l’allineamento, ecc. Con l’attributo text-align: center sarà possibile eliminare l’elemento <center>, oramai obsoleto.

Margini: margin, margin-top, margin-right, margin-bottom, margin-left consentono di definire i margini dell’oggetto (<div>, …) all’interno del quale verranno forniti i contenuti.

Posizionamento: float, position, top, right, bottom, left consentono di posizionare l’oggetto nella pagina.

Si consiglia di evitare l’uso degli stili creati con l’attributo HTML “style”: dalla versione 1.1 di XHTML tale elemento è stato deprecato per garantire una maggiore separazione di contenuto e presentazione.

Punto di controllo 6.1 (Priorità 1). Organizzare i documenti in modo che possano essere letti anche in assenza dei fogli di stile

È necessario inoltre sviluppare i siti in modo che possano essere fruiti anche se il browser utilizzato dall’utente non supporta i fogli di stile: la finalità dello sviluppatore deve essere quella di garantire la fruibilità del sito e, di conseguenza, là e l’usabilità dei suoi contenuti. Un esempio di contenuti con una particolare formattazione generata da foglio di stile è il seguente.

Figura 4.5 Esempio d’uso dei fogli di stile.

La frase “The quick brown fox jumped over the lazy dogs” viene spesso utilizzata in questo tipo di esempi poiché, contenendo tutte le lettere dell’alfabeto, consente di valutare la resa della rappresentazione dei singoli caratteri. Il testo nella figura è stato generato e posizionato utilizzando i fogli di stile, definendo quattro elementi div.

<div class="parte1">The quick</div>
<div class="parte2">brown fox</div>
<div class="parte3">jumped over</div>
<div class="parte4">the lazy dogs.</div>

Per ottenere l’effetto grafico desiderato, per ogni blocco di testo è stata impostata una particolare combinazione di caratteri e colori.

.parte1 /* The quick */ {
color: red;
font-size: 1.0em;
padding-left: 0;
margin-top: 40px;
font-family: copperplate gothic bold, fantasy, sans-serif }

.parte2 /* brown fox */ {
color: brown;
font-size: 0.7em;
padding-left: 100px;
margin-top: 30px;
font-family: times new roman, desdemona, serif }

.parte3 /* jumped over */ {
color: purple;
font-size: 0.8em;
padding-left: 200px;
margin-top: -60px;
font-family: desdemona, times new roman, serif }

.parte4 /* the lazy dogs */ {
color: blue; size: 2.4em;
padding-left: 350px;
margin-top: -80px;
margin-bottom: 100px;
font-family: fantasy, copperplate gothic bold, sans-serif }

Se utilizziamo un browser che consente di disattivare i fogli di stile, come Opera, il risultato sarà comunque un testo chiaramente leggibile e fruibile:

The quick
brown fox
jumped over
the lazy dogs.

Modificando il posizionamento dei testi, per un utente che utilizza un browser in grado di interpretare i CSS il risultato non sarebbe cambiato, mentre a un utente con tale funzionalità disabilitata verrebbe mostrato un testo senza senso: il contenuto della pagina non soddisferebbe questo requisito.

Per la stessa motivazione, quando si sviluppano layout tramite elementi <div> è necessario, disabilitando i fogli di stile, verificare che tutti i contenuti siano comprensibili secondo il normale ordine di lettura dei contenuti della pagina.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare l’uso di elementi e/o attributi deprecati a favore dei fogli di stile;
  • verificare, disabilitando i fogli di stile, che i contenuti siano ancora fruibili e comprensibili secondo il loro ordine di presentazione.

Tramite la Barra dell’accessibilità è possibile utilizzare:

CSS

Attiva/Disattiva i CSS: Attiva/disattiva i fogli di stile esterni (Punti di controllo 3.3 e 6.1).

Disattiva i CSS inline: Rimuove l’attributo style (se presente) da tutti gli elementi della pagina (Punti di controllo 3.3 e 6.1).

Elementi e attributi deprecati (Nuova finestra). Visualizza gli elementi e gli attributi deprecati. (Punto di controllo 3.3).

Struttura

Bordi delle tabelle. Evidenzia tutti i bordi delle tabelle/celle sulla pagina corrente (Punto di controllo 3.3).

Ordine di tabulazione. Visualizza per ogni elemento attivo il numero corrispondente al suo ordine di tabulazione, al fine di poter consentire all’esperto di verificare la correttezza dell’ordine di navigazione anche senza disabilitare i fogli di stile (Punto di controllo 6.1).

Visualizza i Div. Mostra l’ordine (numerico) di tabulazione ed i bordi degli elementi <div> presenti sulla pagina corrente (Punto di controllo 6.1).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 12

Enunciato: La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area di visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri.

Riferimenti WCAG 1.0: 3.4

Riferimenti Section 508: non presente

Motivazione

Questo requisito è particolarmente sentito dagli utenti ipovedenti, in quanto se non viene soddisfatto esistono grosse possibilità che un utente con tale disabilità visiva non possa accedere ai contenuti delle pagine. Considerando che in tale categoria di utenti ricadono anche le persone anziane, non rispettare questo punto di controllo provoca l’esclusione di una grossa fetta di utenza.

Il requisito inoltre garantisce ad utenti che utilizzano configurazioni particolari di poter accedere al contenuto che, se sviluppato secondo i criteri che andremo ad analizzare, si adatterà alla periferica di output.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web indipendentemente dalla dimensione della finestra di visualizzazione e/o dalla dimensione dei caratteri. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’effettiva fruibilità del contenuto, ad esempio visualizzando la pagina in diverse risoluzioni. Il requisito non richiede comunque di praticare l’impossibile ma di garantire una certa visibilità dei contenuti anche a risoluzioni video 800 x 600 a caratteri molto grandi considerando che tale risoluzione è ormai un’impostazione minima consigliata per ogni configurazione hardware.

Relativamente a fogli di stile per i diversi media se questi vengono forniti devono anch’essi rispettare il requisito: un foglio di stile per la stampa dovrà adattarsi alle impostazioni del browser dell’utente e consentire la stampa dei contenuti mentre un foglio di stile per i dispositivi handheld (palmari) dovrà consentirne la visualizzazione da parte dei browser che supportano tale tipologia del foglio di stile.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 3.4 (Priorità 2). Usare unità relative anziché assolute nei valori degli attributi del linguaggio e per i valori delle proprietà del foglio di stile

Come affermato nel requisito precedente, tutte le impostazioni relative alla rappresentazione devono essere definite all’interno dei fogli di stile. L’utilizzo di un’unità di misura di tipo assoluto, come pica (pc), punti (pt), inches (in), centimetri (cm), e millimetri (mm) ha come effetto il blocco delle dimensioni di un elemento a una dimensione fissa: un testo per noi di dimensioni “normali” potrebbe essere davvero troppo piccolo per un utente ipovedente o per chi utilizza monitor a risoluzioni elevate. Se invece le dimensioni del testo vengono definite con unità misura di tipo relativo, come .em o in percentuale (%), i visitatori del sito potranno facilmente adattare il carattere alle proprie esigenze. Ciò comporta da parte dello sviluppatore una fase di test delle pagine simulando tali visualizzazioni e controllando che anche a risoluzioni medio-basse (800×600) con caratteri molto grandi il proprio sito sia fruibile senza problemi.

Un caso particolare è relativo ai pixel. Nei documenti ufficiali W3C relativi alla raccomandazione CSS 2.0 è definito che la misura in pixel (.px) è relativa alla periferica di presentazione: un pixel di una slide in uno schermo del computer portatile di un docente avrà sicuramente dimensione differente di un pixel dello stesso schermo proiettato su di un pannello largo 3 metri.

Per questa relazione alla periferica (la dizione corretta è “relativo al dispositivo di visualizzazione”), in Microsoft Internet Explorer nella funzionalità di ingrandimento carattere gli elementi di testo dimensionati in pixel non vengono ridimensionati, con gravi problemi di accessibilità per gli ipovedenti (o semplicemente, per i miopi).

In ogni caso, al fine di rispettare la metodologia di verifica dei requisiti non è possibile utilizzare il pixel come unità di misura per i caratteri, in quantola metodologia all’allegato A, lettera C) al punto 5 dichiara:

5. I contenuti della pagina siano fruibili in caso di utilizzo delle funzioni previste dai browser per definire la grandezza dei caratteri;

Non è inoltre possibile utilizzare script o altre tecniche per ridimensionare “al volo” i pixel, considerando che sempre la metodologia alla lettera C) al punto 7 dichiara:

7. i contenuti e le funzionalità della pagina siano ancora fruibili, anche in modalità diverse, in caso di disattivazione di fogli di stile, script e applet ed altri oggetti di programmazione;

Per garantire l’accessibilità sarà necessario non utilizzare i pixel per assegnare dimensioni ai testi di una pagina, utilizzando invece le dimensioni espresse in “em”. Per lo stesso motivo, è consigliabile utilizzare – ove possibile – le dimensioni in percentuale per tutti gli attributi di impostazione di larghezza ed altezza degli elementi presentazionali.

Nelle tecniche di applicazione dei CSS per le WCAG 2.0 è chiarito definitivamente il problema <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS/#syntax-data-types>:

Utilizzare “em” o dimensioni percentuali per le proprietà che necessitano di essere modificate. Tali dimensioni sono “font-size” e “line-height”.

Utilizzare “px” per le proprietà che non necessitano di essere modificate. Tali dimensioni sono “height” e “width” per le immagini raster, “margin” e “border”.

Relativamente ai layout a dimensioni fisse i valori per padding, margin, top, left, width e height possono essere espressi in px, ma – al fine di rispettare il requisito – non devono provocare sovrapposizioni tra i contenuti.

Di seguito un esempio di come preparare un foglio di stile (CSS) che consenta l’utilizzo di caratteri con dimensioni di tipo relativo, utilizzando le dimensioni di tipo em, ed elementi con dimensioni in percentuale.

body {
font-family: Georgia, "Times New Roman", Times, serif;
color: #000;
background-color: #369;
font-size: .9em;
}
a {
color: #036;
text-decoration: underline;
background-color: transparent;
}
.codice {
font-family: "CoURIer New", CoURIer, serif;
background-color: transparent;
color: #666;
font-size: 0.9em;
}
div {
color: #036;
width: 25%;
background-color: transparent;
}

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare la presenza di dimensioni assolute e/o dimensioni in pixel all’interno del foglio di stile o degli stili in linea;
  • verificare che al ridimensionamento dei caratteri il contenuto rimanga leggibile e comprensibile;
  • verificare che al ridimensionamento della finestra il contenuto rimanga leggibile e comprensibile.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Ridimensiona

800 x 600. Ridimensiona l’attuale finestra del browser ad una larghezza di 800 pixel e ad un’altezza di 600 pixel.

1024 x 768. Ridimensiona l’attuale finestra del browser ad una larghezza di 1024 pixel e ad un’altezza di 768 pixel.

Misure personalizzate. Ridimensiona la finestra corrente del browser ad un’altezza/larghezza definita dall’utente.

Misure personalizzate. Controllo della grandezza dello schermo Collegamento ad un test on-line per la misura dello schermo e presenta delle informazioni sulle varie configurazioni per un vasto insieme di browser/schermi e risoluzioni/piattaforme.

CSS

Visualizza gli stili applicati (Nuova finestra). Visualizza gli stili (in una nuova finestra) associate col contenuto posizionato al di sotto del puntatore del mouse. L’esperto potrà quindi verificare la presenza di caratteri o di elementi in cui non sono state utilizzate dimensioni di tipo relativo e/o dimensioni in pixel (Punto di controllo 3.4).

Visualizza il foglio di stile (Nuova finestra). Visualizza il contenuto dei fogli di stile richiamati dalla pagina corrente (in una nuova finestra). L’esperto potrà quindi verificare la presenza di caratteri o di elementi in cui non sono state utilizzate dimensioni di tipo relativo e/o dimensioni in pixel (Punto di controllo 3.4).

Strumenti

Juicy Studio Tools / CSS Accessibility Analyzer (Nuova finestra). Invia al sistema di valutazione di JuicyStudio il foglio di stile della pagina corrente. CSS Accessibility Analyzer verificherà la conformità del foglio di stile (segnalando errori o avvisi) nonché la presenza del contrasto dei colori (Requisito 6) e segnalando l’eventuale presenza di caratteri o elementi in dimensioni assolute oppure l’uso di dimensioni tramite pixel (Punto di controllo 3.4).

L’esperto potrà inoltre utilizzare le funzionalità di ingrandimento caratteri previste dai diversi browser con cui effettua il test come indicato al Punto 2 Paragrafo c) della metodologia per la verifica tecnica. Un ottimo strumento di supporto è senz’altro browsercam.com, che consente di acquisire delle immagini per una determinata pagina web nonché di poter utilizzare una connessione remota ad un personal computer in configurazioni non disponibili all’utente (per esempio, un utente dotato di PC con Microsoft Windows potrà trovare utile testare la pagina con MAC, con Linux ed i relativi browser).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 13

Enunciato: In caso di utilizzo di tabelle a scopo di impaginazione, garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato e utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico definito nella specifica del linguaggio a marcatori utilizzato.

Riferimenti WCAG 1.0: 5.3, 5.4

Riferimenti Section 508: non presente

Motivazione

È bene ricordare che gli sviluppatori dovrebbero utilizzare i fogli di stile (CSS) per lo sviluppo dell’impaginazione (layout) di una pagina Web. Ancora oggi le tabelle vengono utilizzate spesso per impaginazione anziché per contenere dati. Per tale motivo nelle linee guida per l’accessibilità dei contenuti del W3C e quindi all’interno di questo requisito si richiede agli sviluppatori – nel caso utilizzassero ancora le tabelle a scopo di impaginazione – di non usare elementi ed attributi dedicati alle tabelle dati.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti delle tabelle di impaginazione contenute in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di elementi ed attributi in modo conforme alle specifiche e soprattutto la linearizzazione – quindi la comprensibilità – dei contenuti presentati tramite le tabelle di impaginazione.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 5.3 (Priorità 2). Non usare le TABELLE PER IMPAGINAZIONE a meno che la tabella non sia comprensibile se linearizzata

Se è necessario utilizzare tabelle di impaginazione, il contenuto della tabella deve poter essere linearizzato, ossia il contenuto delle celle verrà interpretato come una serie di paragrafi successivi. Per questo motivo, è necessario che la lettura dei contenuti (che avviene riga per riga, a seconda della direzione del testo) conservi un senso.

Utilizzando le tabelle di impaginazione si possono riscontrare dei problemi con le tecnologie assistive: utilizzando una tabella come quella di seguito rappresentata allo scopo di dividere la pagina in due colonne, i programmi di lettura dello schermo leggeranno cella dopo cella, ovvero nel nostro esempio per primo il contenuto della prima cella della prima colonna, il contenuto della prima cella della seconda colonna, quindi la seconda cella della prima colonna e così di seguito.

<table summary="Indicazioni sulla struttura della tabella">
<tr>
<td>Riga 1 Colonna 1</td>
<td>Riga 1 Colonna 2</td>
</tr>
<tr>
<td>Riga 2 Colonna 1</td>
<td>Riga 2 Colonna 2</td>
</tr>
</table>

Nella verifica del requisito vedremo come siano disponibili degli strumenti per verificare la linearizzazione delle tabelle.

Punto di controllo 5.4 (Priorità 2). Se si utilizza una TABELLA DI IMPAGINAZIONE non utilizzare alcun marcatore di struttura a scopo di formattazione

Se si utilizzano le tabelle per sviluppare un layout, è necessario ricordare che gli elementi <th> non devono essere utilizzati a scopo di formattazione. Solitamente l’elemento <th> (table header) viene visualizzato in grassetto e centrato nella cella: se la cella non rappresenta una intestazione di riga o colonna, la formattazione deve avvenire tramite foglio di stile. Pertanto per una tabella di impaginazione non va utilizzato alcun elemento strutturale (<th>, <thead>, <tfoot>, <tbody>, <colgroup>, <col>) in quanto ciò confonderebbe le tecnologie assistive che hanno lo scopo di linearizzarne e leggerne i contenuti.

Per esempio, l’uso di:

<th>Testo centrato e grassetto</th>

è scorretto, mentre è necessario utilizzare codice come il seguente:

<td class= "evidenzia">Testo centrato e grassetto</td>

in cui la classe “evidenzia” conterrà delle formattazioni tramite fogli di stile per riprodurre l’effetto desiderato.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la barra dell’accessibilità per:

verificare la presenza di tabelle di impaginazione;

  • verificare l’eventuale errata presenza degli elementi ed attributi previsti dalle specifiche per le tabelle dati;
  • verificare che il contenuto della tabella sia linearizzabile.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Struttura

Bordi delle tabelle. Evidenzia tutti I bordi delle tabelle/celle sulla pagina corrente al fine di identificare la struttura della pagina (Punto di controllo 5.4).

Tabelle dati complesse. Visualizza gli elementi <table>, <th>, <td>, <thead>, <tbody>, <tfoot>, <col>, <colgroup> sulla pagina corrente insieme agli attributi raccomandati per il linguaggio di marcatura di tabelle di dati complesse (summary, scope, id, headers). Un attributo vuoto indica che l’attributo non è stato utilizzato. L’esperto potrà quindi verificare l’errato utilizzo di tali elementi per le tabelle di impaginazione (Punto di controllo 5.4).

Ordinamento delle celle in tabella. Visualizza l’ordine (numerico) di tabulazione ed i bordi delle celle delle tabelle sulla pagina corrente (Punto di controllo 5.3). Grazie a tale funzionalità l’esperto può verificare il corretto ordine di lettura.

Linearizza (Rimuovi le tabelle). Rimuove tutti gli elementi <table>, <th>,<tr>, <td> e <div> dalla pagina corrente per controllare la linearizzazione dei contenuti (Punto di controllo 5.3).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 14

Enunciato: Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che sia agevolata la compilazione dei campi da parte di chi utilizza le tecnologie assistive.

Riferimenti WCAG 1.0: 10.2, 12.4

Riferimenti Section 508: 1194.22 (n)

Motivazione

I moduli (form) consentono l’interazione tra l’utente ed i contenuti nella pagina web: moduli di ricerca, moduli di contatto, questionari sono attualmente largamente diffusi.

Ogni elemento contenuto nel modulo deve perciò essere chiaramente identificabile da parte degli utenti, indipendentemente dalla disabilità. È quindi necessario garantire che l’utente possa comprendere l’etichetta che accompagna i campi di inserimento e di selezione implementando delle tecniche che consentano alle tecnologie assistive di affiliare l’elemento alla propria etichetta informativa. Nel caso queste etichette non siano presenti o non siano posizionate correttamente l’utente non potrà procedere con la compilazione del modulo, che quindi sarà inaccessibile.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che garantiscono a tutti gli utenti di poter utilizzare i moduli contenuti in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di elementi ed attributi in modo conforme alle specifiche.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito. I riferimenti alle WCAG riguardano sia le etichette implicite che le etichette esplicite mentre di fatto il requisito riguarda le etichette esplicite. È possibile ipotizzare che tale definizione sia stata inserita richiedendo di garantire la possibilità di accedere ai moduli anche per le etichette non fornite in modo esplicito: l’accesso ai moduli, quindi, deve in ogni caso essere garantito.

Punto di controllo 10.2 (Priorità 2). Fino a quando i programmi utente non supporteranno esplicite associazioni fra etichette e controlli dei moduli, garantire che l’etichetta sia posizionata correttamente per tutti i controlli dei moduli che hanno etichette associate implicitamente

Nella motivazione del requisito è chiaramente spiegato come sia necessario fornire un’etichetta per ogni elemento di un modulo:

  • elemento <input>, ad esclusione degli elementi con type=”button”;
  • elemento <textarea>;
  • elemento <select>.

Le etichette vengono identificate tramite l’elemento <label> che, secondo quanto richiesto dal Punto di controllo 10.2, viene associato al modulo in modo implicito:

<label>
Nome Utente: <input type="text" size="20"
id="utente" name="utente"/>
</label>

In questo modo una tecnologia assistiva è in grado di identificare che il testo dell’etichetta è affiliato all’elemento input identificato come “utente”.

Utilizzando un normale browser è possibile cliccare sull’etichetta “Nome Utente:” e si verrà trasferiti all’interno del campo di input. Questa caratteristica risulta utile quindi non solo agli utenti non vedenti ma anche ad utenti con disabilità o difficoltà motorie. La normativa italiana però chiede di riferirsi alle etichette esplicite, descritte nel punto di controllo 12.4 ed ha anticipato quanto richiesto attualmente dalle techniques delle WCAG 2.0, ovvero di utilizzare la modalità esplicita anzichè la modalità implicita per assegnare le etichette ai rispettivi controlli.

Punto di controllo 12.4 (Priorità 2). Associare esplicitamente le etichette ai loro controlli.

Per soddisfare questo punto di controllo, è necessario utilizzare l’elemento <label> in modo esplicito tramite l’attributo for che deve corrispondere all’attributo id dell’elemento interno al modulo:

<p>
<label for="utente">Nome Utente:</label>
<input type="text" size="20" id="utente" name="utente" />
</p>

Come si noterà, tramite l’attributo for è possibile associare un elemento <label> in modo esplicito a un determinato elemento interno al modulo, ricordando che il valore dell’attributo for dell’elemento <label> deve corrispondere al valore dell’attributo id dell’elemento interno al modulo.

Perché è comunque necessario usare la modalità esplicita? Ipotizziamo di utilizzare in un sito una tabella di impaginazione per presentare un modulo di raccolta dati. In questo caso, ci troveremmo ad avere una colonna della tabella contenente gli elementi <label> e una colonna con elementi interni al modulo (campi di input testuale, ecc.). Se si utilizzasse la modalità implicita, l’elemento <label> non riuscirebbe ad individuare il proprio elemento interno al modulo, per cui è necessario utilizzare l’attributo for. Riporto una serie di esempi.

<tr>
<td><label for="nome">Nome:</label></td>
<td><input type="text" size="20"
id="nome" name="nome" />
</td>
</tr>

Nel primo caso abbiamo una tabella contenente l’etichetta nella cella di sinistra e il campo di input nella cella di destra: cliccando o selezionando l’elemento <label> l’utente verrà trasferito nel campo di input. Prendiamo invece il caso di due pulsanti di selezione (radio button) che condividono lo stesso attributo name ma devono utilizzare due diversi ID, questo per poter affiliare in modo corretto gli elementi <label>.

<fieldset>
<legend>Sesso</legend>
<label for="sessoM">Maschio</label>
<input type="radio" size="20"
id="sessoM" name="sesso" /> <br />
<label for="sessoF">Femmina</label></td>
<td><input type="radio" size="20"
id="sessoF" name="sesso" />
</fieldset>

In modo similare è possibile definire delle caselle di controllo (checkbox) che, se numericamente sostanziose potrebbero richiedere l’uso di elementi di raggruppamento come <fieldset>, altrimenti possono in ogni caso essere intabellati.

<tr>
<td><label for="cliente">Cliente XYZ</label></td>
<td><input type="checkbox" size="20"
id="cliente" name="cliente" />
</td>
</tr>

Per quanto riguarda invece gli elenchi di selezioni (elemento <select>) l’etichetta corrisponde all’id dell’elemento select. Nell’esempio seguente utilizziamo, oltre all’elemento <option> anche l’elemento <optgroup> per raggruppare le diverse opzioni e consentire agli utenti di poter saltare tra i diversi gruppi.

<tr>
<td><label for="citta">Città</label></td>
<td><select name="citta" id="citta">
<optgroup label="Lombardia">
<option value="Brescia">Brescia</option>
</optgroup>
<optgroup label="Veneto">
<option value="Venezia">Venezia</option>
</optgroup>
</td>
</tr>

Per finire riporto l’esempio di una area di inserimento testuale (elemento <textarea> la cui etichetta è collegata tramite l’attributo ID come per gli altri elementi di input.

<tr>
<td><label for="note">Annotazioni:</label></td>
<td><textarea rows="2" cols="70"
name="note" id="note">
</textarea>
</td>
</tr>

Utilizzando il codice appena rappresentato, in cui sono evidenziati esempi per ogni campo del modulo che necessita l’elemento <label>, sarà possibile garantire la conformità al requisito. Tengo a precisare che l’impaginazione tabellare è stata utilizzata esclusivamente per rendere maggiormente chiara la problematica delle etichette per i moduli: evitare quindi l’uso delle tabelle per impaginazione, delegando invece tale funzionalità ai fogli di stile ed agli elementi strutturali come l’elemento <div>.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare la presenza di moduli (form);
  • verificare l’eventuale presenza di campi che necessitano dell’attributo <label>;
  • verificare la corretta affiliazione degli elementi <label>.

Tramite la barra dell’accessibilità è possibile utilizzare:

Struttura

Elementi Fieldset / Label: Visualizza gli elementi <fieldset>, <legend> e <label> sulla pagina corrente, e l’attributo “for” dell’elemento <label> (se presente), altrimenti visualizza il testo ‘NoFor!’. Inoltre, visualizza l’attributo id [id=””], sui controlli dei form, se presente (Punto di controllo 12.4). Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Potrebbero interessarti anche i seguenti articoli

  • Requisiti 2 e 3Requisiti 2 e 3 Requisito 2 Enunciato: Non è consentito l'uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione, per i siti Web esistenti già […]
  • Requisiti 15, 16, 17Requisiti 15, 16, 17 Requisito 15 Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; […]
  • Requisiti 19, 20, 21, 22Requisiti 19, 20, 21, 22 Requisito 19 Enunciato: Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio […]
  • Legge Stanca – Guida ai 22 requisiti tecniciLegge Stanca – Guida ai 22 requisiti tecnici Sull'argomento "Legge 4/2004, documenti e buone pratiche ad essa correlati" è stata fatta molta disinformazione, spesso con il solo scopo di sollevare polvere e di […]
  • Requisito 1 – Prima applicazione e verificaRequisito 1 – Prima applicazione e verifica Prima applicazione In caso di prima applicazione nel caso si utilizzino DTD di tipo Transitional l'enunciato richiede di evitare sia l'uso di attributi di […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

Nessun commento

    Rispondi

    Link e informazioni