More Accessible YUI Grids Layouts with ARIA Landmark Roles

March 5, 2009 at 4:09 pm by Todd Kloots | In Accessibility, Development | 5 Comments

YUI Grids CSS has long been an important tool for developers wishing to create more accessible layouts. Through its support of source-order independent layouts, Grids enables control of the reading order of a page, allowing developers to place the most important content higher in the markup so that it can be quickly discovered by users of screen readers. However, while the role of each section of a Grid (e.g., navigation, main content, footer, etc.) is easily perceived through visual style and layout, it is not immediately perceived by users of screen readers because <div>s are inherently structural elements with no default semantic meaning.

The Benefit of Landmark Roles

ARIA Landmark Roles improve the content parsability of Grids for users of screen readers. By allowing developers to declare the intended purpose of each section of a layout, Landmark Roles provide semantic meaning to each section of a Grid, giving users of screen readers a high-level summary of how a page is organized. In addition, Landmark Roles significantly improves a Grid’s navigability. For example, the JAWS screen reader will announce all of the Landmarks when a page is loaded and allows users to quickly jump between them by pressing the semicolon key:

Example Page Using YUI Grids And ARIA Landmark Roles @ Yahoo! Video

Using Landmark Roles

Of all the roles defined in the ARIA Specification, the Landmark Roles are among the easiest to implement since they don’t require JavaScript for keyboard support or state management. Landmark Roles are applied to an element using the role attribute and can be used to improve the semantics of any section of a Grid. For example, to declare a section of a Grid as navigation, simply set the role attribute to a value of “navigation”:

<div class="yui-b" role="navigation">

Presently the ARIA Specification defines seven different Landmark Roles:

Getting Started Is Easy

Since ARIA Landmark Roles are such a perfect complement to Grids, we’ve added built-in support to YUI Grids Builder, added a new section on using Landmarks to the Grids user guide, and created a new example to highlight usage of Landmarks Roles within YUI Grids CSS. Developers who are currently using Grids should definitely consider adding ARIA Landmark Roles to their markup to easily improve the accessibility of existing layouts.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

5 Comments »

RSS feed for comments on this post. TrackBack URI

Nice. I had no idea these existed. This will be a nice feature to add into my sites especially if it works with selector engines like sizzle(which it should).

Thanks!

Comment by Jeffrey Gilbert — March 6, 2009 #
I am someone that is in full support of adding roles and other ARIA features to my designs. But one thing that I am not sure of is whether or not roles are supposed to be like ids in that there should only be one element with that role in the document.

For example, suppose one’s design has a main navigation along the top of the design, and page specific navigation running along the side. Should both of the containers for the navigation elements be given the role of navigation, or what? Similar for the role of banner and secondary (a name I dislike because it is too specific — think of those of us with a three column layout). And is it necessary to use labelledby for an element where the next element is a header?

Comment by Brian LePore — March 10, 2009 #
Brian -

Currently the ARIA specification says that only two roles (“banner” and “main”) should be used once per documented or application. So, to answer your question about navigation: you could use the role of “navigation” for BOTH main navigation and page-specific navigation. You could then use the ARIA “labelledby” property along with a header element to distinguish the two sets of navigation from each other. The same goes for use of the “secondary” landmark role. For more, read the section titled “Providing Navigable Structure within Web Pages” (http://www.w3.org/TR/wai-aria-practices/#kbd_layout) of the ARIA Best Practices document.

Regarding your question: “is it necessary to use labelledby for an element where the next element is a header?” Both are necessary as they have different uses, and provide different benefits.

Headers are important as a means of providing semantic meaning and improving navigability for users of browsers and/or screen readers that either don’t support ARIA, or that do support ARIA, but currently lack support for ARIA landmark roles. This reminds me of a cardinal rule of using ARIA: always consider ARIA a Progressive Enhancement to existing best practices, rather than a replacement for existing best practices.

Using the “labelledby” property to label each landmark provides the user with more specific information when he/she is exclusively browsing the landmarks of the page, as opposed to reading a specific section. Using the earlier example of navigation: if you use the “lablledby” property users would be able to distinguish global navigation from page-specific navigation.

I hope that clears things up for you.

Todd

Comment by Todd Kloots — March 14, 2009 #
Todd,

Thank you for that reply. I am a Web developer that has been very hard to integrate ARIA into the designs that my company offers to the clients of our CMS. I have not yet gone back over designs I had done in the past to add these roles, but I have been adding them where appropriate to our new designs.

I know this sounds weird, but has the work group considered the idea for fall back labels? I know this seems odd, but it in my experience with CMS design is that no matter how much instructions you leave or how clear it is how the layout should look, some times a client will just do what they want to do. For example, suppose that you have a two column layout where one is the main area, and the other secondary data. Both of them deserve to have a header so it is in the template. But occasionally a client will decide to delete the header for the secondary column. This implies a different type of meaning for the page. If a fallback label could be applied this could be a way of allow the correct meaning to the page.

I know for my example the proper solution would be to provide an alternative page layout for people in my CMS. This is within my power and something that I can do for my situation, but not all providers will be able to do this, and from my experience many clients will just stick with whatever the default layout there is.

Another question: is there some methodology for naming roles? I mean, I guess I can understand how contentinfo is a bit more generic than footer, but I just cannot see a practical example of when one would use contentinfo besides in the footer of most sites.

Comment by Brian LePore — March 16, 2009 #
Nice post… You guys rock!!
Keep up the good work..

Regards,
MindAlbum

Comment by MindAlbum — March 27, 2009 #

Yahoo! User Interface Blog (YUIBlog)