WCAG 3.2.6: Ayuda coherente

Qué Significa Esta Regla

El Criterio de Éxito 3.2.6 de las WCAG, Ayuda Consistente (Nivel AA, introducido en WCAG 2.2), establece: «Si una página web contiene cualquiera de los siguientes mecanismos de ayuda, y esos mecanismos se repiten en varias páginas web, aparecen en el mismo orden relativo con respecto al resto del contenido de la página, a menos que el cambio sea iniciado por la persona usuaria.» Los mecanismos de ayuda cubiertos por este criterio son: datos de contacto humanos (como un número de teléfono, dirección de correo electrónico u horario de atención), un mecanismo de contacto humano (como un widget de chat en vivo o un formulario de contacto), una opción de autoayuda (como una página de preguntas frecuentes, un centro de ayuda o una base de conocimientos) y un mecanismo de contacto totalmente automatizado (como un chatbot o asistente virtual).

El requisito clave es la consistencia del orden relativo, no la colocación idéntica en píxeles. Si un botón de chat en vivo aparece en la esquina inferior derecha de la página de inicio, debe aparecer en la misma posición inferior derecha en todas las demás páginas en las que se muestre. Si un enlace de «Ayuda» es el tercer elemento en la barra de navegación superior en una página, debe seguir siendo el tercer elemento —o al menos mantener la misma relación relativa con el contenido que lo rodea— en todas las demás páginas donde aparezca esa barra de navegación.

Una página cumple este criterio cuando: (a) no existe ningún mecanismo de ayuda en el sitio, o (b) existe un mecanismo de ayuda solo en una página, o (c) siempre que un mecanismo de ayuda se repita en varias páginas, aparece en el mismo orden relativo dentro del diseño de la página. Una página no cumple cuando un mecanismo de ayuda que está presente en varias páginas cambia su posición en el orden de la página de una a otra sin que la persona usuaria haya iniciado ese cambio; por ejemplo, un widget de chat que flota en la esquina inferior derecha en la página de listado de productos pero se mueve a la esquina inferior izquierda en la página de pago.

El criterio incluye una excepción explícita: el orden puede cambiar si la persona usuaria inicia el cambio. Por ejemplo, si una persona usuaria arrastra y recoloca un widget de ayuda flotante, o si una preferencia de usuario cambia el panel de ayuda de un lado a otro, ese reposicionamiento es iniciado por la persona usuaria y no constituye un incumplimiento. Esta excepción refleja la misma lógica de acción iniciada por la persona usuaria que se encuentra en el Criterio 3.2.2 (Al introducir datos).

Es importante señalar que este criterio no exige que todas las páginas tengan un mecanismo de ayuda, ni exige que el mecanismo de ayuda sea eficaz o fácil de usar. Solo regula la consistencia posicional cuando el mecanismo está presente en varias páginas.

Por Qué Importa

La colocación consistente de la ayuda está diseñada principalmente para beneficiar a personas usuarias con discapacidades cognitivas, incluidas personas con deterioro de la memoria, dificultades de atención, dificultades de aprendizaje como la dislexia y condiciones como el TDAH o la demencia en fase inicial. Para estas personas, localizar un elemento de interfaz familiar requiere un esfuerzo cognitivo deliberado. Cuando un botón de ayuda o un enlace de contacto aparece en un lugar diferente en cada página, deben invertir ese esfuerzo repetidamente, aumentando la carga cognitiva y el riesgo de frustración, desorientación o abandono de la tarea.

Las personas usuarias que son nuevas en la web o tienen una alfabetización digital limitada —una población significativa en Turquía y a nivel global— también dependen en gran medida de una colocación predecible. Según la Organización Mundial de la Salud, más de 1,3 mil millones de personas en todo el mundo viven con algún tipo de discapacidad, y las condiciones cognitivas y neurológicas representan una parte sustancial de esa población. Diseñar para la consistencia posicional, por lo tanto, sirve a un público amplio que va mucho más allá de quienes tienen discapacidades clínicamente diagnosticadas.

Considere un escenario concreto: una persona usuaria con enfermedad de Alzheimer en fase inicial intenta completar una reserva de vuelo en línea. Recuerda que el sitio web de la aerolínea tiene una opción de chat en vivo que puede usar cuando se confunde. En la página de resultados de búsqueda, el icono de chat aparece en la esquina inferior derecha. Pero cuando pasa a la página de selección de asiento, el widget de chat se ha reubicado en la esquina superior derecha dentro de un panel de ayuda desplegable. No puede encontrarlo, se siente abrumada y abandona la reserva por completo. Esto es un incumplimiento directo y evitable del Criterio 3.2.6.

Para las personas usuarias con discapacidad motriz que navegan con acceso por pulsadores, software de seguimiento ocular o punteros de cabeza, recolocar un mecanismo de ayuda significa volver a escanear y volver a apuntar a una nueva zona de la pantalla, un proceso esforzado y que consume tiempo, que la colocación consistente elimina.

Las personas usuarias de lectores de pantalla que han memorizado el orden de tabulación o la estructura de encabezados de un sitio para llegar rápidamente a la sección de ayuda se ven igualmente afectadas cuando el orden en el DOM de ese mecanismo cambia de una página a otra, incluso si la posición visual parece similar.

Más allá de la accesibilidad, existe un claro beneficio de usabilidad y de negocio: las personas usuarias que pueden encontrar ayuda rápidamente tienen menos probabilidades de abandonar una transacción, lo que reduce las tasas de abandono y los costos de soporte. Los patrones de interfaz consistentes también refuerzan la confianza en la marca y la profesionalidad.

Reglas Relacionadas de Axe-core

WCAG 3.2.6 se clasifica como un criterio que requiere solo pruebas manuales y no tiene una regla automatizada correspondiente en axe-core que pueda señalar incumplimientos de forma programática. Esto es intencional, y entender por qué ayuda a las personas evaluadoras a apreciar la naturaleza de este criterio.

• Se requiere inspección manual — no hay regla de axe disponible: Las herramientas automatizadas como axe-core, Lighthouse o IBM Equal Access Checker analizan una sola página de forma aislada. No tienen una comprensión inherente de lo que es un «mecanismo de ayuda», ninguna capacidad para comparar la posición relativa en el DOM de un elemento a través de múltiples cargas de página o URLs, y ninguna forma de determinar si un elemento dado cumple la función de proporcionar ayuda. Un widget de chat, por ejemplo, podría implementarse como un simple <div>, un componente de shadow DOM, un <iframe> o un script inyectado de terceros, ninguno de los cuales puede identificarse de forma fiable como un «mecanismo de ayuda» por un motor de reglas sin juicio humano. Axe-core necesitaría conciencia de estado entre páginas y reconocimiento de intención semántica para señalar esto, capacidades que quedan fuera del alcance del análisis estático de una sola página. Por eso las propias WCAG 2.2 etiquetan el 3.2.6 como un criterio que requiere evaluación humana mediante auditorías manuales estructuradas y comparación entre páginas.

Cómo Probar

1. Inventariar los mecanismos de ayuda: Antes de probar páginas individuales, cree una lista de todos los mecanismos de ayuda presentes en el sitio: widgets de chat en vivo, números de teléfono de contacto, enlaces de correo electrónico, enlaces a preguntas frecuentes, lanzadores de chatbots, formularios de contacto y enlaces al centro de ayuda. Anote en qué páginas aparece cada mecanismo. Si un mecanismo aparece solo en una página, queda fuera del alcance de este criterio.
2. Ejecutar un análisis automatizado para obtener un contexto de referencia: Use axe DevTools (extensión del navegador) o Lighthouse en páginas representativas para capturar instantáneas del orden del DOM e identificar la posición estructural de los elementos relacionados con la ayuda. Aunque ninguna regla de axe apunta directamente al Criterio 3.2.6, el orden del DOM que informan estas herramientas puede compararse manualmente entre páginas. Exporte o haga capturas de pantalla del árbol de accesibilidad de cada página que contenga un mecanismo de ayuda.
3. Comparar posiciones relativas entre páginas: Abra dos o más páginas que compartan el mismo mecanismo de ayuda una al lado de la otra (o de forma secuencial). Para cada mecanismo, identifique su posición relativa a las regiones de referencia (<header>, <main>, <footer>, <nav>). Registre si el mecanismo aparece en la misma región de referencia y en el mismo orden relativo (antes o después de los elementos adyacentes) en cada página. Un cambio de posición constituye un posible incumplimiento.
4. Probar con navegación por teclado (todos los navegadores): Recorra con la tecla Tab cada página que contenga un mecanismo de ayuda. Cuente el número de pulsaciones de Tab necesarias para llegar al mecanismo de ayuda desde el inicio de la página. Compare este recuento entre páginas. Una diferencia significativa —por ejemplo, alcanzable en 5 tabulaciones en la página de inicio pero en 47 en la página de pago— indica un cambio en el orden del DOM incluso si la posición visual parece similar.
5. Probar con NVDA + Firefox: Abra la Lista de Elementos de NVDA (tecla NVDA + F7) y cambie a la vista de Enlaces o Botones. Localice el mecanismo de ayuda en la lista. Anote su posición relativa a otros elementos listados. Repita en cada página donde aparezca el mecanismo y compare las posiciones.
6. Probar con VoiceOver + Safari (macOS/iOS): Use el rotor de VoiceOver (VO + U) para abrir la lista de Enlaces o Controles de formulario. Navegue hasta el mecanismo de ayuda y anote su posición en la lista. Compare entre páginas.
7. Probar con JAWS + Chrome: Use la Lista de Enlaces de JAWS (Insert + F7) para localizar el mecanismo de ayuda. Anote su posición ordinal y los elementos adyacentes. Repita en varias páginas.
8. Comprobar las excepciones iniciadas por la persona usuaria: Si el sitio permite que las personas usuarias reposicionen u oculten mecanismos de ayuda (por ejemplo, un widget de chat arrastrable), verifique que el reposicionamiento se active mediante una acción explícita de la persona usuaria y que la preferencia se mantenga de forma lógica. Documente esto como una excepción válida según el criterio.
9. Revisar en vistas móviles: Los diseños responsivos a veces reordenan elementos del DOM en diferentes puntos de corte. Pruebe tanto en vistas de escritorio como móviles (anchos de 375px y 1440px como mínimo) para confirmar que el mecanismo de ayuda mantiene una colocación relativa consistente en todos los tamaños de pantalla habituales.

Cómo Corregir

Widget de chat flotante — Incorrecto

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Widget de chat flotante — Correcto

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Enlace de ayuda en la navegación — Incorrecto

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Enlace de ayuda en la navegación — Correcto

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Visualización condicional de la ayuda — Incorrecto

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Visualización condicional de la ayuda — Correcto

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Errores Comunes

• Colocar el widget de chat en diferentes esquinas en distintas plantillas de página: Los equipos de desarrollo suelen aplicar posicionamiento fijo para los widgets de chat por plantilla en lugar de hacerlo mediante una hoja de estilos global, lo que provoca que el widget aparezca en la esquina inferior derecha en las páginas de marketing y en la inferior izquierda en las páginas de la aplicación. Use un único componente incluido globalmente con una clase de posición fija.
• Eliminar el enlace de ayuda de la navegación en las páginas de pago para reducir el desorden: Algunos patrones de UX eliminan intencionalmente la navegación en las páginas de pago para optimizar la conversión. Si un mecanismo de ayuda forma parte de esa navegación, eliminarlo de esta plantilla de página rompe la consistencia. En su lugar, mantenga el enlace de ayuda en un encabezado mínimo incluso en los flujos de pago simplificados.
• Inyectar mecanismos de ayuda mediante scripts de terceros que se cargan con posiciones impredecibles en el DOM: Muchos SDK de chat en vivo inyectan su widget en el DOM de forma asíncrona, y su punto de inserción puede variar según el orden de carga de los scripts. Esto puede hacer que el widget aparezca en una posición diferente en el árbol de accesibilidad entre páginas. Configure los widgets de terceros para que siempre se añadan a un elemento ancla fijo y conocido en el DOM.
• Usar la propiedad order de CSS o el reordenamiento de flexbox/grid para mover visualmente el elemento de ayuda sin cambiar el DOM, y luego cambiar ese CSS por página: Aunque la posición visual pueda parecer consistente, las sobreescrituras de CSS por página que alteran el orden visual de un mecanismo de ayuda siguen cambiando el orden perceptible para la persona usuaria y pueden confundir a las personas usuarias de lectores de pantalla cuyo orden de lectura sigue el DOM.
• Confiar en herramientas de pruebas A/B que intercambian la posición del elemento de ayuda entre variantes de prueba: Si las personas usuarias en la variante A ven el botón de ayuda en la barra superior y las de la variante B lo ven en el pie de página, esas personas experimentarán una colocación de ayuda inconsistente entre páginas dentro de su sesión a medida que el marco de A/B aplica diferentes variantes en distintas páginas. Asegúrese de que las pruebas A/B que afectan a la colocación del mecanismo de ayuda apliquen la variante de forma consistente en todas las páginas de una sesión.
• Tratar los estados autenticado y no autenticado como «sitios» diferentes y aplicar diseños de ayuda distintos: Las personas usuarias que inician sesión a mitad de sesión encontrarán de repente el mecanismo de ayuda en una nueva ubicación. El cambio de estado de autenticación no está iniciado por la persona usuaria en el contexto de la colocación de la ayuda, por lo que esto sigue incumpliendo el Criterio 3.2.6. Aplique un diseño de ayuda consistente en todos los estados de autenticación.
• Incluir el número de teléfono de ayuda solo dentro de texto denso en el pie de página en algunas páginas y en una barra de encabezado dedicada en otras: Incluso si el número de teléfono está técnicamente presente en todas las páginas, un cambio significativo en su posición relativa (de ser el primer elemento interactivo en el encabezado a estar enterrado en el pie de página después de cientos de enlaces) supone un incumplimiento del orden consistente.
• Suponer que, porque un icono de ayuda está siempre visualmente «en la esquina», cumple el criterio: El criterio mide el orden relativo en el contenido de la página, no solo las coordenadas absolutas de píxeles. Un icono de chat que siempre está visualmente en la esquina inferior derecha pero aparece en un punto muy diferente del orden del DOM en distintas páginas (por ejemplo, inmediatamente después de la etiqueta <body> en una página y justo antes de la etiqueta de cierre </body> en otra) puede seguir incumpliendo el criterio para las personas usuarias de teclado y lectores de pantalla.
• Olvidar auditar los puntos de corte responsivos: Un mecanismo de ayuda que es consistente en anchos de escritorio puede ocultarse o moverse a un menú hamburguesa móvil en vistas estrechas, lo que da lugar a una posición diferente en móviles. Si las personas usuarias móviles experimentan una posición relativa diferente a la de escritorio, esto debe evaluarse frente al criterio, especialmente si el móvil es el método de acceso principal para el público objetivo.
• No documentar las ubicaciones de los mecanismos de ayuda en los sistemas de diseño: Sin un estándar documentado sobre dónde deben aparecer los mecanismos de ayuda, las personas desarrolladoras y diseñadoras tomarán decisiones independientes que producirán inconsistencias con el tiempo. Añada reglas de colocación de mecanismos de ayuda explícitamente a la documentación de su sistema de diseño o biblioteca de componentes.

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úmero 32933 el 21 de junio de 2025, establece un marco nacional integral para la accesibilidad digital. La circular exige la conformidad con WCAG 2.2 Nivel AA como estándar básico de accesibilidad para una amplia gama de servicios digitales que operan en Turquía. El Criterio 3.2.6 de las WCAG, Ayuda Consistente, como criterio de Nivel AA introducido en WCAG 2.2, entra directamente dentro del alcance de esta obligación legal.

Los tipos de entidades cubiertas por la Circular Presidencial 2025/10 incluyen: instituciones y organismos públicos tanto a nivel de gobierno central como local; bancos y proveedores de servicios financieros regulados por la Agencia de Regulación y Supervisión Bancaria (BDDK); plataformas de comercio electrónico y mercados en línea; hospitales y proveedores de servicios sanitarios que ofrecen servicios digitales dirigidos a pacientes; empresas de telecomunicaciones con 200,000 o más abonados; agencias de viajes con sistemas de reserva en línea; empresas de transporte privado que operan servicios regulares; y escuelas privadas e instituciones educativas autorizadas por el Ministerio de Educación Nacional (MoNE). Para todas estas entidades, el conjunto completo de criterios WCAG 2.2 Nivel AA —incluido el Criterio 3.2.6— es el estándar aplicable.

El cumplimiento del Criterio 3.2.6 de las WCAG también es un requisito previo para obtener el Erişilebilirlik Logosu (Logotipo de Accesibilidad) emitido por el Ministerio de Familia y Servicios Sociales de Turquía (Aile ve Sosyal Hizmetler Bakanlığı). Este logotipo sirve como marca oficial de conformidad en accesibilidad y es cada vez más reconocido por las personas consumidoras turcas y por quienes se encargan de las compras públicas como una señal de calidad. Las organizaciones que soliciten el logotipo deben demostrar la conformidad total con WCAG 2.2 Nivel AA en todas sus propiedades digitales, lo que significa que una colocación de ayuda inconsistente —aunque parezca menor— puede descalificar una solicitud.

Desde una perspectiva práctica de cumplimiento, el Criterio 3.2.6 es especialmente relevante para proveedores turcos de comercio electrónico y servicios financieros, cuyos sitios web y aplicaciones web móviles suelen incluir widgets de chat en vivo, enlaces de contacto por WhatsApp y secciones de preguntas frecuentes como canales principales de atención al cliente. Garantizar que estos mecanismos de ayuda aparezcan en posiciones consistentes en las páginas de listado de productos, páginas de carrito, flujos de pago y secciones de gestión de cuentas es tanto una obligación legal según la Circular como una buena práctica de UX para atender a la diversa base de personas usuarias de internet de Turquía, que incluye una gran población de personas usuarias primerizas y con baja alfabetización digital que se benefician especialmente de patrones de interfaz predecibles.

Las organizaciones sujetas a la Circular que aún no hayan auditado la colocación de sus mecanismos de ayuda deberían priorizar una auditoría de consistencia entre páginas como parte de su hoja de ruta de cumplimiento de WCAG 2.2. Dado que este criterio requiere pruebas manuales, debe incluirse tanto en las auditorías iniciales de conformidad como en los ciclos continuos de aseguramiento de la calidad, especialmente después de rediseños importantes o cambios de plantilla que puedan desplazar inadvertidamente la posición de los elementos de ayuda.