Importancia de WCAG 1.3.1 en la Accesibilidad Web

¿Qué dice WCAG 1.3.1?

El criterio WCAG 1.3.1, conocido como «Información y relaciones», es un pilar fundamental para construir una web verdaderamente inclusiva. En esencia, nos pide que toda la información y las relaciones que comunicamos a través de la presentación visual o auditiva de nuestro contenido también puedan ser entendidas por medios programáticos (es decir, por el código) o estén disponibles en texto simple.

Imagina esto: los usuarios visuales percibimos la estructura de una página gracias a claves visuales. Los títulos son más grandes y en negrita, las listas tienen viñetas, los párrafos están separados por espacios, los campos de un formulario se agrupan visualmente, o un color de fondo diferente indica que varios elementos están relacionados. Todas estas son «relaciones» y «estructuras» que nuestro cerebro procesa al instante.

Pero, ¿qué pasa si alguien usa un lector de pantalla, una lupa, o tiene una hoja de estilo personalizada? Si estas relaciones solo existen visualmente, estas personas perderán información crucial. WCAG 1.3.1 busca evitar eso, garantizando que cuando la presentación cambie, el significado original se mantenga intacto. La información importante para la comprensión debe ser percibida por todos.

Por ejemplo, si un enlace a un glosario se distingue por un tipo de letra especial, un usuario de lector de pantalla seguirá sabiendo que es un enlace, incluso si no percibe el cambio de fuente. O si el precio de un producto se muestra en rojo y grande, el lector de pantalla seguirá leyendo el precio completo porque lo importante es la información textual, no el color. Cuando las tecnologías lo permiten, es mucho mejor que estas relaciones se determinen programáticamente a que se describan solo en texto (como «todos los campos requeridos están marcados con un asterisco»).

Cómo implementarlo paso a paso

Para cumplir con WCAG 1.3.1, el secreto está en usar el código de forma semántica. Aquí te mostramos cómo:

1. Estructura tu contenido con HTML Semántico (H101, G115)

Usa las etiquetas HTML con el propósito para el que fueron creadas. Esto le da a tu contenido una estructura lógica que los navegadores y tecnologías asistivas pueden entender. ¡Es como construir con ladrillos que ya tienen un nombre y una función!

<header>
  <!-- Contenido del encabezado, como el logo y la navegación -->
</header>
<nav aria-label="Navegación principal">
  <ul>
    <li><a href="#">Inicio</a></li>
    <li><a href="#">Servicios</a></li>
  </ul>
</nav>
<main role="main">
  <!-- Contenido principal de la página -->
  <article>
    <h1>Título de mi Artículo</h1>
    <section>
      <h2>Una Sección Importante</h2>
      <p>Este es un párrafo de contenido.</p>
    </section>
  </article>
  <aside>
    <!-- Contenido secundario, como una barra lateral -->
  </aside>
</main>
<footer>
  <!-- Contenido del pie de página -->
</footer>

2. Usa Encabezados Correctamente (ARIA12)

Define la jerarquía de tu página con las etiquetas <h1> a <h6>. Un <h1> por página para el título principal, y luego <h2>, <h3>, etc., para subtítulos, siguiendo un orden lógico. Esto permite a los usuarios de lectores de pantalla navegar rápidamente por la estructura del contenido.

<h1>El Título de la Noticia</h1>
<h2>Primer Apartado Interesante</h2>
<p>Aquí va el desarrollo del primer apartado.</p>
<h3>Un Punto Específico del Apartado</h3>
<p>Detalle sobre este punto.</p>

3. Agrupa Controles de Formulario (ARIA17)

Si tienes un grupo de campos relacionados en un formulario (por ejemplo, opciones de pago, preguntas con múltiples respuestas), usa <fieldset> con una <legend>. Esto asocia lógicamente los campos, y los lectores de pantalla anunciarán la relación.

<fieldset>
  <legend>Elige tu método de pago</legend>
  <input type="radio" id="tarjeta" name="pago" value="tarjeta">
  <label for="tarjeta">Tarjeta de Crédito</label><br>
  <input type="radio" id="paypal" name="pago" value="paypal">
  <label for="paypal">PayPal</label>
</fieldset>

Para etiquetas más complejas, usa aria-labelledby (ARIA16) para asociar un texto visible a un control.

4. Destaca el Texto con Semántica (H49)

Para enfatizar texto, usa <strong> (para importancia) o <em> (para énfasis). Evita usar solo CSS (como poner texto en negrita con font-weight: bold;) si el énfasis conlleva un significado importante. Las etiquetas semánticas comunican ese significado a todos los usuarios.

<p>Esta parte del texto es <strong>muy importante</strong>.</p>
<p>Quiero <em>enfatizar</em> esta palabra.</p>

5. Identifica Regiones con ARIA Landmarks (ARIA11)

Además del HTML semántico, puedes usar roles ARIA para identificar regiones clave de tu página, especialmente si estás usando elementos más genéricos como <div> (aunque siempre prioriza el HTML semántico). Las etiquetas semánticas de HTML5 (como <main>, <nav>, <aside>) ya tienen roles ARIA implícitos, lo cual es ideal.

<div role="search">
  <!-- Campo de búsqueda -->
</div>
<div role="contentinfo">
  <!-- Información de copyright, etc. -->
</div>

6. Ofrece Información en Texto cuando sea Necesario (G117)

Si usas un indicador visual (como un color o un icono) para comunicar información, asegúrate de que también haya una alternativa textual. Por ejemplo, si un campo es obligatorio, no solo lo marques en rojo, añade también un asterisco y un texto que diga «*Campo obligatorio».

<label for="email">Email <span class="requerido">(obligatorio)</span>:</label>
<input type="email" id="email" aria-required="true">

Si usas un icono para transmitir significado, asegúrate de que tenga role="img" y un aria-label (ARIA24) descriptivo.

<span class="icono-info" role="img" aria-label="Información adicional"></span>

7. Separa Contenido de Presentación (G140)

Mantén tu HTML limpio y dedicado a la estructura y el contenido, dejando los estilos visuales completamente al CSS. Esto permite que el contenido sea adaptable a diferentes necesidades y dispositivos.

Errores comunes y cómo evitarlos

Evita estas prácticas para asegurar el cumplimiento del 1.3.1:

• Comunicar información solo con cambios visuales (F2): No uses solo el color o el tamaño de la fuente para comunicar un error o un estado importante. Siempre acompaña estos cambios con texto, atributos ARIA o etiquetas semánticas que lo hagan programáticamente accesible.
• Maquetar con espacios y saltos de línea (F33, F34): Crear columnas o tablas usando espacios, tabulaciones o múltiples saltos de línea es una mala práctica. Los lectores de pantalla no interpretan esto como una estructura. Usa CSS Grid/Flexbox para maquetar columnas y la etiqueta <table> para datos tabulares.
• Uso incorrecto del marcado estructural (F43): No uses una etiqueta <h2> para algo que no es un encabezado solo porque te gusta el tamaño de fuente. Usa la etiqueta correcta para el propósito correcto y ajusta el estilo con CSS.
• Problemas con la accesibilidad de tablas (F46, F48, F90, F91): Evita usar <th> en tablas de maquetación, usar la etiqueta <pre> para mostrar información tabular, o asociar incorrectamente los encabezados con las celdas de datos. Usa <table> solo para datos tabulares, con <th>, <caption>, el atributo scope (para encabezados de fila/columna) y, si es necesario, headers/id para tablas complejas.
• Ocultar la semántica con role="presentation" (F92): No uses role="presentation" o role="none" en elementos que transmiten información semántica importante. Esto indicaría a las tecnologías asistivas que ignoren ese elemento y su significado.

Cómo testear que tu implementación es correcta

Probar es crucial para verificar que tu sitio web cumple con este criterio:

• Navega solo con el teclado: Asegúrate de que puedes acceder a todos los elementos interactivos y entender su propósito sin usar el mouse. ¿El orden de tabulación es lógico?
• Usa un lector de pantalla: Instala un lector de pantalla (como NVDA o JAWS en Windows, VoiceOver en macOS, o Narrator en Windows) y navega por tu sitio. ¿Se anuncian correctamente los encabezados, listas, campos de formulario y sus agrupaciones? ¿Se pierde alguna relación o información?
• Desactiva CSS: Quita las hojas de estilo de tu navegador o usa una extensión. ¿La estructura del contenido sigue siendo lógica y comprensible? Si la respuesta es sí, ¡vas por buen camino!
• Herramientas de inspección del navegador: Utiliza las herramientas de desarrollo de tu navegador para inspeccionar el DOM y verificar que los atributos ARIA y las etiquetas semánticas se estén utilizando correctamente.

Conclusión

El WCAG 1.3.1 no es solo una regla; es una invitación a pensar en cómo todas las personas perciben y entienden el contenido que creamos. Al aplicar correctamente las técnicas de HTML semántico y ARIA, no solo cumplimos con un estándar, sino que construimos experiencias digitales más sólidas, coherentes y, lo más importante, accesibles para absolutamente todos.

Si te interesa seguir profundizando en la accesibilidad, te invitamos a leer nuestro artículo anterior, «WCAG 1.2.5: Audiodescripciones Grabadas para Videos Inclusivos«, donde exploramos cómo hacer tus videos más inclusivos.

En itgrarte fundación estamos comprometidos con la creación de experiencias digitales inclusivas. Si necesitas ayuda para asegurar que tu sitio web cumpla con los estándares de accesibilidad, no dudes en contactarnos.