Ufix

Con un po' di ritardo a causa di impegni lavorativi, ecco il terzo e ultimo appuntamento per migliorare l'accessibilità di Drupal (nei post precedenti ho parlato del tema accessibilityblue e del modulo htmlvalidator, dei quali nel frattempo ho corretto qualche altro bug).

Ma ora due parole sul modulo accessibilityvalidator...

Anche se una pagina validata XHTML 1.0 Strict vuol dire che è già abbastanza accessibile, questo non basta. Ecco quindi un altro modulo, che esegue altri controlli di accessibilità che il semplice HTML Validator ignora. In particolare, accessibilityvalidator controlla:

• che ogni tabella contenga un riassunto del contenuto (attributo summary del tag table);
• che ogni tabella abbia almeno una cella intestazione (tag th);
• che ogni cella di una tabella abbia un'identificativo univoco (attributo id del tag th);
• che ogni cella si riferisca ad almeno un'intestazione (attributo header del tag td);
• che sia impostato l'ordine di accesso agli elementi di input di un form (cioé che ogni elemento di input abbia l'attributo tabindex);
• che ogni elemento di input di un form abbia un'identificativo univoco (attributo id);
• che ogni elemento di input abbia associata un'etichetta (tag label);
• che ogni insieme di campi (tag fieldset) abbia un riassunto dei contenuti (tag legend);
• che ogni elemento di input di tipo radio e check sia dentro a un insieme di campi (tag fieldset).

Per un sito Drupal accessibile consiglio l'uso di entrambi i moduli.

Ordunque:

• Scarica il modulo (12 Kb)
• Leggi altre informazioni sull'argomento

C'è comunque da dire che questi moduli aiutano a migliorare la sintassi del codice HTML ma non garantiscono il rispetto assoluto delle linee guida del W3C. Inoltre, nota non meno importante, un rispetto della sintassi non vuol dire automaticamente che il sito sia accessibile: bisognerebbe testare il sito con persone disabili e comunque avere sempre presente il problema e sapersi immedesimarsi negli altri (qualunque sia il loro approccio al web e alla vita). La sfida è sempre aperta.


Nota: Sia htmlvalidator che accessibilityvalidator sono alla loro prima versione. Sono ben accetti commenti, in particolare segnalazioni di bug e di problemi di traduzioni inglesi (entrambi i moduli sono in inglese con già disponibile la traduzione in italiano).

Continua il lavoro iniziato una decina di giorni fa per rendere Drupal ancora più accessibile.

Dopo aver effettuato una prima fase di debug delle tre creazioni, è arrivato il momento di presentare la seconda delle tre creazioni.

Il modulo htmlvalidator interviene ogni volta che viene inserito un nuovo contenuto, viene modificato un contenuto esistente o viene richiesta un'anteprima di un contenuto in fase di inserimento/modifica.

Prende il contenuto inserito/modificato e lo fa validare dal validatore di sintassi del W3C.

Nel caso in cui la validazione fallisce, l'inserimento/modifica del contenuto viene impedito e vengono mostrati all'utente gli errori riscontrati dal validatore.

Andando nel menu Amministra / Impostazioni / htmlvalidator è possibile scegliere il DTD da usare per la validazione (scelte possibili: XHTML 1.1, XHTML 1.0 Strict, XHTML 1.0 Transitional, XHTML 1.0 Frameset, HTML 4.01 Strict, HTML 4.01 Transitional, HTML 4.01 Frameset, HTML 3.2, HTML 2.0.

Si è scelto di dare la possibilità di scelta del DTD per far sì che il modulo sia usufruibile anche per motivi che vanno al di là dell'accessibilità.

Il DTD predefinito è XHTML 1.0 Strict: se una pagina è validata XHTML 1.0 Strict vuol dire che ha anche superato alcuni tra i principali checkpoint per l'accessibilità. Tra i quali:

• i tag a non contengono attributi target;
• i media (tag img e simili) contengono necessariamente l'attributo alt;
• non vengono utilizzati frame
• non vengono utilizzati tag presentazionali (ad esempio font)
• non vengono utilizzati tag problematici (ad esempio blink)
• il tag optgroup contiene necessariamente una label

Ordunque:

• Scarica il modulo (10 Kb)
• Leggi altre informazioni sull'argomento

Il CMS Drupal (di cui ho già parlato in passato) di suo è già abbastanza orientato all'accessibilità. Ma ancora ci sono ampi margini di miglioramento.
Ed è proprio per migliorare questo lato del CMS che ho creato un tema e due moduli:

• accessibleblue (19 Kb)
• htmlvalidator (7 Kb)
• accessibilityvalidator (11 Kb)

Il tema accessibleblue è un clone di "Blue marine", il tema originale predefinito di Drupal. Le differenze dall'originale sono "invisibili agli occhi":

• Elimina totalmente l'uso delle tabelle per scopi presentazionali, passando interamente l'impaginazione al CSS.
• Inserisce nel codice un link che per mettere di saltare automaticamente la barra di navigazione. La modifica è visibile solo dagli screen reader (o dal browser purché si disattivi il CSS).

Dei due moduli parlerò più ampiamente nei prossimi post.

Finalmente mi sono deciso a cambiare il CMS che gestisce il mio sito personale.
E finalmente sono passato a Drupal.

Per il momento devo dire che mi soddisfa molto: è facile da usare quanto FlatNuke e potente e ampliabile quanto eZ.

Un'altra cosa molto apprezzabile è l'occhio di riguardo verso l'accessibilità, indicata tra i goal del progetto e a cui è orientato Pushbutton, uno dei temi preinstallati del CMS (i temi gestiscono il layout del sito e quindi l'(X)HTML che viene tirato fuori).
Partendo da Pushbutton ho creato un tema tutto mio, ancora più rigido e vicino ai dettami della Legge Stanca. Lo perfezionerò e "generalizzerò" e poi lo metterò a disposizione della comunità.

I miei progetti per il futuro  riguardo Drupal:

• un layer che intereccetti le chiamate al database (attualmente mi appoggio a MySQL) e le trasformi in operazioni su filesystem, al fine di ottenere un database "flat";
• un editor HTML accessibile e che non sia una semplice htmlarea;
• una migliore profilazione per editori disabili (sarebbe carino che dal profilo si potesse scegliere il proprio editor preferito, se non addirittura indicare se e quali disabilita' si ha, affinche' il sistema poi agisca di conseguenza).

In queste cose i tempi si dilatano sempre, però mi piacerebbe raggiungere questi obiettivi prima di fine luglio. Per il momento mi limito a fare un po' di betatesting del sito e dei blog (visto che ho cambiato di conseguenza anche i template)...

L'obiettivo è sempre quello : avere un CMS accessibile. Per accessibile intendo che rispetti la Legge Stanca (sorvolo in quest'occasione commenti in positivo o in negativo sulla legge in sé), sia il frontend che il backend.

Puntavo a dare una mano in tal senso per Flatnuke o FlatnukeTre ma mi sono reso conto che alcune caratteristiche a cui puntavo rendevano inevitabile cambiare il core con relativi problemi di retrocompatibilità.

Sto valutando se fare un CMS da zero (be' non proprio da zero: raccantando componenti qua e là).
A questo punto metterei qualche caratteristica anche non strettamente legata all'accessibilità.

Le prime caratteristiche che mi vengono in mente sono le seguenti:

• XHTML Compliant
• Template interamente stabilito dai temi (tramite l'utilizzo di XTemplate o in modo similare)
  
• Basato su filesystem
• Multilingua
• Con editor accessibile e che crea codice accessibile (nei limiti del possibile)
• Con la possibilità di usare le accesskey.
• Con un'interfaccia di backend usabile e accessibile
• Modulare e ampliabile attraverso nuovi temi.
• Modulare e ampliabile attraverso nuovi blocchi.
• Modulare e ampliabile attraverso nuove sezioni.
• Modulare e ampliabile attraverso moduli per il DBMS
• Modulare e ampliabile attraverso nuovi editor
• Modulare e ampliabile attraverso nuovi script php da avviare al caricamento di ogni pagina (ad esempio per statistiche sui referer).

Mi chiedo e chiedo a chi passa da questo blog: esite già un CMS del genere? (oggi darò un'occhiata a Limbo, che sembra interessante)
Altrimenti, avete altri consigli per questo nuovo CMS? (considerato che il targete è per l'uso in siti medio-piccoli, ad esempio come portale di Comuni di pochi abitanti)

Per quanto, come dicevo prima,  Flatnuke sia carino, ci sono ancora tante migliorie possibili. Ho trovato un fork di questo CMS che mi soddisfa di più, ma anche quello è migliorabile. Così mi sto rimboccando le maniche...

Sto provando a crearne una versione che sia più accessibile.
Per il momento mi sto limitando al fatto che sia XHTML compliant e che ci sia un'effettiva divisione tra contenuto e resa grafica (quindi via tutto il layout tabellare per dare più spazio ai CSS).
Ho preparato una prima versione, sia scaricabile, sia visualizzabile. Per il momento solo la homepage è validata XHTML.

Sto proponendo le modifiche agli sviluppatori ufficiali del CMS.
Vedremo cosa mi rispondono...

Primo giorno di riposo da impegni di studio, lavoro o laurea...
Per rilassarmi mi dedico un po' al mio giardinetto zen: ho cambiato motore che gestisce il mio sito.
Sono passato da Ez Publish a Flatnuke.

EZ è il CMS (Content Management System: sistema per gestire i contenuti) più potente che io abbia mai visto.
Appunto: troppo potente. E quindi troppo macchinoso per un semplice sito personale.

Dalle mie parti si dice: il vento ci vuole ma non per spegnere le candele.

Flatnuke è molto carino. Leggero leggero. Poco codice dietro, molto personalizzabile (purché si conosca un po' di linguaggio PHP) e non ha bisogno di una base di dati alle spalle: fa tutto con file di testo.

Ancora c'è qualche problema con i CSS ma il grosso del trasloco ormai è fatto :).

Ora forse è il caso di tornare a pensare alla tesi... :)