Tag: ARIA-roles

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.

 

 

What are Implicit ARIA Roles?

For a while now, I’ve been seeing mentions of implicit ARIA roles as something web designers and developers should be aware of and know how to use.

In the case of ARIA roles, the word implicit means that the browser interprets certain HTML elements semantically and treats them as if an ARIA role were assigned to them. In these situations, the web designer does not specifically need to add the role attribute to the element. The addition of the ARIA role is considered redundant in some situations.

If you do add the role information, it does no harm, but, in my opinion, it’s best practice to know when you do need to add it and when you don’t.

For elements that have been around for a while, say the a (anchor) element, the browser implicitly assigns a role="link" attribute.

For the newer HTML5 semantic structural elements, browsers already have some of the roles built in. This improves as browsers add support. A header element that is not a descendant of an article or section element is implicitly assigned role="banner". A footer element that is not a descendant of an article or section element is implicitly assigned role="contentinfo". There are a number of other cases like this as browsers add support for HTML5. They are detailed at the W3C in two tables. This table shows strong native HTML semantics with default ARIA semantics. Just under it, this table lists the default implicit ARIA semantics for many other elements, along with any restrictions that apply.

In addition to the information at the W3C, check out this article by Steve Faulkner: HTML5 Accessibility Chops: When to use an ARIA role.

Think about ARIA roles when choosing a WordPress theme – Updated

ARIA landmark roles are used to improve accessibility and provide useful navigation points that a screen reader recognizes and can find quickly.

The role information is written into the HTML as an attribute of any element that fills a particular role. In the code, they look like this:

<header role="banner">
<nav role="navigation">

The current list of landmark roles includes:

  • application
  • banner
  • complementary
  • contentinfo
  • form
  • main
  • navigation
  • search

Some WordPress themes come with ARIA landmark roles built in from the start. It’s easy to find out if your theme uses them. One way is to look at your page source and search for “role” to see if or where it appears in the source code.

If you have the Web Developer Toolbar installed in your browser, use the Information menu to look at ARIA roles.

Display ARIA roles
Display ARIA roles in Information menu

This blog uses a slightly modified version of the basic WordPress Twenty Eleven theme. It’s an excellent theme in terms of ARIA information. Using the Display ARIA roles command from the Web Developer Toolbar, this blog looks like this:

Web Teacher ARIA roles
Web Teacher ARIA roles visible above the fold

One of the things you want to do when using ARIA roles is make sure that every section of your page that a screen reader user would want to find quickly has an appropriate landmark role. Twenty eleven has this covered.

I’m using a theme called Oxygen on my new blog Old Ain’t Dead.

Old Ain't Dead ARIA roles
Old Ain’t Dead ARIA roles

The only roles that comes out of the box with this theme identifies the navigation elements. A bit further down the page the social media sharing buttons do have role=”button” but the plugin maker deserves the credit for this, not the theme designer.

It’s easy to go into the theme files and add roles where you want them. For example. in the header.php file, I added role=”banner” like this:

adding a role
Adding a role to the header.php file

This is immediately reflected on the blog when I upload the header.php file.

the new banner role
The blog displays the banner role

I don’t regard this as a perfect solution, however. I am using a child theme. I made the adjustment in the header.php file of the parent theme.

Turns out you can copy theme files such as header.php, footer.php, sidebar.php and others into your child theme folder, add the ARIA role where you want it, and that version of the file is what gets served. Updates to the parent theme don’t cause the ARIA roles to disappear.

aria roles
ARIA Roles displayed on Old Ain’t Dead

Look at the beautiful ARIA roles on my blog now. And I have role=”contentinfo” in the footer, too!

A theme on wordpress.com

The two themes I’ve mentioned are self-hosted blogs, and I have control over the theme files. I also have a blog on wordpress.com – a free blog that I have no control over. I’m using a pretty old theme that I haven’t changed in years. It’s inadequate and I cannot do anything to fix it.

First 50 Words ARIA roles
First 50 Words ARIA roles

The two navigation landmarks you see come from the WordPress header bar, not from the theme.

I can change the theme to a more modern one, but if I stay with this one, there’s nothing. This is the incentive I need to take some time to look for a more current theme with ARIA roles included.

When you choose a WordPress theme, keep accessibility in mind and look for ARIA roles built into the theme by the designer.

For more information, see ARIA Roles 101.

Useful Links: Design Patterns, CSS3 Transforms, Industry Ready, Large Background

HTML5 and ARIA Design Patterns is at .net magazine. It provides design patterns for main elements, navigation elements, sections, details, summaries, and figures and figcaptions. In each design pattern, the appropriate ARIA roles are shown.

The Tower Blog explains how they did the CSS3 transforms in their sidebar in CSS3 Transforms by Example.

How to Teach Industry Ready? is at Unicorn Institute.

Large Background Images in Web Design: Tips and Techniques. Nice summary of the various options.

Useful links: media queries, landmark roles, structural elements

CSS Media Queries is a Mozilla Dev Network basic tutorial on media queries.

Usable landmarks across desktop and mobile is from Henny Swan about which ARIA roles are the most useful and when to use them.

The truth about structuring and HTML5 page at .net magazine is sure to be controversial, as is the book it’s an excerpt from. Be sure to read it.

Waiting for Screen Readers to Learn the Semantics of HTML5

There are new semantic elements in HTML5 with names like header, article, and nav. But the screen readers haven’t quite caught up with the element names yet. The most recent test results I’ve seen on how various browsers and screen readers handle the new HTML5 semantic elements can be found at Accessible Culture.

When we talk about accessibility, we stress how using the correct HTML tag to format something is accessibility Rule Number One. The reason is that most HTML tags are self-describing – the tag itself describes the semantic underpinning of the content it’s used to format. For example, tags like li and em and blockquote add meaning, semantic meaning, into the markup.

But what if the device you are using to get the content doesn’t recognize the semantics of an element like aside or section? You can add an attribute to the element that provides information that most assistive technology devices do recognize. The attributes I’m talking about describe  ARIA roles. Here are a few example of new HTML5 semantic elements with ARIA roles.

<header role="banner">
<nav role="navigation">
<aside  role="complementary">
<section role="main">
<footer role="contentinfo">

What are the possible ARIA roles you can use with the new HTML5 semantic elements? The most useful for the situations I’m talking about are the “landmark” roles:

Screen readers have a pretty good track record with ARIA roles. Adding them to HTML5 markup (or any version of HTML prior to HTML5 as well) adds meaningful help for people using assistive technology.

One way to fill the time before screen readers are updated to recognize the new semantic elements is to make sure you include ARIA roles in your markup.

See Also:

  1. How to make HTML5 semantic elements more accessible
  2. ARIA: A Quick Overview
  3. HTML5 and Screen Readers

WebAIM’s Screen Reader User Survey

You can see the full set of results of the WebAIM Screen Reader User Survey #3. I hope you’ll study them with interest.

I want to highlight a few of their findings here.

ARIA Landmarks

Chart showing usage of ARIA landmarks

ARIA (Accessible Rich Internet Applications) introduces something called landmarks. These provide quick access to page areas, such as navigation, search, and main content. Which of the following best describes your use of landmarks?
Response # of Respondents % of Respondents
I didn’t know this functionality existed 342 30.9%
I do not use landmarks for navigation 287 25.9%
I sometimes use landmarks for navigation 277 25.0%
I use landmarks for navigation whenever they are present 161 14.5%
My screen reader does not support landmarks 40 3.6%

Awareness of landmarks has increased – 42% were unaware of this functionality in October 2009. However, these data continue to show mixed levels of usage.

In spite of that finding, I think its important to teach people how to use ARIA roles, particularly in HTML5. In HTML5, we’re still dealing with levels of support for various new elements, and any help that a front-end developer can add to the code is a good thing.

Other findings important to front-end developers:

  • JAWS is still the primary tool, although others are increasing in number
  • Almost 95% of users have JavaScript enabled
  • A majority of users are using a screen reader on a mobile device, too
  • The main method for navigating a page is using headings
  • The use of “skip links” and access keys is decreasing
  • The heading structure found most useful by a big majority of screen reader users: Two first level headings, one for the site name and one for the document title
  • Users indicate strong usefulness of the longdesc attribute, which may not make it into HTML5