· Tech watch

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.

Ajouter un commentaire

8 commentaires

  1. Nicolas Hoffmann

    J’avais ouï dire que certaines API comme « Drag and Drop » étaient un poil limites si on ne mettait pas une couche d’ARIA dessus, tu confirmes ou pas ?

    Répondre

  2. Stéphane Deschamps

    Nicolas,

    Effectivement tu as raison j’aurais dû parler de cette API-là, qui n’était pas vraiment dans les préoccupations de cet article à la base (j’ai tracé à grands traits, je voulais surtout traiter les points les plus saillants).

    Je n’ai pas encore creusé le sujet du drag’n’drop, ça fera l’objet de ma veille à venir :)

    Répondre

  3. Steve Faulkner

    Hi Stephane,

    HTML5Accessibility.com provides and overview of current support browser support for a range of ‘new’ HTML5 features. Implementation status for HTML5 element/attribute accessibility mappings provides in depth results for the support of accessibility semantics requirements in the HTML5 Recommendation. As far as the HTML5 outline algorithm is concerned the HTML5 REC states: “Warning! There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.”

    Further advice and links to bugs on browsers is provided on the W3C Wiki: Use h1 to h6 to identify document structure

    Répondre

  4. Nicolas Hoffmann

    Cool, vivement que l’on te relise sur le sujet. :)

    Mine de rien, c’est un sacré chantier en mouvement, les confs que j’ai vues sur l’accessibilité de HTML5 il y a qq temps sont pour la plupart « obsolètes » (même si je n’aime pas ce mot) tellement ça a beaucoup bougé ces deux dernières années.

    Répondre

  5. Stéphane Deschamps

    Steve, Thanks a lot for the additional information!

    Répondre

  6. Olivier Nourry

    Bonjour Stéphane, et merci pour cette très bonne synthèse.

    Pour tes lecteurs: il faut savoir que le RGAA3 (en cours de retouche suite à l’appel à commentaires public sur la version beta) intègre les possibilités nouvelles offertes par le HTML5 et son indispensable compagnon ARIA. Un gros effort a porté sur la vérification du fonctionnement de ces nouvelles balises dans les navigateurs et surtout les technologies d’assistance. Il suffira donc de vérifier les critères pour être sûr que le service attendu est effectivement rendu à tous les utilisateurs.

    On y trouvera notamment le fait que le titrage « à la HTML4 » reste le seul moyen recommandé, à ce jour, pour une hiérarchie de titres accessible.

    Tu n’as pas du tout évoqué, les images, tiens? Sans doute l’exercice de synthèse impose certains choix, mais il me semble qu’entre CANVAS, FIGURE et SVG on avait de quoi faire un chapitre assez incontournable, et tout-à-fait passionnant!

    Répondre

  7. Bonjour,

    Précision sur le le type date (formulaire).

    En réalité, la proposition d’implémentation sous Chrome desktop (même si, en termes d’accessibilité Chrome ne nécessite pas forcément que le date picker généré par l’interface soit accessible au clavier.

    En effet, le masque de saisie (jj/mm/aaa) proposé par Chrome est lui, parfaitement utilisable au clavier, il s’agit donc de la version alternative accessible du composant date picker proposé qui peut être considéré, dés lors, comme un simple enrichissement.

    Il s’agit, pour le moment, d’un POC, sur le desktop, mais, une fois n’est pas coutume, l’implémentation de Chrome est parfaitement accessible (au sens de WCAG).

    Sinon, super papier, tu à l’art de la synthèse…

    Répondre

  8. Stéphane Deschamps

    Olivier : tu me donnes des idées pour un autre papier :)

    JP : merci pour les précisions !

    Répondre

Ajouter un commentaire

Votre adresse email ne sera pas publiée. Les champs obligatoires sont indiqués par un astérisque.

Vous pouvez utiliser les balises et attributs HTML suivants dans votre commentaire : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre>

Les champs obligatoires sont marqués d'un astérisque (*). Les informations de ce formulaire ne seront pas conservées et ne seront utilisées que pour vous répondre. Conformément à la règlementation applicable, vous disposez d’un droit d’accès, de rectification et d’opposition aux informations vous concernant. Pour plus d’informations sur le traitement de vos données, cliquez ici