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.

1. Consumption of information is more efficient when information is presented on paper compared to presenting the information on a computer screen.
2. Consumption of information generates less mental workload when the page layout is adapted to fit the screen.

The first point may not come as a surprise. Steve Krug has argued that users tend to scan web pages rather than read them and Erik’s study cites previous research that says users tend to have difficulties reading longer passages of text on a screen.

A fundamental characteristic of reading information on a computer screen is that it “involves both the process of reading the presented text and handling the computer. The reader’s processing capacity is being utilized not only for decoding but also for page navigation.”. When we read e.g. a book the mental workload is low because we know from experience where to focus after turning a page.

Adapting content to the screen

The second point has some interesting implications for people working with the web. Currently, web pages with a lot of text tend to come in two flavors:

1. All text on a single web page and the standard browser scrollbar to move forward in the page. (Example: A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft).
2. Paged text and one or more navigation buttons to move to the next page. (Example: Mark Pilgrim’s Dive Into Accessibility, Day 6: Choosing a DOCTYPE).

Paged text on the web today is rarely adapted to the browser window size.

In Erik’s study the test subjects were given reading assignments. One group read the document in a scrolled format (number 1 above) and the other group read the document in a paged format where the page format was adapted to the computer screen.

The result showed that mental workload was lower when you read information in a paged way adapted to the screen. This is interesting as the current technology for constructung web pages (HTML and CSS) do not provide an easy way to page text adapted to the user’s screen. I am guessing that it may be possible by using javascript to measure the window size and create keys to move forward by a viewport page at the click of a button.

On the other hand, most browsers provide this functionality for scrolled pages in the Page-up and Page-down keys. In the usability tests I have participted in during the past years I can not recall a single user using the Page-up/down keys.

So, does this mean that scrolled text is better if user’s learn to navigate with the Page-up/down keys? Or should content authors paginate long documents? Will these methods have other accessibility implications?

In order to make accessibility development efforts more efficient I believe that accessibility has to be integrated into all stages of a project with as much automation as possible. Here are some ideas on how this can be done for the developer role.

Project roles and process

Consider the typical staffing of a web development project and how the respective roles relate to accessibility:

• Designers create the user interface design. The design needs to be checked for visual aspects such as contrast issues, choice of color, font readability etc. The designer deliverables are often due early in the project.
• Developers create the markup and application logic for the application. The markup has needs to be checked for technical accessibility issues such as correct markup of tables, forms, document structure etc. The developer devliverables appear throughout the project.
• Content producers (copywriters) create text. The text has to be checked for readability issues and other language aspects. Content is often delivered towards the end of the project.

Accessibility experts typically appear at the end of the project to test the application. This is natural as it isn’t until the end that the majority of design, markup and content is available for testing.

Implications

The problem with this approach is that the time between feedback from the accessibility evaluation and the work done is too long. Proponents of agile development methods identified this a long time ago and it is typically illustrated with the cost of change curve:

In essence, rapid feedback is easier to act upon and incurs a lower cost of change. Getting the feedback later means that you as a developer may have implemented more functionality in an inaccessible way. There may also be more dependencies developed that affect the parts that you need to change based on the late feedback.

So, if possible we would like to have a tool that provides rapid feedback throughout the development process to all project roles. By “rapid” I am referring to near instantaneous feedback to minimize context switching for the developer.

Challenges with automated accessibility evaluation tools

The challenge with accessibility testing is that many things are difficult to automate. Content, for example, is hard to do an automated assessment of. You may calculate all the readability scores you want but only real user testing will give you enough information to conclude if your content is understandable.

Contrast and color is also difficult. Developers may have used combinations of javascript, css and markup to create the final look. To have a machine understand the actual contrast ratio for a specific text may be nearly impossible if you don’t roll your own browser implementation.

Other challenges include integrating a tool into your project’s continuous integration framework. This rules out many of the web based tools available.

A proposed solution

If you haven’t heard of Raakt (The Ruby Accessibility Analysis Kit) before, there is a quick introduction on the Raakt wiki. Raakt focuses on the developer role in a project and helps developers make sure that the created markup passes a set of basic accessibility tests. It integrates with many test frameworks to become part of the automated test cycle.

The ambition is to make basic technical accessibility testing a natural part of a development project’s test suite. This will hopefully improve markup quality and minimize the number of accessibility issues found in subsequent tests. It also helps developers with little or no accessibility knowledge to get on track faster.

I would be very interested in receiving your feedback on what you think about this approach. How can accessibility become a more natural part of a development project? In your experience, would a project benefit from rapid accessibility feedback? Have you tried Raakt and did you find it useful?

References

• Scott W. Ambler: Why Agile Software Development Techniques Work: Improved Feedback.