Tag: WAI-ARIA

Twitter Writes a Post about role=presentation

There is an ARIA role called “presentation” in the WAI ARIA spec. With Twitter’s help, Denis Boudreau wrote this post about it.

This is how it started:

Then @jsutt took up the idea with this:

Denis Boudreau to the rescue!

 

 

 

As you see, this ARIA role has specific and limited use. I wasn’t sure where a front end developer who was only working with semantic HTML would even consider using it.

 

Oh, at last the light dawns. This is what developers building apps sometimes need to do. Even at that, go back to point one about only using it when you really know what you’re doing and are absolutely sure you want to strip an element of its semantics.

Denis draws us to a sensible conclusion.

 

 

Improve Accessibility in HTML5 with WAI-ARIA Landmark Roles

html5 logo

HTML5 contains several new elements that are considered semantic in that they more accurately describe the content they contain than a generic element such as a div.

These new elements improve accessibility as standalone structure, because of the semantic underpinnings they carry with them. The elements in question are: header, footer, main, section, article, aside, and nav. Simply using them without any additional coding such as the WAI-ARIA landmark roles I’m going to describe today is an improvement.

The roles I’ll describe are banner, complementary, contentinfo, form, main, navigation, search. The names make the role pretty obvious, but some roles have fine points.

The header element

In HTML5, the header element can be used repeatedly on a page. It can be the main header for the entire page, or a header for a subsection of the page such as a section or an article or an aside.

If the header element is used at the main header for the entire page, the role banner can be assigned to it. Only one header on a page can have the role banner.

<header role="banner"> . . .</header>

Within the page there may be header elements used as article or section or aside headings. The ARIA role that can by used in that case is heading.

<article><header role="heading">Article heading</header>Article body</article>

The heading role can also be used in tables.

The footer element

In HTML5, the footer element can be used repeatedly on a page. It can be the main footer for the entire page, or a footer for a subsection of the page such as a section or an article or an aside.

The main page footer can use the role contentinfo. But footer elements for subsections of a page may not use this role. It can only be used once on a page.

<footer role="contentinfo"> footer for entire page</footer>

Depending on what kind of information is included in the footer for articles or other smaller page sections, the footer might be appropriately labeled with the complementary role.

<footer role="complementary"> informative footer for an article</footer>

 The aside element

The aside element is meant for complementary material, not crucial to the page content, but supplementary. Therefore the complementary role is perfect for it.

<aside role="complementary"> supplemental content</aside>

Main, Navigation, Form and Search

You’ve seen how simple it is to assign a role to an element, so I’ll stop giving code examples. There are just a few points about the roles main, navigation, form and search. It seems self-evident when to apply navigation, form, and search to page elements. But main is another role that can only be used once on a page to indicate the main content, which might be contained in a main, div or section element. Using the main role properly eliminates the need for those “jump to main content” links that were so prevalent for a while on the web.

ARIA Roles are not only for HTML5

The last point to keep in mind is that ARIA roles work in all flavors of HTML. They do not depend on the use of HTML5 to make your web page accessible. Even if you are not ready to switch to HTML5, you should begin using ARIA roles.

See Also: ARIA Roles 101 and How to Make HTML5 Semantic Elements more Accessible.

HTML5 & annotations for assistive technology

I was scrounging around in the HTML5 spec on the W3C site looking for something else and found an answer to a question I had asked about earlier on Web Teacher. In the section titled Annotations for assistive technology products (ARIA) I found the answer to my question about aria-level.

A table in the spec detailing the HTML5 language feature with its “strong native semantics and implied ARIA semantics” shows the following for h1 through h6 elements.

Native Semantic Element: h1-h6 element that does not have an hgroup ancestor
Implied ARIA semantics: heading role, with the aria-level property set to the element’s outline depth

So the answer is do include a value for aria-level in headings that are not nested in an hgroup. If the heading is part of an hgroup, include the aria-level attribute in the hgroup element.

The value associated with the aria-level would be dependent on the element’s position in the document outline.  Here’s an example with an hgroup:

<hgroup role="heading" aria-level="2">
<h1>Main heading</h1>
<h2>Subheading</h2>
</hgroup>

Without an hgroup:

<h1 role="heading" aria-level="2">

The entire table at W3C is very useful. I urge you to read the whole section on Annotations for assistive technology products (ARIA).