Personal tools

Legge Stanca

Feb 07, 2012

Accessibilità: cosa sta succedendo?

Ecco alcuni appunti sull'aggiornamento della Legge Stanca, le WCAG 2.0, l'accessibilità e chi sta cercando di fare il punto sulla situazione

Capire cosa stia succedendo non è affatto semplice. Qualcosa si sta muovendo, ma le notizie non sono molte, anche in Italia: tutto sembra tacere da troppo tempo.

Già a settembre 2011 volevo scrivere qualcosa sull'aggiornamento dei requisiti della Legge Stanca, senza riuscirci. Sono stato mosso da vari eventi che vorrei condividere con voi. E' un peccato che alcuni dei link raccolti non siano permanenti sul sito in questione.

Nel testo del DM 8 luglio 2005, con gli aggiornamenti (ma datato 2010), e sul documento di presentazione delle linee guida dei siti web della PA, avevo letto che la consultazione che sarebbe seguita alla proposta di aggiornamento 2011 (avviata l'11 maggio) si era conclusa l'11 luglio, cercando di fare luce sulla situazione nel documento delle linee guida stesso avevo anche letto anche la nota 17. Eccola:


Al momento dell’aggiornamento delle presenti Linee guida, l’Allegato A del Decreto Ministeriale 8 luglio 2005 è in via di revisione per permettere un adeguamento della normativa italiana alle evoluzioni degli strumenti tecnologici e delle regolamentazioni internazionali intervenute dalla sua pubblicazione. Attualmente, terminata la fase di consultazione pubblica, la proposta di adeguamento è stata notificata alla Commissione europea, ai sensi della Direttiva 98/34/CE, e potrà essere adottata al termine del periodo di statu quo previsto (settembre 2011). Si veda: Direttiva 98/34/CE".


Seguendo quest'ultimo link avevo trovato scritto che la fine del periodo di status quo era stato il 22 settembre 2011, cosa che suggeriva senza troppe ambiguità che questo fosse l'ultimo aggiornamento entrato in vigore.

Pensai immediatamente: e perché nessuno ne parla sul web? Forse mancava solamente una pubblica approvazione da parte del gruppo di lavoro e un aggiornamento delle date?

Allo stato attuale, diversi Enti Pubblici, tra cui alcune Regioni, considerano già la possibilità di fornire una doppia scelta: conformarsi ai vecchi requisiti Stanca (22) o ai nuovi (12), aggiornati dal DM e basati su un adeguamento alle WCAG 2.0.

In generale, cosa si può dire sulle novità? Alcune di queste sono sicuramente l'utilizzo di javascript “accessibile” e quindi javascript è inserito tra le tecnologie utilizzabili. Chiaramente però è necessario che sia implementato nel rispetto dei requisiti.

Senza entrare troppo nello specifico di tutti i requisiti riformulati, ne vorrei segnalare semplicemente uno sul quale occorre porre attenzione, fin dalla fase iniziale di progettazione:

Requisito 11 - Assistenza nell'inserimento di dati e informazioni

Questa è sicuramente una fase del progetto che va pianificata e su cui difficilmente sarà possibile intervenire a posteriori in maniera completa.
Al di là dei suggerimenti e dell'informare l'utente sulle sue interazioni, la revisione e la correzione delle informazioni inserite, anche a posteriori, implica l'esistenza di funzionalità che permettano queste operazioni.

In sostanza occorre comunque essere allineati con le WCAG2.0, le linee guida del W3C in materia, le quali il 3 gennaio 2012 sono state affiancate dagli aggiornamenti dei due principali strumenti di comprensione e di apprendimento delle tecniche per le WCAG2.0.

Sicuramente per districarsi in materia occorre ripartire anche da questi strumenti aggiornati che ci sono stati messi a disposizione.

All'estero si cerca di fare il punto della situazione. Lo si è fatto da poco a San Diego, con una bella e articolata conferenza sull'accessibilità, (#CSUN12), the CSUN 27th Annual International Technology and Persons with Disabilities Conference

Questo è un bell'articolo che parla di alcuni punti emersi alla conferenza,
del disagio, non solo italiano, nel cercare informazioni chiare anche per i principianti dell'argomento e quindi, della possibilità di fornire nuovi strumenti di consultazione semplificati (vedi anche questo) e dell'approccio "Be the fire fighter, not the cop" ovvero del focalizzare l'attenzione sul processo di aiutare a capire e a formare sull'argomento e non l'avere come fine il punire.

A Roma ci prova fra poco 10 maggio 2012 un manipolo di coraggiosi con un piccolo incontro di aggiornamento Innovazione tecnologica e responsabilità sociale:


Il punto sulla Legge 4/2004 dopo 8 anni e le prospettive future per l'accessibilità del Web
Interverranno (in ordine alfabetico):
- Onorevole Ileana Argentin (Partito Democratico)
- Sergio Bellucci (Net Left)
- Marco Bertoni (Esperto di accessibilità del Web)
- Antonio De Vanna (Capo dell’Ufficio Accessibilità dei sistemi informatici CNIPA)
- Ennio Paiella (Fondazione Asphi)
- Nicola Palmarini (IBM)
Il convegno si svolgerà giovedì 10 maggio 2012 a Roma presso l'Associazione Culturale Centofiori, Via Goito 134 alle ore 17

Seguite l'evento su Facebook. (ci saranno aggiornamenti anche sulla location)

Sarebbe davvero bello se questo silenzio si sciogliesse e potessimo capire insieme quali sono le nuove prospettive. Quali le implementazioni possibili, le soluzioni pratiche, le opportunità per l'accessibilità che il web può offrire oggi. Come ho imparato fin dal primo giorno da un vecchio amico che fa formazione in questo settore, l'accessibilità è un processo e il processo va anche aggiornato. 

Bibliografia:

03-01-2012
WCAG Techniques Updated - Learn about the informative guidance

22-09-2011
Legge Stanca e accessibilità: cosa cambia?

15-06-2011 
Aggiornamento Legge Stanca

Documenti:

11-12-2008
Web Content Accessibility Guidelines (WCAG) 2.0
W3C Recommendation 11 December 2008

03-01-2012
Techniques for WCAG 2.0

03-01-2012
Understanding WCAG 2.0

Sitografia:

http://www.w3.org/WAI/

http://www.w3.org/WAI/Technical/Activity

http://radharc.com.au/2012/01/the-good-points-of-wcag2/

Link di cui si è persa la consistenza nel sito di origine:

http://www.innovazionepa.gov.it/TestoPDF.aspx?d=19451

http://www.innovazionepa.gov.it/lazione-del-ministro/linee-guida-siti-web-pa/presentazione.aspx

http://www.innovazionepa.gov.it/media/835828/linee_guida_siti_web_delle_pa_2011.pdf

 

Jul 21, 2010

Migliorare l'usabilità dei link interni in TinyMCE

Analisi di collective.tinymceplugins.advfilelinks, un'alternativa al plugin di TinyMCE per i link interni a Plone che permette di gestire in modo differente i link a file del sito.

La Regione Emilia Romagna sta lavorando alacremente al miglioramento dell'accessibilità e dell'usabilità di Plone.

Dato che il futuro dell'editor WYSIWYG in Plone non è più Kupu (difficilmente personalizzabile e non troppo supportato) ma TinyMCE, già da tempo la scelta è stata di passare a TinyMCE anche nella versione 3 di Plone, usata in vari siti regionali.

Migliorare TinyMCE è più semplice che Kupu e lo dimostra come è stato possibile da parte nostra aumentarne le funzionalità per venire incontro ad alcune delle richieste della Legge Stanca (modifiche di cui si è discusso in un altro post, e ora integrate nella release ufficiale già dalla versione 1.1rc9); Altro particolare: trovo importante che questo editor esista anche come progetto indipendente.

Altre novità: la gestione dei link

Una richiesta recente per aumentare l'usabilità dei documenti è stata la seguente:

Modificare Plone in modo che i link interni, se fatti a contenuto di tipo File, mostrino l'icona del tipo di contenuto e la dimensione del file stesso

Una simile modifica aumenta l'usabilità generale della pagina, nonché impatta col Requisito 19 della Legge Stanca.
Dopo una prima analisi è risultato chiaro come fosse necessario scrivere un nuovo plugin per TinyMCE.

Come funziona collective.tinymceplugins.advfilelinks?

Il prodotto rilasciato fornisce il minimo delle modifiche possibili a TinyMCE (ma non minime quanto avrei voluto... ne parliamo dopo). Si tratta di un un plugin aggiuntivo (e per fortuna la presenza di plugin è prevista non solo dall'editor ma anche dalla sua configurazione di Plone) che sostituisce quello predefinito di Plone per i link interni (dal nome autoesplicativo plonelink).

Dopo un'analisi attenta di come poter ottenere le funzionalità richieste e della flessibilità delle API di TinyMCE, su indicazione della Regione stessa abbiamo preso la seguente strada, forse un po' limitata ma di minimo impatto sullo sviluppo e con una resa eccezionale se il browser è aggiornato:

  • I link a file acquisiscono un nuovo attributo type (previsto dallo standard HTML anche se poco conosciuto) ed viene fornito un CSS aggiuntivo contenente varie regole per fornire l'icona.
    Esempio:
    a[type='application/pdf'] {
        background: url(pdf.png) no-repeat 0 50%;
        padding-left: 20px;
    }
    Questo tipo di regola CSS ha un buon supporto (da Internet Explorer 7 in poi).
  • La dimensione del file è prima di tutto inserita nel title del link (che normalmente il plugin originale non fornisce) ma un buon effetto è ottenuto associando una ulteriore regola CSS:
    a.internal-link-tofile:after {
    	content: " ("attr(title)")";
    }
    Questa magica regola CSS (fa parte dello standard CSS 2, per quanto Internet Explorer la supporti solo dalla versione 8 in poi) inserisce del testo aggiuntivo dopo i link con classe internal-link-tofile.
    Il contenuto di questo testo è preso dall'attributo title, ma vi vengono aggiunte delle parentesi. Ovviamente questa classe CSS aggiuntiva è inserita dal nostro plugin in aggiunta alla già nota internal-link.

L'ultima funzionalità è forse la più interessante e per quanto il metodo usato sia davvero poco invasivo e l'effetto finale a dir poco bello, il limite ad avere Internet Explorer 8 è ancora grande.
E' comunque sopportabile? Sì, dato che l'attributo title rimane comunque disponibile agli utenti (e agli Screen Reader) in tutti i casi.

Preview degli effetti del Plugin

Note tecniche di estendibilità

TinyMCE per Plone sfrutta chiamate AJAX per richiedere al server informazioni sui contenuti. Come sempre le modifiche lato server sono minime e perfettamente integrate con quanto Plone già fornisce.

E' bastato fornire un nuovo adapter.

  <adapter
        for="Products.ATContentTypes.interface.IATFile"
        provides="Products.TinyMCE.adapters.interfaces.JSONDetails.IJSONDetails"
        factory=".adapters.JSONDetails"
        />

Grazie alla ZCA, questo adapter aggiuntivo interviene solo per i contenuti di tipo File o sottotipi (a volte ho l'impressione che senza adapter i plonisti non vivrebbero più!).

I problemi maggiori sono lato client... L'idea sarebbe come sempre estendere e non sovrascrivere. In un mondo perfetto questo plugin si sarebbe dovuto integrare con quello preesistente, sfruttandone tutto il codice presente.

Non mi è ancora chiaro se questo non è stato possibile per limiti miei, del plugin stesso, o di TinyMCE, ma il risultato per quanto funzionante è anche una copia di molti dei file originali (una forma di branch del plugin)... probabilmente non dormirò di notte per aver dovuto copiare i file di lingua... ma dopo tutto è una versione alpha!

Il limite maggiore di TinyMCE attualmente è che non usa jQuery (per quanto ci sia un progetto che integra jQuery e TinyMCE) e soprattutto che non c'è uso di eventi Javascript.

Selezione link interni in TinyMCESarebbe stato bello (ma che dico bello! Utile) se al click del mouse sul pulsante radio che seleziona un file piuttosto che un qualunque altro documento a cui associare il link, venisse lanciato un evento Javascript... evento al quale un buon plugin per jQuery avrebbe potuto reagire per eseguire azioni...

Per ora questo non pare possibile, ma sarebbe un buon passo avanti per TinyMCE.

Nota sul namespace

Sono rimasto colpito nel vedere come sulla collective ci siano così pochi plugin the TinyMCE (l'unica eccezione pare essere collective.tinymcetiles). Ci sono state sanguinose discussioni in passato sull'uso di namespace a 2 o 3 livelli (ne ricordo una completa e interessante). In questo caso l'uso dei 3 livelli mi è parso opportuno.

Spero che in futuro altri contribuiscano al gruppo di plugin collective.tinymceplugins e figli!

Riferimenti

May 07, 2010

... and finally: what if they want tab inside Plone portlets?

A little demo (and the idea behind) for collective.portlettabber product

They want tab!

The request is quite common in recent layout that you can see all around the Web. Ok, "portlet" is common, but you can also find many examples of portlets with tabs.

What is this? The data inside portlets is split in sections that you can easily switch with a little Javascript code. The benefit is to put more information inside a tiny space, maybe showing to users only the most interesting ones when he arrive at your page.

Technically speaking this task is so simple that a blog post is not needed... but we don't know what kind of contents we want put inside the portlet tab.

Also the customer want to have the choice of use all (maybe the most part) of Plone portlets available is his installation... We really can't rewrite/overrider all portlets to get this...

...and finally (like everytime) accessibility. Data inside portlets must the accessible and the requirement 15 of the Stanca Act force us to make this available also with Javascript disabled.

Solution

Let's starts from what we can't lose:

  • accessibility of the page without Javascript
  • all Plone portlet usable as "tab"

For those two reasons the simplest way is to keep Plone portlet engine like it is. Plone portlets are working normally without Javascript, so why don't simply show tabs in only when Javascript is there?

This lead us to a solution. "Simply" generate portlet with tab using Javascript.

One more time again jQuery is our hero. The product add to Plone portal_javascript tool a new jQuery plugin for this. Is not a perfect plugin right now (is a composition of jQuery and normal Javascript OOP) but reach the target.

Here an example:

jq(document).ready(function() {
    var generatedPortlet = jq.tabbedportlet();

    generatedPortlet.makeTab("#portal-column-two .portletNews");
    generatedPortlet.makeTab("#portal-column-two .portletCalendar");
    generatedPortlet.makeTab("#portal-column-two .portlet-static-static");
    jq("#portal-column-two .visualPadding").prepend(generatedPortlet.getPortlet());
});

When page is loaded a new Javascript object is created, and calling makeTab method you can "steal" other existing portlets all around the page (simply giving a jQuery selector, a DOM element or a jQuery object wrapping the portlet).

The method also has other features, look at the pypi page below for more.

Every call to makeTab will remove the portlet and move the DOM elements of the portlet inside a new ones (that, for now, is not inside the document yet).

When you have finished, just put the result of getPortlet method wherever you want.

The final effect is quite good... the demo will show you the page with disabled Javascript, then (long life to Web Developer's Firefox extension) it is enabled again and the page reloaded...

What next?

The product is not so simple to be used by Plone site members (this is not named collective.portlet.tabber... :-))

A developer or a skinner must provide the additional Javascript inside a product/theme and he must know something about jQuery selectors... but after this starting setup... nothing more!

Another thing Ithat is not perfect is the Javascript structure, not a fully jQuery plugin. You can't fully rely on chaining right now.

More info?

http://pypi.python.org/pypi/collective.portlettabber

 

Apr 11, 2010

Change navigation behaviour with jQuery: collective.navigationtoggle

A requirement from one of our customer lead us to develop a very tiny Plone add-ons... After all jQuery make all the dirty work!

Navigation collapsedOne of the navigation portlet in the main site of our customer is done like the one you see on the left.

The element with arrow icon is unique and very important, but is not the element itself that links to an important document. The real useful information for end users are elements inside the section with this special icon (the subelements).

If facts the different icon itself is not enough so the customer asked us to develop an expand/collapse feature to make possible to users to not be forced to visit the not-important-section, then choose one of the subelements. For user experience the first click is only a waste of time (it's matter of usability) as the general element you see in the navigation is only a way to keep together and categorize the real infos.

Question: how many not-important-section you have in your Plone sites? Folder that only show folder_listing view or useless welcome pages?

Navigation expandedHowever: what we developed in the first version of this site was a very simple (and not configurable) expand/collapse feature, you'll see on the right.

This was a Plone 2.1 site and what you see wasn't a real Plone navigation portlet. Important subelements were all loaded with the page and a simple Javascript script make them visible/invisible.

As we recently migrated this site to Plone 3, the question was: can we reproduce the same effect keeping the Plone real navigation... and this time make the feature more reusable?

Some of you can say at this point that there are already other dynamic Javascript/AJAX navigation system for Plone (for example, I well remember collective.portlet.explore) but the problem here is different... we don't want to make all navigation(s) entries expansible/collapsible but only one (or few).
Another important fact: this is the site of an italian public company, so it must follow the Stanca Act accessibility requirements (so very restrictive in matter of client side scripts technology) and a complete Javascript UI is not a good choice.

The role of jQuery

Instead of developing some new funny navigation system, our work was focused on making the most possible client side (whit an eye on graceful degradation like the Law say).

We used jQuery to obtain a cross-browser, configurable and simple plugin for Plone that make possible to chose on which navigation elements apply the expand/collapse feature. All this client side!

Welcome to collective.navigationtoggle.

The only server side component is a simple view that query the Plone catalog to show all element inside a given folder, and return all information needed by jQuery to generate navigation sub-elements on the fly (quite simple, isn't it?).

The view return only a JSON data structure, so the HTML is generated client side. How? The code create new navigation elements cloning existing ones from the navigation itself (using parents of the trigger element), then filling them using response data.

Is this way is possible that even a non-standard Plone navigation could works normally with this product (not so sure of this... to be honest some assumption are done, like the main element structure of the navigation that must be composed of UL and LI elements).

Cache

Two different problem there: prevent browser from caching server response for a too long time, but also prevent that if a user begin to click 10.000 times onto the navigation element this will send to the server one non cached request for every click.

The first problem is quite simple playing a little bit with HTTP header sent by the server, and adding timestamps with the client side request.

For the second problem we rely on jQuery.data() fantastic method, caching the generated HTML and preventing that expand/collapse actions will ask the server for the same data.

Configuration

Right now we have a real well-know problem to solve, so the product is targeted on developers. To configure it you must provide a tiny Javascript with line(s) of code like this:

jq.collective_navigationtoggle.toggle_elements.push("/foo1/foo2");

This is a simple Javascript array stored in the jQuery plugin namespace. Data provided must be the final part of the href attribute of links inside navigations portlet. This link will no more move the user to the target page but will be gifted with the expand/collapse feature.
All the magic left is done by the power of jQuery.

Plone 4 and jQuery 1.4

The product works on Plone 4 also... no problems with jQuery 1.4 (delivered with the next version of our favorite CMS, while Plone 3.3 still rely on jQuery 1.3), in facts dropping jQuery 1.3 support can reduce the Javascript code size and complexity (jQuery 1.4 has new fantastic features... take a look!).

However a real and pretty integration like with the Plone 3 theme right now is not available in Plone 4 also. Maybe in future I can work on this (Plone 4 Sunburst is not using anymore the IMG tag, instead it generate icon usin CSS classes). If you are interested and wanna help, you are welcome!

Nov 16, 2009

A Tiny step for more accessibility in Plone

In last months I'm keeping updated a branch of TinyMCE that can be very interesting for Italian users of Plone (but not only...)

For a preamble for all who didn't know nothing about it, lets me say some words on the Italian law for accessibility: the so called Stanca Act.

The Italian Legislation on Accessibility force all newly created public websites to keep 22 requirements, mainly taken from the WCAG 1.0.

For how Plone is designed (trying to fulfil the WCAG at AA level) a lot of required work is just done (I really like when this happen)!

There are only 2 requirements that keep our head busy every time we develop a new site for an Italian public agency:

Requirement 1
The (X)HTML must follow the Strict DTD.
Requirement 10
"[...] associate data cells and header cells in data tables that have two or more logical levels of row or column headers."

For us the requirement 1 is a fight against the Transitional DTD of Plone (see also the #4379). Of course, this mean we are always forced to fix manually some Plone templates, but at the end after 4 year this become a well know job!

The real problem is the XHTML code that users put inside the WYSIWYG editor... this must provide us XHTML Strict code someway!

When Kupu was the Plone choice this was a difficult... sometimes our choice was to put a layer between the editor work and the end user, fixing the code using the uTidylib!

In the perfect world the WYSIWYG editor itself must return us the XHTML Strict code...

Again: the requirement 10 is also a WYSIWYG editor problem. Kupu is not helping us to add additional cell info on created tables.

Welcome TinyMCE

The future (but already available) WYSIWYG editor for Plone 4 is TinyMCE.

The output code of TinyMCE is "more strict" than the Kupu ones... only some minimal fixes are needed. If facts the only validation error found right now if the use of the type attribute for ordered and unordered list (not available in XHTML Strict).

We are keeping updated a TinyMCE branch you can download and test from the collective; it fix the 2 problems described.

First of all: it's not using the type attribute again, but instead it applies a CSS class. An additional small stylesheet make the rest. For details see changes.

The other missing feature is to help the editor to add more attribute to table cells and headers. The simpler solution from the W3C is to provide the scope attribute.

When I started this task I was sure that this was going to steal me a lot of time... but again TinyMCE was a nice surprise!

The patch applied is simple; for some reason TinyMCE support the scope natively but it's disabled (probably only in the Plone version?). As you can see in changes done, my work was very quick (and again: I like when this happen)!

And now?

Keeping updated the code is a quite simple task, but I don't like the idea to branches forever. Also note that:
  • The first fix above is also valid for XHTML Transitional pages
  • The new scope attribute feature can be useful also outside a Stanca Law environment.

So?

We proposed to merge those changes in the TinyMCE core!

Keep one eye on #115 and #131!