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
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
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
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
elements which are contained within, say an <article>
element, are not meant to be exposed as contentinfo` landmarks.
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 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
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.
<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.
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>
<h1>Another instance of primary content</h1>
If this content is revealed, the previous
main would need to be set to hidden.
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
navigation landmarks, which together often contain multiple keyboard focusable elements.
<nav element natively has a role of
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-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).
I have no name, therefore I am not exposed as a region landmark.
I also have no name, so I too am not supposed to be exposed
as a region landmark.
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.
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.
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
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 navigation elements like so:
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
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.
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 (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
<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.
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
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.