Refer to Using WAI-ARIA Landmarks – 2013
Ukranian translation of Using WAI-ARIA Landmarks 2011 by Vlad Brown.
Using WAI ARIA Landmark Roles – updated
Share:
Share:
Categories:
Development
About Steve Faulkner
Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.
See All Posts by Steve Faulkner
Comments
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?
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
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?
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.
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.
Hi Jeremy,
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.
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.
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.
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.
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.
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!
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.
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?
role=”main” does not correspond to the html5 article element , role=”article” does though, but it is not a landmark.
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.
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.
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?
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?
Can a document have multiple complimentary elements?
yes.