État des lieux de l'accessibilité de HTML5 HTML5 : les nouvelles balises
Les apports des balises HTML5
Les balises comme article, time, header, nav ou figure apportent de la sémantique à votre page. Cela signifie concrètement plusieurs choses :
une meilleure lisibilité du code, ce qui est important pour ceux qui l'écrivent et facilite la maintenance,
une (future) exploitation facilitée pour les tiers : Readability (Application de lecture, service de rétribution des auteurs de blogs) se base sur ces nouvelles balises (ou sur microformat) pour tirer les informations des articles des pages. Il est difficile de trouver d'autres exemples pour le moment.
un (futur) meilleur référencement : la position officielle de Google sur le sujet est qu'ils adaptent leurs algos à toutes les pratiques émergentes. Si beaucoup de sites utilisent article, google finira par l'interpréter.
une (future) meilleure accessibilité : les navigateurs vont rajouter automatiquement des rôles ARIA sur certaines balises. Ce tableau vous montre le support actuel, il est aujourd'hui très limité : Firefox 4 pour certaines balises, Opéra pour les formulaires sont leaders
Les apports immédiats pour tous les sites ne sont pas évidents
Bref, les apports immédiats pour tous les sites ne sont pas évidents. Il y aura tout de même un bonus pour ceux qui jouent l'innovation et y passent avant les concurrents lorsque ces lecteurs de code source (services, moteurs de recherche, navigateurs) exploiteront cette mine d'informations.
Les problèmes
Le reproche principal fait aux nouvelles balises, c'est que IE6-8 font disparaître du DOM les éléments qu'il ne connaît pas, et donc ne les présentent pas aux technologies d'assistance. Le moyen de contourner cela est connu, facile à mettre en place et bullet-proof mais il induit une dépendance envers JavaScript. Les derniers chiffres français pris sur la homepage de Yahoo! font état de 1.5% d'utilisateurs dans cet état. La part de marché de IE est d'environ 50%, cela vous laisse avec 0.7% d'utilisateurs que cela peut gêner parmi vos visiteurs handicapés.
A ma connaissance, il y a 2 autres choses qui ont donné une mauvaise réputation à ces nouveaux éléments :
une combinaison de certaines versions de JAWS et de Firefox avait un bug qui faisait disparaître le contenu situé dans une balise <header>. En plus de la perte brute de contenu, selon où elle est placée, <header> peut contenir des titres ou des liens, 2 éléments fondamentaux pour la navigation avec les technologies d'assistance.
une autre combinaison, celle de versions de Windows-Eyes et d'Internet Explorer, n'arrivait pas à lister les liens à l'intérieur d'éléments HTML5 avec une balise role. C'est très spécifique mais là aussi il y a perte d'éléments de navigation fondamentaux.
L'introduction des nouvelles balises compromise par des bugs de certains logiciels importants
Doit-on changer sa manière de coder parce que deux logiciels boguent? Historiquement, les développeurs Web ont toujours répondu oui à cette question, en changeant leur code pour s'adapter aux bugs d'IE par exemple.
Sauf qu'IE est officiellement supporté par tous les sites Web alors que ce n'est pas le cas pour ces deux logiciels. Même si ces bugs ont été corrigés, ils restent majeurs (perte de contenu). Certains chiffres publics montrent que 25% de ces utilisateurs n'ont pas mis à jour leur version après un an, ce qui signifie qu'il faut prendre en compte ces bugs plusieurs années.
En conclusion : l'introduction des nouvelles balises est surtout compromise par des bugs majeurs de certains logiciels importants et votre sentiment sur la dépendance à JavaScript (que vous devriez d'ailleurs mesurer sur votre site). Elle est à mettre en balance avec les avantages de ces balises, qui eux ne sont pas immédiats.