Niveau Niveau confirmé

État des lieux de l'accessibilité de HTML5

Articleaccessibilité

Publié par le , mis à jour le (46396 lectures)

accessibilité html5 aria

Après avoir affirmé à Paris Web 2010 que HTML5 était utilisable immédiatement en production, un expert accessibilité m'a repris en disant qu'il était dangereux de dire que HTML5 était accessible (j'en parlais au futur cela dit). Dans le cadre d'un gros projet autour de HTML5, j'ai depuis fait pas mal de recherches ce qui m'a permis de mieux comprendre son intervention.

Je sais qu'il est dangereux de parler en dehors de son domaine d'expertise, mais il faut bien qu'un développeur Web mette les pieds dans le plat et à tout le moins provoque le débat. Autant vous dire que si vous vous y connaissez en accessibilité, je prend tout ajout ou correction. Autant vous le dire tout de suite, mes conclusions sont mitigées, et il se peut même que je revienne sur ce que j'affirmais à l'époque.

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 représente 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'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

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.

Doit-on changer sa manière de coder parce que 2 logiciels buguent ? Historiquement les développeurs Web ont toujours répondu oui à cette question, en changeant leur code pour s'adapter aux bugs 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 2 logiciels. Même si ces bugs 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 bugué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 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.

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 bugué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é.

Conclusion : les balises video et audio sont vraiment trop jeunes concernant l'accessibilité, et il n'y a pas de gros bénéfice à en tirer sur les navigateurs de bureau. Flash étant pire, vous devez améliorer vous même les choses en codant un player 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 au contraire à 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.

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.

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 2 navigateurs les plus utilisés par les clients des lecteurs d'écran. Ce sont également les 2 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 version d'essai gratuit 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 accessibilité passeront sur ce blog pour me corriger ou rajouter d'autres difficultés. En conclusion :

  • il me faut l'admettre, l'introduction des nouvelles balises peut causer des bugs majeurs ou gêner des logiciels de lecture d'écran. Ces bugs 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. A 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 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 APIs JavaScript ne sont ici pas concernées.

Commentaires

Pour audio et video, il existe des couches js pour améliorer l'accessibilité. Mais bon, si js est désactivé…

@Patidou : oui, je l'évoque dans l'article
par contre je ne connais pas de solution toute prête plus efficace qu'une autre car je n'ai pas testé, tu as des noms ?

Un bon article permettant de calmer, si je puis dire, les ardeurs de certains (même si, et tu fais bien, Jean-Pierre, de le donner à entendre dans ta conclusion, l'accessibilité ne consiste pas à interdire le recours à telle ou telle technologie, sous prétexte qu'elle pose des problèmes d'accessibilité). ;)

En ce qui concerne le nouvel algorithme de HTML 5 pour la hiérarchie des titres de section, sa restitution peut produire un résultat surprenant, comme le rapporte Roger Johansson sur son blog : http://www.456bereastreet.com/archive/201103/...

Bref, pour un projet de site Web qui doit être accessible soit par obligation légale soit par labellisation (labellisation Accessiweb, par exemple), il convient d'en rester aux bons vieux HTML 4 et XHTML 1. En revanche, rien n'empêche d'insérer des morceaux de HTML 5 dans un projet Web accessible à environnement maîtrisé (ex. : un Intranet dont on a la certitude absolue qu'il sera consulté depuis des postes équipés exclusivement de Firefox 4, d'IE 8, voire 9, et des dernières versions de Jaws ou de NVDA, avec JavaScript obligatoirement activé) ; mais, l'essentiel, dans ce cas, est d'expérimenter, c'est-à-dire de faire appel à un panel d'utilisateurs qui pourront tester et dire si, en termes d'accessibilité, ils se sont heurtés ou non à des difficultés.

@jpvincent : Je pense que Patidou fait allusion au fait qu'on peut personnaliser en JavaScript les contrôles utilisés pour les éléments audio et video, si l'on ne souhaite pas utiliser les contrôles natifs du navigateur (en omettant d'utiliser l'attribut booléen controls).

Quand j'étais à la conférence "Accessibilité au service du référencement" à Chambéry, Laurence Tézier a fait plusieurs tests de mise en situation, dont un sur mon site personnel, lequel est en (X-)HTML5. A priori aucun problème avec son lecteur d'écran (je ne parle pas de la balise vidéo, bien entendu, mais bien des nouvelles balises comme nav, etc.), qui pourtant utilisait IE.

Pour ma part, je pense qu'on ne doit pas se limiter à l'utilisation des nouvelles balises comme article, nav, etc... (video est déjà plus sensible) à cause de bugs quand même particuliers... pour seulement deux versions (!) de logiciels.

Je pars aussi de l'idée que celui qui est sous IE qui désactive sciemment le Javascript (en situation de handicap ou non d'ailleurs) doit quand même savoir ce qu'il fait. (un expert en logiciels d'accessibilité pourrait-il confirmer ou éclairer ?)

Par contre, je reconnais qu'il manque de "l'offre" accessible (si j'ose dire) point de vue lecteur d'écran, heureusement que NVDA permet de tester gratuitement ses sites sans limitation pénible.

Bonjour a tous et a toutes pas de discrimination :) comme en accessibilité

Je suis pas la pour critiquer l'article mais juste pour rajouté certaine chose :

"Il faut avoir a l'esprit que HTML5 est pas pris en charge par les anciennes version des navigateurs. Cela reviens en plus d'autre chose a faire de l’interopérabilité.
par conséquent, si on veut un site intérop et/ou accessible , il faut pensé a nos boulets de navigateur : IE6 , IE7 (je cite seulement les plus gros boulets, la je sens que je vais me faire des amis chez microsoft ). bref quoi qu'il en soit HTML5 permet de faire des choses sympa sans parler de CSS3 , après il faut penser a qui on s'adresse quand on fait un site Web "

@Nico3333fr : ben j'ai eu l'occasion d'allez chez braillenet cf : http://www.braillenet.org/ , de connaitre Dai... ( cf : http://www.daisy.org/ )
Il est pas simple de faire en sorte de rendre les sites accessibles, car il y a un gros problème : personne ne pense au handicapé et a l'accès par tous a l'information, sans parler du non respect des standard HTML mis en place par le W3C.
Même les développeurs, n'y pense pas ou ne sont pas sensibilisés.

Après je sais et j'ai bien été placé pour le savoir, cela demande 2 a 3 fois plus de taff quand on veux faire des sites normés, compatible et accessible , mais c'est possible !

@Victor BRITO : C'est tout à fait ça ;-)

En ce qui me concerne (débutant en accessibilité), sur mon blog, j'ai fait un compromis : je ne redémarre pas sur un h1 dans un section ou article, mais j'utilise la bonne vieille hiérarchie à l'ancienne. Je n'utilise pas non plus (ou rarement) d'effets spéciaux en JavaScript. Je me suis contenté d'ajouter des rôles aria aux endroits stratégiques (contenu principal, navigation, formulaires, etc).

Il ne reste plus qu'à attendre que les bugs de Jaws et windows-eyes soient corrigés. ;-)

P.S. : j'ai eu l'heureuse surprise de constater que voiceover (sur Mac ou iOS) signalait les champs requis dans les formulaires, je ne sais pas si c'est dû à html5, aria ou les deux. Il faudrait que je teste. :-)