Guides pratiques

Choisir et tester les composants d’une interface web

Un composant est une partie réutilisable d’une interface : commande, champ, navigation ou présentation de données. Son apparence ne suffit pas à décider de son usage. Le bon choix permet au visiteur de comprendre ce qui va se passer, d’agir et de retrouver sa place après l’action.

Voir la méthode

Cartes de couleurs disposées en cercle sur un fond clair
Illustration

Partir de la tâche plutôt que de la maquette

Écrivez la tâche en une phrase : consulter les conditions, choisir une commune, comparer des offres ou confirmer une suppression. Précisez ensuite ce que l’action change : une adresse, un contenu affiché, une valeur saisie ou des données enregistrées. Cette distinction aide à choisir entre lien, bouton, champ et fenêtre de dialogue.

Commencez par la présentation la plus simple qui répond au besoin. Une liste de liens peut suffire là où une navigation complexe ajouterait des interactions. Une information nécessaire à tous peut rester visible. Le nombre de clics ne constitue pas, à lui seul, une mesure de la facilité du parcours.

Décrire un contrat de comportement

Pour chaque composant, notez son nom visible, ses états, les actions possibles et la destination du focus. Les pratiques ARIA du W3C expliquent qu’un rôle annoncé implique un comportement : ajouter un attribut ARIA ne fournit pas les interactions. Privilégiez les éléments HTML natifs quand ils répondent au besoin.

Préparez les cas hors démonstration : texte long, absence de donnée, délai, annulation, erreur et modification simultanée. Le contrat précise ce qui est sauvegardé et ce qui reste provisoire. Une personne qui valide la maquette doit pouvoir distinguer une demande envoyée d’une simple animation du bouton.

Choisir une fiche selon la décision à prendre

Les fiches suivantes décrivent des décisions différentes : montrer un complément, changer de vue, sélectionner une valeur, gérer une interruption, lire des données ou réordonner des éléments. Elles complètent le guide général d’accessibilité sans constituer une certification du site.

Après le choix, inscrivez une tâche et un résultat attendu dans le carnet de recette. Testez une occurrence réelle, puis les variantes du composant dans un formulaire, un catalogue et une page traduite. Un correctif dans le modèle partagé doit être vérifié dans ces contextes.

Comparer deux solutions sur une même tâche

Exemple pédagogique : une équipe hésite entre trois onglets et trois sections visibles pour présenter des offres. Elle demande de retrouver une condition puis de comparer deux prestations sur téléphone. Elle observe les retours en arrière, les détails oubliés et la possibilité de partager la bonne information. Si les visiteurs ont besoin de lire les trois parties ensemble, les sections visibles peuvent être plus adaptées.

Contenu mis à jour le 7 octobre 2026

Matrice de recette à adapter au projet

Ces contrôles proposés utilisent des cas fictifs. Décidez du comportement attendu avec l’équipe, notez le résultat et attribuez les écarts non résolus avant publication.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Cas de test, résultats attendus et preuves utiles
CasRésultat attenduPreuve à conserver
Choix du composantLa tâche et le changement produit sont explicitesUne phrase de besoin et l’alternative comparée
États incompletsAttente, erreur et annulation ont une issueCaptures et résultat de chaque scénario
Clavier et téléphoneL’action se termine et le focus reste compréhensibleParcours, environnement et anomalies
MaintenanceLe propriétaire et les variantes sont connusListe des pages et critères de recontrôle

Questions fréquentes

Faut-il créer un composant sur mesure pour chaque page ?

Réutilisez un modèle éprouvé lorsque le comportement est le même. Personnalisez les mots et les données. Une variante qui change les commandes ou la gestion du focus mérite son propre contrôle.

Un composant issu d’une bibliothèque est-il automatiquement accessible ?

Sa qualité dépend aussi de sa version, de son intégration et du contenu. Vérifiez la documentation, puis la tâche réelle avec les navigateurs et aides techniques pertinents pour le public.

Ces fiches remplacent-elles un audit d’accessibilité ?

Elles aident à concevoir et à tester des interactions ciblées. Un audit examine également la structure, les contenus, les médias, les contrastes et les parcours complets selon le référentiel applicable.