Aujourd'hui, on a vu ce matin qu'il y avait des standards qu'il faut respecter. Ça reste l'objectif final de toute démarche d'accessibilité, mais la difficulté première c'est que la majorité des gens à l'heure actuelle ne sont pas formés et il y a un grand besoin de s'approprier ces standards et de les mettre en œuvre dans ces projets. Pour pouvoir monter en compétences, il y a 4 problématiques sur lesquelles je vais essayer de donner des réponses. La première difficulté que je rencontre en tant qu'expert accessibilité c'est qu'effectivement on va me demander de faire des audits, des évaluations et puis on va me demander de restituer des éléments par exemple sur lequel y a pas d'attribut alt sur les images qui sont vraiment des choses très basiques sur lesquelles moi en tant qu'expert, j'ai pas de valeur ajoutée, parce qu'il y a des outils automatiques qui peuvent le faire même à la limite mieux que moi. Donc ma problématique à moi en tant qu'expert, C'est faire quelque chose qui m'intéresse donc ce genre d'audit, je préfèrerais que ce soit des outils qui le fassent de l'autre coté, j'ai des intégrateurs web qui la plupart du temps viennent me voir et me disent : "Bonjour, est-ce qu'il y a des consignes de développement accessibles ?" alors effectivement on a SGQRI, en France on a RGAA. On a les WCAG. La problématique de ça c'est que les WCAG, SGQRI, le RGAA ce sont des documents qui sont destinés à des testeurs d'accessibilité. Ce ne sont pas des documents destinés à des intégrateurs, des développeurs. Ils ne sont pas rédigés avec le langage d'un développeur web. Donc quelles sont les consignes, lorsque je développe plutôt que les règles à vérifier une fois que j'ai développé, Pour être dès le départ dans le projet. 2ème difficulté, lorsque je mets en œuvre l'accessibilité j'ai besoin d'avoir des gens qui sont motivés, et pour les motiver, j'ai besoin d'avoir des éléments à leur communiquer pour leur dire où est ce que j'en suis vers où je vais et comment je me compare par rapport aux autres. Cela, c'est un élément très important parce que l'accessibilité au même titre que la qualité web c'est des choses que l'on ne va pas voir. On peut avoir une interface visuelle qui va être quasiment identique, mais en tant que décideur ou en tant que personne impliquée dans un projet, j'ai besoin d'avoir un outil pour pouvoir communiquer et montrer aux autres, la valeur ajoutée de ce que je fais. La troisième difficulté, c'est quelle est la priorité parce qu'effectivement on a dit le respect d'un standard il y a beaucoup de choses à faire quand on part de zéro ou quasiment. Comment je priorise ces éléments-là? Qu'est-ce que je mets, je traite d'abord et comment je peux répartir justement les choses à faire. Et puis enfin, comment je peux effectivement monter en compétences le plus rapidement possible en ayant le minimum de coûts parce qu'évidemment investir des centaines de milliers de dollars sur l'accessibilité ça peut être une solution mais il ne faut pas que la mise en œuvre de l'accessibilité se fasse au détriment de la production des contenus elle-même. En France on a effectivement le RGAA qui s'applique à toutes les villes. De plus en plus de villes proposent des vidéos, sur internet de leurs sessions municipales etc. pour voir ce qui se dit dans les réunions. Le sous-titrage normalement est obligatoire, Si la ville en question n'a pas la possibilité de sous-titrer parce que ça lui coûte trop cher, ça ne veut pas dire qu'il faut qu'elle enlève la vidéo du site internet. Parce que sinon si elle enlève la vidéo du site internet, ça veut dire qu'il y a une perte d'informations pour tout le monde. Donc il faut qu'il y ait cette possibilité de monter en compétences rapidement tout en diminuant les coûts. Donc une des solutions c'est ce qu'on va appeler l'amélioration continue ou l'accessibilité agile. Un premier point, ça va être de commencer par la base. Et la base ça va être quoi? On va voir ça va être tout ce qui est automatisable et détectable automatiquement. Le deuxième élément, ça va être la mise en place de ce qu'on appelle des indicateurs et d'un tableau de bord qui permet de communiquer autour d'une démarche pour pouvoir fédérer les équipes. Le troisième élément c'est comment on peut répartir et prioriser ces tâches de correction une fois qu'on a détecté des problèmes. Et ensuite le dernier point, comment on va pouvoir faire de l'évaluation formative c'est à dire se former en étant accompagné. Donc pour la partie effectivement 'Commencer petit pour devenir grand' la problématique que j'ai rencontrée, je vous l'ai dit tout à l'heure c'est les intégrateurs, ils veulent des consignes de développement. Ils veulent pas savoir 'Est-ce que je respecte la règle WCAG 10 42?' ce qui les intéresse c'est 'Qu'est-ce que je dois corriger ?' et 'Où est-ce que je dois le corriger ?'. Et ça, ils veulent le savoir très rapidement. Donc on a développé moi-même et puis un groupe de travail au cours de l'année dernière, deux listes d'instructions qu'on appelle WCAG First Steps ou Pas à Pas vers les WCAG 2. La première étape ça va être effectivement toutes les choses qui sont des erreurs, dont on sait à 100% que ce sont des erreurs, des choses à faire. La deuxième, ça va être les risques à anticiper ou les choses qui vont être semi-automatisables, c'est à dire qu'on va pouvoir détecter si un élément dans la page mais on va pas pouvoir dire s'il est bon ou s'il est pas bon mais on va pouvoir dire s'il est présent ou pas. Ce qui est important, c'est effectivement au niveau de la rédaction c'est comment vont être rédigés les intitulés. Donc je vais vous donner un petit exemple. Je suis parti des WCAG, donc en haut vous avez la règle WCAG, qui dit 'Tout contenu non-textuel présenté à l'utilisateur a-t-il un équivalent textuel qui remplit une fonction équivalente? Ben je ne sais pas si vous faites de la formation, mais moi si je vais voir un développeur web et que je lui dis ça, avec ça il est bien content mais il ne sait pas ce qu'il faut qu'il fasse. Donc concrètement comment on peut traduire ça par des règles simples dont on sait qu'il y a une obligation, c'est 'Utiliser un attribut alt pour l'élément img' Donc l'intégrateur je vais le voir et je vais lui dire 'tu utilises un attribut alt sur l'élément img' ça c'est ce que tu as à faire. Et quand il va développer, il pourra éventuellement le tester ou simplement connaître la règle et l'appliquer. Un deuxième exemple: 'Ne pas utiliser d'attribut alt vide si l'élément est le seul enfant d'un élément a ou bouton' Pourquoi? Parce que si j'ai un attribut alt vide dans un a ou dans un bouton ça génère un lien vide et donc il y a un problème d'accessibilité dans tous les cas de figure. Donc ça c'est pour les éléments qu'on peut comme ça détecter automatiquement et être sûr que c'est des choses à faire ou à ne pas faire. Deuxième exemple, toujours basé sur les WCAG : 'la fonction de chaque lien est-elle déterminée par le texte du lien seul ou par le texte du lien associé à un contexte du lien déterminé par un programme informatique sauf si la fonction du lien est ambiguë pour tout utilisateur ?' Pfiou, vous êtes encore avec moi ? Vous avez de la chance hein. Donc concrètement pour un dévelopeur web, je vais lui dire 'Utiliser avec précaution l'attribut target avec la valeur _blank pour l'élément a' ça veut dire quoi ? ça veut dire qu'il va vouloir ouvrir une nouvelle fenêtre, il va falloir qu'il fasse attention parce qu'il y aura des choses supplémentaires à faire s'il veut rendre cet élément-là accessible. Typiquement, il va devoir signaler l'ouverture de la nouvelle fenêtre donc pour le respect de SGQRI, par exemple, il devra mettre une icône dans le lien avec indication dans le alt pour dire nouvelle fenêtre. Donc ça c'est la notion de d'exemple, d'instruction, d'avertissement. Donc ça en utilisant ces deux listes-là, vous pouvez très rapidement avoir un premier niveau de ... une première évaluation de votre niveau d'accessibilité ça ne va pas vous garantir la conformité à un standard, simplement ce que ça va faire c'est que ça va préparer le terrain à simplement vraiement pouvoir commencer à travailler à l'accessibilité ça va faire que quand vous allez engager un expert accessibilité pour vous assister il va vraiment vous apporter de la plus-value, il ne va pas venir vous rapporter des choses qu'un outil automatique va pouvoir vous dire ou que vous en tant qu'intégrateur je dirais traditionnel, classique, avec un niveau de compétences moyen devrait faire quotidiennement dans son travail. Mettre un attribut alt sur une image, ce n'est pas faire de l'accessibilité c'est juste connaître son métier de développeur web. Maintenant, pour motiver tout cela, il faut effectivement mettre en place des outils de communication. La volonté c'est de rendre visible la démarche et les efforts, de susciter éventuellement de la concurrence, entre les équipes ou entres les responsables de projets, de fixer des objectifs restreints de manière continue. On va commencer petit et au fur et à mesure on va faire monter en compétences les gens et augmenter les exigences et puis on va avoir une démarche collégiale Ces évolutions et ces améliorations, elles vont être faites de manière commune, entre les développeurs et les responsables projets, et il va y avoir une animation de la démarche pour dire aujourd'hui on est à 90% conformes sur des critères de bases, demain vous serez à 100%. Quand vous serez à 100%, on rajoutera des critères donc vous redescendrez à 80% et au fur et à mesure on peut demander aux gens ce qu'ils veulent qu'on rajoute. Je vais vous montrer un exemple en pratique cela. Là c'est un exemple qui est basé sur les Ministères français et qui est sur la qualité web donc il est pas restreint à l'accessibilité mais l'idée c'est de pouvoir dire sur un parc de sites ici sur 18 sites. 'Quelle est la qualité globale de ces 18 sites et comment se classe chacun de ces sites et dans chacun de ces sites ?' 'Comment chaque site répond à différents critères ?' donc on arrive à avoir une note globale sur 10 pour l'ensemble des sites. On va avoir des indicateurs donc, par exemple, ici des indicateurs accessibilité, vitesse, référencement, usabilité. Sur une démarche vraiment que l'accessibilité SGQRI ça pourrait être éventuellement un indicateur intégrateur web, un indicateur rédacteur, un indicateur développeur, qui donnerait des indications par type de profil. On va avoir le nombre d'informations, un classement top 3 des sites avec pour chaque site la note et puis le score de chaque indicateur. Des conformités par niveaux, par type de sites, les critères les plus conformes. En fait, toutes ces données-là, elles sont extraites d'un outil et directement mises en ligne. Après cette interface, vous la partagez si vous le voulez avec le public pour attirer l'attention des ministères. On a en projet en travaillant avec Accessibiliteweb de faire la même chose pour SGQRI. De pouvoir montrer au gens 'Est-ce que je suis conforme SGQRI ?' et si ce n'est pas le cas, que les gens rentrent dans la démarche ou alors on peut l'utiliser en interne, simplement pour dire voilà j'ai 10, 20, 30 sites comment je fais pour voir où j'en suis. Tout cela, ce sont des données qui sont mises en avant par rapport au travail que vous faites dans vos évaluations ou dans vos mises en œuvre. En novembre, on va publier le 1er baromètre SGQRI qui sera basé sur les ministères et les organismes publics. La répartition et la priorisation des tâches, c'est une autre problématique. Vous avez fait une évaluation, l'évaluation en tant que telle, elle est intéressante. Le test en lui même est intéressant. Sauf que le test va vous rapporter des problèmes. Hors les problèmes ne correspondent pas à ce qu'il y a à faire concrètement. Typiquement on a détecté qu'une image n'avait pas d'attribut alt Pourquoi il n'y a pas d'attribut alt ? Peut-être que c'est parce que le développeur n'a pas produit la fonctionnalité dans le gabarit de la page ou parce que dans l'interface de saisie du gestionnaire de contenu il n'y a pas la possibilité pour le rédacteur de le saisir. Il peut y avoir plusieurs causes possibles à 1 problème qui est détecté on va devoir identifier plusieurs tâches. Sur chacune de ces tâches, on va pouvoir affecter des profils et les estimer en durée. Une fois que l'on aura estimé les durées et affecté les profils, on va pouvoir les prioriser en fonction de l'impact utilisateur. Ne pas avoir d'attribut alt sur une image, ça a une forte conséquence pour l'utilisateur. Ne pas avoir un intitulé de lien parfaitement pertinent dans un contexte donné, ça va avoir moins d'impact. Tout cela, ce sont des choses que l'on va pouvoir classer, une fois que l'on a fait cette liste des taches de manière collaborative, avec les gens qui détectent les problèmes et les équipes de développement. Pour vous aider à cela encore une fois, on peut avoir des outils. Je vais vous en montrer un exemple, et puis on a pour WCAG pour l'instant et on est en rain de travailler avec Accessibiliteweb pour faire la même chose sur SGQRI. On a un document qui émane de ce qui a été montré ce matin, le BOEW je vais vous le remontrer. Ça c'est la répartition qui a été faite dans la boite à outils de l'expérience web. Pour chaque critère WCAG, ils vont vous donner la répartition correspondante en fonction du profil, par exemple le critère 1.1.1. il concerne les rédacteurs, les développeurs, le contrôle qualité et le prototypage Typiquement, si je détecte ce problème là et que je génère un rapport d'audit je vais pouvoir l'envoyer uniquement à la personne qui est concernée par ce problème là et la personne qui n'est pas concernée n'aura pas la visibilité de ce point là puisqu'il ne la concerne pas. L'autre élément, c'est un exemple dans l'outil qu'on développe chez nous à Temesis On a une fonctionnalité de tâches ici ça correspond à un audit qui a été fait sur un site. Pour chacune des tâches correctives qui ont été créées, on a estimé une durée, on a fixé une priorité et on a mis des tags. Par exemple ici dans les tags, vous avez... Vous ne voyez pas car l'écran n'est pas très net, vous avez templates, contenu, développement, CMS, etc. Ce qui permet de classer ces tâches en fonction des mots-clés et donc d'avoir des priorités qui sont classées et donc estimable plus concrètement. Surtout cela permet de mutualiser. Typiquement si vous avez plusieurs sites, si vous vous rendez compte que vous avez des sous-titres qui ne sont pas présents sur l'ensemble des sites que vous gérez. Vous allez commander vos sous-titres pour l'ensemble de vos sites plutôt que de manière individuelle. Si vous devez développer un plugin pour un gestionnaire de contenu. En fait, vous vous rendez compte que vous n'avez pas 1 site qui a ce gestionnaire de contenu mais vous en avez 10. Le plugin que vous développez, vous le développez par pour 1 un site mais pour 6, 10, ou 20 sites et donc les coûts sont d'autant diminués. Pour terminer, la partie sur l'évaluation formative, ça, c'est un point qui est très important. Qu'est ce que je met là dedans ? Je mets la possibilité d'avoir pour les développeurs des outils très simples à utiliser qui leur donne très rapidement des informations sur où se situent les problèmes et sur qu'est ce qu'il faut faire pour les corriger ? Donc les intégrer le plus en amont possible dans l'ensemble de la chaîne de production. Fournir le matériel pédagogique au môment opportun et en quantité limité Je vais pas renvoyer la personne sur les techniques WCAG où il y a 500 techniques réparties, toutes au même niveau sans priorisation à l'intérieur. Je vais utiliser un langage qui est propre à la cible à qui je m'adresse. L'autre solution intéressant, c'est que plutôt de demander de faire des évalutions complètes à postériori. Vous avez un auditeur, un évaluateur qui va sur le site qui vous fait un rapport, qui vous transmet le rapport. C'est important d'avoir l'évaluateur proche du développeur. Si possible même d'avoir du travail en commun Quand le développeur va coder, vous avez l'évaluateur qui est à coté de lui et qui va le corriger au fur et à mesure De cette manière-là, il va y avoir une vraie montée en compétences, beaucoup plus rapide de l'intégrateur et du développeur que s'il avait reçu un rapport de 80, 40 ou 50 pages, qu'il fallait qu'il le lise et qu'il le comprenne. Qu'il corrige puis que l'évaluateur revienne qu'il se rend compte qu'il avait pas bien corrigé etc, etc, etc. Donc ça c'est ce qu'on appelle l'évaluation à 4 mains donc les mains du développeur et puis les mains de l'évaluateur. Et puis la mise à disposition des outils, je vais vous montrer cela rapidement C'était le premier site qui s'est ouvert quand j'ai ouvert le navigateur, donc c'est celui là que je vais montrer. Ici, donc pareil on a développé un plugin open-source pour Firefox, qui vous permet à l'heure actuelle de tester 450 tests dont une bonne partie qui concerne l'accessibilité les fameux 1er pas et 2ème pas. Donc sur ce site là, par exemple, j'ai simplement appuyé sur le bouton pour lancer l'analyse et donc il y a 1, 2, 3, 4, 5, 6 élements qui ne sont pas conformes. Je peux ici, avoir la liste des éléments en question et si nécessaire avoir avoir accès plus précisément à l'élément qui pose problème et avoir accès à son code HTML pour voir où se situe le souci. Donc, ce genre d'outil qui est très simple va vous permettre d'avoir la base. Corrigez la base et une fois que la base est corrigée, vous envoyez vos maquettes à une évaluation par un évaluateur qui va faire un audit complet de votre site et effectivement là, il vous remontera peut-être des éléments sur la pertinence du contenu ou comme a montré François sur la partie subjective mais toute la partie objective sera traitée en amont. Voilà merci.