♪
Quel HTML5 ?▲
Le terme commençant à être flou, il vaut mieux le préciser à chaque fois qu'on l'évoque : pour une fois sur ce blog, le HTML5 dont nous parlerons dans cet article représente uniquement la spécification adoubée par le W3C, celle qui correspond à l‘évolution de HTML4 avec les nouvelles balises, le nouvel algorithme de parsing, canvas et le multimédia.
Les nouvelles balises▲
Leur apport▲
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'il adapte ses algorithmes à 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.
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'ils ne connaissent 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 page d'accueil 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.
À ma connaissance, il y a deux 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 bogue 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, deux éléments fondamentaux pour la navigation avec les technologies d‘assistance ;
- une autre combinaison, celle des 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.
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 bogues de IE par exemple. Sauf que 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 bogues ont été corrigés, ils restent majeurs (perte de contenu). Je n'ai pas de chiffre sur le taux de pénétration de ces versions boguées, mais les seuls chiffres publics que j'ai pu trouver 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 bogues durant plusieurs années.
En conclusion▲
L'introduction des nouvelles balises est surtout compromise par des bogues 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.
Les zones de navigation▲
L'introduction des balises nav, header, footer et aside est très intéressante car elle permet au navigateur de fournir aux technologies d‘assistance une carte de la page. Jusqu'ici les utilisateurs de ces technologies naviguaient principalement avec la liste des titres et la liste des liens d‘une page, ils pourraient également avoir accès automatiquement aux zones classiques présentes sur les sites Web.
Première ombre au tableau, HTML5 définit un mapping strict entre certaines balises et des rôles de zone ARIA, mais sur ces zones-là il n'y a pas de rôle par défaut. Il y a donc contradiction entre la spécification et les rôles que les navigateurs devraient automatiquement implémenter ( <nav role="navigation">, <header role="banner">, <footer role="contentinfo">, <aside role="complementary">). Qui dit contradiction dit mésentente possible entre navigateurs.
Ensuite vient le support : la traduction automatique des balises en rôle de zone ARIA par les navigateurs arrive à peine, Firefox 4 étant pour le moment seul. Par contre ARIA est bien supporté par les versions récentes des lecteurs d‘écran. Sauf que comme pour les navigateurs, les clients de ces logiciels mettent un certain temps avant de passer aux nouvelles versions.
Enfin, ces rôles et ces balises sont censés permettre la disparition des liens d'échappement, bonne pratique d'accessibilité reconnue. Mais ça serait oublier ceux qui n'utilisent pas ces logiciels, mais qui naviguent tout de même au clavier (choix, accident de souris, mauvais matériel, certains mobiles…). À ma connaissance, les navigateurs n'ont pas prévu de fonctionnalité pour ces utilisateurs, en leur mettant à disposition des raccourcis vers ces zones.
En conclusion▲
La technique du lien d'évitement restera très longtemps un moyen de navigation plus universel. Si vous ne la pratiquiez pas, utiliser les nouvelles balises maintenant apportera naturellement de l'accessibilité au fur et à mesure du déploiement des nouvelles versions de navigateurs et de technologie d'assistance.
Le multimédia▲
Les éléments audio et video natifs ont fait rêver un peu tout le monde et sur le papier règlent d'épineux problèmes. En pratique c'est beaucoup plus compliqué (sur mon projet, nous avons jugé que les implémentations navigateur ne valaient pas encore Flash) et l'accessibilité n'est pas en reste. Les implémentations des navigateurs concernant la navigation clavier sont variées, parfois boguées et parfois inexistantes.
Les sous-titres ne sont implémentés nativement nulle part et les spécifications ont vraiment beaucoup bougé à ce sujet. Difficile de savoir si le consensus actuel autour de l'élément track et le format WebSrt va rester.
Comme vous devez de toute manière fournir une lecture de la vidéo en Flash, qui lui est naturellement encore moins accessible (il pourrait, mais les flasheurs ne le font pas), votre seule option est de coder vous même un lecteur vidéo accessible, en sortant les contrôles du lecteur (natif ou Flash) pour en faire des éléments HTML marqués avec ARIA et d'implémenter votre propre solution de sous-titrage en JavaScript. Mais vous sacrifiez l'option fullscreen, ce qui est rarement toléré.
En conclusion▲
Les balises audio et video sont vraiment trop jeunes concernant l'accessibilité et il n‘y a pas de gros bénéfices à en tirer sur les navigateurs de bureau. Flash étant pire, vous devez améliorer vous-même les choses en codant un lecteur accessible ou en espérant en trouver un dans cette longue liste.
Les titres▲
HTML5 définit un algorithme pour déterminer le vrai niveau des Hx d'une page. Concrètement si vous mettez un h1 dans une balise section ou article qui n'est elle-même pas enfant d‘une autre balise sectionnante, alors votre h1 est en fait un h2. C'est très pratique pour ceux qui développent des sites Web de façon modulaire : on ne s‘occupe que de la hiérarchie interne d'un bout de page, sans avoir à se demander quel est le nombre de niveaux de titre déjà introduit. Pour voir cet algorithme en action, vous pouvez utiliser l'outil HTML5 outliner.
En quoi est-ce important ? Les titres sont la première manière de naviguer sur une page lorsque l'on utilise un lecteur d'écran et selon le moteur HTML utilisé, la hiérarchie interprétée ne sera pas la même et vous ne pouvez rien y faire. Honnêtement si vous n'aviez pas prêté attention à la hiérarchie globale des titres jusqu'à présent, HTML5 vous aidera à mieux vous organiser module par module et à obtenir au final quelque chose de cohérent au moins sur les nouveaux navigateurs. Si vous aviez une belle hiérarchie, alors pour la conserver sur tous les navigateurs, il vous faudra éviter les balises sectionnantes comme article, section ou aside.
Cela dit, une hiérarchie bien maîtrisée de titres n'est réellement importante que si la page comporte beaucoup de titres, par exemple sur des sites à fort contenu textuel (longs articles de journaux, encyclopédie…). La plupart des sites se contentent d'une vingtaine de titres de niveau 1 et 2.
En conclusion▲
Si vous ne gériez pas votre hiérarchie parfaitement au niveau de la page (site très modulaire, maintenu par plusieurs personnes, ou par méconnaissance), autant passer directement à la logique HTML5, vous devrez vivre avec une hiérarchie de titres différente selon le navigateur. Si vous aviez une belle hiérarchie et beaucoup de titres, alors pour la conserver sur tous les navigateurs, il vous faudra éviter les balises sectionnantes comme article, section ou aside.
Canvas▲
Canvas est effectivement un trou noir d'où rien ne sort et ironiquement, même Flash peut être plus accessible que cette balise (encore une fois, si le développeur Flash a fourni un effort supplémentaire). Seul IE9 permet d'accéder au shadow DOM, mais en supposant que tous les navigateurs fassent de même, la question de l'intérêt se pose : pourquoi accéder à des paquets de pixels ? Si vous l'utilisez pour obtenir des effets graphiques décoratifs, un contenu alternatif textuel peut suffire. Si vous l'utilisez pour la navigation, vous vous êtes probablement trompé de technologie. Si votre application repose de manière justifiée sur cette technologie, comme pour un jeu, alors il me semble de toute façon impossible de rendre accessible ce type d'application très graphique.
En conclusion▲
Ressortez donc les bonnes pratiques, fournissez un contenu alternatif si c'est possible et évaluez bien vos besoins : SVG / VML ou une navigation scriptée peuvent suffire.
Passer à ARIA▲
Ma conclusion personnelle est qu'il faut rajouter ARIA et ses multiples rôles à votre page HTML5. Voici ce que j'utilise occasionnellement pour tester l'ajout d'ARIA ou pour vérifier l'accessibilité d'une page.
Pour tester ARIA, il vous faut un Windows, un Firefox et un Internet Explorer 8 qui sont les deux navigateurs les plus utilisés par les clients des lecteurs d'écran.
Ce sont également les deux navigateurs qui supportent le mieux ARIA. En lecteur d‘écran JAWS par Freedom Scientific est clairement le leader du marché,
suivi par Window-Eyes de GW Micro. Ils offrent tous deux des versions d'essai gratuites dont la limite est que vous devez redémarrer Windows toutes les 40 minutes.
Astuce : utilisez des machines virtuelles et la fonctionnalité snapshot pour vous éviter ces redémarrages fastidieux. Vous pouvez également utiliser un lecteur d‘écran open source : NVDA
ainsi que la toolbar Juicy Studio Accessibility Toolbar pour Firefox qui permet de vérifier ses zones pendant le développement.
Conclusion▲
Vaste sujet que l'accessibilité de HTML5 et j'imagine (j'espère!) que des experts en accessibilité passeront sur cet article pour me corriger ou rajouter d'autres difficultés.
En conclusion :
- il me faut l'admettre, l'introduction des nouvelles balises peut causer des bogues majeurs ou gêner des logiciels de lecture d'écran. Ces bogues et cette gêne de la hiérarchie sont là pour plusieurs années tandis que les avantages des nouvelles balises ne sont pas encore massivement arrivés. À vous de voir ;
- l'utilisation des balises video et audio est prématurée à tous les points de vue ;
- il va falloir encore du temps avant que HTML5 ne vous apporte plus d'accessibilité que ARIA. Soit vous passez à ARIA immédiatement, soit vous pariez sur le futur.
Si le ton négatif de ce billet vous fait conclure qu'il ne faut pas utiliser HTML5, alors je vous invite à me relire : j'ai principalement listé les problèmes afin que vous sachiez à quoi vous vous engagez en restant sur les techniques actuelles ou en partant sur certaines nouveautés de HTML5. HTML5 au sens des applications Web avec toutes ses nouvelles API JS ne sont ici pas concernées.
Remerciements▲
Je tiens à remercier Mahefasoa et jacques_jean pour leur relecture de cet article.
L'article original et les commentaires peuvent être lus sur le site BrainCracking : État des lieux de l'accessibilité de HTML5.