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

HTML: addio title sui link

Usare il title sui link di una pagina web è inutile per gli screen reader e crea solo confusione.

Codice HTML

Ammettetelo: se avete fatto attenzione all’accessibilità dei vostri siti, fino a qualche tempo fa vi siete sicuramente preoccupati di inserire sui link poco comprensibili un attributo title. Lo scopo era chiaro: spiegare meglio la destinazione del collegamento.

Un esempio su tutti è quello dei classici “read more” o “continua…”, dove un attributo title poteva dare qualche informazione in più:

<a title="Titolo della pagina di destinazione">continua...</a>

Leggendo un post di David Ball ho fatto la scoperta: il title non serve perchè non viene letto dagli screen reader, e utilizzarlo crea solo confusione. Incredibile fino a qualche anno fa: se cercate in rete articoli che parlano di accessibilità, erano in molti a raccomandare l’uso di questo attributo.

Continua a leggere HTML: addio title sui link »

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 »

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 »

HTML5: l’attributo placeholder

Come utilizzare l’attributo placeholder di HTML5 e risolvere i problemi di accessibilità.

L’attributo placeholder di HTML5 consente di visualizzare un breve suggerimento all’interno delle caselle input di tipo testo e delle textarea. Quando la casella riceve il focus, il testo sparisce e lascia spazio ai caratteri digitati dall’utente.

Continua a leggere HTML5: l’attributo placeholder »

Guida all’uso di HTML5

Tutte le indicazioni per utilizzare HTML5: semantica, CSS reset, tag video e compatibilità cross-browser.

Le sperimentazioni con HTML5 sono già iniziate da tempo, e nonostante serviranno ancora degli anni prima che la specifica diventi uno standard del W3C, si possono già trovare in rete molti esempi del suo utilizzo.

Dopo avere introdotto l’argomento su questo blog, ho approfittato di un piccolo progetto basato su Sweetcron per prepararmi e testare con mano lo stato attuale di HTML5. E’ così che è nata la nuova versione di 1la.it, lavoro che mi ha aiutato a mettere in ordine le idee per scrivere questa guida.

Continua a leggere Guida all’uso di HTML5 »

IE9 e HTML5

Uno sguardo alle nuove caratteristiche di Internet Explorer 9 ed alle funzionalità supportate di HTML5.

La nuova versione di Internet Explorer si preannuncia molto interessante per gli sviluppatori, viste le numerose modifiche introdotte ed i miglioramenti al motore di rendering.

Si potrebbe discutere a lungo sui ritardi nell’introduzione di novità già presenti da tempo sui browser concorrenti, ma al momento la cosa più importante è capire cosa cambierà nel prossimo futuro.

Il supporto di HTML5

Seguendo la working draft del W3C, queste caratteristiche sono già state presentate come supportate da IE9:

Inoltre sono state introdotte altre novità interessanti, come il supporto a SVG.

Guida per sviluppatori

E’ stato realizzato anche un documento molto ben dettagliato destinato agli sviluppatori. Si tratta della Beta Guide for Developers, dove si parla di CSS3, DOM, SVG e HTML5.

La guida finché il browser non sarà rilasciato potrà subire dei cambiamenti, ma già adesso è un utile punto di riferimento.

E le vecchie versioni di IE?

Quello delle versioni obsolete non è un problema da sottovalutare. E’ difficile infatti trovare versioni obsolete di Firefox o Chrome, mentre è cosa nota l’incredibile resistenza di Explorer 6. Proprio per questo motivo conviene sfruttare JavaScript, scegliendo tra due soluzioni:

  • ie7.js: consente di adeguare IE6 agli standard, aggiungendo anche il supporto alle immagini png trasparenti
  • Modernizr: una libreria che individua le funzioni supportate dal browser utilizzato, aggiungendo all’elemento html delle classi (per esempio .borderradius, .audio, .opacity…). Non aggiunge nuove funzionalità ai browser obsoleti, ma permette di individuarne le mancanze e gestirli in maniera diversa.

Qualsiasi soluzione decidiate di adottare, è bene considerare le conseguenze: abbandonare il supporto a IE6 ormai non è una scelta sbagliata, ma significa escludere comunque una parte di utenti. Il mio consiglio è di fare le dovute considerazioni a seconda del target del vostro sito: se vi rendete conto che gli utenti di Explorer 6 sono ancora numerosi, un file JavaScript potrebbe salvarvi.

CSS @import ed i tempi di caricamento

Conseguenze dei metodi di inclusione dei CSS in una pagina web, ed i soliti problemi con Internet Explorer.

I fogli di stile possono essere inclusi in una pagina web usando principalmente due metodi: link e @import. L’obiettivo di questo post è analizzare le conseguenze dell’utilizzo delle due tecniche. Il risultato in sintesi? Non usare @import per migliorare la velocità delle pagine ed evitare problemi con Internet Explorer.

Nonostante infatti possano sembrare differenti solo semanticamente, in realtà usare link o @import cambia considerevolmente i tempi di caricamento di una pagina. La scoperta è stata pubblicata qualche tempo fa sul blog di Steve Souders, un dipendente Google che si occupa di web performance e open source.

Metodi di inclusione

Link multipli

Il metodo più diffuso, che non crea problemi, è il seguente:

<link rel="stylesheet" type="text/css" href="style1.css" />
<link rel="stylesheet" type="text/css" href="style2.css" />

Guardando i tempi di caricamento, è possibile notare come i CSS vengano letti in parallelo su tutti i browser:

La prima breve barra dall’alto corrisponde al documento HTML, le altre due sono i CSS che vengono caricati simultaneamente.

Link e @import

I problemi arrivano quando insieme ad un CSS incluso con link, viene usato @import:

<link rel="stylesheet" type="text/css" href="style1.css" />
<style type="text/css">
@import url("style2.css");
</style>

In questo caso, su Internet Explorer (tutte le versioni, IE8 compreso), il CSS incluso con @import viene caricato solo dopo aver completato il primo file. Questo allunga considerevolmente i tempi di caricamento della pagina:

Lo stesso succede quando il secondo foglio di stile viene importato all’interno del primo:

<link rel="stylesheet" type="text/css" href="style1.css" />

e all’interno di style1.css:

@import url("style2.css");

In questo caso però il caricamento in sequenza succede su tutti i browser.

@import multipli

Gli esempi mostrati dovrebbero già bastare per preferire l’inclusione dei CSS utilizzando solo link, ma c’è un altro caso interessante: quello con @import multipli.

Su tutti i browser diversi da IE, questa tecnica non presenta problemi, e funziona in maniera analoga alla prima mostrata (link multipli). I guai arrivano proprio su Explorer, dove gli elementi vengono caricati in maniera del tutto casuale, senza rispettare l’ordine dichiarato.

Prendendo infatti un esempio con i seguenti file, tra cui un JavaScript:

<style type="text/css">
@import url("style1.css");
@import url("style2.css");
@import url("style3.css");
@import url("style4.css");
@import url("style5.css");
@import url("style6.css");
</style>
<script type="text/javascript" src="script.js"></script>

Il grafico risultante è questo, dove la seconda barra corrisponde al file .js:

Il file script.js viene caricato senza rispettare l’ordine dichiarato, e questo potrebbe portare a problemi di rendering della pagina. Il problema in questione si verifica su tutte le versione di Internet Explorer.

E’ bene che casi come quelli elencati siano noti, perché potrebbe essere veramente difficile indagare sui problemi di una pagina web dove gli elementi vengono caricati senza rispettare le precedenze.

In molti casi le pagine web hanno elementi più pesanti dei CSS (immagini, framework JavaScript), ma se volete ottimizzare il vostro sito tenete presente anche queste indicazioni. Non è un mistero che Google abbia iniziato a considerare anche la velocità di caricamento tra i parametri del suo algoritmo: anche il modo in cui vengono inclusi i fogli di stile è un fattore da valutare.