When a sighted person visits a page on the GOV.UK website, they can take it in at a glance. They can quickly identify the header and footer, the main content area and navigation, and other things like a search. Someone who is blind and who uses a screen reader cannot do this, but a feature of the GOV.UK website provides a practical alternative.
Every page on the GOV.UK website includes landmarks. Like landmarks on a map, landmarks on web pages are recogniseable features used for navigation. The landmarks on GOV.UK match the visible features of each page - the header (banner), main content area, navigation, footer (content info) and search area.
How does this help screen reader users?
Screen readers recognise these landmarks and provide shortcut keys for finding them. In this video a screen reader user is moving between landmarks on the GOV.UK homepage. As the screen reader moves to each landmark it announces which bit of the page it has reached.
The transcript for the video is:
"Banner"
"Main region"
"Search region"
You can find the keyboard shortcuts for landmarks in different screen readers in this article on basic screen reader commands for accessibility testing.
How are landmarks created?
You can use standard HTML5 elements to provide some landmarks. The <header>, <main>, <nav>, <footer>, and <aside> elements all provide landmarks for screen readers by default.
You can also use the ARIA (Accessible Rich Internet Applications) role attribute to provide landmarks. This is useful for two reasons:
- You can provide a landmark for the search area (which doesn’t have an equivalent HTML5 element)
- You can make landmarks more backwards compatible for older browsers and screen readers
We know that some people use the GOV.UK website with older browsers and screen readers, so we use both the HTML5 elements and ARIA roles to make sure the landmarks are available to as many people as possible. A good example is Internet Explorer 11, which does not have accessibility support for the HTML5 elements used to provide landmarks, but which does support the equivalent ARIA roles.
What does the code look like?
A simple example might look like this:
<body>
<header role="banner">
// header content here
<div role="search">
// Search here
</div>
</header>
<main role="main">
<nav role="navigation">
// Navigation links here
</nav>
// Main content here
<aside role="complementary">
// Complementary content here
</aside>
</main>
<footer role="contentinfo">
// Footer content here
</footer>
</body>
Note that each of the HTML5 elements also has the corresponding ARIA role applied. The exception is the <div> containing the search, which only has the ARIA role because there is no corresponding HTML5 element.
Follow @LeonieWatson on Twitter and don't forget to sign up for email alerts.
6 comments
Comment by Šime Vidas posted on
Would you recommend labeling landmarks with the aria-label attribute? For instance, this very page has 3 header elements; how does a screen reader user differentiate between them when moving between landmarks?
Comment by Leonie Watson posted on
It can help to use aria-label to provide more information, yes. This article was written before HTML5 support was as widespread, but it explains how to use aria-label to do this:
http://tink.uk/enhancing-aria-landmarks-with-aria-labelledby/
That said, the header and footer elements are exceptions to the rule. These elements should only be exposed to screen readers when they are children of the body element. In other words screen readers should not be aware of multiple headers/footers on a page - so providing extended labels is not necessary.
Comment by Nic posted on
Hi Leonie,
Thanks for all this great work. I have however not seen a situation where the header and footer elements are used outside of the banner and footer areas and screen readers, e.g., JAWS 18, NVDA latest, Narrator with Edge have failed not to map them to aria banner and content information respectively. I have tried to put a few codes down based on html5 specs and recommendations but have not been successful. Would you by any chance have sample codes to demonstrate success for this? BTW, this happens in all browsers, e.g. IE11, FF 59 / latest, and Microsoft Edge.
Your help is greatly appreciated.
Nic
Comment by Léonie Watson posted on
Thanks Nic.
The mapping for header and footer has changed recently. Now if the header or footer is a child of either the article or section elements, it is not exposed by the browser. If those elements are children of other elements, they are exposed as banner and contentinfo respectively.
A quick check this morning shows that Firefox, Chrome and Safari honour this behaviour. IE does not support header and footer elements through its accessibility API anyway, but I wasn't able to check Edge.
It's worth noting that just because a browser does something, a screen reader does not have to follow suit. Jaws in particular is known for doing it's own thing - so in Firefox for example it still announces the header and footer elements when they are children of both article and footer.
Comment by Nic posted on
Thanks Leonie.
After reading your comments, I went and wrote down a few lines of codes and here is what I found:
with IE11:
Wrapping header, nav elements and footer inside section element in the main content still maps to banner, navigation and content information region respectively whether using JAWS18 or NVDA.
with FF52 and Chrome
Wrapping header element and footer inside section element in the main content does not map to banner using NVDA, but still maps to banner and content information when using JAWS18.
however, wrapping nav element inside section element in the main content still maps to navigation region with both JAWS18 and NVDA
With Edge and Narrator:
Wrapping header, footer or nav elements inside section element in the main content does not map to banner, content information or navigation landmarks
Observation: So far, Narrator with Edge seem to conform best to mapping scheme.
Conclusions:
1. JAWS 18, whether in IE11, FF52 or chrome does not recognize the correct html5 header and footer elements mapping scheme.
2. As you pointed out, IE11 does not conform to the mapping scheme all together.
3. The Nav element, whether wrapped inside section element or not still maps to navigation region landmark for IE11, FF52 and Chrome using JAWS or NVDA. Only Narrator with Edge does not map to navigation region when nav element is wrapped inside section element.
Comment by Chris Moore posted on
Do you think we should have an ARIA landmark for the search region of the banner?
JAWS 15 introduced the quick key (Q) to jump straight to the main content region of a page, I would love to see other screen readers adopt a similar shortcut.