Questo documento è una traduzione della Working Draft relativa alle Linee Guida per l'Accessibilità ai Contenuti Web 2.0. Questo documento potrebbe contenere errori di traduzione.
Copyright © 2004 W3C ® ( MIT , ERCIM , Keio), Tutti i diritti riservati. Si applicano le regole del W3C riguardanti la responsabilità, il marchio depositato, l' uso dei documenti e le licenze software .
Il World Wide Web Consortium (W3C) ha pubblicato nel maggio 1999 le Web Content Accessibility Guidelines 1.0 (WCAG 1.0) sotto forma di Reccommendation. L’attuale Working Draft per la versione 2.0 si basa sulle WCAG 1.0. Ha lo stesso scopo: spiegare come costruire materiali Web accessibili ad utenti disabili e stabilire come obiettivo dei livelli di accessibilità. Avendo tenuto in debito conto il feedback relativo alle WCAG 1.0, la Working Draft 2.0 si concentra sulle linee guida che tenta di applicare ad un’ampia gamma di tecnologie e si sforza di usare una terminologia comprensibile ad un più vasto uditorio.
In questa sezione viene descritto lo stato del documento all’atto della sua pubblicazione. Altri documenti possono prenderne il posto. Un elenco delle correnti pubblicazioni del W3C e l’ultima revisione di questo rapporto tecnico sono reperibili nel W3C technical reports index all’indirizzo http://www.w3.org/TR/.
Questo documento è stato redatto dal Web Content Accessibility Guidelines Working Group (WCAG WG) per mostrare come leggere linee guida (less HTML-specific)WCAG più generiche (meno specifiche per l’HTML). Questa draft non si basa ancora sul consenso del WCAG Working Group né ha superato il cammino di un documento tecnico del W3C, né soppianta le WCAG 1.0.
Far riferimento a "Issue Tracking for WCAG 2.0 Working Draft" per un elenco di questioni aperte relative a questa Working Draft. E’ anche disponibile la "History of Changes to WCAG 2.0 Working Drafts".
Pubblicazioni tipo una Working Draft non implica l’approvazione dei membri del W3C. Questo documento è in stato di bozza e può essere aggiornato, sostituito o reso obsoleto da altri documenti in qualunque momento. Va citato unicamente come work in progress. E’ disponibile un elenco dei current W3C Recommendations and other technical documents current W3C Recommendations and other technical documents.
The Working Group attende commenti a questo documento all’indirizzo public-comments-wcag20@w3.org. Gli archives for this list sono di dominio pubblico, così come gli archivi relativi alle WCAG WG mailing list discussions.
Questo documento è stato prodotto secondo la 24 January 2002 CPP ed è stato emendato attenendosi alla W3C Patent Policy Transition Procedure . Il Working Group rende disponibile una public list of patent disclosures (lista pubblica sull’informativa relativa ai diritti di brevetto) importante per il documento stesso; tale pagina contiene anche istruzioni sull'informativa riguardante un brevetto. Una persona che ha effettiva conoscenza di un brevetto che la stessa persona ritiene contenga Affermazioni Essenziali rispetto a questa specifica dovrebbe rendere nota l'informazione in accordo con la section 6 of the W3C Patent Policy .
Questo documento è stato prodotto come parte del W3C Web Accessibility Initiative (WAI). Gli obiettivi del WCAG WG sono dibattuti nella Working Group charter. Il WCAG WG fa parte di WAI Technical Activity.
Questo documento delinea i principi di progettazione per creare materiali Web accessibili. Laddove tali principi vengano ignorati, gli utenti disabili non saranno in grado di accedere ai contenuti o vi accederanno con grande difficoltà. Se i principi di accessibilità saranno implementati, i contenuti Web diventeranno accessibili tramite molteplici dispositivi, quali telefoni, palmari, cabine telefoniche, apparecchiature di rete e pertanto accessibili agli utenti nelle situazioni più disparate.
I principi di progettazione espressi in questo documento rappresentano concetti generali che si applicano a tutti i contenuti Web, non essendo specifici per l’HTML, XML o qualsiasi altra tecnologia. Si è scelto questo tipo di approccio per consentire l’applicazione dei principi di progettazione a molteplici situazioni e tecnologie, incluse quelle future.
Allo scopo di facilitare la comprensione delle linee guida e aiutare i lettori a focalizzare esattamente le parti di interesse, si è deciso di presentare le linee guida sotto forma di più documenti intercorrelati. Le WCAG 2.0 sono articolate su tre livelli di informazione:
Tale livello ha per titolo "Web Content Accessibility Guidelines 2.0". E’ costituito dal presente documento. Contiene:
Un'introduzione
I 4 principi fondamentali per l'accessibilità (Percepibile, Fruibile, Comprensibile e Robusto).
Le linee guida (non riferite a tecnologie specifiche) (14 in tutto).
I success criteria , test di verifica del successo, (normativi), e le definizioni, i benefici e gli esempi (tutti non normativi) relativi a ciascuna linea guida.
Un’appendice contenente definizioni, riferimenti ed altre informazioni di supporto.
Andranno ad integrare le linee guida tutta una serie di documenti costituiti da liste di controllo inerenti tecnologie specifiche. Questi documenti forniranno informazioni su quanto richiesto nell’uso delle varie tecnologie per conformarsi alla Working Draft delle WCAG 2.0.
Nota dell’ Editore: Tali checklist non sono state ancora organizzate. Al momento, non è chiaro se saranno normative o non-normative. Se le checklist saranno non-normative, sarà più facile aggiornarle. In caso contrario, i cambiamenti ad esse apportate andranno ad alterare la definizione di conformità. Comunque, potrebbe essere indispensabile organizzare checklist normative al fine di rendere le linee guida testabili.
I Techniques Documents includeranno esempi di codice, screen shot e informazioni specifiche relative alle diverse tecnologie. Saranno documenti non normativi. Illustreranno varie strategie, che consentiranno di conformarsi ai requisiti delle linee guida, e gli approcci correnti più utilizzati, laddove esistano. Gli esempi comprenderanno:
Hypertext Markup Language (HTML) and Extensible Hypertext Markup Language (XHTML) Techniques
Server-side scripting Techniques
Client-side scripting Techniques
Scalable Vector Graphics (SVG) Techniques
Synchronized Multimedia Integration Language (SMIL) Techniques
Extensible Markup Language (XML) Techniques
(I sopracitati diventeranno link attivi non appena le corrispondenti Working Draft saranno pubblicate)
Le linee guida sono dirette ad un pubblico vasto, politici, manager, creatori di contenuti Web, programmatori. Ci si è sforzati di rendere il documento leggibile ed usabile per quanto possibile senza trascurare l’accuratezza e la chiarezza necessarie in una specifica di carattere tecnico. Per utenti alle prime armi, è vivamente raccomandato il lavoro Education and Outreach Working Group del WAI.
Le linee guida coprono un’ampia gamma di questioni e raccomandazioni per creare contenuti Web maggiormente accessibili. Includono raccomandazioni per rendere i materiali accessibili ed usabili da utenti con le più disparate disabilità. In genere, non includono raccomandazioni inerenti l’usabilità, eccetto dove esistono specifiche conseguenze per l’accessibilità che vanno al di là dell’effetto degli standard di usabilità.
La Working Draft WCAG 2.0 si basa sulle WCAG 1.0 e sul feedback ricevuto a partire dalla loro pubblicazione, avvenuta nel maggio del 1999. Anche se i due documenti si approcciano in modo identico alle problematiche dell’accessibilità, hanno organizzazione e struttura diverse. Mentre le WCAG 1.0 sono organizzate in linee guida in cui sono inseriti i vari checkpoint, le WCAG 2.0 utilizzano le linee guida per raggruppare i success criteria. Nelle WCAG 1.0, ad ogni checkpoint è assegnato un diverso livello di priorità; nella presente draft i success criteria sono articolati in tre diverse categorie.
I principi di progettazione sono stati riscritti per essere applicati ad un’ampia gamma di tecnologie esistenti e future. La Working Draft WCAG 2.0 non contiene requisiti o tecniche di implementazione relative a tecnologie specifiche, ma farà riferimento a requisiti, esempi e tecniche inerenti tecnologie specifiche (non appena saranno organizzati i relativi documenti).
Il Working Group si sta preoccupando di facilitare la transizione alle WCAG 2.0 per le organizzazioni e per coloro che fanno riferimento alle WCAG 1.0 (che al momento rimangono l’unico documento ufficiale). Per maggiori informazioni riguardanti analogie e differenze fra i checkpoint delle WCAG 1.0 e le linee guida con i relativi success criteria delle WCAG 2.0, si può far riferimento al documento Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft.
Nota dell’Editore: Esistono varie questioni aperte relative allo schema di conformità proposto. Questa sezione delinea lo schema di conformità usato in questo documento. Si auspicano feedback, commenti e proposte.
Le linee guida sono articolate in tre categorie di success criteria:
Success criteria di livello 1:
Realizzano un livello minimo di accessibilità attraverso markup, scripting o altre tecnologie che interagiscono con gli user agent, comprese le tecnologie assistive.
Potrebbero essere ragionevolmente applicati a tutte le risorse Web
Success criteria di livello 2:
Incrementano l'accessibilità attraverso una o entrambe le seguenti:
agevolazioni aggiuntive dello user agent basate sull'accessibilità
il contenuto e/o la presentazione sono direttamente accessibili e non richiedono all'utente o allo user agent di operare in modo diverso rispetto agli utenti non disabili
Potrebbero essere ragionevolmente applicati a tutte le risorse Web.
Success criteria di livello 3:
Vanno oltre i livelli 1 e 2 per incrementare l'accresciuta accesibilità diretta e dello user agent
Il Working Group ritiene che tutti i success criteria dovrebbero essere testabili. I test possono essere realizzati automaticamente tramite il computer o con l'ausilio di esperti in queste linee guida. I test condotti da esperti dovrebbero giungere allo stesso risultato analizzando lo stesso contenuto con gli stessi success criteria.
Nota dell’Editore: Per facilitare la discussione relativa ai livelli assegnati a ciascun criterio, al termine di ciascuno di essi è stata posta una notazione racchiusa in parentesi quadre. “[I]” (invisibile) indica che un criterio non specifica come è presentata l’informazione e “[V]” (visibile) indica che conformarsi al criterio può richiedere all’autore di presentare il contenuto in modo specifico.
Ogni conformità con le WCAG 2.0 richiede che siano soddisfatti tutti i success criteria di livello 1 di tutte le linee guida.
Conformità alle WCAG 2.0 di livello A significa che sono soddisfatti tutti i success criteria di livello 1 di tutte linee guida.
Conformità alle WCAG 2.0 di livello AA significa che sono soddisfatti tutti i success criteria di livello 1 e tutti i success criteria di livello 2 di tutte le linee guida.
Conformità alle WCAG 2.0 di livello AAA significa che sono soddisfatti tutti i success criteria di livello 1, di livello 2 e di livello 3 di tutte le linee guida.
Tutte le dichiarazioni di conformità devono includere come minimo:
La versione delle linee guida in base alla quale è sta dichiarata la conformità.
L'URI dell'authored unit che risulta conforme.
Nota dell'Editore : C'è la questione sollevata da alcuni riguardo a se il termine "authored unit" possa essere abbastanza preciso.
Nota dell'Editore : C'è qualche questione riguardo a se l'URI sia specifico a sufficienza come riferimento al materiale per il quale è stata fatta la dichiarazione di conformità.
Il livello di conformità che è stato dichiarato.
I siti attualmente conformi alle WCAG 1.0, che desiderano passare alle WCAG 2.0, vorranno capitalizzare gli sforzi fatti in passato per raggiungere l’accessibilità. Ciò potrebbe realizzarsi mediante una dichiarazione di conformità con riserva. Una dichiarazione di conformità ad hoc potrebbe essere del tipo: “I materiali creati o modificati prima del 24 aprile 2003 sono conformi alle WCAG 1.0. Quelli creati o modificati in data o dopo il 24 aprile 2003 sono conformi alle WCAG 2.0 ”.
Nota dell’Editore: A seconda dei success criteria, potrebbe risultare più semplice o più complicato conformarsi alla WCAG 2.0 Working Draft che alla WCAG 1.0 Recommendation. Il WCAG WG prenderà in considerazione le differenze fra la conformità secondo le WCAG 1.0 e quella secondo le WCAG 2.0 e fornirà comunicazione agli sviluppatori che attualmente si conformano alle WCAG 1.0. Tale comunicazione, che non è stata ancora organizzata, potrebbe assumere la forma di un profilo di conformità tra WCAG 1.0 e WCAG 2.0 e informare su come passare dalle WCAG 1.0 alle WCAG 2.0.
L’obiettivo principale è creare materiale Web che sia percepibile, fruibile e comprensibile da una molteplicità di utenti e compatibile con un’ampia gamma di tecnologie assistive, attuali e future. I principi fondamentali sono:
Rendere i contenuti percepibili.
Rendere fruibili gli elementi dell’interfaccia nel contenuto.
Rendere comprensibili contenuti e comandi.
Progettare contenuti sufficientemente robusti al fine di garantirne la compatibilità con le tecnologie presenti e future.
Rendere accessibile i contenuti Web va a vantaggio di moltissimi utenti, non solo di quelli con disabilità. Nel mondo fisico, le rampe sono usate dalle biciclette, dalle persone con passeggini e da quelle in carrozzella. Parimenti, dei contenuti Web accessibili beneficerà una grande varietà di utenti, con o senza disabilità. Ad esempio, chi si trova temporaneamente ad operare in condizioni poco consone (es. ambienti rumorosi che impediscono di ascoltare bene o sguardo rivolto alla strada mentre si è alla guida della propria auto), può trarre benefici da un sito accessibile. Allo stesso modo, un motore di ricerca può trovare una citazione famosa in un film se esso è sottotitolato.
Nota:
I principi di progettazione si applicano solo ai contenuti Web rivolti ad un lettore umano. Un database o un insieme di metadata destinati all’uso di altre macchine, e che non richiedono interfaccia, non rientrano nel campo d’azione di queste linee guida.
Di seguito sono rappresentati alcuni scenari senza alcuna pretesa di esaustività nei riguardi dei vari tipi di disabilità e bisogni:
Chi non può sentire desidera una rappresentazione visiva delle informazioni veicolate col sonoro.
Chi non può vedere desidera ascoltare o sentire (mediante braille o grafici tattili) l’equivalente dell’informazione visiva.
Chi ha difficoltà nei movimenti desidera utilizzare piccolissimi spostamenti ed avere più tempo a disposizione per operare con le interfacce Web.
Chi non legge bene può desiderare che le informazioni siano lette ad alta voce.
Se i contenuti Web si avvalgono dei principi di progettazione descritti in questo documento, gli utenti dovrebbero essere in grado di accedere ai materiali usando strategie adattive e tecnologie assistive. Esistono molti strumenti utilizzati da utenti disabili per navigare all’interno del Web. Per scenari più approfonditi inerenti le disabilità rapportate a contenuti Web accessibili o meno, far riferimento al documento "How People with Disabilities Use the Web".
Le presenti linee guida forniscono i requisiti base per progettare contenuti Web accessibili. Scopo di questo documento non è fornire il background necessario per far apprendere come progettare un Web accessibile in maniera effettiva od esauriente. A questo proposito, si può far riferimento al documento Education and Outreach Working Group of the Web Accessibility Initiative.
Per ogni contenuto non testuale che è funzionale, come i link grafici o i bottoni, sono presenti testi alternativi che assolvono allo stesso scopo o funzione; o,
Per ogni contenuto non testuale che è utilizzato per trasmettere informazioni, sono presenti testi alternativi che trasmettono le stesse informazioni; o,
Per ogni contenuto non testuale che è mirato a creare una specifica esperienza sensoriale, come musica o arte visiva, sono presenti testi alternativi che identificano e descrivono il contenuto non testuale; o,
Sono fornite alternative multimediali conformi alla linea guida 1.2 ; o,
il contenuto non testuale che non fornisce informazioni o funzionalità è marcato in modo da essere ignorato dalle tecnologie assistive.
How to provide text alternatives for all non-text content . (Come fornire testi alternativi per tutti i contenuti non testuali) (Informativo)
Nessun success criteria di livello 2 per questa linea guida.
How to provide descriptions of all important visual information for multimedia . (Come fornire descrizioni di tutte le informazioni visive importanti inerenti i multimedia) (Informativo)
Linea Guida 1.1 (testo equivalente) Problemi
Utenti non vedenti, ipovedenti, disabili cognitivi o che hanno difficoltà per un qualsiasi motivo a leggere un testo possono usufruire del contenuto letto a voce alta dalle tecnologie assistive.
Utenti non udenti, con menomazioni dell’udito o che hanno difficoltà per un qualsiasi motivo a comprendere informazioni audio possono leggere il contenuto in forma testuale o averlo tradotto e rappresentato nel linguaggio dei segni dalle tecnologie assistive.
Utenti non vedenti-non udenti possono leggere il testo in braille.
Esempio 1: un’immagine usata come un pulsante. (breve equivalente testuale per la funzione)
Un’icona a forma di freccia rivolta verso destra è usata in una presentazione per collegare una slide alla successiva. L’equivalente testuale all’icona è “Slide successiva” e uno screen reader, leggendolo, lo identifica automaticamente come link, aggiungendo la parola link o modificando la voce del sintetizzatore.
Esempio 2: un diagramma di dati. (etichetta breve + descrizione lunga)
Un diagramma a barre confronta quanti articoli sono stati venduti in Giugno, Luglio ed Agosto. L’etichetta breve dice “ Figura 1 – Vendite in Giugno, Luglio ed Agosto”. La descrizione lunga identifica il tipo di diagramma o grafico, fornisce un sommario dei dati confrontabile con quello che risulta dal diagramma o grafico, e organizza i dati in una tabella o in un altro formato accessibile.
Esempio 3: un’animazione. (etichetta breve + descrizione lunga)
Un’animazione mostra come allacciare un nodo. L’etichetta breve dice, “Un’animazione mostra come intrecciare un nodo”. La spiegazione più lunga descrive i movimenti delle mani necessari.
Esempio 4: un file audio di un discorso. (etichetta breve + trascrizione)
In una pagina Web è inserito un file audio. L’etichetta breve dice, “Discorso di Chairman all’assemblea”. Dopo l’audio clip viene fornito immediatamente un link alla trascrizione testuale.
Esempio 5: un file audio di una sinfonia. (etichetta breve)
In una pagina Web è inserito un file audio. L’etichetta breve dice, “Quinta sinfonia di Beethoven eseguita dall’ Orchestra filarmonica di Vienna”.
Nota dell'Editore: Per rispettare la data di scadenza della nostra pubblicazione, la risoluzione dei problemi inerenti questa linea guida è rimandata alla prossima Working Draft. La questione fondamentale è "Come applicare questi success criteria ad una qualunque Webcam, notiziario e home broadcast?" Le possibilità che stiamo considerando includono di spostare i success criteria esistenti dal Livello 1 al Livello 2 o di permettere dichiarazioni di conformità che escludono sezioni del sito come "Tutte le pagine e le applicazioni presenti in questo sito sono conformi al livello 1 delle linee guida delle WCAG 2.0 eccetto la Webcam all’indirizzo http://example.org/webcam/."
un contenuto alternativo conforme alla
un link ad un contenuto alternativo conforme alla linea guida 1.1 (ad esempio, un link ad un sito meteorologico conforme alla linea guida 1.1)
Nota dell'Editore: Si discute su cosa è possibile e cosa dovrebbe essere necessario per le descrizioni audio in tempo reale, poiché non c’è modo di sapere se ci saranno intervalli di tempo tali da permettere di leggere le descrizioni e quali altri problemi potrebbero verificarsi in concomitanza con gli eventi descritti in tempo reale.
Nessun success criteria di livello 3 per questa linea guida.
Linea Guida 1.2 (media equivalenti) Problemi
Utenti non udenti o con menomazioni dell’udito possono accedere alle informazioni audio mediante i sottotitoli.
Utenti non vedenti o ipovedenti o con disabilità cognitive , che hanno difficoltà ad interpretare informazioni visive, traggono vantaggio dalle corrispondenti descrizioni audio.
Anche persone non disabili beneficiano dei media equivalenti:
Utenti in ambienti rumorosi o senza sonoro spesso fanno affidamento sui sottotitoli.
I sottotitoli aiutano molti utenti a sviluppare il linguaggio e l’abilità di lettura.
Le descrizioni audio forniscono l’informazione visiva a chi distoglie temporaneamente lo sguardo dallo schermo, ad esempio quando si stanno eseguendo le istruzioni di un video e l’attenzione è rivolta si alle mani.
Sottotitoli e descrizioni testuali rendono possibile l’indicizzazione e la ricerca dei file mediali.
Nota:
Presentazioni dipendenti dal tempo che richiedono all’utente di usare un solo senso per seguire due o più eventi contemporaneamente possono costituire per alcune categorie di persone barriere significative. A seconda della natura della presentazione, può essere possibile evitare scenari dove, ad esempio, ad un utente non udente è richiesto di osservare un’azione sullo schermo e leggere allo stesso tempo i sottotitoli. Comunque, ciò potrebbe non esser possibile per trasmissioni dal vivo (ad esempio, una partita di football). Dove possibile (specialmente per materiali educativi e di addestramento), occorre fornire i contenuti in modo da non richiedere di attivare lo stesso senso per seguire più eventi simultaneamente o dare all’utente la possibilità di congelare lo schermo, cosicché i sottotitoli possano essere letti senza perdere la schermata.
Esempio 1: un movie clip con descrizione audio e sottotitoli.
Un movie clip è pubblicato su un sito Web. Nel clip un bambino sparge delle briciole per attrarre un cucciolo nella sua stanza. Poiché il sonoro include esclusivamente il borbottio del bambino, la descrizione audio che si sente quando il bambino smette di borbottare dice “Charlie mette una briciola su ogni gradino che conduce alla sua stanza”. Il sottotitolo che appare mentre lui borbotta riporta “borbottio impercettibile”.
Esempio 2: un video clip di una notizia di attualità.
Un video clip è collegato alla notizia di un allagamento in una grande città. Il giornalista descrive la scena. Non è necessaria alcuna descrizione audio. I sottotitoli spiegano quello che il giornalista sta dicendo.
Esempio 3: un’animazione silenziosa.
Un’animazione mostra un mimo con la faccia bianca e il costume nero che sale su una scala invisibile. Non c’è traccia audio per questa animazione. Non sono richiesti sottotitoli o descrizioni audio. Viene invece fornita un’etichetta di testo e una descrizione, come richiesto dalla linea guida 1.1.
Nota dell'Editore: I concetti di "reliable" and "standard" necessitano di essere incorporati nella definizione di "programmaticamente".
Nessun success criteria di livello 3 per questa linea guida.
Linea Guida 1.3 (separazione del contenuto dalla struttura) Problemi
Separare contenuto e struttura dalla presentazione permette di veicolare i contenuti Web essere in maniera differenziata per venire incontro alle esigenze e alle difficoltà degli utenti, senza perdita d’informazione o di struttura. Ad esempio, un contenuto concepito originariamente per essere rappresentato visivamente, può esser reso col sonoro o in testo braille.
Può essere facilitata l’enfasi automatica della struttura o una navigazione più efficiente.
Di tutto ciò possono beneficiare utenti con disabilità cognitive, fisiche, uditive e visive.
Nota dell'Editore: Questi esempi sono stati migliorati rispetto alle draft precedenti, ma sono specifici per l’HTML. Saranno generalizzati nelle future draft.
Esempio 1: Un form che specifica in forma testuale quali campi non sono stati compilati.
Quando un utente compila un form senza riempire tutti i campi richiesti, appare un messaggio che lo informa dei campi ancora vuoti. Questi sono anche evidenziati con colore diverso per attrarre su di essi l’attenzione dei disabili cognitivi. Poiché il messaggio è anche disponibile in forma testuale, gli utenti che non possono distinguere i colori saranno in grado di individuare i campi da correggere.
Esempio 2: Un orario di autobus dove le intestazioni sono state associate alle celle.
L’orario di un autobus è organizzato in una tabella dove verticalmente sono indicate le fermate e orizzontalmente le diverse corse. Ogni cella contiene l’ora relativa alla fermata del bus. Nel markup ogni cella è stata associata sia alla corrispondente fermata dell’autobus, che alla relativa corsa.
Esempio 3: Un form dove ad ogni casella di controllo è stata associata la relativa etichetta.
In un form dove gli utenti possono selezionare differenti opzioni usando caselle di controllo, ad ognuna è stata associata la relativa etichetta. Ciò avvantaggia varie categorie di utenti. Permette ai non vedenti di determinare qual è la funzione della casella. I disabili motori possono controllare la casella più agevolmente in quanto possono selezionare un qualunque punto dell’etichetta invece di cliccare esattamente nella casella di controllo.
Nota:
Questo criterio dovrebbe essere soddisfatto dal testo conforme alla linea guida 1.1
Nota dell'Editore: Il Working Group sta cercando di sviluppare un algoritmo che misuri il contrasto in modo sufficientemente accurato e testabile, al fine di poterlo includere nelle linee guida. Attualmente è preso in considerazione, per l’inclusione nelle tecniche, un algoritmo presente nel documento Techniques For Accessibility Evaluation And Repair Tools, ma il gruppo non ha ancora trovato qualcosa di più specifico per l’inserimento nelle linee guida.
Linea Guida 1.4 (contrasto visivo) Problemi
Utenti ipovedenti possono facilmente leggere i caratteri di un testo perfino se non hanno un ampio campo visivo o la piena percezione del colore, cose che consentono agli utenti normodotati di distinguere il testo dalle immagini di background.
Esempio 1: una pagina con immagine di background.
Un’immagine di background e un testo sono implementati in modo tale che essa non si trovi dietro il testo o che sia appena percettibile in modo che il contrasto tra la parte più scura dell’immagine e il testo (che è scuro) incontri i requisiti standard per il contrasto tra foreground e background. Inoltre l’immagine dietro il testo non contiene linee che hanno lo stesso spessore dei caratteri, in modo da non interferire con il loro riconoscimento.
Nessun success criteria di livello 2 per questa linea guida.
Nota:
Una differenza di 20 decibel nel livello di un suono lo rende circa 4 volte più basso (o più alto). Il background sonoro che ha questi requisiti risulterà approssimativamente quattro volte (4x) più basso del contenuto audio di foreground.
Linea Guida 1.5 (contrasto audio) Problemi
Utenti con menomazioni uditive, che limitano la loro capacità di percepire le frequenze sonore, possono estrapolare le parole dai suoni perché non mixate col sottofondo musicale.
Esempio 1: parlato su background sonoro.
Il parlato è spesso naturalmente mixato con suoni di background (movie, notizie dal vivo ecc.) e non può essere facilmente rimosso o separato, perciò (secondo le indicazioni della linea guida 1.2) sono forniti sottotitoli al fine di rendere il dialogo comprensibile. Non tutte le persone, però, sono in grado di leggerli o vederli. Se il parlato è mixato o registrato con suoni di background, ma ha un’intensità superiore ad essi di almeno 20 decibel, per molti utenti non sono più necessari i sottotitoli per comprendere il dialogo.
Nota:
Sono incluse caratteristiche di accessibilità fornite dagli autori.
Nota:
Possono essere fornite interfacce aggiuntive alla tastiera, come ad esempio il mouse.
Nota:
Far riferimento alla linea guida 4.2 per informazioni inerenti il supporto degli user agent.
Tutte le funzionalità del contenuto sono fruibili tramite tastiera o interfaccia di tastiera.
Linea Guida 2.1 (operazioni da tastiera) Problemi
I non vedenti (che non possono usare dispositivi di puntamento) possono accedere alle funzionalità del contenuto Web o del sito.
Coloro che hanno serie disabilità fisiche possono utilizzare input vocali (che simulano i tasti) sia per immettere i dati che per operare con gli elementi dell’ interfaccia della pagina.
Esempio 1: operare con più dispositivi di input.
Il contenuto fa affidamento soltanto su focus-in, focus-out e eventi di attivazione; questi sono definiti nelle API dell’ambiente per il quale il contenuto è stato realizzato e sono fruibili mediante più dispositivi di input, inclusi dispositivi di puntamento, tastiere e sistemi di input vocale.
Esempio 2: esempi di contenuto Web fruibile o meno da tastiera o interfaccia di tastiera.
Se è scritto per essere fruibile da tastiera, allora è conforme (in quanto è fruibile da tastiera).
Se è scritto per essere per essere utilizzato da un dispositivo che solitamente non è provvisto di tastiera, come un telefono cellulare, ma può essere controllato mediante una tastiera aggiuntiva, allora è conforme. (Un utente che necessita di tastiera – o di tastiera alternativa – può utilizzarla per controllare l’ applicazione).
Se è scritto per essere fruibile da un dispositivo che non ha tastiera, ma potrebbe anche essere utilizzabile mediante tastiera da dispositivi simili che ne sono provvisti, allora è conforme. (Un utente che necessita di tastiera non comprerebbe un dispositivo che ne è privo, che potrebbe essere considerato non accessibile. Ma il contenuto può essere controllato da un dispositivo con tastiera e quindi è conforme a questa linea guida).
Se è scritto per essere fruibile da dispositivi sprovvisti di tastiera ma non può essere utilizzato da quelli con tastiera, allora non è conforme (non si può accedere al contenuto tramite tastiera).
L’utente può disattivare il tempo o;
L’utente può regolare il tempo entro un ampio intervallo, almeno 10 volte più lungo rispetto alle impostazioni di default o;
L’utente è avvertito che il tempo a disposizione sta per terminare, può prolungarlo con una semplice azione (ad esempio premendo un qualunque tasto) e gli vengono forniti almeno 10 secondi per rispondere o;
Il tempo è una componente importante di un evento real-time (ad esempio una vendita all’incanto) e non ci sono alternative possibili al limite temporale o;
Il tempo è parte di un’attività in cui la temporizzazione è essenziale (ad esempio gare o test da risolvere entro un certo limite di tempo) e quindi non può essere ulteriormente prolungato per non invalidare l’attività.
Nota dell'Editore: Con questa affermazione, non sarebbero permessi eventi in tempo reale. Vogliamo accettarli?
Linea Guida 2.2 (limiti di tempo) Problemi
Utenti dislessici, con disabilità cognitive e di apprendimento hanno spesso bisogno di più tempo per leggere e comprendere un testo scritto.
Utenti con disabilità fisiche possono esaminare e leggere i materiali frequentemente aggiornati prima che avvenga il refresh o nel caso in cui i contenuti siano letti con una tecnologia assistiva o un browser vocale guasti.
Esempi di contenuti che devono soddisfare i success criteria di questo checkpoint:
refresh automatico,
reindirizzamento,
testo che lampeggia o in scorrimento,
dialogo che scompare dopo un breve periodo,
chiusura o disattivazione di risorse se l’attività non è espletata entro un certo tempo.
Esempio 1: testo che lampeggia.
Lo scripting dal lato client è utilizzato per creare testo che lampeggia. Il contenuto fornisce all’utente un’opzione che gli consente di disattivare l’intermittenza.
Esempio 2: un sito di news che si aggiorna regolarmente.
La prima pagina di un sito di news viene aggiornata ogni mezz’ora. Contiene testi molto stringati e consiste principalmente di link al contenuto. Un utente che non desidera l’aggiornamento della pagina seleziona una casella di controllo, che si trova nella sezione del sito relativa alle “user preferences” e che costituisce uno dei primi link di ogni pagina.
Linea Guida 2.3 (sfarfallio) Problemi
La luminanza di un video non è una misura diretta della luminosità dello schermo. Non tutti i dispositivi schermo presentano le stesse caratteristiche di gamma, ma si può scegliere un display con una gamma di 2.2 allo scopo di determinare misure elettriche per controllare la conformità alle linee guida.
Allo scopo di determinare misure elettriche per controllare la conformità alle linee guida, si assume che le immagini siano visualizzate in accordo con 'home viewing environment' descritto nella Recommendation ITU-R BT.500 in cui il massimo di bianco corrisponde ad un’illuminazione dello schermo di 200 cd.m-2.
Le soglie si basano sul documento ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television (Riveduto e ripubblicato nel luglio 2001) come modificato dal Wisconsin Computer Equivalence Algorithm.
Nota dell'Editore: Nel secondo trimestre del 2004, verrà reso disponibile dall’University of Wisconsin's Trace Center un free tool in grado di analizzare il contenuto Web.
Nota dell'Editore: Cos’è una pagina percepita? E se si tratta di un’ applicazione VoiceXML? Come utilizzarla nelle applicazioni Web? Perché 50 e 50.000?
struttura gerarchica,
tabella dei contenuti (per le pagine) o mappa del sito (per i siti),
ordine alternativo di visualizzazione (per le pagine) o meccanismi di navigazione di un sito alternativi (per i siti).
Nota dell'Editore: "L’ordine logico di tabulazione " può non essere testabile.
Nota dell'Editore : Abbiamo avuto bisogno di specificare "a cui si può accedere separatamente" per chiarire che ciò che viene fornito di titolo è un pezzo di contenuto nel suo complesso contro elementi individuali o porzioni di contenuto.
Frammentare il testo in paragrafi logici,
Suddividere i documenti, in particolare di quelli molto lunghi, in sezioni gerarchiche e sottosezioni con titoli chiari e significativi,
Evidenziare le relazioni non gerarchiche, come i riferimenti incrociati, in modo che le relazioni siano rappresentate in maniera non ambigua nel markup o nel data model.
Nota dell'Editore: Ne esistono altre?
Linea Guida 2.4 (meccanismi di navigazione) Problemi
Se nel markup o nel data model è fornita la struttura logica,
Utenti con disabilità fisiche possono usare la struttura per muoversi più agevolmente fra paragrafi, capitoli, sezioni ecc.
Utenti con disabilità cognitive possono usare la struttura (titoli dei capitoli, intestazioni, ecc.) per contestualizzare meglio il testo di loro interesse. Fra l’altro gli elementi strutturali richiamano l’attenzione sui cambiamenti di contesto ed orientano l’utente verso il nuovo focus.
Utenti non vedenti o ipovedenti possono passare da intestazione ad intestazione per avere una panoramica degli argomenti o per "saltare" più rapidamente alla sezione d’interesse.
Lettori ipovedenti possono talvolta (a seconda della tecnologia video) modificare la visualizzazione dei titoli dei capitoli e delle intestazioni per renderli più visibili e più facili da usare quando navigano nel documento.
Il contenuto può essere visualizzato tramite molteplici dispositivi il cui software non solo è in grado di scegliere quali elementi visualizzare, ma di farlo anche nel modo più efficace.
Fornire differenti meccanismi di navigazione può aiutare utenti con diverse abilità, background culturale, orientamento visuale verso il testo, e tipo di informazioni che essi stanno ricercando in quel momento.
Per utenti con disabilità cognitive può risultare più facile cercare quello che desiderano piuttosto che dedurne la posizione da scelte categoriche.
Utenti ipovedenti o non vedenti possono reputare più efficaci tecniche di ricerca che prelevano i dati inerenti l’argomento d’interesse, rispetto a tecniche che richiedono loro di esaminare liste o elenchi di contenuti.
Una presentazione che enfatizza la struttura:
Mette in grado gli utenti con disabilità cognitive e visive di orientarsi all’interno dei contenuti,
Mette in grado tutti gli utenti di spostarsi più velocemente fra i contenuti e di rilevarne le ripartizioni più importanti,
Mette in grado tutti gli utenti, ma particolarmente gli utenti con disabilità cognitive e visive a focalizzare contenuti chiave,
Mette in grado tutti gli utenti, ma particolarmente gli utenti con disabilità cognitive e visive di distinguere i vari tipi di contenuto.
Esempio 1: documentazione per un prodotto.
E’ consuetudine identificare i capitoli ed etichettare la struttura di un libro. Nei capitoli, i titoli (etichette) identificano i cambiamenti di contesto e i concetti chiave contenuti nel testo. Le sottili differenze fra l’aspetto del titolo di un capitolo e delle intestazioni dei paragrafi aiutano l’utente a comprendere la gerarchia e le relazioni fra titoli ed intestazioni. Nel caso di informazioni visive, la differenza potrebbe consistere nella dimensione del carattere e nei margini di indentazione; nel caso di informazioni uditive in una voce diversa o in un suono da anteporre.
Esempio 2: un’immagine scalabile di una bicicletta.
Linee e una circonferenza (raggi e cerchio) sono raggruppati in una “ruota”. Linee in un triangolo che si fissa ad ogni ruota sono raggruppati in un “telaio”.
Esempio 3: interfaccia utente.
I controlli dell’interfaccia utente sono suddivisi in gruppi organizzati.
Esempio 4: una tabella di dati.
I gruppi di righe o colonne sono etichettati con le intestazioni.
Esempio 5: una presentazione audio.
La versione audio di un documento, generata secondo un foglio di stile, utilizza una voce diversa, più formale, per leggere i titoli e le intestazioni in modo che l’ascoltatore possa identificare facilmente le parole componenti i titoli e distinguerle dal restante testo.
E’ rilevato un errore dell’utente. L’errore è identificato e segnalato sotto forma di testo.
E’ rilevato un errore dell’utente e sono noti i suggerimenti per la correzione da poter fornire senza compromettere la sicurezza o gli obiettivi (ad esempio, validità di un test). Tali suggerimenti sono resi disponibili (in forma accessibile come richiesto dai success criteria - Livello 1).
Se sono importanti le conseguenze ma non il tempo di risposta, si verifica una delle seguenti possibilità:
Le azioni sono reversibili.
Se le azioni sono non reversibili, viene eseguito il controllo degli errori prima di procedere al passo successivo.
Se le azioni sono non reversibili e non controllabili, l’utente è messo in grado di riesaminare e confermare o correggere l’informazione prima che venga trasmessa.
Se sono note le opzioni di input, sono meno di 75 e possono essere fornite senza compromettere la sicurezza, la validità di un test, ecc., l’utente può selezionarle da una lista di opzioni così come accedere direttamente al testo.
Esiste il controllo ortografico e vengono suggeriti i termini corretti quando è richiesta l’immissione testo.
Linea Guida 2.5 (minimizzare l'errore) Problemi
Identificare gli errori di battitura aiuta gli utenti disgrafici e dislessici che spesso incontrano difficoltà nell’inserire il testo nei form o dove è richiesto un input testuale.
Alcune disabilità rendono difficoltoso operare con i dispositivi di input, incrementando la possibilità di errore. Per esempio, gli utenti con limitate funzioni motorie hanno più probabilità di commettere errori se utilizzano il mouse o la tastiera. I sistemi di riconoscimento vocale possono aver difficoltà nel riconoscere le parole di chi ha disabilità del linguaggio. Le caratteristiche che aiutano ad individuare e correggere gli errori vanno a vantaggio di questi tipi di disabili.
Esempio 1: un motore di ricerca
Un motore di ricerca è provvisto di una varietà di opzioni di ricerca relative a differenti livelli di abilità e diverse preferenze. Include una ricerca vocale e offre alternative di “best guess”, ricerche basate su query-by-example e ricerche analoghe.
Nota:
Quanto detto sopra non si applica ai termini stranieri presenti nel testo, diventati ormai di uso comune.
Nota dell'editore: Stiamo tuttora esaminando metodi per rendere testabili alcuni o tutti i success criteria succitati (tali metodi potrebbero essi stessi diventare dei success criteria).
In generale
Organizzare il materiale in modo che sia semplice da leggere ed usare.
Usare un manuale di stile, dizionario, e gli altri materiali di riferimento.
Testare i documenti con potenziali utenti per verificare la comprensibilità del materiale, includendo nel test group soggetti con disabilità cognitive, di apprendimento e di lettura.
Sviluppare un solo argomento o sotto argomento per paragrafo.
Lessico
Usare un lessico che sia familiare ai potenziali lettori.
Se la risorsa è diretta a chi lavora in un particolare campo tecnico, usare un linguaggio controllato. Per esempio, una risorsa progettata per ingegneri aeronautici potrebbe servirsi di un linguaggio controllato come quello utilizzato dalla Boeing Aircraft Company.
Se una risorsa tecnica è designata ad essere tradotta in altre lingue, usare un linguaggio controllato
Evitare gergo professionale, dialetto, e altri termini con significato specialistico che può essere sconosciuto a persone non del ramo, se il materiale è diretto ad una vasta platea o è destinato alla traduzione in altre lingue. Può essere anche utile rivedere il materiale per semplificarne il linguaggio, usando una checklist come quella prodotta dagli Stati Uniti e da agenzie governative canadesi.
Nota dell'editore: Bisogna aggiungere esempi relativi ad altri paesi ed altre lingue.
Formulare frasi di lunghezza e complessità conformi a quanto raccomandato nelle best practices relative al pubblico a cui ci si rivolge. Ciò è quanto avviene nei correnti libri di testo che trattano argomenti della disciplina o del campo d’interesse dei lettori.
Frasi
Rendere la lunghezza della frase coerente con le comuni pratiche del linguaggio del documento o dello specifico pubblico a cui il documento è diretto. Possono essere utili i libri di testo che trattano della disciplina o del campo d’interesse dei lettori, se disponibili.
Sintassi
Usare per le frasi la sintassi più semplice, adatta allo scopo del contenuto.
Per esempio, la sintassi più semplice per una frase inglese è soggetto-verbo-complemento: John hit the ball o Il sito Web è conforme alle WCAG 2.0.
Usare elenchi numerati o puntati al posto di paragrafi che contengono una lunga serie di parole o frasi separate da punteggiatura.
Nomi, locuzioni nominali, e pronomi
Usare nomi singoli o brevi locuzioni nominali.
Rendere chiaro a chi o cosa rimanda un certo pronome e collocarlo il più vicino possibile al termine a cui fa riferimento nel documento.
Esempio di potenziale ambiguità.La frase sottostante contiene vari pronomi e non è chiaro a chi o a cosa essi si riferiscano:
Web developers can't understand those guidelines because they don't speak their language.
Non è chiaro a quali linee guida si fa riferimento con “those guidelines” (le linee guida che stai leggendo ora, sono these guidelines).
Non è chiaro se il pronome “they” è riferito ai Web developers o alle guidelines (la sintassi inglese afferma che dovrebbe riferirsi alle guidelines ma questa regola non sempre è rispettata nell’uso comune).
Non è chiaro se il pronome Non è chiaro se il pronome “their” è riferito al linguaggio utilizzato dai Web developers o al linguaggio in cui sono scritte le guidelines.
Per evitare ambiguità, la frase può essere riscritta nel seguente modo:
Web developers can't understand these guidelines because the guidelines are not written in the developers' language.
Verbi
Voci verbali
Usare la voce attiva per documenti scritti in inglese e nelle altre lingue occidentali, a meno che non ci sia una specifica ragione per usare la costruzione passiva. Infatti le frasi attive sono spesso più corte e più facili da capire di quelle in forma passiva.
Attivo: Many people believe that readers understand sentences in the active voice more easily than sentences in the passive voice.
Passivo: It is believed by many that sentences in the active voice are more easily understood by readers than sentences in the passive voice.
Tempi
Usare i tempi verbali in modo coerente.
Ad esempio, non cambiare a caso tra presente e passato. Nella frase, John left the room. He takes the elevator down to the lobby, il passaggio dal tempo passato (nella prima frase left the room) al tempo presente nella seconda frase (takes the elevator) potrebbe creare ambiguità circa l’uso dell’ascensore da parte di John: l’ha usato nel passato o lo sta usando adesso?
Logica e relazioni
Indicare le relazioni logiche tra frasi, proposizioni, paragrafi o sezioni del testo.
In alcuni casi, semplici parole come “e”, “comunque”, “inoltre”, “perciò” possono essere sufficienti per chiarire la relazione logica tra una proposizione e la successiva. In altri casi può essere utile ricorrere a frasi più lunghe o proposizioni aggiuntive che siano maggiormente esplicative del contenuto.
Istruzioni e contenuti fruibili
Spiegare in modo esauriente istruzioni o azioni richieste.
Usare in maniera coerente nomi ed etichette.
Esser chiari nei punti in cui il documento:
spiega le scelte e le opzioni,
etichetta le opzioni per ottenere ulteriori informazioni,
istruisce gli utenti su come modificare selezioni in funzioni critiche (ad esempio, come cancellare un articolo da un carrello di acquisto).
Utilizzare una struttura obiettivo-azione per il prompt di menu.
Utilizzare le impostazioni di default (e renderne facile il ripristino)
Utilizzare two-step, “seleziona e conferma” per ridurre selezioni accidentali per funzioni critiche.
Fornire assistenza di calcolo (per esempio, usare uno script per calcolare il prezzo totale per un acquisto on-line).
Rappresentazioni alternative: sommari, parafrasi, esempi, illustrazioni, e linguaggi simbolici
Fornire sommari per aiutare la comprensione.
Aggiungere contenuto non-testuale al sito per pagine o sezioni chiave in modo da renderlo più comprensibile agli utenti che non possono capire la sola versione testuale.
Nota dell'editore: Le WCAG 1.0 e la Section 508 permettono varianti di solo testo unicamente nei casi in cui "l’originale" non possa esser reso accessibile in alcun modo, e richiedono che la versione solo-testo sia aggiornata ogni volta che si modifica l’originale. Tale richiesta non è presente nelle WCAG 2.0, ma riteniamo necessario reinserirla.
Usare design, grafica, colori, font, animazioni, video o audio per chiarire testi complessi.
Includere contenuto non-testuale in aggiunta a quello testuale nelle pagine o nelle sezioni chiave del sito.
Linea Guida 3.1 (significato) Problemi
Spesso in un documento sono utilizzate frasi di lingua diversa dal resto del documento. Se queste sono opportunamente identificate, un sintetizzatore vocale può leggerle con accento e pronuncia appropriati; in caso contrario esso legge la frase in modo incomprensibile poiché continua ad utilizzare la lingua base del documento. Identificare i cambiamenti di lingua permette inoltre di chiedere traduzioni automatiche del contenuto. Nell’editare il testo, gli authoring tools possono scegliere fra dizionari appropriati.
Fornire la spiegazione delle abbreviazioni e degli acronimi non solo aiuta gli utenti che hanno poca familiarità con essi, ma chiarisce quale sia il significato più appropriato da usare. Ad esempio, l'acronimo "ADA" sta sia per “American with Disabilities Act” che per “American Dental Association”.
Definire termini chiave e linguaggio specifico aiuta le persone che non hanno familiarità con quell’argomento.
La decodifica non ambigua di caratteri e parole di un contenuto è inoltre utile per coloro che stanno imparando a leggere o stanno studiando una seconda lingua.
Tutti gli utenti, specialmente quelli con deficit cognitivo, di apprendimento o difficoltà di lettura si avvantaggiano dell’utilizzo di un linguaggio chiaro e semplice. Ciò non dovrebbe però scoraggiare dall’esprimere idee complesse o concetti tecnici.
Usare un linguaggio chiaro e semplice aiuta chi non padroneggia la lingua, inclusi coloro che comunicano soprattutto col linguaggio dei segni.
Suoni, grafica, video e animazioni possono aiutare a presentare meglio i concetti, specialmente a persone con deficit cognitivo, di lettura, di apprendimento e a chi ha poca familiarità con la lingua del sito.
Riassumere le informazioni difficili da comprendere aiuta le persone con difficoltà di lettura.
Fornire sommari degli schemi visivi che mostrano relazioni e collegamenti fra informazioni complesse aiuta le persone che non utilizzano schemi visivi o che hanno difficoltà ad interpretarli. Ad esempio, i non vedenti non possono servirsi di alcuno schema visivo, mentre i dislessici o gli ipovedenti potrebbero avere difficoltà nell’interpretarli.
Nota:
I designer devono essere cauti nell’utilizzo delle illustrazioni. Leggere una figura è probabilmente un modo di apprendere più facile per alcuni che per altri. Alcuni utenti ignorano le figure, mentre altri leggono solo quelle. I designer devono inoltre tener presente che le convenzioni visive non sono universali e che ognuno sviluppa propri schemi mentali e aspettative nell'interpretare le informazioni visive.
Esempio 1: un acronimo nel titolo di una pagina.
Nel titolo seguente, "People of the W3C" il markup è stato fatto in modo appropriato, così gli user agent saranno in grado di leggere le lettere dell’acronimo una alla volta, piuttosto che tentare di pronunciarlo come se fosse un’unica parola.
Esempio 2: una frase in lingua francese in un periodo in lingua inglese.
Nel seguente periodo, “And with a certain je ne sais quoi, she entered both the room, and his life, forever", la frase "je ne sais quoi" è identificata come lingua francese. A seconda del linguaggio di markup, l’inglese può essere marcato come la lingua usata per l’intero documento, eccetto dove specificato o marcato a livello di paragrafo.
Esempio 3: una descrizione di un processo.
Una pagina descrive come imparare a giocare a calcio. Ciascun passo nell’apprendimento delle regole del gioco è illustrato con la foto di un giocatore mentre esegue ciò che viene descritto nel testo.
Esempio 4: un concetto concreto.
Il concetto principale espresso in una pagina è un concetto concreto. Si sta trattando del Vulcano Pinatubo. Viene descritta l’eruzione del 1991, sono inserite le relative foto, e si discute delle conseguenze. Si effettua un collegamento ad un sito che contiene un video e ad un altro sito che presenta una simulazione in 3D di cosa accade sotto la crosta terrestre e all’interno del vulcano durante l’eruzione.
Esempio 5: relazione di una bambina su una gita scolastica.
Una bambina è andata in visita scolastica presso una fabbrica che costruisce biciclette. Scrive una relazione da inserire nel Web per la sua famiglia e per gli amici. In essa, include il logo della compagnia e l’immagine di una bicicletta sulla catena di montaggio. Effettua il collegamento al sito Web della compagnia per ulteriori informazioni e inserisce le foto della fabbrica.
Esempio 6: dati sull’andamento della borsa.
Un sito di news confronta l’andamento dell’economia nel terzo trimestre di questo anno con il terzo trimestre degli ultimi tre anni. Si confrontano i prezzi delle azioni più comuni. I dati vengono rappresentati in un grafico a barre collegato ai dati grezzi utilizzati per la creazione del diagramma.
Esempio 7: storia della musica.
Un nonno ha l’hobby di ascoltare e suonare musica, tanto che ha creato un sito Web che contiene esempi di vari tipi di musica e di strumenti musicali. Quando descrive specifici tipi di musica, effettua un collegamento ad un breve clip sonoro.
Nota dell'editore: Stiamo cercando un termine per rimpiazzare la parola “pagina” che sia valido per le tecnologie. Per applicazioni visive, si potrebbe utilizzare "schermata", ma tale termine non sarebbe fruibile per tecnologie sonore, come VoiceXML.
Nota dell'editore: Questo criterio è specifico per l’HTML.
Nota dell'editore: C'è qualche discussione circa la specificità di questo criterio. C'è anche una questione riguardo la sua inclusione a livello 2 o a livello 3.
Nota dell'editore: Ci si preoccupa del fatto che questi success criteria siano troppo specifici per l’HTML.
Linea Guida 3.2 (condotta coerente) Problemi
Fornire risposte coerenti e prevedibili alle azioni dell’utente costituisce per questi un importante feedback. Consente loro di capire che il sito funziona in maniera appropriata e ne incoraggia le interazioni con i contenuti. Risposte inaspettate potrebbero scoraggiare gli utenti nell’utilizzo del sito o far ritenere che ci siano problemi di funzionamento. Alcuni potrebbero confondersi tanto da non ritenersi in grado di navigare il sito.
Gli utenti che non sono capaci d’individuare cambiamenti imprevisti nel contesto o che non possono realizzare che il contesto è cambiato saranno probabilmente meno disorientati nel corso della navigazione. Ci si riferisce alle seguenti situazioni:
Non vedenti o ipovedenti che possono avere difficoltà ad individuare cambiamenti nel contesto visivo, come l’apertura automatica di una finestra di pop up. In tal caso, avvertire l’utente che il contesto sta cambiando, minimizza la confusione quando egli scopre che il pulsante per tornare alla pagina precedente non funziona più al solito modo.
Nelle presentazioni solo audio, gli utenti sordi o con deficit dell’udito o quelli che non sono in grado di individuare cambiamenti dello speaker: è opportuno, quindi, evidenziarli mediante sottotitoli.
Gli ipovedenti, i dislessici o coloro che hanno difficoltà ad interpretare schemi visivi possono beneficiare di indicazioni supplementari per rilevare cambiamenti imprevisti del contesto.
Esempio 1: un form per disattivare finestre di pop-up.
In una pagina di link viene fornita una casella di controllo per permettere agli utenti di scegliere se far apparire le pagine attivate nella stessa finestra o meno.
Esempio 2: un avvertimento fornito prima dell’apertura di una finestra di pop-up.
Al termine di una notizia di attualità, vengono forniti parecchi link per ottenere ulteriori informazioni. All’inizio di ogni link viene posta un'icona a forma di freccia, con testo equivalente "Il collegamento attiverà una nuova finestra ".
Esempio 3: frame che non permettono di tracciare lo sviluppo della storia perché il pulsante per tornare alla pagina precedente si comporta in maniera inaspettata.
Esempio 4: form.
Nota dell'editore: E’ necessario completare questi esempi o sostituirli con altri migliori.
superato i test di validazione per la versione in uso (se essa è conforme o meno ad uno schema, Document Type Definition - DTD), o soddisfa altri test descritti nelle specifiche),
gli elementi strutturali e gli attributi sono utilizzati come suggerito nelle specifiche.
Nessun success criteria di livello 2 per questa linea guida.
Linea Guida 4.1 (uso specifiche) Problemi
Questa linea guida enfatizza il fatto che le future specifiche accrescono la probabilità di contenuto accessibile. Mentre altre linee guida fanno riferimento a parti specifiche del contenuto, la 4.1 fa un passo indietro per guardare al quadro generale; è stata predisposta per permettere di risolvere i problemi che potranno crearsi con le futute tecnologie e quelli che al momento della stesura di queste linee guida non si possono prevedere. Così, i vantaggi delle future specifiche consistono principalmente nel fatto che le tecnologie assistive e gli user agent possono rappresentare il contenuto in modo conforme.
Conformarsi alle future specifiche per markup e altri formati di file rende più semplice riformattare, riproporre e riutilizzare il contenuto, cosa importante per gli utenti che possono utilizzarlo a pieno solo se è presentato in un particolare formato.
Esempio 1: elementi strutturali.
In un sito Web a carattere storico, gli elementi strutturali sono usati in maniera appropriata per indicare la presenza di citazioni, definizioni e riferimenti bibliografici. Poiché questi elementi sono stati utilizzati secondo le specifiche, gli user agent possono essere configurati in maniera tale che gli elementi siano differenziati dal resto del contesto, permettendo all’utente di ottimizzare l’uso del sito per scopi di ricerca.
Esempio 2: elementi di presentazione.
Un autore di pagine Web desidera attirare l’attenzione su determinate parole, per ragioni puramente estetiche. Usa elementi progettati per applicare caratteristiche di stile e di presentazione, piuttosto che elementi progettati per trasmettere informazioni circa la struttura o l’organizzazione della pagina, per esaltare la presentazione visiva ed evita elementi poco comprensibili a utenti che non usano l’informazione visuale o che fanno riferimento solo al testo.
Esempio 3: API accessibili.
Un’applet Java utilizza l’accessibilità API definita dal linguaggio. Far riferimento a IBM Guidelines for Writing Accessible Applications Using 100% Pure Java.
Requisiti (a) through (j)
Le applicazioni che presentano testo sotto forma di immagine dovrebbero conformarsi a VisualText checkpoints.
Le applicazioni che presentano immagini dovrebbero conformarsi a Image checkpoints.
Le applicazioni che presentano animazioni dovrebbero conformarsi a Animation checkpoints.
Le applicazioni che utilizzano audio dovrebbero conformarsi a Video checkpoints.
Le applicazioni che utilizzano audio dovrebbero conformarsi a Audio checkpoints.
Le applicazioni che eseguono un proprio event handling dovrebbero conformarsi a Events checkpoints.
Le applicazioni che implementano meccanismi di selezione dovrebbero conformarsi a Selection checkpoints.
Le applicazioni dovrebbero supportare l’accesso tramite tastiera per i checkpoint 1.1 e 6.7 delle UAAG 1.0.
Le applicazioni che implementano input vocali o di puntamento dovrebbero conformarsi a Input Modality checkpoints.
Nota:
Quando scegli la tecnologia occorrente, considera che l’hardware e il software assistivi si adattano con ritardo ai progressi tecnologici e che la disponibilità di tecnologie assistive varia a seconda dei linguaggi naturali. Verifica che la tecnologia assistiva compatibile con le tecnologie che hai scelto sia disponibile nel linguaggio naturale del tuo contenuto.
Linea Guida 4.2 (accesso ai supporti tecnologici) Problemi
Gli autori che assicurano l’accessibilità delle interfacce utente in tutto il loro contenuto:
andranno incontro a minori difficoltà implementando queste linee guida, encounter fewer challenges when implementing these guidelines,
non avranno bisogno di creare soluzioni personalizzate e di procedere per approssimazioni successive per fronteggiare i problemi di accessibilità,
non avranno bisogno di fornire versioni alternative del contenuto presentato mediante una tecnologia che non si adegua totalmente a queste linee guida.
Vantaggi nel determinare e documentare i requisiti delle tecnologie:
Gli utenti possono capire (attraverso la documentazione del sito o automaticamente attraverso i metadata) se sono o non sono in grado di utilizzare il sito. In combinazione con un motore di ricerca o un server proxy, ciò potrebbe servire a filtrare ed escludere i siti a cui l’utente non può accedere oppure servire a filtrare i migliori siti usabili.
Documentare i requisiti tecnologici costringerà gli autori a valutare le assunzioni degli user agent e minimizzerà il numero di siti loro malgrado inaccessibili perché non sono consapevoli dei problemi di compatibilità sottostanti.
Vantaggi nell’assicurare l’accessibilità dell’interfaccia utente e nel fornire alternative accessibili:
Utenti che devono usare browser e dispositivi alternativi saranno in grado di accedere al contenuto.
Gli utenti che non possono permettersi o non possono avere accesso alle più recenti tecnologie traggono vantaggio dalla compatibilità con le versioni precedenti poiché non avranno bisogno di acquistare spesso aggiornamenti o attrezzature.
Esempio 1: un magazzino online che elenca le tecnologie richieste
Documentando i requisiti minimi dell'user agent, lo store rende possibile l’uso di particolari tecnologie per verificare se gli utenti potranno trovarsi in difficoltà utilizzando il magazzino o il suo meccanismo di checkout, prima che comincino ad acquistare. Ciò impedisce che dopo la selezione dei prodotti e l'inizio del processo di checkout, l'utente scopra di non essere in grado di completare la transazione. Si possono comunque scegliere alternative per riuscire nell’intento.
Esempio 2: un sito intranet che si trasforma in modo gradevole
Una grande compagnia si interessa di indirizzare gli utenti alle varie diverse office locations che hanno differenti basi tecnologiche. Per risolvere il problema, essa ha creato due versioni dei propri contenuti e documentato i requisiti per ciascuno, rendendo facile per gli utenti determinare con quale versione lavorare al meglio, nel rispetto delle loro tecnologie.
Esempio 3: un sito di informazione che assicura la compatibilità con le versioni precedenti.
Un sito di informazione tratta di una gran varietà di argomenti e vuole mettere in grado i propri visitatori di reperire velocemente gli argomenti oggetto della ricerca. A questo scopo, è stato implementato nel sito un sistema di menù interattivo supportato dalla più recente versione di due diffusi user agent. Per assicurare ai visitatori sprovvisti di questi user agent di utilizzare in maniera efficiente il sito, viene fornito un meccanismo di navigazione che non dipende dal sistema di menù interattivo e che non supporta le tecnologie più recenti.
Nota dell'editore: Il WCAG WG non ha ancora affrontato le definizioni dei termini, utilizzati a volte in modo non coerente. È necessario coordinare i termini e le definizioni col Glossario del WAI e lavorare sulle proposte per organizzare le definizioni. L’attenzione è rivolta al glossario dell'UAAG 1.0 e agli altri glossari del W3C.
Un'attività in cui la temporizzazione è essenziale è stata progettata in modo che il tempo rivesta in essa un’importanza fondamentale. La rimozione del fattore tempo può modificare la performance dei partecipanti. Potrebbero essere preferite e necessarie in alcune circostanze attività (es. test) non basate sul tempo o con limiti di tempo. Questo comporterebbe riprogettare l’attività (es. test) e potrebbe modificarne il carattere e i metodi di validazione e non rientrerebbe quindi nel campo di azione di queste linee guida.
Rappresentazioni grafiche create per mezzo di una sistemazione spaziale di caratteri di testo. Sebbene si possa visualizzare in forma testuale, non si tratta di testo.
Una descrizione audio è una descrizione verbale di significative informazioni visive relative a scene, azioni, eventi che non possono essere percepiti soltanto dalla traccia sonora. L’estensione è resa possibile dai vincoli esistenti sulla traccia audio e dalle limitazioni relative al congelamento del programma audiovisivo, per l’inserimento di descrizioni audio supplementari.
Nota:
Quando viene aggiunta una descrizione audio a materiali esistenti, tutte le informazioni veicolate attraverso tale descrizione sono vincolate dallo spazio disponibile nell’esistente traccia audio, a meno che il suo inserimento sia consentito dalla possibilità di congelare periodicamente il programma audiovisivo. Comunque è spesso impossibile o inappropriato effettuare tale congelamento per inserire descrizioni audio supplementari.
Insieme di materiali creati da un autore come singola entità. Ad esempio, una raccolta di markup, un foglio di stile, una risorsa mediale, come un'immagine o una clip audio.
Nota:
Questo termine è stato preso letteralmente dal Glossary of Terms for Device Independence .
I sottotitoli sono equivalenti testuali di informazioni uditive relative al parlato, a effetti sonori, a suoni di ambiente, sincronizzati con la presentazione multimediale.
Il contenuto è considerato complesso quando non è facile dedurre le relazioni esistenti tra le varie informazioni. Se la presentazione delle informazioni mira ad evidenziare trend o relazioni tra i concetti, questi dovrebbero essere esplicitati nel sommario.
Esempi d'informazioni complesse:
tabelle di dati,
concetti esoterici o difficili da capire,
contenuto sviluppato su più livelli.
Contenuto
Nota dell'editore : È necessario includere in questo punto una definizione di contenuto.
Il contenuto che lampeggia è un contenuto che si accende e si spegne da 0.5 a 4 volte al secondo.
I Linguaggi controllati usano un vocabolario ristretto che costituisce un sottoinsieme del linguaggio naturale. Lo scopo è di rendere i testi più semplici da capire e da tradurre. Gli standard in genere attribuiscono alle parole un solo significato e prestabilita parte del discorso. È evitata la sintassi complessa. Informazioni sulle applicazioni di linguaggio controllato sono disponibili sul Web.
Sezione di codice che corrisponde ad un'azione effettuata dall'utente (o dallo user agent). Sulle pagine Web, gli eventi di solito sono azioni eseguite dall’utente come il movimento del mouse, la pressione di un tasto, ecc. Un event handler determina la risposta a quell'azione. Un event handler specifico per una tecnologia risponde solo ad un'azione effettuata tramite un certo dispositivo di input. Un abstract event handler corrisponde ad un’azione che può essere attivata da più dispositivi di input.
Nota dell'editore: : È necessario includere in questo punto una definizione di associazione esplicita.
Un cambiamento imprevisto nel contesto include:
apertura inaspettata di una nuova finestra del browser e senza alcuna indicazione non visiva (il pulsante per tornare alla pagina precedente improvvisamente non funziona)
in una presentazione uditiva, lo speaker cambia senza che venga dato un avvertimento visivo o un’indicazione nei sottotitoli
sottotitoli che non segnalano il cambiamento dello speaker
Azioni tipiche dell’utente sono:
movimenti del mouse
attivazione di un tasto
selezione di un link
uso di un pulsante di navigazione del browser (es. pulsanti per tornare indietro o andare avanti)
apertura di nuove finestre del browser
Risposte tipiche alle azioni dell’utente sono:
caricamenti di nuove pagine
visibilità o meno del contenuto a seconda della posizione del mouse o del focus della tastiera
visualizzazione dei contenuti di un menù (in modo uditivo o visivo)
visualizzazione di menù o finestre di pop-up
sottoscrizione di un form
È importante che le risposte alle azioni dell’utente siano prevedibili e percepibili e che le modalità d’interazioni siano coerenti in tutto il sito e analoghe alle metafore d’interazione comunemente usate nel Web.
Una caratteristica è una specifica componente di una tecnologia, per esempio un elemento in un linguaggio di markup o l’attivazione di una funzione in una Application Programming Interface. Solitamente, una certa caratteristica può essere disponibile solo in determinate versioni della tecnologia, e quindi può essere necessario segnalare la cosa nell'elenco dei requisiti.
Le funzionalità rappresentano lo scopo o effetto previsto del contenuto. Ciò può includere presentare un’informazione, raccogliere dati, assicurare una risposta da parte dell’utente, fornirgli esperienza, stabilire collegamenti ad altro contenuto, testare, confermare, acquistare, ecc.
Su dispositivi che non hanno una tastiera incorporata o annessa, esiste spesso un metodo alternativo per connettere la tastiera al dispositivo, o un metodo interno per inserire un testo. Attraverso “l' interfaccia di tastiera”, il contenuto può essere controllato per mezzo di comandi da tastiera o metodi alternativi che ne sostituiscono l’utilizzo.
Un link indirizza a un collegamento ipertestuale fra il documento corrente e una singola destinazione. (Qui, "link" indirizza ad un singolo "arc" nella specifica XML Linking Language (XLink) Version 1.0 ). Solo i link che sono disponibili per essere attivati dall'utente necessitano di incontrare i requisiti di accessibilità. Ciò esclude i link attivati automaticamente o programmaticamente.
Il contenuto è marcato in modo da permettere all’utente di individuare il materiale indesiderato e di evitarlo. Alcuni metodi che potrebbero essere usati a tale scopo includono:
metadata relativi alla pagina
informazioni nel titolo (così i motori di ricerca sono in grado di mostrarle)
notifica sulla pagina prima che le informazioni indesiderate stanno per essere visualizzate.
Nota dell'editore: Questa definizione necessita di rielaborazione.
I Media equivalenti presentano visivamente informazioni audio essenziali (sottotitoli) ed uditivamente informazioni video essenziali (descrizioni audio).
I linguaggi naturali sono quelli usati dall’uomo per comunicare, incluse le lingue parlate, scritte e il linguaggio dei segni.
Il contenuto non testuale include, ma non si limita, a immagini, testo in immagini raster, mappe immagini, animazioni (es. GIF animate), Arte ASCII, immagini usate come list bullet, barre spaziatrici, pulsanti grafici, suoni (che si attivano con o senza interazione dell’utente), file audio stand-alone, tracce audio o video, video. Inoltre includono qualunque testo che non può essere tradotto nel linguaggio Unicode.
Nota:
Script, applet, e oggetti programmatici non sono inclusi in questa definizione e sono analizzati nella linea guida 4.2.
Richiesto per la conformità.
La presentazione è la resa del contenuto e della struttura in una forma che può essere percepita dall’utente.
Componente d’interfaccia creata dall’autore, aggiuntiva rispetto a quelle fornite dallo user agent. Per esempio, una casella di controllo HTML non può essere una componente programmatica dell’interfaccia utente perché l’autore usa una componente dell’interfaccia supportata dallo user agent. Una casella di controllo implementata con script potrebbe essere una componente programmatica dell’interfaccia utente perché fornisce funzionalità che sono note o supportate dagli user agent e non possono essere rese accessibili dagli user agent anche se questi si conformano alle UAAG.
Determinato programmaticamente indica che può essere determinato il significato specifico.
Individuato programmaticamente vuole dire che il significato può essere trovato, sebbene possano esistere più significati per una stessa parola.
Nota dell'editore: Questa disposizione dipende dalla definizione di un modo standard di associare i dizionari e dalla disponibilità di dizionari on-line.
Eventi in tempo reale sono accadimenti che non sono sotto il diretto controllo dell’autore.
Un meccanismo di navigazione di un sito è un meccanismo per orientarsi e muoversi facilmente all’interno del sito. I meccanismi di navigazione di un sito includono ma non sono limitati a:
homepage con hyperlink e pagine successive che collegano ad altre parti del sito
mappa(e) del sito
motore(i) di ricerca
schema(i) che si espandono
visioni dinamiche a vasto raggio che mostrano tutte le pagine linkate o gli argomenti collegati a ciascuna pagina.
rappresentazioni virtuali in 3-D del contenuto del sito
La struttura include sia la struttura gerarchica del contenuto, sia le relazioni non gerarchiche come i riferimenti incrociati o le corrispondenze tra le intestazioni e i dati contenuti nelle celle di una tabella. La struttura gerarchica del contenuto rappresenta le variazioni nel contesto. Per esempio,
un libro è diviso in capitoli, paragrafi, liste. I titoli dei capitoli aiutano il lettore ad anticipare il senso dei paragrafi successivi. Le liste indicano concetti separati, ma collegati tra loro. Tutte queste suddivisioni aiutano il lettore ad anticipare le variazioni nel contesto.
una bicicletta è costituita da ruote e telaio. Inoltre una ruota è formata da un pneumatico e un cerchio. In un’immagine di bicicletta, un gruppo di cerchi e linee si trasformano in una “ruota” mentre un altro gruppo si trasforma nel “telaio”.
Una technologia è
un linguaggio di markup o di programmazione
un’Application Programming Interface (API)
o un protocollo di comunicazione
Nota dell'editore: Stiamo attualmente lavorando con Internationalization (I18N) per includere riferimenti ed esprimere meglio le definizioni WCAG 2.0 relative a “testo” e “codifica dei caratteri”.
Nota dell'editore: È necessario inserire in questo punto una definizione di descrizione testuale.
Nota dell'editore: È necessario inserire in questo punto una definizione di etichetta di testo.
Un testo alternativo
ha la stessa funzione del contenuto non testuale
comunica la stessa informazione veicolata dal contenuto non testuale
può comprendere contenuto strutturato o metadata
Nota:
I testi alternativi dovrebbero essere facilmente convertibili in Braille o parlato, visualizzati con un font più grande o colori diversi, inseriti nei traduttori o in software per riassumere, etc.
Una presentazione dipendente dal tempo è una presentazione che:
è formata da tracce audio e video sincronizzate (es. un film), o
richiede all'utente di interagire in uno specifico momento della presentazione.
È probabile che il contenuto sia poco familiare se si usano termini specifici per un particolare uditorio. Per esempio, molti dei termini usati in questo documento sono specifici per la comunità dei disabili.
Il Wisconsin Computer Equivalence Algorithm è un metodo per applicare i principi espressi dalla ITC del Regno Unito (nel documento "ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television" revisionato e pubblicato nel Luglio 2001) riguardo al contenuto visualizzato sullo schermo di un computer, come le pagine Web o altri contenuti digitali. ITC Guidance si basa sull’assunzione che lo schermo televisivo occupa i dieci gradi centrali del campo visivo. Questo non è esatto per uno schermo che è collocato di fronte ad una persona. Il Wisconsin Algorithm fondamentalmente esegue la stessa analisi delle linee guida dell’ITC, ma lo fa per ogni possibile finestra di dieci gradi di un prototipo di display di calcolatore.
Nota dell'editore: I collegamenti ai riferimenti saranno forniti non appena essi saranno disponibili.
Sin dalla pubblicazione delle WCAG 1.0 nel Maggio 1999, il WCAG Working Group ha ricevuto feedback sulle priorità dei checkpoint, sull’usabilità dei vari documenti, e richieste di chiarimenti sul significato di specifici checkpoint e di come operare per soddisfarli. Pertanto quando le WCAG 2.0 diventeranno una W3C Recommendation:
saranno organizzate in modo più efficiente,
potranno rettificare la priorità di alcuni checkpoint,
potranno modificare, eliminare o aggiungere requisiti a seguito dei cambiamenti nelle Tecnologie Web, riscontrati dopo la pubblicazione delle WCAG 1.0,
incorporeranno gli Errata delle WCAG 1.0,
faranno tesoro dell’esperienza acquisita nell’implementare le WCAG 1.0.
Per un confronto dettagliato, fare riferimento al documento Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft.
Ci auguriamo che le WCAG 2.0 presentino parecchi miglioramenti rispetto alle WCAG 1.0. L’obiettivo principale delle WCAG 2.0 è lo stesso delle WCAG 1.0 (promuovere l’accessibilità dei contenuti Web). Obiettivi supplementari per le WCAG 2.0 sono:
assicurare che i requisiti possano essere applicati trasversalmente dalle tecnologie
assicurare che i requisiti per la conformità siano chiari
assicurare che i documenti siano facili da usare
scrivere per un pubblico variegato
identificare chiaramente chi beneficia dei contenuti accessibili
assicurare che la revisione sia compatibile con le WCAG 1.0 Per maggiori informazioni circa i miglioramenti
Per maggiori informazioni circa i miglioramenti proposti nella Working Draft WCAG 2.0 fare riferimento ai Requisiti per WCAG 2.0 .