L’accessibilité sur WordPress

L’accessibilité WordPress, qu’est ce que c’est ? L’accessibilité consiste à rendre les contenus et services web utilisables par tous les publics, y compris les personnes en situation de handicap.

Introduction à l’accessibilité web

L’accessibilité d’un site internet est importante pour vos clients et pour vous.

D’une part, elle répond à des exigences légales comme le RGAA en France (Référentiel Général d’Amélioration de l’Accessibilité), les WCAG du W3C (Web Content Accessibility Guidelines) ou encore la Section 508 aux États-Unis ; d’autre part, elle améliore l’expérience utilisateur pour l’ensemble des visiteurs.

Un site accessible est souvent mieux structuré, plus clair, et plus facile à utiliser, ce qui bénéficie à tous les utilisateurs.

Enjeux de société et business

Au-delà de l’obligation légale, l’accessibilité numérique est une obligation morale.

Dans un contexte où 15 % de la population mondiale vit avec un handicap, offrir un web inclusif est une démarche de responsabilité sociétale (RSE) forte.

Les entreprises compétitives l’ont compris : investir dans l’accessibilité élargit l’audience potentielle et renforce l’image de marque.

Par exemple, en France seuls 1 % des sites sont totalement conformes RGAA.

S’engager dans l’accessibilité offre donc un avantage concurrentiel notable.

Cela améliore aussi le SEO car un site bien codé et structuré a de meilleures chances d’être bien référencé.

Agence WordPress Harsene : votre allié accessibilité

Nous accompagnons les entreprises dans cette démarche d’accessibilité pour leur site internet WordPress.

Grâce à notre expertise WP, Harsene vous aide à auditer, mettre en conformité et maintenir vos sites vitrine et e-commerce. L’objectif est que votre site respecte la loi en vigueur et offre une expérience utilisateur optimale à tous les visiteurs.

Bénéficiez d’un accompagnement pour intégrer l’accessibilité sur WordPress dès la conception ou pour améliorer un site existant.

Cadre technique de l’accessibilité web

Créer un site accessible implique de respecter un ensemble de critères techniques rigoureux.

Principaux aspects techniques à respecter en accessibilité web

• Structure HTML sémantique : Utiliser les balises HTML conformément à leur sémantique. Par exemple, les titres <h1> ... <h6> doivent former une hiérarchie logique sans sauter de niveau de titre (pas de <h3> sans <h2> le précédant). Chaque page doit posséder un <h1> unique et significatif.
• Rôles ARIA et zones repères : Les landmarks ARIA permettent de structurer la page pour les technologies d’assistance. Des éléments comme <header role="banner">, <nav role="navigation"> ou <main role="main"> aident les lecteurs d’écran à comprendre l’organisation du contenu. Il faut aussi prévoir des liens d’évitement (ex. un lien « Aller au contenu principal ») pour faciliter la navigation clavier et permettre aux utilisateurs de passer directement au contenu.
• Navigation au clavier & focus : Tout contenu interactif doit être accessible via le clavier (navigation à la touche Tabulation). Il est crucial de rendre le focus visible : l’élément actuellement sélectionné par le clavier doit être mis en évidence à l’écran (par un contour ou un soulignement apparent). On évitera de supprimer les styles de focus par défaut pour des raisons esthétiques sans fournir une alternative adaptée, car cela empêcherait les utilisateurs clavier de savoir où ils se trouvent sur la page.
• Contrastes et lisibilité : Les textes et éléments graphiques doivent présenter un contraste suffisant par rapport à leur arrière-plan. Les WCAG 2.1 recommandent un ratio de contraste d’au moins 4.5:1 pour le texte normal et 3:1 pour les textes de grande taille (au moins 24 px). Par exemple, un texte gris clair sur fond blanc risque d’être illisible : un contraste insuffisant est l’erreur la plus fréquente en accessibilité web d’après de nombreuses études. Astuce pour les graphistes : utilisez des outils comme le Contrast Checker de WebAIM pour tester vos couleurs.
• Images et alternatives (balises alt) : Chaque image porteuse d’information doit avoir un attribut alt descriptif. Si l’image est purement décorative, l’alt peut rester vide (alt=""). Il est important de décrire l’image en fonction du contexte : par exemple, l’alt d’un bouton contenant une image doit décrire la fonction du bouton (ex. alt="Rechercher" si c’est une loupe de recherche). Les arrière-plans décoratifs via CSS n’ont pas d’alt, mais attention à ne pas y inclure de texte important car il ne serait pas lu par un lecteur d’écran.
• Formulaires et labels : Tous les champs de formulaire doivent être associés à une étiquette explicite. La méthode recommandée est d’utiliser <label for="champ"> lié à l’id du champ correspondant. Si, pour des raisons esthétiques, le label visible est omis, il doit être présent dans le code d’une manière cachée visuellement (par CSS, ex. classe .visually-hidden) afin que les lecteurs d’écran puissent tout de même l’annoncer. Évitez d’utiliser uniquement le placeholder comme label : les placeholders disparaissent lorsque l’utilisateur saisit le texte et peuvent semer la confusion.
• Liens cohérents : Fournir des intitulés explicites pour chaque lien en évitant les « cliquez ici » et indiquez si un lien ouvre une nouvelle fenêtre.
• Autres éléments techniques : Veiller à la validité du code HTML (passez le validateur W3C), à l’utilisation correcte des listes, tableaux (fournir des en-têtes via <th> pour les tableaux de données) et au bon usage des éléments multimédia (sous-titres pour les vidéos, transcription pour les podcasts, etc.).

L’expertise de Harsene pour auditer l’accessibilité

Harsene dispose d’une équipe formée aux outils d’audit et réalise pour vous une vérification exhaustive de l’accessibilité de votre WordPress.

L’intérêt de passer par une agence WordPress est de combiner tests automatisés et audits manuels, puis de vous proposer un plan d’action clair.

Harsene peut par exemple exécuter un audit initial avec WAVE et Lighthouse, puis approfondir manuellement (test au clavier, à la voix, etc.).

Vous gagnez du temps tout en étant sûr d’atteindre la conformité légale et un excellent niveau de qualité.

Toutes ces recommandations se basent sur des normes mises en place par des organismes internationaux.

Les normes d’accéssibilité

Les normes d’accessibilité sont des directives et des recommandations conçues pour garantir que les produits, services et environnements sont accessibles à toutes les personnes, y compris celles ayant des handicaps.

Voici un aperçu des principales normes d’accessibilité :

Web Content Accessibility Guidelines (WCAG)

• WCAG 2.0/2.1/2.2 : Ces directives fournissent des recommandations pour rendre le contenu web plus accessible. Elles sont organisées autour de quatre principes : perceptible, utilisable, compréhensible et robuste. Chaque principe comporte des lignes directrices et des critères de succès qui peuvent être testés
• Niveaux de Conformité : Les WCAG ont trois niveaux de conformité : A (le plus bas), AA et AAA (le plus haut). Chaque niveau inclut des critères de succès qui doivent être satisfaits pour atteindre ce niveau de conformité

Authoring Tool Accessibility Guidelines (ATAG)

Egalement connu sous l’acronyme ATAG 2.0.

Ces directives fournissent des recommandations pour les outils de création de contenu web, afin de rendre ces outils eux-mêmes accessibles et d’encourager la création de contenu accessible.

Les ATAG se concentrent sur la production de contenu accessible et la prise en charge des auteurs dans cette tâche

Accessible Rich Internet Applications (ARIA)

ARIA et WAI-ARIA sont des outils essentiels pour les développeurs web qui cherchent à créer des applications accessibles.

Ils permettent d’améliorer l’interaction des utilisateurs avec les technologies d’assistance en fournissant des informations supplémentaires sur les éléments interactifs et dynamiques des pages web.

ARIA (Accessible Rich Internet Applications)

• Objectif : ARIA fournit des moyens pour améliorer l’accessibilité des contenus web dynamiques en permettant aux développeurs d’ajouter des attributs supplémentaires aux éléments HTML. Ces attributs fournissent des informations supplémentaires aux technologies d’assistance, comme les lecteurs d’écran, sur le rôle, l’état et les propriétés des éléments interactifs.
• Utilisation : ARIA est particulièrement utile pour les applications web modernes qui utilisent beaucoup de JavaScript pour créer des interfaces utilisateur interactives. Par exemple, ARIA peut être utilisé pour définir des rôles comme « button », « dialog », ou « menu », et des états comme « hidden », « disabled », ou « checked ».

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)

• Contexte : WAI-ARIA est une spécification développée par le Web Accessibility Initiative (WAI) du W3C. Elle fait partie des directives WCAG (Web Content Accessibility Guidelines) et fournit un cadre pour rendre les applications web riches plus accessibles.
• Rôles et Propriétés : WAI-ARIA définit des rôles, des états et des propriétés qui peuvent être ajoutés aux éléments HTML pour améliorer l’accessibilité. Par exemple, le rôle « alert » peut être utilisé pour indiquer qu’un message important doit être communiqué à l’utilisateur, tandis que la propriété « aria-live » peut être utilisée pour indiquer que le contenu d’un élément sera mis à jour dynamiquement.

Intégration avec WCAG

• Conformité : L’utilisation de WAI-ARIA est souvent nécessaire pour se conformer aux critères de succès des WCAG, en particulier ceux qui concernent l’accessibilité des contenus dynamiques et interactifs. Par exemple, le critère de succès 4.1.2 (Name, Role, Value) des WCAG 2.1 exige que les technologies d’assistance puissent déterminer le rôle, l’état et les valeurs des éléments interactifs.
• Meilleures Pratiques : Les développeurs sont encouragés à utiliser WAI-ARIA pour compléter les éléments HTML natifs et fournir des informations supplémentaires aux technologies d’assistance. Cela permet de créer des interfaces utilisateur plus inclusives et accessibles.

Section 508 (États-Unis)

Cette loi américaine « Section 508 » exige que les technologies de l’information et de la communication (TIC) utilisées par le gouvernement fédéral soient accessibles aux personnes handicapées.

Elle inclut des exigences spécifiques pour les logiciels, le matériel, le contenu web et les documents électroniques

Americans with Disabilities Act (ADA)

Cette loi américaine « ADA » interdit la discrimination à l’encontre des personnes handicapées dans tous les domaines de la vie publique, y compris les emplois, les transports et toutes les zones ouvertes au public.

Elle inclut des exigences pour l’accessibilité des bâtiments, des services et des communications

European Accessibility Act (EAA)

Cette directive de l’Union européenne « EAA » vise à améliorer l’accessibilité des produits et services pour les personnes handicapées.

Elle couvre une large gamme de produits et services, y compris les TIC, les services bancaires et les transports

Ces normes et directives sont essentielles pour garantir que les environnements numériques et physiques sont inclusifs et accessibles à tous.

Spécificités de WordPress en matière d’accessibilité

WordPress est l’un des CMS les plus utilisés au monde. Et qu’en est-il de son accessibilité ?

En natif, WordPress fournit une base technique capable d’être accessible, mais tout dépend de la manière dont le site est construit. Voici les points à connaître.

Thèmes « accessibility-ready »

La communauté WordPress propose de nombreux thèmes marqués « prêts pour l’accessibilité » ou « Ready for Accessibility ». C’est toujours plus marketing en anglais 😉

Ces thèmes respectent généralement les WordPress Accessibility Coding Standards (visant une conformité WCAG 2.0 AA comme vu précédemment).

Ils intègrent, par exemple, des liens d’évitement, des contrastes suffisants, une navigation clavier, etc.

Si vous démarrez avec un theme WordPress, choisir un thème accessible dès le départ vous évite de corriger des problèmes plus tard.

Éditeur Gutenberg

Introduit en 2018, l’éditeur de blocs Gutenberg a suscité des débats sur son accessibilité.

De nombreux problèmes d’accessibilité avaient été relevés par un audit WPCampus sur l’accessibilité de Gutemberg.

Depuis, l’équipe WordPress a corrigé une grande partie de ces points, mais cela rappelle que l’accessibilité du back-office (interface d’édition) est aussi importante, surtout si des contributeurs en situation de handicap doivent gérer le site.

Plugins et constructeurs de pages

L’écosystème WordPress compte plus de 60 000 plugins.

Or, un plugin mal conçu peut introduire des éléments non accessibles (un formulaire sans labels, un slider non navigable au clavier, etc.).

De même, les constructeurs de pages (Elementor, Divi, WPBakery…) génèrent leur propre HTML et leur qualité d’accessibilité varie.

Les meilleurs constructeurs améliorent régulièrement leur conformité en se basant sur les retours de la communauté.

Forces et faiblesses natives de WP

WordPress lui-même respecte l’ATAG (Authoring Tool Accessibility Guidelines) dans son interface admin autant que possible, mais n’atteint pas encore la perfection.

Du côté du front-office (le site visible par l’utilisateur final), tout est entre les mains du développeur et du choix du thème/plugin.

Un point fort : WordPress fournit des fonctions API pour l’accessibilité (par ex., la fonction the_content traite correctement certains éléments, et les menus ou widgets par défaut sont généralement au propre).

Un point faible : l’ajout incontrôlé de plugins peut vite dégrader la qualité du code.

Accessibilité WordPress facile avec le plugin Ally

Une façon rapide d’améliorer l’accessibilité d’un site WordPress consiste à utiliser un plugin dédié.

Parmi les quelques plugins existants, « Ally – Web Accessibility & Usability », anciennement connu sous le nom de One Click Accessibility, se démarque par son approche tout-en-un.

Développé par l’équipe d’Elementor, Ally agit comme un widget d’accessibilité que les visiteurs peuvent utiliser pour personnaliser l’affichage selon leurs besoins.

One Click Accessibility était un plugin populaire pour ajouter quelques outils (changer la taille du texte, contrastes, etc.).

Elementor a repris et étendu ce plugin sous le nom Ally afin d’offrir une solution plus complète.

Il est bien intégrée aux sites réalisés avec Elementor et fonctionne avec n’importe quel site autre WordPress (pas besoin d’utiliser Elementor pour l’employer).

Cette approche entre dans la nouvelle stratégie d’Elementor a diversifier ses sources de revenus en proposant des outils complémentaires à Elementor.

Explication du nom « ally »

Le lien entre « ally » et l’accessibilité web est direct. « ally » est une évolution de « a11y », le raccourci pour le mot « accessibility » dans le contexte du numérique et du web.

• « a11y » est une forme abrégée de « accessibility », formée selon le principe de l’abbreviation numérique : on garde la première lettre (« a ») et la dernière (« y ») du mot, et on remplace les 11 lettres entre les deux par le chiffre 11.
• C’est comme « i18n » pour internationalization.

Fonctionnalités principales d’Ally

Ce plugin offre deux volets : des options pour les créateurs du site (configuration du widget) et des options pour les visiteurs (outils d’accessibilité utilisables).

• Côté administrateur (configuration) :
  • Affichage du widget : choisir l’icône du bouton d’accessibilité (plusieurs symboles disponibles, par ex. l’icône standard « fauteuil roulant » ♿️), sa taille (petit, moyen, grand), sa position à l’écran (coin en bas à droite par défaut, mais ajustable sur les 4 coins) et ses couleurs pour qu’il s’intègre au design du site. Vous pouvez aussi décider d’afficher ou non l’icône sur mobile et/ou desktop.
  • Déclaration d’accessibilité : ajouter un lien vers une page « Accessibilité » du site ou même utiliser le générateur intégré pour créer automatiquement votre déclaration d’accessibilité (obligatoire pour les sites publics dans de nombreux pays). Ce générateur vous guide pour remplir les informations légales requises.
  • Autres réglages : possibilité de définir un lien vers le plan du site (sitemap) dans le widget, d’activer/désactiver certaines fonctionnalités pour les visiteurs.
• Côté utilisateur (widget sur le site) :
  • Modifier la taille du texte : augmenter ou diminuer la police pour améliorer la lisibilité pour les personnes malvoyantes ou ayant des difficultés de lecture.
  • Changer les contrastes / couleurs : Ally propose un mode niveaux de contraste (contraste élevé, contraste inversé, tons gris, etc.) pour aider les personnes daltoniennes ou avec basse vision.
  • Police lisible (Readable Font) : remplacement de la police par une police sans empattement plus lisible, utile notamment pour les personnes dyslexiques.
  • Souligner les liens (Links Underline) : rend tous les liens soulignés pour qu’ils soient facilement distinguables du texte normal.
  • Guide de lecture et curseur : possibilité d’afficher un guide de lecture (une ligne ou un curseur agrandi suivant la souris) pour aider au suivi du texte.
  • Espacement du texte : ajuster l’espacement des lignes (line-height) pour plus de confort.
  • Alignement du texte : le visiteur peut aligner le texte différemment (gauche, centré, droite) selon ses préférences.
  • Masquer les images : cacher toutes les images du site pour éviter les distractions ou améliorer la concentration sur le texte.
  • Pause des animations : stopper les animations/mouvements (ex. carrousels, GIFs) pour ne pas déranger les personnes sensibles ou neuroatypiques.
  • Sitemap / Table des matières : afficher une liste structurée des en-têtes de la page et des zones ARIA (pratique pour se faire une vue d’ensemble et naviguer rapidement).
  • Raccourcis clavier : le widget inclut un lien « Skip to main content » (Aller au contenu) qui apparaît dès qu’on Tabule sur la page, permettant de sauter les menus. D’autres raccourcis peuvent être configurés selon le besoin.
  • Reset : un bouton pour restaurer les paramètres par défaut si l’utilisateur a fait plusieurs ajustements.

Il est important de noter qu’Ally n’est pas une baguette magique qui rend un site conforme à lui seul.

D’ailleurs, Elementor le précise : « Le plugin Ally n’est pas un substitut à un audit d’accessibilité approfondi et ne rendra pas votre site automatiquement conforme à la loi ».

C’est un complément utile : il améliore l’expérience utilisateur et comble certaines lacunes pour l’utilisateur final, mais il ne corrige pas le code source de votre site. Par exemple, si vos images n’ont pas d’attribut alt, Ally ne pourra pas les deviner ; si vos liens sont mal nommés, le problème restera.

En revanche, pour un site déjà correctement développé, Ally apporte un plus en offrant des options d’accessibilité personnalisées à chaque visiteur et un accès facile à la déclaration d’accessibilité.

Configuration de Ally par l’agence WordPress Harsene

Harsene intègre souvent Ally dans ses projets :

• Harsene va configurer Ally en adéquation avec le design du site (choix de l’icône, couleur respectant la charte graphique tout en restant visible, position judicieuse qui n’empiète pas sur d’autres éléments).
• Harsene teste la compatibilité d’Ally avec les autres composants du site (notamment si votre site utilise Elementor ou d’autres plugins : s’assurer qu’il n’y a pas de conflit d’affichage ou de performances).
• Selon les besoins du client, Harsene peut désactiver des options non pertinentes d’Ally pour épurer le widget et ne montrer que celles utiles à vos utilisateurs cibles.

Accessibilité WordPress avancée

Soyons honnête, c’est clairement compliqué et couteux !

Mais si vous souhaitez relevé un défi ou qu’un projet l’impose, voici une approche holistique sur WordPress :

• En amont du projet : choisir un thème accessible et planifier l’accessibilité (cahier des charges incluant le respect du RGAA/WCAG). Et sélectionner des plugins éprouvés en accessibilité (par exemple, pour un formulaire, choisir un plugin qui gère correctement les labels et erreurs).
• Pendant le développement : tester à chaque ajout de fonctionnalité ou de plugin. Configurer ces plugins correctement (parfois l’accessibilité dépend d’options à activer).
• Recette et audit final : vérifier la conformité avant mise en ligne (avec la checklist et les outils mentionnés). Et effectuer un nettoyage de code : supprimer les éléments inutiles, éviter les balises redondantes générées par certains constructeurs, etc. Si nécessaire, ajouter une couche de correctifs (par exemple via du JavaScript ou du CSS) pour pallier une petite lacune d’un plugin tiers, en attendant mieux.
• Back-office : Si le client en a besoin, s’assurer que l’interface de gestion soit utilisable (ex : champs de custom fields correctement étiquetés, éditeur convenable).
• Formation : former les équipes à publier des contenus accessibles (rappel sur la rédaction des alt, l’usage des titres, etc.).

Abordons maintenant le comment faire : voici un guide étape par étape pour améliorer l’accessibilité d’un site WordPress, en mettant en avant comment Harsene peut vous assister à chaque phase.

Étape 1 : Audit initial et installation du plugin Ally

Avant d’installer quoi que ce soit, il faut évaluer l’existant.

On commence généralement par un audit rapide : utilisation de WAVE ou Lighthouse pour repérer les erreurs courantes (contrastes, images sans alt, structure de titres…) et parcourir le site au clavier.

Cette vue d’ensemble permet de cibler les points faibles.

Une fois l’audit de base fait, installez et configurez le plugin Ally depuis le répertoire WordPress (recherchez « Ally – Web Accessibility » dans l’onglet Extensions).

Étape 2 : Vérification de la structure HTML et des rôles ARIA

Après Ally installé (il apporte du confort utilisateur), retour au cœur du site : son code.

Il s’agit de vérifier que la structure HTML est saine et que les rôles ARIA sont utilisés à bon escient.

• Titres et structure : Parcourez vos pages principales et vérifiez l’ordre des titres (<h1>, <h2>, etc.). Si vous utilisez un constructeur, assurez-vous qu’il n’a pas généré par erreur plusieurs <h1> ou sauté de niveaux. Un outil pratique est l’extension HeadingsMap (Chrome/Firefox) qui affiche la hiérarchie des titres d’une page.
• Landmarks ARIA : Passez en revue le code source ou utilisez un inspecteur de DOM pour vérifier la présence de repères comme <nav role="navigation">, <main role="main">, <footer role="contentinfo">, etc. Si votre thème ne les a pas, envisagez de mettre à jour le code.
• Labels et formulaires : Identifiez tous les formulaires (contact, recherche, commentaires…). Assurez-vous via le code HTML ou WAVE que chaque champ a son label correctement lié. Ally ne règle pas ça : c’est à faire manuellement.
• Attributs alt sur images : À l’étape précédente, l’outil WAVE a dû vous signaler les images sans alt. Parcourez la médiathèque et les pages : ajoutez des textes alternatifs pertinents à toutes les images informatives.
• Focus et navigation : Testez la navigation clavier page par page.

Étape 3 : Analyse approfondie avec les outils d’accessibilité

Une fois la structure et le code nettoyés, il est temps de passer un coup de scanner approfondi.

Ici, on peut utiliser tous les outils en ligne de test d’accessibilité mentionné précédemment.

À l’issue de ces analyses, vous aurez potentiellement une liste de dizaines de points à améliorer. Pas de panique : toutes les erreurs n’ont pas le même impact.

Corrigez en priorité les erreurs bloquantes signalées (ce qui empêche un utilisateur d’accéder à une fonctionnalité, ex. un bouton de soumission de formulaire inaccessible au clavier).

Étape 4 : Tests manuels utilisateur (navigation, lecteurs d’écran…)

Malgré tous les outils du monde, rien ne remplace une session de test en conditions réelles.

Cette étape consiste à se mettre dans la peau de différents utilisateurs et voir si le site répond à leurs besoins :

• Navigation 100 % clavier : Déconnectez votre souris, et tentez d’utiliser le site uniquement au clavier. Pouvez-vous accéder à tous les liens et boutons ? Le menu est-il entièrement navigable (sous-menus compris) via Tab et flèches si menu déroulant ? Le focus se déplace-t-il logiquement et reste-il visible en tout temps ? Essayez de remplir un formulaire sans souris : pouvez-vous sélectionner chaque champ, cocher les cases, soumettre ? Si un élément vous bloque, c’est qu’il y a un problème (par ex., certains composants JS mal gérés ne reçoivent pas le focus).
• Lecteur d’écran : Activez NVDA (sur Windows) ou VoiceOver (sur Mac/iPhone). Parcourez la page en mode lecture linéaire et en mode navigation par titres. Le lecteur d’écran annonce-t-il des choses étranges (par ex. un champ de formulaire sans nom, ou lit-il du texte qui devrait être masqué) ? Assurez-vous que toutes les images sont bien décrites, que les liens ont du sens hors contexte. Testez des interactions : par exemple, si vous ouvrez une fenêtre modale (popup), le lecteur d’écran doit immédiatement « entrer » dedans et non pas continuer à lire l’arrière-plan ; ceci nécessite un focus managé en JS et un aria-modal="true" sur la modale, etc. Ce niveau de détail fait la différence entre un site passable et un site véritablement accessible.
• Scénarios utilisateur variés : Pensez aussi aux utilisateurs malvoyants utilisant un zoom très fort ou une loupe d’écran. Votre site en zoom 400 % est-il encore utilisable sur mobile ? (Le Responsive Web Design bien fait doit aider.) Pensez aux daltoniens : activez des filtres de daltonisme (il existe des extensions ou simplement des paramètres d’accessibilité dans certains OS) pour voir si vos indications par couleur sont toujours compréhensibles. Par exemple, ne pas dire juste « les champs en rouge sont invalides » sans autre indication, car un utilisateur daltonien ne distinguera peut-être pas le rouge.
• Feedback d’utilisateurs réels : Dans l’idéal, faites appel à des utilisateurs en situation de handicap pour tester. Certaines associations ou entreprises proposent ce service (tests utilisateurs encadrés). Un développeur peut penser qu’une page est accessible car « tout marche au clavier », mais un testeur aveugle vous fera peut-être remarquer que la structure de vos titres n’est pas logique du point de vue de la compréhension du contenu. Ce type de retour est inestimable.
• Corrections finales : Suite à ces tests, effectuez les derniers ajustements. Souvent, ce sont de petits détails qui émergent : ajouter un message ARIA live pour signaler la mise à jour dynamique d’un contenu, améliorer le texte d’une étiquette, augmenter légèrement un contraste, etc.

Étape 5 : Mise en ligne, suivi et maintenance régulière

Une fois les étapes précédentes validées, vous pouvez déployer votre site accessible en production (mise en ligne).

Félicitations ! Cependant, le travail ne s’arrête pas là : l’accessibilité est un processus continu, pas un état figé.

• Formation et bonnes pratiques : Si vous livrez le site à un client (ou à des rédacteurs internes), formez-les aux bonnes pratiques : par exemple, penser à remplir l’attribut alt à chaque ajout d’image, ne pas incorporer de vidéos non sous-titrées, respecter les styles prévus pour les titres (ne pas mettre du texte en gros caractères en gras pour simuler un titre, mais utiliser le vrai style de titre).
• Mises à jour de WordPress : Chaque fois que vous ajoutez une nouvelle fonctionnalité ou installez un nouveau plugin, considérez l’impact sur l’accessibilité. Gardez un œil sur les mises à jour de WordPress, du thème et des plugins : les nouvelles versions peuvent corriger des problèmes d’accessibilité, mais parfois aussi en introduire involontairement.
• Audit périodique : Il est recommandé de programmer un audit annuel (ou tous les 6 mois si votre site évolue beaucoup). Les standards peuvent évoluer (WCAG 2.2, 3.0 à l’horizon), de nouvelles pratiques apparaissent.
• Retour utilisateur : Encouragez vos utilisateurs à vous signaler d’éventuels problèmes d’accessibilité via un point de contact (mail ou formulaire) mentionné dans la déclaration d’accessibilité.

En résumé, rendre un site WordPress accessible peut-être un projet dans le projet et très complexe.

Checklist de vérification d’accessibilité sur WordPress

Arrivé au terme de ce parcours, voici une checklist récapitulative des éléments à valider avant de considérer votre site WordPress comme accessible :

ELEMENT	VERIFICATION
Titres (h1-h6)	Hiérarchie correcte, pas de saut de niveau, textes de titres pertinents.
Langue du site	Attribut lang sur <html> (ex. lang="fr"), langages des passages étrangers marqués le cas échéant.
Images	Attributs alt présents et adaptés pour toutes les images informatives. Images décoratives avec alt vide.
Couleurs/Contraste	Ratio ≥ 4.5:1 pour texte normal (AA), ≥ 3:1 pour les gros titres. Vérifier avec un outil de contraste.
Liens	Intitulés explicites (éviter « cliquez ici »), nouvelle fenêtre signalée dans l’attribut ou le texte. Pas de liens vides.
Navigation	Possibilité de naviguer à la Tab dans tout le site. Ordre de tabulation logique. Présence de « Skip link » pour aller au contenu.
Focus visible	Styles de focus bien visibles sur tous les éléments interactifs (boutons, champs, menus…).
Formulaires	Chaque champ a son <label> associé. Boutons de soumission identifiables (ex. type="submit" ou rôle ARIA correct). Messages d’erreur liés aux champs (ex. aria-describedby).
Tables (données)	Utilisation de <th> pour les en-têtes, attributs scope ou technique d’en-têtes associées si tableau complexe.
Multimédia	Vidéos sous-titrées, transcripts disponibles pour l’audio, possibilité de pause pour tout média en mouvement/sonore.
ARIA	Rôles ARIA présents pour structurer (banner, navigation, main, contentinfo…), attributs ARIA utilisés seulement si nécessaire et correctement (pas d’ARIA superflu pouvant perturber).
Contenus dynamiques	Si du contenu apparaît dynamiquement (erreur de formulaire, message de confirmation), utilisation d’aria-live ou focus donné sur ce contenu pour qu’il soit annoncé.
Plugin d’accessibilité	(Si utilisé, ex. Ally) Bien configuré : icône visible, options utiles activées, pas de conflit d’affichage.
Déclaration d’accessibilité	Page dédiée présente, à jour, avec niveau de conformité, date, contact, alternatives possibles.
Tests utilisateurs	Site testé avec un lecteur d’écran, au clavier, et idéalement par un panel d’utilisateurs handicapés. Problèmes relevés corrigés.

Si chaque point de cette checklist est satisfait, votre site est en bonne voie d’être conforme aux normes et, surtout, réellement utilisable par tous.

Outils de test d’accessibilité web

Aucun site ne devrait être mis en ligne sans test d’accessibilité.

Plusieurs outils peuvent détecter une partie des problèmes :

• WAVE (Web Accessibility Evaluation Tool) : une extension navigateur qui affiche directement sur la page les erreurs (icônes et surbrillances) – très utile pour un premier audit visuel.
• aXe : une librairie d’audit d’accessibilité parmi les meilleurs outils au monde.
• Lighthouse : DevTool de Google, alimenté par axe-core (ci-dessus), est une ressource fantastique pour effectuer des audits d’accessibilité et lister les problèmes détectés en même temps que des tests de performance et de référencement (attention, il ne détecte pas tout).
• Contrast Color Checkers : par exemple l’outil de contraste de WebAIM ou des extensions comme Color Contrast Analyzer.
• Validateurs de code HTML/CSS : pour repérer les erreurs techniques qui pourraient impacter l’accessibilité (éléments mal imbriqués, attributs ARIA incorrects, etc.).
• Lecteurs d’écran : testez avec NVDA (Windows) ou VoiceOver (macOS) pour comprendre la lecture audio de votre site. De même, naviguez uniquement au clavier (désactivez votre souris un moment) pour vous assurer que tout est accessible.

Ce qu’il faut retenir de l’accessibilité sur WordPress

• L’accessibilité web est incontournable : que ce soit pour respecter la loi (RGAA, WCAG, EAA…) ou pour offrir une expérience inclusive à 100 % de vos utilisateurs, c’est un investissement gagnant sur le plan humain, marketing et SEO.
• WordPress peut (et doit) être accessible : en choisissant les bons thèmes, plugins et en adoptant les bonnes pratiques de développement, un site WordPress peut se conformer aux standards les plus exigeants. Attention aux thèmes ou builders trop fantaisistes qui négligent l’accessibilité : privilégiez du code propre et sémantique.
• Le plugin Ally est un outil précieux pour ajouter des options d’accessibilité pour vos visiteurs (taille du texte, contraste, etc.) et faciliter la conformité (déclaration d’accessibilité). Il ne remplace pas un travail de fond sur le code, mais en fait partie intégrante.
• Méthodologie par étapes : Suivez un processus clair si vous avez un projet ambitieux pour une grande entreprise ou un gouvernement : audit, corrections, tests, déploiement, formation, maintenance. Ne brûlez pas les étapes et testez dans la peau d’un utilisateur réel.
• Agence WordPress partenaire : Se faire accompagner par une agence WP comme Harsene, c’est assurer la réussite de votre démarche accessibilité. Vous gagnerez du temps, éviterez les pièges et garantirez un résultat de haute qualité pour un web réellement inclusif.

En somme, l’accessibilité d’un site WordPress n’est plus optionnelle ni réservée aux sites institutionnels : c’est un standard de qualité qui profite à tous comme un service de maintenance WordPress.

A présent, vous avez toutes les clés pour rendre votre site accessible à tous les utilisateurs, quelles que soient leurs capacités.

Ensemble, faisons d’internet un espace plus ouvert et accueillant pour chacun.