Yesterday I discovered that Mozilla add-on hosting has improved a lot so in the future you will find Fangs there. It should make updating a lot simpler. Version 1.06 adds compatibility with Firefox 3.6.

See Fangs screen reader emulator add-on over at Mozilla.org.

Introduction

When you start working with web accessibility as a site owner you will typically be exposed to online accessibility evaluation tools recommended by your supplier. These tools typically let you enter a link to a web page after some automated checks are made you get a report of all the errors that were found.

While these tools may be a good way to convince your organization to increase funding for accessibility work you should be careful how you interpret their results. Your website may be good enough already and if you try to fix all reported errors you may be spending money in the wrong thing.

As an example of how difficult these tools may be to trust and understand I have selected some of the more popular ones from the Web Accessibility Initiative list of tools and performed some tests.

Letting accessibility evaluation tools test themselves

Here, each of the tools were pointed at their own starting page. When possible WCAG 1.0 triple A settings were selected.

Very few errors as expected. After all, these tools are built by professionals and I would expect them to have checked their own service.

Letting them test each other

So, what do they say about each other? Only one way to find out.

It is understandable that people find it hard to make use of web accessibility evaluation tools. How are you supposed to interpret these results? None of the tools are in agreement on any of the tested pages. Similar results would be returned for most pages you evaluate.

Observations

• WAVE didn’t find any accessibility issues in any of the pages. Also, WAVE would display a fun error message if you try to make it check itself by URL (I had to copy and paste the source instead).
• The output from many of the tools are really hard to interpret, especially if you are new in the field of web accessibility. The  TAW tool, for example, displays tiny icons all over the page and you have to hover them to see what they mean.
• Worldspace uses nested tables for layout (something that WAVE didn’t complain about).

What would be your advice for a site owner that wants to increase accessibility on his/her website? How can they check if their supplier did the right thing when creating the markup?

(Please leave a comment or send me an email if you find any errors).

Currently many developers seem to be reluctant to add the role attribute in their markup since it will make pages invalid when using the W3C markup validation service. This is understandable given the attitude developers of content management systems have had to put up with from some people in the industry.

If you want to now more about WAI-ARIA, please have a look at the WAI-ARIA best practices document.

1. Adding the role attribute to relevant elements in markup

This is the easiest way of describing the different parts of your web page, but has the drawback of making the pages invalid. To add the role “main” to a div just add the role attribute with the value “main”:

<div role="main">...</div>

2. Set role attribute values on elements by ID

If your markup already has elements with proper ID attributes that match the landmark regions in scope you can use a simple javascript to set the role attributes when the page has loaded. This will allow your precious template code to pass the markup validation test as well if you or your users worry about that. Consider the following markup fragment:

<div class="special" id="mymaincontent">
<h1>The main content heading</h1>
<p>Some text</p>
</div>

Adding landmarks via the role attribute can be done with a simple javascript like this:

function setRoleAttribute(id, rolevalue) {
if(document.getElementById(id)) {
document.getElementById(id).setAttribute("role", rolevalue);
}
}
function setAriaRoleElementsById() {
//Add all Id:s and aria roles here
setRoleAttribute("mymaincontent", "main");
}
window.onload=function(){ setAriaRoleElementsById(); }


For a larger example see Landmarks by ID (view source to see details).

3. Set role attribute values on elements via CSS decoration

If you for some reason are more comfortable using CSS classes instead you can create an unobtrusive javascript like this:

function setAriaRoleElements() {
var els = document.getElementsByTagName('*');
var pattern = new RegExp("ariarole-([\\w]+)", "g");
for ( i=0; i < els.length; i++ ) {
var match = pattern.exec(els[i].className);
if (match && match.length > 1) {
els[i].setAttribute("role", match[1]);
}
}
return;
}
window.onload=function(){ setAriaRoleElements(); }


This will allow you to add CSS classes to existing elements in the following form <div class=”ariarole-main”> and get a role attribute with the value “main” on the same element. This pattern won’t affect validation. For a larger example see Landmarks by CSS decoration.

4. Set role attribute values on arbitrary elements using a javascript library

If you already are using a javascript library like jQuery and Prototype you may be more comfortable using that to set the role attribute. This pattern won’t affect validation. For jQuery a typical example may look like this:

$(document).ready(function() {
$("#mymaincontent").attr("role","main");
});

You can of course use other selector patterns as well.

If you find errors or have suggestions for improvement, please add a comment below. All code examples are free to use without attribution (yes, I am looking at you WTFPL license).

At the European Accessibility Forum in Frankfurt (eminently organised by Namics) I met Steve Faulkner who has done a lot of research on  WAI-ARIA (see Using WAI ARIA Landmark Roles). Although the specification isn’t finalized yet there are many advantages to WAI-ARIA and browser support is increasing.

With the help of Steve, I submitted a minor patch for the default WordPress theme that adds ARIA landmark roles. I believe that a simple thing like this would make the web a better place for a lot of people as well as making web development easier.

How to add WAI-ARIA landmark roles

For an overview of methods to work with landmark roles in existing HTML see Patterns for WAI-ARIA landmark roles in existing HTML.

How to check WAI-ARIA landmark roles

If you want to start working on implementing landmark roles in a theme, check out Juicy Studio’s Web Accessibility Toolbar Extension for Firefox or the YAML debug tool bookmarklet. These will aid you in checking that the markup you add is correct.

Adopt your favorite CMS

What other content management systems would you like to see support WAI-ARIA landmark roles? If more people could help to create patches adoption would increase rapidly.

Add your suggestions below (or better, create a patch and send to the developers).

Content management systems

• WordPress (patch accepted for WordPress 2.8)
• Typo3
• Joomla (patch accepted for Joomla 1.6)
• Drupal (patch submitted by Mike Gifford)
• Dotclear (patch submitted in ticket 728)
• Textpattern
• Plone (ticket 9298 submitted by Christophe Strobbe)

Wiki tools

• MediaWiki (patch submitted)
  
• twiki
• Dokuwiki (patch submitted)
• Dekiwiki (may need some accessibility love in other areas too)
• PmWiki (patch submitted)
  

Forum applications

• bbPress (patch submitted by Marco Zehe and accepted in ticket 1074)
• phpBB
• PunBB

Layout generators

• YUI Grids (done)

Hosted services

• Blogger (feature suggestion submitted by Lars Gunter).
• Laconica

Web frameworks

• Django

This is excellent news. Hopefully it will lead to a better web. If you run a consulting company this could be a compulsory course for GUI developers.

A big thank you to Stuart Middleton who showed me the necessary steps to get rid of the annoying security warning that Firefox 3 displays for unsigned extensions.

The purpose of the quality criteria is:

• to act as a tool for developing and assessing public web services
• to improve the quality of public web services for both users and producers
• to increase the benefits from public web services.

I have updated the Index of Government Guidelines page and search engine to include this version.

Quoting from the announcement: “The Guidelines are divided into chapters which can be read separately depending on the readerâ€s role and responsibilities. The order of the chapters is intended to mirror the lifecycle of a website.

• Chapter 1 covers the overall communications objectives of a website, which should be used as the basis for its development.
• Chapter 2 presents the development process as steps towards a defined objective.
• Chapter 3 shows methods for website design and web page coding, along with web standards.
• Chapters 4 and 5 describe the basic content and services a website should provide, giving additional information on how to write for web-based media as well as methods for keeping the website up to date.
• Chapters 6, 7 and 8 cover the development of web content for mobile devices, Content Management Systems (CMS) / authoring tools, and assistive technologies (AT).

A survey carried out in February 2007 showed that over 90% of those responsible for public administration websites in Sweden were aware of the Guidelines, with 80% or more actively using them.”

The Guidelines are published under the Creative Commons Attribution 2.5 Sweden license.

A bit of background on RDFa

RDFa is a set of extensions to HTML and XHTML from W3C. With RDFa it is possible to use custom vocabularies to include machine readable data in web documents. In current web documents based on HTML or XHTML there are very limited ways of expressing information for machines. There are:

• HTML elements that express document structure (e.g. headings, lists, tables), and rethoric (em, strong),
• (broadly defined) HTML elements that express various technical terms (code, kbd, samp), and,
• the content itself.

As more business domains are moving online the need to exchange data in a more structured fashion will increase. Instead of publishing data twice, once in a web document for humans and once in a separate file for machines, RDFa makes it possible to include machine readable data in web documents. (In a way, this has been possible since the modularization of XHTML, but in practice, few developers seem to have used the extension mechanisms of XHTML).

An RDFa example

Consider the following XHTML markup:

<p class="contactinfo">
	My name is Jo Smith. I'm a distinguished web engineer at
	<a href="http://example.org">Example.org</a>.
	You can contact me 
	<a href="mailto:jo@example.org">via email</a>.
</p>

Most humans will be able to understand the information but for machines this markup is too vague to parse without ambiguity. By providing more information about the content we can reduce this ambigity. First we provide information about our vocabulary in the HTML element:

<html xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#">

Then we can use the terms of that vocabulary to provide more information for machines:

<p class="contactinfo" about="http://example.org/staff/jo">
	My name is
	<span property="contact:fn">Jo Smith</span>.
	I'm a
	<span property="contact:title">
		distinguished web engineer
	</span>
	at
	<a rel="contact:org" href="http://example.org">
		Example.org
	</a>.
	You can contact me
	<a rel="contact:email" href="mailto:jo@example.org">
		via email
	</a>.
</p>

One of the major benefits is that there is a standard for the vocuabulary specification and it is machine readable. You can open the URI for the vcard vocabulary used above in your browser (you may have to “view source” to see it) and see more information about the terms of the vocabulary. Another big advantage is that you can create a vocabulary specification for your business domain yourself and publish on the web. You do not have to put it through some central authority.

We have now modified the markup in our document to make it useful for both humans and machines. The document still looks the same for sighted users that look at the information in their web browser. Apart from the added benefit for search engines and desktop applications (e.g. importing this information into your adressbook now becomes easier) I believe it will have interesting implications for assistive tools as well.

What if assistive software could use RDFa information?

Since the vocabuary is created in a machine readable format it should be possible to let assistive software such as screen readers load the vocabulary specification and provide more information for the user. If you look at the vocabulary specification for vcards used above each term has a label text. For the title the specification looks like this:

<rdfs:label>Position Title</rdfs:label>

One of the simplest ways of using this information is of course to read it to the listener during the linearization of the page. Since a term can have a description too even more information could be provided to the user.

In practice, the sequence of events for a screen reader working on top of a web browser could look like this:

1. Browser opens the web page.
2. Screen reader parses the HTML and extracts references to all external vocabularies.
3. External vocabularies are fetched and parsed for labels and descriptions.
4. The screen reader announce that extended information exists and starts rendering the page.

So, by using RDFa to reduce ambiguity for machines it is likely that humans too can benefit from the added information. It will be very interesting to see what makers of assistive tools can come up with. What other use cases for RDFa with regards to accessibility can you see?

References

For more information on RDFa see:

• Introduction to RDFa by Mark Birbeck.
• The W3C RDFa primer.
• The Wikipedia entry on RDFa.