Accueil
  • #accessibilité
  • #UX/UI
  • #Bisit

Accessibilité web : les vérifications à faire avant de publier

Par · · 3 min de lecture

Un site accessible fonctionne pour tout le monde : au clavier, avec un lecteur d’écran, avec un fort zoom, sur un petit écran ou en plein soleil. Les règles de référence sont les WCAG (Web Content Accessibility Guidelines). Le niveau visé par la plupart des projets est AA.

Voici les vérifications à faire avant de publier une page, dans l’ordre où elles évitent le plus de problèmes.

Mettez la souris de côté et utilisez uniquement la touche Tab.

  • Chaque lien, bouton et champ doit être atteignable.
  • L’ordre doit suivre la logique de la page.
  • Un indicateur de focus visible doit toujours montrer où l’on se trouve.

Si vous ne voyez pas où vous êtes, un utilisateur au clavier ne le voit pas non plus.

Vérifier les contrastes#

Le texte doit se distinguer clairement de son fond. Les seuils du niveau AA sont les suivants :

  • 4,5:1 pour le texte courant ;
  • 3:1 pour le grand texte, les icônes utiles et les bordures de composants importants.

Testez aussi le mode sombre et les états : survol, focus, désactivé, lien visité.

Ne jamais compter sur la couleur seule#

Une erreur indiquée uniquement en rouge, ou un état sélectionné uniquement en changeant de teinte, échappe à une partie des utilisateurs. Ajoutez toujours un texte, une icône ou une forme.

Structurer avec de vrais titres#

Un seul h1 par page, puis des h2 et h3 dans l’ordre. Les lecteurs d’écran utilisent les titres pour naviguer, et les moteurs de recherche aussi. Utilisez les éléments natifs (button, a, nav, main) plutôt que des div cliquables : ils apportent gratuitement le comportement clavier et les rôles.

Nommer les contrôles#

  • Chaque champ de formulaire doit avoir une étiquette visible.
  • Un bouton avec seulement une icône doit avoir un nom accessible.
  • Chaque image porteuse d’information doit avoir un texte alternatif, et une image purement décorative un alt vide.

Soigner les formulaires#

Les messages d’erreur doivent être associés au champ concerné, expliquer le problème et suggérer une correction. Ne vous contentez pas d’un bandeau générique en haut de page.

Tester le zoom et les petits écrans#

La page doit rester utilisable à 200 % de zoom du texte et se réorganiser à 320 pixels de large, sans défilement horizontal. Les cibles tactiles doivent mesurer au moins 24 par 24 pixels.

Respecter les préférences de mouvement#

Les animations qui bougent beaucoup doivent s’arrêter ou se réduire quand la personne a demandé moins de mouvement dans son système (prefers-reduced-motion). Évitez tout contenu clignotant.

Des outils pour aider#

Les outils automatiques repèrent une partie des problèmes seulement : contrastes, textes alternatifs manquants, étiquettes absentes. Ils ne remplacent pas un test au clavier ni un test avec un lecteur d’écran. Combinez les deux.

Et pour les agents de code IA ?#

Les interfaces générées par IA ont tendance à se ressembler et à oublier l’accessibilité. C’est pour cela que j’ai écrit Bisit, un skill de design frontend et d’accessibilité pour les agents de code : il rappelle ces vérifications et préserve le contenu et l’identité du produit.

En résumé#

Clavier, contraste, structure, étiquettes, formulaires, zoom et mouvement : ces huit contrôles couvrent l’essentiel. Pour comprendre pourquoi ils comptent, lisez aussi Pourquoi l’UX/UI est importante.

À lire aussi