Usable landmarks across desktop and mobile

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 application, banner, complementary, contentinfo, form, main, navigation and 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.

Content order

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.

Labeling Landmarks

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: aria-label="Channels" role="navigation".

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…

Verbosity

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.

spacer

Multiple options for a global search

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.

Responsive design

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.

Summary

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 aria-label
  • 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

Written by Henny

Accessibility, Mobile Android, iOS, MobA11y, Mobile, WAI ARIA 14 Comments

14 thoughts on “Usable landmarks across desktop and mobile”

  1. Ramya Sethuraman

    Henny, thanks for an excellent post on landmarks. I have a couple of questions on the points you have noted in your post:
    1. Is it ok for a h2 to follow the main content landmark assuming the h1 is used above the navigation landmark region to mark the logo/main heading that appears on every page of the website while the h2 heading marks the heading of every page?

    2. Regarding links placed offscreen and voiceover picking them up on iOS — is this acceptable? For eg: if we enclosed the offscreen links within a role=navigation, can we assume iOS voiceover users will use the rotor to jump to the next landmark and it is ok for these links to get voiceover focus on iOS?

    Thanks!
    Ramya

    Henny Reply:
    September 15th, 2012 at 7:42 am

    Hi Ramya, thanks for the questions!

    1. Personally I’m not a fan of having H1 as the site name as this has nothing to do with the page structure – the unique page heading should be the H1. Having said that many sites structure content this way including many WordPress themes (like this one – which I’m in the process of changing).

    Another thing I’ve noticed is that if H1 is used around the site name then H1 (rather than H2) tends to be replicated around the unique page title therefore giving the page duplicated H1s. WCAG doesn’t explicitly state this is not allowed plus I have heard a few screen reader users say they don’t mind this however I’m not a big fan of this technique. Needless to say the H1 debate has been raging for years!

    2. Whether acceptable or not it’s a reality but I think it’s one that can be easily handled well if you, as the developer, understands that this will happen. I’d say it’s ok but the way to really establish what works is to user test.

  2. Stomme poes

    Regarding headings I’ve run into this problem so many times… current project has headings *in* the navigation so either the levels won’t be in order, or h1’s etc get duplicated. We are hoping the use of landmark roles can help this make more sense, especially when we don’t have the power/ability/permission to change the main navigation structure.

    Henny Reply:
    September 19th, 2012 at 7:57 am

    Hi Stomme, I work on similar projects with similar problems. As you say it quite often comes down to frameworks and how content management systems spit out code so often you’re stuck with it. Using Landmarks to give the headings context is definitely good but we still have to be aware that many users can’t access Landmarks.

    On a positive note I have spoken to some screen reader users who say that as long as some sort of logic is applied and there is a structure that can be understood (all be it a slightly incorrect one) they can generally work it out. Problem is this is mostly more advanced users.

    So until Landmarks are supported across all screen readers and browsers it comes back to trying to get it right the first time as well as ensuring that Landmarks are supplementary to a well structured page.

    Stomme poes Reply:
    September 19th, 2012 at 8:29 am

    Pretty much, yup.

  3. Detlev Fischer

    Hi Henny,
    thanks for this useful article!
    I wonder how you feel about the trade-off between
    (1) Structuring content in a way that users of older browsers and screen readers can navigate it, for example, by using off-screen positioned headings for navigation and content sections
    (2) Using landmarks plus aria-label only to reduce verbosity and redundancy for those users that have full support of landmarks and aria-label
    Currently, the use of landmarks is not yet included as Sufficient Technique in WCAG 2.0 supporting docs (“How to meet WCAG 2.0″). Do you think that accessibility support for landmarks + aria-label is solid enough by now that one can call it sufficient for public web sites (and thereby meet the ‘Bypass bocks” success criterion (2.4.1) by *just* using landmarks?

    Regards,
    Detlev

    Stomme poes Reply:
    September 17th, 2012 at 8:26 am

    I dunno how could just landmarks fulfill that requirement. Still today sighted keyboarders can’t make use of them (I dunno why, I think that would rock… *hint hint browser vendors*), and updating of AT lags far behind updating of browsers. For every lonely IE6 user out there, we have still apparently a good number of old JAWS/W-E (who still doesn’t support ARIA really)/Dolphin/etc users who aren’t upgrading because they don’t have the money or haven’t heard of the free open source ones or whatever. WCAG doesn’t necessarily say anything about that but as a practical matter, assuming you have *average* internet users, you have old AT users.

    Henny Reply:
    September 19th, 2012 at 8:06 am

    I agree with Stomme – we’re not there yet with Landmarks I don’t think. I would always make the core HTML accessible and ensure solid implementation of headings is used with Landmarks provided to add supplementary information.

    With regards to hidden headings off screen for navigation I, personally, am not a fan however I think it comes down to context and judging it on a site by site basis. I guess I’m not a fan as I like to keep things simple and streamlined as possible. Using structure as structure was intended should make content speak for itself. 99.9% of users will know roughly where to find the main nav and locate the sub nav within the content order if content order is coded logically. Good editorial on links also helps reinforce whether the link is main/sub navigation or other content.

    To be clear, the use of aria-label is to improve the usability of Landmarks that exist on a page that already makes sense via structural coding of headings. I’m not suggesting that this is a stand alone solution in itself.

  4. Ted Drake

    Verbosity is a problem. I’m working with a team that is actively using landmarks, aria-labels, etc. I applaud their dedication towards providing full keyboard accessibility, focus control, and well defined content. But I worry about the excessive verbosity.

    My plan is to do a verbosity evaluation after the full release and look at how we can simplify code where needed in a post-launch release. I don’t want to stop their momentum at this point and more is better than nothing.

    I think navigation, main, button, and search are probably the most relevant roles and others may be weeded out.

  5. Henny

    I agree verbosity is an issue; I hope the post is clear that aria-label should be used wisely and thoughtful placement of headings should be used.
    Like you I only really recommend the minimum for landmarks. My organisation uses a framework for the header and footer which utilises navigation, header and search. This is fixed obviously but on that foundation I require sites to have a main landmark (otherwise there would be a gap) but generally leave it at that unless sub navigation is needed.
    I’m really happy to hear you are doing a verbosity evaluation Ted, this is desperately needed as we are in danger of all going a bit crazy with Landmarks. If there is anything I can do to help let me know.

  7. Pingback: User testing observations with disabled mobile users | iheni

  8. Pingback: Using WAI-ARIA Landmarks – 2013 | The Paciello Group Blog

  9. homepage

    This is really interesting, You’re a very skilled blogger.
    I’ve joined your rss feed and look forward to seeking more of your magnificent post.

    Also, I’ve shared your site in my social networks!

Comments are closed.