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 rendere le linee guida più generiche (meno specifiche per l’HTML). Questa draft non si basa ancora sul consenso di tutto il WCAG Working Group né ha ancora 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".
La pubblicazione di 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.
Il 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. Un soggetto con conoscenza effettiva di un brevetto, che ritiene contenga Dichiarazioni 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 d’interesse, si è deciso di presentare le linee guida sotto forma di più documenti intercorrelati. Le WCAG 2.0 sono articolate su tre livelli:
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) (13 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 sull’uso delle differenti tecnologie per conformarsi alle WCAG 2.0 Working Draft.
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
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 e in particolare Getting Started: Making a Web Site Accessible.
La maggior parte dei contenuti Web è creata usando authoring tool. Questi strumenti spesso determinano come implementare il contenuto, sia assumendo direttamente decisioni di authoring sia limitando le possibilità di scelta dell’autore. Dunque gli authoring tool giocheranno un ruolo molto importante nella creazione di contenuti conformi alle Web Content Accessibility Guidelines. Allo stesso tempo raccomandiamo che tutti gli autori familiarizzino con le Linee Guida poiché ciò favorirà la creazione di contenuti accessibili e poiché la copertura delle linee guida può variare da tool a tool.
Gli sviluppatori di authoring tool possono rendere tali strumenti maggiormente compatibili con le Web Content Accessibility Guidelines seguendo le Authoring Tool Accessibility Guidelines.
Consigliamo agli utilizzatori finali e agli acquirenti di authoring tool di considerare la conformità alle Authoring Tool Accessibility Guidelines come criterio di selezione tra i vari strumenti.
Nota dell’editore: Il Working Group delle Authoring Tool Accessibility Guidelines ha pubblicato varie Working Draft delle ATAG 2.0. I riferimenti sopra indicati dovranno essere aggiornati non appena le ATAG 2.0 diventeranno delle recommendation.
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 generale le linee guida non includono raccomandazioni inerenti l’usabilità, eccetto dove esse abbiano specifiche conseguenze per l’accessibilità.
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: Assunzione di una Linea base per le Tecnologie
Nella stesura delle WCAG 2.0, il WCAG WG si dibatte nel tentativo di definire il ruolo dei content author e degli user agent nel rendere i contenuti Web accessibili alle persone con disabilità. A causa delle carenze individuate negli user agent, nelle WCAG 1.0 sono state utilizzate frasi del tipo: "finché gli user agent..."
Oggi continuano a sussistere molti problemi e si sta cercando un meccanismo più efficace per risolverli rispetto alla creazione di linee guida "temporary bridge", progettate per sopperire alle carenze degli user agent. Un modo per fare ciò potrebbe consistere nel creare linee guida basate sull’assunzione di una linea base per gli user agent. Stiamo attualmente considerando di utilizzare user agent conformi alle User Agent accessibility Guidelines come linea base per User Agent per le WCAG 2.0. Quindi le WCAG 2.0 dovrebbero essere scritte assumendo che tutti gli utenti possiedano user agent conformi a tutti i checkpoint di priorità 1 delle User Agent Accessibility Guideline 1.0 (UAAG 1.0). Ne derivano parecchie implicazioni. Per esempio, le WCAG 2.0 dovrebbero assumere che gli user agent e le tecnologie assistive possano effettivamente interagire con i contenuti.
Oggi, nessuno user agent soddisfa tutti i checkpoint di priorità 1 delle UAAG 1.0. Se le WCAG 2.0 assumessero che gli user agent debbano conformarsi ai checkpoint di priority 1 delle UAAG 1.0, si creerebbero delle discrepanze tra il contenuto che soddisfa le WCAG 2.0 e gli attuali user agent disponibili. Per risolvere tale problema, proponiamo due metodi.
Incalzare per lo sviluppo di user agent che si confomino a tutti i checkpoint di priorità 1 delle UAAG 1.0
Sviluppare un insieme di "tecniche di riparazione" ad uso degli autori di contenuti che desiderano sia conformarsi alle WCAG 2.0, sia compensare le mancanze degli attuali user agent.
Gradiremmo inoltre collaborare con User Agent Accessibility Guidelines Working Group (UAWG) e con Authoring Tools Accessibility Guidelines Working Group (AUWG) per individuare un insieme di strategie che i produttori di user agent potrebbero inserire all’interno di essi per compensare i più comuni errori degli autori di contenuti.
Come risultato si potrebbero ottenere WCAG 2.0 più stabili e una migliore integrazione con le UAAG, in modo da attribuire la responsabilità per i problemi di accessibilità alle appropriate competenze delle tecnologie Web (user agent versus Web content). Fare riferimento a Interdependent Components of Web Accessibility per maggiori informazioni.
Il WCAG working group sta analizzando questo approccio per capirne meglio le possibili conseguenze sugli utenti. Le linee guida e i success criteria in questa working draft non riflettono ancora questo andamento. Il WCAG WG invita a commentare questo approccio e i problemi ad esso collegati.
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.
I success criteria per ciascuna linea guida sono raggruppati in tre livelli:
Success criteria di livello 1:
Si raggiunge un livello minimo di accessibilità attraverso markup, scripting o altre tecnologie che interagiscono o permettono l’accesso tramite user agent e tecnologie assistive.
Possono essere ragionevolmente applicati a tutte le risorse Web
Success criteria di livello 2:
L'accessibilità aumenta attraverso una o entrambe le seguenti condizioni:
viene ulteriormente facilitata l'abilità dello user agent di fornire contenuto accessibile
il contenuto e/o la presentazione sono direttamente accessibili e non richiedono all'utente disabile o allo user agent di operare in modo diverso rispetto agli utenti non disabili
Possono essere ragionevolmente applicati a tutte le risorse Web.
Success criteria di livello 3:
Si va oltre i livelli 1 e 2 per incrementare ulteriormente l’accessibilità 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.
Qualunque conformità con le WCAG 2.0 richiede che siano soddisfatti tutti i success criteria di livello 1 di tutte le linee guida.
La conformità alle WCAG 2.0 di livello A significa che sono soddisfatti tutti i success criteria di livello 1 di tutte linee guida.
La conformità alle WCAG 2.0 di livello Double-A significa che sono soddisfatti tutti i success criteria di livello 1 e tutti i success criteria di livello 2 di tutte le linee guida.
La conformità alle WCAG 2.0 di livello Triple-A significa che sono soddisfatti tutti i success criteria di livello 1, di livello 2 e di livello 3 di tutte le linee guida.
Il Working Group ritiene che tutti e tre i livelli di success criteria siano importanti o essenziali per alcune persone. Quindi le precedenti descrizioni "impossibile accedere" per il livello A, "difficoltà di accesso" per il livello AA, e "alcune difficoltà" per il livello AAA non sono più usate. Al loro posto, abbiamo definito i tre livelli come sopra.
Tutte le dichiarazioni di conformità devono includere almeno le seguenti informazioni:
La versione delle linee guida in base alla quale è sta dichiarata la conformità.
Una lista di uno o più URI o URI pattern, che identificano le delivery unit per le quali la dichiarazione è stata fatta. Una risorsa è conforme alle WCAG 2.0, per un dato livello, se è conforme tutto il contenuto fornito da quella risorsa.
Nota:
Se attraverso la negoziazione del contenuto si possono recuperare da un URI più rappresentazioni dello stesso, allora la dichiarazione di conformità dovrebbe essere fatta per la delivery unit restituita in assenza di negoziazione (a meno che il server non fornisca errore in quella situazione, nel qual caso una delle forme negoziate deve essere conforme).
Nota dell’editore: Vi sono dei problemi riguardo a se l’URI sia un riferimento abbastanza specifico del materiale per il quale viene fatta la dichiarazione di conformità
Il livello di conformità deve essere dichiarato.
Nota dell’editore: E' stato sollevato il problema riguardo a se l’informazione richiesta negli item 1-3 sopra indicati debba essere trasmessa nell’intestazione HTTP o in qualche altro modo.
Il livello di conformità per una delivery unit che contiene authored unit è equivalente al livello più basso di conformità dichiarato per il contenuto della delivery unit e per qualsiasi authored unit che essa contiene - incluse le dichiarazioni di unità aggregate.
Una risorsa individuata per mezzo di un URI è conforme alle WCAG 2.0, ad un dato livello di conformità, solo se tutto il contenuto fornito da quella risorsa è conforme. Per esempio, se la risorsa fornisce informazioni recuperate da un database in risposta ad interrogazioni dell'utente, tutte le delivery unit contenenti tale informazione devono soddisfare tutti i success criteria delle WCAG 2.0 del livello per il quale la conformità è dichiarata. Notare l’eccezione se la negoziazione del contenuto è operativa e lo user agent richiede una versione del contenuto che non soddisfa le WCAG 2.0 al livello di conformità asserito.
Nota dell’editore: Ci stiamo attualmente occupando di come trattare authored unit sconosciute o prodotte da comunità, create utilizzando un tool aggregatore fornito. Se il tool aggregatore fornito è conforme alle ATAG, la conformità alle ATAG implica che il contenuto aggregato sia conforme alle WCAG?
Le dichiarazioni di conformità possono riguardare solo alcune parti di un sito Web. Tutte le dichiarazioni di conformità devono fare riferimento ad un URI o ad un gruppo di URI. Non è permesso escludere da un sito un particolare tipo di contenuto (per esempio, immagini o script) poichè ciò comporterebbe l'esclusione di singoli success criteria. E' invece permesso utilizzare un URI per escludere sezioni di un sito, in modo che gli autori possano effettuare dichiarazioni di conformità che ne riguardino solo alcune parti.
Gli autori di un contenuto attualmente conforme alle WCAG 1.0 potrebbero volersi adeguare alle WCAG 2.0, capitalizzando il lavoro fatto in passato per raggiungere l'accessibilità. Questo passaggio potrebbe essere permesso da una dichiarazione di conformità condizionata. Ad esempio, una dichiarazione di conformità potrebbe essere fatta nel seguente modo:"I materiali creati o modificati prima del 24 Aprile 2003 sono conformi alle WCAG 1.0. I materiali creati o modificati il 24 Aprile 2003 o dopo tale data sono conformi alle WCAG 2.0. Se una delivery unit è modificata in modo significativo, allora dovrebbe conformarsi completamente alle WCAG 2.0."
Nota dell'Editore: A seconda dei success criteria utilizzati, in alcuni casi potrebbe essere più semplice conformarsi alle WCAG 2.0 che alle WCAG 1.0 e viceversa. 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à comunicazioni 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 accessibili 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 adatte come ambienti rumorosi che impediscono di ascoltare bene o scarsamente illuminati può trarre benefici da un contenuto accessibile. Allo stesso modo, un motore di ricerca può trovare una citazione famosa in un film se esso è corredato di sottotitoli per supportare utenti non-udenti.
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 del Web Accessibility Initiative.
Come fornire testo alternativo per contenuto funzionale. (Informativo)
Nota: ciò significa che per i multimedia sono fornite etichette (come descritto nel precedente criterio) e trascrizioni.
Come fornire testo alternativo per contenuto che trasmette informazioni. (Informativo)
Come fornire testo alternativo per il contenuto che genera una specifica esperienza sensoriale. (Informativo)
Come fornire testi alternativi che possano essere ignorati dalle tecnologie assistive.. (Informativo)
Come associare in modo esplicito il testo alternativo con il contenuto non testuale.. (Informativo)
Per il contenuto dal vivo solo audio o solo video, come internet radio o Web camera, il testo alternativo descrive lo scopo della presentazione o è fornito un link ad un contenuto alternativo in tempo reale, come un rapporto sul traffico trasmesso da una Web camera.
Nota: il contenuto in tempo reale non implica sottotitoli in tempo reale.
Nota dell’editore: Ciò è simile al #1 sopra indicato, sembra che ci sia ancora bisogno di occuparsi in modo specifico del contenuto solo audio o solo video per evitare confusione.
Nessun success criteria di livello 2 per questa linea guida.
Come fornire descrizioni di tutte le importanti informazioni visive 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.
Un’icona a forma di lente d’ingrandimento è usata per linkare alla pagina di ricerca di un sito Web. Uno screen reader individua il pulsante come un link e legge il testo alternativo "Ricerca".
Esempio 2: un diagramma di dati.
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 grafico, fornisce un sommario dei dati confrontabile con quello che risulta dal grafico, e organizza i dati in una tabella.
Esempio 3: una registrazione di un discorso.
Il link ad una clip audio dice, “Discorso di Chairman all'assemblea“. E' fornito un link ad una trascrizione testuale immediatamente dopo il link alla clip audio.
Esempio 4: una registrazione di una sinfonia.
Il link ad un file audio dice, “Quinta sinfonia di Beethoven eseguita dall’ Orchestra filarmonica di Vienna”.
Esempio 5: una’animazione che illustra come lavora il motore di una macchina.
Un’animazione illustra come lavora il motore di una macchina. Non è presente l’audio e l’animazione è parte di un tutorial che descrive come lavora un motore. Tutto quel che è necessario è una descrizione dell’immagine. Da “Come lavora il motore di una macchina: Combustione interna”
Nota dell’Editore: Devono essere sviluppati esempi relativi a radio stream e Web camera dal vivo.
Sono forniti sottotitoli per i multimedia preregistrati. [I]
Sono fornite descrizioni audio per i multimedia preregistrati [I]
Nota dell’Editore: Sebbene vi sono casi in cui sottotitoli e descrizioni audio non sono indispensabili, questa versione della Linea guida 1.2 non cerca di risolvere il problema. Piuttosto, si presume che maggiori dettagli vengano inclusi nei documenti tecnici e che i policy maker chiariranno quando i sottotitoli e le descrizioni audio risultino indispensabili.
Se il contenuto multimediale è trasmesso da un altro medium, le caratteristiche di accessibilità richieste per quel medium devono restare inalterate.
Nota dell’Editore: Come rapportarsi con le presentazioni che contengono solo audio o solo video e che costringono gli utenti ad interagire con esse in momenti specifici? Poichè non si tratta di questioni riguardanti i multimedia, si potrebbe aggiungere un criterio alla linea guida 1.1. Si sente comunque la necessità di alternative sincronizzate, quindi si potrebbe aggiungere un criterio a questa linea guida. Fare riferimento al problema 1272.
I multimedia sono corredati di traduzione nel linguaggio dei segni
Sono fornite ampie descrizioni audio per i multimedia preregistrati.
Sono fornite descrizioni audio per i multimedia dal vivo.
Linea guida 1.2 (media-equiv) 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.
Dei media alternativi beneficiano anche persone non disabili quali ad esempio:
Utenti in ambienti rumorosi o privi del 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 alle mani.
Sottotitoli e descrizioni testuali rendono possibile l’indicizzazione e la ricerca dei file mediali.
Esempio 1: un movie clip con descrizione audio.
Trascrizione audio basata sui primi cinque minuti di "Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.)
Descrittore: Il titolo, "Teaching Evolution Case Studies. Bonnie Chen." Ora un' insegnante mostra delle fotografie.
Bonnie Chen: Queste sono tutte inquadrature delle Everglades...per oggi può darsi proprio il caso che voi siate una specie di trampoliere che ha un becco come questo."
Descrittore: Lei consegna a ciascuno di loro due lamine di legno lisce e sottili.
Esempio 2: un tutorial sottotitolato.
Un video mostra come fare un nodo. Nei sottotitoli si legge "(musica)
USARE UNA CORDA PER FARE NODI
ERA UNA ABILITA' IMPORTANTE
PER MARINAI, SOLDATI E BOSCAIOLI."
Da Formattazione di Trascrizioni Campione di Whit Anderson
Nota dell’Editore: Esempi da sviluppare: un’animazione con colonna sonora di musica lirica, una presentazione di diapositive interattiva, un'animazione con colonna sonora musicale.
Come assicurare che strutture e relazioni nel contenuto possano essere programmaticamente determinate. (Informativo)
Nota dell’Editore: I concetti "affidabile" e "standard" devono essere incorporati nella definizione "programmaticamente."
Come assicurare che l’enfasi possa essere programmaticamente determinata. (Informativo)
Come rendere disponibile l’informazione presentata tramite il colore attraverso il contesto o il markup. (Informativo)
Come rendere disponibile l’informazione presentata attraverso il colore senza dover interpretare il markup. (Informativo)
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:
Le immagini del testo che si adeguano alla linea guida 1.1 dovrebbero soddisfare questo criterio. (Fare riferimento alla Linea Guida 1.1 Fornire testo alternativo per tutti i contenuti non testuali.)
Nota dell'Editore: Il Working Group sta cercando un algoritmo capace di misurare il contrasto in maniera sufficientemente accurata e verificabile da poterlo includere nelle linee guida. Attualmente viene preso in considerazione, per essere incorporato nelle tecniche, l'algoritmo che proviene dal documento Techniques For Accessibility Evaluation And Repair Tools. Il gruppo, però, non ha ancora trovato qualcosa di abbastanza specifico da poter essere incluso a livello di linee guida.
Note:
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.4 (contrasto audio-visivo) Problemi
Utenti ipovedenti possono facilmente leggere i caratteri di un testo, pur in presenza di un campo visivo limitato o di carenze nella percezione del colore, al pari di utenti normodotati che non hanno difficoltà nel distinguere il testo dalle immagini di background. Anche i disabili cognitivi si avvantaggeranno nella comprensione, poichè beneficeranno di un testo facilmente distinguibile. Il contrasto visivo aiuta anche gli utenti con disabilità uditive, che potranno usufruire di una chiara rappresentazione visiva del'informazione.
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.
Nota:
Il Contrasto Audio è anche conosciuto come "rapporto segnale/rumore" dagli audiologisti, dove "segnale" fa riferimento all'audio di foreground e "rumore" a quello 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.
Esempio 2: 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 time-out 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à.
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.
Nota dell'Editore: Il Trace Center dell'Università del Wisconsin renderà disponibile un free tool che analizzerà in tal senso il contenuto Web.
Nota:
Conformemente al primo criterio di livello 1 della Linea Guida 1.3 Assicurare che informazioni, funzionalità e strutture siano separabili dalla presentazione. si destina anche questa linea guida al livello 1.
Nota dell'Editore: Il working group è alla ricerca di input circa la sovrapposizione del criterio per le linee guida 1.3 e 2.4.
Nota dell'Editore: Le General Techniques potrebbero includere informazioni su come soddisfare questo criterio attraverso metadata, uso di un futuro attributo di ruolo, ecc.
Nota dell'Editore: Il problema è come specificare l'applicazione di questo criterio al contenuto organizzato in sequenza, senza che occorra un test allo scopo. E' stato notato che l'ordine di lettura è già garantito dalla 1.3, che chiede di rendere determinabili programmaticamente le strutture e le relazioni all'interno del contenuto. Se il Working Group ed altri lettori condividono questo punto di vista, questo success criterion potrebbe essere cancellato e la relativa General Technique potrebbe essere spostata alla linea guida 1.3.
Nota dell'Editore: Il criterio riguardante l'ordine di lettura può essere più appropriato se inserito nel Principio 3: si potrebbe arguire che l'ordine di lettura sia irrilevante, a meno che non incida sull'abilità dell'utente di capire il contenuto. L'ordine di lettura di per sé non è necessariamente un problema relativo all'accessibilità. Lo diventa se un utente disabile (ad esempio con menomazioni visive o cognitive) non riesce a ricavare in maniera affidabile un significativo ordine di lettura dalla presentazione di default. Se vogliamo mantenere questo criterio e conservarlo nella 2.4, abbiamo bisogno di dare una formulazione che vincoli l'ordine di lettura all'abilità dell'utente nell'operare ed utilizzare il contenuto. Non è necessariamente vero che il solo mostrare la struttura allo user agent sia sufficiente ad indicare un ordine di lettura plausibile. L'esempio per la General Technique circa l'ordine di lettura è ideato per evidenziare questo problema.
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.
Se è rilevato un errore dell’utente, l'errore è identificato e segnalato sotto forma di testo.
Se è rilevato un errore dell’utente e sono noti i suggerimenti per la correzione da poter fornire senza compromettere la sicurezza o gli obiettivi, l'errore è identificato e i suggerimenti resi disponibili.
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.
Laddove è richiesta immissione testo per cui esiste un insieme di meno di 75 alternative valide che possono essere fornite senza compromettere la sicurezza o gli obiettivi, agli utenti è permesso selezionare le scelte da una lista di opzioni così come digitare i dati direttamente.
Se consenito dal linguaggio naturale del testo, è fornita un'opzione per il controllo ortografico dei termini immessi con suggerimento di quelli corretti.
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: Identificare errori nella trasmissione di un form.
Il sito Web di una linea aerea offre una speciale promozione relativa ai voli scontati. All'utente è richiesta la compilazione di un semplice form in cui inserire informazioni personali, come nome, indirizzo, numero di telefono, preferenze per il posto a sedere ed e-mail. Se qualcuno dei campi del form è incompleto o completato in modo non esatto, l'utente è avvertito dell'errore di input. All'utente è poi presentato lo stesso form, con ancora disponibili tutte le informazione inserite in precedenza in maniera corretta. Gli verrà richiesto di correggere ogni campo segnalato da una freccia rossa o da un doppio asterisco. Notare come gli errori non siano evidenziati unicamente tramite il colore.
Esempio 2: Username e password errati.
Una pagina Web richiede all'utente di inserire sia username che password. Se uno dei due non è corretto, l'utente è informato della presenza di un errore, ma per ragioni di sicurezza, non gli viene comunicato in quale campo è l'errore, se in quello relativo allo username o in quello relativo alla password, e non vengono proposti suggerimenti per la correzione.
Esempio 3: Un test online.
Un sito Web fornisce un test online per certificare le conoscenze in un determinato ambito di studio. Il test segnala all'utente le risposte errate, ma non offre suggerimenti per la correzione. Lo scopo del test online è di saggiare le conoscenze dell'utente, pertanto, fornire indizi sulle risposte esatte andrebbe contro gli obiettivi del sito Web.
Esempio 4: Conferma di un ordine.
Un'attività Web di vendita al minuto offre shopping online ai consumatori. Quando viene trasmesso un ordine, le relative informazioni, comprendenti gli articoli ordinati, la quantità di ciascuno, l'indirizzo per la spedizione e il metodo di pagamento, sono visualizzate sullo schermo per consentire all'utente di controllare la correttezza dell'ordine. Questi può o confermare l'ordine o apportare dei cambiamenti.
Esempio 5: Una lista di selezione per ridurre gli errori.
Un'attività Web di vendita al minuto offre shopping online ai consumatori interessati all'equipaggiamento per la pesca con la mosca. Quando all'utente è richiesto il paese d'origine, viene proposto di selezionare il proprio da un elenco pulldown, invece di digitare l'informazione. Al fine di rendere le cose più semplici, l'utente è avvertito che i paesi sono elencati in ordine alfabetico.
Esempio 6: Caratteristiche di un motore di ricerca.
Un motore di ricerca è fornito di varie opzioni di ricerca per i differenti livelli di abilità e le diverse preferenze. Include un'opzione per controllare l'ortografia dei termini da ricercare ed offre alternative "best guess", ricerche tipo query-by-example ed altre ricerche simili.
Esempio 7: Controllo ortografico in un form con feedback.
Il sito Web di una banca fornisce ai clienti un form per trasmettere domande o suggerimenti. L'interfaccia del form include una caratteristica opzionale di controllo ortografico per l'area riservata all'input del testo dove immettere la domanda o il suggerimento.
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: descrizione di un complesso evento naturale.
Una pagina Web tratta del Monte Pinatubo nelle Filippine. La pagina include la descrizione dell'eruzione del 1991, corredata di foto, le sue conseguenze ed anche una breve spiegazione sulle cause delle eruzioni vulcaniche. Allo scopo di rendere più chiara la spiegazione, è presente un link ad un video accessibile e ad una simulazione 3D di ciò che accadde al di sotto della crosta terrestre e all'interno del vulcano durante l'eruzione.
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. E' disponibile un elenco di problemi aperti relativi a questo glossario.
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.
Un URI pattern è un' espressione regolare che identifica un insieme di risorse. Una risorsa appartiene all'insieme se l'espressione regolare corrisponde al suo URI.
Nota:
per essere inclusa nel set, la risorsa deve esistere; l'espressione regolare può e tipicamente incontrerà URI che non fanno riferimento a risorse esistenti.
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.
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.
Narrazione audio aggiuntiva che spiega dettagli importanti che non possono essere capiti soltanto dalla traccia sonora principale. Durante le pause di dialogo, le descrizioni audio forniscono informazioni sulle azioni, sui personaggi, sui cambiamenti di scena, che sono inoltre visualizzate sullo schermo sotto forma di testo per i disabili della vista.
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 .
Immagine che appare dietro o sullo sfondo del campo visivo.
Trascrizioni sincronizzzate di dialogo ed importanti effetti sonori. I sottotitoli consentono l'accesso ai multimedia per i disabili dell'udito.
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.
Un insieme di materiali trasferiti fra due programmi Web cooperanti, come la risposta ad una singola richiesta HTTP . Il trasferimento potrebbe, ad esempio, essere fra un origin server e uno user agent.
Nota:
Questo termine è stato preso letteralmente dal Glossary of Terms for Device Independence.
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.
Nei casi in cui è necessaria una più lunga descrizione audio, ma non c'e nell'audio una pausa sufficiente per inserirla, l'audio e il video vengono arrestati durante l'esecuzione della descrizione audio. Quando la descrizione termina, il video ed il dialogo riprendono. Descrizioni ampie e "regolari" possono essere mixate in una stessa presentazione multimediale.
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.
Non sono permesse sequenze intermittenti o rapidi cambiamenti di immagini quando si verificano entrambe le seguenti situazioni:
L’area sede delle intermittenze che avvengono simultaneamente (ma non necessariamente contiguamente) occupa più di un quarto di un qualsiasi rettangolo di dimensioni 355x268 pixel entro l’area schermo, laddove il contenuto sia visualizzato con risoluzione 1024x768 e
Avvengono più di tre intermittenze al secondo.
Nota:
Nella General Flash Threshold, un’intermittenza è definita come coppia di opposti cambiamenti nella luminanza (ad esempio, un aumento della luminanza seguito da una sua diminuzione o una diminuzione seguito da un aumento) di 20 cd.m-2 o più, e se la luminanza dello schermo relativa alle immagini più scure è inferiore a 160 cd.m -2.
Nota:
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.
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 alternativi presentano visivamente informazioni audio essenziali (sottotitoli) ed uditivamente informazioni video essenziali (descrizioni audio).
Nelle intenzioni di queste linee guida, i multimedia si riferiscono a presentazioni congiunte di audio e video.
Nota dell'Editore: Nel futuro, i multimedia comprenderanno probabilmente anche contenuti visivi dinamici, interattivi e forse altre combinazioni di media.
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 significa che può essere determinato lo specifico valore in uno standard, forma decifrabile da una macchina o da un software.
Individuato programmaticamente significa che il valore può essere trovato, sebbene possano esistere più valori (ad esempio, fornendo una definizione da dizionario per una parola che ha molteplici significati). Questo termine contrasta con determinato programmaticamente, dove lo specifico valore può essere determinato.
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.
Non è permesso il passaggio a (o da) un rosso saturo ad un qualsiasi livello luminescente quando si verificano entrambe le seguenti situazioni:
L’area sede delle intermittenze che avvengono simultaneamente occupa più di un quarto di un qualsiasi rettangolo di dimensioni 355x268 pixel entro l’area schermo, laddove il contenuto è visualizzato con risoluzione 1024x768 e
avvengono più di tre intermittenze al secondo.
Nota:
Nella Red Flash Threshold, un flash è definito come qualunque coppia di transizioni opposte a (o da) un rosso saturo ad un qualsiasi livello luminescente. (Vedi nota sottostante).
Nota:
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.
Una espressione regolare come definita in XML Schema Part 2: Datatypes, Appendix F.
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
Le definizioni internazionali per la soglia di distribuzione spaziale stanno mutando e noi adotteremo i nuovi standard non appena saranno resi pubblici
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 tecnologia è
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”.
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.
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.
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.
Una presentazione dipendente dal tempo che contiene solo video.
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 Requirements for WCAG 2.0 .