WCAG 1.3.1: Información y relaciones

Qué significa esta regla

WCAG 1.3.1 — Información y relaciones es un criterio de Nivel A bajo el principio de Perceptible. Su requisito central es sencillo pero de gran alcance: cualquier información o relación que se comunique visualmente también debe expresarse de una manera que las tecnologías de asistencia puedan detectar y transmitir a las personas usuarias. Si tu diseño utiliza pistas visuales — sangría para implicar una lista, texto en negrita para marcar un campo obligatorio, color para indicar un error o tamaño para denotar un encabezado — esas mismas semánticas deben existir en el código subyacente.

El criterio se aplica a tres categorías de significado que el contenido web transmite habitualmente a través de la presentación:

• Información — hechos o datos comunicados en la página, como qué campos de un formulario son obligatorios o qué celdas de una tabla comparten una relación.
• Estructura — el esquema organizativo del contenido, como jerarquías de encabezados, listas ordenadas o desordenadas y tablas de datos.
• Relaciones — asociaciones entre elementos, como una etiqueta y su campo de entrada, un encabezado de tabla y sus celdas de datos, o un término y su definición.

Una página cumple con 1.3.1 cuando cada pieza de información estructural o relacional disponible para una persona vidente está codificada en HTML semántico válido o expuesta mediante un rol, propiedad o estado ARIA correcto que las tecnologías de asistencia puedan interpretar. Una página falla cuando la estructura visual existe solo en CSS o imágenes, o cuando el marcado ARIA contradice o está ausente de la estructura del DOM que se presenta.

Las excepciones oficiales son mínimas. El criterio no exige que toda decoración visual tenga significado semántico — el formato puramente estético, como un borde decorativo o un color de fondo, no necesita un equivalente programático. Sin embargo, cualquier formato que una persona usuaria razonablemente interpretaría como portador de significado (asteriscos de obligatoriedad, términos en negrita en un glosario, pasos numerados) debe tener una expresión programática correspondiente.

Por qué importa

La información y las relaciones sustentan casi todas las interacciones que una persona usuaria tiene con una página web. Cuando esa estructura queda encerrada únicamente en la presentación visual, una parte significativa de la población queda efectivamente excluida de comprender el contenido.

Las personas usuarias de lectores de pantalla — normalmente personas ciegas o con baja visión — navegan por las páginas consultando el árbol de accesibilidad, que se construye a partir de HTML semántico y ARIA. Cuando una persona desarrolladora usa un <div> con estilo para parecer un encabezado en lugar de un <h2> real, una persona usuaria de lector de pantalla que salta entre encabezados con la tecla H lo omitirá por completo. Puede que nunca encuentre la sección que introduce. Según la Organización Mundial de la Salud, aproximadamente 2,2 mil millones de personas en todo el mundo viven con algún tipo de discapacidad visual, y decenas de millones dependen de lectores de pantalla a diario.

Las personas con discapacidades cognitivas se benefician igualmente de una estructura clara. Encabezados correctamente anidados, marcado de listas significativo y controles de formulario etiquetados reducen la carga cognitiva al proporcionar patrones predecibles. Un lector de pantalla que anuncia "encabezado de nivel 2, Productos" seguido de "encabezado de nivel 3, Portátiles" ofrece un mapa cognitivo de la página. Un muro plano de texto con estilo sin anclajes estructurales desorienta a todo el mundo, pero especialmente a las personas con dificultades de atención o memoria.

Las personas con discapacidad motriz que dependen de la navegación por teclado, el acceso por pulsadores o el software de control por voz también dependen de la estructura programática. El software de control por voz como Dragon NaturallySpeaking genera objetivos clicables a partir de nombres accesibles derivados de etiquetas y roles — los campos de formulario sin etiquetas asociadas simplemente no pueden ser dirigidos de forma fiable mediante comandos de voz.

Considera un escenario concreto: un portal de pacientes de un hospital muestra una tabla de próximas citas. La tabla utiliza alineación visual y color de fondo para asociar fechas con médicos, pero los elementos <th> carecen de atributos scope y las celdas de datos no hacen referencia a encabezados. Una persona ciega con un lector de pantalla escucha valores de celdas aislados — "9:00 AM", "Dra. Ayşe Kaya", "Cardiología" — sin forma de saber qué valor pertenece a qué columna. Puede interpretar mal la hora de su cita o presentarse en el departamento equivocado. El uso correcto de scope='col' en los encabezados y de atributos headers en las celdas habría hecho audibles las relaciones.

Más allá de la accesibilidad, el HTML estructural tiene un valor significativo para el SEO. Los rastreadores de motores de búsqueda utilizan las jerarquías de encabezados para comprender los temas de la página, el marcado de listas para identificar contenido enumerado y las asociaciones de etiquetas para entender la finalidad de los formularios. Una página que cumple con 1.3.1 casi siempre es una página que los motores de búsqueda pueden analizar y clasificar con mayor precisión.

Reglas relacionadas de axe-core

Las siguientes reglas de axe-core se corresponden directamente con infracciones de WCAG 1.3.1. Cada regla se centra en un aspecto específico de la estructura o relación programática:

• aria-required-children — Comprueba que los elementos con determinados roles ARIA contengan los roles secundarios requeridos. Por ejemplo, un role='list' debe contener elementos secundarios con role='listitem'. Sin la estructura secundaria correcta, la relación entre un contenedor y sus elementos se rompe para las tecnologías de asistencia.
• aria-required-parent — La inversa de la anterior: comprueba que los elementos con roles que requieren un contexto de elemento padre específico realmente tengan ese padre. Un role='listitem' que no está dentro de un role='list' o de un contenedor <ul>/<ol> se marca porque falta el contexto relacional.
• aria-roles — Valida que todos los valores del atributo role sean roles ARIA válidos. Un rol no válido o mal escrito (por ejemplo, role='heading' en lugar de usar un elemento de encabezado, o un rol completamente inventado) significa que la tecnología de asistencia no recibe información útil y puede ignorar el elemento por completo.
• definition-list — Verifica que los elementos <dl> contengan solo elementos secundarios permitidos: <dt>, <dd>, <div>, <script> y <template>. Insertar otros elementos como <p> directamente dentro de un <dl> invalida la estructura de relación término-definición.
• dlitem — Comprueba que los elementos <dt> y <dd> solo se utilicen dentro de elementos <dl>. Usar estos elementos fuera de su contexto de elemento padre requerido destruye el significado semántico del par término-definición.
• heading-order — Señala niveles de encabezado que se omiten en el esquema del documento (por ejemplo, saltar de <h2> a <h4>). Aunque no siempre es un fallo estricto, omitir niveles induce a error a las tecnologías de asistencia sobre la estructura jerárquica de la página y confunde a las personas usuarias que navegan por encabezados.
• label — Verifica que cada campo de formulario tenga una etiqueta asociada programáticamente, ya sea mediante <label for='...'>, aria-label, aria-labelledby o un elemento <label> envolvente. Un campo sin etiqueta accesible niega a las personas ciegas y usuarias de control por voz la información que necesitan para entender qué deben introducir.
• list — Garantiza que los elementos <ul> y <ol> contengan solo elementos <li> como elementos secundarios directos (además de <script> y <template>). Los elementos secundarios no válidos rompen la estructura de lista que los lectores de pantalla utilizan para anunciar el número de elementos y sus posiciones.
• listitem — Comprueba que los elementos <li> solo se utilicen dentro de contenedores <ul>, <ol> o role='list'. Los elementos de lista huérfanos pierden por completo su significado semántico.
• scope-attr-valid — Valida que el atributo scope en los elementos <th> contenga solo los valores permitidos: col, row, colgroup o rowgroup. Un valor de scope no válido o ausente en una tabla de datos compleja significa que los lectores de pantalla no pueden anunciar de forma fiable qué encabezado se aplica a una celda de datos determinada.
• td-headers-attr — Comprueba que, cuando las celdas de datos utilizan el atributo headers, cada ID referenciado exista realmente en la misma tabla y pertenezca a una celda de encabezado. Las referencias rotas o ausentes cortan la relación programática entre los datos y su encabezado descriptivo, dejando a las personas usuarias de lectores de pantalla sin contexto.

Ten en cuenta que las herramientas automatizadas como axe-core no pueden detectar todas las infracciones de 1.3.1. Por ejemplo, una persona desarrolladora podría usar un <div> con estilo visual con role='list' y elementos secundarios role='listitem' correctamente estructurados — axe lo aprobará — pero una persona evaluadora humana podría descubrir que la sangría visual implica una sublista anidada que no está representada en la estructura ARIA. Siempre que la jerarquía visual sea compleja, la inspección manual y las pruebas con lectores de pantalla son complementos esenciales al escaneo automatizado.

Cómo probar

1. Análisis automatizado con axe DevTools o Lighthouse: Instala la extensión de navegador axe DevTools (Chrome o Firefox). Abre la página que quieres probar, abre las DevTools, ve a la pestaña de axe y ejecuta un análisis de página completa. Filtra los resultados por la etiqueta wcag131 o revisa todos los problemas etiquetados bajo "Info and Relationships". Busca específicamente infracciones de las once reglas de axe enumeradas arriba. En Lighthouse (panel Audits de Chrome DevTools), ejecuta una auditoría de accesibilidad y revisa la categoría "Accessibility" para detectar fallos relacionados con el orden de encabezados, etiquetas y listas. Anota todos los elementos marcados y sus selectores DOM para su corrección.
2. Revisión manual de la estructura de encabezados: Utiliza la extensión de navegador HeadingsMap o el panel "Headings" en axe DevTools para ver el esquema completo de encabezados de la página. Verifica que el esquema sea lógico y jerárquico — debería leerse como una tabla de contenidos bien estructurada. Confirma que no se omiten niveles de encabezado y que el texto de los encabezados es significativo y no solo estilo visual aplicado a elementos que no son encabezados.
3. Verificación de etiquetas de formularios: Recorre con la tecla Tab cada elemento de formulario interactivo de la página. Para cada input, select y textarea, confirma que haya una etiqueta visible y que esté asociada programáticamente (comprueba el elemento en DevTools y busca un par for/id coincidente, o un aria-label/aria-labelledby). Utiliza el árbol de accesibilidad en Chrome DevTools (panel Elements → pestaña Accessibility) para confirmar el nombre accesible calculado de cada control.
4. Pruebas con lector de pantalla usando NVDA + Firefox: Inicia NVDA y abre la página en Firefox. Pulsa H para desplazarte por los encabezados y verifica que los niveles de encabezado anunciados coincidan con la jerarquía visual. Pulsa F para moverte entre los campos de formulario y confirma que se anuncie la etiqueta de cada campo. Pulsa T para navegar por las tablas y recorre las celdas con las flechas, escuchando los encabezados anunciados. Pulsa L para desplazarte por las listas y confirma que se anuncie el número de elementos.
5. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Activa VoiceOver (Cmd+F5 en macOS). Abre el Rotor (Ctrl+Option+U) y revisa Headings, Links, Form Controls y Tables. Confirma que todos los elementos estructurales aparezcan en el Rotor y que los nombres anunciados sean significativos y precisos.
6. Pruebas con lector de pantalla usando JAWS + Chrome: Abre JAWS y la página en Chrome. Utiliza la Lista de encabezados de JAWS (Insert+F6) para revisar el árbol de encabezados. Utiliza Insert+F5 para los campos de formulario y verificar las asociaciones de etiquetas. Navega por las tablas con las teclas de flecha y confirma que JAWS anuncie los encabezados de columna y fila para cada celda de datos.
7. Comprobación de la relación entre encabezados de tabla: Identifica todas las tablas de datos de la página. Para tablas simples, verifica que los elementos <th> tengan atributos scope apropiados. Para tablas complejas con encabezados multinivel, verifica que las celdas de datos utilicen el atributo headers haciendo referencia a los valores de id correctos. Traza visualmente cada celda hasta sus encabezados lógicos de fila y columna, y luego confirma que la misma ruta esté representada en el código.

Cómo corregir

Encabezados visuales implementados como divs con estilo — Incorrecto

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Encabezados visuales implementados como divs con estilo — Correcto

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Campo de formulario sin etiqueta asociada — Incorrecto

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Campo de formulario sin etiqueta asociada — Correcto

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Tabla de datos sin atributos scope — Incorrecto

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Tabla de datos sin atributos scope — Correcto

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Elementos de lista usados fuera de un contenedor de lista — Incorrecto

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Elementos de lista usados fuera de un contenedor de lista — Correcto

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Errores comunes

• Usar únicamente CSS font-size y font-weight para crear la apariencia visual de encabezados en elementos <div> o <span>, sin añadir nunca role='heading' y aria-level ni convertirlos en elementos <h1>–<h6> reales — los lectores de pantalla no pueden descubrirlos como encabezados navegables.
• Usar texto de placeholder como única etiqueta para campos de formulario, lo que hace que la etiqueta desaparezca en cuanto la persona usuaria empieza a escribir, dejando el campo sin etiquetar durante todo el tiempo de introducción — siempre empareja los campos con un elemento <label> persistente.
• Marcar campos obligatorios con un asterisco rojo (*) que solo se explica en una leyenda visual en la parte superior del formulario, sin añadir aria-required='true' ni incluir "required" en la etiqueta programática para que las personas usuarias de lectores de pantalla reciban la misma información.
• Aplicar list-style: none mediante CSS a un <ul> sin entender que algunos lectores de pantalla (en particular Safari + VoiceOver) pueden dejar de anunciar el elemento como una lista — si las semánticas de lista son significativas, añade explícitamente role='list' para preservarlas.
• Omitir niveles de encabezado — por ejemplo, colocar un <h4> directamente después de un <h2> porque la persona diseñadora quería un texto más pequeño — en lugar de usar el nivel de encabezado correcto y controlar la apariencia visual mediante CSS.
• Construir tablas de datos complejas con celdas combinadas (colspan/rowspan) sin añadir el atributo headers en las celdas de datos, dejando a las personas usuarias de lectores de pantalla sin poder determinar qué encabezado rige una celda combinada ambigua.
• Usar elementos <table> con fines de maquetación y luego añadir role='presentation' de forma inconsistente — algunas celdas siguen conteniendo encabezados que se anuncian fuera de contexto, confundiendo a las personas usuarias que no pueden ver que la tabla es puramente decorativa.
• Envolver un par <dt>/<dd> dentro de un <p> o <div> que es un elemento secundario directo de un <dl> sin entender que en HTML5 solo se permiten contenedores <div> dentro de <dl>, y que mezclar otros elementos de bloque destruye la estructura de la lista de definiciones.
• Añadir aria-labelledby en un campo de entrada que hace referencia a un ID que no existe en el DOM, o que hace referencia al ID de un elemento que no es de texto — el nombre accesible calculado queda vacío y el campo de entrada queda efectivamente sin etiquetar para las tecnologías de asistencia.
• Suponer que, porque una página se ve correctamente de forma visual y obtiene una puntuación de Lighthouse superior a 90, cumple con 1.3.1 — las herramientas automatizadas no pueden detectar todas las infracciones estructurales, como las relaciones de anidamiento visual que no se reflejan en la jerarquía de roles ARIA, lo que exige una verificación manual y con lectores de pantalla obligatoria.

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 web alineadas con WCAG 2.2 para una amplia gama de entidades que operan en Turquía. WCAG 1.3.1 es un criterio de Nivel A, lo que significa que se sitúa en el nivel fundamental de conformidad — el nivel mínimo aceptable de accesibilidad — y, por tanto, es plenamente obligatorio para todas las entidades cubiertas por la circular.

La circular define dos plazos de cumplimiento. Las instituciones públicas — incluidos los organismos de la administración central, los municipios, las universidades públicas y los hospitales públicos — deben lograr la conformidad total de Nivel A en el plazo de un año desde la entrada en vigor de la circular. Las entidades del sector privado cubiertas por la regulación disponen de un plazo de dos años para cumplirla. Sin embargo, la obligación no es opcional para ninguno de los dos grupos: el incumplimiento expone a las entidades cubiertas a un escrutinio regulatorio y a posibles medidas de ejecución.

Las entidades del sector privado explícitamente cubiertas por la circular incluyen plataformas de comercio electrónico, bancos e instituciones financieras, hospitales privados y proveedores de atención sanitaria, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privadas y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (MoNE). Cualquiera de estas entidades que opere un sitio web de cara al público o una aplicación web móvil debe garantizar que 1.3.1 se cumpla en todas sus propiedades digitales.

Para fines prácticos de cumplimiento, 1.3.1 es uno de los criterios de Nivel A más impactantes porque rige la estructura fundamental de la página. Un sitio de comercio electrónico turco cuyas páginas de categorías de productos utilicen elementos <div> con estilo para los encabezados, cuyos campos de formulario de pago carezcan de asociaciones de etiquetas o cuyo resumen de pedido sea una tabla no estructurada sin atributos scope incumpliría 1.3.1 de forma generalizada. La corrección no es solo una obligación legal — mejora directamente la experiencia de las aproximadamente 700,000 o más personas ciegas y con baja visión en Turquía que dependen de tecnologías de asistencia para comprar, hacer operaciones bancarias, acceder a la atención sanitaria y relacionarse con los servicios gubernamentales en línea.

Se recomienda a las organizaciones que deseen demostrar su cumplimiento que realicen tanto análisis automatizados con axe-core como auditorías manuales con lectores de pantalla que abarquen toda la amplitud de su contenido digital. La accesibilidad estructural — la base que refuerza 1.3.1 — debe integrarse en los sistemas de diseño y las bibliotecas de componentes para que el cumplimiento se mantenga a medida que se crea y actualiza el contenido, en lugar de tratarse como un ejercicio de corrección puntual.