Voir les obstacles réels
Navigation clavier, lecteur d’écran, reflow, zoom, formulaires, contenus multimédias, composants dynamiques et documents.
Mission documentée
Audit accessibilité numérique et RGAA
Trouver les obstacles, produire la preuve, organiser la correction.
Edikka audite les parcours réels avec une méthode hybride : contrôles RGAA, tests clavier et technologies d’assistance, automatisation raisonnée, registre des écarts et contre-tests. Le résultat n’est pas un score décoratif, mais une base de décision exploitable par la direction, le produit et le développement.
- RGAA 4.1.2 et WCAG 2.2
- Tests humains et automatisés
- Preuves et limites explicites
- Backlog de correction actionnable
Ce que la mission doit rendre possible
À la fin de l’audit, chaque écart doit être compréhensible, reproductible, attribuable et priorisable. La direction connaît le risque ; l’équipe produit sait quel parcours corriger ; les développeurs disposent d’un attendu testable ; le prochain contre-audit peut rejouer la même décision.
Prioriser sans diluer
Impact utilisateur, fréquence, criticité du parcours, portée du composant et effort de correction sont séparés.
Prouver la progression
Constat initial, correction et contre-test restent datés. Un résultat automatisé n’est jamais présenté comme une validation humaine.
Limite contractuelle saine : l’audit ne promet ni certification, ni première position Google, ni conformité totale avant les vérifications nécessaires. Il produit les preuves et le plan permettant de progresser de façon défendable.
Un périmètre conçu autour du service rendu
L’échantillon est arrêté après inventaire. Il inclut les pages obligatoires, les gabarits, les contenus, les composants et les parcours critiques réellement présents. Selon le contexte, la mission peut aussi documenter les obligations EAA, les exigences des marchés publics ou les dépendances tierces, sans les confondre avec un résultat RGAA.
- Entrées : sitemap, analytics disponibles, design system, composants, documents, vidéos, formulaires et espaces authentifiés.
- Parcours : recherche, navigation, création de compte, authentification, achat, paiement, demande de contact, téléchargement ou action métier.
- Environnements : navigateurs et technologies d’assistance définis au cadrage, avec versions et limites consignées.
- Sorties : ce qui est conforme, non conforme, non applicable, à tester ou hors périmètre reste explicitement séparé.
La méthode d’audit
- Inventorier. Cartographier gabarits, composants, contenus, documents, fonctionnalités et dépendances.
- Échantillonner. Justifier les pages et parcours retenus, y compris les cas défavorables.
- Automatiser avec mesure. Utiliser Lighthouse, axe, validation et crawl comme détecteurs, jamais comme verdict unique.
- Tester humainement. Rejouer clavier, focus, zoom, reflow, annonces, formulaires, médias et technologies d’assistance.
- Documenter. Pour chaque décision : attendu, observé, URL, preuve, sévérité, limite et propriétaire.
- Prioriser. Transformer les écarts en backlog avec ordre de traitement et critères d’acceptation.
- Contre-tester. Rejouer après correction, conserver l’historique et publier seulement les conclusions soutenues par les preuves.
Des livrables utilisables, pas un PDF oublié
Décision
Synthèse exécutive, périmètre, méthode, risques, limites et trajectoire recommandée.
Production
Grille détaillée, registre des écarts, preuves, recommandations et backlog priorisé avec critères d’acceptation.
Transmission
Restitution aux équipes, réponses aux objections, aide à la déclaration et protocole de contre-audit selon le mandat.
Les formats sont définis au cadrage : HTML accessible, tableur, JSON ou Markdown peuvent compléter le rapport principal lorsque cela améliore le suivi, l’archivage ou l’exploitation par les outils internes.
Exemples publics de la méthode Edikka
- Candidat v1.1 enrichi et JSON Schema de validation — le niveau thème RGAA est publié, mais aucun rapprochement critère par critère non revu n’est inventé.
Questions sur l’audit accessibilité
Un score Lighthouse à 100 suffit-il pour déclarer un site accessible ?
Non. Lighthouse repère une partie des défauts détectables automatiquement. Un audit crédible ajoute des contrôles humains : clavier, lecteur d’écran, reflow, zoom, formulaires, médias, composants et compréhension des parcours.
L’audit produit-il automatiquement une déclaration de conformité RGAA ?
Non. La déclaration dépend du périmètre, de l’échantillon, des résultats et du cadre applicable. Edikka livre les éléments factuels nécessaires et sépare toujours audit, correction, contre-audit et éventuelle revendication de conformité.
Comment l’échantillon de pages est-il choisi ?
Après inventaire des gabarits, contenus, composants et parcours critiques. L’échantillon vise les pages obligatoires, les fonctionnalités essentielles et les variations réellement présentes, sans sélectionner seulement les pages les plus favorables.
Que reçoit l’équipe de développement ?
Un rapport lisible, une grille de résultats, un registre des écarts, les preuves utiles, des recommandations reproductibles et un backlog priorisé par impact, urgence et effort. Le format exact est fixé au cadrage.
Edikka peut-elle corriger les écarts après l’audit ?
Oui, si la mission inclut la remédiation. Pour préserver la traçabilité, les constats initiaux, les correctifs et les contre-tests restent distingués. Une revue indépendante peut être prévue pour les décisions sensibles.
Combien de temps faut-il prévoir ?
Le calendrier dépend du nombre de gabarits, des documents, des composants, des accès et du niveau de preuve attendu. Après une qualification courte, Edikka fournit un périmètre, des jalons et une estimation écrite avant le démarrage.
Cadrer l’audit sur votre vrai périmètre
Transmettez le domaine, les parcours critiques, les documents concernés, le calendrier et les contraintes d’accès. Edikka répond avec les hypothèses, les exclusions, les livrables, les jalons et une estimation écrite.
Demander le cadrage de l’audit