HTML semántico

Revisa, reescribe y explica la semántica de HTML5 (etiquetas, puntos de referencia, encabezados, formularios, ARIA). Úsalo cada vez que el usuario pegue HTML o solicite una revisión de marcado, las etiquetas correctas, accesibilidad o corregir 'divitis'.

¿Qué es HTML semántico?

Esta habilidad permite a un agente de IA (como Claude Code, Cursor o Codex) analizar fragmentos de HTML y proporcionar una revisión semántica completa, una versión corregida y explicaciones detalladas de cada cambio. Está diseñada para ayudar a desarrolladores a mejorar la accesibilidad y la calidad estructural de su marcado web, basándose en principios de HTML5 plano, independientemente del framework utilizado (por ejemplo, JSX o plantillas). El agente sigue un flujo de trabajo estructurado que incluye comprender el contenido, aplicar una lista de verificación de buenas prácticas (documento, puntos de referencia, encabezados, interacción, formularios, listas, tablas, medios, texto y ARIA) y generar una respuesta con diagnóstico, código corregido y justificaciones vinculadas al árbol de accesibilidad del navegador. La habilidad enfatiza el uso de elementos nativos sobre ARIA, evita la corrección excesiva y proporciona ejemplos concretos para que las explicaciones sean prácticas. Funciona con cualquier plataforma que admita agentes de IA y respeta el idioma del usuario.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lucasaugustsof/skills/tree/HEAD/semantic-html

Installed? Explore more Productividad y colaboración skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace HTML semántico?

Ayuda a revisar HTML, devolver una versión corregida y explicar el razonamiento detrás de cada elección. El enfoque es siempre HTML5 plano, independiente del framework: si el código viene como JSX u otra plantilla, analiza solo el marcado resultante y responde en HTML.

Responde en el idioma en que escribe el usuario.

Por qué es importante la semántica (úsalo para explicar)

El navegador convierte el HTML en el DOM y, a partir de él, construye el árbol de accesibilidad. Cada etiqueta tiene un rol implícito (<button> → botón, <nav> → navegación, <h2> → nivel de encabezado 2). Los lectores de pantalla, motores de búsqueda, modo lectura y extensiones leen ese árbol, no el CSS. Un <div> con estilo de botón parece un botón, pero para el árbol es solo un bloque genérico: no recibe foco, no responde a Enter/Espacio y no se anuncia como botón.

Ancla las explicaciones en esto — lo que el navegador entiende y lo que cambia para las personas que usan la página — en lugar de reglas memorizadas. Prefiere ejemplos concretos ("el lector de pantalla anunciará...", "Tab saltará este elemento...") sobre abstracciones.

Prueba mental útil: si el CSS desapareciera, ¿la estructura seguiría teniendo sentido?

Flujo de trabajo

  1. Comprende el contenido antes que las etiquetas. ¿Qué es cada bloque? ¿Navegación, contenido principal, un elemento independiente, un control interactivo? Si la intención es ambigua (por ejemplo, un enlace que parece un botón), asume la lectura más probable e indica cuál asumiste.
  2. Revisa usando la lista de verificación a continuación.
  3. Responde en el formato definido.

Lista de verificación de revisión

Documento

  • <!DOCTYPE html>, <html lang="...">, <meta charset="utf-8">, <meta name="viewport">, un <title> descriptivo (solo si el fragmento es un documento completo).

Puntos de referencia

  • <header>, <nav>, <main> (solo uno visible por página), <aside>, <footer>.
  • <section> agrupa contenido temático y normalmente tiene un encabezado; sin encabezado probablemente es un <div>.
  • <article> es contenido que tendría sentido por sí solo (publicación, tarjeta de producto, comentario).
  • Múltiples <nav> en la página → distínguelos con aria-label.

Encabezados

  • Jerarquía sin niveles saltados (h2 → h4 es un problema).
  • Un encabezado describe su sección; no uses encabezados para agrandar texto, ni texto estilizado en lugar de un encabezado.

Interacción

  • Una acción en la página → <button> (con un type explícito dentro de formularios). Navegación a otra URL → <a href>.
  • <div onclick>, <span onclick> y <a> sin href son banderas rojas.
  • Considera elementos nativos antes de reconstruirlos: <details>/<summary>, <dialog>.

Formularios

  • Cada campo tiene un <label> asociado (for/id o envolviendo el input). Un placeholder no reemplaza una etiqueta.
  • Grupos de radio/checkbox en <fieldset> + <legend>.
  • type apropiado (email, tel, number, date...) y autocomplete donde tenga sentido.

Listas y tablas

  • Un conjunto de elementos → <ul>/<ol>; pares término–definición → <dl>.
  • <table> solo para datos tabulares, con <caption>, <thead> y <th scope>. Nunca para maquetación.

Medios

  • <img> con alt que describa su propósito; decorativo → alt="".
  • Imagen con pie de foto → <figure> + <figcaption>.

Texto

  • Énfasis significativo: <strong>/<em>; <b>/<i> solo para desplazamiento estilístico sin importancia.
  • <time datetime>, <blockquote>/<q>, <cite>, <abbr>, <code>/<pre>, <address> donde corresponda.
  • <br> solo para saltos de línea que son parte del contenido (dirección, poema), no para espaciado.

ARIA

  • Primera regla: si existe un elemento nativo, úsalo en lugar de ARIA.
  • Marca ARIA redundante (<button role="button">, <nav role="navigation">) y ARIA que contradiga la etiqueta.

No corrijas en exceso. <div> y <span> son correctos cuando un bloque existe solo para diseño o estilo. Cambiar cada <div> por un <section> empeora el árbol de accesibilidad.

Formato de respuesta (tono mixto: corrección directa + breve explicación)

Diagnóstico

Lista de problemas agrupados por impacto:

  • Rompe la accesibilidad/usabilidad — algo que impide a alguien usar la página (botón sin foco, campo sin etiqueta, imagen sin alt).
  • Semántica imprecisa — funciona, pero comunica la estructura incorrecta (encabezado saltado, section sin título).
  • Detalle — mejora fina.

Cada elemento: qué está mal → qué usar. Una línea.

Código corregido

El HTML completo reescrito, con comentarios cortos solo en las partes cambiadas.

Por qué

De 2 a 5 explicaciones cortas, una por decisión importante, vinculadas a lo que hace el navegador/árbol de accesibilidad. Si un concepto es central (por ejemplo, rol implícito, punto de referencia), explícalo una vez con un ejemplo concreto.

Si el código ya es bueno, dilo claramente y señala solo lo que realmente vale la pena ajustar.

Ejemplo

Entrada:

<div class="header">
  <div class="logo">Tienda</div>
  <div class="menu"><a>Inicio</a><a>Productos</a></div>
</div>
<div class="title">Ofertas</div>
<div onclick="buy()">Comprar</div>

Salida (resumida):

Diagnóstico

  • Rompe la usabilidad: <div onclick> → <button type="button">; <a> sin href → enlaces con href.
  • Semántica imprecisa: .header → <header>; .menu → <nav> con <ul>; .title → <h1>; falta <main>.

Código corregido

<header>
  <p class="logo">Tienda</p>
  <nav aria-label="Principal">
    <ul>
      <li><a href="/">Inicio</a></li>
      <li><a href="/productos">Productos</a></li>
    </ul>
  </nav>
</header>
<main>
  <h1>Ofertas</h1>
  <button type="button" onclick="buy()">Comprar</button>
</main>

Por qué

  • El <div> no está en el orden de Tab y no reacciona a Enter; <button> viene con soporte de foco y teclado y se anuncia como "botón".
  • Un <a> sin href no es un enlace para el navegador: no recibe foco y no aparece en la lista de enlaces del lector de pantalla.
  • <nav> y <main> se convierten en puntos de referencia: los usuarios de lectores de pantalla pueden saltar directamente a ellos.

Fuentes

Cuando tengas dudas sobre una regla, confírmala en MDN o en el Estándar Viviente de HTML (si hay una herramienta de documentación disponible, úsala) y cita el enlace.

Skills relacionados