Rends ton site WordPress vraiment accessible. EAA, RGAA et WCAG, sans overlay

La vérité : WordPress n'est pas accessible par défaut

Un thème par blocs WordPress soigné comme Twenty Twenty-Four démarre mieux que beaucoup de sites, mais atteint rarement le WCAG 2.2 AA tout seul. Dès que tu construis avec Elementor, Divi ou Gutenberg, que tu laisses des plugins injecter du markup ou que tu ajoutes des images sans texte alternatif, des obstacles apparaissent que tes visiteurs, et le European Accessibility Act, n'acceptent pas.

Ce qui cloche souvent sur WordPress

• Les page builders produisent une soupe de div illisibleElementor et Divi imbriquent sections, colonnes et wrappers sur des dizaines de niveaux. Cette soupe de div n'a aucune sémantique, si bien qu'un lecteur d'écran perd la structure logique de ta page et ne lit que des fragments de texte épars.
• Markup de plugin sans nom accessibleLes sliders, pop-ups et formulaires issus de plugins injectent souvent des boutons et des champs sans label ni aria-label. Un utilisateur de lecteur d'écran n'entend alors que « bouton » et ne sait pas ce que fait l'action.
• Ordre des titres cassé par le builderLes page builders choisissent souvent les titres selon leur taille plutôt que leur sens, si bien que tu sautes d'un h2 directement à un h4. Les utilisateurs de lecteur d'écran naviguent par les titres et perdent le fil de ta page.
• Images de la médiathèque sans texte alternatifLes images de la médiathèque arrivent souvent dans ton thème sans texte alternatif, ou avec le nom du fichier comme alt, illisible pour les lecteurs d'écran et invisible pour Google.

À quoi ressemble une vraie correction

Prends un bouton-icône de ton bloc Elementor ou Gutenberg. Sans nom accessible, un utilisateur de lecteur d'écran n'entend que « bouton ». La correction tient en un seul attribut, pas de reconstruction :

<button class="elementor-button">
  <i class="icon-cart" aria-hidden="true"></i>
</button>

<button class="elementor-button"
  aria-label="<?php esc_attr_e( 'Bekijk winkelwagen', 'theme' ); ?>">
  <i class="icon-cart" aria-hidden="true"></i>
</button>

Ce que tu reçois

Avec un outil de reporting, tu paies la licence et tes développeurs pour corriger les erreurs. Avec Seviranta, la correction est incluse, pas de double facture.

Protège ta conversion et ta situation juridique

Une app qui colle une icône d'accessibilité par-dessus ton site WordPress est un risque pour ton activité. Les faits :

Mon thème est accessibility-ready. Ai-je fini ?

Non. Le tag dit que le thème satisfait aux exigences de base de l'équipe de revue ; WordPress dit lui-même que ce n'est pas une déclaration WCAG AA. Ton contenu, tes plugins et ton builder viennent par-dessus, et c'est là que se trouvent la plupart des constats.

Mon site WordPress doit-il respecter le RGAA ou l'EAA ?

Le RGAA (version 4.1.2, géré par la DINUM) est la méthode française : 106 critères qui couvrent les critères de succès de niveau A et AA du WCAG 2.1 via l'EN 301 549. L'obligation de l'article 47 de la loi 2005-102 vise le secteur public et les entreprises dont le chiffre d'affaires dépasse 250 M€, avec l'Arcom comme autorité de contrôle. Depuis le 28 juin 2025, si tu vends en ligne, ton site relève en plus de la transposition de l'EAA dans le Code de la consommation (article L. 412-13), avec une exception pour les micro-entreprises (moins de 10 personnes et 2 M€ de CA ou de bilan au maximum), sous le contrôle de la DGCCRF. Le RGAA évalue la page publiée, quel que soit l'outil de construction. Le tag accessibility-ready ne vaut pas conformité RGAA.

Puis-je faire la correction moi-même dans le Site Editor, ou faut-il mon développeur ?

Les couleurs, les titres, les textes alternatifs, la structure du menu et beaucoup de parties de template, tu peux les modifier toi-même dans l'éditeur ou le Site Editor. Le balisage issu de plugins ou d'un builder demande souvent un développeur : une surcharge de template dans un thème enfant, un filtre, ou un réglage du plugin. Notre rapport indique pour chaque constat où il se trouve, pour que tu saches qui peut s'en charger.

Un widget d'accessibilité pour WordPress suffit-il pour l'EAA ?

Non. Un widget pose une couche par-dessus ton site, mais ne répare pas le code sous-jacent et ne compte pas comme une conformité structurelle.

Mon checkout WordPress relève-t-il de l'EAA ?

Oui. Le checkout et la navigation font explicitement partie de l'obligation au titre du WCAG 2.1 AA.

Seviranta scanne-t-il aussi mes apps WordPress ?

Oui. On teste le HTML final généré, thème plus apps, comme le fait une autorité de contrôle.

Est-ce que ça va ralentir mon site WordPress ?

Non. On scanne de l'extérieur depuis nos serveurs en UE ; aucun script ne se pose sur ton site. 0 % d'impact sur ta vitesse de chargement et tes Core Web Vitals.