État des lieux de l'accessibilité de HTML5 HTML5 : le multimédia et Canvas
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 mes projets, 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.
Les balises video et audio restent trop jeunes en matière d'accessibilité
Comme vous devez de toute manière fournir une lecture de la vidéo en Flash, qui lui est naturellement encore moins accessible, 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.
Canvas, peu recommandé
Canvas est effectivement un trou noir d'où rien ne sort, et ironiquement même Flash peut être plus accessible que cette balise (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.