Criterios de éxito de las WCAG · Level AAA

WCAG 1.3.6: Identificar propósito

WCAG 1.3.6 requiere que el propósito de los componentes de la interfaz de usuario, los íconos y las regiones pueda determinarse de forma programática para que los navegadores y las tecnologías de asistencia puedan adaptar la presentación a las necesidades de cada usuario. Este criterio es esencial para las personas con discapacidades cognitivas que se benefician de interfaces personalizadas, simplificadas o enriquecidas con símbolos.

  • Level AAA

Qué significa esta regla

\n

WCAG 1.3.6 — Identify Purpose es un criterio de nivel AAA bajo el Principio 1 (Perceptible) que amplía los requisitos existentes de estructura y semántica a un nivel más fino de granularidad. En concreto, exige que la finalidad de cada componente de la interfaz de usuario, icono, región y ciertos campos de entrada pueda determinarse de forma programática, lo que significa que la información semántica se expone de una manera que los navegadores, las extensiones de navegador y las tecnologías de apoyo puedan leerla y actuar en consecuencia.

\n

El criterio se basa directamente en 1.3.1 (Información y relaciones) y 1.3.5 (Identificar la finalidad de la entrada). Mientras que 1.3.5 se centra en campos de entrada de datos personales comunes (nombre, correo electrónico, teléfono, etc.), 1.3.6 amplía el requisito a todas las regiones y componentes de la interfaz de usuario, incluidos puntos de referencia de navegación, iconos, botones y widgets interactivos. La idea central es que un agente de usuario o una herramienta de personalización debería poder sustituir la presentación predeterminada —reemplazando etiquetas de texto por símbolos, simplificando una navegación recargada o resaltando los controles más relevantes— basándose en datos de finalidad legibles por máquina incrustados en el marcado.

\n

En términos prácticos, una página cumple 1.3.6 cuando utiliza elementos de puntos de referencia de HTML5 (como <header>, <nav>, <main>, <aside>, <footer> y <section>), aplica roles de puntos de referencia ARIA apropiados cuando no se usan elementos de puntos de referencia, expone la finalidad de los iconos y otros componentes de la interfaz de usuario no textuales mediante nombres o roles accesibles y, cuando proceda, utiliza tokens de finalidad estandarizados como los definidos en la especificación W3C Personalization Semantics (anteriormente conocida como la propuesta COGA Semantics), por ejemplo mediante el vocabulario de atributos aui-.

\n

Una página no cumple cuando sus regiones se implementan como contenedores genéricos <div> o <span> sin ningún rol semántico, cuando los iconos tienen significado pero no tienen nombre accesible ni semántica de apoyo, o cuando los componentes interactivos no proporcionan ninguna pista programática sobre su función más allá de su apariencia visible. Se aplica una excepción oficial: el requisito solo se aplica al contenido que se implementa utilizando tecnologías con soporte para identificar el significado esperado. Si no existe una tecnología o especificación de soporte para un tipo de componente concreto en una pila tecnológica determinada, el criterio no puede aplicarse razonablemente a ese componente.

\n\n

Por qué es importante

\n

Los principales beneficiarios de WCAG 1.3.6 son las personas con discapacidades cognitivas y de aprendizaje, incluidas la dislexia, los trastornos por déficit de atención, las condiciones del espectro autista, los deterioros de la memoria y las discapacidades intelectuales. Según la Organización Mundial de la Salud, aproximadamente 1 de cada 6 personas en el mundo —más de mil millones de individuos— vive con algún tipo de discapacidad significativa, y las discapacidades cognitivas representan uno de los grupos más grandes y desatendidos. Muchas de estas personas tienen dificultades con estructuras de navegación complejas, menús de texto densos y controles solo con iconos que no proporcionan un anclaje semántico.

\n

Considera un escenario concreto: una persona con dislexia grave depende de una extensión de navegador que sustituye las etiquetas de navegación estándar por conjuntos de símbolos personales —iconos basados en imágenes de un tablero de comunicación que utiliza en su vida diaria—. Para que esta sustitución funcione, la extensión debe poder determinar que un determinado <div> es en realidad un punto de referencia de navegación, que un icono de estrella representa “añadir a favoritos” y que una flecha circular representa “actualizar”. Sin una finalidad determinable de forma programática, la extensión no tiene nada a lo que engancharse y la sustitución falla silenciosamente, dejando a la persona con una interfaz que no puede interpretar.

\n

Las personas con discapacidad motora que dependen de herramientas de acceso mediante pulsadores o control por voz también se benefician significativamente, porque las herramientas conscientes de la finalidad pueden generar superposiciones de atajos o asignaciones de comandos de voz solo para los controles cuya función es legible por máquina. Las personas ciegas que interactúan mediante lectores de pantalla se benefician de regiones de puntos de referencia claramente etiquetadas, que les permiten saltar directamente al contenido de <main> o omitir la navegación repetitiva. Las personas con baja visión que utilizan zoom del navegador u hojas de estilo personalizadas se benefician de la estructura de puntos de referencia porque permite que el navegador redistribuya el contenido de forma predecible.

\n

Más allá de la accesibilidad, implementar la semántica requerida por 1.3.6 produce beneficios de SEO medibles. Los rastreadores de motores de búsqueda utilizan el marcado de puntos de referencia y de esquema para comprender la estructura de la página, indexar jerarquías de contenido y generar resultados enriquecidos. Una página bien estructurada con regiones de puntos de referencia significativas tiene más probabilidades de obtener fragmentos destacados y puntuaciones de relevancia más altas. También hay un dividendo de usabilidad directo: las páginas con una estructura semántica clara son más fáciles de mantener, probar y ampliar por los equipos de desarrollo, lo que reduce la deuda técnica a largo plazo.

\n\n

Reglas relacionadas de Axe-core

\n

WCAG 1.3.6 requiere pruebas manuales además de cualquier comprobación automatizada. Las herramientas automatizadas pueden verificar la presencia de marcado semántico, pero no pueden determinar si ese marcado transmite de forma precisa y completa la finalidad de cada componente como lo haría una persona que realiza pruebas. Las siguientes reglas de axe-core están estrechamente relacionadas y sirven como proxies automatizados para aspectos de este criterio:

\n
    \n
  • region — Comprueba que todo el contenido de la página esté contenido dentro de una región de punto de referencia. Señala el contenido que se encuentra fuera de cualquier elemento de punto de referencia reconocido o rol de punto de referencia ARIA. Aunque esta regla no prueba la precisión de la identificación de la finalidad, garantiza que esté presente la base estructural requerida por 1.3.6. Un fallo significa que contenido significativo es invisible para la navegación basada en puntos de referencia.
  • \n
  • landmark-one-main — Verifica que la página contenga exactamente un elemento <main> o un elemento con role='main'. Esto es fundamental para 1.3.6 porque el área de contenido principal es una de las regiones más críticas cuya finalidad debe ser identificable. Puntos de referencia <main> múltiples o ausentes hacen imposible que las herramientas de personalización aíslen el contenido principal.
  • \n
  • landmark-complementary-is-top-level — Comprueba que los elementos <aside> o las regiones con role='complementary' no estén anidados dentro del área de contenido principal de una manera que tergiverse su finalidad. Un anidamiento incorrecto induce a error a las tecnologías de apoyo sobre la relación entre regiones.
  • \n
  • aria-allowed-role y aria-valid-attr-value — Señalan asignaciones de roles ARIA no válidas o inapropiadas. Dado que 1.3.6 depende de una semántica de roles precisa, el uso de un rol incorrecto (por ejemplo, role='navigation' en un grupo de botones) socava activamente la identificación de la finalidad y estas reglas sacarán a la luz tales desajustes.
  • \n
  • button-name y link-name — Verifican que los controles interactivos tengan nombres accesibles. Los botones e hipervínculos solo con iconos y sin nombres accesibles son un modo de fallo principal para 1.3.6, ya que no se puede determinar la finalidad de un control sin nombre. Estas reglas señalan la ausencia de aria-label, aria-labelledby o texto visible.
  • \n
\n

Se requieren pruebas manuales porque las herramientas automatizadas no pueden evaluar si los tokens de finalidad o los roles semánticos elegidos representan con precisión la función real del componente dentro del contexto de la aplicación. Un botón podría tener un nombre accesible y un rol ARIA válido, pero aun así no cumplir 1.3.6 si el nombre es engañoso o el rol no refleja lo que el control realmente hace.

\n\n

Cómo hacer las pruebas

\n
    \n
  1. Ejecuta un análisis automatizado con axe DevTools o Lighthouse. Abre la página en Chrome, activa la extensión axe DevTools y ejecuta un análisis de página completa. Filtra los resultados por las reglas mencionadas anteriormente: region, landmark-one-main, button-name y link-name. Anota cualquier infracción y sus niveles de impacto. En Lighthouse, ejecuta una auditoría de Accesibilidad y revisa las secciones de puntos de referencia y ARIA. Documenta todos los fallos como línea de base, pero ten en cuenta que representan solo un subconjunto del cumplimiento de 1.3.6.
  2. \n
  3. Inspecciona manualmente la estructura de puntos de referencia utilizando las herramientas de desarrollo del navegador. Abre DevTools, navega al panel Accessibility Tree (Chrome) o al Accessibility Inspector (Firefox) y verifica que la página exponga una jerarquía coherente de puntos de referencia: un <header> en el nivel superior, un <main>, al menos un <nav> (con una etiqueta diferenciadora si hay varios) y un <footer>. Confirma que ninguna región de contenido significativa esté envuelta solo en un <div> o <span> genérico.
  4. \n
  5. Haz pruebas con NVDA y Firefox. Inicia NVDA, abre la página en Firefox y pulsa D para recorrer los puntos de referencia. Verifica que cada punto de referencia se anuncie con un rol significativo y, cuando existan varios puntos de referencia del mismo tipo, con una etiqueta única. Navega hasta cada botón solo con icono usando la tecla Tab y confirma que NVDA anuncia un nombre accesible descriptivo, no una cadena vacía, un nombre de archivo o una etiqueta genérica como “button”.
  6. \n
  7. Haz pruebas con VoiceOver y Safari (macOS/iOS). Activa VoiceOver (Cmd+F5 en macOS). Usa el Rotor (Vo+U) para abrir la lista de puntos de referencia y verifica que aparezcan todas las regiones esperadas. Recorre los controles interactivos con la tecla Tab y escucha descripciones significativas. En iOS, usa un gesto de tres dedos para navegar por encabezados y puntos de referencia y confirma que la finalidad de cada región se anuncie correctamente.
  8. \n
  9. Haz pruebas con JAWS y Chrome. Abre la página en Chrome con JAWS en ejecución. Pulsa R para navegar por regiones y confirma que el rol y la etiqueta de cada región sean precisos. Usa el Cursor Virtual de JAWS para leer los botones con iconos y verificar que se transmita su finalidad. Usa la Lista de enlaces de JAWS (Insert+F7) para revisar la relevancia de todos los nombres de enlaces.
  10. \n
  11. Prueba la semántica de personalización (si está implementada). Si tu página utiliza el vocabulario W3C Personalization Semantics (por ejemplo, atributos data-purpose o aui-), utiliza la herramienta de prueba Personalization Semantics o una extensión de navegador compatible para verificar que los tokens de finalidad se apliquen correctamente y sean legibles por máquina para los agentes de usuario que admiten la especificación.
  12. \n
  13. Lleva a cabo una auditoría de finalidad componente por componente. Para cada componente interactivo e icono de la página, pregúntate: ¿se puede determinar la finalidad de este componente sin contexto visual? Si al eliminar todo el CSS y las imágenes la finalidad del componente sigue siendo clara solo a partir del DOM y los atributos ARIA, cumple. Si la finalidad solo se transmite visualmente, no cumple.
  14. \n
\n\n

Cómo solucionarlo

\n\n

Regiones div genéricas sin puntos de referencia — Incorrecto

\n
<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>
\n\n

Regiones div genéricas sin puntos de referencia — Correcto

\n
<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>
\n\n

Botón solo con icono sin nombre accesible — Incorrecto

\n
<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>
\n\n

Botón solo con icono sin nombre accesible — Correcto

\n
<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>
\n\n

Múltiples puntos de referencia de navegación sin etiquetas diferenciadoras — Incorrecto

\n
<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)