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

Une équipe de développement a demandé à Claude de créer un DatePicker personnalisé en React pour un formulaire de prise de rendez-vous médical, avec une prise en charge complète de la navigation au clavier et des lecteurs d'écran. L'IA a produit rapidement une première version. Puis trois jours de corrections ont suivi.

Ce que Claude a bien fait

Claude a généré une base fonctionnelle du composant : la structure JSX, des attributs ARIA de base (`role="dialog"`, `aria-label`, `aria-live`), des gestionnaires de touches pour la navigation aux flèches et la logique de la grille du calendrier. Comme point de départ, c'était correct : le code compilait, l'aspect visuel était bon et la vérification manuelle n'a rien cassé.

L'IA s'est montrée particulièrement utile sur le code répétitif : générer les 42 cellules de la grille, calculer le décalage du premier jour du mois, formater les dates pour `aria-label`. C'est un travail fastidieux à faire à la main, et Claude l'a mené proprement.

Le problème n'est devenu évident qu'après le branchement de véritables technologies d'assistance.

Là où tout a déraillé

Le vrai test a commencé avec NVDA sous Windows et VoiceOver sous macOS. Plusieurs problèmes sont apparus :

• Le piège à focus ne fonctionnait pas : en tabulant dans la boîte de dialogue, le focus passait au document principal
• Les dates étaient mal annoncées : 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 au changement de mois
• Échap fermait sans rendre le focus : après la fermeture du calendrier, le focus se perdait au lieu de revenir sur le bouton déclencheur
• Contraste élevé de Windows : la date sélectionnée ne se distinguait pas des autres, car le composant s'appuyait sur une couleur CSS sans attributs d'état

Dans le code généré, chacun de ces points ressemblait à « il y a un gestionnaire », mais le comportement avec un vrai lecteur d'écran différait de ce qui était attendu.

Comment ils ont corrigé

La planche de salut a été le WAI-ARIA APG, le guide officiel du W3C avec un modèle précis pour la boîte de dialogue DatePicker. Il ne dit pas simplement « ajoutez `aria-modal` » : il fixe la séquence exacte, à savoir quel élément reçoit le focus à l'ouverture, comment maintenir le piège à focus, où le renvoyer à la fermeture et quels `aria-label` les boutons de navigation entre les mois exigent.

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

Seul un vrai lecteur d'écran dit la vérité. »

Le piège à focus a été réécrit avec `querySelectorAll`, en interceptant manuellement Tab et Maj+Tab. Chaque cellule de jour a reçu un `aria-label` complet du type « mercredi 3 juin 2026 », plus `aria-pressed="true"` pour l'état sélectionné. Pour le mode contraste élevé, l'équipe a ajouté `aria-selected` et un contour via `outline`, au lieu de se fier à la seule couleur de fond.

Le point le plus délicat était `aria-live` : la région doit être présente dans le DOM avant qu'on y écrive du texte, sinon le lecteur d'écran l'ignore. Claude a inséré la région dynamiquement, et cette subtilité n'est apparue qu'au test.

Ce que cela signifie

Claude accélère l'écriture de code accessible, mais ne remplace pas les tests avec des lecteurs d'écran. La bonne nouvelle : une fois le WAI-ARIA APG maîtrisé et les solutions documentées, le composant accessible suivant s'écrit nettement plus vite. L'IA prend en charge le travail répétitif, mais la vérification finale avec NVDA et VoiceOver ne peut pas être sautée.