La IA construye tu sitio. Wawsome se asegura de que cualquiera pueda usarlo.
Herramientas como Lovable, Bolt y v0 te permiten tener un sitio funcionando en una tarde, y lo hacen bien. Lo que no hacen es comprobar si ese sitio funciona para alguien que usa un lector de pantalla o solo el teclado, ni darte pruebas para mostrar cuando un cliente o una autoridad te las pide. Esa parte es la que cubre Wawsome.
Cada escaneo se ejecuta contra EN 301 549 y WCAG 2.2, los estándares a los que apunta la EAA.
Wawsome y una corrección vibe-coded, lado a lado
Por qué los equipos eligen Wawsome frente a una solución DIY
La IA genera. No verifica. Si le pides a una IA que “haga esto accesible”, añadirá texto alternativo y algunas etiquetas. Lo que no te dirá es qué se ha saltado o si el resultado realmente funciona para alguien que navega con teclado. Wawsome escanea la página en vivo contra criterios WCAG reales y te muestra exactamente qué falta.
El cumplimiento no es un prompt único. La EAA no viene con línea de meta. Cada página nueva, cada rediseño y cada salto de WCAG 2.1 a 2.2 vuelve a abrir las brechas. Wawsome supervisa continuamente, para que no tengas que volver a revisar a mano en cada release.
Pruebas, no sensaciones. Una sesión de vibe-coding te deja con la impresión de que el sitio está bien. Cuando el equipo de compras de un cliente o una autoridad pide evidencia, una impresión no es un documento. Wawsome te da exportaciones listas para auditoría que puedes entregar.
Una línea, no un refactor. Ya terminaste el sitio. No quieres volver al código. Wawsome se instala con una sola línea, sin desarrollador y sin rebuild, y funciona a partir de ahí.
De dónde salen realmente las brechas
Las mismas cuatro brechas aparecen en casi todos los sitios construidos con IA, porque están justo donde los componentes de la herramienta ya no ayudan.
El contenido que rellena la IA. Los dos fallos de accesibilidad más comunes en la web son el texto con bajo contraste y las imágenes sin texto alternativo, y una librería de componentes no puede arreglar ninguno de los dos. La IA elige los colores por cómo se ve la marca, no por la relación de contraste 4.5:1 que pide WCAG, y las imágenes generadas o de marcador de posición suelen salir sin alt text o con uno genérico.
Las partes personalizadas. Los componentes estándar son una cosa. En el momento en que pides “hazme un X personalizado” — un dropdown a medida, una tarjeta clicable, una navegación más elaborada — la IA puede construirlo como un div estilizado en vez de un botón o enlace real. Se ve igual y funciona con ratón, pero un usuario de teclado no puede llegar, y un lector de pantalla no anuncia nada.
La página alrededor de los componentes. Los componentes no controlan todo el documento. El orden de los headings se puede saltar, la página puede no declarar su idioma, pueden faltar las regiones landmark y un skip link, y cada ruta puede compartir el mismo title genérico. Nada de eso se ve en el preview; todo importa para alguien que usa un lector de pantalla.
Lo que pasa después de un clic. La mayoría de estas herramientas construyen apps de una sola página. Por defecto, al moverte entre “páginas” no se desplaza el foco del teclado ni se anuncia el cambio a las tecnologías asistivas. Y como las páginas generadas con IA dependen mucho de ARIA, aparece el problema inverso: un ARIA mal aplicado empeora las cosas, no las mejora.
Esto no es una corazonada
En el análisis 2026 de WebAIM sobre los un millón de home pages principales, los errores de accesibilidad aumentaron alrededor de un 10% en un solo año, revirtiendo años de mejora lenta. El informe atribuye parte de ese retroceso al aumento de la complejidad de las páginas y al código asistido por IA, al que llama “vibe coding”. Solo el texto con bajo contraste aparece ahora en aproximadamente el 83,9% de las home pages. Los mismos seis problemas — contraste, alt text, etiquetas de formulario, enlaces vacíos, botones vacíos y falta de idioma del documento — han representado alrededor del 96% de todos los fallos detectados durante siete años seguidos. Una forma más rápida de construir no ha cambiado lo que se omite. Solo ha añadido más problemas.
Cómo se ve en la herramienta que usas
Lovable genera React con componentes shadcn/ui, construidos sobre primitivas de Radix, así que gran parte de lo difícil ya viene resuelto: manejo del foco en menús y diálogos, interacción con teclado en controles estándar y un ARIA razonable. Empiezas por delante de la mayor parte de la web. Las brechas son las de arriba: los colores y las imágenes que rellena, cualquier parte personalizada que pidas, la estructura de la página y el hecho de que nada comprueba la página final contra el estándar.
Escanea tu sitio de Lovable gratis
Bolt (de StackBlitz) funciona en un WebContainer del navegador y, como Lovable, se apoya en React con Tailwind y componentes tipo shadcn, así que aplican las mismas primitivas accesibles — y los mismos puntos ciegos. Donde suele fallar más: Bolt está pensado para ir rápido hacia una demo compartible y su parte de backend es más ligera, así que los equipos suelen montar formularios y flujos personalizados a mano. Ahí es exactamente donde desaparecen las etiquetas y el soporte de teclado. Los componentes están bien; el pegamento entre ellos es lo que hay que revisar.
Escanea tu sitio de Bolt gratis
v0 de Vercel genera Next.js con shadcn/ui y Tailwind, y empezó como generador de componentes, así que sus primitivas UI están entre las más limpias de esta lista. Incluso ejecuta un escaneo automático en cada generación — para problemas de seguridad como claves expuestas, no para accesibilidad. Ahí está la clave: una herramienta puede comprobarse a sí misma para una clase de problema y aun así entregarte contrastes fallidos y alt text ausente sin tocar. Los buenos componentes no hacen por sí solos una página conforme.
Replit Agent es otra historia. No se compromete con una sola librería de componentes: elige una stack por proyecto, desde React hasta un backend en Python, y escribe gran parte de la estructura por su cuenta. Así que no hay una base accesible garantizada como la que shadcn ofrece a Lovable o v0; lo que obtienes depende de lo que eligió el Agent y de lo limpio que construyó. El código generado por IA aquí suele ser rápido pero poco idiomático, un terreno fértil para las brechas estructurales y de etiquetado que detecta un escaneo. Cuanto menos predecibles son los cimientos, más razón hay para revisar la página final.
Escanea tu sitio de Replit gratis
Cursor (y otros asistentes dentro del editor) no es un constructor de sitios: es un asistente de IA dentro de tu propio editor, escribiendo en la base de código que ya tienes. Así que la accesibilidad solo es tan buena como lo que pidas y lo que revises. Cursor añadirá un aria-label si se lo pides, y también puede entregar un div clicable si no lo haces. No hay ningún paso de build que intente comprobar el resultado. Si publicas con Cursor, Claude Code o Copilot, el sitio final sigue necesitando una pasada independiente contra el estándar; el asistente no lo hará por ti.
Véelo en tu propio sitio
Toma la URL de tu sitio y pásala por nuestro checker. El escaneo lee la página renderizada — el DOM real que entrega tu herramienta, después de estilos y scripts — y reporta según WCAG 2.2 / EN 301 549. Verás los fallos de contraste, las imágenes y controles sin etiqueta, y las brechas estructurales en unos 10 segundos. No hace falta registrarse para ver el resultado.
Cómo encaja Wawsome con tu forma de trabajar
Wawsome no reemplaza tu builder. Sigue construyendo como siempre. Se coloca encima del sitio ya terminado.
- Haz un escaneo gratuito. Apunta scan.wawsome.com a tu sitio y mira en qué punto estás.
- Añade una sola línea de código. Sin exportar, sin refactorizar, sin un segundo developer.
- Aplica las correcciones. El widget gestiona las brechas comunes que el scan detecta.
- Deja el monitoreo activado. A medida que añades páginas y vuelves a generar contenido, Wawsome sigue comprobando, para que el cumplimiento no se vuelva a desviar, y los exports de evidencia te den algo que mostrar a un cliente o a una autoridad.
¿Wawsome es para tu equipo?
Wawsome merece la pena si te identificas con varias de estas situaciones:
- Has construido, o estás construyendo, tu sitio con una herramienta de IA.
- Vendes a clientes de la UE o les prestas servicio, así que la EAA aplica.
- No tienes un developer o un especialista en accesibilidad de guardia.
- Nunca has pasado el sitio final contra WCAG.
- Prefieres no volver a revisar a mano cada vez que re-prompt-eas.
FAQ
¿Puede la IA hacer que un sitio web sea accesible?
En parte. Las herramientas de IA resuelven la parte visible: alt text, etiquetas, contraste — pero no pueden verificar su propio trabajo contra el estándar ni darte una prueba de conformidad. Ese vacío es el que cubre Wawsome.
¿Mi sitio hecho con Lovable / Bolt / v0 es EAA-compliant?
No automáticamente. Estas herramientas te dejan muy bien encaminado en la parte de componentes, pero el contenido, las partes personalizadas y la estructura de la página suelen cubrir solo parte del estándar, no todo. Un scan te dice exactamente cuál.
¿Por qué mi sitio hecho con IA suspendió un scan si los componentes son accesibles?
Las primitivas accesibles no garantizan una página accesible. El contraste, el alt text, los headings y cualquier componente custom dependen del output generado, no de la biblioteca.
¿Necesito un developer para arreglarlo?
No. Wawsome se instala con una sola línea, y el widget se ocupa de las correcciones comunes.
¿La EAA realmente se aplica a mí?
Si ofreces servicios a consumidores de la UE, probablemente sí. Wawsome no ofrece asesoría legal, pero técnicamente el estándar de referencia es EN 301 549 / WCAG 2.2.
La IA construye. Wawsome verifica.
El sitio ya no es la parte difícil. Lo importante es que funcione para todos y que puedas demostrarlo. Haz un escaneo gratis y comprueba dónde está el tuyo.