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.

E’ l’atto conclusivo di presentazione del progetto RACER, che vuole rendere pubblici gli strumenti che ha realizzato e raccolto. La giornata si svolgerà in 2 momenti:

1. presentazione dei prodotti RACER e del kit per l’accessibilità
2. barcamp sui CMS opensource. L’incontro vuole far toccare con mano i prodotti e le soluzioni e far conoscere tra loro gli stakeholder affinchè possano fare rete tra loro.

L’evento vuole essere un punto di incontro tra pubbliche amministrazioni alla ricerca di soluzioni web accessibili e a codice aperto, e le aziende e sviluppatori che offrono già queste soluzioni. L’evento si svolgerà presso l’Hotel NH de la Gare a Bologna.

Obiettivo del convegno: e’ l’atto conclusivo di presentazione del progetto RACER, che vuole rendere pubblici gli strumenti che ha realizzato e raccolto. La giornata si svolgerà in 2 momenti: presentazione dei prodotti RACER e del kit per l’accessibilità, barcamp sui CMS opensource. L’incontro vuole far toccare con mano i prodotti e le soluzioni e far conoscere tra loro gli stakeholder affinchè possano fare rete tra loro.

Destinatari
Tutte le pubbliche amministrazioni che vogliano risolvere le esigenze imposte dalla legge sull’accessibilità
Tutte le PA che hanno adottato un CMS opensource o intendono farlo.
Tutte le aziende e professionisti che lavorano o offorno servizi su CMS opensource.
Tutti i professionisti esperti in tema di accessibilità

Per maggiori informazioni e iscrizione: http://www.barcampitalia.org/2009/12/04/22-gennaio-2010-accessibilita-e-cms/