Réinventons les audits
d’accessibilité web
par Julie Moynat, Tanaguru
Paris Web
10 octobre 2019
Présentation
- Julie Moynat
(Twitter : @JulieMoynat) - Intégratrice web et consultante en accessibilité web, chez Tanaguru
(Twitter : @TanaguruApp) - Avant, je réceptionnais les audits.
Aujourd’hui, je les livre.
Partie 1 : C’est quoi le problème avec les audits d’accessibilité web ?
Tu veux te battre ?
Les clients et clientes demandent, les experts et expertes exécutent
- La loi dit que les sites doivent être accessibles aux personnes handicapées ;
- Les clients et clientes demandent des audits de conformité (évaluation du niveau et préconisations de correction) ;
- Les experts et expertes livrent les audits de conformité : c’est comme ça qu’on a appris !
Rappel des actions demandées par la loi (article 47, loi no2005-102)
- Page d’accueil : mention du niveau d’accessibilité (totalement, partiellement ou non conforme) ;
- Déclaration d’accessibilité (résultat d’évaluation : état de conformité, liste des contenus non accessibles, moyen de contact…) ;
- Schéma pluriannuel de mise en accessibilité ;
- Plan d’actions de l’année en cours.
Des audits de conformité, conformément à ce qui est attendu dans le RGAA
(Référentiel Général d’Amélioration de l’Accessibilité)
Le RGAA – référentiel français dont le champ d’application est précisé dans l’article 47 de la loi no 2005-102 – est basé sur la norme internationale, en anglais, WCAG (Web Content Accessibility Guidelines, Règles d’accessibilité pour les contenus web).
Le RGAA est constitué de 13 thématiques, 106 critères et 257 tests.
- Chaque thématique contient un certain nombre de critères.
- Chaque critère contient un certain nombre de tests.
- Chaque test d’un critère doit être vérifié.
- Si un des tests est non conforme, alors le critère est non conforme.
- Un critère est conforme seulement si au moins un test est conforme et que les autres sont aussi conformes ou non applicables.
- Un critère est non applicable seulement si l’ensemble de ses tests l’est.
Il existe 4 statuts de conformité dans le RGAA :
- Conforme : l’ensemble des tests applicables sont réussis ;
- Non conforme : un test applicable est échoué au moins ;
- Non applicable : il n’y a pas de contenu concerné par le critère ;
- Non testé : le critère n’a pas été testé (statut permettant de mesurer la progression de l’audit).
Ce qu’on livre si on suit le guide de réalisation d’audits RGAA
- La grille d’audit : relevé des problèmes, sans préconisation ;
- Un rapport d’audit qui reprend le contenu de la grille d’audit avec un seul exemple de non conformité pour un critère + préconisations associées ;
- Un support de présentation non technique pour la réunion de restitution de l’audit.
Ce qu’on a fini par livrer : une grille d’audit exhaustive
Ou des tartines de texte dans des cases de tableur
(+ toujours un support de présentation non technique)
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
- Combien de clients et clientes :
- savent vraiment ce qu’est l’accessibilité ?
- savent ce qu’implique un audit de conformité ?
- sont formées à l’accessibilité numérique ?
- Comment bien accompagner les équipes :
- si les audits et rapports ne sont pas complets ?
- avec des outils inadaptés à leur processus ?
- Pourquoi ne les avons-nous pas mieux conseillées en amont, en tant qu’auditeurs et auditrices ? N’aurions-nous pas un peu raté notre devoir de conseil ?
Conséquences pour les auditeurs et auditrices
- On nous demande des audits de conformité même quand :
- aucune attention n’a été portée à l’accessibilité ;
- le site est fini, sans accompagnement préalable ;
- il n’y a pas la capacité à corriger (manque de temps, de budget…).
- Énormément de problèmes ? C’est très long et fastidieux ;
- On écrit des tartines imbuvables dans des cases de tableur.
Conséquences pour l’équipe correctrice
- Grille ouverte et refermée aussitôt, jamais traitée ;
- Ou suivi dans la grille avec ajout d’un nombre infini de colonnes (Retours équipe, Retours de tests, Retours équipe, Retours de tests…) ;
- Ou création de tickets dans l’outil de gestion : cellules de la grille à redécouper ou regrouper (double travail) :
- Tickets ajoutés au flot d’anomalies existant et mis de côté ;
- Ou tickets inclus dans des lots existants et du temps est prévu pour les corriger (chance !).
La plupart du temps : l’accessibilité, au placard !
Partie 2 : Allez, on se reprend et on s’écoute !
Tout va bien se passer…
Le besoin des équipes correctrices
On doit leur faciliter la tâche !
- Lisibilité & compréhensibilité : des informations structurées ;
- Ré-utilisabilité des recommandations ;
- Adaptation à leurs méthodes de travail, à leurs processus, à leurs découpages en fonctionnalités, en histoires, en composants ;
- Être plus dans l’accompagnement ;
- Des données chiffrées au moment où ça a du sens.
Le besoin des auditeurs et auditrices
- L’accessibilité prise au sérieux ;
- Être compris et comprises ;
- Ne pas auditer pour rien ;
- Pouvoir modifier les recommandations facilement après échanges avec l’équipe de développement ;
- Ne pas faire un travail doublon sur un audit.
Partie 3 : Différents types d’audit pour chaque besoin
Maintenant, on casse tout et on recommence !
À chaque besoin son type d’audit
- L’audit de conformité avec préconisations ;
- L’audit de conformité sans préconisations ;
- L’audit flash ;
- L’audit de composants.
Audit de conformité : avec ou sans préconisations
- But du projet : déclaration d’accessibilité ;
- Objectif de l’audit : niveau de conformité et relevé des problèmes ;
- Usage :
- Peu d’anomalies : avec préconisations pour mise en conformité ;
- Beaucoup d’anomalies : sans préconisation ;
- Pas de possibilité de corriger rapidement : sans préconisation.
- Principe : recherche des problèmes à partir des tests et critères du RGAA ;
- Outil : grille d’audit RGAA (tableur).
Audit de conformité : l’outil
La grille d’audit RGAA repensée :
github.com/Tanaguru/Accessibility-Evaluation-Reports
- Avec préco : audit par tests. Sans préco : plutôt audit par critères ;
- Relevé des non-conformités des éléments transverses ;
- Audit de chaque page (Conforme, Non conforme, Non applicable) ;
- Si audit avec préco, pour chaque non-conformité :
- Explication du problème et préconisations de correction ;
- Si possible ou si besoin, exemple de code corrigé ;
- Estimation de la priorité + complexité de correction.
- Si audit sans préco, pour chaque non-conformité : relevé du problème.
Audit flash et audit de composants
- But du projet : mise en accessibilité ;
- Objectif de l’audit : être pratique et didactique ;
- Usage :
- Beaucoup d’anomalies et objectif de correction ;
- Vers un accompagnement de l’équipe correctrice.
- Principe : recherche des critères à partir des problèmes relevés (« à la WCAG ») ;
- Outil : documents texte ou web.
Audit flash et audit de composants : l’outil
Un ou des documents texte ou web structurés - dans l’esprit composants, tickets
- Découpage en titres, sous-titres ;
- Mise en forme (gras, couleurs…) et captures d’écran ;
- Lecture plus facile ;
- Commentaires possibles dans le fichier ;
- Relevé des non conformités, uniquement. Et toujours :
- Explication du problème + préconisations de correction ;
- Exemple de code corrigé ;
- Estimation de la priorité + complexité de correction.
Audit flash, en détails : un audit rapide pour déblayer le terrain
- Balayage rapide de l’échantillon de pages : ce qui saute aux yeux ;
- Non exhaustif ;
- Premier pas vers la mise en conformité ;
- Budget plus serré.
Audit de composants, en détails
- Relevé le plus exhaustif possible :
- Liste de tests pour ne rien oublier ;
- Toujours avoir le RGAA à portée de main.
- Ensemble de fiches-composants : un composant = une fiche :
- Audit d’un composant à la fois ;
- Découpage par types de problèmes et / ou sous-parties du composant ;
- Une sous-partie peut être associée à plusieurs critères invalidés ;
- Un composant « Page » pour les recommandations liées aux pages.
- Si on veut : ajout de tableaux récapitulatifs ;
- L’audit de composants ne remplace pas l’audit de conformité !
Audit de composants, avantages et limites
Avantages :
- Vue d’ensemble d’un composant ;
- Découpage synchrone avec le projet ;
- Préconisations adaptables ;
- Suivi facilité et échanges favorisés ;
- Permet d’évaluer la capacité à faire de l’équipe correctrice.
Limites :
- Nécessite une bonne maîtrise des règles d’accessibilité ;
- Pas de résultat chiffré du niveau de conformité
(est-ce bien utile quand le résultat est, de toutes façons, catastrophique ?) ; - Préparation en amont un peu plus longue (mais gain de temps pour création des tickets).
Audit de composants, exemple de récap.
Extrait d’un récapitulatif de critères invalidés par composant :
- 34 critères invalidés pour 9 composants ;
- 4 à 17 critères invalidés pour 1 composant ;
- Un audit de conformité n’aurait pas du tout été adapté.
Partie 4 : Conclusion-résumé :
les audits, des modèles à adapter
Chaque projet, chaque équipe est différente.
Récap. des types d’audit par caractéristique
Audit flash | Audit de composants | Audit de conformité avec préco | Audit de conformité sans préco | |
---|---|---|---|---|
Outil | Document texte | Fiches composants | Grille d’audit par tests | Grille d’audit par critères (ou tests) |
Usage | Nombreuses anomalies + corriger le plus flagrant + petit budget |
Nombreuses anomalies + mise en conformité (étape 1 avant audit de conformité) |
Peu d’anomalies + déclaration d’accessibilité + mise en conformité totale |
Déclaration d’accessibilité uniquement (impossibilité de corriger immédiatement) |
Les livrables pour les audits
- L’outil utilisé (grille, document texte…) ;
- Et / ou les tickets :
- Si possible, dans l’outil de suivi des anomalies du projet ;
- Si non, un document bien structuré pour créer les tickets facilement : titre + description + priorité de correction. (Déjà fait pour l’audit flash et de composants)
- Un support de présentation non technique pour la réunion de restitution de l’audit (avec chiffres clés : nombre d'anomalies par priorité, etc.).
Note : Dans tous les cas, on priorise les correctifs selon l'impact utilisateur ou utilisatrice supposé.
Un audit à tout prix ? Non !
- Un audit a une limite de validité dépendante de l’évolution des sites ;
- Auditer pour auditer n’a d’intérêt pour personne ;
- Ne nous lançons pas dans un audit complet si les équipes ne peuvent pas corriger ;
- Testons la capacité à faire des équipes correctrices ;
- Vérifions en amont si le projet a beaucoup d’anomalies pour mieux choisir la méthode ;
- Information importante : l’équipe est-elle formée à l’accessibilité ? Adaptons notre niveau de détails dans les préconisations.
Encore mieux qu’un audit : essayons d’arriver au début du projet
- Vérifions les spécifications fonctionnelles ;
- Vérifions les maquettes graphiques ;
- Faisons des préconisations aux équipes de développement en amont, dans les tickets ;
- Auditons à chaque grande phase du projet (avec des tickets).
Les retours d’audit sont ensuite tout petits-petits. Testé et approuvé !
Rappel essentiel
Rappel pour tous les types d’audit et d’accompagnement :
la présence d’une ou plusieurs personnes qui portent le sujet côté projet est nécessaire.
Ressources complémentaires
- Grille d’audit RGAA de la DINSIC (par critères - RGAA 3-2016) :
github.com/DISIC/rgaa_modeles_documents/ ; - Grille d’audit RGAA de Tanaguru (par tests - RGAA 3-2017 et RGAA 4.0) : github.com/Tanaguru/Accessibility-Evaluation-Reports ;
- Guide DINSIC pour la réalisation d’audits de conformité RGAA :
disic.github.io/guide-auditeur/ ; - Critères du RGAA 4 (version document pour l’instant) :
numerique.gouv.fr/publications/rgaa-accessibilite/ ; - Les critères WCAG 2.1 : w3.org/WAI/WCAG21/quickref/ ;
- Infographie sur le cadre législatif français : ekino.fr/articles/une-infographie-pour-comprendre-le-cadre-le-gislatif-de-laccessibilite.
Merci de votre attention !
Diaporama : pw2019.tanaguru.com
Des questions ?
- Diaporama accessible : AccesSlide
- Police d’écriture : Luciole, conçue spécifiquement pour les personnes malvoyantes
- Icônes et illustrations :
- Aymeric Faivre, pour Tanaguru
- Flaticon sous licence CC 3.0 BY : Freepik et Smashicons