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.