Consigna y contexto
Necesitas un carrusel horizontal de tarjetas de producto y deseas que el navegador genere botones de desplazamiento anterior/siguiente y marcadores de posición. Explica CSS Overflow Module Level 5, la alternativa para navegadores no compatibles, la accesibilidad y los criterios de lanzamiento.
CSS Overflow 5 define los controles ::scroll-button() y ::scroll-marker generados por un contenedor de desplazamiento, además de scroll-marker-group para agruparlos. El soporte en navegadores aún está evolucionando, por lo que la entrevista evalúa los límites de capacidades y la mejora progresiva en lugar de tratar la característica como una base universal.
Qué evalúa el entrevistador
El entrevistador espera que distingas el contenedor de desplazamiento, los botones de desplazamiento y el grupo de marcadores; que expliques la selección del eje, los estados deshabilitados y el comportamiento del desplazamiento; que preserves los enlaces nativos y las rutas de teclado; que proporciones una alternativa usable; y que valides con dispositivos reales y tecnologías de asistencia en lugar de limitarte a revisar los píxeles.
Preguntas para clarificar
Contenido y diseño
Pregunta si se trata de un carrusel de tarjetas paginado, una galería continua o una lista de pestañas; cuántos elementos aparecen por página; si los anchos de los elementos son fijos; y si se permite el desplazamiento libre.
Alcance de navegadores
Confirma los navegadores objetivo, la ventana de versiones compatibles, la política de JavaScript y si el producto puede ocultar la mejora experimental en navegadores sin soporte.
Interacción y accesibilidad
Confirma el orden de enfoque del teclado, el anuncio del elemento actual por parte del lector de pantalla, el comportamiento táctil y de la rueda del mouse, la preferencia de movimiento reducido y la retroalimentación cuando un botón no está disponible.
Respuesta en 30 segundos
“Construiría un contenedor de desplazamiento horizontal normal con tarjetas enfocables como base, y luego habilitaría scroll-marker-group y ::scroll-button() donde CSS Overflow 5 sea compatible. Los botones activan el desplazamiento, pero las tarjetas conservan su propia semántica y ruta de teclado. Condicionaría la mejora con @supports selector(::scroll-button(*)). Los navegadores no compatibles conservan el desplazamiento nativo o un control liviano en JavaScript, y las pruebas de teclado, lector de pantalla, interacción táctil y movimiento reducido funcionan como criterios de lanzamiento.”
Solución paso a paso
Paso 1: Establecer una base usable
Comienza con un diseño ordinario, overflow-x: auto, una política explícita de scroll-snap y estilos de enfoque visibles. Cada tarjeta tiene un encabezado, enlace o botón, de modo que el contenido siga siendo accesible sin marcadores generados.
Paso 2: Habilitar controles nativos
En los navegadores compatibles, define un grupo de marcadores y usa ::scroll-button(left) y ::scroll-button(right) para los controles anterior y siguiente. La especificación asocia estos botones con el contenedor de desplazamiento de origen; la disponibilidad depende del contenido desplazable restante, por lo que no son pseudoelementos decorativos comunes.
.carousel {
overflow-x: auto;
scroll-snap-type: x mandatory;
scroll-marker-group: after;
}
.carousel::scroll-button(left),
.carousel::scroll-button(right) {
inline-size: 2.5rem;
block-size: 2.5rem;
}Paso 3: Detectar capacidades
Condiciona los estilos de mejora con @supports o detección de capacidades basada en selectores. Cuando la detección falle, no ocultes la barra de desplazamiento, las tarjetas ni una alternativa hecha a mano. Cuando tenga éxito, preserva dimensiones estables para que los controles generados no cambien el rango de contenido visible de forma inesperada.
Paso 4: Preservar la semántica y las rutas de teclado
Los botones pseudoelemento generados no deben ser la única ruta de operación. Define un movimiento de enfoque consistente, comportamiento para Inicio/Fin, teclas de flecha e interacción táctil; desplaza una tarjeta a la vista cuando el enfoque llegue a ella. Un lector de pantalla debe anunciar el nombre del carrusel, la tarjeta actual y la acción, no simplemente “siguiente”.
Paso 5: Manejar el eje y RTL
Los argumentos de los botones se relacionan con el eje de desplazamiento, por lo que los valores físicos left y right no son automáticamente el inicio y el final lógicos. Prueba RTL, modos de escritura vertical y otros modos de escritura por separado. Prioriza dimensiones y espaciados lógicos, y luego verifica las direcciones visuales y de teclado.
Paso 6: Diseñar la alternativa (fallback)
Sin soporte, mantén el desplazamiento horizontal nativo. Si se requieren botones explícitos, una capa pequeña de JavaScript puede observar la posición de desplazamiento y actualizar disabled, el elemento actual y el estado aria. Ambas rutas deben compartir los datos y la semántica de las tarjetas en lugar de mantener dos árboles de contenido.
Paso 7: Definir criterios de lanzamiento
Prueba navegadores con y sin soporte, teclado, interacción táctil, rueda del mouse, zoom al 200%, alto contraste, lectores de pantalla y prefers-reduced-motion. Rastrea las tarjetas visibles en el primer renderizado, activaciones accidentales, pérdida de enfoque, latencia de desplazamiento y cobertura del fallback; una captura de pantalla no puede demostrar que los controles sean usables.
Respuesta modelo
Trataría el desplazamiento horizontal ordinario y la semántica de las tarjetas como la base, y luego superpondría los controles de CSS Overflow 5 encima. La detección de capacidades habilita scroll-marker-group y ::scroll-button() donde estén disponibles; en otros lugares el desplazamiento sigue funcionando, con una pequeña alternativa en JavaScript solo si los controles explícitos son un requisito. Los botones generados nunca reemplazan enlaces, enfoque ni semántica de lectores de pantalla. Probaría RTL, escritura vertical, estados no disponibles, enfoque visible, interacción táctil y movimiento reducido, y luego usaría una matriz de navegadores y tecnologías de asistencia reales para confirmar que cada tarjeta permanezca accesible.
Errores comunes
- Error: Tratar
::scroll-button()como un botón normal disponible en todas partes. → Por qué falla: El soporte para CSS Overflow 5 aún está evolucionando. → Solución: Detectar capacidades y conservar el desplazamiento nativo. - Error: Ocultar la barra de desplazamiento y los enlaces de las tarjetas, dejando solo puntos. → Por qué falla: Los usuarios de teclado y tecnologías de asistencia pueden perder la ruta de acceso al contenido. → Solución: Hacer que la semántica de las tarjetas funcione de forma independiente; los marcadores son navegación adicional.
- Error: Mapear izquierda/derecha físicas directamente a la lógica RTL. → Por qué falla: La dirección visual, el modo de escritura y la dirección lógica pueden diferir. → Solución: Probar los botones, el enfoque y los resultados de desplazamiento por separado en RTL y escritura vertical.
- Error: Probar únicamente clics. → Por qué falla: La pérdida de enfoque, el desbordamiento por zoom y los problemas de movimiento reducido pasan inadvertidos. → Solución: Establecer comprobaciones de teclado, interacción táctil, lector de pantalla y zoom al 200% como criterios de lanzamiento.
Preguntas de seguimiento y respuestas
¿Cuál es el límite entre ::scroll-button() y un botón normal?
Es generado por el contenedor de desplazamiento y está vinculado al contexto de desplazamiento, lo que determina su estilo y disponibilidad. Las acciones específicas del producto, la analítica o los flujos de confirmación aún pueden necesitar un botón real o JavaScript.
¿Por qué mantener el desplazamiento nativo?
Es la ruta funcional cuando la mejora no está disponible y cubre la interacción táctil, la rueda del mouse y las preferencias del usuario. Si la mejora falla, los usuarios aún pueden acceder al contenido.
¿Cómo evitar cambios de diseño (layout shifts) causados por los controles generados?
Reserva espacio para los controles, usa dimensiones de contenedor estables y espaciado lógico, y compara la cantidad de tarjetas en el primer renderizado y las posiciones de ajuste (snap) entre las ramas de capacidades.
¿Cuándo deberías evitar esta característica?
Usa desplazamiento ordinario con un control maduro cuando los navegadores objetivo carezcan de soporte, el estado del carrusel sea complejo o el equipo no pueda mantener una alternativa confiable. Reducir JavaScript no justifica reducir el acceso.