Accessibilité web : concevoir pour tous les utilisateurs

Ce que vous saurez faire

L’accessibilité web n’est pas un luxe réservé aux grandes entreprises européennes. Au Sénégal, où la diversité des utilisateurs est grande (personnes âgées dans les zones rurales, personnes malvoyantes, utilisateurs de smartphones bas de gamme, connexions 3G instables), concevoir accessible devient un avantage concurrentiel majeur. Une PME qui vend des produits locaux en ligne depuis Dakar peut toucher 30 % de clients supplémentaires simplement en respectant les bases de l’accessibilité. Au terme de ce tutoriel, vous saurez auditer un site existant, appliquer les règles WCAG (Web Content Accessibility Guidelines) niveau AA, adapter vos interfaces aux lecteurs d’écran, tester avec les outils gratuits du marché, et former votre équipe aux bonnes pratiques. Vous comprendrez pourquoi une commerçante non-voyante de Pikine doit pouvoir commander sur votre site aussi facilement qu’un étudiant de l’UCAD avec un MacBook dernier cri.

Étape 1 — Comprendre les quatre principes POUR

L’accessibilité repose sur quatre piliers : Perceptible, Opérable, Compréhensible, Robuste. Perceptible signifie que l’information doit pouvoir être captée par plusieurs sens (pas uniquement la vue). Opérable veut dire que les fonctionnalités doivent être utilisables au clavier, pas seulement à la souris. Compréhensible impose un langage clair et des interactions prévisibles. Robuste exige que le code fonctionne sur différents navigateurs et technologies d’assistance. Imprimez ces quatre mots au-dessus de votre bureau. Chaque décision de design doit être validée face à ces principes.

Étape 2 — Auditer l’existant avec des outils gratuits

Avant de modifier quoi que ce soit, mesurez. Installez l’extension WAVE (wave.webaim.org) ou axe DevTools sur Chrome. Lancez l’audit sur votre page d’accueil, votre page produit, votre formulaire de contact et votre tunnel d’achat. Notez le nombre d’erreurs critiques (ex : images sans alt, contrastes insuffisants, champs sans label). Exportez un rapport que vous partagerez avec votre développeur. Lighthouse (intégré à Chrome via F12 > Lighthouse) donne aussi un score d’accessibilité de 0 à 100. Visez au minimum 85 dans un premier temps, 95 à terme.

Étape 3 — Garantir un contraste suffisant

Le ratio de contraste entre le texte et son arrière-plan doit être d’au moins 4,5:1 pour le texte normal et 3:1 pour le texte large (plus de 18 points). Utilisez le Contrast Checker de WebAIM pour vérifier. Erreur fréquente sur les sites sénégalais : texte gris clair sur fond blanc pour un effet « moderne ». Sous le soleil dakarois, sur un écran de smartphone à luminosité moyenne, ce texte devient illisible. Préférez un gris foncé (#333333) sur blanc. Pour vos boutons d’action (ex : « Commander — 15 000 FCFA »), le contraste doit être maximal : blanc sur vert foncé, par exemple.

Étape 4 — Écrire des textes alternatifs utiles

Chaque image informative doit avoir un attribut alt. Mais attention : « image1.jpg » ou « photo du produit » ne servent à rien. Décrivez ce qui est important dans le contexte. Exemple : pour un produit de cosmétique, écrivez alt= »Pot de beurre de karité bio 250g, étiquette orange avec logo Keur Naturel ». Les images purement décoratives doivent avoir un alt vide (alt= » »), pour que le lecteur d’écran les ignore. Ne jamais mettre le même alt à toutes les images d’un carrousel. Prenez le temps : un bon alt prend 15 secondes à écrire mais change tout pour un utilisateur aveugle.

Étape 5 — Structurer avec des titres hiérarchiques

Utilisez un seul <h1> par page (le titre principal), puis <h2> pour les sections, <h3> pour les sous-sections. Les lecteurs d’écran permettent de naviguer de titre en titre : une structure claire fait gagner un temps fou. Erreur classique : utiliser des <h2> juste pour grossir un texte, sans logique de structure. Si vous voulez un texte gros, utilisez le CSS (font-size), pas une balise de titre. Testez : naviguez dans votre page uniquement via les titres. Si le plan est logique, c’est bon.

Étape 6 — Rendre les formulaires accessibles

Chaque champ doit avoir un <label> associé via l’attribut for. Ne vous contentez pas d’un placeholder : il disparaît dès que l’utilisateur tape. Groupez les champs liés avec <fieldset> et <legend>. Pour un formulaire de livraison, indiquez clairement les champs obligatoires avec aria-required= »true » et un astérisque visible. Les messages d’erreur doivent être explicites : « Le numéro de téléphone doit commencer par +221 » plutôt que « Erreur de saisie ». Placez l’erreur près du champ concerné et associez-la via aria-describedby.

Étape 7 — Assurer la navigation au clavier

Débranchez votre souris pendant 10 minutes et essayez d’utiliser votre site uniquement avec Tab, Shift+Tab, Entrée et les flèches. Tous les liens et boutons doivent être accessibles. L’ordre de tabulation doit suivre une logique visuelle (de haut en bas, de gauche à droite). Le focus doit être visible : un contour bleu ou une surbrillance. Erreur critique : supprimer l’outline CSS par « souci esthétique ». Cela rend le site inutilisable pour des milliers de personnes. Restylez le focus plutôt que de le supprimer.

Étape 8 — Proposer un lien d’évitement

Au tout début de la page, ajoutez un lien « Aller au contenu principal » qui pointe vers l’id de votre <main>. Ce lien est invisible par défaut mais apparaît au focus clavier. Il permet aux utilisateurs de lecteur d’écran ou de clavier de sauter le menu de navigation qui, sinon, se répète sur chaque page. C’est une ligne de code qui fait gagner 30 secondes de tabulation à chaque visite.

Étape 9 — Sous-titrer les vidéos et audios

Si vous publiez des vidéos explicatives (ex : tutoriel pour utiliser votre service, témoignage client), ajoutez des sous-titres. YouTube les génère automatiquement, mais corrigez-les : l’IA confond souvent les noms locaux (Ousmane devient « Osman », Fatou devient « fatwa »). Pour une vidéo en wolof, fournissez aussi une transcription écrite en français. Cela bénéficie aux personnes sourdes, mais aussi aux utilisateurs dans un bus bruyant de Dakar qui ne peuvent pas mettre le son.

Étape 10 — Rédiger dans un langage clair

Évitez le jargon technique ou juridique. Préférez « Votre commande sera livrée demain » à « Le délai de mise à disposition du bien est de 24 heures ». Les phrases courtes (15-20 mots maximum) facilitent la lecture pour les personnes dyslexiques et les utilisateurs dont le français est la deuxième ou troisième langue. Segmentez les longs paragraphes, utilisez des listes à puces, mettez en gras les points essentiels. Un test simple : votre grand-mère comprendrait-elle ?

Étape 11 — Tester avec un lecteur d’écran

Installez NVDA (gratuit, Windows) ou utilisez VoiceOver (intégré sur Mac et iPhone via Cmd+F5). Fermez les yeux et naviguez sur votre site. L’expérience est instructive : vous découvrirez que certains boutons sont annoncés « bouton, bouton » sans label, que des carrousels annoncent 50 fois la même chose, que des menus déroulants sont totalement silencieux. Chaque correction améliore l’expérience. Ne comptez pas tester en une fois : étalez sur plusieurs sessions.

Étape 12 — Respecter les préférences utilisateur

Détectez via CSS les préférences du système : prefers-reduced-motion pour les personnes sensibles aux animations, prefers-color-scheme pour le mode sombre, prefers-contrast pour le contraste élevé. Adapter votre site à ces préférences montre un vrai souci d’inclusion. Évitez les animations qui clignotent plus de 3 fois par seconde : elles peuvent déclencher des crises d’épilepsie. Laissez l’utilisateur mettre en pause les carrousels automatiques.

Étape 13 — Former l’équipe et documenter

L’accessibilité n’est pas une action ponctuelle mais un état d’esprit continu. Organisez une demi-journée de formation pour votre équipe (designer, développeur, rédacteur, responsable marketing). Créez un guide interne de 5 pages avec les règles principales. Intégrez un checkpoint accessibilité dans chaque validation de maquette et chaque mise en production. Nommez un référent accessibilité : souvent le UX designer ou le chef de projet web.

Étape 14 — Communiquer votre engagement

Publiez une page « Accessibilité » sur votre site. Expliquez votre démarche, le niveau de conformité visé (WCAG 2.1 AA), les points encore en chantier, et surtout un contact pour signaler un problème. Cette transparence rassure vos clients et peut devenir un argument commercial, notamment face à des appels d’offres publics qui imposent de plus en plus des critères d’accessibilité. Au Sénégal, la loi d’orientation sociale de 2010 reconnaît les droits des personnes handicapées : votre site web fait partie de cet écosystème.

Erreurs à éviter

Traiter l’accessibilité en fin de projet. Refaire un site accessible coûte 3 à 5 fois plus cher que de le concevoir accessible dès le départ. Intégrez les exigences dès la phase de maquette.

Confondre accessibilité et responsive design. Un site qui s’adapte aux smartphones n’est pas forcément accessible aux lecteurs d’écran ou aux personnes daltoniennes. Ce sont deux démarches complémentaires mais distinctes.

Utiliser uniquement la couleur pour transmettre une information. Exemple : « les champs obligatoires sont en rouge ». Un utilisateur daltonien ne verra rien. Ajoutez toujours un texte ou un symbole.

Supprimer le focus visible au clavier. Sous prétexte d’esthétique, beaucoup de développeurs appliquent outline:none. Restylez-le, ne le supprimez pas.

Remplir les alt avec des mots-clés SEO. L’attribut alt sert à décrire l’image, pas à manipuler Google. Les moteurs pénalisent ce spam, et les lecteurs d’écran deviennent incompréhensibles.

Penser que l’accessibilité ne concerne que les aveugles. Elle concerne aussi les sourds, les personnes à mobilité réduite, les seniors, les personnes avec des troubles cognitifs, et tous ceux qui utilisent temporairement un contexte dégradé (soleil, bruit, mains prises).

Négliger les PDF et documents téléchargés. Un catalogue en PDF de 30 pages non structuré est inaccessible. Utilisez Word ou InDesign avec la fonction « vérifier l’accessibilité » avant d’exporter.

Checklist finale

• Audit WAVE et Lighthouse réalisé, score supérieur à 85
• Contraste de tous les textes vérifié au WebAIM Contrast Checker
• Images informatives avec alt descriptif, images décoratives avec alt= » »
• Structure de titres hiérarchique (un seul h1 par page)
• Tous les champs de formulaire dotés d’un label associé
• Navigation complète au clavier testée (Tab, Entrée, flèches)
• Focus visible et stylé sur tous les éléments interactifs
• Lien d’évitement « Aller au contenu principal » en début de page
• Vidéos sous-titrées, transcriptions disponibles
• Langage clair, phrases courtes, pas de jargon inutile
• Test avec un lecteur d’écran (NVDA ou VoiceOver) effectué
• Préférences utilisateur respectées (reduced-motion, dark-mode)
• Équipe formée, référent accessibilité désigné
• Page « Accessibilité » publiée avec contact dédié
• Audit à renouveler tous les 6 mois