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

Imagine if you could not see the image. What would you write in the text field? The phrase “you inaccessible idiots” spring to mind…

Captchas are often used to prevent automated mass registration of accounts to online services such as web mail, site forums and auction sites. A problem with captchas is that they tend to be inaccessible for all users that can not see the test image. In the article Inaccessibility of Visually-Oriented Anti-Robot Tests, Matt May from W3C takes a look at some of the issues that face internet users today.

This article is also available in Japanese.

In this article we will take a look at some of these issues and propose a solution for a captcha that improves accessibility.

Requirements for a Captcha

I propose the following requirements for a decent captcha:

1. The test should be accessible for as many users as possible regardless of culture, age and impairment.
2. The server software has to be able to create a test instance efficiently. A test instance should be able to create automatically without human intervention.
3. The server software has to be able to calculate the test result easily.
4. User privacy must not be invaded. No one would like to send personal details just to register on a discussion forum.
5. It should be difficult for a non-human to deduct the answer to the test.

We will come back to these requirements in a short while.

A Proposed Solution

Some of the solutions proposed in the W3C article are:

1. Use logic puzzles. This solution does not satisfy requirement 2. It would require someone to manually create these tests. Also, they would probably be difficult if you have a cognitive impairment.
2. Use credit card validation. Brilliant idea. Everyone would be happy to submit their credit card number to unknown sites on the internet.
3. Live operators. Fails on cost efficiency. Although it would be one of the best ways to provide support for your users, a lot of sites do not have the resources to provide this kind of service.
4. Federated identity systems. Well, this does not exist yet so we can not use it.
5. Sound output. If it could be possible to create a sound file that was difficult to decode for a machine, this may be the best option to use together with a regular captcha image. Let’s move forward with this solution.

First of all I suggest that you thoroughly evaluate why you need a captcha. Is it really necessary? A lot of sites implement them because it “looks professional”. If you can avoid captchas, please do so.

My proposed solution is based on an ordinary captcha image in combination with an audio based test. Instead of providing the same information in the audio file as in the test image (like the Hotmail registration form) we will use a separate test. This test is based on the ability of the human brain to understand the meaning of information as well as discard unnecessary details.

The captcha would look like this:

1. On the main registration form a regular captcha is presented just like before. Users that can see the image may use this test. A link informs users that there is an alternative test.
2. Clicking the link leads to the audio based test form. This form provides access to an audio file and three input fields. The audio file contains three numbers that the user has to enter into the fields.

The Structure of the Audio Clip

In order to make it hard for machines to parse the numbers from the audio clip we use a combination of methods.

First, the text in the audio file varies between test instances. This has no effect on a real user (who will only listen to a test instance once) but requires a computer to be trained on many different samples. Test instances could look like this:

• “Here are the three numbers: 12, 51 and 9.”
• “First number is 12. Second number is 51. The third number is 9.”
• “12, 51, 9. Those were the three numbers.”

Since there may be numbers in the surrounding text (e.g. “Here are the three numbers”) it is difficult for a computer to understand which of the numbers that should be used.

Second, if these instances are spoken with different voices it becomes even harder to create a speech parser.

Enough talk. How would it look in real life? Click here to see/listen to a sample test.

Why This May Work

It is easy to automatically create a massive amount of test instances thereby satisfying requirement 2 above. See my sample application in the references section below.

Using a limited domain of a language (numbers) we make it easier for users that do not use English as their primary language. Numbers are typically one of the first things a person learns in a foreign language.

For a human it is easy to extract the three separate numbers from the information in the audio file. This is harder for a computer that has difficulties knowing if there are three or four numbers in the string “Here are the three numbers: 12, 51 and 9.”

Evaluating the Solution

Let’s evaluate this approach to an accessible captcha by looking at the personas available at Dive Into Accessibility. If you do serious accessibility work it will do you good to use these to evaluate your work from time to time.

Jackie is a blind 19 year old woman using Jaws to read web pages. She will have no trouble using the audio based test as long as the input form is readable by Jaws.

Michael is 27 years old and colorblind. He is using a slow modem connection to browse the web without images. If you make sure that the first registration form contains a text notifying the user that images are required for this form he can turn images on for this page. Also, please make sure the captcha image does not rely on colors.

Bill has suffered a stroke and is using the keyboard to navigate the web. He should have no problems using the image based captcha test as long as the tab order is set properly on the input form.

Lillian is 54 and has poor vision. Her native language is Cantonese and she as trouble with advanced English. She uses Internet Explorer to browse the web with javascript turned off. Lillian will be able to use the image based captcha provided that the image is big enough. If she used the audio version she probably knows enough English to understand numbers. By not using javascript to open the audio test page she can access the page and audio file without problems.

Marcus is blind since birth and uses Lynx with a Braille reader to browse the web. He hates Jaws as he wants to listen to radio while browsing. If the registration form informs Marcus that he has to listen to an audio clip to complete the registration Marcus can use the audio based captcha.

It looks like this can work. So, let’s go through the requirements for a captcha we discussed earlier:

1. The test should be accessible for as many users as possible regardless of culture, age and impairment. Evaluating the test with the personas above it looks like this is ok. I have also done an unscientific test using three relatives with varying computer literacy (Hi Mom!). No one of the test subjects had difficulties passing the test.
2. The server software has to be able to create a test instance efficiently. A test instance should be able to create automatically without human intervention. Using the Microsoft Speech SDK I have created a sample dotnet application that can create test instances easily. With this application it is easy to generate thousands of audio files quickly. For details, see this screenshot of the captcha audio generator. If you want to use open source products, it would be easy to do the same in Java using FreeTTS (check out the Alan voice for numbers).
3. The server software has to be able to calculate the test result easily. Generating test instances with my captcha audio generator also creates a table linking audio files to the numbers the user is supposed to enter. It would be easy to use your programming language of choice to validate user input with this data.
4. User privacy must not be invaded. No one would like to send personal details just to register on a discussion forum. Nothing personal submitted here.
5. It should be difficult for a non-human to deduct the answer to the test. I have tried acquiring text from the audio files with Dragon dictate. It had severe difficulties interpreting the computer voices. It also requires a lot more processing after converting it to text to know what goes into the separate fields.

To further complicate things it is possible to mix other sounds into the audio files.

What do you think? Any suggestions or ideas? If you think the Captcha Generator application is useful, do not hesitate to develop it further.

References

1. Inaccessibility of Visually-Oriented Anti-Robot Tests by Matt May.
2. FreeTTS is an open source speech synthesizer written in Java.
3. I wrote a captcha audio generator to make sure it was easy to generate a large number of test instances easily. Download the Visual Studio dotnet 2003 project files for more details. The download also includes a compiled version. Please note that you have to have the dotnet framework and the Microsoft Speech SDK installed for it to work.
4. Dive Into Accessibility personas by Mark Pilgrim.
5. For an advanced text-to-speech SDK see AT&T Natural voices SDK.
6. An alternative to pure speech is to have a synthetic voice singing the numbers. This would be virtually impossible to decode in software. If Vocaloid was scriptable this could be possible to do.
7. The Festvox text-to-speech platform.

Several other articles have proved insight into the proper format of the page title tag. Thus, we won’t go into the details about the format here but accept some “best practices” to take into consideration when constructing the title tag (for references see the end of this article):

1. The separator character should be distinct so that users understand that it is a separator. (I.e. it should not appear as part of text items in the title).
2. If the title contains the name of the site, the name of the site should be placed at the end of the title. This makes sure that multiple bookmarks from the same site are easy to browse through in the bookmarks folder and listeners to your page get the most important information first.
3. Use a favicon to help sighted visitors group multiple bookmarks from the same site in their browser.

To help you select an accessible title tag separator I have created a table of commonly used separator characters below and recorded the ouput from JAWS:

Observations

• As you can hear, the use of the right double angle bracket character (») forces the listener to endure a lot of garbage. Therefore it is best avoided.
• The sound of “special” unicode characters such as → (→) and ★ (★) depend on the setup of the listener’s computer. If the browser is unable to decode the character it is likely that the output will be a questionmark which in turn will be read as question (notice the intonation). If no preceding space character exists the entire sentence will be pronounced as a question which may alter the meaning of your text. If the characters are decoded correctly they seem to fall outside the scope of readable Jaws characters and end up as a short pause between words.
• Repeating characters will repeat the sound in JAWS. A worst case scenario would be the use of multiple »’s.
• Almost all browsers add the browser name (e.g. ” – Microsoft Internet Explorer”) at the end of the title. This text will also be read by JAWS. Most JAWS users know how to skip that part when they hear the “dash Microsoft…”, but this could be an incentive to refrain from using the dash character as a separator in your title tag.

Picking the winner

Prime candidates to use as separators are the vertical bar (|), the dot (·) and the dash (-). My experience is that screen reader users understand that the vertical bar delimits items. The dash is OK even though it may appear as part of your title text. Usually the context of your text provides enough information for a listener whether to treat the dash as a separator or not.

Other characters can also be used, but pick one which sound is unlikely to appear as part of the text in the title. E.g. do not use the bullet character if you write about guns and ammunition. (This would be an argument against the “vertical bar” if you are into designing cool drinking establishments).

Regardless of the character you pick, it is important to surround it with whitespace. This will aid both sighted visitors and listeners as it will distinguish the character from the title text.

I hope this article has provided you with some inspiration to create more accessible document titles for your websites/applications. Obviously, it would be best if screen reader manufacturers could create software that was compliant with the aural features of CSS in which case styling of web content could move to an entirely different level.

If you miss your favorite sepratator character above, create a comment and I will add it.

References

1. Jacob Nielsen, Microcontent: How to Write Headlines, Page Titles, and Subject Lines
2. Adrian Holovaty, Page titles on news article pages
3. Roger Johansson, Document titles and title separators
4. Jonathan Snook, The Usable Page Title

[Update 2004-10-25: After writing this article I found an almost identical approach at WebAIM.]

One can understand the difficulties facing makers of screen reading software. Few websites look the same and as we all know, the web is nowhere close to following modern standards. Creating software to linearize the information in a webpage that uses javascript, table layouts and image based menus is no easy task.

This is why I can understand why Jaws does not read any text within an element with a style attribute of display:none. If it would, all sites with dhtml-based drop-down navigation would take ages to listen to as Jaws would have to read the entire menu.

Why is this a problem?

Well, since you are here reading this my guess is that you, like me, are interested in accessibility. If that is the case you are probably interested in making sure your listening visitors enjoy your website as much as those with a regular browser. If you provide complex information structures or your site is more like an application you will find a need to provide special information for your listeners. This information should not be visible on a screen but still exist in the proper context within the rest of the information.

One exmaple is to provide a descriptive h2 heading for the content in the right column of this website. A listener could then get information that the content is the same for every page. If this information was not available a lsitener would have to listen to the right colum on a few pages before deciding that that content can probably be skipped.

A stab at a solution

Since we are fond of the pragmatic approach to accessibility and web standards, lets create a CSS class that let’s us:

1. Hide the text from the screen without using display:none.
2. Place the text in the proper context so that it makes sense.
3. Keep the rest of the layout intact (i.e. the text should not occupy any screen space).

Let’s call this class “aural text”:

.auraltext
{
   position: absolute;
   font-size: 0;
   left: -1000px;
}


It should be fairly obvious to everyone what this CSS class does. It makes sure the content is moved off the visible area of the screen.

So, do you have any areas for your website/application that you need to clarify?