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
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
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
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
application roles within a single view. As this would allow assistive technologies to jump to each nested
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
footer element that is most closely scoped to the
main, there should be no more than a single instance of a
contentinfo role within a page, unless there are nested
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.
<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.
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:
<main> <h1>The currently active main!</h1> <p>...</p> </main> <main hidden> <h1>Another instance of primary content</h1> <p> If this content is revealed, the previous main should be set to hidden. </p> </main>
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
navigation landmarks, which together often contain multiple keyboard focusable elements.
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-labelledby attribute). Or, an element can be modified into a region via ARIA’s
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.
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:
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"> ... </nav>
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
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.
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.
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. 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
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.
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
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-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.
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
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.