Dal 2010 (aggiornate annualmente) sono state emanate delle linee guida, previste dall’art. 4 della Direttiva del Ministro per la pubblica amministrazione e l’innovazione 26 novembre 2009, n. 8, al fine di suggerire alle pubbliche amministrazioni criteri e strumenti per la riduzione dei siti web pubblici obsoleti ed il miglioramento di quelli attivi, in termini di principi generali, gestione e aggiornamento, contenuti minimi.

I siti Web sono il mezzo primario di comunicazione, il più accessibile e meno oneroso, attraverso cui le Pubbliche amministrazioni devono:

• garantire un’informazione trasparente ed esauriente sul loro operato;
• promuovere nuove relazioni con i cittadini, le imprese e le altre PA;
• pubblicizzare e consentire l’accesso ai propri servizi;
• consolidare la propria immagine.

Essi devono offrire all’utenza cui si rivolgono servizi, sia di tipo informativo che transazionale, rispondenti a caratteristiche di qualità sinteticamente esprimibili in:

• accertata utilità;
• semplificazione dell’interazione tra amministrazione ed utenza;
• trasparenza dell’azione amministrativa;
• facile reperibilità e fruibilità dei contenuti;
• costante aggiornamento.

Con la sezione qualità, l’Osservatorio vuole fornire al cittadino lo strumento di segnalazione in relazione a criticità riguardo ai contenuti obbligatori previsti per i siti istituzionali dalle vigenti disposizioni in materia di qualità, trasparenza amministrativa e codice amministrazione digitale. Di seguito vengono esposte le voci presenti nell’apposita sezione del portale con una breve spiegazione.

Progetti conclusi con contenuti non più aggiornati

Si tratta di siti web dedicati a specifiche iniziative che restano online a progetto concluso e, nonostante la perdita di interesse a consultarli da parte del cittadino, generano costi di gestione impropri.

Precisione delle informazioni

Una pubblica amministrazione deve garantire che le informazioni pubblicate all’interno dei siti Web siano precise ed aggiornate. Il comma 4 dell’art. 54 del Decreto legislativo 7 marzo 2005 n. 82 “Codice dell’Amministrazione digitale” (CAD) prevede che “Le pubbliche amministrazioni garantiscono che le informazioni contenute sui siti siano conformi e corrispondenti alle informazioni contenute nei provvedimenti amministrativi originali dei quali si fornisce comunicazione tramite il sito”. Si consiglia, ad esempio, di evitare la pubblicazione di contenuti provenienti da altri siti, prevedendo invece un collegamento ipertestuale (link) alla risorsa informativa (esempio: fornire un collegamento alla pagina degli orari dei servizi pubblici anziché copiare la tabella orari nel proprio sito Web).

Aggiornamento dei contenuti

L’utente deve poter conoscere lo stato di aggiornamento dei contenuti di un sito Web, ovvero comprendere se l’informazione pubblicata è aggiornata e vigente oppure se si tratta di un archivio storico di contenuti. Si raccomanda, visto quanto previsto dal già citato comma 3 dell’art. 54 del CAD, di definire procedure di controllo dei contenuti (c.d. content audit) e di definizione dei bisogni, nonché di applicare regole di aggiornamento continuo. In particolare, occorre:

• controllare e aggiornare periodicamente i contenuti soggetti a obsolescenza;
• evidenziare elementi informativi relativi alla effettiva validità del singolo contenuto (data di pubblicazione di una notizia, vigenza di una norma, scadenza di un provvedimento, ecc.);
• evidenziare la data di pubblicazione dell’informazione;
• monitorare gli accessi e verificare la rispondenza dei contenuti/servizi alle aspettative degli utenti, anche attraverso strumenti semplici (come nel caso del progetto “Mettiamoci la faccia”).

Ridondanza dei contenuti

Va evitata la duplicazione di informazioni, che siano presenti sullo stesso sito o su aree diverse dello stesso sito o su siti tematici della stessa amministrazione, al fine di non replicare lo stesso contenuto né i relativi aggiornamenti.

Recapiti URP non disponibili

L’Ufficio relazioni con il pubblico (URP) reso obbligatorio dalla Legge n. 150/2000, ha l’obiettivo di agevolare i rapporti tra ente pubblico e cittadini, garantendo il diritto d’accesso agli atti e favorendo la trasparenza amministrativa. Allo scopo di favorire il reperimento delle modalità di contatto da parte del cittadino (nominativo degli addetti a cui rivolgersi, indirizzo, telefono, email, orari, ecc.), le informazioni relative all’URP devono essere indirizzate dall’etichetta “URP” o “Ufficio relazioni con il pubblico” e facilmente raggiungibili fin dalla home page.

Indirizzo PEC istituzionale non disponibile

Il codice dell’amministrazione digitale, all’articolo 3 sancisce il diritto dei cittadini all’uso delle nuove tecnologie per comunicare con la pubblica amministrazione. Gli enti locali e nazionali devono perciò dotarsi di strumenti adeguati, come appunto la Posta elettronica certificata e la firma digitale, per permettere alla collettività di accedere per via telematica ai loro servizi.

Ai sensi del comma 2-ter, dell’art. 54 del CAD le amministrazioni pubbliche sono tenute a pubblicare nel loro sito istituzionale un indirizzo di posta elettronica certificata (PEC) al quale il cittadino possa indirizzare, ai sensi dello stesso codice, qualsiasi richiesta. “Tale indirizzo deve essere costantemente disponibile all’interno della testata ovvero collocato in posizione privilegiata per visibilità nella home page del sito”.

Sezione Trasparenza, valutazione e merito assente o incompleta

Le amministrazioni pubblicano, ai sensi del Decreto legislativo 150/2009, e secondo quanto indicato dalla Delibera CiVIT n.105/2010 e dalle Linee guida del Garante per la Privacy del 2 marzo 2011, in un’apposita sezione sulla homepage dei siti istituzionali, identificata tramite l’apposito logo e denominata “Trasparenza, valutazione e merito”, una serie di informazioni:

1. Programma triennale per la trasparenza e l’integrità e relativo stato di attuazione (art. 11, comma 8, lettera a), del Decreto legislativo n. 150 del 2009);
2. Piano e Relazione sulla performance (art. 11, comma 8, lettera b), del Decreto legislativo n. 150 del 2009);
3. Dati informativi sull’organizzazione e i procedimenti;
4. Dati informativi relativi al personale;
5. Dati relativi a incarichi e consulenze;
6. Dati sulla gestione economico-finanziaria dei servizi pubblici;
7. Dati sulla gestione dei pagamenti;
8. Dati relativi alle buone prassi;
9. Dati su sovvenzioni, contributi, crediti, sussidi e benefici di natura economica.

Per una indicazione puntuale dell’organizzazione e dei contenuti della Sezione Trasparenza, valutazione e merito si rimanda alla Delibera CiVIT n.105/2010.

Organigramma non disponibile o incompleto

L’organigramma è essenziale per consentire al cittadino di poter identificare il corretto referente per le proprie necessità. In particolare, sempre ai sensi dell’art. 54 del CAD l’organigramma deve contenere:

• l’articolazione e le attribuzioni, anche in termini di procedimenti amministrativi di competenza, dei singoli uffici di livello dirigenziale generale e non;
• i nomi dei dirigenti responsabili dei singoli uffici;
• il settore dell’ordinamento giuridico riferibile all’attività svolta;
• per ogni dirigente responsabile di un ufficio:
• riferimenti telefonici;
• riferimenti posta elettronica;
• riferimenti posta elettronica certificata.

Elenco indirizzi e-mail non disponibile

La posta elettronica o e-mail è il mezzo di comunicazione in forma scritta via Internet più utilizzato; consente con estrema velocità ed immediatezza di inviare messaggi che possono includere testo, immagini, audio, video o qualsiasi tipo di file, con il vantaggio, rispetto al telefono, di poter raggiungere il destinatario in asincrono lasciando traccia delle richieste.

Le caselle di posta elettronica possono essere distribuite ad personam o essere associate ad un ufficio o ad una specifica funzione.

Sempre ai sensi dell’art. 54 del CAD sui siti istituzionali deve essere pubblicato l’elenco delle caselle di posta elettronica attive, specificando per ciascuna casella:

• nome e cognome del dipendente destinatario o titolo dell’ufficio destinatario o descrizione della funzione cui la casella è riservata;
• se si tratta di casella di posta elettronica certificata.

L’elenco deve essere corredato dall’informativa sulle finalità della pubblicazione dell’elenco stesso e sulle conseguenti limitazioni d’uso.

Elenco procedimenti amministrativi non disponibile o incompleto

In coerenza con quanto previsto dal citato art. 54 del CAD, i siti istituzionali devono contenere l’elenco dei procedimenti amministrativi di competenza dell’Amministrazione titolare del sito e per ciascuno indicare:

• l’ufficio dirigenziale non generale cui compete il procedimento ed il relativo responsabile;
• il termine per la conclusione del procedimento;
• l’unità organizzativa responsabile dell’istruttoria, di ogni altro adempimento procedimentale e dell’adozione del provvedimento finale;
• le scadenze e le modalità di adempimento dei procedimenti.

L’elenco va correlato alle sezioni informative sui procedimenti ed a quelle di distribuzione della modulistica e servizi on line.

Sezione Documentazione / Modulistica assente o incompleta

Ai sensi dell’art 57 del CAD, le pubbliche amministrazioni non possono richiedere ai cittadini l’uso di moduli e formulari che non siano stati pubblicati. In caso di mancata pubblicazione, i procedimenti possono essere avviati senza la presentazione del modulo/formulario.  La mancata pubblicazione è altresì rilevante ai fini della misurazione e valutazione della performance individuale dei dirigenti responsabili.

Le pubbliche amministrazioni provvedono a definire e a rendere disponibili per via telematica l’elenco della documentazione richiesta per i singoli procedimenti, i moduli e i formulari validi ad ogni effetto di legge, anche ai fini delle dichiarazioni sostitutive di certificazione e delle dichiarazioni sostitutive di notorietà.

Sezione Bandi di gara, concorsi, bilanci assente o incompleta

Un sito istituzionale è il luogo deputato per dare massima diffusione alle iniziative delle Amministrazioni relative a bandi di gara e di concorso e favorire, in questo modo, la partecipazione allargata e la leale concorrenza.

Il bando di gara è un atto della pubblica amministrazione con il quale viene esternata e pubblicizzata la determinazione di contrarre attraverso un confronto competitivo. Può essere riferito alla acquisizione di beni e servizi, all’assegnazione di contributi per iniziative, alla concessione di finanziamento per progetti.

Il concorso è la procedura con la quale una Amministrazione provvede a reclutare il personale. Rientrano in questo ambito anche le procedure di selezione o i concorsi per l’assegnazione di borse di studio o premi quando destinati a persone.

L’obbligo alla pubblicazione dei bandi di gara e di concorso è stabilito dall’art. 54, comma 1, del CAD.

Gli elenchi dei bandi di gara, concorsi, bilanci devono essere raggiungibili dalla home page del sito indirizzati dalle etichette “Bandi di gara”,”Concorsi”, “Bilanci”.

Per quanto riguarda il dettaglio sulle sezioni bandi di gara e bilanci, si deve comunque far riferimento al DPCM del 26 aprile 2011 relativo alla pubblicazione nei siti informatici di atti e provvedimenti concernenti procedure ad evidenza pubblica o di bilanci adottato ai sensi dell’art.32 della Legge n. 69 del 2009.

Sezione Pubblicità legale (Albo Pretorio) assente o incompleta

Con la pubblicità legale un atto amministrativo assume piena validità in quanto portato a conoscenza di tutti coloro che possono avere interesse al contenuto dell’atto medesimo. La pubblicazione avviene attraverso l’esposizione dell’atto in un luogo fisico accessibile a tutti per un determinato periodo di tempo, il “tempo di affissione”.

L’art. 32 della Legge n 69/2009, dal 1 gennaio 2011, ha stabilito che “gli obblighi di pubblicazione di atti e provvedimenti amministrativi aventi effetto di pubblicità legale si intendono assolti con la pubblicazione, da parte delle amministrazioni e degli enti pubblici obbligati, nei propri siti informatici, o nei siti informatici di altre amministrazioni ed enti pubblici obbligati, ovvero di loro associazioni”.

Per ottemperare alla citata norma, i siti istituzionali debbono prevedere una sezione dedicata alla pubblicità legale all’interno della quale debbono essere pubblicati, organizzati per tipologia, gli atti di competenza soggetti a pubblicità legale.

Il servizio di consultazione della pubblicità legale deve essere raggiungibile dalla home page del sito e deve essere chiaramente indirizzato da un’etichetta esplicativa del tipo “Pubblicità legale” ovvero, per gli enti territoriali, “Albo pretorio” o “Albo pretorio on line”.

Sezione Elenco servizi assente o incompleta

L’accesso ai servizi on line deve essere disponibile sulla barra di navigazione del sito o in ogni caso sulla home page del sito in posizione massimamente visibile identificato dall’etichetta “Servizi on line”. L’obbligo alla pubblicazione sui siti istituzionali dell’elenco dei servizi on line già disponibili e dei servizi di futura attivazione è stabilito dal citato art. 54, comma 1, del CAD.

Sezione Informativa privacy / Note legali assente o incompleta

Nella sezione “Privacy” devono essere descritte le modalità di gestione del sito in riferimento al trattamento dei dati personali e degli utenti che interagiscono con i servizi resi disponibili. Si tratta di una informativa da rendere ai sensi del Decreto legislativo 30 giugno 2003, n. 196 “Codice in materia di protezione dei dati personali”. Nel predisporre l’informativa si raccomanda di considerare:

• tipi di dati trattati distinguendo tra:
• dati di navigazione
• dati forniti volontariamente dall’utente
• cookies
• diritti degli interessati

Va fatto presente che la violazione delle disposizioni di cui all’articolo 13 del citato decreto è punita con la sanzione amministrativa del pagamento di una somma da seimila euro a trentaseimila euro.

Sezione Elenco siti tematici assente o incompleta

Al fine di consentire al cittadino di poter consultare i servizi web erogati dalle PA, è necessario fornire un elenco dei siti tematici afferenti all’amministrazione.

I siti tematici pubblici debbono riportare nel piè di pagina una sezione informativa indirizzata dall’etichetta “Informazioni sul sito” con i seguenti contenuti:

• Amministrazioni responsabili: indicazione delle Amministrazioni, una o più, che hanno realizzato il sito e che lo gestiscono, aggiornandolo;
• Finalità del sito: sintetica descrizione delle finalità del sito con il riferimento alle norme, ai protocolli d’intesa, al progetto o all’iniziativa che ne hanno determinato o reso opportuna la realizzazione;
• Frequenza di aggiornamento dei contenuti: descrizione dei motivi, delle modalità e dei tempi previsti per l’aggiornamento dei contenuti;
• Periodo di validità del sito: segnalazione della data eventualmente prevista per la chiusura del sito;
• Informativa sulla privacy.

• la disponibilità di informazioni chiare, aggiornate, complete e facilmente fruibili sull’organizzazione, le sue attività, i programmi e i servizi
• la disponibilità di servizi on line sempre più numerosi, transattivi, interconnessi.

Le linee guida per la comunicazione Web regionale sono il frutto di un percorso cominciato nel 2010 con il censimento dei siti web della Regione Emilia-Romagna, con l’obiettivo di mappare motivazioni, caratteristiche tecniche e comunicative, dati di accesso, costi di realizzazione e gestionali, e con la successiva Delibera di Giunta 1394/2010 con cui è stato avviato un percorso di riorganizzazione della comunicazione web regionale.

Allegato: Razionalizzazione della comunicazione su Web Emilia Romagna, PDF, 448 Kb

La verifica ha lo scopo di agevolare l’individuazione e la risoluzione dei problemi di accessibilità nei file, ed è basata su regole condivise da WCAG 2 e normativa corrente (alle immagini è associato o meno un testo alternativo, nelle tabelle sono presenti intestazioni per le colonne, le diapositive possiedono almeno un titolo, e così via).

Verifica Accessibilità al lavoro su un documento Word

1. Per accedere a Verifica accessibilità, selezionate File > Informazioni.
2. Nella scheda Informazioni, selezionate Verifica Documento > Verifica accessibilità.

Apertura di Verifica accessibilità.

La finestra di Verifica accessibilità può essere mantenuta aperta anche durante la preparazione del documento, e costituisce così un utile strumento di verifica in tempo reale.
Per ottenere un documento a norma, è necessario seguire sia le indicazioni riportate come Errori sia quelle indicate come Avvisi, e anche i Suggerimenti (per esempio, “I file audio e video inseriti includono sottotitoli codificati” per Verifica accessibilità di Office è un suggerimento, ma per noi un obbligo).
Sul sito dedicato sono disponibili degli interessanti video sottotitolati su questa caratteristica:

Individuazione e risoluzione dei problemi di accessibilità in Word 2010

Controllare l’accessibilità di una presentazione di PowerPoint 2010

Livio Mondini

Problemi di accessibilità dei CMS

I CMS di norma forniscono interfacce che consentono di gestire i contenuti operando in modalità WYSIWYG (quel che vedi è quel che ottieni) con modalità molto simili a quelle dei normali word processor utilizzati negli uffici.  Di fatto, quali sono i problemi di accessibilità dei CMS? Innanzitutto è necessario ricordare che i CMS sono strumenti di sviluppo, e come tali per essere accessibili devono seguire le indicazioni W3C delle ATAG (Authoring Tools Accessibility Guidelines), attualmente disponibili nella versione 1.0 ma in aggiornamento (previsto per il 2012) con particolare attenzione a linee guida specifiche per le interfacce di pubblicazione Web-based. In particolare, i problemi di accessibilità dei CMS possono essere raggruppati nelle seguenti categorie:

• accessibilità del back-end;
• accessibilità dell’editor;
• accessibilità dei contenuti generati dal CMS.

Accessibilità del back-end

Il back-end è l’area di gestione dei contenuti del sito Web alla quale i singoli content manager accedono per gestire i contenuti di propria competenza. Di fatto, si tratta di un’area riservata all’interno di un sito internet o intranet dove l’utente può gestire le operazioni utilizzando un ambiente conosciuto, come il proprio browser. È quindi chiaro che il back-end, essendo formato da un insieme di pagine Web, deve garantire l’accesso anche a persone con disabilità nella fase di gestione e pubblicazione dei contenuti.

Sviluppando, per esempio, un CMS la cui interfaccia sia basata su due frame (si, esistono ancora oggi…), di cui uno contenente i menu e l’altro l’interfaccia operativa, si potrebbero generare difficoltà nella navigazione del sistema agli utenti che utilizzano tecnologie assistive.

Analogamente, ricorrendo a complicati sistemi di navigazione o utilizzando moduli (form) di inserimento dati non accessibili, per esempio privi dell’elemento <label>, si può rendere inaccessibile il sistema a operatori con disabilità di tipo visivo o cognitivo. Anche i sistemi di archiviazione documentale (immagini, allegati, ecc.) dovrebbero essere accessibili e consentire all’utente di selezionare i contenuti da pubblicare in modo facile ed intuitivo ma, purtroppo, in molti casi per poterne comprendere il contenuto è necessario aprire ogni file. I produttori di CMS dimenticano spesso l’accessibilità del back-end (ed in generale delle applicazioni Web), che invece è l’accesso principale alla gestione dei contenuti.

Per la gestione dei contenuti, normalmente i sistemi CMS prevedono che l’inserimento dei dati avvenga tramite moduli (form) predefiniti che consentono di compilare i diversi campi richiesti dall’argomento. Nel caso di moduli di inserimento molto lunghi o complessi, è consigliabile utilizzare un sistema di aiuto nella pubblicazione dei contenuti. In questo caso si utilizza un sistema definito wizard, che consente guidare l’utente passo dopo passo durante l’inserimento dei dati. I moduli di inserimento di tipo wizard devono contenere:

• la posizione attuale: utilizzando etichette come “Passo 1 di 3” si informerà l’utente sul numero totale di maschere di inserimento che si dovranno compilare;
• lo scopo del modulo attuale: subito dopo la posizione è necessario indicare lo scopo del modulo corrente. Affiancando una breve descrizione, è possibile fornire ulteriori delucidazioni sulla funzionalità del modulo;
• la barra di navigazione: deve essere possibile poter tornare al passo precedente e passare al passo successivo con comandi semplici (collegamento ipertestuale o pulsante). I collegamenti ai diversi passi dovrebbero prevedere un attributo title per informare l’operatore sul contenuto delle pagine precedente e successiva.

Accessibilità dell’editor

Ogni CMS si basa su un sistema di gestione dei contenuti funzionante in modalità grafica WYSIWYG, in modo da rendere semplice e immediato l’utilizzo da parte dei content manager.
Questo sistema è di fatto un editor integrato al CMS, che può essere:

• un editor proprietario, se sviluppato direttamente dal produttore del CMS ed è integrato allo stesso;
• un’applicazione integrata all’editor prodotta da terze parti (plug-in).

Mentre un editor proprietario garantisce una migliore integrazione con il sistema e la possibilità di gestione completa delle eventuali revisioni dello stesso da parte del produttore, il plug-in implica un maggior grado di aggiornamento dell’editor: potenzialmente, verrà utilizzato da un numero maggiore di utenti e quindi possibili problemi di funzionamento dello stesso verranno individuati più facilmente. È chiaro che lo svantaggio nell’utilizzo dei plug-in di terze parti è legato alla necessità di instaurare rapporti con un ulteriore soggetto (il produttore del plug-in) per quanto riguarda eventuali aggiornamenti del prodotto, senza avere garanzia di piena compatibilità con il CMS.

I problemi comuni di accessibilità di entrambe le soluzioni sono:

• La generazione di codice non valido. Molto spesso gli editor integrati ai CMS non generano codice secondo le grammatiche formali del W3C (requisito 1). Per valutare la qualità dell’editor è sufficiente fare un semplice copia e incolla da un editor di testi (per esempio, Microsoft Word): se il testo incollato contiene tutti gli elementi proprietari del codice Microsoft, allora l’editor non è orientato all’accessibilità.
• La predisposizione dell’editor alla generazione di contenuti accessibili. L’editor deve poter guidare l’utente nella creazione di contenuti accessibili, per esempio obbligando l’inserimento dell’attributo alt per le immagini informative.
• L’accessibilità dell’interfaccia dell’editor. L’interfaccia dell’editor deve essere direttamente accessibile o compatibile con le tecnologie assistive (requisito 17) e quindi permettere la gestione anche tramite tastiera.

Gran parte dei CMS del mondo “open” utilizzano soluzioni come TinyMCE, un editor visuale con avanzate caratteristiche di accessibilità diretta. Va chiaramente detto che tutti questi sistemi necessitano di script per operare e pertanto sono pienamente fruibili solo applicando le WCAG 2.0 (riferimento per l’aggiornamento normativo dei requisiti della legge 4/2004).

Accessibilità dei contenuti generati dal CMS

Il risultato finale delle operazioni di pubblicazione dei contenuti deve essere accessibile. Anche se l’editor  e i contenuti generati rispettano i requisiti di accessibilità, è necessario verificare che le modalità di navigazione del sito e di presentazione dei contenuti (generate dinamicamente dall’interfaccia pubblica del CMS) siano accessibili. Collegamenti ipertestuali incomprensibili e mappe del sito generate dinamicamente possono essere non accessibili e impedire di conseguenza l’accessibilità dei contenuti.

Quali sono quindi i punti per ottenere una conformità dell’interfaccia pubblica del sito Web? La risposta più semplice è chiaramente il rispetto dei requisiti, ma dobbiamo immedesimarci nel “creatore” del CMS, che deve utilizzare i contenuti inseriti dall’utente consentendone una chiara presentazione. Questo significa rispettare soprattutto i seguenti punti:

• Validità formale del documento. La pagina composta da impostazione generale e da contenuti prodotti dal CMS deve rispettare le grammatiche formali e superare quindi la validazione del codice (HTML e CSS). Spesso alcuni CMS generano elementi di apertura e chiusura di pagina anche all’interno dei contenuti, danneggiando la conformità in generale.
• Selezione automatica della lingua. Nei CMS multilingua, devono essere inserite delle procedure che consentono di identificare la lingua del browser utilizzato dall’utente presentando quindi la pagina in modo che sia comprensibile.
• Navigabilità della pagina. La pagina deve essere di facile consultazione. Lo sviluppatore del CMS dovrebbe evitare l’uso di impostazioni di navigazione difficoltose o poco chiare: evitare quindi l’uso di grandi elenchi di collegamenti non chiari è uno dei requisiti fondamentali soprattutto per i grandi portali.
• Interazione con l’utente. I moduli e le modalità di contatto devono essere chiari e semplici, così come il motore di ricerca interno al sito Web deve consentire una rapida individuazione di ciò che l’utente ricerca.

È chiaro quindi che lo sviluppatore del CMS dovrà analizzare tutte le possibilità di pubblicazione offerte dal backoffice per generare una modalità di pubblicazione che consenta di mantenere la conformità.

CMS Open Source e accessibilità: alcuni esempi

Diamo ora uno sguardo ai due CMS open source più diffusi sul mercato internazionale. Un’analisi approfondita di ulteriori CMS è stata svolta dalla Regione Emilia Romagna all’interno del progetto “Linee guida per siti ed applicazioni Web“, di cui si consiglia la lettura.

WordPress

WordPress, sistema oramai promosso a CMS, dichiara di essere accessibile. Sfortunatamente se gli sviluppatori di plug-in o di modelli grafici (template) non applicano la medesima cura nel rispetto della generazione di interfacce (amministrative e pubbliche) accessibili, questa accessibilità viene danneggata. Ci sono moltissimi plug-in e temi per WordPress che consentono invece di incrementare l’accessibilità del sito: l’importante è seguire accuratamente le indicazioni di WordPress per rispettare l’accessibilità.

Drupal

Drupal offre moltissimi collegamenti a risorse utili per integrare funzionalità accessibili nella piattaforma, tra cui un ottimo 
tutorial ed una serie di collegamenti per approfindire la tematica:

• Drupal Accessibility
  Statement
• Accessibility Documentation
• Designing accessibility into
  themes

CMS: iniziative per l’accessibilità

Grazie alla normativa italiana per l’obbligo di accessibilità dei siti Web pubblici, nonché grazie alla diffusione della cultura dell’accessibilità da parte dei produttori di soluzioni applicative (sia open che closed), il tema dei CMS accessibili è stato oramai sdoganato. Per la maggior parte dei CMS open source sono disponibili iniziative specifiche con creazione di moduli specifici per garantire l’accessibilità di interfacce e contenuti.

Un buon esempio arriva anche dal mondo della scuola italiana. Da anni la comunità di Porte aperte sul Web è attiva nel settore dell’accessibilità e della comunicazione istituzionale per gli Istituti e gli Uffici scolastici. A seguito di attivita formative e di collaborazione tra docenti che hanno portato alla pubblicazione di guide e video-guide all’uso di strumenti open source per la pubblicazione di contenuti in Rete, si è notata l’esigenza di supportare la creazione di siti tramite dei modelli per i CMS piu diffusi.

Il progetto “Un CMS per la scuola” ha lo scopo di mettere a disposizione delle Scuole e delle Pubbliche Amministrazioni interessate modelli di sito scolastico basati su quattro CMS open source (Drupal, Joomla, Plone, WordPress) aventi una architettura comune per quanto riguarda la navigazione e l’organizzazione delle sezioni.

Accessibilità, non solo tramite mouse

Uno dei problemi dei menu a comparsa è correlato proprio all’accessibilità da parte di diverse tipologie di utenti in quanto solitamente il menu secondario appare quando un utente passa il puntatore del mouse sopra il menu principale e scompare quando il puntatore esce da tale menu. Un menu che risponde solamente ai comandi del mouse non è pertanto accessibile agli utenti che navigano tramite tastiera, utilizzando i tasti di tabulazione e i tasti cursore di movimento (frecce), nonché da parte degli utenti che utilizzano periferiche mobili che richiedono la pressione dello schermo per interagire con i controlli della pagina. Gran parte di questi menu non sono inoltre accessibili nemmeno a tecnologie assistive come i lettori di schermo (screen reader) e richiedono la disponibilità di script (Javascript).

Menu a comparsa accessibili: alcuni esempi

Alcuni sviluppatori, già negli hanni passati, hanno cercato di risolvere questo problema:

• Drop-Down Menus, Horizontal Style
• Suckerfish Dropdowns
• Son of Suckerfish Dropdowns
• Yet Another Dynamic Menu

Questi menu seguono tutti una serie di principi:

• I menu sono creati utilizzando elementi di lista non ordinata (elemento <ul>) con l’uso di codice di marcatura in linguaggio HTML/XHTML. Tutta la formattazione, inclusa la gestione di visualizzazione dei menu secondari, è sviluppata tramite i fogli di stile (CSS). Disabilitando i CSS, i menu vengono comunque visualizzati come elenchi indentati.
• Con l’ausilio dei CSS, i menu secondari vengono inizialmente nascosti. Questa funzionalità viene spesso realizzata utilizzando – in modo errato – le proprietà CSS visibility:hidden or display:none. Tali istruzioni causano problemi in quanto alcuni lettori di schermo nascondono agli utenti non vedenti i contenuti identificati con tali proprietà. Un approccio differente (e consigliato) sta nel posizionare il menu secondario inizialmente fuori dal campo visivo (per esempio, con top:-9999em) in modo da renderlo tecnicamente non visibile all’utente ma fruibile (leggibile) dai lettori di schermo.
• Quando l’utente passa sopra al menu principale con il mouse (oppure utilizzando il tasto “tab” in caso di navigazione tramite tastiera), le proprietà del menu secondario vengono modificate tramite CSS, rendendolo quindi visibile. Questa attività solitamente richiede delle istruzioni Javascript, ovvero il funzionamento della comparsa dei menu è legato al supporto degli script da parte del browser dell’utente.Vi sono casi in cui degli sviluppatori hanno cercato di produrre menu a comparsa con il solo supporto dei CSS, anche se in alcuni casi non vi è perfetta funzionalità tramite tastiera: Eric Meyer (Pure CSS Menus) e Stuart Robertson (Pure CSS Pulldown Menus) oppure il nostrano Tommaso Baldovino (Menu a tendina accessibile) sono alcuni esempi.

Vi sono poi casi in cui degli sviluppatori prendono ispirazione dai suddetti prodotti per generare soluzioni accessibili da tastiera, sia in presenza che in assenza di script: è il caso di http://www.blakehaswell.com/lab/dropdown/deux/.

Accessibilità dei menu con WAI-ARIA

Un aiuto all’accessibilità ci arriva da WAI-ARIA, che sarà applicabile con il recepimento normativo delle WCAG 2.0. WAI-ARIA, Accessibile Rich Internet Applications , definisce un modo per rendere i contenuti Web e applicazioni Web più accessibili alle persone con disabilità, aiutandoli soprattutto con contenuti dinamici e interfacce utente avanzate con controlli sviluppati in AJAX, HTML, JavaScript e tecnologie correlate. (per approfondire: http://www.w3.org/WAI/intro/aria).

Uno dei vantaggi di soluzioni basate su WAI-ARIA è il pieno supporto della specifica da parte dei più diffusi framework per lo sviluppo di interfacce Web. Un esempio è fornito da MenuNav Node Plugin per Yahoo User Interfaces (YUI) in cui si delega allo script la gestione dell’inserimento di specifiche istruzioni WAI-ARIA necessarie a garantire l’interazione con le tecnologie assistive.

Se invece si desidera implementare autonomamente dei menu accessibili, si consiglia di consultare il sito iCITA nella sezione specifica dedicata ai menu di navigazione. Come funziona? Si parte chiaramente da HTML, CSS e Javascript, per vestire i menu come già descritto in precedenza. ARIA entra in azione con la definizione di una serie di specifici attributi “role” che consentono al lettore di schermo di “agganciare” e “comprendere” la struttura dell’informazione, come oggi avviene nel software tradizionale.  Nel nostro caso abbiamo questi tre valori per “role”:

• menubar. Si tratta di un contenitore per elementi di menu. Ogni elemento “menu” può attivare un sottomenu. La navigazione è del tutto similare a quella dei classici menu di navigazione presenti nel software tradizionale.
• menu. Offre un elenco di scelte all’utente.
• menuitem.  Un collegamento ad un menu. Questa è un’opzione all’interno di un gruppo di scelte disponibili in un menu.

Il seguente esempio rende chiara la semplicità di implementazione di WAI-ARIA (le voci di menu sono esemplificative: possono essere sostituite da elementi di lista non ordinata).

<div role="menubar" id="menutop">
<!--
Esempio di menu con attributo aria-haspopup impostato a 'true'.
Il menu a comparsa è subito disponibile di seguito,
con affiliazione tramite attributo aria-labelledby.
-->
<h3 role="menuitem" aria-haspopup="true" id="mnustruttura"><a href="#">Struttura</a></h3>
<ul role="menu" aria-labelledby="mnustruttura">
<li role="menuitem"><a href="#">Presidenza</a></li>
<li role="menuitem"><a href="#">Consiglio di Amministrazione</a></li>
<li role="menuitem"><a href="#">Revisori dei Conti</a></li>
...
</ul>
<!--
Menu Dove siamo:
-->
<h3 role="menuitem" aria-haspopup="true" id="mnudove"><a href="#">Dove siamo</a></h3>
<ul role="menu" aria-labelledby="mnudove">
<lu role="menuitem"><a href="#">Come raggiungerci</a></li>
<li role="menuitem"><a href="#">Contatti</a></li>
</ul>
</div> <!-- fine menubar -->

Si può pertanto riassumere che lo sviluppo di menu a comparsa accessibili deve garantire funzionalità indipendenti dal dispositivo di input (tastiera e mouse), funzionamento anche da parte di screen reader. Per menu a più livelli si consiglia l’uso di WAI-ARIA.

Negli anni precedenti, stante la problematica dei costi di connessione e la dimensione degli schermi, le versioni mobile per i servizi web si basavano essenzialmente in un foglio di stile personalizzato con rimozione della grafica oppure – caso sempre più diffuso – con la realizzazione di una versione specifica (mobile.nomesito.it). Un esempio in tal senso è il servizio mobile viaggiatreno di Trenitalia.

Attualmente la panoramica è cambiata. La diffusione di strumenti mobile con supporto alla multimedialità ha notevolmente modificato il mercato dei servizi, per i quali in molti casi si preferisce lo sviluppo di applicazioni specifiche (le cosiddette “app”) per differenti tipologie di sistemi operativi. Sorge però il problema di identificare chiaramente il proprio target di utenza e la necessità effettiva di versioni mobile. L’implementazione di soluzioni mobile, oggi è comunque altamente onerosa, con un gran numero di variabili, tra cui la dimensione e risoluzione dello schermo e l’ambiente operativo (e relativo browser) utilizzato dall’utente.

I problemi del Web mobile

Va innanzitutto chiarito che, stante l’eterogenea tipologia di periferiche, risoluzioni video ed ambienti operativi, non esistono linee guida specifiche per l’accessibilità del Web mobile. Il W3C ha emanato una serie di indicazioni, le Mobile Best Practices, che forniscono generiche indicazioni per migliorare la fruibilità dei contenuti tramite Web mobile, riferendosi in particolare alle seguenti problematiche:

• Rappresentazione dei contenuti. Differenti tipologie di browser, risoluzioni video e tecnologie richiedono di implementare soluzioni adattabili, identificando caratteristiche comuni di rappresentazione dei contenuti (convenzioni).
• Modalità di input. Le periferiche mobile possono consentire input diretti tramite tastiera, tramite interfaccia di emulazione tastiera, tramite “touch” o comandi vocali. Gli sviluppatori devono pertanto garantire interoperabilità delle interfacce (sia Web-based che delle cosiddette “app”).
• Banda e costi. Sviluppare siti Web e testarli con linee ADSL o similari può non far comprendere i reali tempi di caricamento dei contenuti. Gli sviluppatori dovranno quindi valutare la riduzione del carico di byte per contenuti “decorativi” (immagini, filmati, loghi, ecc.).
• Advertising. La pubblicità è l’anima del commercio e quotidianamente si riscontrano nuove forme di promozione, tra cui fastidiosi pop-up. Tali soluzioni vanno testate anche con tecnologie mobile per valutare se impediscono la fruibilità dei contenuti.
• Limiti delle periferiche. Non tutti gli utenti sono dotati dell’ultima versione del prodotto mobile XYZ. Gli sviluppatori dovranno pertanto garantire una retrocompatibilità delle loro creazioni, onde evitare la perdita di utenza.

Risorse per l’accessibilità del Web mobile

Di seguito vengono riepilogate una serie di risorse utili, pubblicate da Henny Swan, per l’approfondimento da parte degli sviluppatori, sia in ambito generale, sia per specifici ambienti.

Risorse generali

• Mobile Web Best Practices 1.0 – indicazioni specifiche per lo sviluppo di applicazioni Web mobile.
• Web Content Accessibility Guidelines 2.0 – le linee guida di riferimento per l’accessibilità del Web, applicabili quindi anche allo sviluppo di interfacce Web per il mobile
• Relationship between Mobile Web Best Practices and the Web Content Accessibility Guidelines – pubblicate dal W3C-WAI, forniscono dei riferimenti incrociati tra le linee guida per il web mobile e per l’accessibilità del Web.
• Barriers Common to Mobile Device Users and People with Disabilities – una serie di informazioni utili per conoscere le problematiche di accessibilità di singole disabilità per l’accesso al Web mobile
• Widget Accessibility Best Practices – scritte da Steve Lee, queste best practice forniscono indicazioni sullo sviluppo di widget accessibili rispettosi degli standard e multipiattaforma.
• Mobile Website Guidelines – linee guida per il Web mobile pubblicate dall’Università di Austin, una serie di principi generali e piccole indicazioni su dimensioni delle immagini, tipologia di stili, ecc.

Risorse per Android

• Designing for accessibility, pubblicato a cura degli sviluppatori di Android, si occupa di fornire indicazioni sullo sviluppo accessibile di applicazioni (app).
• Android accessibility – pubblicato a cura del progetto Google Eyes Free

Risorse per Blackberry

• Best practices designing accessible applications – pubblicato dal Blackberry Developer Centre

Risorse per iOS (iPhone, iPad, iPod Touch)

• Accessibility programming guide for iOS – Linee guida di Apple per rendere accessibili le applicazioni per iOS
• Accessibility for iPhone and iPad apps – una versione di facile comprensione per sviluppare app accessibili, a cura di Matt Gemmell
• iPad usability studies- two studies published over two years by Jakob Neilson

Risorse per Nokia e Symbian

• User experience checklist for touch (PDF – new window) – pubblicate da Nokia
• User experience checklist for keypad (PDF – new window) - pubblicate da Nokia

Risorse per Windows mobile

• Design guidelines for Windows Mobile – pubblicate da Microsoft, contengono riferimenti anche a linee guida per usabilità, navigabilità, gestione dei controlli di input e dei testi
• Accessibility and Ergonomic Guidelines – per Windows Mobile, pubblicate da Microsoft

Creare file PowerPoint con l’accessibilità in mente

Tutte le versioni di PowerPoint a partire dalla 2000 dispongono di diversi layout predefiniti accessibili. L’uso corretto di questi template assicura che i titoli siano correttamente strutturati, gli elenchi puntati e numerati ben formati, l’ordine di lettura rispettato.

In PowerPoint 2007/2010, potete accedere a questi template facendo clic sul pulsante Nuova diapositiva del menu Home come mostrato nella figura seguente.

Il menu Nuova diapositiva di PowerPoint permette di accedere a template accessibili.

Testo alternativo per le immagini

Normalmente le presentazioni PowerPoint contengono immagini. Spesso queste sono decorative, ma diverse presentano contenuti che devono essere dotati di testo alternativo.

Il testo alternativo verrà letto da uno screen reader in PowerPoint, e rimarrà intatto esportando il file in HTML o PDF.

Per dotare un’immagine non decorativa di testo alternativo, fate clic con il pulsante destro del mouse sull’immagine stessa e nel menu contestuale che apparirà selezionate la voce Dimensioni e posizione. Nella finestra di dialogo che apparirà, fate clic sulla scheda Testo alternativo e digitate il vostro testo.

Aggiungere il testo alternativo per le immagini in PowerPoint.

Tabelle dati e accessibilità

Utilizzando il comando Inserisci > Tabella di Powerpoint, è possibile creare tabelle del desiderato numero di celle e colonne. Nel menu Progettazione che si attiverà, verificate che la casella di controllo Riga di intestazione sia attiva. Questa è l’unica opzione disponibile per l’accessibilità delle tabelle, e in caso di tabelle dati complesse certamente non è sufficiente. In questi casi considerate la possibilità di esportare le vostre presentazioni in PDF, utilizzando Acrobat Pro per aggiungere le necessarie informazioni di struttura.

Link

I link iptertestuali vengono creati incollando l’URL (Uniform Resource Locator) completo in una pagina. Premendo Invio o qualsiasi altro tasto, automaticamente nella slide comparirà un collegamento attivabile.

Però, leggere un URL non ha molto senso per il lettore. Potete cambiare il testo che fa da link selezionando il collegamento, fate clic destro e selezionate la voce Modifica collegamento ipertestuale nel menu contestuale che apparirà e modificando adeguatamente il testo contenuto nella casella Testo da visualizzare. In questo modo nel documento non comparirà più un incomprensibile URL, bensì un testo che prepari il lettore a quello che avverrà facendo clic sul link.

Predisponete un testo comprensibile per i link.

Altre tecniche

• Verificate che la dimensione del testo sia sufficiente ad essere visualizzata senza sforzo anche quando proiettata.
• Fornite un contrasto adeguato fra colore del testo e sfondo.
• Evitate le transizioni automatiche, e se fosse necessario utilizzarle ricorrete alle più semplici.
• Utilizzate un linguaggio semplice.
• Verificate l’ordine di lettura dei box che non fanno parte del layout originale: normalmente verranno letti per ultimi. Sfruttate a questo scopo il pannello Struttura posto nell’area destra della finestra del programma (se l’area fosse ridotta, potete allargare il pannello trascinando la barra divisoria verticale posta fra pannelli e area del documento. Ricordate che i contenuti possono essere digitati direttamente nel pannello Struttura.

Utlizzate il pannello Struttura per verificare l'ordine di lettura e introdurre contenuti.

• Se inserite contenuti video, controllate che siano sottotitolati e che il controlli del player siano accessibili.
• Se inserite contenuti audio, fornite una trascrizione.

Verifica dell’accessibilità

Office 2010 è dotato di un nuovo strumento chiamato “Accessibility Checker” in grado di produrre una verifica tecnica sui documenti Word, Excel e PowerPoint. Purtroppo questo strumento non è disponibile per versioni precedenti dei programmi.

1. 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à.
2. Utilizzabile. I componenti dell’interfaccia utente devono essere navigabili ed utilizzabili. 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.
3. 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.
4. 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.

In questo articolo cercheremo di comprendere meglio le finalità delle dodici linee guida, fondamento dell’aggiornamento dei requisiti della legge 4/2004. Ogni principio contiene delle linee guida il cui scopo è quello di aiutare a rispettare il principio, garantendo 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. La numerazione delle linee guida richiama il principio (da 1 a 4) e un numero progressivo interno allo stesso.

• Linea guida 1.1 (Alternative testuali): Fornire alternative testuali per qualsiasi contenuto non di testo in modo che questo possa essere trasformato in altre forme fruibili secondo le necessità degli utenti come stampa a caratteri ingranditi, Braille, sintesi vocale, simboli o un linguaggio più semplice. Lo scopo di questa linea guida è di garantire che tutti i contenuti non testuali siano disponibili anche sottoforma di testo. Il termine testo si riferisce al testo elettronico e non a quello rappresentato sottoforma di immagini, considerando che il testo elettronico ha il beneficio di essere interpretato da qualsiasi tecnologia Web e può essere rappresentato in modo visivo tramite ingrandimenti, in modo tattile, per mezzo del sonoro. Esempio: Una persona non vedente potrà comprendere immagini grazie a testi alternativi, una persona non udente potrà comprendere dei dialoghi grazie a contenuti testuali. Per giungere alla conformità di questa linea guida è pertanto necessario che qualsiasi oggetto fornisca un’alternativa testuale consona.
• Linea guida 1.2 (Tipi di media temporizzati): Fornire alternative per i tipi di media temporizzati. Lo scopo di questa linea guida è di fornire l’accesso ai media temporizzati e sincronizzati. Nei criteri di successo sono inclusi i seguenti media: solo audio, solo video, audio-video, audio e/o video combinati con interazioni. I media possono essere preregistrati oppure in tempo reale (live). Pertanto sarà necessario fornire sottotitoli (o interpretazione tramite lingua dei segni) per persone non udenti, audiodescrizioni delle azioni per gli utenti non vedenti oppure fornire una trascrizione completa dei contenuti.
• Linea guida 1.3 (Adattabile): Creare contenuti che possano essere rappresentati in modalità differenti (ad esempio, con layout più semplici), senza perdere informazioni o la struttura. Lo scopo di questa linea guida è di garantire che tutte le informazioni siano disponibili in una forma che possa essere compresa dall’utente, ad esempio, con lettura a voce alta oppure utilizzando un’impostazione grafica più semplice. Se tutte le informazioni vengono fornite in modo da poter essere comprese dal software dell’utente, sarà più facile garantirne la portabilità in altre forme di comunicazione (visuali, uditive, ecc.). Per giungere alla conformità di questa linea guida è necessario rendere percepibili le informazioni, la struttura, le relazioni e le funzionalità dei contenuti presenti nella pagina Web garantendo, ad esempio, un corretto ordine di lettura dei contenuti.
• Linea guida 1.4 (Distinguibile): Rendere più semplice agli utenti la visione e l’ascolto dei contenuti, separando i contenuti in primo piano dallo sfondo. Lo scopo di questa linea guida è di garantire che tutte le informazioni presenti nella modalità predefinita di visualizzazione siano maggiormente accessibili da parte delle persone con disabilità. Tra gli obiettivi principali vi è la separazione tra informazioni in primo piano e quelle di sfondo: per le presentazioni visive, è necessario quindi garantire un adeguato contrasto tra testo e sfondo mentre per quelle sonore è fondamentale assicurarsi che l’utente possa comprendere i contenuti audio senza interferenze dovute a suoni di sfondo. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui l’utilizzo di caratteri leggibili e ridimensionabili, l’uso di adeguati contrasti tra testo principale e sfondo con la possibilità di disabilitare l’audio di sfondo ove lo stesso, rendesse incomprensibile i contenuti audio principali.
• Linea guida 2.1 (Accessibile da tastiera): Rendere disponibili tutte le funzionalità tramite tastiera. Lo scopo di questa linea guida è di garantire che tutte le funzionalità presenti nel contenuto siano accessibili tramite tastiera. Tale uso consente a chi opera con tastiere, sistemi in emulazione della tastiera (comandi vocali, uso del mouse con una tastiera virtuale) o con tecnologie assistive di poter interagire con la maggior parte dei contenuti. Per giungere alla conformità di questa linea guida, vi sono una serie di criteri di successo tra cui l’operatività tramite tastiera senza richiedere particolari tempistiche di esecuzione e la possibilità, di passare il focus da un oggetto al successivo tramite il solo uso della tastiera.
• Linea guida 2.2 (Adeguata disponibilità di tempo): Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti. Lo scopo di questa linea guida è di garantire che gli utenti siano in grado di completare i compiti richiesti dal contenuto con i propri tempi di risposta individuale. Molte persone con disabilità hanno bisogno di più tempo per portare a termine dei compiti rispetto alla maggior parte degli utenti: possono richiedere più tempo sia per rispondere fisicamente che per leggere i contenuti oppure, possono accedervi tramite delle tecnologie assistive che richiedono più tempo di interazione. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui la possibilità di interrompere e/o personalizzare, il tempo di esecuzione dei contenuti di una pagina Web.
• Linea guida 2.3 (Convulsioni): Non sviluppare contenuti che possano causare attacchi epilettici. Lo scopo di questa linea guida è di garantire che il contenuto contrassegnato come conforme alle WCAG 2.0, eviti i tipi di lampeggiamento che sono i più suscettibili a causare attacchi epilettici se visualizzati anche per soli uno o due secondi. Alcuni utenti con disturbi convulsivi possono avere attacchi epilettici nel caso di contenuti lampeggianti. Per giungere alla conformità di questa linea guida vi sono una serie di indicazioni da rispettare tra cui il suggerimento di non implementare contenuti lampeggianti e, ove necessario, verificare che la frequenza di lampeggio non rientri in intervalli ritenuti pericolosi (definiti nel glossario WCAG 2.0 come soglia generale o soglia del rosso), o che non superino i tre lampeggi per secondo.
• Linea guida 2.4 (Navigabile): Fornire delle funzionalità di supporto all’utente per navigare, trovare contenuti e determinare la propria posizione. Lo scopo di questa linea guida è di aiutare gli utenti a trovare i contenuti di cui hanno bisogno e di consentire loro, di tenere traccia della loro posizione. Questi compiti spesso sono difficili per gli utenti con disabilità in quanto per la ricerca, la navigazione e l’orientamento è importante che l’utente sia in grado di comprendere la sua posizione attuale all’interno del contenuto. Per giungere alla conformità di questa linea guida vi sono una serie di indicazioni da rispettare tra cui limitare il numero di link presenti nella pagina, consentire modalità per navigare agevolmente tra i diversi blocchi e rendere i collegamenti chiaramente identificabili.
• Linea guida 3.1 (Leggibile): Rendere il testo leggibile e comprensibile. Lo scopo di questa linea guida è di permettere che il contenuto testuale possa essere letto sia da utenti che da tecnologie assistive e di garantire la disponibilità delle informazioni necessarie per la comprensione. Le persone con disabilità possono interpretare il testo in modalità differenti: c’è chi avrà un’esperienza visiva, chi uditiva; per qualcuno sarà un’esperienza tattile mentre per altri ancora potrà essere sia visiva che uditiva. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui, la necessità di definire la lingua principale del documento, eventuali cambi di lingua per blocchi di testi e, le espansioni di acronimi ed abbreviazioni.
• Linea guida 3.2 (Prevedibile): Creare pagine Web che appaiano e che siano prevedibili. Lo scopo di questa linea guida è di aiutare gli utenti con disabilità, presentando i contenuti in un ordine prevedibile da pagina Web a pagina Web rendendo prevedibile, il comportamento di componenti funzionali e interattivi. Ad esempio persone che utilizzano sistemi di ingrandimento dello schermo possono vedere esclusivamente delle parti della pagina. Garantendo una navigazione coerente tra le pagine l’utente potrà spostarsi tra i contenuti in modo più agevole. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui la richiesta di fornire una navigazione consistente (mantenendo ad esempio una struttura di menu costante tra le diverse pagine del sito).
• Linea guida 3.3 (Assistenza nell’inserimento): Aiutare gli utenti ad evitare gli errori ed agevolarli nella loro correzione. Lo scopo di questa linea guida è di aiutare gli utenti a ridurre il numero degli errori gravi ed irreversibili, incrementando la possibilità di notificare all’utente i possibili errori oppure, aiutandoli a capire le azioni che dovrebbero intraprendere per correggerli. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui, la richiesta di fornire i messaggi di errore descrivendoli in modo chiaro ed in forma testuale, fornendo altresì delle modalità di supporto per correggere le inesattezze e/o per evitare errori successivi (esempio: disponibilità di guide contestuali).
• Linea guida 4.1 (Compatibile): Garantire la massima compatibilità con i programmi utente attuali e futuri, comprese le tecnologie assistive. Lo scopo di questa linea guida è di sostenere la compatibilità con i programmi utente attuali e futuri, in particolare con le tecnologie assistive (AT). Questo è attuabile se ci si impegna a: garantire che gli autori non producano contenuti che interrompono l’esecuzione delle tecnologie assistive (esempio: errori di marcatura) oppure che le aggirino (esempio: utilizzando codice di marcatura non convenzionale) e a fornire alle tecnologie assistive le informazioni necessarie sullo stato dei contenuti, in modo da garantirne l’interazione. Per giungere alla conformità di questa linea guida vi sono una serie di criteri di successo tra cui la richiesta di consultare ed impostare in modo programmatico il nome (name), il ruolo (role), lo stato (state), le proprietà (proprieties) e i valori (values) degli oggetti, notificandone la modifica anche alle tecnologie assistive.

Ordine di lettura delle celle di una tabella letta con uno screen reader.

Osserviamo quindi la seguente tabella:

Uno screen reader leggerà le informazioni in questa tabella così: attributo, gatto, scimmia, serpente, pelliccia, sì, sì, no, zampe, 4, 2, 0.
Non è molto di aiuto, vero?. Certamente sarebbe molto più comprensibile una lettura di questo tipo:

• Gatto: pelliccia, quattro zampe
• Scimmia: pelliccia, due zampe
• Serpente: no pelliccia, no zampe

Come in molti altri casi, un semplice intervento redazionale sui contenuti è già in grado di migliorare l’accessibilità degli stessi senza dover ricorrere alla tecnica.

Inoltre, è auspicabile dotare le tabelle di una appropriata didascalia. In Word, questo lo si ottiene selezionando  la tabella e facendo clic sul pulsante Inserisci didascalia della scheda Riferimenti. Pensate a un testo che permetta anche a chi non vede fisicamente la didascalia di comprendere la natura dei dati presentati (per approfondire,WCAG 2.0 H39: Using caption elements to associate data table captions with data tables).

Creazione della didascalia di una tabella.

I formati PDF e XHTML dispongono di ben più accurati strumenti per l’accessibilità delle tabelle, e per ora questa tabella esportata in uno di questi formati non disporrebbe di quegli attributi che permettono di collegare esplicitamente il contenuto di una cella alla rispettiva intestazione di riga o di colonna, argomento di un apposito tutorial.
Sono possibili ulteriori miglioramenti? Certo.

• In Word, selezionate la tabella e impostate la larghezza delle colonne in % invece che in pixel: selezionare la tabella, clic destro sulla tabella e selezionate nel menu contestuale che apparirà Proprietà tabella > scheda Colonna. Impostate le dimensioni in Percentuale (clic sull’elenco a discesa Unità di misura) in modo che la tabella se sottoposta a ingrandimento in Acrobat con la funzione Ridisponi attiva si ingrandisca senza produrre la comparsa della barra di scorrimento orizzontale.

• Word non permette di definire colonne come intestazioni di righe, ma di determinare quali siano le intestazioni delle colonne sì: selezionare la prima riga e nella scheda Riga della finestra di dialogo Proprietà tabella fate clic sulla casella di controllo Ripeti come riga di intestazione in ogni pagina. Quando verrà creato il PDF, quella riga della tabella possiederà una sezione THead che contiene gli elementi TH.

Livio Mondini

Adobe è molto attiva sul fronte accessibilità, e i tool disponibili sono piuttosto efficaci ed orientati alla produzione. Per esempio, l’ultima versione di Acrobat, denominata X, prevede una procedura guidata che permette di applicare a gruppi di file determinate azioni orientate al renderli accessibili (creazione della struttura, assegnazione dei testi alternativi, e così via).

Certo, con la consapevolezza che l’accessibilità non può essere demandata a tool automatici, che potranno al massimo sveltire le operazioni. E in ogni caso, nessun tool potrà riparare quei PDF contenenti soltanto scansioni di pagine che con pessima abitudine vengono frequentemente pubblicati sui siti della PA.

In ogni caso, esiste un vincolo: a oggi, nonostante il formato PDF sia pubblico e quindi chiunque ne può conoscere le caratteristiche e di conseguenza, volendo, sviluppare uno strumento per la gestione e la modifica dei file PDF, soltanto Acrobat Pro dispone degli strumenti necessari. È davvero un fatto curioso, perché sono disponibili innumerevoli lettori di PDF sia free sia commerciali, ma nessuno sembra essersi posto il problema eccetto Adobe.

Nel nostro caso, poter modificare un file PDF è importante, poiché dopo la validazione potrebbe essere necessario dover apportare qualche correzione. Le strade sono due: o provo a correggere il file originale nel programma di authoring utilizzato, o utilizzo Acrobat Pro. Nel primo caso, potrebbe essere una lotta senza soluzione: per esempio, esportando in PDF un file da Word, a oggi il programma di conversione non salva gli attributi title dei link.

D’altra parte questi attributi sono necessari, ed ecco che se non dispongo di Acrobat Pro diventa quasi impossibile risolvere questa problematica. In ogni caso, la indisponibilità di Acrobat Pro non può essere una scusa per pubblicare PDF completamente inaccessibili: qualsiasi sia lo strumento utilizzato per produrre il testo originale, le caratteristiche di accessibilità basilari potranno essere rese disponibili agli utenti.

In cosa ci aiuta la validazione? Ovvio, nell’individuazione rapida di eventuali problematiche tecniche presenti nei nostri file.

Quali sono gli strumenti disponibili? Acrobat Pro, come già detto, e il il PDF Accessibility Checker di Access for All, un tool gratuito per la verifica dei file PDF.

Questo tool è veramente raccomandato per tutte quelle realtà dove la disponibilità di Acrobat Pro è improbabile.

Il PDF Accessibility Checker produce dei report dettagliati e ben comprensibili,e l’analisi svolta approfondisce aspetti determinanti come il corretto ordine di lettura, la presenza di testi alternativi, la congruenza della struttura dei titoli, l’ordine di lettura navigando con la tastiera, la disponibilità dell’attributo title, la definizione della lingua del documento per un totale di 14 criteri di verifica:

1. Il documento possiede una struttura a tag
2. Il documento possiede un title
3. La lingua del documento è stata definita
4. Le opzioni di sicurezza non inibiscono le tecnologie assistive
5. L’ordine di tabulazione è congruente con la struttura a tag
6. È disponibile un ordine gerarchico di titoli ben delineato
7. Sono presenti i segnalibri
8. Vengono utilizzate font con il corretto encoding
9. Il contenuto è completamente inserito nella struttura a tag
10. L’ordine di lettura è corretto
11. Sono disponibili i testi alternativi
12. La sintassi dei tag è corretta
13. Il contrasto fra testo e sfondo è sufficiente
14. Sono presenti le spaziature necessarie fra i brani di testo (alcuni PRD Writer eliminano completamente lo spazio fra parole, non si sa bene per quale motivo, e ovviamente questo è un problema per chi utilizza uno screen reader).

Il PDF Accessibility Checker

Particolarmente efficace (anche per chi possiede Acrobat Pro) è la visualizzazione che si ottiene facendo clic sul tasto Preview: il file PDF viene aperto linearizzato in un browser e la struttura semantica dei tag è evidenziata tramite icone. Ponendo il cursore sulle icone viene visualizzato il tag assegnato all’elemento.

Preview del documento PDF con la struttura evidenziata.

Livio Mondini