Cosa sono le WCAG?

Le linee guida per l’accessibilità dei contenuti Web spiegano come realizzare contenuti per il Web di modo che siano accessibili a persone affette da disabilità. Le linee guida sono rivolte agli sviluppatori di contenuti per il Web (autori di pagine Web e persone che si occupano del design di siti Web), nonché agli sviluppatori di strumenti di authoring. Il fine primario delle linee guida è quello di promuovere l’accessibilità. Nondimeno, la loro applicazione consente di rendere disponibili i contenuti Web a tutti gli utenti, indipendentemente dal tipo di strumento di navigazione utilizzato (ad esempio browser grafici, browser vocali, cellulari, navigatori per automobile ecc.) o da limitazioni cui ci si trovi costretti (ad es. un ambiente rumoroso, sovra o sotto-illuminato, o circostanze che impongano di non utilizzare le mani ecc.). Nel seguire le linee guida si aiutano inoltre le persone a reperire più velocemente informazioni nel Web, mentre non si dissuadono i content manager dall’usare immagini, filmati, ecc., indicando inoltre le modalità per un corretto uso dei contenuti multimediali, onde renderli accessibili ad una più vasta utenza.

Si tratta di un documento di riferimento per i principi dell’accessibilità ed i progetti di Web-design. Alcune delle strategie qui discusse sono rivolte a problematiche riguardanti l’internazionalizzazione del Web e l’accesso attraverso periferiche mobili. D’altronde, il presente documento si incentra sull’accessibilità e non è direttamente connesso agli altri rami di attività del W3C. Per approfondimenti al riguardo, consultare le seguenti URL: http://www.w3.org/Mobile  , http://www.w3.org/International .

Il documento è da intendersi definito nel tempo, pertanto non contiene informazioni specifiche riguardo il supporto dei browser per le diverse tecnologie, che sono soggette a rapido mutamento.

Esse sono invece presenti nel sito della WAI Web Accessibility Initiative.

Nel documento è inclusa un’appendice che organizza tutti i punti di controllo (checkpoints), per argomento e priorità. I punti di controllo linkano alle loro definizioni, presenti nel documento. Gli argomenti dell’appendice includono immagini, documenti multimediali, tabelle, frame, moduli e script. L’appendice è disponibile sia in veste di sommario tabellare che come lista semplice.

Un documento separato, intitolato “Techniques for Web Content Accessibility Guidelines 1.0”, illustra le modalità di implementazione dei punti di controllo definiti nel documento in esame. Il documento sulle tecniche analizza ciascun checkpoint in modo dettagliato, con esempi sull’utilizzo di codice HTML, dei fogli di stile (CSS), del Synchronized Multimedia Integration Language (SMIL) e del Mathematical Markup Language (MathML). Il documento include inoltre tecniche di validazione e di testing delle pagine, ed un indice degli elementi e degli attributi HTML (con le relative indicazioni sul loro uso corretto). Il documento tecnico è stato ideato per tracciare l’evoluzione delle tecnologie, e sarà soggetto a frequenti aggiornamenti, diversamente dal documento in esame.

Nota: non tutti i browser e le strumentazioni multimediali sono in grado di supportare le caratteristiche descritte nelle linee guida. In particolare, specifiche HTML 4.0, CSS 1 e 2 potrebbero non essere supportate.

“Linee guida per l’accessibilità dei contenuti Web 1.0” è parte di una serie di linee guida sull’accessibilità pubblicate dalla Web Accessibility Initiative . La serie comprende anche le User Agent Accessibility Guidelines e le Authoring Tool Accessibility Guidelines, http://www.w3.org/TR/WAI-AUTOOLS/ .

Per coloro che non hanno dimestichezza con le problematiche afferenti l’accessibilità dei siti Web, è opportuno rivolgere l’attenzione al fatto che gli utenti possono trovarsi ad operare in contesti del tutto dissimili dall’usuale:

  • Potrebbero non essere in grado di vedere, di sentire, di muoversi, o di recepire in modo agevole – o affatto – alcuni tipi di informazioni.
  • Potrebbero avere difficoltà nel leggere o nel comprendere i testi.
  • Potrebbero non essere in grado di usare la tastiera o il mouse.
  • Potrebbero utilizzare un lettore solo-testo, un piccolo monitor, o una connessione a Internet molto lenta.
  • Potrebbero non dominare la lingua in cui è scritto il testo.
  • Potrebbero trovarsi a non disporre appieno della loro vista, udito, o delle loro mani (per esempio guidando, in un ambiente inquinato acusticamente, ecc.).
  • Potrebbero disporre di una versione antiquata del browser, o di un browser alternativo, di un browser vocale ad esempio, o di un inusuale sistema operativo.
  • I content manager dovrebbero considerare tutte queste eventualità nella progettazione di interfacce.

Esistono molteplici situazioni da prendere in esame, ma ogni scelta nel Web design accessibile comporta una serie di vantaggi per la comunità Web. Ad esempio, utilizzando i fogli di stile per controllare la formattazione dei font – eliminando l’elemento “font” – gli sviluppatori di codice HTML potranno avere maggiore controllo sulle pagine, che saranno pertanto più accessibili a chi non gode di una vista perfetta, e più velocemente visualizzabili per tutti grazie ai fogli di stile.

Le linee guida affrontano i problemi dell’accessibilità e forniscono soluzioni per la progettazione accessibile. Esse riguardano scenari rappresentativi (simili a quanto rilevato per la scelta dei font) che possono configurare difficoltà per utenti con particolari disabilità. Ad esempio, la prima linea guida illustra come gli sviluppatori possano rendere accessibili le immagini: alcuni utenti potrebbero non essere in grado di visualizzare le immagini, altri potrebbero usare browser testuali che non supportano immagini, mentre altri ancora potrebbero avere disattivate le funzionalità per le immagini (ad es. a causa di una connessione Internet lenta). Le linee guida non dissuadono dall’uso delle immagini come incremento dell’accessibilità. Al contrario, esse mostrano che fornire un equivalente testuale dell’immagine può consentire al non vedente di crearsi una immagine mentale della immagine stessa.

Come può un equivalente testuale rendere un’immagine accessibile? Nell’espressione “equivalente testuale” i termini sono entrambi importanti:

  • Il testo può essere presentato all’utente come sintesi vocale, braille e testo visualizzato sullo schermo. Ognuno di questi tre meccanismi usa uno dei diversi sensi – udito per la sintesi vocale, tatto per il braille e vista per il testo visualizzato – consentendo l’accessibilità dell’informazione a gruppi rappresentativi di una molteplicità di disabilità sensoriali o di altra natura.
  • Perché sia utile, il testo deve avere la stessa funzione o scopo dell’immagine. Ad esempio, si consideri un equivalente testuale per un’immagine fotografica della Terra vista dallo spazio. Se la finalità dell’immagine è precipuamente decorativa, il testo “Foto della Terra vista dallo spazio” svolge la funzione necessaria. Se il fine della foto è quello di delineare un’informazione specifica riguardo la geografia terrestre, conseguentemente l’equivalente testuale deve trasmettere quell’informazione. Se la foto è stata predisposta per dire all’utente di selezionare l’immagine (ad esempio cliccandoci) per ottenere informazioni sulla Terra, l’equivalente testuale potrà essere “Informazioni sul pianeta Terra”. Pertanto, se il testo ha la stessa funzione o finalità – per l’utente affetto da disabilità – dell’immagine per gli utenti normodotati, allora essa può considerarsi un equivalente testuale.

Si noti che, oltre ad apportare un beneficio agli utenti disabili, gli equivalenti testuali possono aiutare tutti gli utenti a trovare con maggiore facilità le pagine, dacché i robots dei motori di ricerca utilizzano il testo per l’indicizzazione.

Mentre è compito degli sviluppatori fornire equivalenti testuali delle immagini e dei contenuti multimediali, è responsabilità degli interpreti (ad es. browser e tecnologie assistive come lettori di schermo, display braille, ecc.) presentare le informazioni all’utente.

Gli equivalenti non testuali del testo (ad esempio icone, discorsi pre-registrati o il filmato di una persona che traduce il testo in gesti per i non udenti) fanno accedere all’informazione persone che hanno delle difficoltà ad accedere al testo scritto, inclusi gli individui con disabilità cognitive, difficoltà di apprendimento e sordità. Gli equivalenti non testuali possono essere altresì utili a quanti non possono leggere. Una descrizione sonora è un esempio di equivalente non testuale della informazione visuale. Una descrizione sonora della traccia visiva di una presentazione multimediale giova a quanti non riescono a fruire dell’informazione visiva.

Attualmente, all’interno del Gruppo di Lavoro dedicato alla creazione delle linee WCAG 2.0 (WCAG Working Group), vi sono anche degli italiani (in good standing, in ordine alfabetico):

  • Roberto Castaldo
  • Roberto Ellero
  • Roberto Scano

 

Potrebbero interessarti anche i seguenti articoli

  • ATAG – Authoring Tool Accessibility GuidelinesATAG – Authoring Tool Accessibility Guidelines Questo documento contiene le linee guida per gli sviluppatori di strumenti di authoring. Il suo scopo è duplice: assistere gli sviluppatori nella progettazione di […]
  • WCAG 2.0 in italianoWCAG 2.0 in italiano Dopo molti mesi di lavoro ed il succedersi di diverse versioni beta, il gruppo di lavoro coordinato da IWA/HWG ha finalmente visto riconoscere il risultato dei propri […]
  • Analisi – ATAG 2.0 W3C Working Draft 22 November 2004Analisi – ATAG 2.0 W3C Working Draft 22 November 2004 Descrizione del documento Questo documento vuole analizzare e fornire una serie di commenti alle linee guida del Working Draft pubblico del 22 Novembre 2004 delle […]
  • Web Accessibility Initiative (WAI)Web Accessibility Initiative (WAI) 1. Accessibilità: 10 anni di storia dall'ICADD al WAI Il World Wide web Consortium lanciò il WAI, letteralmente Web Accessible Iniziative, nell'ottobre del […]
  • XML Accessibility GuidelinesXML Accessibility Guidelines Le linee guida che si andranno ad analizzare forniscono informazioni utili su come creare applicazioni accessibili utilizzando XML. Confrontandolo con il linguaggio […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

Nessun commento

    Rispondi

    Link e informazioni