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.
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 !
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 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 !
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.
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, 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é.
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.
