Información y relaciones

Qué exige

Todo lo que puede percibirse de un vistazo —que este texto grande y en negrita es un encabezado, que estas filas forman una tabla de datos, que este grupo de campos corresponde a la «dirección de facturación», que este asterisco indica un campo obligatorio— debe estar presente también en el código subyacente. Los lectores de pantalla, el software de control por voz y los motores de reflujo solo leen el marcado. Si una relación es puramente visual (una fuente mayor, un borde más grueso, una sangría), la tecnología de apoyo no percibe nada.

Cómo cumplirlo

• Usar elementos de encabezado reales (<h1> a <h6>) en un orden de anidamiento lógico; nunca un <div> con estilos para simular un encabezado.
• Marcar las listas con <ul>, <ol> y <li>, no con párrafos separados por saltos de línea o caracteres de viñeta.
• Usar <table> con <th scope="col"> / <th scope="row"> para tablas de datos, con <caption> que describa el propósito de la tabla.
• Cada control de formulario necesita una etiqueta programática: <label for="...">, aria-labelledby o aria-label. El texto de marcador de posición no es una etiqueta.
• Agrupar los campos de formulario relacionados en <fieldset> con <legend>, o usar role="group" con aria-labelledby para componentes personalizados.
• Para figuras y pies de foto, usar <figure> y <figcaption>. Para pares de definición, usar <dl> / <dt> / <dd>.
• Indicar los campos obligatorios tanto visualmente (asterisco) como de forma programática (aria-required="true" o el atributo required).

Errores habituales

• <div class="heading-1"> en lugar de <h1>: visualmente correcto, pero no anuncia nada como encabezado.
• Tablas de diseño usadas para columnas visuales, o tablas de datos construidas con cuadrículas de <div> sin celdas <th>.
• Campos de formulario con etiquetas únicamente como marcador de posición: la etiqueta desaparece al activar el foco y los lectores de pantalla pueden no anunciarla.
• Viñetas simuladas con <p>•&nbsp;Elemento</p> en lugar de marcado de lista real.
• Asteriscos de campo obligatorio mostrados en CSS rojo sin atributo aria-required o required.
• Botones de opción agrupados visualmente sin <fieldset> / <legend>, lo que deja a los usuarios de lector de pantalla con opciones flotantes sin la pregunta asociada.
• Tablas de datos en las que la fila de encabezado está en negrita pero usa <td> en lugar de <th>.

Por qué importa

El criterio 1.3.1 es el criterio de conformidad más citado en las auditorías de accesibilidad web después del 1.1.1 y el 1.4.3. Cada página generada por un CMS, cada página de aterrizaje de marketing, cada componente de formulario personalizado suele incumplir al menos una parte de este criterio. La corrección es casi siempre HTML semántico, no ARIA: cuando se recurre a role="heading" para reparar un <div> que debería haber sido <h2>, el problema ya está hecho.