Dopo aver letto le sedici regole definite dall’Agenzia federale per l’accesso, viene naturale domandarsi quale sia la loro relazione con le Linee Guida per l’Accessibilità del contenuto Web versione 1.0 (WCAG, Web Content Accessibility Guidelines 1.0), rilasciate il 5 maggio del 1999 come standard internazionale dal Gruppo WAI del W3C.

Tra le due formulazioni vi sono numerose somiglianze ma anche importanti differenze. A questo proposito, una nota alle sedici regole federali per l’accessibilità del Web dice testualmente:

1. L’Agenzia interpreta i paragrafi da (a) fino a (k) di questa sezione come compatibili con i seguenti punti di controllo di priorità 1 delle Linee Guida per l’Accessibilità del contenuto Web versione 1.0 (WCAG 1.0, 5 Maggio 1999), pubblicate dalla Web Accessibility Initiative del World Wide Web Consortium:

Paragrafi della sezione 1194.22 Punti di controllo WCAG 1.0
(a) 1.1
(b) 1.4
(c) 2.1
(d) 6.1
(e) 1.2
(f) 9.1
(g) 5.1
(h) 5.2
(i) 12.1
(j) 7.1
(k) 11.4

2. I paragrafi (l), (m), (n), (o) e (p) di questa sezione differiscono da WCAG 1.0. Le pagine Web che sono conformi al livello A di WCAG 1.0 (che passano cioè tutti i punti di controllo di priorità 1) devono soddisfare anche i paragrafi (l), (m), (n), (o) e (p) di questa sezione per guadagnare la conformità.

In particolare, le regole dell’articolo 508 introducono differenze significative per quanto riguarda la gestione di script, applet e programmi accessori integrati; sono più restrittive circa lo sfarfallamento dello schermo e fanno riferimento al problema della risposta temporizzata, del tutto assente dalle linee guida WAI-W3C.

D’altro canto le Linee Guida WAI pongono tra i requisiti per l’accessibilità la segnalazione di qualsiasi cambiamento di linguaggio naturale nel testo (per mezzo di <span lang="..."></span>) e l’uso del più chiaro e semplice linguaggio appropriato al contesto: due criteri che nelle regole per il Web elencate sotto l’articolo 508 sono completamente assenti.

Insomma la piena conformità alle sedici linee guida federali non coincide con la piena conformità alle raccomandazioni WCAG 1.0 del WAI: aver raggiunto la prima non è garanzia di ottenere la seconda, e viceversa. A complicare ulteriormente le cose, vi sono poi dei punti di divergenza che rendono in certi casi materialmente impossibile soddisfare entrambe le formulazioni, in quanto l’obbedienza ad una delle due esclude di poter obbedire all’altra.

Mi riferisco in particolar modo ad un caso molto comune ed importante: la gestione delle funzionalità introdotte nelle pagine web per mezzo di linguaggi di script, applet ed oggetti di programmazione. Il punto di controllo 6.3 delle WCAG 1.0 dice testualmente (la traduzione è mia, da http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-scripts):

Assicuratevi che le pagine siano usabili quando script, applet o altri oggetti di programmazione siano disabilitati o non supportati. Se questo non è possibile, fornite informazioni equivalenti su una pagina alternativa accessibile. [Priorità 1]

Non considerando per ora applet ed oggetti di programmazione, a proposito degli script il paragrafo (l) delle norme federali dichiara:

Quando delle pagine utilizzano linguaggi di script per visualizzare contenuti, o per creare elementi dell’interfaccia, le informazioni fornite per mezzo dello script devono essere identificate tramite del testo funzionale che possa essere letto usando tecnologie assistive.

La differenza sembra inconciliabile. Per le WCAG 1.0 il contenuto informativo generato dallo script deve essere accessibile (tramite testi alternativi) anche per mezzo di programmi che non supportano gli script o che ne hanno disabilitato il supporto, anche se poi lo script in se stesso non genera testo funzionale leggibile per mezzo di tecnologie assistive. Per il paragrafo (l) di Section 508 basta invece che si generi un testo funzionale che sia possibile leggere per mezzo di tecnologie assistive e non occorre produrre un’alternativa per utenti che non possano o non vogliano usare sistemi abilitati a gestire linguaggi di script.

Presumo che la ragione per cui le regole federali si differenziano, almeno su questo punto, dalle norme WAI-W3C sia che in queste ultime il tentativo di raggiungere la piena conformità porta a delle vere e proprie contraddizioni in termini, come quella che mi pare esistere tra i punti di controllo 6.3 ed 8.1 (1). Esaminare tali contraddizioni va però oltre gli scopi di questo articolo.

Per ora accontentiamoci di una piccola morale: non diamo molto credito a quei siti che dichiarano la doppia conformità, da un lato al dettato dell’ articolo 508 emendato del Rehabilitation Act e, dall’ altro, alle Linee Guida versione 1.0 del WAI. Vi sono circostanze abbastanza comuni nella realizzazione di pagine web che richiedono di scegliere quale delle due conformità adottare, essendo molto probabile che la scelta di una delle due precluderà il raggiungimento dell’altra.

Ma in conclusione dobbiamo anche chiederci: le divergenze, tra il dettato delle WCAG 1.0 e quanto prescritto dalle norme federali sull’accessibilità del contenuto Web, hanno ricadute pratiche significative per gli sviluppatori italiani di siti? Direi di no, almeno per il momento. Deve essere chiaro, infatti, che le regole definite sotto il titolo 1194.22 di Section 508 riguardano esclusivamente gli acquisti di applicazioni e contenuti per il Web da parte di agenzie federali statunitensi.

Per il resto del mondo – e quindi anche per le Pubbliche Amministrazioni italiane che volessero rendere accessibili i propri siti Internet – valgono le regole definite in WCAG 1.0, pur con i limiti e le contraddizioni che queste, ad un esame approfondito, finiscono con il rivelare. Sicuramente la versione 2.0 delle WCAG, attualmente allo stato di bozza di lavoro, dovrà tenere conto di tali contraddizioni e magari provare ad incorporare il meglio dell’esperienza scaturita, nel frattempo, dall’applicazione delle regole per l’accessibilità del Web conosciute come Section 508.

(1) 8.1. Rendete gli elementi di programmazione come script e applet direttamente accessibili o compatibili con le tecnologie assistive [Priorità 1 se la funzionalità è importante e non è presentata altrove, altrimenti Priorità 2.]