Addaw, ir a inicio Donar

Lección 2 de 10 · 11 min de lectura · Revisado el 26/10/2026

Semántica: por qué importa; árbol de accesibilidad y nombre accesible

Cuando escribimos HTML no solo dibujamos cajas en una pantalla: describimos qué es cada cosa. Un lector de pantalla, un navegador por voz o un conmutador no «ven» la página; leen una estructura de datos que el navegador construye a partir del marcado. Esa estructura es el árbol de accesibilidad, y la calidad del HTML determina directamente la calidad de lo que recibe la persona. En esta lección veremos por qué la semántica es la base de todo lo demás y cómo se calcula el dato más importante de cada elemento: su nombre accesible.

Qué significa «semántico»

Un elemento HTML es semántico cuando su propia etiqueta comunica su función: <button> es un botón, <nav> es una navegación, <h2> es un encabezado de segundo nivel, <table> es una tabla de datos. Por el contrario, <div> y <span> no significan nada: son contenedores genéricos que solo sirven para agrupar o aplicar estilos.

El navegador «regala» comportamiento a los elementos semánticos. Un <button> nativo recibe el foco con Tab, se activa con Intro y Espacio, expone el rol «botón» a las tecnologías de apoyo, admite el atributo disabled y participa en el envío de formularios. Si lo sustituimos por un <div> con un manejador de clic, perdemos todo eso y tendremos que reconstruirlo a mano con tabindex, eventos de teclado y atributos ARIA. Casi nunca se hace completo.

Ejemplo

Incorrecto: el elemento se ve como un botón pero no lo es.

<div class="btn" onclick="guardar()">Guardar</div>

Correcto: el navegador aporta rol, foco, teclado y estado.

<button type="button" onclick="guardar()">Guardar</button>

Con el <div>, una persona que usa lector de pantalla oye solo «Guardar», sin saber que puede activarlo, y una persona que navega con teclado ni siquiera llega a él.

El árbol de accesibilidad

El navegador construye el DOM a partir del HTML y, en paralelo, un árbol de accesibilidad: una versión simplificada en la que cada nodo relevante tiene cinco tipos de información:

  • Rol: qué es (botón, enlace, encabezado, casilla de verificación, región…).
  • Nombre: cómo se llama («Guardar», «Buscar en el sitio», «Acepto las condiciones»).
  • Descripción: información complementaria opcional (por ejemplo, el texto de ayuda de un campo).
  • Estado y propiedades: marcado, expandido, deshabilitado, obligatorio, nivel de encabezado, posición en una lista, etc.
  • Valor: para controles que lo tienen (un deslizador al 40 %, un campo con texto).

Los elementos puramente decorativos o sin contenido (un <div> vacío que solo aplica un fondo) ni siquiera aparecen. Las tecnologías de apoyo consultan ese árbol a través de las API de accesibilidad del sistema operativo (UI Automation e IAccessible2 en Windows, NSAccessibility en macOS, AT-SPI en Linux). Por eso el criterio 4.1.2 Nombre, función, valor exige que el nombre y el rol de todo componente de interfaz puedan determinarse por programa, que los estados, propiedades y valores que la persona puede cambiar puedan establecerse por programa y que sus cambios se notifiquen a las tecnologías de apoyo.

Puedes inspeccionarlo tú mismo. En Chrome y Edge, abre las herramientas de desarrollo, selecciona un elemento y abre la pestaña Accessibility (o activa la vista completa del árbol desde esa misma pestaña). En Firefox, el Inspector tiene una pestaña Accesibilidad que además marca problemas de contraste y de nombre. Ver el árbol es la forma más rápida de saber qué recibirá realmente una persona usuaria de lector de pantalla.

Punto clave

Lo que no está en el árbol de accesibilidad no existe para las tecnologías de apoyo. Antes de añadir ARIA, pregúntate qué elemento HTML nativo ya pone en el árbol el rol, el nombre y el estado que necesitas.

Cómo se calcula el nombre accesible

El nombre accesible es lo que el lector de pantalla anuncia para identificar el elemento, lo que el control por voz necesita para que la orden «pulsar Guardar» funcione, y lo que compara el criterio 2.5.3 Etiqueta en el nombre con el texto visible. El W3C define el algoritmo en la especificación Accessible Name and Description Computation. Simplificado, el navegador recorre estas fuentes en orden y se queda con la primera que dé resultado:

  1. aria-labelledby: toma el texto de los elementos referenciados por su id.
  2. aria-label: usa el texto del atributo.
  3. La fuente nativa del elemento: el <label> asociado en un campo, el alt en una imagen, la <caption> en una tabla, la <legend> en un <fieldset> o, en botones y enlaces, su propio contenido de texto (incluido el alt de las imágenes que contengan).
  4. title: solo como último recurso; además, no es visible en pantallas táctiles.

Si nada de eso existe, el nombre queda vacío y el lector anuncia algo como «botón» o «enlace» sin más. Es uno de los fallos más frecuentes en iconos y enlaces de imagen.

Error frecuente

Un botón de cierre con un icono y sin texto:

<button class="cerrar"><svg aria-hidden="true">…</svg></button>

El SVG está oculto (correctamente, porque es decorativo), pero entonces el botón no tiene nombre. Solución:

<button class="cerrar" aria-label="Cerrar"><svg aria-hidden="true">…</svg></button>

O mejor aún, texto visible: <button><svg aria-hidden="true">…</svg> Cerrar</button>.

Reglas prácticas sobre el nombre

  • Prefiere el texto visible. Si el nombre viene de un texto que ya está en pantalla, úsalo con <label> o aria-labelledby; así nombre y etiqueta visible nunca se desincronizan.
  • Si usas aria-label en un control con texto visible, el texto visible debe estar contenido en el aria-label («Guardar borrador» puede ser el nombre del botón visible «Guardar», pero «Enviar» no).
  • El title no sustituye a una etiqueta: no se muestra con el teclado ni en el móvil.
  • Evita nombres repetidos sin contexto: cinco enlaces «Leer más» tienen el mismo nombre y no se distinguen en la lista de enlaces del lector de pantalla.

Pruébalo tú

Abre una página que uses a menudo, como la de tu banco o la sede electrónica de tu ayuntamiento. Con las herramientas de desarrollo, inspecciona tres controles que solo tengan un icono (buscar, cerrar, menú) y mira en la pestaña Accessibility su rol y su nombre. Anota cuáles tienen el nombre vacío y cuáles un nombre que no coincide con lo que se ve. Son los primeros fallos que corregirías.

Cómo comprobarlo

Para cada control interactivo, verifica en el panel de accesibilidad del navegador que tiene un rol correcto, un nombre no vacío y que ese nombre describe la acción. Con un lector de pantalla (NVDA es gratuito), abre la lista de enlaces o de controles de formulario (Insert+F7 en NVDA) y lee los nombres fuera de contexto: si la lista no se entiende, los nombres no son buenos. axe o WAVE detectan el nombre vacío, pero no el nombre incorrecto o engañoso; eso solo lo detecta una revisión humana.

Resumen

  • Los elementos semánticos nativos aportan rol, nombre, foco, teclado y estado sin esfuerzo; <div> y <span> no aportan nada.
  • Las tecnologías de apoyo leen el árbol de accesibilidad, no la pantalla; lo que no está en ese árbol no existe para ellas.
  • El nombre accesible se calcula en este orden: aria-labelledby, aria-label, fuente nativa (label, alt, contenido), title.
  • Todo control interactivo necesita un nombre no vacío y descriptivo (4.1.2) que incluya el texto visible (2.5.3).
  • Inspecciona el árbol en las herramientas de desarrollo y escucha los nombres fuera de contexto con un lector de pantalla.

Comprueba lo que has aprendido

Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.