Using WAI ARIA Landmark Roles – updated

Refer to Using WAI-ARIA Landmarks – 2013

Ukranian translation of Using WAI-ARIA Landmarks 2011 by Vlad Brown.

About Steve Faulkner

Steven is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains www.HTML5accessibility.com
This entry was posted in HTML, HTML 5, iPhone, JAWS, landmark roles, NVDA, Safari, Screen Readers, Standards, VoiceOver, W3C, WAI-ARIA, Web Accessibility, Window Eyes, WordPress, Zoomtext. Bookmark the permalink.

35 Responses to Using WAI ARIA Landmark Roles – updated

  1. You don’t think the banner role maps to the HTML5 header element? And that the main role maps to the HTML5 article element? And that the search role maps to the HTML5 Search state of the input element?

  2. Steve Faulkner says:

    Hi Anne, not from my reading of the spec, for example, i would expect there to be only one section of content with a role of banner or main in a web page, the html5 header element can be used multiple times in a web page as can article. While role=”search” can be added to containers that contain the whole search form, the search state of the input element identifies only the input itself. But i do not see an issue with using <header role=”banner”> for a section of content that contains what ARIA describes as banner content, which is what bruce lawson has done on his site.

  3. Jared Smith says:

    I’m redesigning the WebAIM site now and will be implementing landmark roles and other ARIA properties. My current dilemma is that I don’t think I can stomach all of the “I can’t believe your site doesn’t validate!” emails I’m certain to get. When I accidentally break validation now, I hardly go a day without somebody nagging me about it. As such, I’m leaning toward adding the ARIA roles and properties through scripting.

    So, in your opinion, are there any disadvantages to doing this (beyond the fact that those without javascript don’t get it)? And are you aware of any plans to update the W3C validator to support ARIA?

  4. Jeremy Keith says:

    This is excellent, Steve. Many thanks.

    I have a couple of quick questions:

    1. Do you think that the element with the role of “main” and the element with the role of “complementary” should be separate or do you think the “complementary” element should be nested within the “main” element?

    2. Would it be appropriate to apply a role of “application” to an object element containing a Flash movie?

    I’ve looked at the draft spec but couldn’t find answers to those questions there.

  5. Steve Faulkner says:

    Hi Jared, I don’t see any disadvantages apart from the one you mentioned. you have brought up the issue of how the ARIA stuff can be validated, I don’t know of any plans to update the W3C validator at this stage, though there has been some discussion about how to validate (X)HTML+ARIA. I am working on a possibility right now, will keep you posted.

  6. Steve Faulkner says:

    Hi Jeremy,

    1. Do you think that the element with the role of “main” and the element with the role of “complementary” should be separate or do you think the “complementary” element should be nested within the “main” element?

    I think it depends on the page layout, if there is an “island” of complementary content included with the main content then it could be nested. Where there is a clear visual delineation between the main content (example its in the middle) and the complementary content (on the side) then it would make sense to have them seperated.

    2. Would it be appropriate to apply a role of “application” to an object element containing a Flash movie?

    It’s a great question! The role of application does something quite specific, it tells the AT to switch modes (if the AT uses them). It was only added as a landmark role the other day, so I don’t think the PF WG have thought about it in terms of its landmark use. It would make sense for a flash movie that is an interactive widget to be given a role=”application” i guess, I will bring this up on the mailing list and see what other people think.

  7. Jeremy Keith says:

    Excellent! Thanks, Steve. I’ll try to keep an eye on the mailing list to see what people think about applying an “application” role to Flash movies.

  8. James Craig says:

    I can see the benefit of using application on a Flash movie for the sake of landmark navigation, but it also is intended to communicate to the UA/AT to switch from ‘document browsing’ mode into ‘application interface’ mode, so it doesn’t make as much sense b/c Flash movies aren’t ARIA applications. In a sense, because Flash isn’t accessible on all systems, and because the interface is very different from the web browser’s interface, the author is promising the user something they can’t always deliver, or may not deliver in the way the user expects.

    In theory, on the platforms where Flash is accessible, the Flash player could/should communicate role, state, and property information directly to the accessibility API, instead of going through the browser via ARIA.

  9. Pingback: How Can I Validate (X)HTML + ARIA? - The Paciello Group Blog

  10. Thanks for a great article. I’ve been wondering about the overlap between the roles in ARIA and the new elements in HTML 5, this has helped answer some of the questions. I was going to ask if you thought there would be a 1-1 matching of the two for all the pieces of both, but the more I read and think about it I see it’s going to depend on how each page is designed. Overall, this is a great starting point for understanding how they can work together.

  11. Pingback: Max Design - standards based web design, development and training » Some links for light reading (20/1/09)

  12. Pingback: Redesigning with HTML 5 and WAI-ARIA | Neuronworks Blog, webMethods, Oracle, Bea, Java Dev2Dev, Arch2Arch

  13. Pingback: Links: March 4th - March 5th | The World According to Buchs

  14. Pingback: Bruce Lawson’s personal site  : Marking up a blog with HTML 5 (part 2)

  15. Pingback: The Paciello Group Blog » » WAI-ARIA role support - How the browsers stack up

  16. Pingback: Contributing WAI-ARIA landmark roles to open source CMS themes- Standards Schmandards

  17. Scott Jehl says:

    Thanks for this post, it’s been quite helpful for us.

    Question: I have an application with 2 areas of the page that I’d consider to be landmarks (the app content area and the header/toolbar area. Using the “main” role for the content area of the application seems to make good sense, but the header/toolbar area contains both global navigation and local page tools (menus, radiogroups, slider roles, etc). Given your description of the “banner” role, it seems it wouldn’t be an appropriate landmark to use for this header/toolbar div, but I’d like to use a landmark of some form for page organization purposes. Do you think the banner role really needs to be so strictly tied to global site actions or could it be appropriate here?
    Also, could I use multiple roles on one element or would I have to add another wrapper div to specify that the div is both a toolbar and a banner?
    Thanks for your thoughts!

  18. Pingback: Vorsprung durch Webstandards | 7 Gründe Wai-Aria Landmarks sofort einzusetzen

  19. role=main does have a corresponding HTML5 element: article.

    Also, in HTML5 an input can be of type=search, so the form that contains such an input is equivalent to role=search.

    • Steve Faulkner says:

      role=main does have a corresponding HTML5 element: article.

      role=”main” does not correspond to the html5 article element , role=”article” does though, but it is not a landmark.

      Also, in HTML5 an input can be of type=search, so the form that contains such an input is equivalent to role=search.

      That can work if the form element contains the text (instructions labels etc.) associated with the search and does not include content extraneous to the search interface and the form element is present and the input type=”search” is supported by AT/browsers.
      If all these issues are taken into consideration, there is still a place for role=”search” which can be placed on any container element to define the element as containing the search interface.

  20. What interface does JAWS use for finding out the landmark roles? Does any other screen reader on a non-Windows platfrom support landmarks by now?

    • Steve Faulkner says:

      What interface does JAWS use for finding out the landmark roles? Does any other screen reader on a non-Windows platfrom support landmarks by now?

      i think I answered the second question over on Anne’s blog. The answer to the first question I am not so sure about. IE8 supposedly exposes all ARIA roles via the UI Automation AriaRole property, but have not been able to confirm this with the testing tools available.

  21. Pingback: The shelf life of a skip link » iheni :: making the web worldwide

  22. Pingback: Accessibility Field Notes » Blog Archive » Skip links: Chrome, Safari and Added WAI-ARIA

  23. Pingback: The Paciello Group Blog » Apple Webkit Gets Serious About WAI-ARIA (on MAC)

  24. Pingback: Apple Webkit Gets Serious About WAI-ARIA (on MAC) « AccessTech News

  25. Pingback: Apple Webkit Gets Serious About WAI-ARIA (on MAC) « The BAT Channel

  26. This could get messy.

    I currently have in an HTML 5 document a “header” with and id of “branding” and a role of “banner”.

    I have a “footer” with an id of “siteInformation” and a role of “contentinfo”.

    It strikes me there’s going to be instances where the readability of the code could get confusing.

    Any ideas?

  27. Jim Thatcher says:

    There is an elephant in this Landmark room: keyboard access. Sure skip link are incredibly arcane but even if not visible, a skip link can be used from the keyboard by checking the status area. I know that is awful. But where is any keyboard support for landmarks?

  28. Pingback: WAI-ARIA und (X)HTML validieren! | Webseiten-Infos.de

  29. Pingback: Tim Noonan’s Favourite and blind friendly Accessible WordPress Plugins and his Choice of Thesis as Theme. JFW JAWS Screen-reader Friendly blog widgets — Vocal Branding Australia

  30. Pingback: Javascript e acessibilidade | Boas práticas de Desenvolvimento com Padrões Web

  31. Pingback: Javascript e acessibilidade « …tecnologicamente correta…

  32. Martin says:

    Can a document have multiple complimentary elements?