Map the automotive customer journey and you almost always get the same slide: awareness, research, c…
commercetools y BFSG/WCAG: resolver bien la accesibilidad en un stack Composable
commercetools y BFSG/WCAG: resolver bien la accesibilidad en un stack Composable
Desde el 28 de junio de 2025 está en vigor la Ley alemana de refuerzo de la accesibilidad (BFSG). Para la mayoría de las tiendas online B2C, eso significa que la accesibilidad ya no es opcional, sino obligatoria. Si su comercio funciona sobre commercetools, la primera pregunta suele ser: ¿lo resuelve el backend por mí? La respuesta corta es no. La accesibilidad ocurre allí donde la persona usuaria hace clic, escribe y lee, y ese lugar es la storefront, no la API de commerce.
Por qué la BFSG afecta a la storefront y no al backend
commercetools es un backend de commerce API first. Sirve datos de producto, precios, carrito y lógica de checkout a través de GraphQL y REST. Lo que deliberadamente no define es el frontend, que es justamente la capa que debe cumplir los criterios WCAG: operabilidad por teclado, orden de foco, ratios de contraste, estructura semántica, etiquetas para lectores de pantalla y mensajes de error en formularios. Un setup Composable desacopla backend y frontend a propósito, y eso es una fortaleza. Pero también significa que la responsabilidad sobre la accesibilidad recae por completo en su capa de frontend. Los criterios WCAG 2.1 AA a los que apunta en la práctica la BFSG no se cumplen dentro de la API de commercetools, sino en el marcado que renderiza su storefront.
El problema de añadir la accesibilidad a posteriori
Muchos equipos tratan la accesibilidad como un sprint de fin de trimestre: una auditoría, una lista de hallazgos y unas semanas de correcciones. El problema es que la accesibilidad es una propiedad de cada componente, no una funcionalidad que se añade una sola vez. Un anillo de foco que vuelve a desaparecer en el siguiente rediseño. Un carrusel que no se puede manejar con el teclado. Un desplegable personalizado sin roles ARIA. Cuando estas cosas se construyen componente a componente y se rompen componente a componente, cada relanzamiento se convierte en un nuevo riesgo de accesibilidad. En un stack Composable con muchos bloques de UI independientes, ese riesgo se multiplica.
La accesibilidad como propiedad de la plataforma, no como sprint
El enfoque más duradero consiste en incorporar la accesibilidad a la base de componentes, de modo que cada bloque cumpla desde el principio y lo siga haciendo después del próximo rediseño. Ahí es exactamente donde entra el enfoque de frontend independiente del backend que aplicamos en Laioutr: commercetools sigue siendo su backend, pero la capa de frontend incluye de serie componentes preparados para WCAG 3.0. Los bloques estándar, los formularios, la navegación y los elementos interactivos cumplen los criterios sin que su equipo tenga que pelear con regresiones cada sprint. Esa es la diferencia entre «tenemos un ticket de accesibilidad» y «nuestra storefront es accesible por diseño».
Qué significa esto en concreto para los equipos de commercetools
| Aspecto | Backend (commercetools) | Capa de frontend (relevante para la BFSG) |
|---|---|---|
| Responsabilidad | Datos de producto, precios, lógica de checkout | Renderizado, semántica, teclado, contraste |
| Criterios WCAG | no se abordan | se cumplen aquí por completo |
| Riesgo de regresión | bajo | alto con desarrollos componente a componente |
| Solución | la API se mantiene sin cambios | componentes WCAG Ready de serie |
En la práctica: no necesita tocar su backend de commercetools por la BFSG. La palanca está en elegir una capa de frontend en la que la accesibilidad venga integrada en lugar de añadida después. Si de todos modos tiene pendiente una decisión sobre el frontend, la BFSG es un motivo más para elegir la capa de storefront de forma deliberada e independiente del backend. Ya explicamos hasta qué punto el propio commercetools se está volviendo modular en nuestro artículo sobre commercetools y los nuevos módulos independientes, y la misma lógica de desacoplamiento se aplica a la accesibilidad.
FAQ
¿commercetools hace que mi tienda sea accesible automáticamente? No. commercetools es un backend de commerce y no incluye ninguna interfaz de storefront. Todos los criterios relevantes de WCAG se cumplen en la capa de frontend que renderiza el marcado.
¿Basta con una auditoría de accesibilidad puntual para cumplir la BFSG? Una auditoría muestra el estado actual, pero no se sostiene en el tiempo. La accesibilidad es una propiedad de cada componente y puede volver a romperse en cualquier rediseño. Una base de componentes que ya cumple de serie es mucho más sostenible.
¿Tengo que rehacer mi backend de commercetools por la BFSG? No. La palanca relevante es la capa de frontend. El backend se mantiene sin cambios.
Próximos pasos
Si su storefront de commercetools debe cumplir la BFSG, merece la pena valorar una capa de frontend con accesibilidad incluida de serie. Conozca la base WCAG Ready, o reserve una llamada en la que repasamos en detalle la situación actual de su frontend de commercetools.
Más contenidos de la plataforma Laioutr
Sobre el autor: Marcel Thiesies es Co-Founder de Laioutr. Trabaja con equipos de commercetools en la región DACH para hacer su storefront conforme a la BFSG e independiente del backend.
Todos los datos se basan en información de acceso público y en nuestra propia experiencia con la plataforma. Estado: julio de 2026. La BFSG, los criterios WCAG y las funcionalidades de commercetools pueden haber evolucionado desde entonces. Este artículo no constituye asesoramiento legal.