So long as they’re used appropriately, landmarks can be a useful structural mechanism to help people who use screen readers orient themselves to important areas of a web page, and help quickly navigate to these areas within a website or application.

Certain elements introduced in the HTML5 specification, such as <header, aside, nav and main, natively convey special landmark roles to modern browsers. Landmarks can also be defined by the use of special ARIA roles, to overwrite a native or custom element’s semantics. There are certain landmarks which require certain conditions to be met for them to be exposed as such, and one landmark that (presently) can only be exposed via an explicit ARIA role.

Sighted individuals using keyboards can also benefit from landmarks, if using a landmark browser plug-in/extension. Such plug-ins allow for people to more easily navigate a page’s main and sectioning elements, rather than having to primarily rely on tab keys, and skip links to navigate sequentially through focusable content.

Types of landmarks

Just like in the real world, where landmark could mean “statue”, “town center”, or “the main entrance to a building”, landmarks on the web refer to recognizable areas of a page or application. Each landmark helps set expectations for the type, and importance, of content that each contain.

An area that primarily contains global, rather than page-specific, information or actionable elements. For example, a website or application’s logo, and primary navigation would be expected child elements of a banner landmark.

Since there is no native “banner element” in HTML, modern browsers are meant to treat the <header>, that is the nearest direct child of the <body> element, as a banner landmark. While there can be multiple <header> elements used within a web document, ideally there should only be a single banner landmark exposed. Instances where multiple banners may be desired would be if there were nested document or application roles within a single view. In such a case, it would be best to ensure each of these were given their own accessible name, as this would allow assistive technologies to jump to each nested banner and have a better idea of which “banner” they had navigated to.

The type of content that goes into “Hero banners”, or “jumbotrons”, as they are referred to by Bootstrap, may seem like content that would go in a banner. This is compounded by the fact that these visually styled “banners” are typically placed at the top of a page. However, unless the hero’s content, or a version of the content, is used across all pages of a site, a hero banner would be better placed within a landmark more specific to the individual document itself.


An area of a page that contains additional information that “complements” the “main” content it is related to. Though complementary, the content it represents should also be understandable on its own.

For instance, a blog article would be contained within the main landmark of a page. There then might be a region of related articles, and/or other blog posts, that follow the article. This information would fit well into a complementary landmark, as none of it is required to understand the primary topic of the page, but serves as additional information to learn more about the topic, or different topics.

If the content has no relevance to the primary content of the page, then it may be better suited to be contained within a different type of landmark.


Another globally repeating landmarkn (like banner) that should contain information about the parent document. Browsers are meant to treat a <footer> element that is scoped to the <body> as an implicit role="contentinfo". <footer> elements which are contained within, say an <article> or <section> element, are not meant to be exposed as contentinfo` landmarks.

Like banner and main, there should be no more than a single instance of a contentinfo role within a page, unless there are nested document or application roles within that page. In such a scenario, an aria-label should be provided to the contentinfo to better distinguish each instance.


Forms are meant to be conveyed as a landmark to assistive technologies so long as they have been given an accessible name. Otherwise, while they may still expose a ‘form’ role, they are not meant to be treated as landmarks.

Exposing a form as a landmark may be most useful if there are multiple forms on a single page. Ideally, in such a situation they would also each have their own visible heading to help further indicate the purpose of the form. The heading can then be used to provide an accessible name to the form by use of an aria-labelledby attribute.

If providing a visible heading would absolutely ruin the visual design of the web page (it wouldn’t), then alternate methods can be used to provide an accessible name to the <form>. For instance, using an aria-label on the <form> element, or still using an aria-labelledby to point to the id of hidden text. Unique, succinct names like “contact”, “newsletter”, or “login” will help quickly convey the purpose of the form.

While <form>s may be used to contain website or application search components, there is a specific search role that can be used to better surface these specific types of forms.


The main landmark is meant to designate the primary content of a page. In modern browsers, a main landmark is natively conveyed by use of the <main> HTML element. Alternatively, if the <main> element can’t be used, the ARIA role="main" can be used instead.

Ideally there would only be a single main landmark exposed in an interface at a time. Having multiple “mains” would be contradictory to purpose of the element, and would make it harder than necessary for people trying to quickly find the primary content of a page.

For example, the following snippet is valid because one of the main elements is hidden:

  <h1>The currently active main!</h1>

<main hidden>
  <h1>Another instance of primary content</h1>
    If this content is revealed, the previous 
    main would need to be set to hidden.

As a main landmark represents the primary content of a page, it is the most important destination for any skip links that would be available for sighted individuals primarily navigating by keyboard. Such a skip link would allow these people to bypass recurring global content, such as banner and navigation landmarks, which together often contain multiple keyboard focusable elements.

The HTML <nav element natively has a role of navigation.

navigation landmarks should be used as necessary within a document, and as with other landmarks where multiples could appear in a document at once, they should be given accessible names to distinguish one from another.

For instance, a single document might have a global navigation (primary), a navigation specifically for related pages to a particular document (secondary), or a navigation that conveys your current location in a series of related pages (breadcrumb or pagination).

navigation landmarks are typically expected to contain navigational elements, like links, but may contain other elements to assist in the navigation of a site or application.

For instance, a navigation on small screen devices may initially contain only a single toggle button (or in this case, a ‘disclosure widget’(. That button would reveal (and also re-hide) additional links and other navigational elements, when activated. See also Landmark Discoverability.


Ideally, most content would neatly fit under other existing landmarks. However, there may be times when that may not be possible, or certain content is deemed important enough to surface to assistive technologies for quick access.

There is no HTML element that natively conveys itself as a region, that is, without some assistance. A <section> element can become a region landmark if it is provided an accessible name (for instance, by giving it an aria-label or aria-labelledby attribute). Or, an element can be modified into a region via ARIA’s role="region" (which would also require an accessible name to be exposed).

For instance:

    I have no name, therefore I am not exposed as a region landmark.
  <div role=region>
    I also have no name, so I too am not supposed to be exposed
    as a region landmark.
  <section aria-label=heyo>
    Sup? I'm a region. Fancy that.

The use of region landmarks should be limited, as too many landmarks can dilute their usefulness in quickly navigating to important areas of a page. If you find there are many landmarks, especially generic regions existing in a single page, then the page’s structure should be re-examined.

As mentioned, a search landmark is a specific type of form that is given a unique role to allow for easier discoverability from other general forms.

There is presently no native search element (not to be confused with input type="search), but a proposal has been put forth to include on in HTML. For now, an ARIA role="search" will need to expose this landmark as necessary.

A search landmark should contain form controls (such as an input type="search" or other controls to help people define their search query) and any other applicable content to help people easily search a website or application.

A search landmark might be declared on an existing <form> element, if that element performs traditional submission of form data. Or, it could go on a wrapping <div> if the search form is powered soley via JavaScript.

Multiple landmark roles of the same type

The more landmarks one has in a document, especially landmarks of the same type, the less meaningful they become in their ability to outline unique regions of a page.
By default, a landmark is merely exposed as its role. For instance: navigation, banner and main.

A unique label can help distinguish multiple landmarks of the same type from each other, and help provide context to people who many be new to using landmarks to navigate a page.

As an example, adding an aria-label to navigation elements like so:

<nav aria-label="primary">...</nav>
<nav aria-label="secondary">...</nav>

will announce the landmarks as “primary” or “secondary” navigations. Additionally it will be revealed as “[name] navigation” if someone opens a listing of all landmarks present in the current document. It is unnecessary to include the name of the role in the aria-label, as the role will be announced on its own. Rather, including the type of the role in the name of the element will result in redundant content being announced, such as “primary navigation, navigation”. And that’s just silly.

In the event of nested document and application roles within a single page, there may be instances of duplicate landmark roles that shouldn’t, otherwise, have multiple instances.

Labeling can then be even more important to differentiate these nested landmarks from each other.

If not using a screen readers, or have a specific browser plug-ins, landmarks are not presently navigable. Developers can enable easier access to key landmarks, with keyboard navigation, by providing “skip links”. Skip links, typically appear at the top of a page and are in-page links that point to the ID of an element in the current document.

Skip links are most often used to navigate past globally available landmarks, like the site’s banner and primary navigation(s), and bring keyboard focus directly to the main content of a page.

Using screen readers to navigate landmarks

If using a screen reader to navigate the web, the following hot keys will help you navigate a document by its available landmarks.


Pressing the R key will move JAWS focus to contents of the landmarks & regions of a page in the order of their appearance in the DOM. Control + Insert + R will open a listing of all landmarks and regions on the page, listing them by landmark type, and with their accessible name, if they have one.

JAWS can jump directly to the main landmark of a page with the Q key.

Insert + F3 will open a list of elements, including landmarks and regions, in the current document.


Navigate landmarks with NVDA by pressing the D key. Insert + F7 will open a list of links, headings and landmarks for a quick navigation.

Desktop VoiceOver

With VoiceOver on, the Rotor menu can be opened by pressing CTRL + Option + U, and then using left or right arrows, navigate to the Landmarks menu. Here one can review all landmarks present on the page, and quickly navigate to that content.

FYI: CTRL + Option is typically referred to as the VoiceOver key.

Mobile VoiceOver

With VoiceOver on, place two fingers on the screen of your iPhone or iPad and move them in a clockwise or counterclockwise manner. This should expose the mobile VO rotor, and you can navigate through the different options until hearing “landmarks.” Once landmarks is selected, swipe up (backward) or down (forward) on a screen to jump between the different landmark regions of the current page.


To navigate by landmarks you must open TalkBack’s local context menu. To do this swipe up and then right in one single motion. Then, navigate the listing of options until you hear “landmarks”.

Once selected, navigate sequentially through landmarks by swiping left (backward) or right (forward).

Note about landmark bugs

Support for landmark regions has only gotten better since they were first introduced. However, that doesn’t mean that there may not still be bugs. For instance, it wasn’t until Safari 13 that a <footer> element was exposed as a contentinfo landmark. (Actually, the <address> element used to be exposed as a contentinfo landmark as long ago that element was mapped to this role.)

Additionally, while certain elements like <form>, <section>, and <header> are only meant to be exposed as landmarks under certain conditions - these might not be fully implemented by all browsers. Be sure to check to make sure your content is being exposed correctly, and adjust the markup (roles) as needed to mitigate against such gaps.

application, article and document

To be clear, these roles are not landmarks, though there is literature out there that might suggest otherwise. How these roles were previously implemented and exposed by screen readers likely contributed to some of this confusion. For instance, previous testing with iOS (11 & 12) and VoiceOver, content with an article role, whether that be via the native article element, or ARIA role, would be included when navigating by landmarks.

As another example, JAWS 18 included articles when navigating by regions, but JAWS 2018+ no longer does so. Instead, JAWS 2018+ allows navigation of <article elements by pressing the O key, which was previously used to navigate between <objects.

A landmark test page

Want a bit more information on landmarks and test out how they are exposed in different browsers and screen reader combos? I’ve created a quick landmark test page and GitHub repo for you to check out.