accesskey
Acquista il libro su Apogeonline
Google Memoria dello Spazio

Capitolo 20

Una panoramica sulle WCAG 2.0

La prima bozza pubblica delle WCAG 2.0 collegamento esterno risale all'ormai lontano 25 gennaio 2001. La bozza più aggiornata collegamento esterno, al momento in cui scriviamo, è quella del 17 maggio 2007. La prima e l'ultima sono divise tra loro da un lungo cammino, segnato da numerose bozze intermedie. Scorrendo il sommario dei contenuti di ciascuno di questi documenti, è possibile farsi un'idea di quanto lavoro e di quanti cambiamenti di opinione e di prospettiva ci siano dietro il tentativo, ancora non concluso, di dare un successore alle WCAG 1.0.

In ogni caso, sette anni sono un tempo di formazione lunghissimo, anche per un testo complesso come una Raccomandazione del W3C. Com'è possibile che non siano bastati per arrivare a un documento finale condiviso? Se, da un lato, il ritardo può essere spiegato con i limiti inevitabili di un metodo di lavoro basato sul volontariato, dall'altro è la vastità stessa del progetto – che appare evidente a chiunque scorra i corposi documenti accessori collegati al testo della futura Raccomandazione – a valere come una spiegazione del (tanto) tempo trascorso dall'inizio dei lavori.

Un'ampiezza che non sta nel numero delle raccomandazioni di accessibilità: le WCAG 2.0, per come sono organizzate attualmente, constano infatti di sole dodici linee guida, a fronte delle quattordici contenute nelle WCAG 1.0. La vastità è, piuttosto, nel meccanismo di chiarimenti, definizioni, criteri di successo per il superamento delle linee guida e tecniche di applicazione: un insieme di complementi e di approfondimenti, legati da rimandi incrociati, che equivale ad alcune centinaia di pagine a stampa e che forma un corpo unico con il documento “padre”, cioè la bozza di Raccomandazione.

Ma procediamo con ordine, partendo dai concetti principali intorno ai quali sono organizzate le WCAG 2.0.

Inizio pagina

Indipendenza dalla tecnologia

Il primo e più importante concetto, che fa da spartiacque tra il mondo delle WCAG 1.0 e quello delle WCAG 2.0, è quello di indipendenza dalla tecnologia: mentre le WCAG 1.0 non sono indipendenti dalla tecnologia, le WCAG 2.0 sono invece progettate per esserlo. Le WCAG 1.0 sono state scritte, nel 1999, con in mente un Web fatto principalmente di documenti HTML, da rendere accessibili 1) per mezzo di un uso semantico del codice di marcatura e 2) delegando ogni aspetto di presentazione ai fogli di stile CSS.

L'invito a usare codice di marcatura e fogli di stile, e a usarli in modo corretto (linea guida 3), così come la raccomandazione di creare tabelle che si trasformino elegantemente (linea guida 5) sono chiari esempi, nelle WCAG 1.0, di una visione dipendente dalla tecnologia. Sono esempi di questa visione anche la linea guida 6, che divide le tecnologie in vecchie e nuove (Garantire che le pagine caratterizzate da nuove tecnologie si trasformino elegantemente), e la linea guida 11 (Usare tecnologie e linee guida del W3C).

Le raccomandazioni per l'uso accessibile di tabelle e fogli di stile, la distinzione tra nuove e vecchie tecnologie, l'invito a usare le tecnologie prodotte dal W3C sono ciò che rende in parte obsolete le WCAG 1.0, di fronte a un Web che, negli ultimi anni, si è arricchito di applicazioni, contenuti, modalità di interazione e tecnologie (RSS, AJAX, Flash ecc.), a cui i criteri di accessibilità definiti dalle linee guida del 1999, nate dall'idea di un Web costruito sull'ossatura di HTML, CSS e specifiche W3C, possono essere estesi – e non sempre – solo per analogia.

Ciò non vuol dire che il principio guida delle WCAG 1.0, di usare cioè codice di marcatura semantico e delegare la presentazione ai fogli di stile, sia sbagliato, anzi (si veda in proposito il Capitolo 6 di questo libro). Solo che le WCAG 1.0 “fotografano” un Web che, nel frattempo, è cambiato: la loro è una “fotografia” ingiallita, che fissa un soggetto che oggi non è più completamente riconoscibile in quella foto e che, prevedibilmente, lo sarà ancor meno nei prossimi anni.

Il punto di partenza delle WCAG 2.0 è dunque l'idea di una ricetta universale per l'accessibilità, che sia non solo in grado di intercettare e soddisfare le esigenze degli utenti con disabilità che frequentano il Web odierno, ma anche quelle degli utenti di domani, che frequenteranno un Web che sarà, con ogni probabilità, differente da quello che conosciamo oggi. Come poter prevedere, però, il futuro? Non è possibile, ovviamente, sapere quali tecnologie domineranno il Web fra due, tre o cinque anni. È possibile, tuttavia, individuare delle caratteristiche generali di accessibilità, che possono essere considerate extra-temporali e compatibili con qualsiasi tecnologia web, anche con quelle non ancora inventate, caratteristiche che riguardano semplicemente l'interazione tra un soggetto umano e i contenuti del Web, e che prescindono dalla forma che essi assumono e dalla tecnologia adoperata per veicolarli.

Non senza difficoltà e ripensamenti, il gruppo di lavoro per le WCAG 2.0 ha così individuato quattro principi universali di accessibilità indipendenti dalle tecnologie, che sono stati posti a fondamento di tutta l'architettura delle nuove linee guida per l'accessibilità. I quattro principi sono i seguenti (termini e definizioni sono una traduzione in italiano della terminologia inglese):

  1. percepibile - informazioni e componenti dell'interfaccia utente devono essere percepibili dagli utenti.
  2. utilizzabile (operable) - i componenti dell'interfaccia utente devono essere utilizzabili dagli utenti.
  3. comprensibile - informazioni e operazioni dell'interfaccia utente devono essere comprensibili per gli utenti.
  4. robusto - i contenuti devono essere sufficientemente robusti, da poter essere interpretati affidabilmente da un'ampia varietà di programmi utente, comprese le tecnologie assistive.

I quattro principi sono le categorie generali sotto cui si collocano una serie di linee guida – da una a un massimo di quattro per ciascun principio – che hanno la funzione di indicare la strada attraverso cui può essere implementato il principio a cui ciascuna fa riferimento. Per esempio, rendere predicibili l'aspetto e le funzionalità dei contenuti è una delle tre linee guida (precisamente la 3.2) che sono raccolte sotto il terzo principio, quello della comprensibilità: il suo scopo, condiviso con le altre due linee guida che fanno capo allo stesso principio, è di indicare a sviluppatori e autori come rendere comprensibili i contenuti pubblicati sul Web.

Inizio pagina

Salta inserzione pubblicitaria

I criteri di successo

A ciascuna linea guida fa capo un numero variabile di criteri di successo o success criteria (complessivamente sono 56). Si tratta di affermazioni che identificano il minimo indispensabile di caratteristiche e funzionalità che devono essere implementate in una pagina web, affinché sia ritenuta soddisfatta la linea guida di riferimento. Per esempio, la linea guida 3.2, citata nel paragrafo precedente, ha cinque criteri di successo, il quarto dei quali, intitolato “Identificazione coerente”, afferma: “I componenti che hanno la medesima funzionalità all'interno di un insieme di pagine web sono identificati in maniera coerente”.

I criteri di successo corrispondono, nelle WCAG 2.0, a ciò che sono i punti di controllo (checkpoints) nelle WCAG 1.0. C'è però una grande differenza. Mentre i punti di controllo sono suggerimenti piuttosto vaghi, che rendono difficile o impossibile definire metodi oggettivi per stabilire se sono stati applicati oppure no (sono esemplari per indeterminatezza alcuni punti di controllo della linea guida 6 delle WCAG 1.0), i criteri di successo delle WCAG 2.0 sono progettati per essere verificabili. Si tratta, cioè, di affermazioni che ammettono solo due risposte: sì o no. Il “forse” non è contemplato.

Ad ogni criterio di successo sono associate delle tecniche di applicazione, che consentono di verificare praticamente se il documento o il sito che si intende rendere accessibile in base alle WCAG 2.0 supera oppure no il relativo criterio di successo. Il superamento avviene solo se la verifica dà esito positivo, cioè permette di rispondere “sì” all'affermazione contenuta in un criterio di successo. Il sistema è spiegato nella definizione di “tecniche sufficienti” (sufficient techniques), presente nella bozza del 17 maggio 2007:

Per ciascun criterio di successo, esiste una lista di tecniche che il Gruppo di Lavoro ha ritenuto sufficienti per soddisfare il requisito. Per ciascuna tecnica sufficiente, esiste un test per determinare se la tecnica sia stata implementata con successo. Se il test o i test per una tecnica “sufficiente” (o per una combinazione di tecniche) sono superati, allora il criterio di successo è stato soddisfatto.

Passare tutti i test per tutte le tecniche sufficienti non è necessario. La maggior parte dei criteri di successo ha in elenco più “tecniche sufficienti”. Può essere usata una qualsiasi delle “tecniche sufficienti” elencate per soddisfare il criterio di successo.

Il meccanismo dei criteri di successo tende, in definitiva, a superare l'incertezza nella valutazione della conformità, che è ineliminabile nelle WCAG 1.0. Moltissimo tempo e attenzione sono stati spesi dai membri del gruppo di lavoro per le WCAG per rifinire la forma in cui sono poste le affermazioni che formano i vari criteri di successo. Altrettanto tempo e altrettanta attenzione sono stati necessari per definire lo scopo, i benefici per l'accessibilità e le tecniche per il superamento di ciascun criterio di successo (inclusi collettivamente in un lungo documento accessorio, intitolato Understanding WCAG 2.0).

I tre livelli in cui sono ripartiti i criteri di successo

Se i criteri di successo, formulati per dare risposte nette, univoche e verificabili a ciascuna raccomandazione di accessibilità, rappresentano uno degli aspetti più positivi delle WCAG 2.0, la loro suddivisione in tre livelli costituisce, a nostro avviso, una non indispensabile zavorra, che le nuove linee guida ereditano dalle WCAG 1.0. Saranno così ancora una volta presenti, a meno di imprevedibili ripensamenti dell'ultima ora, i tre livelli di conformità (A, doppia A e tripla A), già definiti per le WCAG 1.0.

Per di più, la distinzione in tre livelli nelle linee guida del 1999 derivava una certa chiarezza concettuale dall'uso delle tre parole chiave “deve”, “dovrebbe” e “può” (must, should e may. Si veda in proposito il Capitolo 3), usate per definire il grado di necessità dei punti di controllo appartenenti a ciascuno dei tre livelli. Invece, la distinzione in tre livelli operata dalle WCAG 2.0 appare non collegata a vincoli di accessibilità chiaramente definibili e lascia alcune perplessità, non solo circa i fattori che distinguono un livello dall'altro, ma anche, in certi casi, circa le ragioni per cui un certo criterio di successo è stato inserito in un livello piuttosto che in un altro.

Riportiamo di seguito in traduzione italiana il brano che definisce i tre livelli di criteri di successo nell'attuale bozza delle WCAG 2.0, in modo che il lettore possa valutare analogie e differenze con la suddivisione dei punti di controllo in tre priorità, operata dalle WCAG 1.0 (si veda in proposito la nota alla fine del paragrafo).

La parola “livelli” non vuol dire che alcuni criteri di successo sono più importanti di altri. Ciascun criterio di successo nelle WCAG 2.0 è essenziale per alcuni utenti, e i livelli sono costruiti l'uno sull'altro [build upon each other]. Tuttavia, anche i contenuti che sono conformi ad AAA (tripla A) possono non essere pienamente accessibili per tutte le persone con una disabilità o una combinazione di disabilità, specialmente certi tipi di disabilità gravi.

In generale, i criteri di successo di Livello A raggiungono l'accessibilità supportando le tecnologie assistive e imponendo allo stesso tempo i minori limiti possibili sulla presentazione. Pertanto, persone con un'ampia gamma di disabilità, che usano un'ampia gamma di tecnologie assistive, dai dispositivi ad input vocale e tracciamento oculare ai lettori e agli ingranditori di schermo, sono in grado di accedere ai contenuti in modi differenti. In altre parole, i criteri di successo di Livello A supportano la capacità sia dei programmi utente tradizionali sia di quelli specializzati, di adattare i contenuti a formati che soddisfano i bisogni degli utenti.

I criteri di successo nel Livello AA forniscono un supporto aggiuntivo alle tecnologie assistive. Allo stesso tempo, essi supportano anche l'accesso diretto ai contenuti da parte di molte persone che usano programmi utente convenzionali, senza ricorrere a tecnologie assistive. In generale, i criteri di successo di Livello AA impongono maggiori limiti sulla presentazione visuale e su altri aspetti del contenuto rispetto ai criteri di successo di Livello A.

I criteri di successo di Livello AAA incrementano sia l'accesso diretto sia l'accesso attraverso tecnologie assistive. Essi pongono limiti più stringenti su presentazione e contenuti, il che vuol dire che alcuni tipi di contenuto possono non riuscire a soddisfare questo livello di conformità.

I fattori che contraddistinguono il passaggio da un livello all'altro nelle WCAG 2.0 sono due: da un lato un progressivo incremento dell'accessibilità, dall'altro un progressivo aggravio dei vincoli di presentazione e composizione dei contenuti. Ma, vista soprattutto la precisazione riportata all'inizio del brano citato (non vi sono criteri di successo più importanti degli altri), non si capisce perché debbano esserci proprio tre livelli. Soprattutto, ci sembra che non esista un criterio evidente, oggettivo, che permetta di capire – senza leggerlo nel testo delle WCAG – a che livello appartenga un qualsiasi criterio di successo.

Consideriamo, per esempio, i due criteri di successo per la linea guida 2.1, che richiede che tutte le funzionalità siano utilizzabili tramite tastiera. Il criterio di successo 2.1.1 è classificato come Livello A e afferma che tutte le funzionalità sono utilizzabili da tastiera senza forzare l'utente a premere tasti in un tempo determinato, tranne che nei casi in cui il compito da eseguire sia specificamente dipendente da una data sequenza di input non modificabile. Il criterio di successo 2.1.2 dice, invece, che tutte le funzionalità sono utilizzabili da tastiera in modo indipendente dal tempo. Questo criterio di successo è classificato come Livello AAA, mancando qualsiasi criterio di successo intermedio di Livello AA.

Posto che non potrebbe esserci alcunché di intermedio, visto che tra il 2.1.1 e il 2.1.2 l'unica differenza è che il secondo criterio di successo elimina le eccezioni che introducono vincoli di tempo nell'input da tastiera, ci domandiamo perché mai i due criteri di successo non siano classificati in livelli consecutivi (AA e AAA oppure A e AA). Il medesimo salto di livello si verifica con i criteri di successo della linea guida 2.3, che tratta degli interventi per evitare ai soggetti predisposti di imbattersi in contenuti che possono scatenare crisi da epilessia fotosensibile (su questo tipo di epilessia, si veda il Capitolo 10).

Ci sembra, in breve, che la suddivisione fissa in tre livelli, troppo somigliante al meccanismo, già rivelatosi imperfetto, delle WCAG 1.0, introduca nelle WCAG 2.0, almeno in certi casi, un elemento di artificiosità, di cui molto probabilmente si sarebbe potuto fare a meno. Ciò non toglie che determinati interventi a favore dell'accessibilità possono essere ragionevolmente scaglionati secondo un principio di gradualità, che giustifica, entro certi limiti, una classificazione per livelli (per esempio, la definizione di differenti soglie di contrasto di luminosità tra primo piano e sfondo).

[Inizio approfondimento] I tre livelli (priorità) delle WCAG 1.0

Secondo le WCAG 1.0, soddisfare i punti di controllo di priorità 1 (livello A) rende possibile accedere ai contenuti a uno o più gruppi di utenti, che altrimenti sarebbero esclusi. Soddisfare i punti di controllo di priorità 2 (livello AA) permette di rimuovere ostacoli importanti all'accesso; soddisfare quelli di priorità 3 (livello AAA), infine, rende più facile e soddisfacente l'accesso ai contenuti, perseguendo uno scopo che è affine a quello dell'usabilità. Si veda per maggiori dettagli il paragrafo Le tre priorità, nel Capitolo 3. [Fine approfondimento]

Inizio pagina

Nascita e morte del concetto di baseline

Uno dei maggiori limiti applicativi delle linee guida del 1999 risiede nelle raccomandazioni transitorie, come quelle della linea guida 10, che suggeriscono agli sviluppatori alcune precauzioni per la compatibilità all'indietro, oggi totalmente inutili se non addirittura dannose (come inserire caratteri segnaposto all'interno di un campo modulo).

Le WCAG 2.0 eliminano, per saggia scelta, le raccomandazioni transitorie e qualsiasi raccomandazione orientata a una specifica tecnologia. Non potendo, però, eludere il problema della compatibilità con le tecnologie passate e presenti, hanno la necessità di trovare un meccanismo che permetta di definire comunque dei vincoli tecnologici, così da garantire agli utenti la possibilità reale di accedere ai contenuti: senza tali vincoli gli autori potrebbero, infatti, sviluppare contenuti conformi alle WCAG 2.0 usando esclusivamente tecnologie di nicchia, il che escluderebbe la maggior parte degli utenti dalla loro fruizione. Rischieremmo così di avere contenuti accessibili a cui, paradossalmente, non si riesce ad accedere.

Nel tentativo di scongiurare questo rischio, la bozza di aprile 2006 delle WCAG 2.0 collegamento esterno introduceva il nuovo concetto di baseline, o linea di base, con lo scopo di permettere agli autori di definire liberamente la griglia di tecnologie, che i programmi utente devono supportare, affinché gli utenti possano accedere ai contenuti:

Nello scegliere le tecnologie web (HTML, scripting ecc.) che saranno usate per costruire i contenuti, gli autori hanno bisogno di sapere quali tecnologie possono assumere che saranno supportate dai, e attive nei, programmi utente (comprese le tecnologie assistive) che le persone con disabilità adopereranno. Se gli autori fanno affidamento su tecnologie che non sono supportate, allora i loro contenuti possono non essere accessibili.

L'insieme di tali tecnologie, che un autore assume siano supportate e attive in programmi utente accessibili, è chiamata una baseline. Gli autori devono garantire che tutte le informazioni e le funzionalità del contenuto web siano conformi alle WCAG 2.0, assumendo che i programmi utente supportino tutte le tecnologie nella baseline e che esse siano attive. Possono essere usate anche tecnologie non incluse nella baseline, ma tutte le informazioni e le funzionalità del contenuto web devono essere conformi sia quando le tecnologie non-baseline sono attive sia quando sono disattive. Entrambe le condizioni sono necessarie, poiché alcuni utenti possono avere browser che le supportano mentre altri no.

Con il termine baseline s'intende, dunque, l'elenco completo delle tecnologie che un browser o un plug-in, eventualmente in combinazione con una tecnologia assistiva, devono supportare, affinché i contenuti delle pagine web dichiarate conformi alle WCAG 2.0 siano effettivamente accessibili (un elenco contenente HTML, CSS, GIF, JPG è un esempio di baseline).

Tuttavia, per quanto fosse un concetto innovativo la bozza di maggio 2007 delle WCAG 2.0 cancella semplicemente ogni riferimento alla nozione di baseline. Viene introdotto al suo posto un nuovo concetto, quello di accessibility supported, cioè “supportato per l'accessibilità”:

Affinché i contenuti creati con tecnologie per il Web (quali HTML, CSS, PDF, GIF, MPEG, Flash ecc.) siano accessibili a persone con differenti tipi di disabilità, è essenziale che quelle tecnologie siano compatibili con le tecnologie assistive e con le caratteristiche di accessibilità di browser e altri programmi utente. Per esempio, al fine di consentire a qualcosa di superare un criterio di successo che richiede di essere “programmaticamente determinato”, questo qualcosa dovrebbe essere implementato usando una tecnologia che ha il supporto delle tecnologie assistive.

Supportato per l'accessibilità” significa supportato dalle tecnologie assistive degli utenti come pure dalle caratteristiche di accessibilità di browser e altri programmi utente.

Se i contenuti sviluppati in applicazione delle WCAG 2.0 devono usare tecnologie che siano accessibility supported, sorge allora il problema, già presentatosi per le WCAG 1.0, di definire una lista di programmi utente con supporto per l'accessibilità, che elenchi dettagliatamente le caratteristiche di tale supporto. Una nota redazionale nella bozza di maggio 2007 delle WCAG 2.0 precisa a tale proposito che il WAI/W3C si impegnerà a creare liste pubbliche di informazioni sul supporto per l'accessibilità fornito dai programmi utente alle proprie tecnologie, e si aspetta, inoltre, che altri enti e organizzazioni facciano altrettanto.

In conclusione di argomento, è lecito però domandarsi quale vantaggio ci sia per l'accessibilità nell'aver cancellato la nozione di baseline, sostituendola con quella di accessibility supported.

La questione su cui riflettere è che la scelta di una baseline, una volta che è libera e affidata agli autori, introduce un elemento di potenziale discriminazione. Se un autore decide, per esempio, di definire una baseline che contiene un nuovo linguaggio di marcatura che la maggior parte dei programmi utente ancora non supporta, potrebbe produrre pagine web formalmente conformi alle WCAG 2.0, pur avendo vincolato l'accesso ai contenuti alla disponibilità di supporto, ancora non sufficiente, per questo nuovo linguaggio. Basterebbe, a tal fine, che fossero già state prodotte tecniche adatte a garantire il superamento dei vari criteri di successo usando quel nuovo linguaggio di marcatura: si assume, infatti, a priori che le tecnologie in essa inserite siano supportate e attive nei programmi utente.

Il concetto di “supportato per l'accessibilità” (accessibility supported) dovrebbe eliminare, o quanto meno ridurre, questo rischio di discriminazione. Il quinto requisito per la conformità alle WCAG 2.0, sui nove presenti nella bozza di maggio 2007, dice infatti:

Solo tecnologie supportate per l'accessibilità. Per superare i criteri di successo, si fa affidamento solo su tecnologie web per le quali è documentato il supporto per l'accessibilità. Qualsiasi informazione o funzionalità che è implementata con tecnologie che non sono supportate per l'accessibilità deve essere disponibile anche attraverso tecnologie che sono supportate per l'accessibilità.

Sarà in tal modo affidata alla disponibilità e alla qualità dei futuri elenchi pubblici di tecnologie accessibility supported la scelta della migliore infrastruttura tecnologica per siti web che vogliano essere praticamente, non solo teoricamente, accessibili. Il periodico aggiornamento di tali elenchi dovrebbe consentire, inoltre, agli autori di evitare il rischio di mantenere oltre il necessario la compatibilità all'indietro con programmi utente obsoleti e non più utilizzati.

Inizio pagina

I documenti che fanno capo alle WCAG 2.0

La prima suddivisione da considerare è tra documenti normativi e documenti informativi: i primi sono il riferimento obbligato, anche dal punto di vista giuridico, per valutare la conformità alle WCAG 2.0; i secondi, invece, servono per completezza d'informazione, per chiarire e approfondire le richieste delle linee guida, ma non impongono vincoli di alcun genere per il raggiungimento della conformità.

L'unico documento normativo è Web Content Accessibility Guidelines 2.0 e il suo indirizzo di riferimento, sia per le bozze pubbliche più recenti sia per quello che sarà il testo definitivo pubblicato come Raccomandazione W3C, è http://www.w3.org/TR/WCAG20/ collegamento esterno.

I documenti informativi, elencati nella sezione WCAG 2.0 Supporting Documents dell'attuale bozza di Raccomandazione, sono riportati qui di seguito.

A questo gruppo di documenti principali, si aggiungono altri documenti accessori, che contengono informazioni introduttive e note di sviluppo sulle WCAG 2.0. Appartengono a questo secondo insieme:

Inizio pagina

Il testo delle linee guida e dei criteri di successo

Riportiamo in traduzione italiana il testo delle linee guida e dei relativi criteri di successo, così come appare nella bozza delle WCAG 2.0 datata 17 maggio 2007 collegamento esterno.

Lo scopo della traduzione è puramente informativo. Per un'applicazione corretta di queste linee guida, è indispensabile, infatti, far riferimento al documento originale in inglese, soprattutto perché mancano nella traduzione le tecniche relative ai vari criteri di successo (avrebbero occupato da sole un libro di discreta grandezza) e l'ampio glossario, a cui rimandano numerosi termini nel documento originale. Spiegheremo solo, con apposite note, i termini più importanti per la comprensione del testo.

In ogni caso, è necessario tener presente che l'ordine e il dettato di linee guida e criteri di successo sono ancora provvisori. Il testo definitivo che sarà pubblicato come Raccomandazione W3C potrebbe essere differente da quello di seguito riportato.

Inizio pagina

Principio 1. Percepibile

Informazioni e componenti dell'interfaccia utente devono essere percepibili dagli utenti.

Linea guida 1.1.

Fornire alternative testuali per tutti i contenuti non testuali, in modo che possano essere cambiati in altre forme di cui le persone hanno bisogno, quali stampe di grandi dimensioni, braille, parlato, simboli o linguaggio semplificato.

Criteri di successo di Livello A per la linea guida 1.1

1.1.1 Contenuti non testuali. Tutti i contenuti non testuali hanno un'alternativa testuale che presenta informazioni equivalenti, tranne che per le situazioni di seguito elencate.

Nessun criterio di successo di Livello AA per la linea guida 1.1
Nessun criterio di successo di Livello AAA per la linea guida 1.1

Inizio pagina

Linea guida 1.2.

Fornire alternative sincronizzate per i contenuti multimediali.

Criteri di successo di Livello A per la linea guida 1.2

1.2.1 Sottotitoli (preregistrati). Sono forniti sottotitoli per i contenuti multimediali preregistrati, tranne che per le alternative multimediali al testo che siano chiaramente etichettate come tali.

1.2.2 Audiodescrizioni o alternative testuali complete. Per i contenuti multimediali preregistrati, è fornita un'audiodescrizione del video o un'alternativa testuale completa dei contenuti multimediali, comprendente qualsiasi interazione.

Nota. Per 1.2.2, 1.2.4 e 1.2.7, se tutte le informazioni relative alla traccia video sono già presenti nella traccia audio, non è necessaria alcuna audiodescrizione.

Criteri di successo di Livello AA per la linea guida 1.2

1.2.3 Sottotitoli (in diretta). I contenuti multimediali in diretta [live] sono sottotitolati.

Nota. Se i contenuti multimediali sono generati completamente al computer, non sono in diretta e sono soggetti ai requisiti delle WCAG 2.0 per i contenuti multimediali preregistrati.

1.2.4 Audiodescrizioni. I contenuti multimediali preregistrati sono forniti di audiodescrizione della parte video.

Criteri di successo di Livello AAA per la linea guida 1.2

1.2.5 Lingua dei segni. I contenuti multimediali sono forniti di interpretazione nella lingua dei segni.

1.2.6 Audiodescrizione (estesa). I contenuti multimediali preregistrati sono forniti di audiodescrizione estesa della parte video.

1.2.7 Alternativa testuale completa. Per tutti i contenuti multimediali preregistrati è fornita un'alternativa testuale completa comprendente qualsiasi interazione, tranne che per le alternative multimediali al testo che siano chiaramente etichettate come tali.

[Inizio approfondimento] Alternativa testuale completa per il multimedia

Un'alternativa testuale completa di un contenuto multimediale comprendente qualsiasi interazione è un documento che include descrizioni correttamente poste in sequenza di tutti gli ambienti visivi, le azioni e i suoni non verbali, combinate con le trascrizioni descrittive di tutti i dialoghi e con strumenti per ottenere qualsiasi risultato che sia raggungibile interagendo con il brano multimediale durante la sua esecuzione. Una sceneggiatura può corrispondere a una simile definizione solo se sia stata rimaneggiata in modo da rappresentare accuratamente il brano multimediale, così come si presenta nella sua forma finale. [Fine approfondimento]

[Inizio approfondimento] Audiodescrizione estesa

Un'audiodescrizione che è aggiunta a una presentazione audiovisiva mettendo in pausa il video, in modo da ricavare il tempo per inserire una descrizione aggiuntiva. Una simile tecnica è da adoperare soltanto nel caso in cui il senso del video andrebbe perduto senza l'audiodescrizione aggiuntiva. [Fine approfondimento]

[Inizio approfondimento] Una soluzione italiana per il criterio di successo 1.2.5

Il criterio di successo 1.2.5 pone una sfida difficile a chi intende produrre contenuti multimediali accessibili al terzo livello delle WCAG 2.0. Richiede infatti che i brani audiovideo pubblicati sul Web siano accompagnati dalla relativa traduzione nella lingua dei segni, cosa per nulla facile non solo per le ingenti risorse economiche e di tempo necessarie per approntare materiali interpretati nella lingua dei segni, ma anche per ragioni squisitamente tecnologiche. Occorre infatti trovare risposte ad alcune domande: come associare l'interpretazione nella lingua dei segni al documento multimediale di partenza? Come fare in modo che l'utente possa tenere sotto controllo entrambi, dandogli allo stesso tempo la possibilità di personalizzare l'esperienza di fruizione, in modo da adattarla alle proprie esigenze?

Partendo dall'idea con cui la televisione ha risolto il problema, cioè la tecnica dell'incorporamento di una finestra più piccola, contenente l'interpretazione nella lingua dei segni, all'interno della finestra più grande del documento audiovideo di partenza, Alessio Cartocci, un ricercatore italiano che collabora al progetto Webmultimediale.org, ha sviluppato di recente una soluzione innovativa collegamento esterno (Figura 20.1).

Nel sistema prodotto da Cartocci, l'interpretazione in lingua dei segni è visibile all'interno di un secondo flusso video nel formato Flash Video, contenuto in una finestra che l'utente può ridimensionare trascinando un triangolino posto nell'angolo inferiore destro. La finestra può inoltre essere spostata, anche tramite tastiera, in ogni punto dell'area delimitata dal blocco in cui è inserito il brano audiovideo di partenza, lasciando così quest'ultimo del tutto visibile.

La soluzione è integrata da una pulsantiera posta sotto l'area di visualizzazione del brano multimediale, per mezzo della quale è possibile far apparire e scomparire a discrezione dell'utente la finestra ridimensionabile con l'interpretazione in lingua dei segni. La presenza di sottotitoli chiusi e la possibilità di disattivarli e di cambiare al volo la lingua dei sottotitoli e del parlato rende il prodotto sviluppato da Cartocci una soluzione per l'accessibilità dei contenuti multimediali completa e del tutto conforme alle richieste delle WCAG 2.0. È conforme, in particolare, al criterio di successo 1.2.5: per informazioni dettagliate, si veda la traduzione realizzata da Roberto Ellero su Webmultimediale.org e il testo originale inglese delle tecniche per questo criterio di successo collegamento esterno.

Figura 20.1. La soluzione sviluppata da Alessio Cartocci per associare una traduzione in lingua dei segni a un brano audiovideo (12/5/2007).

L'aspetto più innovativo è che tutto l'insieme di contenuti multimediali, pulsanti e informazioni testuali che il player Flash riproduce è gestito per mezzo di SMIL. L'uso di SMIL con Flash garantisce la massima flessibilità di utilizzo; consente infatti di sincronizzare un numero indefinito di tracce video, audio e testo. Inoltre, il ricorso al formato Flash garantisce la massima interoperabilità per i brani audiovideo accessibili diffusi sul Web, un'interoperabilità che gli altri formati audiovisivi per il Web, afflitti da problemi di compatibilità con browser e sistemi operativi, non consentono (si veda in proposito il paragrafo Formati e player per il multimedia accessibile, nel Capitolo 4).

In sostanza, il lavoro di Cartocci apre la porta a possibilità di sperimentazione molto interessanti, per quanto riguarda il fornire alternative sincronizzate in lingue parlate e in lingue dei segni differenti. Si tratta, in ogni caso, di una soluzione che l'autore stesso definisce ancora sperimentale e in evoluzione, aperta ai cambiamenti e ai suggerimenti degli utilizzatori. [Fine approfondimento]

Inizio pagina

Linea guida 1.3.

Creare contenuti che possano essere presentati in modi differenti (per esempio ad alta voce, con un'impaginazione semplificata ecc.) senza perdere informazione o struttura.

Criteri di successo di Livello A per la linea guida 1.3

1.3.1 Informazioni e relazioni. Le informazioni e le relazioni convogliate attraverso la presentazione possono essere programmaticamente determinate o sono disponibili nel testo, e la notifica dei loro cambiamenti è disponibile ai programmi utente, comprese le tecnologie assistive.

1.3.2 Sequenza significativa. Quando la sequenza in cui i contenuti sono presentati influenza il loro significato, una corretta sequenza di lettura può essere programmaticamente determinata e la navigazione sequenziale di componenti interattivi è coerente con quella sequenza.

1.3.3 Dimensione, forma, posizione. Le istruzioni fornite per comprendere e utilizzare i contenuti non si basano sulla forma, la dimensione, la posizione visiva o l'orientamento dei componenti.

Nessun criterio di successo di Livello AA per la linea guida 1.3
Nessun criterio di successo di Livello AAA per la linea guida 1.3

Inizio pagina

Salta inserzione pubblicitaria

Linea guida 1.4.

Rendere più facile per le persone con disabilità vedere e ascoltare contenuti che richiedono di separare il primo piano dallo sfondo.

Criteri di successo di Livello A per la linea guida 1.4

1.4.1 Uso del colore. Ogni informazione veicolata per mezzo di differenze di colore è nello stesso tempo evidente visivamente anche senza le differenze di colore.

1.4.2 Spegnere l'audio. Se dell'audio è riprodotto automaticamente per più di 3 secondi, è disponibile un meccanismo per mettere in pausa o fermare l'audio oppure è disponibile un meccanismo per controllare il volume dell'audio in modo che possa essere regolato indipendentemente dal volume del sistema.

[Inizio approfondimento] Struttura, presentazione e contenuto

Nelle WCAG 2.0 il termine struttura può avere due significati: 1) il modo in cui le parti di una pagina web sono organizzate in reciproca relazione; 2) il modo in cui una collezione di pagine web è organizzata. La presentazione, invece, è definita come la riproduzione del contenuto in una forma che può essere percepita dagli utenti. Infine, il contenuto (o meglio il contenuto web) sono le informazioni o l'esperienza sensoriale da comunicare all'utente per mezzo di un programma utente, come pure per mezzo del codice o della marcatura che definiscono la struttura, la presentazione e le interazioni associate con quegli elementi. [Fine approfondimento]

[Inizio approfondimento] Programmaticamente determinato

È un'espressione introdotta dalle WCAG 2.0. Indica un'informazione che, a partire da dati forniti dall'autore, può essere ricavata e usata dai programmi utente, comprese le tecnologie assistive, e presentata all'utente in differenti modalità. Un esempio sono le informazioni sulla lingua inserite nel codice di marcatura. Spetta agli autori definire tramite appositi elementi e attributi la lingua del contenuto, mentre spetta ai programmi utente determinare programmaticamente quest'informazione, cioè ricavarla dal codice di marcatura ed elaborarla in tutti i modi possibili. [Fine approfondimento]

Criteri di successo di Livello AA per la linea guida 1.4

1.4.3 Contrasto (minimo). Il testo (e le immagini del testo) hanno un rapporto di contrasto di almeno 5:1, tranne quando il testo è puramente decorativo. Testo e immagini del testo sovradimensionati [larger-scale] possono avere un rapporto di contrasto di 3:1.

1.4.4 Ridimensionamento del testo. Il testo riprodotto visualmente può essere ingrandito fino al 200 per cento e rimpicciolito fino al 50 per cento senza il ricorso a tecnologie assistive e senza perdite di contenuto o di funzionalità.

Criteri di successo di Livello AAA per la linea guida 1.4

1.4.5 Contrasto (potenziato). Il testo (e le immagini del testo) hanno un rapporto di contrasto di almeno 7:1, tranne quando il testo è puramente decorativo. Testo e immagini del testo sovradimensionati [larger-scale] possono avere un rapporto di contrasto di 5:1.

1.4.6 Audio di sfondo basso o mancante. I contenuti audio in cui vi è del parlato in primo piano non contengono suoni di sfondo, i suoni di sfondo possono essere spenti oppure i suoni di sfondo solo almeno 20 decibel più bassi del contenuto parlato in primo piano, con l'eccezione di occasionali effetti sonori.

Nota. I suoni di sfondo che soddisfano il requisito hanno un'intensità equivalente approssimativamente a un quarto di quella del contenuto parlato in primo piano.

1.4.7 Ridimensionamento e avvolgimento. Il testo riprodotto visivamente può essere ingrandito fino al 200 per cento e rimpicciolito fino al 50 per cento senza il ricorso a tecnologie assistive e senza perdite di contenuto o di funzionalità, e in un modo che non richieda all'utente di scorrere il testo orizzontalmente.

[Inizio approfondimento] Testo puramente decorativo [pure decoration]

Un testo è definito come puramente decorativo se serve soltanto a uno scopo estetico, non fornendo alcuna informazione e non avendo alcuna funzionalità. Il glossario delle WCAG 2.0 aggiunge una nota, che chiarisce meglio il concetto: un testo è puramente decorativo, se le parole che lo compongono possono essere ridisposte o sostituite senza che cambi il suo scopo. Viene fornito anche un esempio: la copertina di un dizionario, che ha sullo sfondo del testo molto poco contrastato. Un simile testo è puramente decorativo perché sta lì per sole ragioni estetiche, non per veicolare informazione. [Fine approfondimento]

[Inizio approfondimento] Testo sovradimensionato [larger-scale]

Il glossario delle WCAG 2.0 definisce larger-scale un testo che abbia una dimensione di almeno 18 punti (pt), o anche di soli 14 punti se formattato in grassetto. La definizione è accompagnata da due note. La prima precisa: “I caratteri dal tratto straordinariamente sottile o di aspetto e caratteristiche inusuali, che diminuiscono la familiarità della forma delle lettere, sono più difficili da leggere, specialmente a più bassi livelli di contrasto”. La seconda nota aggiunge: “La dimensione del carattere è la dimensione con cui il contenuto è servito. Non include il ridimensionamento che può essere operato dall'utente”. [Fine approfondimento]

[Inizio approfondimento] L'algoritmo delle WCAG 2.0 per la valutazione del contrasto

Nelle WCAG 1.0, il contrasto tra primo piano e sfondo deve superare due soglie definite da due diverse formule: una per il calcolo del contrasto cromatico (la soglia deve essere maggiore di 500) e una per il calcolo della differenza di luminosità (la soglia, in questo caso, deve essere maggiore di 125). Le due formule e le criticità del metodo sono state illustrate alla fine del Capitolo 5.

Le WCAG 2.0 cambiano strada. Invece di due formule, una sola, molto più semplice: (L1 + 0,05) / (L2 + 0,05), dove L1 è la luminanza relativa del colore più luminoso del primo piano o dello sfondo e L2 è la luminanza relativa (relative luminance) del colore più scuro del primo piano o dello sfondo. Lo 0,05 da aggiungere ai due valori serve per compensare l'effetto di leggero bagliore provocato dalla luce ambiente.

L'enunciazione della formula è accompagnata, nel glossario delle WCAG 2.0, dalle seguenti note.

  • Nota 1. Il rapporto di contrasto (contrast ratio) può variare da 1 a 21, cioè da 1:1 a 21:1.
  • Nota 2. Per i colori rappresentati dall'accostamento di punti di colori differenti (dithered colors), usare i valori medi dei colori generati per accostamento (R medio, G medio, B medio).
  • Nota 3. Il testo può essere valutato senza l'anti-aliasing.
  • Nota 4. Il colore di sfondo è il colore specificato per il contenuto sul quale il testo viene riprodotto nell'uso normale. Se non è specificato alcun colore di sfondo, si assume allora il bianco.
  • Nota 5. Per il testo visualizzato su gradienti [superfici che sfumano da un colore all'altro] o su immagini di sfondo, gli autori dovrebbero garantire che esiste un sufficiente contrasto per ogni parte di ciascun carattere presente nel contenuto.

L'algoritmo delle WCAG 2.0 ha il pregio di eliminare il calcolo della differenza cromatica usato nelle WCAG 1.0, focalizzando la propria azione, come è più corretto che sia, sul solo calcolo della differenza di luminosità, che è l'elemento realmente discriminante per l'accessibilità dei contrasti tra primo piano e sfondo (si legge nel documento Understanding WCAG 2.0: I deficit di percezione del colore possono influenzare in qualche misura il contrasto di luminanza. Tuttavia, nella raccomandazione, il contrasto è calcolato in maniera tale che il colore non costituisce un fattore chiave, così che anche le persone che hanno un deficit nella visione dei colori avranno un contrasto adeguato tra il testo e lo sfondo).

Un altro elemento di progresso nel trattamento dell'accessibilità del contrasto è dato, nelle WCAG 2.0, dalla definizione di soglie di contrasto differenti da superare, a seconda degli obiettivi che si intendono raggiungere e del tipo di testo a cui il calcolo si applica. Abbiamo così una soglia di contrasto minima di 3:1, che vale il superamento del criterio di successo 1.4.3 (livello AA) se il testo ha una dimensione di almeno 18 punti o anche di 14 punti se è in grassetto. La soglia diventa 5:1, se il testo non raggiunge le dimensioni indicate oppure le raggiunge, ma si intende superare il contrasto potenziato del criterio di successo 1.4.5 (livello AAA). Si finisce con una soglia di contrasto di 7:1, necessaria per il superamento del criterio di successo 1.4.5 quando la dimensione del testo è al di sotto dei 18 punti (o dei 14 se è in grassetto).



Figura 20.2. I tre campioni nel riquadro in alto superano il criterio di successo 1.4.3; i tre campioni nel riquadro in basso superano il criterio di successo 1.4.5.

Numerosi esempi di accoppiamenti primo piano/sfondo e dei relativi valori di contrasto sono disponibili sul sito del Trace Center, presso l'Università di Wisconsin-Madison (Index of Color Contrast Samples collegamento esterno). Chi vuole testare il contrasto di luminosità con il nuovo algoritmo del W3C, può utilizzare l'analizzatore online realizzato da Gez Lemon collegamento esterno. Lo stesso Gez Lemon ha realizzato una pagina d'esempio collegamento esterno che mette a confronto una serie di campioni di colore, valutandoli sia con gli algoritmi usati per le WCAG 1.0 sia con quello per le WCAG 2.0.

Per gli sviluppatori che hanno bisogno di testare in situazioni di lavoro il contrasto tra primo piano e sfondo secondo il nuovo algoritmo delle WCAG 2.0, è disponibile un software apposito, chiamato Colour Contrast Analyser, sviluppato da Steve Faulkner e tradotto in italiano da Roberto Castaldo. Il programma consente di verificare se una coppia di colori supera le soglie di contrasto definite per entrambi i criteri di successo interessati (1.4.3 e 1.4.5) e, per entrambi, sia per il testo normale sia per il testo ingrandito (Figura 20.3). È possibile scaricare la versione italiana dal sito di Webaccessibile collegamento esterno.

Figura 20.3. L'interfaccia del Colour Contrast Analyser. Nell'esempio, la coppia di colori prescelti supera entrambe le soglie di contrasto del criterio di successo 1.4.3 e la sola soglia per il testo ingrandito del criterio di successo 1.4.5.

[Fine approfondimento]
[Inizio approfondimento] Luminanza relativa

La brillantezza relativa percepita di un qualsiasi punto, normalizzata a 0 per il nero e a 1 per il bianco più brillante. La luminanza relativa di un colore sRGB (standard RGB) è definita dalla formula L = 0.2126 × R + 0.7152 × G + 0.0722 × B, dove R, G e B sono i valori rispettivi del rosso, del verde e del blu, calcolati – nei sistemi di codifica del colore a 8 bit – su una scala che va da 0 a 255. [Fine approfondimento]

Inizio pagina

Principio 2. Utilizzabile

I componenti dell'interfaccia devono essere utilizzabili dall'utente.

Linea guida 2.1.

Rendere tutte le funzionalità disponibili da tastiera.

Criteri di successo di Livello A per la linea guida 2.1

2.1.1 Tastiera. Tutte le funzionalità del contenuto sono utilizzabili attraverso un'interfaccia a tastiera, senza richiedere che singoli tasti siano premuti entro un tempo determinato, eccetto quando il compito da svolgere richiede un input che dipende dalla serie dei movimenti dell'utente e non semplicemente dal loro punto conclusivo.

Nota 1. Questa eccezione è correlata alla funzione sottostante, non al metodo di input. Per esempio, se si usa la scrittura manuale per immettere del testo, il metodo di input (scrivere a mano) richiede un input dipendente dalla serie dei movimenti, ma la funzione sottostante (l'inserimento del testo) no.

Nota 2. Ciò non vieta né dovrebbe scoraggiare il fornire input attraverso il mouse o altri metodi, in aggiunta alle operazioni da tastiera.

Nessun criterio di successo di Livello AA per la linea guida 2.1
Criteri di successo di Livello AAA per la linea guida 2.1

2.1.2 Tastiera (nessuna eccezione). Tutte le funzionalità del contenuto sono utilizzabili attraverso un'interfaccia a tastiera, in modo non dipendente dal tempo.

[Inizio approfondimento] Interfaccia a tastiera [keyboard interface]

È importante notare che il criterio di successo 2.1.1 richiede che le funzioni siano utilizzabili attraverso un'interfaccia a tastiera, che è qualcosa di più e di diverso rispetto a una semplice tastiera fisica. Alcuni utenti, infatti, non possono utilizzare, o per disabilità fisiche o a causa del dispositivo su cui stanno lavorando, una tastiera fisica, ma usano al suo posto un software che emula una tastiera. Si vedano in proposito gli esempi mostrati nel Capitolo 2 (Figure 2.48 e 2.54). Una delle differenze tra una tastiera fisica e un'emulazione è che nel secondo caso le combinazioni di tasti premuti contemporaneamente devono essere trasformate in sequenze di tasti, da premere in successione. [Fine approfondimento]

[Inizio approfondimento] Tipi di input che dipendono dalla serie dei movimenti

La limitazione che conclude il testo del criterio di successo 2.1.1 (eccetto quando il compito da svolgere richiede un input che dipende dalla serie dei movimenti dell'utente e non semplicemente dal loro punto conclusivo) fa riferimento a una particolare classe di operazioni di input che non possono avere un equivalente da tastiera. Disegnare a mano libera, dipingere ad acquerello, guidare un elicottero attraverso un percorso ad ostacoli sono esempi di operazioni che non possono essere emulate da una ragionevole sequenza di tasti. Al contrario, vi sono numerose operazioni eseguite normalmente con il mouse che possono avere un equivalente da tastiera. A parte le azioni fondamentali come fare clic, selezionare, muovere e ridimensionare, possono essere eseguiti da tastiera disegni di linee rette e forme geometriche regolari e lo spostamento di oggetti da un luogo ad un altro (quando il percorso seguito non sia rilevante). [Fine approfondimento]

Inizio pagina

Linea guida 2.2.

Fornire agli utenti con disabilità un tempo sufficiente per leggere e usare il contenuto.

Criteri di successo di Livello A per la linea guida 2.2

2.2.1 Temporizzazione. Per ciascun limite di tempo determinato dal contenuto, è vera almeno una delle condizioni seguenti.

Criteri di successo di Livello AA per la linea guida 2.2

2.2.2 Intermittenza. Il contenuto non è intermittente per più di tre secondi o è disponibile un meccanismo per fermare ogni contenuto intermittente nella pagina web.

Nota. Per i requisiti relativi a contenuti sfarfallanti o lampeggianti, fare riferimento alla linea guida 2.3.

2.2.3 Pausa. Informazioni che si muovono, sono intermittenti, scorrono o si autoaggiornano possono essere messe in pausa dall'utente, a meno che non facciano parte di un'attività in cui la temporizzazione o il movimento sono essenziali. Il contenuto mobile puramente decorativo può essere fermato dall'utente.

Criteri di successo di Livello AAA per la linea guida 2.2

2.2.4 Temporizzazione. La temporizzazione non è una parte essenziale dell'evento o dell'attività presentata dal contenuto, eccetto che per la multimedialità non interattiva e per gli eventi in tempo reale.

2.2.5 Interruzioni. Le interruzioni, come quelle per l'aggiornamento dei contenuti, possono essere posposte o soppresse dall'utente, eccetto le interruzioni che coinvolgono un'emergenza.

2.2.6 Ri-autenticazione. Quando termina una sessione autenticata, l'utente può continuare l'attività senza perdita di dati dopo essersi ri-autenticato.

[Inizio approfondimento] Intermittenza [blink]

Le WCAG 2.0 intendono per intermittenza (blink in inglese) l'accendersi e lo spegnersi di un oggetto con intervalli che vanno da 0,5 a 3 volte per secondo. L'intermittenza, più lenta, è in contrapposizione con il lampeggiamento (flashing in inglese), che si riferisce a veloci cambiamenti di intensità luminosa, che sono in grado di scatenare attacchi nei soggetti predisposti. [Fine approfondimento]

Inizio pagina

Linea guida 2.3.

Non creare contenuti che sono noti per scatenare attacchi.

Criteri di successo di Livello A per la linea guida 2.3

2.3.1 Tre lampi o sotto la soglia. Nel contenuto non vi è nulla che lampeggia più di tre volte per ogni intervallo di un secondo o il lampo è al di sotto della soglia generale di lampeggiamento e della soglia del lampo rosso.

Nessun criterio di successo di Livello AA per la linea guida 2.3
Criteri di successo di Livello AAA per la linea guida 2.3

2.3.2 Tre lampi. Nel contenuto non vi è nulla che lampeggia più di tre volte per ogni intervallo di un secondo.

[Inizio approfondimento] Soglia generale di lampeggiamento (general flash threshold)

È definita nelle WCAG 2.0 come una sequenza di lampi o una serie di immagini che cambiano rapidamente, per le quali sono vere tutte e quattro le condizioni seguenti:

  1. avvengono più di tre lampi per ogni intervallo di un secondo;
  2. il lampeggiamento è al di sotto dei 50 Hz;
  3. la luminanza relativa dell'immagine più scura è al di sotto della soglia di 0,8;
  4. l'area combinata coperta dai lampi che avvengono simultaneamente e in zone contingue occupa più di 0,006 steradianti totali (o un quarto di ogni dieci gradi di campo visivo sullo schermo).

Un lampo è definito come una coppia di cambiamenti di segno opposto, pari al 10% o più dell'intensità del bianco puro. Un cambiamento di segno opposto (opposing change) è un incremento di luminosità seguito da un decremento o un decremento seguito da un incremento.

Per il contenuto web in generale, un rettangolo di 341×256 pixel, posizionato in un qualsiasi punto dello schermo, copre con buona approssimazione un angolo visivo di 10 gradi, se la risoluzione impostata è di 1024×768 pixel, considerando uno schermo di dimensioni standard e una distanza media dell'utente dallo schermo.

Se un rettangolo di 341×256 pixel corrisponde a 10 gradi, allora l'angolo solido di 0,006 steradianti, richiesto come soglia dal requisito, dovrebbe corrispondere a un quarto di quel rettangolo e cioè, approssimativamente, a un rettangolo di 170×128 pixel. [Fine approfondimento]

[Inizio approfondimento] Soglia del lampo rosso (red flash threshold)

Transizione verso o da un rosso saturo, nella quale sono vere tutte e tre le condizioni seguenti: 1) si verificano più di tre lampi per ogni intervallo di un secondo; 2) il lampeggiamento ha una frequenza inferiore a 50 Hz; 3) l'area combinata coperta dai lampi che avvengono simultaneamente e in zone contingue occupa più di 0,006 steradianti totali (o un quarto di ogni dieci gradi di campo visivo sullo schermo). [Fine approfondimento]

[Inizio approfondimento] Steradiante

Unità di misura degli angoli solidi (sterangoli), indicata con il simbolo sr: corrisponde all'angolo sotto il quale si vede, dal centro di una sfera, una porzione di superficie sferica equivalente al quadrato del raggio della sfera. [Fine approfondimento]

Inizio pagina

Linea guida 2.4.

Fornire modi per aiutare gli utenti con disabilità a navigare, a trovare i contenuti e a determinare dove si trovano.

Criteri di successo di Livello A per la linea guida 2.4

2.4.1 Evitare blocchi. È disponibile un meccanismo per evitare blocchi di contenuto che si ripetono su molteplici pagine web.

2.4.2 Pagine titolate. Le pagine web hanno titoli descrittivi.

2.4.3 Ordine del focus. Se una pagina web può essere navigata sequenzialmente, i componenti che possono ricevere il focus ricevono il focus in un ordine che segue le informazioni e le relazioni convogliate attraverso la presentazione.

2.4.4 Scopo dei link (contesto). Lo scopo di ciascun collegamento può essere determinato dal suo testo e dal suo contesto programmaticamente determinato [una nota editoriale avvisa che questo criterio di successo potrebbe essere spostato ad un altro livello, se dovesse essere accertato che i contenuti rimangono accessibili alle tecnologie assistive anche quando questo criterio non è superato].

Criteri di successo di Livello AA per la linea guida 2.4

2.4.5 Molteplici modi. È disponibile più di un modo per localizzare i contenuti all'interno di un insieme di pagine web, laddove il contenuto non sia il risultato o lo stadio di un processo.

2.4.6 Etichette descrittive. Titoli ed etichette sono descrittivi.

Criteri di successo di Livello AAA per la linea guida 2.4

2.4.7 Posizione. Sono disponibili informazioni sulla posizione dell'utente all'interno di un insieme di pagine web.

2.4.8 Scopo dei link (testo dei link). Lo scopo di ciascun collegamento può essere identificato dal testo del collegamento.

2.4.9 Intestazioni di sezione. Laddove i contenuti sono organizzati in sezioni, le sezioni sono indicate da intestazioni.

Inizio pagina

Principio 3. Comprensibile

Informazioni e operazioni dell'interfaccia utente devono essere comprensibili per gli utenti.

Linea guida 3.1.

Rendere il contenuto testuale leggibile e comprensibile.

[Inizio approfondimento] Pagina web (Web page)

È definita nelle WCAG 2.0 come “una risorsa che è referenziata da un URI e che non è incorporata in un'altra risorsa, più qualsiasi altra risorsa che viene riprodotta insieme con essa o è progettata per essere riprodotta insieme”. Una nota precisa poi che le altre risorse, che dovrebbero essere riprodotte insieme con la risorsa primaria identificata dall'URI, non necessariamente devono essere riprodotte simultaneamente l'una rispetto all'altra.

Non è una definizione molto felice (le specifiche W3C non brillano in generale per la qualità dei glossari). Tuttavia si capisce meglio il significato di pagina web, ricavandolo dai quattro esempi che accompagnano la definizione.

  • Esempio 1. Un ambiente interattivo animato per acquisti online, nel quale l'utente si muove visualmente attraverso un negozio, prendendo i prodotti dagli scaffali e collocandoli all'interno di un carrello posto davanti ad essi. Cliccando su un prodotto, parte una dimostrazione che apre un foglio di specifiche di fianco al carrello.
  • Esempio 2. Una risorsa web che include tutte le immagini e i media incorporati.
  • Esempio 3. Un programma di posta web (Web mail) costruito usando Asynchronous JavaScript and XML (AJAX). Il programma vive interamente a http://mail.example.com, ma include una casella di posta, un'area contatti e un calendario. Sono presenti collegamenti o pulsanti che permettono di visualizzare la casella di posta, i contatti o il calendario, ma non cambiano l'URL della pagina considerata come un intero.
  • Esempio 4. Un portale personalizzabile, nel quale gli utenti possono scegliere i contenuti da visualizzare, tra una serie di moduli di contenuto differenti.

Come si può dedurre da quanto qui sopra riportato, le WCAG 2.0 ridefiniscono il concetto di pagina web, allargandolo a comprendere le moderne interfacce utente interattive e dinamiche, a cui poco si adatterebbe l'idea di pagina web che è alla base delle WCAG 1.0 (cioè un documento HTML fatto per lo più di testo e immagini, in cui l'interattività e le nuove tecnologie compaiono al massimo come elementi incorporati. Si veda l'esempio numero 2).

Il cammino per arrivare a questa definizione non è stato tuttavia né semplice né diretto. Fino alla bozza di aprile 2006 delle WCAG 2.0 collegamento esterno, la pagina web non esisteva più, sostituita dalla Web unit, o unità web, di cui è possibile leggere la definizione, comunque simile a quella di pagina web. Poi, soprattutto per non creare possibili ambiguità dovute all'introduzione di un tecnicismo di uso non comune, gli estensori delle WCAG 2.0 hanno deciso di ripristinare la ben nota e consolidata forma Web page (pagina web). [Fine approfondimento]

Criteri di successo di Livello A per la linea guida 3.1

3.1.1 Lingua della pagina. La lingua predefinita del contenuto di ciascuna pagina web può essere programmaticamente determinata.

Criteri di successo di Livello AA per la linea guida 3.1

3.1.2 Lingua delle parti. La lingua di ciascun passaggio o frase nel contenuto può essere programmaticamente determinata.

Nota. Questo requisito non si applica a singole parole. Non si applica neppure a nomi propri, termini tecnici o frasi che sono divenuti parte della lingua del contesto in cui sono adoperati [questa nota risolve molte delle ambiguità che nascono dall'indeterminatezza del punto di controllo 4.1 delle WCAG 1.0. Si veda il Capitolo 7 per spiegazioni più dettagliate].

Criteri di successo di Livello AAA per la linea guida 3.1

3.1.3 Parole inusuali. È disponibile un meccanismo per identificare le definizioni specifiche di parole o frasi usate in un'accezione inusuale o ristretta, compresi gerghi ed espressioni idiomatiche.

3.1.4 Abbreviazioni. È disponibile un meccanismo per trovare la forma estesa o il significato delle abbreviazioni.

3.1.5 Leggibilità. Quando il testo richiede capacità di lettura più avanzate del livello della scuola media inferiore, sono disponibili contenuti integrativi oppure una versione alternativa che non richiede capacità di lettura superiori a quelle del livello della scuola media inferiore.

3.1.6 Pronuncia. È disponibile un meccanismo per identificare la specifica pronuncia di parole, il cui significato è ambiguo se non si conosce la pronuncia.

[Inizio approfondimento] Abbreviazioni, inizialismi, acronimi

Un'abbreviazione è definita nelle WCAG 2.0 come la forma abbreviata di una parola, di una frase o di un nome. È specificato poi in una nota che le abbreviazioni includono inizialismi e acronimi. Un inizialismo è definito come la forma abbreviata di un nome o di una frase, composta dalle lettere iniziali delle parole o delle sillabe contenute in quel nome o in quella frase. Come esempio di inizialismo è proposto SNCF, che sta per Sociétè Nationale des Chemins de Fer (l'ente nazionale francese delle ferrovie). Un acronimo è invece definito come una forma abbreviata composta dalle lettere iniziali o da parti di altre parole (in un nome o in una frase) che possono essere pronunciate come una parola. Posto che le definizioni qui esposte sono valide soprattutto per l'inglese, un esempio in italiano di acronimo è la sigla NATO (si pronuncia come una parola), mentre un esempio di inizialismo è HTML (si pronunciano le singole lettere). Un'analisi delle forme abbreviate in italiano è disponibile sul sito web dell'Accademia della Crusca collegamento esterno. [Fine approfondimento]

[Inizio approfondimento] Versione alternativa (alternate version)

Nelle WCAG 2.0, è una versione che fornisce tutte le informazioni e le funzionalità del contenuto non conforme, è realizzata nella medesima lingua ed è aggiornata con la stessa frequenza di quello. Per informazioni dettagliate sulle conformità delle versioni alternative, si consulti il documento WAI/W3C Alternate Versions Conformance Requirement collegamento esterno. [Fine approfondimento]

Inizio pagina

Linea guida 3.2.

Fare in modo che le pagine web appaiano e funzionino in modo predicibile.

Criteri di successo di Livello A per la linea guida 3.2

3.2.1 Sul focus. Quando un qualsiasi componente riceve il focus, non inizia un cambiamento di contesto.

3.2.2 Sull'input. Cambiare le impostazioni di qualsiasi componente dell'interfaccia utente non produce automaticamente un cambiamento di contesto, a meno che l'utente sia stato avvertito del comportamento prima di usare il componente.

Criteri di successo di Livello AA per la linea guida 3.2

3.2.3 Navigazione coerente. I meccanismi di navigazione che si ripetono su più pagine web all'interno di un insieme di pagine web si trovano nel medesimo ordine relativo ogni volta che sono ripetuti, a meno che non sia l'utente a iniziare un cambiamento.

3.2.4 Identificazione coerente. I componenti che hanno le medesime funzionalità all'interno di un insieme di pagine web sono identificati in maniera coerente.

Criteri di successo di Livello AAA per la linea guida 3.2

3.2.5 Cambiamenti su richiesta. I cambiamenti di contesto sono iniziati unicamente da una richiesta dell'utente.

[Inizio approfondimento] Cambiamento di contesto (change of context)

È un cambiamento che può avere quattro specie: 1) cambio di programma utente; 2) cambio di finestra nel programma utente; 3) spostamento del focus; 4) modifiche del contenuto che alterano il significato della pagina web. Una nota aggiunge che i cambiamenti nel contenuto non sono sempre cambiamenti di contesto: per esempio, piccoli cambiamenti come l'espansione di un contorno o di un menu dinamico non sono da considerare cambiamenti di contesto. [Fine approfondimento]

Inizio pagina

Linea guida 3.3.

Aiutare gli utenti a evitare e correggere gli errori.

Criteri di successo di Livello A per la linea guida 3.3

3.3.1 Identificazione degli errori. Se un errore di immissione è rilevato automaticamente, l'elemento che è in errore è identificato e descritto all'utente nel testo.

Criteri di successo di Livello AA per la linea guida 3.3

3.3.2 Suggerimenti per gli errori. Se un errore di immissione è rilevato e i suggerimenti per correggerlo sono noti, allora i suggerimenti sono presentati all'utente, a meno che ciò non metta a repentaglio la sicurezza o lo scopo del contenuto.

3.3.3 Prevenzione degli errori (legali, finanziari, dati). Per i moduli che producono obblighi di legge o transazioni finanziarie, che modificano o cancellano dati controllabili dall'utente nei sistemi di archiviazione o che inviano risposte a test, almeno una delle seguenti condizioni è vera.

3.3.4 Etichette o istruzioni. Sono fornite etichette o istruzioni quando il contenuto richiede un input da parte dell'utente.

Criteri di successo di Livello AAA per la linea guida 3.3

3.3.5 Aiuto. È disponibile un aiuto dipendente dal contesto.

3.3.6 Prevenzione degli errori (tutti). Per i moduli che richiedono che l'utente invii informazioni, almeno una delle seguenti condizioni è vera.

[Inizio approfondimento] Processo

Una serie di azioni dell'utente, nella quale ogni azione è necessaria al fine di completare un'attività. Esempio 1: una serie di pagine web su un sito di commercio elettronico richiede che gli utenti vedano prodotti alternativi e i relativi prezzi, selezionino i prodotti, inviino il proprio ordine, forniscano informazioni per la spedizione e per il pagamento. Esempio 2: La pagina di registrazione di un conto personale richiede di completare con successo un test di Turing (cioè di risolvere un CAPTCHA), prima che sia possibile accedere al modulo di registrazione. [Fine approfondimento]

Inizio pagina

Salta inserzione pubblicitaria

Principio 4. Robusto

I contenuti devono essere sufficientemente robusti, da poter essere interpretati affidabilmente da un'ampia varietà di programmi utente, comprese le tecnologie assistive.

Linea guida 4.1.

Rendere massima la compatibilità con gli attuali e i futuri programmi utente, comprese le tecnologie assistive.

Criteri di successo di Livello A per la linea guida 4.1

4.1.1 Analisi [Parsing]. I contenuti implementati usando linguaggi di marcatura hanno elementi con marcatori iniziali e finali completi, tranne quando consentito dalle relative specifiche, e sono annidati in accordo con le relative specifiche.

Nota. Marcatori iniziali e finali a cui manchi un carattere critico nella loro formazione, quali una parentesi angolare di chiusura o delle virgolette mal assortite per un valore di attributo, non sono completi.

4.1.2 Nome, ruolo, valore. Per tutti i componenti dell'interfaccia utente, il nome e il ruolo possono essere programmaticamente determinati; stati, proprietà e valori che possono essere impostati dall'utente possono essere programmaticamente determinati e programmaticamente impostati; e la notifica dei cambiamenti di questi elementi è disponibile ai programmi utente, comprese le tecnologie assistive.

Nessun criterio di successo di Livello AA per la linea guida 4.1
Nessun criterio di successo di Livello AAA per la linea guida 4.1
[Inizio approfondimento] Nomi, etichette e ruoli

Nella terminologia delle WCAG 2.0, il nome (name) è un testo per mezzo del quale un software può identificare un componente all'interno del contenuto web a beneficio dell'utente. Il nome può anche essere nascosto all'utente ed esposto solo alle tecnologie assistive, mentre un'etichetta (label) è presentata all'utente anche in assenza di tecnologie assistive. In molti, ma non in tutti i casi, l'etichetta è una visualizzazione del nome. Il ruolo (role) è un testo o un numero per mezzo del quale un software può identificare la funzione di un componente all'interno del contenuto web a beneficio dell'utente. Per maggiori informazioni su ruoli e stati, si veda il paragrafo Uso di ruoli, stati e proprietà ARIA in XHTML e JavaScript, nel Capitolo 11. [Fine approfondimento]

[Inizio approfondimento] Programmaticamente impostato [programmatically set]

Impostato dal software, usando metodi che sono supportati dai programmi utente, comprese le tecnologie assistive. [Fine approfondimento]

[Inizio approfondimento] Le WCAG 2.0 non richiedono un codice di marcatura a zero errori

È degno di nota il dettato del criterio di successo 4.1.1. Il requisito della robustezza del codice è richiesto come fattore di interoperabilità, cioè di compatibilità con i più disparati programmi utente. Il criterio di successo non richiede però un codice che passi con zero errori l'analisi di un software di validazione, cosa che metterebbe in crisi la grande maggioranza degli autori di pagine web e chiunque non utilizzi un CMS dotato di sufficienti misure di controllo sul codice. Si limita a richiedere che gli elementi siano completi di marcatore iniziale e finale (tranne che nei casi ammessi dalle specifiche: per esempio gli elementi P e TD in HTML) e siano annidati correttamente. [Fine approfondimento]

Inizio pagina

Tasti di accesso rapido: Indice generale 0 | Capitolo precedente 1 | Capitolo successivo 2 | Glossario 3 | Indice analitico 4 | Torna a inizio pagina 5 | Diodati.org 6 | Forum accessibili 7 | Commenti dei lettori 8 | Recensioni e citazioni 9
Creative Commons License
Accessibilità Guida completa versione HTML by Michele Diodati is licensed under a Creative Commons Attribuzione-Non commerciale-Non opere derivate 2.5 Italia License.