L’accessibilité web n’est pas optionnelle — c’est une obligation professionnelle

L’accessibilité web (a11y) consiste à concevoir des sites utilisables par tout le monde, y compris les personnes en situation de handicap : malvoyants, daltoniens, personnes à mobilité réduite, sourds et malentendants, personnes avec des troubles cognitifs. En Afrique subsaharienne, l’OMS estime que 15 % de la population vit avec une forme de handicap. Ignorer l’accessibilité, c’est exclure 15 % de vos utilisateurs potentiels.

Au-delà de l’aspect éthique, l’accessibilité améliore le SEO (Google favorise les sites accessibles), l’expérience mobile (les bonnes pratiques a11y améliorent l’UX pour tous), et dans certains pays, c’est une obligation légale (ADA aux USA, RGAA en France).

Les 4 principes WCAG (Web Content Accessibility Guidelines)

Les WCAG sont le standard international de l’accessibilité web. Ils s’organisent autour de 4 principes :

1. Perceptible : le contenu doit être perçu par tous les sens

Images : chaque image informative doit avoir un attribut alt descriptif. Pas alt="image" mais alt="Femme portant le sac à main en cuir marron, vue de face". Les images décoratives ont un alt="" vide
Vidéos : ajoutez des sous-titres pour les sourds et malentendants. YouTube génère des sous-titres automatiques (à corriger manuellement)
Contraste : le texte doit avoir un ratio de contraste minimum de 4.5:1 par rapport au fond. Vérifiez avec WebAIM Contrast Checker (webaim.org/resources/contrastchecker). Un texte gris #999 sur fond blanc #fff a un ratio de 2.85:1 — insuffisant
Taille du texte : le corps de texte ne doit jamais être inférieur à 16px. Utilisez des unités relatives (rem) pour que l’utilisateur puisse zoomer

2. Utilisable : l’interface doit fonctionner avec tous les dispositifs

Navigation au clavier : chaque élément interactif (lien, bouton, champ de formulaire) doit être accessible avec la touche Tab. Testez : naviguez sur votre site sans souris. Si vous êtes bloqué, il y a un problème
Focus visible : quand un élément est sélectionné au clavier, il doit avoir un indicateur visuel clair (outline). Ne faites jamais outline: none sans fournir une alternative visible
Pas de piège au clavier : l’utilisateur doit toujours pouvoir quitter un modal ou un menu avec Échap
Temps suffisant : pas de timeout automatique sur les formulaires sans avertissement

3. Compréhensible : le contenu et l’interface doivent être clairs

Langage simple : écrivez pour un niveau de lecture de 12-14 ans. Pas de jargon inutile
Messages d’erreur explicites : pas « Erreur » mais « Le numéro de téléphone doit contenir 9 chiffres »
Étiquettes de formulaire : chaque champ doit avoir un <label> associé, pas juste un placeholder
Navigation cohérente : le menu est au même endroit sur chaque page, les boutons ont le même style

4. Robuste : le code doit être interprétable par les technologies d’assistance

HTML sémantique : utilisez <nav> pour la navigation, <main> pour le contenu principal, <header> et <footer>, <button> pour les boutons (pas des <div onclick>)
Rôles ARIA quand le HTML sémantique ne suffit pas : rôle="alert" pour les messages d’erreur dynamiques, aria-label pour les boutons sans texte (icônes)
Structure de titres logique : un seul <h1> par page, suivi de <h2>, <h3> sans sauter de niveaux

Les corrections les plus impactantes (20 % d’effort, 80 % de résultat)

1. Ajouter les alt text aux images

Dans WordPress, éditez chaque image dans la médiathèque et remplissez le champ « Texte alternatif ». Pour un e-commerce, le alt text doit décrire le produit comme vous le feriez à quelqu’un au téléphone.

2. Corriger le contraste des couleurs

Lancez WAVE (wave.webaim.org) sur votre site. Il surligne immédiatement les éléments avec un contraste insuffisant. Corrigez en assombrissant les textes clairs ou en éclaircissant les fonds sombres.

3. Rendre les formulaires accessibles

<!-- ❌ Inaccessible -->
<input type="text" placeholder="Votre email">

<!-- ✅ Accessible -->
<label for="email">Adresse email</label>
<input type="email" id="email" name="email" 
       autocomplete="email" required
       aria-describedby="email-help">
<span id="email-help">Nous ne partagerons jamais votre email</span>

4. Ajouter un lien « Aller au contenu »

Les utilisateurs de lecteurs d’écran doivent pouvoir sauter la navigation pour accéder directement au contenu :

<body>
  <a href="#main-content" class="skip-link">Aller au contenu principal</a>
  <nav>...</nav>
  <main id="main-content">...</main>
</body>

<style>
.skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 100;
}
.skip-link:focus {
    top: 0;
}
</style>

Outils de test d’accessibilité

WAVE (wave.webaim.org) : audit gratuit en ligne — le plus simple pour débuter
Lighthouse (intégré à Chrome DevTools > onglet Lighthouse) : audit automatisé avec score d’accessibilité
axe DevTools (extension Chrome gratuite) : détection d’erreurs a11y directement dans le navigateur
NVDA (nvaccess.org) : lecteur d’écran gratuit pour Windows. Installez-le et naviguez sur votre site les yeux fermés — c’est l’expérience de vos utilisateurs aveugles
Colorblindly (extension Chrome) : simule les différents types de daltonisme

Accessibilité sur WordPress

WordPress intègre des outils d’accessibilité, mais votre thème peut les annuler :

Choisissez un thème taggé « accessibility-ready » dans le répertoire WordPress
Installez le plugin WP Accessibility (gratuit) : il corrige les problèmes courants (skip links, labels manquants, toolbar a11y)
Vérifiez que votre thème ne fait pas outline: none sans alternative — c’est l’erreur d’accessibilité la plus courante dans les thèmes WordPress

Accessibilité web 2026 : un standard, pas un bonus

À Dakar, Abidjan ou Yaoundé, des millions d’internautes naviguent avec un lecteur d’écran, une vision réduite, une dextérité limitée ou via un clavier seul. La référence mondiale est le WCAG (Web Content Accessibility Guidelines) du W3C, en version 2.2 publiée en octobre 2023. Ce tutoriel applique ses critères clés à un site moderne en sept étapes pratiques.

Étape 1 : auditer votre page actuelle

Commencez par mesurer. L’extension axe DevTools (Deque, gratuite) s’ajoute à Chrome ou Firefox et liste les violations WCAG en deux clics. Lighthouse (intégré à Chrome) fournit un score d’accessibilité de 0 à 100 dans son onglet dédié.

npx @axe-core/cli https://votre-site.tld --tags wcag2a,wcag2aa

Résultat type : un rapport JSON détaillant chaque violation avec son sélecteur CSS. Comment vérifier le bon fonctionnement immédiat est de connaître votre score de départ — typiquement 60 à 75 sur un site WordPress non optimisé.

Étape 2 : garantir un contraste suffisant

WCAG 2.2 niveau AA exige un ratio de contraste de 4,5:1 pour le texte normal et 3:1 pour le texte large (18pt ou 14pt gras). Testez chaque combinaison avec WebAIM Contrast Checker.

/* Avant : gris clair sur blanc, contraste 2,5:1 (fail) */
.meta { color: #999; background: #fff; }

/* Après : gris foncé, contraste 5,7:1 (pass AA) */
.meta { color: #595959; background: #fff; }

La preuve que ça tourne est un score WebAIM affichant « Pass » pour AA Normal Text. Notez que le texte sur image nécessite une zone de fond ou un overlay foncé.

Étape 3 : structurer le HTML sémantique

Un lecteur d’écran navigue par titres, listes et régions. Utilisez <header>, <nav>, <main>, <article>, <footer> au lieu de <div> génériques. Une seule balise <h1> par page, suivie d’une hiérarchie h2/h3 sans saut de niveau.

<main>
  <article>
    <h1>Titre principal</h1>
    <h2>Sous-section</h2>
    <p>Contenu...</p>
  </article>
</main>

Sortie de référence vu par un lecteur d’écran : « Région principale, article, titre niveau 1, Titre principal ». Indicateur que tout est en place est qu’un utilisateur de NVDA ou VoiceOver puisse sauter de section en section avec la touche H.

Étape 4 : alternatives textuelles pour les images

Chaque <img> porteuse d’information doit avoir un attribut alt qui décrit son sens, pas son apparence. Pour une icône purement décorative, mettez alt="" pour que le lecteur d’écran l’ignore.

<img src="cap-vert-skyline.jpg"
     alt="Vue panoramique de la baie de Dakar au coucher du soleil">
<img src="puce-deco.svg" alt="" aria-hidden="true">

Le bon résultat se reconnaît à est qu’un audit axe ne signale plus aucune image sans alt. Évitez « image de » ou « photo de » — c’est redondant car le lecteur annonce déjà la nature de l’élément.

Étape 5 : focus visible au clavier

Les utilisateurs naviguant au clavier (Tab, Shift+Tab) ont besoin de voir où ils sont. Ne supprimez jamais outline: none sans alternative. Définissez un style focus distinct et apparent.

:focus-visible {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
  border-radius: 2px;
}

Sortie de référence : un anneau bleu visible quand vous tabulez dans la page. Le marqueur de succès est de pouvoir traverser tout le formulaire sans toucher la souris, en sachant en permanence où se trouve le curseur.

Étape 6 : ARIA seulement quand le HTML ne suffit pas

La règle première d’ARIA : ne pas utiliser ARIA. Si un <button> natif fait l’affaire, n’utilisez pas <div role="button">. ARIA reste utile pour les composants riches (dropdown, modale, tab panel).

<button aria-expanded="false" aria-controls="menu-mobile">
  Menu
</button>
<ul id="menu-mobile" hidden>
  <li><a href="/blog">Blog</a></li>
</ul>

Le bon résultat se reconnaît à est qu’un lecteur d’écran annonce « bouton, Menu, replié » et après clic « bouton, Menu, déplié ». Sans cette synchronisation JS de aria-expanded, le composant trompe l’utilisateur aveugle.

Étape 7 : tester avec un vrai lecteur d’écran

Aucun outil automatique ne remplace un test manuel. Sur macOS, activez VoiceOver avec Cmd+F5. Sous Windows, installez NVDA (gratuit). Sur Android, TalkBack est intégré. Parcourez votre page, formulaires inclus, sans regarder l’écran.

Notez chaque blocage : un champ sans label, un bouton « Cliquez ici » sans contexte, une page qui change sans annonce. Sur le même thème, voyez le guide ARIA pratique et les patterns accessibles.

Étape 8 : intégrer l’accessibilité dans la CI

Pour ne pas régresser, ajoutez un test axe-core dans votre pipeline. À chaque pull request, le job échoue si une page introduit de nouvelles violations critiques.

# .github/workflows/a11y.yml
- run: npx playwright install --with-deps
- run: npx @axe-core/cli http://localhost:3000 \
       --exit --tags wcag2a,wcag2aa

Vous saurez que tout fonctionne quand est un check vert à chaque merge. Cette discipline fait progresser le score d’accessibilité de manière monotone, sans rétropédalage.

Étape 9 : rendre les formulaires accessibles

Chaque champ doit avoir un <label> explicitement associé via for et id. Les messages d’erreur doivent être annoncés et liés au champ avec aria-describedby. Évitez le placeholder seul — il disparaît à la saisie et n’est pas lu de manière fiable.

<label for="email">Adresse email</label>
<input id="email" type="email" required
       aria-describedby="email-help email-error">
<p id="email-help">Format : nom@domaine.tld</p>
<p id="email-error" role="alert" hidden>Email invalide</p>

Résultat attendu : à la soumission d’une saisie incorrecte, NVDA annonce « Email invalide » sans rechargement. Comment vérifier le bon fonctionnement est un formulaire utilisable de bout en bout sans souris ni vue.

Étape 10 : gérer les médias (vidéo, audio)

Toute vidéo doit fournir des sous-titres synchronisés (track kind="captions") et idéalement une transcription écrite hébergée sur la même page. WCAG 2.2 critère 1.2.2 l’exige au niveau A. Pour des vidéos en wolof ou bambara, hébergez les sous-titres en français pour ouvrir l’audience aux malentendants francophones de la sous-région.

<video controls>
  <source src="tutoriel.mp4" type="video/mp4">
  <track kind="captions" src="tutoriel-fr.vtt" srclang="fr" label="Français" default>
</video>

Le bon résultat se reconnaît à est un toggle de sous-titres opérationnel et un fichier .vtt synchrone à la seconde près.

Étape 11 : penser aux utilisateurs sur réseau lent

Au-delà du handicap, l’accessibilité couvre les contextes : un utilisateur en 3G à Ziguinchor avec un téléphone d’entrée de gamme. Mesurez votre page sur Chrome DevTools en mode « Slow 4G » et « 4× CPU slowdown ». Visez moins de 200 Ko de JavaScript critique et un Largest Contentful Paint sous 4 secondes.

npx lighthouse https://votre-site.tld \
   --throttling.cpuSlowdownMultiplier=4 \
   --only-categories=performance,accessibility

Indicateur que tout est en place est un score Lighthouse Performance et Accessibility tous deux supérieurs à 90 sur mobile. Cette double exigence pousse à servir un contenu lisible immédiatement, même si une animation tarde à charger.

Étape 12 : former l’équipe

L’accessibilité ne tient que si toute la chaîne (design, dev, contenu) la porte. Organisez une session trimestrielle d’une heure : un audit en direct, un test au lecteur d’écran, une revue d’un pull request. Documentez la convention dans un fichier ACCESSIBILITY.md à la racine du dépôt — checklist courte avant chaque merge. C’est ce qui transforme l’accessibilité d’un sujet ponctuel en réflexe d’équipe partagé entre Dakar et Abidjan.

Étape 13 : suivre les nouveautés WCAG 2.2

WCAG 2.2 a ajouté neuf critères, dont 2.4.11 Focus Not Obscured (le focus ne doit pas être masqué par une bannière collante) et 3.3.8 Accessible Authentication (ne pas exiger de mémorisation cognitive lourde pour se connecter). Relisez chaque trimestre la checklist officielle du W3C et confrontez-la à votre site. Cette veille tient en quinze minutes par trimestre et évite les régressions silencieuses qui pénalisent à la fois les utilisateurs et la conformité légale en zone UEMOA.

Étape 14 : publier votre déclaration d’accessibilité

Une page /accessibilite rend visible l’engagement et facilite le retour des utilisateurs. Indiquez votre niveau de conformité (partielle, totale), les points connus en cours de correction, et un email de contact dédié. Cette transparence rassure et oriente les signalements vers un canal unique, plutôt que de noyer les retours dans un formulaire générique.