Dall’undici dicembre 2008 sono state definitivamente approvate le nuove linee guida per l’accessibilità dei contenuti per il Web, abbreviate con l’acronimo WCAG 2.0 (Web Content Accessibility Guidelines). Il documento è diventato W3C Reccomandation (ossia documento di riferimento) dopo molti anni di lavoro e riadattamento alla costante evoluzione delle tecnologie presenti nel Web, in particolare del cosiddetto Web collaborativo (o Web 2.0). Grazie ad un gruppo di lavoro nazionale, è stato possibile ottenere una traduzione ufficiale in italiano.

HTML ma non solo

Una delle principali critiche rivolte alle precedenti linee guida (WCAG 1.0, rilasciate il 5 maggio 1999) è la particolare aderenza dei requisiti alle specifiche HTML e CSS. Dalla nascita delle WCAG 1.0 però il Web non si è fermato: in quel periodo c’erano i primi accenni di utilizzo di Adobe Flash, i primi documenti PDF, i primi JavaScript… il cosiddetto Web 2.0, gli ActiveX, erano argomenti quasi sconosciuti e le tecnologie assistive, già faticavano ad interpretare il linguaggio HTML… figuriamoci oggetti di programmazione. È stato quindi necessario ripensare alle linee guida per l’accessibilità dei contenuti, soprattutto ripensando al concetto di contenuto Web. Per tale motivazione, all’interno delle WCAG 2.0 ci sono tre termini molto importanti da ricordare:

• Pagina Web. Nelle WCAG 2.0 questo termine non si limita alle pagine HTML inglobando qualsiasi risorsa raggiungibile tramite un URI. Ad esempio il termine pagina Web può contenere anche un filmato interattivo.
• Determinati tramite programmazione (programmatically determinated). Diversi criteri di successo richiedono che il contenuto (o alcuni aspetti di esso) possa essere “determinato tramite programmazione”. Ciò significa che il contenuto è espresso in modo tale che i programmi utente, tra cui le tecnologie assistive, sono in grado di estrarre e presentare le informazioni agli utenti in diverse modalità.
• Tecnologia che supporta l’accessibilità (Accessibility Supported). Si tratta di una tecnologia (HTML,CSS, ecc.) in grado di essere interpretata sia dalle caratteristiche di accessibilità previste nei browser che dalle tecnologie assistive. Solo le tecnologie “Accessibility Supported” possono essere utilizzate per raggiungere la conformità ai criteri di successo mentre le tecnologie non conformi (esempio: non utilizzabili con tecnologie assistive), possono comunque essere utilizzate anche se non per essere conformi ad un determinato criterio di successo.

Quest’ultimo punto è una delle maggiori novità delle WCAG 2.0. Per essere una tecnologia “accessibility supported” è necessario che entrambi i seguenti punti vengano soddisfatti per una particolare tecnologia per i contenuti Web:

• La tecnologia deve essere supportata dalle tecnologie assistive. Questo significa che la tecnologia deve essere verificata con l’ausilio di tecnologie assistive utilizzate dagli utenti.
• La tecnologia deve essere supportata dai browser disponibili agli utenti. Questo significa che almeno uno dei punti seguenti è rispettato:
  1. La tecnologia è supportata in modo nativo dalla gran parte dei browser che supportano l’accessibilità (esempio: HTML, CSS, ecc.).
  2. La tecnologia è supportata tramite dei plug-in largamente diffusi e che supportano l’accessibilità (esempio: PDF, contenuti multimediali, ecc.).
  3. Il contenuto è disponibile in un ambiente chiuso, come un’università o una rete aziendale, in cui il programma utente richiesto dalla tecnologia utilizzata e dall’organizzazione, supporta l’accessibilità.
  4. Il programma utente che supporta la tecnologia in modo accessibile è disponibile per il download o è acquistabile; è necessario verificare che tale programma non costi di più e non sia più complicato ottenerne una copia da parte di una persona con disabilità rispetto ad un utente normodotato.

I quattro principi

I principi alla base delle WCAG 2.0 sono quattro e sono da considerare i fondamenti dell’accessibilità. Se anche solo uno di questi principi non viene rispettato, gli utenti con disabilità non saranno assolutamente in grado di utilizzare il Web.

• Percepibile. Le informazioni e i componenti dell’interfaccia utente devono essere presentati agli utenti in modo da poter essere percepiti. Questo significa che l’utente, deve essere in grado di percepire le indicazioni indipendentemente dalla propria disabilità.
• Operabile. I componenti dell’interfaccia utente devono essere navigabili ed operabili. Questo significa che l’utente deve essere in grado di interagire con i componenti dell’interfaccia, ovvero l’interfaccia non può richiedere azioni per le quali un utente non è in grado di agire.
• Comprensibile. Le informazioni ed il funzionamento dei componenti dell’interfaccia utente devono essere comprensibili. Questo significa che gli utenti devono essere in grado di capire le informazioni, nonché il funzionamento dell’interfaccia utente.
• Robusto. Il contenuto deve essere sufficientemente robusto per essere interpretato in modo affidabile dalla maggior parte dei programmi utente, comprese le tecnologie assistive. Questo significa che gli utenti devono essere in grado di accedere al contenuto anche con l’evoluzione delle tecnologie, ovvero il contenuto deve risultare accessibile nel presente come nel futuro.

Linee guida

Ogni principio contiene delle linee guida il cui scopo è quello di aiutare a rispettare il principio stesso.

Uno dei principali obiettivi delle linee guida è quello di garantire che il contenuto sia direttamente accessibile al maggior numero di persone possibili, e che sia in grado di essere rappresentato in forme diverse per soddisfare le diverse necessità sensoriali, fisiche e capacità cognitive. Nelle WCAG 2.0 sono presenti 12 linee guida, suddivise per i quattro principi.

1. Percepibile

• 1.1. Fornire alternative testuali per qualsiasi contenuto non di testo in modo che possa essere trasformato in altre modalità fruibili secondo le necessità degli utenti come stampa a grandi caratteri, Braille, sintesi vocale, simboli o linguaggio più semplice.
• 1.2. Fornire alternative per i media temporizzati.
• 1.3. Creare contenuti che possano essere rappresentati in modalità differenti (ad esempio, con layout più semplici), senza perdere informazioni o la struttura.
• 1.4. Rendere più semplice agli utenti la visualizzazione e il sonoro dei contenuti, separando i contenuti in primo piano dallo sfondo.

2. Operabile

• 2.1. Rendere disponibili tutte le funzionalità tramite tastiera.
• 2.2. Fornire agli utenti un’adeguata disponibilità di tempo per leggere ed utilizzare i contenuti.
• 2.3. Non sviluppare contenuti che possano causare attacchi epilettici.
• 2.4. Fornire delle funzionalità di supporto all’utente per navigare, trovare contenuti e determinare la propria posizione.

3. Comprensibile

• 3.1. Rendere il testo leggibile e comprensibile.
• 3.2. Creare pagine Web che appaiano e che siano prevedibili.
• 3.3. Aiutare gli utenti ad evitare gli errori ed agevolarli nella loro correzione.

4. Robusto

• 4.1 Incrementare la compatibilità con i programmi utente attuali e futuri, includendo le tecnologie assistive.

Criteri di successo

All’interno di ogni linea guida sono presenti dei criteri di successo (success criteria) che descrivono in modo specifico che cosa sia necessario implementare per essere conformi a questa indicazione tecnica. I criteri di successo sono simili ai punti di controllo (checkpoint) presenti nelle WCAG 1.0 dai quali traggono ispirazione.

Le caratteristiche dei criteri di successo sono:

• conformità (un contenuto Web può essere conforme o meno)
• verificabilità (un contenuto Web può essere verificato in modalità automatizzata, con il parziale o totale ausilio di un utente)
• indipendenza (applicabili indipendentemente dalla tipologia di contenuto Web)

Conformità

Come per la precedente versione, anche in questo caso sono previsti tre livelli di conformità: per essere conforme, uno dei seguenti livelli deve essere completamente soddisfatto.

• Livello “A”. Per essere conforme al livello minimo “A”, un contenuto Web deve essere conforme a tutti i criteri di successo di livello “A” delle WCAG 2.0 oppure, deve fornire un contenuto alternativo conforme al livello “A” (che dovrà contenere le medesime informazioni e funzionalità, aggiornato come il contenuto non conforme e che sia raggiungibile senza difficoltà).
• Livello “Doppia A”. Per essere conforme al livello “Doppia A”, un contenuto Web deve essere conforme a tutti i criteri di successo di livello “A” e di livello “Doppia A” delle WCAG 2.0 oppure deve fornire un contenuto alternativo conforme al livello “Doppia A” (che dovrà racchiudere le medesime informazioni e funzionalità, aggiornato come il contenuto non conforme e che sia raggiungibile senza difficoltà).
• Livello “Tripla A”. Per essere conforme al livello “Tripla A”, un contenuto Web deve essere conforme a tutti i criteri di successo di livello “A” , di livello “Doppia A” e di livello “Tripla A” delle WCAG 2.0 oppure deve fornire un contenuto alternativo conforme al livello “Tripla A” (che dovrà racchiudere le medesime informazioni e funzionalità, aggiornato come il contenuto non conforme e che sia raggiungibile senza difficoltà).

La conformità (ed il livello di conformità dichiarato) è relativo all’intera pagina Web e non è dichiarabile se una parte del contenuto viene esclusa. Al fine di definire la conformità di una pagina, i contenuti alternativi sono considerati contenuto della pagina se sono raggiungibili direttamente dalla stessa (esempio: descrizioni estese, versioni alternative di video, ecc.). Gli sviluppatori che non possono dichiarare una conformità totale a causa di contenuti esterni non direttamente controllati dall’autore, possono utilizzare una dichiarazione di conformità parziale.

Tecniche per implementare e verificare la conformità

Quanto appena detto non deve spaventare: l’applicazione delle WCAG 2.0 sarà supportata da una serie di esempi e tecniche di applicazione che vengono rese pubbliche con costante aggiornamento a cura del gruppo di lavoro del W3C.  Il gruppo di lavoro delle WCAG 2.0, infatti, continua a lavorare con wiki, riunioni e votazioni sulla stesura delle tecniche di applicazione delle WCAG 2.0. Nell’attuale bozza di lavoro sono presenti tecniche specifiche per:

• Tutte le tecnologie
• HTML e XHTML
• CSS
• Script lato client
• Script lato server
• SMIL
• Testo
• WAI-ARIA
• Flash
• Silverlight
• PDF

Il futuro

Questa nuova specifica – su cui si basa l’aggiornamento dei requisiti della legge 4/2004 – aiuterà a garantire l’accessibilità di tutti quei contenuti “discriminati” in precedenza, ovvero consentirà di usare tecnologie quali Javascript, Flash, Java, ecc. chiaramente garantendo una piena accessibilità degli oggetti sviluppati con le stesse.

Torna alla home

Parole chiave: