Faut-il utiliser l’intégration en HTML5 en contexte de production ?

Coder en HTML5Après avoir touché un peu au HTML5 dans mon précédent article, je pense que cette version 5 du langage le plus utilisé du Web va révolutionner la manière de structurer le code des pages et donc des interfaces que nous réalisons au quotidien.

Il y a des pour et des contre, et à travers cet article je vais surtout vous exposer ce qui me semble incohérent ou pas prêt pour la mise en production d’un site codé en HTML5.

Une accessibilité encore sujette à débat

Un des buts de l’HyperText Markup Language en sa version 5 est de rendre le contenu de ses pages plus accessible aux handicapés.

Je n’ai personnellement pas encore eu l’occasion d’utiliser <canvas> et <video> mais il semblerait que ces 2 nouveautés posent un gros souci d’accessibilité. En effet le principe de <canvas> est de manipuler des pixels à l’écran, alors comment décrire cette animation à un lecteur d’écran en direct via un contenu alternatif ?

Autre « souci », l’attribut alt n’est plus obligatoire :

The requirements for the altattribute depend on what the image is intended to represent, as described in the following sections.

Or, on a vu des lecteurs d’écran lire à un aveugle le contenu de l’attribut src quand l’attribut alt d’une image venait à manquer (d’où l’importance de mettre alt=”” sur des images dont la présence est à but exclusivement décoratif). L’intention est bonne car le code serait moins pollué ainsi, mais le parc des machines chez les handicapés visuels n’est pas prêt.

Articles sur l’accessibilité et le HTML5

Certaines technologies pas encore adoptées par tous les navigateurs

Le tag <video> n’est pas supporté par tous les navigateurs et nécessite donc de prévoir un flash en remplacement comme l’explique cet article (en).

Le tag <canvas> est supporté par la plupart des navigateurs modernes, mais dans le cas d’Internet Explorer, nous devrons attendre sa version 9.

Impact du HTML5 sur le référencement

Le HTML dans sa version 5 est fait pour le Search Engine Optimizer ! Le référenceur va y trouver son bonheur.

Les tags comme <header role=”banner”> remplaceront très justement les <div id=”header”>, et la navigation aura enfin son propre tag <nav>. La page ou l’<article> pourront être divisés en plusieurs <section>, et le contenu annexe sera imbriqué dans un <aside>. Bref tout un tas d’éléments pour signifier ce qui est du contenu propre à la page et ce qui n’en est pas.

En revanche, comment dire à un référenceur que l’on pourra inclure une infinité de <h1> dans notre page comme le préconise le groupe de travail sur le HTML5 ?

En effet, d’après le brouillon actuel des spécifications du HTML5, il est fortement recommandé de n’utiliser soit que des <h1>, soit des titres de niveau approprié (que comprendre par là ?).

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

Pour le moment nous ne savons pas l’effet qu’une telle utilisation des titres aura sur notre référencement, mais il y a fort à parier qu’un moteur de recherche rencontrant ce type de code aura bien du mal à hiérarchiser les contenus crawlés. Par exemple, Google recommande officieusement (en) l’utilisation de 2 à 3 titres h1 par page maximum.

HTML5 + Javascript + IE = *$@?

Si la mise en page des documents contenant de nouveaux tags fonctionne parfaitement sous Internet Explorer grâce à une astuce à insérer dans le <head> de votre code HTML :

<!--[if lte IE 8]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

Le moteur javascript d’Internet Explorer lui, ne parcourt pas correctement le DOM d’un document dont il ne connait pas les tags en natif. Par exemple, ce code ne s’exécutera pas sous IE :

Cufon.set('fontFamily', 'American Typewriter').replace('hgroup h1')

Il faut donc appliquer un ID au hgroup (par exemple #hgroup). On perd clairement l’intérêt sémantique puisqu’on revient au principe d’autrefois : des id sur des DIV.

Ce qui freine la planète dans son élan

Disons-le, le web est un bordel pas possible et 90% des pages sont mal construites ou pas construites du tout. Il est temps qu’un langage approprié au classement et à la hiérarchisation du contenu soit mis au point et fonctionne sur tous les terminaux de la planète.

Le HTML5 va venir nous sauver mais avant, les lecteurs d’écran, moteurs de recherche et navigateurs doivent être mis à jour dans une portion suffisante pour que notre travail ait un sens sur un maximum de terminaux. Sans cela, point de salut pour le HTML5.

D’après un récent communiqué, la compagnie de Redmond souhaite corriger le tir avec Internet Explorer 9. En espérant que l’effort soit réel cette fois.

Alors, on attend encore longtemps ?

Nous devons malheureusement nous plier au monopole de Microsoft car les parts de marché d’Internet Explorer restent supérieures à 60% (en). C’est principalement à cause d’un seul acteur du monde informatique que notre capacité d’innovation est radicalement bridée (tout comme pour le passage à certaines technologies – pour n’en citer qu’un : le CSS2 & 3).

Comme le disais dans mon précédent article, j’aime beaucoup la plupart des innovations contenues dans la version 5 du langage HTML, mais il me semble plus sage d’attendre que le marché soit prêt avant de l’employer sur des sites en production.

Dans quelques années  on pourra revenir sur cet article et le mettre à jour. En attendant, la release des recommandations HTML5 par le groupe de travail est prévue pour fin 2010 (mais le W3C lui-même ne préfère pas trop s’avancer). Rendez-vous en 2022, c’est là que le w3c prévoit de recommander officiellement l’utilisation du HTML5.

Lectures intéressantes

Cela m’intéresse de connaître vos retours d’expérience avec ce langage si vous l’avez récemment utilisé ou si vous pensez l’employer dans l’un de vos projets (perso ou pro), et pourquoi. J’attends vos commentaires à ce propos.

Par Kaelig Deloumeau

Kaelig Deloumeau
Kaelig Deloumeau

À propos de l'auteur

Kaelig est intégrateur xHTML/CSS et code toujours dans un souci de propreté, d'ergonomie et d'accessibilité. Il a accompagné LunaWeb pendant 4 ans avant de rejoindre en 2012 la team UX de la BBC, pour s'occuper notamment de la bascule en responsive webdesign de tous les sites de cette vénérable institution. Il a également écrit un ouvrage vite devenue best-seller dans la profession (Avec Sass et Compass - Outils et bonnes pratiques pour l'intégrateur web). Une stèle à son effigie orne l'entrée de l'agence !