A page has three <nav> elements — the primary menu, a breadcrumb trail, and an on-page table of contents. How do you make them distinguishable in a screen reader's landmark list?

## How a landmark is announced Assistive technology presents a landmark as **role + accessible name**. With no name, all a user hears is the role. One `<nav>` on a page is fine that way — "navigation" is unambiguous. Three are not: the rotor shows three identical entries and the user has to enter each one and read around to work out which is which, which is exactly the linear reading landmarks exist to avoid. ## Naming them ```html <nav aria-label="Primary">…site menu…</nav> <nav aria-label="Breadcrumb"> <ol>…</ol> </nav> <nav aria-labelledby="toc-h"> <h2 id="toc-h">On this page</h2> <ol>…</ol> </nav> ``` The rotor now reads "Primary navigation", "Breadcrumb navigation", "On this page navigation" — three distinct destinations. Prefer `aria-labelledby` whenever the region already has visible text that names it. It keeps one string in the DOM instead of two, so the label cannot drift out of sync with what is on screen, and it is translated along with the rest of the page by machine translation that would skip an attribute. Use `aria-label` when there is no visible heading to point at, as with the primary menu and the breadcrumb trail above. ## The redundancy trap Because the role is announced automatically, the label must not repeat it. `aria-label="Primary navigation"` on a `<nav>` produces "primary navigation navigation". Write `aria-label="Primary"`. The same applies to `<aside aria-label="Complementary sidebar">` and to `<section aria-label="Region: filters">`. The name is the *distinguisher*, not a description of the element type. ## Which landmarks actually need names Only the ones that repeat, plus the ones that do not exist without a name at all: - **`<nav>`** — name every one when there is more than one. A lone nav needs nothing. - **`<section>`** — not exposed as a `region` landmark until it has an accessible name. Unnamed, it maps to generic and simply is not in the list. - **`<form>`** — same conditional rule: it becomes the `form` landmark only once named. - **`<aside>`** — name them when a page has several. - **`<main>`** — never. There is one, and its role already says what it is. - **`<header>`/`<footer>` at page level** — normally not; a page should have one banner and one contentinfo. ## Techniques that do not work `id` and `class` do not reach assistive technology at all; they are selector hooks. Order in the DOM is not announced. A `title` attribute is a weak fallback and unreliable in practice — do not rely on it for landmark naming. And wrapping each nav in a labelled `<div>` accomplishes nothing, since a `<div>` is generic no matter what attributes it carries. ## Do not over-name Naming has a cost: every named landmark is another entry the user must skim. Adding `aria-label` to a dozen sections turns a five-item map into a directory. Landmarks are meant to be the coarse skeleton of a page — a couple of navs, main, a complementary region or two, the masthead and the footer. If a name is needed only because there are eight regions where two would do, the fix is fewer landmarks, not better labels. ## How to verify Read the landmark list rather than the markup. Browser devtools expose each node's computed role and accessible name, and screen readers offer a landmark rotor or menu that shows exactly what the user will hear. That is also how you catch the two silent failures in this area: a `<section>` you thought was a region but never named, and a label that duplicates the role.