Il convegno

Il convegno doveva illustrare i risultati del progetto RACER e far capire come ci eravamo mossi a 360° per realizzare il kit dell’accessibilità.

La parte sicuramente più interessante per i presenti era il lavoro sull’opensource, il tool per la validazione ed il monitoraggio poteva interessare solo quella nicchia che l’accessibilità la pratica tutti i giorni. Era un convegno, nasceva poco intrattivo, le aspettative erano basse.

Com’è andata

Sicuramente positiva l’affluenza. Un sacco di persone, puntuali alle 9.30 tutte sedute e frementi. I tempi sono stati rispettati e tutti sono riusciti più o meno a dire quel che dovevano. L’unico che forse non è riuscito a raccontare tutto, è stato Nicola Grassano sul panorama del FLOSS in Emilia-Romagna. Ha almeno potuto far sapere lo stato dell’arte e che EROSS esiste.

Oggettivamente non è andato lo streaming, ed è stato un peccato visti gli sforzi per riuscire ad avere almeno un collegamento di rete, che fino al giorno prima non avrebbe dovuto esserci.

Non è forse neanche passato il messaggio del perchè si era fatto l’incontro, e questo è un peccato.

Le nuove opportunità

L’obiettivo che mi sarebbe piaciuto raggiungere con questo incontro, e che si sarebbe dovuto sviluppare nel pomeriggio, era sulle nuove opportunità che si aprono a chi lavora sull’opensource.

E’ un messaggio che più volte ho cercato di far passare: l’opensource per noi, Italia, è il business ideale per chi lavora sul software. Perchè l’Italia è fatta di micro aziende che se riescono a mettersi in rete in modo efficace, possono raggiungere grandi risultati. Da noi una nuova Microsoft non può nascere, ma una grande rete di realtà brillanti, innovative e competenti, si.

Mostrare a chi lavora sull’open, che la Regione queste cose le favorisce, le incoraggia, le monitora, doveva servire a far capire che lo spazio può esserci. La Regione ha sposato il progetto Plonegov, ma è solo un esempio, non significa che tutti debbano usare Plone. Per questo motivo abbiamo fatto vedere che avevamo valutato anche altri prodotti, validi e diffusi. Se solo le comunità uscissero dalla rete e le aziende riuscissero a fare rete tra loro e con le PA che usano i prodotti open, si potrebbe costruire un sistema di enne reti.

Questo il messaggio che sottintendeva tutto l’evento, queste le nuove opportunità: ragazzi c’è spazio, noi vi sosteniamo e ci crediamo.

Il barcamp

Il bacamp dovrebbe essere una non conferenza. Abbiamo diviso gli interventi in due sale:

• una per Plonegov, a cui la Regione ha appena aderito
• l’altra per accessibilità e cms diversi da Plone

Importante è stata l’apertura di ASPHI che con la sempre efficace demo di Marina Vriz ha fatto vedere come naviga un cieco. Tutte le volte scopriamo che c’è un sacco di gente che non ne ha un’idea e ne resta stupita. Poi si sono susseguiti una serie di interventi sull’accessibilità, corsi, eventi e progetti, più 7-8 speech specifici sui CMS accessibili. CMS non tutti stranieri, CMS non tutti open (es. sharepoint, che non è solo un cms)

Com’è andata

Rete e streaming, male, peggio del mattino. Se non altro il pranzo offerto mi han detto che non era male, e qui dobbiamo dire che l’organizzazione dell’albergo ha funzionato.

Plonegov

Per quanto mi hanno riferito nella parte di Plonegov, le cose sono andate decisamente bene. E’ stato un vero barcamp, con domande, confronti anche duri ma costruttivi, molta interattività e informalità. La gente davvero si è arricchita, ha conosciuto i progetti degli altri e ci sono stati molti scambi e ipotesi per sviluppi futuri. La sala non era grande, il tema molto focalizzato e verticale. Ha funzionato.

CMS e accessibilità

Io mi sono trovato a gestire la parte più ampia e generalista, con interventi un po’ su tutto, che rischiavano quindi di diventare superficiali. Cosa che è avvenuta, in parte. Ho provato a far capire che lo spazio era aperto, che la Regione offriva solo il palco (facendomi sempre da parte) e che chiunque avrebbe potuto dire la sua. Ma molti relatori e buona parte del pubblico, devo ammettere,  non avevano esperienza di barcamp (io per primo): la cosa non ha funzionato. Mi sono trovato a presentare le relazioni e i relatori, mentre avrei solo voluto far rispettare i tempi e dare la parola a qualcuno del pubblico per le domande. Ammetto che la mia inesperienza e poca abilità nel condurre una platea forse, non ha fatto passare molto bene il concetto di non-conferenza.

La sala era troppo ampia, i temi troppo vari, le persone un po’ impreparate al modello “barcamp” hanno fatto si che pian piano l’attenzione calasse e la sala si svuotasse.

Non è stato un successo come evento in sè, ma penso che tutti abbiano apprezzato il fatto che finalmente una Pubblica Amministrazione (PA) desse spazio e sposasse l’opensource.

Qualche link

• Tutte le presentazioni
• La pagina del barcamp
• Come i campers hanno vissuto l’evento “durante”
• Qualche commento a posteriori:
  • Luca Sartoni (colpito dallo screenreader)
    
  • Elena Franco (abbastanza delusa)
  • Commenti su Facebook
  • e la discussione su Linkedin

Dalla trincea una strategia per affrontare
l’accessibilità di Plone e dell’opensource:
il nuovissimo progetto Racer darà l’impulso necessario
alla nuova “offensiva” della Regione Emilia Romagna

Naplone Bonasource

Fratello mio, una buona notizia finalmente!
Quando la guerra per l’accessibilità sembrava ormai persa, un evento insperato: il nostro alleato, la Regione Emilia-Romagna ha deciso di fare la difficile scelta di cambiare CMS e ha scelto Plone. Anni di logorante difesa del fronte, vedono finalmente i tempi maturati per una nuova offensiva su tutto il territorio. Adotteremo questa nuova arma in un attacco a tenaglia, sfruttando un’idea nata già all’inizio del conflitto.

L’idea se ricordi era semplice: l’accessibilità nel 2004 dava l’opportunità di far crescere professionalmente le nostre aziende. Se la crescita fosse stata fatta su prodotti open avremmo potuto competere a livello internazionale. Se in più si fosse riuscito a trasformare la caratteristica di avere un tessuto fatto di centinaia di piccolissime aziende, da difetto a vantaggio, coordinando i micro sviluppi di ciascuna di esse, il salto sarebbe stato perfetto.

Una strategia innovativa: il progetto Racer

Come sai, l’accessibilità da sola non ha sfondato, le coscienze non sono state scosse dagli obblighi morali e l’impeto è ormai esaurito. Serve una nuova strategia, perchè l’attacco frontale si è rivelato inefficace. Ci siamo contati, e reclutato nuove forze per accerchiare il nemico. E’ nato il progetto Rete per l’accessibilità della Regione Emilia-Romagna (RACER) che darà l’impulso di una nuova offensiva.

RACER, dopo un anno di lavoro nelle retrovie, ci ha dato un nuovo esercito, fatto di:

• artiglieria: un sistema di validazione automatica dell’accessibilità (e qualità) aggiornabile, open, collegato ad un progetto internazionale (AChecker) e realizzato da chi la materia la conosce perchè la studia (Università di Bologna)
• intelligence: un sistema di monitoraggio costante, basato sul validatore, per mappare lo stato dell’accessibilità di tutti i siti presenti nel suo database
• cavalleria: un kit fatto di soluzioni pronte, fatto di prodotti open, di formazione (anche in e-learning e riusabile);
• fanteria: la rete, fatta di aziende e amministrazioni che usano le soluzioni del kit o lavorano sull’accessibilità

Le truppe sono ormai schierate: il Laboratorio di Usabilità e accessibilità del CSI sta rifinendo l’interfaccia del validatore, prima che lo puntiamo sul nemico. Il sistema di monitoraggio è pronto al 70%, ma ha già raccolto i dati che ci servono: ora sappiamo dove si nascondono i nostri avversari! Il kit è già on-line, aspetta solo il segnale della carica:

• in prima file c’è una selezione di 6 CMS sui quali abbiamo pubblicato tutto lo studio sui requisiti e caratteristiche che hanno, frutto del lavoro fatto per scegliere il  CMS della Regione;
• nelle retrovie abbiamo sufficiente materiale formativo, libri e learning object caricati su SELF (il sistema di e-learning federato della regione) per supportare l’attacco.

Il pezzo mancante

Che cosa manca all’offensiva? Ci serve ancora un po’ di tempo: validatore e monitor, saranno terminati entro fine anno, ma il kit dovrebbe ancora arricchirsi di 3 elementi, che stiamo per realizzare:

1. Almeno un corso in e-learning su Plone di livello base, per i redattori
2. Le modifiche al backoffice di Plone per renderlo conforme alla 4/2004
3. Un set di prodotti a norma, che trasformino Plone nel groupware che ci manca.

Potremmo già attaccare, perchè Plone, preso, così com’è, di fatto è accessibile, non è 100% a norma, ma è accessibile. I 2 test fatti con utenti disabili di ASPHI sul frontend, sono positivi anche se segnalano difetti minimi. L’analisi che ho fatto sul backoffice evidenzia che sia quasi tutto accessibile. Serve poco, ma non possiamo permetterci errori, non avremo la forza per un secondo attacco.

Aspetteremo prima di avanzare, prima sistemeremo il CMS e i vari prodotti per il groupware. Ma non lo faremo da soli, ci aiuterà l’elite della nostra fanteria, la community network sull’e-inclusion, la rete di PA del Progetto telematico della Regione Emilia-Romagna.

Ciò che ci da ancora coraggio è che non lo faremo solo per noi stessi, ma per tutti quelli per cui combattiamo da anni per l’accessibilità.

1. Dalla 4/2004 alle wcag 2.0
2. Dalle wcag 2.0 alla 4/2004
3. Misurazione sul campo dei requisiti

E la proposta per i nuovi requisiti

Riportiamo in tabella la sintesi dei requisiti WCAG 2 che si propongono, e la corrispondenza ai requisiti dell’allegato A.:

Riportiamo in questa seconda tabella i requisiti che si propone di mantenere dall’allegato A e la loro corrispondenza alle WCAG 2

Dalle due tabelle precedenti si può quindi concludere che quasi tutti i requisiti dell’Allegato A si possono mappare sulle WCAG 2, a patto di far decadere alcuni requisiti che non costituiscono ostacolo, o che non sono in linea con il web di oggi.

Se si accettano quindi i presupposti:

1.     Requisiti che abbattano le vere barriere di accesso

2.     Requisiti internazionali che non limito l’adozione di software stranieri

La conclusione porta a suggerire di adottare il seguente sottoinsieme ponderato dei criteri di controllo delle WCAG 2

I criteri di successo essenziali

Percepibile

1.1 Alternative testuali: Fornire alternative testuali per qualsiasi contenuto non di testo in modo che possa essere trasformato in altre modalità fruibili secondo le necessità degli utenti come stampa a grandi caratteri, Braille, sintesi vocale, simboli o linguaggio più semplice.

1.1.1 Contenuti non testuali: Tutti i contenuti non testuali presentati all’utente hanno un’alternativa testuale equivalente che serve allo stesso scopo, ad eccezione delle seguenti situazioni (…)
L. 4/2004: 3, 7, 8, 14

1.2  Media temporizzati: Fornire alternative per i media temporizzati.

1.2.1 Solo audio e solo video (preregistrati): Per i media preregistrati di solo audio e di solo video, a meno che questi non costituiscano un media alternativo ad un contenuto testuale chiaramente etichettato come tale, vengono soddisfatti i seguenti punti (…)
L. 4/2004: 3

1.3 Adattabile: Creare contenuti che possano essere rappresentati in modalità differenti (ad esempio, con layout più semplici), senza perdere informazioni o la struttura.

1.3.1 Informazioni e correlazioni: Informazioni e relazioni: Le informazioni, la struttura e le relazioni interne alla presentazione possono essere determinate tramite programmi oppure sono disponibili in forma testuale
L. 4/2004: 1, 9, 10, 11, 13, 14, 19

1.3.3 Caratteristiche sensoriali Le istruzioni fornite per comprendere ed operare sui contenuti non devono basarsi unicamente su caratteristiche sensoriali dei componenti quali forma, dimensione, ubicazione visiva, orientamento o il suono.
L. 4/2004: -

1.4 Distinguibile: Rendere più semplice agli utenti la visualizzazione e il sonoro dei contenuti, separando i contenuti in primo piano dallo sfondo.

1.4.1 Uso del colore: l colore non deve essere utilizzato come unica modalità visiva per rappresentare informazioni, indicare azioni, richiedere risposte o come elemento di distinzione visiva.
L. 4/2004: 4, 11

1.4.3 Contrasto (minimo): I testi e le immagini contenenti testo devono avere un rapporto di contrasto di almeno 4.5:1, fatta eccezione per i seguenti casi (…)

L. 4/2004: 6

Utilizzabile

2.1 Accessibile da tastiera: Rendere disponibili tutte le funzionalità tramite tastiera.

2.1.3 Tastiera (nessuna eccezione): Tutte le funzionalità del contenuto sono utilizzabili tramite un’interfaccia di tastiera senza richiedere tempi specifici per le singole battute.
L. 4/2004: 16

2.2 Adeguata disponibilità di tempo: Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti Regolazione tempi di esecuzione

2.2.3 Nessun tempo di esecuzione: Le temporizzazioni non sono indispensabili per la tipologia di contenuto, ad eccezione fatta dei media sincronizzati ed eventi in tempo reale.
L. 4/2004:

2.3 Convulsioni: Non sviluppare contenuti che possano causare attacchi epilettici.

2.3.2 Tre lampeggiamenti: Le pagine Web non devono contenere nulla che lampeggi per più di tre volte al secondo.
L. 4/2004: 5

Robusto

4.1 Compatibile: Garantire la massima compatibilità con i programmi utente attuali e futuri, comprese le tecnologie assistive.

4.1.1 Analisi sintattica (parsing): Nel contenuto implementato utilizzando linguaggi di marcatura gli elementi possiedono tag di apertura e chiusura completi, sono annidati in conformità alle proprie specifiche, non contengono attributi duplicati e tutti gli ID sono unici, salvo il caso in cui le specifiche permettano eccezioni.
L. 4/2004: 1

4.1.2 Name, Role, Value: Per tutti i componenti dell’interfaccia utente (inclusi ma non limitati a: elementi di un modulo, collegamenti e componenti generati da script), name (nome) e role (ruolo) devono essere determinati programmaticamente; stati, proprietà e valori che possono essere impostati dall’utente devono essere impostabili da programma; e le notifiche sui cambi di stato di questi elementi devono essere rese disponibili ai programmi utente, incluse le tecnologie assistive.
L. 4/2004: 3