Claude a écrit un React DatePicker, mais atteindre l’accessibilité WCAG a pris 3 jours de plus

L'équipe de développement a demandé à Claude de créer un DatePicker React personnalisé pour un formulaire de prise de rendez-vous médical—avec un support complet de la navigation au clavier et des lecteurs d'écran. L'IA a géré rapidement la première version. Puis ont suivi trois jours de raffinement.

Ce Que Claude a Bien Fait

Claude a généré une base fonctionnelle pour le composant : structure JSX, attributs ARIA basiques (`role="dialog"`, `aria-label`, `aria-live`), gestionnaires de clavier pour la navigation aux flèches et logique de grille calendaire. Comme point de départ—solide : le code se compilait, paraissait visuellement correct, et les tests manuels n'ont rien cassé. L'IA s'est avérée particulièrement utile pour le code passe-partout : générer 42 cellules de grille, calculer le décalage du premier jour du mois, formater les dates pour `aria-label`. C'est un travail fastidieux à faire manuellement, et Claude l'a géré proprement. Le problème n'est devenu évident qu'après le raccordement des vraies technologies d'assistance.

Où Tout s'est Mal Passé

Le vrai test a commencé quand NVDA sous Windows et VoiceOver sur macOS ont été lancés. Il y avait plusieurs problèmes :

• Le piège au focus ne fonctionnait pas — en naviguant par tabulation dans le dialogue, le focus revenait au document principal
• Les dates étaient mal lues — le lecteur d'écran disait « 1 » au lieu de « Lundi 1er juin 2026 »
• Le changement de mois était silencieux — la région `aria-live` ne se mettait pas à jour quand le mois changeait
• Échap fermait mais ne revenait pas — après fermeture du calendrier, le focus était perdu au lieu de revenir au bouton déclencheur
• Contraste élevé de Windows — la date sélectionnée n'était pas visuellement distincte du reste : le composant reposait sur la couleur CSS sans attributs d'état

Chacun de ces points dans le code généré ressemblait à « gestionnaire présent »—mais le comportement avec un vrai lecteur d'écran différait des attentes.

Comment Nous l'Avons Corrigé

Le salut a été WAI-ARIA APG—le guide officiel du W3C avec un modèle spécifique pour les dialogues DatePicker. Cela ne dit pas simplement « ajoute `aria-modal` », mais prescrit la séquence exacte : quel élément reçoit le focus à l'ouverture, comment maintenir le piège au focus, où le retourner à la fermeture, quel `aria-label` est nécessaire sur les boutons de navigation des mois.

« Lire le code généré ne signifie pas vérifier l'accessibilité.

Seul un vrai lecteur d'écran révèle la vérité. »

Le piège au focus a été réécrit en utilisant `querySelectorAll` avec interception manuelle de Tab et Shift+Tab. Chaque cellule de jour a reçu un `aria-label` complet comme « Mercredi 3 juin 2026 » plus `aria-pressed="true"` pour l'état sélectionné. Pour le mode contraste élevé, nous avons ajouté `aria-selected` et un contour via `outline` plutôt que juste une couleur de fond. La partie la plus subtile était `aria-live` : la région doit exister dans le DOM avant que le texte y soit écrit, sinon le lecteur d'écran l'ignore. Claude a inséré la région dynamiquement—cette nuance n'a pu être découverte que lors du test.

Ce Que Cela Signifie

Claude accélère l'écriture de code accessible mais ne remplace pas les tests avec lecteurs d'écran. La bonne nouvelle : une fois que vous avez travaillé avec WAI-ARIA APG une fois et documenté les solutions, le prochain composant accessible est écrit notablement plus rapidement. L'IA assume le travail passe-partout—mais sauter la vérification finale avec NVDA et VoiceOver n'est pas une option.