Sviluppare siti per utenti con disabilità cognitive e difficoltà nell'apprendimento

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

  1. Introduzione
  2. Lavorare col contenuto
  3. Mostrare e nascondere il contenuto
  4. Uso dei CSS per migliorare la capacità di clic e di lettura
  5. Possibilità per l’utente di controllare contenuto e presentazione
  6. Conclusioni
  7. 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.

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.

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.

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

Copyright © 2000-2005 Juicy Studio. All rights reserved.

Annunci

Da Acrobat XI a HTML: ripristinare l'esportazione a HTML 3.2 e HTML 4

In Acrobat XI,  il comando Salva come altro > Pagina Web HTML ha ricevuto significativi miglioramenti, per esempio riguardo le liste e le tabelle. Attraverso questo meccanismo Adobe ha cercato di offrire agli utenti un output HTML che rispettasse il più possibile il look and feel del documento PDF, usando sia i fogli di stile CSS sia stili inline.

Salva pagina Web HTML in Acrobat XI.

Salva pagina Web HTML in Acrobat XI.

Però, soprattutto quando è necessario poter disporre di un file HTML in cui sia presente soltanto la struttura e il meno possibile degli elementi di stile, l’esportazione in HTML 3.2 o HTML 4 delle versioni precedenti era più efficace.

Per ripristinare queste opzioni, è sufficiente recuperare i due file xml che si occupavano della mappatura degli elementi da una versione 9.0 del programma o scaricandoli dal Web.

HTML 3.2.xml e HTML 4.01.xml vanno poi posizionati nella cartella Acrobatplug_insSaveAsXMLMappingTables della vostra installazione di Acrobat.

Il file HTML risultante sarà certamente più pulito e adatto alla successiva rielaborazione per l’utilizzo in un epub.

Norme e standard: accessibilità del Web e dei documenti digitali online per i disabili

Articolo per Il Documento Digitale, versione cartacea – marzo 2013

Per sua natura, il Web comprende fra sue caratteristiche fondative anche l’accessibilità: come enunciato fin dal lontano 2005 da Tim Berners-Lee, il creatore del Web come lo conosciamo, “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect”.

Per realizzare questo obiettivo, il consorzio W3C ha creato una apposita iniziativa, chiamata Web Accessibility Initiative (WAI). Il materiale redatto da questo gruppo di lavoro esteso, che comprende rappresentanti delle maggiori software house, rappresentanti di governi e organizzazioni di disabili a livello mondiale, è di grande estensione e qualità. Dopo anni di lavoro, sono state rese pubbliche linee guida, tecniche e griglie di
valutazione che gli sviluppatori dei siti Web possono utilizzare per verificare l’accessibilità dei siti realizzati.

Attualmente queste Linee Guida sono diventate standard ISO, (ISO/IEC 40500:2012) e fanno da riferimento alla normativa sull’accessibilità di numerose nazioni nel mondo, fra cui anche l’Italia con la Legge 04/2004 già citata con i relativi decreti attuativi, che fissano i requisiti a cui debbono sottostare i siti web della Pubblica Amministrazione.

Per accessibilità nell’ambito della legge 04/2004 (detta anche Legge Stanca) si intende la “capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari”.

Sono previsti dalla normativa due livelli di verifica, una verifica oggettiva, da implementare mediante l’utilizzo di strumenti di validazione automatica e un intervento dell’esperto tecnico sulle soluzioni adottate, e una verifica soggettiva, da condurre tramite l’analisi da parte di uno o più esperti di fattori umani mediante l’osservazione diretta dello svolgimento di attività predefinite da parte di un gruppo di utenti rappresentanti delle varie disabilità: sordità, ipovisione, daltonismo, cecità, disabilità motoria agli arti superiori, distrofia spastica, disabilità cognitiva, nonché soggetti appartenenti a diverse categorie di utenti interessate ad accedere al sito. Il rispetto dei Requisiti indicati (22 in totale) dall’Allegato A del Ministeriale 8 luglio 2005 permette di definire il proprio sito come “sito accessibile”.

In effetti, un sito realizzato in quel modo potrà essere fruito dalla più grande platea di utenti possibile, anche da parte di chi per consultare il documento utilizza particolari tecnologie assistive come possono essere i lettori di schermo (software in grado di leggere a voce alta quello che compare sul monitor dell’utente), tastiere e schermi Braille, gli ingranditori utilizzati dagli ipovedenti e innumerevoli altre tecnologie di ausilio. Nonostante questo, i siti web della Pubblica Amministrazione realmente a norma sono pochissimi. Per quale motivo, non è facile da definire. Senza
dubbio pesa una certa “ignoranza” degli sviluppatori.

Anche la vigilanza su questi aspetti dei dirigenti è importante (la Legge Stanca comporta responsabilità dirigenziale e responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n. 165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti). In effetti, l’accessibilità impone un obbligo: i documenti realizzati alla fine delle verifiche dovranno essere di ottima qualità, utili e maggiormente fruibili per tutti.

Come anticipato, probabilmente un grosso impedimento alla realizzazione di questo intento proviene dalla scarsa conoscenza dell’argomento da parte degli sviluppatori e degli amministratori.

L’attività di verifica di grossi siti della Pubblica Amministrazione svolta da CNIPA insegna questo, e i colloqui svolti con gli sviluppatori allo scopo di risolvere le problematiche presenti sui siti analizzati hanno sempre portato, una volta compreso l’argomento, a positive evoluzioni sia in termini di accessibilità sia in termini di qualità generale del sito.

Il sito “accessibile.gov.it”, un portale nato per raccogliere segnalazioni di difficoltà d’uso da parte dei cittadini ed avviare un dialogo e fornire assistenza alle amministrazioni coinvolte, ha raccolto durante la sua attività più di mille segnalazioni di utenti disabili. Sul sito è presente inoltre una biblioteca di tutorial e materiale vario sull’argomento accessibilità. Ebbene, anche in questo caso le amministrazioni quando rese consapevoli del problema hanno provveduto in grande maggioranza alla soluzione dello stesso.

Inoltre, nessuna associazione di disabili ha mai avviato una causa contro un’amministrazione mancante da questo punto di vista, e men che meno un privato. La mancanza di sentenze e l’elevato costo delle cause probabilmente ha bloccato anche questo possibile deterrente, mentre all’estero accade di frequente (famoso il caso di un cieco contro il sito delle Olimpiadi di Sydney) ovviamente mantenendo alta l’attenzione sul problema.

Allo stato attuale, anche ai documenti elettronici possono essere riservate le stesse cure dei siti web, e i più diffusi software dispongono di validatori dell’accessibilità integrati. Per esempio, Microsoft Office dispone di un validatore molto efficace per Word, Excel e Powerpoint. Lo stesso si può dire riguardo Adobe Acrobat, lo strumento utilizzato per creare i molto diffusi file PDF.

In conclusione, sono disponibili tutti gli strumenti tecnologici necessari per realizzare compiutamente questo importante traguardo, esiste una solida normativa di riferimento sia nazionale sia internazionale, sono disponibili numerosi esempi applicativi e linee guida. L’accessibilità del Web e dei documenti elettronici in generale è una sfida entusiasmante, poiché permette che almeno in questo ambito le possibilità di conoscere, studiare, fruire delle risorse disponibili siano le stesse per tutti i cittadini digitali.

Audiolibri, epub3 e… accessibilità

un attore che legge un libro

Un audiolibro è un libro parlato, la riproduzione vocale di un’opera. In genere, si tratta di un libro classico o un romanzo di grande successo che viene letto da un attore e registrato in file .mp3 o altri formati audio, ma esistono anche audiolibri realizzati appositamente per questo scopo, che includono oltre ai file audio del parlato anche file musicali, scenografie sonore e quanto necessario per rappresentare, per esempio, un’opera teatrale.

Nel nostro caso, un audio e-book sarà composto da diversi file audio organizzati in una struttura e dotato di un sistema di navigazione che ne consenta la fruizione. Esistono degli standard tecnici che si occupano di fornire riferimenti su come realizzare questi audiolibri, il più conosciuto (almeno come acronimo) dei quali è probabilmente DAISY,  Digital Accessible Information System.

Qui iniziano i miei personali dubbi riguardo l’accessibilità: sul sito del Daisy Consortium spicca la scritta “Making Information Accessible for All“. Ma un audiolibro può essere davvero considerato accessibile per tutti? Molto brutalmente, che se ne fa un sordo di un audiolibro? Accessible for all? No. Inoltre, le periferiche hardware Daisy sono veramente costose, tanto da spingere il nostrano CILP (Centro Internazionale del Libro Parlato “A. Sernagiotto” – ONLUS) a sviluppare hardware dedicato a un prezzo decisamente più abbordabile. Sarà per questo, anche, che il consorzio DAISY non è che sia così simpatico?

Comunque, i tipi di Daisy hanno lavorato con gli sviluppatori di Epub 3 per creare la sezione dedicata al rendering audio TTS delle specifiche (attualmente non supportato da alcun reader)  e al meccanismo chiamato Media Overlays che permette di evidenziare in sincrono le parti del testo in lettura e il brano audio corrispondente enfatizzando questo risultato come se fosse la soluzione di tutti i mali.

Niente di nuovo, la stessa cosa si può ottenere da anni con altri strumenti, per esempio provate a leggere un brano con Balabolka, un programma TTS (text-to-speech) gratuito e davvero ben fatto.

Se aprite un epub con Balabolka ed avviate la lettura (in questo caso l’audio proviene dalla sintesi vocale installata, e non da un attore registrato mentre recita il testo), vedrete le parti del testo in lettura evidenziate mano a mano che la lettura procede.

Balabolka in azione: il testo in lettura appare evidenziato.

Balabolka in azione: il testo in lettura appare evidenziato.

Per ottenere lo stesso risultato (l’evidenziazione) ma correlando il testo a una voce recitante (quindi una base registrata, su cui non potete intervenire per quanto riguarda tono, velocità, tipo di voce), i media overlays di epub 3 prevedono l’utilizzo di SMIL (un markup del W3C) e di altre specifiche.

Qui mi sorge un altro grosso dubbio: SMIL (Synchronized Multimedia Integration Language) è un markup collaudato la cui versione più recente (3.0)  risale al 2008. Non riesco a capire che c’entra DAISY, se devo usare SMIL. Boh? Mi risponde indirettamente Matt Garrish nel suo Accessible EPUB 3, scaricabile gratuitamente da O’Reilly (il PDF non è accessibile, ma pazienza).

If you’re coming to this guide from accessibility circles, however, you’re probably wondering why this is considered new and exciting when it sounds an awful lot like the SMIL technology that has been at the core of the DAISY talking book specifications for more than a decade. And you’re right…sort of. Overlays are not new technology, but represent a new evolution of the DAISY standard, which EPUB 3 is a successor to. What is really exciting from an accessibility perspective is the chance to move this production back to the source to get high-quality audio and text synchronized ebooks directly from publishers.

Ma era così anche prima, nessuno ha mai impedito a un publisher di usare SMIL. Boh? Che c’è di eccitante? Mai sottotitolato un video? È la stessa cosa e l’hanno fatto in tanti ben prima che nascesse Epub 3.
Il libro utilizzato nell’esempio di Balabolka è un epub in versione 3, e per vederlo in azione al completo delle sue possibilità una delle pochissime opzioni disponibili (epub 3 non è che abbia avuto questo gran successo) è aprirlo in Google Chrome con Readium. Vediamo che succede.

In Readium il brano in lettura appare evidenziato in giallo.

In Readium il brano in lettura appare evidenziato in giallo.

Ascoltando la lettura, si noterà che al brano recitato in audio corrisponde una evidenziazione in giallo del testo in Readium. Come si ottiene questo? Tramite SMIL e markup.

Osservando la struttura del file epub in Sigil le cose (forse) appaiono più chiare.

In Sigil, è facile vedere il contenuto delle due cartelle Audio e Misc: tutti i file mp3 che costituiscono la libreria audio e i corrispondenti file SMIL che stabiliscono le correlazioni. Nel codice, ciascun brano viene delineato da un tag span.

Il contenuto del file epub in Sigil.

In Sigil, è facile vedere il contenuto delle due cartelle Audio e Misc: tutti i file mp3 che costituiscono la libreria audio e i corrispondenti file SMIL che stabiliscono le correlazioni. Nel codice, ciascun brano viene delineato da un tag span.

Si capisce che è un lavoro non da poco: con uno strumento di authoring bisogna selezionare ciascuna parte del testo che si intende evidenziare, associarvi le parti del brano audio con dei puntatori e aggiornare il file html con tutti gli span corrispondenti, ciascuno con una id diversa.
I file SMIL contengono informazioni di questo tipo:

<p class="chapterTitle"> <par id="p000001"><text src="p002.xhtml#f000001"/><audio clipBegin="0:00:00.000" clipEnd="0:00:02.879" src="../Audio/02_CantodiNatale_Strofa_1_A.mp3"/></par>

E nel corrispondente file html troveremo:

<h1><span id="'p000001">Strofa Prima</span></h1>

Quindi, due approcci completamente diversi: nel primo caso la lettura viene effettuata dalla sintesi vocale, nel secondo si tratta di un laborioso lavoro di sincronizzazione fra markup e file audio.

Ma, i dubbi che ho sono: nel caso Balabolka, il software di lettura è sicuramente accessibile a tutti, nel caso di Chrome/Readium no.

È un audio e-book in Epub 3 definibile come accessibile? A oggi no, o meglio lo è soltanto teoricamente: le specifiche del markup relative all’accessibilità non sono supportate da alcun reader Readium compreso (stiamo lavorando, dicono nelle FAQ. Ok, aspettiamo), e di conseguenza come verificare?  Forse è per questo che la sezione “Best Practice” delle EPUB 3 Accessibility Guidelines per ora appare “Coming Soon”. Dovrebbero esserci novità per febbraio 2013, ok, aspettiamo.

C’è qualcosa di innovativo nell’approccio di epub3? No, in generale per l’accessibilità Epub 3 si appoggia a tecnologie del W3C e le stesse cose si possono fare da anni, utilizzando tecniche standard con risultati anche più trasparenti e senza obbligare “il lettore” ad usare specifici browser ed estensioni non accessibili.

A chi giova ciò? Francamente, a parte discorsi di marketing, non lo capisco. Tempo fa ho chiesto informazioni sul forum di IDPF nella sezione relativa all’accessibilità, domandando esplicitamente che cosa intendessero con “epub accessibility“. Si sono un po’ arrabbiati, pensando che fosse una disfida fra PDF e EPUB – disfida di cui non mi interessava nulla, però onestamente ammettendo che:

You’re kind of presenting an impossible problem, though. Either EPUB stays in the past with XHTML 1.1 and doesn’t get the benefits that will come with native audio/video, mathml, aria support, etc. or, it moves forward and has to live with some instability.

The decision was made to move forward with the web, so that does leave us in a position where we have to talk about an ideal future. I certainly appreciate this fact, as there’s a line I find myself always treading between what you can say is possible versus what is possible right now.

Ok, aspettiamo… Per ora si vede molta confusione, spero che possa servire a rendere più chiare e trasparenti le cose il convegno “eBooks: Great Expectations for Web Standards” organizzato dal W3C in partnership con IDPF e BISG. Magari ce la facciamo a farcela.

Livio e il teorema della palla pelosa: ancora l'accessibilità…

“Non è possibile pettinare completamente una palla pelosa”, dice questa teoria. Io ogni tanto ci provo, ma effettivamente è difficile.

La storia si svolge attorno all’argomento accessibilità, ed è un po’ pelosa. Capita di leggere un articolo dove si annunciano mirabilie per il prossimo arrivo di libri digitali accessibili, con tanto di citazione della Legge Stanca. Ok, l’abbiamo già sentita, parto un po’ prevenuto, però ovviamente mi incuriosisco e vado a vedere.

La maggiore pecca dell’articolo per me è nel titolo, che contiene un “finalmente”. Un avverbio importante, ce l’abbiamo fatta, i problemi son risolti… Uhm. Il testo dell’articolo è piacevole, scritto da una persona entusiasta che pare credere davvero a quello che ha sentito dire con le sue orecchie da un importante relatore in un importante convegno.

Esiste un sito di riferimento, andiamo a vedere, no? Immediatamente noto nell’area sinistra della home page  una dichiarazione di accessibilità, con un link “Download Certificato”. Accidenti, addirittura un certificato? Che sito sarà mai questo? Leggo il certificato (in PDF, taggato malamente ma pazienza), dove scopro che una importante associazione di disabili certifica l’accessibilità del sito, anzi la certificazione fa riferimento esplicito alla metodologia della 04/2004, verifica oggettiva e soggettiva, quindi sono del tutto autorizzato a pensare che la verifica sia stata effettuata con l’intento di adeguare il sito ai requisiti di detta legge. Bè, già lo sapete come va a finire, un’analisi di due minuti mi fa rilevare che il sito non è per niente a norma.

Ci sono degli errori proprio grossolani, addirittura non esiste una struttura dei titoli. O meglio, esiste, ma sono tutti h1 e non si sono nemmeno accorti che in due dei banner che campeggiano nella pagina sono stati marcate con due elementi h1 separati le due parole che compongono il titolo, proprio su due titoli che sono “Editoria accessibile” e “Lettura accessibile”. Sì, la immagino la lettura accessibile con lo screen reader che dice “titolo di primo livello – Lettura” “titolo successivo – Accessibile”. Possibile? Dicono di aver fatto anche una verifica con utenti, nessuno ha letto gli h1 nei banner della home page?

E ovviamente la navigazione per titoli, fondamentale per chi usa uno screen reader, in questo caso non porta da nessuna parte, poiché non sono veri titoli, gli serviva solo mettere del testo grosso nei banner. Il sito è fatto tutto in questo modo, e certamente non è a norma, non sto a entrare nel dettaglio.

Ma come, un sito che trasuda accessibilità, fondato sull’accessibilità, pesantemente finanziato per realizzare libri accessibili, che mette in home page una dichiarazione di accessibilità con un certificato firmato da un importante istituto per ciechi… non è accessibile?

Ebbene è proprio così. Piuttosto irritato (proprio incazzato, direi), ho commentato il post in questione (che compare sul sito di un importante quotidiano italiano) facendo presente l’evidente incongruenza. Il giornalista passato un primo momento di sbandamento ha ripreso le redini del discorso, e contattato l’istituto in questione. Ha risposto il direttore, motivando i fatti con delle curiose affermazioni, che copio/incollo:

“Le anomalie riscontrate e rilevate tra i commenti di questo blog, sono effettivamente presenti, ma si è ritenuto sufficiente segnalarle al gestore del sito, in fase di sua realizzazione, senza tuttavia sanzionarle come “inammissibili”,

Segue arrampicamento sugli specchi per motivare tecnicamente questa scelta, affermando che “tutti i lettori vocali di schermo dispongono di comandi rapidi da tastiera per saltare immediatamente da una HeadLine all’altra”. A me viene proprio il dubbio che non ci abbiano provato, o si sarebbero accorti di quella stranezza nei banner. E proprio perché i lettori vocali permettono di navigare utilizzando la struttura dei titoli che ne avrebbero dovuta produrre una. Vorrei andare lì e chiedergli ci sei o ci fai…

Intravedete la palla pelosa?

Continua dicendo che “Insomma, abbiamo la sensazione che le critiche, magari formalmente legittime, tendano maggiormente a ribadire l’obbligo di una applicazione pedissequa e formalistica delle “norme”, astraendole però un po’ troppo dalle situazioni e dai casi concreti“. Magari formalmente legittime? Ma stai scherzando o cosa?

Al che un altro lettore fa giustamente notare che

“desidererei Lei spiegasse in forza di quale norma o criterio Lei ritiene Vi sia consentito considerare priva di rilevanza la conformità ai requisiti 1, 15 e 19 del citato provvedimento (nel caso del requisito 15 addirittura anche obsoleta, Lei dice, a causa dell’evoluzione tecnologica dei browser) se invece, come pare evidente, ciò Vi è al contrario imposto da una Legge della Repubblica con tanto di completo impianto regolamentare ad essa correlato e in pieno vigore?”.

La risposta è terrificante:

“proprio pensando alla lacuna vera della legge 4/2004 e dei suoi regolamenti attuativi che non prevedono, purtroppo, alcuna sanzione per chi non rispetta nella vera sostanza i criteri di accessibilità dei siti web, e sono davvero tantissimi in questo nostro povero e martoriato paese, mantenendo barriere di separazione e di segregazione verso tutte le persone con disabilitàe perpetrando in tal modo l’odiosa violazione di un diritto di cittadinanza, di inclusione sociale e di partecipazione attiva.”

Voi di questo istituto, vi rendete conto che a rendere povero e martoriato questo paese e a mantenere le barriere di separazione siete proprio voi con questo comportamento? Quale sarebbe “la vera sostanza“? Quello che dite voi? E che quel “i regolamenti attuativi non prevedono alcuna sanzione” in questo contesto di illegalità suona come “ma chi se ne frega, tanto non c’è una pena”? Vi rendete conto che alla prima riga di quel certificato avete scritto testualmente “L’Istituto xxxxxx, validatore CNIPA, su richiesta della società xxxx di Milano fornisce il presente rapporto sull’accessibilità ai disabili del sito”? Vi rendete conto che state agendo in nome dello Stato Italiano? Ma soprattutto, vi rendete conto che dovreste agire per difendere i diritti dei disabili, pene o meno, voi per primi? E che invece avvallate l’idea di una accessibilità “più o meno”, subordinata alle personali convinzioni di qualcuno? L’accessibilità non può e non deve essere un’opinione, sennò è inutile parlarne.

Io non riesco sinceramente a capire se si tratti di ignoranza, arroganza, indifferenza o che altro. Mi fa impressione questa mancanza di rispetto verso l’accessibilità in genere, e che questa provenga da un istituto per ciechi, firmata da un ingegnere e perorata dal suo direttore mi fa veramente star male. Ma per quale motivo avete voluto apporre una certificazione di accessibilità su un sito che non lo è? Vi rendere conto del danno che fate all’accessibilità? Se non interessa a voi, a chi mai interesserà?

Ma dove vuole andare l’accessibilità se non interessa nemmeno ai rappresentanti dei disabili?

In commenti successivi le mancanze (grosse) del sito vengono definite “lievi anomalie del tutto formali“. Ma avete provato almeno a ingrandire i caratteri del sito? Non avete visto la barra di scorrimento che compare immediatamente? Eccetera eccetera, le “anomalie” (a casa mia si chiamano errori) sono numerose e gravi.

Non sono entrato nel dettaglio su quel blog, sarebbe inutile. Mi sono limitato a far notare che concordavamo sul fatto che il sito non è conforme, e forse sarebbe meglio togliere quella certificazione. Almeno per rispetto verso i disabili.

Se poi rendessero il sito veramente accessibile, sarebbe anche meglio. Anche perché il sito per ora non passa nemmeno una verifica automatica, non dico a livelli sofisticati ma nemmeno a un livello di base come WCAG 1 Livello A… ma quali test avete fatto?[1. Verifica con Achecker WCAG 1 Level A: Know problems 10, Likely Problems 44, Potentially Problems 71)]


Dopo questo post, quel sito è stato modificato. Le modifiche apportate sono incommentabili, e certamente non risolutive. Però, quella certificazione è sempre lì.

Provare per credere: http://www.progettolia.it/

Accessibilità nel Decreto Legge Crescita 2.0

Ok qualcosa è successo, l’ex decreto Digitalia ora D.L. Crescita 2.0 è stato approvato dal Consiglio dei Ministri. Ora, come tutti i Decreti Legge (che sono provvedimenti d’urgenza di carattere provvisorio), entro 60 giorni deve essere convertito in legge, o perderà qualsiasi efficacia.

Nell’ultimo testo conosciuto prima della pubblicazione in Gazzetta, presumibilmente lunedì 6/10/2012,  l’accessibilità era finita insieme agli Open Data, con una serie di modifiche alla 04/2004. Modifiche importanti, che ampliano l’azione della Legge Stanca.

Per esempio, l’azione della Stanca viene estesa “a tutti i soggetti che usufruiscono di contributi pubblici o agevolazioni per l’erogazione dei propri servizi tramite sistemi informativi o internet.”;

Vengono introdotte delle sanzioni, e in particolare il punto 6 assegna alla nascente agenzia ulteriore compito di vigilanza di tipo attivo: il cittadino segnala e se ci sono problemi, entro 90 gg. la PA deve sistemarli a pena sanzioni dirigenziali e valore della premialità.

5. Entro il 31 marzo di ogni anno, le amministrazioni pubbliche di cui all’articolo 1, comma 2, del decreto legislativo 30 marzo 2001, n. 165, pubblicano nel proprio sito web, gli obiettivi di accessibilità per l’anno corrente. La mancata pubblicazione è altresì rilevante ai fini della misurazione e valutazione della performance individuale dei dirigenti responsabili.
6. Gli interessati che rilevino inadempienze in ordine all’accessibilità dei servizi erogati dai soggetti di cui all’articolo 3, comma 1, della legge 9 gennaio 2004, n. 4, ne fanno formale segnalazione, anche in via telematica, all’Agenzia per l’Italia digitale. Qualora l’Agenzia ritenga la segnalazione fondata, richiede l’adeguamento dei servizi assegnando un termine non superiore a 90 giorni.
7. L’inosservanza delle disposizioni del presente articolo, ivi inclusa la mancata pubblicazione degli obiettivi di cui al comma 5:
a) è rilevante ai fini della misurazione e della valutazione della performance individuale dei dirigenti responsabili;
b) comporta responsabilità dirigenziale e disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n.165, e successive modificazioni, ferme restando le eventuali responsabilità penali e civili previste dalle disposizioni vigenti.

Spero vivamente che nel passaggio al Parlamento sia possibile includere anche l’Art. 27 della proposta Palmieri/Gentiloni, che chiedeva:

Art. 27.
(Accessibilità dei testi scolastici).

1. Dopo il comma 2 dell’articolo 5 della legge 9 gennaio 2004, n.4, è aggiunto il seguente:
«2-bis. Il materiale di cui al comma 2 del presente articolo, oltre che agli obblighi di cui all’articolo 3 del regolamento di cui al decreto del Presidente della Repubblica del 3 maggio 2006, n.252, è sottoposto all’obbligo di deposito della versione digitale ai sensi del decreto del Ministro per le riforme e le innovazioni nella pubblica amministrazione 30 aprile 2008, pubblicato nella Gazzetta Ufficiale n.136 del 12 giugno 2008. Tale versione è resa disponibile per l’acquisto dagli editori ad un prezzo inferiore rispetto a quello della versione cartacea».

Sarebbe un passaggio decisivo, di quelli che possono cambiare in meglio la qualità della vita di tutti e specialmente di chi è in difficoltà. Una piccola frase per un enorme cambiamento.

Su Twitter gli Onorevoli Antonio Palmieri e Roberto Rao hanno già risposto positivamente alla chiamata di Roberto Scano. Speriamo bene, ma bisogna spingere un po’.

Epub 3 e accessibilità

dubbi su epub 3 e accessibilitàCon molta (troppa) enfasi, qualche tempo fa Eric Freese (membro del EPUB3 Working Group) affermava che mentre in Epub 2 le caratteristiche di accessibilità dovevano essere implementate tramite una combinazione di EPUB e DTBook (non ne conosco uno che se ne sia preoccupato, anzi che sia a conoscenza di questo particolare), con HTML5 non è più necessario usare DTBook perché “accessible by design”.
Se non funziona, è colpa degli editori incapaci. Lo notate il sorrisino, vero?

Cosa succede in realtà? Vediamo qualche semplice esempio. Come ben esposto nella Screen Reader User Survey #4 di WebAIM (maggio 2012), uno dei principali riferimenti per chi usa uno screen reader per leggere un testo restano i titoli, come è facile immaginare.

Lecito aspettarsi che almeno questo importantissimo elemento venga rispettato, vero? Invece no…

L’algoritmo di outline di HTML5 permette di usare  un elemento h1 per ciascun titolo contenuto in una pagina, e il valore del titolo viene ridefinito in relazione al livello di annidamento degli elementi di sezione (section) in cui h1 è posizionato. Anche se le specifiche di HTML “incoraggiano” a usare un solo elemento h1, è permesso l’uso di elementi da h1 a h6 che derivano il rank dal livello di annidamento della sezione.

Per chiarezza:

<h1>Level 1</h1>
<nav>
<h1>Level 2</h1>
</nav>
<section>
<h1>Level 2</h1>
<article>
<h1>Level 3</h1>
<aside>
<h1>Level 4</h1>
</aside>
</article>
</section>

È la stessa cosa di

<h1>Level 1</h1>
<nav>
<h2>Level 2</h2>
</nav>
<section>
<h2>Level 2</h2>
<article>
<h3>Level 3</h3>
<aside>
<h4>Level 4</h4>
</aside>
</article>
</section>

Abbastanza prevedibilmente, Jaws non interpreta i titoli del primo esempio. Peggio, con Jaws 13 succede che un h4 di questo tipo viene interpretato come h2, generando ovviamente una certa confusione nel lettore.

Così, l’unico modo per cavarsela è usare gli elementi da h1 a h6 alla vecchia maniera. Dopo dieci anni di sviluppo di HTML 5 siamo ancora qui. E stiamo parlando del solo markup di base, anzi nemmeno, dei soli titoli. Mah.

PDF/UA e WCAG2: mappatura dei requisiti

AIIM (Association for Information and Image Management) ha pubblicato un interessante articolo intitolato “Achieving WCAG 2.0 with PDF/UA” che ha lo scopo di articolare l’allineamento tra WCAG 2.0 e ISO 14289-1:2012 (PDF/UA), lo standard internazionale per la tecnologia PDF accessibili.

Così gli sviluppatori di software in grado di elaborare PDF possono ottenere la conformità alle vigenti criteri di successo WCAG 2.0 tramite implementazioni che seguono la mappatura a PDF/UA. In quanto tale, questa mappatura permette di validare un file PDF in formato PDF/UA secondo i criteri delle WCAG 2.0.

È un work in progress, e verrà mantenuta una change history per tenere traccia di eventuali modifiche e aggiornamenti.

L’articolo contiene anche interessanti informazioni riguardo la corretta versione delle specifiche, ed avvisa che la versione finale corretta FDIS di PDF/UA deve avere in copertina la data 2012-08-01. Avevamo parlato in precedenza di questa gaffe di ISO, ora corretta (il PDF dello standard non era conforme a se stesso, e per alcuni giorni non è stato disponibile).

Ottenere la conformità alle WCAG 2.0 con PDF/UA

I 61 criteri di successo delle WCAG 2.0 vengono mappati in una tabella, e Per ciascun criterio, la tabella indica le sottosezioni applicabili di PDF/UA per i rispettivi criteri di conformità per file e reader (software di lettura.

Vengono fornite inoltre tutte le corrispondenze a ISO 32000-1 (ovvero, PDF 1.7).

PDF/UA (ISO 14289-1:2012) disponibile al pubblico

Dopo otto anni di lavoro, da ieri 7 agosto 2012 il testo dello standard ISO PDF/UA (ISO 14289-1:2012) è disponibile al pubblico.

È un passaggio importante per l’accessibilità. Il formato PDF sembra inarrestabile e un documento che faccia da riferimento è fondamentale per lo sviluppo delle tecnologie attuali e future e per l’armonizzazione delle regole.

ISO 14289 ha anche stabilito un record: è il primo standard ISO che parla di accessibilità dei PDF che non è conforme a se stesso. Meglio, il PDF del testo dello standard non supera tutti i punti di controllo. Ok, non è il documento a non essere accessibile, bensì il timbro con la data apposta al momento dell’acquisto su tutte le pagine. No comment.

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.