HTML5 diventa W3C Recommendation

HTML5

Il 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 »

HTML5 e l’attributo placeholder

L’attributo placeholder di HTML5 è utile, ma non può sostituire le label di testo all’interno dei form.

L’attributo placeholder di HTML5 è una novità molto utile: consente infatti di visualizzare un breve suggerimento all’interno di un campo input testuale. Se in passato avevate usato l’attributo value abbinato a del codice JavaScript, adesso non è più necessario. Basta aggiungerlo in questo modo:

<label for"nome">Nome:</label>
<input type="text" name="nome" placeholder="Inserisci il tuo nome">

Il risultato sarà simile a questo:

Continua a leggere HTML5 e l’attributo placeholder »

CSS3: Flexible Box Layout Module

Analisi della nuova specifica CSS3 per gestire i layout e l’allineamento verticale.

Tra i vari moduli in lavorazione nelle specifiche dei CSS3, ce n’è uno particolarmente interessante: il Flexible Box Layout Module. Con questa specifica (ancora in sviluppo) è possibile infatti rendere flessibili i contenuti di un box, facendo loro occupare lo spazio vuoto a disposizione, sia orizzontalmente che verticalmente.

Il codice CSS

La teoria è semplice: dato un contenitore e degli elementi al suo interno, questi potranno adattarsi allo spazio vuoto. Considerando come html di base:

<div class="container">
    <div class="box"></div>
    <div class="box"></div>
</div>

Il CSS necessario per far adattare verticalmente i due div interni sarà:

.container {
    display: box;
    box-align: stretch;
    box-orient: vertical;
}
.box {
    box-flex: 1;
}

N.B.: Per lo stretch orizzontale, basta usare box-orient: horizontal.

In realtà per effettuare dei test è ancora necessario utilizzare i prefissi -moz- e -webkit-, visto che le proprietà standard non sono ancora supportate.

Esempi pratici

Flexible box layout model

Per capire ancora meglio la dinamica di questo modulo, gli esempi che trovate su css3.info sono meglio di qualsiasi descrizione testuale, a patto che stiate utilizzando le ultime versioni di Firefox, Safari o Chrome. Il W3C infatti sta ancora lavorando sul documento, e per adesso solo i motori di rendering Gecko e Webkit hanno delle istruzioni proprietarie adatte allo scopo.

Da notare che i due motori presentano risultati differenti, pur rendendo chiaramente l’idea dell’utilità della proprietà. A mio parere l’interpretazione corretta è quella di Webkit, ma finchè le specifiche non saranno definitive diventa difficile stabilirlo.

Un altro articolo interessante a riguardo è sul blog di Alex Russel, che ha preparato un foglio di stile su misura per avere già pronte tutte le classi necessarie.

Perchè parlarne?

Se le specifiche per il Flexible Box Layout Module sono ancora così indietro, ha senso parlarne? La risposta è sì, come nel caso di tutte le altre proprietà dei CSS3 che non sono ancora supportate. Pur non potendo utilizzarle nei propri progetti, per un web designer non è mai troppo presto per sperimentare: quando arriverà il momento sarà un grande vantaggio conoscerle.

Purtroppo l’ostacolo è rappresentato dalla lentezza del W3C e dal normale ciclo di vita dei browser: finchè esisteranno sul mercato delle versioni che non supportano queste nuove proprietà, sarà ancora presto per utilizzarle.

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 Logo

Il 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.

Il nuovo sito del W3C

Un importante redesign per il sito del W3C, attualmente in beta.

Aggiornamento: il 13 Ottobre 2009 è stata pubblicata definitivamente la nuova versione del sito del W3C, non più in beta.

Il W3C ha da poco presentato la nuova versione del proprio sito, ancora in fase di sviluppo. Si tratta di un aggiornamento importante e doveroso, che va ben oltre il semplice restyling grafico. Potete vedere il nuovo sito all’indirizzo beta.w3.org.

La prima cosa che ho notato è il layout fluido, che continua a supportare elegantemente risoluzioni fino a 800×600. Il menu di navigazione inserito nella colonna sinistra è a larghezza fissa, mentre il resto del sito si adatta alla finestra del browser.

C’è uno slider JavaScript per le notizie in homepage e nel complesso il risultato è molto più ordinato rispetto a prima: è stato fatto anche un notevole lavoro di riorganizzazione dei contenuti. Sono cambiate inoltre le pagine della documentazione, come potete vedere nel caso delle specifiche XHTML 1.0.

Essendo una beta non mancano problemi, ma la direzione mi sembra quella giusta. Volendo cercare un difetto non sono molto convinto dell’ordine degli elementi nella pagina: il menu di sinistra appare prima del contenuto principale.

Se volete dare il vostro contributo, trovate maggiori informazioni su questa pagina. Ci sono anche alcune indicazioni per dei task da svolgere all’interno del sito, come cercare un tutorial HTML o la pagina dell’archivio news. Qualsiasi feedback inviato al W3C sarà ben accolto.

HTML5: approfondimenti ed evoluzioni future

Una raccolta di materiale sulla specifica HTML 5, tra problemi di compatibilità presenti ed evoluzioni future.

Sono passati due anni e mezzo dalla pubblicazione dell’ultima bozza sulle specifiche XHTML 2.0 E’ passato più di un anno dalle discussioni su quale dovessere essere la direzione da seguire: XHTML 2.0 o HTML 5?

In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.

Approfondimenti sulla specifica HTML 5

Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.

Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.

Parlando invece di nuove funzionalità, sul sempre eccellente Dev Opera è disponibile un articolo che illustra il funzionamento dei canvas, che permettono di creare della grafica direttamente in JavaScript.

In questo contesto, ci sono già stati i primi esperimenti:

  • il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
  • una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript

Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.

Evoluzioni future

Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.

Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.

La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.

Come scrivere il testo alternativo sulle immagini

La realizzazione di un sito accessibile passa anche per gli attributi alt delle immagini: ecco come rispettare legge Stanca e WCAG 2.0

Uno dei primi punti da osservare per la realizzazione di un sito accessibile è l’utilizzo di testi alternativi sui contenuti non testuali come le immagini. Potrebbe sembrare un compito facile da assolvere, ma non è sempre così, soprattutto perchè a seconda delle situazioni le soluzioni possibili cambiano radicalmente.

Legge Stanca e WCAG 2.0

La normativa italiana e le linee guida del W3C sono molto precise a riguardo, questi sono gli enunciati:

Legge Stanca, requisito n°3

Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti. L’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

WCAG 2.0, linea guida 1.1

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Per ogni immagine presente sulla pagina è quindi necessario fornire un’alternativa testuale: il cosiddetto alt text.

Come usare l’attributo alt

Prima di tutto è d’obbligo tenere presente che ogni immagine inserita nel codice HTML di una pagina, soprattutto con doctype di tipo XHTML 1.0 Strict, necessita dell’attributo alt. Questo serve non solo quando l’attributo ha un valore, perchè è sempre utile indicare (ad esempio agli screen reader) che l’immagine non ha un significato rilevante e può essere saltata (usando alt=””). Questo accade spesso con le immagini puramente decorative, che sarebbe comunque meglio inserire tramite il foglio di stile.

Per eliminare ogni dubbio su cosa scrivere nell’attributo alt, la soluzione migliore è porsi una semplice domanda:

“Se dovessi illustrare al telefono la pagina che stai visitando, descriveresti l’immagine e il suo contenuto?”

Se la risposta è sì, allora è bene che quell’immagine abbia un testo alternativo, altrimenti non servirà a niente. Il metodo viene direttamente da Roger Johansson, e lo trovo perfetto per casi come questi.

L’importante è ricordarsi sempre di non esagerare, perchè è facile cadere nell’errore opposto: inserire troppe informazioni (inutili) in una pagina. Rendere accessibili le immagini di un sito non significa usare testi alternativi esageratamente lunghi e descrittivi: creerebbero solamente problemi. La cosa migliore è inserirli solo dove necessario, ad esempio in immagini che contengono del testo, per far arrivare all’utente lo stesso identico messaggio.

Conclusioni

Non è sempre facile trovare il giusto testo alternativo per le immagini di una pagina web. Le soluzioni variano a seconda dei casi, ma la regola fondamentale è ricordarsi che il testo alternativo deve servire per veicolare lo stesso messaggio dell’immagine, non per descriverla.

La differenza tra le due cose in certi casi potrebbe essere sottile, ma l’importante è essere coscienti del problema e cercare di risolverlo. Un sito accessibile passa anche per questi dettagli.

WCAG 2.0: le nuove linee guida

La seconda versione delle WCAG raggiunge lo stato di Proposed Recommendation: ecco tutto ciò che occorre sapere sulle nuove linee guida.

Dopo aver atteso a lungo, il 3 Novembre 2008 le WCAG 2.0 hanno raggiunto lo stato di Proposed Recommendation: il rilascio finale è questione di poco tempo, si parla di fine anno.

Sono passati diversi anni da quando è iniziato lo studio di una seconda versione per linee guida del W3C: basti pensare che le WCAG 1.0 risalgono al 1999. Già nel 2006 affrontai l’argomento su questo blog, parlando della presa di posizione di Joe Clark sulle pagine di A List Apart; da allora sono stati fatti diversi passi avanti, già evidenti al raggiungimento dello stato di Candidate Recommendation nel Maggio scorso.

12 linee guida

Le WCAG 2.0 sono costituite da 12 punti. In questi criteri vengono riassunte tutte le problematiche relative all’accessibilità, con l’obiettivo di dare indicazioni generali, non legate ad una particolare tecnologia o dispositivo. L’obiettivo viene così raggiunto senza perdersi in linee guida troppo specifiche e limitanti.

Ognuno dei 12 punti è poi suddiviso in 3 (o meno) livelli di conformità: le già famose A, AA, AAA, che servono ad indicare quali siano le priorità.

Cosa cambia dalle WCAG 1.0 alle WCAG 2.0

Chi da sempre si preoccupa di realizzare siti accessibili indipendentemente dai requisiti obbligatori e dalle linee guida può rimanere tranquillo. L’obiettivo delle WCAG 2.0 è proprio quello di avere delle indicazioni universali, indipendenti dalla tecnologia e dal dispositivo utilizzati: se vi siete preoccupati di realizzare dei siti accessibili preoccupandovi dei problemi reali e non semplicemente di seguire delle regole, molto probabilmente non dovrete cambiare niente.

Se volete approfondire il discorso e scoprire le differenze, è comunque disponibile una bozza comparativa tra tutti i checkpoint delle WCAG 1.0 e delle WCAG 2.0 appena pubblicate.

Risorse utili

Per non rimanere disorientati dall’enorme documentazione disponibile, ecco alcuni punti di riferimento per capire meglio e poter seguire senza problemi le WCAG 2.0:

  • L’accessibilità è 2.0: un ottimo articolo di Punto Informatico sulle nuove linee guida.
  • Understanding WCAG 2.0: una guida del W3C per capire ed implementare ogni singolo punto delle WCAG.
  • Techniques for WCAG 2.0: tutte le informazioni tecniche necessarie per osservare i requisiti, facendo riferimento a HTML, CSS e altri linguaggi. Interessanti anche gli esempi relativi al mancato rispetto delle linee guida.
  • Accessible forms using WCAG 2.0: una guida completa per realizzare form realmente accessibili

Se conoscete altre risorse utili disponibili, segnalatele e provvederò ad aggiungerle in questa pagina.