Landmark roles are important for screen reader users, because they can help them directly find important sections of a web page. By important sections I’m referring to navigation areas, main content, forms, etc. This post looks at how landmark roles are defined, and how you can extend their use with labels to give users the best experience.
What are landmark roles?
Landmark roles are demarcated regions within web pages, and are primarily for screen reader users – both on desktop and mobile devices. They identify areas of the page – for instance: the banner, navigation areas, and the main content of the page. Landmark roles are implemented by using the
role attribute – attached to
<div>s or other suitable containing elements.
<div role="banner"> – which identifies the ‘banner’ of the web page.
There is a strict set of landmarks you can choose from when marking up a page. These are the ones recognised by browsers and screen readers. Unfortunately, you can’t just allocate your own role names using the
role attribute. But as we’ll see later, it’s possible to further label the landmark roles if (say) there is more than one navigation area on a page.
This table shows the available landmark roles.
|Landmark role||Used for|
|banner||Typically the area at the top of pages with logos, site name, etc.|
|navigation||Contains a menu or other list of links.|
|main||Reserved for the main content of the page.|
|complementary||Complementary information. Often used for sidebars.|
|contentinfo||Information about the page or site. This might be contact information and a copyright statement. Typically used for page footers.|
|form||An online form.|
|application||A special instance of web application that has its own interface.|
|region||A discrete area of interest within a page|
What about HTML5 elements?
There’s an obvious overlap between some of these roles and the newer HTML5 page structure elements.
This table shows the ones where there is a direct correlation.
|HTML5 element||Default landmark role|
|<header>||banner (see note 1 below)|
|<footer>||contentinfo (see note 2 below)|
- Note 1 – since multiple
<header>elements are permitted in a page, only a
<header>element in the context of the
<body>element will be equivalent to
- Note 2 – since multiple
<footer>elements are permitted in a page, only a
<footer>element in the context of the
<body>element will be equivalent to
Most screen readers and browsers do support the HTML5 elements now. However, there is still a chance that certain combinations of browser and screen reader do not support or recognise the HTML5 elements.
So, whilst it is possible to use HTML5 elements like
<nav> instead of the corresponding landmark role, the current recommendation is to double up and use both to give the best accessibility.
But watch out for semantic confusion
One of the things I teach on my accessibility training courses is that semantic HTML is one of the key foundations of web accessibility.
But it’s important to note that adding a role attribute to an element will change its semantic meaning, so we must be careful not to override semantics where they are important.
Take this example:
<ul> <li><a href="menu1.html">Menu Item 1</a></li> ... </ul>
Here, a navigation menu has been placed in an unordered list, which is a sensible construct for a list of navigation items. Screen readers will inform users that the navigation links are in a list.
So, to add a landmark it might be tempting to use this markup:
<ul role="navigation"> <li><a href="menu1.html">Menu Item 1</a></li> ...
<ul> element has been given a role of
navigation. But this actually overrides the semantic meaning of the list – potentially affecting the way screen readers will communicate the page structure.
So, a much better approach would be to separate the two definitions:
<div role="navigation"> <ul> <li><a href="menu1.html">Menu Item 1</a></li> ...
Now the navigation area of the page is identified, without affecting the announcement that the navigation items are in a list.
How screen readers interpret landmark roles
All major desktop (NVDA, JAWS, Voiceover on OSX) and mobile screen readers (Talkback, Voiceover on iOS) support landmark roles in current versions.
When moving around the page using arrow keys or tab keys, if the user crosses a landmark boundary, the screen reader usually announces the new landmark area. Additionally, desktop screen reader users have keystrokes available which can move them to the next landmark, previous landmark, or even directly to specific landmarks within a page.
NVDA (for Windows) shows a dialogue box which enables users to hear which landmarks are available, and use a keystroke to move to the selected one.
But sometimes this is not enough
Whilst the simple landmark structure may work for less complex web pages and templates, many sites feature multiple forms, asides and/or navigation areas. Using just the landmarks on their own is not enough to really help the screen reader user.
Look at these examples (once again from NVDA):
This first example is from a WordPress website using one of the freely available themes. Note that there are two ‘navigation areas’, and three ‘complementary areas’.
The ‘navigation’ areas are substantially the same main navigation in this page – although a screen reader user may not know that without visiting both areas.
The ‘complementary’ areas correspond with the use of WordPress widgets in a side bar – one ‘complementary’ for each widget. But there is nothing available here to indicate each widget’s purpose.
There are a couple of other problems with the landmarks here.
- One of the widgets is actually a Search box, but that is not identified.
- It’s easy to see here is that there is no ‘main’ landmark in the list to indicate the main content of the page.
This second example is from one of the Stack Overflow websites. (Stack Overflow has a network of sites where people post technical questions for others to answer.) Note that there are multiple navigation blocks. These are all in the footer of the site, and although they are all navigation blocks, a screen reader user has no way of differentiating between them.
So how can we fix that?
Well it’s possible to use the
aria-label attribute to help differentiate between the multiple instances of the same landmark. For example:
<nav role="navigation" aria-label="Main navigation">…</nav>
Alternatively, if appropriate, you can use a heading in the area to label the landmark with
aria-labelledby. For example:
<div role="region" aria-labelledby="calc-header"> <h2 id="calc-header">Mortgage calculator</h2> [Content] </div>
Note that the
aria-labelledby attribute refers to the
id attribute of the heading.
Here is an example where this has been done.
Note in this example that there are multiple banners, multiple navigation areas, and multiple regions, but most of the landmark regions have been labelled to clarify what they contain. The BBC News home page is a very complex page with many, many sections. Now, screen reader users can more easily find the section of the page they are interested in.
Any other points?
Whilst using landmark roles properly is a great help to screen reader users, it is sensible not to over-use them. Too many landmarks will cause ‘user fatigue’ and will devalue their use.
Let’s return briefly to the Stack Overflow example from above:
Here, there are multiple navigation areas present in the footer. Even with proper labelling to differentiate them this is probably way too many. An alternate approach would be to label that part of the footer as one ‘secondary’ navigation area. If the individual navigation blocks then had headings, a screen reader user could use those to fine tune their browsing. Alternatively, using labelled regions – as with the BBC News pages – would be a good approach.