Diodati.org - Accessibilità e traduzioni dal W3C

Sponsor ufficiale di Diodati.org: Hosting a partire da 25 euro/anno | Domini a partire da 10,79 euro/anno | Server dedicati a partire da 120 euro/mese

Le WCAG 1.0 sono essenzialmente una raccolta di raccomandazioni destinate a quelli che nel documento del WAI sono chiamati "content developers", ovvero sviluppatori di contenuti. Nel glossario delle WCAG il content developer è definito come Someone who authors Web pages or designs Web sites: qualcuno, cioè, che produce pagine Web o che progetta siti Internet.

In realtà questa definizione racchiude diverse figure professionali, come minimo tre:

• il progettista dell'interfaccia grafica delle pagine o del sito;
• chi traduce il progetto grafico in codice usando i linguaggi HTML, XHTML, CSS, XML, SMIL, SVG, ecc.;
• chi scrive i testi e struttura logicamente i contenuti.

In certi siti più semplici può anche esservi un'unica persona che svolge da sola questi differenti compiti. Per progetti complessi, si tratterà inevitabilmente di individui diversi, ciascuno dei quali dovrà affrontare per ciò che riguarda il suo specifico campo le richieste dell'accessibilità.

Qualunque sia la distribuzione dei compiti, le WCAG 1.0 pongono ai professionisti interessati due obiettivi principali:

1. assicurare una trasformazione gradevole della pagina;
2. rendere i contenuti comprensibili e navigabili.

Le prime undici raccomandazioni, delle quattordici di cui si compongono complessivamente le WCAG 1.0, sono dedicate al raggiungimento del primo obiettivo; le ultime tre al raggiungimento del secondo.

I metodi suggeriti dalle WCAG per il conseguimento del primo obiettivo riguardano soprattutto interventi sul codice, mirati a rendere la struttura della pagina il più possibile flessibile, in modo che i suoi contenuti possano essere fruiti senza perdita d'informazioni per mezzo dei più diversi dispositivi di navigazione: dai normali browser grafici ai browser testuali, dai sintetizzatori vocali alle barre Braille, dai computer palmari ai robot di ricerca, dai telefoni cellulari agli ingranditori di schermo usati dagli ipovedenti.

Ecco alcuni dei metodi che le WCAG 1.0 raccomandano per raggiungere questa necessaria flessibilità:

• separare la struttura dalla presentazione del documento (vedremo in seguito che cosa significa)
• fornire equivalenti testuali per i contenuti grafici e multimediali
• creare alternative equivalenti per i contenuti che si rivolgono ad un solo canale sensoriale (la vista o l'udito)
• non progettare per uno specifico tipo di hardware
• non affidare le informazioni esclusivamente al colore

I metodi raccomandati per il raggiungimento del secondo obiettivo - cioè rendere i contenuti comprensibili e navigabili - sono invece i seguenti:

• fornire informazioni contestuali e di orientamento
• fornire chiari meccanismi di navigazione
• rendere i documenti il più possibile chiari e semplici

Come è facile comprendere, se è vero che la maggior parte dei metodi suggeriti dalle WCAG 1.0 per raggiungere l'accessibilità riguardano interventi tecnici sul codice, i rimanenti metodi richiedono invece competenze che esulano da quelle tipiche degli sviluppatori e coinvolgono piuttosto quelle del responsabile editoriale e dell'esperto di usabilità.

A nostro parere uno dei limiti principali delle WCAG 1.0 sta proprio nel non aver messo in luce adeguatamente la profonda diversità che esiste tra i tipi di intervento mirati a rendere flessibile la struttura della pagina e quelli mirati, invece, a rendere i contenuti accessibili dal punto di vista cognitivo, concettuale. La scarsa rilevanza data alla suddetta differenza ha prodotto una dannosa conseguenza: nell'opinione comune, il raggiungimento dell'accessibilità è diventata una mera questione di lavoro sul codice, e come tale ritenuta completamente alla portata dello sviluppatore, del tecnico.

Ciò ha prodotto un'ulteriore distorsione: scambiare il superamento di un test automatico effettuato da appositi software - come per esempio il notissimo Bobby sul sito Watchfire - con il raggiungimento tout court dell'accessibilità.

Si tratta di un errore gravissimo, di una vera e propria presa in giro ai danni di chi dovrebbe trar giovamento dall'utilizzare le pagine rese in questo modo "accessibili". Tanto per fare un esempio pratico, è possibile ottenere il bollino "Bobby approved" - e fregiarsene pubblicamente come a dichiarare di aver raggiunto una piena accessibilità - dopo aver riempito le proprie pagine di attributi "alt" con valori del tutto non adeguati alle immagini a cui sono associati (per es. "foto 1", "foto 2", "foto 3", ecc., sono valori di "alt" che non dicono nulla sul contenuto delle relative immagini). In tutti i casi simili, l'esposizione del bollino dichiara una pretesa accessibilità che non corrisponde affatto all'accessibilità effettiva della pagina.

La colpa di ciò non è però di Bobby (o di altro programma analogo), ma dello sviluppatore superficiale: il programma avverte infatti chi effettua il test che l'esposizione del bollino va subordinata al superamento di tutti i controlli sulla pagina che non è possibile effettuare automaticamente. Controlli - come quello sulla significatività dei testi alternativi - che solo un essere umano esperto può compiere. Ma quanti sviluppatori si preoccupano effettivamente di portare a termine simili controlli? E con quali metodi poi? Molto spesso ci si limita purtroppo a considerare concluso il lavoro sull'accessibilità, non appena Bobby segnala che i controlli automatici sulla pagina sono stati superati.

Contrastare il pregiudizio che il raggiungimento dell'accessibilità sia solo una questione di lavoro sul codice è uno degli obiettivi principali di questa guida.