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

Una delle prime amministrazioni che ha voluto garantire una gestione economica, razionale e efficace della propria comunicazione accessibile su web è stata la Regione Emilia-Romagna.
Nell’intento di illustrare a tutte le amministrazioni interessate tale esperienza e offrire gli utili spunti metodologici che se ne possono trarre, pubblichiamo nella sezione Esempi e Guide un documento in cui vengono descritti gli aspetti più importanti.

A.D.V. – L.M.

I documenti aggiornati sono i seguenti:

• Techniques for WCAG 2.0
• Understanding WCAG 2.0

Questi importanti documenti di supporto all’applicazione delle WCAG 2.0 (definiti W3C Working Group Notes) sono aggiornati periodicamente per recepire le tecnologie più recenti e i casi pratici di implementazione accessibile.

Va ricordato che questi documenti NON sono aggiornamenti delle WCAG 2.0, che sono ritenute documento stabile e riferimento per l’accessibilità del Web.

Questo aggiornamento delle tecniche e della guida alla comprensione delle WCAG 2.0 include una maggiore copertura di tecnologie non sviluppate dal W3C (Flash, PDF, Silverlight) in modo da aiutare gli sviluppatori che utilizzano tali tecnologie a renderle maggiormente accessibili. Tuttavia, la pubblicazione di tecniche per una tecnologia specifica non implica che la tecnologia può essere utilizzata in tutti i casi per creare contenuti accessibili in grado di soddisfare le WCAG 2.0. Ad esempio, le tecniche Flash per le WCAG 2.0 riportano che: “il supporto di accessibilità per le tecnologie assistive di di Flash si basa su l’uso dei sistemi operativi Windows, con Internet Explorer 6 o versioni successive (con Flash Player 6 o versioni successive) o Mozilla Firefox 3 o versione successiva (con Flash Player 9 o versioni successive)“. Gli sviluppatori devono essere consapevoli dei limiti delle specifiche tecnologie e devono pertanto garantire che queste creino contenuti in un modo che siano accessibili a tutti i loro potenziali utenti.

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

Un social network perfettamente accessibile e fruibile da parte di non vedenti ed ipovedenti, ma aperto a tutti. Si chiama Freerumble e verrà presentato ufficialmente il 20 ottobre alle ore 18.00 a Palazzo Marini, presso la Camera dei Deputati in via della Mercede n. 55 a Roma. A presentare l’iniziativa i volontari dell’Uiciechi e dell’Associazione disabili visivi (Adv).

Per saperne di più:

Superabile

Freerumble

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