Webflow & accessibilité,est-ce un match ?

Si vous êtes utilisatrice ou utilisateur de Webflow, vous avez déjà constaté que l'interface ménageait quelques garde-fous pour éviter certaines erreurs classiques d'accessibilité.

Elle vous alerte par exemple :

• en l'absence de texte alternatif sur des images porteuses d'information,
• lors de la duplication d'identifiant,
• en cas de non-respect de la hiérarchie des titres (H1, H2, H3,…),
• en présence de liens images sans nom accessible.

Webflow offre également des outils pour tester le rendu de votre site en fonction de certaines déficiences visuelles (daltonisme,…) ou les contrastes entre couleur de premier plan et une couleur de fond.

Enfin, une check-list d'accessibilité s'inspirant des WCAG (Web Content Accessibility Guidelines) est disponible sur le site web de l'éditeur.

Je dois saluer ces efforts qui dénotent une réelle prise en compte de l'accessibilité numérique par les équipes de Webflow. Mais comme on peut le lire sur un article disponible sur leur Help Center, tout ceci permet de créer un site "plus accessible" et non un site accessible.

Et bien que certains composants mériteraient une refonte pour devenir nativement accessibles, la mise en conformité d'un site dans Webflow repose avant tout sur la compétence du designer en matière d'accessibilité. C'est ce que nous allons découvrir par la suite !

En guise d'avant-propos, je tiens à préciser que l'objet de cet article n'est pas d'effectuer une revue d'accessibilité de l'ensemble des composants de Webflow, mais de faire le récit de la mise en conformité de bbcorp.fr vis-à-vis du RGAA.

Dans la suite de cet article, je vous décris au travers des différentes thématiques du RGAA certains des écueils rencontrés et vous livre quelques astuces pour "mettre en accessibilité" un site Webflow.

Sommaire :

1. Images

La majeure partie des critères de la thématique Images concernent la distinction entre images décoratives et images porteuses d'information.

Cette distinction est native dans Webflow puisque l'interface permet au chargement puis à l'insertion des visuels de définir s'il s'agit d'images décoratives ou porteuses d'information. Dans le premier cas, Webflow ajoutera automatiquement un attribut alt vide. Dans le second, le back-office attend que vous en précisiez son alternative textuelle. Toute absence provoquera automatiquement une alerte à la publication du site.

Remarque : si vous chargez un SVG, celui-ci sera intégré via la balise <img> et non un <svg> inline qui nécessiterait, lui, l'ajout d'un role "img" spécifique.

Webflow permet également, comme pour l'exemple ci-dessus, d'ajouter des légendes au sein du bloc "Rich text" (aaaah, le composant "Rich text", meilleur ami et pire ennemi de l'utilisateur·rice Webflow…).

🛑 Problème : l'intégration des images légendées par Webflow n'est pas conforme. Si l'on retrouve bien la balise <figure> qui englobe image et légende, et la balise <figcaption> pour la légende, il manque à la balise <figure> un role="group" et un aria-label dont le contenu est identique à la légende (critère 1.9 du RGAA).

Pour corriger cette non-conformité, pas de panique : Webflow offre la possibilité, via les settings de la plupart des balises, l'ajout d'attributs customs. Dans notre cas, il suffit de :

C'est une méthode que l'on retrouvera à de multiples reprises car c'est elle qui va nous permettre d'intégrer en particulier les attributs aria nécessaires à la mise en conformité de Webflow.

Note : je n'ai pas testé l'élément Captcha qui fait l'objet des critères 1.4 et 1.5 dans la thématique Images du RGAA.

2. Cadres

Pas de frame sur bbcorp.fr !

3. Couleurs

Voilà un thème qui peut se révéler problématique lorsqu'il n'est pas traité à la création d'un site, en particulier si l'on hérite d'une charte graphique non accessible.

S'agissant de bbcorp.fr, le choix initial d'un design sobre m'assurait que les contrastes présents sur le site ne poseraient pas de problème, que cela soit entre textes et couleurs de fond d'une part (critère 3.2), et composants d'interface et couleurs de fond d'autre part (critère 3.3). Pas d'ajustement à effectuer de ce côté-là.

Restait cependant le critère 3.1 qui impose qu'une couleur ne puisse être le seul élément porteur d'information. Or, dans ma déclaration environnementale, le niveau d'éco-conception était uniquement visible grâce à la couleur du pavé entourant la lettre A (intégré en CSS).

Si l'inversion de contraste aurait pu suffire pour certaines situations de handicap comme le daltonisme, il était nécessaire d'intégrer une alternative perceptible pour tout le monde (et en particulier les lecteurs d'écran). J'ai adopté pour cela la technique du texte positionné hors écran .sr-only lisible uniquement par les lecteurs d'écran.

J'ai donc ajouté le texte « A est la note actuelle du site » dans la balise <li> de la lettre A, et lui ai appliqué une classe .sr-only avec les paramètres suivants :

1. margin="-1"
2. width=1px & height=1px
3. overflow=hidden (ne pas confondre avec display="none" qui masquerait le texte pour tout le monde, y compris les technologies d'assistance)
4. position=absolute
5. left=-1000

Le texte concerné n'est pas visible par les utilisateur·rice·s voyant·e·s mais sera bien vocalisé par les lecteurs d'écran.

Cette technique du texte positionné hors écran est une technique d'accessibilité classique, il est donc utile de créer dès le début de votre projet la classe .sr-only car vous serez très probablement amené·e à l'utiliser dans le travail d'accessibilité de votre site.

Remarque : une autre option aurait consisté à ajouter un attribut custom aria-current au <li> correspondant au niveau du site, mais cela me semblait moins explicite et donc potentiellement moins compréhensible à la vocalisation.

4. Multimédias

Pas d’éléments multimédia (temporel ou non temporel) sur bbcorp.fr !

5. Tableaux

Si la mise en conformité des tableaux peut être fastidieuse, elle reste finalement assez simple. En revanche, la création d'un tableau HTML (et non d'une grille CSS) dans Webflow est en soi un petit challenge. Il n'existe pas de composant tableau HTML dans l'interface, ce qui vous oblige à le construire "à la main".

L'inconvénient ? C'est long. L'avantage ? Si vous construisez votre tableau en suivant les bonnes pratiques du RGAA, pas de risque d'obtenir une non-conformité à la fin.

Alors, comment crée-t-on un tableau HTML dans Webflow ? Eh bien, en utilisant une fonctionnalité bien pratique qui permet de transformer une <div> en balise custom.

Pour cela :

Dans le cas d'un tableau HTML, vous aurez besoin de balises <table>, <thead>, <tr>, <td>, <caption>,… pour construire votre tableau, mais également d'attributs customs scope="row" et scope="col" dans vos en-têtes de ligne et de colonne pour être conforme aux critères 5.6 et 5.7 du RGAA.

La bonne nouvelle : si Webflow ne vous facilite pas la tâche lorsqu'il s'agit d'intégrer un tableau HTML, il comprend dès la création de la balise <table> votre intention et ajoutera par exemple automatiquement la balise <tbody> à votre code HTML.

Vous l'aurez compris : créer vos propres tableaux HTML dans Webflow vous demandera une solide connaissance de leur structure HTML avant de vous lancer.

Vous trouverez un exemple de tableau de données conforme dans l'article E-commerce et éco-conception numérique, l'impossible idylle ? (deuxième partie).

6. Liens

Pas de soucis particuliers concernant les liens sur bbcorp.fr : quelques survols à retravailler graphiquement pour les rendre plus visibles, des intitulés à rendre plus explicites,… rien de spécifique en tout cas à Webflow puisque l'enjeu se joue plus dans la conception que dans la mise en œuvre.

Reste, cependant, à gérer un écueil à la frontière entre thématiques Liens et Scripts...

Le web s'est construit sur une distinction majeure entre liens d'une part et boutons d'autre part. Le lien permet de naviguer d'une page à l'autre, le bouton déclenche une interaction dans la page. Ainsi, un lien ne devrait jamais être utilisé pour déclencher une interaction dans la page puisque c'est donc là le rôle du bouton.

🛑 Problème : si vous utilisez le composant "button" de Webflow, celui-ci génère… un lien : <a href="#" class="w-button">Button Text</a>.

Ce choix fait par les concepteurs de Webflow induit les technologies d'assistance en erreur puisqu'elles se servent de cette distinction bouton / lien pour anticiper le type d'événement déclenché par l'élément. Elles interpréteront donc ces boutons comme des liens !

La solution pour créer de vrais boutons est identique à la technique utilisée pour créer les tableaux : ajouter une <div> et la transformer en balise custom <button>. C'est ce que j'ai fait pour les boutons "Me contacter" qui ouvrent la pop-in de contact.

Je m'interroge sur les raisons qui ont conduit Webflow à créer des liens en lieu et place de boutons, alors même que l'élément s'intitule bien "button". C'est en tout cas un point de vigilance puisque l'utilisation d'un lien dans un contexte d'usage de bouton entraîne une non-conformité vis-à-vis du critère 7.1 du RGAA.

7. Scripts

La thématique Scripts est bien souvent la plus complexe à traiter lors d'un audit d'accessibilité. Elle concerne en effet la plupart des éléments interactifs d'un site. Il peut s'agir du fonctionnement d'un carrousel, d'un accordéon, d'un menu déroulant,…

Afin de faciliter la conception accessible de ces éléments interactifs, le W3C met à disposition un ensemble de "patterns" (littéralement "motifs") de conception décrivant le fonctionnement accessible des composants interactifs les plus fréquents du web.

Dans le cas de bbcorp.fr, les composants interactifs qu'il m'a fallu faire évoluer étaient :

• La navigation mobile (mix des composants "disclosure" et "dialog") ‍
• La pop-in de contact (composant "dialog")
• Le toggle d'ouverture de la pop-in éco-conception et la pop-in elle-même (composants "switch" et "dialog")
• Les onglets présents dans la déclaration environnementale (composant "tabs")

🛑 À ce stade de l'article, je me dois de préciser que tous les composants ou fonctionnalités proposés par Webflow pour traiter ces différentes interactions comportent d'importantes non-conformités.

Qu'il s'agisse de l'ouverture des pop-in via des « boutons liens » comme je l'évoquais précédemment, de l'élément "Navbar" qui permet de gérer son menu sur desktop et mobile ou de "Tabs" qui sert à la création d'onglets, je recommande vivement de les recréer manuellement, au risque de se confronter à des difficultés parfois importantes pour les rendre conformes.

Mais qui dit recréation de composants interactifs dit utilisation de javascript custom… ce qui peut sembler antinomique avec le choix du no-code pour créer un site web.

Si la remarque est justifiée, il est important d'avoir en tête que :

• le javascript est indispensable pour viser une conformité totale au RGAA, et ce indépendamment de Webflow,
• seul le javascript permet la mise en conformité des composants natifs Webflow.

Alors, comment faire quand, comme pour moi, le passage par la case rédaction de script n'est pas une option ?

Deux options s'offrent à vous:

• Accepter de ne pas avoir un site 100 % conforme, ce qui reste un choix tout à fait acceptable lorsqu'on n'a ni les compétences ni les ressources pour viser une conformité globale.
• Vous mettre… au "vibe coding".

"Vibe coding" : technique création de code informatique à l'aide de prompts sur une IA générative.

Dans mon cas, l'idée fut donc de faire écrire à l'IA le code nécessaire à la mise en accessibilité de bbcorp.fr en fournissant le code HTML généré par Webflow et en décrivant le comportement accessible attendu.

C'est ainsi que je me suis rapidement trouvé face à un dilemme éthique :

• Accepter de ne pas aller au bout de la mise en conformité de son site,
• Ou accepter, n'ayant pas les moyens de payer un développement, d'utiliser un outil dont l'impact écologique, économique et social est d'ores et déjà fortement décrié.

Je ne peux apporter aucune réponse satisfaisante à ce dilemme, même si je suis convaincu que la solution se trouve en grande partie du côté de Webflow. En effet, si l'éditeur de la solution décidait de mettre à disposition des composants nativement accessibles, cela réduirait fortement l'usage de script custom pour les fonctionnalités les plus courantes.

J'ai en tout cas fait le choix d'aller au bout de ma démarche d'accessibilité et donc de me reposer sur Claude d'Anthropic pour rédiger le code nécessaire à la mise en conformité de bbcorp.fr.

Voici quelques exemples de mes échanges concernant le script de mise en conformité du menu mobile:

• "Au clic / au déclenchement clavier sur le burger, déplacer le focus sur le premier élément de la nav."
• "J'aimerais changer la navigation en modal et ajouter un focus trap pour éviter de sortir du menu. possible ?"

Ce travail de construction par itération successive de mon script d'accessibilité via une IA aura finalement porté ses fruits puisqu'il m'aura permis d'atteindre mon objectif de conformité. Mais il aura également représenté la moitié du temps passé à la mise en conformité de bbcorp.fr tout en requérant un background technique significatif.

C'est selon moi un point noir du travail d'accessibilité sur Webflow : la conformité n'est accessible (sans mauvais jeu de mots) qu'avec de solides compétences techniques, et est donc loin d'être à la portée de tou·te·s.

Pour conclure cette thématique (qui aurait pu faire l'objet d'un article à elle seule…), j'aimerais partager avec vous ce qui fut l'une de mes grandes découvertes en formation et l'une des évolutions les plus complexes à mettre en œuvre : la navigation au clavier sur mon menu mobile.

Mais pourquoi diable rendre une interface tactile navigable au clavier !?!

Imaginons une personne en situation de polyhandicap qui doit à la fois zoomer fortement pour voir votre interface (+200 % a minima selon le critère 10.4) et utilise le clavier pour consulter votre site (critère 7.3). Un zoom important conduit le plus souvent à naviguer sur la version mobile du site (je vous laisse tester en +250% sur bbcorp.fr). Voilà comment on se retrouve à consulter une version mobile… sur desktop !

Les impacts dans mon cas ont été multiples, en particulier pour le menu mobile, puisqu'il a fallu (liste non exhaustive) :

• permettre le déclenchement de l'animation du burger au clavier (touches "espace" et "entrer"),
• mettre en place un « focus trap » qui évite de sortir du menu lorsqu'on navigue au clavier,
• déplacer le focus à l'ouverture du menu mais également à sa fermeture.

J'aime beaucoup cet exemple car il permet de comprendre qu'il n'existe pas une situation de handicap, mais autant de situations que d'utilisateur·rice·s souffrant de handicap.

Le plus grand challenge de la conformité ne réside donc pas uniquement dans l'application littérale de ses critères mais dans la compréhension de la complexité des situations qu'il nous est parfois difficile d'appréhender en tant que valide.

8. Éléments obligatoires

Dans cette thématique, je mets volontairement de côté la plupart des critères puisqu'ils sont soit parfaitement traités par Webflow, soit simples à mettre en œuvre comme le fait d'indiquer les changements de langue dans le code source (critère 8.7 et 8.8).

Un exemple : sur la page Savoir-Faire, j'ai ajouté à la balise <blockquote> de la citation de Jordan un attribut lang="en" pour préciser que la citation était en anglais.

Reste le critère 8.9 qui requiert que :

« Les balises (à l'exception de <div>, <span> et <table>) ne doivent pas être utilisées uniquement à des fins de présentation »

La principale difficulté du critère réside dans son acception très large qui nécessite un travail sémantique global et précis de la structure de nos pages.

Si Webflow permet nativement d'effectuer ce travail de structure sémantique (que l'on retrouvera également dans la thématique suivante), il impose comme avec beaucoup de CMS d'être attentif aux détails…

Un exemple : l'apparition de <br/> indésirables à la fin de certains titres ou pour matérialiser certains sauts de paragraphe. Un grand classique qui finit toujours par "poper" dans une intégration de contenu même pour les utilisateur·rice·s les plus averti·e·s (oui, je parle bien de moi 😁).

9. Structuration de l'information

Cette thématique s'inscrit dans la continuité directe du critère 8.9. L'enjeu est  de construire des structures de page sémantiquement correctes, qu'il s'agisse de hiérarchie des titres, de déclaration des listes ou des citations ou de la structure globale des pages en utilisant les balises sémantiques pour déclarer les zones d'entête, de navigation, de contenu principal ou de pied de page.

Là encore, Webflow donne tous les outils pour construire des pages structurellement conformes… tant que l'on n'utilise pas ses composants prédéfinis.

Je reprends l'exemple du composant Navbar qui permet de gérer son menu sur desktop et mobile.

Lorsque vous intégrez un menu, les items de ce menu doivent impérativement être présentés sous forme de liste. Or, Navbar intègre les liens du menu directement dans la div englobante, sans intégration dans une liste, ce qui entraîne une non-conformité vis-à-vis du critère 9.3.

La solution pour préserver les fonctionnalités natives du composant tout en assurant sa conformité : wrapper les liens dans une div englobante que vous transformez ensuite en div custom <ul>, puis chaque lien dans une div que vous transformez en balise <li> 🤯

Toujours concernant ce même composant Navbar, lorsque vous l'implémentez dans votre page, celui-ci devrait être inséré dans une balise <header> pour se conformer au critère 9.2. Or point de  <header> dans le composant Navbar !

Là encore, la solution réside dans le fait d'intégrer l'ensemble du composant dans une div que vous passez en <header>. Dans ce cas, pas besoin de transformer la div en balise custom car Webflow met à disposition dans les propriétés de chaque div un déroulant comportant les « tags » sémantiques classiques : header, navigation, main, footer, section…

Comme vous pouvez le constater, il existe la plupart du temps un contournement à la non-conformité des composants Webflow, mais au prix parfois d'efforts de recherche conséquents (même lorsque la mise en conformité ne nécessite pas l'utilisation de script).

10. Présentation de l'information

Gros morceau que cette thématique avec pas moins de 14 critères. L'enjeu de l'ensemble de ces critères réside cependant avant tout dans la conception de nos pages et le respect des « bonnes pratiques » du web, plutôt que dans d'éventuelles difficultés dans la mise en œuvre pratique dans Webflow.

J'aimerais cependant vous partager deux modifications importantes que j'ai appliquées en application du critère 10.3. Celui-ci demande :

« Dans chaque page web, l'information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ? »

Vous pourriez légitimement vous poser la question de l'utilité de ce critère. En effet, quel·le utilisateur·rice navigue aujourd'hui sur le web en désactivant les feuilles de styles dans son navigateur ? Eh bien… les lecteurs d'écran !

Enfin, pas exactement, mais si l'ordre de votre contenu n'est pas logique lorsque vous désactivez les feuilles de styles d'un site, il ne le sera pas non plus pour un lecteur d'écran.

Un exemple ? Sur la page Parcours de bbcorp.fr, les clients apparaissent avant les dates déterminant chaque période de mon parcours. Ainsi, avant ajustement de ma part, un utilisateur de lecteur d'écran associait les clients à la mauvaise période, puisque la cohérence du contenu voudrait que les dates précèdent les clients. Vous pourriez arguer qu'il s'agit là d'un défaut de conception, et vous n'auriez pas tout à fait tort.

Pourtant, j'aime cette présentation qui pour un·e utilisateur·rice voyant me semblait claire malgré tout. J'ai donc modifié la structure du contenu pour que dans la source les dates apparaissent bien avant les clients puis j'ai utilisé la possibilité offerte par flex (et Webflow) d'inverser certains blocs de contenu. Résultat : un critère 10.3 désormais conforme et un principe d'affichage préservé.

11. Formulaires

Pas de formulaire sur bbcorp.fr !

12. Navigation

Si bbcorp.fr "échappe" à certains critères de la thématique Navigation de par sa simplicité (tout ce qui concerne la mise en place d'un double système de navigation et des critères associés comme ceux concernant le plan de site), d'autres ont fait l'objet de modifications conséquentes.

Je pense tout particulièrement à la mise à disposition de liens d'évitement (12.7) ou la nécessité d'avoir une navigation cohérente à la tabulation (12.8).

Pour ces deux critères, l'utilisation du javascript s'est imposée lorsqu'il s'est agi de déplacer le focus après clic sur un lien d'accès rapide ou après ouverture d'une pop-in / du menu mobile par exemple. L'article étant bien assez long comme ça, je ne détaille pas, l'information importante étant que sans javascript, point de salut concernant la conformité à ces deux critères.

Reste le critère 12.6 qui consiste à ajouter des rôles spécifiques aux balises sémantiques (banner, navigation, main, contentinfo…). Rien de complexe cependant puisque vous êtes désormais des pros de l'utilisation des attributs customs dans Webflow !

13. Consultation

Dernière thématique qui a peu d'impact pour bbcorp.fr puisque la plupart des critères sont non applicables ou naturellement conformes.

Le seul critère qui a demandé une intervention de ma part concerne les "contenus cryptiques" du type emoji ou glyphes (critères 13.5 et 13.6). Dans la plupart des cas, ceux-ci ont été masqués des technologies d'assistance ou ont reçu une alternative accessible via des aria-label.

Le bilan que je retire de ce travail de mise en conformité au RGAA sur bbcorp.fr est double :

• Si Webflow semble avoir conscience des enjeux de l'accessibilité numérique, le chemin à parcourir pour proposer des éléments nativement accessibles est encore long. La situation économique globale et les enjeux autour de l'intégration de l'IA me laissent penser que malheureusement cette évolution vers un Webflow plus inclusif n'est pas pour demain. Je garde cependant un mince espoir qu'une évolution positive soit possible !
• Plus globalement, la démonstration est faite pour moi qu'intégrer l'accessibilité numérique (comme la sobriété numérique d'ailleurs) dès la création d'un projet numérique permet une mise en conformité infiniment plus simple et complète que lorsqu'elle doit s'appliquer sur un existant qui n'a pas été pensé pour dès les premiers instants de la conception. Mais n'est-ce pas là l'un des fondements mêmes de l'accessibilité ? Il sera toujours plus simple de prévoir une entrée d'immeuble accessible dès la construction que de devoir ajouter une rampe ou un ascenseur accessible une fois l'immeuble construit…