Nuova intervista a Elena Brescacin, sviluppatrice non vedente

Una nuova intervista ad Elena Brescacin: accessibilità della rete, app mobile e Internet of Things per un mondo migliore.

Era il 2009 quando decisi di condividere una delle interviste più interessanti mai pubblicate su questo sito: una bella chiacchierata con Elena Brescacin, sviluppatrice web non vedente che lasciò una testimonianza preziosa sull’accessibilità della rete e sulla sua esperienza con il mondo web.

Dopo diversi anni è giunto il momento di parlare di nuovo con Elena, che nel frattempo è cresciuta professionalmente e mi ha offerto molti nuovi spunti di discussione.

Si parla non solo di sviluppo web, ma di nuovi ambiti dove l’accessibilità è fondamentale: applicazioni mobile e internet of things.

Continua a leggere Nuova intervista a Elena Brescacin, sviluppatrice non vedente »

HTML5 diventa W3C Recommendation

HTML5Il 28 Ottobre 2014 HTML5 è passato allo stato di W3C Recommendation.

La notizia non può passare inosservata ed è destinata a cambiare anche in Italia l’approccio alla realizzazione di siti web accessibili.

Le parole riportate sul blog di The Paciello Group sono perfette per capire i vantaggi di HTML5:

HTML5 is a great leap forward for an accessible web. In HTML5, accessibility is a core design principle. For the first time the semantics of HTML have been mapped, and implementation requirements defined in terms of the way HTML semantics are conveyed to people using assistive technologies.

The addition of new interactive controls, native video and captioning and new structural elements in HTML5, make it easier than ever for developers to create HTML interfaces that are usable by everyone. The inclusion of WAI-ARIA in HTML5 also provides developers with the tools and information to create accessible custom content and controls that extend the core features of HTML.

Continua a leggere HTML5 diventa W3C Recommendation »

Accessibilità? Sì, grazie

Il mondo sta diventando sempre più accessibile: il web non può rimanere indietro.

voiceover

È ormai da diverso tempo che non parlo di accessibilità su questo blog, ma questo non significa che l’argomento sia ormai da dimenticare. Al contrario il tema è più che mai vivo senza che sia necessariamente legato alla parola “accessibile”, anche in contesti diversi dal web.

Qualche esempio?

Continua a leggere Accessibilità? Sì, grazie »

Il web design è morto?

Essere un esperto di HTML e CSS ormai non è sufficiente: è tempo di specializzarsi.

Con l’inizio del 2014 è tornata alla ribalta una discussione non del tutto nuova: conoscere HTML e CSS è sufficiente per potersi considerare dei web designer professionisti?

La risposta è no.

È iniziato tutto dal post di Jeff Croft: Web Standards killed the HTML star.
Abbiamo attraversato un periodo in cui lavorare con IE6 ci provocava incubi ogni giorno: essere un web designer significava saper risolvere in pochi secondi i problemi più assurdi.

È stata dura battersi per il riconoscimento degli standard web e per un comportamento coerente tra tutti i browser, ma alla fine i risultati sono arrivati. Gli standard erano importanti proprio perchè i browser si comportavano in maniera diversa, con un grande caos per tutti.

Continua a leggere Il web design è morto? »

Form accessibili: come usare le label

Guida all’uso delle label nei form HTML, per un sito più accessibile.

Esistono due metodi HTML per contrassegnare un campo di un form con un’etichetta.

Il primo è usare l’attributo “for” sulla label, con un valore corrispondente all’id dell’elemento associato:

<label for="email">email:</label>
<input type="text" id="email" />

Il secondo è inserire il campo del form all’interno della label:

<label>email: <input type="text" /></label>

Personalmente preferisco il primo metodo, ma il secondo è comunque valido e riconosciuto come corretto.

Continua a leggere Form accessibili: come usare le label »

Quando usare gli access key?

Usare gli access key non è un requisito fondamentale per un sito accessibile: in molte occasioni sono inutili e creano confusione.

Per molto tempo l’utilizzo degli access key è stato considerato un requisito fondamentale per un sito accessibile. Fornire delle scorciatoie da tastiera potrebbe a prima vista sembrare una soluzione intelligente, ma nella realtà dei fatti non è sempre così.

Come funzionano gli access key?

Associando ad un elemento di tipo a, area, button, input, label, legend e textarea l’attributo accesskey=”…” , è possibile indicare al browser una scorciatoia per raggiungere quell’elemento. Generalmente per utilizzare l’access key è necessario premere alt in combinazione con il tasto indicato.

I problemi degli access key

Il problema fondamentale è che non è mai stato definito uno standard su quali elementi di un sito debbano essere raggiungibili tramite access key. Considerando poi che non esiste nemmeno una regola su quali lettere utilizzare, il risultato è decisamente caotico.

Non solo un utente dovrebbe imparare per ogni sito degli access key diversi, ma potrebbe anche trovare dei conflitti con altre scorciatoie già definite dal sistema. Ogni browser infatti ha delle abbreviazioni predefinite per accedere ai menu (File, Modifica, ecc…), ed ognuno di loro si comporta in maniera diversa: in certi casi gli access key hanno la precedenza, in altri no.

Un altro fattore da considerare è che gli utenti utilizzatori di screen reader utilizzano molte altre scorciatoie, anche queste da aggiungere alla lista.

Inserire degli access key in una pagina non assicura quindi la possibilità di raggiungere velocemente determinati link, ma potrebbe aumentare la confusione. Se siete interessati ad approfondire il discorso, vi consiglio di leggere parte del capitolo 14 del libro “Accessibilità: guida completa” di Michele Diodati, dove questi problemi vengono descritti ampiamente. Il testo è di qualche anno fa ed alcuni esempi non sono aggiornati, ma è ancora oggi utilissimo.

Come fornire delle scorciatoie?

E’ comunque importante fornire dei metodi per muoversi all’interno di una pagina anche senza mouse. La soluzione migliore, ormai largamente diffusa, è quella di inserire degli skip link per saltare al contenuto principale di una pagina o al menu di navigazione. Solitamente queste scorciatoie sono posizionate ad inizio pagina, nascoste via CSS, e permettono a chiunque di andare immediatamente al contenuto desiderato.

Una soluzione di questo tipo è inserita anche nelle tecniche consigliate per adempiere al punto 2.4.1 delle WCAG 2.0.

La possibilità di utilizzare gli access key rimane, ma da requisito è passata a suggerimento: considerando i possibili problemi il mio consiglio è di trovare soluzioni alternative e non utilizzarli. Su questo sito ad esempio è presente uno skip link per saltare al contenuto, visibile anche premendo il tasto tab dopo il caricamento della pagina.

[foto di alcomm]

L’utopia del codice HTML valido

Uno spunto di riflessione sulla realizzazione di progetti con codice HTML valido.

Perchè esistono gli standard HTML? La risposta è semplice: deve esserci una base comune su cui poter sviluppare, e questa base deve essere capita e condivisa da tutti, per evitare incomprensioni e incompatibilità.

I problemi

In questo scenario, esistono numerose società che sviluppano applicazioni e tecnologie basate su un linguaggio come l’HTML: il loro nemico più grande è il codice non valido. Basti pensare a come sarebbe molto più semplice lavorare sempre su pagine validate, prive di errori e warning, anche semplicemente durante lo sviluppo di un sito web. Se però iniziano ad essere presenti errori e codici non standard, ecco che una gran parte del tempo verrà impiegato per correggere questi problemi. Se si parla poi di progetti come la creazione di un nuovo motore di rendering o di un browser, il tempo perso in questa direzione sarà ancora maggiore.

A questo proposito è illuminante un post di Rebuilding the Web riguardo al linguaggio HTML ed all’importanza della sua validità. L’autore dell’articolo racconta la sua esperienza in una piccola azienda che progettava la realizzazione di un browser standard-compliant: era impossibile pensare di gestire tutte le eccezioni generate dal codice non valido con un piccolo team di lavoro. Per questo i motori di rendering sul mercato restano sempre gli stessi, a meno che qualche soggetto importante non decida di investire, potendoselo permettere. Anche Apple e Google hanno deciso di puntare su Webkit (open-source) per Safari e Chrome piuttosto che realizzare un proprio rendering engine: la spesa sarebbe stata troppo elevata.

Meno del 10% del web ha codice valido

La colpa di tutto questo è proprio da ricercare nella diffusione del codice HTML non valido: se l’intero web non avesse errori non ci sarebbero problemi, ma è chiaro che questa rimarrà un’utopia. In passato ci sono state anche delle discussioni sul comportamento dei browser: c’era chi proponeva di visualizzare solo le pagine con codice valido, ma questo significherebbe impedire l’accesso a più del 90% dei siti web.

I dati che si trovano sulla rete sono impressionanti:

  • una ricerca del 2001 di Dagfinn Parnas, analizzando i siti indicizzati su dmoz.org, ha rivelato che solo lo 0.71% aveva codice HTML valido.
  • nel 2006 Rene Saarsoo ha ripetuto lo studio, ed i siti validi erano diventati il 2.58%.
  • un progetto di ricerca di Opera del 2008, chiamato MAMA, ha analizzato 3 milioni e mezzo di pagine e quelle valide erano il 4.13%.

Fortunatamente la tendenza è in aumento, ma i numeri restano ridicoli ed per ora ben poco influenti.

L’utopia di un web migliore

Con un quadro di questo genere, è facile comprendere come le conseguenze del codice HTML non valido riguardino tutti. Se utilizzate un qualsiasi browser, o a maggior ragione uno screen reader, un editor WYSIWYG o un motore di ricerca state pagando la presenza di milioni di pagine web errate. Enormi risorse continuano ad essere investite per gestire gli errori contenuti in queste pagine, ed in futuro lo scenario non sarà molto diverso.

Non esiste una soluzione immediata al problema, ma se una pagina web può essere validata senza grande sforzo, perchè non impegnarsi a raggiungere questo obiettivo? Anche questi sono costi di sviluppo da considerare, ma esistono anche dei vantaggi: una pagina valida non ha problemi ad essere visualizzata in tutti i browser e viene indicizzata senza problemi dai motori di ricerca.

Nel vostro prossimo progetto pensate seriamente alla validità del codice HTML, con un minimo di attenzione in più darete il vostro contributo per un web migliore.

[foto: Heberger Site]

I problemi di validazione con i CSS3

Utilizzare i CSS3 significa spesso avere fogli di stile non validi. Come affrontare il problema?

Uno dei problemi principali nell’utilizzo dei CSS3 è la creazione di fogli di stile con codice valido. I CSS2 sono ormai uno standard, ma non è così per le nuove specifiche.

Escludendo qualche rara eccezione, la maggior parte delle proprietà hanno nomi diversi e sono supportate in maniera differente a seconda del browser: questo non semplifica il lavoro degli sviluppatori. Basti pensare ad una proprietà ormai diffusa su tutti i browser (escludendo il solito Internet Explorer): border-radius. Su Firefox è necessario utilizzare il prefisso “moz-“, su Safari e Chrome bisogna anteporre “webkit-“ , ed ognuna di queste forme ovviamente non è riconosciuta dal W3C.

Il risultato è che se si desidera utilizzare i CSS3 per dare ad una parte dei propri utenti una migliore esperienza di navigazione, non sarà possibile validare il foglio di stile.

Come comportarsi in questo caso? L’unica soluzione è trovare un compromesso. Su questo sito ad esempio l’unica proprietà particolare che ho utilizzato è text-shadow, ben supportata nella sua forma standard. Ho invece trascurato proprio border-radius e altre proprietà simili, che però utilizzo su altri progetti come il mio blog personale, dove sono meno rigido per quanto riguarda la validazione dei CSS.

La colpa di questa situazione è da attribuire soprattutto alla lentezza del W3C, perchè i produttori di browser stanno dimostrando una grande attenzione alle novità. Supportare certe funzionalità è comunque motivo di vanto sulla concorrenza. Non è possibile però chiedere ai produttori di utilizzare fin da subito la forma standard delle proprietà: le specifiche potrebbero cambiare prima del raggiungimento della loro forma standard.

Proprio sull’uso dei CSS3 sarei curioso di conoscere anche il vostro punto di vista: li utilizzate? Vi preoccupate della validazione del foglio di stile?

Uno dei migliori suggerimenti sull’argomento, segnalato su CSS3.info, riguarda una possibile modifica al validatore del W3C. La soluzione ideale infatti sarebbe vedere segnalate come “experimental” o “warning” le proprietà dei CSS3 ancora sperimentali, consentendone l’uso senza problemi. Gli errori sparirebbero per la felicità di tutti, ma è una speranza probabilmente troppo ottimista.

Il W3C abbandona XHTML, il futuro è HTML 5

La presa di posizione del W3C: stop allo sviluppo di XHTML 2 per portare avanti solo HTML 5.

W3C LogoIl W3C ha chiarito la sua posizione sul futuro della specifica XHTML: con una news pubblicata il 3 Luglio ha chiuso lo sviluppo di XHTML 2, per dedicare tutte le risorse al futuro HTML 5.

Dalle notizie della settimana appena conclusa infatti è possibile leggere:

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Una decisione sicuramente importante per il futuro di chi sviluppa sul web, ma non così sorprendente come potrebbe sembrare. Ammetto di avere sperato in XHTML 2, ma i segnali colti fino ad ora non sono mai stati rassicuranti. Quest’ultima notizia è solo la conferma della strada fortemente voluta e consigliata (in modo più o meno forzato) da Google e dai vari sviluppatori di browser, che da tempo stanno spingendo per la specifica HTML 5.

Alla luce di quanto accaduto la decisione di Dave Shea, sviluppatore americano, che ha deciso di abbandonare XHTML da qualche tempo, non appare così sbagliata. Ne avevo parlato nel post “Abbandonare XHTML?”, ma in ogni caso non c’è alcun motivo di avere fretta di cambiare. Per quanto mi riguarda resto fermo sulla mia posizione: finchè HTML 5 non sarà pienamente supportato, XHTML 1.0 resterà la mia scelta principale; è semplicemente arrivato il momento di approfondire lo studio della nuova specifica per chi non l’avesse ancora presa in considerazione, visto che tra qualche tempo sarà largamente diffusa.

Come punto di partenza vi segnalo le Faq del W3C sul futuro di XHTML, ed il post “HTML 5: approfondimenti ed evoluzioni future”, dove troverete diversi link utili.

A proposito di tempi: quanto ci vorrà per vedere HTML 5 supportato da tutti i principali browser? Sicuramente qualche anno, ma la data potrebbe non essere così lontana. In alcuni casi certe funzionalità sono già ben supportate, e questo indica che gli stessi produttori hanno interesse a seguire la specifica. Non sarà comunque un cambiamento improvviso: c’è tutto il tempo per documentarsi ed approfondire.

Abbandonare XHTML?

E’ logico abbandonare XHTML in attesa di HTML 5? Un approfondimento sulle recenti discussioni in rete.

Tutto è iniziato con un post di Dave Shea su Mezzoblue, che sollevando non poco stupore ha dichiarato:

Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Un salto indietro di svariati anni, per tornare a realizzare pagine in semplice HTML, abbandonando una specifica ben più rigorosa come l’XHTML.

Questo cambiamento è da interpretare in proiezione futura, per via del supporto di alcuni browser (Opera soprattutto) e dell’attuale stato delle specifiche. Non è un mistero che XHTML 2 sia ancora indietro, mentre con HTML 5 sia già possibile ottenere dei risultati: ne avevo parlato anche in un articolo sui form.

La discussione per quanto riguarda l’Italia è proseguita su Edit, dove nei commenti del post Bye Bye XHTML si scontrano le due posizioni. Chi difende il web semantico e XHTML ha le sue ragioni, ma non è così incomprensibile appoggiare la semplicità di HTML 5.

E’ veramente ora di abbandonare XHTML?

La risposta a questa domanda va in controtendenza con quanto affermato da Dave Shea.

La specifica XHTML infatti è attualmente la scelta migliore.

Che senso avrebbe tornare a HTML 4? Dal mio punto di vista sarebbe un passo indietro, non giustificabile guardando al futuro. E’ lecito prepararsi a HTML 5, diversi siti lo stanno già facendo, ma il suo supporto è appena agli inizi: qualsiasi cambiamento è ancora prematuro. Ovviamente è un’opinione personale, se la pensate diversamente mi farebbe piacere discuterne nei commenti.