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
Tested with macOS 10.14.5
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
Tested with iOS 12.3.1
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
Tested with JAWS 2018 and 2019
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
Tested with NVDA 2018.4.1 and 2019.1
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
Tested with Narrator on Windows 10
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
Tested with Android 8.1 and TalkBack 7.2
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.