Un blog sobre accesibilidad, usabilidad, diseño para todos y nuevas tecnologías
El WebAIM, cada año, realiza una encuesta a los usuarios de lectores de pantalla. Este 2026 es la número 11 y pueden participar todas las personas usuarias de lectores de pantalla incluidas las que lo usan de forma puntual para realizar pruebas.
Se pueden consultar los resultados de la encuesta del 2025 en su sitio web.
La participación en la encuesta del 2026 estará abierta hasta finales de agosto del 2026.
El atributo tabindex forma parte de HTML y permite modificar la forma en la que un elemento recibe el foco del teclado. Su uso puede mejorar la accesibilidad de una interfaz, pero también puede empeorarla si se utiliza para corregir problemas que deberían resolverse con una estructura HTML adecuada.
La navegación con teclado es una parte esencial de la accesibilidad web. Muchas personas no utilizan ratón, bien porque trabajan con lector de pantalla, porque emplean otros productos de apoyo o porque simplemente prefieren desplazarse por la interfaz mediante la tecla de tabulación y otros comandos del teclado. En esos casos el foco indica en qué elemento se encuentra la interacción en cada momento.
Los elementos de HTML ya forman parte del orden de tabulación por defecto. Un enlace con href, un botón, un campo de formulario o un control nativo pueden recibir el foco sin necesidad de añadir atributos adicionales. Esto es importante porque HTML ya incorpora mucho comportamiento accesible cuando se utiliza correctamente.
El problema aparece cuando se intenta forzar el comportamiento de una página mediante tabindex sin tener en cuenta las expectativas de las personas que navegan con teclado.
El atributo tabindex permite alterar el orden natural del foco. Puede hacer que un elemento no interactivo pueda recibir el foco, puede retirar un elemento interactivo del orden de tabulación y también puede reorganizar el orden en el que se recorren los elementos de la página.
Su valor es numérico. Cuando se utiliza tabindex=»-1″, el elemento puede recibir el foco mediante JavaScript, pero no queda incluido en la navegación secuencial con la tecla Tab. Cuando se utiliza tabindex=»0″, el elemento entra en el orden de tabulación respetando la posición que ocupa en el código HTML. Cuando se utiliza un valor positivo, como tabindex=»1″ o tabindex=»2″, se fuerza un orden de navegación distinto al orden natural del documento.
En la práctica, los valores positivos suelen ser una mala señal. Si el orden de foco no coincide con el orden visual o lógico de la página, lo correcto normalmente no es añadir números para reconstruir artificialmente la navegación. Lo adecuado es revisar la estructura del HTML y utilizar CSS para ajustar la presentación visual cuando sea necesario.
<a href="/inicio">Inicio</a>
<div tabindex="0">Contenido desplazable</div>
<a href="/contacto">Contacto</a>
En este ejemplo, el div entra en el orden de tabulación en el lugar que ocupa dentro del documento. Esto puede ser correcto si ese contenedor tiene algún comportamiento interactivo real. Pero si se trata solo de un bloque de texto, añadirlo al foco puede introducir ruido innecesario en la navegación.
Una regla sencilla para evaluar el uso de tabindex consiste en preguntarse si el elemento debería ser interactivo. Si se necesita un botón, se debe utilizar un elemento button. Si se necesita un enlace, se debe utilizar un enlace. Si se necesita un campo de formulario, se debe utilizar el control correspondiente.
Crear un botón con un div y añadirle tabindex=»0″ no convierte ese elemento en un botón completo. Puede recibir el foco, pero no incorpora automáticamente el comportamiento esperado con teclado, la semántica adecuada ni la comunicación correcta con los productos de apoyo. En muchos casos, ese tipo de solución obliga a reproducir manualmente características que HTML ya ofrece de forma nativa.
La accesibilidad no consiste solo en que algo pueda recibir el foco. También importa qué anuncia el lector de pantalla, qué teclas activan el componente, cómo se informa del estado, cómo se integra en el flujo del documento y si la interacción coincide con lo que la persona usuaria espera.
El valor -1 resulta útil cuando un elemento no debe aparecer en la navegación normal con Tab, pero necesita recibir el foco en una situación concreta. Un caso habitual es un mensaje de error después de enviar un formulario.
Si una persona envía un formulario y existen errores, mover el foco al resumen de errores puede ayudar a comprender qué ha ocurrido. Para una persona que navega con teclado, evita tener que volver a recorrer toda la página hasta localizar el problema. Para una persona que utiliza lector de pantalla, permite que el mensaje sea anunciado en el momento adecuado.
<div id="errores" tabindex="-1">
Hay errores en el formulario. Revisa los campos indicados.
</div>
Después, mediante JavaScript, se puede enviar el foco a ese elemento cuando se detecten errores.
document.getElementById('errores').focus();
Este patrón también puede ser útil en ventanas modales, paneles que se abren dinámicamente o zonas de la interfaz que aparecen como consecuencia de una acción de la persona usuaria. El objetivo no es añadir más paradas al teclado, sino colocar el foco en un punto lógico cuando cambia el contexto de interacción.
El valor 0 debe utilizarse con más cuidado. Su función es incorporar un elemento al orden natural de tabulación. Esto puede tener sentido cuando existe una zona que debe poder recibir interacción con teclado, pero que por defecto no forma parte del orden de foco.
Un ejemplo frecuente son los contenedores con desplazamiento interno creados con CSS mediante overflow.
Si un bloque tiene contenido desplazable y una persona solo utiliza el teclado, necesita poder situar el foco en esa región para desplazarse por ella. En ese caso, tabindex=»0″ puede hacer que el contenedor sea alcanzable saltando con la tecla de tabulador.
<section aria-labelledby="condiciones" tabindex="0" style="overflow: auto; max-height: 12rem;">
<h2 id="condiciones">Condiciones de uso</h2>
<p>Texto de las condiciones de uso...</p>
</section>
En este tipo de componentes no es suficiente con hacer que el contenedor reciba el foco. También conviene proporcionar una etiqueta accesible y una estructura semántica clara. Una persona que usa lector de pantalla debe poder entender qué contiene esa región y por qué ha llegado hasta ella.
Los valores positivos de tabindex permiten definir un orden de tabulación independiente del orden del documento.
Esta práctica debe realizarse con mucho cuidado ya que es muy sencillo romper el orden coherente y comprensible del orden de tabulación.
Cuando el foco salta de una parte a otra de la página en un orden inesperado, la interfaz se vuelve más difícil de comprender. La persona que navega con teclado puede perder la relación entre la posición visual, la estructura del contenido y el punto real de interacción. Para quien utiliza lector de pantalla, esa separación entre orden del código, orden visual y orden de foco puede resultar especialmente confusa.
<div tabindex="3">Tercer elemento</div>
<div tabindex="1">Primer elemento</div>
<div tabindex="2">Segundo elemento</div>
Este código fuerza una secuencia que no coincide con el orden del documento. Si el diseño necesita mostrar visualmente los elementos de otra manera, CSS debería encargarse de la presentación. El HTML debe conservar un orden lógico, comprensible y coherente.
Existen componentes interactivos que no tienen una equivalencia directa en HTML nativo. Un sistema de pestañas, determinados widgets complejos o algunos controles de aplicación pueden requerir una gestión específica del foco.
En estos casos, tabindex puede formar parte de la solución, pero no debe utilizarse de forma aislada. Un patrón de pestañas accesible, por ejemplo, puede necesitar que la pestaña activa tenga tabindex=»0″ y que las pestañas inactivas tengan tabindex=»-1″ para permitir una navegación controlada con flechas y una gestión correcta del foco.
Una revisión de accesibilidad debería incluir la búsqueda de usos de tabindex en el código. Cada aparición merece una comprobación concreta. Si un elemento nativo interactivo tiene tabindex=»0″, probablemente no lo necesita. Si un elemento no interactivo tiene tabindex=»0″, conviene revisar si realmente debe recibir el foco. Si aparece un valor positivo, normalmente debería corregirse el orden del documento en lugar de mantener ese valor.
También es importante revisar los casos con tabindex=»-1″. No son necesariamente incorrectos, pero deben estar asociados a una gestión del foco clara. Si ningún script envía el foco a ese elemento, puede que el atributo no esté cumpliendo ninguna función.
Las herramientas automáticas pueden localizar estos casos, pero la decisión final requiere criterio humano. Una herramienta puede indicar que existe un tabindex, pero no siempre puede determinar si su uso responde a una necesidad real de interacción.
tabindex no es un atributo prohibido. Es una herramienta potente para gestionar el foco en situaciones concretas. Pero precisamente por afectar directamente a la navegación con teclado, debe utilizarse con prudencia.
En una página bien estructurada, la mayor parte del orden de tabulación debería venir dado por el propio HTML. Los enlaces, botones y campos de formulario ya tienen comportamiento accesible cuando se usan correctamente. Añadir tabindex sin una razón clara puede introducir barreras donde antes no las había.
El proyecto The Color Contrast Checker es una herramienta web orientada a revisar el contraste entre colores y facilitar el cumplimiento de las pautas de accesibilidad relacionadas con la legibilidad visual. Su objetivo principal es permitir que diseñadores, desarrolladores y responsables de contenido comprueben si una combinación de color de texto y fondo alcanza los niveles exigidos por WCAG para los criterios AA y AAA.
La propia herramienta se presenta como un comprobador gratuito de contraste WCAG con sugerencias para encontrar combinaciones de color accesibles.
El contraste de color es uno de esos aspectos de la accesibilidad que puede parecer sencillo hasta que se analiza con cierta atención. No es suficiente con que dos colores parezcan diferentes en una pantalla concreta, con un brillo concreto y en unas condiciones de iluminación concretas. Una combinación que para una persona resulta aceptable puede ser insuficiente para otra con baja visión, daltonismo, fatiga visual o simplemente utilizando el dispositivo en un entorno poco favorable.
La accesibilidad visual no depende únicamente del tamaño de la letra ni de la calidad tipográfica. También depende de la relación entre el color del primer plano y el color del fondo. Cuando esa relación de contraste de color es baja, el contenido puede seguir estando técnicamente presente, pero deja de ser cómodo, eficiente o incluso posible de leer para gran parte de los usuarios. En esa situación el problema deja de ser estético para convertirse en un problema funcional.
Herramientas como The Color Contrast Checker ayudan a convertir una percepción subjetiva en un dato verificable. El diseñador puede introducir los colores, comprobar la relación de contraste y conocer si la combinación cumple o no los umbrales establecidos. Esta verificación resulta especialmente útil porque evita depender únicamente de la intuición, de la vista del diseñador o de la apariencia en una única pantalla.
WCAG utiliza ratios de contraste para determinar si un texto resulta suficientemente distinguible respecto a su fondo. En el modelo tradicional de WCAG 2, la escala va de 1:1, cuando no hay contraste, hasta 21:1, que corresponde al contraste máximo entre negro y blanco. Otras herramientas actuales también incorporan APCA, un modelo perceptual propuesto en el contexto de WCAG 3, que expresa el contraste mediante valores de luminancia percibida en lugar de utilizar el ratio clásico.
La revisión del contraste no debería considerarse una fase final del proyecto. Debería formar parte del diseño desde el principio. Si una paleta no permite combinaciones suficientes para texto normal, texto grande, componentes interactivos y estados de interfaz, el problema no está en la herramienta que lo detecta. El problema está en la definición de la propia paleta.
También conviene recordar que una buena puntuación de contraste no resuelve por sí sola toda la accesibilidad visual. Un texto puede tener contraste suficiente y seguir siendo difícil de leer por usar un tamaño demasiado pequeño, una fuente poco clara, demasiado espaciado negativo, bloques extensos sin estructura o información transmitida solamente mediante color.
Cuando abrimos una página web en el navegador, éste interpreta el código HTML para entender qué contenido hay y qué significa cada parte. Después aplica el CSS para definir el aspecto visual de ese contenido. Pero una página web moderna no solo necesita estructura y presentación: en muchos casos también necesita comportamiento, lógica e interacción. Ahí es donde entra JavaScript.
JavaScript es el lenguaje que permite que una página web responda a acciones del usuario, modifique contenidos, valide formularios, cargue información sin recargar toda la página o cambie el estado de distintos elementos de la interfaz. Es, por tanto, la parte de la Web que aporta funcionalidad y dinamismo.
JavaScript es un lenguaje de programación. A diferencia de HTML y CSS, que no son lenguajes de programación, Javascript sí puede ejecutar comandos y funciones de lógica. Esto no implica que Javascript no tenga que relacionarse con HTML o CSS. Con HTML describimos el contenido y su estructura. Con CSS definimos la presentación visual. Con JavaScript programamos el comportamiento de la página.
Aunque mucha gente identifica JavaScript solo con el navegador, el lenguaje también se puede utilizar fuera de la Web en otros entornos como scripts en la Terminal de Linux o MacOçS, como lenguaje de programación para servidores con NodeJS o para programar servicios para la Nube.
El estándar del lenguaje se denomina ECMAScript, y JavaScript es su implementación más conocida en la actualidad.
A continuación tenemos un ejemplo de una página HTML con un botón y un pequeño fragmento de JavaScript:
<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8">
<title>Mi primera página con JavaScript</title>
</head>
<body>
<h1>Mi primera página con JavaScript</h1>
<p id="mensaje">Todavía no ha pasado nada.</p>
<button id="boton">Pulsa aquí</button>
<script>
document.getElementById("boton").addEventListener("click", function () {
document.getElementById("mensaje").textContent = "Has pulsado el botón.";
});
</script>
</body>
</html>
Si guardamos ese contenido en un fichero con extensión .html y lo abrimos con el navegador, veremos una página con un botón. Al pulsarlo, el texto del párrafo cambiará.
Ese cambio no lo hace HTML ni lo hace CSS. Lo hace JavaScript.
Aunque a primera vista pueda parecer mucho código, en realidad están pasando pocas cosas.
Primero tenemos este párrafo:
<p id="mensaje">Todavía no ha pasado nada.</p>
Ese párrafo tiene un atributo id con el valor mensaje. Ese identificador nos permite localizar el elemento desde JavaScript.
Después tenemos este botón:
<button id="boton">Pulsa aquí</button>
También tiene un id, en este caso boton.
Y por último aparece el bloque script:
<script>
document.getElementById("boton").addEventListener("click", function () {
document.getElementById("mensaje").textContent = "Has pulsado el botón.";
});
</script>
Ese bloque contiene código JavaScript que el navegador ejecuta. La instrucción busca el botón, escucha el evento de pulsación (click) y, cuando ese evento ocurre, modifica el texto del párrafo.
La forma más habitual de incluir JavaScript en una página HTML es mediante la etiqueta <script>.
Puede escribirse directamente dentro del propio documento HTML:
<script>
console.log("Hola desde JavaScript");
</script>
O bien enlazarse desde un fichero externo:
<script src="app.js"></script>
En la práctica, cuando el código crece, lo normal es utilizar un fichero independiente. Esto facilita el mantenimiento, permite reutilizar código y evita mezclar demasiadas responsabilidades en el HTML.
Cuando JavaScript trabaja con una página HTML, normalmente no “ve” el fichero como texto plano, sino como una estructura interna que el navegador ha construido en memoria.
A esa representación se la suele llamar DOM (Document Object Model).
Utilizando el DOM, JavaScript puede realizar diversas funciones como buscar y manipular elementos de la página, añadir y eliminar elementos, reaccionar a eventos provocados por el usuario o por el navegador…
Una idea importante al empezar es que JavaScript no debería utilizarse para suplir una mala estructura HTML.
Primero conviene tener un documento HTML bien organizado y semántico. Después CSS se ocupa de la presentación. Y finalmente JavaScript añade comportamiento.
Si se invierte ese orden, es fácil terminar con páginas difíciles de mantener, menos accesibles y más frágiles.
En artículos anteriores indicamos que HTML describe contenido y CSS describe presentación. Siguiendo esa idea de separar contenido, diseño y funcionalidad, Javascript debe añadir funcionalidad sin romper la semántica del documento. Esta separación de responsabilidades hace que la página sea más clara, con un mejor mantenimiento y más robusta.
Aunque JavaScript aporta mucha potencia a una página web, conviene usarlo con cierta prudencia.
Una mala práctica bastante común consiste en construir páginas que dependen completamente de JavaScript para funcionar, incluso en tareas básicas como mostrar contenido, seguir enlaces o enviar un formulario. Cuando esto ocurre, la página se vuelve dependiente de Javascript y, en muchos casos, menos accesible.
Lo apropiado es que HTML proporcione una base sólida por sí mismo. Es decir, que la estructura del documento, los enlaces, los textos y la información principal existan ya en el marcado. Después, JavaScript puede enriquecer esa base con comportamiento adicional: validar datos en el navegador, mostrar u ocultar partes de la interfaz, actualizar contenidos o responder a acciones del usuario.
Con esto se mantiene la idea de que JavaScript debería mejorar la experiencia, no convertirse en un obstáculo.
También conviene evitar un uso intrusivo del lenguaje. Por ejemplo, no es buena idea abrir ventanas inesperadas, cambiar el foco sin necesidad, alterar el contenido de manera brusca sin avisar o interceptar comportamientos normales del navegador si no hay un motivo claro. Todas esas prácticas pueden desorientar a muchas personas usuarias y hacer que la navegación resulte confusa.
Cuando abrimos una página web en el navegador, éste interpreta el código HTML para entender qué contenido hay y qué significa cada parte (títulos, párrafos, enlaces, formularios, etc.).
Además de estructura y semántica, una página necesita presentacióny estilo visual (tipografías, tamaños, colores, márgenes, alineación, distribución en columnas, etc).
En los artículos sobre HTML se ha hablado de contenido, semántica y estructura pero nunca hablamos de aspecto visual o diseño. Esto se debe a que HTML, en las versiones más modernas y responsables con la accesibilidad, ha cedido toda la responsabilidad de definir el aspecto visual del contenido a la parte CSS de una página web.
CSS son las siglas de Cascading Style Sheets (Hojas de estilo en cascada).
Al igual que ocurre con HTML, CSS no es un lenguaje de programación. No ejecuta lógica como lo haría JavaScript; en su lugar, define reglas de estilo que el navegador aplica sobre los elementos HTML para controlar cómo se muestran en la pantalla.
La idea fundamental es separar responsabilidades entre las distintas partes de una página web. El código HTML describe el contenido y su estructura. El código CSS describe el aspecto visual y parte del comportamiento de presentación (por ejemplo, el diseño adaptable o ciertas animaciones). Por último, el código Javascript describe la funcionalidad y el dinamismo de la página.
Un ejemplo típico es tener un fichero HTML y, aparte, un fichero CSS enlazado. Por ejemplo, un HTML clásico es:
<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8">
<title>Mi primera página con CSS</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<h1>Mi primera página</h1>
<p>Este es un párrafo con información.</p>
<a href="https://programaraciegas.net">Visitar el blog</a>
</body>
</html>
Y el contenido del fichero styles.css podría ser:
body {
font-family: system-ui, sans-serif;
line-height: 1.5;
}h1 {
font-size: 2rem;
}
a {
text-decoration: underline;
}
Si guardamos ambos ficheros en la misma carpeta y abrimos el HTML en el navegador, veremos que el contenido es el mismo, pero con el aspecto definido por las reglas CSS.
El término cascading (en cascada) tiene una razón por la forma de aplicarse los estilos en un contenido. Cuando varias reglas podrían aplicarse al mismo elemento, CSS define un sistema para resolver conflictos (origen, orden, especificidad, importancia).
La unidad básica de CSS es la regla (a veces llamada ruleset). Una regla se compone de:
• Un selector, que indica a qué elementos se aplica.
• Un bloque de declaraciones, que indica qué propiedades se aplican y con qué valores.
Veamos un ejemplo simple:
p {
font-size: 1rem;
margin-bottom: 1rem;
}
En este caso:
• p es el selector: selecciona todos los párrafos.
• Dentro de { … } hay declaraciones.
• Cada declaración es un par propiedad: valor; como font-size: 1rem;.
Hay tres formas habituales de aplicar CSS:
Es la forma más común y la recomendada por accesibilidad. Se enlaza desde el <head> de la página:
<link rel="stylesheet" href="styles.css">
Entre las ventajas encontramos la separación del diseño del contenido y permite reutilizar estilos en muchas páginas.
Se escriben dentro de un bloque <style> en el <head>:
<style>
p { line-height: 1.6; }
</style>Esto es útil para ejemplos o páginas muy pequeñas, pero no es reutilizable para otras páginas.
Se escriben directamente en el atributo style de un elemento del <body>: dentro de la estructura de contenidos de la página.
<p style="line-height: 1.6;">Texto</p>
Aunque este estilo se aplica al contenido, es la opción menos recomendable porque mezcla contenido y presentación y complica el mantenimiento de la página y su estructura.
El selector es la condición que decide qué elementos reciben una regla.
Los más utilizados son:
Afecta a todos los elementos de ese tipo:
p { ... }
h1 { ... }
Afecta a elementos que tengan class=»…»:
.destacado { font-weight: bold; }
Y en HTML:
<p class="destacado">Texto importante</p>
Afecta a un único elemento con id=»…»:
#cabecera { ... }
En HTML:
<header id="cabecera">...</header>
En la práctica, para estilos suele preferirse clases antes que abusar de id, porque son más reutilizables en otros contenidos o componentes.
Es habitual que varias reglas intenten aplicar estilos al mismo elemento. CSS resuelve esto con la aplicación en cascada: el navegador decide qué declaración gana según el origen y el orden, y si hace falta entra en juego la especificidad del selector.
Un ejemplo típico que nos podemos encontrar es:
p { color: black; }
.destacado { color: blue; }
Si un párrafo tiene class=»destacado», el color será azul porque .destacado es más específico que p.
La cascada es una de las razones por las que, al empezar con CSS, a veces parece que no se aplique correctamente a algunos contenidos. normalmente sí funciona, pero otra regla está ganando en prevalencia de la cascada.
CSS puede mejorar mucho la experiencia de navegación y la accesibilidad presente en la página web o romperla con facilidad. Un mal CSS es responsable de estas barreras de accesibilidad:
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.
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.
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>.
<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>
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.
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.
Se deben utilizar para elementos sin orden relevante.
<ul>
<li>Texto alternativo</li>
<li>Encabezados jerárquicos</li>
<li>Landmarks</li>
</ul>
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>
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>
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.
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>
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.