Valider l’accessibilité et les critères de livraison

Un tableau de bord peut afficher les bons montants tout en restant inutilisable pour une personne qui navigue au clavier ou utilise un lecteur d’écran. Avant la livraison, vous devez vérifier le parcours complet, les annonces produites après les actions et l’absence d’erreurs de typage.

Cette recette ne remplace pas les tests automatisés ni les vérifications faites avec des technologies d’assistance : elle les complète en vous donnant une séquence reproductible. Vous allez tester les principales actions du tableau de bord, noter les résultats attendus et bloquer la livraison si un critère essentiel échoue.

Préparer une recette reproductible

Commencez avec un jeu de données connu : au moins deux dépenses de catégories différentes, dont une dans le mois récapitulé et une autre hors de ce mois. Notez les valeurs attendues pour le total mensuel, le nombre de dépenses et les résultats des filtres ; vous pourrez ainsi distinguer une anomalie d’accessibilité d’une erreur métier.

Tester les parcours essentiels

Partez du début de la page et parcourez les liens de navigation. Chaque lien doit atteindre la section nommée correspondante, sans saut inattendu dans l’ordre de lecture. Poursuivez jusqu’au formulaire : chaque champ doit être identifiable par son libellé, et les contraintes natives doivent empêcher un envoi incomplet ou invalide lorsqu’elles s’appliquent.

Ajoutez une dépense valide, puis confirmez que les valeurs affichées sont cohérentes dans la liste et le récapitulatif concerné. Avec un lecteur d’écran, vérifiez que la confirmation est annoncée une seule fois et qu’elle ne provoque pas de déplacement forcé du focus. Essayez aussi de supprimer une ligne : son bouton doit annoncer une action compréhensible qui distingue la dépense visée, plutôt qu’un nom générique identique pour toutes les lignes.

Testez ensuite les filtres au clavier, avec une catégorie précise puis avec une recherche sans résultat. La table doit conserver ses en-têtes lorsque des lignes sont présentes ; dans le cas vide, le message doit expliquer clairement qu’aucune dépense ne correspond aux critères. Vérifiez que changer les filtres ne modifie pas les dépenses enregistrées ni le total mensuel, sauf si le comportement défini du récapitulatif dépend explicitement de ces filtres.

Contrôler les annonces et la structure

Inspectez la page avec un lecteur d’écran ou les outils d’accessibilité du navigateur. Les régions principales, les titres, le formulaire et la table doivent rester compréhensibles dans l’ordre de lecture ; les titres de colonnes doivent être associés aux données, et chaque action doit avoir un nom accessible pertinent. Si vous utilisez les outils du navigateur, traitez leurs alertes comme des pistes à vérifier, pas comme une preuve complète de conformité.

La région de statut doit rester disponible dans la page et ne recevoir un nouveau message qu’après une action réussie. Contrôlez aussi le cas d’une erreur de formulaire : le problème doit être perceptible, relié au champ concerné et formulé de manière exploitable. Si une action supprime l’élément actuellement focalisé, vérifiez que le focus demeure dans un emplacement logique et que la suite de la tâche reste possible.

Vérifier TypeScript et décider de la livraison

Exécutez le contrôle de types prévu par le projet, par exemple avec la commande suivante si le script existe dans son fichier package.json. Le contrôle doit s’achever sans erreur, sans désactiver les options strictes et sans contourner un problème par un type trop permissif. Vérifiez en particulier les valeurs potentiellement absentes, les propriétés des composants et les résultats produits par les hooks.

npm run typecheck

La commande se termine avec le code de sortie 0 et n’affiche aucune erreur TypeScript. Le nom exact du script dépend du package.json du projet.

N’ajoutez pas une dépendance ou une modification structurelle pour faire passer un contrôle isolé si une correction ciblée suffit. Comparez les fichiers concernés au contrat du projet : noms des fichiers, classes autorisées, variables CSS autorisées, état partagé des dépenses et des catégories, et filtres conservés localement. La recette finale vérifie également que ces contraintes restent intactes.

À retenir

• Parcourez l’application au clavier de bout en bout et confirmez la visibilité ainsi que la cohérence du focus.
• Testez l’ajout, la suppression, les filtres et les cas sans résultat avec les valeurs attendues.
• Vérifiez les noms accessibles, les erreurs reliées aux champs et les annonces de statut avec une technologie d’assistance.
• Lancez le contrôle TypeScript strict et corrigez les erreurs sans affaiblir les contrats.
• Livrez uniquement lorsque les contrôles fonctionnels, d’accessibilité et de structure sont satisfaisants.

Pour une prochaine évolution, conservez cette recette comme base de non-régression et complétez-la à chaque nouveau parcours ou composant interactif.