Du code accessible avec Cursor, Claude Code et d’autres…

Les assistants de code comme Cursor, Claude Code, GitHub Copilot et Windsurf travaillent dans votre propre base de code. Ils lisent vos fichiers, lancent des commandes et proposent des modifications que vous relisez. Vous gardez donc plus de contrôle qu’avec un créateur de sites en discussion, mais l’accessibilité dépend des mêmes trois choses que le reste de la qualité de votre code : des règles claires, des vérifications automatiques et une relecture humaine. Ce guide s’adresse aux développeurs et couvre les trois, ainsi que la vérification du résultat déployé avec ibin.

Ce que les assistants de code ratent souvent

Les assistants reproduisent les schémas qu’ils voient, dans votre base de code et dans leurs données d’entraînement. Or la majorité du web n’est pas accessible : l’analyse 2026 de WebAIM portant sur un million de pages d’accueil a trouvé des erreurs détectables automatiquement sur 95,9 % d’entre elles. Résultats typiques sans règles :

Une div ou un span avec un gestionnaire onClick au lieu d’un bouton, donc inaccessible au clavier.
Des boutons réduits à une icône, sans nom accessible : un lecteur d’écran (logiciel qui lit l’écran à voix haute) annonce seulement « bouton ».
outline: none pour supprimer un contour de focus jugé disgracieux, sans remplacement.
Des listes déroulantes, combobox et fenêtres modales recréées de zéro, sans prise en charge du clavier ni gestion du focus.
Des attributs ARIA ajoutés pour corriger un problème qu’un élément natif n’aurait jamais eu. Un ARIA erroné est souvent pire que pas d’ARIA du tout.
Des couleurs codées en dur qui contournent vos design tokens et manquent de contraste.
Des changements de route côté client qui laissent le titre du document et le focus là où ils étaient.

Où placer les règles selon l’outil

Chaque outil lit un fichier au début d’une tâche. Consultez la documentation de votre outil, car ces emplacements évoluent.

Cursor : les règles de projet sont des fichiers .mdc dans .cursor/rules, avec un en-tête (frontmatter) qui précise quand elles s’appliquent. Utilisez alwaysApply: true pour les règles valables dans chaque discussion. Cursor lit aussi AGENTS.md, une alternative en markdown simple. Voir la documentation des règles de Cursor.
Claude Code : CLAUDE.md à la racine du projet (ou .claude/CLAUDE.md), chargé au début de chaque session. En l’absence de CLAUDE.md, Claude Code lit AGENTS.md, et un CLAUDE.md peut l’importer avec la ligne @AGENTS.md. Voir la documentation de Claude Code.
GitHub Copilot : des instructions pour tout le dépôt dans .github/copilot-instructions.md, et des instructions par chemin dans .github/instructions/NOM.instructions.md avec un motif applyTo. Les agents de Copilot lisent aussi AGENTS.md. Voir la documentation de GitHub.
Windsurf (devenu Devin Desktop en 2026) : les règles d’espace de travail sont des fichiers markdown dans .devin/rules, l’ancien dossier .windsurf/rules étant toujours lu. Indiquez trigger: always_on dans l’en-tête. Un AGENTS.md à la racine s’applique toujours. Voir la documentation des règles.
AGENTS.md : un format ouvert d’instructions pour agents, géré par l’Agentic AI Foundation au sein de la Linux Foundation et lu par de nombreux outils, dont OpenAI Codex, Gemini CLI, Cursor, Copilot et Windsurf.

Une organisation pratique pour une équipe qui utilise plusieurs outils : placez les règles dans AGENTS.md et faites pointer les fichiers propres à chaque outil vers lui. Pour Claude Code, un CLAUDE.md avec une seule ligne d’import suffit :

@AGENTS.md

Dans Cursor, si vous préférez une règle dédiée à AGENTS.md, créez .cursor/rules/accessibility.mdc commençant par cet en-tête :

---
description: Exigences d’accessibilité pour tout le code d’interface
alwaysApply: true
---

Le bloc de règles

Ajoutez ce bloc à AGENTS.md ou au fichier de règles de votre outil. Adaptez les noms de tokens et les commandes à votre projet.

## Accessibilité (WCAG 2.2 AA)

- Privilégie les éléments natifs : button pour les actions, a href pour la navigation, label pour les champs, fieldset/legend pour les groupes, dialog ou le Dialog du design system pour les fenêtres modales. Ne mets jamais onClick sur une div ou un span.
- N’utilise ARIA que si aucun élément natif ne convient. Ne remplace jamais un rôle natif.
- Chaque élément interactif a un nom accessible. Les boutons réduits à une icône reçoivent aria-label ; les icônes décoratives reçoivent aria-hidden="true".
- Chaque champ a une étiquette visible, reliée dans le code. Les erreurs sont reliées avec aria-describedby et affichées en texte.
- Ne supprime jamais un contour de focus sans remplacement visible via :focus-visible, avec un contraste d’au moins 3:1.
- Utilise uniquement les tokens de couleur du design system. Les tokens de texte atteignent 4.5:1 sur les surfaces où ils sont utilisés (3:1 pour le grand texte et les composants d’interface). Pas de couleurs codées en dur.
- Gestion du focus : place le focus dans les fenêtres modales, garde-le à l’intérieur tant qu’elles sont ouvertes et rends-le à la fermeture. Lors d’un changement de route côté client, mets à jour document.title et place le focus sur le titre principal.
- Respecte prefers-reduced-motion pour toute animation non essentielle.
- Un seul h1 par page et des titres dans l’ordre. Définis lang sur l’élément html.
- Les cibles interactives font au moins 24x24 pixels CSS.
- Avant de terminer une modification d’interface, lance le linter et les tests d’accessibilité (npm run lint, npm run test:a11y) et corrige les nouvelles erreurs.

Ajouter des vérifications automatiques en CI

Les règles rendent le bon code plus probable ; les vérifications rattrapent ce qui passe entre les mailles. Deux niveaux se complètent bien.

Un linter pour vos templates. Pour React et tout code JSX, eslint-plugin-jsx-a11y signale les textes alternatifs manquants, les div cliquables, les étiquettes sans champ et d’autres erreurs pendant la saisie. Les projets Vue peuvent utiliser eslint-plugin-vuejs-accessibility. Avec la configuration « flat » d’ESLint (vérifiez que le plugin prend en charge votre version d’ESLint) :

import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  jsxA11y.flatConfigs.recommended,
  // your other configs
];

Un test navigateur pour les pages rendues. axe-core est un moteur open source qui contrôle une page rendue selon de nombreuses règles WCAG. Playwright, un outil de test dans le navigateur, peut l’exécuter sur vos pages clés avec le paquet @axe-core/playwright :

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home page has no detectable accessibility violations", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

Lancez les deux en CI à chaque pull request, et mentionnez les commandes dans AGENTS.md pour que l’assistant les exécute avant d’annoncer qu’il a terminé. Les assistants corrigent bien une vérification en échec quand ils voient le message d’erreur.

Vérifier l’aperçu déployé avec ibin

Les tests tournent sur votre build local et sur les pages que vous avez choisies. Une vérification du site déployé attrape ce qu’ils manquent : scripts tiers, bandeaux de cookies, contenu de votre CMS et pages pour lesquelles personne n’a écrit de test.

Déployez un aperçu. La plupart des hébergeurs créent une adresse d’aperçu pour chaque pull request. Si l’aperçu est protégé par une connexion, utilisez une adresse de préproduction sans protection, ou l’adresse de production après la fusion ; un outil de vérification ne peut pas se connecter.
Vérifiez l’aperçu avec ibin. Le rapport présente les problèmes en langage clair, classés par ordre de priorité, avec une vue rapprochée de chaque endroit. Le détail technique se trouve sous « Code pour votre développeur ».
Confiez la correction à votre assistant. Chaque problème a un bouton « Copier les instructions pour un outil d’IA ». Le prompt fonctionne aussi bien dans Cursor, Claude Code ou Copilot que dans un créateur de sites : collez-le et relisez le diff.
Vérifiez tout le site. Connectez-vous pour vérifier jusqu’à 200 pages, et activez les vérifications hebdomadaires pour recevoir les régressions dans votre boîte mail.

Les outils automatiques, axe-core et ibin compris, trouvent environ un tiers à la moitié des problèmes d’accessibilité. Faites le test clavier en dix minutes sur les nouveaux parcours, et essayez un lecteur d’écran sur votre formulaire le plus important.

Ce qu’aucun assistant ni test ne peut juger

Un texte alternatif est-il juste, un texte de lien a-t-il un sens hors contexte, un message d’erreur aide-t-il, votre texte est-il clair ? Tout cela dépend du sens. Un assistant peut proposer un texte alternatif, mais il ne sait pas pourquoi l’image est sur la page. Relisez ces points à la main quand le contenu change. Le second regard de l’IA, proposé en option par ibin, note les descriptions d’images, les textes de liens, l’usage du clavier et la langue de 1 à 5, comme pistes pour une relecture humaine.

Pour la version non technique de cette approche, voir la présentation pour les créateurs de sites par IA. Les guides de correction expliquent chaque problème, par exemple les textes de liens.

Vérifiez votre site déployé

Déployez un aperçu et vérifiez gratuitement une page avec ibin. Collez les instructions de chaque problème dans votre assistant de code, relisez la modification et vérifiez à nouveau.

Voyez où en est votre site

Vérifiez gratuitement une page, sans compte. Vous recevez une liste claire de ce qu’il faut corriger en premier, avec des images de l’endroit où se trouve chaque problème.