Tempi di rinnovamento per l’accessibilità dei siti. Sarà l’effetto WCAG 2.0, sarà che dal Decreto Ministeriale 8 luglio 2005 son passati un po’ di anni e l’effetto moltiplicatorio per Web e tecnologie, è noto, funziona un po’ come l’età dei gatti e il decreto oggi appare un po’ vecchierello, insomma sia quel che sia un nutrito e ben congegnato gruppo di lavoro sta ridisegnando quelli che vengono definiti “i requisiti” fondamentali dei siti Web della P.A. affinché gli stessi possano essere definiti a norma della Legge 04/2004 (Stanca).
Inoltre, sotto il cappello del Formez è stato costituito un laboratorio, se così si può dire, denominato “Osservatorio Accessibilità” con compiti sia di analisi sia di supporto agli sviluppatori. Insomma, un bel traffico.
Nel periodo precedente, ho usato la forma “a norma” perché c’è un po’ di confusione sui termini “accessibile” e “a norma Stanca”.
La legge Stanca non è l’unica normativa di riferimento sull’accessibilità esistente sul pianeta. Gli Stati Uniti possiedono da tempo la Section 508, la mamma di tutte le normative sull’accessibilità (anche lei in revisione), le già citate WCAG del W3C (in questo caso non si tratta di una legge, ma di “raccomandazioni“, l’Australia possiede una propria legislazione, il Canada anche, così come la Francia, il Giappone e l’Irlanda (un elenco è disponibile all’URL http://www.w3.org/WAI/Policy/).
Tornando alla precedente affermazione, non è detto che un sito “a norma Stanca” corrisponda a un sito “WCAG compatibile”, o conforme alla Section 508, mentre tutti possono essere detti accessibili. L’obiettivo di tutte queste leggi e raccomandazioni è comune, ovvero ottenere l’accessibilità dei siti Web, e tutte si basano su Section 508 e WCAG per formulare le proprie richieste. Però, ciascuna normativa ha anche caratteristiche proprie (per esempio, la legge Stanca richiede l’uso di una DTD Strict, mentre le WCAG no). Probabilmente le WCAG 2.0. faranno da elemento collante e tutte le normative cercheranno di adeguarsi ai nuovi requisiti proposti dal W3C.
È un bene o un male? Non lo so, personalmente trovo le WCAG 2.0 ottime nei principi ma un po’ scarse nelle tecniche proposte (francamente, in qualche caso davvero di basso livello). Si potebbe obbiettare “Sì, d’accordo, ma l’accessibilità non riguarda gli standard, si occupa esclusivamente di proporre delle tecniche che rendano accessibili le pagine”.
D’accordo, ma propongo un esempio credo significativo per chiunque si occupi di accessibilità. Fra gli elementi più importanti per la navigazione delle pagine ci sono i titoli, gli header di cui molto abbiamo parlato su questo blog. È un elemento indiscutibile, chiunque abbia provato a navigare delle pagine con uno screen reader si sarà reso conto della fontamentale importanza dell’uso di una struttura corretta per delineare i contenuti delle pagine, e di come sia importante utilizzare in modo congruente ai contenuti gli elementi da <h1> a <h6>.
Ebbene, proprio su un argomento così basilare nelle “HTML e XHTML Techniques” è presente un esempio così fatto:
<head> <title>Stock Market Up Today</title> </head> <body> <!-- left nav --> <div class="left-nav"> <h2>Site Navigation</h2> <!-- content here --> </div> <!-- main contents --> <div class="main"> <h1>Stock Market up today</h1> <!-- article text here --> </div> <!-- right panel --> <div class="left-nav"> <h2>Related links</h2> <!-- content here --> </div> </body>
Rieccoci da capo. La pagina inizia con un <h2>, si passa a <h1> e si torna a <h2>. Non mi pare un bell’esempio.
Per questo e altri motivi mi piacerebbe che i nuovi requisiti della Stanca mantenessero l’intrinseca richiesta di pulizia e semantica, si semplificassero nella forma e facessero esplicito riferimento alle best practice più affermate. Personalmente trovo inaccettabile che sia per la Stanca sia per le WCAG una barra di navigazione fatta a colpi di <div> e <br /> possa essere dichiarata “accessibile”.
Per qualsiasi sviluppatore appena sensato gli elementi da utilizzare per le barre di navigazione sono <ul> e <li> per le voci, magari facendo precedere alla barra un titolo esplicito utilizzando l’elemento <hn> opportuno.
Insomma, mi piacerebbero dei requisiti un po’ meno “saputelli” e un po’ più di senso pratico, per esempio prendendo spunto anche dall’elenco di Best Practice dell’iCITA (Illinois Center for Information Technology and Web Accessibility) utilizzate dal “Functional Accessibility Evaluator 1.0.2” dell’ University of Illinois at Urbana-Champaign.
Biroblu 