WCAG et accessibilité web : ce que votre site doit respecter en 2026

L'accessibilité web, c'est un peu le casque de vélo du web. Tout le monde sait que c'est important. Presque personne ne le met spontanément.

Dans la plupart des projets, c'est le sujet qui arrive en dernier dans la conversation, juste avant la mise en ligne, quand le budget est déjà consommé et que tout le monde est fatigué.

Le problème, c'est que depuis juin 2025, ce n'est plus vraiment une option. L'European Accessibility Act est entré en vigueur dans toute l'Union européenne. Pour la première fois, les obligations d'accessibilité numérique s'appliquent aux entreprises privées, pas seulement aux institutions publiques. Ce changement est fondamental, et il concerne directement la façon dont on conçoit les sites web aujourd'hui.

Cet article explique ce que sont les WCAG, ce que la loi impose concrètement, et comment Webflow se positionne sur le sujet.

C'est quoi exactement les WCAG

WCAG signifie Web Content Accessibility Guidelines. Ce sont des recommandations techniques publiées par le W3C, l'organisme international qui définit les standards du web. L'objectif : rendre les contenus web utilisables par tout le monde, y compris les personnes en situation de handicap.

Et "tout le monde", ça représente vraiment beaucoup de monde.

Une personne aveugle qui navigue avec un lecteur d'écran comme NVDA ou VoiceOver. Une personne qui utilise uniquement le clavier parce qu'elle ne peut pas utiliser une souris. Une personne daltonienne qui ne distingue pas le rouge du vert. Une personne dyslexique qui lutte contre une mise en page trop dense. Une personne âgée qui a grossi le texte à 200% dans son navigateur.

L'OMS estime que 1,3 milliard de personnes dans le monde vivent avec un handicap. Ce n'est pas une niche. Et chacune d'entre elles peut essayer d'accéder à un site aujourd'hui.

Les WCAG existent depuis 1999. La version 2.1 de 2018 a posé les bases légales modernes. La version 2.2, publiée en octobre 2023 et mise à jour en décembre 2024, est aujourd'hui le standard de référence. C'est elle qui compte.

Les 4 principes de base

Toute la logique des WCAG repose sur quatre piliers, résumés sous l'acronyme POUR.

Perceptible. Chaque utilisateur doit pouvoir percevoir votre contenu avec au moins un de ses sens. En pratique, ça veut dire des textes alternatifs sur les images, des sous-titres pour les vidéos, un contraste suffisant entre le texte et le fond (minimum 4,5:1 pour le texte courant), et ne jamais transmettre une information uniquement par la couleur.

Opérable. L'interface doit fonctionner quelle que soit la façon dont l'utilisateur navigue. Navigation complète au clavier, focus visibles à chaque étape, animations contrôlables. C'est là que beaucoup de sites ont des problèmes qu'on ne voit pas à l'écran mais qui bloquent réellement certains utilisateurs.

Compréhensible. Le contenu doit être compréhensible. La langue de la page déclarée dans le HTML, des comportements prévisibles, des messages d'erreur qui expliquent vraiment ce qui ne va pas. Pas juste un champ rouge qui s'agite.

Robuste. Le code doit fonctionner avec les technologies d'assistance actuelles et futures. HTML sémantique, attributs ARIA corrects, compatibilité avec les lecteurs d'écran. Un code propre, quoi.

Les niveaux A, AA et AAA

Les WCAG définissent trois niveaux de conformité.

Le niveau A supprime les obstacles les plus bloquants. C'est le strict minimum, et il ne suffit pas légalement.

Le niveau AA est la référence légale en Europe. L'EAA et le RGAA français se basent sur ce niveau. C'est la cible.

Le niveau AAA est le plus exigeant. Pas toujours atteignable sur l'ensemble d'un site, mais recommandé sur les contenus les plus critiques.

Si on devait résumer en une phrase : l'objectif à atteindre, c'est WCAG 2.2 niveau AA. Le reste découle de là.

Ce que WCAG 2.2 a changé

La version 2.2 introduit 9 nouveaux critères par rapport à la 2.1. Les plus importants à retenir dans la pratique :

Focus Not Obscured (AA). L'élément actif au clavier ne peut pas être masqué par un élément fixe, comme un sticky header ou un bandeau de cookies. Beaucoup de designs populaires sont directement concernés.

Dragging Movements (AA). Toute interaction de type glisser-déposer doit avoir une alternative. Un carrousel sans boutons de navigation ? C'est un problème.

Target Size (AA). Les zones cliquables doivent faire au minimum 24x24 pixels CSS. Les petits liens icon-only ou les boutons trop proches les uns des autres rentrent dans cette case.

Consistent Help (A). Si un site propose un chat, un formulaire de contact ou un numéro de téléphone, il doit apparaître au même endroit sur toutes les pages.

Redundant Entry (A). Dans un formulaire multi-step, on ne redemande pas deux fois la même information à l'utilisateur.

Accessible Authentication (AA). Les CAPTCHA cognitifs ne peuvent pas être l'unique barrière d'accès. Il doit exister une alternative.

À noter aussi : le critère 4.1.1 Parsing a été retiré dans WCAG 2.2. Les navigateurs modernes gèrent suffisamment bien les erreurs HTML pour que ce critère soit devenu obsolète.

Ce que la loi dit maintenant

L'EAA, la Directive européenne 2019/882, est pleinement applicable depuis le 28 juin 2025. Elle a mis fin à quelque chose d'important : l'idée que l'accessibilité numérique, c'était l'affaire des administrations. Maintenant, les entreprises privées sont dans la boucle.

Sont concernés : les sites e-commerce, les services SaaS, les plateformes de réservation et de billetterie, les portails bancaires, et globalement tout service numérique proposé aux consommateurs européens. Le champ est délibérément large.

En Belgique, les sanctions peuvent atteindre 200 000 euros par infraction. Ce n'est pas une menace théorique. En 2024, une compagnie aérienne espagnole a été condamnée à 90 000 euros d'amende et interdite de fonds publics pendant six mois pour un site non accessible. C'était avant l'EAA.

Les institutions publiques belges, elles, sont sous obligation d'accessibilité depuis 2021. En 2025, plus de 180 sites fédéraux ont été audités par le Service fédéral de l'Accessibilité Numérique.

Une chose concrète à retenir : si un site a été modifié après le 28 juin 2025, il entre dans le champ d'application. Et "modifié", ça peut vouloir dire n'importe quelle mise à jour de contenu ou de fonctionnalité. La période de transition est terminée.

La réalité du web en 2026

WebAIM publie chaque année une analyse des erreurs d'accessibilité sur les sites les plus visités du web. En 2023, 98% des sites audités avaient au moins une erreur d'accessibilité. 98%.

Et les erreurs les plus fréquentes restent les mêmes depuis des années : images sans attribut alt, contrastes insuffisants, liens qui disent "cliquez ici" ou "en savoir plus", champs de formulaire sans label, structure de titres incohérente.

Ce ne sont pas des bugs complexes à corriger. Ce sont des oublis de conception qui s'accumulent parce que personne n'y pense au bon moment. Quand l'accessibilité est traitée en correction après coup, elle coûte en moyenne 3 à 5 fois plus cher que si elle avait été intégrée dès la phase de design.

Comment Webflow gère l'accessibilité

Webflow a fait des progrès réels sur ce sujet, et la plateforme offre des outils natifs qui facilitent vraiment le travail. Mais elle ne rend pas un site conforme automatiquement. Ce serait trop beau.

-> Le panneau Audit dans le Designer détecte les problèmes les plus courants : images sans alt, boutons sans label, liens vides. C'est un bon filet de sécurité, pas un outil d'audit complet.

-> Vision Preview simule différents types de déficiences visuelles : daltonisme rouge-vert, bleu-jaune, achromatopsie, vision floue. On voit le site comme certains utilisateurs le voient vraiment.

-> Text Zoom Preview vérifie que la mise en page tient quand le texte est grossi à 200%. C'est une exigence directe des WCAG, et beaucoup de sites la brisent avec des overflow cachés ou des grilles trop rigides.

-> Les attributs ARIA personnalisés s'ajoutent directement dans les réglages d'élément, sans toucher au code. Pour les composants comme les onglets, les accordéons ou les modales, c'est indispensable.

-> La structure sémantique HTML est contrôlable depuis le Designer. Choisir la bonne balise (H1, H2, nav, main, footer...) se fait sans écrire une seule ligne de code.

Un point important sur l'ARIA : une étude WebAIM montre que les pages avec des attributs ARIA mal implémentés ont en moyenne 34% d'erreurs supplémentaires par rapport aux pages sans ARIA. Ce n'est pas un détail. Mieux vaut une implémentation soignée qu'une implémentation hasardeuse.

La checklist qu'on applique sur nos projets

Ce sont les points vérifiés systématiquement avant toute mise en ligne.

Structure et sémantique

• Langue déclarée (html lang="fr" ou "en")
• Un seul H1 par page, hiérarchie cohérente jusqu'au H6
• Balises sémantiques utilisées : nav, main, header, footer, aside
• Titre de page unique et descriptif pour chaque URL

Images et médias

• Chaque image informative a un alt descriptif et utile
• Les images décoratives ont alt="" ou aria-hidden="true"
• Les vidéos ont des sous-titres ou une transcription

Navigation

• Navigation complète au clavier testée (Tab, Shift+Tab, Enter, Escape)
• Focus visible à tout moment, non masqué par le sticky header
• Lien "Aller au contenu principal" en début de page
• Texte de lien descriptif, jamais "cliquez ici"

Formulaires

• Chaque champ a un label associé correctement
• Messages d'erreur explicites et accessibles
• Pas de CAPTCHA sans alternative

Design et contraste

• Contraste texte/fond minimum 4,5:1 pour le texte courant
• L'information n'est jamais transmise uniquement par la couleur
• Zones cliquables d'au moins 24x24 px (critère WCAG 2.2)
• Pas d'animation automatique sans contrôle utilisateur

Code et ARIA

• HTML valide et sémantique
• Attributs ARIA utilisés avec parcimonie et correctement
• Les composants interactifs personnalisés ont les bons rôles

Accessibilité et SEO, c'est la même logique

Google lit un site web de la même façon qu'un lecteur d'écran. Il suit la structure HTML, analyse les textes alternatifs, vérifie la navigabilité, lit les labels. Un site accessible est un site que Google comprend mieux.

Les balises alt alimentent le SEO image. La hiérarchie des titres structure le contenu pour les crawlers. Les liens descriptifs améliorent l'indexation des pages qu'ils pointent. Un HTML propre améliore les Core Web Vitals. Ce n'est pas une coïncidence, c'est la même rigueur appliquée aux deux disciplines en même temps.

Des études montrent que les sites qui investissent dans l'accessibilité voient en moyenne +20% sur leurs taux de conversion globaux. Pas parce que l'accessibilité est magique, mais parce qu'un site accessible est généralement mieux structuré, plus lisible et plus facile à utiliser pour tout le monde.

Ce qu'il faut retenir

L'accessibilité web n'est pas un sujet réservé aux grandes entreprises ou aux organismes publics. Depuis juin 2025, elle concerne les entreprises privées qui ont un site, une boutique en ligne, ou un service numérique.

Les WCAG 2.2 niveau AA sont le standard de référence. Ils couvrent la structure du contenu, la navigation, les contrastes, les formulaires, les médias, et les composants interactifs. Webflow permet d'atteindre ce niveau sans sortir du no-code, à condition de travailler correctement dès la conception.

Deux choses à éviter absolument : traiter l'accessibilité en fin de projet, et faire confiance aux overlays d'accessibilité. Ces widgets qui prétendent rendre un site conforme en un clic ne constituent pas une preuve de conformité légale. Le W3C lui-même les a mis en cause. L'accessibilité se construit dans le code, pas en surface.

Le bon moment pour s'en occuper, c'était il y a six mois. Le deuxième bon moment, c'est maintenant.

Les sources qui font référence sur le sujet

W3C WAI : la documentation officielle des WCAG, traduite en français depuis juin 2025.

Access42 : la référence francophone sur l'accessibilité numérique. Ils ont coordonné la traduction française officielle des WCAG 2.2.

Belgian Web Accessibility : le portail officiel belge, avec les obligations locales et les ressources pour se mettre en conformité.

WebAIM : les analyses annuelles sur l'état de l'accessibilité web, avec des données chiffrées et des études de cas.

Webflow Accessibility : la documentation officielle Webflow sur les outils d'accessibilité intégrés dans le Designer.

RGAA : le référentiel français basé sur les WCAG, utile pour les projets côté France.