WCAG 2.4.6: Encabezados y etiquetas

Qué Significa Esta Regla

WCAG 2.4.6 establece: «Los encabezados y las etiquetas describen el tema o el propósito.» En esencia, este criterio exige que cualquier encabezado (<h1> a <h6>) o etiqueta (<label>, aria-label, aria-labelledby) que aparezca en una página sea lo suficientemente descriptivo como para comunicar el tema del contenido que introduce o el propósito del control que identifica.

Este criterio no exige que existan encabezados o etiquetas; esa obligación está cubierta por otros criterios de éxito como 1.3.1 (Información y relaciones) y 2.4.2 (Página titulada). Lo que regula 2.4.6 es la calidad de los encabezados y etiquetas que ya existen: cuando los tienes, deben ser significativos. Un encabezado que dice «Sección 1» o una etiqueta que dice «Campo» no le dice nada útil a las personas usuarias sobre el contenido que sigue o la entrada que describe. Contrástalo con «Tu dirección de envío» o «Resumen del presupuesto mensual», que orientan a las personas usuarias de inmediato.

Las etiquetas en este contexto incluyen no solo el elemento HTML <label> asociado con controles de formulario, sino también cualquier mecanismo de etiquetado programático: aria-label, aria-labelledby, el atributo title cuando se usa como nombre accesible y el elemento legend para fieldsets. Cualquiera de estos que se exponga a tecnologías de apoyo debe describir claramente el propósito del control asociado.

Se produce un fallo cuando un encabezado o una etiqueta es tan genérico, ambiguo o poco informativo que la persona usuaria no puede determinar de qué trata la sección o el control sin leer el contexto circundante. Por ejemplo, un formulario con tres campos de entrada, todos etiquetados «Introducir aquí», incumple este criterio, al igual que una página que usa encabezados repetidos como «Más información» para cada subsección. Del mismo modo, un encabezado que está técnicamente presente en el DOM pero engaña por completo a la persona usuaria —como etiquetar una sección de formulario de contacto con un encabezado que dice «Noticias y actualizaciones»— también constituye un fallo.

Hay una excepción oficial importante: WCAG 2.4.6 solo se aplica cuando se utilizan encabezados y etiquetas. Si una página legítimamente no tiene encabezados (por ejemplo, un documento muy corto con un solo tema) o un control de formulario que no tiene etiqueta visible ni programática (lo cual sería detectado por 1.3.1), 2.4.6 en sí no se aplica. El alcance del criterio se refiere estrictamente a la capacidad descriptiva, no a la presencia.

Por Qué Importa

Los encabezados y etiquetas descriptivos benefician a un público notablemente amplio, pero el impacto es más agudo para las personas con discapacidad que dependen de la estructura para navegar.

Las personas usuarias de lectores de pantalla —principalmente personas ciegas o con baja visión grave— navegan habitualmente por las páginas saltando de encabezado en encabezado mediante teclas de acceso rápido (H en NVDA/JAWS, el Rotor en VoiceOver). Si los encabezados son vagos o engañosos, esta estrategia de navegación se desmorona por completo. Una persona ciega que llega a un portal de servicios gubernamentales que usa «Sección A», «Sección B» y «Sección C» como encabezados debe leer cada palabra de cada sección de forma secuencial para encontrar lo que necesita, eliminando la ventaja de eficiencia que se supone que deben proporcionar los encabezados. Según la Organización Mundial de la Salud, aproximadamente 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, lo que constituye una población global considerable.

Las personas con discapacidades cognitivas, incluidas aquellas con trastornos por déficit de atención, deterioros de la memoria o dificultades de aprendizaje, dependen en gran medida de etiquetas y encabezados claros y predecibles para reducir la carga cognitiva. Cuando un campo de formulario está etiquetado solo como «Nombre» en una página que recopila tanto el nombre de la empresa como el nombre de la persona de contacto, una persona con discapacidad cognitiva puede no ser capaz de resolver la ambigüedad solo a partir del contexto, lo que provoca errores y frustración.

Las personas usuarias con discapacidades motoras que dependen de acceso por pulsadores, software de seguimiento ocular o control por voz (como Dragon NaturallySpeaking) se benefician de etiquetas descriptivas porque pueden activar un campo de formulario específico pronunciando el nombre de su etiqueta. Si varios campos comparten el mismo texto de etiqueta, el software de control por voz no puede desambiguarlos, obligando a la persona usuaria a realizar pasos adicionales que resultan físicamente exigentes.

Considera un escenario del mundo real: una persona que usa un lector de pantalla visita una página de pago de comercio electrónico. La página contiene tres secciones de dirección —facturación, envío y dirección de la persona destinataria del regalo—, pero cada sección utiliza el mismo encabezado genérico «Dirección» y cada conjunto de campos de entrada usa las mismas etiquetas: «Calle», «Ciudad», «Código postal». Sin encabezados y etiquetas únicos y descriptivos, la persona usuaria del lector de pantalla no puede determinar qué grupo de campos está completando, lo que aumenta drásticamente el riesgo de errores en el pedido y la probabilidad de abandonar la compra por completo.

Más allá de la accesibilidad, los encabezados descriptivos aportan un valor sustancial en SEO. Los motores de búsqueda utilizan la estructura de encabezados como una señal importante para comprender el contenido de la página y relacionarlo con las consultas de las personas usuarias. Los encabezados significativos ayudan a los motores de búsqueda a indexar las páginas con mayor precisión y pueden mejorar las tasas de clics en los resultados de búsqueda, donde los encabezados suelen mostrarse como texto de vista previa. Esto alinea directamente los incentivos empresariales con los requisitos de accesibilidad.

Reglas Relacionadas de Axe-core

WCAG 2.4.6 requiere pruebas manuales porque ninguna herramienta automatizada puede determinar de forma fiable si un encabezado o una etiqueta es descriptivo. La capacidad descriptiva es un juicio semántico y contextual: un encabezado que dice «Productos» puede ser perfectamente descriptivo en una página y completamente ambiguo en otra. Los escáneres automatizados pueden detectar la presencia o ausencia de encabezados y etiquetas, pero no pueden evaluar si el texto de esos encabezados y etiquetas es significativo sin interpretación humana.

• Revisión manual del texto de los encabezados: Axe-core marcará encabezados faltantes o anidamiento incorrecto (mediante reglas como heading-order), pero no puede marcar un encabezado que diga «Haz clic aquí» o «Sección sin título» como una infracción de 2.4.6. Una persona evaluadora debe leer cada encabezado de forma aislada —tal como lo encontraría una persona usuaria de lector de pantalla al navegar por encabezados— y evaluar si comunica el tema del contenido que le sigue.
• Revisión manual del texto de las etiquetas de formulario: La regla label de axe-core verifica que cada campo de formulario tenga una etiqueta asociada, pero no evalúa si el texto de esa etiqueta es descriptivo. Un elemento label que contiene solo un carácter de marcador de posición, un carácter de icono o una palabra genérica como «Entrada» pasará las comprobaciones automatizadas y aun así incumplirá 2.4.6. La revisión manual requiere leer cada etiqueta y confirmar que describe con precisión el propósito de su control asociado.
• Revisión manual de los valores de aria-label y aria-labelledby: De forma similar, la familia de reglas aria-label-is-accessible de axe-core confirma que las etiquetas ARIA son sintácticamente válidas y que los elementos referenciados existen, pero no evalúa si el texto de la etiqueta es semánticamente significativo o descriptivo del propósito del control.
• Detección de etiquetas duplicadas: Aunque algunas herramientas pueden marcar texto de etiqueta duplicado en una página, no pueden determinar si la duplicación es intencional y apropiada (dos campos con el mismo propósito en filas diferentes de una tabla) o un fallo real de capacidad descriptiva en el que varios controles distintos comparten una etiqueta ambigua. Se requiere revisión manual para hacer esta distinción.

Cómo Probar

1. Ejecuta primero un análisis automatizado: Usa axe DevTools (extensión del navegador) o Lighthouse en Chrome DevTools para identificar cualquier problema estructural de encabezados o etiquetas que las herramientas automatizadas puedan detectar, como etiquetas faltantes, niveles de encabezado omitidos o elementos de encabezado vacíos. Aunque estos no son infracciones directas de 2.4.6, indican áreas que deben examinarse con más cuidado durante la revisión manual. Toma nota de cada encabezado y control etiquetado marcado o identificado en el informe.
2. Extrae la lista de encabezados: Usa una extensión del navegador como la extensión HeadingsMap (disponible para Firefox y Chrome) o la herramienta WAVE para generar una lista plana de todos los encabezados de la página, desprovista de su contenido circundante. Lee esta lista como si fuera una tabla de contenidos. Pregunta: ¿podría una persona usuaria entender la estructura y los temas principales de esta página solo a partir de los encabezados, sin leer el texto del cuerpo? Si algún encabezado es ambiguo o poco informativo de forma aislada, es un fallo de 2.4.6.
3. Prueba con NVDA y Firefox: Abre la página y pulsa H para navegar de encabezado en encabezado. Escucha el anuncio de cada encabezado y evalúa si describe el contenido que le sigue. Luego pulsa F para recorrer los campos de formulario y escucha la etiqueta anunciada para cada campo de entrada. Registra cualquier encabezado o etiqueta que no describa claramente su tema o propósito.
4. Prueba con VoiceOver y Safari (macOS/iOS): Usa el Web Rotor (VO+U) para abrir la lista de encabezados y la lista de controles de formulario. Navega por cada lista y evalúa la capacidad descriptiva de cada elemento de forma independiente del contexto de la página. En iOS, usa un gesto de deslizamiento con tres dedos para navegar por encabezados en el Rotor.
5. Prueba con JAWS y Chrome: Pulsa H para navegar por encabezados y usa el Modo formularios (F) para moverte entre controles de formulario. Usa el cuadro de diálogo Lista de encabezados de JAWS (Insert+F6) para ver todos los encabezados en una lista plana, lo que reproduce cómo una persona usuaria de lector de pantalla escanearía la estructura de la página.
6. Evalúa las etiquetas de formulario de forma aislada: Para cada control de formulario, cubre o ignora todo el contexto circundante y lee solo la etiqueta programática (texto visible de la etiqueta, aria-label o destino de aria-labelledby). Confirma que la etiqueta por sí sola es suficiente para entender qué información debe introducirse o qué acción realiza el control.
7. Comprueba si hay texto de encabezado o etiqueta duplicado: Busca en la página texto de encabezado repetido (por ejemplo, varios encabezados «Leer más» o varias secciones «Más información»). Si el mismo texto se usa para encabezados o etiquetas que se refieren a temas o controles diferentes, esto es un incumplimiento de 2.4.6.

Cómo Corregir

Encabezados de Sección Genéricos — Incorrecto

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Encabezados de Sección Genéricos — Correcto

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Etiquetas de Formulario Ambiguas — Incorrecto

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Etiquetas de Formulario Ambiguas — Correcto

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Etiqueta ARIA No Descriptiva en Botón de Icono — Incorrecto

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Etiqueta ARIA No Descriptiva en Botón de Icono — Correcto

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Encabezados o Enlaces «Read More» Repetidos — Incorrecto

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Encabezados o Enlaces «Read More» Repetidos — Correcto

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Errores Comunes

• Usar encabezados posicionales u ordinales como «Paso 1», «Paso 2», «Sección A» sin ningún texto descriptivo: estos encabezados solo indican a la persona usuaria dónde se encuentra en una secuencia, no de qué trata la sección. Combina siempre los indicadores de secuencia con una frase nominal descriptiva, por ejemplo, «Paso 2: Verifica tu dirección de correo electrónico».
• Dar a todas las tarjetas o componentes de artículo en una página de listado el mismo texto de encabezado (por ejemplo, cada tarjeta de producto tiene un <h3> que solo dice «Producto»): cada encabezado de tarjeta debe identificar de forma única ese producto, entrada de blog o elemento específico.
• Usar texto de marcador de posición como etiqueta accesible para un campo de formulario (confiar en el atributo placeholder en lugar de un elemento <label> o aria-label): los marcadores de posición desaparecen al introducir datos y no son anunciados de forma fiable por todos los lectores de pantalla como nombres accesibles. Incluso cuando existe un marcador de posición, se requiere una etiqueta descriptiva independiente.
• Escribir un aria-label que simplemente repite el tipo de elemento en lugar de su propósito, como aria-label='input' en un campo de texto o aria-label='button' en un botón: la etiqueta debe describir qué hace el control o qué valor recopila, no qué tipo de elemento es.
• Usar texto de tooltip o atributos title como única etiqueta para un control de formulario y asumir que esto satisface 2.4.6: las etiquetas basadas en title suelen ser inaccesibles para las personas usuarias que solo usan teclado y no son anunciadas de forma consistente por los lectores de pantalla. En su lugar, confía en elementos <label> visibles o en aria-label.
• Etiquetar campos de búsqueda solo con «Buscar» en una página donde existen varios ámbitos de búsqueda (por ejemplo, búsqueda en todo el sitio y búsqueda dentro de una tabla de datos): cuando dos controles realizan búsquedas diferentes, cada etiqueta debe especificar el ámbito, como «Buscar todos los productos» y «Buscar en el historial de pedidos».
• Aplicar el mismo texto de encabezado al encabezado de un cuadro de diálogo modal que al encabezado principal de la página: los encabezados de los modales deben describir la tarea específica o el contenido del cuadro de diálogo (por ejemplo, «Confirma tu cancelación») en lugar de heredar el título de la página, lo que resultaría confuso para las personas usuarias de lectores de pantalla que navegan dentro del diálogo.
• Omitir un <legend> descriptivo para grupos de botones de opción o casillas de verificación mientras se proporcionan etiquetas para las opciones individuales: el <legend> proporciona un contexto esencial que hace que cada etiqueta individual sea significativa. «Sí» y «No» como etiquetas de opción independientes son poco informativas sin una leyenda como «¿Aceptas los términos y condiciones?».
• Truncar el texto del encabezado en el DOM por motivos de diseño visual (por ejemplo, un encabezado que solo contiene un icono o una sola palabra porque el texto completo está en elementos visuales adyacentes): el encabezado programático debe ser completamente descriptivo porque las personas usuarias de lectores de pantalla lo escuchan sin ver la disposición visual circundante.
• Asumir que, porque una etiqueta es visible para las personas videntes, es suficientemente descriptiva para todas las personas usuarias: una etiqueta que depende de la posición espacial (por ejemplo, un encabezado de columna en una cuadrícula personalizada donde el significado de la etiqueta depende de ver su relación con las celdas circundantes) puede ser visualmente clara pero no transmitir la misma información de forma programática. Verifica siempre que el nombre accesible por sí solo sea suficiente.

Relación con la Normativa de Accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones obligatorias de accesibilidad digital para una amplia gama de entidades públicas y privadas que operan en Turquía. La Circular hace referencia explícita a WCAG 2.1 Nivel AA como el estándar técnico para la conformidad, y los requisitos de Nivel AA según WCAG 2.2 —que es retrocompatible con WCAG 2.1 en el nivel AA— se fomentan firmemente y se exigen a las entidades que buscan el Logotipo de Accesibilidad (Erişilebilirlik Logosu) oficial emitido por el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 es un criterio de Nivel AA, lo que significa que entra de lleno en el ámbito de lo que las entidades cubiertas deben abordar para lograr la conformidad total. Los siguientes tipos de entidades están cubiertos por la Circular Presidencial: instituciones públicas y organismos gubernamentales; plataformas de comercio electrónico; bancos e instituciones financieras; hospitales y proveedores de atención sanitaria; operadores de telecomunicaciones con 200,000 o más abonados; agencias de viajes; empresas de transporte privado; y escuelas privadas autorizadas por el Ministerio de Educación Nacional (Millî Eğitim Bakanlığı).

Para estas entidades, no proporcionar encabezados y etiquetas descriptivos conlleva un riesgo regulatorio concreto. Un portal gubernamental con encabezados de sección vagos impide que las personas con discapacidad accedan a los servicios públicos, lo que entra en conflicto directo con el objetivo declarado de la Circular de garantizar la igualdad de acceso. Un sitio de comercio electrónico con etiquetas de formulario ambiguas en su flujo de pago puede impedir que las personas usuarias con discapacidades visuales o cognitivas completen las compras, lo que constituye una barrera a la participación económica que la Circular está diseñada para eliminar.

Las entidades que buscan el Erişilebilirlik Logosu deben demostrar la conformidad mediante una auditoría de accesibilidad, y 2.4.6 se encuentra entre los criterios que las personas auditoras evaluarán manualmente. Dado que este criterio requiere juicio humano —las herramientas automatizadas no pueden evaluar la capacidad descriptiva—, las organizaciones deben incluir una revisión manual estructurada de todos los encabezados y etiquetas de formulario como parte estándar de su proceso de auditoría de accesibilidad. Integrar esta revisión en los flujos de trabajo de gestión de contenidos y en los sistemas de diseño, en lugar de tratarla como una tarea de auditoría puntual, es la estrategia más eficaz para mantener el cumplimiento continuo a medida que el contenido cambia con el tiempo.