Accessibilité du Web 2.0 avec et .

2. Accessibilité du Web 2.0 avec et . Code Session : ACC301 Philippe BERAUD Consultant Architecte Direction Technique Microsoft France philippe.beraud@microsoft.com David Rousset Evangéliste Développeur DPE Microsoft France davrous@microsoft.com

3. Le parcours "Accessibilité Numérique" dans le cadre des Microsoft TechDays 2011 • 2 sessions pour faire un point ensemble • Session ACC301 "Accessibilité du Web 2.0 avec HTML5 et Silverlight " • Cette session !! • Session ACC201 "SharePoint 2010 : le Web pour tous" • A revivre prochainement en webcast

4. Objectifs et sommaire de la session • Pourquoi l’accessibilité ? • Silverlight et l’accessibilité • HTML5 et l’accessibilité • Conclusion

5. Qu’est ce que l’accessibilité ? Cela peut représenter différentes choses en fonction des personnes Visuel Physique Audition Langage Difficultés d’apprentissage

6. La carotte… • La population âgée est de plus en plus importante • Des millions d’utilisateurs souffrent de déficiences diverses •  Vous pouvez permettre à ce type de population de bénéficier de vos produits

7. …ou le bâton? United Nations G3ict (Global Initiative for Inclusive ICT) EC – Mandate 376 i2010 Initiative Member States Accessibility UK: Disability Discrimination Act (DDA) Japan JIS-X8341 Australia: Disability Discrimination Act Section 508 Refresh Section 255 Telecom U.S. State Accessibility OAS / L.A. / S.A Country Policies New Zealand Government Web Standards 9

8. Quels bénéfices à part les obligations légales ? • Augmenter l’adoption de vos produits • Améliorer l’ergonomie de vos interfaces • Augmenter le « ranking » au près des moteurs de recherches (SEO)

9. Un moteur de recherche connu ressemble à un aveugle ! http://www.slideshare.net/AaronGustafson/progressive-enhancement-with-aria-accessibility-summit-2010-5324750

10. Le Web 2.0 et l’accessibilité : pas une belle histoire d’amour… • L’arrivée de l’utilisation intensive du JavaScript (AJAX, jQuery, etc.) • Du contenu très riche visuellement mais très difficile d’accès pour les technologies d’accessibilité • Elles ne savent pas qui fait quoi • Manque de sémantique • Des zones dynamiques dans la page impossible « à voir » ou détecter

11. A quoi dois-je faire attention ? Au clavier • Votre application doit pouvoir fonctionner sans souris • … voir fonctionner sans clavier ! (Merci Kinect) Au visuel • Votre application doit être « visible » à un lecteur d’écran • Votre application doit pouvoir être utilisée par des personnes avec une acuité visuelle limitée A l’audio • Votre media doit pouvoir être « lu » et pas uniquement être écouté

12. Regardons d’abord du côté de Silverlight

13. Silverlight Accessibilité au clavier

14. Démo Accessibilité au clavier d’une application Silverlight

15. Accessibilité au clavier • Bilan • Cela était joli… • … mais non accessible • Utilisez les contrôles pour les tabulations et le support du focus • Gérez le clavier pour mettre en place des actions particulières • Mais faites attention aux raccourcis claviers gérés par le navigateur par exemple

16. Permettre une navigation avec le clavier • Indiquez quels contrôles peuvent recevoir le focus en spécifiant la propriété IsTabStop • Précisez l’ordre de navigation par tabulation avec la propriété TabIndexdes éléments • Seuls les éléments de type contrôles (héritant de Control) peuvent recevoir le focus • Pour les autres éléments (images, multimédia, etc.), si vous prévoyez une accessibilité au niveau du clavier : • Spécifiez une commande clavier ou un contrôle associé dans l’IHM • Sinon, créez un contrôle personnalisé contenant l’élément visuel et ajouter la logique d’interaction au clavier dans celui-ci • N’oubliez pas de fournir une indication visuel lors du focus de l’élément

17. Fournir les indications sur le focus • Visuellement un contrôle doit montrer qu'il possède le focus • Si le contrôle dérive d'un contrôle Silverlight existant • Utilisez le gestionnaire visuel d'état (Visual State Manager) pour spécifier un modèle de contrôle qui définit visuellement le focus • Si lecontrôle est complètement personnalisé • Créez un focus visuel propre et ajoutez du code dans les handler d'évènement GotFocuset LostFocuspour afficher/cacher l’indicateur visuel

18. Silverlight Accessibilité visuelle

19. UI Automation(UIA)En 30 secondes… • API d’accessibilité fournies dans Silverlight • UIA expose chaque partie de l’UI, ses propriétés, son état, etc. aux applications clientes et technologies d’assistance (JAWS, NVDA, narrateur, etc.) <button x:Name="openBookButton" AutomationProperties.Name="Open Book" AutomationProperties.HelpText="Open a Daisy book from your local computer" AutomationProperties.AcceleratorKey="0" ... <button>

20. Démo Support d’un lecteur d’écran avec Silverlight

21. Accessibilité pour lecteur d’écran • Bilan • Utilisez les contrôles livrés par défaut et faites du « retemplate » • Certains contrôles ont besoin de métadonnées supplémentaires • Si vous partez de 0, créez votre propre AutomationPeer • Identifiez les contrôles non textuels (par ex. des images) • AutomationProperties.Name

22. Démo Application avec contrôles personnalisés

23. Accessibilité visuelle • Attention aux couleurs et au contraste • 8% des hommes ne peuvent faire la différence entre le rouge et le vert (aux Etats-Unis)

24. Démo Gestion du contraste élevé

25. Accessibilité visuelle • Pour supporter le contraste élevé • Analysez la propriété SystemParameters.HighContrast • Jouez avec les styles • Le Toolkit Silverlight propose un thème adapté • Ne vous contentez pas de la couleur • Ajoutez d’autres formes ou mise en forme du texte • Zoom et large taille de police • Assurez vous que votre application réagisse au zoom du navigateur • Fournissez un contrôle permettant de choisir la taille de la police

26. Démo Bonnes pratiques : Lecteur Silverlight DAISY sous licence libre

27. Silverlight Accessibilité audio

28. Accessibilité audio • Utilisez des lecteurs média prêt à l’emploi • Accessible Media Project (AMP) sur Codeplex • http://amp.codeplex.com/ • Expression Encoder • Utilisez des sous-titres

29. Démo Player AMP

30. Regardons maintenant du côté de HTML5 et WAI-ARIA

31. HTML5 : le futur • La prochaine version du markup HTML • De nouvelles balises permettant de clarifier les rôles • Beaucoup de parties ne sont pas encore implémentées voire même encore statuées • Certains parlent de 2022 ! • De nombreuses nouveautés permettront aux développeurs web de créer du contenu accessible… et aussi totalement inaccessible • La spécification est énorme ! Environ 800 pages

32. HTML5 : un gros potentiel • Nouveaux éléments sémantiques • <nav>, <article>, <footer>, etc. • Fournirons une structure sémantique jusqu’à présent inexistante • Pas encore implémentés dans tous les navigateurs • Pas encore supportés par les technologies d’assistance

33. Futur potentiel Avant en HTML4 Après en HTML5

34. WAI-ARIA : le présent • Permet l’ajout d’un nom, d’un rôle, d’un état à n’importe quel élément via des attributs <div role=“slider”> <input aria-required=“true”> <imgrole=“presentation”> <input type=“text” aria-haspopup=“true”> • Toujours en cours de développement mais de nombreuses parties sont stables et implémentées dans les navigateurs et les technologies d’assistance • Peut être utilisé avec HTML, XHTML, SVG, etc.

35. API d’accessibilité Périphérique d’entrée role=button Navigateur state=focused value=submit query action=press

36. Landmark Roles vs. HTML5 Section Elements ARIA HTML5 <header> ? Pas d’équivalent <nav> <input type="search"> ? Pas d’équivalent <aside> <form> Pas d’équivalent role="banner" role="main" role="navigation" role="search" role="contentinfo" role="complementary" role="form" role="application"

37. Pragmatisme HTML4 + ARIA HTML5 + ARIA

38. Accessibilité au clavier

39. Potentiel : HTML5 Formscontrols • Input type="number" • Input type=“date" • Input type=“range" Très bon support dans Opera, assez bon dans Chrome, léger dans Firefox 4 et inexistant dans IE9 mais… Inaccessible dans tous ! 

40. Démo Web Forms dans Opera et chez les autres

41. Démo WAI-ARIA

42. Accessibilité visuelle

43. HTML5 <canvas> • Super sexy pour les personnes voyantes ! • Mais totalement invisible dans le DOM et donc pour les personnes malvoyantes… • L’unique alternative consiste donc à dupliquer le contenu pour le rendre accessible • Ne mettez pas ce contenu dans le tag <canvas> mais en dehors

44. Démo HTML5 <canvas> avec contenu alternatif

45. <SVG> • Toujours aussi sexy pour les voyants ! • Et déjà plus sympa pour les malvoyants car visible dans le DOM  A privilégier à <canvas> si l’accessibilité est une cible • Doit être utilisé avec ARIA en complément

46. <SVG> et ARIA <svgwidth="6cm"height="5cm"viewBox="0 0 600 400" xmlns="http://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"/> <textid="text1"x="160"y="100"font-size="40"> svg circle checkbox 1 </text> </svg>

47. Démo <SVG> avec attributs ARIA

48. Accessibilité audio

49. HTML5 <audio> & <video> • Permet de s’affranchir des plug-ins Silverlight ou Flash pour le contenu audio/vidéo • Les lecteurs ont un support disparate du clavier • L’unique alternative consiste donc faire un transcript en texte pour le rendre le contenu accessible • A nouveau, ne pas mettre ce contenu dans le tag <audio> ou <video> mais en dehors  Avantage : indexation par les moteurs de recherches !

50. Démo Lecteur HTML <audio> accessible au clavier Lecteur HTML <video> avec sous-titres