L’accessibilité web : un impératif éthique, légal et business
L’accessibilité web consiste à concevoir des sites internet utilisables par toutes les personnes, quelles que soient leurs capacités physiques, sensorielles ou cognitives. Cela concerne les personnes aveugles ou malvoyantes qui naviguent avec un lecteur d’écran, les personnes sourdes qui ont besoin de sous-titres, les personnes à mobilité réduite qui utilisent un clavier plutôt qu’une souris, les personnes dyslexiques qui nécessitent des typographies adaptées, et les personnes souffrant de troubles de l’attention qui bénéficient d’interfaces claires et prévisibles.
En France, 12 millions de personnes vivent avec un handicap — soit près de 20% de la population. À l’échelle mondiale, l’OMS estime que 1,3 milliard de personnes (16% de la population) sont en situation de handicap significatif. Ignorer l’accessibilité revient à fermer la porte de votre commerce à un client sur cinq. Au-delà du handicap permanent, l’accessibilité bénéficie aussi aux handicaps temporaires (bras cassé, infection oculaire) et situationnels (écran en plein soleil, environnement bruyant, connexion lente).
L’accessibilité n’est pas uniquement une question d’éthique ou d’inclusion — c’est aussi un avantage commercial et technique. Un site accessible est mieux structuré pour le SEO (Google est lui-même un « utilisateur aveugle » qui lit votre contenu sans voir vos images), offre une meilleure expérience utilisateur pour tous (y compris les personnes sans handicap), et évite les risques juridiques croissants liés à la non-conformité. En 2025, les obligations légales se durcissent significativement avec la transposition de la directive européenne sur l’accessibilité.
WCAG et RGAA : comprendre les référentiels
WCAG : le standard international
Les Web Content Accessibility Guidelines (WCAG), publiées par le W3C (World Wide Web Consortium), constituent le standard international de référence en matière d’accessibilité web. La version actuelle est WCAG 2.2 (publiée en octobre 2023), qui étend WCAG 2.1 avec des critères supplémentaires pour les utilisateurs mobiles et les personnes avec des déficiences cognitives.
Les WCAG s’organisent autour de 4 principes fondamentaux, résumés par l’acronyme POUR :
Perceptible (Perceivable) — L’information et les composants d’interface doivent être présentés de manière à être perçus par tous les utilisateurs. Cela signifie : alternatives textuelles pour les images, sous-titres pour les vidéos, contrastes suffisants pour les textes, et information non transmise uniquement par la couleur.
Opérable (Operable) — Les composants d’interface et la navigation doivent être utilisables. Toute fonctionnalité doit être accessible au clavier, le temps d’interaction doit être suffisant, le contenu ne doit pas provoquer de crises (épilepsie), et la navigation doit être prévisible.
Compréhensible (Understandable) — L’information et l’utilisation de l’interface doivent être compréhensibles. Les textes doivent être lisibles, les pages doivent fonctionner de manière prévisible, et les erreurs de saisie doivent être identifiées et expliquées clairement.
Robuste (Robust) — Le contenu doit être suffisamment robuste pour être interprété par une variété d’agents utilisateurs, incluant les technologies d’assistance. Concrètement : un HTML valide et sémantiquement correct, des attributs ARIA utilisés correctement.
Chaque critère WCAG est évalué selon trois niveaux de conformité :
Niveau A — Le minimum vital. Les obstacles les plus graves sont éliminés. Un site qui ne satisfait pas le niveau A est inutilisable par une grande partie des personnes handicapées.
Niveau AA — Le niveau recommandé et généralement exigé par les législations. Élimine les obstacles majeurs et offre une expérience raisonnablement accessible à la plupart des utilisateurs handicapés. C’est la cible pour la majorité des sites web professionnels.
Niveau AAA — Le plus haut niveau d’accessibilité. Extrêmement strict et souvent impossible à atteindre sur l’intégralité d’un site. Recommandé pour des contenus spécifiques (sites gouvernementaux critiques, services de santé) mais pas comme objectif global.
RGAA : le référentiel français
Le Référentiel Général d’Amélioration de l’Accessibilité (RGAA) est l’adaptation française des WCAG. Sa version actuelle (4.1, mise à jour en 2021) transpose les critères WCAG 2.1 niveau AA en un référentiel opérationnel et testable, organisé en 106 critères répartis dans 13 thématiques.
Les 13 thématiques du RGAA :
1. Images — Alternatives textuelles, images décoratives vs informatives, images complexes (graphiques, cartes).
2. Cadres (iframes) — Titre des cadres, accessibilité du contenu embarqué.
3. Couleurs — Information non transmise uniquement par la couleur, contrastes suffisants.
4. Multimédia — Sous-titres, audiodescription, transcription, contrôles accessibles.
5. Tableaux — Structure sémantique correcte, en-têtes identifiés, résumé quand nécessaire.
6. Liens — Intitulé explicite, distinction des liens, liens identiques ayant la même destination.
7. Scripts — Compatibilité avec les technologies d’assistance, alternatives en cas de désactivation JavaScript.
8. Éléments obligatoires — Langue de la page, titre de page, validité du code, balises utilisées à bon escient.
9. Structuration de l’information — Hiérarchie des titres, listes, citations, zones de regroupement.
10. Présentation de l’information — CSS utilisé pour la mise en forme, visibilité du focus, adaptabilité aux préférences utilisateur.
11. Formulaires — Étiquettes associées aux champs, regroupement logique, aide à la saisie, messages d’erreur.
12. Navigation — Systèmes de navigation cohérents, plan du site, fil d’Ariane, accès rapide au contenu.
13. Consultation — Limite de temps, rafraîchissements, documents téléchargeables accessibles.
La différence pratique entre WCAG et RGAA : le WCAG définit des principes et critères de succès (parfois abstraits), tandis que le RGAA traduit ces critères en tests concrets et vérifiables avec une méthodologie précise. Pour un développeur ou un auditeur français, le RGAA est plus opérationnel au quotidien.
Les obligations légales en France (2025)
Le cadre légal français en matière d’accessibilité web s’est considérablement renforcé ces dernières années :
Qui est obligé ? — Depuis la loi du 11 février 2005 et le décret du 24 juillet 2019, l’obligation de conformité RGAA s’applique à : tous les services publics (État, collectivités, établissements publics), les entreprises dont le chiffre d’affaires excède 250 millions d’euros, et depuis juin 2025 (transposition de la directive européenne EAA — European Accessibility Act), les services numériques de commerce électronique, les services bancaires, les transports, et les télécommunications.
Sanctions en cas de non-conformité — Amende annuelle de 20 000€ pour les services publics non conformes (et 50 000€ pour le secteur privé soumis à l’obligation à partir de 2025). Obligation d’afficher une déclaration d’accessibilité sur le site, avec le niveau de conformité actuel et un plan d’action pour corriger les non-conformités. Les utilisateurs peuvent saisir le Défenseur des droits en cas de refus de mise en conformité.
Et les TPE/PME ? — En 2025, les TPE et PME classiques ne sont pas directement soumises à l’obligation légale du RGAA (sauf si elles vendent en ligne des produits/services couverts par l’EAA). Cependant, la tendance est clairement à l’élargissement : les marchés publics exigent de plus en plus la conformité des sous-traitants, les grandes entreprises imposent l’accessibilité à leurs prestataires, et la jurisprudence européenne tend vers une obligation universelle. Se mettre en conformité maintenant, c’est anticiper une obligation qui arrivera inévitablement.
Les problèmes d’accessibilité les plus courants (et comment les corriger)
Images sans alternative textuelle
C’est le défaut d’accessibilité le plus fréquent sur le web — et le plus simple à corriger. Chaque image qui transmet une information doit avoir un attribut alt descriptif. Un lecteur d’écran lit cet attribut alt à la personne aveugle. Sans lui, l’image est invisible et son information est perdue.
Règles pour rédiger de bons attributs alt :
Image informative (photo de produit, schéma explicatif, capture d’écran) → alt descriptif et concis : alt="Graphique montrant l'évolution du trafic SEO sur 6 mois avec une hausse de 150%". Décrivez ce que l’image MONTRE, pas ce qu’elle EST (« photo de… » est inutile).
Image décorative (séparateur, illustration purement esthétique, fond) → alt vide : alt="". Ne pas omettre l’attribut alt (erreur technique), mais le laisser vide signale explicitement au lecteur d’écran d’ignorer cette image.
Image-lien (logo cliquable, icône de navigation) → alt décrivant la DESTINATION ou l’ACTION, pas l’image elle-même : alt="Retour à l'accueil" pour le logo, alt="Ouvrir le menu" pour l’icône hamburger.
Image complexe (infographie, graphique de données, carte géographique) → alt résumant l’information essentielle + description détaillée à proximité ou via un lien « Description complète » : alt="Répartition du budget marketing 2025 : SEO 40%, Ads 30%, Contenu 20%, Social 10%. Description détaillée ci-dessous."
Contrastes de couleurs insuffisants
Un texte avec un contraste insuffisant par rapport à son arrière-plan est illisible pour les personnes malvoyantes, les personnes âgées dont l’acuité visuelle baisse, et même les utilisateurs standards en plein soleil sur leur smartphone.
Les ratios minimaux selon WCAG 2.1 niveau AA :
Texte de taille normale (moins de 18pt ou moins de 14pt gras) → ratio de contraste minimum de 4.5:1 par rapport à l’arrière-plan. Texte de grande taille (18pt+ ou 14pt+ gras) → ratio minimum de 3:1. Composants d’interface et éléments graphiques porteurs d’information → ratio minimum de 3:1.
Les pièges courants : texte gris clair (#999) sur fond blanc (ratio 2.8:1 — insuffisant), texte blanc sur fond jaune ou vert clair (souvent insuffisant), placeholders de formulaire gris clair (non conformes par défaut dans la plupart des thèmes), texte sur image de fond sans overlay de contraste (résultat imprévisible selon la zone de l’image).
Outils de vérification : WebAIM Contrast Checker (en ligne, gratuit), l’extension Chrome « WAVE » qui signale automatiquement les problèmes de contraste, l’extension Firefox « Accessibility Insights » pour un audit plus complet. Dans vos outils de design : Figma et Adobe XD intègrent des vérificateurs de contraste.
Correction : augmentez la taille du texte (un texte plus grand tolère un contraste plus faible), assombrissez le texte ou le fond, ajoutez un fond semi-transparent sous le texte quand il est sur une image. Concrètement, un texte corps de page en #333333 sur fond blanc (#FFFFFF) offre un ratio de 12.6:1 — largement conforme et agréable à lire.
Navigation au clavier impossible
De nombreux utilisateurs ne peuvent pas utiliser de souris : personnes avec un handicap moteur, utilisateurs de lecteurs d’écran, personnes avec des tremblements. Ils naviguent exclusivement au clavier (Tab pour avancer, Shift+Tab pour reculer, Entrée pour activer, Échap pour fermer).
Problèmes fréquents :
Le focus n’est pas visible — Quand l’utilisateur tab sur un élément, il doit voir clairement QUEL élément est actif. La suppression du outline focus (outline: none sans remplacement) est l’erreur d’accessibilité la plus dommageable et la plus répandue en CSS. Solution : conservez le focus outline natif du navigateur, ou remplacez-le par un style personnalisé visible (un contour coloré, un changement de fond).
Des éléments interactifs ne sont pas atteignables au clavier — Les menus déroulants qui ne s’ouvrent qu’au survol souris, les carousels sans contrôles clavier, les modales qui ne piègent pas le focus, les boutons custom (div avec onclick au lieu de vrai button) non focusables. Solution : utilisez des éléments HTML natifs (button, a, input) qui sont nativement accessibles au clavier, ou ajoutez role, tabindex et gestion des événements clavier sur les composants personnalisés.
L’ordre de tabulation est illogique — Le focus passe d’un endroit à un autre sans logique visuelle. Solution : assurez-vous que l’ordre du DOM HTML correspond à l’ordre visuel de la page. Évitez les tabindex positifs (tabindex= »1″, « 2 », etc.) qui cassent l’ordre naturel — utilisez uniquement tabindex= »0″ (ajout dans l’ordre naturel) ou tabindex= »-1″ (retrait du flux tab mais focusable via script).
Les pièges clavier — Le focus entre dans un composant (modal, menu) mais ne peut plus en sortir. L’utilisateur est piégé. Solution : les modales doivent piéger le focus EN INTERNE (cycle Tab entre les éléments de la modale) et le relâcher quand la modale se ferme (focus retour sur l’élément déclencheur).
Formulaires non accessibles
Les formulaires sont un point critique d’accessibilité car ils impliquent une interaction active de l’utilisateur. Un formulaire inaccessible peut empêcher une personne de contacter votre entreprise, de passer commande, ou de s’inscrire — exclusion totale d’un service.
Champs sans label associé — Chaque champ de formulaire (input, select, textarea) doit être associé à un label via l’attribut for/id : <label for="email">Adresse email</label><input type="email" id="email">. Un placeholder n’est PAS un label — il disparaît à la saisie et n’est pas toujours lu par les lecteurs d’écran. Les champs avec uniquement un placeholder comme indication sont non conformes.
Messages d’erreur non identifiables — Quand un champ est mal rempli, le message d’erreur doit être : visuellement adjacent au champ concerné, programmatiquement lié au champ (via aria-describedby ou aria-errormessage), et explicite sur le problème ET la solution (« Le format attendu est jj/mm/aaaa » plutôt que simplement « Format invalide »). L’erreur ne doit pas être signalée uniquement par un changement de couleur (rouge) — ajoutez un icône, un texte explicite, ou une bordure modifiée.
Groupes de champs non structurés — Un ensemble de boutons radio ou de checkboxes liés au même sujet doivent être regroupés dans un fieldset avec une legend. Exemple : « Votre budget » (legend) avec les options « Moins de 1000€ », « 1000-3000€ », « Plus de 3000€ » (radios). Sans fieldset/legend, un lecteur d’écran lit chaque radio isolément sans contexte.
Autocomplétion non activée — L’attribut autocomplete sur les champs courants (name, email, tel, address) permet aux navigateurs et technologies d’assistance de pré-remplir les champs, réduisant la charge cognitive et les erreurs de saisie pour tous les utilisateurs.
Structure sémantique absente ou incorrecte
La structure sémantique HTML est le squelette invisible que les technologies d’assistance utilisent pour naviguer dans votre page. Un lecteur d’écran permet à l’utilisateur de « sauter » de titre en titre, de section en section, de naviguer par landmarks. Si votre HTML n’utilise pas la sémantique correctement, cette navigation est impossible.
Hiérarchie des titres — Utilisez les titres (h1 à h6) selon leur niveau hiérarchique, pas selon leur apparence visuelle. Un seul h1 par page (le titre principal), des h2 pour les sections principales, des h3 pour les sous-sections, etc. Ne sautez pas de niveau (pas de h1 suivi directement d’un h4). Le style visuel d’un titre se gère en CSS, pas en changeant le niveau sémantique.
Landmarks (régions de page) — Utilisez les balises sémantiques HTML5 : header (en-tête), nav (navigation), main (contenu principal), aside (contenu complémentaire), footer (pied de page). Ces landmarks permettent aux utilisateurs de lecteurs d’écran de sauter directement à la section souhaitée. Un site avec uniquement des div imbriquées est un labyrinthe sans carte pour un utilisateur aveugle.
Listes — Une liste d’éléments (menu de navigation, étapes d’un processus, liste de produits) doit être structurée avec ul/ol + li. Un lecteur d’écran annonce « liste de 5 éléments » — l’utilisateur sait immédiatement combien d’items il va parcourir. Des liens simplement empilés dans des div n’offrent pas cette information.
Langue de la page — L’attribut lang sur la balise html (<html lang="fr">) indique aux lecteurs d’écran quelle prononciation utiliser. Un texte français lu avec une synthèse vocale anglaise est inintelligible. Si votre page contient des passages dans une autre langue, utilisez l’attribut lang sur l’élément concerné (<span lang="en">landing page</span>).
Auditer l’accessibilité de votre site : méthode et outils
Audit automatisé : ce que les outils détectent (et ce qu’ils ne détectent pas)
Les outils d’audit automatisé sont votre première ligne de détection. Ils scannent votre code HTML et identifient les non-conformités détectables programmatiquement. Cependant, ils ne couvrent que 30 à 40% des critères d’accessibilité — le reste nécessite une évaluation humaine.
Ce que les outils automatisés détectent bien : images sans attribut alt, contrastes insuffisants (via analyse des couleurs CSS), absence de labels sur les formulaires, liens sans texte descriptif, titres sautant des niveaux, attribut lang manquant, balises ARIA invalides, structure de page sans landmarks.
Ce que les outils automatisés NE détectent PAS : la pertinence d’un attribut alt (il vérifie sa présence, pas si le texte est correct), l’ordre logique du contenu, la qualité des intitulés de liens (« cliquez ici » est détecté mais pas toujours), la navigabilité réelle au clavier (les tests d’interaction nécessitent un humain), la cohérence de la navigation, la compréhension des messages d’erreur.
Outils recommandés (gratuits) :
WAVE (WebAIM) — Extension navigateur qui affiche les problèmes directement sur votre page avec des icônes colorées. Très visuel et pédagogique. Idéal pour une première évaluation rapide page par page.
axe DevTools (Deque) — Extension Chrome qui s’intègre aux DevTools. Plus technique que WAVE, plus précis dans ses diagnostics. Détecte les violations WCAG avec explications et suggestions de correction. Utilisé par les professionnels de l’accessibilité.
Lighthouse (intégré à Chrome) — L’audit Accessibility de Lighthouse donne un score sur 100 et liste les problèmes détectés. Moins complet qu’axe mais déjà intégré à Chrome — aucune installation nécessaire. Bon pour un aperçu rapide.
Pa11y — Outil en ligne de commande pour auditer des sites entiers (pas juste une page). Idéal pour un scan automatisé de toutes vos URLs. Intégrable dans un pipeline CI/CD pour détecter les régressions d’accessibilité à chaque déploiement.
Audit manuel : les tests indispensables
Après l’audit automatisé, effectuez ces tests manuels qui couvrent les aspects non détectables par les outils :
Test de navigation clavier complet — Débranchez votre souris (mentalement ou physiquement) et naviguez sur votre site uniquement avec Tab, Shift+Tab, Entrée et les touches fléchées. Pouvez-vous atteindre tous les éléments interactifs ? Le focus est-il toujours visible ? L’ordre de tabulation est-il logique ? Pouvez-vous fermer les modales ? Pouvez-vous utiliser les menus déroulants ?
Test avec un lecteur d’écran — Activez NVDA (gratuit, Windows), VoiceOver (intégré, Mac/iOS) ou TalkBack (Android). Fermez les yeux et essayez de comprendre votre page uniquement à l’écoute. Les images sont-elles décrites ? Les formulaires sont-ils compréhensibles ? Pouvez-vous naviguer par titres ? Les liens ont-ils un intitulé explicite hors contexte ?
Test de zoom à 200% — Zoomez votre page à 200% dans le navigateur (Ctrl+). Le contenu reste-t-il lisible et fonctionnel ? Le texte ne déborde pas ? Les menus sont toujours utilisables ? Rien ne se chevauche ? C’est un critère WCAG AA (1.4.4) — de nombreuses personnes malvoyantes naviguent en permanence avec un zoom de 150 à 200%.
Test de désactivation des images — Désactivez l’affichage des images dans votre navigateur. Votre page a-t-elle encore du sens ? Chaque image informative est-elle remplacée par un alt descriptif ? Aucune information critique n’est-elle transmise uniquement par l’image ?
Test de désactivation du CSS — Désactivez les styles CSS. Le contenu s’affiche-t-il dans un ordre logique ? La structure (titres, listes, paragraphes) est-elle compréhensible sans mise en forme ? Si votre page n’a de sens qu’avec le CSS, c’est que la structure HTML sous-jacente est déficiente.
Prioriser les corrections : l’approche pragmatique
Un audit d’accessibilité peut révéler des dizaines voire des centaines de non-conformités. Tout corriger d’un coup est irréaliste pour une PME. Priorisez selon l’impact utilisateur :
Priorité 1 (bloquant — corriger cette semaine) — Problèmes qui empêchent totalement l’utilisation : navigation clavier impossible, formulaire de contact inutilisable avec un lecteur d’écran, absence totale d’alternatives textuelles, page sans structure de titres rendant la navigation impossible.
Priorité 2 (majeur — corriger ce mois) — Problèmes qui rendent l’utilisation très difficile : contrastes insuffisants sur le texte principal, messages d’erreur non explicites, liens « cliquez ici » sans contexte, images informatives sans alt pertinent.
Priorité 3 (mineur — corriger ce trimestre) — Problèmes qui dégradent l’expérience sans bloquer : lang manquant sur les passages en langue étrangère, autocomplete absent sur les formulaires, focus visible mais peu contrasté, ordre des landmarks perfectible.
Implémenter l’accessibilité sur WordPress
Choisir un thème accessible
Le choix du thème WordPress est fondamental pour l’accessibilité. Un thème mal codé introduit des problèmes structurels que vous ne pourrez corriger qu’en intervenant dans le code source — beaucoup plus coûteux que de partir sur une bonne base.
Thèmes WordPress labellisés « Accessibility Ready » — WordPress.org propose un tag « accessibility-ready » pour les thèmes qui passent un audit d’accessibilité basique. Cherchez ce tag sur le répertoire officiel. Cependant, ce label ne garantit pas une conformité RGAA complète — il couvre les fondamentaux (navigation clavier, contraste, landmarks) mais pas tous les critères.
Thèmes recommandés pour l’accessibilité :
GeneratePress — Léger, sémantiquement correct, focus visible par défaut, landmarks bien structurés. Son code minimal facilite les corrections d’accessibilité spécifiques. L’un des meilleurs choix pour un site accessible et performant.
Flavor — Développé avec l’accessibilité comme priorité de design. Conforme WCAG 2.1 AA dès l’installation. Idéal si l’accessibilité est une exigence principale de votre projet.
Flavor Theme / Flavor Theme — Thèmes développés spécifiquement pour la conformité accessibilité, souvent utilisés par les institutions publiques.
Astra — Populaire et relativement accessible dans sa configuration par défaut. Nécessite quelques ajustements (contraste des liens, focus styling) mais part sur une bonne base technique.
À éviter : les thèmes multi-purpose surchargés de fonctionnalités (Avada, Divi dans sa configuration par défaut, les thèmes ThemeForest complexes). Leur HTML est souvent non sémantique (divs imbriquées à l’excès), leur navigation clavier déficiente, et les surcharges CSS rendent les corrections laborieuses.
Plugins d’accessibilité : compléments utiles mais pas suffisants
Aucun plugin ne peut rendre un site accessible automatiquement. Les overlays d’accessibilité (AccessiBe, UserWay, etc.) qui promettent une conformité automatique sont largement critiqués par la communauté accessibilité — ils ne corrigent que les symptômes superficiels sans résoudre les problèmes structurels, et peuvent même créer de nouveaux problèmes. La conformité réelle nécessite des corrections dans le code source.
Plugins réellement utiles comme compléments :
WP Accessibility (gratuit) — Ajoute des fonctionnalités d’accessibilité concrètes : lien « skip to content », forçage du focus visible, suppression de l’attribut title sur les images (souvent redondant avec alt), corrections de certains problèmes courants de WordPress core.
One Click Accessibility (gratuit) — Ajoute une barre d’outils permettant aux visiteurs d’agrandir le texte, augmenter les contrastes, et activer un mode lecture. Utile mais ne remplace pas une conception accessible native.
Flavor Accessibility Checker (gratuit) — Analyse vos pages directement dans l’éditeur WordPress et signale les problèmes d’accessibilité au moment de la création de contenu. Prévention plutôt que correction.
Rédiger du contenu accessible
L’accessibilité n’est pas uniquement technique — la rédaction du contenu joue un rôle majeur :
Langage clair et simple — Utilisez des phrases courtes (maximum 25 mots par phrase), un vocabulaire courant, et une structure logique (une idée par paragraphe). Les personnes avec des troubles cognitifs, les personnes dont le français n’est pas la langue maternelle, et les lecteurs pressés bénéficient tous d’un langage clair. Le RGAA n’impose pas de niveau de lecture spécifique (contrairement à WCAG AAA), mais c’est une bonne pratique universelle.
Liens explicites — L’intitulé d’un lien doit être compréhensible hors contexte. « Cliquez ici », « En savoir plus », « Lire la suite » sont insuffisants — un utilisateur de lecteur d’écran qui navigue de lien en lien entend une liste de « cliquez ici » sans savoir vers quoi chaque lien mène. Préférez : « Consultez notre guide de migration WordPress », « Téléchargez le template de cahier des charges », « Découvrez nos tarifs de création de site ».
Alternatives textuelles pour le multimédia — Chaque vidéo doit avoir des sous-titres (pas générés automatiquement sans relecture — YouTube auto-captions contiennent ~15% d’erreurs). Chaque audio (podcast) doit avoir une transcription textuelle. Chaque infographie complexe doit avoir une description textuelle équivalente. C’est du travail supplémentaire mais c’est la loi pour les organismes soumis au RGAA, et une bonne pratique SEO pour tous (Google indexe le texte, pas les vidéos).
Pas d’information uniquement par la couleur — « Les champs en rouge sont obligatoires » exclut les personnes daltoniques (8% des hommes). Ajoutez un astérisque, un texte « (obligatoire) », ou un icône en plus de la couleur. De même pour les graphiques : ne différenciez pas les séries uniquement par la couleur — ajoutez des motifs, labels ou légendes textuelles.
Accessibilité et SEO : le cercle vertueux
Ce que l’accessibilité apporte au référencement
Accessibilité et SEO partagent un socle technique commun. De nombreuses bonnes pratiques d’accessibilité sont directement bénéfiques pour le référencement :
Structure sémantique = meilleur crawl — Les titres h1-h6 structurés aident Google à comprendre la hiérarchie de votre contenu autant qu’ils aident les lecteurs d’écran. Un site avec une structure de titres claire est mieux compris et mieux classé par Google.
Alternatives textuelles = indexation des images — Google ne « voit » pas vos images (malgré les progrès en vision par ordinateur). L’attribut alt est le principal signal qu’il utilise pour comprendre et indexer vos images dans Google Images. Un site accessible avec des alt descriptifs est un site qui se positionne mieux dans Google Images.
Transcriptions et sous-titres = contenu indexable — Le contenu d’une vidéo sans transcription est invisible pour Google. Ajouter des sous-titres et une transcription crée du contenu textuel indexable, positionnable sur des mots-clés, et partageable. L’intelligence artificielle peut vous aider à générer des transcriptions plus rapidement.
Performance = accessibilité et SEO — Un site rapide est à la fois plus accessible (les connexions lentes handicapent les utilisateurs en zones rurales ou avec des équipements anciens) et mieux classé par Google (Core Web Vitals).
Mobile-first = accessibilité mobile — Les critères d’accessibilité mobile (taille des zones cliquables, espacement des éléments, lisibilité sans zoom) sont exactement les mêmes que les bonnes pratiques d’ergonomie mobile que Google évalue.
Le bonus SEO concret
Au-delà du socle technique commun, l’accessibilité offre des avantages SEO indirects mesurables :
Réduction du taux de rebond — Un site accessible est plus facile à utiliser pour TOUT le monde. Une meilleure expérience utilisateur se traduit par un temps de visite plus long et un taux de rebond plus bas — deux signaux positifs pour le classement.
Augmentation de l’audience potentielle — 20% de la population ayant un handicap, un site accessible touche 20% de visiteurs en plus. Plus de trafic, plus d’engagement, plus de signaux positifs pour Google.
Liens entrants — Les sites institutionnels et associatifs (sources de backlinks de qualité) sont sensibles à l’accessibilité. Un site accessible est plus susceptible d’être recommandé et lié par ces sources. Découvrez comment une migration WordPress bien menée préserve votre SEO et améliore votre accessibilité technique.
Déclaration d’accessibilité : ce que vous devez publier
Contenu obligatoire de la déclaration
Tout site soumis à l’obligation d’accessibilité doit publier une déclaration d’accessibilité accessible depuis chaque page (généralement un lien dans le footer). Cette déclaration doit contenir :
L’état de conformité — « Totalement conforme », « Partiellement conforme » (entre 50% et 99% des critères respectés), ou « Non conforme » (moins de 50%). Soyez honnête — une fausse déclaration de conformité est pire que l’aveu d’une non-conformité en cours de correction.
La date de l’audit — Quand l’évaluation a été réalisée, et par qui (auto-évaluation ou audit externe).
Le référentiel utilisé — RGAA version 4.1, WCAG 2.1 niveau AA.
Les non-conformités connues — Liste des critères non respectés avec explication du problème et plan de correction prévu.
Les contenus non soumis à l’obligation — Contenus tiers non contrôlables, contenus archivés, etc.
Un moyen de contact — Email ou formulaire permettant aux utilisateurs de signaler un problème d’accessibilité rencontré sur le site.
Les voies de recours — Mention du Défenseur des droits comme recours en cas de non-réponse.
Modèle de déclaration pour une PME
Même si votre PME n’est pas légalement obligée en 2025, publier une déclaration d’accessibilité volontaire démontre votre engagement et votre professionnalisme. Voici la structure recommandée :
Titre de la page : « Accessibilité ». Contenu : état actuel de votre conformité (soyez transparent), actions déjà réalisées, plan d’action pour les prochains mois, contact pour signaler un problème. Cette transparence est bien plus valorisante qu’un silence qui pourrait être interprété comme de l’indifférence.
Plan d’action : rendre votre site accessible progressivement
Phase 1 : Les quick wins (1 à 2 semaines)
Attributs alt sur toutes les images — Parcourez votre médiathèque WordPress et renseignez le champ « Texte alternatif » pour chaque image. Laissez vide (alt= » ») les images purement décoratives. C’est fastidieux mais critique — et c’est du contenu indexable en bonus SEO.
Contrastes des textes — Vérifiez vos couleurs principales (texte corps, titres, liens, boutons) avec un outil de contraste. Ajustez les couleurs insuffisantes dans les options de votre thème ou via du CSS personnalisé. Le plus courant : passer vos textes de #666 à #333 suffit souvent à corriger les problèmes.
Labels de formulaire — Vérifiez que chaque champ de vos formulaires (Contact Form 7, Gravity Forms, WPForms) a un label visible et associé. La plupart des plugins de formulaire WordPress gèrent ça correctement par défaut, mais vérifiez — certaines configurations personnalisées cassent l’association label/input.
Attribut lang sur la balise html — Vérifiez que votre balise html contient lang="fr". WordPress le gère normalement via les paramètres de langue du site, mais certains thèmes ou configurations multilingues peuvent le casser.
Phase 2 : La structure (2 à 4 semaines)
Hiérarchie des titres — Auditez la structure de titres de chaque template de page (page d’accueil, pages services, articles). Corrigez les sauts de niveau et les titres utilisés pour leur style plutôt que leur sémantique.
Navigation clavier — Testez la navigation au clavier sur votre menu principal, vos formulaires, et vos composants interactifs. Ajoutez un lien « Aller au contenu principal » (skip link) en début de page — le plugin WP Accessibility le fait automatiquement.
Landmarks HTML5 — Vérifiez que votre thème utilise les balises header, nav, main, footer. Si non, ajoutez les rôles ARIA correspondants (role= »banner », role= »navigation », role= »main », role= »contentinfo ») sur les div existantes.
Phase 3 : L’approfondissement (1 à 3 mois)
Audit complet avec WAVE et axe — Passez chaque template de page dans les outils d’audit et corrigez systématiquement les erreurs signalées.
Tests avec lecteur d’écran — Naviguez sur votre site avec NVDA (gratuit, Windows) ou VoiceOver (Mac). Identifiez les parcours utilisateur critiques (trouver un service, remplir le formulaire de contact, naviguer dans le blog) et assurez-vous qu’ils sont réalisables à l’écoute.
Accessibilité des PDFs — Si vous proposez des documents PDF en téléchargement (brochures, guides, devis), vérifiez qu’ils sont structurés (titres, alternative aux images, ordre de lecture logique). Les PDF scannés sans OCR sont totalement inaccessibles — refaites-les ou proposez une alternative HTML.
Formation de l’équipe — Sensibilisez toute personne qui produit du contenu pour votre site (rédacteurs, contributeurs) aux bonnes pratiques : alt sur les images, liens explicites, structure de titres, contrastes. L’accessibilité maintenue dans le temps nécessite que chaque nouveau contenu respecte les règles.
FAQ : Accessibilité web RGAA et WCAG
Mon site doit-il obligatoirement être conforme au RGAA ?
En 2025, l’obligation légale concerne les services publics, les grandes entreprises (CA > 250M€), et les entreprises de certains secteurs réglementés (e-commerce, banque, transport, télécom) suite à la transposition de l’European Accessibility Act. Les TPE et PME classiques ne sont pas encore légalement obligées pour leur site vitrine. Cependant, la tendance réglementaire va clairement vers un élargissement, et de nombreux donneurs d’ordre exigent déjà la conformité de leurs prestataires. Se mettre en conformité maintenant, c’est prendre de l’avance plutôt que de subir une obligation dans l’urgence.
Les overlays d’accessibilité (AccessiBe, UserWay) rendent-ils un site conforme ?
Non. Ces outils ajoutent une couche par-dessus votre site qui propose des fonctionnalités (agrandissement du texte, changement de contrastes, etc.) mais ne corrigent pas les problèmes structurels du code. Un formulaire sans label reste sans label, une image sans alt reste sans alt, une navigation clavier cassée reste cassée. La communauté accessibilité et les experts du domaine sont unanimes : ces overlays ne constituent pas une mise en conformité et peuvent même créer des conflits avec les technologies d’assistance réelles des utilisateurs. La seule approche valide est la correction du code source.
Combien coûte la mise en accessibilité d’un site existant ?
Le coût dépend de la taille du site et de la gravité des non-conformités. Pour un site vitrine de 5-10 pages avec un thème WordPress bien codé : 1 500 à 3 000€ pour un audit + corrections pour atteindre une conformité partielle haute (80%+). Pour un site e-commerce ou un site complexe (20+ pages, formulaires multiples, espace membre) : 5 000 à 15 000€. Pour une conformité totale certifiée : ajoutez 3 000 à 5 000€ d’audit externe par un organisme habilité. L’investissement est à comparer avec le risque d’amende (20 000-50 000€/an) et l’audience perdue (20% de la population potentiellement exclue).
L’accessibilité dégrade-t-elle le design d’un site ?
C’est un mythe tenace. Un site accessible peut être aussi esthétique et moderne qu’un site non accessible. Les contraintes d’accessibilité (contrastes suffisants, tailles de texte lisibles, espacement adéquat) améliorent en réalité la lisibilité et l’ergonomie pour TOUS les utilisateurs. Les plus beaux sites du monde (Apple, gov.uk, BBC) sont parmi les plus accessibles. La contrainte créative imposée par l’accessibilité produit souvent des designs plus clairs, plus élégants et plus efficaces que les designs sans contrainte.
Par où commencer quand on n’y connaît rien en accessibilité ?
Commencez par trois actions immédiates qui ont le plus grand impact : vérifiez les contrastes de vos textes principaux (outil en ligne WebAIM Contrast Checker, 5 minutes), ajoutez des attributs alt à toutes vos images (parcourez votre médiathèque WordPress, 1 à 2 heures selon le nombre d’images), et testez la navigation au clavier sur votre page d’accueil (débranchez la souris et naviguez avec Tab, 10 minutes). Ces trois vérifications couvrent les problèmes les plus graves et les plus fréquents. Ensuite, lancez un audit WAVE de votre page d’accueil et corrigez les erreurs signalées une par une.
Conclusion : l’accessibilité est un investissement durable
Rendre votre site web accessible n’est pas un coût — c’est un investissement qui génère des retours multiples : conformité légale (protection contre les sanctions), audience élargie (20% de population supplémentaire), meilleur SEO (structure sémantique, contenu textuel riche), et image de marque responsable (engagement RSE visible).
L’approche pragmatique est la suivante : ne visez pas la perfection immédiate, mais une amélioration continue. Commencez par les corrections à fort impact (contrastes, alt, navigation clavier), puis progressez méthodiquement vers une conformité RGAA partielle haute. Chaque amélioration bénéficie immédiatement à vos utilisateurs — y compris ceux sans handicap déclaré.
En 2025, l’accessibilité n’est plus optionnelle pour les entreprises qui se veulent professionnelles et responsables. C’est un standard de qualité au même titre que la sécurité HTTPS ou la compatibilité mobile. Les sites qui l’ignorent aujourd’hui devront s’y conformer demain — dans l’urgence et à un coût supérieur. Besoin d’un audit d’accessibilité de votre site ou d’un accompagnement vers la conformité RGAA ? Contactez Site Web Montpellier.
Parlons de votre projet
Décrivez votre activité en deux lignes. Vous recevez un devis gratuit et détaillé sous 48 h — c’est Noham qui vous répond.
Contact
Envie de créer votre site web ?
Et si on parlait de votre projet ?
