[Salta il menu][L'elefantino con la matita, logo del sito]

Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

1.1) Requisiti da sottoporre a verifica tecnica

Nella tabella A sono descritti i requisiti che sono obbligatori per raggiungere il livello minimo di accessibilità nei siti internet e nelle applicazioni web based.

Nella seguente tabella sono indicati:

Sono stati indicati, quando esistenti, i riferimenti ai punti di controllo delle WCAG 1.0 e agli standard del paragrafo 1194.22 della Section 508. Tali riferimenti non vanno intesi come perfette corrispondenze ma solo come analogie o vicinanze per consentire un più facile riscontro con gli standard esistenti a coloro che hanno già applicato tali standard e per facilitare l’utilizzo degli strumenti informatici di valutazione della accessibilità oggi disponibili sul mercato.

Tabella A

Requisiti da sottoporre a verifica tecnica

Requisito: 1

Enunciato: Realizzare pagine e oggetti in esse contenuti con tecnologie definite da grammatiche formali pubblicate, utilizzando le ultime versioni disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle specifiche. Per l’HTML o l’XHTML utilizzare una Definizione del Tipo di Documento (Document Type Definition - DTD) di tipo rigoroso (Strict)

Riferimenti WCAG 1.0: 3.1, 3.2, 3.5, 3.6, 3.7, 11.1, 11.2

Riferimenti Sec. 508: Non presente

Commento al requisito 1

E' apprezzabile la scelta di richiedere la conformità alla DTD rigorosa, dal momento che è quella che garantisce la maggiore separazione tra contenuti e presentazione.

Tuttavia l'enunciato, che ricalca in parte quello del punto di controllo 11.1 delle WCAG 1.0, si potrebbe prestare ad un'interpretazione ambigua. La richiesta di utilizzare "le ultime versioni disponibili quando sono supportate dai programmi utente" sembra implicare di fatto la rinuncia, da parte degli sviluppatori, alle varie versioni di HTML in favore di XHTML 1.0, dal momento che praticamente tutti i programmi utente supportano la resa di pagine scritte in XHTML 1.0 (non in XHTML 1.1, per l'eliminazione dell'attributo "name" in favore di "id"). Però, subito dopo aver detto di utilizzare la versione più recente delle grammatiche formali pubblicate, si fa riferimento all'uso della DTD rigorosa di HTML, intendendo quindi del tutto lecito l'uso di HTML, benché sia stato reso in un certo senso obsoleto dall'introduzione di XHTML, che conserva da un lato la compatibilità con HTML e introduce, dall'altro, i vantaggi di una maggiore interoperabilità e rigore formale (si veda http://www.w3.org/TR/xhtml1/#why).

Insomma, per rispettare il requisito 1 si deve usare esclusivamente XHTML o si può continuare tranquillamente ad utilizzare HTML? E se si può continuare ad usare HTML, come dobbiamo intendere la richiesta di usare le più recenti versioni dei linguaggi di marcatura W3C supportate dai programmi utente?

Torna all'elenco

Requisito: 2

Enunciato: E’ sconsigliato in generale l’uso dei frame nella realizzazione di nuovi siti. Ove non evitabile una definizione a frame (DTD frameset) avere cura che il codice interno ai frame sia conforme alle specifiche della DTD rigorosa e che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione. Se necessario, descrivere anche lo scopo dei frame e la loro interazione.

Riferimenti WCAG 1.0: 12.1, 12.2

Riferimenti Sec. 508: 1194.22 (i)

Commento al requisito 2

Qui ricorrerei ad una prescrizione più dura, indicando come "proibito" piuttosto che "sconsigliato" l'uso dei frame in nuovi siti che aspirino ad essere accessibili.

Dare un titolo sensato ai frame è sufficiente, in linea teorica, per renderli accessibili. Ma consideriamo la pratica piuttosto che la teoria. La pratica ci dice che, di solito, il menu di navigazione sta in un frame ed i contenuti in un altro (spesso con contorno di altri vari frame, a complicare le cose). Ciò significa che l'utente che naviga con un sintetizzatore vocale, ogni volta che vuole cambiare pagina è costretto a ritornare al frame con il menu, per poi passare nuovamente, dopo aver scelto un qualsiasi collegamento, al frame con il contenuto selezionato.

Per non parlare dei noti problemi di indeterminatezza dell'indirizzo delle singole pagine di un sito costruito a frame, dal momento che, nella barra degli indirizzi del browser, compare sempre e soltanto l'indirizzo della pagina che contiene il frameset.

Ha senso tutto ciò? E' veramente accessibile un simile sistema? Può considerarsi "esperta in accessibilità" una ditta che realizzi - oggi, non nel '99 - un sito organizzato a frame?

In verità non esiste alcuna sensata ragione, allo stato attuale, per voler realizzare un sito "accessibile" organizzato a frame. Si può considerare accettabile, dal punto di vista dell'accessibilità, solo il rinominare in modo più comprensibile i frame di un sito già esistente e dotato di migliaia di pagine, quando non sia economicamente possibile riconvertirlo in un sito senza frame.

Torna all'elenco

Requisito: 3

Enunciato: Fornire una alternativa testuale equivalente per ogni oggetto non testuale presente in una pagina e assicurarsi che quando cambia dinamicamente il contenuto non testuale di un oggetto vengano aggiornati anche i suoi equivalenti. L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto nello specifico contesto.

Riferimenti WCAG 1.0: 1.1, 6.2

Riferimenti Sec. 508: 1194.22 (a)

Commento al requisito 3

Un altro requisito che, così come è posto, apre la strada a problemi di interpretazione. Si dice nell'enunciato: ...assicurarsi che quando cambia dinamicamente il contenuto non testuale di un oggetto vengano aggiornati anche i suoi equivalenti. Il problema qui è chiarire cosa si intende per "equivalente".

Immaginiamo un applet java che mostri una schacchiera, nella quale la posizione dei pezzi viene aggiornata dinamicamente via Internet, a mano a mano che i giocatori, per esempio dei campioni che stanno disputando un torneo internazionale, effettuano le loro mosse. Come è possibile in una situazione del genere aggiornare dinamicamente gli equivalenti testuali?

La risposta è che non è possibile, a meno che gli equivalenti testuali non vengano aggiornati all'interno stesso dell'applet. Il meccanismo fornito da HTML e XHTML per gestire gli oggetti di programmazione come le applet java prevede l'uso dell'elemento object, all'interno del quale va posizionato l'"equivalente" testuale, utile per chi non può utilizzare direttamente l'oggetto di programmazione grafico (per esempio un cieco). Il limite di questo meccanismo è che, mentre l'oggetto di programmazione, una volta caricato, vive nella pagina di vita propria, aggiornandosi dinamicamente se è stato programmato per farlo, il testo alternativo rimane invece fisso ed immutabile!

Gli esempi di "equivalente" testuale per oggetti di programmazione, mostrati nelle tecniche di controllo associate alle WCAG 1.0, dimostrano chiariamente quanto ho appena spiegato. Il testo presunto "equivalente" inserito in quegli esempi non cambia dinamicamente, ma descrive una volta per tutte ed in modo generico il contenuto dell'applet. E' come se, per ritornare all'esempio della scacchiera, si considerasse come equivalente delle mosse dei giocatori un testo che dicesse: Una scacchiera in cui la posizione dei pezzi viene aggiornata dinamicamente, in modo da riflettere le mosse che i giocatori X e Y stanno facendo nel corso del torneo di Z. E' chiaro che questo è un equivalente per modo di dire, allo stesso modo in cui il menu di un ristorante può essere considerato l'equivalente di un pranzo.

Né migliora le cose la limitazione con cui si chiude l'enunciato: L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto nello specifico contesto. Cosa significa esattamente? Che se l'oggetto svolge una funzione non importante, posso fare a meno di aggiornare l'equivalente testuale? Ma nel caso della partita di scacchi? In quel caso mi pare fondamentale per l'accessibilità del contenuto che venga aggiornata ad ogni mossa anche la descrizione testuale della posizione dei pezzi sulla schacchiera... E non mi si dica che questo non è un problema perché sui siti della Pubblica Amministrazione non compaiono scacchiere dinamiche in java!

Quella del significato preciso della parola "equivalente" (si veda, come riferimento, l'accezione in cui è intesa nel glossario delle WCAG 1.0) e dei limiti dell'aggiornamento dinamico degli equivalenti testuali sono ambiguità che lo studio in esame, prima di trapassare in un decreto attuativo, dovrebbe assolutamente eliminare.

Torna all'elenco

Requisito: 4

Enunciato: Assicurarsi che tutta l’informazione e tutte le funzionalità veicolate dal colore siano disponibili anche senza l’uso dello stesso.

Riferimenti WCAG 1.0: 2.1

Riferimenti Sec. 508: 1194.22 (c)

Torna all'elenco

Requisito: 5

Enunciato: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di funzionamento possono provocare disturbi da epilessia fotosensibile, disturbi della concentrazione o che possono causare il malfunzionamento delle tecnologie assistive. Quando le esigenze informative richiedono comunque il loro utilizzo, avvisare l’utente del rischio e predisporre metodi che consentano di evitare tali contenuti.

Riferimenti WCAG 1.0: 7.1, 7.2, 7.3

Riferimenti Sec. 508: 1194.22 (j)

Commento al requisito 5

Questa regola contiene due errori di concezione, a mio parere. Il primo è quello di esprimere un divieto e subito dopo rendere lecito che non lo si rispetti (Evitare oggetti e scritte lampeggianti o in movimento [...]. Quando le esigenze informative richiedono comunque il loro utilizzo). Il secondo è quello di non chiarire i limiti precisi in cui valgono il divieto, o il permesso, di utilizzare scritte lampeggianti o in movimento.

Troppo ambiguo, non vi sembra? O una cosa è vietata o è permessa. Bisognerebbe poi chiarire cosa si intende precisamente per "esigenze informative". Andrebbe anche definito chiaramente entro quali limiti un oggetto lampeggiante ed in movimento può alterare la concentrazione, generare una crisi epilettica o compromettere il funzionamento delle tecnologie assistive.

Così come è formulato, insomma, l'enunciato del requisito 5 è privo di valore ai fini dell'accessibilità. Gli americani, evidentemente più pragmatici di noi, hanno formulato, a proposito di oggetti lampeggianti, una regola semplice, chiara ed univoca: (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.. Tradotto: "Le pagine devono essere progettate in modo da evitare che lo schermo lampeggi con una frequenza maggiore di 2 Hz e minore di 55 Hz".

Propongo di riformulare il requisito come un divieto dotato di limiti precisi ed inequivocabili, sulla falsariga del punto 1194.22 (j) di Section 508.

Torna all'elenco

Requisito: 6

Enunciato: Assicurarsi che il contenuto informativo (foreground) e lo sfondo (background) siano distinguibili, per mezzo di un sufficiente contrasto nel caso di testo oppure di differenza di livello sonoro in caso di parlato con sottofondo musicale. Un testo in forma di immagine è sconsigliato in genere ma, se non evitabile, deve essere realizzato in modo da garantire una alta leggibilità.

Riferimenti WCAG 1.0: 2.2

Riferimenti Sec. 508: Non presente

Commento al requisito 6

Trovo sbagliato formulare una regola che "sconsigli", invece di proibire o permettere: come si possono effettuare valutazioni equilibrate e comparabili dell'accessibilità se non c'è un criterio fisso di giudizio? Dice l'enunciato: Un testo in forma di immagine è sconsigliato in genere ma, se non evitabile, deve essere realizzato in modo da garantire una alta leggibilità. Perché dovrebbe essere non evitabile l'uso di un testo in forma di immagine? E cosa significa poi "alta leggibilità"? Non c'è nulla di più soggettivo di una simile valutazione: per uno con la vista di falco un testo di 8 px visto su uno schermo impostato alla risoluzione orizzontale di 1900 pixel potrebbe risultare leggibilissimo, mentre per un altro un testo di 24 px sullo stesso monitor impostato ad 800 pixel orizzontali potrebbe apparire poco leggibile.

Si esce dall'ambiguità solo fornendo una misura precisa di cosa si intende per alta leggibilità. Ecco di seguito una mia proposta di riformulazione non ambigua della seconda parte di questo enunciato: E' possibile inserire su una pagina web testo in forma di immagine purché le scritte in esso contenute non superino i 60 caratteri spazi compresi, abbiano un testo alternativo adatto ad essere letto dai sintetizzatori vocali, e vengano adoperati nell'immagine caratteri a bastone, di almeno 14 pixel di corpo e privi di effetti di sfumatura.

Torna all'elenco

Requisito: 7

Enunciato: Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, eccetto il caso in cui le zone sensibili non possano essere definite con una forma geometrica valida.

Riferimenti WCAG 1.0: 9.1

Riferimenti Sec. 508: 1194.22 (f)

Torna all'elenco

Requisito: 8

Enunciato: Se sono utilizzate mappe immagine lato server, fornire i collegamenti di testo alternativi necessari ad ottenere tutte le informazioni o i servizi raggiungibili tramite l'interazione con la mappa.

Riferimenti WCAG 1.0: 1.2

Riferimenti Sec. 508: 1194.22 (e)

Commento al requisito 8

Considero questo requisito insufficiente a garantire l'accessibilità delle mappe immagine.

Propongo di estendere la richiesta di collegamenti testuali alternativi anche alla mappe immagine sul lato client. Infatti il testo alternativo contenuto in ciascuna area sensibile di una mappa è un ausilio adatto ad utenti ciechi, non ad utenti ipovedenti o con difficoltà motorie. Provate ad immaginare degli ipovedenti o dei motulesi alle prese con una tipica mappa immagine, costituita da una cartina dell'Italia alta all'incirca 300 pixel, contenente al suo interno venti diverse aree sensibili posizionate in modo da corrispondere alle venti regioni in cui è suddiviso il Paese. Pensate che sia facile per questi utenti identificare le zone di pochi pixel che rappresentano il Molise e la Valle d'Aosta, e poi cliccarvi sopra? Penso proprio di no.

Credo sia indispensabile corredare ogni mappa immagine, lato server o lato client, di equivalenti e ben visibili collegamenti testuali, che replichino i contenuti di tutte le aree sensibili della mappa.

Torna all'elenco

Requisito: 9

Enunciato: Usare elementi (marcatori) ed attributi per descrivere i contenuti e per identificare le intestazioni di righe e colonne all’interno di tabelle di dati.

Riferimenti WCAG 1.0: 5.1, 5.5, 5.6

Riferimenti Sec. 508: 1194.22 (g)

Commento al requisito 9

Non so se è previsto un ampliamento di questo studio, che aggiunga glossario e definizioni all'elenco dei requisiti. Se non è previsto, insisto vivamente affinché si valuti l'importanza di questa aggiunta. A partire dal requisito 9 si comincia a far riferimento alle tabelle di dati. So per esperienza che la distinzione tra una tabella di dati (data table, per gli amanti dell'inglese) ed una tabella d'impaginazione (layout table in inglese) non è per nulla chiara. Si tratta di concetti piuttosto sottili, che richiedono di essere opportunamente chiariti per mezzo di definizioni ed esempi.

Per chi volesse avere un'idea del problema a cui mi riferisco, rimando ad un capitolo della mia guida all'accessibilità pubblicata lo scorso anno: http://www.diodati.org/scritti/2004/guida/ele_acc30.asp.

Torna all'elenco

Requisito: 10

Enunciato: Usare elementi (marcatori) per associare le celle di dati e le celle di intestazione nelle tabelle di dati che hanno due o più livelli logici di intestazione di righe o colonne.

Riferimenti WCAG 1.0: 5.2

Riferimenti Sec. 508: 1194.22 (h)

Torna all'elenco

Requisito: 11

Enunciato: Usare i fogli di stile per controllare l’impaginazione e la presentazione 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 Sec. 508: 1194.22 (d)

Commento al requisito 11

Quest'enunciato distingue secondo me impropriamente "impaginazione" da "presentazione". L'impaginazione è una forma di presentazione; non occorrono due termini: basta "presentazione", che è più generale di "impaginazione", comprendendo per esempio anche la presentazione auditiva di un documento. La frase potrebbe dunque essere "asciugata" e resa meno confusiva eliminando la parola "impaginazione".

Torna all'elenco

Requisito: 12

Enunciato: L’impaginazione, la presentazione e i contenuti testuali di una pagina devono potersi adattare all’interfaccia utilizzata dall’utente, senza sovrapposizioni o perdita di informazioni in caso di ridimensionamento (ingrandimento o riduzione di visualizzazione e/o dei caratteri).

Riferimenti WCAG 1.0: 3.4

Riferimenti Sec. 508: Non presente

Commento al requisito 12

Anche questo enunciato mi sembra impreciso. Lo riformulerei nel modo seguente: Il contenuto di un documento, se visualizzato attraverso un'interfaccia grafica, deve potersi adattare alle dimensioni della finestra del programma utilizzato. Deve consentire inoltre l'ingrandimento ed il rimpicciolimento dei caratteri da parte dell'utente, senza che risulti compromessa la leggibilità del contenuto.

Per consentire, poi, una vera applicabilità del requisito, occorre a mio parere specificare i limiti dell'ingrandimento e del rimpicciolimento dei caratteri, dal momento che qualsiasi tipo di impaginazione, anche la più curata dal punto di vista dell'accessibilità, non è mai infinitamente ridimensionabile.

Propongo di definire questi limiti come segue: Il requisito 12 risulta soddisfatto, se una pagina, visualizzata alla risoluzione di 800 x 600 pixel, può essere ingrandita fino al 200% senza che si verifichino sovrapposizioni tra due o più oggetti presenti nella pagina, e se può essere rimpicciolita fino al 75% senza che i caratteri delle scritte perdano la loro leggibilità.

Fissare tali limiti è anche utile dal punto di vista della determinazione della grandezza base dei caratteri. La sola ridimensionabilità, infatti, non basta a garantire una vera accessibilità del contenuto. A causa dei limiti di Internet Explorer, il browser tuttora più diffuso, i caratteri di una pagina non possono essere ingranditi oltre una certa misura (il "molto grande" del menu "Visualizza", corrispondente all'incirca al 130% di Mozilla). Ciò comporta una grave conseguenza per l'accessibilità: se la grandezza base dei caratteri è fissata ad una misura inferiore al 100% (che è la grandezza predefinita dei browser, corrispondente all'incirca ad un corpo 12), l'utente ipovedente non ha a disposizione ingrandimenti sufficienti a raggiungere una accettabile leggibilità del testo. Stabilire perciò che i caratteri devono rimanere singolarmente riconoscibili anche se ridotti al 75% impone agli sviluppatori di partire da una grandezza base prossima al 100%, misura in genere sufficiente a garantire una buona leggibilità per gli ipovedenti anche utilizzando Internet Explorer.

Torna all'elenco

Requisito: 13

Enunciato: Evitare l’uso di tabelle per l’impaginazione. Qualora si utilizzino le tabelle a tale scopo, assicurarsi che il loro contenuto sia comprensibile quando esse sono lette in modo linearizzato e non associarvi gli elementi (marcatori) richiesti per la descrizione di una tabella dati, essendo tale associazione impropria in questo caso. FA eccezione (in HTML e XHTML) l'attributo "summary" che può essere utilizzato per descrivere l'eventuale funzione della tabella nella struttura della pagina.

Riferimenti WCAG 1.0: 5.3, 5.4

Riferimenti Sec. 508: Non presente

Commento al requisito 13

La prima parte di tale enunciato ricalca il contenuto del punto di controllo 5.3 delle WCAG 1.0. A differenza di quest'ultimo, ricorre però al solito discorso - che considero controproducente - del vietare, ma fino ad un certo punto. Vi si dice, infatti: Evitare l’uso di tabelle per l’impaginazione. Qualora si utilizzino le tabelle a tale scopo... ecc.. Ancora una volta, prima si richiede di evitare una certa cosa (le tabelle d'impaginazione), ma subito dopo si ammette che si usi, sia pure con una limitazione, ciò che doveva essere evitato.

In WCAG 1.0 5.3, invece, molto più linearmente si dice: Do not use tables for layout unless the table makes sense when linearized. Cioè: non usare tabelle a scopo d'impaginazione a meno che la tabella abbia senso una volta linearizzata. Molto meglio sarebbe stato riprodurre alla lettera il dettato di questo punto di controllo.

La seconda parte dell'enunciato introduce poi una vera e propria inesattezza. Dice: ...non associarvi [alla tabella d'impaginazione] gli elementi (marcatori) richiesti per la descrizione di una tabella dati, essendo tale associazione impropria in questo caso.

L'inesattezza sta nel fatto che non è sempre vero che non sia possibile identificare delle celle d'intestazione (elementi TH) all'interno di tabelle usate a scopo d'impaginazione. L'esempio che presento alla fine del capitolo della mia guida all'accessibilità indicato nel commento al requisito 9 ne è una prova, credo, abbastanza evidente.

Il fatto è che una tabella di dati ed una tabella d'impaginazione non sono due opposti assoluti. Esistono tabelle che sono usate principalmente a scopo d'impaginazione, cioè per posizionare i contenuti in posti precisi della pagina, le quali contengono però dei sottoinsiemi di celle organizzati come tabelle di dati. Per questi sottoinsiemi l'uso di TH, nonché degli attributi per associare le celle di dati con le relative celle d'intestazione, è assolutamente legittimo. Forse consapevoli di ciò, gli estensori delle WCAG 1.0 hanno formulato il punto di controllo 5.4, su cui è modellata la seconda parte del requisito 13, in modo da lasciare aperta la possibilità di usare quegli elementi che vengono qui invece proibiti: If a table is used for layout, do not use any structural markup for the purpose of visual formatting. Tradotto: Se una tabella è usata a scopo d'impaginazione, non usare alcun codice di marcatura strutturale con il proposito di ottenere effetti di formattazione.

Come si vede, il significato è ben diverso: non si dice di non usare codice di marcatura strutturale, ma di non utilizzarlo per soli scopi di presentazione visuale. Anche in questo caso, meglio sarebbe stato se la seconda parte dell'enunciato del requisito 13 avesse ricalcato integralmente il dettato di WCAG 1.0 5.4.

Torna all'elenco

Requisito: 14

Enunciato: Nei moduli (form), associare in maniera esplicita le etichette ai loro controlli, posizionandole in modo da agevolare la compilazione dei campi a chi utilizza le tecnologie assistive.

Riferimenti WCAG 1.0: 10.2, 12.4

Riferimenti Sec. 508: 1194.22 (n)

Torna all'elenco

Requisito: 15

Enunciato:

Assicurarsi che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile, fornire informazione equivalente in una pagina accessibile alternativa.

Riferimenti WCAG 1.0: 6.3

Riferimenti Sec. 508: 1194.22 (l), 1194.22 (m)

Commento al requisito 15

Questo enunciato è una traduzione letterale, ma non troppo precisa, del punto di controllo 6.3 delle WCAG 1.0. Riformulerei il testo sostituendo la parola "utilizzabili" con la parola "usabili". Tale sostituzione è giustificata secondo me dal fatto che la parola inglese usable, presente in WCAG 1.0 6.3, va intesa nel significato proprio dell'usabilità e non in quello di una generica utilizzabilità.

Anche in questo requisito, come nel corrispondente punto di controllo 6.3 delle WCAG 1.0, si cela a mio parere una notevole ambiguità. L'invito a fornire "informazioni equivalenti" su un'altra pagina, qualora quella su cui sono presenti script, applet ecc. non sia più usabile senza il supporto a javascript, java, ecc., può indurre gli sviluppatori inesperti a credere che il compito dell'accessibilità si riduca a descrivere in forma testuale - per esempio utilizzando un elemento noscript oppure realizzando una pagina alternativa ad hoc - cosa mostra o cosa permette di fare l'oggetto di programmazione non accessibile.

Le cose non sono invece così semplici. Occorre, senza dubbio, fornire, attraverso noscript o altri criteri, una spiegazione testuale dei contenuti o dei servizi veicolati attraverso script e oggetti di programmazione. Ma questo è solo un surrogato, destinato a chi utilizza browser testuali come Lynx, privi di supporto a javascript e java. A vantaggio di chi utilizza invece tecnologie assistive di ultima e penultima generazione, come ad esempio Jaws di Freedom Scientific, il compito dell'accessibilista consiste nel rendere direttamente accessibili script, applet e altri oggetti di programmazione.

Questa richiesta è presente nei successivi requisiti 16 e 17, ma la possibilità di una cattiva interpretazione del requisito 15 rimane. A mio parere l'ambiguità può essere eliminata dall'enunciato di questo requisito, togliendo il riferimento ad un'"informazione equivalente". Come ho chiarito con l'esempio della scacchiera dinamica nel commento al requisito 3, non può esistere un'informazione fornita in (X)HTML che sia davvero equivalente al contenuto di un oggetto di programmazione dinamico. Un'informazione veramente equivalente può essere fornita solo all'interno dello stesso oggetto di programmazione. Per esempio, nel caso della scacchiera in Java, rendendo l'interfaccia accessibile alle tecnologie assistive e fornendo anche in forma testuale l'informazione sulla posizione dei pezzi in un certo momento della partita.

L'informazione testuale alternativa che può essere fornita tramite noscript o il contenuto testuale di object è in molti casi una mera descrizione generica, un lontano surrogato. Non la definirei perciò come un'informazione equivalente, ma come un'informazione alternativa (che può o no, a seconda dei casi, essere equivalente). Userei, invece, la terminologia "informazione equivalente" solo per le informazioni alternative presentate all'interno di uno script, di un applet o di un oggetto resi accessibili, aggiornate dinamicamente in concomitanza del variare dei contenuti "principali" presentati in forma grafica o multimediale.

Torna all'elenco

Requisito: 16

Enunciato: Assicurarsi che i gestori di eventi che attivano script, applet oppure altri oggetti di programmazione o che possiedono comunque una loro specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Riferimenti WCAG 1.0: 6.4, 9.2

Riferimenti Sec. 508: 1194.22 (l), 1194.22 (m)

Torna all'elenco

Requisito: 17

Enunciato: Fare in modo che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzino tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili o compatibili con le tecnologie assistive.

Riferimenti WCAG 1.0: 8.1

Riferimenti Sec. 508: 1194.22 (l), 1194.22 (m)

Commento al requisito 17

Questo requisito è una riformulazione in italiano del punto di controllo 8.1 delle WCAG 1.0.

L'enunciato in questo caso non è ambiguo, ma crea una regola secondo me non sufficiente a garantire una vera accessibilità dei contenuti.

Chiarisco perché. L'inghippo sta nell'uso della parola "compatibili". Mentre un javascript può essere reso direttamente accessibile alle tecnologie assistive, utilizzando per esempio le precauzioni descritte al punto (l) del paragrafo 1194.22 di Section 508, un documento realizzato in formato PDF ha bisogno, per essere caricato all'interno di un browser, dell'installazione preventiva di Adobe Reader, un programma ausiliario (un plug-in, per dirla in inglese) che si integra con il browser. Se ci limitiamo a ritenere per l'accessibilità sufficiente la sola compatibilità, il compito potrebbe ritenersi concluso una volta che ci si sia accertati che la tecnologia assistiva, appoggiandosi ad un browser come fa Jaws con Internet Explorer, consenta il caricamento di un documento in PDF per mezzo di Adobe Reader.

Il problema è che spesso non basta ai fini dell'accessibilità che un documento possa essere caricato nel browser grazie ad un plug-in preinstallato. Non basta insomma che il documento sia astrattamente "compatibile" con la tecnologia assistiva utilizzata. Occorre anche e soprattutto che il documento sia reso accessibile all'interno del programma ausiliario compatibile. Un file PDF, per esempio, può essere salvato in forma protetta dalla copia (lo si fa in genere per difendere il diritto d'autore). E un file PDF protetto dalla copia risulta non leggibile da Jaws, benché Adobe Reader, il programma ausiliario, sia compatibile con la tecnologia assistiva.

Se perciò giudichiamo la "compatibilità" come equivalente alla "diretta accessibilità", rischiamo di creare un grosso problema di accessibilità. Potremmo trovarci, per esempio, con un sito che viene dichiarato accessibile benché contenga una moltitudine di documenti in PDF protetti dalla copia e perciò materialmente illeggibili per mezzo di una tecnologia assistiva come Jaws.

Non per niente, il punto (m) di Section 508 1194.22 raccomanda che si fornisca, nella pagina che richiede l'uso di un plug-in, un collegamento ad un programma ausiliario compatibile con il formato del documento da leggere, che sia però accessibile in base a tutti i requisiti elencati nel precedente paragrafo 1194.21 di Section 508 (Software Applications and Operating Systems).

Il mio suggerimento è dunque di riformulare l'enunciato, in modo da chiarire che non solo i programmi ausiliari devono essere compatibili con le tecnologie assistive, ma i documenti da caricare per mezzo dei programmi ausiliari devono essere resi accessibili alle tecnologie assistive, il che può essere ottenuto sia evitando di salvare quei documenti utilizzando opzioni incompatibili con la loro lettura da parte delle tecnologie assistive sia aggiungendo ai documenti specifiche caratteristiche di accessibilità, se previste dal software che si sta adoperando. Tanto per rimanere al formato PDF, la Adobe, per esempio, mette a disposizione degli utenti precise soluzioni per migliorare l'accessibilità dei documenti salvati in formato PDF.

Torna all'elenco

Requisito: 18

Enunciato: Qualora un filmato o una presentazione multimediale temporizzata siano indispensabili alla informazione fornita o al servizio erogato, sincronizzare con essi l’alternativa testuale equivalente, in forma di sotto-titolazione o descrizione vocale, oppure associarvi un riassunto o una semplice etichetta, a seconda del livello di importanza e delle difficoltà di realizzazione nel caso di presentazioni in tempo reale.

Riferimenti WCAG 1.0: 1.4

Riferimenti Sec. 508: 1194.22 (b)

Torna all'elenco

Requisito: 19

Enunciato: Rendere chiara la destinazione di ogni collegamento ipertestuale (link) e associarvi testi alternativi significativi anche se letti fuori dal loro contesto. Prevedere meccanismi che consentano di evitare letture ripetitive di sequenze di collegamenti cumuni a più pagine.

Riferimenti WCAG 1.0: 13.1, 13.6

Riferimenti Sec. 508: 1194.22 (o)

Commento al requisito 19

La prima parte dell'enunciato non interpreta correttamente la raccomandazione contenuta nel punto di controllo 13.1 delle WCAG 1.0, a cui si ispira. Nella spiegazione di quello è scritto: Link text should be meaningful enough to make sense when read out of context. Tradotto: Il testo di un collegamento dovrebbe essere sufficientemente chiaro da conservare il proprio senso quando letto fuori contesto. Non sono cioè i testi alternativi che devono rimanere significativi se letti fuori contesto, ma il testo stesso del collegamento.

Tra l'altro, l'espressione "testo alternativo" non è corretta in relazione ad un collegamento ipertestuale. Sono le immagini su cui viene eventualmente applicato un collegamento a dover essere dotate di un testo alternativo, non il collegamento in sé: per l' elemento A, l'attributo alt non è infatti neppure previsto dalle specifiche HTML 4.

L'enunciato, ricalcando le spiegazioni di WCAG 1.0 13.1, potrebbe poi essere ampliato con un riferimento all'uso, in certi casi chiarificatore, dell' attributo title, a supporto delle informazioni contenute nel testo visibile di un collegamento ipertestuale.

Anche la parte finale dell'enunciato ha qualcosa che non va. E' scritto: Prevedere meccanismi che consentano di evitare letture ripetitive di sequenze di collegamenti comuni a più pagine. Perché solo sequenze di collegamenti comuni a più pagine? Evidentemente gli estensori di questo requisito, influenzati dall'enunciato di Section 508 1194.22 (o), stavano pensando ad un tipico menu di navigazione, che si ripete più o meno uguale su tutte le pagine di un sito. Tuttavia è opportuna la creazione di un link di salto non solo per un elenco di link comune a più pagine, ma per qualsiasi sequenza di link che si frapponga tra l'inizio di una pagina web ed il suo contenuto principale. Anche se si tratta di una sequenza che compare in una sola pagina, l'utente che ha già visitato più di una volta quella pagina con un sintetizzatore e vuole andare direttamente al contenuto che gli interessa, non dovrebbe essere costretto a sorbirsi l'intera serie dei link, solo perché, non essendo comune ad altre pagine, non è stato previsto un link di salto al suo inizio.

Non so se perché avevano previsto anche questa possibilità, gli estensori delle WCAG 1.0 hanno confezionato il punto di controllo 13.6 nel modo seguente: Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. Tradotto: Raggruppate i collegamenti correlati, identificate il gruppo (per i programmi utente), e, finché i programmi utente non saranno in grado di farlo da soli, fornite un modo per saltare il gruppo.

Come si vede, si parla di gruppi di link correlati, senza specificare se si tratti di gruppi comuni anche ad altre pagine (cioè di un tipico menu di navigazione) o di gruppi presenti solo sulla pagina di cui ci si sta occupando.

In questo caso, secondo me l'enunciato di WCAG 1.0 13.6 è preferibile a quello di Section 508 1194.22 (o). Meglio sarebbe stato se il requisito 19 avesse riportato pari pari il testo del punto di controllo 13.6 delle WCAG, piuttosto che riformularlo sulla base dell'interpretazione fornita da Section 508.

Torna all'elenco

Requisito: 20

Enunciato: Se, nonostante ogni sforzo, non si può creare una pagina accessibile, fornire un collegamento a una pagina alternativa che usi le tecnologie come definite al punto 1, sia accessibile, contenga informazioni e funzionalità equivalenti, e sia aggiornata con la stessa frequenza della pagina originale non accessibile.

Riferimenti WCAG 1.0: 11.4

Riferimenti Sec. 508: 1194.22 (k)

Commento al requisito 20

Sia le WCAG 1.0 sia Section 508 concordano quasi alla lettera su questa raccomandazione: create una pagina alternativa dotata di informazioni o funzionalità equivalenti ad una certa pagina che, nonostante i vostri sforzi, è rimasta inaccessibile. In più, aggiornate la versione alternativa almeno altrettanto spesso della "sorella" inaccessibile. Section 508 precisa anche che la versione alternativa deve essere una pagina di solo testo, mentre WCAG 1.0 11.4, ripreso dal requisito 20 di questo studio, si limita a parlare di una generica pagina accessibile.

Scostandomi dalla scelta fatta dagli estensori dello studio qui in esame, sono dell'opinione che non avrebbero dovuto inserire tale raccomandazione tra i requisiti richiesti per l'accessibilità, quantomeno non nella forma in cui è stata inserita.

Il problema principale sta in quel nonostante ogni sforzo presente nell'enunciato. Cosa vuol dire precisamente? Esistono delle fattispecie concrete a cui richiamarsi come testimonianze di sforzi verso l'accessibilità che non hanno avuto successo?

La vaghezza di quel nonostante ogni sforzo giustifica, di fatto, le versioni alternative di un sito: se, infatti, è accettabile per una pagina il criterio di un imprecisato "sforzo" senza successo, cosa vieta di estendere lo stesso criterio a tutte le pagine di un sito?

Ora, innanzitutto è cosa nota che gli internauti con disabilità odiano visceralmente le versioni alternative di pagine e siti. Ma, più ancora, va chiarito bene che, se è stato materialmente impossibile rendere accessibili le informazioni e/o i servizi contenuti in una data pagina web, non può esistere - checché ne dicano WCAG 1.0 e Section 508 - alcuna alternativa veramente equivalente ai servizi ed alle informazioni contenuti nella pagina inaccessibile associata.

Per capire la precedente affermazione, domandiamoci perché una pagina è inaccessibile. E' inaccessibile, forse, perché contiene delle complesse tabelle di dati? Bene: posso certamente rendere quelle tabelle meno inaccessibili utilizzando gli appositi elementi e attributi strutturali definiti nelle WCAG 1.0 ed in Section 508. (Potrò, magari, creare una versione alternativa opportunamente linearizzata delle tabelle, ma è un di più.)

O è inaccessibile forse perché si tratta di un sito realizzato in Flash? Sì? Bene: allora lo sforzo consisterà nel non utilizzare Flash e nel rifare la pagina ed il sito in XHTML e CSS.

O forse la pagina è inaccessibile perché è scritta con un linguaggio contorto, pedante ed inadatto al pubblico a cui si rivolge?

In tutti e tre i casi citati, e in molti altri non citati, è senza'altro possibile rendere i contenuti direttamente accessibili, o meno inaccessibili, senza bisogno di versioni alternative. Se si ricorre alle versioni alternative è quasi sempre perché non si è voluto rinunciare alla versione base inaccessibile: non si è fatto in realtà alcuno sforzo per modificare quella versione.

La conclusione è che, sforzandosi, le pagine diventano accessibili, o, se non lo diventano, è perché si tratta di contenuti che non possono in nessun caso, neppure su una pagina alternativa, essere resi accessibili (come è il caso, per esempio, di un simulatore di volo, se deve essere usato come un simulatore di volo). Dunque o si concede che le versioni alternative sono sempre lecite (e questa non è una buona cosa per l'accessibilità...) oppure si elimina questo requisito. Comunque si decida di fare, il riferimento ad imprecisati sforzi senza successo è del tutto ambiguo e fuorviante.

Torna all'elenco

*Leggi: 1.2) Metodologie per la verifica tecnica
*Vai a: Diodati.org > Guide, articoli, scritti > Studio (commentato) sulle linee guida
*Scrivi: info@diodati.org
*Ultima modifica: 20/10/2012 ore 02:02