Aller au contenu principal

Accessibilité d’une interface

Une interface accessible permet à davantage de personnes d’atteindre le même objectif, avec le mode d’entrée et les réglages qui leur conviennent. Ce n’est pas une version spéciale : c’est une structure robuste qui donne plusieurs chemins vers la même information et la même action.

Commencer par la sémantique​

Le navigateur expose le rôle, le nom, l’état et la valeur des éléments aux technologies d’assistance. Utiliser le bon élément HTML est donc une décision fonctionnelle :

  • <button> déclenche une action dans la page ;
  • <a href> mène vers une autre ressource ou route ;
  • <form> regroupe une soumission ;
  • <label> nomme un champ ;
  • <nav>, <main>, <header> et <footer> structurent les régions ;
  • <h1> à <h6> annoncent une hiérarchie, pas une taille choisie au hasard.

Une <div> rendue cliquable n’acquiert pas automatiquement le clavier, le focus, le rôle ou le nom d’un bouton. Avant d’ajouter ARIA et des gestionnaires, demande si un élément natif décrit déjà le comportement.

Nommer les contrôles​

Chaque contrôle doit avoir un nom compréhensible hors contexte visuel. Un label visible est la meilleure base :

<label for="search">Rechercher une notion</label>
<input id="search" name="search" type="search"
       aria-describedby="search-help">
<p id="search-help">Par exemple : focus clavier ou architecture.</p>

Le placeholder donne un exemple temporaire ; il ne remplace pas le label. Pour un bouton avec une icône, garde un texte visible lorsque l’action est importante. Si l’icône est seule, son nom doit être explicite et stable.

Clavier et focus​

Un parcours clavier doit permettre de :

  1. atteindre chaque action interactive avec Tab ;
  2. voir où se trouve le focus ;
  3. activer un bouton avec Entrée ou Espace selon le comportement natif ;
  4. ouvrir, parcourir et fermer un composant sans souris ;
  5. comprendre le nouvel emplacement du focus après une navigation ou une erreur.

Le focus ne doit pas disparaître dans un contour de couleur insuffisant ni être envoyé au début de la page sans raison. Après une erreur de formulaire, place-le sur le premier champ invalide ou sur le résumé qui explique la correction. Après la fermeture d’une modal, restaure-le sur l’élément qui l’a ouverte.

Dialogues et menus​

Une modal doit avoir un titre, un rôle de dialogue, une fermeture explicite, une fermeture par Échap si le contexte l’autorise, un focus contenu dans la boîte pendant son ouverture et une restauration du focus. Un menu doit pouvoir être atteint, compris et fermé sans dépendre du survol.

N’ajoute pas role="dialog" à un bloc simplement parce qu’il ressemble à une carte. ARIA décrit un contrat ; un rôle incorrect est pire qu’une absence de rôle car il peut annoncer une fausse structure.

Messages et changements dynamiques​

Un changement visible n’est pas toujours annoncé. Pour un retour bref, une zone role="status" ou aria-live="polite" peut annoncer le résultat sans interrompre une lecture. Les erreurs urgentes doivent rester compréhensibles et récupérables.

<p id="save-status" role="status" aria-live="polite"></p>

Le message doit dire ce qui s’est passé et la prochaine action : « Réponse enregistrée. Ouvre la carte suivante. » est plus utile que « OK ».

Contraste et signaux multiples​

Vérifie séparément :

  • texte courant et texte de grande taille ;
  • bordure et focus des contrôles ;
  • texte d’aide et d’erreur ;
  • icônes et graphiques qui portent une information ;
  • état désactivé, qui ne doit pas rendre une information nécessaire illisible.

Un état ne doit pas être transmis par la couleur seule. Combine couleur, texte, icône, forme, position ou changement de contenu. Les utilisateurs ne partagent pas tous la même perception des couleurs, mais tout le monde bénéficie d’un message explicite.

Images, audio et vidéo​

  • Une image porteuse d’information reçoit un texte alternatif qui transmet la même information, sans décrire les pixels pour eux-mêmes.
  • Une image purement décorative a un alt="" et ne détourne pas la lecture.
  • Une vidéo pédagogique propose des sous-titres synchronisés et une transcription ; les informations visuelles importantes sont aussi rendues disponibles dans le texte ou l’audio.
  • Un graphique est accompagné d’un résumé et, si nécessaire, des données consultables.

Responsive, zoom et mouvement​

Le contenu doit rester accessible avec une largeur réduite, un zoom élevé, un texte agrandi et une orientation différente. Évite le scroll horizontal pour une phrase ou un champ ; laisse les blocs se réorganiser.

Respecte prefers-reduced-motion. Une transition ne doit pas être la seule preuve qu’une action a fonctionné et une animation ne doit pas masquer le contenu ou provoquer un malaise. Les limites de temps doivent pouvoir être prolongées ou supprimées lorsque la tâche le permet.

Tester dans l’ordre le plus rentable​

  1. Clavier : Tab, Shift+Tab, Entrée, Espace, Échap et flèches selon le composant.
  2. Structure : titres, landmarks, noms et ordre du DOM.
  3. Zoom et responsive : 320 px, zoom 200 %, texte long, mobile réel.
  4. Contraste : texte, focus et états ; jamais uniquement la capture idéale.
  5. Technologie d’assistance : au moins un lecteur d’écran sur le parcours principal.
  6. Test avec une personne : observer une tâche et écouter les difficultés sans conclure à partir d’un score automatique.

Les outils automatiques trouvent des problèmes de structure et de contraste, mais ils ne savent pas toujours si le message est compréhensible ou si l’ordre du parcours correspond à l’intention.

Exemple : une réponse enregistrée​

<button type="button" aria-controls="answer" aria-expanded="false">
  Révéler la réponse
</button>
<p id="answer" hidden>Une représentation qui aide à prévoir un système.</p>
<p role="status" aria-live="polite"></p>

Le bouton reçoit le focus nativement, son état aria-expanded peut suivre la visibilité, la réponse est reliée au contrôle et la zone de statut annonce une confirmation indépendante de la couleur ou de l’animation.

Atelier : rapporter un défaut accessible​

Un bon rapport contient :

  • l’environnement et le mode d’entrée ;
  • les étapes exactes ;
  • le résultat attendu ;
  • le résultat observé ;
  • l’impact sur la tâche ;
  • le correctif proposé et la façon de le vérifier.

Exemple : « À 320 px, après avoir ouvert le menu Parcours avec le clavier, Tab sort du menu et le focus disparaît. Attendu : le focus reste dans le menu ou le ferme vers son bouton. Observé : la personne ne sait plus où elle se trouve. Vérifier avec Tab, Shift+Tab et Échap sur Safari et Firefox. »

Checklist de sortie​

  • Le rôle HTML est natif lorsque c’est possible.
  • Chaque champ a un label visible, une aide et une erreur reliées.
  • Chaque action a un nom compréhensible et un retour observable.
  • Le focus est visible, ordonné et restauré après un dialogue.
  • Les changements dynamiques sont annoncés sans bruit inutile.
  • Les états ne dépendent pas de la couleur ou du survol seul.
  • Images, audio et vidéo ont une alternative adaptée.
  • Le contenu tient à 320 px, au zoom 200 % et avec du texte long.
  • Le mouvement respecte la préférence de réduction.
  • Le parcours principal a été vérifié au clavier et avec une technologie d’assistance.

Sources de référence​

Applique ces contrôles dans le parcours UI/UX interactif, puis relis les principes UI et les règles CSS.