Mega Menús

El mega menú es la solución correcta cuando la arquitectura de información tiene tanta profundidad o amplitud que un dropdown clásico obligaría al usuario a recordar opciones ocultas en cadena. El criterio práctico: cuando hay varios niveles de drill-down o el conjunto de destinos crece a varias decenas (orientativamente 20 o más), el mega menú deja ver todo el espacio de navegación de un vistazo y le ahorra al usuario saltarse niveles. Pero por debajo de ese umbral, un dropdown de un solo nivel produce menor carga cognitiva y menor riesgo de error de apuntado. La regla resumida: si el usuario tiene que recordar por dónde vino para saber a dónde va, el sitio necesita mega menú; si no, no.

Dentro del panel, cada columna o grupo de enlaces necesita un encabezado legible que etiquete la categoría. Los separadores decorativos sin texto son insuficientes: el usuario escanea en patrón F y necesita anclas verbales en la cima de cada grupo para orientarse antes de leer enlace por enlace. Las etiquetas deben empezar por la palabra que más información carga y ordenarse por flujo de trabajo o importancia, con el grupo más usado arriba a la izquierda. Evita etiquetas que arrancan todas con la misma palabra: si "Pre-Owned Juegos / Pre-Owned Consolas / Pre-Owned Accesorios" comparten prefijo, se vuelven indistinguibles en el escaneo rápido.

Para categorías de productos físicos (moda, mobiliario, tecnología), una miniatura o ícono junto a cada grupo reduce el tiempo de decisión: el usuario reconoce visualmente antes de leer. No toda categoría lo necesita. En menús de software o servicios B2B, un ícono vectorial sobrio orienta mejor que una fotografía: las fotos de personas sonrientes como thumbnails de categoría confunden en lugar de guiar. La proporción correcta imagen/texto depende de la densidad de categorías; cuando hay muchas, el exceso de imágenes convierte el panel en ruido y ralentiza el escaneo. La imagen es una ayuda de reconocimiento, no decoración.

Los roles role="menú" y role="menuitem" se diseñaron para replicar menús de aplicación de escritorio (File > Save), donde el lector de pantalla espera navegación completa con flechas, primera letra y Home/End, interacciones que ninguna navegación de sitio implementa. La arquitectura correcta para un mega menú es el patrón Disclosure del APG de W3C: <nav> con <ul>, un <button> con aria-expanded y aria-controls, y el subpanel como una lista de enlaces ordinarios. El W3C es explícito: la navegación de sitio no usa el rol menú porque no provee la funcionalidad compleja que la tecnología asistiva espera de ese widget. Además, los roles de menú prohíben incluir cualquier elemento activo no-menú dentro de la misma estructura.

<nav>
  <ul>
   <li>
    <button
      aria-expanded="false"
      aria-controls="p-prod"
    >Productos</button>
    <ul id="p-prod">
      <li><a>API</a></li>
      <li><a>SDKs</a></li>
    </ul>
   </li>
  </ul>
</nav>

<ul role="menubar">
  <li role="menuitem">
    Productos
    <ul role="menú">
      <li role="menuitem">
        API
      </li>
    </ul>
  </li>
</ul>

// SR anuncia "menú"; el
// usuario prueba flechas
// y nada responde.

Todo botón que activa un subpanel debe llevar aria-expanded (false cerrado, true abierto) y aria-controls apuntando al id del panel. Al abrir, el foco avanza con Tab por los enlaces visibles; al presionar Escape, el panel cierra y el foco regresa al botón disparador. Sin este ciclo completo, los usuarios de teclado y lectores de pantalla quedan atrapados. La interacción la fija el APG de W3C: Tab/Shift+Tab navega botones y enlaces, Space o Enter alterna la visibilidad, y Escape cierra y devuelve el foco al botón. El foco nunca debe aterrizar en ítems ocultos: debe ir al elemento que expande la sección colapsada. WCAG 2.4.11 exige además que el panel no tape por completo el elemento enfocado.

Los usuarios táctiles no tienen hover; los de teclado activan con Enter o Space. Un mega menú que solo responde a mouseover excluye a ambos grupos. La implementación robusta escucha los tres caminos: mouseenter para hover en desktop, click y keydown (Enter/Space) para teclado y touch, y focus-within como respaldo CSS. El estado del panel debe ser idéntico sin importar cómo se activó. Esto no es preferencia sino el criterio normativo WCAG 2.1.1 (Keyboard): toda funcionalidad debe ser operable por teclado. Un panel atado solo a :hover de CSS deja al usuario de tablet tocando un botón muerto.

Sin delay, un usuario que mueve el cursor hacia otra parte de la página activa accidentalmente todos los mega menús que cruza al pasar. Un delay corto de apertura (en el orden de 300 a 500 ms) elimina la mayoría de activaciones accidentales sin crear latencia perceptible; delays demasiado largos reducen el parpadeo pero introducen lag notable. Pese a ser un patrón conocido, una proporción alta de sitios de e-commerce no implementa ningún delay. Para el cierre, la técnica del triángulo (popularizada por Amazon) traza un área triangular entre el cursor y los bordes del panel, permitiendo desplazarse en diagonal hacia las opciones del submenú sin que este desaparezca. Si el panel se cierra al salir 1px del ítem, el usuario debe moverse en línea recta perfecta: extremadamente frustrante.

El mega menú ya es la solución al problema de la profundidad excesiva. Introducir un segundo nivel dentro del panel (un flyout sobre un encabezado) recrea el problema que el mega menú venía a resolver y suma la complejidad de gestionar hover y foco en dos dimensiones. El patrón correcto: el panel muestra categorías-grupo con sus enlaces directos; si una categoría tiene demasiados sub-ítems, merece su propia página de categoría, no otro nivel de menú. El consenso de NN/g y Smashing es normativo contra la anidación, y la técnica del triángulo se vuelve inservible cuando los targets están demasiado juntos, como ocurre al multiplicar la densidad con sub-submenús imposibles de controlar por teclado o touch.