Accessibilité web et WordPress : rendre votre site utilisable par tous

Vous avez investi du temps et de l’argent dans votre site WordPress. Le design est clean, les contenus sont travaillés, le SEO est en place… mais avez-vous pensé aux 12 millions de Français en situation de handicap ? 🤔

L’accessibilité web, c’est un sujet que je vois systématiquement négligé sur les projets WordPress que j’audite. Et pourtant, au-delà de l’aspect humain (qui devrait suffire à convaincre), c’est aussi un levier SEO puissant et, de plus en plus, une obligation légale. En tant que développeur freelance WordPress, c’est un réflexe que j’ai intégré dans chacune de mes intégrations depuis plusieurs années maintenant.

Dans cet article, je vous explique concrètement ce que ça implique pour votre site WordPress, ce que la loi exige, et surtout comment on met ça en place sans tout refaire de zéro.

L’accessibilité web, c’est quoi exactement ? ♿

L’accessibilité web (souvent abrégée « a11y » dans le jargon dev — il y a 11 lettres entre le « a » et le « y » d’accessibility 🤓), c’est le fait de rendre un site utilisable par le plus grand nombre de personnes possible, y compris celles en situation de handicap.

On parle de handicaps visuels (cécité, malvoyance, daltonisme), auditifs (surdité), moteurs (impossibilité d’utiliser une souris), cognitifs (dyslexie, troubles de l’attention)… et aussi de situations temporaires. Vous vous êtes déjà cassé le poignet ? Essayez de naviguer sur un site uniquement au clavier, vous allez vite comprendre le problème 😬

Concrètement, un site accessible c’est un site où :

• Chaque image a un texte alternatif descriptif pour les lecteurs d’écran
• Les contrastes de couleurs sont suffisants pour être lisibles
• La navigation au clavier fonctionne intégralement (pas besoin de souris)
• Les formulaires sont étiquetés correctement avec des labels
• La structure HTML est sémantique (titres hiérarchisés, landmarks ARIA…)
• Les vidéos ont des sous-titres et les contenus audio une transcription

Ça vous paraît basique ? Pourtant, d’après une étude WebAIM de 2025, 96% des pages d’accueil des sites les plus visités présentent au moins une erreur d’accessibilité. Oui, 96% 😩

Ce que dit la loi en France : RGAA et obligations légales 📜

En France, l’accessibilité web n’est pas juste « sympa à avoir ». Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) impose des règles précises, basées sur les standards internationaux WCAG 2.1.

Qui est concerné ?

• Les services publics : obligation totale depuis 2012 (et pourtant, beaucoup sont encore à la traîne…)
• Les entreprises privées avec un CA > 250 millions d’euros : obligation depuis 2020
• Et bientôt tout le monde : la directive européenne sur l’accessibilité (European Accessibility Act) entre en application en juin 2025, élargissant les obligations aux sites e-commerce, services bancaires, transport, etc.

Les sanctions ? Jusqu’à 50 000 € pour les grandes entreprises qui ne respectent pas les obligations. Et même si votre PME n’est pas encore directement concernée par la loi, l’évolution est claire : l’accessibilité web va devenir la norme, pas l’exception. Autant prendre le train maintenant plutôt que de courir derrière dans 2 ans 🚂

Accessibilité et SEO : les deux faces d’une même médaille 🎯

Ce que beaucoup de gens ne réalisent pas, c’est que l’accessibilité et le SEO technique partagent énormément de bonnes pratiques. Google est, d’une certaine façon, le plus grand utilisateur aveugle du web — son robot ne « voit » pas votre site, il le lit.

Voici ce que l’accessibilité apporte directement à votre référencement :

• Les textes alternatifs des images aident Google à comprendre vos visuels (et apparaître dans Google Images)
• Une structure HTML sémantique (h1, h2, h3 bien hiérarchisés) facilite le crawl et améliore la compréhension de vos pages
• Les transcriptions de vidéos ajoutent du contenu textuel indexable
• Un bon contraste et une lisibilité améliorée réduisent le taux de rebond
• La navigation au clavier garantit une bonne structure de liens internes

J’ai déjà vu des sites gagner des positions simplement en corrigeant leurs balises alt et en restructurant leur balisage HTML. Rien de magique là-dedans — c’est juste que Google récompense les sites bien construits, et un site accessible EST un site bien construit 💪

Les erreurs d’accessibilité les plus fréquentes sur WordPress 🚨

Après des années à auditer des sites WordPress, voici le top des erreurs que je retrouve quasi systématiquement :

1. Les images sans texte alternatif (ou avec un alt inutile)

C’est l’erreur numéro un, de loin. WordPress permet de renseigner l’attribut alt à l’upload de chaque image dans la médiathèque — mais encore faut-il le faire. Et « IMG_20260315_143022.jpg » ou « image1 » ne comptent pas comme du texte alternatif 😅

Un bon texte alternatif décrit ce que l’image apporte au contenu. Si l’image est purement décorative, un alt vide (alt= » ») est la bonne pratique — ça dit au lecteur d’écran « ignore cette image, elle n’apporte rien de sémantique ».

2. Les contrastes insuffisants

Du texte gris clair sur fond blanc, ce fameux « gris design » que les graphistes adorent… c’est peut-être esthétique, mais c’est illisible pour une bonne partie de la population. Le WCAG exige un ratio de contraste minimum de 4.5:1 pour le texte courant et 3:1 pour les grands titres.

Quand je reçois une maquette Figma avec des contrastes insuffisants, je le signale systématiquement au designer. C’est un sujet qu’il vaut mieux régler en amont plutôt que de devoir retoucher toute la charte graphique après coup.

3. Les formulaires sans labels

Un champ de formulaire avec juste un placeholder « Votre email » et aucun <label> associé, c’est un cauchemar pour les lecteurs d’écran. Le placeholder disparaît quand on commence à taper — l’utilisateur ne sait plus ce qu’il est censé remplir. Toujours utiliser des balises <label> avec un attribut for pointant vers l’id du champ.

4. La navigation au clavier impossible

Essayez de naviguer sur votre site uniquement avec la touche Tab. Si vous ne voyez aucun indicateur visuel de focus (le fameux « outline » que beaucoup de dev suppriment par esthétique avec outline: none), c’est un gros red flag. Les utilisateurs qui ne peuvent pas utiliser de souris dépendent entièrement du clavier — et sans focus visible, ils naviguent à l’aveugle.

5. Une hiérarchie de titres anarchique

Passer d’un H1 à un H4 parce que « la taille de police correspondait mieux », c’est une erreur classique. Les titres HTML ont une valeur sémantique, pas seulement stylistique. Un lecteur d’écran utilise la hiérarchie des titres pour permettre à l’utilisateur de naviguer dans la page. Si vos titres sautent des niveaux, c’est comme un livre avec des chapitres numérotés 1, 4, 2, 7 — incompréhensible 📖

Comment je gère l’accessibilité dans mes développements WordPress 🔧

L’accessibilité, ça ne se rajoute pas à la fin comme un vernis. C’est un réflexe qui s’intègre dès le début du développement. Voici comment je procède sur chaque projet :

Un HTML sémantique irréprochable

Quand je développe un thème WordPress custom avec Bedrock et Sage, la base c’est un HTML propre et sémantique. Ça veut dire :

• Des balises <header>, <nav>, <main>, <footer> pour structurer la page
• Des attributs ARIA (role, aria-label, aria-expanded) là où le HTML natif ne suffit pas
• Des <button> pour les actions et des <a> pour les liens — jamais l’inverse
• Un skip-to-content en haut de page pour permettre de sauter directement au contenu principal

C’est la fondation. Si votre HTML est propre, vous avez déjà éliminé la moitié des problèmes d’accessibilité.

Du CSS pensé pour l’inclusion

Que j’utilise du CSS BEM custom (ma préférence sur les gros projets pour sa maintenabilité et ses performances) ou du Tailwind CSS (idéal quand le budget est serré et qu’on veut aller vite), l’accessibilité guide mes choix CSS :

• Des focus states visibles sur tous les éléments interactifs — pas de outline: none sans alternative
• Des tailles de police en rem/em plutôt qu’en px, pour respecter les préférences de zoom de l’utilisateur
• Des media queries prefers-reduced-motion pour désactiver les animations chez les utilisateurs sensibles
• Des media queries prefers-contrast pour renforcer les contrastes quand le système le demande
• Un responsive irréprochable — un site accessible doit fonctionner à 400% de zoom sans perte de contenu

Les blocs Gutenberg accessibles

Bonne nouvelle : l’éditeur Gutenberg de WordPress a fait d’énormes progrès en matière d’accessibilité ces dernières années. Les blocs natifs (paragraphes, titres, listes, images) génèrent un HTML plutôt propre par défaut.

Là où ça se complique, c’est avec les blocs custom et les thèmes builders (Elementor, Divi…). Ces outils ajoutent souvent des couches de <div> inutiles qui polluent la structure sémantique. C’est une des raisons pour lesquelles je développe des blocs Gutenberg sur mesure avec ACF Pro — je maîtrise le HTML généré à 100%, et donc son accessibilité.

Les tests que j’effectue

Avant de livrer un site, je passe systématiquement par :

1. Lighthouse (intégré à Chrome DevTools) — score d’accessibilité, détection automatique des erreurs basiques
2. WAVE (extension navigateur) — analyse détaillée des erreurs et alertes d’accessibilité
3. Navigation clavier manuelle — je parcours tout le site uniquement au clavier (Tab, Enter, Escape, flèches)
4. Test de contraste — vérification des ratios avec des outils comme Colour Contrast Analyser
5. Test avec un lecteur d’écran — VoiceOver sur Mac ou NVDA sur Windows pour vérifier l’expérience réelle

C’est ce combo de tests automatisés + manuels qui fait la différence. Les outils automatiques ne détectent qu’environ 30 à 40% des problèmes d’accessibilité — le reste nécessite un œil humain (ou plutôt une oreille humaine, avec un lecteur d’écran 🎧).

Les outils WordPress pour améliorer l’accessibilité 🛠️

WordPress dispose de plusieurs outils et plugins pour vous aider :

Les thèmes « accessibility-ready »

Le répertoire officiel WordPress propose un tag « accessibility-ready » pour filtrer les thèmes qui ont passé une revue d’accessibilité. C’est un bon point de départ si vous utilisez un thème du répertoire. Mais attention — « accessibility-ready » ne veut pas dire « 100% accessible ». C’est une base, pas une garantie.

Sur un développement custom (ce que je fais au quotidien), la question ne se pose pas : l’accessibilité est intégrée dès la première ligne de code du thème.

Les plugins utiles

• WP Accessibility : corrige certains problèmes courants (skip links, suppression des attributs title inutiles, gestion du outline)
• Sa11y : outil de vérification d’accessibilité directement dans l’interface admin WordPress — parfait pour les rédacteurs
• Yoast SEO : vérifie la présence des textes alternatifs dans l’analyse de contenu

Cela dit, je ne suis pas fan de la philosophie « on installe un plugin d’overlay d’accessibilité et c’est réglé ». Ces widgets qui ajoutent un petit bonhomme en bas de page avec des options de contraste et de taille de texte… c’est du pansement sur une jambe cassée. L’accessibilité, ça se fait dans le code, pas dans une surcouche JavaScript 🩹

Accessibilité et e-commerce WordPress (WooCommerce) 🛒

Si vous avez une boutique WooCommerce, l’accessibilité est encore plus critique. Pourquoi ? Parce que l’European Accessibility Act cible spécifiquement les sites e-commerce. Et surtout, parce qu’un tunnel d’achat inaccessible, c’est des ventes perdues — point final.

Les points d’attention spécifiques au e-commerce :

• Les filtres produits doivent être utilisables au clavier
• Le panier et le checkout doivent annoncer les changements de prix via des régions ARIA live
• Les images produits nécessitent des alt descriptifs (pas juste « Photo produit »)
• Les messages d’erreur des formulaires doivent être liés aux champs concernés et annoncés aux lecteurs d’écran
• Le sélecteur de quantité doit avoir des labels explicites

WooCommerce a fait des progrès, mais il reste du travail. Quand je développe une boutique en ligne, je teste systématiquement le parcours d’achat complet au clavier et au lecteur d’écran.

Un audit d’accessibilité, ça se passe comment ? 🔍

Quand un client me demande un audit incluant un volet accessibilité, voici ma méthode :

1. Scan automatique de l’ensemble du site avec Lighthouse et WAVE — ça donne une première photographie
2. Audit manuel des gabarits principaux : page d’accueil, page interne, article de blog, page contact, et tunnel de conversion le cas échéant
3. Test clavier complet sur chaque gabarit
4. Test lecteur d’écran sur les parcours critiques
5. Vérification du code source : structure HTML, attributs ARIA, hiérarchie de titres
6. Rapport détaillé avec chaque problème classé par criticité (bloquant, majeur, mineur) et la solution technique associée

L’objectif n’est pas de viser la perfection absolue du premier coup (le RGAA compte 106 critères, c’est conséquent), mais de prioriser les corrections qui auront le plus d’impact. Corriger les alt manquants, les contrastes et la navigation clavier, ça couvre déjà 80% des problèmes rencontrés par les utilisateurs en situation de handicap 🎯

Combien ça coûte de rendre un site WordPress accessible ? 💰

La question qui fâche. La réponse honnête : ça dépend (je sais, vous adorez cette réponse 😅).

Si l’accessibilité est intégrée dès la conception du site, le surcoût est minime — de l’ordre de 10 à 15% du budget total. C’est le scénario idéal, et c’est ce que je recommande systématiquement.

Si en revanche il faut rendre accessible un site existant qui n’a pas du tout été pensé pour, ça peut représenter un chantier plus conséquent. On parle potentiellement de :

• Refonte partielle du CSS pour les contrastes et les focus states
• Réécriture de composants JavaScript (menus déroulants, modales, carrousels…)
• Ajout de tous les textes alternatifs dans la médiathèque
• Restructuration du balisage HTML si le thème génère du code non sémantique

C’est pour ça que je martèle ce message : pensez accessibilité DÈS LE DÉPART. C’est comme l’isolation d’une maison — c’est 10 fois moins cher de le prévoir à la construction que de tout casser pour l’ajouter après 🏗️

Les idées reçues sur l’accessibilité web 🙅

Je termine avec quelques mythes que j’entends régulièrement :

« L’accessibilité, c’est moche » — Faux. Un site accessible peut être tout aussi beau qu’un site « normal ». Apple.com est un modèle d’accessibilité, et personne ne va dire que leur site manque de style.

« Ça concerne très peu de gens » — Faux. 15% de la population mondiale vit avec un handicap. Et on ne parle même pas des situations temporaires (bras dans le plâtre, migraine, environnement bruyant, écran en plein soleil…). L’accessibilité bénéficie à TOUT le monde.

« Un plugin d’accessibilité suffit » — Archifaux. Les overlays d’accessibilité (AccessiBe, UserWay…) sont critiqués par la communauté handicap elle-même. Ils ne résolvent pas les vrais problèmes de code et créent parfois de nouveaux bugs. L’accessibilité se fait dans le code source, pas dans une surcouche.

« WordPress n’est pas accessible » — Nuancé. Le cœur de WordPress est plutôt bien pensé côté accessibilité (il y a une équipe dédiée). Le problème vient souvent des thèmes et plugins tiers mal développés. D’où l’intérêt de travailler avec un développeur qui maîtrise le sujet 😉

FAQ — Accessibilité web et WordPress

Mon site WordPress est-il obligé d'être accessible ?

Ça dépend de votre structure. Les services publics et les grandes entreprises (CA > 250M€) sont déjà soumis au RGAA. Avec l'European Accessibility Act (juin 2025), les sites e-commerce et de nombreux services numériques seront aussi concernés. Même si vous n'êtes pas encore légalement obligé, c'est un investissement malin : meilleur SEO, plus large audience, et anticipation de la réglementation.

Quel est le niveau d'accessibilité à viser (A, AA, AAA) ?

Le standard recommandé (et exigé par le RGAA) est le niveau AA du WCAG 2.1. C'est le bon compromis entre accessibilité et faisabilité. Le niveau AAA est idéal mais très contraignant — il est rarement exigé en totalité. Viser le AA, c'est déjà couvrir l'immense majorité des besoins des utilisateurs en situation de handicap.

Les thèmes WordPress premium (Divi, Avada, Elementor) sont-ils accessibles ?

En général, pas suffisamment. Ces thèmes privilégient la flexibilité visuelle au détriment du HTML sémantique. Ils ajoutent souvent des couches de divs inutiles, des attributs ARIA incorrects, et des composants JavaScript non accessibles au clavier. Pour un site véritablement accessible, un thème custom développé sur mesure reste la meilleure option.

Comment tester rapidement l'accessibilité de mon site WordPress ?

Trois tests rapides : 1) Ouvrez Chrome DevTools et lancez un audit Lighthouse (onglet Accessibility). 2) Installez l'extension WAVE et scannez votre page. 3) Naviguez sur votre site uniquement au clavier (Tab pour avancer, Shift+Tab pour reculer, Enter pour valider). Si un de ces trois tests révèle des problèmes, un audit approfondi est recommandé.

L'accessibilité ralentit-elle les performances de mon site ?

Au contraire ! Un site accessible est généralement plus performant : HTML sémantique plus léger, moins de JavaScript superflu, images optimisées avec des alt descriptifs. Les bonnes pratiques d'accessibilité convergent naturellement avec les bonnes pratiques de performance web.

Puis-je rendre mon site existant accessible sans le refaire entièrement ?

Oui, dans la plupart des cas. On procède par un audit qui identifie les problèmes classés par criticité, puis on corrige par ordre de priorité. Corriger les textes alternatifs, les contrastes, les labels de formulaires et la navigation clavier couvre déjà 80% des problèmes. Une refonte complète n'est nécessaire que si le thème génère un HTML fondamentalement non sémantique.