Il problema della grammatica formale pubblicata

Come spiegato nel post “L’intento semantico e l’accessibilità”, per funzionare una tecnologia assistiva deve potersi riferire al layer che gestisce nomi, ruoli e scopi degli elementi e mapparli a qualcosa di conosciuto.

È una relazione diretta: in Windows, per esempio, l’elemento MSAA (Microsoft Active Accessibility, ora Microsoft UI Automation) che rappresenta un elenco puntato deve avere un ruolo mappabile a una grammatica formale pubblicata (ovvero, una grammatica definita e pubblica in cui tutti gli elementi siano definiti e conosciuti a priori) in modo che la mappatura fra elemento MSAA e elemento codificato dalla grammatica possa essere diretto ed univoco.

In pratica, se la tecnologia assistiva leggendo un documento HTML rileva un elemento con accRole=h2 nel livello MSAA del sistema operativo, il lettore di schermo” capirà” immediatamente che si tratta di un titolo di secondo livello, perché esiste una mappatura certa (h2 fa riferimento alla DTD XHTML pubblicata dal W3C) e potrà rappresentarne correttamente l’intento semantico di questo elemento nell’indice navigabile generato automaticamente.

La stessa cosa avviene con testo normale, link, immagini, tabelle, elenchi puntati e numerati, e così via. È determinante che accRole possa riferirsi a un elemento conosciuto, oppure la tecnologia assistiva non sarà in grado di rilevarne l’intento semantico.
Lo stesso accade con un documento PDF accessibile, che possiede una grammatica formale pubblicata standard ISO.

Per sua natura, XML non possiede una grammatica formale pubblicata: la sua potenza consiste proprio nel permettere l’utilizzo di nomi di elementi personalizzati. Però è evidente che se nel documento è presente un elemento che ha accRole=titolone (definito da chi impagina), non essendo “titolone” riferibile a una grammatica formale pubblicata la tecnologia assistiva non saprà come utilizzarlo, e certamente non lo interpreterà come titolo.

La risposta di un lettore di schermo sarà sempre “Spiacente, non sono presenti intestazioni nel documento”.

Quindi XML non è adatto a risolvere le nostre necessità, a meno di non ricorrere a una rimappatura degli elementi utilizzando tecnologie come XSLT o altre trasformazioni per ricondurre la DTD personale a una DTD standard riconosciuta dalle tecnologie assistive. Per PDF invece occorrerà ricorrere al meccanismo chiamato “mappa ruolo“.

Rif:

Annunci

L’intento semantico e l'accessibilità

Le tecnologie assistive utilizzate da ipovedenti e non vedenti per funzionare si basano su un layer del sistema operativo utilizzato sul computer dell’utente (in assoluta prevalenza Windows, ma anche Mac OS X e Linux), rilevando in questo layer precise istruzioni (nel caso in oggetto, gli elementi accName, accRole e accValue) che permettono di ricostruire in modo elettronico le informazioni semantiche che il nostro occhio rileva immediatamente e che il nostro cervello elabora in base a un modello visivo consolidato permettendoci di riconoscere “a colpo d’occhio” gli elementi che costituiscono il corpo di un documento, ovvero il testo normale, titoli, immagini, tabelle, elenchi puntati e numerati, e così via.

Tutto questo avviene indipendentemente dal contenuto di questi elementi, la semplice rappresentazione grafica codificata ci permette l’identificazione dell’intento semantico di quel particolare elemento informativo.

Lo scopo delle tecnologie assistive è riprodurre tramite computer questa struttura semantica, in modo che sia percepibile anche a chi abbia difficoltà o completo impedimento a vedere il monitor.
Questo avviene soltanto se le istruzioni citate in precedenza sono presenti e correttamente utilizzate.

Si tratta di una questione tecnicamente molto semplice: se la tecnologia assistiva individua il ruolo di un elemento tramite una corretta istruzione accRole, questa sarà in grado di assegnare all’elemento il valore semantico corretto e quindi, per esempio, potrà ricostituire l’indice del documento cercando nel contenuto gli elementi che possiedono accRole=H1, H2, H3 e così via (alle condizioni esposte nel post “Il problema della grammatica formale pubblicata”).

È evidente che l’assenza di queste informazioni nel documento ne provoca l’inaccessibilità: per esempio, un utente di Jaws (lettore di schermo) premendo la combinazione di tasti Ins+F6 otterrà un laconico messaggio “Nessuna intestazione presente nel documento” invece di un vero e proprio indice navigabile, come accadrebbe invece se il computer rilevasse i corretti ruoli semantici assegnati agli elementi (lavoro che deve essere svolto da chi impagina il documento).

È facile riprodurre visualmente l’effetto della mancanza di queste informazioni fondamentali: basta provare a visualizzare un documento in cui sono presenti dei titoli. I titoli sono immediatamente riconoscibili perché di corpo più grande, in grassetto, e di dimensioni che ne indicano l’importanza gerarchica (intento semantico degli elementi al lavoro) e immaginare di osservare lo stesso testo ma tutto nello stesso carattere e senza interruzioni di paragrafo: una marmellata di caratteri incomprensibile, che per essere decodificata richiede un elevato stress cognitivo all’utente (ed ammesso che questo sia possibile).

Il secondo caso, seppur leggibile da un lettore di schermo o visibile sul monitor da parte di un ipovedente, non può essere ritenuto accettabile e/o accessibile.
Per definire un testo “accessibile” non è certo sufficiente la condizione “un lettore di schermo lo legge”.

È vero, il lettore di schermo legge quanto appare sul monitor, è il suo lavoro, ma a noi interessa che l’utente ne possa fruire proprio come se si trattasse dello stesso documento su carta, non che una tecnologia effettui la lettura di caratteri disposti alla rinfusa sullo schermo.

Rif:

La grafica dei mondi virtuali: SecondLife e le mesh

gli strumenti di building in secondlifeGli strumenti per la creazione di oggetti 3D integrati in SecondLife sono abbastanza rudimentali: semplici primitive di base a cui si possono applicare trasformazioni che per qualsiasi utilizzatore di software grafico 3D come Maya, 3DStudio o Poser sono davvero obsoleti e insufficenti. Non è possibile alcuna operazione booleana e ancora oggi gli oggetti complessi obbligano all’utilizzo di una quantità di prim (primitive grafiche) esorbitante.

Visto che qualsiasi region, parcel o luogo in SL possiede una quantità di prim limitata (e costosa, perché si pagano con l’affitto della terra), è facile capire che la lotta per il contenimento dei prim è una grossa preoccupazione per i builder e per gli utenti di SecondLife.

In ogni caso, è necessario riconoscere che nonostante queste limitazioni la creatività e l’uso attento di script e texture ha permesso ad alcuni designer di creare luoghi ed oggetti davvero belli. Però, per esempio, qualcuno ha mai provato a controllare di quanti prim sia costituito il bellissimo telescopio gigante di AM Radio? Ci vuole una parcel da 512 mq. solo per il telescopio. Le creazioni di Bryn Oh sono bellissime, ed anche in vendita a prezzi accessibili. Ma come faccio a metterne una in casa se occupa più prim della casa intera?

Anche tutti quelle capigliature, gioielli, accessori di abbigliamento così dettagliati e luccicanti sono davvero belli, in qualche caso. Ma se li indossi non ti muovi più, diventa quasi impossibile anche un semplice teleport e la presenza di dieci signore così attrezzate può bloccare una intera region: si chiama Avatar Rendering Cost, produce lag ed è causato dalla infinità di prim e script utilizzati per realizzare quella bella collana luccicante, le scarpe coi tacchi e quei capelli flessuosi. Belli, non discuto, ma per ciascun oggetto è necessaria una transazione col server con conseguente tempo di attesa e ciascuno deve essere renderizzato dalla vostra scheda grafica e dal client. Insomma, lag e ampie risorse utilizzate.

esempio di sculpt mapUn primo passo verso un 3D più realistico e “leggero” è stata l’introduzione degli sculpted prims. Una tecnologia interessante, un primo passo verso un vero 3D: gli Sculpted Prims sono oggetti composti da vertici e poligoni come tutti gli altri oggetti presenti in SecondLife, e uno Sculpted Prim è rappresentato da 1024 vertici modificabili dall’utente tramite delle texture speciali chiamate dalla Linden Sculpted Maps, una davvero interessante tecnologia che permette di rappresentare le geometrie 3D in una mappa rgb 2D: sono immagini quadrate in cui ogni pixel (elemento quadrato che la compone) assume un colore che viene poi tradotto come coordinata tridimensionale.

Tutto interessante, un grosso passo avanti per il conteggio dei prim e la grafica dei mondi 3D, ma anche qualche grattacapo: non infrequentemente le sculpt map vengono visualizzate come grossi palloni che veleggiano nel panorama circostante, e far quadrare il conto dei vertici non è per niente semplice. Il cosidetto rendervolumeLODfactor è sempre in agguato e comunque non si tratta di una tecnologia particolarmente performante per quanto riguarda i tempi di caricamento e rendering. Bello, ma non basta.

Stamattina però un annuncio piuttosto importante da LindenLab: dopo un periodo coperto da NDA alcuni tester hanno pubblicato i primi video di oggetti realizzati con mesh in SecondLife. La possibilità di usare le mesh cambia completamente la prospettiva e il supporto di Collada come standard è davvero un grosso passo in avanti, oltre che per la creatività e la qualità grafica dei mondi virtuali anche verso quella possibilità di interscambio fra grid che ormai appare essere indispensabile, così come appare ormai indispensabile l’implementazione di Open Grid Protocol. Ok, forse è troppo in un colpo solo.

In un paio di settimane dovrebbe essere aperta la beta pubblica, e sono sicuro che ne vedremo delle belle.

SecondLife: qual è il viewer giusto?

Linden ci avvisa che Emerald non è più utilizzabile su Second Life, e contemporaneamente vengono aggiunti alla Third-Party Viewer Directory tre nuovi viewer: Ascent, Emergence e Phoenix.
Bene, sempre meglio avere un po’ di scelta, era rimasto solo Imprudence…
Però, è anche lecito farsi delle domande: chi c’è dietro questi viewer? Saranno davvero affidabili, nel futuro? (ricordo che la presenza nella TPVD è una autocertificazione, non una certezza immutabile e scolpita nel marmo, come la vicenda Emerald insegna).
L’ultima “titolare” di Emerald viewer pone qualche questione a Linden Lab sul suo blog, e non di poco conto.
Per esempio, si chiede se davvero sia meritevole di fiducia Ascent, che sembra nascere dalla fusione di due altri viewer poco raccomandabili.
O se il così definito “lead dev” del gruppo di Phoenix sia così affidabile, visto che aveva creato una versione di Emerald ma con i permessi di copia abilitati. “Ah sì, ma solo per gli amici”, commenta ironica Arabella Steadham. E che dire dei componenti del team di Emergence bannati in massa qualche tempo fa? Saranno diventati tutti buoni e onesti?

Per capire di cosa stiamo parlando, può essere istruttivo dare un’occhiata al codice nella repository di Phoenix, per esempio date un occhio agli elementi XML in questa pagina.
Insomma, io ci andrei piano. Spero veramente che tutto questo non si tramuti nella fine di Second Life così come la conosciamo.
Tutti sembrano dimenticare che Linden Lab è un’azienda e deve fare profitti, non è un ente di beneficenza. Se la gente si stufa e si sente insicura se ne va, è ovvio. E ciao Second Life…
Spero proprio di sbagliarmi, ma credo che una lettura del post di Arabella sia necessaria per farsi un’opinione personale, e diffidate dagli annunci entusiastici, non c’è niente di buono in questa faccenda quale che sia il vostro uso personale di SL.
Credo che questa sia una delle pagine più brutte dell’open source in generale, ma è un’altra faccenda.

Personalmente sto usando Imprudence Experimental e il viewer Linden Second Life Development (Snowstorm). Molto ben fatti, anche se si tratta di release sperimentali. E comunque bisogna pensare di muoversi verso i viewer 2, che piaccia o meno ormai i viewer della precedente generazione sono destinati a sparire.