Rudra Analyzer

Vérificateur d'accessibilité gratuit

Exécutez le moteur d'accessibilité axe-core sur votre page dans un vrai navigateur pour repérer les obstacles courants — comme les champs de formulaire sans étiquette, un contraste de couleurs insuffisant, des images sans alternative textuelle et des erreurs ARIA — et apprenez à les corriger.

Saisissez une page, par exemple https://yourwebsite.com ou https://yourwebsite.com/pricing.

Ce que vérifie cet outil

  • Alternatives textuelles

    Les images, boutons-images et autres contenus non textuels sans alternative textuelle lisible par un lecteur d'écran.

  • Étiquettes de formulaire

    Les champs, cases à cocher et listes déroulantes sans étiquette accessible : les technologies d'assistance ne peuvent pas indiquer à quoi ils servent.

  • Contraste des couleurs

    Le texte dont la couleur est trop proche de son arrière-plan pour respecter les ratios de contraste WCAG AA.

  • Noms des liens et boutons

    Les liens et boutons sans nom lisible — souvent des boutons composés d'une seule icône.

  • ARIA

    Les rôles et attributs ARIA invalides, non autorisés sur l'élément concerné ou auxquels il manque des parties obligatoires.

  • Structure de la page

    Une langue de page, un titre de page, des repères (landmarks) et d'autres règles structurelles issues des WCAG et des bonnes pratiques d'axe-core.

  • Nombre d'éléments concernés

    Pour chaque problème (jusqu'à 25 types), le nombre d'éléments en échec et un exemple de l'endroit où en trouver un.

Comment fonctionne la vérification

Nous chargeons votre page dans Chromium headless, y ajoutons la bibliothèque axe-core et exécutons son ensemble de règles par défaut une fois la page rendue : le contenu ajouté par JavaScript est donc testé lui aussi. L'ensemble par défaut couvre les règles WCAG 2.x de niveau A et AA ainsi que les bonnes pratiques d'axe-core.

Chaque règle non respectée fait baisser le score selon son impact : 15 points si critique, 10 si grave, 5 si modéré et 2 si mineur. La déduction se fait par règle, pas par élément : une étiquette manquante ou vingt coûtent la même chose — le problème indique combien d'éléments sont concernés.

Les tests automatiques ne détectent qu'une partie des problèmes d'accessibilité qu'une page peut avoir. Beaucoup nécessitent le jugement d'une personne — si le texte alternatif a vraiment du sens, si l'ordre de navigation au clavier est logique, si le contenu est compréhensible. Considérez ce contrôle comme un point de départ, pas comme un certificat.

Problèmes fréquents que nous détectons

  • Texte peu contrasté

    Du texte gris clair, du texte sur des boutons colorés, et un texte indicatif (placeholder) utilisé à la place d'une étiquette.

  • Images sans texte alternatif

    Logos, photos de produits et images utilisées comme liens.

  • Champs de formulaire sans étiquette

    Des champs de recherche et d'inscription à la newsletter qui reposent uniquement sur un texte indicatif.

  • Boutons et liens composés d'une seule icône

    Des icônes de menu, de fermeture, de réseaux sociaux ou de panier sans texte pour les lecteurs d'écran.

  • Langue de la page manquante

    Pas d'attribut lang sur l'élément html : les lecteurs d'écran risquent d'utiliser la mauvaise prononciation.

  • ARIA mal utilisé

    Des rôles sur les mauvais éléments, ou des références à des identifiants (ID) qui n'existent pas.

Comment les corriger

  1. Foncez le texte ou éclaircissez l'arrière-plan

    Visez un ratio de contraste d'au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte. Un vérificateur de contraste dans les outils de développement de votre navigateur affiche ce ratio.

  2. Ajoutez un texte alternatif qui dit à quoi sert l'image

    Décrivez ce qui compte dans le contexte — « Télécharger la liste des prix » pour un lien-icône, et non « icône ». Utilisez alt="" pour les images purement décoratives.

  3. Donnez à chaque champ une étiquette visible

    Utilisez un élément label associé au champ. Si le design ne permet vraiment pas d'en afficher une, utilisez aria-label — mais les étiquettes visibles aident tout le monde.

  4. Nommez les boutons-icônes

    Ajoutez un texte visuellement masqué ou un aria-label, par exemple aria-label="Ouvrir le menu".

  5. Préférez le HTML natif à l'ARIA

    Un vrai élément button ou lien est accessible par défaut. N'ajoutez de l'ARIA que lorsqu'aucun élément natif ne convient.

  6. Testez aussi à la main

    Essayez d'utiliser la page uniquement au clavier, puis avec un lecteur d'écran comme NVDA ou VoiceOver, pour trouver ce que les règles automatiques ne détectent pas.

Questions fréquentes

Si je réussis ce contrôle, mon site est-il conforme aux WCAG ?

Non. Réussir signifie qu'aucun problème n'a été détecté par les règles automatiques. De nombreuses exigences WCAG ne peuvent être vérifiées que par une personne : la conformité nécessite donc aussi un examen manuel.

Teste-t-il la navigation au clavier ou les lecteurs d'écran ?

Non. axe-core inspecte le code de la page et les styles calculés. Il ne peut pas dire si l'ordre de tabulation est logique ni comment un lecteur d'écran annonce réellement la page — testez ces points à la main.

Quelle version et quel niveau WCAG utilise-t-il ?

L'ensemble de règles par défaut d'axe-core : règles WCAG 2.x de niveaux A et AA, plus des règles de bonnes pratiques. Les règles de niveau AAA ne sont pas incluses.

Pourquoi corriger un élément n'a-t-il pas changé mon score ?

Le score baisse une fois par règle non respectée, quel que soit le nombre d'éléments. Une règle ne compte plus contre vous que lorsque tous les éléments qu'elle a signalés sont corrigés.

Peut-il vérifier des pages protégées par une connexion ?

Non. Nous ne pouvons tester que les pages accessibles publiquement sans connexion.

Guides utiles

Outils gratuits associés

Vous préférez qu'on corrige pour vous ?

Ces contrôles sont gratuits, tout comme les guides. Si vous préférez qu'une personne effectue les modifications, notre équipe propose une aide payante.