HTML5 est-il accessible ?

On nous pose souvent la question : « HTML5 est-il accessible ? » D’une part, HTML5 n’est pas une seule entité, un seul corpus technique ; d’autre part l’accessibilité n’est jamais tranchée binairement, c’est une gradation (de « très accessible » à « pas accessible » selon les cas au sein d’une même page, souvent). Tentons d’éclairer la discussion.

HTML5 est qualifié par certains experts de « HTML5 and friends. » Il s’agit en effet de séparer le langage de balises, HTML, de ses API (les moyens pour le navigateur d’interagir avec le langage et avec son environnement).

De nouvelles balises de structure

Les nouvelles balises de structure, header, footer, article, etc. ne servent qu’à indiquer des informations qui manquaient dans le HTML4 et qui soulignent la sémantique globale du document.

Elles ne sont pas comprises par les anciens navigateurs (jusqu’à IE9) , mais la règle de fallback (contournement) qu’ils appliquent est très simple : si une balise n’est pas comprise, afficher son contenu. C’est ce qui fait, par exemple, qu’on peut mettre n’importe quelle balise dans son HTML : quoi qu’il arrive, son contenu sera exposé si la balise elle-même est étrangère au navigateur. Essayez d’insérer une balise toto, pour voir.

Autrement dit : si header n’est pas compris, affichons tout de même le contenu du header. Il existe même une petite bibliothèque Javascript (html5shiv) pour que les anciens Internet Explorer acceptent de les afficher proprement et même de leur appliquer des styles comme un navigateur moderne.

Ces balises de structure ne posent pas de problème d’accessibilité, et il y a fort à parier qu’elles seront même utiles, à terme : aujourd’hui on peut s’appuyer sur l’attribut role pour définir des zones notables dans la page (des landmarks). Par exemple une zone de recherche peut se voir attribuer un role="search", la partie principale du document un role="main", etc., et un raccourci clavier dans Jaws (un lecteur d’écran, c’est à dire un logiciel qui retranscrit, soit à l’aide d’un logiciel de synthèse vocale, soit à l’aide d’une plage Braille, ce que vous voyez à l’écran) permet de sauter de l’une à l’autre.

La sémantique des balises de structure fait même l’objet d’un rattachement formel aux rôles ARIA dans un working draft au W3C.

On peut imaginer qu’à terme on pourra aussi, à l’aide d’un raccourci clavier, naviguer d’un élément de structure à l’autre (de la navigation à la recherche, de la recherche au contenu principal, du contenu principal au pied de page, etc.).

Un nouvel algorithme de hiérarchie de la page

Parmi les nouvelles balises de structure que nous venons de décrire, il y a aussi section. Cette balise permet de définir des sections dans la page (d’où son nom), et dans chaque section l’algorithme HTML5 prévoit de réinitialiser le plan de page.

Jusque-là une hiérarchie correcte en HTML4 était :

<h1>Titre niveau 1</h1>
 <h2>Titre niveau 2</h2>
 <h2>Titre niveau 2</h2>
   <h3>Titre niveau 3</h3>
 <h2>Titre niveau 2</h2>

En HTML5, on peut écrire conformément à la spécification la structure suivante :

<h1>Titre niveau 1</h1>
<section>
 <h1>Titre niveau 2</h1>
</section>
<section>
 <h1>Titre niveau 2</h1>
   <h2>Titre niveau 3</h2>
</section>
<section>
 <h1>Titre niveau 2</h1>
</section>

L’algorithme de structure de la page doit renvoyer la même hiérarchie :

• Titre niveau 1
  • Titre niveau 2
  • Titre niveau 2
    • Titre niveau 3
  • Titre niveau 2

En résumé, un titre dans une section devient automatiquement « l’enfant » du titre précédent dans la hiérarchie de la page. Charge au navigateur de reconstituer correctement cette hiérarchie dans sa moulinette interne.

Pour le moment la seconde structure hiérarchique (celle de HTML5), n’est pas réinterprétée par les outils d’assistance (ni même par les navigateurs au moment où nous écrivons ces lignes. Quant aux moteurs de recherche, on n’a pas encore d’informations sur leur prise en compte de cette nouvelle structure|en —article de 2012, n’hésitez pas à mentionner en commentaire une source plus récente.). Sur ce point-là, on note une légère perte en termes d’accessibilité. Un utilisateur d’outils d’assistance risque simplement de ne pas comprendre les relations hiérarchiques entre les éléments de titre, le temps que les outils se mettent à niveau. Pour autant, ça n’empêche tout de même pas de sauter de titre en titre (là encore il existe déjà un raccourci clavier).

Des balises média

Nouvelles balises de HTML5, audio et video posaient un souci d’accessibilité la dernière fois que j’ai regardé, parce que leurs contrôles (les boutons play, pause etc.) n’étaient pas capables de prendre le focus (autrement dit, le clavier ne passe pas sur l’ensemble des contrôles de l’interface). On ne pouvait donc pas contrôler la vidéo ou l’audio. Dans Firefox par exemple, on peut tabuler jusqu’au lecteur vidéo, appuyer sur la touche espace pour lancer la vidéo, appuyer à nouveau sur la touche espace pour la mettre en pause, mais impossible de déplacer le curseur de temps ou de changer le volume.

Par contre, contrairement aux players vidéo en Flash par exemple, il existe une API normalisée pour pouvoir parler à ces éléments audio et video en Javascript, par exemple monMedia.play(), monMedia.pause(), etc.

Là encore le principe est plutôt celui d’une accessibilité “built-in” plutôt que d’une rétro-ingénierie.

De même, l’intégration des sous-titres fait l’objet d’une API assez simple : il suffit là encore d’ajouter une balise (track) qui pointe vers le fichier de sous-titre.

De nouveaux attributs de champs de formulaires

Les éléments de formulaires bénéficient de nouveaux attributs : en particulier un certain nombre de nouveaux types de champs qui permettent sur un mobile ou une tablette de faire apparaître le clavier le plus adapté à la saisie : type="email", type="url" ne donnent pas le même résultat qu’un simple champ texte (type="text"). À l’aide de ces nouveaux types de champs, on améliore l’ergonomie/l’accessibilité sur les interfaces touch.

Si le navigateur ne comprend pas les nouveaux types (pour Internet Explorer : pas avant la version 10), le mécanisme de fallback des navigateurs est tel qu’on se retrouve avec un input qui se comporte comme un champ texte. Aucune perte d’accessibilité a priori, donc.

Un type qui peut poser problème cependant, c’est le type="date", dont l’interface n’est pas documentée. Par conséquent, pour l’instant à ma connaissance l’accessibilité du composant implémenté par les navigateurs desktop laisse à désirer (pas de gestion correcte du clavier notamment). Ce type a été testé dans Opera avant qu’il n’hérite du moteur de Webkit dans un fork baptisé Blink, il affichait un calendrier qui était un vrai point de blocage au clavier (mauvaise gestion du focus, interface mal exposée aux outils d’assistance).

Pour la petite histoire, les navigateurs desktop récents que j’ai sous la main n’implémentent pas le type de champ « date » (à l’exception de Chrome), ce qui peut s’expliquer notamment par le manque de moyens de transformer l’affichage de la date pour la rendre conforme à la langue de l’utilisateur (à ce jour, le format attendu est YYYY-MM-DD, ce qui ne parle pas forcément à tout le monde, en particulier les gens qui ne baignent pas dans les formats ISO).

Les fabricants de navigateurs dans leur course concurrentielle sont malheureusement souvent plus pressés de lancer des features que de s’assurer de leur accessibilité. Mettons donc pour le moment un bémol sur ce type d’input, à utiliser avec précaution après avoir testé les problèmes éventuels.

Une API DOM

Pour la première fois de son histoire, HTML5 documente l’API DOM : en clair ça veut dire que chaque élément HTML est listé ainsi que toutes les propriétés qu’il doit exposer à Javascript, et toutes les méthodes Javascript qu’on peut lui appliquer. Par exemple, l’élément image (img) nous donne accès à l’adresse de sa source (src) en lecture (dis-moi quelle ressource tu affiches) et en écriture (affiche telle ressource à la place de la source d’origine) ; l’élément video, on l’a vu, nous permet de le jouer (play()) et de le mettre en pause (pause()), etc.

Je ne note pas de souci d’accessibilité à ce niveau-là : le Javascript est ce que l’on en fait. Nous avons enfin une chance de nous attendre à des comportements documentés, normalisés, donc de simplifer le codage : à terme on se libèrera du temps pour mieux écrire son code et se concentrer sur sa qualité (et donc potentiellement son accessibilité) plutôt que sur la compatiblité multi-navigateurs.

Des nouvelles API

Les nouvelles API liées à HTML5 (localStorage qui permet de stocker des données localement, utile par exemple pour accélérer la navigation, geolocation pour savoir géolocaliser le navigateur et lui proposer des services contextualisés) n’ont pas vraiment grand-chose à voir avec l’accessibilité, nous ne voyons pas de souci a priori à utiliser ces nouveautés.

En bref

HTML5 est plutôt une bonne chose en général, il consolide HTML4, explicite les interfaces avec les éléments du code, précise les algorithmes d’interprétation des éléments, fournit grâce à ses API des fonctionnalités jusque-là réservées à des plugins (le multimédia) ou à des applications lourdes (services géolocalisés). Pour ce qui concerne l’accessibilité, vous l’aurez compris, il n’est pas franchement plus préjudiciable que HTML4, et il ne faudrait surtout pas, pour des imperfections, rejeter en bloc toutes ces nouveautés.