Oggi si parla molto di Responsive, parola utilizzatissima nell’ambito della progettazione web contemporanea, non sempre collocata nel modo corretto o con l’accezione giusta. A questa parola qualcuno preferisce invece il termine Adaptive come Aaron Gustafson in Adaptive Web Design, edito da Easy Readers.

Proprio in questo libro Aaron focalizza l’attenzione su tre concetti teorici che stanno alla base di questa tecnica di progettazione, fondamentali per coglierne la portata. Dunque, al di là della terminologia adottata, vediamo quali sono queste tre nozioni.

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:

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

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.

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.

Sarebbe 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

• Plugin su plone.org
• Plugin su Python Cheeseshop

When Web pages load and run things

Let's start with CSS. Browsers load HTML source from the Web. Inside the page you will find resources that are CSS file. Immediately the resource is loaded and the rules inside are applied to your HTML.

Now switch to Javascript resources. For Javascript... it's the same. The Javascript code is executed as soon as it is found in the page...

...but for this reason, when we need to act using Javascript on an already loaded DOM, we rely onto Javascript events.

We read immediately the code, but the execution is postponed later, when the page is fully loaded.

As the use of jQuery became standard for those tasks (especially in Plone) we always use something like this:

jq(document).ready(function() {
    // do something
});

When this lead to problems

Although we have really no choice, there are some cases where this "postpone things" is not perfect: when we need to apply (using Javascript) CSS classes on page elements at page load time.

But we can't avoid making those actions when page is loaded.

If we don't rely on onload event, we have no ready DOM to traverse. So we can't load and change a DOM node if the page is not fully loaded (even if we put the Javascript script after the HTML that define the node).

<html>
<body>
    <div id="foo">Hello world</div>
    <script type="text/javascript">
    <!--
        var foo = document.getElementById("foo");
        alert(foo.innerHTML);
    // -->
    </script>
</body>
</html>

The code above is bad, even if you are using or not jQuery... So we really need to wait for the moment when DOM is ready. You can't act of the page DOM before it is fully loaded.

However: what is the problem applying CSS style when the DOM is loaded?

The nasty effect can be a visual flip.

The page in the browser show the DOM node with the original CSS style, then after some time (that can be not so brief sometimes if the page is full of elements and heavy scripts) the Javascript engine run your code, and the node is changed: your new CSS class or your new scripted style is applied.

<html>
<head>
    <style type="text/css">
    #foo {
        background-color: red;
    }
    </style>
    <script type="text/javascript">
    <!--
        window.onload = function() {
            ... MANY OTHER EXPENSIVE OPERATIONS
            var foo = document.getElementById("foo");
            alert(foo.innerHTML);
        }
    // -->
    </script>
</head>
<body>
    <div id="foo">Hello world</div>
    ... A LOT OF MANY AND MANY HTML NODES
    <script type="text/javscript">
    <!--
        var foo = document.getElementById("foo");
        alert(foo.innerHTML);
    // -->
    </script>
</body>
</html>

A practical example

A customer ask us to develop a Plone portlet that:

• show some random images when the page is load
  
• works behind a reverse proxy (Varnish)
• works with Javascript disabled (accessibility and graceful degradation)

Step 1

Varnish is caching all our resource, images and also HTML for every page. We can't (and don't want) change this.
How to cache everything but some little images inside a portlet?

The idea is to use Javascript  for performing AJAX request for this portlet and obtain a structure of data. The cache of this kind of request can be avoided easily.

Step 2

So we are able to load an HTML for the portlet without images then, when the DOM is ready, we can populate the portlet waiting for the AJAX call to the server. For some time the visitor see and empty portlet that magically begin load images. The effect is pleasant (at least... it's not annoying).

But we can't!
The portlet must work also with disabled Javascript... So we must load random images also when the page is loaded.

NB: if the visitor use a browser with Javascript disabled, we can only give him some random pre-loaded images, but we can't prevent Varnish cache of the whole page. Reloading the same page will show him the same images for some minutes. This is acceptable for us (and for the customer!).

Step 3

The final result is to load the first "static" images in the portlet itself, then use Javascript as described at step 1: changing those images with new ones obtained from AJAX call.

This lead to the ugly visual flip effect I talked above.

I can't explain why (this is not my work), but see an empty section that is filled after a little delay is not ugly... instead seeing a set of images that suddenly change to other is... bothersome!

Step 4?

Ok, so we can simply load static images hidden by some CSS class, then using Javascript we can show them only after the AJAX call and...
Opss!

But in this way we don't see any image when Javascript is disabled!

Ok... step 4 aborted.

Scripted CSS Injection

The perfect world is the one where the step 4 is performed, but only with Javascript enabled.

I need a CSS that is loaded early like all other CSS in the page (so its style is applied immediately to the page) but only when Javascript is enabled.

I found a way to do this, but surfing the web I was not able to find other example like this one. So I called this approach Scripted CSS Injection (SCI)... maybe someone can point me to other original name or example?

However... how this works? Simply generating the additional CSS... with Javascript!
For this we use the standard window.write Javascript API. The window.write command is used commonly to write HTML inside windows (is more common to use it in popup windows for generating the contained HTML from scratch).

The additional Javascript is load in the page head section and it doesn't wait for DOM load. The one in our product is only one line:

document.write('<style type="text/css">.hideFlag img {display: none}</style>');

As I said at the beginning, Javascript is interpreted as CSS, so immediately when found in the page.
The browser will add to HTML the style node immediatly.

What is nice of SCI approach is obvious: a browser with no Javascript support can't add the CSS rule to the page!

Fairytale gone well

This technique finally lead us to a portlet that:

• will show cached images if without Javascript support, but images are still random (chosen server side and changed with some delay)
• will show random (and not cachable) images client side if Javascript is enabled
• No ugly visual flip effects. With Javascript enabled static images are loaded hidden, then new dynamic ones are taken from the server and show. Thanks to SCI approach.
  

For more info, check the code of auslfe.portlet.multimedia.

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