En los últimos años, la creación de componentes interactivos en la web ha evolucionado considerablemente gracias al avance de las tecnologías como CSS y JavaScript. Entre estos componentes, los carruseles son especialmente populares por su capacidad de mostrar múltiples contenidos en un espacio reducido. Recientemente, se ha popularizado la noción de “carruseles CSS”, implementaciones que prescinden de JavaScript para apoyarse exclusivamente en nuevas funcionalidades CSS, específicamente en la especificación CSS Overflow Module 5. Sin embargo, al analizar estos carruseles desde la perspectiva de la accesibilidad, surgen importantes dudas y limitaciones que nos impiden considerarlos como una solución lista para producción y amigable para todos los usuarios, especialmente aquellos que utilizan tecnologías asistivas. Los carruseles CSS son, en esencia, patrones de interfaz de usuario que implementan áreas desplazables (scroll) utilizando únicamente CSS para crear elementos como indicadores o controles interactivos (puntos/dots o botones de navegación).
Esto se consigue gracias a nuevas propiedades y pseudo-elementos como ::scroll-marker, ::scroll-marker-group y ::scroll-button(), disponibles solo en navegadores muy específicos y experimentales, como Chrome Canary con funciones activadas manualmente. La idea de poder generar un carrusel sin JavaScript resulta atractiva para desarrolladores por la simplicidad aparente y la reducción en la cantidad de código, pero esta simplicidad técnica no garantiza que la experiencia sea adecuada para todos los usuarios. Tras examinar estos carruseles desde una óptica de accesibilidad, queda claro que presentan limitaciones estructurales significativas. Uno de los problemas principales radica en la forma en que los navegadores exponen sus elementos a tecnologías asistivas como lectores de pantalla. Los pseudo-elementos que representan los indicadores de posición o controles son tratados como “tabs” dentro de un “tablist” a nivel de accesibilidad, colocándolos bajo el rol ARIA de pestañas.
Este enfoque es problemático porque, a pesar de la representación como pestañas, la mayoría de estos carruseles no cumplen con las expectativas funcionales y semánticas de un widget Tab. Para que un widget Tab sea accesible, se debe respetar la asociación clara entre cada pestaña y su panel de contenido correspondiente. Solo un panel debe exhibirse a la vez, y las pestañas deben actualizar adecuadamente su estado aria-selected para reflejar qué contenido está activo. Sin embargo, los carruseles CSS frecuentemente muestran múltiples elementos activos a la vez y no cuentan con paneles con rol tabpanel para contextualizar el contenido asociado a cada pestaña. Como consecuencia, los usuarios que usan lectores de pantalla reciben información descuadrada y confusa, sin saber qué opción controla qué contenido, o qué sección está realmente activa.
Otro punto crítico está relacionado con los nombres accesibles que se asignan a los indicadores o pestañas. Aunque técnicamente se les otorga un nombre accesible, este suele ser genérico y repetitivo para todos los elementos, lo que impide que el usuario pueda distinguir entre los distintos índices dentro del carrusel. Someter a un usuario con discapacidad visual a una lista de controles idénticos, sin descripción única, dificulta enormemente la navegación y entendimiento del componente. Además, un aspecto técnico que agrava la experiencia es la falta de control del desarrollador sobre los roles y semántica que el navegador asigna automáticamente a estos elementos. CSS no puede crear HTML ni modificar el DOM; su ámbito se limita estrictamente al estilo visual.
Por ello, el navegador asigna los roles en base a supuestos internos, lo que genera situaciones donde un carrusel es interpretado como un widget de pestañas aunque no cumpla con las reglas específicas de este patrón. Esto crea una disonancia semántica entre el código HTML real y la interfaz presentada al usuario con discapacidad. En términos de interacción, los carruseles CSS permiten navegar usando el teclado, generalmente utilizando las flechas para cambiar entre elementos del grupo de scroll markers – equiparables a las pestañas. Sin embargo, la experiencia de movilidad no siempre es coherente con las expectativas de los usuarios ni con las pautas definidas por ARIA y el APG (Authoring Practices Guide). Los usuarios pueden aventurarse a un estado donde los controles parecen activos pero el contenido visible no cambia en forma lógica o los estados de selección no se actualizan correctamente.
Esto genera confusión, y apunta a que las implementaciones con carruseles CSS pueden promover experiencias inconsistentes o frustrantes para usuarios con discapacidades. Las propiedades y pseudo-elementos definidos en CSS Overflow Module 5 son pioneros en su tipo, ya que introducen elementos interactivos nativos en CSS, característica nunca antes vista. Esta novedad también plantea inquietudes relacionadas con el principio de separación de responsabilidades, ya que estos estilos CSS comienzan a incorporar contenido accesible y roles semánticos, algo tradicionalmente reservado al HTML. Algunos expertos en accesibilidad manifiestan preocupación porque esto puede derivar en prácticas de desarrollo donde el contenido y la semántica se fragmentan entre diferentes capas, aumentando el riesgo de incoherencias y errores accesibles difíciles de detectar y corregir. Asimismo, la disponibilidad real de estas funcionalidades está limitada a pocos navegadores en modo experimental, lo cual aconseja a los desarrolladores evitar su uso en entornos de producción hasta que exista un soporte unificado y maduro.
En caso de usarse, se deben implementar complementos y alternativas que garanticen una experiencia accesible completa, como roles ARIA manualmente aplicados, etiquetas descriptivas únicas y controles claros. En otro orden de ideas, el concepto de carrusel mismo presenta retos inherentes a la accesibilidad. Su naturaleza dinámica y la posible falta de control sobre la velocidad, la activación automática o manual, pueden afectar negativamente a personas con discapacidades cognitivas o dificultades motoras. Por ello, además de la implementación técnica, es vital considerar el diseño y la usabilidad global del componente para todo tipo de usuarios – algo que los carruseles CSS por sí solos no garantizan. Frente a esta situación, la comunidad de accesibilidad y desarrollo web coincide en que lo ideal sería contar con elementos nativos en HTML que integren la semántica y comportamiento interactivo necesarios para patrones como pestañas, sliders y carruseles.
Estos elementos brindarían una base sólida y estandarizada que simplificaría la creación de interfaces accesibles y confiables sin necesidad de aplicar complejos arreglos con ARIA o CSS avanzados. Organizaciones como OpenUI trabajan actualmente en el desarrollo de componentes nativos, abarcando pestañas, carruseles y otros widgets comunes, con una fuerte orientación a la accesibilidad y usabilidad. La consolidación de estos standard nativos ayudaría no solo a mejorar la experiencia para usuarios con discapacidades, sino también a empoderar a los desarrolladores con herramientas más fáciles, consistentes y seguras. Mientras tanto, los profesionales web deben ser conscientes de las limitaciones de los carruseles CSS y evaluar cuidadosamente si cumplen con las necesidades de sus usuarios. Es recomendable realizar pruebas con tecnologías asistivas reales, inspeccionar la accesibilidad del componente mediante herramientas especializadas, y garantizar que cada componente tenga roles y nombres accesibles adecuados y únicos.
En algunos casos, puede ser mejor optar por soluciones tradicionales basadas en HTML semántico y JavaScript, donde se controla explícitamente el comportamiento y la accesibilidad. En resumen, aunque la propuesta de carruseles implementados únicamente con CSS es innovadora y ofrece ciertos beneficios en términos de simplicidad y rendimiento, su estado actual es experimental y presenta importantes retos en materia de accesibilidad. La forma en que estos componentes se exponen a lectores de pantalla y otros dispositivos asistivos no asegura una experiencia comprensible, operable y útil para todos los usuarios. Se requiere que la especificación y las implementaciones maduren, que los navegadores mejoren su soporte, y que los desarrolladores integren cuidadosamente roles y prácticas accesibles para que estos carruseles puedan ser una opción viable y confiable en el futuro. Finalmente, la reflexión para cualquier creador de contenido digital es clara: la accesibilidad no es opcional ni secundaria, sino un pilar fundamental para el desarrollo web moderno.
Antes de adoptar nuevas tecnologías o técnicas, es imprescindible evaluar cómo afectan a la diversidad de usuarios y si éstas cumplen con estándares y principios que aseguran la igualdad de acceso y experiencia. Con una actitud crítica y responsable, podremos contribuir a la construcción de la web como un espacio inclusivo y universal.
