Nueve errores que rompen las webs animadas hechas con IA, y cómo arreglarlos

Por qué estos errores sobreviven a una build correcta

Estos errores no rompen la build ni dejan rastro en la consola, así que solo los encuentra quien mira la página. La investigación sobre accesibilidad muestra cuánto se queda por el camino. El análisis de WebAIM de 2026 (se abre en una pestaña nueva) detectó fallos de WCAG en el 95,9 % de un millón de páginas de inicio, con una media de 56,1 errores por página, un 10,1 % más que los 51 de 2025. En un estudio de AudioEye (se abre en una pestaña nueva), empresa que vende servicios de accesibilidad, las 15 webs creadas por cinco herramientas de IA no cumplieron el nivel A de WCAG.

Los nueve errores siguientes llegaron a builds nuestras hechas con un prompt. Arreglamos cada uno y lo añadimos a las reglas que aplicamos en todas las builds.

Tres errores que vienen de Tailwind v4

Los valores por defecto de Tailwind pueden pisar lo que escribiste, a través de los nombres de keyframes, el orden de los breakpoints y el reset de medios. Los tres parecen un fallo tuyo hasta que lees el CSS generado.

1. Tu animación reproduce otra cosa

Síntoma: un pulso o un giro que escribiste se comporta de forma rara o no se ejecuta.

Causa: Tailwind trae sus propias animaciones (se abre en una pestaña nueva), con 4 nombres de keyframes genéricos: spin, ping, pulse y bounce. Tu @keyframes pulse choca con el suyo.

Arreglo: pon prefijo a cada keyframe que escribas, por ejemplo @keyframes os-pulse.

2. Los márgenes fallan en un tamaño de pantalla

Síntoma: a 1920 píxeles, nuestros márgenes eran de 32 px en lugar de los 64 px que habíamos pedido.

Causa: en el CSS que generó Tailwind v4, sm: iba después de min-[1600px]:, así que el breakpoint menor ganaba en anchos grandes.

Arreglo: no mezcles breakpoints con nombre y arbitrarios. Usa arbitrarios en todas partes, como min-[640px]: y min-[1600px]:.

3. Las imágenes y los vídeos grandes no se desbordan

Síntoma: un vídeo que debería ser mayor que su marco, para un parallax o un recorte, se detiene en el ancho del contenedor.

Causa: el reset de Tailwind (se abre en una pestaña nueva) da a imágenes y vídeos max-width: 100%.

Arreglo: añade max-w-none a todo medio que deba ser mayor que su contenedor.

Dos animaciones que siguen actuando al terminar

Una animación puede conservar el control de un elemento cuando termina, o recortar el texto mientras se ejecuta. Las dos se ven bien en el primer segundo, que es cuando casi todo el mundo deja de mirar.

4. Los hovers dejan de funcionar tras la entrada

Síntoma: una tarjeta entra animada a la perfección y luego su hover no hace nada.

Causa: una animación con animation-fill-mode: both sigue aplicando sus valores finales, y estos ganan a tus estilos de hover.

Arreglo: quita la animación cuando termine, o anima por separado las propiedades translate y scale y deja transform para el hover.

card.addEventListener("animationend", () => {
  card.style.animation = "none";
});

5. Los titulares con máscara pierden los descendentes

Síntoma: las colas de la g, la j, la p y la y, y las tildes de las mayúsculas, aparecen cortadas en un titular que se anima línea a línea.

Causa: las apariciones por líneas recortan cada línea, que es lo que hace la opción mask de SplitText (se abre en una pestaña nueva) con overflow: clip, y un interlineado ajustado deja las letras más altas que su caja.

Arreglo: da a la máscara al menos 0,3 em de relleno vertical y compénsalo con un margen negativo. Apila las líneas en una columna flex, porque los márgenes de bloque colapsan y abren el interlineado. Después inicia la aparición desde más abajo.

.line-mask {
  overflow: hidden;
  padding-block: 0.3em;
  margin-block: -0.3em;
}
.lines { display: flex; flex-direction: column; }

Animamos desde un yPercent de unos 155 para las líneas y 175 para las letras sueltas, de modo que nada asome sobre la máscara antes de empezar.

Dos errores de foco que solo encuentra el teclado

El foco se queda atrás cuando un panel aún está oculto, o cuando un menú no se comporta como un diálogo. Con el ratón no se nota ninguno de los dos.

6. El panel se abre, pero el foco se queda atrás

Síntoma: se abre un menú o un diálogo, y quien usa el teclado sigue en la página de detrás.

Causa: el panel aparece con una transición de visibility. Cuando tu código llama a focus(), el panel aún está oculto, así que la llamada no hace nada.

Arreglo: cambia visibility al instante al abrir y anima solo opacity y transform.

7. El menú móvil no es un diálogo

Síntoma: con el menú abierto, un lector de pantalla o el teclado aún llegan a la página de detrás, y al cerrar el menú vuelves arriba del todo.

Causa: el menú se construyó como un panel que tapa la página, sin nada que la deje fuera de uso.

Arreglo: sigue el patrón del W3C para diálogos modales (se abre en una pestaña nueva). Marca el fondo como inert (se abre en una pestaña nueva), lleva el foco al menú y devuélvelo al botón al cerrar.

Dos errores que esperan a un móvil o a un vídeo bloqueado

Una comprobación de errores demasiado amplia muestra un botón que nadie necesita, y un solo SVG sin ancho aleja el zoom de toda la página. Ninguno aparece en un navegador de escritorio con el autoplay activado.

8. Cualquier error de vídeo parece un autoplay bloqueado

Síntoma: la página muestra un botón de «toca para reproducir» en dispositivos donde el autoplay funciona bien.

Causa: el código trata cualquier rechazo de play() como un autoplay bloqueado. Un rechazo también puede significar que se interrumpió la reproducción o que el formato no es compatible.

Arreglo: comprueba el nombre del error. Solo un NotAllowedError (se abre en una pestaña nueva) significa que el navegador bloqueó la reproducción.

9. Toda la página se aleja en el móvil

Síntoma: en un móvil, toda la página se ve un poco alejada, con una franja vacía a un lado.

Causa: un <svg> con posición absoluta y sin width toma el ancho de su viewBox. En nuestro caso eran 1440 px, así que se desbordó y el navegador móvil alejó el zoom para que cupiera.

Arreglo: da un width explícito a cada SVG posicionado.

Si construyes con Claude Code, los pasos de revisión de nuestra guía de Claude Code detectan la mayoría antes de que los vea nadie más.

Cuatro comprobaciones que cubren los nueve

Cuatro pasadas manuales cubren los nueve errores, y ninguna necesita más que un navegador. Hazlas en cada build, porque un cambio en una sección puede devolver un error en otra.

Después escribe cada regla en el prompt, para que la siguiente build ya empiece con ella. Nuestra guía para escribir el prompt de una web muestra dónde van estas reglas, y nuestra comparativa de vídeo, WebGL y CSS cubre los fallos que dependen de la técnica. Las plantillas de nuestro catálogo se revisan en estos cuatro anchos, con teclado y táctil.