Il primo requisito - Webaccessibile.org

Nel dicembre 2004 i gruppi di lavoro 1 “Metodologia” e 2 “Regole tecniche” della Segreteria tecnico-scientifica della Commissione Interministeriale permanente per l’impiego delle ICT a favore delle categorie deboli o svantaggiate del CNIPA, hanno rilasciato la terza versione dello “studio sulle linee guida recanti i requisiti tecnici e i diversi livelli per l’accessibilità e le […]

Nella parte riguardante la verifica tecnica obbligatoria è stato inserito come primo punto fondamentale il seguente requisito:

“Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico.”

Questo requisito ha ricevuto diverse critiche di non chiarezza o di non necessità per le tematiche riguardanti l’accessibilità, ma cerchiamo di capire cosa implica realmente e su cosa si fonda.

A chi si applica?

Il requisito si applica a tutte le pubbliche amministrazioni per tutti i beni e servizi internet rientranti nella legge 04/2004.

Questo requisito non si applica solo alle normali pagine HTML ma a qualunque risorsa basata sul web, sia in area pubbliche che riservate, richiedendo che queste ultime vengano fornite unicamente seguento grammatiche formali ufficialmente pubblicate.

Quindi non si possono realizzare pagine o oggetti web senza dichiararne la conformità a qualche specifica, anche se implicita come per i file Adobe Acrobat o Microsoft Word.

Conformità alle grammatiche formali?

Una grammatica formale in informatica non è nient’altro che una specifica o una raccomandazione tecnica definita o in linguaggio naturale (documentazione) oppure in un linguaggio di definizione come una DTD SGML oppure un XML Schema.

La conformità varia a dipendenza del tipo di definizione. Se per esempio prendiamo una normale pagina web che è definita in HTML o XHTML, la sua definizione è un file DTD.

Questo file DTD ci fornisce ufficialmente le seguenti informazioni:

Qual è l’elemento di partenza del documento (HTML)
Quali elementi esistono
Qual è lo scopo di ogni elemento e quando deve essere usato
Quali elementi possono essere annidiati sotto quali elementi, nonché quante volte possono occorrere
Quale tipo di contenuto e in che forma può essere inserito all’interno degli elementi
Quali attributi esistono
Qual è lo scopo di ogni attributo e quando deve essere usato
Quali attributi possono essere inseriti in quali elementi
Quali valori e in che forma possono prendere i vali attributi

Alcuni punti come lo scopo di ogni elemento o attributo è riaffermato poi esplicitamente nella frase conclusiva della regola tecnica.

In caso adottassimo un linguaggio dove la sua definizione è formalizzata in XML Schema, come per esempio RSS, avremmo molte informazioni in più come i limiti di occorrenza oppure eventuali spazi logici dei nomi.

Infine se adottassimo una tecnologia definita descritta solo in linguaggio naturale dovremmo semplicemente seguire le direttive in essa definite, questo vale per esempio per le specifiche di accessibilità dei documenti Acrobat dell’Adobe o Word della Microsoft.

Versioni più recenti disponibili quando sono supportate dai programmi utente?

La richiesta di adottare sempre le versioni più recenti disponibili quando supportate dai programmi utenti, riporta direttamente il suo significato all’evoluzione degli standard e delle raccomandazioni tecniche che di fatto appena vengono supportate dalla maggior’parte dei programmi utente (come i browser) andrebbero adottate per le nuove risorse web prodotte.

Il CNIPA con la possibilità di aggiornare annualmente il decreto segnalerà quali versioni di un determinato formato o linguaggio sono considerate supportate dai programmi utente.

Come si verifica?

La verifica e la validazione di una risorsa web come una pagina HTML trova un valido supporto nei validatori automatici forniti dai vari enti di normalizzazione o raccomandazione come il W3C, che però ricorda come questi strumenti siano solo di supporto.

Per esempio, il validatore HTML del W3C è in grado di effettuare solo un controllo sull’annidiamento corretto degli elementi e sull’uso dei relativi attributi ma non sul corretto uso semantico e logico degli elementi nonchè sui valori inseriti negli elementi o attributi che andranno dunque verificati manualmente.

Oltre a questo l’HTML come moltri altri linguaggi può subire ulteriori trasformazioni in corso di elaborazione tramite linguaggi come javascript e DOM oppure XSL, questo ci porta a non basare la nostra validazione sul file HTML sorgente ma sul risultato finale dopo che tutte le trasformazioni sono state eseguite.

Questo ci mostra una realtà frequentemente proposta recentemente che vuole sfruttare le potenzialità di javascript e DOM, in maniera non consona, per effettuare modifiche in tempo reale alla struttura XHTML memorizzata nel browser (l’Object Model) inserendogli elementi o attributi non permessi nella DTD.

Due esempi pratici di questa tecnica si sono visti recentemente.

Il primo è un javascript che inserisce automaticamente l’attributo “target” nelle pagine, permettendo così di far generare nuove finestre mantenendo la validità del codice.

Il secondo è invece la tecnica sIFR che inserisce automaticamente su alcuni testi dei filmati flash accessibili, utilizzando però elementi e attributi non validi secondo la DTD.

Entrambe queste tecniche sono considerate violanti il requisito 1.

Per le pagine perchè HTML o XHTML Strict?

La scelta di richiedere un linguaggio nella versione strict deriva semplicemente dal fatto che le versioni transitional delle specifiche in realtà non sono ufficiali.

Le uniche versioni ufficiali di specifiche o raccomandazioni sono quelle considerate “pure” che corrispondono alle versioni strict.

Ma il codice ha influenza sull’accessibilità?

Una domanda che ci si è posti molto spesso sul requisito 1 e se effettivamente il codice ha una reale influenza sull’accessibilità.

La risposta è “in parte”.

Il codice HTML o XHTML in tutte le sue forme e attributi permette una completa frammentizzazione dei vari tipi di contenuto all’interno delle pagine con gli attributi necessari per un completo trattamento degli stessi contenuti.

Questa moltitudine di attributi non è direttamente relazionata con l’accessibilità ma per HTML e XHTML il W3C si è trovato di fronte ad una scelta.

Infatti non vi è prova scientifica che l’uso di alcuni elementi migliori l’accessibilità, ma siccome non si è a conoscenza di tutti i programmi utente sul mercato non si può neanche affermare il contrario.

Dunque la scelta fatta internazionalmente da tutti gli enti normatori in materia è quella di stabilire che un codice completamente valido e ricco di elementi e attributi semanticamente corretti è il requisito base per l’ accessibilità.

L’Unione Europea ha poi subito recepito e accettato questo requisito (sia implicitamente sia nei suoi gruppi di lavoro) chiedendo ai propri membri che nella formalizzazione delle singole leggi nazionali fosse inserito come requisito di accessibilità.

In conclusione

Un buon codice correttamente strutturato e ricco di elementi e attributi per la tipizzazione e la semanticizzazione dei contenuti permette un infinito trattamento dei contenuti da parte dei programmi utente che potranno così adattarsi e configurarsi sulla base dei vari tipi di disabilità.

Dunque la validità formale (non automatica) del codice e l’aderenza ad una raccomandazione internazionalmente riconosciuta è il primo punto per iniziare ad applicare correttamente l’accessibilità.