WCAG 2.4.5: Múltiples formas

Qué significa esta regla

WCAG 2.4.5 — Múltiples formas es un criterio de éxito de Nivel AA bajo el principio de Operable. Exige que cualquier página web que forme parte de un conjunto más amplio de páginas web sea accesible a través de al menos dos mecanismos de navegación distintos. En otras palabras, nunca se debe obligar a una persona usuaria a depender de una única ruta para encontrar una página.

Los mecanismos de navegación habituales que satisfacen este criterio incluyen: una función de búsqueda en todo el sitio, un mapa del sitio (ya sea como página independiente o como estructura integrada), una tabla de contenidos, un menú de navegación o barra lateral coherente, rutas de migas de pan (breadcrumbs) y enlaces entre páginas relacionadas. Cualesquiera dos de estos — u otros mecanismos equivalentes — utilizados conjuntamente satisfacen el requisito.

El criterio se aplica específicamente a conjuntos de páginas web. Una página web independiente que no pertenezca a un sitio o aplicación más grande está exenta. Además, las páginas que son el resultado de, o un paso dentro de, un proceso — como una página de confirmación de compra, una pantalla de envío correcto de un formulario o un paso de un asistente — también están explícitamente exentas. Esto se debe a que dichas páginas son intrínsecamente secuenciales y sería inapropiado o perjudicial permitir el acceso directo a ellas fuera de orden.

Un aprobado requiere que al menos dos mecanismos de navegación independientes estén presentes, sean funcionales y accesibles en todo el sitio. Se produce un fallo cuando solo existe un mecanismo — por ejemplo, un sitio que solo proporciona un menú de navegación superior sin búsqueda, sin mapa del sitio y sin otra ayuda de navegación. También falla si el mecanismo secundario no funciona o no es accesible (por ejemplo, un cuadro de búsqueda que no devuelve resultados, o un mapa del sitio que está oculto a las tecnologías de asistencia).

Es importante destacar que este criterio no exige ninguna combinación específica de mecanismos. La flexibilidad es intencionada: diferentes personas usuarias tienen estrategias fundamentalmente distintas para encontrar contenido, y la norma reconoce esta diversidad exigiendo redundancia en lugar de prescribir una solución concreta.

Por qué es importante

La navegación es la base de cualquier experiencia web, y las barreras a la navegación afectan de forma desproporcionada a las personas con discapacidad. Cuando solo existe una ruta de navegación, las personas que no pueden usar esa ruta quedan, en la práctica, excluidas del contenido.

Para personas con discapacidades motoras — incluidas quienes usan acceso por pulsadores, dispositivos de seguimiento ocular, software de control por voz o navegación solo con teclado — los menús jerárquicos complejos pueden resultar agotadores o imposibles de recorrer de forma eficiente. Una búsqueda en el sitio les permite ir directamente al contenido sin tener que navegar por varios niveles de menús. A la inversa, las personas con ciertas discapacidades cognitivas o de memoria pueden encontrar los campos de búsqueda abiertos confusos o difíciles de usar de forma eficaz; para ellas, un mapa del sitio claramente estructurado o un árbol de categorías navegable es mucho más útil.

Para personas ciegas que dependen de lectores de pantalla, un menú de navegación denso puede convertirse en un obstáculo repetitivo en cada visita a una página, incluso con enlaces de salto. Un mapa del sitio o un acceso directo a la búsqueda reduce significativamente esa carga cognitiva y física. Para las personas con baja visión que usan ampliación de pantalla, los menús de navegación amplios pueden ser solo parcialmente visibles a niveles altos de zoom, lo que convierte a una búsqueda basada en texto o a un mapa del sitio en un recurso de respaldo fundamental.

Para personas con discapacidades cognitivas como dislexia o trastornos de atención, la posibilidad de buscar usando términos aproximados o parciales — en lugar de tener que recordar o reconocer la jerarquía exacta del menú — puede marcar la diferencia entre encontrar contenido de forma independiente y abandonar por completo.

Un escenario concreto del mundo real: imagina a una persona usuaria con artritis reumatoide que visita una plataforma turca de comercio electrónico usando solo el teclado. El mega-menú del sitio requiere interacciones precisas de desplazamiento del ratón para revelar subcategorías, y el comportamiento del foco del teclado es poco fiable. Si el sitio también proporciona una barra de búsqueda y un mapa del sitio, esa persona aún puede localizar la página de producto que necesita. Sin esas alternativas, el sitio es, en la práctica, inutilizable para ella, lo que representa una clienta o un cliente perdido y una posible responsabilidad legal.

Más allá de la accesibilidad, los múltiples mecanismos de navegación ofrecen beneficios medibles de SEO y usabilidad. Los mapas del sitio mejoran la capacidad de rastreo por parte de los bots de los motores de búsqueda. La funcionalidad de búsqueda en el sitio aumenta la interacción de las personas usuarias y reduce las tasas de rebote. Las rutas de migas de pan mejoran las tasas de clics en las páginas de resultados de los motores de búsqueda cuando se implementan con datos estructurados. Estos beneficios significan que cumplir con 2.4.5 no es solo un ejercicio de conformidad, sino una buena práctica de diseño web.

Reglas relacionadas de Axe-core

WCAG 2.4.5 requiere pruebas manuales porque ninguna herramienta automatizada puede determinar de forma fiable si un sitio proporciona suficiente variedad de navegación. Los escáneres automatizados pueden verificar si existen elementos específicos y si son sintácticamente correctos, pero no pueden evaluar la arquitectura de navegación de todo el sitio ni determinar si una combinación dada de mecanismos es realmente adecuada. Las siguientes consideraciones guían la evaluación manual:

• Presencia de una búsqueda en el sitio (comprobación manual): Las herramientas automatizadas no pueden confirmar si un campo de búsqueda es funcional, devuelve resultados significativos o es accesible en todo el sitio. Una persona evaluadora debe verificar manualmente que existe un mecanismo de búsqueda, que es accesible mediante teclado y que produce resultados relevantes para consultas representativas.
• Presencia de un mapa del sitio u otro mecanismo de navegación alternativo (comprobación manual): Las herramientas no pueden determinar si existe una página de mapa del sitio, si está enlazada desde todas las páginas o si cubre de forma exhaustiva el contenido del sitio. Una persona revisora debe confirmar que al menos un mecanismo adicional más allá de la navegación principal está disponible y es accesible.
• Coherencia de la navegación (relacionado con 2.4.3 y 3.2.3, comprobación manual): Las herramientas automatizadas pueden señalar un orden incoherente de componentes entre páginas, pero no pueden juzgar si la estrategia de navegación general sigue siendo coherente y suficiente para las personas con discapacidad. Se requiere una revisión manual en varios tipos de páginas representativas.
• Accesibilidad de los mecanismos secundarios (comprobación manual): Incluso si existe un mapa del sitio o una búsqueda, un análisis automatizado puede no detectar casos en los que esos mecanismos no sean accesibles mediante teclado, tengan un etiquetado deficiente para lectores de pantalla o estén visualmente ocultos de una forma que afecte a la usabilidad. Las pruebas manuales con teclado y lector de pantalla deben confirmar que cada mecanismo funciona de extremo a extremo.

Cómo hacer las pruebas

1. Análisis automatizado — establecer una línea base: Ejecuta axe DevTools o Lighthouse en páginas representativas del sitio. Aunque ninguna de las dos herramientas señala directamente infracciones de 2.4.5, utiliza la auditoría para identificar cualquier componente de navegación (menús, campos de búsqueda, migas de pan) con problemas de accesibilidad subyacentes, como etiquetas ausentes, roles ARIA incorrectos o problemas de gestión del foco. Corrige estos primero, ya que un mecanismo de navegación roto no puede contar como una “forma” válida según 2.4.5.
2. Catalogar los mecanismos de navegación: Revisa manualmente el sitio y enumera cada mecanismo distinto que una persona usuaria podría utilizar para llegar a una página determinada: menús de navegación superiores, enlaces en el pie de página, búsqueda en el sitio, páginas de mapa del sitio, migas de pan, enlaces a contenido relacionado, índices de categorías, etc. Confirma que al menos dos de estos mecanismos están presentes, son funcionales y están disponibles en cada página que no forme parte de un proceso secuencial.
3. Prueba de navegación solo con teclado: Usando únicamente las teclas Tab, Enter, las flechas y Escape (sin ratón), intenta llegar a una página específica que no sea la página de inicio mediante dos mecanismos diferentes. Por ejemplo, utiliza la barra de búsqueda para encontrar una página de producto y luego utiliza el mapa del sitio o el menú de navegación para llegar a la misma página. Confirma que ambas rutas son totalmente operables sin ratón.
4. Prueba con lector de pantalla usando NVDA + Firefox: Abre NVDA, inicia Firefox y navega a la página de inicio. Utiliza el modo de exploración de NVDA (F6 para regiones, H para encabezados) para localizar la región de búsqueda y cualquier enlace al mapa del sitio o de navegación. Confirma que ambos mecanismos se anuncian correctamente, que los campos de formulario tienen etiquetas accesibles y que las páginas de resultados o destino se cargan y son legibles.
5. Prueba con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Activa VoiceOver (Cmd+F5) y utiliza el Rotor (VO+U) para inspeccionar los controles de formulario y los enlaces de la página. Confirma que el campo de búsqueda aparece en la lista y está etiquetado, y que los enlaces de navegación que conducen a un mapa del sitio o a un índice alternativo están presentes y son operables.
6. Prueba con lector de pantalla usando JAWS + Chrome: Utiliza las teclas de navegación de JAWS (F para saltar a formularios, Insert+F7 para la lista de enlaces) para verificar que el campo de búsqueda y cualquier enlace al mapa del sitio se pueden descubrir y usar tanto desde el teclado como desde el cursor virtual.
7. Comprobación de la exención para procesos secuenciales: Identifica cualquier página que sea un paso dentro de un proceso (compra, formularios de varios pasos, flujos de inicio de sesión). Confirma que estas páginas no necesitan cumplir el requisito de múltiples formas. Documenta esto en tu auditoría de accesibilidad para evitar falsos fallos.
8. Verificación funcional de los resultados de búsqueda: Realiza varias búsquedas representativas (nombres de productos, títulos de artículos, temas de soporte). Confirma que aparecen resultados, que son relevantes y que la página de resultados es accesible y navegable mediante teclado y lector de pantalla.

Cómo corregir

Falta búsqueda en el sitio — Incorrecto

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Falta búsqueda en el sitio — Correcto

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Mapa del sitio inaccesible — Incorrecto

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Mapa del sitio inaccesible — Correcto

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Formulario de búsqueda sin etiqueta accesible — Incorrecto

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Formulario de búsqueda sin etiqueta accesible — Correcto

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Errores comunes

• Contar un mapa del sitio XML como un mecanismo de navegación orientado a la persona usuaria: Un mapa del sitio XML enviado a los motores de búsqueda (por ejemplo, /sitemap.xml) es un archivo legible por máquinas y no puede ser utilizado por visitantes habituales. Solo una página de mapa del sitio en HTML, navegable por personas, cuenta como un segundo mecanismo de navegación válido.
• Proporcionar un formulario de búsqueda que sea meramente decorativo o esté roto: Un campo de búsqueda que siempre devuelve resultados vacíos, genera errores al enviarse o redirige a una página 404 no satisface 2.4.5. El mecanismo debe ser realmente funcional para que el criterio se considere cumplido.
• Ocultar el enlace al mapa del sitio detrás de JavaScript que falla o está desactivado: Si el único enlace a un mapa del sitio está dentro de una ventana modal inyectada dinámicamente o de un menú desplegable dependiente de JavaScript que falla en ciertos entornos, las personas que no pueden ejecutar ese JavaScript (incluidas algunas configuraciones de tecnología de asistencia) pierden el acceso a ese mecanismo de navegación.
• Aplicar display:none o visibility:hidden a un mecanismo de navegación en las vistas móviles: Ocultar por completo una barra de búsqueda o un enlace al mapa del sitio en el diseño móvil elimina ese mecanismo para las personas usuarias móviles, lo que supone un fallo, incluso si el diseño de escritorio cumple. Es aceptable contraer el mecanismo detrás de un botón de alternancia accesible; eliminarlo del DOM o del árbol de accesibilidad no lo es.
• Tratar las migas de pan como un segundo mecanismo independiente sin ningún apoyo adicional: Las migas de pan solo muestran la ruta hacia la página actual y no son, por sí solas, suficientes para ayudar a una persona usuaria a descubrir y navegar a páginas arbitrarias de un sitio. Pueden complementar otros mecanismos, pero normalmente no pueden servir como uno de los dos mecanismos requeridos por sí mismas.
• Eximir páginas del requisito de forma incorrecta: La exención para procesos secuenciales se aplica únicamente a páginas que son literalmente pasos dentro de un proceso (por ejemplo, paso 2 de 4 en una compra). Las páginas de categoría, las páginas de detalle de producto y las entradas de blog no están exentas, incluso si la persona usuaria llegó a ellas a través de un embudo.
• Usar un campo de búsqueda con type='text' en lugar de type='search' y omitir role='search' en el formulario: Aunque no es una infracción directa de 2.4.5, esto significa que las personas usuarias de lectores de pantalla que navegan por regiones no pueden encontrar la región de búsqueda. El mecanismo existe técnicamente, pero en la práctica es más difícil de descubrir, lo que socava la intención del criterio.
• Proporcionar dos mecanismos que son efectivamente idénticos: Un menú de navegación superior y un menú de navegación en el pie de página que contienen exactamente los mismos enlaces con exactamente la misma estructura no constituyen dos mecanismos de navegación significativamente diferentes. La intención es que las personas con distintas necesidades puedan encontrar estrategias alternativas, no que la misma estrategia aparezca dos veces en la página.
• Excluir ciertos tipos de página del sistema de navegación: Algunas configuraciones de CMS sitúan las entradas de blog, las páginas legales o las páginas de cuenta de usuario fuera del mapa del sitio principal o del índice de búsqueda. Si las personas usuarias no pueden encontrar estas páginas mediante al menos dos mecanismos, esas páginas incumplen 2.4.5 independientemente de lo bien estructurado que esté el resto del sitio.
• No probar los mecanismos con tecnología de asistencia: Dado que 2.4.5 requiere pruebas manuales, los equipos que dependen únicamente de herramientas automatizadas pasarán por alto fallos causados por trampas de teclado en formularios de búsqueda, campos sin etiquetar o mapas del sitio que están presentes en el DOM pero son inaccesibles mediante la navegación por regiones del lector de pantalla.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial de Turquía n.º 2025/10, publicada en el Boletín Oficial (Resmî Gazete) n.º 32933 el 21 de junio de 2025, establece obligaciones vinculantes de accesibilidad web para una amplia gama de entidades del sector público y privado. La Circular exige la conformidad con normas de accesibilidad reconocidas internacionalmente, alineando los requisitos legales turcos con WCAG 2.1 y WCAG 2.2 Nivel AA como expectativa básica.

WCAG 2.4.5 — Múltiples formas es un criterio de Nivel AA, lo que significa que encaja plenamente dentro del nivel de conformidad exigido por la Circular. Las entidades sujetas a la regulación deben garantizar que todas las páginas web que pertenezcan a un conjunto proporcionen al menos dos mecanismos de navegación, tal como se describe en este criterio. No cumplir este requisito supone una falta directa de conformidad con el mandato regulatorio.

Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen: instituciones públicas y organismos gubernamentales de todos los niveles; bancos e instituciones financieras; hospitales y proveedores de servicios sanitarios; plataformas de comercio electrónico; operadores de telecomunicaciones con 200,000 o más abonados; agencias de viajes; empresas de transporte privado; y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (Millî Eğitim Bakanlığı, MEB). Se espera que cada uno de estos tipos de entidades mantenga una navegación accesible y con múltiples rutas en sus propiedades web.

Además de los requisitos obligatorios de conformidad, el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı) otorga el Erişilebilirlik Logosu (Logotipo de Accesibilidad) a las organizaciones que demuestran buenas prácticas de accesibilidad. Obtener este logotipo requiere una conformidad completa de Nivel AA, incluida la observancia de 2.4.5. Para las empresas que operan en el competitivo mercado digital de Turquía — en particular las plataformas de comercio electrónico, los bancos y los proveedores de servicios sanitarios — el Logotipo de Accesibilidad sirve tanto como señal de confianza para las personas usuarias con discapacidad como evidencia de buena fe regulatoria.

En la práctica, los sitios web turcos que atienden a poblaciones de personas usuarias diversas se benefician significativamente de implementar múltiples mecanismos de navegación. Turquía tiene una gran población de personas mayores usuarias de internet y personas en regiones con menor alfabetización digital, ambas beneficiadas por la redundancia que exige 2.4.5. Una búsqueda en el sitio con soporte para el idioma turco (incluido el manejo correcto de caracteres específicos del turco como ı, İ, ş, ğ, ü, ö, ç) combinada con un mapa del sitio en HTML claramente estructurado representa una implementación accesible y conforme a la normativa que sirve bien a este público. Las organizaciones que busquen obtener o mantener el Erişilebilirlik Logosu deben tratar el cumplimiento de 2.4.5 no como una mejora opcional, sino como un requisito fundamental de su programa de accesibilidad.