Accessibilité web : les bases pour un site plus inclusif
Clavier, contrastes, images et formulaires : des exemples pour comprendre l'accessibilité web et commencer par les obstacles qui bloquent vos visiteurs.
Sur cette page6 sections
Vous avez rempli un formulaire. Vous cliquez sur « envoyer ». Rien ne se passe, sauf un petit cadre rouge autour d'un champ, sans explication. Vous relisez, vous essayez un autre format, vous recommencez. Au bout d'un moment, vous partez.
Ce genre de détail peut agacer tout le monde. Pour une personne qui ne distingue pas certaines couleurs ou utilise un lecteur d'écran, il peut carrément empêcher la demande d'aboutir. L'accessibilité web commence là : est-ce que le site laisse vraiment les gens faire ce qu'ils sont venus faire ?
Elle répond d'abord aux besoins des personnes handicapées, et ses bénéfices dépassent ce seul public. Un texte lisible aide aussi sur un téléphone en plein soleil. Un parcours utilisable au clavier peut servir après une blessure. Ces situations ne sont pas toutes équivalentes ; elles montrent qu'on ne peut pas exiger une seule façon de lire et d'utiliser un site.
Les recommandations WCAG donnent des repères mesurables. Pour le niveau AA, le contraste du texte courant doit généralement atteindre 4,5:1 ; celui d'un grand texte, 3:1, avec les définitions et exceptions prévues par le critère. Le W3C explique ces seuils. Pas besoin de les calculer à l'œil : on peut vérifier les couleurs avec un outil.
La couleur ne doit pas porter seule une information importante. « Les champs rouges sont obligatoires » est moins utile que de nommer clairement les champs nécessaires. Pour une erreur, on peut garder le rouge, mais ajouter « Indiquez une adresse e-mail complète ». La personne sait alors ce qu'elle doit corriger.
Je préfère un site sur lequel on lit sans effort à un site qui mérite une capture d'écran mais demande ensuite de plisser les yeux.
S'il disparaît, vous avancez à l'aveugle. S'il reste coincé dans un menu, vous ne pouvez plus atteindre le formulaire. Ce sont des obstacles réels pour les personnes qui utilisent le clavier ou certaines technologies d'assistance.
Essayez un parcours complet : ouvrir le menu, choisir une prestation, atteindre le formulaire, le remplir, l'envoyer. Les contrôles doivent répondre avec les touches adaptées à leur fonctionnement : Entrée pour les liens, Entrée ou Espace pour les boutons usuels, par exemple. Tab ne sert pas à tout faire ; un composant complexe peut utiliser d'autres touches, mais son fonctionnement doit rester cohérent.
Les critères clavier et focus visible posent ces bases. Un bouton dessiné à partir d'un élément qui ne sait pas être un bouton demande parfois davantage de corrections qu'un composant HTML adapté dès le départ.
Prenons une photo de réalisation : « Terrasse en bois autour d'une piscine, avec marches intégrées » donne une information. « Image », le nom du fichier ou une liste de villes à référencer n'en donnent pas. Et si l'image montre un plan avec des dimensions indispensables, une courte description ne suffit pas : ces informations doivent aussi être disponibles sous une forme textuelle exploitable.
À l'inverse, une image purement décorative peut avoir un alt vide pour ne pas encombrer la lecture. Une icône dans un bouton doit permettre d'identifier l'action : une loupe qui lance une recherche ne doit pas seulement être annoncée comme « loupe ».
Le guide des images du W3C explique cette différence. La bonne question reste assez simple : qu'est-ce que la personne manquerait si l'image n'était pas là ?
Le nom du champ doit rester compréhensible. Les exigences aussi. Si vous attendez un format précis, expliquez-le avant l'envoi. Si quelque chose bloque, indiquez où et pourquoi, sans effacer toutes les informations déjà saisies.
Et après l'envoi ? « Merci, votre demande a été transmise » répond à une vraie question. Un bouton qui change brièvement de couleur ne suffit pas à dire que le message est parti. Les notifications doivent aussi pouvoir être perçues par les technologies d'assistance.
Ce travail est détaillé dans le guide du W3C sur les étiquettes de formulaire. Il profite à votre relation client : une personne ne devrait pas devoir téléphoner uniquement parce qu'elle n'arrive pas à comprendre le formulaire.
Le critère de redistribution du contenu traite ce sujet. Un test sur votre propre téléphone ne suffit pas à couvrir toutes les situations, mais il aide à repérer une mise en page qui ne fonctionne qu'à une taille précise.
La structure des textes compte également : des titres qui annoncent leur sujet, des liens qui indiquent où ils mènent, une langue de page correctement déclarée. Pour les vidéos, il faut notamment prévoir les équivalents nécessaires aux informations sonores. Pour les animations, regarder si elles gênent la lecture et quels moyens de pause ou de réduction sont adaptés. On n'aide pas le visiteur en faisant bouger continuellement ce qu'il essaie de lire.
Un audit automatique aide à trouver des erreurs répétitives. Il ne sait pas à lui seul si une description est pertinente ou si une consigne est compréhensible. Ces tests sont un début, pas une certification et pas une réponse complète aux obligations légales éventuelles.
Chez Cadarsir, l'intérêt est de distinguer ce qu'on peut corriger dans l'existant de ce qui vient d'une structure plus profonde. Il n'est pas toujours nécessaire de refaire tout le site. En revanche, quand une refonte devient utile, autant éviter de reconstruire les mêmes obstacles avec des couleurs plus récentes.
Ce genre de détail peut agacer tout le monde. Pour une personne qui ne distingue pas certaines couleurs ou utilise un lecteur d'écran, il peut carrément empêcher la demande d'aboutir. L'accessibilité web commence là : est-ce que le site laisse vraiment les gens faire ce qu'ils sont venus faire ?
Elle répond d'abord aux besoins des personnes handicapées, et ses bénéfices dépassent ce seul public. Un texte lisible aide aussi sur un téléphone en plein soleil. Un parcours utilisable au clavier peut servir après une blessure. Ces situations ne sont pas toutes équivalentes ; elles montrent qu'on ne peut pas exiger une seule façon de lire et d'utiliser un site.
Le gris clair n'est pas plus élégant quand on ne peut pas le lire
Dans une maquette sur un grand écran, un texte discret peut sembler très soigné. Sur le téléphone du visiteur, le même texte se perd dans le fond. S'il explique une condition de réservation ou un supplément, ce n'est plus un détail graphique.Les recommandations WCAG donnent des repères mesurables. Pour le niveau AA, le contraste du texte courant doit généralement atteindre 4,5:1 ; celui d'un grand texte, 3:1, avec les définitions et exceptions prévues par le critère. Le W3C explique ces seuils. Pas besoin de les calculer à l'œil : on peut vérifier les couleurs avec un outil.
La couleur ne doit pas porter seule une information importante. « Les champs rouges sont obligatoires » est moins utile que de nommer clairement les champs nécessaires. Pour une erreur, on peut garder le rouge, mais ajouter « Indiquez une adresse e-mail complète ». La personne sait alors ce qu'elle doit corriger.
Je préfère un site sur lequel on lit sans effort à un site qui mérite une capture d'écran mais demande ensuite de plisser les yeux.
Posez la souris et essayez de prendre rendez-vous
La touche Tab permet normalement d'avancer entre les liens, les boutons et les champs. Le repère visible autour de l'élément actif s'appelle le focus. C'est, en quelque sorte, votre position sur la page quand vous n'avez pas de pointeur de souris.S'il disparaît, vous avancez à l'aveugle. S'il reste coincé dans un menu, vous ne pouvez plus atteindre le formulaire. Ce sont des obstacles réels pour les personnes qui utilisent le clavier ou certaines technologies d'assistance.
Essayez un parcours complet : ouvrir le menu, choisir une prestation, atteindre le formulaire, le remplir, l'envoyer. Les contrôles doivent répondre avec les touches adaptées à leur fonctionnement : Entrée pour les liens, Entrée ou Espace pour les boutons usuels, par exemple. Tab ne sert pas à tout faire ; un composant complexe peut utiliser d'autres touches, mais son fonctionnement doit rester cohérent.
Les critères clavier et focus visible posent ces bases. Un bouton dessiné à partir d'un élément qui ne sait pas être un bouton demande parfois davantage de corrections qu'un composant HTML adapté dès le départ.
Décrire une image, ce n'est pas remplir un champ pour Google
Le texte alternatif, souvent appelé alt, sert à transmettre ce que l'image apporte lorsque l'on ne peut pas la voir. Il dépend donc de son rôle, pas seulement de ce qu'elle représente.Prenons une photo de réalisation : « Terrasse en bois autour d'une piscine, avec marches intégrées » donne une information. « Image », le nom du fichier ou une liste de villes à référencer n'en donnent pas. Et si l'image montre un plan avec des dimensions indispensables, une courte description ne suffit pas : ces informations doivent aussi être disponibles sous une forme textuelle exploitable.
À l'inverse, une image purement décorative peut avoir un alt vide pour ne pas encombrer la lecture. Une icône dans un bouton doit permettre d'identifier l'action : une loupe qui lance une recherche ne doit pas seulement être annoncée comme « loupe ».
Le guide des images du W3C explique cette différence. La bonne question reste assez simple : qu'est-ce que la personne manquerait si l'image n'était pas là ?
Un formulaire doit accompagner, pas faire passer un examen
Dans un champ, le texte gris « Votre téléphone » disparaît dès qu'on écrit. Ce placeholder peut donner un exemple, mais il ne remplace pas à lui seul une étiquette clairement identifiable et correctement reliée au champ.Le nom du champ doit rester compréhensible. Les exigences aussi. Si vous attendez un format précis, expliquez-le avant l'envoi. Si quelque chose bloque, indiquez où et pourquoi, sans effacer toutes les informations déjà saisies.
Et après l'envoi ? « Merci, votre demande a été transmise » répond à une vraie question. Un bouton qui change brièvement de couleur ne suffit pas à dire que le message est parti. Les notifications doivent aussi pouvoir être perçues par les technologies d'assistance.
Ce travail est détaillé dans le guide du W3C sur les étiquettes de formulaire. Il profite à votre relation client : une personne ne devrait pas devoir téléphoner uniquement parce qu'elle n'arrive pas à comprendre le formulaire.
Agrandir le texte ne devrait pas cacher la moitié du site
Une page doit supporter un écran étroit et les réglages de lecture du visiteur. Quand on agrandit, les titres doivent rester lisibles, les boutons accessibles et les informations présentes. Pour le contenu courant, devoir déplacer la page à gauche et à droite à chaque ligne devient vite pénible ; certains tableaux ou contenus nécessitant deux dimensions ont des contraintes particulières.Le critère de redistribution du contenu traite ce sujet. Un test sur votre propre téléphone ne suffit pas à couvrir toutes les situations, mais il aide à repérer une mise en page qui ne fonctionne qu'à une taille précise.
La structure des textes compte également : des titres qui annoncent leur sujet, des liens qui indiquent où ils mènent, une langue de page correctement déclarée. Pour les vidéos, il faut notamment prévoir les équivalents nécessaires aux informations sonores. Pour les animations, regarder si elles gênent la lecture et quels moyens de pause ou de réduction sont adaptés. On n'aide pas le visiteur en faisant bouger continuellement ce qu'il essaie de lire.
Commencer par un parcours, sans annoncer une conformité imaginaire
Sur un petit site, je commencerais par l'action la plus importante : contacter, demander un devis ou réserver. On la teste au clavier, sur petit écran et avec les outils adaptés, puis on corrige les blocages.Un audit automatique aide à trouver des erreurs répétitives. Il ne sait pas à lui seul si une description est pertinente ou si une consigne est compréhensible. Ces tests sont un début, pas une certification et pas une réponse complète aux obligations légales éventuelles.
Chez Cadarsir, l'intérêt est de distinguer ce qu'on peut corriger dans l'existant de ce qui vient d'une structure plus profonde. Il n'est pas toujours nécessaire de refaire tout le site. En revanche, quand une refonte devient utile, autant éviter de reconstruire les mêmes obstacles avec des couleurs plus récentes.
