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.
@vdebolt Don’t like the output? Just change the markup instead of hiding the semantics under a presentation role. /cc @jsutt
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.
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:
The current list of landmark roles includes:
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.
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:
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.
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:
This is immediately reflected on the blog when I upload the header.php file.
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.
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.
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.
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.
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.
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?
# of Respondents
% of Respondents
I didn’t know this functionality existed
I do not use landmarks for navigation
I sometimes use landmarks for navigation
I use landmarks for navigation whenever they are present
My screen reader does not support landmarks
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
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