Comienza por las tareas y una arquitectura de información pequeña
La arquitectura de información es cómo se agrupan, nombran y conectan contenidos y funciones. Enumera las tareas de los visitantes y mapea la página de inicio de cada tarea, la página siguiente y el estado final exitoso. Esto muestra si un elemento de menú es útil o si es una etiqueta interna que los visitantes deben descifrar. Mantén la navegación primaria enfocada en secciones que inician esas tareas.
La navegación no es un mapa del sitio. GOV.UK aconseja listar secciones útiles de primer nivel en lugar de cada parte de un servicio. Cuando un recorrido tiene un orden obligatorio, muéstralo en el contenido o en una lista de tareas en vez de obligar a la gente a inferirlo desde un menú global.
Coloca páginas juntas cuando los visitantes esperan la misma respuesta o tarea, no porque un equipo las gestione.
Usa páginas de aterrizaje y enlaces contextuales para el detalle en lugar de un encabezado denso.
Usa etiquetas que predigan el destino
Una etiqueta es una promesa sobre lo que sigue. Prefiere nombres familiares como “Precios”, “Documentación”, “Obtener soporte” o “Administrar cuenta” cuando coincidan con el destino. Evita etiquetas vagas como “Recursos” o “Explorar” a menos que los visitantes puedan predecir el contenido. Mantén la redacción y el orden consistentes.
Google aconseja texto de enlace conciso y relevante que sea comprensible fuera de contexto. Los genéricos “haz clic aquí” y los enlaces con relleno de palabras clave no cumplen eso. Da a un control solo con icono un nombre accesible que describa su acción.
Usa “Ver planes” en lugar de “Más información” cuando el destino son los planes.
Marca el destino activo visual y programáticamente; W3C describe aria-current=page para la página mostrada.
Haz que los destinos sean rastreables y estructuralmente claros
Un destino de navegación debe ser normalmente un ancla HTML con un href que resuelva a una dirección web real. Google indica que generalmente puede rastrear esta forma, incluyendo anclas insertadas dinámicamente cuando el marcado renderizado conserva esa estructura. Un manejador de clics o un atributo personalizado por sí solo no es un sustituto fiable. Inspecciona la salida renderizada, no solo el código fuente del framework.
Usa estructura semántica alrededor de la navegación principal. W3C recomienda un elemento nav y, para la navegación habitual del sitio, una lista. Si una página tiene varias regiones de navegación, etiqueta cada una para que un usuario de lector de pantalla pueda distinguir la navegación primaria del pie de página o la navegación local.
Confirma que los destinos importantes en escritorio y móvil sean anclas con valores href después del renderizado del lado del cliente.
La Inspección de URL ofrece información sobre rastreo, indexación y servicio en Google; no demuestra que los visitantes puedan encontrar una página.
Diseña el menú móvil como una interacción completa
La navegación responsive puede colapsar, pero los destinos que permanezcan deben mantener la misma redacción, orden y objetivo entre tamaños de pantalla. W3C permite colapsar u ocultar elementos de subnavegación mientras pide consistencia. No conviertas una ruta crítica en exclusiva de escritorio porque el encabezado está abarrotado; reubica material de baja prioridad o reconsidera la jerarquía.
Para un menú que muestra/oculta, usa un botón para controlar el grupo de enlaces y comunica si está abierto. El ejemplo disclosure-navigation de W3C usa aria-expanded y aria-controls y documenta Tab, Shift+Tab y Escape. Es instructivo, así que prueba tu componente con las combinaciones que usa tu audiencia.
Cuando se necesiten tanto la página padre como sus enlaces hijos, distingue el enlace de la página del control que la expande.
Cualquier cosa revelada por hover del puntero debe ser descubrible con foco de teclado y táctil.
Soporta orientación y navegación por teclado
El acceso por teclado no es un detalle final. WCAG 2.1 Success Criterion 2.1.1 exige que la funcionalidad sea operable mediante una interfaz de teclado excepto en entrada dependiente de la trayectoria. En un encabezado, los visitantes deben poder navegar con Tab por los controles, ver el foco, activar enlaces y botones, y alejarse sin quedar atrapados.
Los enlaces repetidos del encabezado pueden hacer que las páginas sean lentas de recorrer. Un enlace de omisión (skip link) cerca del inicio ofrece a los usuarios de teclado una ruta al contenido principal. GOV.UK explica que está visualmente oculto hasta que el uso del teclado lo activa. Comprueba que aterrice en un destino significativo.
No elimines el indicador de foco del navegador sin una alternativa clara que permanezca visible al hacer zoom.
Usa Tab, Shift+Tab, Enter, Space y Escape desde el encabezado hasta la página de destino.
Prueba la localización antes y después del lanzamiento
Pide a personas representativas que completen una tarea realista, como encontrar la guía de cancelación o comparar planes. Observa a dónde esperan ir, qué etiquetas interpretan mal y si recurren a la búsqueda porque la navegación les falló. No guíes a las personas hacia la etiqueta prevista. Registra cada barrera y el cambio mínimo que probablemente la elimine.
Combina las pruebas de tareas con comprobaciones técnicas. Easy Checks de W3C recomienda probar sin ratón, incluyendo visibilidad del foco, orden de tabulación, trampas de teclado y desplegables. Repite las tareas principales en anchos reducidos y con tamaños de texto mayores. Las comprobaciones automatizadas pueden señalar problemas de marcado, pero no pueden establecer que una etiqueta tenga sentido.
Registra el punto final previsto y el dispositivo o método de entrada soportado antes de probar.
Prueba la ruta antigua y la nueva con las mismas tareas en lugar de confiar en la preferencia de las partes interesadas.
Trata los cambios de navegación como lanzamientos sensibles a la disponibilidad
Un encabezado puede cargarse mientras una ruta crítica está efectivamente indisponible: un checkout, inicio de sesión, ruta de soporte o página de documentación puede quedar detrás de un estado roto, un enlace obsoleto o una redirección errónea. Antes del lanzamiento, inventaría los destinos críticos, prueba las rutas en escritorio y móvil y confirma que los enlaces renderizados alcanzan la página prevista. Usa entornos autorizados para rutas autenticadas o regionales.
El papel de SIU es la remediación proactiva: realiza una prueba previa, verifica las rutas esenciales tras el despliegue y haz que la corrección sea reversible. Mantén una configuración de menú versionada, nombra a la persona que puede restaurarla y valida las rutas restauradas. Esto limita el impacto del lanzamiento; no reemplaza la investigación de usabilidad o el monitoreo de estado en vivo.
Bloquea la publicación cuando falte un destino crítico, sea incorrecto o no pueda alcanzarse con teclado y táctil.
Documenta la configuración anterior, el responsable, el disparador y los pasos de validación antes de reestructurar.