Ce dépôt contient les outils que nous utilisons chez Copsaé et que nous avons modifiés pour nos besoins dans la réalisation d’audits d’accessibilité.
Vous pouvez vous les approprier à votre tour selon la licence établie.
Vous trouverez plus de détails dans le « README.md » de chaque dossier :
- Grille d’audit de conformité au RGAA ;
- Grille d’audit flash (checklist) basé sur le RGAA ;
- Grille d’audit flash graphisme (checklist) basé sur le RGAA.
- Liste d’outils d’aide pour les audits
- Fournir un document de préconisations, en plus de la grille d’audit
- Estimer l’impact d’une anomalie d’accessibilité pour les utilisateurs et utilisatrices handicapées
Nom de l’outil | Type d’outil | Information |
---|---|---|
Assistant RGAA | Extension de navigateur | Extension Firefox |
Axe | Extension de navigateur | Extension Firefox |
Clavier | Périphérique | - |
Color Contrast Analyser | Logiciel | Télécharger chez l’éditeur |
Feuille de style pour tester l’espacement des caractères | Code | Extrait de code sur Gist |
Firefox | Logiciel | Télécharger chez l’éditeur |
HeadingsMap | Extension de navigateur | Extension Firefox |
Inspecteur navigateur | Outil navigateur natif | F12 dans le navigateur |
Lecteurs d’écran | Logiciel | NVDA, JAWS, VoiceOver, Talkback |
PDF Accessibility Checker | Logiciel | Télécharger chez l’éditeur |
Souris | Périphérique | - |
Stylus | Extension de navigateur | Extension Firefox |
The Contrast Triangle | Application web | Voir l’application web |
Validateur nu HTML checker + bookmarklet Check for WCAG 2.0 parsing compliance | Site web | Nu HTML checker + bookmarklet disponible dans la page « About » |
Vue adaptative du navigateur | Outil navigateur natif | CTRL + Maj + M sur Firefox |
WCAG Contrast checker | Extension de navigateur | Extension Firefox |
Web Developer toolbar | Extension de navigateur | Extension Firefox |
Zoom navigateur | Outil navigateur natif | CTRL + + (6 fois pour 200%) |
Nous déconseillons, si possible, de mettre les préconisations de correction pour les anomalies d’accessibilité dans la grille d’audit (quelque soit l’audit). En effet, la nature et la longueur des textes rédigés ne sont pas appropriées pour des cases de tableur : ce ne sera pas lisible, la mise en forme est difficilement possible, etc.
Nous conseillons donc de mettre les préconisations dans un (ou plusieurs) document séparé (ou bien dans l’outil de gestion des tickets du projet).
Voici quelques points qui nous semblent importants :
- Qu’on fasse un seul ou plusieurs documents, ils sont toujours organisés avec des titres.
- La hiérarchie du contenu doit forcément permettre de copier/coller ensuite le contenu pour en faire des tickets. On doit retrouver :
- Titre du ticket (= titre de l’anomalie)
- Description de l’anomalie/du problème
- Éventuellement : capture(s) d’écran ou code concerné (non corrigé)
- Impact utilisateur/utilisatrice estimé (bloquant, majeur, mineur)
- Page ou liste des pages concernées
- Critère(s) RGAA invalidé(s)
- Préconisation de correction
- Éventuellement : exemple de code corrigé
- Certaines anomalies peuvent porter sur plusieurs critères RGAA invalidés à la fois si cela se justifie en termes de taille du ticket (attention : à éviter si le ticket devient trop gros), de métiers concernés (design, développement, contribution…)…
- Exemple 1 : un bouton qui a un défaut de contraste (design) + un défaut de nom (développement) = 2 tickets séparés
- Exemple 2 : un bouton qui n’a pas la bonne sémantique (développement) + un défaut de nom (développement) = un seul ticket
- Éviter les trop gros tickets : voir si ça ne peut pas être découpé en plusieurs plus petits. Un ticket trop gros sera généralement partiellement corrigé car il sera difficile à suivre.
Dans le cadre d’un audit de conformité, la DINUM propose un modèle de rapport d’audit qui peut servir comme structure de base du document. Libre à nous, ensuite, de rédiger les préconisations de la façon qui nous semble la plus appropriée.
Estimer l’impact d’une anomalie d’accessibilité pour les utilisateurs et utilisatrices handicapées n’est pas forcément facile. Nous avons essayé de définir 3 niveaux d’impact comme suit :
- Bloquant = impact bloquant : le problème empêche l’accès à une information ou un service pour au moins un « type de handicap » (exemple : un bouton n’est pas utilisable au clavier et il n’y a aucun moyen alternatif pour obtenir l’information cachée derrière ce bouton) ;
- Majeur = impact fort : le problème est gênant pour accéder à une information ou un service pour au moins un « type de handicap » (exemple : visuellement, le contenu est hiérarchisé avec des titres mais ce sont tous des paragraphes dans le code) ;
- Mineur = impact faible : le problème ne gêne pas l’accès à l’information (exemple : l’élément
<title>
ne contient pas le nom du site mais le nom du site est bien présent dans l’en-tête de celui-ci) ou le problème a un impact inexistant tant que le code reste en l’état mais présente un risque (exemple : un identifiant dupliqué lorsque cet identifiant n’est associé à aucun autre élément techniquement (champs de formulaire, ancre,aria-labelledby
,aria-describedby
…)).
Ces définitions peuvent être amenées à changer avec le temps (selon leur pertinence évaluée à l’usage, selon des discussions avec d’autres personnes expertes, etc.). Ainsi, elles sont précisées dans le mode d’emploi de chaque grille d’audit pour ne pas fausser la lecture d’un audit réalisé avec une éventuelle version antérieure de ces règles.