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.

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?

Test method

The test method is the same as last time (to be able to see if scores changed compared to the previous test). In short, I tried to create a sample document in each of the editors. The sample document contains markup commonly found on the web. All editors were tested on the same date and the online demo version was used when available. If there was an option to enable more features, all were enabled. Please note that I am primarily testing the output of the editor and not the accessibility of the editor itself.

Tested editors

Most of the editors from the previous test are included this time. Based on feedback from the comments I have also added a couple of new contestants.

From the previous test:

1. EditOnPro by Realobjects. Commercial license.
2. XStandard by Belus Technology. Commercial license. Lite version free (also see special license for open source CMS projects)
3. FCKeditor by Frederico Caldeira Knabben. Open source (LGPL), commercial license available.
4. CuteEditor by Cute Soft. Commercial license.
5. TinyMCE by Moxiecode. Open source (LGPL).
6. New: Xinha. Open source BSD-style license.
7. New: WYMeditor. Open source (MIT and GPL). For an introduction to WYMeditor see Visually Editing Semantics – What You See Is What You Mean.
8. New: Loki by Carleton College. Open source (GPL).

Missing from this round is Kupu as it has not come out with any new release since the previous test. Also, eWebEditPro could not be tested. The online demo gives an error: “Error loading mycontent1”.

Test result

The total score for each editor is listed below. For full test result details see here.

If you find error in the results, please leave a comment or send an e-mail to peter krantz at gmail.com.

Observations

• Many of the tested editors have implemented more accessibility features since the previous test. This is good.
• The bold and italics icons are still used when creating emphasis.
• TinyMCE is one of the few editors that doesn’t nest list items properly. According to the developer comment to my previous article there is an option to corrent this behaviour but it isn’t enabled by default for some reason. TinyMCE now has support for acronyms and abbreviations (with icons that are easy to understand). TinyMCE would have had a score of 18 if the nesting was fixed.
• XStandard is the only editor that pass all the tests.
• WYMeditor is a very interesting contender. Although in a very early stage of development (only two versions released) it managed to score 14 points. It is also the only editor that clearly displays to the user what type of markup is being edited.
• Loki is one of the few editors that has a proper icon for block quotes (it looks like a quote character).
• Only XStandard and TinyMCE provide functionality to create acronyms.

There are now more editors that provide functionality to do proper semantic markup. This is great! My guess is that it would be easy to add many of the remaining features (acronyms, abbreviations and inline quotes) to many of the editors.

Which one will you be selecting for your next project and why?

EIZO worked closely with the Color Universal Design Organization (CUDO) (also see english machine translation) in conducting experiments with colorblind test subjects to improve the ability to identify difficult to distinguish colors.

Fore those not fortunate to have access to an EIZO monitor, there are a number of software tools available to simulate how web pages and images look with various types of vision deficiencies:

• Vischeck (which you have probably used if you tried the Web Accessibility Toolbar for Internet Explorer.
• Colorblind Web Page Filter – simulates a whole range of deficiencies such as deutanopia, tritanopia, protanomaly, tritanomaly and more.

What I haven’t seen is an application that isn’t confined to the browser, but works on top of your operating system. I guess this wouldn’t be very hard to do. Depending on the operating system it should be possible to have a filter applied to the entire screen. If you know of one, please post it in the comments below.

The tactile objects were developed by art educators who are also active artists, after meticulous studies of the work of art and literature about the artist. One of the paintings represented is Matisse’s Apollo from 1953. It is considered as one of his last great works and depicts the sun god Apollo:

The tactile version of this picture makes it possible to feel the face and the sweeping lines forming the shape of a heart. It is using the same colors as the original to aid partially sighted in experiencing the painting. Looking closely at the the tactile object reveal lines that are raised approximately 0.5 centimeters to enable exploration by hand.

Another interesting feature is that the material used has a different temperature depending on the color. The blue parts feel much colder compared to the red parts. This provides another dimension for those with complete vision loss.

A part of the painting The Engima of William Tell by Salvador Dalí has been represented in a plaster cast. The original depicts Lenin’s protruded buttock being held by a crutch but the tactile object has focused on his foot in the lower part of the painting.

The object contains part of the foot and two nuts visible in the lower part of the painting. In one of the nuts is a model of Gala, Dalí’s wife, which is hard to see in the painting. This is more apparent in the tactile object:

Is it a different experience?

Tiina Nummi-Södergren, head of the Swedish Association of the Visually Impaired sums it up:

You can never replace the lack of vision, but you can try to enable participation as much as possible. If you and I visit a botanical garden we will not experience it in the same way. I will be influenced by what I touch, smell and hear. My inner image will be different from your’s. But noone can say that my experience will be so small that it doesn’t matter.

References

• Feely kit – A tactile tool for the visually impaired, Moderna Museet.
• Art for fingers (in swedish), article in Dagens Nyheter (my translation).
• Tactile pictures. Pictorial representations for the blind 1784-1940, by Yvonne Eriksson, Göteborg University.

If you want to help out with RAAKT testing, please have a look at the online web interface. With it you can test accessibility of remote web pages in a similar fashion to the W3C validator tool. As mentioned previously, one of the design goals is that RAAKT will only test machine measurable accessibility issues. In practice, this means that all web pages should pass all the time, there are no “if applicable” results.

Testing it with Google Labs’ new product Google Accessible Search yields some interesting results. RAAKT reports three errors for the page http://labs.google.com/accessible/.

If you find a bug, please report it at the RAAKT project page. For more information about RAAKT, see the previous entry Automated Accessibility Tests with RAAKT in Ruby on Rails.

Ruby on rails is a great framework for developing web applications. With the increased developer productivity you can put a lot more effort into usability and accessibility. To get started I have created a library (they are called “gems” in the Ruby world) called RAAKT with methods to assert basic accessibility in HTML documents. You will need the programming language Ruby to run RAAKT.

My focus has been to implement machine measurable issues (so no content checking) that never should be present in a document. Other tools give you a massive overdose of checks that end up with results with the wording “if applicable”. In my opinion these do not really help a developer who is new to the field of accessibility.

Currently the RAAKT module will do the following tests on your markup:

• check document structure: Verify that headings are correctly structured (h1 -> h2 etc)
• check tables: Verify that all tables have headers (th elements).
• check for formatting elements: Make sure no font, b, i, blink or marquee elements have been used.
• check has heading: Verify that the document has at least one h1 heading.
• check form: Verifies that all form input fields (except hidden fields) have a corresponding label element.
• check link text: Verifies that all link elements are unambiguous (two links with different targets should not have the same link text. Yes, that means all your edit links in lists). Use the title attribute to separate links.
• check title: Verify that a non-empty title element is available.
• check frames: If frames are used, verify that each frame has a descriptive title attribute.
• check images: Verify that all images have an alt attribute.
• check refresh: Make sure that no client-side meta refresh is present.
• check for nested tables: Verify that no nested tables are present.
• check for language info: Make sure the html element has a lang attribute indicating what language your document is in.

I plan on implementing more checks soon.

Follow these instructions to install RAAKT and test accessibility in your Ruby on Rails application.

Errors in web applications be divided into two groups:

1. Server errors e.g. 404 Page not found and other HTTP protocol errors.
2. Application errors e.g. The ‘Name’ field can not be empty. and other errors that your web based application will present to the user.

This article will deal with number 2: application errors. If you are more interested in server errors I suggest you have a look at The Perfect 404 by Ian Lloyd.

Proposal for accessible error messages

I propose the following requirements for error message presentation in web applications:

1. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
2. It should be easy to understand that an error has occurred.
3. It should be clear what the user has to do to correct the error.
4. It should be clear for the user where the error was found in the form.
5. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
6. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.

I assume you already know how to create accessible forms and styling them properly so that sighted users can understand them. If you need more information about forms, please see the references at the end of this article.

Let’s see what we have to do to comply with the above requirements:

Visual presentation of errors

• Make sure the user can see that an error has occurred. Error messages need to stand out from the rest of the layout. They should be placed at the top of the page if that is the area displayed after the form has been submitted with errors.
• Use an error icon if your layout makes it difficult to visually separate errors from the rest of the page.
• Be consistent when you present errors (the user will expect errors to be displayed at the same location and with the same style on all pages).
• Update the page title to indicate that the user is on the same page but with errors (e.g. if the page title is “Registration” you could change it to “Registration – Error occurred”).

The error message text

• Make sure the error message identifies the related field with the name as it is written in the label for that field.
• Do not use complicated words. (tip: check out Ogdens basic english)
• Describe what the user should do to correct the error, especially if it could be difficult to understand.
• Make it clear if there were more than one error so that the user can correct all errors at once.

Markup of error messages

• Make sure all user agents can parse error details. Use a heading to identify the error area.
• Present each error as an item in a list. This makes it easy for the user to understand what has to be corrected. Also, screen reader users will find it easier to keep errors apart.
• If you use software specific error id numbers (most developers do) do not hesitate to add them to the id-attribute of the li element. If you use automated functional tests (e.g. Rational Robot) it will be much easier for the test robot to parse and identify errors.
• Provide an accesskey for the error message section. This is valuable if your form can generate many errors and enables the user to move back and forth between the error list and the form.
• Make it possible to navigate from the error message to the related field. This makes it easier for users that navigate with the keyboard.

Client side validation

Using client side validation has many advantages. Users can get instant feedback instead of having to wait for a server roundtrip. Server load is also reduced. However, there are some things to take into consideration:

• Never rely on client side validation alone. Only use it as a complement to server side validation.
• Users must be able to submit the form and trigger server side validation even if client side validation failed. Some browsing devices (e.g. screen readers) will not understand that the page has been dynamically updated (with your error messages). This means that users will not understand why the form submission failed. One way of using client side validation is to trigger it when a field loses focus (on the onblur event).
• Be careful when using the ASP.NET validation controls. By default ASP.NET will prevent form submission until the form is valid. For information on how to allow form submission with errors see Disabling Validation for ASP.NET Server Controls.

An example

Enough talking, let’s look at an example:

The markup for this sample error section with two errors looks like this:

<div id="validationerror">
  <h2 id="errorsummary">2 errors were found in your registration.</h2>
  <p>Please correct these errors and submit the form again:</p>
  <ul>
    <li id="er_128">
    <a href="#name" onclick="setfocus('name')">
    The Name field can not be empty.
    Please enter your name.</a></li>
    <li id="er_215">
    <a href="#age" onclick="setfocus('age')">
    The Age field can not be empty.
    Please enter your age in years.</a></li>
  </ul>
</div>

Clicking the validation error link triggers this simple javascript function:

function setfocus(objectid) { if(document.getElementById(objectid)) { document.getElementById(objectid).focus(); } }

Click here to see the complete validation error example. Evaluating the result can be done by looking at the personas from Mark Pilgrim’s excellent Dive into Accessibility. If you do not have access to a real test panel using personas is the next best thing.

Update: Reader Tanny O'Haley suggested that the label element should be used instead of setting focus with javascript. See details in comment 9 and 10 below.

I would be very happy for your comments and suggestions.

References

1. Accessible form validation errors (WebAIM forum discussion).
2. Disabling Validation for ASP.NET Server Controls.
3. Client-Side Validation for ASP.NET Server Controls.
4. IBM Accessibility center – Indicating required fields.
5. Cross browser CSS :focus by Paul Griffin. Describes how you can use the focus pseudoclass in Internet Explorer (not used in the example in this article).
6. AJAX and Accessibility.
7. (about server errors) The Perfect 404 by Ian Lloyd.