Cuando una página HTML tiene una organización por zonas(landmarks, secciones y encabezados), con la definición del mapa general para navegar, es necesario profundizar más en la organización de los contenidos textuales buscando cómo escribir HTML que se entienda bien tanto visualmente como con lector de pantalla, y que además sea fácil de mantener.
Semántica antes que estilo
Una idea que conviene repetir siempre es que en HTML no se dibuja la página, se describe qué es cada cosa.
El CSS se encarga de cómo se ve.
El objetivo con HTML es que el contenido tenga una estructura que se pueda comprender incluso si no hay estilos visuales, se navega por teclado o con lector de pantallas o se está accediendo desde un dispositivo móvil o de escritorio.
Párrafos
El párrafo es la unidad mínima de texto con sentido propio. Si se está escribiendo frases que forman una idea, normalmente eso es un <p>.
Ejemplo
<p>HTML es un lenguaje de marcado. Su objetivo es describir el contenido de una página.</p>
<p>Cuando usamos elementos semánticos, hacemos que la web sea más navegable y accesible.</p>
Errores habituales
Muchos desarrolladores suelen usar <br> para construir párrafos pero <br> se debe utilizar para un salto de línea dentro de un mismo bloque, por ejemplo direcciones postales o poesía, no para separar ideas completas.
Un mal ejemplo puede ser:
HTML es un lenguaje de marcado.<br>
Su objetivo es describir el contenido de una página.<br><br>
Cuando usamos elementos semánticos...
Otro error habitual es meter párrafos dentro de cualquier cosa porque funciona en el navegador. Por ejemplo, meter texto plano directamente dentro de un contenedor sin estructura. Se puede, pero se pierde semántica y consistencia.
Listas
Una lista no es solo un párrafo con viñetas bonitas: es una relación estructural entre elementos semánticamente relacionados de forma consecutiva.
Listas no ordenadas: <ul>
Se deben utilizar para elementos sin orden relevante.
<ul>
<li>Texto alternativo</li>
<li>Encabezados jerárquicos</li>
<li>Landmarks</li>
</ul>
Listas ordenadas: <ol>
Se deben utilizar cuando el orden importa (pasos, ranking, instrucciones).
<ol>
<li>Abre el archivo HTML.</li>
<li>Localiza el contenido principal.</li>
<li>Revisa la jerarquía de encabezados.</li>
</ol>
Listas de definición: <dl>
Se deben utilizar para pares término–definición. Son muy útiles en glosarios o fichas.
<dl>
<dt>Landmark</dt>
<dd>Región navegable de una página (main, nav, footer...).</dd>
<dt>Semántica</dt>
<dd>El significado estructural de un elemento HTML.</dd>
</dl>
Errores habituales
Alguno de los errores más comunes a la hora de agrupar contenidos en lista es, por ejemplo, simular listas con <p>• …</p>: visualmente se parece, pero para la accesibilidad no es una lista.
Otros de los errores es usar listas para maquetar (por ejemplo, columnas) cuando en realidad no se está representando un conjunto de elementos relacionados.
Citas
Las citas también son marcas semánticas que ayudan a estructurar mejor el contenido textual. Existen los siguientes marcados de cita:
Cita en línea: <q> utilizada para una cita corta dentro de una frase.
<p>Como dijo alguien una vez: <q>la accesibilidad es usabilidad para todos</q>.</p>
Cita en bloque: <blockquote> utilizada para un fragmento más largo que merece entidad propia o que ocupa más de un párrafo.
<blockquote>
<p>La accesibilidad no es una característica extra. Es parte del diseño.</p>
</blockquote>
Se puede añadir la fuente de forma clara usando <cite> (no es el enlace, es la referencia bibliográfica):
<blockquote>
<p>La accesibilidad no es una característica extra. Es parte del diseño.</p>
<cite>Manual interno del equipo</cite>
</blockquote>
Errores habituales
Se suele usar <blockquote> solo para poner texto sangrado. Eso es CSS.
• Poner comillas visuales y olvidarte de la estructura: el lector de pantalla no sabe que es una cita.
⸻
Código: <code>, <pre>, <kbd>, <samp> (sí, hay más de uno)
El contenido técnico es especialmente sensible a accesibilidad y comprensión.
Código en línea: <code>
Para pequeños fragmentos dentro de un párrafo.
<p>El elemento <code><main></code> debe aparecer una sola vez por página.</p>
Bloques de código: <pre><code>
Cuando necesitas respetar espacios y saltos de línea.
<pre><code>function hello() {
console.log(Hola);
}</code></pre>
Teclas y atajos: <kbd>
Para representar lo que el usuario pulsa.
<p>Pulsa <kbd>Control</kbd> + <kbd>S</kbd> para guardar.</p>
Salida del sistema: <samp>
Para texto que representa la salida de un programa, terminal, etc.
<p>El sistema mostrará: <samp>Error: file not found</samp></p>
Buenas prácticas muy recomendables:
• Escapa caracteres en código (<, >, &) si estás escribiendo HTML dentro del bloque.
• Si publicas tutoriales, intenta que el texto explique el código antes y después: el bloque de código sin contexto es una pared.
⸻
Tablas: solo para datos, y con estructura real
La tabla es el elemento que más se malusa.
Regla de oro:
Una tabla es para datos tabulares, no para maquetar.
¿Cuándo sí usar tabla?
Cuando tienes datos que se entienden por filas/columnas: horarios, comparativas, listados con atributos, etc.
Ejemplo básico con cabecera:
<table>
<caption>Comparativa de planes</caption>
<thead>
<tr>
<th scope=col>Plan</th>
<th scope=col>Precio</th>
<th scope=col>Soporte</th>
</tr>
</thead>
<tbody>
<tr>
<td>Básico</td>
<td>0 €</td>
<td>No</td>
</tr>
<tr>
<td>Pro</td>
<td>10 €</td>
<td>Sí</td>
</tr>
</tbody>
</table>
Claves de accesibilidad:
• <caption>: describe la tabla. Muchísima gente lo olvida.
• <th> con scope=col o scope=row: define encabezados de columna o fila.
• Usa <thead>, <tbody> cuando tenga sentido: ayuda a organizar.
Errores típicos que rompen la experiencia:
• Tablas sin encabezados: el lector de pantalla leerá celdas sin contexto.
• Tablas para alinear cosas (como un grid de diseño): hoy eso es CSS (flex, grid).
⸻
¿Cuándo NO usar un <div>?
El <div> es un contenedor genérico sin semántica. No es malo, pero es la última opción, no la primera.
Usa <div> cuando:
• necesitas agrupar elementos para aplicar estilos o layout,
• y no hay un elemento semántico que describa esa agrupación.
No uses <div> cuando exista un elemento que sí describe lo que es:
• ¿Es un párrafo? → <p>
• ¿Es una lista? → <ul>/<ol>/<dl>
• ¿Es una sección temática? → <section>
• ¿Es una pieza de contenido autocontenida? → <article>
• ¿Es navegación? → <nav>
• ¿Es el contenido principal? → <main>
• ¿Es un encabezado de página o sección? → <header>
• ¿Es un pie? → <footer>
• ¿Es complementario? → <aside>
• ¿Es un botón? → <button> (no un <div> clicable)
• ¿Es un enlace? → <a>
Ejemplo clásico (y problemático):
<div onclick=guardar()>Guardar</div>
Eso visualmente puede parecer un botón, pero:
• no es accesible por teclado como un botón real,
• no tiene rol semántico correcto,
• y no hereda comportamientos estándar.
Lo correcto:
<button type=button onclick=guardar()>Guardar</button>
⸻
Un mini-checklist para tus artículos y páginas
Cuando estés escribiendo contenido textual, prueba este repaso rápido:
1. ¿Cada idea completa está en un <p> (o elemento equivalente)?
2. ¿Si hay un conjunto de items, está en una lista real?
3. ¿Si cito a alguien, uso <blockquote> o <q> según el caso?
4. ¿El código está marcado como código (<code>, <pre>, <kbd>)?
5. ¿Las tablas tienen caption y encabezados (th, scope)?
6. ¿Estoy usando <div> solo cuando no hay alternativa semántica?
⸻
Si quieres, el siguiente artículo encaja muy bien si lo enfocamos en elementos de texto de detalle que suelen aparecer en contenidos reales: <strong>, <em>, <mark>, <abbr>, <time>, enlaces bien escritos, y cómo evitar el haz clic aquí para que la navegación por enlaces tenga sentido.