Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
commercetools et BFSG/WCAG : réussir l'accessibilité dans une pile composable
commercetools et BFSG/WCAG : réussir l'accessibilité dans une pile composable
Depuis le 28 juin 2025, la loi allemande de renforcement de l'accessibilité (BFSG) est en vigueur. Pour la plupart des boutiques en ligne B2C, cela signifie que l'accessibilité n'est plus optionnelle, elle est obligatoire. Si vous utilisez commercetools, la première question est souvent : le backend s'en charge-t-il pour moi ? La réponse courte est non. L'accessibilité se joue là où l'utilisateur clique, saisit et lit réellement, c'est-à-dire la boutique, pas l'API commerce.
Pourquoi le BFSG touche la boutique, pas le backend
commercetools est un backend commerce API-first. Il sert les données produit, les prix, la logique de panier et de checkout via GraphQL et REST. Ce qu'il ne prescrit volontairement pas, c'est le frontend, précisément la couche qui doit satisfaire les critères WCAG : navigation au clavier, ordre de focus, ratios de contraste, structure sémantique, libellés pour lecteurs d'écran, messages d'erreur de formulaire. Une configuration composable découple backend et frontend à dessein, et c'est une force. Mais cela veut aussi dire que la responsabilité de l'accessibilité repose entièrement sur votre couche frontend. Les critères WCAG 2.1 AA que le BFSG vise en pratique ne sont pas remplis dans l'API commercetools, ils le sont dans le markup rendu que votre boutique livre.
Le problème de l'accessibilité rajoutée après coup
Beaucoup d'équipes traitent l'accessibilité comme un sprint de fin de trimestre : un audit, une liste de constats, quelques semaines de rattrapage. Le problème est que l'accessibilité est une propriété de chaque composant, pas une fonctionnalité qu'on ajoute une fois. Un anneau de focus qui disparaît à la prochaine refonte. Un carrousel non utilisable au clavier. Un menu déroulant sur mesure sans rôles ARIA. Quand ces éléments sont construits composant par composant et cassent composant par composant, chaque relance devient un nouveau risque d'accessibilité. Dans une pile composable comportant de nombreuses briques d'interface individuelles, ce risque se multiplie.
L'accessibilité comme propriété de plateforme, pas comme sprint
L'approche la plus durable consiste à intégrer l'accessibilité dans la base de composants, afin que chaque brique soit conforme dès le départ et le reste après la prochaine refonte. C'est exactement là qu'intervient l'approche frontend indépendante du backend que nous adoptons chez Laioutr : commercetools reste votre backend, mais la couche frontend livre des composants prêts pour WCAG 3.0 dès l'origine. Les briques standard, les formulaires, la navigation et les éléments interactifs respectent les critères sans que votre équipe combatte des régressions à chaque sprint. C'est la différence entre « nous avons un ticket accessibilité » et « notre boutique est structurellement accessible ».
Ce que cela signifie concrètement pour les équipes commercetools
| Aspect | Backend (commercetools) | Couche frontend (pertinente BFSG) |
|---|---|---|
| Responsabilité | Données produit, prix, logique de checkout | Rendu, sémantique, clavier, contraste |
| Critères WCAG | non traités | entièrement remplis ici |
| Risque de régression | faible | élevé avec des builds composant par composant |
| Solution | l'API reste inchangée | composants prêts WCAG dès l'origine |
En pratique : vous n'avez pas à toucher à votre backend commercetools pour le BFSG. Le levier est de choisir une couche frontend où l'accessibilité est intégrée plutôt que rajoutée. Si vous êtes de toute façon face à une décision frontend, le BFSG est une raison de plus de choisir la couche boutique de façon délibérée et indépendante du backend. Nous avons décrit à quel point commercetools lui-même devient modulaire dans notre article sur commercetools et les nouveaux modules autonomes, et la même logique de découplage s'applique à l'accessibilité.
FAQ
commercetools rend-il ma boutique accessible automatiquement ? Non. commercetools est un backend commerce et ne livre aucune interface de boutique. Tous les critères pertinents WCAG sont remplis dans la couche frontend qui rend le markup.
Un audit d'accessibilité unique suffit-il pour le BFSG ? Un audit montre l'état actuel mais ne tient pas dans le temps. L'accessibilité est une propriété de chaque composant et peut casser à nouveau à chaque refonte. Une base de composants livrée conforme est plus durable.
Dois-je reconstruire mon backend commercetools pour le BFSG ? Non. Le levier pertinent est la couche frontend. Le backend reste inchangé.
Prochaines étapes
Si votre boutique commercetools doit devenir conforme au BFSG, il vaut la peine de regarder une couche frontend avec l'accessibilité prête à l'emploi. Découvrez la base prête pour WCAG, ou réservez un appel où nous passons en revue en détail votre situation frontend commercetools actuelle.
Plus depuis la plateforme Laioutr
À propos de l'auteur : Marcel Thiesies est cofondateur de Laioutr. Il accompagne les équipes commercetools de la région DACH qui rendent leur boutique conforme au BFSG et indépendante du backend.
Toutes les données reposent sur des informations publiquement disponibles et notre propre expérience de plateforme. En date de juillet 2026. Le BFSG, les critères WCAG et les fonctionnalités commercetools peuvent avoir évolué depuis. Cet article ne constitue pas un conseil juridique.