Un logiciel accessible au clavier permet de parcourir les contrôles, comprendre le focus et accomplir les actions sans dépendre de la souris.
Les employés peuvent utiliser des raccourcis, une technologie d’assistance ou un clavier défectueux. Une interface qui ouvre une fenêtre sans déplacer le focus ou qui cache un bouton essentiel bloque le parcours.
Vérifier l’ordre
Le focus doit suivre l’ordre visuel et le flux du métier. Un contrôle désactivé doit être expliqué si son absence surprend. Les modales doivent capturer le focus puis le rendre au contrôle d’origine à la fermeture.
Donner un nom aux contrôles
Un bouton doit décrire son action. Une icône seule peut être ambiguë. Les erreurs doivent être associées au champ et annoncées de façon compréhensible. Les formulaires métier doivent conserver les valeurs saisies après une erreur.
Tester les raccourcis
Essayez tabulation, entrée, échappement, sélection, recherche et téléchargement. Vérifiez qu’aucun raccourci ne remplace une saisie utilisateur ou ne déclenche une action irréversible sans confirmation.
Sources : W3C, navigation clavier, WAI, formulaires.
Vérifier les tableaux et menus
Un tableau doit annoncer ses en-têtes et associer chaque cellule à la bonne colonne. Les menus ouverts au clavier doivent indiquer leur état et se fermer avec une touche prévue. Les contrôles désactivés doivent conserver une explication lorsqu’ils sont nécessaires à la compréhension du parcours.
Testez une recherche, une pagination, un téléchargement et une erreur de validation avec le clavier uniquement. Vérifiez aussi le zoom et le contraste sur les états de chargement et les messages temporaires. Ces cas sont fréquents dans les logiciels où les utilisateurs traitent de nombreux dossiers.
Organiser les corrections
Ajoutez un scénario de régression lorsqu’un composant est réutilisé. Une correction appliquée sur un écran doit être vérifiée sur les autres parcours qui utilisent le même bouton, tableau ou formulaire. L’équipe peut alors éviter de réparer le même blocage dans plusieurs écrans.
Inclure les erreurs et les confirmations
Une validation refusée doit déplacer le focus vers le premier champ incorrect ou vers un résumé qui mène à chaque erreur. Une confirmation doit indiquer l’action effectuée et permettre de retrouver l’élément modifié. Les messages temporaires doivent rester visibles assez longtemps et pouvoir être relus.
Testez aussi le téléchargement, la recherche et l’ouverture d’une nouvelle fenêtre. Le clavier doit permettre de revenir à l’application et de comprendre ce qui vient de changer. Ces contrôles s’ajoutent aux vérifications automatiques ; une analyse manuelle reste nécessaire pour juger le parcours.
Une équipe peut ajouter une liste de composants approuvés et des exemples accessibles. Le propriétaire du design et le propriétaire technique relisent les nouveaux composants avant leur réutilisation. La qualité est ainsi maintenue quand le logiciel grandit.
Incluez une vérification de clavier dans la recette de chaque fonction qui ajoute un contrôle. Notez les touches utilisées, l’ordre de focus et le résultat attendu. Cette petite fiche permet au support de reproduire un blocage et évite que l’accessibilité soit vérifiée seulement à la fin d’un projet.
Répétez le contrôle après une refonte visuelle ou un changement de bibliothèque.
Conservez le résultat dans la recette.
Rendre le focus visible
Le focus doit avoir un contraste suffisant et rester visible sur les contrôles. Un style supprimé pour des raisons graphiques peut rendre la navigation impossible. Vérifiez le focus sur les boutons, champs, menus, tableaux et fenêtres qui apparaissent après une action.
Lorsqu’une liste se met à jour, placez le focus à un endroit prévisible. Une personne ne doit pas recommencer depuis le haut après chaque suppression ou pagination. Annoncez le nombre de résultats lorsqu’il change et fournissez un moyen de revenir au titre de la liste.
Traiter les composants complexes
Un tableau éditable doit permettre d’entrer dans une cellule, de modifier sa valeur et de revenir à la ligne suivante. Une liste déroulante doit pouvoir être ouverte, recherchée et fermée au clavier. Un glisser déposer doit avoir une action équivalente accessible.
Les raccourcis doivent éviter les lettres utilisées dans les champs. Documentez-les et permettez de les désactiver lorsqu’ils peuvent déclencher une action. Les boutons de suppression et de validation exigent une confirmation ou une possibilité d’annulation selon leur impact.
Vérifier les messages
Une erreur de formulaire doit être annoncée et associée au champ. Le message doit rester compréhensible sans voir la couleur ou une icône. Les valeurs déjà saisies doivent être conservées après la réponse du serveur.
Testez avec la tabulation, les lecteurs d’écran disponibles dans les environnements supportés et une taille de zoom élevée. Vérifiez les états vides, les modales et les exports. L’accessibilité se juge sur le parcours complet, avec les droits et les erreurs.
Une correction doit être enregistrée comme un changement produit. Ajoutez un scénario de régression lorsque le composant est réutilisé. Une équipe peut ainsi éviter de réparer le même blocage dans plusieurs écrans.