Scelgo prima HTML; uso ARIA solo quando il markup non basta. Per strutturare una pagina parto da <header>, <nav>, <main>, <aside> e <footer>, con un solo landmark main esposto per documento.
Il confronto riguarda significato, nomi accessibili, supporto e manutenzione. In pratica:
- Uso
<section>e<form>come landmark solo con un nome accessibile; per la ricerca valuto<search>orole="search". - Distinguo le aree ripetute con nomi chiari, senza trasformare ogni contenitore in una destinazione.
- Controllo ruoli e nomi nell’albero di accessibilità, poi provo la navigazione con uno screen reader, anche dopo modifiche al layout o al CMS.
<u>Il punto è aiutare chi naviga, non migliorare direttamente il ranking.</u> E i landmark, da soli, non aggiungono comandi da tastiera.
Confronto rapido
| Criterio | HTML nativo | ARIA |
|---|---|---|
| Significato | Dato dal tag e dal contesto | Assegnato con role
|
| Nomi accessibili | Dipendono dal landmark | Seguono i requisiti del ruolo |
| Supporto | Da verificare negli ambienti previsti | Da verificare negli ambienti previsti |
| Manutenzione | Meno attributi da gestire | Ruoli e attributi da tenere coerenti |
| Quando lo scelgo | Per strutture nuove o modificabili | Quando non posso usare l’elemento HTML adatto |
HTML elements and their landmark roles
resta un’intestazione locale | |<main>|main| Contenuto principale | Non richiesto | Un solo landmark principale esposto per documento | |<footer>|contentinfo| Informazioni sul documento, copyright e privacy | Non richiesto | Non diventacontentinfodentro<article>, <aside>, <main>, <nav>o<section>| |<nav>|navigation| Percorsi di navigazione rilevanti | Serve a distinguere navigazioni diverse | Non va usato per qualsiasi raccolta di link | |<aside>|complementary| Contenuto di supporto | Consigliato per distinguere più aree | Correlato al contenuto principale, ma comprensibile anche separatamente | |<section>|region, se denominata | Sezione tematica raggiungibile direttamente | Necessario | Riservare il landmark alle sezioni importanti | | <form>|form, se denominato | Raccolta di controlli di un modulo | Necessario per l’esposizione come landmark | Utile per moduli articolati o distinguibili | | <search>|search` | Area di ricerca | Serve a distinguere eventuali ricerche multiple | Verificare il supporto nelle combinazioni previste di browser e tecnologie assistive |
I landmark nativi non richiedono un nome, tranne nei casi in cui il nome è necessario per esporli come tali. Partiamo da quelli che definiscono la struttura di pagina più comune.
Intestazione, contenuto principale e piè di pagina
Usa un solo banner, un solo main e un solo contentinfo per pagina. Gli elementi <header> e <footer> inseriti nei contenitori indicati in tabella restano validi, ma descrivono una struttura locale. Non assegnare loro ruoli di pagina per forzarne l’esposizione come landmark.
Nelle app con viste dinamiche, esponi un solo main per schermata.
Navigazione, contenuti correlati e sezioni denominate
Riserva <nav> ai percorsi di navigazione rilevanti e <aside> alle risorse collegate al contenuto principale. La posizione laterale non basta: ciò che conta è che il contenuto offra un supporto effettivo.
Per trasformare una <section> in un landmark, aggiungi aria-labelledby alla sezione e indica l’id del titolo visibile. Un <h2> da solo non basta.
Ricerca, moduli e contenitori esistenti
Usa <search> per l’area di ricerca, dopo averne verificato il supporto negli ambienti previsti. Per gestire la compatibilità, puoi usare role="search" su un contenitore adatto. Il nome del <form>, invece, non sostituisce le etichette dei campi.
Se riutilizzi un contenitore esistente, assegna il ruolo ARIA corretto e rispetta le condizioni di ambito e di denominazione: role="landmark" non è valido. Questi ruoli non aggiungono focus né comportamenti da tastiera.
sbb-itb-bc3fb49
HTML versus ARIA: significato, supporto e manutenzione
HTML esprime il landmark attraverso il tag; ARIA lo aggiunge o lo corregge con role. Per <header>, <nav>, <main>, <aside> e <footer>, il punto è capire cosa aggiunge ARIA e quanto lavoro richiede mantenerlo corretto.
| Aspetto | HTML nativo | Ruoli landmark ARIA |
|---|---|---|
| Semantica nell’albero di accessibilità | Implicita nell’elemento, in base al contesto | Esplicita, assegnata con role
|
| Denominazione | Dipende dal tipo di landmark e dalla necessità di distinguerlo | Si applicano comunque i requisiti di denominazione del ruolo scelto |
| Semplicità del codice | Meno attributi; il tag rende leggibile il significato | Attributi aggiuntivi da mantenere coerenti |
| Rischi di manutenzione | Più bassi, grazie alla semantica nativa | Più alti: ruolo e attributi devono restare coerenti con il markup |
| Casi d’uso | Prima scelta per strutture nuove o modificabili | Quando non è possibile sostituire il markup esistente |
| Errori comuni | Scegliere un elemento per l’aspetto anziché per il significato | Sovrascrivere una semantica corretta o aggiungere ruoli ridondanti |
I landmark descrivono la struttura, non aggiungono comandi da tastiera. Queste funzionalità appartengono agli elementi HTML interattivi che le prevedono.
Dopo ogni modifica, occorre ricontrollare ruolo, nome accessibile e albero di accessibilità. Il passaggio successivo porta questa distinzione nella pratica: capire quando basta HTML, quando serve ARIA e come verificare i landmark con gli screen reader previsti.
Come scegliere e testare i landmark
Landmark HTML e ARIA: come sceglierli e testarli
Dopo aver scelto tra HTML nativo e ARIA, mappa le aree funzionali dei template reali: intestazione del sito, menu, ricerca, contenuto principale, informazioni complementari e piè di pagina. Individua le destinazioni utili da raggiungere direttamente, non i semplici contenitori grafici. Verifica poi la navigazione su homepage, scheda prodotto e checkout.
Parti dall’HTML nativo
Usa gli elementi HTML quando descrivono una funzione reale, non per contrassegnare griglie, schede o contenitori di layout. Posiziona <aside> in base al suo ambito: l’intera pagina oppure un singolo articolo. Documenta le eccezioni legate al codice legacy.
Scegli prima il landmark corretto, poi assegnagli un nome chiaro che lo renda riconoscibile.
Dai un nome alle regioni ripetute e ordina i titoli
Distingui le regioni con nomi brevi e legati alla loro funzione. Se c’è un titolo visibile, usalo per assegnare il nome; ricorri a aria-label solo quando manca. Le navigazioni con lo stesso scopo possono condividere il nome, mentre quelle con scopi diversi devono essere distinguibili.
Organizza i livelli dei titoli secondo la gerarchia dei contenuti, non secondo la dimensione grafica. I landmark identificano le aree; i titoli ne chiariscono la struttura.
Controlla l’albero di accessibilità e la navigazione con screen reader
Negli strumenti di accessibilità del browser, confronta ruoli, nomi, titoli e confini delle regioni con il contenuto visibile. Cerca duplicati, landmark vuoti o in eccesso e pannelli nascosti che risultano esposti per errore.
Passa poi ad almeno una combinazione browser–screen reader supportata dal progetto. Naviga prima per landmark, poi per titoli, e controlla che ogni destinazione contenga ciò che il nome promette.
Ripeti la prova alle diverse larghezze previste dal layout responsive e dopo aver aperto o chiuso menu e finestre modali. I controlli automatici non bastano: testa i template rappresentativi prima di estendere la modifica al sito e ripeti il test dopo ogni aggiornamento del CMS.
Conclusione: prima HTML, ARIA quando serve
Dopo aver scelto i landmark, il criterio resta semplice: ciascuno deve essere una destinazione utile, riconoscibile e unica. Parti da HTML e usa ARIA solo quando serve, evitando ruoli ridondanti e regioni inutili.
Nel progetto, considera la validazione dell’accessibilità un requisito separato, con responsabilità e criteri di accettazione chiari. Controlla che le destinazioni siano chiare, i nomi coerenti e i titoli ordinati, senza landmark superflui.
FAQs
Come gestisco i landmark nei componenti riutilizzabili?
Preferisci gli elementi HTML nativi come nav, main, aside e footer: semantica e accessibilità sono già integrate. Se un componente compare più volte nella stessa pagina, assegna a ogni landmark un nome univoco con aria-label, per esempio aria-label="Menu principale" o aria-label="Categorie prodotto".
Usa ARIA solo quando i tag nativi non bastano. Gli attributi superflui possono aggiungere rumore e rendere la navigazione meno chiara per chi usa tecnologie assistive.
Come evito landmark duplicati tra menu desktop e mobile?
Mantieni nel DOM una sola versione della navigazione alla volta e gestiscine la visualizzazione con CSS. Evita di duplicare il tag nav nello stesso contesto.
Se entrambi i menu sono presenti nel markup, nascondi quello non attivo agli screen reader con aria-hidden="true" oppure rimuovilo dinamicamente. Attenzione: aria-hidden non impedisce di raggiungere i link con la tastiera; anche questo accesso va disattivato per il menu nascosto.
Usa etichette diverse tramite aria-label per distinguere chiaramente le aree di navigazione.
I landmark sostituiscono il link «Salta al contenuto»?
No, i landmark HTML5 non sostituiscono il link «Salta al contenuto». Tag semantici come main, nav e footer offrono punti di riferimento a chi usa uno screen reader. Il link, però, resta fondamentale per chi naviga con la tastiera: consente di saltare menu ripetitivi e blocchi di navigazione, riducendo il numero di pressioni del tasto Tab per raggiungere il contenuto principale.
