HTML semántico

Los contenedores sin semántica

<div> y <span> son contenedores sin semántica: no le dicen nada al navegador, al lector de pantalla ni al motor de búsqueda sobre el significado del contenido que envuelven. No generan ningún landmark de accesibilidad. Son herramientas neutras.

La diferencia entre los dos es de comportamiento visual:

  • <div> — contenedor de bloque: genera salto de línea, ocupa el ancho disponible (igual que <p>, <h1>, etc.).
  • <span> — contenedor en línea: fluye con el texto sin romper la línea (igual que <strong>, <em>).
<!-- <div>: agrupar elementos para darles un estilo compartido -->
<div class="tarjeta-producto">
  <img src="zapatilla.jpg" alt="Zapatilla modelo X">
  <h3>Zapatilla Modelo X</h3>
  <p>$12.000</p>
</div>

<!-- <span>: marcar una parte del texto para darle estilo, sin semántica -->
<p>El precio es <span class="precio-destacado">$12.000</span> con envío gratis.</p>

¿Cuándo usar <div> y <span>? Solo cuando no existe un elemento semántico apropiado y se necesita un gancho para CSS o para agrupar elementos. Son el último recurso, no el punto de partida.

El antipatrón “div soup”

El “div soup” es el resultado de usar exclusivamente <div> para toda la estructura de la página, sin ningún elemento semántico. El código se vuelve ilegible e inaccesible:

<!-- ❌ MAL: "div soup" — ningún elemento comunica su rol -->
<div id="header">
  <div class="logo">MiSitio</div>
  <div class="nav">
    <div class="item"><a href="#">Inicio</a></div>
    <div class="item"><a href="#">Acerca</a></div>
  </div>
</div>
<div id="main">
  <div class="contenido">
    <div class="post">
      <div class="titulo">Mi primer artículo</div>
      <div class="texto">Contenido del artículo...</div>
    </div>
  </div>
</div>
<div id="footer">
  <div class="copy">© 2026 MiSitio</div>
</div>
<!-- ✅ BIEN: los mismos roles comunicados con semántica -->
<header>
  <span class="logo">MiSitio</span>
  <nav>
    <ul>
      <li><a href="#">Inicio</a></li>
      <li><a href="#">Acerca</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h2>Mi primer artículo</h2>
    <p>Contenido del artículo...</p>
  </article>
</main>
<footer>
  <p>© 2026 MiSitio</p>
</footer>

En el ejemplo de arriba, el <span class="logo"> es un uso válido de <span> — no hay un elemento semántico para “el texto del logo dentro del header”. El <div> queda reservado para agrupaciones que tampoco tienen un elemento semántico mejor.

La regla: primero buscá el elemento semántico correcto. Si no existe → usá <div> (bloque) o <span> (inline).

Semántica vs layout: dos ejes completamente distintos

Este es el concepto más malentendido de todo el módulo. Valé la pena que quede absolutamente claro.

La semántica comunica SIGNIFICADO. El layout comunica POSICIÓN y APARIENCIA. Son ejes independientes.

Los elementos semánticos de HTML no posicionan nada. <aside> no aparece visualmente “al costado” por ser <aside>. <header> no aparece arriba de la pantalla por ser <header>. <footer> no se pega al fondo de la pantalla por ser <footer>.

Sin CSS, todos estos elementos se apilan verticalmente en el orden en que aparecen en el HTML, igual que cualquier elemento de bloque. Eso no es un bug ni algo que “hay que arreglar”. Es el comportamiento correcto: el HTML define la estructura semántica, el CSS define la apariencia visual.

<!-- Sin CSS, este HTML renderiza así (cada elemento en su propia fila): -->
<header>Cabecera</header>        <!-- fila 1 -->
<nav>Navegación</nav>            <!-- fila 2 -->
<main>Contenido principal</main> <!-- fila 3 -->
<aside>Contenido lateral</aside> <!-- fila 4 -->
<footer>Pie</footer>             <!-- fila 5 -->

Que el <aside> aparezca visualmente a la derecha del <main> en dos columnas — eso lo hace CSS (Flexbox o Grid, en el Bloque II). No tiene nada que ver con la semántica.

Dos preguntas completamente separadas:

  1. ¿Qué ES este contenido? → la responde el HTML con los elementos semánticos.
  2. ¿Dónde SE VE este contenido? → la responde CSS.

Un diseñador gráfico que entrega una maqueta con “cabecera arriba, sidebar a la derecha, footer abajo” está describiendo el layout. Vos, como desarrollador HTML, traducís esa maqueta a semántica: “esto que está arriba es el header porque tiene el logo y la nav; esto de la derecha es el aside porque es contenido complementario; esto de abajo es el footer porque es el pie de página”. Esa traducción no depende de la posición visual — si el diseñador pusiera el footer arriba, seguiría siendo el footer semántico.

Beneficios concretos del HTML semántico

El HTML semántico no es solo una convención de legibilidad — tiene consecuencias reales:

Accesibilidad: los elementos generan landmarks

Cada elemento semántico de HTML tiene un rol ARIA implícito que los lectores de pantalla y otras tecnologías de asistencia usan para navegar la página:

Elemento HTMLRol ARIA implícitoNota
<header>bannerSolo cuando es hijo de <body>
<nav>navigationSiempre
<main>mainSiempre
<section>regionSolo si tiene nombre accesible
<article>articleSiempre
<aside>complementarySiempre
<footer>contentinfoSolo cuando es hijo de <body>

Un usuario de lector de pantalla puede navegar entre estos landmarks con un atajo de teclado — “ir al menú”, “ir al contenido principal”, “ir al pie” — sin leer cada elemento uno por uno. La diferencia entre una página con <div> genéricos y una con elementos semánticos puede ser la diferencia entre una página inaccesible y una que sí funciona para alguien con discapacidad visual.

El detalle de cuándo el rol cambia a generic (por anidado dentro de otras secciones) y cómo activar el landmark region en <section> con nombre accesible está en la sección de Referencia del módulo.

SEO: los motores entienden la estructura

Los motores de búsqueda usan los elementos semánticos para identificar qué parte del contenido es principal (<main>) y cuál es navegación o pie de página. Un <article> le indica al motor que ese bloque es contenido autónomo, potencialmente indexable como unidad. No es un efecto mágico ni inmediato, pero escribir código semántico es la práctica correcta, y el SEO es uno de sus beneficios acumulativos.

Mantenibilidad: código autoexplicativo

Un documento con <header>, <nav>, <main>, <article>, <aside>, <footer> comunica su estructura sin necesidad de comentarios ni clases CSS descriptivas. Cualquier desarrollador que abra el archivo entiende qué rol cumple cada parte. El “div soup” requiere conocimiento externo — leer las clases, los comentarios o el CSS — para entender lo mismo.

En la siguiente lección vas a armar una página de blog completa usando todos los elementos de este módulo.

Sandbox libre — probá lo que aprendiste:

Preview

En la referencia