Accessibilité Webflow : vérifier les parcours essentiels

Commencer par les tâches que les visiteurs doivent réussir

Vérifier l’accessibilité d’un site Webflow commence par une question concrète : une personne peut-elle comprendre une offre, naviguer et envoyer une demande avec les moyens qu’elle utilise ? Le contrôle doit porter sur le parcours, ses contenus et ses interactions, au-delà de l’apparence de la page.

Vous pouvez réaliser une première vérification pour repérer des obstacles et transmettre des corrections exploitables. Cette démarche ne constitue pas un audit de conformité ni une certification. Le W3C précise que ses premières vérifications d’accessibilité ne couvrent qu’une partie des problèmes : un site peut les réussir et conserver des obstacles importants.

Choisissez des tâches utiles à votre activité : atteindre une offre depuis le menu, consulter un contenu et compléter un formulaire. Notez les pages, les modèles et les composants rencontrés. Incluez des états que la simple consultation ne montre pas : menu ouvert, erreur de saisie, message de réussite et fenêtre de dialogue.

Prévoyez un environnement de test identifié et des données fictives, avec l’accord de la personne qui gère les formulaires. L’équipe doit pouvoir contrôler la réception d’un essai sans le confondre avec une demande commerciale réelle.

Comprendre ce que l’Audit panel Webflow vérifie

Le panneau Audit de Webflow signale notamment quatre catégories de problèmes d’accessibilité : alternatives textuelles manquantes, contenu de lien non descriptif, niveaux de titres sautés et identifiants d’éléments dupliqués. Sa documentation officielle en décrit le périmètre et les limites.

Le panneau ne vérifie pas les problèmes à l’intérieur des composants. Le contrôle des alternatives comporte aussi des exclusions, notamment les images liées au CMS et certains médias Lightbox. Les contrastes de texte se contrôlent séparément, avec le vérificateur du sélecteur de couleur. Une absence d’alerte ne démontre donc pas l’accessibilité du site.

Utilisez ces alertes comme des points de départ : identifiez l’élément concerné, comprenez son rôle et vérifiez le résultat après correction. Masquer une alerte ne corrige pas l’obstacle. Pour les contenus réutilisés et les pages CMS, examinez le modèle commun et des exemples de contenus réels.

Webflow documente également des éléments avec prise en charge du clavier et des lecteurs d’écran. Certains nécessitent notamment un style de focus visible. Le comportement d’un composant natif ne valide pas les styles, les contenus, les scripts ajoutés ou son intégration au parcours.

Parcourir le site au clavier et suivre le focus

Le focus indique l’élément qui reçoit l’action du clavier. Ouvrez la page, placez-vous dans la barre d’adresse puis parcourez le site sans utiliser la souris. Tab permet généralement d’avancer entre les éléments interactifs ; Maj + Tab de revenir. Activez les liens avec Entrée et les boutons selon leur comportement attendu, notamment avec Entrée ou Espace.

Vérifiez que vous voyez toujours où vous êtes, que l’ordre reste compréhensible et que les éléments utiles sont atteignables. Repérez un bouton ignoré, un lien masqué sous un élément fixe, un menu impossible à refermer ou une zone dont vous ne pouvez plus sortir. Notez l’action exacte qui provoque le blocage.

Un contour présent sur un seul état ne suffit pas si le visiteur le perd ensuite dans le menu ou dans un formulaire. Contrôlez aussi le retour dans la page après la fermeture d’une interaction. Les réglages du navigateur et du système peuvent influencer la navigation clavier : consignez-les plutôt que d’attribuer immédiatement toute différence au site.

Vérifier que le contenu reste compréhensible

Titres, liens et agrandissement

Lisez les titres dans leur ordre : permettent-ils de comprendre les parties de la page ? Un texte affiché en gros peut rester un simple paragraphe dans le code. Faites vérifier la structure réelle lorsque le rendu visuel ne permet pas de conclure. Le W3C distingue la clarté des titres et leur identification dans le code.

Examinez les liens dans leur contexte. Leur libellé doit aider à comprendre la destination ou l’action, particulièrement dans une liste de cartes répétées. Agrandissez ensuite le texte dans le navigateur : vérifiez que les phrases, les boutons et les messages ne sont pas coupés ou superposés et que le parcours reste réalisable. Consignez le niveau utilisé et la largeur de fenêtre. Le critère W3C sur l’agrandissement du texte explique ce contrôle de contenu et de fonctionnement.

Pour les contrastes, utilisez une mesure adaptée aux couleurs réellement affichées, en examinant aussi les états de focus et d’erreur. Une couleur jugée lisible à l’œil sur votre écran ne suffit pas à conclure. Si un résultat est ambigu ou dépend d’un arrière-plan complexe, transmettez-le pour examen plutôt que de déclarer le contrôle réussi.

Médias et informations utiles

Repérez les informations qui ne sont disponibles que dans une image, une vidéo ou un son. Il faut examiner les alternatives adaptées à leur rôle, les sous-titres et les autres moyens d’accéder au message. Une alternative présente peut rester inadaptée ; la vérification demande de comprendre ce que le média apporte. Le tutoriel W3C sur les images explique comment ce rôle guide le choix d’une alternative.

Attribuez cette revue à la personne responsable des contenus et des médias. Le contrôle d’une page ne doit pas oublier les médias ajoutés dans un article ou dans un composant partagé. Gardez dans le compte rendu les éléments à revoir et leur emplacement précis.

Tester le formulaire dans ses différents états

Avant la saisie, les champs doivent être compréhensibles : libellé, information demandée, indication des champs requis et consignes utiles. Vérifiez qu’ils restent identifiables lorsque vous commencez à écrire ; un texte d’exemple qui disparaît ne remplace pas à lui seul un libellé. Le guide W3C des libellés de formulaire précise leur association aux contrôles.

Provoquez ensuite une erreur de manière contrôlée. Le visiteur peut-il identifier le champ concerné, comprendre le problème et le corriger au clavier ? Une bordure rouge seule n’explique pas quoi faire. Après correction, contrôlez le message de réussite et, avec le responsable du système, la réception de l’essai.

Le guide W3C sur les messages de formulaire explique l’intérêt de retours clairs sur les erreurs et la réussite, y compris pour les technologies d’assistance. La présence visuelle d’un message ne prouve pas son annonce par un lecteur d’écran : cette partie nécessite un contrôle adapté.

Trois fiches pour préparer une vérification reproductible

Les fiches suivantes portent sur un site fictif. Elles donnent les actions, les résultats attendus et un exemple de constat possible ; aucun test Gemme Studio ou client n’est présenté. Les observations illustratives servent à montrer comment écrire un compte rendu, et les statuts restent « à tester ».

Fiche 1 — Atteindre une offre depuis le menu

Parcours et périmètre : accueil /, menu principal, page /services/accompagnement. Objectif : consulter l’offre sans souris.

Actions à réaliser : partir de la barre d’adresse ; avancer au clavier jusqu’au menu ; ouvrir la rubrique si nécessaire ; atteindre le lien de l’offre ; l’activer ; retrouver le contenu principal et revenir dans la navigation.

Résultat attendu : le focus reste visible, l’ordre est logique et le lien permet d’atteindre l’offre. L’ouverture du menu ne rend pas les autres actions indispensables inaccessibles.

Constat pédagogique possible : « Après l’ouverture du menu, le lien de l’offre reçoit le focus, mais aucun indicateur visible ne permet de le repérer. » C’est une situation fictive à confirmer ou remplacer par l’observation réelle.

Environnement : URL et version de préproduction prévues ; navigateur, version, système, largeur et réglages clavier à renseigner. Preuve : courte capture du parcours avec les touches utilisées à joindre après essai. Responsable : intégrateur du menu, avec validation par le chef de projet. Statut : à tester, aucun résultat acquis.

Fiche 2 — Comprendre et corriger une erreur de formulaire

Parcours et périmètre : /contact, formulaire de demande et état de confirmation. Objectif : corriger une adresse e-mail invalide puis terminer un envoi de test autorisé.

Actions à réaliser : atteindre les champs au clavier ; lire les consignes ; saisir une valeur volontairement invalide ; déclencher la validation ; identifier l’erreur ; revenir au champ ; corriger avec les données de test convenues ; soumettre ; vérifier le retour et la réception.

Résultat attendu : le champ et le problème sont identifiables, une consigne explique la correction, le focus permet de reprendre la saisie et la réussite est compréhensible. La réception est contrôlée séparément par le responsable du formulaire.

Constat pédagogique possible : « La bordure change de couleur, mais aucun texte n’explique le format attendu ; l’utilisateur doit deviner la correction. » Cette observation n’a pas été réalisée sur un site réel.

Environnement : version du formulaire, navigateur, système et mode de validation à renseigner ; lecteur d’écran et réglages à noter si ce contrôle complémentaire est effectué. Preuve : états avant erreur, après erreur et après correction, sans donnée personnelle. Responsable : intégrateur du formulaire et responsable de réception. Statut : à tester.

Fiche 3 — Ouvrir et fermer une fenêtre de dialogue

Parcours et périmètre : /services/accompagnement, bouton ouvrant une fenêtre modale avec des informations complémentaires. Objectif : lire puis refermer cette fenêtre au clavier.

Actions à réaliser : atteindre le bouton ; ouvrir la fenêtre ; repérer le focus dans son contenu ; parcourir ses actions dans les deux sens ; fermer avec Échap ; vérifier le retour au bouton déclencheur ou à un point logique du parcours. Refaire l’ouverture et essayer aussi le bouton de fermeture.

Résultat attendu : lorsque la fenêtre est modale, le focus reste dans son périmètre tant qu’elle est ouverte. La fermeture est possible et le visiteur retrouve un point de reprise cohérent. Ce comportement suit le modèle de dialogue modal du W3C ; il ne doit pas être appliqué indistinctement à tous les composants.

Constat pédagogique possible : « Après fermeture, le focus revient au début de la page au lieu du déclencheur, ce qui oblige à reparcourir la navigation. » Il s’agit d’un exemple fictif de description.

Environnement : version du composant, navigateur, système et éventuelle technologie d’assistance à renseigner. Preuve : séquence ouverture, déplacement et fermeture avec la position du focus. Responsable : intégrateur du composant partagé. Statut : à tester.

Contrôler les mouvements et les modèles partagés

Activez la préférence de réduction des animations de votre système, puis reprenez les tâches importantes. Vérifiez si les déplacements non essentiels sont réduits et si le contenu, les boutons et les retours d’action restent accessibles. Le W3C explique les difficultés liées aux animations déclenchées par les interactions, notamment pour les personnes sensibles au mouvement.

Ne supposez pas que toute animation suit automatiquement ce réglage : contrôlez le comportement du site et de ses ajouts. Une information essentielle ne devrait pas devenir introuvable lorsque l’effet est réduit ou retiré. Documentez les transitions problématiques et faites examiner leur utilité.

Répétez les contrôles sur les principaux modèles : offre, article, page de contact et autre type utilisé dans le parcours. Choisissez aussi des contenus longs, des champs facultatifs vides et les langues réellement proposées. Une correction du menu partagé doit être recontrôlée sur les pages concernées ; une fiche CMS réussie ne valide pas toutes ses variantes.

Transformer une observation en correction exploitable

Écrire une fiche d’anomalie complète

Une capture seule ne permet pas toujours de reproduire un problème. Utilisez une fiche qui réunit l’URL, le modèle, les préconditions, les actions, le résultat attendu, l’observation, l’impact, l’environnement, la preuve et la décision. Voici un exemple entièrement fictif issu de la première fiche.

• Référence et cible : ACC-01 ; accueil / ; composant de menu commun aux pages de services.
• Préconditions : menu fermé, navigation clavier active, départ dans la barre d’adresse.
• Étapes : atteindre le bouton du menu, l’ouvrir, avancer jusqu’au lien de l’offre.
• Attendu : le lien actif possède un indicateur visible et reste repérable.
• Observé dans l’exemple fictif : le lien reçoit le focus mais son apparence ne change pas.
• Impact à examiner : la personne qui navigue au clavier ne sait plus quelle action elle va activer ; le menu est partagé par plusieurs pages.
• Environnement réel : à compléter lors du test avec URL de version, navigateur, système, largeur et réglages ; aucun environnement n’a été testé pour cet exemple.
• Preuve : enregistrement montrant les touches et la position du focus à joindre ; pièce non produite dans cet exemple.
• Responsable et décision proposée : intégrateur du menu ; examiner le style de focus commun, corriger puis refaire le parcours sur les pages concernées.
• Statut : exemple pédagogique, non constaté. Pour une vraie anomalie : à confirmer, à corriger, puis à recontrôler avec preuve.

Prioriser et attribuer les contrôles

Comparez les anomalies selon la tâche empêchée, les personnes concernées et la diffusion du composant. Un obstacle qui bloque le contact ou toute la navigation demande un traitement différent d’un défaut ponctuel de présentation. Précisez les incertitudes ; ne transformez pas cette première revue en score global de conformité.

Pour chaque correction, nommez la personne qui intervient et celle qui vérifie le résultat. Conservez le constat initial, la décision et le nouveau test. Une correction sur un composant partagé appelle aussi des contrôles de régression : le menu doit rester utilisable dans ses autres états et sur mobile.

Vous pouvez ensuite intégrer les vérifications au cahier des charges : parcours prioritaires, responsabilités, preuves attendues et conditions de validation. Le compte rendu devient ainsi une base de travail pour le projet.

Savoir quand demander une évaluation spécialisée

Demandez une évaluation plus complète si vous devez connaître le niveau de conformité, examiner des interactions complexes ou comprendre des problèmes avec les technologies d’assistance. Une navigation au clavier réussie ne valide pas à elle seule l’expérience d’une personne utilisant un lecteur d’écran.

Le W3C rappelle qu’aucun outil ne détermine seul l’accessibilité. Sa méthode d’évaluation WCAG-EM organise notamment le périmètre, l’exploration du site, un échantillon représentatif, l’évaluation et le compte rendu. Elle exige des compétences et des vérifications qui dépassent cette première prise en main.

Si les constats révèlent des choix de navigation, de modèles ou de formulaires à reprendre dans un nouveau site, ils peuvent aider à cadrer la création d'un site Webflow. Apportez les parcours, les anomalies reproductibles et les responsabilités déjà identifiées : le projet pourra intégrer les contrôles nécessaires dès sa conception.