Breadcrumbs & Nav Secundaria

Los breadcrumbs aportan orientación cuando el sitio tiene al menos tres niveles de jerarquía y el usuario necesita ubicarse dentro de una estructura compleja. En arquitecturas planas o en flujos transaccionales lineales (checkout, wizard de pasos) añaden ruido sin orientación real y compiten con el indicador de progreso del propio flujo. GOV.UK los define explícitamente como inadecuados para "progress indicators for linear journeys or transactions" y para páginas que ya cuentan con suficiente navegación lateral. NN/g recomienda omitirlos en estructuras simples: si bastan dos clics para llegar a cualquier página, el breadcrumb es decorativo.

Existen tres tipos de breadcrumb: location-based (posición fija en la jerarquía del sitio), path-based o history (la ruta que el usuario recorrió esta sesión) y attribute-based (atributos o filtros del ítem). Solo los location-based aportan orientación consistente: la misma página muestra siempre la misma ruta, sin importar cómo llegó el usuario. Los path-based duplican el botón Atrás del navegador y confunden cuando el usuario tomó atajos o digresiones, Nielsen los desaconseja explícitamente por esta razón. Un breadcrump que cambia según la sesión deja de ser un mapa y se vuelve un registro.

El ítem final del breadcrumb representa la página en la que ya estás. Convertirlo en enlace a sí mismo genera confusión, el clic no produce navegación perceptible, y provoca rage clicks. Debe ser texto plano, o un <a> con aria-current="page" si por razones de estilo se mantiene como enlace, para que los lectores de pantalla anuncien la ubicación actual. El patrón Breadcrumb de WAI-ARIA APG lo establece así: el enlace a la página actual lleva aria-current="page", y el atributo es opcional solo si el ítem actual no es un enlace. Esto satisface además WCAG 2.4.8 (Location).

El breadcrumb debe envolverse en <nav aria-label="Breadcrumb"> para exponerlo como landmark navegable a la tecnología asistiva, y sus ítems van en una <ol> porque el orden jerárquico es significativo (no es una lista cualquiera). Una <div> con spans separados por "›" no tiene semántica ni landmark: el lector de pantalla no la reconoce como navegación ni anuncia "lista de 4 ítems". Si la página tiene varios <nav>, cada uno necesita un aria-label único (técnica WCAG ARIA11) para distinguirlos. GOV.UK y aditus.io usan exactamente este patrón en su implementación oficial.

<nav aria-label="Breadcrumb">
  <ol>          <!-- orden = jerarquía -->
    <li><a href="/">Inicio</a></li>
    <li><a href="/laptops">Laptops</a></li>
    <li><span aria-current="page">Gaming</span></li>
  </ol>
</nav>

Los caracteres separadores (/, ›, >) entre ítems son puramente visuales y no deben ser anunciados por lectores de pantalla. Si se insertan en el HTML deben ir en <span aria-hidden="true">; la alternativa preferida es generarlos con CSS ::before en cada <li>, que el árbol de accesibilidad ignora automáticamente. Si el separador es un <li> de texto sin ocultar, el AT lo anuncia como "barra diagonal" o "mayor que" entre cada nivel, degradando la lectura: "Inicio, barra, Laptops, barra, Gaming". La generación por CSS es la de menor fricción porque nunca produce nodos en el accessibility tree.

En pantallas pequeñas, el breadcrumb completo suele provocar wrap multi-línea que desperdicia espacio vertical valioso y genera tap targets por debajo del mínimo recomendado (1cm × 1cm según NN/g). El patrón estándar es colapsar a un enlace de retroceso al padre inmediato ("← Ropa") o mostrar solo el primer y último ítem, como hace GOV.UK con su modificador collapse-on-mobile en breakpoints de tablet y menores. NN/g advierte que en móvil "the cost of using breadcrumbs can quickly overwhelm the benefits"; Smashing ranquea el wrapping multi-línea como la peor opción por consumir espacio vertical excesivo. El truncado es la salida correcta, no el desbordamiento.

Google usa el marcado estructurado BreadcrumbList para mostrar la ruta de navegación en los resultados de búsqueda en lugar de la URL cruda, lo que mejora la comprensión de la jerarquía del sitio. La implementación requiere un array de ListItem con position (entero desde 1), name y item (la URL; omitible en el ítem final, que es la página actual). Google recomienda JSON-LD por ser el formato de menor riesgo de error de parsing, y exige un mínimo de dos ítems. Sin marcado, Google muestra la cadena de URL /categoría/subcategoria/producto; con él, muestra "Inicio › Laptops › Gaming".

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type":"ListItem", "position":1,
      "name":"Inicio", "item":"https://ej.com" },
    { "@type":"ListItem", "position":2,
      "name":"Laptops", "item":"https://ej.com/laptops" },
    { "@type":"ListItem", "position":3,
      "name":"Gaming" /* sin item: página actual */ }
  ]
}

Cuando una sección tiene sub-páginas propias (ej. "Soporte: FAQ / Contacto / Estado de pedido") se necesita una navegación local o sidebar nav, conceptualmente distinta del breadcrumb (que orienta) y de la nav primaria (que cubre todo el sitio). Este componente debe ser un <nav> separado con aria-label único (ej. "Navegación de soporte") para que los usuarios de tecnología asistiva puedan saltar directamente a él. Tener varios <nav> sin labels distintos incumple la técnica WCAG ARIA11: el lector de pantalla anuncia "Navigation, Navigation, Navigation" sin poder distinguirlos. El breadcrumb va antes del <main>; la nav local vive dentro o junto a él como primer bloque.