MontréalCA
Marseille FR

Accessibilité web et directive européenne : vos obligations et comment vous y conformer

La directive européenne sur l'accessibilité s'applique à une grande partie du secteur privé depuis le 28 juin 2025. Panorama complet des obligations, des sanctions, des outils d'audit et des corrections techniques à mettre en place sur un site WordPress.

Les sites web n'ont jamais été aussi sophistiqués. Ils n'ont jamais été aussi peu accessibles. Le rapport WebAIM Million 2026, qui analyse chaque année les pages d'accueil du million de sites les plus visités du monde, constate que 95,9 % d'entre elles présentent au moins une erreur d'accessibilité détectable automatiquement. Ce chiffre, stable autour de 95 % depuis plusieurs années, augmente pour la première fois depuis six exercices successifs. La complexité croissante des pages, l'explosion des composants dynamiques et l'usage mal maîtrisé des attributs ARIA produisent mécaniquement plus d'obstacles pour les utilisateurs en situation de handicap, alors même que les outils pour bien faire n'ont jamais été aussi matures.

Cette dégradation tombe au pire moment possible. Depuis le 28 juin 2025, la directive européenne 2019/882, dite European Accessibility Act ou EAA, est devenue exigible. Elle a été transposée en droit français par l'article 16 de la loi du 9 mars 2023, complétée par une ordonnance, un décret et un arrêté d'application. Pour une grande partie du secteur privé (e-commerce, services bancaires aux consommateurs, plateformes de réservation, services de communications électroniques, médias audiovisuels, livres numériques), l'accessibilité numérique n'est plus une bonne pratique facultative : c'est une obligation légale, contrôlée et sanctionnée par la DGCCRF, l'ARCEP ou l'ARCOM selon les secteurs.

Nous accompagnons chez MtoM Création des TPE et des PME sur la création et la maintenance de leurs sites et boutiques en ligne, aussi bien sur WordPress et WooCommerce que sur Shopify ou en développement sur mesure avec Laravel. L'accessibilité concerne chacun de ces environnements, avec des leviers de correction différents. Cet article fait le point sur ce que la directive impose vraiment, qui est concerné, quelles sanctions sont en jeu, et surtout comment auditer et corriger votre site sans tout reprendre de zéro.

Une bascule législative passée inaperçue

Jusqu'à récemment, l'accessibilité numérique était surtout une obligation du secteur public en France. Le RGAA, référentiel général d'amélioration de l'accessibilité, encadrait depuis 2009 les sites des administrations, des collectivités et de certaines grandes entreprises publiques. Le reste du secteur privé s'y intéressait par conviction ou par calcul marketing, mais pas par obligation légale.

La directive européenne adoptée en 2019 a changé cette donne. Elle vise à harmoniser les obligations d'accessibilité à l'échelle de l'Union européenne pour un large ensemble de produits et de services du secteur privé. La France l'a transposée par la loi du 9 mars 2023 (dite loi DDADUE), précisée par l'ordonnance n° 2023-859 du 6 septembre 2023, le décret n° 2023-931 et un arrêté du 9 octobre 2023. L'application est devenue exigible le 28 juin 2025. Pour les contrats déjà en cours à cette date, une période de transition court jusqu'au 28 juin 2030.

Qui est concerné ?

La directive cible plusieurs familles de produits et de services. Côté services, sont concernés les services bancaires aux consommateurs, les services de communications électroniques, les services de transport de voyageurs (billetterie, information voyageur en temps réel), l'accès aux services de médias audiovisuels, le commerce électronique au sens large, les livres numériques et leurs logiciels de lecture. Côté produits, la directive touche les terminaux informatiques grand public, les liseuses, les distributeurs automatiques bancaires, les automates de vente de billets et les téléviseurs connectés.

Pour la plupart des sites web et applications que nous conseillons, c'est la notion de commerce électronique qui déclenche l'obligation. Elle est entendue largement : tout service permettant à un consommateur de conclure un contrat à distance entre dans le périmètre. Un site e-commerce classique, évidemment. Mais aussi la réservation d'un hébergement, la vente de cartes cadeaux numériques, la plateforme de réservation d'un restaurant ou l'abonnement à un service payant en ligne. Les zones grises existent, notamment pour les prises de rendez-vous qui ne donnent pas lieu à contrat commercial : chaque cas limite mérite une analyse, mais la prudence consiste à se considérer dans le périmètre dès qu'une transaction en ligne est possible.

Une exception importante existe pour les micro-entreprises. Une structure qui emploie moins de 10 personnes et dont le chiffre d'affaires annuel ou le total du bilan ne dépasse pas 2 millions d'euros est exemptée, mais uniquement pour ses services. Cette exemption ne s'applique pas aux produits qu'elle conçoit ou fabrique. Autrement dit, une TPE qui vend en ligne ses propres produits cosmétiques n'a pas à rendre son site accessible (elle est exemptée au titre du service e-commerce), mais si cette même TPE fabrique des terminaux de paiement, ces terminaux doivent être conformes.

En pratique, beaucoup de nos clients entrent dans cette exemption TPE. Cela ne signifie pas pour autant que l'accessibilité devient sans intérêt pour eux : elle reste un levier SEO, un facteur de conversion et un signal de qualité. Une TPE exemptée aujourd'hui peut aussi basculer dans le périmètre obligatoire si elle se développe.

WCAG, RGAA, EN 301 549 : démêler ce qu'on vous demande vraiment

Le mille-feuille normatif qui entoure l'accessibilité numérique est l'une des raisons qui font fuir les TPE et les PME. Entre les référentiels internationaux, les normes européennes et les déclinaisons françaises, il est facile de s'y perdre. Les trois références principales que vous rencontrerez s'articulent ainsi.

WCAG 2.1 AA, le socle international de référence

Les Web Content Accessibility Guidelines, ou WCAG, sont publiées par le W3C, l'organisme qui normalise les standards du web. La version 2.1, publiée en juin 2018, reste la version légalement exigible en Europe. La version 2.2 existe depuis octobre 2023 et sera probablement intégrée au cadre légal à partir de 2026, mais elle n'est pas encore obligatoire.

Les WCAG s'organisent autour de quatre principes : le contenu doit être perceptible (lisible par tous les sens utilisables), utilisable (manipulable au clavier, sans piège temporel), compréhensible (lisible, prévisible) et robuste (compatible avec les technologies d'assistance actuelles et futures). Ces principes se déclinent en critères, chacun classé à trois niveaux de conformité : A, AA et AAA. Le niveau AA est celui retenu par la législation européenne comme objectif à atteindre. Le niveau AAA est un plafond rarement atteint, souvent incompatible avec certaines contraintes de design.

EN 301 549, la norme européenne harmonisée

La norme EN 301 549 est la traduction technique officielle des exigences d'accessibilité au niveau européen. Sa version actuelle, v3.2.1, a été harmonisée en août 2021 et intègre l'intégralité des critères WCAG 2.1 AA. Elle ajoute des exigences spécifiques aux technologies de l'information et de la communication qui ne sont pas couvertes par les WCAG : accessibilité des fonctions matérielles des appareils, compatibilité avec les aides auditives, exigences sur les services vocaux.

La version 4.1.1 de la norme est attendue en 2026 et doit intégrer WCAG 2.2 ainsi que des mises à jour sur le texte en temps réel. En pratique, pour un site web, la conformité aux WCAG 2.1 AA couvre la majeure partie des exigences de l'EN 301 549.

RGAA 4.1, la déclinaison française opérationnelle

Le Référentiel général d'amélioration de l'accessibilité, dans sa version 4.1, est maintenu par la DINUM. Il traduit les critères WCAG en une méthodologie d'évaluation applicable dans le contexte français. Là où les WCAG formulent des critères de haut niveau, le RGAA fournit des tests concrets, rédigés en français, que vos développeurs ou votre agence peuvent appliquer page par page. Pour mesurer concrètement la conformité d'un site en France, c'est la référence opérationnelle.

Le RGAA 4.1 couvre 106 critères organisés en 13 thématiques. Un audit complet consiste à évaluer chaque critère sur un échantillon de pages représentatif du site, puis à calculer un taux de conformité global. Un site est considéré comme pleinement conforme à partir de 100 % et partiellement conforme au-delà de 50 %. En dessous, il est non conforme.

Ce que vous devez afficher sur votre site

Au-delà de la mise en conformité technique, la directive impose plusieurs obligations d'information. Votre site doit publier les informations sur la manière dont le service répond aux exigences d'accessibilité : niveau de conformité, description des fonctionnalités accessibles, éventuelles limitations connues. Un moyen de contact doit permettre aux utilisateurs de signaler un problème d'accessibilité, avec engagement de réponse sous un délai raisonnable. Ces informations doivent être facilement accessibles, généralement depuis le pied de page ou un menu secondaire, pas enfouies au fond d'une arborescence. Attention à ne pas confondre ce régime avec les obligations plus détaillées du secteur public (déclaration d'accessibilité formelle et schéma pluriannuel triennal imposés par la loi de 2005), qui suivent leur propre logique et qui ne s'appliquent pas automatiquement aux entreprises privées couvertes par l'EAA.

Les sanctions ne sont pas théoriques

Le régime de sanctions est désormais clair et stratifié selon l'autorité compétente. La DGCCRF est la première ligne pour tout ce qui relève des produits et services grand public, en particulier le commerce électronique. Un manquement à la directive est qualifié de contravention de 5e classe : l'amende forfaitaire est de 1 500 € pour une personne physique et 7 500 € pour une personne morale. Ces amendes sont cumulatives : chaque manquement constaté est sanctionné séparément, et le total peut théoriquement atteindre plusieurs centaines de milliers d'euros sur un audit complet.

Pour les services de communications électroniques, c'est l'ARCEP qui contrôle. Les sanctions peuvent monter jusqu'à 75 000 € pour une personne physique et jusqu'à 1 % du chiffre d'affaires hors taxes réalisé en France lors du dernier exercice clos pour une personne morale. Pour les services de médias audiovisuels et le secteur public, l'ARCOM peut prononcer des amendes pouvant atteindre 50 000 €, renouvelables tous les six mois tant que la situation n'est pas corrigée.

Le processus type commence par un signalement, souvent fait par un utilisateur lésé ou une association. L'autorité compétente enquête, constate les manquements, met en demeure l'entreprise de se mettre en conformité dans un délai précisé, puis sanctionne si la mise en conformité n'a pas lieu. Les contrôles ont commencé à la date d'entrée en application de la directive, le 28 juin 2025. La probabilité d'un contrôle spontané reste faible pour une PME, mais celle d'un signalement de la part d'un utilisateur exclu augmente à mesure que la sensibilité du public s'installe.

Où en est le web aujourd'hui ?

Le rapport WebAIM Million, publié chaque année depuis 2019 par l'organisme américain spécialisé dans l'accessibilité, analyse les pages d'accueil du million de sites les plus visités au monde. L'édition 2026 du rapport livre un constat préoccupant : 95,9 % des pages d'accueil analysées présentent au moins une erreur d'accessibilité détectable automatiquement, contre 94,8 % en 2025. Ce chiffre augmente pour la première fois depuis six années consécutives de légère amélioration.

La cause identifiée par WebAIM est à contre-courant de ce que l'on pourrait croire. Les pages d'accueil ne sont pas moins travaillées qu'avant : elles sont plus complexes. Une page d'accueil moyenne contient désormais 1 437 éléments HTML, soit une augmentation de 22,5 % en un an et un quasi-doublement depuis 2019. L'usage d'ARIA, un langage qui permet d'ajouter des informations d'accessibilité aux composants dynamiques, a également explosé. Le problème : ARIA mal utilisé dégrade l'accessibilité au lieu de l'améliorer. La prolifération des constructeurs visuels, des widgets dynamiques et des effets JavaScript produit mécaniquement plus d'erreurs.

Les six catégories d'erreurs qui concentrent presque tout

Six types d'erreurs représentent à elles seules 96 % des défauts détectés, et ce classement est stable depuis sept ans. Le contraste de texte insuffisant reste en tête, présent sur 83,9 % des pages, avec une moyenne de 34 instances par page. Viennent ensuite les textes alternatifs manquants sur les images, les libellés manquants dans les formulaires, les boutons dont le contenu est vide, les liens dont le contenu est vide, et l'absence de déclaration de langue sur la page. Ces six erreurs ont un point commun : elles sont toutes détectables automatiquement par les outils d'audit gratuits que nous présentons dans la section suivante. Elles ne représentent pas toute la conformité (les outils automatiques captent environ un tiers des problèmes réels), mais elles constituent la première strate à traiter, la plus rentable en temps et la plus visible côté utilisateurs.

Auditer votre site rapidement

Avant de corriger, il faut mesurer. Un audit complet par un cabinet spécialisé coûte entre 5 000 et 15 000 € pour un site WordPress de taille moyenne, et il est pleinement justifié quand l'enjeu est réglementaire et qu'une déclaration officielle doit être publiée. Mais avant d'en arriver là, vous pouvez faire un premier diagnostic vous-même avec des outils gratuits, qui révèleront 30 à 40 % des problèmes réels de votre site.

Les outils gratuits qui suffisent pour démarrer

Lighthouse est intégré directement aux outils développeurs de Chrome. Ouvrez la console (F12 ou clic droit puis Inspecter), onglet Lighthouse, cochez Accessibility et lancez l'audit. En 30 secondes, vous obtenez un score sur 100 et une liste des problèmes détectés, avec des liens vers la documentation WCAG correspondante. Lighthouse est particulièrement efficace pour détecter les contrastes insuffisants, les attributs ARIA invalides et les problèmes de structure.

WAVE, édité par WebAIM, fonctionne comme une extension navigateur ou un service en ligne. Collez l'URL de votre page sur wave.webaim.org, ou installez l'extension Chrome ou Firefox. WAVE superpose visuellement sur votre page les erreurs, les alertes et les éléments structurels. Son intérêt principal est pédagogique : vous voyez directement sur votre page où se trouve chaque problème, ce qui aide à comprendre ce qu'il faut corriger.

axe DevTools, édité par Deque, est une extension navigateur dont la version gratuite suffit pour la plupart des PME. Elle est réputée pour la précision de ses détections et la qualité de ses explications, avec un niveau de faux positifs très bas. Vous pouvez l'utiliser en complément de Lighthouse pour confirmer ou infirmer des détections.

Le cas WordPress avec Accessibility Checker

Pour un site WordPress, nous recommandons l'extension Accessibility Checker d'Equalize Digital. Sa version gratuite permet d'auditer toutes les pages et tous les articles du site, d'afficher un score de conformité dans l'administration, et de pointer précisément les problèmes trouvés. Installez l'extension, activez-la, et un scan automatique tourne en arrière-plan pour chaque contenu édité. Dans la liste des pages, une colonne indique le nombre d'erreurs détectées. Cliquez sur une page, vous accédez au détail des problèmes avec des explications contextuelles. La version payante ajoute des fonctionnalités utiles en entreprise (rapports PDF, scan planifié, vues d'équipe), mais la version gratuite couvre l'essentiel pour une PME.

Ce qu'aucun outil ne peut voir

Les outils automatiques détectent en moyenne 30 à 40 % des problèmes d'accessibilité réels. Les 60 % restants nécessitent des tests manuels, qui ne sont ni complexes ni coûteux, mais qui demandent un peu de méthode. Le test le plus rapide et le plus révélateur consiste à naviguer sur tout votre site en utilisant uniquement le clavier. Partez de la page d'accueil, utilisez Tab pour avancer, Shift+Tab pour reculer, Entrée pour valider, Échap pour fermer. Essayez d'accéder à toutes les fonctionnalités principales : menu, recherche, ajout au panier, paiement, formulaire de contact. Si un élément n'est pas accessible au clavier ou si vous perdez le focus visuel, c'est un manquement grave.

Le second test consiste à activer un lecteur d'écran. Sur macOS, VoiceOver est intégré (Cmd+F5 pour l'activer). Sur Windows, téléchargez NVDA qui est gratuit. Naviguez sur vos pages en écoutant ce qui est lu : la navigation est-elle compréhensible, les images sont-elles décrites pertinemment, les formulaires annoncent-ils leurs champs et leurs erreurs ? Ce test est déroutant la première fois, mais il est le seul moyen de comprendre ce que vit réellement un utilisateur non voyant.

Complétez par un test de zoom à 200 %, un test de contraste manuel avec un outil type Colour Contrast Analyser sur les éléments détachés graphiquement que les outils ratent, et un test de lecture dans un mode de couleur inversée (utile pour débusquer les textes dessinés sur des images de fond).

Les dix corrections qui règlent la plupart des problèmes WordPress

La bonne nouvelle, après un premier audit, c'est que les problèmes récurrents se résument à une dizaine de patterns. Ceux que nous rencontrons systématiquement sur les sites WordPress, classés par impact et par facilité de correction :

1. Contraste insuffisant sur vos boutons et votre texte. Le contraste minimum requis par WCAG AA est de 4,5:1 pour le texte standard et 3:1 pour le texte de grande taille ou les éléments graphiques. Un bouton blanc sur fond gris clair, ou un texte gris moyen sur fond blanc, passe en dessous. Correction dans Elementor : ouvrez votre thème global, ajustez les couleurs secondaires et les variantes de texte pour respecter ces seuils. Dans Bricks Builder, utilisez les variables de couleur globales et testez chaque combinaison avec Colour Contrast Analyser.

2. Focus invisible au clavier. Beaucoup de thèmes et de constructeurs suppriment l'outline de focus par défaut des navigateurs pour des raisons esthétiques. Résultat : un utilisateur qui navigue au clavier ne sait plus où il en est. Correction : ajoutez dans votre feuille de style globale un style de focus visible. Par exemple :

:focus-visible {
  outline: 3px solid #0056b3;
  outline-offset: 2px;
}

3. Labels manquants dans vos formulaires. Chaque champ doit avoir un libellé lié explicitement via l'attribut for, ou via un aria-label si le libellé est visuel mais non textuel. Les placeholders ne suffisent pas : ils disparaissent dès la saisie. Correction dans Contact Form 7 ou WPForms : vérifiez que chaque champ a une étiquette visible et que le champ de recherche de votre en-tête possède un aria-label explicite.

4. Hiérarchie des titres incohérente. Une page doit avoir un seul H1, puis une structure H2, H3, H4 qui reflète la logique du contenu. Les constructeurs visuels permettent facilement de casser cette hiérarchie en choisissant un style H3 pour un titre principal parce qu'il paraît mieux. À corriger systématiquement : le style typographique est une chose, la structure sémantique en est une autre. Dans Bricks et Elementor, dissociez toujours le tag HTML du style.

5. Absence de lien d'évitement en haut de page. Un skip link permet à un utilisateur au clavier ou avec lecteur d'écran de sauter la navigation et d'aller directement au contenu principal. Il doit être le premier élément focusable de la page, généralement caché visuellement mais révélé au focus :

<a class="skip-link" href="#main">Aller au contenu principal</a>
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
  background: white;
  padding: .5rem 1rem;
  z-index: 9999;
}

6. Texte alternatif absent ou mal pensé. Toute image porteuse d'information doit avoir un attribut alt pertinent. Les images purement décoratives doivent avoir alt="" pour que le lecteur d'écran les ignore. Un logo doit avoir comme alt le nom de l'entreprise, pas "logo". Une image de produit doit décrire le produit, pas son nom de fichier. WordPress propose le champ de texte alternatif à chaque import dans la médiathèque : profitez de ce moment, il ne reviendra pas, et envisagez une extension qui rend cette saisie obligatoire pour vos rédacteurs.

7. Attributs ARIA mal utilisés sur les composants dynamiques. Un menu déroulant, un accordéon, un modal ou un carousel ont besoin d'ARIA pour être compris des technologies d'assistance. Mais ARIA mal utilisé est pire que pas d'ARIA du tout. Règle de base : si un élément HTML natif existe pour votre besoin (bouton, lien, liste), utilisez-le plutôt qu'un <div> enrichi en ARIA. Pour les composants vraiment personnalisés, suivez les patterns officiels du W3C documentés dans ARIA Authoring Practices.

8. Messages d'erreur non associés à leur champ. Dans un formulaire, un message d'erreur qui s'affiche en rouge à côté du champ doit être lié sémantiquement au champ, pas juste positionné visuellement. Utilisez aria-describedby pointant vers l'ID du message d'erreur, et annoncez dynamiquement les erreurs à la soumission via aria-live="polite" sur le conteneur d'erreur.

9. Langue de la page non déclarée. L'attribut lang de la balise <html> indique aux lecteurs d'écran quelle voix et quelle prononciation utiliser. Une page française sans lang="fr" sera lue avec l'accent anglais par défaut, ce qui rend le contenu incompréhensible. WordPress insère normalement cet attribut à partir des réglages de site, mais certains thèmes le perdent. Vérifiez dans le code source de votre page que <html lang="fr"> apparaît.

10. Tunnel de paiement WooCommerce défaillant. Le checkout WooCommerce concentre un maximum d'accessibilité critique : formulaires complexes, messages d'erreur dynamiques, steps multiples. Testez-le systématiquement au clavier et au lecteur d'écran. Si vous utilisez un builder de checkout tiers, vérifiez sa documentation d'accessibilité avant de l'installer. Une extension populaire peut parfaitement être un désastre pour un utilisateur avec lecteur d'écran.

Ce qui ne se corrige pas après coup

Les corrections techniques que nous venons de décrire suffisent pour redresser un site existant. Mais si vous concevez un nouveau site, ou si vous envisagez une refonte, il est beaucoup plus économique de penser accessibilité dès le départ que d'ajouter une couche de conformité à la fin.

Écrire et designer accessibles dès le départ

Côté contenu, les règles tiennent en quelques principes simples : un langage clair, des phrases courtes, des titres informatifs plutôt qu'accrocheurs, une structure sémantique respectée. Cela améliore aussi la lisibilité pour les utilisateurs valides, le SEO et le taux de conversion. Le plus gros frein reste souvent culturel : les rédacteurs et les marketeurs ont tendance à privilégier des titres évocateurs ou des formulations imagées, qui peuvent nuire à la compréhension pour un public à la littératie variable. Sensibiliser les équipes en amont est plus efficace qu'auditer en aval.

Côté design, la plupart des problèmes d'accessibilité trouvent leur origine à l'étape maquette. Un design system qui valide les contrastes, qui prévoit des états de focus visibles, qui documente les composants dynamiques avec leurs comportements au clavier, prévient 80 % des manquements avant même qu'une ligne de code soit écrite. Des outils comme Stark, intégrés à Figma, automatisent la vérification des contrastes pendant la conception.

Intégrer l'accessibilité au cahier des charges et à la recette

Pour les projets que nous menons chez MtoM Création, nous mentionnons systématiquement la conformité WCAG 2.1 AA au niveau des exigences fonctionnelles. Une phase d'audit d'accessibilité est intégrée à la recette, avec des critères de validation chiffrés plutôt qu'avec une formulation vague. Ce n'est pas une couche d'exigence en plus qui alourdit le projet : c'est une qualité qui s'inscrit naturellement dans une démarche de conception soignée, au même titre que la performance, le SEO ou la sécurité. Quand l'accessibilité est traitée comme un prérequis de qualité, elle ne coûte pas plus cher. Quand elle devient une correction d'urgence avant un contrôle, elle coûte plusieurs fois le prix d'avoir bien fait du premier coup.

Et côté Canada et Québec ?

La directive européenne ne s'applique pas au Canada, mais vos lecteurs canadiens ne sont pas pour autant hors du champ de l'accessibilité numérique.

Au niveau fédéral, la Loi canadienne sur l'accessibilité, adoptée en 2019, impose des obligations progressives aux entités sous juridiction fédérale : banques, télécommunications, transport interprovincial, secteur public fédéral. En Ontario, la LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) encadre depuis 2005 les organismes publics et les entreprises de plus de 50 employés, avec des obligations d'accessibilité numérique alignées sur WCAG 2.0 AA. Au Québec, la Loi assurant l'exercice des droits des personnes handicapées ainsi que la politique gouvernementale sur l'accès aux documents et services offerts au public pour les personnes handicapées structurent le cadre pour le secteur public et ses mandataires.

Nous avons consacré un article au cadre canadien et québécois détaillé

L'accessibilité comme levier, pas seulement comme contrainte

La directive européenne a eu au moins un mérite : faire basculer l'accessibilité numérique du registre de la bonne volonté à celui de l'obligation. Pour autant, limiter la démarche à une conformité réglementaire reviendrait à passer à côté de son vrai intérêt. Un site accessible bénéficie indirectement à son référencement (la structure sémantique propre, les alternatives textuelles et la performance qu'impose la discipline d'accessibilité sont toutes des signaux que Google valorise), il est plus lisible pour tous les utilisateurs y compris ceux en situation temporaire de difficulté (bras cassé, environnement bruyant, fatigue visuelle), et il convertit généralement mieux.

Pour une PME, la mise en conformité n'est pas un chantier hors de portée. Un audit initial avec les outils gratuits, une dizaine de corrections ciblées, un engagement continu dans les nouveaux contenus suffisent à passer du rouge au vert dans la plupart des cas. Ce que nous conseillons à nos clients est d'aborder ce sujet comme n'importe quelle dimension qualité : une fois posées les bases, le maintien demande de la régularité plutôt que de gros efforts ponctuels.

Si vous vous interrogez sur le niveau d'accessibilité de votre site actuel ou sur ce que votre prochain projet devra prévoir, nous serons heureux de regarder cela ensemble. Un diagnostic rapide par écran partagé permet souvent de mesurer l'ampleur du chantier et de prioriser ce qui a le plus d'impact, avant d'engager un audit formel ou une refonte.

Publié le 20 avril 2026 · Par L'équipe MtoM

Questions fréquentes

Les WCAG sont les recommandations internationales publiées par le W3C. Le RGAA est le référentiel français qui en traduit les critères en méthodologie d'évaluation opérationnelle, avec des tests concrets applicables par un auditeur en France. Les WCAG définissent quoi faire, le RGAA explique comment le vérifier. Un site conforme RGAA 4.1 est conforme WCAG 2.1 AA.

Une TPE qui compte moins de 10 salariés et réalise moins de 2 millions d'euros de chiffre d'affaires ou de bilan total bénéficie d'une exemption pour ses services numériques. Mais cette exemption ne couvre pas toutes les situations : vendre en ligne des billets, des rendez-vous payants, des livres numériques peut faire basculer dans le périmètre. Au-delà du cadre légal, l'accessibilité reste un levier SEO et UX pertinent, même pour une TPE exemptée.

Dans la grande majorité des cas, non. Un audit initial, une dizaine de corrections ciblées sur les patterns récurrents (contraste, focus, labels, alt, structure) et une mise à jour du process éditorial suffisent à passer d'un site non conforme à partiellement conforme, voire totalement conforme. La refonte ne s'impose que si le site repose sur un socle technique très ancien ou sur un constructeur de contenu qui ignore les bonnes pratiques d'accessibilité.

Votre hébergeur n'est pas directement responsable de l'accessibilité du contenu publié, qui relève de votre responsabilité éditoriale et technique. Il joue en revanche un rôle indirect important : performance des pages, temps de chargement, stabilité du service. Un site lent ou instable est de facto moins accessible. Pour un site WordPress, un hébergeur spécialisé (Kinsta, WP Engine, O2Switch en France) fournit une base saine qui facilite l'atteinte des objectifs d'accessibilité.

Les outils dits de surcouche d'accessibilité, qui promettent une conformité automatique via un script JavaScript, sont à éviter. Ils ne corrigent pas les problèmes de fond (structure sémantique, labels, contrastes dans le design), ils ajoutent une couche d'interface qui complique souvent l'expérience des vrais utilisateurs de technologies d'assistance, et ils sont aujourd'hui en ligne de mire des associations de personnes handicapées et des régulateurs. L'IA est utile pour générer des descriptions alt à la volée, pour auditer du contenu, pour rédiger des résumés lisibles, mais elle ne remplace pas une démarche d'accessibilité structurelle.

La déclaration doit être publiée dès la mise en ligne du site dans le cadre réglementé, ou mise à jour lors d'une refonte significative. Elle n'a pas à attendre une conformité parfaite : elle peut (et doit) refléter honnêtement l'état actuel du site, avec mention des non-conformités connues et du calendrier de correction. Une déclaration honnête reconnaissant des limites est juridiquement plus sûre qu'une déclaration trop optimiste qui pourrait être contredite par un audit.

Vous avez un projet web?
Travaillons ensemble !

Nous sommes là pour vous accompagner dans la mise en place de votre projet web, de la première idée jusqu'à sa réalisation complète.