Navegación WordPress enterprise que tu equipo de marketing puede cambiar sin un desarrollador

Sí, en todo lo estructural. Agregar, quitar, reordenar y anidar ítems pasa en la pantalla estándar de menús de WordPress, que es justamente la razón por la que nos quedamos ahí en lugar de mover los menús a un plugin o a un conjunto de campos personalizados.

El límite está en la apariencia. Agregar un ítem al menú principal es editorial. Introducir un tipo nuevo de ítem, por ejemplo un panel de mega menú con una imagen promocional donde antes no había ninguna, es un componente, y los componentes se construyen una vez en código para que se comporten igual en todos los lugares donde aparecen.

WordPress renderiza los menús a través de wp_nav_menu y Walker_Nav_Menu, que emiten markup como efecto secundario de recorrer el árbol. Cambiar ese markup implica hacer una subclase del walker y sobrescribir concatenaciones de strings, y por eso tantos themes enterprise arrastran una clase walker que nadie quiere modificar.

Log1x/Navi construye el mismo menú como un array estructurado: ítems, hijos, clases, estados activos. El theme renderiza eso como componentes. Estructura y markup quedan separados, así agregar un campo de ícono o un atributo ARIA es un cambio en un componente, no una reescritura del renderer. Es un paquete de Composer open source, y es lo que corre este sitio.

Es lo que hacemos por defecto. Un mega menú es una decisión de renderizado aplicada a un ítem de menú que tiene hijos, así que la estructura vive en el editor de menús nativo y el layout del panel vive en el theme.

Un editor anida ítems bajo una entrada de primer nivel igual que lo haría para un dropdown normal, y el componente decide si eso se renderiza como una lista simple o como un panel de varias columnas con íconos, descripciones y una llamada a la acción. Sin una segunda interfaz, sin estilos divergentes.

La navegación es donde primero se rompe la accesibilidad por teclado, porque el hover es fácil de construir y el foco es fácil de olvidar. Tratamos cuatro cosas como requisitos, no como refinamientos:

• Un orden de foco que sigue el orden visual, con un estado de foco visible contra cualquier fondo sobre el que pueda apoyarse el header.
• Submenús que se abren tanto con foco como con hover, y se cierran con escape sin dejar atrapada a la persona.
• El estado abierto y cerrado expuesto de forma programática, para que la tecnología asistiva lo anuncie en lugar de dejarlo implícito en el CSS.
• Un drawer mobile que lleva el foco hacia adentro cuando se abre y lo devuelve cuando se cierra.

Cada una de estas cosas se verifica a mano, porque un escaneo puede confirmar que un atributo existe y no puede confirmar que la experiencia funcione. La práctica completa está en nuestra página de accesibilidad.

La arquitectura de información es cómo se modela y se relaciona el contenido: tipos de contenido, taxonomías, jerarquía y la estructura de URLs que se desprende de eso. La navegación es el conjunto de caminos que se exponen a través de ese modelo. El menú es una vista, no la arquitectura.

Esto importa cuando las dos cosas se confunden. Un menú que necesita siete ítems de primer nivel suele ser señal de un modelo de contenido que nunca tuvo un segundo nivel, y ningún trabajo de mega menú arregla eso. Miramos las dos cosas juntas; el lado del modelado está en nuestra página de arquitectura de contenido.