Code Session : ACN103 Denis BOULAY Responsable du label AccessiWeb

Présentation au sujet: "Code Session : ACN103 Denis BOULAY Responsable du label AccessiWeb"— Transcription de la présentation:

1 L’accessibilité du Web : enjeux et impacts sur la société numérique française
Code Session : ACN103 Denis BOULAY Responsable du label AccessiWeb Association BrailleNet Philippe BERAUD Consultant Architecte Direction Technique Microsoft France

2 Description de la session
Cette session animée par l’association BrailleNet a pour objectif de présenter les enjeux de l’accessibilité du Web pour les organismes du secteur public et du secteur privé. La situation particulière en France sera analysée avec la publication des recommandations internationales WCAG2.0 du W3C/WAI, la nouvelle référence concernant l'accessibilité du Web, disponible en langue française, et celle du Référentiel Général d'Accessibilité pour les Administrations (RGAA). Cette session s’intéressera également au nouveau référentiel pour l'accessibilité des contenus Web de l'Association BrailleNet, en l’occurrence AccessiWeb 2.0. Enfin, cette session abordera les principales étapes de la conduite d'un projet intégrant l'accessibilité numérique.

3 Le parcours "Accessibilité Numérique" dans le cadre des Microsoft TechDays 2010
3 sessions pour faire un point ensemble Session ACN103 "L’accessibilité du Web : enjeux et impacts sur la société numérique française" Cette session !! Session ACN201 "Conception de sites Web accessibles avec les technologies SharePoint 2007 et 2010" Aujourd'hui de 16h00 à 17h00 Session ACN102 "Créer un livre audio numérique à l'aide de Microsoft Office Word 2007/2010" Aujourd'hui de 17h30 à 18h30

4 Objectifs de cette session
Compléter la session éponyme INT104 animée lors de TechDays 2009 Après un bref rappel de quelques données importantes développées dans la session INT104, il s'agit de Revenir sur des publications récentes (WCAG 2.0, RGAA, AccessiWeb 2.0) et les évolutions du cadre législatif en France Positionner ces différents éléments les uns par rapport aux autres Et d'en mesurer les impacts concrets

5 Sommaire Bref rappel de quelques données importantes de la session INT104 WCAG 2.0 (et les autres recommandations de la W3C/WAI) Cadre législatif français vis-à-vis de l'accessibilité numérique pour le secteur public et RGAA AccessiWeb et ses évolutions Intégrer l'Accessibilité dans ses projets

6 Un bref rappel du contexte Le Web
Technologie la plus rapidement adoptée Source d’information la plus générale Le Web est prévu pour être accessible … "Le pouvoir du Web est dans son universalité. Un aspect essentiel est qu'il soit accessible à tout le monde quel que soit le handicap" Tim Berners Lee, directeur du W3C … Mais si les sites ne respectent pas les règles d'accessibilité, les personnes handicapées ne peuvent pas y accéder via leurs technologies d’assistance !

7 Un bref rappel du contexte Web et Handicap, …et au-delà
Depuis le début du Web, l'accessibilité des contenus électroniques est au cœur de toutes les spécifications des langages Web "Mettre le Web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales." Tim Berners Lee, directeur du W3C L'accessibilité numérique est une nécessité… De plus en plus de personnes concernées …et un instrument de lutte contre l'exclusion des personnes handicapées et des personnes âgées

8 Un bref rappel Web et Handicap, …et au-delà
En France, la population handicapée s'élève à personnes personnes, en France, présente un handicap visuel (soit 5,77%) personnes, en France, présente un handicap moteur (soit 21.63%) personnes, en France, présente un handicap auditif (soit 7.69%) personnes, en France, présente un handicap cognitif (soit 7,21%) personnes, en France, présente un handicap pluri-physiques (soit 12.02%) personnes, en France, présente des pathologies diverses dues au vieillissement (soit 45.67%) Source : enquête HID (Handicaps-incapacités-dépendance) / INSEE 2003 Autres sources : [1] Tous les chiffres sur la population des personnes handicapées à : [2] : [3] : [4] : [5] MeAC - Measuring Progress of eAccessibility in Europe : date

9 Un bref rappel Web et Handicap, …et au-delà
Problèmes rencontrés Handicapés visuels : image, vidéo, signalétique Handicapés auditifs : son (paroles , musique) Handicapés moteurs : difficultés d'utilisation des souris et clavier traditionnels Handicapés cognitifs : sens et compréhension Seniors : difficultés cumulées (vision, difficultés d'apprentissage, atteintes neuro-motrices) La visite d'un site Web non accessible est soit difficile, soit impossible, par manque d'adaptation aux diverses situations de tout un chacun. L'accessibilité numérique est une chance pour les personnes âgées et pour tous ceux qui naviguent "autrement".

10 Un bref rappel Les technologies d’assistance
Destinées aux personnes atteintes de limitations physiques ou cognitives, de troubles et de handicaps Avec l’objectif d’assumer des tâches qu'elles ne seraient pas en mesure d'accomplir ou qu'elles accompliraient difficilement seules Matérielle et/ou logicielle On parle d’"Aides techniques" pour l’informatique

11 Un bref rappel Les technologies d’assistance
Différentes formes pour différents besoins Logicielles Lecteur d'écran Navigateur vocaux (ou autres agents techniques) adaptés Loupe d'écran Matérielles Tablette Braille : ou plage Braille est un dispositif électromécanique permettant d'afficher des caractères braille Clavier adapté : Un clavier adapté devrait permettre aux personnes handicapées de saisir des textes et utiliser l'ordinateur avec un minimum de limitations. Joystick : Le Joystick est un boitier de commande numérique équipé d'un manche et de boutons Trackball : Le trackball est une boule que l'on manipule avec les doigts faisant office de souris Head-stick : Le head-stick est un système de pointage adapté qui s'utilise avec la tête

12 Un bref rappel L'accessibilité des sites Web
Conception pour tous Critère de qualité Contrairement aux idées reçues, un site Web qui respecte les recommandations internationales d’accessibilité n’est pas seulement un site accessible ; c’est aussi un site plus performant ! Ainsi, lorsque l'information sur le Web est conçue et réalisée pour être accessible aux personnes handicapées, Les sites résultants s’en trouvent généralement construits de manière plus logique et mettent l'accent sur le contenu plutôt que sur la fourniture d'information; les frais de maintenance s’en trouvent d’autant réduits Les sites disposent d'un meilleur référencement par les moteurs de recherche Plusieurs études ont montré l’intérêt de l’accessibilité et les bénéfices d’un site accessible. Parmi elles : L’université de Dallas a dupliqué des sites Web en les modifiant suivant les critères d’accessibilité WAI-A. Ensuite, un groupe de 120 personnes (non-handicapées) de 18 à 74 ans a testé le site avant et après transformation. Résultat, les sites accessibles donnait 10% plus de personnes satisfaites et 10% d’intention en plus de retourner ultérieurement sur le site. Un mini-test a été réalisé avec des personnes handicapées qui indiquait un taux d’abandon de 60% sur le site accessible et un taux de 90% sur le site non-accessible ; L’étude The Web Access and Inclusion for Disabled people menée en 2004 sur 1000 sites britanniques a montré que le temps d’achat sur un site accessible est inférieur d’un tiers à un site non accessible ; La société anglaise Fiona Leslie Counseling a demandé de créer son site suivant les critères d’accessibilité WAI-AA. Sans autre action, ce site s’est trouvé dans le top10 des résultats des moteurs de recherche ; date

13 Cadre de référence international Un bref rappel historique au niveau du W3C
1994 : Création du W3C 1996 : Création de la WAI La Web Accessibility Initiative (WAI) du W3C définit plusieurs recommandations : WCAG, ATAG, UAAG et WAI-ARIA 1999 : Publication des recommandations WCAG 1.0 2008 : Publication des recommandations WCAG 2.0 Publications attendues : ATAG 2.0 et WAI/ARIA WAI : date

14 Cadre de référence international Recommandations et standards techniques
W3C/WAI Web Content Accessibility Guidelines (WCAG) 1.0 Définit 14 directives de principes pour rendre les pages Web accessibles 3 niveaux de conformité : Priorité 1 – A : Points de contrôle impératifs Priorité 2 – AA : Réduction des obstacles d’accès au site Priorité 3 – AAA : Amélioration du confort d’utilisation En Europe, UWEM (United Web Evaluation Methodology) fournit, sur la base des WCAG 1.0, une procédure d'évaluation Consiste en un système de principes et de pratiques pour l'évaluation de l'accessibilité du Web soit par un expert humain, soit de manière automatique par des interfaces de machines UWEN : Projet European Internet Accessibility Observatory (en abrégé EIAO) pour la création d'un observatoire européen de l'accessibilité du Web, Projet Supporting the creation of an eAccessibility Mark (en abrégé Support-EAM) abordé au chapitre précédent pour l’harmonisation de l’accessibilité du Web en Europe, Projet Benchmarking Tools for the Web (en abrégé BenToWeb) pour la création de modules de tests de l'accessibilité du Web. Projet EIAO : Projet Support-EAM : Projet BenToWeb :

15 Cadre de référence international Recommandations et standards techniques
WCAG 2.0 Recommandation en date du 11 décembre 2008 Traduction française agréée : La nouvelle référence pour le contenu accessible Les technologies autres que le HTML sont aussi traitées : ex. Silverlight 2/+ WAI :

16 Cadre de référence international Recommandations et standards techniques
WCAG 2.0 La version 2.0 des WCAG est structurée sur la base de critères de succès testables définis au niveau de 4 principes majeurs Perceptible, Utilisable, Compréhensible et Robuste et 12 règles générales (et 61 critères) Pour lesquels sont documentées des techniques suffisantes et/ou recommandées Trois niveaux de conformité A : niveau minimal AA (A+AA) : niveau normal AAA ( A + AA + AAA) : niveau amélioré (tout n’est pas faisable) WAI :

17 Cadre de référence international Recommandations et standards techniques
WCAG 2.0 Procédure Auto-déclaration Conformité partielle pour les langues et contenus externes Problématiques nouvelles Les documents en téléchargement doivent être accessibles (structure et alternatives) Cf. Séminaire Web et guide éponyme "Créer des documents accessibles avec Microsoft Office Word 2007" Les applications doivent être compatibles avec les aides techniques Cf. Séminaire Web et guide éponyme "Développer au quotidien des applications accessibles sous Windows" WAI :

18 Cadre de référence international Recommandations et standards techniques
UAAG (User Agent Accessibility Guidelines) Recommandations destinées aux Agents Utilisateurs (navigateurs Web, etc.) Importante pour une restitution accessible ATAG (Authoring Tool Accessibility Guidelines) Recommandations destinées aux outils d’éditions de contenus Web (CMS, éditeurs type Microsoft Expression Web Designer, etc.) Complexe mais indispensable pour qualifier les CMS Version 2, dans la lignée WCAG, en cours d’élaboration

19 Cadre de référence international Recommandations et standards techniques
ARIA (Accessible Rich Internet Applications) Initiative du W3C pour rendre des applications riches (JavaScript, AJAX, DHTML, etc.) compatible avec les Technologies d’Assistance Le chainon manquant entre le Web et les Technologies d’Assistance HTML 5 devrait incorporer ces fonctionnalités Axes d’amélioration d’ARIA Utilisation des technologies Web sémantiques Séparation du contenu et de la présentation Permettre la surveillance passive d’une application par les Technologies d’Assistance

20 Cadre législatif en France
L'accessibilité numérique constitue une obligation légale pour le secteur public 2004 : 1er référentiel d’application des WCAG : AccessiWeb (inclus dans le référentiel ADAE 2004 pour les sites du secteur public). 2005 : loi n° votée par le parlement français le 11 février 2005 – Article 47. 2007 : adoption par les Nations Unies de la Convention relative aux Droits des Personnes Handicapées le 13 décembre signée par 118 pays (par la France en mars 2007). 2009 : décret n° du 14 mai 2009 (pris en application de l'article 47). 2009 : publication du RGAA (évolution du 1er référentiel) le 23 octobre 2009 2009 : arrêté au Journal Officiel du 29 octobre 2009 qui rend le RGAA obligatoire à partir de cette date

21 Cadre législatif en France Décret du 16 mai 2009
Le décret d’application n° du 16 mai 2009 a rendu efficient l’article 47 de la loi n° du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, dont le 1er alinéa dispose. "Les services de communication publique en ligne des services de l'Etat, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées" Consulter le texte de loi sur le site de Legifrance Conformément à ces textes, l’arrêté du 21 octobre 2009 relatif au RGAA (référentiel général d'accessibilité pour les administrations) a été publié au Journal Officiel. Les administrations devront désormais se référer à ce document (version V2.2 en date du 23/10/09) pour attester de la conformité de leurs services en ligne aux recommandations internationales WCAG2.0 du W3C/WAI Loi n° du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées : JORF n°0113 du 16 mai 2009 page texte n° 32 Décret n° du 14 mai 2009 pris en application de l'article 47 de la loi n° du 11 février 2005 sur l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées et créant un référentiel d'accessibilité des services de communication publique en ligne : JORF n°0251 du 29 octobre 2009 page texte n° 31 Arrêté du 21 octobre 2009 relatif au référentiel général d'accessibilité pour les administrations : date

22 Cadre législatif en France Standards et recommandations
Les WCAG 2.0 sont la base technique de l'ensemble des standards et labels Le référentiel de la DGME, le RGAA (Référentiel Général d'Accessibilité pour les Administrations) est la base normative pour les sites publics Le référentiel AccessiWeb 2.0 propose une méthode d'application, sur la base des WCAG 2.0

23 Cadre législatif en France Procédure législative
Obligation pour les Services d'Etat, les Collectivités territoriales et les Services qui en dépendent Délai de mise en conformité pour L'Etat : 2 ans Les Collectivités : 3 ans Modalité Le RGAA est la référence pour vérifier la conformité du site au niveau d’accessibilité requis Auto-déclaration de conformité Sanctions en cas de non-conformité Si le site est contrôlé et reconnu non-conforme 6 mois après la déclaration de conformité, il s'ensuit : Une mise en demeure L'inscription sur une liste noire publique

24 Cadre législatif en France Procédure législative
En résumé Ministère en charge des personnes handicapées RGAA Contrôle Décret et Arrêté Mise aux normes Déclaration Conformité Mise en demeure Liste noire publique t0 2 à 3 ans 6 mois

25 Cadre législatif en France RGAA
Référentiel Général pour l'Accessibilité des Administrations (RGAA) Référence normative de la loi du 11 Février 2005 Méthode de déploiement de WCAG 2.0 Annexes normatives (champs d’application, déclaration de conformité, régime dérogatoire, etc.) Reprise de la structure WCAG, thématiques similaires à AccessiWeb 12 thématiques Images, Couleurs, Tableaux, Navigation, etc. 187 tests Niveau “déduit” A, AA et AAA Autocontrôle et auto déclaration (conformité) date

26 AccessiWeb Une méthode d’application des WCAG
Comme tout standard technique, les WCAG nécessitent des méthodes d’application adaptées aux activités qu’elles sont supposées encadrer Développement d’applications Web, développement de contenus, conception de l’interface, conception graphique, certification de conformité, etc. Quelques dates clé pour AccessiWeb 2003 : publication par l’association BrailleNet de la méthode AccessiWeb Permet une approche unifiée de la vérification de conformité aux WCAG 1.0 des sites Web Vise une approche opérationnelle sur la base de critères et d’objectifs thématiques Images, Cadres, Couleurs, Multimédia, Tableaux, Liens, Scripts, Eléments obligatoires, Structuration de l’information, Présentation de l’information, Formulaires, Navigation et Consultation

27 AccessiWeb Une méthode d’application des WCAG
Quelques dates clé pour AccessiWeb 2004 : adoption du référentiel AccessiWeb par l’administration française dans sa version 1.0 comme document de référence pour la mise en conformité des sites de communication en ligne avec les recommandations internationales Cette méthode a donc été largement diffusée et utilisée, en France comme dans le monde francophone Parallèlement à la publication de ce référentiel, l’association BrailleNet a développé un service de certification de site Web, le label AccessiWeb

28 AccessiWeb Les évolutions
Comme toute méthode, AccessiWeb et son référentiel doivent être mis à jour pour répondre aux retours d’expérience, ainsi qu’à l’évolution générale des technologies et des normes Dès 2004, BrailleNet a constitué un groupe de travail technique, le Groupe de Travail AccessiWeb (GTA) Pour assurer notamment la surveillance et l’évolution du référentiel AccessiWeb, sur la base de son utilisation concrète par des professionnels Le GTA, qui compte aujourd’hui près de 300 membres, a fait évoluer le référentiel AccessiWeb de la version 1.0 à la version 1.1, publiée en juin 2008

29 AccessiWeb 2.0 En décembre 2008, à la publication par le W3C de la version 2.0 des WCAG, en remplacement de la version 1.0, BrailleNet a tout d’abord mis en place un comité francophone pour la traduction des WCAG 2.0 auquel le GTA a largement contribué La traduction en français du document WCAG 2.0 a été la première traduction officiellement validée par W3C, en juin 2009 Puis, durant l’été 2009, en s’appuyant sur ce comité francophone, BrailleNet a constitué un groupe Expert Référent pour l’évolution du référentiel AccessiWeb de la version 1.1 à la version 2.0

30 AccessiWeb 2.0 Objectifs En réalisant ce nouveau référentiel, BrailleNet et son groupe Expert Référent visaient quatre objectifs majeurs : Objectif 1 : Permettre une compréhension opérationnelle des WCAG 2.0 Le référentiel AccessiWeb2.0 conserve les 13 thématiques générales d’AccessiWeb 1.1 qui permettent d’organiser la vérification de conformité selon des objectifs clairement compréhensibles et de fournir un cadre méthodologique opérationnel pour l’application des WCAG 2.0 Pour chacune de ces thématiques, le référentiel AccessiWeb 2.0 propose : Une liste de critères formulés sans référence aux technologies du Web de façon à être compris par des lecteurs ayant des profils professionnels variés. Ces critères sont cependant précis et détaillés Une liste de tests associés, se référant très précisément aux technologies du Web, telles que balises/attributs HTML, propriétés CSS, fonctions JavaScript, etc.

31 AccessiWeb 2.0 Objectifs Objectif 2 : Permettre de vérifier la conformité aux WCAG 2.0 Le référentiel AccessiWeb 2.0 établit une correspondance stricte entre les critères AccessiWeb et les règles et critères de succès des WCAG 2.0. Le référentiel AccessiWeb 2.0 reprend exactement les trois niveaux de conformité WCAG 2.0 : A ou AccessiWeb Bronze (le plus bas), AA ou AccessiWeb Argent et AAA ou AccessiWeb Or (le plus élevé) Le référentiel AccessiWeb 2.0 conduit à examiner à une série de questions univoques dont la réponse permet de conclure à la conformité ou non aux WCAG 2.0

32 AccessiWeb 2.0 Objectifs Objectif 3 : être cohérent avec le RGAA 2.2
La loi n° du 11 février 2005, son décret n° d'application et l’arrêté au journal officiel publié le 29 octobre 2009, obligent les administrations françaises à se référer au RGAA (version 2.2 en date du 23/10/09) pour attester de la conformité de leurs services en ligne aux WCAG 2.0, selon les niveaux A et AA Le référentiel AccessiWeb 2.0 vise la cohérence maximale avec le RGAA 2.2. Comme le RGAA 2.2, le référentiel AccessiWeb2.0 repose sur la traduction française des WCAG 2.0 réalisée par le comité francophone de traduction et agréée par le W3C le 25 juin 2009 Les thématiques AccessiWeb 2.0 sont similaires à celles de RGAA 2.2 qui s’en est inspiré Le référentiel AccessiWeb 2.0 propose une table de correspondance avec le RGAA 2.2 Le référentiel AccessiWeb 2.0 conduit à examiner à une série de questions univoques dont la réponse permet de conclure à la conformité ou non au RGAA 2.2

33 AccessiWeb 2.0 Objectifs Objectif 4 : Fournir une méthode pour la certification de conformité Le référentiel AccessiWeb 2.0 est formulé de façon à pouvoir être utilisé dans une procédure de certification de conformité d’un site ou télé-service Web aux WCAG 2.0 Le référentiel AccessiWeb 2.0 est formulé de façon à pouvoir être utilisé dans une procédure de certification de conformité d’un site ou télé-service Web au RGAA 2.2

34 AccessiWeb 2.0 Composition et mode de fonctionnement
Au même titre que la version 1.1, AccessiWeb 2.0 comprend : 13 thématiques Deux listes : liste générale (131 critères) liste déployée (300 tests) Un Glossaire Des cas particuliers Ceux-ci gèrent les cas habituels (Cf. AccessiWeb 1.1) et implémentent une partie des objectifs de la conformité partielle de WCAG 2.0

35 AccessiWeb 2.0 Composition et mode de fonctionnement
A la différence de la version 1.1, certains tests de la liste déployée d'AccessiWeb 2.0 sont rédigés sous forme de conditions. Il y a deux types de conditions : "Une de ces conditions" "Toutes ces conditions" C’est une application des techniques suffisantes de WCAG 2.0 qui valide plusieurs manières de satisfaire un critère

36 AccessiWeb 2.0 Composition et mode de fonctionnement
Prise de position : en tant que méthode d’application, le référentiel AccessiWeb 2.0 a dû faire un certain nombre de choix par rapport aux recommandations WCAG 2.0 : Quand un critère AccessiWeb regroupe des critères/techniques des WCAG de différents niveaux, c’est le niveau le plus bas qui est retenu afin de garantir une correspondance de niveau d’AccessiWeb 2.0 vers RGAA 2.2 Les cas sont peu nombreux

37 AccessiWeb 2.0 Composition et mode de fonctionnement
Les techniques T (structure d’un contenu textuel) n’ont pas été retenues, notamment pour la production d’alternatives au format TXT En effet, ces techniques reposent sur un usage et elles ne sont pas implémentées par les Technologies d’assistance AccessiWeb 2.0 n‘a pas implémenté ARIA WCAG 2.0 possède peu de techniques ARIA. Il faut attendre la publication officielle. Une fois parues, il nous faudra travailler en amont car leur compréhension/application nécessite un important travail de préparation Certaines techniques suffisantes ne sont pas implémentées Elles ont été considérées comme peu pertinentes ou bien elles sont déjà prises en charge d’une manière ou d’une autre

38 AccessiWeb En bref Une méthode d'application, déclinaison des règles WCAG en critères Objectifs principaux : Rendre opérationnel les WCAG en proposant une méthode pédagogique, proche de l’implémentation, facile à utiliser Mettre en place un cadre permettant la certification AccessiWeb 1.1 fondé sur les WCAG 1.0 : 95 critères, 243 tests AccessiWeb 2.0 fondé sur les WCAG 2.0 : 131 critères, 300 tests Publié le 17 décembre 2009 Label AccessiWeb Certification de 2 ans, visites régulières de contrôle 69 sites labellisés à ce jour

39 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 1 : Alternative d’images pour les WCAG 2.0 Règle WCAG 2.0 : 1.1 Proposer des équivalents textuels à tout contenu non textuel qui pourra alors être présenté sous d'autres formes selon les besoins de l'utilisateur : grands caractères, braille, synthèse vocale, symboles ou langage simplifié Critère WCAG 2.0 : 1.1.1 Contenu non textuel : tout contenu non-textuel présenté à l'utilisateur a un équivalent textuel qui remplit une fonction équivalente Techniques suffisantes : H35: Providing text alternatives on applet elements H36: Using alt attributes on images used as submit buttons H37: Using alt attributes on img elements H24: Providing text alternatives for the area elements of image maps F65: Failure of Success Criterion due to omitting the alt attribute on img elements, area elements, and input elements of type "image"

40 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 1 : Alternative d’images pour le RGAA 2.2 4.1.[Images] 1 : Présence de l'attribut alt Champ d'application : img, area, input type='image', applet, tout code JavaScript générant un des éléments précédents Procédure de test : Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est non applicable Si l'élément n'est pas un captcha ou ne fait pas parti d'un test qui deviendrait inutile si l'alternative textuelle était présente, poursuivre le test, sinon le test est non applicable Si l'élément possède un attribut alt, le test est validé, sinon le test invalidé

41 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 1 : Alternative d’images pour AccessiWeb 2.0 Thématique Images Critère 1.1 [Bronze] Chaque image a-t-elle une alternative textuelle ? Test : Chaque image (balise img) a-t-elle un attribut alt ? Test : Chaque zone (balise area) d'une image réactive a-t-elle un attribut alt ? Test : Chaque bouton de formulaire (balise input avec l'attribut type="image") a-t-il un attribut alt ? Test : Chaque image applet (balise applet) a-t-elle un attribut alt ?

42 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 2 : Sous-titrage média en direct pour les WCAG 2.0 Règle WCAG 2.0 : 1.1 Proposer des équivalents textuels à tout contenu non textuel qui pourra alors être présenté sous d'autres formes selon les besoins de l'utilisateur : grands caractères, braille, synthèse vocale, symboles ou langage simplifié Critères WCAG 2.0 : 1.2.4 Sous-titres (en direct) : fournir des sous-titres pour tout contenu audio en direct, sous forme de média synchronisé. (Niveau AA) 1.2.9 Seulement audio (en direct) : fournir une version de remplacement pour un média temporel, donnant une information équivalente pour un contenu seulement audio en direct. (Niveau AAA) Techniques suffisantes : G9: Creating captions for live synchronized media G151: Providing a link to a text transcript of a prepared statement or script if the script is followed G157: Incorporating a live audio captioning service into a Web page SM1: Adding extended audio description in SMIL 1.0 SM2: Adding extended audio description in SMIL 2.0

43 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 2 : Sous-titrage média en direct pour le RGAA 2.2 5.18.[Multimédia] 18 : Présence du sous-titrage synchronisé des médias synchronisés ou sonores diffusés en direct Champ d'application : Tout élément : a, applet, object, embed Procédure de test : Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est non applicable Si l'élément permet de télécharger ou de restituer un média synchronisé ou sonore qui apporte de l'information, poursuivre le test, sinon le test est non applicable Si ce média synchronisé ou sonore diffuse un contenu en direct, poursuivre le test, sinon le test est non applicable. Si le média synchronisé ou sonore nécessite l'utilisation de sous-titres synchronisés pour le rendre compréhensible, poursuivre le test, sinon le test est non applicable Si au moins une version du média synchronisé ou sonore mis à disposition utilise des sous-titres synchronisés ou qu'une transcription textuelle apportant la même information est mise à disposition lors de la diffusion en direct (exemple : un discours en direct pré-écrit), le test est validé, sinon le test est invalidé

44 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 2 : Alternative d’images pour AccessiWeb 2.0 Thématique Multimédia Critère 4.5 : [Argent] Chaque média temporel en direct a-t-il, si nécessaire, des sous-titres synchronisés ou une transcription textuelle (hors cas particuliers) ? Test : Chaque média temporel seulement audio en direct vérifie-t-il une de ces conditions (hors cas particuliers) ? Il existe des sous-titres synchronisés Il existe une version ayant des sous-titres synchronisés Il existe une transcription textuelle Test : Chaque média temporel synchronisé en direct vérifie-t-il une de ces conditions (hors cas particuliers) ?

45 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 3 : Validité du code pour les WCAG 2.0 Règle WCAG 2.0 : 4.1 Compatible : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance Critères WCAG 2.0 : 4.1.1 Analyse syntaxique : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués et chaque ID est unique. (Niveau A) 4.1.2 Nom, rôle et valeur : pour tout composant d'interface utilisateur (comprenant mais n'étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l'utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d'assistance. (Niveau A)

46 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 3 : Validité du code pour les WCAG 2.0 Techniques suffisantes : G134: Validating Web page G192: Fully conforming to specifications H74: Ensuring that opening and closing tags are used according to specification H75: Ensuring that Web pages are well-formed H88: Using HTML according to spec F70: Failure of Success Criterion due to incorrect use of start and end tags or attribute markup F77: Failure of Success Criterion due to duplicate values of type ID

47 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 3 : Validité du code pour le RGAA 2.2 9.4. [Standards] 4 : Validité du code HTML / XHTML au regard de la DTD déclarée Champ d'application : Toute page HTML ou XHTML Procédure de test : Si une déclaration d'utilisation d'une DTD est présente dans la page, poursuivre le test, sinon le test est non applicable Si la page est envoyée sous forme de text/html et qu'elle est invalide selon la DTD déclarée, poursuivre le test, sinon le test est non applicable Si les erreurs de validation ne concernent pas l'imbrication des balises dans l'arbre du document ou l'écriture des balises et des attributs, le test est validé, sinon le test est invalidé

48 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 3 : Validité du code pour le RGAA 2.2 9.5. [Standards] 5 : Absence de composants obsolètes par rapport à la version des spécifications W3C utilisée Champ d'application : Tout composant des spécifications du W3C Procédure de test : Si aucun des composants mentionnés dans le champ d'application n'est déclaré obsolète par rapport à la version des spécifications du W3C utilisée, le test est validé, sinon le test est invalidé

49 Comparatif entre WCAG 2.0, RGAA 2.2 et AccessiWeb 2.0
Exemple 3 : Validité du code pour AccessiWeb 2.0 Thématique Eléments obligatoires Critère 8.2 [Bronze] Pour chaque page Web, le code source est-il valide selon le type de document spécifié ? Test : Pour chaque déclaration de type de document, le code source de la page vérifie-il ces conditions ? Les balises respectent les règles d'écriture L'imbrication des balises est conforme L'ouverture et la fermeture des balises sont conformes Les attributs respectent les règles d'écriture Les valeurs des attributs respectent les règles d'écriture Test : Pour chaque déclaration de type de document, le code source de la page ne doit pas utilisé d'éléments dépréciés. Cette règle est-elle respectée ?

50 Implémenter l’Accessibilité dans vos solutions
Comment répondre à de légitimes interrogations comme Approches classiques vs. Méthodes agiles (XP, Scrum, etc.) Définition de ses objectifs et des critères de succès associés Sélection des acteurs Choix des technologies Choix des référentiels et des méthodes d'applications, comment les articuler ? Testabilité (tests unitaire, automatisation, etc.) Gestion/conduite du changement Etc.

51 Annonce Séminaire AccessiWeb "Conduire un projet e-Accessibilité"
Espace formations

52 Annonce Séminaire "Concevoir des sites accessibles avec SharePoint 2010 conformes aux standards et référentiels en vigueur"

53 Implémenter l’Accessibilité dans vos solutions
Séminaire gratuit "Concevoir des sites accessibles avec SharePoint 2010 conformes aux standards et référentiels en vigueur"  Organisé en partenariat avec l'Association BrailleNet 3 dates 29 mars 2010 15 avril 2010 3 juin 2010 Inscriptions

54 "L'accessibilité numérique des services publics en Europe"
Annonce 4ième Forum européen de l'accessibilité numérique organisé par l'Association BrailleNet "L'accessibilité numérique des services publics en Europe"

55 Pour aller plus loin sur les WCAG
W3C/WAI : W3C WCAG 2.0 : Comprendre les WCAG 2.0 Techniques pour les WCAG 2.0

56 Pour aller plus loin sur le RGGA
Site Web RGAA v2.2.1, Annexe 1 Critères, Annexe 2 Tests, Annexe 3 Grilles, Guide d'accompagnement

57 Pour aller plus loin sur AccessiWeb
Référentiel AccessiWeb 2.0 : Guide AccessiWeb 3.1 (en cours d'évolution) : Référentiel AccessiWeb CMS 1.0 : Espace Formations AccessiWeb : AccessiWeb Site AccessiWeb : Référentiel AccessiWeb : Guide AccessiWeb : Formations AccessiWeb : GTA : Label AccessiWeb : Galerie :

58 Plus d’informations Livre-blanc "L’accessibilité de quoi s’agit-il ?"
Site Microsoft France Accessibilité, technologies pour tous

59 Questions / Réponses SPEAKERS PLEASE NOTE: our standard timing for your availability for Q&A at the Ask- the-Experts pavilion will be the next lunch-break following your session, and variations from this standard will be scheduled based on your availability and for all Friday afternoon sessions.

60 Votre potentiel, notre passion TM
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.