Inizia dai compiti e da una piccola architettura dell'informazione
L'architettura dell'informazione è il modo in cui contenuti e funzioni sono raggruppati, nominati e collegati. Elenca i compiti dei visitatori, quindi mappa la pagina di partenza di ciascun compito, la pagina successiva e lo stato finale di successo. Questo mostra se una voce di menu è utile o se è un'etichetta interna che i visitatori devono decodificare. Mantieni la navigazione principale focalizzata sulle sezioni che avviano quei compiti.
La navigazione non è una mappa del sito. GOV.UK consiglia di elencare sezioni top-level utili piuttosto che ogni parte di un servizio. Quando un percorso richiede un ordine obbligato, mostralo nel contenuto o in una lista di compiti invece di farlo dedurre a un menu globale.
Metti insieme le pagine quando i visitatori si aspettano la stessa risposta o lo stesso compito, non perché un team le possiede.
Usa pagine di atterraggio e link contestuali per i dettagli invece di un'intestazione densa.
Usa etichette che prevedano la destinazione
Un'etichetta è una promessa su ciò che segue. Preferisci nomi familiari come Prezzi, Documentazione, Assistenza o Gestisci account quando corrispondono alla destinazione. Evita etichette vaghe come Risorse o Esplora a meno che i visitatori non possano prevederne il contenuto. Mantieni coerenza nel linguaggio e nell'ordine.
Google consiglia testo di link conciso e pertinente che sia comprensibile anche fuori contesto. I classici click here e i link riempiti di parole chiave non fanno né l'una né l'altra cosa. Dai a un controllo solo icona un nome accessibile che descriva la sua azione.
Usa Vedi piani invece di Scopri di più quando la destinazione è la pagina dei piani.
Segna la destinazione attiva visivamente e programmaticamente; il W3C descrive aria-current=page per la pagina visualizzata.
Rendi le destinazioni crawlable e strutturalmente chiare
Una destinazione di navigazione dovrebbe normalmente essere un ancóra HTML con un href che risolva in un vero indirizzo web. Google afferma che in genere può eseguire il crawling di questa forma, comprese le ancóre inserite dinamicamente quando il markup reso mantiene quella struttura. Un gestore di click o un attributo personalizzato da soli non sono un sostituto affidabile. Ispeziona l'output renderizzato, non solo il codice sorgente del framework.
Usa una struttura semantica attorno alla navigazione principale. Il W3C raccomanda l'elemento nav e, per la navigazione ordinaria del sito, una lista. Se una pagina ha diverse regioni di navigazione, etichettale in modo che un utente di screen reader possa distinguere la navigazione primaria da quella di footer o locale.
Conferma che le destinazioni importanti su desktop e mobile abbiano ancóre e valori href dopo il client-side rendering.
URL Inspection fornisce informazioni su crawl, indicizzazione e serving per Google; non prova che i visitatori possano trovare una pagina.
Progetta il menu mobile come un'interazione completa
La navigazione responsive può collassare, ma le destinazioni che rimangono dovrebbero mantenere lo stesso wording, ordine e obiettivo tra le dimensioni dello schermo. Il W3C permette di collassare o nascondere elementi di subnavigation pur richiedendo coerenza. Non rendere una rotta critica disponibile solo su desktop perché l'intestazione è affollata; sposta materiali a priorità minore o rivaluta la gerarchia.
Per un menu che mostra/nasconde, usa un bottone per controllare il gruppo di link e comunica se è aperto. L'esempio disclosure-navigation del W3C usa aria-expanded e aria-controls e documenta Tab, Shift+Tab ed Escape. È istruttivo, quindi testa il tuo componente con le combinazioni che usa il tuo pubblico.
Quando sono necessari sia il link della pagina padre sia i link figlio, distingue il link della pagina dal controllo che lo espande.
Qualsiasi elemento rivelato dal passaggio del puntatore deve essere scopribile con focus da tastiera e con touch.
Supporta l'orientamento e lo spostamento con la tastiera
L'accesso da tastiera non è un rifinitura finale. WCAG 2.1 Success Criterion 2.1.1 richiede che le funzionalità siano operabili tramite un'interfaccia tastiera, eccetto per l'input dipendente dal percorso. In un'intestazione i visitatori dovrebbero poter usare Tab per scorrere i controlli, vedere il focus, attivare link e pulsanti e allontanarsi senza rimanere intrappolati.
Link ripetuti nell'intestazione possono rendere le pagine lente da attraversare. Un skip link vicino all'inizio fornisce agli utenti da tastiera una rotta verso il contenuto principale. GOV.UK spiega che è visivamente nascosto finché l'uso della tastiera non lo attiva. Verifica che punti a un target significativo.
Non rimuovere l'indicatore di focus del browser senza una chiara alternativa che resti visibile anche con lo zoom.
Usa Tab, Shift+Tab, Enter, Space ed Escape dall'intestazione fino alla pagina di destinazione.
Testa la reperibilità prima e dopo il rilascio
Chiedi a persone rappresentative di completare un compito realistico, come trovare le istruzioni di cancellazione o confrontare i piani. Osserva dove si aspettano di andare, quali etichette fraintendono e se ricorrono alla ricerca perché la navigazione li ha delusi. Non guidarli verso l'etichetta prevista. Registra ogni barriera e il cambiamento minimo probabile per rimuoverla.
Abbina i test di compito con controlli tecnici. Easy Checks del W3C raccomanda di testare senza mouse, inclusa la visibilità del focus, l'ordine di tabulazione, i trappole da tastiera e i dropdown. Ripeti i compiti core a larghezze ridotte e con dimensioni del testo maggiori. I controlli automatizzati possono segnalare problemi di markup, ma non stabilire se un'etichetta sia comprensibile.
Registra l'endpoint previsto e il dispositivo o metodo di input supportato prima del test.
Testa il vecchio e il nuovo percorso con gli stessi compiti invece di fare affidamento sulla preferenza degli stakeholder.
Tratta i cambiamenti di navigazione come rilasci sensibili alla disponibilità
Un'intestazione può caricare mentre un percorso critico è di fatto non disponibile: un checkout, il login, una rotta di assistenza o una pagina di documentazione possono trovarsi dietro uno stato rotto, un link obsoleto o un redirect errato. Prima del rilascio, fai l'inventario delle destinazioni critiche, testa i percorsi su desktop e mobile e conferma che i link resi raggiungano la pagina prevista. Usa ambienti autorizzati per percorsi autenticati o regionali.
Il ruolo di SIU è la rimedio proattivo: esegui un preflight, verifica i percorsi essenziali dopo il deploy e rendi la correzione reversibile. Conserva una configurazione del menu versionata, nomina la persona che può ripristinarla e valida i percorsi ripristinati. Questo limita l'impatto del rilascio; non sostituisce la ricerca di usabilità o il monitoraggio dello stato live.
Blocca la pubblicazione quando una destinazione critica manca, è errata o non è raggiungibile con tastiera e touch.
Documenta la configurazione precedente, il proprietario, il trigger e i passaggi di validazione prima di ristrutturare.