Revisar la accesibilidad y la seguridad del código generado

La IA produce interfaces que se ven bien y fallan con teclado, lector de pantalla o datos maliciosos. Aprende una revisión rápida (elementos nativos, nombres accesibles, teclado, innerHTML y claves) y a pedirlo desde el principio.

El código generado suele verse bien con ratón y fallar con teclado o lector de pantalla: div con onclick, imágenes sin alt, campos sin label.

Revisión de accesibilidad en cinco minutos: recórrelo con Tab, Intro y Escape, comprueba que las acciones son button y los enlaces a, y que todo tiene nombre accesible.

En seguridad, el fallo más habitual es meter con innerHTML datos que no controlas: usa textContent.

Ninguna clave privada va en el JavaScript del navegador: cualquiera puede verla.

  • La IA aprende de código publicado, y mucho no es accesible ni seguro.
  • Pide «un menú hamburguesa» y es muy probable que recibas un <div> con onclick. Con ratón funciona. Con teclado no se puede alcanzar, y un lector de pantalla no anuncia que sea un botón. Lo mismo pasa con imágenes sin alt, campos sin <label> o el foco escondido con outline: none.
  • En seguridad pasa algo parecido: el código funciona, pero tiene un agujero. El caso más habitual en el front es pintar con innerHTML textos que vienen de fuera (un comentario, un formulario, una API). Si ese texto contiene HTML, el navegador lo ejecuta.
  • No sustituye a una auditoría, pero encuentra los fallos más comunes.
  • Tres preguntas que puedes hacer a cualquier código generado.

Se ve bien, pero no funciona para todos

La IA aprende de código publicado, y mucho no es accesible ni seguro.

Pide «un menú hamburguesa» y es muy probable que recibas un <div> con onclick. Con ratón funciona. Con teclado no se puede alcanzar, y un lector de pantalla no anuncia que sea un botón. Lo mismo pasa con imágenes sin alt, campos sin <label> o el foco escondido con outline: none.

En seguridad pasa algo parecido: el código funciona, pero tiene un agujero. El caso más habitual en el front es pintar con innerHTML textos que vienen de fuera (un comentario, un formulario, una API). Si ese texto contiene HTML, el navegador lo ejecuta.

Revisión de accesibilidad en cinco minutos

No sustituye a una auditoría, pero encuentra los fallos más comunes.

Revisión de seguridad para el front

Tres preguntas que puedes hacer a cualquier código generado.

  • ¿Pinta con innerHTML datos que no controlas? Si el texto viene de una persona usuaria, un formulario o una API, usa textContent (o crea los elementos con createElement). innerHTML solo con HTML que has escrito tú.
  • ¿Hay claves en el JavaScript del navegador? Todo lo que llega al navegador se puede leer con F12. Las claves privadas van en un servidor; en el front, solo claves públicas pensadas para ello.
  • ¿Usa eval, new Function o dependencias que no conoces? Pide que lo justifique o que lo resuelva sin ellas.

Pídelo desde el principio

Ponlo en el encargo o en tu AGENTS.md.

Añade a tus encargos (o mejor, a tu AGENTS.md): «Usa elementos nativos (button, a, label); todo debe funcionar con teclado y tener foco visible; imágenes con alt; nunca innerHTML con datos externos, usa textContent; sin claves en el front».

Y aun así revisa: estas reglas reducen mucho los fallos, pero no los eliminan. La revisión de cinco minutos sigue siendo tuya.

IA para programar
11

Revisar la accesibilidad y la seguridad del código generado

La IA produce interfaces que se ven bien y fallan con teclado, lector de pantalla o datos maliciosos. Aprende una revisión rápida (elementos nativos, nombres accesibles, teclado, innerHTML y claves) y a pedirlo desde el principio.

Código del tema: <button> · alt · textContent

📘 Teoría

Se ve bien, pero no funciona para todos

La IA aprende de código publicado, y mucho no es accesible ni seguro.

Pide «un menú hamburguesa» y es muy probable que recibas un <div> con onclick. Con ratón funciona. Con teclado no se puede alcanzar, y un lector de pantalla no anuncia que sea un botón. Lo mismo pasa con imágenes sin alt, campos sin <label> o el foco escondido con outline: none.

En seguridad pasa algo parecido: el código funciona, pero tiene un agujero. El caso más habitual en el front es pintar con innerHTML textos que vienen de fuera (un comentario, un formulario, una API). Si ese texto contiene HTML, el navegador lo ejecuta.

Revisión de accesibilidad en cinco minutos

No sustituye a una auditoría, pero encuentra los fallos más comunes.

1

⌨️ Teclado

Recorre la interfaz solo con Tab, Mayús+Tab, Intro, Espacio y Escape. Todo lo que se pueda hacer con ratón tiene que poder hacerse así, y el foco tiene que verse.

2

🧱 Elementos nativos

Las acciones son <button>; la navegación, <a href>; los campos, <input> con su <label>. Un div clicable es una señal de alarma.

3

🏷️ Nombres accesibles

Imágenes con alt (vacío si son decorativas), botones de solo icono con aria-label, campos con label.

4

🔍 Herramientas

Lighthouse (pestaña de las DevTools) y el panel de Accesibilidad del inspector detectan contraste bajo, nombres que faltan y orden de encabezados.

Revisión de seguridad para el front

Tres preguntas que puedes hacer a cualquier código generado.

  • ¿Pinta con innerHTML datos que no controlas? Si el texto viene de una persona usuaria, un formulario o una API, usa textContent (o crea los elementos con createElement). innerHTML solo con HTML que has escrito tú.
  • ¿Hay claves en el JavaScript del navegador? Todo lo que llega al navegador se puede leer con F12. Las claves privadas van en un servidor; en el front, solo claves públicas pensadas para ello.
  • ¿Usa eval, new Function o dependencias que no conoces? Pide que lo justifique o que lo resuelva sin ellas.

Pídelo desde el principio

Ponlo en el encargo o en tu AGENTS.md.

Añade a tus encargos (o mejor, a tu AGENTS.md): «Usa elementos nativos (button, a, label); todo debe funcionar con teclado y tener foco visible; imágenes con alt; nunca innerHTML con datos externos, usa textContent; sin claves en el front».

Y aun así revisa: estas reglas reducen mucho los fallos, pero no los eliminan. La revisión de cinco minutos sigue siendo tuya.

🧪 Aprende probando

Ejemplo Ejemplo guiado: por qué innerHTML con datos de fuera es peligroso El segundo «comentario» lleva HTML que se ejecuta y cambia el fondo de la página. Cambia innerHTML por textContent y vuelve a ejecutar.
⌄

🏁 Retos

Reto Reto 1: haz accesible la cabecera y el formulario generados Se ve bien con ratón, pero con teclado no se puede abrir el menú ni enviar, y el logo y el campo no tienen nombre.
⌄
Reto Reto 2: pinta los comentarios de forma segura Arregla el código generado para que ningún comentario pueda ejecutar HTML.
⌄

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros. culTest

La hice en febrero de 2026 para facilitar el aprendizaje de mis alumnos. La idea es aprender desarrollo web practicando y que el proyecto siga creciendo con nuevos temas, tests y retos.

Está inspirada en MDN, W3Schools, CodePen, Manz y muchos otros sitios de documentación sobre desarrollo web. Quería combinar teoría útil, ejemplos ejecutables, retos y el sistema de tests que ya tenía en culTest. culTest

Si te gustó, si no te gustó o si quieres escribirme, puedes hacerlo en cristianeslava@gmail.com