WCAG 3.2.4: Identificación coherente

Qué significa esta regla

El Criterio de Éxito 3.2.4 de las WCAG — Identificación consistente — establece que los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas web deben identificarse de forma consistente. Esto significa que siempre que un elemento interactivo o una imagen desempeñe la misma función, debe tener el mismo nombre o etiqueta accesible cada vez que aparezca en el sitio.

El término "identificado" en este contexto se refiere a cómo se presenta un componente a las tecnologías de asistencia y a las personas usuarias. Esto incluye el texto de la etiqueta visible, el atributo aria-label o aria-labelledby, el texto alt de una imagen, el atributo title o el nombre accesible calculado por el árbol de accesibilidad del navegador. Si un botón de búsqueda aparece en cada página de un sitio, siempre debe llamarse "Search" — no "Search" en la página de inicio, "Find" en la página de listado de productos y "Go" en la página de pago.

Este criterio se aplica a un conjunto de páginas web, que las WCAG definen como una colección de páginas que comparten un propósito común y que han sido producidas por la misma persona autora. Esto abarca un sitio web completo, una aplicación web o un formulario de varios pasos que se extiende a lo largo de varias URL. Los componentes que son solo visualmente similares pero cumplen funciones diferentes no están obligados a compartir el mismo nombre: el requisito está específicamente vinculado a la funcionalidad idéntica.

Qué se considera un cumplimiento: Un icono de navegación que abre un menú hamburguesa está etiquetado de forma consistente como "Open navigation menu" (o equivalente) en todas las páginas. Un icono de carrito de compra siempre tiene el texto alternativo o el nombre accesible "Shopping cart". Un botón de cierre de sesión siempre está etiquetado como "Log out". La variación en la redacción para la misma función constituye un incumplimiento.

Qué se considera un incumplimiento: Un botón de envío etiquetado como "Submit" en el formulario de registro pero etiquetado como "Send" en el formulario de contacto cuando ambos botones cumplen el mismo propósito funcional de transmitir datos introducidos por la persona usuaria. Un botón de icono con una lupa etiquetado como "Search" en la mayoría de las páginas pero "Ara" en una única subpágina traducida sin una estrategia de idioma coherente.

Excepción oficial: Las WCAG señalan explícitamente que es aceptable tener dos componentes con el mismo nombre accesible si realizan funciones diferentes; en ese caso, la función diferente en sí misma los desambiguará. El criterio solo se aplica cuando la función es idéntica pero la denominación es inconsistente.

Por qué es importante

La identificación inconsistente crea una carga desproporcionada para las personas que dependen de estrategias de navegación no visuales o basadas en patrones. Los grupos más gravemente afectados incluyen a las personas usuarias de lectores de pantalla, personas con discapacidades cognitivas y personas con discapacidades motoras que dependen de software de control por voz.

Las personas usuarias de lectores de pantalla construyen un modelo mental de un sitio web escuchando los nombres de los elementos mientras navegan con la tecla Tab o por regiones. Cuando un botón que cumplía la misma función en la página anterior ahora tiene un nombre diferente, la persona usuaria debe detenerse, investigar y reorientarse, lo que supone una experiencia frustrante y que consume tiempo. Según la Organización Mundial de la Salud, aproximadamente 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual. Incluso una fracción de esa población que interactúe con un sitio etiquetado de forma inconsistente se encontrará con barreras significativas.

Las personas con discapacidades cognitivas, incluidas aquellas con dislexia, trastornos de atención o problemas de memoria, dependen en gran medida de una denominación predecible para reducir la carga cognitiva. Encontrar un icono o control familiar con un nombre diferente obliga a reaprender y provoca ansiedad. El etiquetado consistente reduce el esfuerzo necesario para construir memoria procedimental cuando se utiliza un sitio con regularidad.

Las personas usuarias de control por voz (que utilizan herramientas como Dragon NaturallySpeaking o Voice Control de Apple) pronuncian el nombre de un control para activarlo. Si el nombre accesible de un botón difiere de lo que esperan en función de su experiencia previa con el sitio, su comando hablado fallará silenciosamente: el software simplemente no encontrará una coincidencia. Esto hace que la interfaz sea efectivamente inutilizable en ese momento.

Un escenario concreto del mundo real: Consideremos una plataforma turca de comercio electrónico que vende ropa. En la página de cuadrícula de productos, cada artículo tiene un botón con un icono de corazón cuyo nombre accesible es "Add to favourites". En la página de detalle del producto, el nombre accesible del mismo icono de corazón es "Kaydet" (turco para "Guardar"). Una persona usuaria de lector de pantalla que aprendió a activar el botón de corazón por su nombre en la página de cuadrícula ahora no puede encontrar el control equivalente en la página de detalle sin una exploración exhaustiva. Es posible que abandone el sitio por completo.

Más allá de la accesibilidad, el etiquetado consistente beneficia al SEO. Los motores de búsqueda analizan los nombres accesibles y el texto de los enlaces para comprender el contenido de la página. El etiquetado inconsistente de enlaces funcionalmente idénticos (por ejemplo, "Read more", "Continue reading", "Learn more" que apuntan todos a páginas de detalle de artículos) diluye las señales de palabras clave y dificulta que los rastreadores comprendan la estructura del sitio.

Reglas relacionadas de Axe-core

WCAG 3.2.4 requiere pruebas manuales porque las herramientas automatizadas no pueden determinar la intención semántica entre páginas ni saber que dos componentes con nombres diferentes cumplen la misma función. Ninguna regla de axe-core se corresponde directamente con este criterio. A continuación se explica por qué la automatización no es suficiente y qué deben hacer las personas evaluadoras en su lugar:

• Se requieren pruebas manuales — consistencia entre páginas: Axe-core evalúa una sola página de forma aislada. No tiene ningún mecanismo para comparar el nombre accesible de un botón "Search" en la página de inicio con un botón "Find" en una página de producto, porque no mantiene un inventario de nombres de componentes entre páginas. Una persona evaluadora debe catalogar los elementos funcionales repetidos y verificar que su denominación sea uniforme en todas las páginas donde aparezcan.
• Se requieren pruebas manuales — consistencia del texto alternativo de iconos e imágenes: Las herramientas automatizadas pueden detectar la ausencia de texto alternativo (mediante la regla image-alt) pero no pueden determinar si dos imágenes que cumplen el mismo propósito tienen el mismo texto alternativo en diferentes páginas. Por ejemplo, un icono de impresora en una página de recibos y el mismo icono de impresora en una página de factura pueden tener ambos texto alternativo, pero si uno dice "Print" y el otro dice "Print this page", una persona debe juzgar si esto constituye una inconsistencia según el criterio 3.2.4.
• Se requieren pruebas manuales — consistencia de etiquetas ARIA: Axe-core comprueba que las etiquetas ARIA estén presentes y no estén vacías, pero no audita si los valores de aria-label para el mismo tipo de componente son consistentes en todo el conjunto de páginas. Una persona evaluadora debe inspeccionar el árbol de accesibilidad en varias páginas y comparar los nombres de controles funcionalmente idénticos.
• Se requieren pruebas manuales — etiquetas de controles de formulario: Reglas automatizadas como label verifican que las entradas estén asociadas a etiquetas, pero no comprueban si un campo "Username" en la página de inicio de sesión también está etiquetado como "Username" (en lugar de "Email" o "User ID") en la página de recuperación de cuenta cuando ambos campos aceptan el mismo tipo de entrada y cumplen el mismo rol funcional.

Cómo hacer las pruebas

1. Preanálisis automatizado: Ejecuta axe DevTools o Lighthouse en cada página para detectar cualquier infracción relacionada, como nombres accesibles ausentes (image-alt, button-name, link-name). Resuelve estas primero: no puedes evaluar la consistencia de los nombres si los nombres no existen. Toma nota de los nombres accesibles que se informan para los componentes repetidos en los resultados del análisis.
2. Crea un inventario de componentes: Enumera manualmente todos los componentes funcionales que se repiten entre páginas: menús de navegación, campos de búsqueda, botones de envío, botones de icono, enlaces de migas de pan, enlaces a redes sociales, botones de imprimir/compartir y controles de paginación. Registra el nombre accesible de cada instancia utilizando el panel de Accesibilidad de tu navegador (Chrome DevTools > Elements > Accessibility, o Firefox Accessibility Inspector).
3. Compara los nombres entre páginas: Para cada tipo de componente de tu inventario, verifica que cada instancia tenga el mismo nombre accesible. Señala cualquier discrepancia. Presta especial atención a los componentes que aparecen en encabezados, pies de página y barras laterales, ya que es más probable que estén etiquetados de forma inconsistente entre plantillas.
4. Pruebas con lector de pantalla usando NVDA + Firefox: Navega a la página de inicio y luego utiliza la lista de elementos de NVDA (Insert + F7) para abrir la lista de botones y enlaces. Toma nota de los nombres de los controles repetidos. Luego navega a tres o cuatro páginas representativas más y repite. Escucha cualquier variación de nombre en controles funcionalmente idénticos.
5. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Utiliza el Rotor (VO + U) para mostrar la lista de botones o enlaces en cada página. Compara los nombres de los elementos repetidos. En iOS, desliza el dedo por los elementos interactivos en páginas equivalentes y toma nota de cualquier diferencia en la denominación.
6. Pruebas con lector de pantalla usando JAWS + Chrome: Utiliza el cursor virtual de JAWS y la lista de campos de formulario (Insert + F5) y de enlaces (Insert + F7) en varias páginas. Confirma que los controles idénticos comparten nombres idénticos en todo el sitio.
7. Prueba de control por voz: Usando Windows Voice Access o Dragon NaturallySpeaking, pronuncia el nombre de un control repetido en una página (por ejemplo, "Click Search"). Navega a otra página y pronuncia el mismo comando. Si falla, los nombres son inconsistentes desde el punto de vista funcional.

Cómo corregirlo

Botón de búsqueda con etiquetas inconsistentes — Incorrecto

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Botón de búsqueda con etiquetas inconsistentes — Correcto

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Imagen de icono usada para la misma acción con texto alternativo diferente — Incorrecto

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Imagen de icono usada para la misma acción con texto alternativo diferente — Correcto

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Botón de cierre de navegación con nombres inconsistentes — Incorrecto

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Botón de cierre de navegación con nombres inconsistentes — Correcto

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Enlaces de compartir en redes sociales con nombres variables — Incorrecto

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Enlaces de compartir en redes sociales con nombres variables — Correcto

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Errores comunes

• Usar valores de aria-label diferentes en distintas plantillas para el mismo componente: Cuando diferentes desarrolladores crean plantillas de página de forma independiente sin una biblioteca de componentes compartida, los botones de icono como cerrar, buscar y carrito suelen recibir etiquetas ad hoc. Establece un token de sistema de diseño o un componente compartido para cada elemento interactivo repetido de modo que el nombre accesible se defina una sola vez y se reutilice en todas partes.
• Traducir los nombres accesibles de forma inconsistente en páginas multilingües: Un sitio puede etiquetar correctamente un botón de búsqueda como "Search" en inglés, pero luego usar un equivalente turco inconsistente — a veces "Ara", a veces "Arama Yap" — según qué plantilla de página se localizó primero. Mantén una única clave de traducción por etiqueta de componente y aplícala en todos los archivos de idioma.
• Añadir sufijos específicos de contexto a controles por lo demás idénticos: Etiquetar botones como "Add to cart — Blue T-Shirt", "Add to cart — Red Dress", etc. cuando la función principal (añadir al carrito) es la misma no es automáticamente un incumplimiento del criterio 3.2.4 — las WCAG permiten la desambiguación — pero hacerlo de forma inconsistente (a veces con sufijo, a veces sin él) genera confusión. Elige un patrón y aplícalo de forma uniforme.
• Confiar en que la etiqueta de texto visible garantice la consistencia mientras los aria-label que la sobrescriben difieren: Cuando un botón muestra visualmente "Search" pero una plantilla añade aria-label='Search the site' y otra no tiene aria-label (por lo que el nombre accesible se deriva solo del texto visible), los lectores de pantalla anunciarán nombres diferentes aunque el botón se vea igual. Audita el cálculo completo del nombre accesible, no solo la etiqueta visible.
• Permitir que las personas editoras de un CMS cambien libremente el texto de los botones sin una gobernanza de accesibilidad: Los sistemas de gestión de contenidos que exponen las etiquetas de los botones como campos editables permiten que las personas editoras cambien "Submit" a "Send" o "Gönder" según su preferencia personal. Restringe la edición de etiquetas para componentes funcionales de la interfaz de usuario o añade validaciones que avisen cuando una etiqueta propuesta se desvíe del estándar establecido.
• No auditar widgets de terceros o componentes incrustados: Los widgets de chat, banners de consentimiento de cookies e iframes de pago inyectados por terceros a menudo contienen botones etiquetados de forma diferente a las convenciones del sitio anfitrión. Revisa y, cuando sea posible, configura los nombres accesibles de terceros para alinearlos con tus convenciones de denominación, o documenta la desviación como una excepción conocida.
• Usar el texto de tooltip (atributo title) como único nombre accesible en algunas instancias pero aria-label en otras: El atributo title no es anunciado de forma fiable por todas las tecnologías de asistencia y se considera una fuente débil de nombre accesible. Si algunas instancias de un componente repetido usan title y otras usan aria-label, los nombres calculados pueden diferir debido a las diferencias en el manejo por parte de navegadores y lectores de pantalla.
• Suponer que los controles de paginación están exentos porque sus números difieren: Los controles "Next page" y "Previous page", incluso cuando incluyen un número de página en su etiqueta (por ejemplo, "Go to page 3"), deben aplicar un patrón consistente. Mezclar "Next" en algunas páginas con "Next page" o "İleri" en otras para el mismo control de paginación incumple el criterio 3.2.4.
• No probar los componentes de encabezado y pie de página en cada plantilla de página distinta: Los sitios suelen tener varias plantillas de página (página de inicio, página de categoría, página de artículo, pago). Los componentes de encabezado y pie de página pueden mostrarse de forma ligeramente diferente entre plantillas. Las personas evaluadoras que solo revisan una o dos plantillas pueden pasar por alto inconsistencias introducidas por sobrescrituras específicas de plantilla.
• Confundir el criterio 3.2.4 con el 3.2.3 (Navegación consistente): Algunos equipos creen que si el orden de navegación es consistente (3.2.3), la denominación también debe serlo, pero se trata de requisitos distintos. Una barra de navegación en la misma ubicación en cada página (cumplimiento del 3.2.3) aún puede incumplir el 3.2.4 si sus enlaces están etiquetados de forma diferente entre páginas. Aborda ambos criterios explícitamente en tu proceso de control de calidad.

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 requisitos de accesibilidad vinculantes para una amplia gama de servicios digitales públicos y privados. La Circular exige la conformidad con normas de accesibilidad reconocidas internacionalmente — en la práctica alineándose con WCAG 2.2 Nivel AA — y vincula esta conformidad al Logotipo de Accesibilidad (Erişilebilirlik Logosu) emitido por el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Identificación consistente es un criterio de Nivel AA, lo que significa que es un requisito obligatorio — no una recomendación — para las organizaciones que deseen obtener o conservar el Erişilebilirlik Logosu. No implementar una identificación consistente en todo un servicio digital impedirá la conformidad completa con el nivel AA y, en consecuencia, la elegibilidad para el logotipo.

La Circular cubre explícitamente los siguientes tipos de entidades, todas las cuales deben abordar el criterio 3.2.4 de las WCAG en sus interfaces web y móviles: instituciones públicas y organismos gubernamentales; bancos y proveedores de servicios financieros; hospitales y plataformas de atención sanitaria; operadores de telecomunicaciones con 200,000 o más abonados; plataformas de comercio electrónico; agencias de viajes y servicios de reserva; empresas de transporte privado; y escuelas privadas autorizadas por el Ministerio de Educación Nacional (Milli Eğitim Bakanlığı).

Para estas organizaciones, la implicación práctica es significativa. Los sitios web institucionales de gran tamaño — como el portal de banca por internet de un banco, el sistema de reserva de citas de un hospital o el sistema de información estudiantil de una universidad — suelen abarcar cientos de páginas y ser desarrollados por varios equipos a lo largo de muchos años. El etiquetado inconsistente de controles repetidos (botones de acción de cuenta, barras de búsqueda, iconos de navegación) en estas páginas es una forma de fallo común y fácil de pasar por alto. Los programas de cumplimiento deben incluir auditorías de consistencia entre páginas como una fase de prueba específica, no solo análisis automatizados de páginas individuales.

Las organizaciones turcas que busquen el Erişilebilirlik Logosu deben integrar las comprobaciones del criterio 3.2.4 de las WCAG en la gobernanza de su sistema de diseño, en los flujos de trabajo de gestión de contenidos y en sus canalizaciones de control de calidad. En concreto, cada componente reutilizable de la interfaz de usuario debe tener su nombre accesible definido como una constante no editable a nivel del sistema de diseño, con claves de traducción gestionadas de forma centralizada para garantizar que el turco y cualquier otra variante lingüística se mantengan consistentes en todas las páginas y plantillas donde aparezca el componente.