¿Son accesibles los sitios web creados con IA? Guía honesta

En parte. Los constructores con IA generan HTML semántico, y eso cubre gratis una parte de la accesibilidad: encabezados, enlaces y controles de formulario nativos. Lo que rara vez aciertan sin pedirlo es el contraste, el orden de foco del teclado y las etiquetas de los componentes personalizados. Un sitio generado es un punto de partida, no una auditoría.

Esa respuesta sirve más que un sí o un no, porque la accesibilidad no es un interruptor. Es un conjunto de propiedades concretas que una página tiene o no tiene, y el código generado suele tener unas y fallar otras siguiendo un patrón bastante predecible.

¿Qué significa "accesible" en la práctica?

Significa que una persona puede usar tu página con un lector de pantalla, con teclado en lugar de ratón, con el zoom al 200 %, con baja visión o con una limitación motriz que dificulta apuntar con precisión. La referencia de trabajo son las WCAG, organizadas en niveles A, AA y AAA.

Para la mayoría de proyectos el objetivo práctico es el nivel AA. Ahí viven los requisitos que la gente nota de verdad: contraste suficiente en el texto, indicador de foco visible, etiqueta en cada campo, alternativa textual en las imágenes con significado y una página operable sin ratón.

Conviene separar dos cosas que se mezclan siempre. Una es si tu página resulta usable para visitantes con discapacidad, que es una pregunta de producto. Otra es si cumple una obligación legal, que depende de dónde operes y de qué tipo de organización seas. Un constructor ayuda con la primera y no puede responder la segunda.

¿Qué suelen acertar los constructores con IA?

Más de lo que esperan los escépticos, porque los aciertos vienen del propio HTML y no de ninguna astucia del modelo. Las páginas generadas se montan con elementos estándar, y los elementos estándar llegan con comportamiento ya incorporado.

• Estructura del documento. Los encabezados suelen anidarse en orden y las secciones son secciones reales, así que un lector de pantalla puede construir un índice de la página. Eso solo ya la hace navegable de una forma que un montón de divs con estilos no es.
• Controles nativos. Un formulario generado usa normalmente <input>, <button> y <select> de verdad. Son operables con teclado, enfocables y se anuncian correctamente sin trabajo extra.
• Texto de los enlaces. Los modelos tienden a escribir etiquetas descriptivas en lugar de "haz clic aquí", en parte porque se entrenaron con prosa que se lee bien.
• Diseño adaptable. Un diseño fluido que sobrevive a una pantalla estrecha suele sobrevivir también al zoom del navegador, que es un requisito real de baja visión y no solo un asunto de móviles.

Nada de esto está garantizado en una construcción concreta. Es la base: lo que sale bien por defecto porque el HTML subyacente ya estaba bien.

¿Dónde falla el código generado?

Los fallos se agrupan en cuatro sitios, y todos vienen de una decisión de diseño y no de un marcado descuidado.

Contraste. Pides una "paleta suave y apagada" y la obtienes: texto gris claro sobre blanco. Se ve tranquilo en tu monitor y desaparece para cualquiera con sensibilidad al contraste reducida. El nivel AA pide una relación mínima de 4,5:1 en texto normal, y nada en un prompt sobre estados de ánimo le dice al modelo que compruebe ese número.

Foco visible. Muchos diseños modernos quitan el anillo de foco del navegador porque choca con la estética. Si nada lo sustituye, quien navega con teclado no ve dónde está, y la página deja de ser usable sin ratón.

Componentes personalizados. Acordeones, pestañas, ventanas modales y carruseles hechos con divs y manejadores de clic parecen correctos y no anuncian nada. Aquí hacen falta roles ARIA, manejo de teclado y atrapado del foco, y aquí es donde el código generado tiene más probabilidades de quedarse a medias.

Imágenes e iconos. Los iconos decorativos llegan a menudo sin atributo alt en lugar de con uno vacío, y las imágenes con significado reciben un texto alternativo genérico porque el modelo no sabe qué imagen pondrás al final. Un botón solo con icono y sin nombre accesible es el defecto más común que merece revisión.

¿Cómo pedir accesibilidad en el prompt?

Con concreción. "Hazlo accesible" es demasiado abstracto para cambiar mucho el resultado; nombrar las propiedades lo cambia bastante, porque cada frase se traduce en una decisión concreta que el generador tiene que tomar.

Un prompt que funciona se parece más a esto: "Página de aterrizaje para una clínica de fisioterapia. Usa texto de cuerpo con contraste de 4,5:1 o mejor sobre el fondo, mantén un contorno de foco visible en cada elemento interactivo, etiqueta cada campo con un <label> real y da nombre accesible a cada botón que solo tenga icono."

Son cuatro requisitos comprobables, no una sensación. En Zugo las mismas frases funcionan como edición posterior sobre un proyecto existente, que suele ser el orden más barato: primero consigues el diseño que quieres y luego gastas una edición en la pasada de accesibilidad, en vez de pelear con las dos cosas a la vez. Cada edición cuesta 3 créditos.

¿Cómo revisar un sitio generado en diez minutos?

No hace falta un especialista para cazar los defectos habituales. Cinco comprobaciones cubren la mayor parte de lo que se rompe, y todas se hacen en un navegador que ya tienes.

Dos más que merece la pena añadir cuando lo básico ya pasa: recorrer la página con el lector de pantalla del propio sistema operativo y comprobar que cualquier ventana modal devuelve el foco al elemento que la abrió.

¿Qué no puede hacer por ti un constructor con IA?

Tres cosas, y conviene decirlas claras, porque la distancia entre "el código generado tiene buena pinta" y "pasó una auditoría" es donde la gente se lleva sustos.

No puede juzgar la intención. Si una imagen es decorativa o significativa es una pregunta sobre tu contenido, no sobre tu marcado. El modelo adivina; tú lo sabes.

No puede probar con tecnología de asistencia real. Las comprobaciones automáticas detectan etiquetas ausentes y contraste bajo. No detectan una jerarquía de encabezados técnicamente válida y semánticamente absurda, ni un recorrido operable pero agotador.

No puede hacer una determinación legal. Las obligaciones varían según la jurisdicción y el tipo de organización. Si tu sitio cae bajo una normativa concreta, trata lo generado como un borrador que revisa un especialista.

Los límites de Zugo van en la misma lista. Cada construcción se arranca en un entorno de pruebas antes de llegarte, y un fallo se informa como fallo en vez de entregarse como producto terminado. Esa comprobación confirma que la página cargó y se dibujó. No es una auditoría de accesibilidad y no pretende serlo.

¿Por dónde empezar?

Empieza probando algo que ya hayas publicado. Recórrelo con Tab, mide el contraste del texto de cuerpo y cuenta cuántas de las cinco comprobaciones pasa. La mayoría de sitios falla dos o tres, los haya escrito una persona o un modelo.

Después arregla los fallos donde salen más baratos, que es dentro de un constructor donde un cambio es una frase y no un ticket. El plan gratuito da 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes. Una construcción sencilla cuesta 6 créditos y tarda alrededor de un minuto, así que la pasada de accesibilidad es genuinamente barata.

El flujo que funciona es construir, revisar, corregir. Si quieres el contexto más amplio, cómo publicar tu proyecto explica el paso a producción, cómo escribir un buen prompt cubre la parte de la descripción y cómo editar después de generar explica el ciclo de correcciones. Puedes probar todo esto en zugo.dev, publicar en un enlace .zugo.run y repetir las cinco comprobaciones sobre la página en vivo antes de conectar un dominio.