Techdays 2011 – slides et ressources de la session Accessibilité d’HTML5 et Silverlight

J’avoue que je suis content du nombre de présents que nous avons eu à notre session sur l’accessibilité du Web 2.0 aux TechDays 2011. Vous étiez en effet plus de 200 sur un thème souvent peu consulté. Merci à ceux qui sont venus assister à notre session! Pour vous et pour les autres qui n’ont pu venir, vous pouvez télécharger les slides ici ou directement les consulter à travers cette page grâce à PowerPoint WebApp :

Nous devrions avoir le webcast de cette session courant du mois de Mars. Je viendrais alors mettre à jour ce post pour y faire référence.

Mise à jour du 25/03/2010. Voici le webcast de cette session :

En complément, je vous propose à travers cet article de découvrir l’ensemble des démonstrations que j’ai jouées pendant cette session.

Tout d’abord, toutes les démos de lecture d’écran ont été faites avec le logiciel NVDA gratuit et open source : https://www.nvda-project.org/ . N’hésitez donc pas à le télécharger pour tester vos applications RIA.

Allez commençons par regarder du côté de Silverlight.

Pour la démo d’accessibilité au clavier et la lecture d’écran avec l’utilisation de propriétés UI Automation, j’ai utilisé cette solution Visual Studio :

La conclusion à cette étape était de vous indiquer de bien partir d’un contrôle de base de Silverlight si vous souhaitez rendre accessible votre application. En effet, les contrôles de base embarquent déjà toute la mécanique nécessaire à l’accessibilité clavier et visuelle. D’une manière générale, si le sujet vous intéresse, je vous conseille vivement la lecture de cet article : Making Silverlight Applications Accessible qui regroupe le B-A-BA de tout ce qu’il faut savoir sur l’accessibilité des applications Silverlight.

Ensuite, si vous souhaitez créer vos propres contrôles et les rendre accessibles, il faudra créer votre propre AutomationPeer. J’ai trouvé 2 exemples intéressants de contrôles relativement “complexes” et néanmoins parfaitement accessibles réalisés par Hitachi :

- HITACHI Double-Layered_Tab_Panel
- HITACHI Accessible_RIA_Prototype

Je vous conseille également la lecture d’un document qu’ils ont écrit sur le sujet : Silverlight Accessibility Issues and Proposed Guidelines by Hitachi

Pour la gestion du contraste élevé, vous pouvez tester la propriété SystemParameters.HighContrast dans vos applications pour réagir correctement au changement de contraste afin d’appliquer un style adapté à la lecture de votre application dans ce mode. Pour vous aider, il existe un thème prêt à l’emploi dans le toolkit Silverlight.

Vous pouvez le tester ici : https://www.silverlight.net/content/samples/sl4/toolkitcontrolsamples/run/default.html en basculant votre machine en mode contraste élevé (ALT gauche + MAJ gauche + impr. Ecran). Vous pouvez également retrouver un exemple dans le lien précédent Making Silverlight Applications Accessible .

Ensuite, afin d’avoir une idée des bonnes pratiques de développement sur l’accessibilité, je vous conseille de regarder le lecteur Silverlight DAISY (sous licence libre). Vous pouvez le tester ici : https://www.buttercupreader.net et télécharger le code source ici : https://buttercupreader.codeplex.com/ . Vous pourrez alors voir comment l’application gère correctement le zoom, les modes de contraste, l’accessibilité au clavier, etc.

Au sujet de l’accessibilité audio d’un player audio/vidéo, je vous conseille le projet Accessible Media Projet (AMP) sur Codeplex : https://amp.codeplex.com qui permet l’insertion de sous-titres synchronisés sur la vidéo pour les sourds et mal-entendants. Je vous ai montré en démo le tutorial proposé sur le site : https://amp.codeplex.com/wikipage?title=tutorial_1&referringTitle=Documentation à l’aide de la vidéo “Elephants Dream” au format h264.

Silverlight est donc pleinement armé à l’écriture d’applications RIA accessibles. Il vous permettra également d’avoir un comportement identique (et donc une écriture unique) sur l’ensemble des plateformes et navigateurs officiellement supportés : IE, Chrome et FireFox sur Windows ainsi que Safari, Chrome et FireFox sur MacOS. Je n’ai pas eu le temps de tester le support sous Linux avec le projet MoonLight. Si vous l’avez fait, je suis preneur du retour !

Allez, regardons maintenant ce qu’il se passe du côté de HTML5 (avec ce joli logo HTML5 en braille ! ).

HTML5 est vraiment plein de promesses pour l’accessibilité. Malheureusement, comme tout le reste d’HTML5, de grandes parties sont encore trop jeunes et mal (voir pas) supportées correctement à travers les différents navigateurs. Si vous cherchez un peu sur le net, vous finirez par tomber sur ce site : https://www.html5accessibility.com/ (avec une version française ici) qui tente de faire un état des lieux (peu glorieux) du niveau de support de chacun des acteurs majeurs des navigateurs (Chrome, Firefox, IE, Opera et Safari). Je n’aime pas trop en général ce genre de site mais celui-là est relativement programmatique et pas trop orienté. Gardez en tête également que le navigateur n’est qu’un des maillons de la chaine complète d’accessibilité : contenu –> navigateur –> OS –> technologie d’assistance –> éventuel périphérique d’assistance –> utilisateur.

Il existe heureusement quelques tentatives de solutions (comme les fallbacks ou shims pour HTML5/CSS3) décrites ici : https://www.temesis.com/html5accessibility/index-aria.html

Nouveaux Tags sémantiques et WAI-ARIA

Un des éléments les plus intéressants d’HTML5 pour l’accessibilité est l’ajout de nouveaux tags sémantiques qui vont enfin donner du sens à des <div> que nous nous contentions de décorer de classes telles que class=”footer” ou class=”sidebar”, etc qui ne veulent rien dire en soi finalement. Les technologies d’assistance vont donc pouvoir s’appuyer sur cette nouvelle structure sémantique d’HTML5 pour comprendre la structure de notre page.

L’idée est donc de passer du schéma de gauche à base d’HTML4 vers le schéma de droite à base d’HTML5 :

Cependant, c’est un scénario idyllique qui est décrit dans cette slide où l’ensemble des navigateurs du marché actuellement utilisés supporteraient ces nouvelles balises et les exposeraient correctement aux technologies d’assistance qui seraient quoi en faire ! C’est pour cela que je parle de futur potentiel. Heureusement, il existe une initiative parallèle nommée WAI-ARIA permettant de décorer nos éléments HTML avec des attributs (Landmark Roles) leur donnant du sens. Cette approche semble aujourd’hui mieux supportée par les navigateurs et les technologies d’assistance. Cette technologie peut être combinée avec HTML4 ou HTML5. Une bonne approche programmatique consiste donc à suivre la logique suivante :

Mieux vaut en effet donner plus de sens à un élément que pas du tout.  

Il y a également d’autres approches dans HTML5 qui sont intéressantes pour rendre nos pages plus accessibles. En effet, l’ensemble des beaux contrôles que nous utilisons en général aujourd’hui (de type slider, calendrier, etc.) et qui sont arrivés avec le fameux “Web 2.0” sont écrits à l’aide de JavaScript. Leur côté dynamique les rends inaccessibles aux technologies d’assistances.

Web Forms 2.0

Les Web Forms 2.0 (ou HTML5 Forms) proposent d’étendre le type d’entrées disponibles dans un formulaire pour aller plus loin qu’une simple saisie de type texte. Opera est à l’origine de cette spécification qui est assez logiquement très bien supportée par leur propre navigateur Opera 11. C’est ensuite relativement bien supporté dans Chrome 11 et un peu moins encore dans Firefox 4. Quand à nous, nous avons décidé de faire l’impasse dessus dans IE (avec IE9 donc) pour le moment. Vous avez donc pour l’instant un support natif disparate. Bien qu’il existe des initiatives telle que celle-ci : https://code.google.com/p/webforms2/ pour palier à ce manque de support, cela ne résout malheureusement pas le problème de l’accessibilité au clavier et visuelle de ces nouveautés.

Pour vous en convaincre, je vous invite à tester cette belle démo fabriquée par Opera : https://people.opera.com/howcome/2010/forms/ dans les dernières versions des navigateurs. Je l’ai moi-même testé avec Opera 11.01, Chrome 11 dev, FireFox 4.0b11 et IE9 RC (classement par niveau de support). Vous constaterez alors un support partiel au clavier mais un support inexistant de la part des Screen Readers manifestement.

Pour du contenu plus accessible, il faut donc plutôt se tourner vers l’utilisation de WAI-ARIA en attendant. Voici les quelques démos que je vous ai faites pendant la session :

- un exemple de blog utilisant les rôles ARIA : https://www.paciellogroup.com/blog/ 
- un slider accessible au clavier et visuellement : https://www.paciellogroup.com/blog/misc/ARIA/slider/ (testez le avec NVDA par exemple)
- une librairie JavaScript injectant les rôles ARIA dynamiquement dans des tabs : https://easy-designs.github.com/tabinterface.js/ 

HTML5 et ses amis (comme SVG) arrivent également avec de nombreuses choses très visuelles et donc super sexy pour les personnes voyantes mais souvent catastrophiques pour l’accessibilité visuelle… Il va donc falloir faire attention à leurs usages.

<canvas>

La première d’entre elle, et l’une des balises les plus connues actuellement, est la balise <canvas> . L’inconvénient majeur de cette balise est qu’elle est totalement invisible dans le DOM puisque vue comme une feuille de l’arbre. Ensuite, c’est une simple boite noire pour les technologies d’assistance. Il faut donc faire attention à son usage lorsque l’accessibilité est l’une de vos cibles ou l’une de vos priorités. Cependant, il y a de bonnes idées et des bonnes pratiques qui commencent à se développer. Le principe est assez simple : on double le contenu. Le contenu principal doit être accessible à tous et le contenu secondaire présente la même information aux voyants de manière plus “sexy” en faisant appel à la balise <canvas>.

Je vous ai ainsi démontré 2 exemples :

- des données présentées d’abord sous la forme d’un tableau puis ensuite dynamiquement parsées et rendues dans un graphique canvas : https://dwpe.googlecode.com/svn/trunk/charting/index.html
- la 2ème n’est pas basée sur <canvas> mais va dans le même genre d’idées que je voulais faire passer. Cela consiste à présenter un contrôle de type treeview “joli” mais toujours accessible : https://dwpe.googlecode.com/svn/trunk/tree/index.html# . Vous noterez d’ailleurs en analysant le source que les éléments sont décorés de rôles ARIA comme role=”treeitem” par exemple. Cela rend ainsi cet exemple parfaitement accessible au travers de technologies telle quel NVDA.

J’ai pioché dans cette série de 12 exemples issues du livre “Designing with Progressive Enhancement” : https://www.filamentgroup.com/dwpe/#codeexamples

<svg>

Du côté de la balise <svg> , c’est déjà mieux En effet, la description de la scène (rendue de manière vectorielle) se fait à travers une structure XML qui est ensuite reflétée dans le DOM. Nous n’avons donc plus le phénomène de boite noire présent avec <canvas>. Par ailleurs, on peut décorer les éléments SVG avec des rôles ARIA. SVG est donc définitivement à privilégier à Canvas lorsque cela est possible.

Voici par exemple, un extrait de code SVG d’une liste avec des boutons de type checkbox parfaitement accessible :

 <svg width="6cm" height="5cm" viewBox="0 0 600 400"
  xmlns="https://www.w3.org/2000/svg" version="1.1">
<desc>SVG checkbox buttons</desc>

<circle
   id="cb1" role="checkbox" aria-checked="false"
   onclick="toggle(evt.target)"
   aria-label="first svg circle checkbox"
   cx="100" cy="100" r="20"
   stroke="black" stroke-width="5"
   fill="white"/>
<text id="text1" x="160" y="100" font-size="40">
 svg circle checkbox 1
</text>
</svg>

Je vous ai ainsi démontré ces 2 exemples dans la session TechDays :

- cette fameuse liste à base de checkbox SVG : SVG and HTML and ARIA

- une barre de progression en SVG : Making Progress with SVG qui fournit apparemment plus d’informations sous NVDA avec Firefox 4.0 qu’avec IE9 dans mes tests. Testez le donc aussi avec votre navigateur préféré sur votre machine pour observer le résultat.

<audio> et <video>

Terminons par, peut-être, les balises les plus “médiatiques” : celles nous permettant de lire du contenu audio ou vidéo directement pris en charge par le navigateur sans avoir besoin de technologies de plug-ins de type Silverlight ou Flash.

Outre le bazar lié au choix du codec, il faut également faire attention à l’accessibilité clavier des players audio et video HTML5. Les players natifs à chacun des navigateurs modernes actuels (IE9, Firefox 4, Chrome 10, Opera 11 et Safari 5) ont un support disparate de l’accessibilité au clavier et c’est encore moins bon pour les technologies d’assistance visuelle. Vous trouverez un statut plus complet à ce sujet ici : Creating Your Own Accessible HTML5 Media Player

Heureusement, il est facile de refaire son propre player en se branchant sur les APIs liées à ces balises pour améliorer l’expérience.

Je vous ai ainsi présenté l’exemple du player audio accessible suivant : HTML5 Audio Controls Test où vous pouvez tester l’accessibilité du player natif à votre navigateur et l’accessibilité du player audio refait pour un meilleur support de l’accessibilité au clavier.

Pour finir, il reste le problème de l’accessibilité audio du contenu joué au sein des balises <audio> et <video>. La meilleure des approches que j’ai pu trouver fut créée par Bruce Lawson (un évangéliste de chez Opera connu, entre autres, pour avoir co-écrit l’excellent livre Introducing HTML5). Il a écrit un article à ce sujet : Accessible HTML5 Video with JavaScripted captions et vous y trouverez une démonstration montrant la technique en œuvre ici : HTML5 Video with JavaScripted synchronised captions: demo

Cependant, comme il a encodé sa vidéo au format Theora, sa démonstration ne fonctionne que sous Opera, Firefox et Chrome (Ah! La galère des codecs avec HTML5 <video>….). Je me suis ainsi permis de ré-encoder la vidéo au format h264 pour y ajouter le support d’IE9 et Safari. Vous pouvez donc tester la même démo ici : https://david.blob.core.windows.net/videos/accessible-html5-video-captions.htm si votre navigateur ne supporte pas le codec Theora.

Cerise sur le gâteau de cette excellente approche, le contenu audio de vos éléments audio/vidéo devient indexable pour les moteurs de recherches !

Références

Il est malheureusement très difficile de trouver de la bonne documentation sur l’accessibilité d’une manière générale. Pour vous faire gagner du temps, voici les références qui m’ont été indispensables à la création de ce contenu et que je vous conseille vivement de lire si vous souhaitez aller plus loin :

HTML5

- HTML5 accessibility - is it ready yet ? et HTML5 & WAI ARIA - happy-families de l’excellent Steve Faulkner

- Progressive Enhancement with ARIA d’Aaron Gustafson

- Introducing HTML5 de Bruce Lawson et Remy Sharp

Par ailleurs, je suis tombé par hasard via Tweeter sur cet excellent article de synthèse sur l’accessibilité d’HTML5 : Etat des lieux de l‘accessibilité de HTML5 de Jean-Pierre Vincent publié 2 jours avant cet article et que j’avais malheureusement loupé. Je vous le conseille vivement !

Silverlight

- Sessions MIX09 et MIX10 :

   - Building Accessible RIAs in Microsoft Silverlight

   - CL51- Building an Accessible Microsoft Silverlight Experience et vous pouvez trouver les slides ici.

- Silverlight Accessibility Issues and Proposed Guidelines by Hitachi : https://www.hitachi.co.jp/universaldesign/silverlight/en/guideline.html

- Making Silverlight Applications Accessible : https://www.silverlight.net/learn/quickstarts/accessibility/

Conclusion

L’accessibilité de vos applications Web 2.0 est un sujet important et ne doit pas être négligé. Cela doit d’ailleurs se concevoir dès le début de vos projets car c’est nettement plus difficile de l’embarquer après coup…

Vous constaterez également que Silverlight semble aujourd’hui parfaitement mature à l’écriture d’applications RIA accessibles. Bien évidement, cela conditionne au fait que vous puissiez (ou vouliez) utiliser cette technologie de type plug-in dans vos projets.

Du côté des standards, les choses semblent s’améliorer mais il reste malheureusement encore beaucoup de choses qui restent inaccessibles. Cela n’est d’ailleurs par forcément la faute des organismes de standardisations comme le W3C. C’est plutôt du côté des autres maillons (développeurs du contenu, éditeur de solutions de technologies d’assistance et éditeurs des navigateurs) que cela se passe. Il est en effet aujourd’hui difficile d’intéresser tout le monde à l’accessibilité.

Cependant, comme nous l’indiquions dans notre session, outre les aspects purement légaux, l’accessibilité de vos applications et interfaces peuvent vous apporter des avantages concurrentiels certains : meilleur SEO, meilleure ergonomie et cible plus vaste. A méditer donc !

David