Réinventons les audits d’accessibilité web, transcription textuelle de ma conférence à Paris Web 2019

En octobre 2019, lors de l’évènement Paris Web, j’ai donné une conférence sur la façon dont on pourrait réinventer les audits d’accessibilité web afin qu’ils se passent mieux à la fois pour les auditeurs et auditrices, mais également pour les équipes projet.

Vous retrouverez :

• La vidéo de la conférence sur le site de Paris Web ;
• Le diaporama de ma conférence ;
• Et, ci-dessous, la transcription textuelle de cette conférence.

Introduction et présentation

Bonjour, je vais vous présenter la conférence « Réinventons les audits d’accessibilité web ». Pour me présenter, je suis intégratrice web et consultante en accessibilité web chez Tanaguru.

Chez Tanaguru, je livre aujourd’hui les audits d’accessibilité à nos clients mais, avant ça, j’ai eu une expérience professionnelle où j’étais plutôt dans la situation où je recevais les audits de la part des agences. Je pense que c’est aussi un petit peu ce qui m’a aidée à prendre du recul sur nos pratiques. Je vais vous proposer qu’on en discute dans cette conférence.

C’est quoi le problème avec les audits d’accessibilité web ?

Je ne cherche pas la bagarre. Je pense qu’il y a des personnes qui ne seront pas forcément d’accord mais je pense qu’on a quand même besoin de se remettre en question donc, on va essayer de faire ça.

Les clients et clientes demandent, les experts et expertes exécutent

Déjà, le constat qu’on a pu faire, c’est que les clients et clientes nous demandent des audits et, nous, en tant qu’experts, expertes, on exécute.

Au départ, il y a la loi qui dit que les sites doivent être accessibles aux personnes handicapées. Du coup, les clients et clientes nous demandent des audits de conformité qui permettent d’évaluer le niveau d’accessibilité du site, avec des préconisations de correction, évidemment, pour corriger.

Et nous, les experts et expertes, on livre les audits de conformité ; c’est comme ça qu’on a appris donc c’est ce qu’on fait.

Rappel des actions demandées par la loi (article 47, loi n^o2005-102)

Je vais faire un petit rappel rapidement sur les actions demandées par la loi. Je ne vais pas rebalayer toute la loi mais il s’agit de l’article 47 de la loi n^o2005-102. Si vous n’êtes pas au courant, vous irez vous renseigner plus en détail par la suite.

Cette loi nous demande plusieurs publications sur un site web :

• La mention du niveau d’accessibilité sur la page d’accueil : on va dire sur la page d’accueil si le site est totalement conforme, partiellement conforme ou non conforme.
• On doit aussi publier une déclaration d’accessibilité ; c’est-à-dire le résultat de l’évaluation d’accessibilité du site. On va publier l’état de conformité, la liste des contenus non accessibles, un moyen de contact, etc.
• On doit publier un schéma pluriannuel de mise en accessibilité.
• Et, avec ça, un plan d’actions pour l’année en cours.

Des audits de conformité, conformément à ce qui est attendu dans le RGAA

Pour faire la déclaration d’accessibilité et savoir si le site est totalement, partiellement ou non conforme, on doit réaliser des audits de conformité.

On travaille avec le RGAA, le Référentiel Général d’Amélioration de l’Accessibilité qui s’appuie sur les WCAG 2.1 (Web Content Accessibility Guidelines), les règles d’accessibilité pour les contenus web. C’est la norme internationale. Le RGAA est construit par rapport à cette norme. Il vient de sortir sa version 4 il n’y a pas très longtemps mais il fonctionne toujours sur le même principe :

• Il a un certain nombre de thématiques (13) ;
• Dans chaque thématique, il y a un certain nombre de critères (106, en tout) ;
• Et dans chaque critère, il y a un certain nombre de tests (257, en tout). Ce qui fait un certain nombre de choses à tester.

Pour évaluer un critère, on doit tester tous les tests associés à ce critère. Pour ça, on a quatre statuts :

• Conforme ;
• Non conforme ;
• Non applicable : si le contenu n’est pas concerné par le test ou le critère ;
• Non testé : celui-ci sert juste pour nous, quand on fait des audits, pour faire le suivi de l’audit.

Pour dire qu’un critère est non conforme, il faut au moins qu’un des tests soit non conforme.

Pour dire qu’un critère (j’ai dit « test » par erreur dans la conférence) est conforme, soit on a des tests non applicables et au moins un test conforme, soit tous les tests sont conformes.

Ce qu’on livre si on suit le guide de réalisation d’audits RGAA

Si on suit le RGAA, on doit livrer un certain nombre de documents :

• On va livrer une grille d’audit, parce que pour faire ce travail de conformité des tests et des critères, ça se fait à travers une grille. Généralement, c’est un tableur Excel ou LibreOffice, par exemple. On relève les problèmes mais on ne fait pas de préconisations dans la grille.
• On livre aussi un rapport d’audit qui reprend le contenu de la grille et qui va donner un seul exemple de non-conformité pour un critère. S’il y a plusieurs non-conformités, débrouillez-vous. On livre les préconisations pour corriger cet exemple-là.
• [Voici venu le moment où il faut impérativement que je me mouche pour poursuivre la conférence. Instant gênant pour moi où je demande donc si on peut couper le micro ; ce qui a bien fait rire toute la salle.]
  On livre, avec la grille et le rapport, un support de présentation non technique pour la réunion de restitution de l’audit puisque les commanditaires de l’audit n’y connaissent parfois rien en technique. Pour que tout le monde puisse comprendre le résultat de l’audit, il faut qu’on l’adapte.

Ce qu’on a fini par livrer : une grille d’audit exhaustive

Ce qu’on a fini par livrer, en tout cas chez Tanaguru, c’est une grille d’audit exhaustive. Pour éviter de faire la grille et, en plus, le rapport d’audit (parce que, ça faisait un peu le double de travail), on a fini par mettre les préconisations directement dans le tableur. Et surtout, on relevait tous les problèmes qu’on trouvait, pas juste un exemple. Puisque, sinon, les équipes ne peuvent pas mettre leur site en conformité. Bien sûr, avec ça, on livrait un support de présentation non technique.

Le problème, c’est qu’on se retrouvait avec des tartines de texte dans les cases du tableur avec tous ces problèmes et toutes ces préconisations.

Description détaillée de l’image

Exemple de grille d’audit Excel où l’on voit les différents onglets du fichier : Transverse, Page1, Synthèse, Synthèse graphique, Récapitulatif invalide, Licences – Crédits, Aide.

On est sur l’onglet « Page1 » et on voit le tableau d’audit avec chaque test associé à son critère.

Certains tests sont invalidés, validés ou non applicables. Il y a des tartines de texte dans les cases de relevé des anomalies.

Problèmes et remise en question

On va voir un petit peu les problèmes que tout ça pose et essayer de se remettre en question.

• Déjà, combien y a-t-il de clients et clientes qui savent vraiment ce qu’est l’accessibilité ?
• Combien y en a-t-il qui savent ce qu’implique un audit de conformité avant qu’on leur en livre un ? Parce qu’il y en a qui ne s’attendent pas forcément à recevoir la grille d’audit qui n’est pas forcément très claire ou le rapport d’audit qui ne comprend pas tous les problèmes.
• Et combien, aussi, sont formé·es à l’accessibilité numérique ?
• Et nous, comment fait-on pour bien accompagner les équipes si les audits et les rapports ne sont pas complets ? Ou si on utilise des outils qui sont inadaptés à leurs processus ?

On peut se demander pourquoi on ne les a pas mieux conseillés en amont nos clients et clientes ? Est-ce qu’on n’aurait pas un petit peu raté notre devoir de conseil ?

Conséquences pour les auditeurs et auditrices

Il y a des conséquences avec tout ça pour les auditeurs et auditrices, déjà.

• On nous demande des audits de conformité :
  • Même quand il n’y a aucune attention qui a été portée à l’accessibilité ;
  • Quand le site est fini et qu’il n’y a eu aucun accompagnement sur le sujet ;
  • Quand il n’y a pas la capacité à corriger (par manque de temps, de budget ou n’importe quoi). On audite donc, parfois, pour rien.
• Quand il y a énormément de problèmes, l’audit est super long à faire et c’est vraiment pénible de remonter tous ces problèmes. [Ça me fait rire de façon un peu gênée, je dis que je suis désolée et cela fait, encore rire la salle, qui applaudit même un peu] ;
• Et on finit par écrire des tartines imbuvables dans des cases de tableur. C’est pénible pour les gens qui reçoivent mais c’est aussi pénible pour nous de les écrire.

Conséquences pour l’équipe correctrice

Évidemment, il y a des conséquences pour l’équipe correctrice et surtout avec la façon dont elle reçoit la grille d’audit.

• Déjà cette grille d’audit, elle peut faire peur car il y a vraiment beaucoup de choses dans les cases. Il arrive qu’elle soit ouverte et refermée aussitôt et puis jamais traitée ;
• Ou alors, si on a un peu de chance, on a une équipe qui va quand même prendre en compte les correctifs et on va faire le suivi dans la grille d’audit directement. Pour ça, on va ajouter une colonne à la fin où l’équipe va dire ce qu’elle a corrigé, ce qu’elle n’a pas corrigé, ce qu’elle ne comprend pas ou autre. Nous, on va faire des tests et on va mettre nos retours. Il y a forcément des trucs qui ne vont pas puisque dans une case de tableur, il y a généralement plusieurs problèmes. Ensuite, l’équipe fait encore des retours. Nous, on refait encore des tests, etc. jusqu’à ce qu’on ait corrigé tous les problèmes de la case ;
• Sinon, une autre solution consiste à créer des tickets dans l’outil de gestion directement. Là, on est un peu plus proche du travail des équipes sauf qu’on doit faire le travail deux fois puisqu’il faut redécouper la grille. Parce que, dans une case, il y a plusieurs problèmes. Ou alors, il faut regrouper parce que, pour un composant, on peut avoir plusieurs critères invalidés et donc avoir des préconisations qui sont un peu réparties dans la grille. Ça devient très compliqué de faire ce travail. On a encore deux possibilités :
  • Soit, les tickets sont ajoutés au flot d’anomalies existant et ils sont mis de côté parce qu’il y en a trop et que c’est juste infernal ;
  • Ou alors, là encore, si on a de la chance, les tickets sont inclus dans des lots existants et il y a du temps qui est prévu pour les corriger.

Mais la plupart du temps, quand même, l’accessibilité finit au placard avec ces méthodes-là donc ça ne marche pas vraiment.

Allez, on se reprend et on s’écoute !

Je vous propose qu’on se reprenne un petit peu et puis qu’on s’écoute. Normalement, ça devrait bien se passer.

Le besoin des équipes correctrices

Déjà on va écouter besoins des équipes correctrices.

Je pense qu’on doit leur faciliter la tâche parce que, même si on voudrait que ce soit facile, l’accessibilité, ce n’est pas toujours facile. Il y a des choses qui sont faciles et d’autres pas.

• Pour faciliter la tâche, si on fournissait des informations structurées qui soient lisibles et compréhensibles, ce serait plus facile parce que la case du tableur ce n’est pas très lisible ;
• Elles ont besoin aussi qu’on puisse réutiliser les recommandations puisqu’un même composant peut être utilisé sur plusieurs pages du site voire sur différents projets d’une même entité ;
• Elles ont besoin qu’on s’adapte à leurs méthodes de travail, à leurs processus, à leur découpage en fonctionnalités, en histoires, en composants. C’est quelque chose qu’on ne peut pas faire avec la grille ;
• Elles ont besoin qu’on soit plus dans l’accompagnement : on ne livre pas juste la grille et « tenez débrouillez-vous ». Il faut qu’on les accompagne ;
• Et elles ont besoin qu’on donne des données chiffrées au moment où ça a du sens. Donner un niveau de conformité dans l’audit alors que le niveau est catastrophique, qu’il y a des centaines d’anomalies à remonter, je pense que ça ne sert à personne.

Le besoin des auditeurs et auditrices

Les auditeurs et auditrices ont aussi des besoins parce que, sinon, on pète un peu un câble.

• On a besoin que l’accessibilité soit prise au sérieux. C’est notre métier donc c’est quand même important ;
• On a besoin d’être compris et comprises et de ne pas auditer pour rien, d’avoir envie de se lever le matin, c’est important [rires] ;
• On aimerait aussi pouvoir modifier les recommandations facilement une fois qu’on a échangé avec l’équipe de développement. Des fois, on fait des préconisations et elles ne s’adaptent pas du tout à l’environnement technique. Ça arrive parce qu’il y a des contraintes qu’on ne connaît pas forcément au départ. On doit alors modifier les préconisations. Quand c’est dans le tableur, il faut retrouver dans quel onglet du tableur ça se trouve et dans quelle case. Sachant que, dans le RGAA 4, il y a déjà 106 critères ; il faut quand même bien chercher ;
• Et on a besoin de ne pas faire un travail doublon sur un audit.

Différents types d’audit pour chaque besoin

On va un petit peu tout casser et tout recommencer, pas totalement mais en partie. Comme il y a différents besoins pour les équipes, on va présenter différents types d’audit.

On aura toujours l’audit de conformité mais on l’aura sous deux formes : avec préconisations, sans préconisation. Et, on aura deux nouveaux types d’audit : l’audit flash et l’audit de composants. Je vais en parler en détail.

Audit de conformité

Avec ou sans préconisations

Il y a d’abord l’audit de conformité, qu’il soit avec ou sans préconisations.

• Le but du projet est vraiment de faire la déclaration d’accessibilité pour se mettre en conformité avec les documents demandés par la loi ;
• L’objectif de l’audit est de relever le niveau de conformité et les problèmes ;
• L’usage :
  • S’il y a peu d’anomalies, on peut faire un audit avec préconisations, histoire de faire la déclaration d’accessibilité mais, aussi, de mettre en conformité les éléments qui restent à corriger ;
  • S’il y a beaucoup d’anomalies, par contre, on fait sans préconisation. Sinon, on se retrouve dans le cas avec les tartines ;
  • Et s’il n’y a pas de possibilité de corriger rapidement, on fait sans préconisation. En effet, l’audit a une durée de validité : dès qu’il y a une évolution dans le site, l’audit n’est plus valable.
• Le principe de fonctionnement de ce type d’audit : on passe les tests et critères du RGAA un à un et, pour chaque test, on vérifie dans la page si on trouve des problèmes ;
• L’outil : on utilise une grille d’audit RGAA, donc un tableur.

L’outil

La DINSIC (aujourd’hui nommée DINUM) fournit une grille par défaut qui est organisée par critères : on met juste le niveau de conformité des critères. Elle est pas encore à jour pour l’instant mais c’est prévu pour dans quelques semaines qu’elle soit à jour avec le RGAA 4. Elle l’est maintenant.

Nous, de notre côté, chez Tanaguru, on a repensé cette grille d’audit pour qu’elle soit organisée par tests et non pas par critères. On va auditer chaque test et mettre le niveau associé à chaque test. Ça va calculer automatiquement le niveau pour le critère.

C’est plus facile pour une personne qui débute dans les audits et quand le référentiel est mis à jour tout simplement. Il faut un petit peu de temps pour s’approprier le RGAA 4, quand même. Travailler avec les tests, ça nous facilite la tâche.

1. On va choisir la grille en fonction du type d’audit qu’on fait :
   • Si on audite avec préconisations, on va plutôt faire un audit par tests parce que, quand on écrit les préconisations dans la case, on ne peut pas retenir le niveau de chaque test pour calculer ensuite celui du critère. Sinon, notre cerveau, il ne tient plus ;
   • En revanche, quand on audite sans préconisation, on peut faire l’audit par critères puisque, là, on a un peu plus de mémoire disponible. Mais il n’est pas exclu de faire l’audit par tests quand on fait l’audit sans préconisation. C’est vraiment comme on veut.
2. Comment fonctionne notre grille ? On relève d’abord les non-conformités pour les éléments transverses à l’échantillon de pages. Par exemple : l’en-tête ou le pied de page du site.
   On relève uniquement les non-conformités et, ensuite, on a un bouton pour propager le statut « invalidé » de ces critères-là sur toutes les pages de l’audit. Ça nous évite de retester toujours les mêmes choses ;
3. Ensuite, on audite vraiment chaque page. Là, on va relever les critères conformes, non conformes, non applicables ;
4. Et, il y a deux cas : si on fait l’audit avec préconisations, pour chaque non-conformité :
   1. On va expliquer le problème et faire des préconisations de correction ;
   2. Si possible ou si besoin, on va fournir un exemple de code corrigé. Des fois, ça parle plus que juste le texte ;
   3. On va estimer la priorité par rapport à l’impact utilisateur ou utilisatrice. On estime parce qu’on ne peut pas contacter tous les utilisateurs pour savoir vraiment. Mais, à force d’être dans le domaine de l’accessibilité, du handicap, on finit par un peu mieux réussir à estimer ça. Il faut donc connaître un petit peu comment les personnes naviguent sur internet.
      Et, la complexité de correction, c’est, de toutes façons, revu ensuite par l’équipe de développement puisqu’en fonction de leur contexte (qu’on n’a pas toujours), ça peut être différent.
5. Pour l’audit sans préconisation, pour chaque non-conformité, on relève juste le problème. On ne s’embête pas avec le reste.

Audit flash et audit de composants

L’audit flash et l’audit de composants fonctionnent différemment.

• On a déjà un but qui est différent : c’est la mise en accessibilité. L’objectif n’est pas de faire la déclaration d’accessibilité : on ne pourra pas la faire avec ces audits-là ;
• L’objectif pour nous quand on fait l’audit, c’est que ce soit pratique et didactique. On est vraiment vers de l’accompagnement ici ;
• L’usage est s’il y a beaucoup d’anomalies et qu’on a un objectif de correction. Encore une fois, s’il n’y a pas de budget pour corriger, ça ne sert à rien qu’on s’embête dans les précisions ;
• On va vers un accompagnement de l’équipe correctrice dans ce type d’audit ;
• Le principe fonctionne à l’inverse de l’audit de conformité. On prend un composant dans l’échantillon de pages et on l’audite en entier. Dès qu’on trouve un problème, on va chercher le critère à invalider. C’est ce qu’on fait avec les audits WCAG parce qu’on n’a pas de grille pour pour faire ces audits-là. Ici, on fonctionne de cette façon ;
• L’outil : des documents textes ou web. C’est comme on préfère.

L’outil

Ici, on a un outil où on sera sur des documents structurés ; ce qu’on ne pouvait pas faire du tout avec la grille. On va être dans l’esprit composant, ticket. Ce sera plus facile de faire des copier-coller pour mettre dans l’outil de gestion des tickets directement.

• On découpe en titres et sous-titres chaque document qu’on crée ;
• On peut mettre en forme (gras, couleurs…), mettre des captures d’écran. Des fois dans les audits, on trouve des problèmes et, quand on met la préconisation, on ne sait plus de quelle partie de la page exactement ça parlait. Les captures d’écran nous aide, nous, pour nous y retrouver mais aussi, les équipes qui vont recevoir l’audit ;
• La lecture est plus facile. On peut mettre des commentaires dans le fichier ; c’est quand même plus simple que de rajouter des colonnes dans le tableur ;
• On relève uniquement les non-conformités. On ne se préoccupe pas de ce qui est valide et de ce qui est non applicable. C’est uniquement ce qui est invalide. L’idée est de mettre en accessibilité le site web ;
• Évidemment, on explique toujours le problème : on fait la préconisation, on met un exemple de code corrigé ;
• On estime la priorité et la complexité de correction.

Audit flash, en détail : un audit rapide pour déblayer le terrain

• On relève uniquement ce qui saute aux yeux ;
• On n’a pas pour objectif de faire un audit exhaustif dans ce cas-là ;
• On fait vraiment un premier pas vers la mise en conformité ;
• En général, c’est parce que l’équipe a un budget qui est plus serré. L’audit est plus rapide à faire. Et comme il y a moins de problèmes relevés, l’équipe peut plus facilement l’intégrer dans son planning.

Audit de composants, en détail

L’audit de composants, lui, c’est l’inverse.

• Il se veut le plus exhaustif possible. Comme on ne travaille pas avec la grille, on a d’autres outils pour essayer d’y arriver.
  • On a une liste de tests pour ne rien oublier. J’aurais voulu vous la partager mais on est en train de la mettre à jour avec le RGAA 4 donc elle n’est pas encore prête ;
  • Ce n’est pas une liste de tests exhaustive donc, on doit toujours avoir le RGAA à portée de main. Par exemple, si on a une vidéo dans la page, on va plutôt aller directement voir le RGAA, les règles précises, plutôt que de se fier à une liste de tests rapides. Il faut quand même qu’on soit sûre de ce qu’on préconise.
• On a un ensemble de fiches composants : un composant = une fiche. Comme ça, on s’y retrouve un peu plus facilement.
  • On audite un composant à la fois, à l’inverse de la grille ;
  • On découpe par type de problème et/ou sous-partie du composant ; ça dépend vraiment de la pertinence ;
  • Une sous-partie peut être associée à plusieurs critères invalidés. Dans la grille, si on avait un composant qui invalidait plusieurs critères, c’était tout réparti dans un seul onglet. Là, on a un plutôt les critères qui viennent se regrouper sous la préconisation. C’est un peu plus facile de corriger tout le composant d’un coup que de le faire par morceaux ;
  • Et bien sûr, on aura un composant « page » parce qu’il y a des recommandations qui sont liées à la page comme la balise <title>, les critères qui concernent les ensembles de pages, etc. On ne peut pas les faire dans un vrai composant.
• Si on veut des chiffres, on peut bien sûr faire des tableaux récapitulatifs. On peut faire, par exemple, les critères par priorité, ou un tableau qui récapitule les critères invalidés, etc. ;
• Ça ne remplace pas l’audit de conformité puisqu’on ne peut pas obtenir un niveau de conformité avec cet audit.

Audit de composants, avantages et limites

Il y a des avantages et des limites ; je pense que vous avez commencé un petit peu à le sentir.

Avantages

1. On a une vue d’ensemble d’un composant donc c’est beaucoup plus facile pour en parler, pour le corriger directement ;
2. Le découpage est plus synchrone avec le projet. Il faut effectivement échanger avec le projet, aussi, pour valider qu’il correspond bien à leur façon de travailler ;
3. Les préconisations sont adaptables. Dans les documents textes, c’est beaucoup plus facile de trouver les informations que dans le fichier Excel ;
4. Ça facilite le suivi et favorise les échanges. Quand on travaille sur les audits d’accessibilité, on doit aussi travailler, parfois, avec des personnes qui s’occupent du référencement naturel. Parfois, on a un peu de mal à être d’accord. Là, l’avantage est qu’on envoie la fiche composant et la personne peut directement avoir une vue d’ensemble. C’est plus facile pour elle de voir là où il y a effectivement des choses qui pourraient coincer avec le référencement et qu’on puisse trouver des solutions ensemble.
   Les échanges sont aussi favorisés avec les équipes de développement puisque c’est plus facile à lire ;
5. L’avantage, qui est peut-être le principal pour nous qui faisons les audits, est que ça permet d’évaluer la capacité à faire de l’équipe correctrice. On n’est pas obligée de faire l’audit de composants en entier, dès le départ. On peut auditer deux ou trois composants, envoyer à l’équipe et, si elle ne corrige pas, on ne fait pas le reste.

Limites

1. La principale limite est que ça nécessite une bonne maîtrise des règles d’accessibilité. Si on n’a jamais fait d’audit de conformité avant, ce type d’audit est quand même vachement compliqué à faire. C’est mieux de faire quelques audits de conformité avant ;
2. On n’a pas de résultat chiffré du niveau de conformité mais, le résultat, de toute façon, s’il est pourri… Je ne sais pas si ça sert à grand chose ;
3. Et puis, on a une préparation en amont qui est un petit peu plus longue parce qu’on doit lister les composants présents dans l’échantillon de pages. Mais, derrière, on a un gain de temps. Quand on va créer les tickets, si c’est nous, dans l’outil de gestion des tickets, ça va aller vite. L’avantage aussi, c’est que n’importe qui dans l’équipe projet peut le faire puisqu’il n’y a pas besoin de comprendre vraiment ce qui se dit. On peut faire des copier-coller puisqu’on a le titre, la description, la priorité.

Audit de composants, exemple de récapitulatif

Je vous montre un exemple de récapitulatif des critères invalidés sur un audit de composants.

Là, on a 9 composants avec 34 critères invalidés et, 4 à 17 critères invalidés pour un seul composant.

Je ne sais pas si vous imaginez, dans un audit de conformité, ce que ça aurait pu donner comme répartition dans la grille du tableur.

Je pense que ça aurait été vraiment horrible à corriger pour l’équipe de développement parce qu’il faut réussir à regrouper tout ça quand on corrige.

Conclusion-resumé : les audits, des modèles à adapter

En conclusion, les audits sont des modèles à adapter, y compris ce que je viens de vous présenter. Ça s’adapte en fonction des projets, en fonction des équipes ; ce ne sont pas des formules toutes faites. S’il y a une équipe qui ne s’en sort pas avec une façon de faire, on peut s’arranger pour que ça fonctionne mieux.

Récapitulatif des types d’audit par caractéristique

J’ai fait un tableau récapitulatif ; je pense que ce sera pratique.

• On a l’audit flash qui a pour outil un document texte (vous pouvez en faire plusieurs, ce n’est pas vraiment mon problème). L’usage est s’il y a beaucoup d’anomalies, qu’on veut corriger le plus flagrant et qu’on a un petit budget ;
• L’audit de composants, lui, a pour outil des fiches composants : plusieurs documents textes (là, c’est obligatoire). Et l’usage est si on a beaucoup d’anomalies, encore une fois. Mais là, on a vraiment un objectif de mise en conformité. C’est la première étape avant l’audit de conformité ;
• Ensuite, on a l’audit de conformité avec préconisations qui a une grille d’audit par tests comme outil. On l’utilise s’il y a peu d’anomalies, si on veut faire une déclaration d’accessibilité et qu’on veut faire une mise en conformité totale. S’il y a peu d’anomalies normalement, il n’y a plus qu’un pas à faire pour que pour que ce soit 100% bon ;
• Et l’audit de conformité sans préconisation aura plutôt la grille d’audit par critères (mais par tests, ça marche aussi) comme outil. L’usage est uniquement la déclaration d’accessibilité, si on n’a pas besoin… euh si on a l’impossibilité de corriger immédiatement (parce que, bien sûr, on a besoin de corriger !).

Les livrables pour les audits

Les livrables pour les audits, ça change un petit peu.

1. On va toujours livrer l’outil qu’on utilise : la grille, le document texte ou autre ;
2. Pour les tickets :
   • Soit, on fait directement les tickets dans l’outil de suivi des anomalies du projet, si on peut ;
   • Soit, on livre un document bien structuré pour créer les tickets facilement avec titres, descriptions, priorités de correction. C’est ce qu’on fait déjà avec l’audit flash et l’audit de composants. Dans ces cas, on n’a pas un double travail. Le 1 et le 2 se regroupent, si on livre ces audits-là et qu’on ne peut pas créer les tickets dans l’outil de suivi. Des fois, on n’a pas les droits donc c’est le projet qui préfère le faire directement.
3. On livre toujours un support de présentation non technique pour la réunion de restitution de l’audit. C’est obligatoire puisqu’on ne va pas livrer un audit sans le présenter à nos clients et clientes. Et puis, on se débrouille pour les chiffres, s’ils en veulent absolument, avec le nombre d’anomalies par priorité, ce genre de choses si on est sur l’audit flash ou de composants (j’ai dit « conformité » par erreur à l’oral). On a toujours un moyen de trouver des chiffres de toutes façons ;
4. Dans tous les cas, on priorise les correctifs selon l’impact utilisateur ou utilisatrice supposé. Si on ne le fait pas, de toutes façons, on va nous le demander puisque s’il y a beaucoup d’anomalies, les projets doivent réussir à gérer le flot.

Un audit à tout prix ? Non !

• Un audit a une limite de validité qui dépend de l’évolution du site (j’en ai parlé) ;
• Auditer pour auditer n’a d’intérêt pour personne ;
• On ne va pas se lancer dans un audit complet si les équipes ne peuvent pas corriger ;
• On va donc tester la capacité à faire des équipes correctrices. Là, l’audit de composants va bien nous aider ;
• On va toujours vérifier si le projet a beaucoup d’anomalies pour qu’on choisisse la bonne méthode. Normalement, on fait une passe rapide sur l’échantillon de pages pour chiffrer. Là, ça nous permettra de dire s’il y a beaucoup ou pas beaucoup d’anomalies ;
• Et surtout, on va demander si l’équipe est formée à l’accessibilité puisqu’on ne sera pas forcément dans le même niveau de détails pour les préconisations. Si l’équipe est pas du tout formée, on va mettre plus de détails pour les accompagner au mieux dans la correction.

Encore mieux qu’un audit : essayons d’arriver au début du projet

Bien sûr, plutôt que de faire que des audits, il faut qu’on essaye d’arriver au début du projet. C’est le monde idéal. C’est encore difficile à mettre en place dans les projets.

Mais si on pouvait vérifier les spécifications fonctionnelles et les maquettes graphiques, faire des préconisations aux équipes de développement, en amont, directement dans les tickets qui décrivent les fonctionnalités qu’elles vont devoir développer, nous, on vient se greffer à ça et on dit voilà, pour que ce soit accessible, vous allez suivre ces points-là.

Quand on est dans ce cas-là, on audite à chaque grande phase du projet et, pas avec la grille. On va plutôt faire des tickets d’anomalies directement. Si on a fait les préconisations en amont, normalement, il n’y a pas grand chose. Les retours d’audit sont ensuite très petits. Et même quand on va faire l’audit de conformité à la fin, il n’y aura plus grand chose.

C’est une méthode qui a été mise en place sur un projet sur lequel j’ai travaillé dans mon entreprise précédente où c’est moi qui faisais les préconisations aux équipes de développement. Ça a super bien fonctionné. On n’avait quasiment pas de retour pour l’audit donc le niveau de satisfaction de l’équipe était, quand même, je pense, un peu plus grand que quand on reçoit la grille de tableur avec toutes ses tartines.

Rappel essentiel

Il y a un rappel essentiel, quand même, c’est ce que je disais avec mon expérience précédente. S’il n’y a personne pour porter le sujet de l’accessibilité au sein du projet, directement en interne, on a beaucoup de mal à faire évoluer les sites vers la mise en accessibilité. Donc, intéressez-vous au sujet de l’accessibilité si ce n’est pas déjà fait. On doit aussi former les équipes en interne.

Ressources complémentaires

Je vous ai mis quelques ressources complémentaires. Je ne vais pas forcément les détailler maintenant :

• La grille d’audit de la DINSIC (DINUM) ;
• La grille de Tanaguru ;
• Un guide pour la réalisation d’audits de conformité RGAA (c’est la méthode dont je vous parlais au tout début avec un seul exemple) ;
• Les critères RGAA et WCAG ;
• Une infographie réalisée il y a quelques jours sur le cadre législatif français.

Merci

Tout ça, c’est dans le diaporama que vous retrouverez sur pw2019.tanaguru.com.

Et voilà ! Merci de votre attention !