Landmark Navigation (ARIA Landmarks)

Landmarks divide a web page into meaningful regions that screen-reader users can navigate between directly. They make page structure easier to understand and reduce the need to traverse every element sequentially.

Landmark navigation lets assistive-technology users move among major page regions, such as navigation, main content, search, and complementary content. Native HTML elements are usually the preferred way to create these regions because they provide semantics without requiring ARIA.

Common landmark elements include `header`, `nav`, `main`, `aside`, and `footer`, while `form` and `section` can become landmarks in specific circumstances. An element with `role="region"` can also expose a named region when a generic section needs to be independently discoverable.

Landmarks should describe meaningful page structure rather than every visual container. A page should normally have one primary `main` landmark, and repeated landmarks such as `nav` or `region` may need accessible names so users can distinguish them.

Accessible names are especially important when the page contains multiple landmarks of the same type. For example, two navigation areas can use `aria-label="Primary"` and `aria-label="Footer"` so a screen-reader user can tell them apart.

Use semantic HTML first and add ARIA only when native semantics do not adequately express the intended structure. Landmark navigation complements, rather than replaces, good heading structure, keyboard accessibility, and meaningful link text.

Key points

• Prefer semantic HTML landmarks such as `main`, `nav`, `aside`, and `header`.
• Use accessible names to distinguish multiple landmarks of the same type.
• Keep landmarks limited to meaningful, navigable page regions.
• A typical page should expose a clear primary `main` landmark.
• Landmarks help screen-reader users navigate by region instead of reading the entire page sequentially.

Interview questions

What is landmark navigation and why is it useful?

Landmark navigation lets screen-reader users move directly between important regions of a page. Examples include the main content, navigation, complementary content, and footer. This avoids requiring users to read through unrelated content to reach a particular area. Good landmark structure also communicates the overall organization of the page to assistive technology.

Which HTML elements commonly create landmarks?

Common native landmarks include `main`, `nav`, `aside`, `header`, and `footer`. A `form` can also expose a form landmark when it has an accessible name, and a suitably named `section` can expose a region landmark. Native elements are generally preferable to manually assigning ARIA roles because their semantics are built into HTML.

Why might you add an accessible name to a landmark?

An accessible name helps users distinguish landmarks when there are multiple regions with the same role or when the purpose is not otherwise clear. For example, two `nav` elements can be labeled `Primary` and `Footer`. This makes the landmark list more useful to screen-reader users. The name should describe the purpose of the region rather than merely repeat its role.

Would you put `role="region"` on every major `<div>`?

No. Landmarks should represent meaningful regions that users may reasonably want to navigate to directly. Making every layout container a landmark creates a noisy and less useful navigation experience. Prefer semantic HTML elements where appropriate and reserve `region` for a genuinely important generic section that needs landmark-level navigation and has an accessible name.

How do landmarks fit into an overall accessible page structure?

Landmarks provide the high-level regions of the page, while headings establish the hierarchy within those regions. They should be designed together so users can first jump to an appropriate region and then navigate its headings or controls. Semantic HTML should provide as much structure as possible, with ARIA used to fill genuine semantic gaps. The result should be tested with keyboard navigation and representative screen readers because the practical experience depends on the complete accessibility tree, not just the source markup.