La session aborde l'accessibilité du web 2.0 et examine l'impact des technologies comme HTML5 et Silverlight sur l'accessibilité pour tous les utilisateurs, y compris ceux en situation de handicap. Les conférenciers discutent de l'importance des rôles et propriétés WAI-ARIA, ainsi que de la nécessité de créer des contenus accessibles dès le début du projet. Bien que HTML5 offre de nouvelles possibilités, des défis subsistent quant à l'accessibilité, en particulier pour certaines fonctionnalités.

2. Accessibilité du Web 2.0 avec et .Code Session : ACC301Philippe BERAUDConsultant ArchitecteDirection TechniqueMicrosoft Francephilippe.beraud@microsoft.comDavid RoussetEvangéliste DéveloppeurDPEMicrosoft Francedavrous@microsoft.com

3. Description de la sessionLes technologies liés au "Web 2.0" introduisent de nombreuses fonctionnalités qui aideront les développeurs à mettre à disposition plus facilement des contenus accessibles MAIS également non accessibles. HTML 5, la nouvelle version d'HTML, n'échappe pas à ce constat. Parfois, cela peut signifier un choix ou peu de travail supplémentaire pour rendre une fonctionnalité utile et utilisable de tous. Que faut-il en retenir ? Dans ce contexte, cette session s'intéresse à l'usage des rôles et propriétés WAI-ARIA dans ce contexte : s'agit-il d'une redondance dans HTML ? Qu'en est-il par ailleurs en termes de support dans IE 9 et d'exposition aux technologies d'assistance ? La session s'intéresse à ces dimensions ainsi qu'à l'outillage disponible pour tester la compatibilité de ces technologies avec les API d'accessibilité.

4. Le parcours "Accessibilité Numérique" dans le cadre des Microsoft TechDays 20112 sessions pour faire un point ensembleSession 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

5. Objectifs et sommaire de la sessionPourquoi l’accessibilité ?Silverlight et l’accessibilitéHTML5 et l’accessibilitéConclusion

6. Accessibilité numériqueDe quoi s'agit-il ?L'accessibilité numérique est une nécessité… De plus en plus de personnes concernées"L’accessibilité est une condition primordiale pour permettre à tous d’exercer les actes de la vie quotidienne et de participer à la vie sociale. Aussi la loi prévoit-elle le principe d’accessibilité généralisée, quel que soit le handicap (physique, sensoriel, mental, psychique, cognitif, polyhandicap). .."Ministère de la Santé et des Solidarités (31/01/2007)…ET constitue EGALEMENT une obligation légale pour le secteur publicCf. Livre blanc "L’accessibilité de quoi s’agit-il ?"http://www.microsoft.com/downloads/details.aspx?FamilyID=b7864e09-be31-49d4-a608-9907d72e8720&displaylang=fr

7. Qu’est ce que l’accessibilité ?Cela peut représenter différentes choses en fonction des personnesVisuelPhysiqueAuditionLangageDifficultés d’apprentissage

8. La carotte… La population âgée est de plus en plus importante

9. Des millions d’utilisateurs souffrent de déficiences diverses Vous pouvez permettre à ce type de population de bénéficier de vos produits

10. …ou le bâton?United Nations G3ict (Global Initiative for Inclusive ICT)EC – Mandate 376i2010 InitiativeMember States AccessibilityUK: Disability Discrimination Act (DDA)Japan JIS-X8341Australia: Disability Discrimination ActSection 508 RefreshSection 255 TelecomU.S. State AccessibilityOAS / L.A. / S.A Country PoliciesNew Zealand Government Web Standards9

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

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

13. 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 quoiManque de sémantiqueDes zones dynamiques dans la page impossible « à voir » ou détecter

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

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

16. SilverlightAccessibilité au clavier

17. DémoAccessibilité au clavier d’une application Silverlight

18. Accessibilité au clavierBilanCela était joli…… mais non accessibleUtilisez les contrôles pour les tabulations et le support du focusGérez le clavier pour mettre en place des actions particulièresMais faites attention aux raccourcis claviers gérés par le navigateur par exemple

19. Permettre une navigation avec le clavierIndiquez quels contrôles peuvent recevoir le focus en spécifiant la propriété IsTabStopPrécisez l’ordre de navigation par tabulation avec la propriété TabIndexdes élémentsSeuls les éléments de type contrôles (héritant de Control) peuvent recevoir le focusPour 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’IHMSinon, créez un contrôle personnalisé contenant l’élément visuel et ajouter la logique d’interaction au clavier dans celui-ciN’oubliez pas de fournir une indication visuel lors du focus de l’élément

20. Fournir les indications sur le focusVisuellement un contrôle doit montrer qu'il possède le focusSi le contrôle dérive d'un contrôle Silverlight existantUtilisez le gestionnaire visuel d'état (Visual State Manager) pour spécifier un modèle de contrôle qui définit visuellement le focusSi 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

21. SilverlightAccessibilité visuelle

22. UI Automation(UIA)En 30 secondes…API d’accessibilité fournies dans SilverlightUIA 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>

23. DémoSupport d’un lecteur d’écran avec Silverlight

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

25. DémoApplication avec contrôles personnalisés

26. Accessibilité visuelleAttention aux couleurs et au contraste8% des hommes ne peuvent faire la différence entre le rouge et le vert (aux Etats-Unis)

27. DémoGestion du contraste élevé

28. Accessibilité visuellePour supporter le contraste élevéAnalysez la propriété SystemParameters.HighContrastJouez avec les styles Le Toolkit Silverlight propose un thème adaptéNe vous contentez pas de la couleurAjoutez d’autres formes ou mise en forme du texteZoom et large taille de policeAssurez vous que votre application réagisse au zoom du navigateurFournissez un contrôle permettant de choisir la taille de la police

29. DémoBonnes pratiques :Lecteur Silverlight DAISY sous licence libre

30. SilverlightAccessibilité audio

31. Accessibilité audioUtilisez des lecteurs média prêt à l’emploiAccessible Media Project (AMP) sur Codeplexhttp://amp.codeplex.com/ Expression EncoderUtilisez des sous-titres

32. DémoPlayer AMP

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

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

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

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

37. WAI-ARIA : le présentPermet 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’assistancePeut être utilisé avec HTML, XHTML, SVG, etc.

38. API d’accessibilitéPériphérique d’entréerole=buttonNavigateurstate=focusedvalue=submit queryaction=press

39. Landmark Roles vs. HTML5 Section ElementsARIAHTML5role="banner"role="main"role="navigation"role="search"role="contentinfo"role="complementary"role="form"role="application"<header> ?

40. Pas d’équivalent

41. <nav>

42. <input type="search"> ?

43. Pas d’équivalent

44. <aside>

45. <form>

46. Pas d’équivalentPragmatisme HTML4 + ARIA HTML5 + ARIA

47. Accessibilité au clavier

48. Potentiel : HTML5 FormscontrolsInput 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 ! 

49. DémoWeb Forms dans Opera et chez les autres

50. DémoWAI-ARIA

51. Accessibilité visuelle

52. 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 accessibleNe mettez pas ce contenu dans le tag <canvas> mais en dehors

53. DémoHTML5 <canvas> avec contenu alternatif

54. <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 cibleDoit être utilisé avec ARIA en complément

55. <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><circleid="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>

56. Démo<SVG> avec attributs ARIA

57. Accessibilité audio

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

59. DémoLecteur HTML <audio> accessible au clavierLecteur HTML <video> avec sous-titres