accessibility-auditing

Déclencheurs

• audit d'accessibilité
• conformité WCAG
• test de lecteur d'écran
• navigation au clavier
• vérification d'accessibilité
• audit a11y
• examen ARIA
• contraste des couleurs
• technologie d'assistance
• conception inclusive
• gestion du focus
• révision du texte alternatif
• composants accessibles
• Section 508
• remédiation d'accessibilité

Instructions

Analyse de base automatisée

• Exécuter axe-core sur toutes les pages avec shell_execute : npx @axe-core/cli [url] --tags wcag2a,wcag2aa,wcag22aa
• Exécuter l'audit d'accessibilité Lighthouse
• Vérifier le contraste des couleurs dans le système de conception
• Examiner la hiérarchie des titres et la structure des repères
• Identifier tous les composants interactifs personnalisés pour les tests manuels
• Utiliser browser_navigate pour inspecter les pages visuellement

Tests manuels de technologie d'assistance

• Parcourir chaque parcours utilisateur au clavier uniquement -- pas de souris
• Compléter tous les flux critiques avec un lecteur d'écran (VoiceOver sur macOS, NVDA sur Windows)
• Tester à 200 % et 400 % de zoom du navigateur pour le chevauchement de contenu et le défilement horizontal
• Activer le mouvement réduit et vérifier que les animations respectent prefers-reduced-motion
• Activer le mode contraste élevé et vérifier que le contenu reste visible et utilisable

Étude approfondie au niveau des composants

• Auditer chaque composant interactif personnalisé par rapport aux WAI-ARIA Authoring Practices
• Vérifier que la validation de formulaire annonce les erreurs aux lecteurs d'écran
• Tester le contenu dynamique (modales, toasts, mises à jour en direct) pour la gestion correcte du focus
• Vérifier que toutes les images, icônes et médias ont des alternatives textuelles appropriées
• Valider les tableaux de données pour les associations d'en-têtes appropriées

Évaluation basée sur les normes

• Toujours référencer les critères de succès WCAG 2.2 spécifiques par numéro et nom
• Classer par gravité : Critique, Sérieux, Modéré, Mineur
• Ne jamais se fier uniquement aux outils automatisés -- ils ratent l'ordre du focus, l'ordre de lecture, l'abus d'ARIA, les barrières cognitives
• Favoriser le HTML sémantique avant ARIA -- le meilleur ARIA est celui dont vous n'avez pas besoin
• Considérer le spectre complet : handicaps visuels, auditifs, moteurs, cognitifs, vestibulaires, handicaps situationnels

Rapport et remédiation

• Documenter chaque problème avec le critère WCAG, la gravité, la preuve et la correction
• Prioriser par impact utilisateur -- un label de formulaire manquant bloque l'accomplissement des tâches
• Fournir des exemples de correction au niveau du code, pas seulement des descriptions
• Utiliser knowledge_write pour stocker les modèles de remédiation
• Planifier un nouvel audit après l'implémentation des corrections

Livrables

Modèle de rapport d'audit d'accessibilité

# Rapport d'audit d'accessibilité

## Aperçu de l'audit
**Produit/Fonctionnalité** : [Nom et portée]
**Norme** : WCAG 2.2 Niveau AA
**Date** : [Date de l'audit]
**Outils utilisés** : [axe-core, Lighthouse, lecteur d'écran(s), test au clavier]

## Méthodologie de test
**Analyse automatisée** : [Outils et pages analysées]
**Test avec lecteur d'écran** : [VoiceOver/NVDA/JAWS -- versions du système d'exploitation et du navigateur]
**Test au clavier** : [Tous les flux interactifs testés au clavier uniquement]
**Test visuel** : [Zoom 200 %/400 %, contraste élevé, mouvement réduit]

## Résumé
**Nombre total de problèmes trouvés** : [Nombre]
- Critique : [Nombre] -- Bloque l'accès complètement pour certains utilisateurs
- Sérieux : [Nombre] -- Barrières majeures nécessitant des contournements
- Modéré : [Nombre] -- Pose des difficultés mais dispose de contournements
- Mineur : [Nombre] -- Gênes qui réduisent l'utilisabilité

**Conformité WCAG** : NE CONFORME PAS / PARTIELLEMENT CONFORME / CONFORME
**Compatibilité technologie d'assistance** : ÉCHOUE / PARTIELLE / RÉUSSIT

## Problèmes trouvés

### Problème 1 : [Titre descriptif]
**Critère WCAG** : [Numéro -- Nom] (Niveau A/AA/AAA)
**Gravité** : Critique / Sérieux / Modéré / Mineur
**Impact utilisateur** : [Qui est affecté et comment]
**Localisation** : [Page, composant ou élément]
**État actuel** : [snippet de code]
**Correction recommandée** : [snippet de code]
**Vérification du test** : [Comment confirmer que la correction fonctionne]

## Ce qui fonctionne bien
- [Résultats positifs -- renforcer les bonnes pratiques]

## Priorité de remédiation
### Immédiate (Critique/Sérieux -- corriger avant la sortie)
### Court terme (Modéré -- corriger au cours du prochain sprint)
### Continu (Mineur -- aborder dans la maintenance régulière)

Liste de contrôle de navigation au clavier

## Navigation globale
- [ ] Tous les éléments interactifs accessibles via Tab
- [ ] L'ordre de tabulation suit la logique de mise en page visuelle
- [ ] Lien de navigation rapide présent et fonctionnel
- [ ] Aucun piège au clavier
- [ ] Indicateur de focus visible sur chaque élément interactif
- [ ] Échap ferme les modales, menus déroulants, superpositions
- [ ] Le focus revient à l'élément déclencheur après la fermeture de la modale

Métriques de succès

• Les produits atteignent une conformité WCAG 2.2 AA véritable, pas seulement le passage des analyses automatisées
• Les utilisateurs de lecteurs d'écran peuvent accomplir tous les parcours utilisateur critiques de manière indépendante
• Les utilisateurs au clavier uniquement peuvent accéder à chaque élément interactif sans pièges
• Les problèmes d'accessibilité sont détectés pendant le développement, non après le lancement
• Les équipes développent des connaissances en accessibilité et préviennent les problèmes récurrents
• Zéro barrière d'accessibilité critique ou sérieuse dans les versions de production

Vérifier

• Un scanner d'accessibilité automatisé (axe, Lighthouse, pa11y ou équivalent) a réellement été exécuté ; le rapport est joint ou résumé avec les identifiants de règle
• Chaque violation signalée porte une référence de critère de succès WCAG (ex. 1.4.3, 2.4.7), non un vague « problème d'a11y »
• Une traversée au clavier uniquement du flux affecté a été effectuée de bout en bout ; l'ordre de tabulation est documenté
• La sortie du lecteur d'écran (VoiceOver, NVDA, TalkBack) a été échantillonnée sur au moins un contrôle critique et le texte annoncé est enregistré
• Les rapports de contraste des couleurs pour le nouveau texte/les icônes sont rapportés sous forme de nombres (ex. 4,7:1) par rapport au seuil WCAG AA
• Les corrections ont été analysées à nouveau après l'application ; le rapport de deuxième passage affiche zéro régression sur les vérifications précédemment réussies