Séminaire AccessiWeb : 8 décembre 2009

Accueil par Dominique Burger11ème séminaire AccessiWeb consacré à la nouvelle version d’AccessiWeb 2.0 : un certain ombre de critères, de pratiques, es formations, le label, les documents d’accompagnement. La publication l’an dernier en décembre des WCAG 2.0 ont un impact très fort sur tout cela. On en avait discuté au mois de juin il y a six mois. C’est ce que nous allons vous présenter aujourd’hui.

Programme très dense. Je veux reprendre les transparents présentés en juin et souligner ce qui a été fait de puis le mois de juin.

Les points saillants de la journée : la norme n’est pas la panacée, WCAG 2.0 est quelque chose d’important, mais ce ne sont pas les WCAG 2.0 seules qui permettront de tout résoudre. A l’époque on disait que WCAG 1.0 n’est pas mort, mais j’aurais presque tendance aujourd’hui à dire que WCAG 1.0 est presque mort, partout les gens ont commencé d’implémenter WCAG 2.0. WCAG 2.0 est plus de liberté pour implémenter des solutions. Liberté accrue d’implémenter des technologies : traitement de flash et PDF dans le contexte WCAG 2.0. WCAG 1.0 ne disait pas grand-chose là-dessus, WCAG 2.0 ouvre des portes. Les méthodes pour décider de la conformité, les référentiels. Quelque chose de nouveau avec WCAG 2.0 est le traitement des exceptions, ou dérogations, la conformité partielle. Les solutions pratiques sont élaborées collectivement ; Ce ne peut pas être BrailleNet qui trouve seul les solutions, ces solutions ne peuvent être élaborées que par une collectivité, c’est-à-dire vous. Cela doit être fait de manière harmonisée : internationale, francophone d’abord. On avait aussi conclu que l’utilisateur reprend une place plus importante dans le dispositif de l’accessibilité et de la vérification de conformité. A l’époque de WCAG 1.0 je me souviens de tous les débats sur Accessibilité, conformité et utilisabilité. Il me semble que WCAG 2.0 ouvre cette dimension et une place plus grande pour l’utilisabilité.

Il faut commencer par la dissémination des documents, des bonnes pratiques.

On arrive à ce qui a été fait depuis six mois : les WCAG 2.0 traduction française ont été publiées le 26 juin officiellement par le W3C. IL y a d’autres documents qui méritent d’être traduits, on avait mis des priorités vers des documents courts et non techniques, des documents plus techniques et plus longs étaient moins prioritaires. Depuis six mois le document très court "WCAG at a glance" a été traduit, publié sur le site du W3C, petit résumé WCAG en bref. Validé par le comité et sur le site du WE3C. C’est un document que vous pouvez utiliser dans votre communication auprès de vos

interlocuteurs pour populariser WCAG et faire passer l’idée qu’aujourd’hui c’est la référence normative pour l’accessibilité du Web.

On s’est attaqué à un chantier un peu plus lourd : c’est le document "Understanding WCAG 2.0". Comprendre les WCAG 2.0. Le même comité de traduction a été sollicité. IL est francophone. Il y a actuellement 32 organismes qui ont été volontaires pour participer à cette traduction. C’est Sylvie Duchateau de BrailleNet qui les coordonne. Le travail avance, c’est un gros travail, il est prévu que cette traduction soit publiée en janvier.

On avait annoncé en juin un forum européen colloque annuel BrailleNet sur l’accessibilité dans l’administration, et on avait annoncé des séminaires administration électronique entre maîtres d’ouvrages et prestataires. Choses en place. Le prochain forum aura lieu le 12 avril, ici même, sous le patronage de Valérie Pécresse ministre de l’enseignement et de la recherche. Conférence de Paul Tiemers, responsable du programme e-inclusion à la commission européenne. Le programme est en cours d’élaboration, il sera publié début janvier.

Pour les séminaires de l’administration électronique on a travaillé sur des contenus avec trois intervenants : Magali Oualid, Jean-Pierre Villain, et Olivier Nourry de Micropole Univers. L’idée est de faire interagir pendant une journée un MOA et un MOE et d’examiner tous les problèmes qui se posent quand on veut produire un projet e-accessibilité cela a eu lieu le 17 novembre, et comme les retours ont été excellents on va reconduire ce séminaire en 2010 sans doute plusieurs fois.

On avait parlé de relancer les trophées AccessiWeb autour du Web 2.0, mis en sommeil. Car idée lancée par DUI Proxima mobile un projet sur la thématique du handicap, sur la thématique seniors, il va y avoir pas mal de communication et les projets seront présentés le 12 avril au forum européen sur l’accessibilité numérique.

AccessiWeb devait reprendre le référentiel AccessiWeb et aller vers une version 2.0 comme méthode d’application des WCAG 2.0 en correspondance avec le RGAA qui a été publié à l’automne. Il faut que ce soit une méthode d’évaluation de la conformité qui permette aussi la labellisation. Ce sont des objectifs que l’on souhaitait maintenir avec AccessiWeb. On a pris l’option de maintenir les thématiques et de garder le principe de plusieurs listes une liste générale a valeur normative, une liste de tests unitaires (liste déployée) qui a valeur normative. Ces deux listes ont été établies, élaborées collectivement, soumises à commentaire et c’est ça qui va être présenté aujourd’hui. La troisième liste : la rédaction d’AccessiWeb 2.0 a commencé juste après le séminaire avec un petit noyau de rédacteurs et un groupe d’experts référents. Plusieurs d’entre vous ont participé, je veux profiter de l’occasion de vous remercier tous de ce travail collectif. La semaine prochaine la version définitive d’AccessiWeb 2.0 sera publiée. Ce que vous allez découvrir aujourd’hui c’est cette version présentée par les acteurs qui l’ont rédigée. La méthode de labellisation est en cours de refonte parce qu’il y a un certain nombre de choses qui doivent être revues. En particulier la question des conformités partielles qui sont autorisées par WCAG 2.0. Pour février tout cela devra être tranché. On prévoit entre le 15 décembre et fin janvier une traduction en anglais des deux listes, la liste générale et la liste déployée de façon à échanger plus facilement à ceux intéressés par es travaux et qui ne maîtrisent pas le français. Dans le courant 2010 - 1er trimestre la troisième liste entre WCA 2.0 et correspondance avec RGAA sera publiée et le guide AccessiWeb va être largement révisé pour correspondre à tout ça.

Le référentiel AccessiWeb 2.0 est le plat de résistance d’aujourd’hui mais il y a d’autres référentiels. On a évoqué un référentiel "documents électroniques" et un référentiel "sous-titrages vidéo". On a publié le référentiel AccessiWeb CMS 1.0 en octobre. Car il y a avait une demande de plus en plus grande autour des outils auteurs. On était conscients qu’on arrivait à une période transitoire car le référentiel s’appuie sur ATAG 1.0. Or le W3C travaille sur ATAG 2.0 qui doit être publiée en 2010. On a fait le choix de publier un CMS 1.0 pour se faire la main mais pour être prêts aussi à pouvoir publier en 2010 ou 2011 un référentiel CMS 2.0.

Concernant le référentiel "Documents électroniques", aujourd’hui documents bureautiques, ce sera discuté aujourd’hui. L’idée est de publier avec le référentiel AccessiWeb des critères qui s’appliquent aux documents bureautiques.

Il reste à faire tout l’outillage nécessaire, les méthodologies de test correspondant aux différentes techniques de production : Word, open office, in design, odt, PDFr, docx … Pour cela il faut le faire en mettant en place des partenariats. L’idée est de publier cela si possible pendant le premier semestre 2010.

Concernant l’autre référentiel sous titrage vidéo c’était une demande express de la DIPH (délégation interministérielle aux personnes handicaps) qui vouait ce référentiel, elle a disparu entre temps. Format ipub qui est aussi un format électronique pour les lires numériques. Si vous avez entendu parler du format xml Daisy xml dtbook, cet ipub est très proche de DAISY. Daisy est plus connu car porté par le consortium Daisy pour gérer des livres électroniques accessibles aux personnes handicapées. Le consortium Daisy a été désigné par le consortium IDPF (qui s’occupe des livres électroniques) comme agence de maintenance d’IPUB. Très bonne nouvelle pour l’accessibilité puisqu’un consortium qui s’occupe de formats pour les personnes handicapées est chargé de la maintenance d’un format destiné au grand public. Vidéo est donc pour l’instant un peu en sommeil puisqu’on n’a pas été relancé par la DIPH sur le sujet puisqu’elle a disparu entre temps.

On avait évoqué le fait qu’il serait nécessaire d’avoir un référentiel ARIA ça reste nécessaire mais ça reste un sujet ouvert et nécessaire et sans doute en 2010 il faudra lancer la réflexion et mettre en place le partenariat, le calendrier et la méthodologie.

Formations : on a dit il faudra évoluer pour prendre en compte WCAG 2, le RGAA, diversifier l’offre. Nous n’avions qu’une seule formation : formation expert en évaluation, mais demande de diversifier. L’autre demande est que la compétence d’expert en accessibilité soit certifier de manier plus forte. Un certain nombre de modules a été défini. Ceux qui sont en rouge sont opérationnels. "Comprendre l’accessibilité du Web" est une sensibilisation. "Conduire un projet accessible" est technique pour Webmestres, j’en ai parlé toute à l’heure. Elle a commencé de fonctionner. Formation vérifier l’accessibilité d’un site Web avec le RGAA : on a développé un partenariat avec Témésis pour développer cette formation, on reprend ensemble cette formation car il va y avoir une grosse demande autour du RGAA qui est publié officiellement. La formation AccessiWeb rendre un site accessible avec la méthode AccessiWeb 2.0. On reprend notre formation précédente et on l’adapte. La première devrait sortir en mars. Une formation sur laquelle on travaille actuellement avec Témésis, qui est une formation assez dense, expert AccessiWeb 2.0 en évaluation. L’idée est de former des experts en accessibilité capables de gérer un projet dans toutes ses dimensions. Faire émerger une expertise de haut niveau qui corresponde au niveau du GTA mais diffuser plus.

Estelle Renaud : question sur la formation vérifier l’accessibilité d’un site Web avec le RGAA. J’ai regardé sur le site est-ce que vous avez prévu d’en faire bénéficier les experts AccessiWeb sans repartir de zéro.

Dominique : il y a une grosse réflexion sur la modularité des formations pour que quelqu’un qui a suivi la formation 2 ait des unités de valeurs et ne soit pas obligé de faire tout le cycle s’il ne veut pas faire la formation 3.

Denis : pas encore formalisé mais vous avez accumulé un certain nombre de savoir mais vous pourrez accéder à une journée 3 ou 4, ceci est prévu.

Est-ce qu’il y a une fonction de péremption des formations, qu’est-ce qui se passe en 2015 ?

Dominique : il y a une demande que la compétence soit certifiée. Dans certification e compétences, il y a des piqûres de rappel. Si on n’a pas réactivé ses connaissances on n’est plus compétent. Si des gens ont été formés il y a dix ans que peuvent-ils dire de pertinent ? Cette certification de compétence n’est pas arrivée à maturité mais il y a déjà cette réflexion. ON a un mécanisme comme ça car quand on est passé à AccessiWeb 1.1 on vous a invités à des mises à jour sur ce qui avait changé entre 1.0 et 1.1. C’étaient des formations gratuites auxquelles étaient invités les experts. C’est l’intérêt du groupe d’experts d’avoir des sessions de mises à jour. Mais pas de réponses beaucoup plus précises. On a une notion de validation des acquis de l’expérience, avec l’université Pierre et Marie Curie, Gilles Chagnon, qui est là.

Programme de la journée :

A 10 heures 30, Denis Boulay et Jean-Pierre Villain vous présenteront le référentiel AccessiWeb 2.0, son organisme, ses principes, comment l’appliquer, versus WCAG 2.0 et versus RGAA 2.2.1. Cela nous prendra deux heures.

Pause déjeuner d’une heure.

A 13 heures 30 : introduction par Dominique.

Cet après-midi ateliers dirigés sur la mise en application de 4 critères significatifs d’AccessiWeb 2.0. Puis deux techniques particulières : traitées par WCAG 2.0 : technique flash et PDF. Ce sera présenté par Aurélien Lévy et Sébastien Delorme d’Atalan. Il y aura deux parties avec une pause goûter entre les deux. La première partie sera flash et la seconde partie sera PDF.

A 16 heures 50, discussion, débats. Fin à 17 heures 30 après conclusion de Dominique.

Magali Oualid Education nationale et recherche, Armony Altinier acs horizon, Christine leproux, arnaud malon, Yes convert, Joséphine , Sylvie, Laurent Ctotterau ratp, JP Villain, Mathieu Faure, Denis, Sébastien Delorme, Jacques qélios, Patrice Bourlon…

AccessiWeb 2.0 Le programme de la matinée : introduction sur le passage AccessiWeb 1.0 de 2003 à 1.1 de juin 2008 à AccessiWeb 2.0 qui sera officiellement publié le 15 décembre prochain.

Objectifs d’AccessiWeb 2.0, comment fonctionne AccessiWeb 2.0.

Opérationnel avec comparatif entre AW 2.0 WCAG 2.0 RGAA 2.0 sur la base d’un certain nombre de critères comment sont-ils structurés et comment arriver au même résultat.

Différences entre AW 1.1 et AW 2.0 Qu’est-ce qui est préservé, qu’est-ce qui est supprimé qu’est-ce qui est ajouté.

A quoi ressemble le référentiel, quel travail de maintenance. Remerciements d’usage.

IntroductionWAI crée des ressources sur l’accessibilité du Web en 1996 pour travailler sur les grands axes : UAAG, ATAG la technologie ARIA et les WCAG.

WCAG est la norme internationale pour l’accessibilité des contenus Web officiellement reconnu par la commission européenne qui recommande leur adoption par les états membres. WCAG 1.0 de 99 un ensemble de recommandations techniques, 14 grandes recommandations sur 5 critères. 3 niveau de conformité : A, AA AAA., Pas de certification mais base d’auto déclaration.

WCAG 2.0, décembre 2008 : 12 règles et 61 critères de succès. 4 principes majeurs : perceptible, compréhensible, utilisable robuste. 3 niveaux de conformité, A, AA et niveau amélioré de AAA. WCAG Stipule bien que tout n’est pas réalisable actuellement. Conformité partielle et contenu externe. Les documents en téléchargement doivent accessibles et les applications doivent être compatibles avec les technologies d’assistance.

Pour permettre la bonne application les WCAG on a besoin d’une méthode d’application adaptée aux activités qu’elles sont supposées encadrer. Dès 2003 AccessiWeb/BrailleNet a mis en place une méthode AccessiWeb, la marque AccessiWeb, cette méthode a permis une approche unifiée de la vérification de conformité de WCAG, sur la base de critères dans des thématiques ; Images, consultation en passant par scripts et liens…

En 2004, le référentiel AccessiWeb a été adopté par l’administration dans sa version 1.0. Méthode largement diffusée et utilisée en France et dans le monde francophone.

L’Association BrailleNet a développé un service de certification de sites Web, le label AccessiWeb.

Comme toute méthode AccessiWeb et ses référentiels a dû être mis à jour pour répondre au retour d’expérience. En 2004 mise en place du groupe de travail technique, GTA. Copte aujourd’hui plus de 300 membres évolutions vers la version 1.1, en juin 2008.

Les grandes étapes : la version 1.1 d’AccessiWeb était toujours en correspondance avec WCAG 1.0. Les WCAG 2.0 arrivent en décembre 2008, il faut se les approprier. IL a fallu un moment pour pouvoir appliquer WCAG 2.0 sur la base de la norme de manière la plus opérationnelle possible. Dès le printemps 2009 on prend la décision de versionner AccessiWeb pour passer de la 1.1 à la 2.0. On s’est donné un planning serré sur six mois de l’été 2009 jusqu’à la semaine prochaine. ON a rassemblé tous les matériels disponibles sur WCAG 2.0. SE référer au RGAA et sa méthodologie de tests, quelqu’un avait déjà réfléchi et sortir une méthode pour analyser WCAG 2.0, cela a servi à l’appropriation es WCAG 2.0. On définit les principaux objectifs opérationnels d’AccessiWeb. Sur le fond, la forme, la correspondance stricte et le planning.

A la rentrée réflexion sur la façon d’écrire le référentiel AccessiWeb, mise en place d’une chaîne d’écriture validation. Jean-Pierre Villain et Témésis (Laurent et Aurélien) ont participé à cette rédaction pour cadrer si on ne faisait pas de sorties de pistes ni de non sens.

On a mis en place un groupe d’experts francophones, experts référents au nombre de 25. Débats sur un forum entre les experts pour régler des situations bloquées dans un temps très réduit. Il était assez difficile de trancher car avis partagés mais cela a permis de faire avancer les choses. Cette première version a été validée par tous et soumise à un appel à commentaires unique du 9 au 26 novembre, limité dans le temps. Nous avons eu une 0aine de retours qui a permis de faire monter la qualité du référentiel.

En décembre, analyse et prise en compte des remarques et présentation aujourd’hui et la semaine prochaine parution officielle de ce nouveau référentiel.

Les objectifs4 objectifs majeurs :

Permettre une compréhension opérationnelle de WCAG 2.0 selon les thématiques AccessiWeb. Fournir méthode opérationnelle. Pour chaque thématique une liste de critères formulés sans référence technique.

Liste de tests associés à chacun de ces critères qui se réfèrent aux technologies Web.

Permettre de vérifier la conformité aux WCAG 2.0. Correspondance stricte entre les critères AccessiWeb et les échecs de WCAG 2.0. A est AccessiWeb bronze, AA argent et or le plus élevé. Un certain nombre de tests de WCAG 2.0 sont quasi impossibles à assurer. Cela fait partie de notre réflexion. Série de questions univoques dont la réponse permet de conclure la conformité à WCAG 2.0. Ne pas laisser de place à l’interprétation.

Etre cohérent avec le RGAA 2.2.1. Loi de 2005, décret d’application de mai, arrêté de publication de fin octobre, qui stipule que la version en ligne de RGAA est la version officielle que les services publics doivent appliquer. AW 2.0 maximise la cohérence avec RGAA 2.2.1. La présence de Témésis dans le groupe restreint a eu pour objectif de maintenir la cohérence avec RGAA. AccessiWeb 2.0 repose sur la traduction française des WCAG faite par le comité francophone. Thématiques similaires : 13 pour AW, 12 pour RGAA. IL y aura une table de correspondance avec RGAA 2.2. Questions univoques pour établir conformité au RGAA.

Fournir une méthode pour la certification de conformité : à WCAG et à RGAA 2.2.

L’objectif est aussi de conserver les règles d’écriture des critères de la version 1.1. Respecter l’indépendance des critères les uns par rapport aux autres. Respecter une forme affirmative, parfois impossible donc un certain nombre de formulations la plus française possible.

Fonctionnement129 critères de la liste générale. Une liste déployée de 287 tests. Un glossaire mis à jour. Les cas particuliers qui seront insérés dans le glossaire. C’était la grande nouveauté du passage de 1.0 à 1.1.

Il y a une nouveauté à la différence d’AW 1.1 : WCAG 2.0 va demander au niveau des techniques suffisantes pour valider un critère de succès si une de ces conditions est présente ou si toutes ces conditions sont valables. Repris ceci dans la rédaction des tests AW 2.0.

Jean-Pierre Villain (JP) : soit on faisait un critère par technique suffisante, soit on faisait le choix d’associer à chaque test un certain nombre de conditions.

WCAG 2.0 laisse ouvertes un certain nombre de portes et la méthode d’application doit trancher. Quand un critère AW regroupe un certain nombre de techniques WCAG de différents niveaux, c’est toujours le niveau le plus bas qui est pris. Le RGAA fonctionne de la même manière.

Un certain nombre de techniques n’a pas été retenu, notamment les techniques T pour le texte. Car ces techniques reposent sur un usage et ne sont pas implémentées par les technologies d’assistance.

JP : on a repris ces technologies Techniques pour les listes des documents téléchargeables.

AW 2.0 n’a pas pris en compte les technologies ARIA ou très peu. Car ARIA n’est pas officiel. Dès que officiel on mettra un groupe de travail en place quant à la diffusion la meilleure des technologies ARIA dans un référentiel ou un guide de bonnes pratiques.

Certaines techniques suffisantes ne sont pas implémentées : car peu pertinentes. La plupart d’entre elles sont référencées et prises en compte par d’autres critères.

JP : exemple pour implémenter les contrastes une technique dit qu’il ne faut pas utiliser CS. Nous a paru asse inutile.

Comparatif entre AccessiWeb 2.0 et RGAA 2.2.1Exemple 1 alternatives d’images : CS 1.1.1 sur les alternatives textuelles. 24 techniques différentes pour le critère 1.1. Pour les images 4 techniques H (html) et un échec. AccessiWeb 2.0 prend la structure classique d’AW 1.1. Un critère chaque image a-t-elle une alternative textuelle, 4 tests qui se réfèrent à chaque technique suffisante WCAG 2.0 html. Pour RGAA, champ d’application donne les objets, méthodologie de test et procédure de test. 3 principes différents et l’objectif était d’arriver au même résultat pour RGAA, AW et WCAG.

Exemple 2 : sous titrage pour médias en direct. Règle 1.1 : on travaille sur 2 critères différents. Niveaux différents : AA et AAA. Mélanger ces deux critères : 3 techniques Générales et 2 techniques SMIL. Pour AW, conditions de validation d’un test : on retrouve sous titres synchronisées et transcription textuelle. 3 conditions à valider pour valider ce test. Si l’une est bonne on valide le critère. Pour RGAA on va retrouver la même structure. Procédure en 5 étapes : conformité identique.

Exemple 3 : validité du code pour WCAG. Règle 4.1. 2 critères. Un sur l’analyse syntaxique et un sur le nom le rôle et la valeur qui réfère au nom rôle et valeur des composants d’interfaces. 2 techniques générales, 3 html et un échec. Un critère 8.2 sur AccessiWeb. Le test doit être validé si toutes les conditions sont réunies. Pour RGAA sur ce critère là, thématique Standard, procédure de test en 3 étapes. Réalise les mêmes tests qu’en AccessiWeb 2. Deux critères différents un sur la validité du code et un sur l’absence de composants obsolètes.

L’objectif était d’avoir une compatibilité dans les deux sens entre WCAG RGAA et AccessiWeb. Grâce au travail commun avec Laurent et Aurélien on a une correspondance quasi parfaite entre AccessiWeb et RGAA. Il nous reste 4 petits problèmes dont un seul est vraiment problématique qui sera sans doute corrigé dans une version future de RGAA.

L’autre objectif était de pouvoir assurer une continuité entre AW 1.1 et AW 2.0. Cela a nécessité un certain nombre d’abandons de critères AW 1.1.

Sur les images et de marinière générale, toutes les limites ont sauté. Sur les équivalents textuels on a conservé court et concis, la limite et reportée au glossaire. On a abandonné le critère qui demandait de contrôler l’ordre dans lequel s’affichaient les zones cliquables.

Prise en compte de description détaillées via un lien dans la page et prise en compte des mécanismes de remplacement pour les textes stylés en CSS. Choix de remplacer les textes en texte en dur soit par un mécanisme qui les remplace.

Pour les cadres il n’y a plus que 2 critères sur les titres. Plus d’alternative aux cadres WCAG 2.0 considère que les cadres sont des technologies compatibles avec l’accessibilité : plus d’alternatives et plus de barres de défilement.

Pour les couleurs, contrastes qui varient selon la taille des caractères sur la manière de mesurer 14 points sur du web.

Multimédia : thématique a été complètement refondue : entre multimédia et code exécutable a complètement disparu : on revient à une structure plus classique : contenus diffusés via la balise object sont dans multimédia : média temporel et média non temporel. Tout ce qui est script a été conservé dans Scripts. Prise en compte d’audio description synchronisée à la place de transcript.

Obligation du sous titrage en direct sur les vidéos et les sont dès l’argent, extraordinairement difficile à organiser choix de conserver conformité argent. Version en LSF au niveau or, audio description synchronisée étendue et transcription textuelle en niveau or dans tous les cas.

Autres critères : information synthétique sur les objets multimédia de la page. On peut enfin sanctionner le déclenchement de sons automatiques. Contrôle du niveau sonore des dialogues ; obligation de rendre le multimédia compatible avec les technologies d’assistance, dès le niveau bronze.

Tableaux : plus d’obligation de summary sur les tableaux de mise en forme. Suppression de l’attribut ABBR. Autorisation de l’utilisation simultanée de scope, ID et headers. La seule contrainte est sur le mécanisme ID et Headers qui doit servir à implémenter des en-têtes partiels.

Liens : liens en contexte qui apparaissent. Liens explicites hors contexte ont été remontés en niveau or et concernent les intitulés de liens seuls. Suppression de la limite de la longueur des intitulés. Prise en compte des informations de contexte, rapatriement d’un critère sur le doublement des liens pour les images map (côté serveur), création d’un critère spécifique pour les liens vides.

Scripts : complètement refondue : on a supprimé le critère sur le rôle et l’état remplacé par le critère sur la compatibilité avec les technologies d’assistance. Les changements de contexte, comportement des scripts, alertes non sollicitées.

Eléments obligatoires : complètement refondue : plus de test sur l’indication de jeu de caractères. Plus de test sur le titre de pages uniques. Reporté sur le critère de pertinence. Le critère sur le détournement de balise a été reformulé. Tous les critères or 8.11 à 8.13 ont été déplacés dans la thématique Consultation. On a rajouté une indication sur le sens de lecture, indiqué par l’attribut DIR.

Structuration : un certain nombre de critères passés en navigation : 9.1, 9.4 à 9.10. Créé un critère sur les abréviations : pas indiquer les abréviations sur chaque terme mais sur le premier terme. Création d’un critère sur les citations ;

Présentation information : énormément de critères WCAG 2.0 ajoutés. 3 critères sur les tailles de caractère, un sur le regroupement dans le contenu, un sur l’absence de barres de défilement horizontal sur les caractères agrandis. Un critère sur la prise de focus. Un critère sur les dispositifs de personnalisation (niveau or) pour les couleurs de police et les couleurs de fond par l’utilisateur. Sur la justification de texte, ou donner à l’utilisateur la possibilité de supprimer la justification de texte, et sur la largeur des blocs de texte et sur l’interlignage. Pour le niveau bronze : un critère sur les textes cachés sur la manière dont on va assurer que les textes cachés sont restitués par les technologies d’assistance, indication sur la forme et la position des éléments.

Formulaires : thématique a considérablement enflé. 11.9 a été supprimé car pris en charge différemment sur plusieurs critères de la même thématique. Title sur les champs à la place d’un label. Cohérence des étiquettes sur des champs répétés pour regarder si labels sont cohérents. Critères sur besoins des utilisateurs : correction à la saisie, contrôle de toutes les informations niveau et aides à la saisie. (Tous sont des besoins utilisateurs).

Navigation a été bouleversée : critère sur menu de navigation identique a disparu au profit d’un critère plus souple. Le critère sur les raccourcis clavier a disparu car plus obligatoire dans WCAG 2.0. Création de critères sur plan du site, moteur de recherche ; Critère spécifique sur la navigation dans une collection de pages. Système de navigation spécifique. Fil d’Ariane fait partie d’un critère de niveau or. Critère sur l’authentification de groupes de liens et de la zone de contenu. Identification de pages actives, ordre de tabulation, création d’un critère sur l’absence de pièges au clavier.

Consultation : modification de l’objet du critère sur l’alternative accessible aux documents en téléchargement : rendre accessibles les documents ou proposer une version accessible. Besoins utilisateurs ajoutés : ouverture de nouvelles fenêtres automatiques seront sanctionnées. L’utilisateur doit avoir le contrôle des limites de temps et des sessions authentifiées. Critère sur le jargon et les expressions inhabituelles. Alternatives aux syntaxes cryptiques : fait référence à la question posée sur les "smileys" : via l’attribut abbr ou version complète adjacente. Explicitation des mots ambiguë quand ils sont prononcés. Un critère sur la présence d’alternatives aux textes complexes avec référence à la fin du secondaire. Déclinaisons qui peuvent être intéressantes mais difficiles à mettre en place. Remonté au niveau or.

Exemples de mots ambigus : "les poules du couvent couvent". Un certain nombre de techniques utilisées à titre expérimental.

Présentation de la version en ligneRappel la thématique, le principe WCAG auquel elle est attaché, correspondance sur critères de succès, techniques suffisantes et tests RGAA. Si on valide un critère on valide un ou plusieurs tests RGAA.

Focus sur les documents en téléchargement, critère 13.7. 3 conditions dont une condition suffit. Doc en téléchargement est compatible avec l’accessibilité. La méthode choisie est de s’appuyer sur les techniques G (techniques générales) sur lesquelles énormément de techniques HTML sont dérivées pour sortir une liste de critères qui permettent de tester l’accessibilité aux documents bureautiques. Cela permet d’éviter de faire un référentiel sur docs Word, PDF, etc. et d’avoir une conformité WCAG 2.0 réelle.

Pris 5 techniques : G57, G94, G115 (éléments sémantiques pour utilisation de langages balisés), G141 organiser les pages en utilisant des titres), G184 qui demande de fournir indications textuelles sur champs obligatoires dans formulaire ou ensemble de formulaires. Cette approche permet d’établir un cadre de conformité. Conformité doit se rattacher u) une technique ou un critère WCAG. Souci avec indication de langue car pas de technique générale sur indications de langues. Indifférente aux formats de fichiers. Spécifier des méthodologies d’évaluation pour chaque type de fichier. Nécessite d’établir des méthodologies d’évaluation qui soient robustes. Evaluation et tests vont être difficiles pour PDF et certains autres types de formats.

Comment établir liste de formats et sur quelles bases : ooxml et odt sont compatibles avec l’accessibilité. Mais WS (works) et abs (abiword) ne sont pas compatibles avec l’accessibilité, il faudra les interdire. IL y a énormément de formats à prendre en compte. Quels outils prendre. Aujourd’hui la vérification de l’accessibilité d’un PDF est extrêmement coûteuse. Aujourd’hui on a le cadre des techniques générales qui cadrent les choses. Mais parfois techniques supplémentaires à intégrer pour certains formats : signets dans PDF, notes dans word. Pour l’instant ce sont les questions qui ressortent de cette expérience.

Pour la semaine prochaine, liste de critères pour documents bureautiques qui évoluera. Pour pouvoir la faire évoluer de manière souple, la décision été de a considérer comme étant un élément de glossaire, le glossaire n’étant pas normatif, on ne sera pas obligé de versionner.

Relecture du glossaire est prévue d’ici le 15. Correction de coquilles. Aspect tableau de correspondance entre 1AW 1.1 et 2.0 un entre AW 2.0 et WCAG et un entre AW 2.0 et RGAA. Réponse aux personnes qui ont répondu à l’appel à commentaires public. Mise en HTML sur le site accdssiweb.org de la liste générale, de la liste déployée et de tous es documents. Il y aura une liste téléchargeable.

En 2010 : on souhaite mettre en place un forum de discussion AccessiWeb 2.0 pour gérer dynamiquement un certain nombre de questions et réponses. Créer la méthodologie de tests AccessiWeb 2.0. Comment travailler son évaluation. Sur cette troisième idée sur une méthode de référence. Repartir des procédures de test dans WCAG 2.0 et les implémenter dans AccessiWeb 2.0. Même chose pour documents bureautiques.

Le gros chantier est la mise à jour du guide AccessiWeb. Document téléchargé de très nombreuses fois. A un certain nombre d’impasses et d’imprécisions. Repensons le guide AccessiWeb avec une

structure la plus stricte possible en termes d’écriture, on fera appel aux experts du groupe de travail. Chacun prenait en charge la rédaction d’une fiche du guide. A partir du moment où on aura défini ce que doit être une fiche on vous soumettra la consultation. Et cela, pas avant qu’on ait mis en place un premier cycle de mise à niveau de la 1.1 vers la 2.0. Dès qu’on aura commencé un premier cycle de formation AccessiWeb2.0 dès le mois de mars. Mise à jour de tous les documents à disposition avec les manuels d’évaluation, Web developer WAT, code source…

On arrive au terme d’une grosse étape : remercier tous ceux qui ont participé : un certain nombre d’entre vous, Jean-Pierre Villain, Laurent et Aurélien de Témésis, ceux qui se reconnaîtront qui ont fait partie du groupe d’experts référents AccessiWeb. Pas de vexation à ceux à qui je n’ai pas demandé j’ai fait de façon assez subjective d’un état de ceux qui participaient au groupe GTA. Merci à certain nombre de mes collègues AccessiWeb qui m’ont donné leur concours pour l’informatisation.

Patrice Bourlon : langage sur la notion de certification : vous parliez beaucoup de labellisation.

Denis : certification car on va se coller un maximum à normes.

Y a-t-il avancées par rapport à notions de certification dans le cadre normatif ?

Denis : travail fait en Europe dans Support EAM, conclusions tirées dans le cadre du CEN workshop (canal de plainte). Concernant la labellisation AccessiWeb 2.0, il est probable qu’au 15 janvier nous n‘ayons pas la réponse de proposer un service de certification mais informer sur le petit gel de la procédure de labellisation AccessiWeb 2.0. Réflexions entamées. IL faut prendre en compte ce que permet WCAG, pas de points bloquants par rapport à l’actuelle procédure.

Dominique : l’idée de ce travail est d’apporter aux gens les outils dont ils ont besoin pour répondre à des questions. Qu’est-ce qui me permet de certifier que je suis conforme. Ce terme de certification a une définition précise dans le cadre des normes, il fait un peu peur certaines fois, au travers de support EAM on a eu des débats sur les questions de certification. Si on a utilisé le mot label dans le cas AccessiWeb d’était d’éviter le terme certification, de fournir une méthode documentée précise pour dire que je suis conforme. Autorité qui dit que j’ai suivi quelque chose et que je suis conforme. Sur la terminologie si vous avez lu le RGAA il est question d’attestation de conformité. Ce sont des procédures assez lourdes.

Patrice : y a-t-il une notion de réciprocité, le RGAA ne prévoit pas d’associer une certification tierce partie, est-ce qu’il y a prévu une réciprocité dans le cadre d’Euracert par exemple, si j’ai un label AccessiWeb j’ai une reconnaissance tierce partie pur le RGAA. Ca se pose pour les clients.

Dominique : l’esprit dans lequel AW 2.0 a été travaillé a été de mettre une correspondance la meilleure possible entre les référentiels. RGAA est une norme française.

JP : comme RGAA est un processus auto déclarée pour le moment pas de réciprocité à mettre en place, pour le moment un site AccessiWeb 2.0 argent doit permettre d’établir une conformité RGAA. Pour l’instant 4 ou 5 soucis identifiés et un qui pose problème les 4 autres pouvant être géré, mais cela a été fait dans cet esprit là et doit être géré. Le but est qu’un contenu AccessiWeb 2.0 permette de valider un contenu WCAG. Un peu difficile pour raisons de structure mais l’objectif est là.

Matthieu Faure : durée de vie d’AW 1.1. ?

JP : état de retraite anticipée.

Matthieu : jusqu’à quand labellisation 1.1 ?

Denis : à partir du 15 décembre 3 mois. De paire avec réflexion quand va-t-on faire labellisation 2.0. Labels peuvent toujours être demandés sur label 1.1, jusqu’au 15 mars.

Victor Brito : est-ce qu’il est prévu qu’Euracert évolue pour tenir compte de l’évolution ?

Denis : nous avons rencontré nos homologues espagnols et belges. Est-ce qu’il y a Euracert 2.0 ou Uwem 2.0 ? Ce qui ressort est qu’on va tendre énormément vers WCAG 2.0. En cohérence avec les méthodes d’applications d’Euracert pour migrer sur WCAG 2.0 et comment s’accorder pour reconnaître que quand un espagnol donne un label Euracert WCAG 2.0 on puisse reconnaître.

Dominique : on s’est mis d’accord sur le principe : le premier principe est de travailler autour d’une méthodologie pivot, dans Euracert actuel c’était Uwem, développé dans le care européen. Dans le futur le pivot sera WCAG 2.0 beaucoup plus normé, l’abandon de UWEM et toujours ce système de correspondance entre des méthodologies qui vont émerger à différents endroits et des partenaires qui pourraient nous rejoindre à terme, avoir correspondance avec WCAG 2.0. Peut-être proposé solution Euracert 2.0 dans le premier semestre 2010 et peut-être inviter d’autres partenaires à rejoindre le schéma.

Estelle Renaud : tu disais qu’il y avait 4 petits problèmes pour équivalence AW 2.0 et RGAA, je n’ai pas noté quels étaient ces problèmes.

JP : le premier pose le plus de soucis : l’alternative aux médias non temporels : objet multimédia ; dans RGAA validation en cascade de plusieurs critères qui font qu’on doit mettre formellement quelque chose dans la balise object. AW ne nous oblige pas à le faire.

Le deuxième est sur les équivalents aux liens d’une image serveur : en AW on accepte des liens ou un formulaire de navigation quand on fait une image map serveur on peut avoir un formulaire de navigation en dessous, pour RGAA c’est spécifiquement des liens. Ce n’est pas un problème puisque dans les conditions de tests on peut utiliser les deux soit l’un soit l’autre, il faudra juste signaler que pour la conformité RGAA il faut des liens.

Troisième chose : souci de compréhension de l’interprétation RGAA des liens explicites en contexte : on peut avoir des liens explicites AccessiWeb qui n’arrivent pas à valider explicitement RGAA. Devrait arriver assez rarement.

Quatrième point : RGAA ne prend pas en compte un certain nombre de cas qui rend les critères non applicables : RGAA demande qu’un document soit compatible, mais ne prend pas en compte un copyright qui ne peut pas permettre de modifier l’information. Dans AW un as de conformité partielle qui n’est pas dans RGAA.

Pour le reste on a quelque chose de parfaitement cohérent et conforme. Sur ces quatre problèmes cités il y en a trois qui présentent une solution. Celui qui pose le plus de problèmes est l’object vide, en RGAA une balise object ne peut pas être vide.

Estelle Renaud : pourquoi ces choix ont-ils été faits dans AW 2.0 ?

JP : la première priorité est la compatibilité WCAG : si compatible avec RGAA mais crée contresens avec compatibilité WCAG cela n’est pas conforme. Dans la mesure où dans un processus de cette nature on a trois méthodes, celle qui établit la conformité est WCAG. Ce travail de rapprochement et de correspondance n’est pas terminé mais il est satisfaisant.

Victor Brito : le point problématique concernant le cas que tu viens de dire est-ce qu’une solution de compromis ne serait pas lorsqu’un site est conforme AW 2.0 si on veut le rendre conforme RGAA, faire comme Euracert avec labellisation de deux critères supplémentaires.

JP : cela sera fait. Conditions particulières pour avoir conformité RGAA, soit pour object vide on ne peut que constater et laisser l’auteur choisir ce qu’il eut mettre dedans.

Il y a en réalité 15 points de débats sur ces 15 on a trouvé 11 solutions et qu’il reste donc ces quatre points.

Matthieu Faure : de ton point de vue AccessiWeb 2.0 bronze est-il plus facile ou difficile que 1.1 et même chose pour argent ou or.

JP : le niveau A de WCAG 2.0 est extraordinairement plus difficile car WCAG 2.0 a rapatrié tous les critères de structure de AA. Implique un certain nombre de choses : très forte montée en compétence car on aborde quelque chose de nouveau, beaucoup plus difficile.

Matthieu : on n’est pas prêts d’avoir des sites Niveau or d’ici demain.

JP : labellisation bronze sera un joli challenge. Comment gérer des labellisations supérieures dès le niveau argent. La labellisation or sera quasiment impossible. Soit tu tombes sur le contenu qui va avec, soit tu restreins ton contenu. En revanche se pose le problème de la labellisation au niveau argent. WCAG 2.0 est beaucoup plus exigeant.

JP : WCAG indique clairement que l’on ne doit pas viser le niveau AAA car certains contenus sont impossibles à mettre en conformité. En WCAG 1.0, on avait l’habitude de dire que l’objectif était AA ; en WCAG 2.0 l’objectif est difficile d’où l’idée de relever le niveau minimum en fonction des usages. La théorie des p1 p2 p3 a complètement disparu en WCAG 2.0. Le double A se présente déjà comme de l’amélioration, et le triple A comme vous le pouvez.

Magali Oualid : en rapport avec la formation en collaboration avec Témésis : est-ce que ce sera sur la même formule que la formation BrailleNet avec un examen qui donne l’impression qu’on obtient une certification quelconque, ceci est très important pour l’administration pour donner une formation quelconque et dire qu’on a obtenu quelque chose.

Denis : pas vraiment d’examen, petits exercices sur les acquis. Pour l’instant pas d’examen final, un certificat de présence mais on ne donne pas une mention particulière sur une compétence propre au RGAA.

Dominique : peut-être une demande d’examen ?

Magali : on ne reconnaît pas forcément la compétence aux personnes formées donc il faudrait une certification pour dire que la personne est en capacité de faire conforme au RGAA. Il risque de manquer cet aspect là dans la formation RGAA.

Estelle : dans le privé cela reste vrai on nous envoie en formation on paie les formations et on attend qu’on revienne avec un certificat d’aptitude ce serait intéressant pour valider.

Patrice Bourlon : formé des personnes de l’éducation nationale. Il faudrait mettre en place un parcours, dispositif de formations certifiantes à mettre en place. Le parcours à évaluer pour vérifier le parcours et savoir si on est vraiment expert. Il y a un parcours à monter qui est important. Les gens avaient des profils complètement différents : des gens qui ne connaissaient pas les bases du HTML et des développeurs.

Clôture de la matinée

Exercice 1 : étudier le critère sur les liens en contexte

Site à étudier, page de téléchargement sur zdnet :

http://www.zdnet.fr/telecharger/windows/comunication-et-internet/

Si un lien est précédé d’un titre, le balisage permet lorsqu’ils sont lus ensemble d’expliciter le lien, le lien est considéré come explicite. Il fait toujours référence au contenu précédent. Jaws 10 propose via un raccourci de restituer le titre précédent. Cela présuppose que les couches logicielles de l’utilisateur sont à niveau.

Le critère 6.1 est non valide : le premier cas concerne les liens de navigation qui ne sont pas explicites. Ils sont explicités par la présence du titre « communication et internet ». Ces liens 1, 2, 3, peuvent être explicités par le titre précédent. Les chevrons ne sont pas explicites. WCAG 2.0 recommande un texte caché par CSS. WCAG 2.0 dit que le support de title étant peu robuste, il faut utiliser un texte caché par CSS pour expliciter le lien. AccessiWeb et RGAA le déconseillent fortement donc ils ont maintenu le title.

On retrouve ensuite les mêmes liens de navigation qui ne sont jamais explicites car le titre précédent est le titre du logiciel en téléchargement. S’il n’y a pas de titre précédent dans la page cette technique ne peut pas être utilisée.

Pour les liens de bas de page il faut utiliser du title. Le lien « donnez votre avis » invalide également le critère. Le titre précédent est communication et internet donc n’apporte rien, les blocs de téléchargement suivants, le titre du paragraphe est un logiciel à télécharger donc le lien n’a rien à voir. Le lien télécharger est explicité par le titre précédent qui est le nom du logiciel.

Question sur les liens ancrés : est-ce explicite ?

Réponse : les liens ancrés ne sont pas des liens.

Est-ce que il s’agit d’une configuration de Jaws pour situer le lien dans le contexte ou est-ce ne fonctionnalité ?

Réponse : on peut obtenir le contexte du lien dans le contexte via un raccourci.

Est-ce que la personne qui n’est pas contente du contexte va essayer avec le titre, puis avec le li ou le paragraphe ?

Réponse : c’est un peu ça.

Quand on aura des implémentations ARIA on pourra déterminer un contexte.

Exercice 2 :

www.cadeaumalin.fr

Exercice sur les formulaires : aller sur le formulaire de création de compte client.

Test de 3 critères : critère 11.1 : chaque champ de saisie de formulaire a-t-il une étiquette ?

11.5 : dans chaque formulaire les informations de même nature sont-elles regroupées si nécessaire ?

11.11 : Dans chaque formulaire le contrôle de saisie est-il accompagné si possible de suggestions facilitant la correction des erreurs de saisie ?

Date de naissance et civilité sont invalidées.

Un certain nombre de cas non valides pour la balise label où la date de naissance n’était pas correctement renseignée. Ils ont transformé un legend en label. Pour les civilités.

Critère 11.5 non valide : fieldset est reprise pour la stricte implémentation HTLM pour regrouper les informations de même nature : on demande par exemple un fieldset autour des trois champs de saisie de la date de naissance. En WCAG 2.0 quand il n’est pas souhaitable de mettre un label on peut mettre un title. Des title sur les input pour rentrer les jours, les mois, les années.

Pour le critère 11.11 il n’y a pas de contrôle de saisie donc le critère est non applicable.

Aurélien Lévy (Témésis) présente "Flash et accessibilité"Première question : pourquoi Flash ? Qui travaille dans une agence Web ? Qui utilise du flash ? Parce que c’est la mode, parce que le client l’a demandé, parce que l’on peut faire des choses en flash qui sont impossibles en HTML. Pour créer une vidéo. Flash est du flash, du flex, production côté serveur…

Qu’est-ce que dit Adobe ? Depuis flash player 6 les informations d’accessibilité sont renvoyées à la couche d’accessibilité, c’est-à-dire qu’une aide technique peut récupérer les informations. Avec Firefox il faudra attendre la version 9 du player, la version 6 pour IE. Il faudra faire attention au moment où vous exportez votre animation l’exporter pour le player 9.

Au niveau du logiciel flash mx est le premier qui propose des options d’accessibilité. On en est aujourd’hui à CS4.

Adobe fournit des scripts spécifiques pour Jaws qui vont servir quand vous développez des applications en flex, il y a un tas de composants de formulaires avancés et autres, atifs dans flex, pas compatibles avec Jaws. Adobe a développé des scripts complémentaires qui peuvent être installés par l’utilisateur.

Eléments supplémentaires : boutons de formulaire, éléments natifs, Macromedia publie une liste des composants accessibles ou pas. Du côté client : il va falloir Window-Eyes en version 4.2 (qui existe depuis mars 2002) qui est le premier à être capable de récupérer les informations dans les animations flash. Sur Jaws commence à être possible à partir de la version 4.5. Entre 4.5 et 6.1 il y avait un bug. A partir de la version 6.1 et plus capable de récupérer les informations. NVDA (lecteur d’écran open source pur Windows) la version 2009.1 est capable de récupérer ces informations. IL faudra Windows car sur mac pas possible de récupérer, sur linux pas possible non plus.

Internet explorer depuis la version 5, FF depuis la version 2, et le reste. Opera chrome, safari, linux macs, orca, voiceover ne permettent pas d’accéder à une information dans un flash même si cela a été fait de façon correcte.

Les spécifications WCAG disent de faire du flash accessible sous entendu qu’on a Windows, version de navigation supérieure à 6, lecteur d’écran compatible etc.

Des cas utiles : un intranet en flex, si vous savez que tous vos utilisateurs ont IE, Jaws 10, flash player et Windows on n’est pas obligé de leur proposer des alternatives.

WCAG et flash accessible : les critères de sous titrage, média temporels fournir du sous titrage. 1.2.2 et 1.2.4. L’audio description : 1.2.5, 1.2.7, 1.2.1. Rendre l’interface utilisable au clavier : 2.1.1, 2.1.2, 2.1.3, 2.4.3, 2.4.7. Le focus doit être visible. La navigation doit être dans un ordre logique. Compatibilité avec les technologies d’assistance : 4.1.2. Critère déjà présent dans WCAG 1, pas présent dans AccessiWeb 1. Niveau A qui demande qu’à partir du moment où on utilise une interface qui n’est pas une interface d’accessibilité la technologie soit compatible avec les apis d’accessibilité qui font l’interface entre le navigateur et les aides techniques. Flash va dire au navigateur des informations, le navigateur renvoie les informations à la couche d’accessibilité et Jaws ou autre les récupère dans la couche d’accessibilité.

On a les alternatives et les contrôles : mouvement, clignotement, flash, défilement, présentation. Les règles sur les interlignes, les espacements, les contrastes de couleurs s’appliquent aussi au flash. (Texte dans le flash). Les critères sur la navigation, la présence de menus doivent s’appliquer aux éléments flash.

Pour AccessiWeb : thématique multimédia, couleurs, présentation, consultation et navigation.

Dans multimédia : 4.1 (alternative texte et audio description), pertinence de l’audio description et transcription. Sous titres synchronisés, sous titres synchronisés ou transcription textuelle pour éléments en direct, audio description, interprétation en langue des signes, audio description étendue synchronisée, transcription textuelle obligatoire, alternative, contrôle du son, réglage du volume sonore, navigation au clavier ou à la souris (pour média temporel et non temporel), compatibilité avec les technologies d’assistance (nom rôle valeur paramétrage et changements d’état). Thématique couleurs : ne pas donner l’information uniquement par la couleur. Les contrastes d’au moins 4,5 sur 1. Prévoir dans le flash un outil pour modifier les contrastes. Pour la navigation : vérifier s’il y a plan du site, moteur de recherche menu de navigation. On oublie souvent d’appliquer ces critères dans un site full flash. Consultation et présentation : redirection, ouvertures de nouvelles fenêtres, limites de temps, informations relatives aux fichiers en téléchargement, niveaux de lecture, changements de luminosité. Surface d’affichage cumulée doit être inférieure à 21 000 pixels. Il y a

des outils qui permettent de le calculer (une université au canada). Contrôlable par l’utilisateur, arrêter, afficher, affichage inférieur à 5 secondes. Pour la partie présentation : les parties sur les feuilles de style ne s’appliquent pas. Lisibilité du texte quand la taille est à 200% au moins. Prise de focus visible sur chaque lien. Choix de la couleur de fond et police de texte contrôlable par l’utilisateur. Le texte ne doit pas être justifié. Blocs de texte pas plus de 80 caractères, lisible sans barre de défilement. Espace entre les lignes et les paragraphes. Textes cachés restitués par les technologies d’assistance, information pas uniquement donnée par la forme …

Comment tester :

Uniquement sur la plateforme Windows pour l’instant car sur les autres il y a un problème pour récupérer les informations.

4 outils : Adesigner 2, NVDA, lecteurs d’écran (jaws, window-eyes), MS inspect 32 (outil Microsoft). UI spy pour tester ui automation.

Deux cas pratiques avec des exemples :

www.groupama.com

Testé avec Adesigner : les informations affichées ne sont pas forcément restituées par le lecteur d’écran. Pour des raisons de versions.

Autre site :

http://www.fiphfp.fr/spip.php?rubrique38

Les informations sont restituées mais pas la structure.

Dans flash il y a des composants, flvplayback et flvcaptioning. Options pour aides techniques : une option « rendre l’animation accessible » cochée par défaut on peut le décocher si c’est de la décoration et qu’on ne veut pas qu’elle soit lue par le lecteur d’écran. Une option rendre accessible l’objet, on peut décocher la case pour éviter qu’elle soit restituée par le lecteur d’écran. Options nom et description : le champ no sera lu au lecteur d’écran. Description correspondrait à un title n’est pas restitué par un lecteur d’écran. La propriété wmode sur une balise object ne restituera pas l’animation au lecteur d’écran. Propriété volontairement destinée à masquer l’animation au lecteur d’écran. Pour masquer la pub par exemple. Update properties : pour mettre à jour les propriétés et dire au lecteur qu’une nouvelle page avec des nouvelles valeurs a été affichée. Les champs textes ne sont restitués que si on a sélectionné champ texte dynamique. En flash on peut détecter la présence d’une aide technique mais on ne peut pas détecter laquelle.

Définir l’ordre de tabulation (petite case ordre de tabulation) définir une touche de raccourci, activer ou non le fait qu’un élément et ses enfants sont tabulables. Il faut que tous les éléments aient un ordre de tabulation.

Flash permettra d’adapter la présentation : couleurs, traitement graphique sur les images, support partiel des CSS (libraire SCSS lib) pour faire du changement de feuille de style comme pour du html. Le mode d’insertion est la balise object. Déconseillé la méthode flash satay : conteneur swf qui allait

charger d’autres flash dynamiquement. Les informations d’accessibilité étaient perdues en cours de route. Embed ou object ne changera rien à l’accessibilité.

Sébastien Delorme (Atalan) présente "Accessibilité des PDF" Un projet global chez Atalan : projet Acède. Né à la demande de grandes entreprises françaises qui publient des informations en PDF s’interrogent sur la possibilité de prendre en compte des méthodes de conception de documents pour favoriser l’accessibilité dans les chaînes de production de PDF. Réflexion sur l’amélioration de l’accessibilité des documents.

La possibilité de rendre un PDF accessible est le balisage. Le gros problème est l’absence de documentation hormis celle proposée par Adobe sur le balisage de PDF. Peu savent comment ‘implémenter. Les personnes qui travaillent dans la PAO ignorent ce balisage. L’idée est de sensibiliser les professionnels, les gens qui créent des PDF de documents diffusés sur le format PDF.

Projet lancé il y a quelques mois trois principaux objectifs :

Créer et diffuser un certain nombre de notices méthodologiques : dédiés aux gens qui produisent des documents en format PDF. Baliser un document à la source pour personnes qui travaillent sur In design, liste de manipulations à effectuer pour rendre le PDF accessible sur In desgin, sous Acrobat. Guides méthodologies en français disponibles gratuitement.

Sensibiliser le public pour les possibilités d’amélioration de l’accessibilité. Diffusion de bonnes pratiques.

Pouvoir tester via les documents PDF (plaquettes commerciales, rapports annuels…) de les rendre accessibles. Travailler avec les agences de ces entreprises : agences externes, studios internes. Travailler à un premier niveau de professionnels capables de créer des PDF balisés et plus accessibles.

On sent la demande par rapport aux clients qui diffusent de l’information par rapport au PDF, sensibilisation de premières agences qui créent des documents PDF, agences PAO, retours assez intéressants puisqu’on commence à avoir des PDF balisés.

www.PDF-accessible.com (ressources techniques sur balisage de documents PDF).

Notices, guides méthodologiques vont être publiés pour le premier trimestre 2010.

JP a parlé du critère 13.7 du référentiel AccessiWeb 2.0. Version accessible de doc en téléchargement. Soit doc compatible avec l’accessibilité, soit téléchargement compatible, soit version html accessible.

Un fichier PDF plaquette balisée.PDF

Il faut l’ouvrir avec Acrobat pro. Regarder le PDF et tester les premiers critères que jp a montrés ce matin.

Aller dans affichage, panneaux de navigation, balises, une arborescence s’affiche. Elle correspond aux alises ajoutées sur le document. Dans l’icône options il y a une option « mettre le contenu en surbrillance » qui permet d’avoir un effet visuel à chaque fois qu’on parcourt l’arbre des balises pour

pouvoir voir le contenu que l’on survole. Dans un document balisé, tous les éléments qui ne sont pas balisés ne sont pas restitués au lecteur d’écran.

Dans affichage, panneau de navigation, il y a un menu « ordre ». Dans ce panneau, page par page il y a la liste des éléments qui ont été balisés avec un numéro qui correspond à l’ordre dans lequel ils sont affichés quand on utilise un lecteur d’écran. Dans le panneau balises, il y a un certain nombre de propriétés que l’on peut attribuer aux balises, en sélectionnant puis clic droit et options, il y a un champ de propriétés qui va afficher toutes les propriétés de la balise : il y a une balise texte de remplacement et une balise langue qui permet de spécifier la langue du contenu de la balise.

Dans Acrobat 4 critères bureautique :

1. L’ordre de restitution des contenus est-il cohérent ?

2. Chaque image porteuse d’information a-t-elle une alternative ?

3. Chaque liste est-elle correctement implémentée ?

4. Utilisation appropriée de titres ?

Le moyen de vérifier l’ordre de restitution des éléments est de vérifier l’ordre cohérent avec les numéros, ou avec Jaws. L’ordre est cohérent.

Images porteuse d’information : une image balisée. Pour trouver les images balisées il faut tout déplier. Ou il faut tester avec Jaws avec la liste des figures. Pour e PDF on peut mettre du texte de remplacement sur n’importe quelle balise.

Structure des titres : organisation de l’information n’est pas claire. Certains titres en orange sont en H23 d’autres ne le sont pas. Sur la première page il y a une balise H sans indication de niveau. Dans la doc Adobe le premier du document est la balise H. Elle est prévue dans les tags d’Adobe pour donner le titre du document.

Joséphine : discuter la façon dont sont restitués les espaces. Chaque titre utilise un format textuel conventionnel. Techniques T des WCAG.

Question sur la linéarisation du document PDF : qu’est-ce qu’on peut vraiment vérifie sur la linéarisation du document PDF ?

Réponse : si on va dans « affichage », « zoom » « redistribuer », il va casser la structure du document et le présenter ligne par ligne. Quand on grossit, pas de scroll bar qui apparaît. On peut s’en servir pour vérifier l’ordre de lecture.

Dans spécialisés cap emploi il manque un espace entre les deux mots.

Le tableau de données page 4 : dans options avancées, accessibilité, retouche de l’ordre de lecture tous les tableaux balisés sont encadrés ave une croix, on sélectionne le tableau en cliquant sur le chiffre correspondant. ON a une option éditeur de tableau, possibilité de gérer les propriétés de chaque cellule, de définir les en-têtes, donner des identifiants aux en-têtes, dans chaque cellule relier aux identifiants.

Pour l’évaluation de documents deux problèmes :

Des critères qui dépendent du lecteur et du visualisateur.

Dans les critères WCAG, on demande s’il y a la possibilité de changer les critères de premier plan et d’arrière plan, possible dans Adobe Reader. La question est donc de savoir quel lecteur on va évaluer pour ce genre de critère.

L’ordre problème est par exemple le changement de langue : quelle balise ? Critère langue d’un passage. Une seule technique WCAG qui est une technique HTML. H58. Il faut donc s’appuyer sur une technique générale.

Dominique : faudrait-il créer es techniques ?

Réponse : dans WCAG 2 on ne peut pas créer de techniques PDF.

Plus on aura de format pris en charge, plus il y aura de cas come celui-là.

Dominique : est-ce que tu as testé les fonctions d’export Daisy fournies par Adobe sur In design ?

Réponse : testé les fonctions d’export HTML d’Acrobat pro, catastrophique.

JP : les exports Daisy sur In design sont impeccables. Au moins aussi bons que ceux de Word.

Sébastien : les exports in design sont plus propres.

Dominique : question stratégique : est-ce qu’il faut à tout prix rendre du PDF accessible, ou faut-il une chaîne de production permettant d’exporter un document dans la chaîne de production.

Sylvie : agence de comme qui font de la PAO pour permettre d’exporter depuis In design.

Sébastien : intégration in design, se fait assez facilement. En un quart d’heure balisage de 40 pages. L’intérêt est de pouvoir générer un PDF balisé ou une version HTML plus pertinente pour les utilisateurs ou un format Daisy.

JP : l’intérêt du format Daisy est de générer un format de sortie accessible. Plus facile de régénérer du PDF accessible à partir d’un format Daisy qu’à parti des exports qu’on peut sur les outils spécialisés.

Cécile : le balisage a-t-il été fait après coup ?

Réponse : après coup : pour effets de démonstrations. Temps : une demi-heure pour les quatre pages.

JP : Utilisation de PDF pour format d’édition n’est pas très intéressant. Il faut mieux travailler sur les formats d’édition et transformer plutôt que de travailler directement sur le format PDF.

Est-ce que le balisage est lisible et utilisable par les moteurs de recherche.

Réponse : pas utilisés.

Matthieu : il faudrait poser la question à Google.

JP : sémantique de PDF extrêmement pauvre.

Victor : Aurélien a indiqué que les lecteurs d’écran restituent sans structure mis à part graphiques et boutons. Est-il possible de structurer sémantiquement un contenu flash : listes comme en html.

Aurélien : via les scripts Jaws pour flex, possibilité d’illustrer certains composants, simuler certains comportements. En train de réfléchir à la balise cannevas qui est du javascript, pouvoir gérer un dom virtuel par-dessus le cannevas pour naviguer dans l’arbre du document généré à côté du fichier.

Conclusion par Dominique BurgerRemercier tout le monde. De plus en plus évident que l’accessibilité n’est pas que le web c’est pourquoi on parle d’accessibilité numérique en général. On l’a vu pour les documents bureautiques qu’on considérait comme quelque chose à part. Bientôt on parlera de l’accessibilité des applicatifs. On arrive à des convergences : jusqu’ici on pouvait dire qu’il y avait les WCAG pour le web et les ATAG et les UAAG et de l’autre côté Daisy pour les gens qui faisaient des livres électroniques. Tout cela est en train de fusionner, émerge avec la problématique de l’industrie en général, il est question que le format ipub puisse être acheté comme du PDF. Ce format va sans doute fusionner avec le format DAISY. Bonne nouvelle pour l’accessibilité.

Pour accompagner tout cela, besoin d’instruments : référentiels, méthodologiques, outils de développement et d’évaluation.

Pour ce qui nous concerne un certain nombre de chantiers en cours : en particulier le chantier AccessiWeb, le chantier ATAG qui va reprendre, le chantier ARIA. Vous serez mobilisés. En 2010 l’état de réflexion de BrailleNet est qu’on atteint une masse critique avec le groupe AccessiWeb, vous êtes nombreux on a des activités autour d’AccessiWeb, autour d’un serveur de livres numériques Daisy et la bibliothèque Hélène, le colloque et de rassembler tout ça autour d’un site Web unifié et fédérer plus largement un grand nombre d’acteurs qui sont invités à participer dans le cadre de partenariats qui pourraient être ponctuels, dans le développement d’un référentiel, de séminaires de partenariats à plus long terme come ceux que l’on monte sur les formations. On travaille sur la refonte du site Web avec une nouvelle identité, des possibilités plus larges, ouvrir des forums AccessiWeb 2.0. L’idée est d’appeler ce site Web institut de l’accessibilité numérique et de l’ouvrir au moment du colloque le 12 avril. Objectif ambitieux mais on est déjà sur les starting blocks et vous serez les premiers informés de cela. L’objectif étant de faire progresser les bonnes connaissances et les bonnes pratiques.

Prochains rendez-vous : certainement un séminaire dans le printemps 2010. Le forum européen de l’accessibilité numérique du 12 avril et la participation aux différents chantiers mentionnés.

Remercier la cité des sciences qui nous accueille ici qui offre d’excellentes conditions de travail, Stéphanie et l’équipe technique.