HTML 5 WAI-ARIA, che editor usare?

Cosa sia HTML 5, spero che sia scontato (il draft linkato è di oggi, HTML 5.1 Nightly). Forse un po’ meno conosciuta è la specifica WAI-ARIA. Questa specifica definisce come rendere contenuti ed applicazioni Web maggiormente accessibili (ARIA sta per Accessible Rich Internet Applications) tramite l’uso di elementi predefiniti e standardizzati che definiscono il ruolo giocato dall’elemento nel contesto.

ARIA è particolarmente utile in presenza di contenuto dinamico e interfacce utente complesse sviluppate utilizzando Ajax, HTML, JavaScript e relative tecnologie. In pratica, ARIA si affianca a HTML quando l’elemento utilizzato non dispone nativamente del necessario attributo a supporto all’accessibilità. Per essere più chiari, non reinventate l’attributo alt per le immagini con i ruoli ARIA…

ARIA sovrascrive il ruolo semantico nativo dell’elemento. Per esempio,

<h1 role=button>text</h1>

diventa nell’accessibility tree:

<button>text</button>

Da usare quindi sapendo cosa si fa.

ARIA funziona bene con HTML 5, e il Nu Markup Validation Service del W3C lo supporta.

Però, già le specifiche di HTML 5 sono piuttosto complesse, aggiungere anche quelle di ARIA potrebbe diventare un po’ complicato per lo svluppatore che usa Blocco Note come i veri uomini. Come fare?

Fra i vari tool disponibili, penso che Blue Griffon sia il migliore: interfaccia semplice, comandi completi, e il set degli attributi ARIA a portata di clic. Supporta SVG e MathML, ed inoltre è gratuito. Sicuramente fra gli strumenti da avere nella cassetta degli attrezzi.

 

Il lungo elenco dei ruoli ARIA nell'interfaccia di Blue Griffon.

Il lungo elenco dei ruoli ARIA nell’interfaccia di Blue Griffon.

Testo nascosto e screen reader nel 2013

omino in incognitoNascondere 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;
}

Navigare il Web con lo screen reader: Giuseppe, i suoi esperimenti e la fondamentale importanza dei titoli

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.

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.

 

Dal word processor a epub: alcune possibili soluzioni

Passare da un formato doc, docx, rtf o odt a epub può essere abbastanza complicato. Molto dipende da come è stato preparato il file di partenza, ovviamente. Valgono le stesse regole necessarie per produrre file PDF accessibili, di cui abbiamo parlato tante volte: uso corretto degli stili di paragrafo, niente formattazioni locali selvagge, niente allineamenti a colpi di tab, barra spaziatrice o tasto Invio a raffica.

Quasi tutti i word processor, anzi direi tutti, dispongono di un’opzione Salva in HTML. Benché con diversi livelli di qualità del risultato, in ogni caso l’HTML prodotto non è adatto ad essere utilizzato in un epub direttamente, bisognerà come minimo ripulirlo da tutto il codice presentazionale (potete anche non farlo, ma ricordate che il contenuto del vostro file epub è in chiaro, chiunque lo potrà vedere e giudicare la qualità del vostro lavoro).

Esistono però alcune soluzioni sul mercato che aiutano molto in queste attività, anche se in qualche caso a pagamento. Di seguito alcuni programmi, scelti con il criterio del rapporto qualità/prezzo, secondo me da valutare. Ovviamente, se qualche lettore volesse aggiungere qualche ulteriore tool, ben contento di completare questa piccola lista.

ePub Maker

ePub Maker (costo attuale 59 $) è un programma che converte file doc e HTML in epub. È piuttosto completo ed efficace, e permette di convertire in batch anche gruppi di file. Il codice prodotto è abbastanza pulito, pronto per essere aperto in Sigil (non penserete che il lavoro sia finito, vero?).

Interfaccia di ePub Maker

Atlantis Word Processor

Questo word processor è davvero sorprendente: ha un basso costo (potete temporaneamente comprarlo a un prezzo speciale di 14.23 euro), ha un’interfaccia praticamente identica a quella di Word 2003, richiede pochissime risorse al computer (pochi mega sull’hard disk, altrettanto in ram), funziona anche in versione portable ed è dotato di tutte le funzioni di un moderno word processor. È ovviamente in grado di aprire i file di Word.

I file possono essere salvati in epub, anche in questo caso con buoni risultati.

No, non è Word, è Atlantis Word Processor

Se visitate il sito del produttore, non dimenticate di scaricare l’utility free Tweak EPUB: è un ottimo coltellino svizzero per fare aggiustamenti e modifiche sui file epub.

Tweak Epub

Writer2ePub

Writer2ePub è un’estensione per il Writer di LibreOffice/OpenOffice (ed è di conseguenza gratuito, anche se viene aggiunta una pagina di “pubblicità” in fondo al file epub prodotto [1. Disattivabile nelle preferenze, come fa notare l’autore del plugin nei commenti]). Per poterlo utilizzare quindi è necessario installare una di queste suite, e nella barra degli strumenti del Writer troverete tre nuovi pulsanti, dedicati alla generazione di file epub a partire dal documento aperto nel programma.
Il risultato è buono ed è possibile personalizzare l’output tramite un pannello di opzioni.

Writer2Epub in Libre Office

Da PDF (o doc, o rtf…) a XHTML senza soffrire troppo

Che dobbiate realizzare un sito o preparare i testi per un epub, poco cambia: è necessario ricavare del codice XHTML di qualità e pulito da un altro formato. Quasi tutti i programmi di impaginazione e word processing dispongono di una opzione “Salva in HTML”, ma se ci avete provato avete già visto i risultati: un file html che tenta di riprodurre l’impaginato (vai a sapere perché), pieno di classi, div span e codice di formattazione. Un programma vale l’altro, tutti producono codice “sporco”.

Con tanta pazienza ci si mette all’opera per le necessarie pulizie, chi con Blocco Note chi con altri editor più sofisticati, Trova e Sostituisci e per i più arditi Grep. Comunque, può essere un’impresa decisamente penosa.

Scrivo questo post per condividere una caratteristica di Dreamweaver che ho trovato molto utile in questa situazione. Vediamo un tipico esempio: ho solo il PDF e devo ricavarne il codice XHTML.

Apro il file in Acrobat Pro, provo ad esportarlo come XHTML, utilizzando le opzioni disponibili a secondo del caso.

Salvataggio del file in xhtml a partire da PDF

Vediamo che è successo.

L’orrendo codice prodotto: e ora chi lo pulisce?

Bè, ok, non è un gran risultato pensando che tutto il codice presentazionale è superfluo e va eliminato. Un lavoro lungo e noioso. Però forse no, un momento, apro il file in Dreamweaver.

Osservando il codice, è evidente che la spazzatura è generata da un’enorme quantità di attributi style, class ed elementi span.

IDEA!

Il Trova e Sostituisci di Dremaweaver fa ovviamente questo lavoro, ma anche altro. Fra le varie opzioni, permette anche di cercare uno specifico tag e rimuoverne gli atttibuti. Nel nostro caso, tutti i tag con attributo style.

Rimozione di tutti gli attributi style e relative definizioni in un colpo solo.

Ripeto la stessa operazione per class, seleziono Commands > Apply Source Formatting così metto anche in bella vista il codice, e… ok, fa proprio un’altra impressione. In pochi minuti di lavoro.

Il codice ripulito.

Probabilmente sarà necessario qualche altro ritocco, ma certo è un’altra cosa.

Firefox e HTML5: a che punto siamo?

Alla luce del post precedente, in cui veniva commentato il per ora non completo supporto ad HTML5 da parte dei browser, mi chiedevo quali fossero i punti ancora mancanti.

Ci viene in aiuto The HTML5 Test, che fra le varie interessanti informazioni pubblica anche delle tabelle relative ad ogni sezione del markup e valuta il relativo supporto da parte dei browser.

Nel caso di Firefox 14.0.1, che è il browser che sto usando ora, HTML5 Test mi avvisa che il mio browser totalizza 345 punti su 500. Bene, cosa sono i 155 punti mancanti?

Parsing rules, 11 punti, tutto ok.

Canvas, 20 punti, tutto ok.

Video, 21 su 31. Ma come??? Non era proprio uno degli elementi innovativi questo? Vediamo un po’: subtitle, non supportato. MPEG4, niente da fare. H.264 niente. Ogg Theora e WebM ok. Aia, qui stiamo già andando alle lunghe. Firefox non supporta H.264 perché non è un formato open, ma Microsoft e Apple sì. Invece WebM è di proprietà Google. Sembra che Firefox si piegherà al codec H.264, rinunciando a un po’ di purezza, “ma non per ora“. Vabbè, vedremo. Certo che questo elemento sembrava essere uno di quelli “innovativi” di HTML5, speriamo che presto funzioni, perché per ora è l’ennesima lotta a colpi di standard pseudo open e similari dove vince un formato che subisce brevetti e restrizioni. Ed è, fra l’altro, lo stesso che attualmente viene utilizzato da Flash, Silverlight, Youtube, Vimeo e così via. Dove sarebbe l’innovazione?

Audio, 20 punti. Aac non supportato, MP3 non supportato. Ah però.

Elementi: 21 punti su 30. Mancano all’appello alcuni attributi, semantica a livello testo, elementi interattivi.

Forms: ecco, una delle veramente buone idee di HTML5 erano le form. Ma che delusione, 56/108? Metà degli elementi non sono supportati.

Interazione utente quasi completa, 35/37.

Microdata 0 su 15. Come? Niente microdata? Un’altra delle cose che mi piacevano di più… sarà mica colpa mia?

Insomma, non voglio farla troppo lunga. Anche il local multimedia non funziona (0/20), così come le Web Notifications (0/20).

Qualche fan di HTML5 riesce a spiegarmi per quale motivo dovrei usare questo markup, per una qualche ragione che non sia per mia conoscenza personale o esperimento? Per scrivere <header> invece di <div id=”header”>? O per usare <nav>, che c’era in HTML 3.2[1. ok, l’elemento si chiamava menu, ma non è che sia così diverso.]?

Sono sicuro che c’è altro, ma al momento mi sfugge.

Mi sembrano particolarmente gravi le mancanze rispetto a video, audio, form e microdata. E a oggi, anche solo inserire un filmato Youtube in una pagina HTML5 può essere un terno al lotto, usando dei meccanismi di fallback che rasentano il comico. Ma perché farsi del male così?
Troppo facile per Adobe proporre un kit gratuito per convertire filmati Flash a HTML5+JavaScript… ma non era HTML5 quello che avrebbe ucciso Flash? Per quale motivo poi, vai a sapere.

Sono andato anche a cercare pagine pro-HTML5, per esempio The State Of HTML5 per quello che riguarda il video.
Si vede che chi ha scritto il post è entusiasta, ma qualcuno sano di mente può davvero essere contento del fatto che forse Firefox gestirà MP4 così tutte le piattaforme saranno allineate? Forse? E quando? Perchè, ora come ora è un marasma di formati supportati e no, differenti fra browser e browser. E come al solito, l’accessibilità del player è scarsa, il sito la valuta 30%. Nemmeno il playback fullscreen funziona, 50%. Mah.

Ah, qualcuno potrebbe dire “è per usare CSS3”. Vorrei ricordare che CSS3 si può usare con qualsiasi markup, mica solo con HTML5.

Sarò pessimista, ma questa mi sembra peggio delle precedenti guerre dei browser. Rimpiangeremo le lotte fra Explorer e Netscape?

 

HTML 5: ma si può davvero dire che sia supportato dai browser?

perplessità leggendo i numeri relativi al supporto di html 5 da parte dei browser
Senza entrare nel dettaglio dell’indeterminazione della parola “supportare“, quello che mi chiedo è: si parla tanto di HTML 5, alcune cose sono davvero interessanti, addirittura EPUB 3 lo utilizza come markup di riferimento nonostante non si tratti di una specifica completata; ma proprio per questo, quanto è consigliabile utilizzarlo per lavoro? È davvero “supportato” dai browser?

Si sente spesso dire “uso HTML 5 perché i browser lo supportano”, che più o meno significa “non c’è alcun problema ad usarlo, perché praticamente tutti i suoi elementi vengono correttamente interpretati dai browser”. In informatica, quando un programma “supporta” una funzione si intende che è in grado di svolgerla.

Ok, già questo è un errore, poiché si potrebbe dire al massimo che i browser più diffusi interpretano chi più chi meno alcune caratteristiche di HTML 5.

Però è interessante capire di più quanto “pesi” questo supporto dei browser, giusto per sapere di cosa stiamo parlando. Viene in aiuto un sito che si occupa proprio di questo: The HTML 5 Test permette di verificare quanto i browser supportino realmente HTML 5.

È interessante notare che a oggi Google Chrome 20 totalizza un punteggio di 414 punti su 500, Opera 12.00 di 385/500, Firefox 14 345/500, Safari 5.1 317/500, Internet Explorer 9 138/500.

Si può davvero dire che HTML 5 è supportato dai browser? Trovo particolarmente deludente che Firefox, Safari e Opera lo supportino poco più del 65%. Nemmeno Chrome arriva al 100%, il supporto migliore viene da Maxthon, un browser che sicuramente tutti utilizzate quotidianamente, che totalizza 422/500.
Se il vostro word processor vi permettesse di usare il 70% dei tasti sulla tastiera, direste che “supporta la tastiera”? Io penso che vi incazzereste non poco.

È interessante seguire gli sviluppi di questa tecnologia, anche se non so cosa succederà ora con il fork HTML Living Standard (quale markup sceglieranno i produttori di browser – anche se Adobe, Google, Microsoft  hanno annunciato il loro supporto a W3C HTML 5)? Ritorneremo al periodo dei tag proprietari?. Ma dire che HTML 5 è supportato dai browser oggi è una bugia. Certo, capisco che dire “è parzialmente supportato dai browser” è meno cool, ma la verità è questa.

HTML 5: un altro buon motivo per non usarlo

terrore per HTML 5

HTML 5 ha una strana storia. Intorno al 2007, Ian Hickson (Hixie) inizia a lavorare con W3C sulle specifiche allora chiamate “Web Applications 1.0“, prodotte da Hickson stesso, che diventano HTML 5 (molto grossolanamente).

Però, parallelamente allo sviluppo di HTML 5, il WHATWG (un gruppo costituito da Apple, Mozilla Foundation e Opera Software con lo scopo di sviluppare Bible 5) continua a lavorare su specifiche proprie, differenti da quelle sviluppate con il W3C note come HTML 5.

Ovviamente questo non aiuta lo sviluppo di uno standard, e le specifiche del WHATWG si sono allontanate tanto da quelle di HTML 5 W3C da indurre Ian Hickson a dividere il lavoro dei due gruppi, formalizzando ufficialmente quello che da tempo stava accadendo (il primo annuncio è del 2011), per la gioia degli sviluppatori che avranno da litigare con due confuse pseudo specifiche nessuna delle due complete e senza avere la minima idea di quale si imporrà nel supporto dei browser.

Perché questo è il problema: le due specifiche si differenziano, hanno un sistema di bug tracking diverso, la confusione regna sovrana e nessuno capisce più di chi sia il bug, se di W3C HTML 5 o WHATWG  HTML 5…

Ora, secondo Hickson, dovremmo parlare di “HTML Living Standard” [1. attenzione, caricando la pagina facile che il browser si inchiodi]. No comment, ma io non userei HTML 5 per produzione, a meno che non vi piaccia rifare i lavori.

Giusto per capire di cosa stiamo parlando, dice Steve Faulkner:

The HTML standard contradicts the HTML5 specification (or vice versa) on a number of author conformance requirements and advisory techniques, including use of tables, use of ARIA and use of the title attribute…

…All in all I do not agree with your claim of the HTML living standard being canonical. It is unfortunately the case that we now have at least 2 specifications; HTML5 and the living standard neither of which can claim to be canonical description of HTML for stakeholders other than browser vendors.

Avanti così, facciamoci del male… Ora dobbiamo anche chiederci “Quale HTML 5”.

 

 

Epub vs. PDF vs. MOBI vs. Godzilla vs. Frankenstein

PDF, Epub, Mobi, KF8: la guerra dei formati

Che gran traffico su questi e-book. E quanti formati, quasi tutti incompatibili e insidiosi da convertire. Così, un e-book che funziona decentemente su una periferica è completamente inutilizzabile su un’altra, e così via. PDF, Epub, Mobi, KF8, tutti contro tutti. La torre di e-Babel.

Inoltre, molte delle versioni elettroniche disponibili sono realizzate malamente, evidentemente in economia e grande velocità senza alcuna verifica. Ovvio che a pagare è sempre l’utente, che qualche volta spenderà dei soldi per comprare degli e-book ma probabilmente si stuferà presto.

Trovo quindi del tutto sciocchi molti dei discorsi sul mercato degli e-book, la loro diffusione, l’esplosiva crescita, la prodigiosa macchina da guerra e così via, in gran parte basati su slogan, fuffa marketing e speranze personali (in Italia, in altri posti per quello che conosco sembra una cosa più seria). Che futuro può avere un mercato che vende prodotti avariati?

D’altra parte, capisco anche la confusione degli editori. Probabilmente in gran parte all’oscuro degli aspetti tecnici, vedono il loro e-book aprirsi in un qualche reader complice il service all’arrembaggio del momento che promette conversioni velocissime a prezzi ultra bassi e pensano eccoci, siamo pronti per il futuro (MOAR! LOOK MA IM IN TEH FUTUAR! We’re totally not going to go extinct now!”). E bisogna fatturare, c’è la crisi, e così via.

Io se fossi un editore sarei preoccupato del mio catalogo. Quale formato utilizzare per gli originali? Quale sarà il formato che mi permette di disporre di tutti i miei contenuti nella forma più flessibile possibile, la più universale, quella che più facilmente si adatterà ai formati di distribuzione attuali e futuri? Ci vuole quanto meno un formato standardizzato, creato da un ente super-partes, completo quanto basta.

Già, ancora il W3C e i suoi markup. Ma i markup originali, non quelli “modificati” o proprietari.

Indesign, epub e il mistero dell'header

Problemi con i caratteri speciali, interruzioni di pagina, gestione dei font e così via? Può un semplice spazio nel posto sbagliato causare una serie di inspiegabili errori in un epub? Sì, può.

A causa di un bug, Indesign CS 5.5 inseriva questo doctype (spazio evidenziato in rosso):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1­͏_//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

La patch è disponibile sul sito Adobe.

Dedicato a quelli che pensano che validare il codice non sia poi così importante.