Landmarks can be quite useful to people who use screen readers, as they can be used to help orient someone to, and help navigate, a properly structured 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 that can only be defined by the use of an 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 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 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 page, 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. As this would allow assistive technologies to jump to each nested banner.

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 document itself.


An area of a page that contains secondary information. The complementary information should be related to the primary focus of the document, but should 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.


An informative landmark that should contain information about the parent document. Modern browsers, except for Webkit-based browsers, will infer a role="contentinfo" from a footer element that is scoped to the body element.

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 a vital part of websites and applications and as such, they are meant to be conveyed as a landmark to assistive technologies.

When there are multiple form landmarks on a single page, they should each have their own visible heading. This heading can then be used to provide an accessible name to the form by use of aria-labelledby, which would then better expose the purpose of the form for people navigating by landmarks.

If a visible heading would just absolutely ruin the design of a form or the page it’s on (btw, 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 using an aria-labelledby to point to the id of hidden text. Unique, succinct labels like “contact”, “newsletter”, or “login” can easily convey the purpose of a form.

While <form>s are used to wrap website or application search components, there is a specific ARIA search role that can be used to better surface these types forms to people.


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, or you need to support a legacy browser that doesn’t have full implementation of the native element, the ARIA role="main" can be used to force the landmark superclass.

Ideally there should only be a single, active, main element on a page at a time. Having multiple “mains” would be contradictory to purpose of the element, and could be confusing to 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 should be set to hidden.

As a main 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, which is conveyed in all modern browsers.

navigation landmarks should be used as necessary within a document, and as with other multiple use landmarks, 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. But that toggle button would reveal additional links and other navigational elements, when activated.


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".

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 reexamined.

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

Since there is no native search element (not to be confused with input type="search), an ARIA role="search" will need to be set to the wrapping form to appropriately convey this landmark.

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.

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 a navigation element like so:

<nav aria-label="primary">

will announce the landmark as “primary navigation”, when a screen reader navigates to it. Additionally it will be revealed as “primary navigation” if someone opens a listing of all landmarks present in the current document.

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.

A screen reader 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.

TalkBack 7.2

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

At the time of writing this, there are known issues with browsers not surfacing native form elements as landmarks. Additionally, Safari and Chrome with VoiceOver on macOS High Sierra/Mojave do not recognize a footer as a contentinfo landmark, even if the footer is scoped to the body element.

Most native HTML5 elements expose landmarks appropriately, it never hurts to test in different browser and screen reader combos.

While it is typically not advised to use a redundant ARIA role on an element that should natively convey that role, such as <main role="main">, depending on your own requirements for legacy browser support, and to mitigate bugs, like the ones mentioned here, there may be times where this rule is overlooked to ensure landmarks are exposed as intended.

Note about article elements and roles

Testing with iOS (11 & 12) and VoiceOver, content with an article role, whether that be via the native article element, or ARIA role, will be included when navigating by landmarks.

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.

Desktop VoiceOver will surface articles, but in a separate rotor category than landmarks, and only if an article has been supplied an accessible name (via aria-label or aria-labelledby). Articles are not surfaced in their own rotor menu if using macOS/OSX prior to High Sierra.

Articles are not meant to be considered landmark elements, as they can, and should be, used whenever appropriate within a document.

An article is meant to contain information that has a self contained relationship to other content within a document. Meaning that the contents of an article should be able to be fully understood if it was viewed in the context of a website, or an external content feed.

The use of articles is not problematic if they are used appropriately. However, where content wrapped in articles can diminish their usefulness, and the usefulness of other landmarks in a document, is when they are used in a manner where a list would be a more appropriate semantic structure.


Updated February 13th, 2019: while chatting in the web-a11y Slack channel, @jdanl noticed that the address element was being announced as a contentinfo landmark when testing with VoiceOver.

Looking into this more, it seems this is unique to Webkit/Blink. While the address element is mapped to browser’s accessibility APIs, there’s no MSAA/IA2 values that would directly indicate address would necessarily be a contentinfo landmark. However, if you check out the accessibility inspector in Chrome’s dev tools on macOS or PC, address is given a contentinfo role. Why address gets the contentinfo landmark over the footer element beats me…

Testing Chrome with NVDA and JAWS, each screen reader is ignoring this computed role, and properly announcing a footer scoped to the body as a contentinfo landmark.

screen shot of VoiceOver rotor set to landmarks, showing a content info landmark. It is selected, and the second test, an address element, is highlighted by VoiceOver.
With Chrome on macOS, the VoiceOver rotor indicates a single contentinfo landmark. It correlates to the highlighted "Test 2" element on the page, which the CodePen HTML panel shows is an address element.

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 open source GitHub repo for you to check out.