Requisiti 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 contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative, nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.

Riferimenti WCAG 1.0: 13.1, 13.6

Riferimenti Section 508: 1194.22 (o)

Motivazione

La chiarezza della destinazione dei collegamenti è utile per tutte le categorie di utenti ma in particolar modo agli utenti con disabilità di tipo visivo e cognitivo: conoscere se il collegamento apre una nuova pagina web di un sito esterno oppure fornire un avvertimento all’utente se il documento di destinazione diverso dalle normali pagine HTML (per esempio un documento PDF) è senz’altro utile al fine di evitare disorientamento e tempo di caricamento inutile. Per lo stesso motivo è necessario garantire la chiarezza del testo del collegamento ipertestuale e la possibilità di saltare i collegamenti ripetitivi nelle varie pagine (ad esempio, l’intestazione della pagina o la barra di navigazione) a diverse categorie di utenti che utilizzano tecnologie assistive o hanno problemi di mobilità.

Implementazione

Il requisito chiede di garantire l’accesso ai contenuti di una pagina web in modo da garantire la possibilità di saltare gruppi di collegamenti ripetitivi e di identificare chiaramente la destinazione dei collegamenti. 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.

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 13.1 (Priorità 2). Identificare con chiarezza la destinazione di ogni collegamento

Quando creiamo un collegamento ipertestuale (link) è necessario che il testo del collegamento abbia un senso. In una frase come la seguente: “Il testo del disegno di legge sull’accessibilità.” può essere rappresentata con dei collegamenti in modalità diverse:

<p><a href="testo.html">Il testo del disegno di legge sull'accessibilità.</a></p>

In questo modo il link risulterà troppo esteso: un collegamento ipertestuale deve essere sintetico in quanto può confondere la lettura e creare degli effetti sgradevoli alla vista all’interno della pagina.

<p>Il testo del disegno di legge sull'accessibilità:

<a href="testo.html">clicca qui</a> per leggerlo.</p>

Questa modalità è assolutamente da evitare: dove si trova il “qui”? se sono un utente che naviga con tastiera come clicco su un determinato collegamento? E se sono un utente non vedente? È pur vero che il mio lettore di schermo potrà segnalarmi il collegamento ma di fatto manca la contestualità tra il testo del collegamento e la sua destinazione, rendendo problematica la comprensione per esempio ad utenti con disabilità cognitive.

<p>Il <a href="testo.html">testo</a> del disegno di legge sull'accessibilità.</p>

Questa modalità è la consigliata in quanto pone il collegamento ipertestuale direttamente sulla parola interessata. Se il testo invece non risulta adeguato per presentare una descrizione della pagina di destinazione, è possibile utilizzare l’attributo title:

<p>Il <a href="testo.html"

title="Gli articoli del disegno di legge">testo</a>

del disegno di legge sull'accessibilità.</p>

Nel caso per esempio si effettui un collegamento a dei file da scaricare, è necessario informare l’utente della dimensione del file per dare un’idea sul tempo che impiegherà a scaricare il tutto.

<p>Il <a href="testo.zip"

title="/documento compresso .zip da 100 Kb">testo</a> del disegno di legge sull'accessibilità.</p>

Sempre per informare l’utente, è necessario che i collegamenti a pagine che si aprono su nuove finestre siano chiaramente notificati all’utente.

<p>Il <a href="testo.html" title="[nuova finestra] Gli articoli del disegno di legge" class="external">testo</a> del disegno di legge sull'accessibilità.</p>

È inoltre importante sottolineare che se due collegamenti puntano a pagine diverse ma utilizzano lo stesso testo è necessario utilizzare l’attributo title per fornire due differenti spiegazioni. È chiaro quindi che l’utente che utilizza tecnologie assistive e salta da un collegamento ad un altro deve poter facilmente identificare il significato del link, significato che può essere compreso solamente da un chiaro testo del collegamento o da un attributo “title” di supporto.

Punto di controllo 13.6 (Priorità 3). Raggruppare i collegamenti correlati, identificare i gruppi (per i programmi utente) e, fino a quando i programmi utente non lo consentiranno, fornire un modo per saltare il gruppo.

Il requisito indica di raggruppare i collegamenti consentendo di saltare collegamenti ripetitivi, come ad esempio la barra di navigazione. È sempre bene posizionare il menu di navigazione all’inizio del codice all’interno della nostra pagina web, magari inserendo anche una barra di navigazione ed i menu contestuali. È altresì vero che gli utenti non vedenti, che utilizzano i lettori di schermo solitamente si spostano all’interno di una pagina saltando da collegamento a collegamento: questo accadrebbe per ogni pagina visitata se non venisse offerta la possibilità di saltare direttamente al contenuto. Se i collegamenti sono raggruppati secondo una logica (per esempio, le barre di navigazione) è possibile definire un collegamento ipertestuale che ne consenta il superamento: questo significa offrire la possibilità anche agli utenti non vedenti di saltare la lettura di una parte del testo, così come qualsiasi utente vedente farebbe nel caso di ripetizione di testi.

Considerando che spesso la prima voce interna a una pagina Web riguarda proprio la barra di navigazione, se raggruppiamo questi collegamenti in una unità logica alcune tecnologie assistive consentono di saltare direttamente il blocco. Per le tecnologie assistive che invece non consentono tale possibilità, è necessario definire un collegamento che permetta di saltare a un’altra area del contenuto. Nell’esempio seguente i collegamenti vengono raggruppati nell’elemento <map> e la prima opzione consente di saltare direttamente all’inizio del contenuto.

<map title="Barra di Navigazione" id="BarNav">

<p>

[<a href="#contenuto">Passa al Contenuto</a>]

<a href="/index.html">Pagina Iniziale</a> -

<a href="/prodotti.html">Prodotti</a> -

<a href="/about.html">Informazioni</a> -

<a href="/contatti.html">Contatti</a>

</p>

</map>

<a id="contenuto"></a>

È inoltre possibile utilizzare i fogli di stile per nascondere questo collegamento in modo che sia fruibile esclusivamente dai lettori di schermo.

<div class="nascosto">

<a href="#contenuto">vai direttamente al contenuto</a>

</div>

È sufficiente inserire il seguente selettore di classe nel foglio di stile, in modo da rendere subito operativo il codice sopra riportato rendendolo quindi “visibile” agli utenti che navigano con sistemi di lettura dello schermo.

.nascosto {

width:0;

position:absolute;

height:0;

overflow:hidden;

top:-200em;

}

Verifica del requisito

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

  • identificare i collegamenti ipertestuali;
  • verificare la leggibilità dei collegamenti ipertestuali e degli eventuali attributi “title”;
  • verificare la presenza di aree ripetitive tra le varie pagine;
  • verificare la presenza di codice di marcatura che consente di saltare le aree ripetitive.

Tramite la barra dell’accessibilità è possibile utilizzare:

Informazioni

Visualizza titoli. Consente di porre graficamente accanto ad ogni collegamento ipertestuale il contenuto dell’attributo title, al fine di controllarne la corretta affiliazione e la chiarezza (Punto di controllo 13.1).

Elenco dei collegamenti ipertestuali (Nuova finestra). Visualizza un elenco dei collegamenti ipertestuali presenti nella pagina corrente con relativo titolo, url ed attributo title, ove presente (Punto di controllo 13.1).

Seguendo le indicazioni del punto di controllo 13.6 l’esperto dovrà quindi verificare se nel codice della pagina web sono state inserite delle caratteristiche che consentono di saltare i collegamenti ipertestuali.

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

Requisito 20

Enunciato: Nel caso che per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare esplicitamente l’utente, indicando il tempo massimo consentito e le alternative per fruire del servizio stesso.

Riferimenti WCAG 1.0: 7.4, 7.5

Riferimenti Section 508: 1194.22 (p)

Motivazione

Gli utenti che utilizzano lettori di schermo oppure utenti con difficoltà di lettura possono riscontrare difficoltà nella fruibilità di contenuti web le cui pagine si autoaggiornano o richiedono un determinato tempo di risposta. È quindi necessario avvertire l’utente su tali condizioni consentendo delle alternative per poter fruire del servizio. Un caso tipico è un test di assunzione tramite tecnologie informatiche: un utente non vedente dotato di lettore di schermo dovrà poter fruire dei contenuti senza che la pagina si autoaggiorni (passando alla domanda successiva) con la stessa frequenza degli utenti che non hanno disabilità.

Implementazione

Il requisito chiede di garantire l’accesso ai contenuti di una pagina web in modo da garantire la possibilità di fruire dei contenuti conoscendo il tempo massimo concesso per la lettura e fornendo la possibilità di soluzioni alternative e/o di personalizzazione del tempo di risposta. 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.

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 7.4 (Priorità 2). Fino a quando i programmi utente non forniranno la possibilità di bloccare l’autoaggiornamento, non creare pagine che si autoaggiornano periodicamente.

Prendiamo come esempio il caso di un sito di un ente pubblico in che fornisce contenuti con aggiornamento in tempo reale e che quindi richiedono un frequente aggiornamento dei contenuti. L’esempio classico è dato dai risultati elettorali per l’elezione di un Sindaco, di un presidente di Regione, ecc. Per non dover costringere l’utente ad aggiornare la pagina Web spesso viene utilizzato l’elemento meta http-equiv=”refresh” per definire automaticamente la frequenza di aggiornamento della pagina.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it">

<head>

<title>Titolo Pagina</title>

<meta http-equiv="Content-Type"

content="text/html; charset=ISO-8859-1" />

<meta http-equiv="Refresh" content="60" />

</head>

...

...

</html>

Nell’esempio riportato, la pagina si aggiorna ogni 60 secondi, presentando in tempo reale l’elenco delle ultime notizie. Il caricamento automatico della pagina può causare problemi ad alcune categorie di utenti: chi ha bisogno di maggior tempo per leggere i contenuti e chi utilizza lettori dello schermo troverà fastidioso dover ricominciare a leggerli. Come ovviare a questo problema? Innanzitutto è necessario avvisare gli utenti di questa funzionalità di autoaggiornamento, in modo che in ogni caso siano preparati all’evento. Nel caso non sia possibile concedere all’utente il controllo di tale evento consentendo una personalizzazione del refresh della pagina, è preferibile fornire un collegamento a una versione alternativa dove questa funzionalità non sia presente. Ipotizzando di usare codice ASP, con un semplice modulo è possibile consentire all’utente di modificare il tempo di riaggiornamento della pagina:

<%

'definisce il valore in secondi del refresh

Dim aggiorna

if request.form("aggiorna") = "" then

aggiorna = 60

elseif isnumeric(request.form("aggiorna")) then

aggiorna = int(request.form("aggiorna"))

else

aggiorna= 60

end if

%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it">

<head>

<title>Titolo Pagina</title>

<meta http-equiv="Content-Type"

content="text/html; charset=ISO-8859-1" />

<meta http-equiv="Refresh" content="<%=aggiorna%>" />

</head>

<body>

<form action="default.asp" method="post">

<label for="aggiorna">Aggiornamento:</label>

<input type="text" id="aggiorna"

value="<%=request.form("aggiorna")%>" />

<input type="submit" value="Aggiorna" />

</form>

...

...

</body>

</html>

Punto di controllo 7.5 (Priorità 2). Fino a quando i programmi utente non forniranno la capacità di bloccare l’autoreindirizzamento, non usare marcature per reindirizzare le pagine automaticamente. Piuttosto, configurare il server in modo che esegua i reindirizzamenti.

Nel punto di controllo 7.4 il problema di accessibilità riguardava il caricamento a particolari intervalli di tempo. Il punto di controllo 7.5 invece richiede di non utilizzare gli elementi meta per reindirizzare l’utente ad altre pagine per diverse motivazioni. La prima innanzitutto è che tale funzionalità può disorientare i navigatori del vostro sito Web creando problemi di navigazione, come per esempio la difficoltà di ritornare alla pagina precedente. Per quanto riguarda invece gli utenti che utilizzano tecnologie assistive (come per esempio i lettori di schermo) oppure gli utenti che necessitano maggior tempo per leggere i contenuti di una pagina il caricamento automatico di una nuova pagina ad un determinato intervallo di tempo causa grossi problemi di fruibilità dei contenuti rendendo perciò la pagina inaccessibile per l’attuale requisito.

Un esempio di codice da non utilizzare è il seguente:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it">

<head>

<title>Titolo Pagina</title>

<meta http-equiv="Content-Type"

content="text/html; charset=ISO-8859-1" />

<meta http-equiv="Refresh" content="3; http://www.w3.org/" />

</head>

Noterete che, a differenza del punto di controllo 7.4 l’elemento http-equiv=”Refresh” accanto al tempo di esecuzione (in questo caso tre secondi) riporta l’indirizzo della nuova pagina dove l’utente verrà automaticamente trasferito (se il browser supporta tale funzionalità). Si sarà facilmente compreso che tutto dipende dal supporto tecnologico del programma utente, ma soprattutto dalle impostazioni del server del proprio hosting provider. Pertanto i consigli che si possono dare agli sviluppatori sono i seguenti:

  • configurare il server per utilizzare il codice HTTP 301 e relativi codici HTTP 30x;
  • utilizzare dei normali collegamenti alla nuova pagina anziché delle funzionalità automatiche di redirect;
  • evitare, ove possibile, l’utilizzo di tali tecnologie in quanto la navigazione deve essere sotto il totale controllo dell’utente.

Verifica del requisito

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

  • identificare se la pagina prevede funzionalità di autoaggiornamento o autoreindirizzamento;
  • verificare se sono presenti possibilità di configurare i tempi di autoaggiornamento e di autoreindirizzamento.

Tramite la barra dell’accessibilità è possibile utilizzare:

Informazioni

  • Informazioni Metadata (Nuova finestra). Visualizza l’elenco di tutti gli elementi meta ed il relativo contenuto della pagina corrente al fine di individuare la presenza di meta http-refresh (Punto di controllo 7.4 e 7.5). Se sono presenti, controllare che vi siano funzionalità nella pagina che consentono di variare il tempo di reindirizzamento.

Un caso particolare sono le aree riservate: è necessario controllare la disponibilità di funzioni che consentano all’utente di esser informato sulla durata della sessione utente ed eventualmente della presenza di funzionalità per personalizzare la durata della sessione. Questa ultima possibilità garantisce accessibilità ma può causare problemi di sicurezza in alcuni sistemi informatici.

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

Requisito 21

Enunciato: Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti presenti in una pagina; per facilitare la selezione e l’attivazione dei collegamenti presenti in una pagina è necessario garantire che la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 0,5 em, le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0,5 em e che le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta.

Riferimenti WCAG 1.0: non presente

Riferimenti Section 508: non presente

Motivazione

Gli utenti con ridotta capacità motoria, che utilizzano comandi da tastiera, tecnologie in emulazione di tastiera o sistemi di puntamento alternativi, possono riscontrare difficoltà nella selezione e nell’attivazione dei collegamenti ipertestuali, e dei pulsanti dei moduli, quando questi sono eccessivamente ravvicinati. Questo vale anche per gli utenti con difficoltà cognitive legate alla lettura, ipovedenti, e, in generale, per tutte le categorie di utenti che sperimentano difficoltà di accesso a testi e ipertesti se non sono presenti idonee distanze tra i singoli elementi. Il requisito richiede di garantire la fruibilità dei collegamenti ipertestuali, e dei pulsanti dei moduli, impostando una distanza ragionevolmente ampia tra di essi, indicata in 0.5em.

Implementazione

Le liste HTML (marcatori <ul>, <ol> e <li>) rappresentano il metodo corretto per codificare un elenco di collegamenti ipertestuali. Questo vale sia per le liste di link verticali sia per quelle orizzontali. Utilizzando i fogli di stile è possibile modificare l’aspetto di una lista HTML (per esempio eliminando o modificando i glifi e i margini predefiniti, oppure trasformando una lista verticale in una orizzontale) senza con ciò alterare il codice HTML sottostante. In tale modo le liste di link avranno l’aspetto desiderato e saranno fruibili anche nel caso in cui i fogli di stile fossero disabilitati o non supportati (Requisito 11).

L’elemento <ul> possiede un margine predefinito superiore e inferiore di 1.12em, un margine destro pari a 0 e il margine sinistro (lo spazio riservato ai glifi) pari a 40px. Queste distanze sono rispettate pressoché da tutti i browser (Mozilla Firefox non applica il margine sinistro, sostituendolo con il padding, e imposta i margini superiore e inferiore a 1em). Non sono previsti margini predefiniti tra le voci di una lista (elementi <li>), è infatti il glifo, posto a sinistra delle singole voci, ad indicarne l’inizio, mentre l’interlinea determina lo spazio verticale tra le righe del testo:

Figura 4.9 Effetto delle spaziature.

Tutti i browser considerano 1.2 come il valore predefinito per l’interlinea del testo (tranne Mozilla Firefox che lo imposta, cURIosamente, a 1.25), conformandosi così al limite superiore raccomandato dal W3C per il valore normal della proprietà line-height (che può infatti oscillare tra 1.0 e 1.2). Nella sua prima stesura, il requisito indicava per le distanze il valore minimo di 1em. Questo valore era inteso dal legislatore come la misura minima dell’interlinea del testo. 1em è, però, un valore inferiore rispetto a quello predefinito dai browser per l’interlinea. Applicarlo, quindi, significherebbe ridurre la fruibilità delle liste di link verticali anziché incrementarla. Se invece lo ampliassimo, per esempio portandolo a 1.5, otterremmo certamente un maggiore spazio verticale tra le righe del testo, ma non vi sarebbe soluzione di continuità tra le singole voci della lista:

Figura 4.10 Effetto dell’aumento dell’interlinea.

Oltre a ciò, l’interlinea non è evidentemente utilizzabile per distanziare le voci delle liste di link orizzontali, o i pulsanti dei moduli, e un valore minimo di 1em può risultare elevato se associato a proprietà diverse da essa, come per esempio il margine o il padding. Queste riflessioni hanno indotto il legislatore a ridurre il valore minimo a 0.5em non associandolo più all’interlinea del testo. È il margine tra gli elementi, infatti, che va considerato come l’interpretazione corretta dei termini “distanza” e “spaziatura” presenti nell’enunciato del requisito. Il margine è applicabile sia ad entrambe le tipologie di liste di link, orizzontali e verticali, sia alle distanze tra i pulsanti di un modulo.

Utilizzando il margine, quindi, a prescindere dal valore assegnato all’interlinea del testo (per esempio quello predefinito o un valore superiore), le voci della lista risulteranno sempre adeguatamente distanziate e il testo diviso in blocchi omogenei. Anche se una voce particolarmente lunga si distribuirà su più righe, la separazione logica tra le voci sarà ugualmente garantita:

li { margin-top: 0.5em; margin-bottom: 0.5em; }

Figura 4.11 Effetto della regola.

Ricordo che i margini degli elementi <li> collassano. Ciò significa che due margini adiacenti non si sommano. Il valore applicato sarà quello più alto tra i due. Nell’esempio precedente i due valori sono identici quindi la misura ‘vincente’ è esattamente 0.5em.

Chiaramente è possibile impostare esclusivamente il margine superiore, o quello inferiore, come nell’esempio seguente:

li { margin-bottom: 0.5em; }

Qualora non fosse possibile utilizzare il margine per distanziare le voci delle liste di link, un risultato analogo si ottiene con la proprietà CSS padding. Nel caso delle liste verticali, per esempio, è possibile applicare il padding superiore e inferiore agli elementi <li>. Dato che il padding non è soggetto al collassamento, è necessario fare attenzione all’impostazione dei valori. Per ottenere una distanza effettiva di 0.5em tra le voci della lista, il valore del padding superiore e inferiore dovrà essere impostato a 0.25em:

li { padding-top: 0.25em; padding-bottom: 0.25em; }

Anche in questo caso è possibile impostare esclusivamente il padding superiore, o quello inferiore, piuttosto che entrambi. In questo caso il valore indicato dovrà essere pari a 0.5em:

li { padding-bottom: 0.5em; }

In merito alla porzione dell’enunciato che si riferisce alla distanza tra i pulsanti dei moduli: “le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0,5 em” bisogna aggiungere che, nonostante non sia esplicitamente indicato, è consigliabile considerare questa distanza minima come riferita non solo allo spazio esistente tra i pulsanti, siano essi affiancati orizzontalmente o posti su righe differenti, ma anche alla distanza tra i pulsanti e i campi dei moduli che li precedono o seguono. Non avrebbe molto senso, per gli scopi che si prefigge il requisito, distanziare due pulsanti tra di loro ma non in relazione al campo o all’area di testo (textarea) che eventualmente li precede o li segue.

Infine, la frase “le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta” è difficile da implementare, e valutare, a causa della mancanza di un riferimento oggettivo a un valore minimo. Il concetto di chiara leggibilità, com’è facile intuire, è estremamente soggettivo. Il consiglio è di non scendere mai sotto le dimensioni predefinite dai browser per i pulsanti dei moduli. Questa è, in ogni caso, una soluzione approssimativa dato che esiste una certa variabilità nel modo predefinito in cui i vari browser rappresentano i pulsanti. Qualora, quindi, si desiderasse modificare l’aspetto dei pulsanti utilizzando i fogli di stile non si dovranno impostare altezza, larghezza e padding inferiori a quelli predefiniti. Inoltre, per mantenere la conformità al Requisito 6, sarà necessario assicurarsi che il contrasto tra il colore dell’etichetta e lo sfondo del pulsante sia sufficiente.

Verifica del requisito

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

  • Identificare i moduli (form) e i raggruppamenti di collegamenti ipertestuali.
  • Identificare gli elementi e le classi associate ad essi.
  • identificare se nel foglio di stile vi sono regole che riducono le distanze minime richieste dal requisito.

Tramite la Barra dell’accessibilità è possibile utilizzare:

CSS

Visualizza gli stili applicati (Nuova finestra): Visualizza gli stili associati al contenuto posizionato al di sotto del puntatore del mouse.

Visualizza il foglio di stile (Nuova finestra): Visualizza il contenuto dei fogli di stile richiamati dalla pagina corrente.

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

Requisito 22

Enunciato: Per le pagine di siti esistenti che non possano rispettare i suelencati requisiti (pagine non accessibili), in sede di prima applicazione, fornire il collegamento a una pagina conforme a tali requisiti, recante informazioni e funzionalità equivalenti a quelle della pagina non accessibile ed aggiornata con la stessa frequenza, evitando la creazione di pagine di solo testo; il collegamento alla pagina conforme deve essere proposto in modo evidente all’inizio della pagina non accessibile.

Riferimenti WCAG 1.0: 11.4

Riferimenti Section 508: 1194.22 (k)

Motivazione

Questo requisito consente di creare delle pagine alternative solo in fase di prima applicazione e nel caso in cui, per una determinata pagina, non sia possibile generare contenuti accessibili. È bene ricordare inoltre che la pagina “solo testo” non significa testo senza formattazione ma una pagina HTML senza elementi di formattazione.

Possiamo considerarlo di fatto un “requisito fantasma”, dato che la sua applicazione riguarda esclusivamente i contenuti esistenti: per i nuovi siti internet tale requisito non è applicabile.

Implementazione

Il requisito chiede di garantire l’accesso ai contenuti di una pagina web esistente inacessibile fornendo una pagina parallela con medesimi contenuti e funzionalità e rispettosa dei 21 requisiti, in modo da garantire la possibilità di fruire dei contenuti. 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.

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 11.4 (Priorità 1). Se, nonostante ogni sforzo, non è possibile creare una pagina accessibile, fornire un collegamento a una pagina alternativa che si riferisca alle tecnologie W3C, che sia accessibile, che contenga informazioni (o funzionalità) equivalenti e sia aggiornata con la stessa frequenza della pagina originale inaccessibile.

Gli sviluppatori dovrebbero ricorrere a pagine alternative solo quando le altre soluzioni falliscono perché le pagine alternative sono in genere meno aggiornate delle pagine principali. È bene chiarire innanzitutto che pagina alternativa non significa pagina visualizzata con diverso foglio di stile ma di una pagina con stesse informazioni e funzionalità della pagina inaccessibile.

Ipotizziamo un sito di un ente pubblico dove ogni ufficio inserisce dei contenuti in modo autonomo: se 100 operatori inseriscono contenuti non accessibili che richiedono una versione parallela, il costo e le ore lavorative saranno quantomeno raddoppiate e sempre con il dubbio che non tutte le pagine alternative siano aggiornate.

Una pagina non aggiornata può essere frustrante quanto una pagina inaccessibile visto che, in entrambi i casi, l’informazione presentata nella pagina originale non è disponibile. La generazione automatica di pagine alternative può portare a aggiornamenti più frequenti, ma gli sviluppatori devono comunque fare attenzione ad assicurare che le pagine generate abbiano sempre senso, e che gli utenti siano in grado di navigare in un sito seguendo i collegamenti delle pagine primarie, di quelle alternative, o di entrambe (magari posizionando su ogni pagina il collegamento alla versione alternativa). Alcuni esperti di accessibilità consigliano di iniziare la conversione dei vecchi siti tramite versioni alternative solo testo, magari con qualche foglio di stile dedicato a particolari tipi di disabilità.

Personalmente seguendo le indicazioni del W3C sconsiglio tale pratica che rende pesante l’aggiornamento e che di fatto può risultare dannosa all’accessibilità di un sito Web in quanto si utilizza tale modalità di ripiego per “tenere la coscienza pulita” da eventuali incompetenze degli sviluppatori o dei gestori dei contenuti. Prima di ricorrere a una pagina alternativa, riesaminare il progetto della pagina originale: è probabile che rendendola accessibile essa risulti migliore per tutti gli utenti.

Il W3C non parla mai di sito alternativo ma di pagina alternativa: chi crea siti alternativi non rispetta le WCAG 1.0 e nemmeno i principi di sviluppo per l’accesso universale. Inoltre la soluzione “solo testo”, spesso utilizzata anche da siti istituzionali, non è conforme a questa linea guida in quanto non si tratta di pagina equivalente che utilizza le tecnologie W3C ma si tratta dell’ispirazione alla normativa americana Section 508, legge non in vigore nel nostro paese.

Possiamo quindi dare la seguente chiave di lettura al punto di controllo:

  • Si parla di pagina, non di sito. Questo è particolarmente importante, in quanto le dichiarazioni di conformità alle WCAG devono essere effettuate per singole pagine.
  • “Nonostante ogni sforzo…” significa che lo sviluppatore, dopo aver valutato l’uso di tutte le possibili soluzioni tecniche presentate nelle WCAG per rendere accessibile un contenuto, alza le braccia e si arrende. Se ciò capita per un intero sito web, con creazione di wai.nomesito.it, il committente dovrebbe verosimilmente chiedersi se ha scelto il fornitore adatto.
  • Si parla di pagina alternativa “che usi le tecnologie W3C, sia accessibile, contenga informazioni (o funzionalità) e equivalenti”. Questo non sembra riscontrabile nei cosiddetti siti paralleli, in quanto molto spesso riportano esclusivamente alcuni contenuti di tipo testuale che non sono “una pagina accessibile che usa le tecnologie W3C“.
  • Si parla di aggiornabilità della pagina (non del sito).

Riassumendo: il sito alternativo è sviluppato da persone che nonostante ogni sforzo di applicare le linee guida non sono stati capaci (forse per incompetenza) di creare nemmeno una pagina accessibile e hanno ripiegato su una versione solo testo ad alto contrasto per accontentare una fetta del mercato degli utenti con disabilità (in questo caso, limitatamente alla disabilità visiva).

Quindi, chi nonostante tutto decide di creare la “porta di servizio” (con tutti i limiti che abbiamo già descritto) non può dirsi in linea con gli standard del Web, non potrà dire che sta seguendo le WCAG – e neppure la legge 04/2004.

La soluzione più accessibile, nel caso si desideri creare la pagina alternativa per un contenuto non accessibile è semplice e logica: la pagina principale dovrà essere la pagina accessibile con un collegamento alla pagina non accessibile, ossia come già oggi avviene per i siti Web che propongono introduzioni animate con tecnologia Flash dove all’ingresso della pagina Web viene fornita la possibilità di visualizzare la pagina contenente la tecnologia Flash.

È importante ricordare inoltre che il contenuto della pagina alternativa deve comunque rispettare tutti i requisiti dal numero 1 al numero 21.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà:

  • Identificare dei collegamenti nella pagina che consentono l’accesso a versioni parallele del tipo “Versione accessibile”, “Versione WAI”, ecc.
  • Analizzare tale pagina rispetto i 21 requisiti presentati in precedenza.

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

Condividi:

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.