HTML5 Landmarks Exposed
Please note that there the following information may no longer be accurate if testing with newer versions of browsers and screen readers than the ones noted in this article. For instance, since Safari 13 was released, VoiceOver will now correctly expose a footer a content information landmark.
An updated version of this article with more up to date information will be posted as soon as possible.
Landmarks can serve as important guideposts to a web document. They allow people using screen readers, as well as those with certain browser plug-ins, to be able to quickly navigate to important areas of a page.
I’ve already written quite a bit about what landmarks are, and how to properly code and use them. You can see my post Accessible Landmarks for more information.
But today I’d like to address a common question I see pop up every few months: “do I need to double up ARIA landmark roles with HTML elements that should be exposed as landmarks?”
Or more simply put, do we need to keep doing:
<main role="main">...</main> vs <main>...</main>?
tldr; It depends on your markup!
Let’s test it out
I’ve created a native landmark test page. It consists only of HTML elements that should be exposed as landmarks without the need for ARIA roles.
That’s not to say there’s no ARIA attributes in the document at all. For instance, elements like <form> and <section> do not get promoted to landmark status unless they have explicitly set accessible names. And one of the easiest ways to do that is to use aria-label or aria-labelledby to set to them.
Note that the following test results are indications if screen reader and browser pairings expose the HTML5 landmarks without the need for ARIA roles. IE11, for instance, does not have full support for exposing landmarks. However, results show screen readers attempted to fill some of these gaps.
It's also important to note that results will vary depending on how your documents are constructed. For example, landmarks may *not* be exposed in IE11 if they have no accessible name.
Testing macOS VoiceOver with Safari and Chrome
Roundup: form and contentinfo landmarks are not exposed to VoiceOver in Webkit or Chromium browsers.
macOS VoiceOver support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| Safari 12.1.1 | Pass | Pass | Pass | Fail | Pass | Pass | Fail |
| Chrome 75 | Pass | Pass | Pass | Fail | Pass | Pass | Fail |
| Edge 77 Canary | Pass | Pass | Pass | Fail | Pass | Pass | Fail |
Testing iOS VoiceOver with Safari
Roundup: form is not exposed as a landmark. contentinfo is exposed, but as a “footer”. article is exposed as a landmark even though articles are not landmarks.
iOS VoiceOver support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| Safari | Pass | Pass | Pass | Fail | Pass | Pass | Exposed as "footer" |
Testing JAWS 2018 and 2019 with IE11, Edge, Firefox and Chrome
Roundup: Firefox and Edge each fully expose native landmarks. Edge doesn’t always announce a landmark’s role when entering the region, however every region is navigated to when using the R key.
IE11 and Chrome do not expose the form landmark.
JAWS 2018 and 2019 fill in the gaps and expose all other native HTML landmarks without need for ARIA roles with IE11. That said, IE11 will not announce the landmark’s role if navigating into a landmark by the Tab key. The roles will be exposed by other navigation methods.
Navigating using virtual cursor to reach various landmarks, JAWS may not announce the landmark’s role.
JAWS support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| IE11 | Pass (with exception) | Pass | Pass | Fail | Pass | Pass (with exception) | Pass |
| Edge (pre-Chromium) | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
| Edge 77 (dev) | Pass | Pass | Pass | Fail | Pass | Pass | Pass |
| Firefox 66.0.2 | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
| Chrome 75 | Pass | Pass | Pass | Fail | Pass | Pass | Pass |
Testing NVDA with IE11, Edge, Firefox and Chrome
Roundup: as might be expected IE11 had the most failures, but NVDA is also bridging the gaps and exposing main, banner, navigation and contentinfo anyway. NVDA + Chrome doesn’t expose form. Edge + NVDA doesn’t expose navigation, but also doesn’t ‘announce’ the role of any landmark. Firefox has no failures.
NVDA support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| IE11 | Pass | Pass | Pass | Fail | Fail | Fail | Pass |
| Edge (pre-Chromium) | Pass | Fail | Pass | Pass | Pass | Pass | Pass |
| Firefox 66.0.2 | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
| Chrome 73 | Pass | Pass | Pass | Fail | Pass | Pass | Pass |
Testing Narrator with Edge
Roundup: Narrator and Edge were able to access every landmark in the document when navigating by landmarks: D.
Edge & Narrator support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| Edge (pre-Chromium) | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
Testing TalkBack with Firefox and Chrome
Roundup: while landmarks are exposed to TalkBack with Firefox, there is no role announcement made when navigating to a landmark with TalkBack. Chrome + TalkBack correctly announces role names when navigated to.
Neither Chrome or Firefox expose form landmarks to TalkBack. Firefox does expose contentinfo while Chrome does not. Chrome exposes regions while Firefox does not. And Chrome exposes articles as landmarks, even though they are not.
Android TalkBack support table
| Banner | Navigation | Main | Form | Region | Complementary | Content Info | |
|---|---|---|---|---|---|---|---|
| Firefox 65.0.1 | Pass | Pass | Pass | Fail | Fail | Pass | Pass |
| Chrome 72 | Pass | Pass | Pass | Fail | Pass | Pass | Fail |
Wrapping up
As far as banner, navigation and main landmarks are concerned, outside of a single navigation failure with Edge + NVDA, these landmarks are exposed consistently and you may be able to safely ignore providing them roles.
Content Info landmarks still have some issues with Webkit based browsers on macOS. With regions having a couple of instances of failures (TalkBack + Firefox and IE11 + NVDA).
Largely though, form landmarks are the least supported. But to be honest, it’s arguably the least important landmark since there’s plenty of ways for screen readers to quickly find form elements in a document.
Final note
You should always test yourself. These results are a snapshot in time with a pretty simple test case. While we can all hope that everything revealed here will hold true to more intricate document structures and as browser and screen readers continue to update, it is important to reverify results.