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.
Or more simply put, do we need to keep doing:
<main role="main">...</main> vs
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
<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-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
contentinfo landmarks are not exposed to VoiceOver in Webkit or Chromium browsers.
macOS VoiceOver support table
|Edge 77 Canary||Pass||Pass||Pass||Fail||Pass||Pass||Fail|
Testing iOS VoiceOver with Safari
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
|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
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
|IE11||Pass (with exception)||Pass||Pass||Fail||Pass||Pass (with exception)||Pass|
|Edge 77 (dev)||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
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
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
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
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.
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.