Testo nascosto e screen reader nel 2013
Di Livio Mondini | Archiviato in Accessibilità, Markup | 28 aprile 2013
Nascondere del testo sul monitor in accessibilità è una tecnica spesso usata soprattutto per migliorare l’esperienza di navigazione di un utente che utilizza uno screen reader: così facendo, è possibile aggiungere alla pagina informazioni che se visualizzate potrebbero apparire superflue o nocive per il design, ma che invece sono fondamentali per chi utilizza uno screen reader. Per esempio, per migliorare e completare la struttura dei titoli che delineano i contenuti delle pagine, o per gli skip link e tante altre situazioni, come etichettare elementi dei form o fornire istruzioni speciali dove l’interazione potrebbe confondere un utente che utilizza tecnologie assistive.
Per anni, allo scopo di ottenere questo risultato è stata utilizzata una tecnica ben documentata in CSS in Action: Invisible Content Just for Screen Reader Users su WebAIM, che prevede di nascondere il testo posizionandolo in modo assoluto fuori dallo schermo (e sue variazioni).
Però, a oggi questa tecnica presenta molti inconvenienti: il layout si può deformare se l’elemento così nascosto riceve il focus da tastiera (tipicamente, quando un utente naviga utilizzando il tasto Tab), il rientro negativo del testo non funziona quando la direzione di lettura è da destra a sinistra, Apple VoiceOver non legge gli elementi XHTML se questi hanno un’altezza pari a 0, Safari con VoiceOver su SnowLeopard legge i titoli nascosti come semplice testo.
Per risolvere questi malfunzionamenti, è stata elaborata una nuova tecnica basata sulla proprietà clip di CSS 2.1. clip consente di consente di specificare le dimensioni di un elemento posizionato in modo assoluto utilizzando i valori in alto, a destra, in basso, e a sinistra creando un box per il contenuto. Impostando tutti i valori a 0 pixel, il contenuto diventa invisibile.
In teoria sembrerebbe semplice, ma come al solito le incompatibilità fra browser ci mettono lo zampino:
- Bisogna prevedere una sintassi diversa per IE6 e IE7, vedi linea con il commento.
- Bisogna correggere un bug in WebKit e Opera che provoca l’overflow del contenuto “ritagliato”; sistemato con overflow: hidden.
- Bisogna impostare l’altezza di 1 pixel per garantire che VoiceOver legga il contenuto.
- Come ulteriore precauzione, gli attributi padding e border sono impostati a 0, al fine di evitare eventuali problemi relativi ai bordi del box di ritaglio.
Alla fine della fiera, il codice del CSS diventa così (al posto di hidden ovviamente utilizzate il nome della classe che avete creato nel vostro CSS):
.hidden {
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
padding: 0 !important;
border: 0 !important;
height: 1px !important;
width: 1px !important;
overflow: hidden;
}
Tag: CSS, screen reader
Formati aperti: ma il .doc è davvero un formato chiuso?
Di Livio Mondini | Archiviato in Accessibilità | 19 aprile 2013
Qualche giorno fa per ragioni diverse mi è capitato di consultare la pagina relativa ai Formati Aperti sul sito DigitPA.
Che cos’é il formato aperto
Il formato dei dati digitali si definisce “aperto” quando ne viene resa pubblica, mediante esaustiva documentazione, la sintassi, la semantica, il contesto operativo e le modalità di utilizzo. Tali informazioni, unitamente ad una guida all’uso del formato, orientata alla lettura da parte dell’utilizzatore, devono essere presenti in uno o più documenti rilasciati dall’ente proponente lo standard.
I formati aperti fanno parte, insieme al software open source, dell’insieme degli standard aperti.
Ok. Allegata una tabella contenente l’elenco dei formati aperti, come prevedibile.
Per i formati da “ufficio” (documentali), ci sono PDF e Open Document Format for Office Applications. Il diffusissimo formato doc non è contemplato, così come docx e altri formati XML di Microsoft, probabilmente perché ritenuti “formati chiusi“, o proprietari.
Non so se questo sia corretto: fin dal 2006 Microsoft permette l’uso libero dei suoi formati sotto licenza Microsoft Open Specification Promise. La OSP permette l’utilizzo libero di diversi formati Microsoft a chiunque
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification (“Covered Implementation”), subject to the following.
Non capisco bene. Nella pagina di Wikipedia dedicata all’argomento si leggono diverse citazioni del tipo:
“I’m pleased that this OSP is compatible with free and open source licenses.”
“Red Hat believes that the text of the OSP gives sufficient flexibility to implement the listed specifications in software licensed under free and open source licenses.”
Magari le specifiche sono segrete? No, sono disponibili a chiunque. Office Open XML è uno standard? Sì, è standard ISO. Sono un po’ confuso…
PDF accessibili da Word: axesPDF
Di Livio Mondini | Archiviato in Accessibilità, PDF | 15 aprile 2013
AxesPDF è un altro di quegli attrezzi senz’altro da avere se desiderate creare file PDF accessibili direttamente da Word 2007/2010.
La beta 3 è disponibile gratuitamente. Attenzione: si tratta di una beta, ed alcune stringhe dei comandi o l’help non sono ancora stati tradotti, così come le etichette di alcune icone. Però è uno strumento così promettente che non posso non presentarlo anche se ancora in fase di sviluppo.
Si tratta di un plugin per Word. Dopo l’installazione, troverete una nuova scheda axesPDF nella barra di accesso rapido. La scheda contiene alcuni pulsanti, che permettono di configurare le opzioni di conversione e creare il PDF.
Bè, che dire, provate, è davvero semplice da usare. La scheda Structure permette di definire nel dettaglio la mappatura degli elementi di tabelle, note, note a piè di pagina, paragrafi e titoli, didascalie.
Le impostazioni di Initial View sono per default già configurate correttamente, ed oltre alle consuete opzioni sono presenti anche due ulteriori controlli per determinare una eventuale pagina speciale dove il file si debba aprire e un fattore di ingrandimento.
Insomma, sono ansioso di vedere la versione commerciale: significherebbe davvero PDF accessibili con un clic, senza interventi a posteriori ed elaborate conversioni.
Le opzioni della scheda Structure di axesPDF.
Tag: Word
La fine di Ruth: il Texture Compositing Service
Di Livio Mondini | Archiviato in Second Life | 9 aprile 2013
Tempo fa avevamo detto dello “Shining Project” di Linden Lab. Ora è arrivato il momento della fase Sunshine (Server-side Baked Texture Generation & Storage), e questo probabilmente coinciderà anche con la fine dei Viewer 1.x.
Senza entrare troppo in dettagli tecnici, questa fase del progetto si occupa del rendering delle texture sul vostro avatar. Ora il processo avviene client side, ovvero è il vostro client che si occupa della corretta riproduzione delle texture utilizzate per rappresentare gli abiti del vostro avatar.
In pratica, oggi il processo chiamato “avatar baking” implica che quando un livello dell’outfit o dell’abbigliamento viene cambiato, incluso gli alpha layer, gli aggiornamenti vengono applicati in locale nel viewer dell’utente. Poi questi cambiamenti vengono comunicati al server a cui si è connessi, che invia gli aggiornamenti ai viewer degli utenti presenti sullo stesso server, in modo che anche loro possano vedere i cambiamenti. Si tratta di un processo che ha diversi punti di potenziale errore: per esempio il processo di comunicazione fra viewer e server si può interrompere, così il server non riceve tutte le informazioni necessarie e come risultato l’utente che ha effettuato le modifiche si vede perfettamente, mentre tutti gli altri lo vedono esattamente come prima, oppure sfocato o grigio, o nei casi peggiori nudo (già successo, vero?). L’avatar appare “ruthed” con i risultati visibili in molte foto di Flickr. Ma di certo è un fenomeno che avete già visto su voi stessi.
I nuovi viewer (e un aggiornamento sarà obbligatorio, oppure vedrete in modi del tutto curiosi gli avatar intorno a voi), si avvarranno del “Texture Compositing Service”. Il rendering avviene lato server, così che tutti i client vengano aggiornati in tempo reale e contemporaneamente (esclusi gli oggetti indossati).
Appena il client ufficiale verrà aggiornato con il nuovo codice (molto a breve), seguiranno immediatamente tutti i TPV come Firestorm, Kokua, ecc. ecc.
La fine di Ruth? Chissà. Non so cosa ne penseranno quelli del Culto di Ruth.
My name is Ruth
I libri di testo elettronici sono nocivi alla salute
Di Livio Mondini | Archiviato in Accessibilità, Libri | 4 aprile 2013
“Senza contare che la memorizzazione e la comprensione sono meno sollecitati dai supporti elettronici”. Aggiungerei “se ne leggete troppi diventerete ciechi” ed ecco fatto.
Non lo dico io eh, lo afferma “La Filiera Del Libro”, ovvero Associazione italiana editori (AIE), la Federazione della Filiera della Carta e della Grafica, l’Associazione librai italiani (ALI), l’Associazione nazionale agenti rappresentanti e promotori editoriali (ANARPE) in una dichiarazione congiunta rilasciata ieri. Sono proprio incazzatissimi contro Profumo e il Decreto Ministeriale n.209 del 26 marzo 2013 – libri digitali.
Condivido pienamente quanto risposto dall’Editore Mario Guaraldi ad AIE & Co, quindi copio/incollo il testo di Guaraldi.
Con preghiera di diffusione
L’Associazione italiana editori (AIE) e tutta la filiera del libro, schiuma alla bocca, riafferma sua totale contrarietà al decreto ministeriale dedicato alle scelte dei libri scolastici: i toni sono apocalittici e le colorazioni xenofobe, da ventennio fascista.
Secondo AIE/ALI, infatti, il decreto solleciterebbe le scuole e le famiglie ad acquistare “prodotti di aziende straniere, non europee, a danno di imprese italiane, mettendo così in difficoltà le aziende e gli occupati dell’intera filiera del libro e della carta”, senza considerare che “l’impatto sempre più pervasivo degli strumenti elettronici sui ragazzi ” potrebbe essere nocivo per la loro salute!
Mi vergogno profondamente di far parte di questa razza di farisei xenofobi che ha fatto pagare alle famiglie italiane ogni anno milioni di euro imposti in nome di quella stessa “autonomia didattica” che oggi viene invocata in difesa dei propri lesi interessi di categoria!
Chiedo pubblicamente scusa ai nostri figli di averli ridotti a fanalini di coda della cultura mondiale dell’innovazione anche a causa di questa arcaica concezione didattica asservita ai soli interessi corporativi.
Mi dissocio da questa per fortuna esigua categoria editoriale, erede fino in fondo di quella cultura fascista che l’ha asservita alla trasmissione dei valori dell’ideologia dominante, “canalizzata” in maniera coatta nel mondo della scuola.Mario Guaraldi
Io, da parte mia, sono proprio contento di leggere nell’Allegato 1 una frase finalmente chiara:
“il libro di testo in versione digitale deve tenere conto delle vigenti normative sull’accessibilità”.
E ciao.
Tag: Accessibilità degli strumenti didattici e formativi, contenuti editoriali accessibili
Navigare il Web con lo screen reader: Giuseppe, i suoi esperimenti e la fondamentale importanza dei titoli
Di Livio Mondini | Archiviato in Accessibilità, Markup | 3 aprile 2013
Giuseppe Di Grande è lo sviluppatore dell’eccellente software Biblos, un word processor che permette di creare stampe Braille e grafici tattili a partire da documenti scritti in un ambiente di authoring del tutto simile a quello di Word.
Giuseppe è un non vedente, esperto di computer e informatica. Trovo quindi molto significativi i suoi interventi in video dedicati ad illustrare le difficoltà che un non vedente incontra navigando il Web: è un’esperienza formativa per chi intende comprendere seriamente che cosa sia l’accessibilità, poiché Giuseppe illustra con chiarezza le operazioni che esegue e le difficoltà incontrate.
La sua playlist è disponibile su Youtube, ed è composta da diversi video dedicati all’uso del suo software, Biblos, e all’illustrazione delle sue esperienze di navigazione su importanti siti italiani.
Recentemente Giuseppe ha visitato i siti di due quotidiani, Il Fatto Quotidiano e La Repubblica. Per me, come studioso dell’accessibilità, si tratta di materiale molto interessante, poiché Giuseppe non è un tecnico del Web, e non esamina i siti secondo un’ottica da “accessibilista” o per una verifica di accessibilità. Semplicemente documenta la sua esperienza, fornendo dove possibile consigli per gli sviluppatori.
Su questo blog si è parlato molte volte dell’importanza degli elementi <hn> di XHTML e di come sia di fondamentale importanza utilizzarli correttamente. I video di Giuseppe mostrano chiaramente perché, e perché sia altrettanto importante il rispetto di quella “grammatica formale” tante volte richiamata dalla normativa e dalle specifiche riguardanti l’accessibilità.
Per esempio osserviamo il sito de Il Fatto Quotidiano (ma la stessa cosa vale per Repubblica): Giuseppe utilizza il tasto speciale H del suo screen reader per navigare la pagina desumendone la struttura dai titoli presenti. La struttura non sembra corrispondere a un ordine logico, bensì presentazionale: i titoli di livello due vengono utilizzati per titolare articoli riguardanti notizie di rango inferiore alla notizia principale, che possiede il tag <h1>.
Giuseppe e Il Fatto Quotidiano
Però, secondo la grammatica formale utilizzata, <h2> non è una notizia di rango inferiore, il tag dovrebbe delineare un sottotitolo all’interno dell’articolo iniziato con <h1>.
Cosa significa in pratica? Per capirlo chiaramente utilizziamo un add-on per Firefox, Heading Maps. Ora osserviamo il sito del Fatto Quotidiano con questo add-on attivo.
Heading Maps crea una mappa attiva e navigabile degli elementi <hn> presenti nella pagina, e simula perfettamente quello che Giuseppe fa nei video utilizzando il tasto H dello screen reader.
Come è facilmente visibile nell’immagine successiva, non è affatto vero che la notizia marcata con <h2> “Csm, 35 milioni di costi e il bilancio è inaccessibile” (sic) sia un sottotitolo all’interno di “Governo, M5S: non diamo liste di nomi” marcata con <h1>.
Sito de il Fatto Quotidiano (03/04/2013). Elementi h annidati.
Così come la notizia marcata con <h3> “Alla Bufalotta tra lamiere e teche” non è per niente un sottotitolo interno a “Il Fatto Quotidiano TV“, marcato con <h2>.
Il Fatto Quotidiano. Elementi h annidati.
Ovviamente, il mancato rispetto della semantica di quegli elementi rende la navigazione di Giuseppe più confusa ed imprecisa. Con poco lavoro di riorganizzazione della struttura della pagina la navigazione potrebbe essere chiara e semplice anche per un non vedente, che mi sembra una bella cosa.
Tag: headings
Sviluppare siti per utenti con disabilità cognitive e difficoltà nell’apprendimento
Di Livio Mondini | Archiviato in Accessibilità | 21 marzo 2013
articolo originale : Juicy Studio, Developing sites for users with Cognitive disabilities and learning difficulties, Sun, 30 Jan 2005 00:00:00 GMT – traduzione: 8 Febbraio, 2005
In breve
Quando si pensa all’accessibilità del contenuto web, si nota una tendenza a concentrarsi sulle persone con disabilità visive. Le persone con disabilità cognitive e difficoltà nell’apprendimento spesso vengono trascurate.
Questo articolo di Roger Hudson, Russ Weakley e Peter Firminger esamina i tipi di problemi che alcuni utenti potrebbe incontrare navigando il vostro sito, suggerendo tecniche pratiche su come sviluppare siti web che non discriminino gli utenti con disabilità cognitive e difficoltà nell’apprendimento.
Roger Hudson, Russ Weakley e Peter Firminger
Contenuti
- Introduzione
- Lavorare col contenuto
- Mostrare e nascondere il contenuto
- Uso dei CSS per migliorare la capacità di clic e di lettura
- Possibilità per l’utente di controllare contenuto e presentazione
- Conclusioni
- Approfondimenti
Introduzione
Il gruppo più ampio di disabili nella nostra comunità è quello che comprende le persone con disabilità cognitive e dell’apprendimento, ma quando si parla di accessibilità del web essi spesso vengono dimenticati.
Le etichette, disabilità cognitive e difficoltà di apprendimento, sembrano comprendere una gamma così ampia di condizioni diverse che gli sviluppatori web frequentemente ritengono i loro specifici bisogni difficili da identificare o da risolvere.
Le disabilità che possono incidere sulla possibilità di accesso a un sito e sul poter usare le informazioni in questo contenute sono molte, per esempio:
- Disabilità cognitive, che includono problemi con la memoria, la percezione, la capacità di risoluzione dei problemi, deficit di concettualizzazione e attenzione. Questo stato può derivare da una gamma di condizioni come ritardo mentale, autismo, lesioni al cervello, sindorme di Parkinson, sindrome di Alzheimer ed età avanzata.
- Anche le difficoltà dell’apprendimento possono influenzare diverse abilità relative alla memoria, alla percezione, alla soluzione dei problemi e concettualizzazione. Le difficoltà dell’apprendimento includono problemi di lettura come la dislessia, il deficit di ragionamento e calcolo e problemi nell’organizzazione e nell’apprendimento non verbale. In qualche occasione questi disturbi vengono classificati come “disturbo da deficit di attenzione con iperattività”.
Per lo sviluppatore web, la situazione viene resa più complessa dal fatto che ogni individuo in queste condizioni può avere necessità molto diverse. È comune che persone con difficoltà cognitive in un’area siano estremamente abili in altre. Per esempio, una persona potrebbe essere un eccellente lettore ma avere considerevoli difficoltà nella comprensione dell’organizzazione di una pagina web, o essere facilmente distratta da una piccola immagine animata.
Il web può risolvere le necessità di tutti questi differenti gruppi di utenti? probabilmente sì, ma ricorrendo a siti differenti.
Il web può portare molta gioia e aiutare le persone con diverse, e in qualche caso pittosto profonde, disabilità cognitive. Il progetto Peepo (ora chiuso) forniva una ampia serie di risorse e idee per permettere alle persone affette da gravi difficoltà nell’apprendimento di navigare e usare il web in modo indipendente.
Il punto focale di questo articolo riguarda principalmente il come migliorare l’esperienza del web per le persone che possono accedervi autonomamente e consultano siti costituiti principalmente da testo. Nello specifico, l’articolo suggerisce alcuni semplici metodi per migliorare l’accessibilità per le persone che trovano difficile leggere e usare contenuti testuali.
Per una versione più dettagliata di questo articolo, leggete An Accessibility Frontier: Cognitive disabilities and learning difficulties
1. Lavorare con il contenuto
1.1 Contenuto chiaro e semplice
Un contenuto è ben scritto quando è accessibile a chiunque, compreso le persone con deficit cognitivi o di apprendimento.
- Verificate che l’informazione sia ben organizzata.
- Mantenete il contenuto corto e semplice.
- Dividete l’informazione in piccoli brani, con un’idea chiave per paragrafo.
- Presentate i punti relativi in una lista invece che in un lungo paragrafo.
- Usate titoli e sottotitoli significativi.
- Verificate che non siano presenti errori ortografici o grammaticali
- Fornite definizioni/spiegazioni di termini tecnici, abbreviazioni ed acronimi.
1.2 Lunghezza della riga ottimale
Per molti utenti del web le righe lunghe sono difficili da leggere. Per le persone con difficoltà di lettura le righe di testo lunghe rappresentano una barriera di accesso non indifferente. Se la risoluzione dello schermo aumenta, i caratteri presenti in una riga aumentano di conseguenza a qualsiasi dimensione del testo. La dimensione ottimale del testo riguardo la facilità di lettura varia da persona a persona. Di conseguenza, è difficile dire una parola definitiva su quale sia la lunghezza di riga ottimale però, in linea generale, si può dire che la lunghezza della riga non dovrebbe superare i 70 – 80 caratteri e il testo deve avere dei margini a sinistra e a destra.
- Esempio di riga molto lunga
- Esempio di lunghezza di riga in un’intervallo ottimale
- Lunghezza di riga ottimale relativamente al contenuto [link esterno]
1.3 Canali di bianco
Molti utenti web hanno difficoltà di lettura quando il testo è giustificato, ovvero allineato a sinistra e a destra. Lo spazio disomogeneo fra parole nel testo giustificato (il browser non è in grado di sillabare il testo) provoca “canali di bianco ” che scorrono nella pagina, provocando difficoltà di lettura, per alcune persone impossibili da superare. La soluzione più semplice è evitare il testo giustificato.
1.4 Scrivere a piramide inversa
Un semplice modo di rendere il contenuto più accessibile è adottare lo stile di scrittura a piramide inversa utilizzato da molti quotidiani. Si inizia con un sommario o un piccolo riassunto del problema e delle sue conseguenze, e poi si forniscono informazioni a supporto e dettagli di sfondo. Questo permette agli utenti di determinare facilmente se sono interessati alle informazioni senza dover scorrere l’intera pagina.
- Esempio di scrittura a piramide
- Format a piramide inversa [link esterno]
- Tecniche di scrittura a piramide (bollettino DFL) [link esterno]
2. Mostrare e nascondere il contenuto
Per molti utenti del web, in particolare per le persone con disabilità cognitive e difficoltà nell’apprendimento, grandi quantità di testo in una pagina rappresentano una barriera. Permettendo agli utenti una certa forma di controllo sull’informazione che gli viene presentata, si può ridurre facilmente l’impatto di questo problema potenziale. È possibile fornire all’utente la possibilità di scegliere fra una versione semplice o dettagliata dei contenuti della pagina in diversi modi.
2.1 Contenuto lungo e corto
Questo metodo permette all’utente di scegliere fra una versione lunga o corta del contenuto della pagina nell’intero sito. L’utente può utilizzare la versione corta mentre sfoglia il sito, leggendo la versione abbreviata di ciascuna pagina. Se per una particolare pagina si desiderano maggiori dettagli, l’utente seleziona la versione lunga e viene caricata la corrispondente versione del contenuto.
Questo metodo viene utilizzato sul sito del Sydney Guardianship Tribunal. Sul sito sono stati effettuati test con diversi utenti, incluso alcune persone con difficoltà cognitive e dell’apprendimento. Appena si accorgevano di poter scegliere fra una versione breve e una completa, molti utenti se ne mostravano felici. Per esempio, le persone con difficoltà di lettura potevano fruire di una versione coincisa dell’informazione, quindi leggerla e comprenderla. Anche medici e operatori sociali usavano la versione abbreviata come default, poiché gli permetteva di trovare facilmente l’informazione desiderata.
2.2 Espandere gli elenchi puntati
Un metodo simile si basa su semplici frasi o titoli per fornire una sintesi del contenuto. Questi elementi vengono presentati in elenchi puntati, che servono anche come chiavi per ottenere maggiori informazioni. Quando l’utente seleziona una voce dell’elenco puntato, la versione espansa dell’informazione relativa viene mostrata sotto la relativa voce.
2.3 Mostrare-nascondere gli elenchi puntati
Anche questo metodo si basa su semplici frasi o titoli. Tuttavia, il contenuto espanso non viene mostrato fra i punti, ma sotto l’intero elenco. Per brani lunghi questa opzione è preferibile.
2.4 Contenuto a slide show
L’uso del web per fornire contenuto informativo per gli utenti con seri problemi cognitivi potrebbe richiedere un approccio diverso. Un metodo consigliabile prevede di presentare l’informazione in uno slide show integrato, con una slide separata per ogni concetto o area di interesse. Questo permette che il il contenuto venga fornito in pezzi chiari, facilmente accessibili in cui l’utente può procedere a proprio piacimento.
3. Uso dei CSS per migliorare la capacità di clic e di lettura
Uno dei maggiori vantaggi dei Cascading Style Sheets (CSS) consiste nel fatto che possono essere utilizzati per manipolare la presentazione del contenuto senza influenzarne la struttura. Di seguito alcuni semplici metodi che si basano su CSS per rendere il contenuto più accessibile alle persone con disabilità cognitive e difficoltà di apprendimento.
3.1 Aumento dell’interlinea (line height)
Per alcuni utenti l’aumento dello spazio fra le linee di testo che compongono un paragrafo si traduce in una migliore leggibilità.
3.2 Aumento del margine dopo i paragrafi
In genere, dopo ciascun paragrafo che compone un blocco di testo viene inserita una riga bianca (1em). Aumentando questo spazio a 1,5 o 2 righe si rende più facile la lettura a diversi utenti.
3.3 Uso di hover sui link
Per alcuni utenti è difficile distinguere i link dal resto del contenuto. I link dovrebbero essere dotati di un effetto hover come risposta al passaggio del cursore del mouse che renda evidente la loro natura .
3.4 Bordo inferiore sui link
La sottolineatura standard può rendere il contenuto, soprattutto in presenza di caratteri molto vicini, difficile da leggere. Rimuovendo la sottolineatura di default dei link e usando invece il border-bottom dei CSS per sottolineare il testo si può controllare la distanza fra testo e sottolineatura.
3.5 Aumento dell’area sensibile dei link
Per alcuni utenti, in modo particolare per chi soffre di disabilità motorie, fare clic su un link può essere difficile. Usando i CSS, l’area sensibile dei link può essere aumentata.
3.6 Hover su paragrafi, voci degli elenchi e celle delle tabelle
Per alcuni utenti con difficoltà di lettura è difficile capire in che punto della pagina si trovano. Applicando un effetto hover ai paragrafi, voci degli elenchi e celle delle tabelle gli si permette di usare il mouse come segnalibro.
Sfortunatamente, Internet Explorer non supporta l’hover su paragrafi, elenchi e celle di tabelle. Tuttavia, se desiderate dare questa possibilità ai vostri utenti, è possibile ricorrere a JavaScript per emulare questo effetto anche in Internet Explorer (usando lo script IE7 di Dean Edwards).
Paragrafi sottolineati
Un altro metodo per fornire aiuto agli utenti con difficoltà di lettura coinvolge la sottolineatura del contenuto del paragrafo attivo. In questo caso l’idea sarebbe fornire un righello virtuale che sia visibile sotto ogni riga di testo, permettendo all’utente di seguire la riga più facilmente.
Uno dei possibili problemi nell’utilizzo di questo metodo è che alcuni utenti potrebbero confondere la sottolineatura del paragrafo con quella dello stile di default dei link. Se si usano i CSS per dare alla sottolineatura uno stile diverso, per esempio con una linea punteggiata, si riduce il rischio potenziale di confusione.
3.8 Colori invertiti
Per alcuni utenti è più facile leggere il contenuto se i colori di testo e sfondo vengono invertiti, in modo che il contenuto della pagina venga presentato in un colore chiaro su uno sfondo scuro.
3.9 Riduzione della luminosità dello sfondo
Altri utenti fanno notare che le pagine con sfondo bianco provocano abbagliamento, rendendo più difficile la lettura. Questo problema può essere risolto utilizzando un tono bianco sporco o grigio chiaro per lo sfondo, riducendo l’abbagliamento.
4. Possibilità per l’utente di controllare contenuto e presentazione
Le varie idee presentate in questo articolo possono essere usate per permettere a ogni utente di un sito di disporre di una pagina che sia consultabile.
Quando CSS viene combinato a JavaScript o a processi Server Side, per lo sviluppatore diventa possibile includere alcuni dei suggerimenti di accessibilità proposti (per esempio il bordo sotto ai link e l’aumento dell’area sensibile degli stessi) come impostazioni di default, permettendo agli utenti di personalizzare altri elementi della pagina come:
- Contenuto: versione breve o estesa dell’informazione.
- Dimensione del carattere: possibilità di aumentare o diminuire la dimensione del testo.
- Leggibilità: cambiando lo spazio fra paragrafi e/o fornendo il mouse-over all’hover dei paragrafi.
- Colori personalizzati: fornite una gamma di opzioni incluso colori invertiti e sfondo non abbagliante.
- Lunghezza della riga: per il layout del contenuto.
- Interlinea: fornite alcune opzioni per cambiare l’interlinea del contenuto e dei link.
- Esempio di strumenti di controllo [link esterno]
Conclusioni
Questi esempi non sono stati proposti per fornire la soluzione definitiva a tutte le difficoltà che gli utenti con disabilità cognitive e difficoltà di apprendimento possono incontrare accedendo a un sito. Invece, sono suggerimenti per gli sviluppatori a cui interessa rendere il proprio contenuto accessibile al maggior numero possibile di utenti. Alcune tecniche sono state verificate con utenti affetti dadisabilità cognitive e dell’apprendimento, altre sono basate semplicemente su teorie.
Approfondimenti
- An Accessibility Frontier: Cognitive disabilities and learning difficulties
- Practical Design Guidelines for Universal Usability
- Adolescents, Autism Spectrum Disorder And Secondary School
- Inclusion Of Cognitive Disabilities in the Web Accessibility Movement
Copyright © 2000-2005 Juicy Studio. All rights reserved.
Tag: Accessibilità, disabilità cognitive, Gez Lemon
Libri elettronici interattivi: Versu, la proposta di Linden Lab
Di Livio Mondini | Archiviato in Second Life | 3 marzo 2013
Versu è una piattaforma narrativa interattiva che permette di creare esperienze di lettura tramite personaggi e interazioni sociali. Ogni storia definisce una premessa e alcuni possibili sviluppi. Come “giocatore”, potere selezionare un personaggio, determinare le sue scelte, osservare le reazioni degli altri personaggi ed eseguire (o no) dei compiti, in una interfaccia testuale.
“Living stories”, le chiama Linden Lab. Il concept non è sicuramente nuovo o originale, però (come al solito) Linden riesce a rendere intrigante l’avventura. Per ora, il punto debole secondo me è la disponibilità delle storie soltanto per Ipad (niente Android – annunciato “very soon”, così come sono in arrivo i client per Kindle e Google Play), e per noi la lingua inglese. Però, come si può vedere nel video, sembra davvero interessante: una via di mezzo fra Comic Chat (chi se lo ricorda?) e un MUD.
I personaggi possono passare da una storia all’altra, mantenendo le proprie caratteristiche ed esperienze, e a ciascuno dei personaggi di base corrispondono caratteristiche predefinite particolari. In effetti, uno degli scopo principali dichiarati è proprio l’interazione sociale dei personaggi, reali o sintetici che siano.
Il motore di Intelligenza Artificiale utilizzato è stato creato da Richard Evans, lead AI Designer per Sims 3, e i personaggi possono agire autonomamente o essere guidati da un umano, che diventa un creatore di contenuti. Emily Short ha realizzato il parser per la conversazione, e le interazioni sono basate sugli studi di Harvey Sacks, il fondatore della disciplina dell’analisi della conversazione.
Insomma, desiderabile ed intrigante…
Versu, di Linden Lab
Scrittura collaborativa in Second Life
Di Livio Mondini | Archiviato in Second Life | 18 febbraio 2013
Fra le varie cose che faccio in SL, collaboro anche con il gruppo Libriamo Tutti, che è un progetto di “invito alla lettura che utilizza le nuove tecnologie e i più noti social network per creare condivisione e scambio di informazioni fra chi ama leggere, gli scrittori e il mondo dell’editoria” e questo gruppo è popolato da veri e propri maniaci della scrittura e dei libri. Tutti scrittori in SL?
La scrittura collaborativa non è certamente una novità, e gli strumenti per scrivere documenti condivisi sono molti (come quelli, per esempio, che Google Drive permette di creare, o lato sviluppo il controllo versione).
Ho fatto un esperimento di uso di Media On A Prim utilizzando il servizio free di Etherpad Lite, uno strumento open source che permette la scrittura collaborativa in real time.
Dopo aver creato un documento in Etherpad Lite, ho inserito il relativo URL su una faccia di un prim.
È davvero strano fare clic su un tabellone in Second Life e vedere il cursore che si comporta come in un word processor. In una foto statica certo non si vede, ma le parole scritte visibili nell’immagine successiva sono prodotte digitando e formattando il testo dall’interno di Second Life.
Il testo prodotto si può salvare in molti formati, e si possono importare file. Insomma, una cosa piuttosto intrigante da esplorare.
Quello che in un’immagine non si capisce, è che sto scrivendo il documento dall’interno di Second Life. I pulsanti e i menu sono attivi, e per editare il documento basta fare clic in esso, come si farebbe in un qualsiasi word processor.
Tag: Second Life, word processor
