CRAW2013 : HTML5, ARIA et accessibilité web

Il y a quelques jours avait lieue la Conférence Romande sur l’Accessibilité du Web 2013 (aka CRAW2013). Organisée par Telono (lien externe) pour la deuxième année consécutive, il s’agit de la première conférence romande sur le sujet de l’accessibilité. Et si la première édition était déjà très réussie, cette deuxième cuvée est vraiment, en ce qui me concerne, une très très grande réussite !

Je vous propose donc un petit compte-rendu en espérant qu’il vous donnera envie de venir jusqu’en Suisse pour la prochaine édition. 🙂
Initialement, je pensais faire un seul article pour ce compte-rendu. Mais il y a tellement à dire que je pars finalement sur un compte-rendu en plusieurs parties. Ça me permet de publier plus rapidement quelque chose, et ça permet aussi d’alléger un peu la lecture. 🙂

Je vais donc attaquer directement dans le dur avec une présentation de Jean-Pierre Villain (lien externe) sur HTML5 et ARIA.

À noter que la conférence ne commençait pas aussi abruptement. Cette présentation était précédée d’une introduction de Florian Egger (lien externe) et Laetitia Giannettini (lien externe) pendant laquelle étaient rappelés les enjeux de l’accessibilité du web. S’agissant des informations classiques d’introduction à l’accessibilité, je saute cette partie. Dans le cadre de la conférence c’est un passage essentiel car le public est très divers et certaines personnes peuvent ne pas être au fait du sujet, cette introduction y a tout son sens. Concernant mon compte-rendu, je fais le choix d’aller directement sur les différents sujets. J’espère que vous ne m’en voudrez pas. 😉

Du HTML4 au HTML5

On commence par une petite leçon d’histoire : HTML4 était un langage simplissime, si bien que pour avoir un minimum d’interaction avec l’utilisateur, les développeurs ont rapidement utilisé Javascript. En terme d’accessibilité, c’était la belle époque : pour faire un site accessible, il fallait que le site soit consultable et utilisable sans javascript.

Le HTML4 étant quand même trop limité pour ce que le web est devenu depuis, le HTML5 est apparu et permet désormais de faire un nombre incroyable de choses facilement. Le HTML4 se résumait à un web de documents, le HTML5 permet un web d’applications.
Mais concernant l’accessibilité, c’est tout autre chose : alors qu’en HTML4 il suffisait de proposer des alternatives au Javascript, en HTML5 Javascript est indissociable du HTML. Mieux encore, c’est désormais sur Javascript qu’il faut compter pour pouvoir faire un site accessible !

Une fois ce contexte posé, Jean-Pierre nous propose un petit état des lieux de l’accessibilité en HTML5. À commencer par un constat simple : le HTML5 est une spécification vivante et en constante évolution, il est donc urgent de se pencher sur l’accessibilité du langage pour savoir ce qu’on peut ou non utiliser.
Car au delà du travail des concepteurs web, l’accessibilité du langage nécessite d’être aussi prise en charge par les éditeurs de navigateurs et les technologies d’assistance. Dans un contexte en perpétuel mouvement, on a donc beaucoup de mal à avoir des implémentations stables et surtout uniformes en fonction des plateformes et des outils de navigation.
D’après Jean-Pierre, il faudra d’ailleurs attendre 3 ou 4 ans avant d’avoir une situation homogène. Et ce n’est pas le récent retrait de la  nouvelle » balise hgroup qui lui donnera tort.

HTML5 et l’accessibilité

Jean-Pierre nous fait un petit tour des nouveautés apportées par HTML5 et leur impact sur l’accessibilité.
Il a été dit énormément de chose, je vous restitue donc tout ce que j’ai pu noter, mais c’est loin d’être complet. Il faudra attendre la diffusion de la présentation pour avoir tous les détails. 😉

  • La balise figcaption permet de renseigner une légende à un média. Problème : en termes d’accessibilité, cette balise est actuellement très mal gérée voire pas du tout. Pour faire un site accessible, il faut donc éviter de l’utiliser, ou mettre en place un fallback. Il donne l’exemple du rôle ARIA group, à définir sur le conteneur de l’image et de sa description.
  • Toujours dans la catégorie des média, le SVG et la balise canvas peuvent être utilisés sans problème, à condition de renseigner une alternative.
  • L’une des grandes nouveautés du HTML5 est l’ajout des balises audio et video permettant de gérer nativement les média, sans plugin. Si ces balises sont désormais assez bien implémentées par les différents navigateurs, Jean-Pierre met en garde contre l’utilisation des contrôles par défaut. Ils sont en effet inaccessible et il préconise donc d’utiliser une solution comme Acorn Media Player (lien externe), qui offre des contrôles accessibles.
  • Une grosse nouveauté est la possibilité d’inclure n’importe quel type d’élément dans un lien, alors qu’on pouvait seulement inclure des éléments en ligne en HTML4. L’un des effets négatifs étaient que pour faire un lien sur un bloc complet, il fallait répéter le lien autant de fois qu’il y avait d’éléments dans le bloc. En terme d’accessibilité, on multipliait donc considérablement la liste des liens d’une page. Même si la restitution n’est pas parfaite partout, ça ne peut pas être pire qu’avant donc il ne faut pas hésiter à profiter de cette nouvelle possibilité.
  • Concernant les formulaires, de nombreux nouveaux types de champs existent. Ils sont déjà partiellement implémentés dans certains navigateurs mais peu ou mal gérés sur le plan de accessibilité. On doit donc continuer à utiliser les solutions Javascript usuelles, au moins pour un moment. Seules exceptions : les types datalist, progress et range qui sont correctement rendus dans la majorités des configurations.
  • Jean-Pierre met aussi en garde contre l’outline (ndla : plan du document). En effet, la spécification HTML5 apporte une toute nouvelle logique de structuration, permettant notamment de mettre uniquement des titres de niveaux 1 sur la page. Le plan du document est alors automatiquement formé en fonction de la position des titres dans la page (un h1 dans un article sera l’équivalent d’un h2, etc). Dans les faits, l’implémentation n’est pas aussi simple et il est conseillé de conserver la hiérarchisation qu’on connaît jusqu’à présent, à savoir un titre unique de niveau 1 et des titres de niveaux 2 à 6 correctement hiérarchisés.
  • Enfin, la spécification HTML5 s’est vue enrichie par l’ajout d’une balise main. Jean-Pierre conseille vivement de l’exploiter car elle permet de délimiter le contenu principal de la page très simplement. Même si elle n’est pas implémentée partout, elle a un intérêt indéniable pour l’accessibilité.

Si HTML5 apporte un tas de nouveautés favorisant à priori l’accessibilité, on voit qu’il reste encore du travail. ARIA nous aide donc à rendre les sites et applications web plus accessibles.

HTML5 et ARIA

Pour commencer, ARIA permet de définir des rôles aux éléments de la page.
Par exemple le rôle banner permet de définir l’entête principale du document. Au contraire de la balise header en HTML5, qui peut définir l’entête d’à peu près n’importe quoi. On utilisera donc le rôle banner sur le header principal de la page, pour souligner qu’il s’agit de l’entête principale.
Il faut cependant faire attention à l’usage qu’on fait des rôles. En effet, le rôle ARIA surpassera systématiquement la valeur « naturelle » de l’élément sur lequel il est appliqué.
Si on applique par exemple un rôle presentation sur un titre, ce dernier ne sera plus considéré comme un titre pour les technologies d’assistance, et donc exclu de la liste des titres.
Il convient donc d’être attentif de l’usage qu’on fait d’ARIA.

Jean-Pierre explique ensuite l’utilité d’ARIA pour décrire les composants et leurs changements d’états. Il fait notamment la démonstration d’un slider totalement utilisable avec un lecteur d’écran.
S’agissant d’un sujet technique, il n’est pas rentré dans les détails et si vous souhaitez aller plus loin, je vous invite à lire l’introduction à WAI-ARIA (lien externe) sur Les intégristes. 🙂

Enfin, il a aussi décrit l’usage des attributs aria-labelledby et aria-describedby. Très simple à mettre en place (il suffit d’ajouter les attributs dans le code), ils permettent de lier des contenus entre eux. Le cas le plus utile concerne les formulaires et particulièrement les messages d’aide qu’on retrouve souvent accolés à certains champs. Lorsque ces messages d’aide sont des phrases, ils sont généralement placés après le champ. Le problème dans ces cas là est que les technologies d’assistance n’ont aucun moyen de savoir à quel champ le message se rapporte. Pire, puisqu’il est placé à la suite du champ, l’utilisateur remplira le champ sans avoir connaissance du message.
Imaginez qu’on ait un champ et un texte d’aide en dessous. Il suffit que le texte d’aide soit dans un contenant portant un id « aide » par exemple. Le simple fait d’ajouter l’attribut aria-describedby ayant pour valeur « aide » sur le champ, la liaison entre le champ et l’aide sera automatique !

Pour conclure sur cette tartine technique, Jean-Pierre conseille enfin de toujours utiliser HTML5 et/ou ARIA avec beaucoup de précaution. Aussi magiques soient-elles, toutes ces nouveautés (plus ou moins) sont parfois très mal implémentées. En règle général, il faudra privilégier l’utilisation de HTML5 sauf si le rendu n’est pas terrible ou si le support des navigateurs et/ou technologies d’assistance est mauvais.

Ce n’est qu’un début…

Voici donc un petit concentré de cette présentation très très intense de Jean-Pierre Villain. 😉 Vous vous doutez qu’au delà de la richesse de la présentation, nous n’avons là qu’un petit aperçu de l’énorme chantier pour l’accessibilité concernant HTML5 et ARIA. Du fait de l’implémentation continue de ces spécifications (notamment pour l’HTML5), créer un site ou un service accessible en HTML5 revient à « marcher sur des œufs ». Il faudra donc passer beaucoup de temps à tester tout ce qu’on fait pendant les prochaines années.
Il en profite pour préciser que des validateurs ARIA sont développés mais des outils comme aViewer (lien externe) et Inspect32 permettent d’ores et déjà de tester son code ARIA.

Enfin il faut noter qu’une première version HTML5 du référentiel Accessiweb (lien externe) est prévue pour le mois de juin. Son élaboration dure depuis déjà de nombreux mois et elle devrait donc déjà donner de nombreuses billes pour savoir ce qu’il est possible ou non de faire. 🙂

Voilà ce que j’ai pu retenir de ces 45 minutes (théoriques 😛) de présentation et je vous dis à très bientôt pour la suite de mon compte-rendu de cette journée très riche en informations et découvertes. 😀

Mise à jour du 25 avril 2013
La présentation est désormais disponible sur Slideshare (lien externe).