Las etiquetas HTML no son piezas visuales: declaran qué significa cada parte de la página

Es posible construir una página que “se vea bien” usando un contenedor genérico para casi todo. Un div para el encabezado, otro para el menú, otro para el contenido, uno más para la barra lateral y algunos span para convertir texto en botones con CSS. Si solo miras una captura de pantalla, quizá no notes ningún problema. Pero una página no la observa únicamente una persona con un navegador visual. También la recorre un lector de pantalla, la interpreta un modo lectura, la indexa un buscador y la mantiene alguien que no estuvo presente cuando escribiste el primer div.

Por eso las etiquetas HTML no son piezas visuales que eliges para conseguir márgenes o colores. Son declaraciones sobre qué significa cada parte de un documento, qué relación tiene con el resto y cómo debería poder encontrarse. El CSS decide la presentación; JavaScript puede añadir comportamiento; HTML establece qué es el contenido antes de que cualquiera de esas capas actúe.

La misma página vista por tres lectores distintos

Imagina una página con una navegación, un artículo, enlaces relacionados, un formulario de suscripción y un pie. Una persona que ve la pantalla puede reconocer la barra superior por su posición y color. Un lector de pantalla no recibe “la barra azul de arriba”; recibe la estructura que el navegador expone. Un modo lectura busca el contenido principal y los encabezados. Un motor de búsqueda necesita distinguir texto central de navegación repetida.

Cuando escribes elementos nativos, das a esos lectores una ruta común:

<header>
  <a href="/">Skydutz</a>
  <nav aria-label="Navegación principal">
    <a href="/python/">Python</a>
    <a href="/javascript/">JavaScript</a>
  </nav>
</header>

<main id="contenido">
  <article>
    <h1>Título del artículo</h1>
    <p>Contenido principal...</p>
  </article>
</main>

<aside>
  <h2>Lecturas relacionadas</h2>
</aside>

<footer>Información del sitio</footer>

La técnica H101 de WCAG 2.2 explica que elementos como header, nav, main, aside y footer crean regiones identificables para tecnología asistiva. Una persona puede saltar directamente al contenido principal sin escuchar cada enlace del menú. Esa utilidad no aparece al final como un extra de accesibilidad: nace de elegir una etiqueta que describe la región.

El mito: una etiqueta semántica es un div con un nombre bonito

Un div no es incorrecto. Es un contenedor genérico, y muchas interfaces lo necesitan para agrupar elementos con un propósito visual o técnico que no merece una región documental. El error es usarlo por defecto incluso cuando ya sabes lo que ese grupo representa. Si el conjunto es navegación, nav comunica más. Si contiene el contenido dominante, main comunica más. Si es una historia, entrada o unidad que podría compartirse por sí sola, article comunica más.

La diferencia no está en que el navegador pinte mágicamente una section más bonita. Está en el significado programático. El currículo de HTML semántico de MDN resume que HTML bien escrito define contenido, estructura y significado legible por máquina, algo relevante para accesibilidad, SEO y las funciones integradas del navegador. Cuando eliges una etiqueta solo por el aspecto que tiene sin CSS, estás dejando sin declarar una parte de ese significado.

Considera dos fragmentos:

<div class="menu">
  <div class="link">Python</div>
  <div class="link">JavaScript</div>
</div>

<nav aria-label="Temas">
  <ul>
    <li><a href="/python/">Python</a></li>
    <li><a href="/javascript/">JavaScript</a></li>
  </ul>
</nav>

El segundo ejemplo no depende de JavaScript para que un texto actúe como enlace ni de una clase CSS para que alguien adivine que es navegación. Mantiene el comportamiento nativo de enlace, la lista expresa un conjunto de opciones y nav nombra la región. Si luego quieres estilizarlo como botones, el diseño no borra el significado.

Los encabezados son un mapa, no una escala de tamaños

Otro hábito común es elegir h1, h2 o h3 por el tamaño que el navegador aplica por defecto. Eso convierte la jerarquía en decoración. Un encabezado debería responder “¿de qué trata la sección que viene después?” y su nivel debería describir su relación con los demás temas.

<main>
  <article>
    <h1>Cómo preparar un entorno Python</h1>
    <p>...</p>

    <h2>Crear el entorno virtual</h2>
    <p>...</p>

    <h3>Activarlo en Windows</h3>
    <p>...</p>
  </article>
</main>

En este caso, “Activarlo en Windows” depende del tema “Crear el entorno virtual”, no compite con el título principal. Esa relación permite que una persona navegue por encabezados y comprenda la forma del artículo antes de leer cada párrafo. También obliga al autor a notar cuando ha metido dos temas sin relación bajo un encabezado ambiguo.

No resuelvas un problema de tipografía saltando niveles. Si necesitas un texto visualmente menor, usa CSS; si necesitas un subtítulo conceptual, usa el nivel que corresponda. La separación entre estructura y presentación te ayuda a corregir diseño sin reescribir el mapa del documento.

main no es una caja de layout: marca qué contenido es único

El elemento main según MDN representa el contenido dominante del body. El sitio puede repetir logo, menú, barra de búsqueda y pie en muchas páginas; el contenido dentro de main debe ser lo que cambia y desarrolla el tema de ese documento. Por eso un documento no debería tener más de un main visible.

Esta etiqueta también se comporta como landmark. Puedes añadir un enlace al principio que vaya a #contenido para que una persona que usa teclado o lector de pantalla salte la navegación repetida. Ese gesto es pequeño, pero deja claro que la estructura no es teoría: sirve para recorrer una página con menos pasos.

<a class="salto" href="#contenido">Ir al contenido principal</a>
<header>...</header>
<main id="contenido">
  <article>...</article>
</main>

La misma lógica explica por qué no necesitas escribir <main role="main"> en navegadores modernos. El elemento nativo ya comunica esa función. Añadir un rol ARIA idéntico no mejora el significado; solo duplica una declaración que HTML ya hizo. Este principio también orienta el uso de ARIA: primero usa el elemento nativo que expresa el comportamiento y la semántica; añade ARIA solo cuando el componente no tiene una alternativa nativa suficiente.

Una imagen no es solo un rectángulo, y un enlace no es solo texto con cursor

img y a aparecen en toda lista de “etiquetas esenciales”, pero su valor no consiste en recordar que existen. Una imagen necesita decidir si aporta información, es decorativa o funciona como enlace. Si aporta información, su alt debe expresar la razón por la que está allí, no describir automáticamente cada píxel. Si es decorativa y el contenido ya está explicado al lado, un alt vacío puede evitar que el lector de pantalla repita ruido.

<img
  src="grafico-ventas.png"
  alt="Las ventas crecieron de 120 a 180 pedidos entre enero y marzo"
>

El texto alternativo anterior no dice “gráfico azul con tres barras”; comunica la conclusión que el gráfico añade al artículo. En cambio, si una imagen es una textura de fondo sin información, el texto alternativo no debería inventar una descripción que distraiga.

Con los enlaces ocurre algo parecido. “Haz clic aquí” es comprensible mientras estás mirando la frase anterior, pero pierde sentido en una lista de enlaces. Un vínculo como “leer la guía sobre accesibilidad web para principiantes” conserva su destino incluso fuera del párrafo. Elegir buen texto de enlace es otra forma de declarar qué relación existe entre documentos.

Un formulario es una conversación con datos, no una cuadrícula de inputs

Los formularios suelen construirse a partir de su aspecto: una etiqueta visual encima de una caja, un botón con estilos y quizá un mensaje rojo. Pero cada control necesita una relación explícita con su propósito. El usuario no debería adivinar qué espera el campo; la tecnología asistiva tampoco.

<form action="/suscripcion" method="post">
  <label for="correo">Correo para recibir las guías</label>
  <input id="correo" name="correo" type="email" autocomplete="email" required>

  <button type="submit">Suscribirme</button>
</form>

La relación entre label y input no es una decoración. Permite que al seleccionar el texto se enfoque el campo y proporciona un nombre accesible para la persona que no está mirando la pantalla. El tipo email informa al navegador sobre la clase de dato; required expresa una condición básica de envío. Ninguno reemplaza validación del servidor, pero cada uno declara una parte del contrato.

Este enfoque se parece a escribir CSS o JavaScript con intención. En vez de pensar “¿qué propiedad deja esto bonito?”, preguntas “¿qué comportamiento necesito preservar?”. La guía sobre diseño responsivo muestra que una interfaz no se adapta solo por encoger píxeles; en HTML ocurre algo equivalente: una página no se vuelve estructurada solo por contener etiquetas visibles.

La semántica también prepara el terreno para manipular una interfaz sin perder su significado. Cuando JavaScript necesita actualizar una lista, un mensaje o un estado, partir de elementos que ya describen su función hace que el DOM sea más legible y que los cambios sean más localizables. El artículo sobre manipulación del DOM con JavaScript muestra esa capa posterior: JavaScript puede cambiar el árbol, pero no debería obligarte a reconstruir con roles manuales la estructura que HTML nativo ya podía expresar.

Un método para decidir antes de añadir otro div

1. Nombra la función del grupo: ¿navega, contiene el tema principal, relata una unidad autónoma, complementa el contenido o solo agrupa para layout?
2. Busca el elemento HTML nativo que ya comunica esa función.
3. Comprueba si el elemento trae un comportamiento o landmark útil sin JavaScript ni ARIA adicional.
4. Usa div cuando el grupo no tenga significado documental propio.
5. Aplica CSS después, sin cambiar el significado elegido para conseguir un tamaño o una posición.

Este proceso evita dos extremos: llenar cada página de etiquetas semánticas forzadas y reducir todo a contenedores genéricos. La semántica no es una lista de etiquetas “modernas”; es una explicación honesta de la función que cada parte cumple en ese documento.

Decisiones que suelen generar dudas

¿Un div está mal por definición?

No. Es adecuado cuando necesitas agrupar elementos sin que el conjunto represente navegación, contenido principal, una sección temática o una región significativa. El problema es usarlo por defecto cuando ya conoces el papel del grupo.

¿Cuándo una section necesita un nombre?

Cuando representa una unidad temática que quieres que el lector identifique. Una sección con un encabezado claro ayuda a explicar su propósito; si solo necesitas agrupar para estilos, probablemente div sea una opción más honesta.

¿Por qué solo debe haber un main visible?

Porque representa el contenido dominante y único del documento. Navegación, logos, barras laterales repetidas y pie no pertenecen a esa región. Mantener esa frontera permite que herramientas asistivas y modo lectura encuentren el asunto principal rápidamente.

¿Un placeholder sustituye a un label?

No. El placeholder puede mostrar un ejemplo breve, pero desaparece al escribir y no proporciona una relación tan clara como una etiqueta asociada. Usa label para nombrar el campo y placeholder solo si agrega una pista adicional útil.

Martin Rojas

Martin Rojas escribe sobre tecnología, programación y desarrollo web. En Skydutz Academy comparte explicaciones prácticas sobre herramientas digitales, conceptos de programación y recursos para aprender de forma progresiva. Su objetivo es hacer que los temas técnicos sean más claros, útiles y accesibles para lectores de distintos niveles.