A lot has been written about how to technically implement WAI ARIA Landmarks but from a human perspective just how usable are they for screen reader users?
Landmarks are a way of providing semantic markup to areas of a page that otherwise are not signposted for screen reader users. By carving up your page into areas marked up as
search you provide an outline that screen reader users can navigate using a keyboard shortcut. Done well this means users can navigate between content areas such as the main content, navigation and footer, in a similar way that sighted user rely on layout to inform the eye.
While the use of Landmarks becomes the norm I’m not convinced that we are really thinking about the user when we add them. Here are few thoughts based on some of the implementations I’ve seen on the web recently.
There is a clear relationship between Landmarks and what follows immediately in the content order. Looking at
role="main" for example you’d expect to find an H1 close by i.e. where the main content starts you’d expect the main heading to immediately follow. If navigating Landmarks with a screen reader you’ll use a keyboard shortcut to move sequentially though Landmarks in a page. Once you arrive at your chosen Landmark you then ARROW down to listen to what follows next in the content order. Having an H1 follow immediately makes perfect sense.
This becomes even more important on mobile, specifically in Mobile Safari. Currently the name of the Landmark is not announced by Voiceover, i.e. ‘Landmark main’. Instead the Landmark is announced as ‘Landmark’ together with what follows it in the content order so always ensure what follows is logical: an H1 follows role=”main”, a logo or the company name follows role=”banner”, an H2 follows role=”article” in a blog post and so on.
Some Landmarks can be repeated in a page. For example you may have
role="navigation" wrapped around your global navigation and your local navigation. This is good and correct but a screen reader user won’t necessarily know which navigation is which. A simple fix is to label the Landmark using
aria-label. The new BBC Channel pages do just this:
The output using Jaws 12 with IE9 and Firefox 12 is “Channels navigation Landmark” while the output for Voiceover with Mobile Safari is “Channels, Landmark start” which is really useful information. Don’t go overboard however, remember that the contents of the Landmark can be uniquely identified by the first item in the content order so don’t assume all Landmarks need to be labelled. You really want to avoid verbosity where possible.
Speaking of which…
One complaint I hear from users is that there’s too many Landmarks on a page making them verbose with signposting which drowns out content. In particular the screen reader NVDA can be very chatty. Landmarks are there to plug the gaps that other semantics can’t reach so don’t feel you have to compartmentalise every area of content into a Landmark – especially if it’s already well represented semantically. It may be there is content that doesn’t naturally sit in a Landmark and if that’s the case leave it alone. Chances are it will fall somewhere within the main Landmark or be taken care of within the heading structure.
Search is an interesting one. Occasionally on pages you see a simple search box with an explicit label of search, placement text of ‘Search the site’ presented in a search Landmark. While not incorrect I find this a little noisy as when a user moves focus to the search field you hear “Landmark search, search, search this site”. On the flipside however it does mean there are three means available for the screen reader user to navigate to search: via Landmark shortcut, forms shortcuts and find. You should always have an explicit label but personally I can’t help thinking that role=”search’ is more appropriate on pages with advanced search option such as the one shown below from the RNIB website.
Another verbosity issue is when role=”navigation” is over used on a page. It’s perfectly legal to use multiple navigation roles but personally I think if you overdo it you are going to undermine their use entirely which for me is to easily signpost main and local navigation. For example blog posts may each have a role of navigation around the category links which could mean a page with multiple posts has a huge number of navigation Landmarks.
Equally don’t put footer links into a navigation role if they are already neatly housed in a contentinfo role. This only duplicates semantics and introduces noise.
What’s usable on desktop may be less so on mobile and vice versa so if building a responsive site you need to think about how the structure of a page collapses down on mobile or, better yet, think mobile first. For example you may have 10 links in your main navigation on desktop that get packed away into a drop down menu on mobile. This being the case mobile could engineer itself out of the need for a navigation Landmark simply because there is only one item there. It adds a level of verbosity that isn’t helpful much in the same way that skip links add noise on touch screens.
Like most things in RWD there are caveats however. In iOS, if menu items hidden visually in a drop down are available off screen, they will still be picked up by Voiceover in which case the need to role=”navigation” still stands. If the menu link is just that, a single link or an anchored link to further links at the foot of the page, then role=”navigation” is probably unnecessary.
The above are just a few thoughts and there is clearly much more user research that needs to be done to understand how to make Landmarks usable across devices. So when adding Landmarks keep the following in mind:
- Ensure logical content follows immediately after a Landmark
- Label repeated Landmarks where necessary using
- Only use Landmarks to plug semantic gaps, try not to duplicate structure or add noise
- Consider removing Landmarks on mobile where content is significantly reduced