MetaEl propósito de los componentes de interfaz, iconos y regiones puede determinarse programáticamente para que el software los adapte.
Qué hacerUsa landmarks HTML5, roles ARIA y nombres accesibles descriptivos en todos los componentes e iconos para exponer su propósito funcional.
Por qué importaPermite que el software adapte la interfaz con símbolos o estilos familiares para usuarios con discapacidades cognitivas, del lenguaje o que usan sistemas AAC.
En contenido implementado mediante lenguajes de marcado, el propósito de los componentes de la interfaz de usuario, los iconos y las regiones puede determinarse mediante programación.
Mientras que 1.3.5 se centra en los campos de formulario que recopilan datos del usuario, 1.3.6 amplía el alcance a toda la interfaz: componentes interactivos, iconos y regiones de la página deben tener un propósito determinable programáticamente. Esto permite que el software —navegadores, extensiones, tecnologías de apoyo— adapte la presentación para personas con discapacidades cognitivas o del lenguaje.
🧩
Componentes UI
Botones, enlaces, controles y widgets tienen un propósito identificable mediante roles, nombres y estados ARIA.
role="button" + aria-label
role="navigation"
aria-expanded, aria-pressed
🔖
Iconos
Los iconos que transmiten información tienen un nombre accesible que las tecnologías de apoyo pueden leer y adaptar.
aria-label="Guardar"
aria-labelledby para iconos complejos
SVG con <title> accesible
🗺️
Regiones
Las áreas de la página —cabecera, navegación, contenido principal, complementario, pie— están delimitadas mediante landmarks semánticos.
<header>, <main>, <nav>
<aside>, <footer>
role="search", role="region"
Aplicación: Este criterio solo aplica a contenido implementado con lenguajes de marcado (HTML, SVG). No aplica a contenido renderizado mediante imágenes rasterizadas o PDF sin etiquetas. El nivel AAA refleja que su implementación completa requiere un esfuerzo significativo.
Comparativa: 1.3.1, 4.1.2 y 1.3.6
Los tres criterios trabajan en capas complementarias para hacer la interfaz completamente interpretable por software:
1.3.1Información y relacionesNivel A
Estructura visual (encabezados, listas, tablas) determinable mediante marcado semántico.
4.1.2Nombre, rol, valorNivel A
Todos los componentes UI tienen nombre, rol y valor accesibles para tecnologías de apoyo.
1.3.6Identificar el propósitoNivel AAA
El propósito funcional de componentes, iconos y regiones es determinable para que el software pueda adaptar la presentación.
¿Por qué importa?
Cuando el propósito de los elementos de la interfaz puede determinarse programáticamente, el software puede personalizar la presentación para cada usuario. El flujo es:
1
Propósito en el marcado
El desarrollador añade roles, labels y landmarks que exponen el propósito de cada elemento en el árbol de accesibilidad.
→
2
Software lo detecta
El navegador, extensión o tecnología de apoyo lee el propósito y puede modificar la presentación: cambiar iconos, añadir etiquetas, aplicar temas.
→
3
Usuario comprende la UI
Personas con dislexia, discapacidades cognitivas o del lenguaje reciben la interfaz en un formato que pueden entender: símbolos familiares, texto simplificado, alto contraste.
Ejemplo real: Una extensión de navegador puede reemplazar el icono de un botón "Guardar" por el símbolo de su conjunto pictográfico favorito (AAC), o mostrar el texto de la región actual ("Estás en: Navegación principal") de forma más prominente.
¿Quién se ve afectado?
Discapacidades cognitivas y del aprendizaje
Personas con dislexia, autismo, discapacidad intelectual o diferencias cognitivas pueden usar software que reemplaza texto por símbolos o iconos familiares de comunicación aumentativa y alternativa (AAC).
Discapacidades del lenguaje
Usuarios que dependen de sistemas pictográficos (como ARASAAC) para comunicarse pueden navegar interfaces cuando los propósitos están expuestos y mapeables a símbolos.
Usuarios de control por voz
Herramientas como Dragon pueden activar componentes por su propósito semántico cuando el nombre accesible refleja fielmente la función del elemento.
Usuarios con baja visión cognitiva
Personas que usan extensiones de personalización de interfaz se benefician cuando los elementos tienen propósitos claros que el software puede intercambiar o resaltar.
Cómo implementarlo
1. HTML semántico para regiones
Usa los elementos de landmark HTML5. Son la base y cubren la mayoría de los casos:
HTML
<header>
<nav aria-label="Principal">...</nav>
</header>
<main id="main-content">
<article>...</article>
<aside aria-label="Artículos relacionados">...</aside>
</main>
<footer>...</footer>
<!-- Región de búsqueda -->
<search aria-label="Buscar en el sitio">
<form role="search">...</form>
</search>
2. Iconos con nombre accesible
Los iconos informativos o interactivos deben tener nombre accesible. Los decorativos deben ocultarse:
Usa role de ARIA cuando el elemento HTML no expresa el propósito por sí solo:
HTML
<!-- Navegación de migas de pan -->
<nav aria-label="Ruta de navegación">
<ol role="list">
<li><a href="/es/">Inicio</a></li>
<li><a href="/es/servicios/">Servicios</a></li>
<li aria-current="page">Auditoría</li>
</ol>
</nav>
<!-- Widget de valoración -->
<div role="radiogroup" aria-labelledby="rating-label">
<span id="rating-label">Valoración</span>
<button role="radio" aria-checked="false" aria-label="1 estrella">★</button>
<button role="radio" aria-checked="true" aria-label="2 estrellas">★</button>
</div>
<!-- Menú de usuario -->
<button aria-haspopup="menu" aria-expanded="false" aria-controls="user-menu">
Mi cuenta
</button>
<ul id="user-menu" role="menu" hidden>
<li role="menuitem"><a href="/perfil">Perfil</a></li>
<li role="menuitem"><a href="/salir">Cerrar sesión</a></li>
</ul>
Ejemplos prácticos
Barra de herramientas de un editor
Una barra de iconos (negrita, cursiva, enlace, imagen) donde cada botón tiene aria-label con el nombre de la acción y aria-pressed para estados activos. Un software de AAC puede reemplazar los iconos por los del set del usuario.
Un artículo de blog con cabecera, navegación principal, navegación de artículo, contenido principal, zona de comentarios y pie. Cada región tiene su landmark y aria-label descriptivo para que el usuario pueda saltar directamente a cualquier sección.
Un gráfico SVG que muestra datos de accesibilidad web expone su propósito con <title> y role="img" para que el software pueda identificarlo como "imagen con información" y ofrecerlo al usuario de forma apropiada.
HTML + SVG
<svg role="img" aria-labelledby="chart-title chart-desc">
<title id="chart-title">Adopción de WCAG 2.2 por sector</title>
<desc id="chart-desc">
Gráfico de barras: sector público 68 %, privado 42 %, educación 55 %
</desc>
<!-- paths del gráfico -->
</svg>
Usar aria-label para proporcionar etiquetas a objetos
Suficiente
Errores comunes
Iconos sin nombre accesible en botones de acción
Botones que solo contienen un icono (font icon o emoji) sin aria-label ni texto oculto con clase visually-hidden. Las tecnologías de apoyo anuncian el código de carácter o nada.
Múltiples navegaciones sin etiqueta diferenciadora
Cuando una página tiene más de un <nav> sin aria-label o aria-labelledby, los lectores de pantalla los anuncian todos como "Navegación" sin distinción.
Incorrecto
<nav>...menú principal...</nav>
<nav>...paginación...</nav>
<nav>...pie de página...</nav>
Correcto
<nav aria-label="Principal">...</nav>
<nav aria-label="Paginación">...</nav>
<nav aria-label="Pie de página">...</nav>
Usar div y span para regiones sin role
Construir la estructura de la página solo con <div> y <span> sin landmarks ni roles ARIA impide que el software identifique el propósito de cada región.
Etiquetar todas las regiones con el mismo nombre (aria-label="Sección") o usar nombres que no describen el propósito real (aria-label="Contenedor 1") inutiliza la identificación del propósito.