Aller au contenu principal
Accessio

Accessibilité Webflow : RGAA, WCAG et audit

Webflow n'est ni conforme ni non conforme au RGAA par nature. La plateforme permet de construire un site conforme, car elle expose les balises HTML, les attributs ARIA et l'ordre du focus. La conformité dépend donc du travail du concepteur, et se démontre uniquement par un audit du site publié sur les 106 critères du RGAA.

Vous voulez rendre un site Webflow accessible et viser la conformité RGAA et European Accessibility Act ? Webflow offre un contrôle quasi total sur le HTML et le CSS produits, ce qui en fait une plateforme au fort potentiel pour l'accessibilité — à condition de maîtriser la sémantique et les composants ARIA. À l'inverse, la liberté créative peut conduire à un site qui « rend bien » à l'œil tout en restant opaque pour les lecteurs d'écran, la navigation au clavier ou les outils d'assistance. Un audit accessibilité Webflow en profondeur reste donc la seule façon de savoir si votre site tient réellement ses engagements : aucun vérificateur intégré ni revendeur de template ne suffit à démontrer la conformité RGAA 4.1.2 ou WCAG 2.1 AA imposée par l'EAA depuis le 28 juin 2025.

Webflowest-il accessible par défaut ?

Webflow peut produire des sites très accessibles, mais il ne le fait pas tout seul. Parce que l'outil expose directement les balises HTML, les classes, les composants et les interactions, la qualité du résultat dépend entièrement des choix du concepteur : balisage sémantique, hiérarchie de titres, gestion du focus, rôles ARIA. Un projet bien structuré, avec une vraie hiérarchie de titres et des composants natifs, sera propre, tandis qu'un design fait uniquement à coups de div génériques (le fameux « div-soup ») sera inaccessible aux technologies d'assistance. Webflow fournit un vérificateur interne et des paramètres d'accessibilité, mais ces outils restent indicatifs : ils donnent une photographie partielle sans se substituer à un audit humain couvrant les 50 critères WCAG 2.1 AA.

Les atouts

  • Contrôle direct des balises HTML (h1, h2, button, nav, main) et des rôles ARIA, ce qui permet un code réellement sémantique — une fois la discipline acquise côté designer.
  • Vérificateur d'accessibilité intégré + paramètres dédiés (attributs alt, ordre du focus, focus visible) pour piloter l'accessibilité dès le design, sans attendre la livraison.
  • Possibilité de baliser correctement boutons, liens, régions et formulaires sans dépendre d'un thème tout fait : le designer garde la main sur le markup de A à Z.
  • Gestion fine des animations et respect natif de la préférence système `prefers-reduced-motion`, précieuse pour viser le critère WCAG 2.3.3 (Animation issue).
  • Communauté francophone RGAA active (forums, ressources, templates « accessibility-friendly ») qui produit régulièrement du contenu pour aider les concepteurs à cadrer leur démarche de mise en conformité.

Les points de vigilance

  • Design construit à partir de div génériques (« div-soup ») qui produit un code sans sémantique si le concepteur n'attribue pas les bonnes balises — premier écueil rencontré dans la majorité des audits.
  • Hiérarchie de titres souvent dictée par le rendu visuel et non par la structure : sauts de niveau (H2 puis H4), H1 dupliqués accidentellement, ou inversions Hn/css.
  • Interactions Webflow personnalisées fréquemment non opérables au clavier (Esc qui ne ferme pas, Tab qui sort du contexte) et sans `aria-expanded` / `aria-controls` correctement gérés.
  • Composants riches (sliders, tabs, dropdowns, lightbox) assemblés à la main qui manquent souvent des rôles ARIA et des états attendus par les lecteurs d'écran (NVDA, JAWS, VoiceOver).
  • Aucun garde-fou par défaut : tout réglage d'accessibilité est optionnel et facile à oublier dans la précipitation d'un projet rapide ou d'une refonte marketing.
  • Templates et assets tiers (icônes, illustrations, animations Lottie, fichiers importés) qui peuvent embarquer leur propre code non accessible et échapper au contrôle visuel du designer.

Les erreurs d'accessibilité les plus fréquentes sur Webflow

Hiérarchie de titres sautée pour coller au visuel

Sur Webflow, on choisit souvent le niveau de titre en fonction de la taille de police voulue, pas de la structure du document. Résultat : un H1 suivi directement d'un H3, ce qui casse le plan du document pour les lecteurs d'écran (RGAA 9.1). La règle est de fixer le niveau selon la logique de contenu, puis d'ajuster la taille avec une classe CSS.

À éviter

<h1>Titre</h1>
<h3>Sous-titre</h3>

À privilégier

<h1>Titre</h1>
<h2 class="style-petit">Sous-titre</h2>

Div-soup au lieu des balises sémantiques

Par défaut, chaque bloc glissé dans le canevas est une div générique. Un site construit uniquement de div est opaque pour les technologies d'assistance, qui ne trouvent ni régions ni repères de navigation. Dans le panneau Settings > Tag, attribuez explicitement Nav, Main, Section, Header et Footer aux conteneurs concernés pour restaurer la structure sémantique.

À éviter

<div class="header">…</div>
<div class="content">…</div>
<div class="footer">…</div>

À privilégier

<nav>…</nav>
<main>…</main>
<footer>…</footer>

Interactions hover ou scroll sans équivalent clavier

Les interactions Webflow déclenchées au survol (hover) ou au défilement (scroll) n'exposent aucun équivalent clavier ni tactile. Un menu qui n'apparaît qu'au survol, ou un contenu révélé au scroll, devient inatteignable pour un utilisateur qui navigue au clavier ou sur mobile. Chaque interaction porteuse d'information doit avoir un déclencheur au focus ou au clic (RGAA 7.1).

Composant Lightbox natif au comportement instable

La Lightbox native de Webflow ne piège pas le focus dans la fenêtre ouverte : la tabulation continue derrière, sur le contenu masqué. La fermeture par la touche Échap dépend du template et n'est pas fiable. Pour une modale conforme (RGAA 7.1, WCAG 4.1.2), il faut soit reconstruire le composant avec un vrai piège à focus et un role dialog, soit vérifier finement chaque comportement.

Contrastes insuffisants des templates Marketplace

Beaucoup de templates de la Marketplace privilégient un rendu épuré (texte gris clair, boutons pastel) dont le rapport de contraste tombe sous le seuil de 4.5:1 exigé en WCAG 2.1 AA (RGAA 3.2). L'Accessibility Audit intégré au Designer détecte ces contrastes trop faibles, ainsi que les images sans alternative : c'est un premier filet, à compléter par un contrôle manuel.

Formulaires sans message d'erreur par champ

Le Form Block natif lie correctement chaque label à son champ, mais il ne fournit pas de message d'erreur associé champ par champ. Un formulaire qui affiche une erreur générale en haut de page, sans relier le message au champ fautif via aria-describedby, laisse l'utilisateur de lecteur d'écran sans indication (RGAA 11.10). Il faut ajouter ces liaisons à la main dans les attributs personnalisés.

Les critères RGAA à surveiller en priorité sur Webflow

Webflow RGAA : ce que la conformité implique concrètement

Le RGAA (Référentiel général d'amélioration de l'accessibilité) est le référentiel français : 106 critères qui déclinent le niveau AA des WCAG 2.1, repris par la norme européenne EN 301 549. Un site Webflow s'évalue exactement comme n'importe quel site : sur le HTML publié, jamais sur l'outil qui l'a produit. Webflow, éditeur américain, ne délivre aucune conformité RGAA et aucun certificat : la déclaration d'accessibilité reste à produire par l'éditeur du site, après audit.

Sur le terrain, ce que Webflow met à disposition (choix des balises dans Settings > Tag, attributs alt, ordre du focus, vérificateur intégré) couvre les prérequis, pas la conformité. Les écarts relevés le plus souvent en audit RGAA d'un site Webflow sont détaillés plus haut : structure en div sans sémantique, hiérarchie de titres calée sur le visuel, interactions sans équivalent clavier, composants riches sans rôles ARIA, contrastes de templates sous le seuil de 4.5:1.

La démarche de conformité RGAA sur Webflow suit le parcours standard : audit des 106 critères sur un échantillon représentatif de pages, correction des non-conformités dans le Designer, puis publication de la déclaration d'accessibilité avec le taux de conformité mesuré. Aucune de ces trois étapes n'est automatisable par la plateforme.

Webflow ARIA : où se règlent les rôles et les états

Webflow n'écrit pas l'ARIA à votre place. Chaque attribut se pose à la main dans le panneau de l'élément (Element Settings > Custom attributes) : c'est là que se déclarent role, aria-expanded, aria-controls, aria-label ou aria-live, car aucun composant assemblé manuellement ne les reçoit par défaut. Les composants natifs (Navbar, Tabs, Dropdown) embarquent une partie des rôles attendus, mais dès qu'un composant est reconstruit en div pour des raisons de design, tout est à re-déclarer.

Le cas le plus fréquent en audit : un menu déroulant fabriqué avec une interaction Webflow. Son déclencheur doit porter aria-expanded, et la valeur doit basculer à l'ouverture. Or une interaction Webflow anime des styles, elle ne modifie pas les attributs : la mise à jour demande un embed de code personnalisé. Même logique pour un système d'onglets maison, muet pour un lecteur d'écran sans role="tab" et aria-selected, là où le composant Tabs natif expose déjà un tablist correct.

La première règle d'ARIA vaut aussi sur Webflow : pas d'ARIA vaut mieux qu'un mauvais ARIA. Une balise button native n'a besoin d'aucun role ajouté, alors qu'un div avec role="button" doit recevoir en plus tabindex="0" et la gestion des touches Entrée et Espace. Commencez par la bonne balise dans Settings > Tag, et n'ajoutez l'ARIA qu'en complément, jamais en substitut (RGAA 7.1, WCAG 4.1.2).

Webflow WCAG : le niveau 2.1 AA, ce qui est couvert, ce qui reste à faire

La cible légale est la même pour tout le monde : le niveau AA des WCAG 2.1, repris par la norme européenne EN 301 549 et décliné en France dans les 106 critères du RGAA. Un site Webflow qui satisfait les WCAG 2.1 AA est donc conforme sur le volet technique du RGAA : les deux référentiels mesurent les mêmes exigences, seuls le découpage et le cadre juridique changent.

Ce que Webflow met à votre portée : le contrôle complet du markup, les attributs alt, l'ordre du focus, le respect de prefers-reduced-motion, et un vérificateur intégré qui repère contrastes insuffisants et images sans alternative. Ce qui reste entièrement à votre charge : la pertinence réelle des alternatives, le comportement clavier des composants interactifs, les contrastes des templates achetés, les PDF téléchargeables et le sous-titrage des vidéos.

En pratique, environ 30 % des critères WCAG se vérifient automatiquement, le reste exige un test humain au clavier et au lecteur d'écran. Ce ratio n'est pas propre à Webflow, il vaut pour toutes les plateformes : Webflow facilite le travail de conformité, il ne le supprime pas.

Checklist pour Webflow

Un thème ou une extension « accessible » ne suffit jamais à rendre un site conforme. Seul un audit du site réel — avec vos contenus, vos modules et vos parcours — permet de viser la conformité (déclaration d'accessibilité, schéma pluriannuel). En savoir plus sur l'audit.

Testez l’accessibilité de votre site, gratuitement

Vérifiez en moins d'une minute les premiers écarts d'accessibilité de votre site Webflow.

Lancer le diagnostic gratuit

Pour aller plus loin

L'accessibilité sur les autres outils no-code

Les écarts RGAA diffèrent d'une plateforme à l'autre. Voici le même état des lieux pour les solutions comparables à Webflow.

Questions sur l'accessibilité Webflow

Webflow permet-il de créer un site conforme RGAA ?
Oui, à condition que le concepteur maîtrise la sémantique HTML, les rôles ARIA et la gestion du focus. Webflow n'impose aucune limite structurelle pouvant empêcher la conformité RGAA 4.1.2 : un projet rigoureux sur Webflow sera conforme, un projet bâclé sera inaccessible. Il n'existe pas de raccourci automatique : l'accessibilité dépend de la qualité du markup, point.
Comment faire un audit accessibilité Webflow ?
Un audit accessibilité Webflow complet combine : (1) un scan automatique de pré-tri pour repérer les écarts évidents (axe-core ou équivalent), (2) une revue manuelle de chaque critère WCAG 2.1 AA avec un lecteur d'écran et une navigation 100 % clavier, (3) un examen des composants dynamiques du site (sliders, modales, formulaires). Le diagnostic gratuit Accessio fournit le panorama automatisé, mais pour viser la conformité un audit humain reste indispensable — il produit un rapport critère-par-critère et un plan d'action priorisé.
Quel budget prévoir pour un audit accessibilité Webflow ?
Notre grille est publiée : 2 500 € HT pour un site vitrine de moins de 20 pages (6 à 8 pages auditées, 2 à 2,5 jours), 4 000 € HT pour un site standard ou e-commerce à tunnel unique (10 pages, 3 jours), 6 500 à 9 000 € HT pour un e-commerce complexe ou une marketplace. Le devis est envoyé sous 48 h après cadrage sur votre site réel. Ces montants couvrent l'audit des 106 critères RGAA avec rapport et plan d'action, pas les corrections elles-mêmes.
Le vérificateur d'accessibilité intégré à Webflow suffit-il ?
Non. C'est un bon outil de pré-tri qui signale les contrastes insuffisants, les liens sans intitulé, certaines erreurs de sémantique. Il couvre environ 30 % des critères WCAG. Pour viser la conformité, l'audit humain est indispensable : le vérificateur ne sait pas évaluer la pertinence d'un `alt`, la logique d'un parcours clavier, la qualité des composants ARIA, ni l'expérience réelle d'un lecteur d'écran sur un parcours d'achat.
Faut-il un freelance ou une agence pour rendre un site Webflow conforme ?
Pour un site court (1 à 5 pages) sans composant dynamique complexe, un freelance Webflow sensibilisé au RGAA peut suffire. Pour un site marchand, un portail avec comptes client, ou un site institutionnel intégrant des plugins tiers, une agence spécialisée accessibilité est préférable : elle pourra auditer chaque parcours critique et accompagner les corrections directement dans le CMS. Dans tous les cas, le livrable attendu est identique : rapport RGAA, déclaration d'accessibilité et schéma pluriannuel.
Mon site Webflow est-il concerné par l'European Accessibility Act ?
Si vous vendez des produits ou des services en ligne à des particuliers dans l'Union européenne et que vous n'êtes pas une micro-entreprise (au sens EAA : < 10 personnes ET CA ≤ 2 M€), oui, Webflow n'exempte pas de l'obligation. Vous devez atteindre le niveau WCAG 2.1 AA sur l'ensemble du site et publier une déclaration d'accessibilité. À défaut, vous encourez les sanctions EAA françaises : 7 500 € (premier manquement) à 15 000 € (récidive), sous contrôle de la DGCCRF.