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

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

Studio (commentato) sulle linee guida per la verifica dell'accessibilità

di Autori Vari. Commenti di Michele Diodati
(18 maggio 2004)

[Salta al sommario] Il testo riportato di seguito riproduce il documento intitolato "Studio sulle linee guida recanti i requisiti tecnici e i diversi livelli per l'accessibilità e le metodologie tecniche per la verifica dell'accessibilità (legge 4 del 2004, art.11 comma a e b)", pubblicato il 12 maggio 2004 sul sito PubbliAccesso.gov.it a partire dalla pagina http://www.pubbliaccesso.gov.it/biblioteca/documentazione/studio_lineeguida/index.htm.

Tale studio costituirà la base per il decreto legge che fisserà i metodi e le regole per la verifica dell'accessibilità dei siti che ricadono sotto l'ambito di applicazione della legge 4/2004, meglio nota come "legge Stanca". La pubblicazione dello studio prima dell'emanazione del decreto fa presumere la volontà da parte del legislatore di recepire le indicazioni dei professionisti del settore, circa il contenuto dello studio medesimo.

Provo dunque a dare il mio contributo. Il testo ufficiale dello studio, che riporto di seguito con la stessa suddivisione che ha sul sito PubbliAccesso.gov.it, appare così intervallato dai miei commenti, messi nei punti che secondo me sono controversi, necessitano di chiarimenti oppure di modifiche migliorative.

Ho inoltre aggiunto, nella pagina dei requisiti tecnici da verificare, i collegamenti a tutti i punti di controllo delle WCAG 1.0 e a tutte le raccomandazioni di Section 508 citate come riferimenti.

Alla fine del testo dello studio riporto le mie considerazioni conclusive. Tutti i lettori sono invitati a dare il loro contributo, proponendo il loro punto di vista sullo studio e sui miei commenti in proposito. Allo scopo è possibile utilizzare i forum accessibili di Diodati.org.

Indice

Premessa

La legge 9 gennaio 2004, n. 4 "Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici" richiede di stabilire, con decreto del Ministro per l'innovazione e le tecnologie (Art. 11):

Il testo integrale della legge è disponibile alla pagina http://www.diodati.org/scritti/2004/legge4_2004/index.asp.

La definizione dei requisiti tecnici di cui al punto a) costituisce un punto di riferimento per le pubbliche amministrazioni:

Ne consegue che i requisiti tecnici e i livelli per l'accessibilità devono essere definiti per:

Presumo che il si devono anche stabilite che si legge al punto 3 sia un errore per vengono anche stabilite.

In merito ai siti Internet, nell'ambito della Segreteria tecnico-scientifica della "Commissione interministeriale permanente per l'impiego delle tecnologie dell'informazione e della comunicazione a favore delle categorie deboli o svantaggiate", sono stati costituiti due specifici gruppi di lavoro denominati rispettivamente "Metodologia" e "Regole tecniche", dei quali fanno parte esperti in materia appartenenti a Pubblica Amministrazione Centrale e Locale, Associazioni di categoria di disabili, CNR, Università, Associazioni di produttori di hardware e software e di sviluppatori.

I due gruppi di lavoro hanno elaborato il presente "Studio sulle linee guida recanti i requisiti tecnici e i diversi livelli per l'accessibilità e le metodologie tecniche per la verifica dell'accessibilità" che è finalizzato alla progettazione, realizzazione e valutazione dei siti Web pubblici e che intende fornire un contributo tecnico per la stesura del decreto ministeriale.

Per la definizione delle linee guida e dei requisiti tecnici relative ai beni informatici e agli servizi informatici è già all'opera un apposito gruppo di lavoro.

Hanno collaborato al presente studio:

Introduzione

Nel presente documento sono descritte:

Nello schema di Regolamento di Attuazione di cui all’art. 10 della Legge sono previsti due tipi di verifica della accessibilità:

Trovo poco chiara la terminologia adottata per i due tipi di verifica. Le parole "tecnica" e "soggettiva" non sono semanticamente opposte né implicano una totale indipendenza dei reciproci domini: una verifica "soggettiva" può essere svolta in base a tecniche, e, viceversa, una verifica tecnica può essere fatta da soggetti differenti.

Mi sembra più opportuno ricorrere ad una distinzione che sia intuitivamente chiara tra i due concetti. Per esempio: verifica "teorica" (o "oggettiva"), quella condotta da esperti sulla base del controllo di requisiti tecnici definiti a priori; verifica "pratica" (o "soggettiva"), quella condotta per mezzo di prove empiriche su utenti selezionati tra il pubblico di riferimento del sito.

L'uso di una terminologia il più possibile non ambigua è il modo migliore per garantire una reale applicabilità dei criteri definiti per le verifiche di accessibilità.

I principi informatori delle linee guida, dei parametri tecnici e delle metodologie presentate in questo documento sono ispirate alle Risoluzioni, Direttive, Comunicazioni e Decisioni dell’Unione Europea in merito alla non discriminazione e alla accessibilità alle nuove tecnologie delle persone con disabilità.

Per quanto riguarda la verifica tecnica si è anche tenuto conto di quanto indicato:

Il sito WAI è consultabile a partire da http://www.w3.org/WAI/. Il testo in inglese del paragrafo 1194.22 della Section 508, insieme con molte altre informazioni collegate, è disponibile alla pagina http://www.access-board.gov/sec508/508standards.htm. Un mio articolo divulgativo sulle regole di accessibilità per il Web contenute in Section 508 è disponibile a partire da http://www.diodati.org/scritti/2002/sec508/index.asp. Il documento sull'accessibilità prodotto dal consorzio ISO ("Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces") non è disponibile per la consultazione gratuita e può essere acquistato tramite il sito ISO.

Per quanto riguarda la verifica soggettiva, si è fatto riferimento anche alle seguenti normative e linee guida internazionali:

Brevi informazioni generali su ISO/IEC 9126-1 e su ISO/IEC 9241-11 sono disponibili rispettivamente qui: http://www.usability.serco.com/trump/resources/standards.htm#9126-1 e qui: http://www.usability.serco.com/trump/resources/standards.htm#9241-1. Un'introduzione al concetto di Design for All è disponibile a partire dalla pagina http://www.design-for-all.info/11686158.xml.

Per il raggiungimento delle caratteristiche di accessibilità dei siti internet e delle applicazioni basate sulle tecnologie internet (web based) sono stati dettagliati i seguenti insiemi di riferimento:

La rispondenza a tutti i requisiti da sottoporre a verifica tecnica costituisce la condizione minima di accessibilità di una pagina Web e di una applicazione web based.

Cosa significa precisamente? Che una pagina web, per passare alla fase della verifica soggettiva, deve prima soddisfare tutti i requisiti tecnici previsti dallo studio? Se è così, il vincolo andrebbe espresso esplicitamente.

1) Siti Internet e applicazioni web-based

Si intendono compresi in questa sezione sia i siti internet di tipo interattivo e non interattivo, che le applicazioni basate su tecnologie web, siano esse in linea oppure no.

Credo che sarebbe stato opportuno precisare meglio, magari con un piccolo glossario, i significati delle parole qui utilizzate, dal momento che la loro comprensione non ambigua è fondamentale per capire cosa deve essere reso accessibile e cosa no.

E vero che si dice che vanno resi accessibili sia i siti interattivi che quelli non interattivi, ma cosa si intende precisamente in questo studio per sito di tipo interattivo? L'"interattività" è intesa come la capacità di un sito di rielaborare i propri contenuti in base alle scelte dell'utente oppure no? Si riferisce alla presenza di javascript e/o strumenti di personalizzazione lato server? Si riferisce alla presenza di moduli da compilare a cura dell'utente?

Cosa si intende poi per "applicazioni"? Un sito "dinamico" - cioè gestito tramite basi dati e pagine che contengono codice di programmazione, in grado dunque di svolgere dei compiti variabili in base alle azioni degli utenti e non solo di presentare dei contenuti fissi - è considerato un'"applicazione" oppure no? Un'"applicazione" è da intendersi come qualcosa di diverso da un sito web?

E cosa si intende precisamente per "tecnologie web"? XHTML e CSS sono sicuramente da considerarsi tecnologie web. Ma javascript, XML e tutta la famiglia di linguaggi basati su XML? Qual è, insomma, il limite preciso in cui un prodotto finisce di essere un'applicazione basata su tecnologie web e diventa qualche altra cosa?

Se sviluppo per una Pubblica Amministrazione un CD-ROM (cioè un'applicazione da consultarsi non in linea) usando HTML e CSS, ho l'obbligo di renderlo accessibile usando le verifiche di seguito descritte? E se invece sviluppo il mio CD-ROM con strumenti autoriali proprietari (p.es. Macromedia), sarò esentato dalle verifiche di seguito indicate?

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

1.2) Metodologie per la verifica tecnica

Allo scopo di accertare la conformità della pagina Web o della applicazione Web-based a tutti i requisiti indicati nella tabella A, si suggerisce una metodologia di valutazione che fa ricorso a strumenti automatici, a strumenti semiautomatici e alle conoscenze dell’esperto tecnico. Essa è mutuata da quella proposta dal W3C in http://www.w3.org/WAI/EO/Drafts/impl/eval/ e consiste dei seguenti passi:

La valutazione si conclude con la predisposizione di un rapporto nel quale l’esperto tecnico indica la conformità ai singoli requisiti della pagina esaminata.

L’esperto tecnico è un professionista delle tecnologie Web che ha una adeguata esperienza e una adeguata conoscenza sulle problematiche e sulle tecniche per l’accessibilità equivalenti a quelle fornite dal W3C - WAI nel suo programma Education & Outreach.

Sulla formazione professionale dell'esperto tecnico

Credo sia di fondamentale importanza che venga dettagliato ufficialmente, in questo studio o altrove, parallelamente ai requisiti tecnici da valutare, il bagaglio di conoscenze che l'esperto di accessibilità deve possedere. Bisogna cioè dare un contenuto non equivocabile all'aggettivo "adeguato" che ricorre ben due volte ([...] una adeguata esperienza e una adeguata conoscenza [...]) nel periodo che precede questo commento.

Un'idea della quantità di conoscenze necessaria la si può ricavare dalla lettura della pagina Review Teams for Evaluating Web Site Accessibility sul sito W3C, in particolare dal paragrafo Expertise of Review Teams.

1.3) Requisiti da sottoporre a verifica soggettiva

Dalle fonti citate nella Introduzione in merito alla verifica soggettiva sono state ricavate le seguenti undici caratteristiche che verranno considerate in modo da stabilire diversi livelli progressivi di accessibilità e fruibilità delle informazioni (es. livello *, livello **, livello ***).

Per ciascuna caratteristica si riportano alcuni esempi di sua applicazione ad un sito web.

  1. percezione: le informazioni e i comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili (Livello *).

    Esempi:

    • Strutturare l’informazione su più livelli: dalla sintesi al documento completo
    • Stabilire una scala di importanza per le informazioni contenute in una pagina e presentarle in ordine decrescente : prima le più importanti
    • Aumentare la leggibilità dei contenuti utilizzando frasi brevi e facilmente identificabili
    • Evitare pagine troppo lunghe
    Commento al requisito 1

    O c'è qualcosa di clamoroso che mi sfugge oppure tutti gli esempi di questo primo punto sono sbagliati.

    Tutti riguardano, infatti, aspetti che facilitano - o dovrebbero facilitare - la comprensione dei contenuti, non la loro percezione. Usare un adeguato livello di contrasto tra primo piano e sfondo: quello sì che riguarderebbe la percezione. Ma creare un sommario dei contenuti, mettere le informazioni importanti all'inizio, scrivere frasi brevi sono tutte accortezze che influenzano la comprensibilità del contenuto, non la sua percepibilità (si veda anche, in proposito, la spiegazione presente nelle WCAG 1.0 sui due metodi generali su cui le linee guida sono basate: ensuring graceful transformation, and making content understandable and navigable. Il primo metodo riguarda la percepibilità, il secondo la comprensibilità dei contenuti. Gli esempi qui riportati sono tipici del secondo metodo).

    L'ultimo esempio, poi, indipendentemente da se riguardi la percezione o la comprensione, è ambiguo nella formulazione e probabilmente inesatto. Innanzitutto bisognerebbe stabilire cosa si intende per "pagine troppo lunghe": 2.000 caratteri, 3.000 caratteri, 15.000 caratteri? Non è detto, inoltre, che fare pagine brevi sia sempre la miglior soluzione: dipende dall'argomento trattato e dal pubblico a cui ci si rivolge.

  2. uso: le informazioni e i comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare (Livello *).

    Esempi:

    • Evidenziare la struttura dei contenuti della pagina con intestazioni, liste, ecc…
    • Utilizzare un linguaggio comprensibile alla grande maggioranza dei destinatari
    • Rendere riconoscibile ai programmi utente, ivi comprese le tecnologie assistive, la lingua principale della pagina e i cambiamenti di lingua interni, almeno per grandi blocchi di testo
    • Prevedere un glossario dei termini tecnici
    • Rendere riconoscibile ai programmi utente, ivi comprese le tecnologie assistive, la lingua principale della pagina e i cambiamenti di lingua interni, almeno per grandi blocchi di testo
    • Fornire versioni stampabili dei documenti, con indicazione esplicita dell’ URL da cui il documento è stampato
    • Ridurre al minimo possibile le operazioni necessarie al raggiungimento di un obiettivo
    • Permettere all’utente di saltare sequenze di link (soprattutto se poste all’inizio della pagina e comuni a tutte le pagine) per arrivare velocemente al contenuto specifico
    Commento al requisito 2

    Anche in questo caso troviamo esempi che generano non pochi problemi.

    Il primo punto dell'elenco sembra sovrapporsi all'esame tecnico, richiesto in precedenza, che dice: Verifica dell’esperto sull’uso degli elementi e degli attributi secondo le specifiche del linguaggio. Ad esempio in HTML: gli elementi Header sono stati utilizzati per strutturare il contenuto e non per ottenere effetti grafici. [...] Ciò dimostra bene, se ce ne fosse bisogno, che è difficile separare in modo chiaro e univoco ciò che riguarda l'analisi tecnica del codice e ciò che riguarda, invece, gli aspetti semantici del contenuto.

    Il secondo punto, veramente fondamentale per l'accessibilità, meriterebbe un capitolo a sé: la semplificazione del linguaggio usato nei documenti pubblicati sul Web costituisce da solo un problema formidabile per l'accessibilità dei siti delle Pubbliche Amministrazioni. Non è pensabile di ridurre una materia così complessa ad un semplice accenno, come abbiamo in questo studio. Rimando per un approfondimento del problema ad alcuni capitoli della mia guida all'accessibilità: http://www.diodati.org/scritti/2004/guida/index.asp#sezione2-3.

    Il terzo punto, quello relativo ai cambi di lingua, risulta duplicato dal quinto, evidentemente riprodotto uguale per errore. La limitazione almeno per grandi blocchi di testo sembra rendere lecito non segnalare i cambi di lingua per singole parole. Dato l'attuale scarso supporto delle tecnologie assistive ai cambi di lingua al volo, mancare di segnalare dei cambi di lingua in una pagina web non cambia le cose all'atto pratico. Il consiglio migliore per raggiungere una buona accessibilità è, in realtà, quello di ricorrere solo in caso di vera necessità all'uso di parole straniere all'interno di un testo in italiano.

    Il sesto punto va in conflitto con la richiesta di usare i linguaggi di marcatura esistenti in modo conforme alle specifiche W3C. Per i fogli di stile disponiamo infatti già del media type print, che ci permette di utilizzare un foglio di stile specifico per la stampa, senza la necessità di ricorrere ad una versione alternativa in (X)HTML della pagina corrente, creata ad hoc per la stampa.

    Il settimo punto non può essere sempre considerato una priorità: in siti molto complessi, allungare di una o due unità la serie delle operazioni per raggiungere un obiettivo può consentire di sfoltire la quantità - spesso enorme - dei menu di navigazione e dei collegamenti presenti in una singola pagina, rendendo più agevole per l'utente la comprensione della struttura generale dei contenuti.

    L'ottavo ed ultimo punto si sovrappone a quanto stabilito dal requisito 19 delle verifiche tecniche.

    In generale, il fatto che le verifiche soggettive ricontrollino in certi casi aspetti già esaminati da chi ha effettuato le verifiche tecniche, mi sembra una fonte di problemi non indifferente. Se le verifiche tecniche devono stabilire la presenza o l'assenza di requisiti oggettivi, allora non serve un successivo esame soggettivo. Viceversa, se non si tratta di requisiti veramente oggettivi, allora non dovrebbero comparire nell'elenco delle verifiche tecniche.

  3. consistenza: stessi simboli, messaggi e azioni devono avere gli stessi significati in tutto l’ambiente (Livello *).

    Esempi:

    • Presentare informazioni e funzioni simili in maniera consistente in tutto il sito: loghi, titoli delle pagine, elementi di navigazione, ecc.
    • Rendere coerente l’impostazione grafica delle pagine in tutto il sito
    • Rendere consistenti i titoli delle pagine con il testo dei link che le indirizzano
    • Mantenere un aspetto grafico coerente per tutti i collegamenti presenti nel sito rispettando il più possibile le convenzioni Web
    • Utilizzare lo stesso tipo di carattere utilizzato per la presentazione di un oggetto in tutte le sue occorrenze nel sito
    Commento al requisito 3

    La cosa da cambiare d'urgenza è il nome del requisito: "consistenza" in italiano significa "solidità, resistenza". E' stata usata questa parola, evidentemente, come traduzione "a orecchio" dell'inglese "consistency" (termine appartenente alla categoria dei cosiddetti "falsi amici"). La parola da utilizzare in italiano è invece "coerenza". Allo stesso modo, vanno eliminate le occorrenze dell'aggettivo "consistente" nei vari esempi riportati, sostituendolo con l'aggettivo "coerente".

    Venendo al contenuto degli esempi, non mi è chiaro che cosa si intenda per "oggetto" nell'ultimo della serie.

    Modificherei anche il testo del terzo esempio nel modo seguente: Rendere coerenti i titoli delle pagine con il testo dei link che le referenziano.

  4. salvaguardia della salute (safety): capacità dell’ambiente di salvaguardare e promuovere il benessere psicofisico dell’utente (Livello *).

    Esempi:

    • Assicurarsi che il movimento degli oggetti, se presente, non provochi disturbi da epilessia fotosensibile
    • Assicurasi che la gestione degli elementi grafici e del contrasto testo/sfondo siano tali da non disturbare la vista
    • Scrivere testi in modo tale da non stancare la vista
  5. sicurezza: capacità dell’ambiente di fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza e riservatezza (Livello *).

    Esempi:

    • Dichiarare in modo esplicito le politiche adottate per la sicurezza delle transazioni
    • Dichiarare in modo esplicito le politiche adottate per la tutela della privacy delle informazioni
    • Avvisare l’utente sulle modalità di gestione e di comportamento di eventuali cookies inviati
    Commento al requisito 5

    Sia il requisito sia gli esempi allegati mi sembrano del tutto indifferenti ed indipendenti rispetto agli scopi dell'accessibilità.

  6. trasparenza: l’ambiente deve comunicare il suo stato e gli effetti delle azioni compiute. All’utente devono essere comunicate le necessarie informazioni per la corretta valutazione della dinamica dell’ambiente (Livello **).

    Esempi:

    • Fornire agli utenti informazioni (feedback) su: dove si trovano, cosa possono fare, dove possono andare
    • Evitare caratteristiche e funzionalità dipendenti da dispositivo
    • Specificare i collegamenti a siti esterni
    • Riportare alla fine d ogni pagina la sua URL, affinché ne sia chiara la provenienza anche quando la pagina stessa sia consultata fuori linea.
    Commento al requisito 6

    A parte l'esempio che dice di evitare caratteristiche e funzionalità dipendenti da dispositivo, gli altri esempi mi sembrano degni di un terzo livello (Livello ***, secondo la simbologia usata in questo studio) piuttosto che di un secondo: mi sembrano infatti precauzioni più vicine agli scopi propri dell'usabilità che a quelli dell'accessibilità in senso stretto.

  7. apprendibilità: capacità dell’ambiente di consentire l’apprendimento del suo utilizzo da parte dell’utente in tempi brevi e con minimo sforzo. (Livello **).

    Esempi:

    • Creare ambienti che riducano al minimo possibile la necessità di apprendimento
    • Fornire modalità semplici di ricerca nel sito
  8. aiuto e documentazione: fornire funzioni di aiuto come guide in linea e documentazione relativi al funzionamento dell’ambiente. Le informazioni di aiuto devono essere facili da trovare e focalizzate sul compito dell’utente (Livello **).

    Esempi:

    • Fornire agli utenti informazioni su dove si trovano, cosa possono fare, dove possono andare
    • Mettere a disposizione una mappa del sito
    • Prevedere che la documentazione e l’help, quando presenti, siano facilmente raggiungibili da ogni pagina e scritti in modo conciso
    Commento al requisito 8

    Il primo esempio è uguale al primo esempio del requisito 6: errore o sovrapposizione voluta?

    Quanto all'oggetto del requisito, non mi è ben chiaro quando si richiede che siano presenti aiuti e documentazione sull'uso dell'interfaccia. Nel caso di siti dotati di funzionalità e servizi particolarmente complessi, avere degli aiuti specifici è certamente utile, se non addirittura indispensabile. Ma in molti altri casi, l'impaginazione prescelta dovrebbe essere autoesplicativa per quanto riguarda l'uso dei contenuti. Anzi, la presenza di documentazione di aiuto su come consultare un sito può essere vista come una sorta di fallimento dei criteri di comunicazione adottati dagli autori.

  9. tolleranza agli errori: l’ambiente deve prevenire gli errori e, qualora questi accadano, devono essere fornite le modalità per recuperare in modo semplice eventuali errori di interazione e devono essere forniti appropriati messaggi che indichino chiaramente il problema e le azioni necessarie per recuperarlo (Livello **).

    Esempi:

    • Guidare l’utente passo passo nelle operazioni complesse
    • Prevedere un sistema di gestione dell’errore di collegamento a pagina inesistente che consenta all’utente di riprendere in percorso
  10. gradevolezza: capacità dell’ambiente di favorire e mantenere l’interesse dell’utente (Livello ***).

    Esempi:

    • Presentare la pagina in modo gradevole e con contenuti leggibili a diverse risoluzioni dello schermo e/o tramite periferiche di output (es. stampa della pagina)
  11. flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti (Livello ***).

    Esempi:

    • Utilizzare dimensioni leggibili dei font e consentire il loro dimensionamento agli utenti
    • Consentire la personalizzazione della presentazione, anche attraverso gli appositi controlli dei browser
    Commento al requisito 11

    La leggibilità dei caratteri e la loro ridimensionabilità sono aspetti importantissimi dell'accessibilità di una pagina web. Considerare tale requisito come un terzo livello (***) nella valutazione dell'accessibilità mi sembra veramente un errore. Propongo che la flessibilità dell'interfaccia, cioè la sua adattabilità alle scelte di personalizzazione degli utenti, sia riclassificata come primo livello nella scala di valutazione dell'accessibilità di un sito o di un'applicazione web.

1.4) Metodologie per la valutazione soggettiva articolata su più livelli di qualità

Il processo di valutazione della rispondenza di un sito Web o di una applicazione web based alle caratteristiche indicate al punto precedente si basa su una metodologia che prevede tre fasi:

  1. analisi da parte di uno o più esperti di fattori umani
  2. test con gli utenti
  3. elaborazione dei dati da parte dell’esperto e rapporto conclusivo con l’indicazione del livello di qualità raggiunto

1.4.1) Valutazione condotta da esperti di fattori umani

La valutazione da parte di uno o più esperti consisterà essenzialmente nel metodo della simulazione cognitiva ("cognitive walkthrough") attraverso il quale verranno analizzate le caratteristiche qualitative indicate nel paragrafo 1.3 in merito alla loro applicazione nel sito o nella applicazione web based in esame.

L'esperto di fattori umani deve avere un livello di esperienza ed un percorso formativo equivalente a quello previsto dal Comitato di Registrazione dell'Ergonomo Europeo (CREE).

A proposito del precedente punto 1.4.1 sottoscrivo in pieno le impeccabili considerazioni fatte da Maurizio Boscarol nell'articolo Legge Stanca ed ergonomi, pubblicato il 13 maggio sul sito collegato al libro Ecologia dei siti web.

1.4.2) Valutazione effettuata con l'utente

La seconda fase della valutazione prevede la costituzione di un gruppo di utenti in cui è prevista la partecipazione di utenti disabili con l'uso di diverse classi di tecnologie assistive o di particolari configurazioni.

Il gruppo di utenti esegue una serie di test basati sulla interazione con il sito o con l’applicazione web based. I test potranno essere svolti sia in forma libera (l’utente naviga il sito senza compiti specifici) sia per obiettivi (l’utente esegue compiti specifici).

Il risultato di ogni test per ogni utente viene registrato in un apposito modulo.

1.4.3) Elaborazione dei dati da parte dell'esperto e rapporto conclusivo con l'indicazione del livello di qualita raggiunto

La valutazione si conclude con la predisposizione di un rapporto nel quale l’esperto indica:

Considerazioni conclusive

Il testo che segue è un commento di Michele Diodati. Non fa parte dello studio sui requisiti per la verifica dell'accessibilità, riportato sopra e disponibile in originale sul sito di PubbliAccesso.

Lo studio sui requisiti e le metodologie per la valutazione dell'accessibilità pubblicato su PubbliAccesso è un tentativo sicuramente meritorio di definire delle regole il più possibile semplici e obiettive per la regolamentazione di una materia nuova ed ancora in evoluzione, come è in effetti l'accessibilità.

Le critiche esposte nei miei commenti non vogliono quindi assolutamente essere demolitorie. Il loro scopo è invece quello di cercare di portare alla riflessione degli autori dello studio, ora che è ancora possibile - mi auguro - apportare dei correttivi, ciò che nel loro lavoro mi è apparso impreciso e bisognoso di correzione. Si tratta naturalmente di miei punti di vista, anche se sostanziati da anni di esperienza nel settore e da una serie di riferimenti a quegli stessi documenti normativi internazionali, a cui anche lo studio in esame afferma esplicitamente di richiamarsi.

Ecco dunque di seguito le considerazioni conclusive del sottoscritto, con la speranza che possano servire ad integrare e migliorare i requisiti per l'accessibilità che trapasseranno nel decreto di attuazione della legge.

Sommario

  1. Sulla differenza tra criteri tecnici e criteri soggettivi
  2. La necessità di una formulazione più rigorosa dei requisiti tecnici
  3. Allestire una completa e chiara documentazione di supporto
  4. Formazione
  5. L'accessibilità del linguaggio

1. Sulla differenza tra criteri tecnici e criteri soggettivi

Va chiarita meglio la differenza tra requisiti tecnici e requisiti soggettivi. I due termini non sono realmente opposti. Proporrei di sostituire la parola "tecnici" con "oggettivi", intendendo con ciò i requisiti che possono essere esaminati o in modo automatico (validazione del codice, esame tramite programmi come Bobby o Torquemada) o tramite una verifica umana basata su precisi criteri di riferimento (raggruppare le sequenze di link, verificare che la pagina possa essere ingrandita fino al 200%, ecc.). A questo punto acquisterebbe chiarezza l'opposizione con i requisiti soggettivi, intendendo con questi ultimi quelli che non possono essere verificati se non tramite esperimenti con utenti umani (la comprensibilità dei testi, la coerenza del sistema di navigazione, la facilità di apprendere il funzionamento dell'interfaccia, ecc.).

Tuttavia i requisiti che fanno parte della prima categoria e quelli che fanno parte della seconda non sono sempre ben distinti e ben distinguibili. Nella prima categoria, per esempio, si trova la valutazione delle alternative equivalenti per contenuti grafici, multimediali o di programmazione. Accertarsi della presenza di un'alternativa è certamente un criterio oggettivo; valutare quanto quest'alternativa sia adeguata è invece tutt'altra storia: è un requisito che dovrebbe essere spostato a mio parere tra le valutazioni soggettive, da svolgersi per mezzo di test con utenti.

D'altro canto, nella seconda categoria abbiamo all'undicesimo posto il criterio della flessibilità, che, almeno nella misura in cui coinvolge il ridimensionamento della pagina e dei caratteri, è qualcosa che può essere valutato in base a criteri oggettivi.

Insomma, la distinzione tra le due categorie non è sempre chiara ed agevole. Ciò che fa la differenza sono soprattutto i criteri metodologici da utilizzare per la verifica: strumenti automatici e prove tecniche nel primo caso; esperimenti su utenti nel secondo. Ciò giustifica anche il ricorso a due figure professionali differenti: il tecnico "accessibilista" nel primo caso, l'ergonomo (ma meglio sarebbe lo psicologo cognitivista e l'usabilista) nel secondo.

torna su

2. La necessità di una formulazione più rigorosa dei requisiti tecnici

La parte dello studio che mi sembra in assoluto più bisognosa di modifiche è quella relativa ai venti requisiti tecnici. Come attestano i numerosi commenti che ho intervallato al testo degli enunciati, in molti casi la formulazione è imprecisa. Oscillando tra i riferimenti alle WCAG 1.0 e quelli a Section 508, i requisiti formulati non hanno una personalità precisa; sono ricavati non di rado "cucendo" tra loro con suture non perfette pezzi non omogenei delle WCAG 1.0 o di Section 508. L'effetto di questo collage non è dei migliori.

In particolare trovo dannosa la scelta che si è fatta di sconsigliare piuttosto che di proibire; o di vietare, per rendere poi ammissibile al rigo successivo ciò che era stato appena proibito. Rende ancora più indeterminato il tutto il fatto che i divieti o le concessioni si legano quasi inevitabilmente a condizioni enunciate in termini vaghi (le "esigenze informative" del requisito 5, l'alta leggibilità del requisito 6, il "nonostante ogni sforzo" del requisito 20, ecc.).

In verità lo stile espressivo degli enunciati non è una novità: ricalca l'indeterminatezza (spesso però peggiorandola senza necessità) di molte raccomandazioni delle WCAG 1.0. Tuttavia, mentre lì l'indeterminatezza era in un certo senso accettabile, perché le WCAG sono raccomandazioni, semplici consigli, e non obblighi di legge, nel caso dei requisiti per il decreto di attuazione della legge 4/2004 la situazione è rovesciata, e quello che nelle WCAG era un pregio diventa qui un grave difetto.

La mia opinione è che, se si vuole che la legge sull'accessibilità sia realmente e largamente applicabile, occorre definire nel modo più chiaro, preciso ed inequivocabile ciò che può essere fatto e ciò che non può essere fatto. Questo non vuol dire creare vincoli di difficile applicazione. Non sto dicendo che bisogna stabilire regole dure, ma che bisogna stabilire regole più precise. Possiamo cioè anche allentare la rigidezza dei requisiti richiesti, ma è di fondamentale importanza che non si mettano lo sviluppatore e il valutatore nella condizione di non essere certi di cosa occorra fare per soddisfare un dato requisito tecnico: questa scritta sarà ad alta leggibilità oppure no? è stato fatto davvero ogni sforzo per evitare la pagina alternativa oppure no? quel testo lampeggiante risponde ad un'esigenza informativa indispensabile oppure no? E così via...

Ma ben più grave del problema psicologico dei dubbi che potrebbero attanagliare lo sviluppatore ed il valutatore è la questione della mancanza di oggettività delle valutazioni di accessibilità che verranno prodotte sulla scorta di requisiti imprecisi. Più è indeterminato il criterio da seguire, più alta è la possibilità che valutatori diversi interpretino in modi completamente differenti le richieste di un medesimo requisito: la conseguenza potrebbe essere che un sito meritevole venga considerato meno accessibile di un altro non meritevole... Senza considerare i rischi di comportamento disonesto a cui la vaghezza dei requisiti spianerebbe la strada.

torna su

3. Allestire una completa e chiara documentazione di supporto

Un altro grosso problema emerso dalla lettura di questo studio è che poggia praticamente... sul nulla. Non c'è un glossario allegato, non sono spiegati i significati dei termini tecnici adoperati, non è descritto come ottenere i risultati che i requisiti stabiliti richiedono di ottenere.

Immagino che sia stata già prevista dagli estensori dello studio la necessità di fornire ai soggetti interessati dall'applicazione di questa legge una documentazione di supporto, che serva come riferimento e come orientamento nel lavoro di messa a punto dell'accessibilità.

Tale documentazione è indispensabile: l'applicazione stessa della legge riuscirà difficile e nebulosa, se non verranno messi a disposizione opportuni testi di riferimento, glossari, documenti di specifiche, esempi di applicazione delle regole di accessibilità.

Non mi sembra sufficiente né corretto limitarsi ad indicare, come è stato fatto, le fonti in inglese - raccomandazioni W3C, paragrafo 1194.22 della Sezione 508, norme ISO - a cui lo studio è ispirato. Lo sviluppatore ed il valutatore italiani non sono tenuti a conoscere l'inglese (o a conoscerlo così bene da usarlo come lingua di lavoro): hanno bisogno di riferimenti normativi in lingua italiana. Non solo: dal momento che i requisiti definiti in questo studio costituiscono una nuova formulazione in materia di accessibilità, evidentemente non possono rimandare tout court ai documenti in inglese che spiegano e regolano l'accessibilità così come è definita nelle WCAG 1.0, in Section 508, negli standard ISO. Se questo studio definisce uno standard italiano per l'accessibilità, deve anche fornire agli interessati strumenti tecnici originali, comprensibili e pertinenti, per consentire di adeguarvisi.

Gli strumenti tecnici a cui mi riferisco sono i seguenti:

Come ulteriore materiale di supporto e consultazione, sarebbe opportuno preparare anche traduzioni ufficiali delle raccomandazioni WCAG 1.0 (una traduzione in italiano delle WCAG 1.0 è stata realizzata anni fa dai volontari dell'AIB) e delle tecniche di applicazione associate, nonché traduzioni del documento in inglese che illustra gli enunciati e le modalità di applicazione dei requisiti di Section 508. Ciò perché tale documentazione viene ripetutamente richiamata come fonte ispiratrice dei requisiti definiti nello studio qui in esame.

torna su

4. Formazione

Le complesse modalità di valutazione dell'accessibilità descritte nei paragrafi 1.2 e 1.4 di questo studio portano in primo piano l'esigenza di formare delle professionalità adeguate ai compiti previsti. Come ha osservato Maurizio Boscarol in un suo recente articolo già citato in precedenza, l'ergonomia è una disciplina troppo generica per presumere che, fin da subito, chi oggi è qualificato come ergonomo sia anche in grado di compiere valutazioni professionali dell'accessibilità di siti e applicazioni web.

Occorre a mio parere che ci si preoccupi di formare delle professionalità apposite, cioè degli esperti che conoscano a fondo l'accessibilità e l'usabilita dei siti web, discipline che da sole richiedono molteplici e raffinate competenze. Dal punto di vista del solo controllo tecnico dell'accessibilità occorre:

Dal punto di vista del controllo dell'usabilità occorre poi che l'esperto sia in grado di organizzare test con utenti disabili e non, traendone valutazioni corrette e sufficientemente oggettive circa il grado di applicazione dei vari requisiti elencati al paragrafo 1.3 dello studio.

Benché sia comprensibile la scelta, da parte degli esperti designati dal legislatore, di affidare all'ergonomo tali valutazioni, una simile scelta è a mio parere troppo limitativa e riduttiva, rispetto alle competenze che fin da oggi occorre mettere in campo. Non è troppo tardi per modificare questo punto dello studio, riformulando la questione in modo da definire magari professionalità e percorsi formativi appositi, che permettano nel corso di un tempo accettabile di formare degli esperti valutatori, dotati di adeguate competenze settoriali.

torna su

5. L'accessibilità del linguaggio

Un punto generalmente trascurato da chi si occupa di accessibilità come tecnico è la verifica che il linguaggio adoperato nelle pagine web sia realmente adeguato al pubblico a cui ci si rivolge. Si è creata una sorta di fraintendimento implicito, che porta chi si occupa di accessibilità a profondere lavoro e attenzione nell'adeguamento della grafica e del codice di marcatura ai requisiti di accessibilità previsti dalle specifiche WCAG 1.0, trascurando quasi del tutto il lavoro sui contenuti e sullo stile comunicativo.

Ciò è un grave errore ed un grave handicap in vista del raggiungimento di una vera accessibilità. Questa è, infatti, per il 50% lavoro sul codice e sulla cornice tecnologica, ma per un altro 50% lavoro sui contenuti testuali e sulla lingua. Non è possibile considerare accessibile un documento che rispetta tutti i requisiti previsti tranne uno: è scritto - come spesso accade - in ostrogoto.

Mettendosi purtroppo nel solco del fraintendimento appena descritto, lo studio qui in esame non dà quasi nessun rilievo al problema dell'accessibilità del linguaggio con cui sono espressi i contenuti. Solo tra gli esempi relativi al requisito soggettivo 2 ("uso") si fa un generico ed insoddisfacente accenno al problema dell'accessibilità del linguaggio: Utilizzare un linguaggio comprensibile alla grande maggioranza dei destinatari.

In tal modo l'importanza di testi accessibili risulta enormemente sottovalutata. Bisognerebbe invece riflettere sul fatto che il testo è l'elemento di interscambio vero e proprio dell'accessibilità: senza testi adeguati, la migliore cornice tecnologica ad alta accessibilità è una scatola vuota, un sepolcro inutile. Come minimo, alla valutazione del linguaggio dovrebbe essere dedicato un requisito soggettivo a sé, identificato come fattore della massima importanza (livello *) per il conseguimento dell'accessibilità.

A supporto degli autori e dei valutatori dovrebbero poi essere forniti adeguati strumenti di consultazione e di riferimento: repertori lessicali tecnici per scegliere i termini più adatti al discorso, manuali di stile, corsi di formazione linguistica, guide alla semplificazione dei linguaggi settoriali (si pensi ai disastri del burocratese), esperti in grado di fornire consulenze linguistiche.

Ripeto: l'intervento sull'accessibilità cognitiva di ciò che attraverso il Web viene comunicato è almeno altrettanto importante dell'intervento sull'accessibilità percettiva: i contenuti devono essere facilmente e chiaramente comprensibili, oltre che ben percepibili.

Curare nei dettagli tutta la cornice tecnologica di supporto (codice valido, elementi alternativi, contrasti di colore, menu di navigazione coerenti, caratteri ridimensionabili, ecc. ecc.) e trascurare l'accessibilità dei testi immessi in quella cornice è un po' come invitare ad una tavola da re - imbandita con tovaglie finissime, piatti di porcellana, bicchieri di cristallo, posate d'argento e portate raffinatissime - una tribù di uomini di Neanderthal: potrebbe essere divertente, questo sì, ma quanto all'utilità...

torna su

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