Accessibilità
Breadcrumb accessibile
Un breadcrumb accessibile è un nav con un nome, una lista ordinata, aria-current sull'ultimo elemento e un JSON-LD con la stessa gerarchia della pagina.
In sintesi
- Il breadcrumb va dentro un nav con aria-label, in una lista ordinata: la struttura arriva dall'HTML, non dagli attributi.
- L'ultimo elemento porta aria-current="page" e non è un link verso sé stesso.
- I separatori sono decorativi e non devono finire nel nome accessibile del link.
Un breadcrumb accessibile è un <nav> con un nome, una lista ordinata di link e aria-current="page" sull'ultimo elemento; il resto è ripetere la stessa gerarchia nel JSON-LD. Niente ruoli aggiunti, niente tabindex: la semantica arriva dagli elementi nativi.
La struttura minima
La lista ordinata non è un dettaglio: dice quante voci ci sono e in che ordine, e il lettore di schermo la annuncia come «lista di 3 elementi». Il nome sul nav distingue questa navigazione da quella principale quando l'utente apre l'elenco dei landmark.
Home
Components
Accessibility
Tre dettagli che rompono
- Separatori annunciati: un chevron come testo dentro il link entra nel nome accessibile. Usa
::beforein CSS, oppurearia-hidden="true"sul separatore. - Ultimo elemento come link: un link verso la pagina in cui ti trovi è un controllo che non fa nulla. Testo semplice con
aria-current="page". - Nomi generici: «Continua» o «Qui» non descrivono la destinazione e violano 2.4.4. Ogni voce deve avere senso letta da sola.
JSON-LD con la stessa gerarchia
Il dato strutturato BreadcrumbList deve descrivere le stesse voci, nello stesso ordine, con position che parte da 1. Se la pagina visibile e il JSON-LD divergono, il markup è una dichiarazione falsa: meglio nessun dato strutturato. Il formato completo, con i controlli, è in BreadcrumbList senza errori.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "Components", "item": "https://example.com/components" },
{ "@type": "ListItem", "position": 3, "name": "Accessibility" }
]
}Il catalogo EneUI
Il record verificato è breadcrumb-01 di flx, descritto come «link con pagina corrente e separatori a chevron»: è il caso della pagina, con la dipendenza di registry breadcrumb e nessun pacchetto esterno. Le altre viste sono in navigazione e accessibilità. Controllo eseguito il 1 novembre 2026 sul catalogo da 111.985 componenti.
La limitazione
Il breadcrumb orienta, non sostituisce il titolo della pagina né una struttura di URL leggibile, e non serve a chi arriva da una ricerca: quella persona entra a metà gerarchia e non ha percorso. Su un sito con due livelli la lista aggiunge rumore; su uno con cinque livelli comprimerla su mobile è necessario, ma il livello corrente deve restare visibile.
Dove continuare
La distinzione fra ruoli, stati e proprietà è in che cos'è ARIA; la checklist per i componenti è in componenti React accessibili. Se confronti primitive headless per costruire la navigazione, leggi Radix, Base UI e React Aria.
Domande frequenti
Serve aria-label sul nav del breadcrumb?
Sì, quando in pagina c'è più di un nav. Il nome «Breadcrumb» o «Percorso» distingue questa navigazione da quella principale nell'elenco dei landmark.
L'ultimo elemento deve essere un link?
No. È la pagina corrente: testo semplice con aria-current="page", oppure un link con lo stesso attributo se vuoi mantenerlo cliccabile.
I separatori vanno letti dallo screen reader?
No. Mettili in CSS con ::before o nascondili con aria-hidden="true": una barra o un chevron annunciato dopo ogni voce rende la lista illeggibile.
Il breadcrumb è obbligatorio per WCAG?
No, nessun criterio lo impone. Se c'è, deve rispettare 1.3.1, 2.4.4 e 4.1.2 come qualsiasi altra navigazione.
Devo mostrare tutti i livelli su mobile?
No, puoi comprimere i livelli intermedi, ma il primo e l'ultimo restano visibili: senza il livello corrente la persona perde il punto in cui si trova.