Garantire che le pagine caratterizzate da nuove tecnologie si trasformino elegantemente

Scalabile e dinamico, secondo le WCAG 1.0

Questa linea guida porta in primo piano il concetto di scalabilità: l’uso di nuove tecnologie non deve ostacolare l’accesso ai contenuti di chi non dispone di programmi utente conformi a tali tecnologie o, per libera scelta, non vuole utilizzarli.

Il principio è a nostro avviso ineccepibile. Tuttavia, le tecniche che le WCAG 1.0 e i documenti accessori associano all’applicazione di questa linea guida sono per lo più sorpassate. In particolare, i riferimenti all’uso di NOSCRIPT, NOFRAMES e, in generale, di equivalenti statici per applicazioni dinamiche testimoniano della lontananza temporale delle WCAG 1.0 dalle pratiche di sviluppo odierne.

L’approccio attuale più avanzato al problema della scalabilità è, infatti, inverso rispetto a quello che si ricava dalla lettura dei suggerimenti tecnici per le WCAG 1.0. Mentre questi ultimi partono dal sito dinamico, considerato l’oggetto che deve essere reso accessibile per mezzo di equivalenti statici o di pagine alternative, l’approccio attuale considera, invece, il sito statico come il punto di partenza. L’idea che si è andata affermando di recente è che le funzioni dinamiche, o comportamenti, debbano essere aggiunte successivamente, senza pregiudicare in nessun modo l’accesso alle funzionalità e alle informazioni, che la versione statica del sito garantisce. Questo è il principio del cosiddetto potenziamento progressivo, che analizzeremo dettagliatamente nei Capitoli 11 e 12.

Un altro concetto essenziale, soprattutto per la comprensione dei punti di controllo 6.2 e 6.5, è il concetto di contenuto dinamico. Il senso in cui la locuzione è usata all’interno delle WCAG 1.0 si ricava dalle tecniche di applicazione suggerite per questa linea guida: il riferimento a script e applet ci informa che si sta parlando di fattori dinamici lato client. Però il riferimento agli equivalenti per i frame allarga il discorso a contenuti dinamici prodotti lato server (i contenuti di un frame, infatti, cambiano perché viene caricata una nuova pagina dal server).

In sostanza, ci sembra che il senso generale in cui è usato nelle WCAG 1.0 il termine “dinamico” prescinda dall’origine dei cambiamenti (il server o il client) e si riferisca in generale a contenuti che cambiano all’interno dell’interfaccia utente del browser, mentre altri contenuti rimangono immutati: è solo l’esistenza di un rapporto tra ciò che cambia e ciò che non cambia che accomuna, per esempio, la dinamica interna di un’applet e quella di un frame. Se questo è il senso, allora ricaricare un’intera pagina web, non è un fatto dinamico, perché tutto il contenuto dell’interfaccia utente viene aggiornato, non solo una sua parte (come accade invece per applet, script e frame).

Va precisato che una definizione esplicita del concetto di “contenuto dinamico” non compare in nessuna parte delle WCAG 1.0, mentre è presente nel glossario una definizione di Dynamic HTML, in cui compare un richiamo alla linea guida 6 (nonché ad altre linee guida).

Inizio pagina

Punto di controllo 6.1, priorità 1

Un documento deve restare leggibile anche a fogli di stile disabilitati

È un punto di controllo d’importanza fondamentale per l’accessibilità. Un ipovedente può decidere di disabilitare i fogli di stile per visualizzare i documenti con i colori e i caratteri che ha impostato nel sistema operativo: l’eliminazione dei fogli di stile deve essere allora “indolore”, nel senso che tutto il contenuto informativo deve rimanere disponibile; e la grafica di base, resa tramite il codice di marcatura, non deve ostacolare la leggibilità dei contenuti. Che i contenuti rimangano integralmente disponibili, e soprattutto comprensibili, anche a fogli di stile disattivati è importante anche per chi naviga usando un browser testuale o uno screen reader.

Insomma, ogni sviluppatore interessato a produrre contenuti accessibili dovrebbe testare con attenzione i propri documenti, prima di pubblicarli sul Web, per essere sicuro che restino fruibili anche a fogli di stile disattivati.

Un buon metodo per ottenere documenti ben leggibili anche senza fogli di stile consiste nel progettare la struttura dei contenuti indipendentemente e prima rispetto alla grafica. Gli stili CSS sono come un “vestito” che può essere “cucito” su misura. I contenuti strutturati del documento sono il “corpo” che quel “vestito” dovrà valorizzare. Se la separazione tra presentazione, contenuto e struttura è completa, aggiungere e togliere il “vestito” degli stili CSS non pregiudicherà in alcun modo la leggibilità dei contenuti. La home page del sito del Comune di Siena (Figure 6.2 A e B) rappresenta una buona applicazione di questo concetto.

Si riveda il commento al punto di controllo 3.3 nel Capitolo 6, per un’analisi particolareggiata di come procedere per separare completamente la presentazione dalla struttura e dal contenuto di un documento.

Inizio pagina

Punto di controllo 6.2, priorità 1

Una formulazione troppo ambigua

Il punto di controllo 6.2 fa riferimento all’uso di opportune tecniche per fornire equivalenti di contenuti dinamici quali frame, script e oggetti di programmazione. Tuttavia è formulato in modo così ambiguo da essere stato scartato dall’elenco dei requisiti trapassati dalle WCAG 1.0 al paragrafo 1194.22 della legge americana sull’accessibilità (la cosiddetta Section 508).

In effetti, se dobbiamo dare un significato letterale a ciò che il punto di controllo afferma, ne deriva automaticamente la sua inapplicabilità. In HTML, infatti, è possibile fornire equivalenti ai contenuti dinamici per mezzo di contenuti statici (testi alternativi, elementi NOFRAMES e NOSCRIPT). Ne derivano due possibilità: o gli equivalenti devono essere aggiornati manualmente ogni volta che un contenuto dinamico cambia oppure non possono rispecchiare i cambiamenti dei contenuti dinamici (se potessero farlo, sarebbero anch’essi contenuti dinamici).

L’esperto di accessibilità Jim Thatcher spiega bene l’assurdità conseguente al modo in cui il punto di controllo 6.2 è stato formulato :

[...] Un altro esempio di ciò, il mio favorito, è una funzione JavaScript che mostra a pie’ di una pagina web la data del suo ultimo aggiornamento, ricavandola dalla data del file. Ciò può garantire che l’informazione sull’aggiornamento sia attuale, senza che la si debba modificare ogni volta che la pagina viene modificata. Ma se usiamo l’opzione NOSCRIPT come un’alternativa testuale a quel contenuto dinamico, il contenuto di NOSCRIPT dovrebbe essere aggiornato, stando a questo punto di controllo, ogni volta che la pagina viene modificata, rendendo nulla a causa di ciò l’utilità dello script.

Inizio pagina

Contenuti scalabili con OBJECT

In realtà, il punto di controllo 6.2 intende qualcosa di diverso rispetto a ciò che la sua infelice formulazione lascia presumere: non richiede l’aggiornamento degli equivalenti in tempo reale con i cambiamenti interni degli oggetti dinamici a cui essi sono associati, ma semplicemente che gli equivalenti cambino quando cambia nel suo complesso l’oggetto dinamico a cui sono associati.

Che questa sia l’interpretazione corretta lo dimostrano gli esempi di applicazione del punto di controllo forniti dai documenti di Tecniche per le WCAG 1.0. Il Listato 9.1 riporta uno di questi esempi, in cui viene presentata un’interessante applicazione del concetto di scalabilità (8.1 Text and Non-Text Equivalents for Applets and Programmatic Objects).

Troviamo in questo frammento di codice il riferimento a quattro tipi di contenuto, ciascuno alternativo all’altro. Il primo è un’applet Java (il file Press.class), che è il contenuto principale, quello che un programma utente conforme alle specifiche HTML dovrebbe cercare di riprodurre per primo. Il secondo elemento OBJECT contiene il primo equivalente da riprodurre in sostituzione dell’applet: l’animazione contenuta nel file Pressure.mpeg. Se un programma utente non è in grado di riprodurre né l’applet né l’animazione, dovrebbe scalare ancora verso il terzo equivalente, più semplice dei due precedenti: un’immagine grafica in formato GIF (il file Pressure.gif), che è il contenuto del terzo e ultimo elemento OBJECT. Se neppure questo tentativo di riproduzione andasse a buon fine, come potrebbe accadere a un browser testuale oppure a uno screen reader, resterebbe l’ultimo equivalente, cioè la descrizione testuale del contenuto dell’applet (nonché dell’animazione e dell’immagine GIF): “As temperature increases, the molecules in the balloon...”, “Con l’innalzarsi della temperatura, le molecole nel pallone…”.

In questo esempio, tutte le alternative sono valide, finché riguardano il medesimo fenomeno fisico, che mostra il movimento delle molecole in relazione all’aumento della temperatura. Nel momento in cui venisse caricata tramite OBJECT un’applet differente, per esempio una che mostrasse il comportamento delle molecole in un sistema ghiacciato, allora dovrebbero cambiare anche gli equivalenti: ciò è perfettamente compatibile anche con una gestione statica degli equivalenti.

La possibilità di usare OBJECT come strumento per fornire contenuti dinamici insieme con alternative equivalenti riposa, in ogni caso, sul supporto dei programmi utente per questo elemento (un supporto che continua a presentare problemi di compatibilità tra browser, come mostra il paragrafo “Incorporare oggetti flash in una pagina web”, alla fine del Capitolo 12).

Inizio pagina

Uso dell’elemento NOSCRIPT

Per fornire alternative equivalenti ai contenuti dinamici generati per mezzo di script, lo strumento previsto in HTML e XHTML è l’elemento NOSCRIPT, il cui contenuto viene riprodotto solo se il supporto ai linguaggi di scripting da parte del programma utente è assente o disabilitato.

Fino a che punto sia possibile generare tramite NOSCRIPT un vero equivalente dipende da che cosa fa lo script. In certi casi, l’equivalente è in grado di presentare una versione statica dei contenuti generati dinamicamente, senza alcuna perdita d’informazione per l’utente. Un caso di questo tipo è quello proposto dal Listato 9.2, che adatta alla lingua italiana un esempio tratto dalle Tecniche HTML per le WCAG 1.0: un tabellone dinamico di risultati sportivi ha come equivalente un elemento NOSCRIPT, il cui contenuto è una versione HTML statica delle medesime informazioni contenute nel tabellone.

In altri casi, invece, come per esempio quello della funzione dataria in JavaScript, ipotizzata da Jim Thatcher, il contenuto di NOSCRIPT può essere tutt’al più una descrizione delle funzioni dello script a cui è associato, senza la possibilità per chi naviga con il supporto per gli script disabilitato di usufruire delle informazioni o dei servizi da quello generati.

Inizio pagina

I frame e l’aggiornamento degli equivalenti

Il terzo elemento dinamico trattato negli esempi associati al punto di controllo 6.2 delle WCAG 1.0 sono i frame. È riguardo ai frame che risalta più chiaramente il senso in cui il punto di controllo intende che gli equivalenti devono essere aggiornati quando cambiano i contenuti dinamici. Leggiamo a tal proposito la spiegazione contenuta nella sezione 10.4 del documento di Tecniche HTML :

Gli sviluppatori di contenuti devono fornire equivalenti testuali dei frame in modo che i loro contenuti e le relazioni tra i frame abbiano senso. Si noti che al mutare del contenuto di un frame, deve cambiare anche la descrizione. Questo non è possibile se un IMG viene inserito direttamente in un frame. Pertanto, gli sviluppatori di contenuti dovrebbero far sì che la sorgente (“src”) di un frame sia sempre un file HTML. Le immagini possono essere inserite nel file HTML e le loro alternative testuali evolvere in modo corretto.

L’esempio seguente, tratto dal medesimo documento di Tecniche HTML, mostra l’uso deprecato dell’attributo src dell’elemento FRAME, descritto nel brano citato:

Un simile uso è inaccessibile, anche se formalmente corretto, perché, mentre il nome del frame rimane sempre lo stesso ("framecattivo"), e uguale rimane anche l’eventuale descrizione inserita nell’attributo title, il contenuto del frame può invece cambiare, a seconda della risorsa richiamata da un qualsiasi frame del frameset, che si riferisca a "framecattivo" per mezzo dell’attributo target. Pertanto, se si vuole rendere accessibile un’immagine, il testo alternativo a essa associato non può stare in un elemento FRAME, ma deve stare in un elemento IMG, all’interno di un file HTML (non importa se caricato in un frame oppure no).

È un esempio sicuramente datato, che si rifà a criteri di sviluppo da anni Novanta del secolo scorso: oggi i siti organizzati a frame sono sempre più rari e nessuno si sognerebbe mai, anche in un sito a frame, di referenziare tramite src un’immagine invece che un file HTML. Tuttavia è un esempio significativo, perché permette di capire bene ciò che il punto di controllo 6.2 chiede agli sviluppatori: la richiesta – vale la pena di ripeterlo – è che ogni contenuto dinamico (frame, script, oggetti di programmazione) sia associato a equivalenti, che devono essere aggiornati se il contenuto dinamico, nel suo insieme, cambia.

Spetta a un altro punto di controllo, l’8.1, raccomandare agli sviluppatori di rendere internamente accessibili script e oggetti di programmazione.

Inizio pagina

Punto di controllo 6.3, priorità 1

Non vincolare l’accesso ai contenuti al supporto per le nuove tecnologie

Il punto di controllo 6.3 raccomanda di non ricorrere a soluzioni di sviluppo che obblighino l’utente a passare attraverso script e oggetti di programmazione per accedere ai contenuti. Un caso tipico è l’uso di funzioni JavaScript come valore dell’attributo href: un collegamento ipertestuale così realizzato non può essere seguito, se il programma utente utilizzato non supporta JavaScript (come accade per i browser testuali Lynx e Links).

Situazioni altrettanto inaccessibili sono quelle in cui un modulo può essere inviato solo per mezzo di uno script, come avviene, per esempio, quando la funzione che fa partire il collegamento a un’altra pagina si attiva solo selezionando una voce in un campo select, senza che sia disponibile un pulsante di invio per eseguire la stessa funzione in modo indipendente dallo script.

Il sito di condivisione video Revver è uno dei tanti esempi di uso inaccessibile di JavaScript, in cui l’accesso ai contenuti o non è possibile o è molto difficoltoso, se l’utente naviga senza supporto per questo linguaggio.

Come si può capire confrontando le due schermate mostrate in Figura 9.1, la disabilitazione del supporto per JavaScript produce due gravi conseguenze.

La prima è che i video non vengono più caricati: l’apposito spazio sulla sinistra della pagina rimane vuoto. Si perde dunque la caratteristica essenziale del sito, che è quella di permettere agli utenti di guardare via Web filmati, animazioni ecc. La seconda è che le funzionalità del motore di ricerca sono compromesse. Mentre con JavaScript attivo compaiono sotto la casella di testo tre differenti opzioni di ricerca (evidenziate dall’ovale in Figura 9.1 A), con il supporto disabilitato tali opzioni scompaiono. Inoltre, non è disponibile alcun pulsante per avviare la ricerca tramite mouse. L’unico sistema, per chi lo intuisce, è premere il tasto INVIO mentre è selezionata la casella di immissione del testo: la ricerca così avviata produce risultati generici, non essendo disponibili le tre opzioni che permetterebbero di restringere il campo dei risultati.

Come ovviare a simili inconvenienti? In generale, il rimedio migliore è evitare di usare JavaScript come unica porta di accesso ai contenuti.

Se ciò per qualche ragione non è possibile, è necessario fornire un’alternativa accessibile per mezzo di un elemento NOSCRIPT (cosa che il sito Revver non fa) oppure cercare di sostituire gli script lato client con equivalenti funzioni lato server. Se neppure ciò è possibile, non resta che la realizzazione, da considerare come ultima ratio, di una pagina alternativa accessibile, coordinata con la pagina inaccessibile.

Più difficile è capire come applicare questo punto di controllo nel caso di oggetti di programmazione dotati di una propria interfaccia utente (Flash, applet ecc.): se le funzioni principali di un documento sono contenute nell’interfaccia utente di un oggetto incorporato, la mancanza di supporto per quel tipo di oggetto da parte del programma utente rende monco il documento. Cosa vuol dire allora “garantire che le pagine siano usabili”? Se, tolto l’oggetto di programmazione, resta solo un menu di navigazione, quello sì usabile, possiamo considerare la pagina nel suo insieme “usabile”? Basta un equivalente testuale di un applet o di un oggetto Flash a garantire il superamento di questo punto di controllo? Non abbiamo risposte certe per tali domande, ma incliniamo per il no.

La verità è che i punti di controllo 6.2 e 6.3 sono tra i più ambigui e peggio formulati delle WCAG 1.0. O, quanto meno, sono carenti di adeguate spiegazioni di contorno. È perciò particolarmente difficile fornire indicazioni certe per la loro applicazione.

Quel che è certo, invece, perché lo dicono le stesse WCAG 1.0, è che il punto di controllo 6.3 rimanda alla linea guida 1 (Fornire alternative equivalenti per i contenuti uditivi e visivi) e al punto di controllo 11.4, che chiede di creare una pagina accessibile equivalente, nel caso non si riesca a rendere direttamente accessibile la pagina su cui si sta lavorando: se sono state soddisfatte l’una o l’altra di queste due condizioni, è ragionevole ritenere che anche il punto di controllo 6.3 sia stato soddisfatto.

Inizio pagina

Punto di controllo 6.4, priorità 2

Uso accessibile dei gestori di evento

La sezione 12.4 (Directly Accessible Scripts ) del documento di Tecniche HTML per le WCAG 1.0 spiega cosa sono i gestori di evento e come utilizzarli in maniera accessibile.

Un gestore di evento è uno script che è invocato quando si verifica un dato evento (per esempio, il mouse si muove, un tasto viene premuto, il documento è caricato ecc.). In HTML 4.01, i gestori di evento sono collegati agli elementi per mezzo di attributi per la gestione di eventi (gli attributi che cominciano con “on”, come onkeyup).

Alcuni gestori di evento, quando invocati, producono effetti puramente decorativi come evidenziare un’immagine o cambiare il colore di un elemento di testo. Altri gestori di evento producono effetti molto più sostanziali, come eseguire un calcolo, fornire importanti informazioni all’utente o inviare i dati di un modulo. Per i gestori di evento che fanno qualcosa di più che cambiare semplicemente la presentazione di un elemento, gli sviluppatori di contenuti dovrebbero provvedere nel modo seguente:

1. usare attivatori di evento a livello di applicazione piuttosto che a livello d’interazione con l’utente. In HTML 4.01, gli attributi di evento a livello di applicazione sono onfocus, onblur (il contrario di onfocus) e onselect. Si noti che questi attributi sono progettati per essere indipendenti dal dispositivo, ma sono implementati nei browser attuali come eventi specifici della tastiera.
2. Se, al contrario, è necessario usare attributi dipendenti dal dispositivo, fornire meccanismi di input ridondanti (specificare, cioè, due gestori per lo stesso elemento):
   • usare onmousedown con onkeydown;
   • usare onmouseup con onkeyup;
   • usare onclick con onkeypress.
   Si noti che in HTML 4.01 non esiste un equivalente da tastiera per il doppio clic (ondblclick).
3. Non inserire gestori di evento associati alle coordinate del mouse, poiché ciò impedisce che l’input sia indipendente dal dispositivo.

Inizio pagina

Gli attributi per la gestione di eventi

Riportiamo l’elenco completo degli attributi per la gestione di eventi in HTML e XHTML, con la descrizione dell’evento a cui ognuno è associato (le descrizioni sono basate su quelle usate nella pagina indice degli attributi, alla fine delle Specifiche HTML 4.01 ):

• onblur – l’elemento perde il focus;
• onchange – il valore dell’elemento è cambiato;
• onclick – un pulsante del dispositivo di puntamento è stato cliccato;
• ondblclick – un pulsante del dispositivo di puntamento è stato cliccato due volte;
• onfocus – l’elemento ha ottenuto il focus;
• onkeydown – un tasto è stato premuto;
• onkeypress – un tasto è stato premuto e rilasciato;
• onkeyup – un tasto è stato rilasciato;
• onload – se usato con FRAMESET, tutti i frame sono stati caricati; se usato con BODY, il documento è stato caricato;
• onmousedown – un pulsante del dispositivo di puntamento è tenuto premuto;
• onmousemove – il puntatore si muove all’interno dell’area occupata dall’elemento a cui è associato;
• onmouseout – il puntatore esce dall’area occupata dall’elemento a cui è associato;
• onmouseover – il puntatore si trova sopra l’area occupata dall’elemento a cui è associato;
• onmouseup – un pulsante del dispositivo di puntamento è stato rilasciato;
• onreset – il modulo è stato reimpostato ai valori predefiniti;
• onselect – è stato selezionato del testo in un elemento INPUT o TEXTAREA;
• onsubmit – il modulo è stato inviato;
• onunload – se usato con FRAMESET, tutti i frame sono stati rimossi dall’interfaccia del programma utente; se usato con BODY, il documento è stato rimosso dall’interfaccia del programma utente.

Inizio pagina

Eventi associati a onclick e onkeypress

È da notare che, se si usa insieme con onclick anche il gestore di evento onkeypress, come prescrive il punto di controllo 6.4, si può incorrere in un inconveniente piuttosto dannoso per l’accessibilità: l’attivazione dello script collegato all’evento, qualsiasi sia il tasto premuto dall’utente.

Perché l’attivazione dello script alla pressione di un tasto qualsiasi diventa un inconveniente? Perché blocca la navigazione da tastiera, che avviene, tipicamente, mediante ripetute pressioni del tasto Tab. Se, premendo Tab, viene attivato un elemento che contiene uno script associato a onkeypress, partirà automaticamente l’esecuzione dello script e non sarà più possibile proseguire la navigazione da tastiera, con conseguenze gravi per chi non può utilizzare in alternativa un dispositivo di puntamento.

Occorre, allora, evitare che la pressione di Tab attivi lo script collegato a onkeypress. Sarebbe meglio, anzi, limitare l’esecuzione dello script alla pressione dei soli tasti Invio e barra spaziatrice, che sono normalmente associati all’esecuzione di un comando.

Questo risultato può essere ottenuto inserendo sull’attributo onkeypress una funzione-filtro, che attivi l’evento solo se è stato premuto un determinato tasto (Invio o comunque un tasto diverso da Tab).

Il Listato 9.4 mostra un esempio elementare di filtro realizzato in JavaScript. Alla pressione di un tasto, si attiva l’evento onkeypress, ma, prima di eseguire una qualsiasi funzione, simboleggiata nel listato dalle parentesi graffe vuote, viene esaminato il codice numerico del tasto premuto. Solo se il confronto ritorna il valore 13, che corrisponde alla pressione del tasto Invio, verrà eseguita la funzione collegata all’evento. In tutti gli altri casi, sarà possibile continuare indisturbati la navigazione da tastiera.

Va detto, infine, che tutti i browser grafici permettono di attivare un evento da tastiera, anche se nel codice di marcatura è presente solo l’attributo onclick. Ciò vuol dire che l’indipendenza dal dispositivo di input, richiesta dal punto di controllo 6.4, sarebbe disponibile ugualmente, anche in mancanza di onkeypress, con il vantaggio di liberare gli sviluppatori dall’onere ulteriore di filtrare l’evento associato a onkeypress, affinché non blocchi la normale navigazione da tastiera.

Sta agli sviluppatori decidere se rispettare il suggerimento delle Tecniche HTML per le WCAG 1.0, di inserire gestori di evento ridondanti per le azioni del mouse, con le conseguenze che abbiamo descritto, oppure lasciare che siano i browser a fornire di propria iniziativa – come già in linea di massima fanno – il necessario supporto, anche in mancanza di una marcatura specifica.

Inizio pagina

Punto di controllo 6.5, priorità 2

Rendere accessibili i contenuti dinamici

Il punto di controllo 6.5 integra il punto di controllo 6.3 e, per certi versi, si sovrappone a esso (per entrambi è suggerito, per esempio, di non usare collegamenti ipertestuali che cominciano con la stringa javascript). C’è sovrapposizione anche con il punto di controllo 8.1, che raccomanda di rendere direttamente accessibili gli oggetti di programmazione. Se c’è una differenza tra 6.5 e 8.1, è da scorgersi nel fatto che i contenuti dinamici sono una categoria più vasta degli oggetti di programmazione, comprendendo anche le interfacce a frame, che sono basate su semplice HTML, e gli elementi grafici e multimediali non incorporati in oggetti di programmazione. Altra differenza è che il punto di controllo 6.5, diversamente dall’8.1, raccomanda di fornire una presentazione o una pagina alternative per i contenuti dinamici che non possono essere resi direttamente accessibili.

Tra i modi per soddisfare questo punto di controllo c’è l’uso dell’elemento NOFRAMES in siti realizzati a frame. Serve per garantire l’accesso ai contenuti anche con programmi utente che non supportano i frame (a questo riguardo, c’è una sovrapposizione con il punto di controllo 1.1, che include anche i frame nel lungo elenco di oggetti non testuali per i quali occorre fornire alternative equivalenti).

L’elemento NOFRAMES va posizionato all’interno dell’elemento FRAMESET, nel documento che fornisce la cornice di una struttura a frame. L’esempio seguente, adattato alla lingua italiana, è tratto dalla sezione 10.3 delle Tecniche HTML per le WCAG 1.0 .

Un altro modo di soddisfare il punto di controllo 6.5 consiste nell’utilizzare l’elemento LINK, per indurre i browser privi di supporto per le funzioni dinamiche a caricare direttamente la versione di un documento più adatta alle loro caratteristiche, usando quella che si chiama tecnicamente negoziazione del contenuto. Il seguente frammento di codice HTML, tratto sempre dalle tecniche HTML per le WCAG 1.0, mostra l’uso di LINK per referenziare una versione alternativa solo testuale di un documento, destinata a dispositivi con supporto per i media type aural, braille e tty.

Tra i suggerimenti per l’applicazione del punto di controllo 6.5, vanno ricordati, inoltre, quelli che riguardano l’accessibilità degli script. La sezione 12.1 delle Tecniche HTML raccomanda in particolare (Graceful Transformation of Scripts ):

Evitare di generare contenuti al volo sul client. Se il browser dell’utente non gestisce gli script, nessun contenuto sarà generato o visualizzato. Ciò, tuttavia, è differente dal visualizzare o nascondere contenuti già esistenti usando una combinazione di fogli di stile e linguaggi di script; se non c’è supporto per gli script, allora il contenuto è sempre visibile. Ciò non richiede, peraltro, di evitare di generare pagine al volo lato server e di servirle al client.

Le soluzioni lato server al posto di quelle lato client sono, in effetti, un altro dei modi per garantire l’accessibilità dei contenuti dinamici. Spostando sul server l’elaborazione che genera il contenuto dinamico, si elimina alla radice il problema di fornire alternative per chi usa programmi utente privi di supporto per script e oggetti di programmazione. Le soluzioni lato server non sono però sempre utilizzabili, sia per ragioni di traffico di rete (la risposta deve essere pressoché immediata, altrimenti si rischia di rendere inutilizzabile la funzione) sia perché alcuni tipi di elaborazione dinamica possono essere compiuti solo dal computer client.

Un esempio di modifica dinamica generata lato server, accessibile perciò anche agli utenti che navigano con il supporto a JavaScript disabilitato, è visibile sulla home page del sito web dell’autore di questo libro : in cima alla pagina è presente un link che consente di scegliere tra un’impaginazione a due colonne, che è quella predefinita (Figura 9.2 A), e un’impaginazione a colonna unica (Figura 9.2 B), più adatta a computer dotati di schermi piccoli o impostati per le basse risoluzioni. Avendo le due impaginazioni URI differenti, chi vuole può utilizzare un segnalibro, così da caricare direttamente la versione che trova più comoda, in ragione del monitor e della risoluzione utilizzati.

I modi per rendere direttamente accessibili i contenuti multimediali, che pure appartengono alla categoria dei contenuti dinamici e riguardano perciò il punto di controllo 6.5, sono stati già trattati ampiamente nel Capitolo 4, in particolare nei commenti ai punti di controllo 1.3 e 1.4. Il tema complesso delle pagine e dei siti alternativi sarà trattato, invece, nel Capitolo 16, a commento del punto di controllo 11.4.

Inizio pagina