Jump to main content

Accessible Landmarks

  • Published:
  • Category: accessibility

Landmarks can be useful to screen reader users as they can be used to help orient a user to, and easily navigate, an appropriately structured web page or application screen.

Certain elements introduced in the HTML5 specification, such as, but not limited to, header, aside, navigation and main, natively convey special landmark roles to modern browsers. Landmarks can also be defined by the use of ARIA roles, to overwrite a native or custom element’s semantics (or lack there of). There are some landmarks that can only be defined with the use of an ARIA role.

Sighted keyboard users can also benefit from landmarks, via the use of a landmark browser plug-in, allowing them 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 content.

The 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 can refer to recognizable areas of a page or application. Each landmark sets user expectations for the type, and importance, of content they should 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 users 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 Safari, will infer a role="contentinfo" the footer element that is most closely 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 users 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 instead utilize an aria-label to provide a form with an accessible name. 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 search ARIA role that can be used to better surface these types forms to users.


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 the definition of the word and purpose of the element, and could be confusing to users attempting to quickly find the primary content of a page.

For instance:

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

<main hidden>
  <h1>This main is hidden</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 keyboard users, allowing them to bypass recurring global content, such as banner and navigation landmarks.

The HTML nav element natively has a set role of navigation, 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 to convey 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, content should fit within existing landmarks. But there may be times where that is not possible, or that an area of content is deemed important enough to surface to users for quick access. The region landmark provides a generic landmark that can be appropriately labeled (ideally by aria-labelledby, or by aria-label) to allow users to quickly access.

The use of regions should be limited, as too many landmarks can dilute their usefulness in quickly navigating to important points of a page. If many regions existing in a single page, then the page’s structure should be reexamined. Would these regions be better served as <section>s or <article>s with appropriate heading hierarchy instead?

There is no HTML element that natively conveys itself as a role="region". However, a section element can become a region if it is provided an accessible name. Again, be careful not to expose more landmarks on a page than necessary.

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") and any necessary links (for instance, a link to advanced search settings) to help users 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 users who many be new to using landmarks to navigate a page.

As an example, adding an aria-label to a navigation element like:

<nav aria-label="primary">

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

In events where there may be separate, document and application roles nested within a DOM, there may be instances of duplicate landmark roles that shouldn’t, otherwise, have multiple instances.

Labeling becomes even more important to differentiate the landmarks nested within different document and application roles from each other.

Outside of screen reader usage, and browser plug-ins, landmarks are not presently navigable. Developers can enable easier access to key landmarks, for keyboard users, 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 useful to navigate past globally available landmarks, like banner and primary navigations, and bring users straight 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 the landmarks & regions of a page in their order of DOM appearance.

A user can go directly to the main landmark of a page with the Q key.

Insert + F3 will open a list of elements, including landmark 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 user to navigate.

Desktop VoiceOver

With VoiceOver on, a user can open the Rotor by pressing CTRL + Option + U, and then using left or right arrows, navigate to the Landmarks menu. Here a user can review all landmarks present on the page, and jump directly to one.

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 or down on a screen to jump between the different landmark regions of the current page.

Note about landmark bugs

At the time of writing this, there are known issues with browsers not surfacing native form elements as landmarks. Safari and VoiceOver on macOS High Sierra also do not recognize a footer as a contentinfo landmark, even when 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 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 also included articles when navigating by regions, but JAWS 2018 no longer does so. However, JAWS 2018 will soon allow navigation of article elements via the use of 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 an macOS or 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.

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.