Moving Islands, un progetto di Eupalinos Ugajin

Moving Islands

A LEA 20 in Second Life stanno accadendo strane cose. “The Cosmogony of Rafts and other improbable floating beings” dice la presentazione, ed è vero.

L’esposizione è formata dalle opere di numerosi artisti, più di 20, e senza dubbio costituisce quella che potrebbe essere definita una “Esposizione Collettiva di Arte Contemporanea”.

Per chi volesse visitare l’installazione, consiglio di alzare il volume dei suoni: molti sono suggestivi e completano l’esperienza sensoriale di fruizione dell’opera digitale, così come non mancate di provare l’interattività delle opere stesse. Qualità video la massima che la vostra scheda grafica vi permette, o come minimo almeno l’Advanced Lighting Model attivo (non è necessario attivare anche le ombre, per chi ha computer un po’ datati).

“Moving Islands” [Rafts] è un progetto collettivo di:
● Alpha Auer
● Artistide Despres
● Aston Leisen
● CapCat Ragu
● Cica Ghost
● Cutea Benelli
● Derek Michelson
Eupalinos Ugajin
● Haveit Neox
● Kake Broek
● Kikas Babenco
● Livio Korobase
● Maclane Mills
● Marmaduke Arado
● Maya Paris
● Meilo Minotaur
● Merlino Mayo
● Oberon Onmura
● Ole Etzel
● Pallina60 Loon/Samira Tammas
● Scottius Polke
● Simotron Aquila
● Takio Ra
●Uan Ceriaptrix

 

Annunci

AAC: Augmentative and Alternative Communication

Augmentative and Alternative Communication

La Augmentative and alternative communication (AAC) include tutte le forme di comunicazione diverse da quella orale utilizzate per esprimere pensieri, necessità, desideri ed idee. Fare una faccia, un gesto, usare simboli o immagini, scrivere sono forme di comunicazione AAC.

Le persone con gravi problemi di linguaggio o espressivi fanno riferimento alla AAC per supplire il parlato attuale o rimpiazzare le parti non funzionali. Per aiutare queste persone ad esprimersi sono disponibili speciali aiuti, high tech e low tech, come dispositivi elettronici e lavagne con simboli. In questo modo queste persone potranno aumentare (la A di augmentative) le proprie interazioni sociali, migliorare le performance a scuola e sentirsi maggiormente auto sufficenti.

Gli utenti AAC non devono abbandonare l’uso del parlato, se sono in grado di utilizzarlo. Gli aiuti e le attrezzature AAC vengono utilizzate per migliorare la loro comunicazione.

E’ un campo ancora un po’ sconosciuto dell’accessibilità, ma probabilmente è ora di iniziare a parlarne anche per quello che riguarda il Web Design. C’è chi fa dei miracoli con la AAC, per esempio Stephen Hawking. Speriamo che le WCAG 3.0 se ne ricordino…

Anche Stephen Hawking, un noto fisico affetto da atrofia muscolare progressiva, usa AAC con risultati a dir poco sorprendenti.

 

Photoshop e il testo sgranato

Anche se non è il suo lavoro, molti grafici utilizzano Photoshop per realizzare bozzetti da utilizzare come traccia per siti Web, blocchi di testo segnaposto compresi. È facile capire perché: oltre a una forse precedente esperienza con il programma, certamente Photoshop è un potentissimo software per fare grafica bitmap.

Il problema del testo sgranato nasce quando si utilizzano font di piccola dimensione, il testo appare sgranato nonostante l’uso degli algoritmi di anti aliasing. Questo accade perché il testo viene riprodotto con i pixel a disposizione, e i pixel disponibili sono pochi (impossibile riprodurre accuratamente le curve e i glifi di un carattere con 9 pixel o meno…).

Non c’è molto da fare, anche se possono essere utilizzate alcune tecniche per rendere il testo di migliore aspetto. Molte sono ampiamente descritte sul Web ed alcune sono davvero molto articolate (ma davvero vale la pena di soffrire così tanto con Photoshop per fare layout per il Web che probabilmente nel passaggio a HTML/CSS verranno snaturati?), ne voglio però ricordare due che non appaiono frequentemente e permettono di ottenere dei risultati anche insperati.

In presenza di testo di piccole dimensioni, è consigliabile disabilitare l’opzione Larghezze frazionali nel menu del pannello Testo di Photoshop. L’effetto è senza dubbio visibile.

Disattivazione dell'opzione Larghezze frazionali in Photoshop

Il testo rimane comunque renderizzato a pixel, e i pixel sono pochi… si tratta soltanto di un piccolo escamotage che può essere utile per visualizzare in modo più preciso il testo a video, ma basta un leggero ingrandimento per sgranare nuovamente l’immagine. Che fare allora quando sia necessario poter disporre di un bozzetto liberamente ingrandibile e visualizzabile a monitor o stampabile con elevata qualità del testo? Qualche volta si renderizza il livello Testo o si converte in vettori il testo inserito, perdendo così qualsiasi possibilità di successiva modifica del testo stesso. Non è una prestazione entusiasmante, soprattutto a livello di bozzetto, dove le modifiche e le correzioni sono frequenti.

Una buona opzione è stampare il lavoro in un PDF: il testo nel PDF può essere reso vettoriale, anche se nel file di Photoshop vediamo tutti quei pixel. Essendo il testo vettoriale, qualsiasi ingrandimento ci fa un baffo.

Lo stesso testo ingrandito al 200% in Photoshop e in Acrobat. La differenza di rendering è notevole.

Al momento di stampare il PDF, semplicemente verificate che nelle opzioni di Output della finestra di dialogo Stampa sia attiva la casella di controllo Includi dati vettoriali.
Simpatico, vero?

La casella di controllo Includi dati vettoriali.

 

WordPress e Dreamweaver

Non è sempre facilissimo lavorare sui temi di WordPress e riuscire ad avere una vista di insieme poiché le pagine sono costruite dinamicamente a partire dagli elementi fondamentali come l’header, index, le barre laterali e così via. Inoltre, i temi sono quasi sempre in inglese e bisogna tradurre le stringhe.

La Vista dal Vivo di DW non ce la fa a gestire l’intrico degli include, e per riuscire a caricare tutti gli elementi contemporaneamente bisogna ricorrere ad alcune estensioni per Dreamweaver, come Themedreamer o WpBuilder, che permettono di simulare anche in locale le pagine complete.

L’uso di Themedreamer è molto semplice e permette di lavorare in locale. Nei vari componenti della pagina vengono posizionati dei contenuti finti, e l’interfaccia di Dreamweaver si adatta alla posizione del cursore nel codice.

Se il cursore è posizionato in un elemento HTML, si avrà la seguente vista, con la barra Proprietà che permette di lavorare sui tag:

elementi html nel tema

Mentre un clic su un elemento del tema provocherà la visualizzazione di tutti gli include nella barra Proprietà, in questo modo:

gli include in dreamweaver

Sono ovviamente disponibili tutti gli strumenti di Dreamweaver, il pannello CSS e così via.

Il design è un mezzo per raggiungere un fine

Pistola che spara all'indietro. Un cattivo design?

Si fa del design per uno scopo: di solito, si progetta un letto pensando di dormirci. Si progetta un orologio per conoscere l’orario. Il risultato di queste attività (il fine) dipende dal design di questi strumenti (i mezzi).

In presenza di un buon design lo strumento risponde così precisamente al fine che diventa parte dell’attività.

Invece di usare un letto, ci si dorme. Invece di usare un orologio, si guarda l’orario.

Si realizzano siti Web per molte ragioni, ma una prevale su tutte le altre: si realizzano siti Web che le persone possano usare. Questi siti verranno guardati, cercati, ascoltati, scartati, letti, stampati, qualcuno farà dei clic, scriverà nei campi dei moduli e verranno utilizzati da persone differenti che utilizzano periferiche di accesso diverse.

Se il risultato di un design è che qualcuno non può caricare una pagina o attivare un link, leggere un paragrafo o interpretare un’immagine, il design non è più un mezzo per raggiungere un fine, il design diventa un impedimento.

Accessibilità dei siti Web

Tempi di rinnovamento per l’accessibilità dei siti. Sarà l’effetto WCAG 2.0, sarà che dal Decreto Ministeriale 8 luglio 2005 son passati un po’ di anni e l’effetto moltiplicatorio per Web e tecnologie, è noto, funziona un po’ come l’età dei gatti e il decreto oggi appare un po’ vecchierello, insomma sia quel che sia un nutrito e ben congegnato gruppo di lavoro sta ridisegnando quelli che vengono definiti “i requisiti” fondamentali dei siti Web della P.A. affinché gli stessi possano essere definiti a norma della Legge 04/2004 (Stanca).

Inoltre, sotto il cappello del Formez è stato costituito un laboratorio, se così si può dire, denominato “Osservatorio Accessibilità” con compiti sia di analisi sia di supporto agli sviluppatori. Insomma, un bel traffico.

Nel periodo precedente, ho usato la forma “a norma” perché c’è un po’ di confusione sui termini “accessibile” e “a norma Stanca”.

La legge Stanca non è l’unica normativa di riferimento sull’accessibilità esistente sul pianeta. Gli Stati Uniti possiedono da tempo la Section 508, la mamma di tutte le normative sull’accessibilità (anche lei in revisione), le già citate WCAG del W3C (in questo caso non si tratta di una legge, ma di “raccomandazioni“, l’Australia possiede una propria legislazione, il Canada anche, così come la Francia, il Giappone e l’Irlanda (un elenco è disponibile all’URL http://www.w3.org/WAI/Policy/).

Tornando alla precedente affermazione, non è detto che un sito “a norma Stanca” corrisponda a un sito “WCAG compatibile”, o conforme alla Section 508, mentre tutti possono essere detti accessibili. L’obiettivo di tutte queste leggi e raccomandazioni è comune, ovvero ottenere l’accessibilità dei siti Web, e tutte si basano su Section 508 e WCAG per formulare le proprie richieste. Però, ciascuna normativa ha anche caratteristiche proprie (per esempio, la legge Stanca richiede l’uso di una DTD Strict, mentre le WCAG no). Probabilmente le WCAG 2.0. faranno da elemento collante e tutte le normative cercheranno di adeguarsi ai nuovi requisiti proposti dal W3C.

È un bene o un male? Non lo so, personalmente trovo le WCAG 2.0 ottime nei principi ma un po’ scarse nelle tecniche proposte (francamente, in qualche caso davvero di basso livello). Si potebbe obbiettare “Sì, d’accordo, ma l’accessibilità non riguarda gli standard, si occupa esclusivamente di proporre delle tecniche che rendano accessibili le pagine”.

D’accordo, ma propongo un esempio credo significativo per chiunque si occupi di accessibilità. Fra gli elementi più importanti per la navigazione delle pagine ci sono i titoli, gli header di cui molto abbiamo parlato su questo blog. È un elemento indiscutibile, chiunque abbia provato a navigare delle pagine con uno screen reader si sarà reso conto della fontamentale importanza dell’uso di una struttura corretta per delineare i contenuti delle pagine, e di come sia importante utilizzare in modo congruente ai contenuti gli elementi da <h1> a <h6>.

Ebbene, proprio su un argomento così basilare nelle “HTML e XHTML Techniques” è presente un esempio così fatto:

<head>   <title>Stock Market Up Today</title>
</head>
<body>
<!-- left nav -->
<div class="left-nav">
<h2>Site Navigation</h2>
<!-- content here -->
</div>
<!-- main contents -->
<div class="main">
<h1>Stock Market up today</h1>
<!-- article text here -->
</div>
<!-- right panel -->
<div class="left-nav">
<h2>Related links</h2>
<!-- content here -->
</div>
</body>

Rieccoci da capo. La pagina inizia con un <h2>, si passa a <h1> e si torna a <h2>. Non mi pare un bell’esempio.

Per questo e altri motivi mi piacerebbe che i nuovi requisiti della Stanca mantenessero l’intrinseca richiesta di pulizia e semantica, si semplificassero nella forma e facessero esplicito riferimento alle best practice più affermate. Personalmente trovo inaccettabile che sia per la Stanca sia per le WCAG una barra di navigazione fatta a colpi di <div> e <br /> possa essere dichiarata “accessibile”.

Per qualsiasi sviluppatore appena sensato gli elementi da utilizzare per le barre di navigazione sono <ul> e <li> per le voci, magari facendo precedere alla barra un titolo esplicito utilizzando l’elemento <hn> opportuno.

Insomma, mi piacerebbero dei requisiti un po’ meno “saputelli” e un po’ più di senso pratico, per esempio prendendo spunto anche dall’elenco di Best Practice dell’iCITA (Illinois Center for Information Technology and Web Accessibility) utilizzate dal “Functional Accessibility Evaluator 1.0.2” dell’ University of Illinois at Urbana-Champaign.

Libri di testo e accessibilità: eppur si muove…

Sono davvero molto contento di aver iniziato un percorso importante con un grosso editore di scolastica. Un progetto che coinvolge tre redazioni complete, dai responsabili editoriali a redattori, grafici, impaginatori e tecnici che realizzeranno gli output elettronici finali.

Tre progetti editoriali già individuati, venti persone coinvolte, un corso lungo e impegnativo da svolgere per me, ma certamente entusiasmante. I tre team sono molto motivati e in gamba, attenti al massimo nella comprensione delle tematiche e tecniche relative all’accessibilità.

Vien da dire “finalmente!”…

Accessibilità in perpetual beta

i fantastici quattroMeno male, verrebbe da dire leggendo il documento del CNIPA intitolato “Linee guida di progettazione e sviluppo per i siti delle Pubbliche Amministrazioni” a cura di CNIPA, Telecom, Elsag e Engineering.

Questo documento, dichiarato “versione perpetual beta”, che vai a sapere cosa significa, “è stata curato dal Raggruppamento Temporaneo di Imprese (Telecom Italia, Engineering Ingegneria Informatica, Elsag Datamat) incaricato della progettazione, realizzazione e gestione dei servizi relativi ai siti web e della relativa conduzione dei sistemi, con la supervisione del CNIPA”.

A che serve? Bella domanda. Dovrebbe essere un documento che   specifica linee guida per:

  • e presenti Linee Guida con lo scopo di suggerire un’impostazione per la progettazione e lo sviluppo di un sito web, individuando le domande e i contesti normativi di riferimento a cui dover rispondere prima di avviare la progettazione esecutiva;
  • e il documento Modello operativo a supporto delle Linee Guida per fornire risposte pratiche e operative per la progettazione di un sito web, attraverso la definizione di un set di regole per ciascuno degli elementi tipici (componenti) della progettazione di un sito istituzionale.

Nell’ambito del Sistema Pubblico di Connettività e Cooperazione (SPC).

È davvero curioso che i fornitori forniscano al loro cliente delle linee guida, mi immagino che chi scrive le regole venga poi escluso dagli appalti oppure sarebbe un bel conflitto di interessi, ma non è solo questo l’aspetto inquietante. Con la scusa dell’infrastruttura tecnologica a favore dell’interoperabilità e cooperazione fra le pubbliche amministrazioni (che di per sé è un principio encomiabile, anche se è abbastanza logico pensare che se le amministrazioni funzionassero a dovere non ce ne sarebbe bisogno), i redattori delle linee guida si lanciano in una analisi del Web che verrà, che ovviamente sarà Web 2.0, sigla dietro la quale di solito si cela “il pacco”. Sarà così anche in questo caso?

Ci si chiede legittimamente dove sono stati negli ultimi anni Telecom, Elsag ed Engineering. Caspita, che scopertona! Addirittura il mashup! Accidenti.

Dopo questa scoperta, il documento analizza la normativa, correttamente. In Italia bisogna fare i conti con alcune leggi, lo sappiamo tutti (tanto per dirne una, la Stanca). Poi c’è il Codice dell’amministrazione digitale e le sue richieste. A questo punto, l’affare si ingrossa.

Sollevando una grossa confusione terminologica e tecnica, il documento si addentra in una analisi di leggi, requisiti, congressi.

A un certo punto si arriva a un argomento abbastanza importante: 5.2. Perché progettare un sito accessibile e usabile.

Qui ci viene spiegato che ci sono molti buoni motivi per progettare in un’ottica di usabilità e accessibilità. Il primo è che un sito usabile e accessibile è semplice da progettare (pag. 21 del PDF). Giuro, c’è scritto così.

Poi si afferma che l’accessibilità non limita la creatività, perché art director e visual designer sono già abituati a lavorare tenendo ben presenti molti vincoli, quindi il rispetto di alcune ulteriori regole non sarà una difficoltà accessiva. Inoltre, un sito accessibile è facile da mantenere.

E così via, con queste amenità. Nessun accenno a standard, best practice universalmente riconosciute, Il Manuale delle Giovani Marmotte del Webbista. Ricordo ancora una volta, stiamo parlando di Telecom, Elsag ed Engineering con la supervisione del CNIPA.

Finalmente si arriva a qualcosa che forse assomiglia a una linea guida: 6. Linee guida per la progettazione e lo sviluppo dei siti Web. Bene, vediamo.

Si esaurisce tutto in mezza pagina: i metodi proposti sono due:

  • una metodologia progettuale classica, strutturata, che utilizza tecniche di verifica centrate sull’utente garantendo, se correttamente eseguita, la qualità ottimale del sito.

Ma, più bello:

  • oppure optare, se il contesto lo richiede (poco tempo a disposizione, impossibilità di coinvolgere immediatamente l’utenza, ecc), verso tecniche di progettazione più agili che velocizzano la fase progettuale e di sviluppo proponendo in tempi brevi il prodotto on-line in uno stato di “beta perpetuo” e che si concentrano sull’ascolto delle esigenze e dei feedback dell’utenza dopo la messa on-line del sito.

Fine delle linee guida. Praticamente, si consiglia di mettere on-line siti piuttosto approssimativi, in beta perpetuo, da raffinare man mano, perché così si fa più alla svelta.

Ammazza, che bel consiglio! Peccato che contravvenga a tutte le leggi, le linee guida, al codice dell’amministrazione digitale e alle stesse raccomandazioni che costituiscono (?) le linee guida citate come fondamento di queste stesse linee guida.

Si prosegue con una serie di perle di saggezza, come “è dunque necessario chiedersi: qual è lo scopo del sito? Perché è necessario crearlo? Quali sono i suoi utenti elettivi?“. Che illuminazione.

E poi via con il Web Design, che per prima cosa prevede la scelta dell’architettura dell’informazione del sito. Ebbè.

Si arriva proseguendo nella lettura del bigino allo sviluppo del sito (siamo già a pag. 69) e qui si straparla di MPC, a detta dei redattori il pattern (?) più diffuso. Sì, i siti della P.A. Web 2.0 sono fatti tutti con Ruby on Rails, Struts e Spring.

Ah ma forse si riferivano a dot.net

Scorri scorri, altra serie di riassuntini, ma dove sono le linee guida? Niente, si arriva in fondo e di linee guida non c’è l’ombra. È una specie di bigino fatto a colpi di copia/incolla sui più vari argomenti dello sviluppo Web.

Sempre se con linee guida si intendono delle raccomandazioni suggerite, prodotte attraverso un processo sistematico, finalizzate ad assistere gli operatori a decidere quali siano le modalità più adeguate in specifiche circostanze.

A parte alcuni grossolani errori (tanto è in perpetual beta…), viene da chiedersi a che serva questo documento. Viene da pensare che Telecom, Elsag ed Engineering non abbiano la possibilità di comprare qualche libro ai propri tecnici, un bel libro completo e non il riassuntino?

Insomma, ci sono tre redattori, cinque verificatori, un approvatore del documento. Non era meglio proporre una bibliografia raccomandata?

E i PDF, non è meglio renderli disponibili in modo che siano accessibili? Non si riesce nemmeno a fare un semplice copia/incolla, tanto sono fatti male. Eppure la Stanca lo richiede, che facciamo predichiamo bene e razzoliamo male? Già, il Web 2.0.

Il problema nasce dal fatto che non stiamo parlando di un libretto, un manualino, qualcosa fatto in proprio. Questi documenti sono stati presentati come:

“Roma, 24 marzo 2009 – Standardizzare un modello web 2.0 per i siti della PA e offrire una misurazione dei reali benefici forniti dai progetti di gestione: su questi temi il CNIPA, in collaborazione con Engineering, Elsag Datamat e Telecom Italia, ha predisposto specifici documenti di indirizzo che sono stati presentati lo scorso 24 marzo 2009 a Roma in un incontro con le Amministrazioni centrali e locali aderenti ai servizi previsti dall’Accordo Quadro CNIPA n. 4/2007.

I documenti, in linea con il Piano eGov 2012 recentemente emanato dal Governo, intendono fornire i primi strumenti di guida alle Amministrazioni, al fine di coinvolgerle nella evoluzione degli stessi e nella eventuale costituzione di una community incentrata sull’innovazione e sul miglioramento della qualità dei servizi”.

Standardizzare un modello Web 2.0 per i siti della PA? In questo modo? E mi raccomando, pubblicate Linee Guida in perpetual beta coperte da copyright (Il presente documento ed i suoi contenuti sono di proprietà del Centro l’informatica nella pubblica amministrazione (CNIPA) e sono protetti dalle norme sul d irnitatozi odn’aauleto rpee er dalle altre norme applicabili)[1. non ho corretto volontariamente il testo, questo è quello che si ottiene con il copia/incolla, pag. 8.].  Ma per favore.
E mi chiedo: o consorzio temporaneo di imprese fino ad oggi, 2009, che cosa avete fatto se improvvisamente adesso vi viene in mente che i siti devono essere accessibili e usabili tanto da dover produrre delle linee guida? Come li avete realizzati i vostri siti? Volete gli applausi perché con cinque anni di ritardo vi siete accorti delle necessità del Web e delle richieste delle leggi italiane?

Flash e accessibilità

Flash accessibile? I filmati Flash sono sempre stati sinonimo di inaccessibilità, e fino alla versione 6 del Flash Player questo era vero. È sorprendente scoprire come le cose si siano evolute, fino a poter parlare di Flash e compatibilità con le WCAG 2.0. Questo è l’argomento del secondo webinar dedicato alle tecnologie Adobe e WCAG 2.0 svolto da Paciello Group e Adobe. È disponibile la registrazione dell’evento, e personalmente l’ho trovato molto interessante.

Interessante anche una domanda a margine: chiede uno dei partecipanti se “All of this additional data that is added to make Flash accessible… it that data available to search engines?”. “Yes, if the search engine chooses to use it”, risponde Kirkpatrick (il riferimento è a tutti i testi alternativi, le descrizioni e le label poste nel filmato).

Inoltre lo stesso afferma che pubblicherà sul blog Adobe dedicato all’accessibilità una soluzione al problema del focus sui filmati in Firefox. Insomma, credo ci sia da tenere alta l’attenzione. E anche se è il primo di aprile giuro che non è uno scherzo, i filmati Flash possono essere resi a prova di WCAG 2.0.

Buona visione.

PDF, Flash e WCAG 2.0

È possibile creare contenuti accessibili conformi alle WCAG 2.0 con Acrobat e Flash?

Lunedì 23 marzo, martedì 31 marzo e mercoledì 8 aprile 2009 si terranno dei seminari Web per dimostrare come rispettivamente su:

  • PDF e WCAG 2.0 (23/3)
  • Flash e WCAG 2.0 (31/3)
  • PDF Forms e WCAG 2.0 (8/4)

Non è richiesta la pre-registrazione e i meeting si terranno nella room http://my.adobe.acrobat.com/wcag2.

L’orario per tutti e tre gli incontri è ore 12:00, Eastern US Daylight Savings Time, che da noi dovrebbe corrispondere alle 17 (non assicuro niente, gradite verifiche sui fusi orari).
I seminari si svolgono in concomitanza con il 3rd European eAccessibility Forum, che si svolge a Parigi nella settimana del 30 marzo.
Ulteriori dettagli sul blog del Paciello Group.