Web Accessibility Research Blog

Our WebAnywhere web-based screen reader is getting closer to its Alpha release set for May 2008.  Please check out the video below to see it in action.

(view the full-size video - 211 MB)

A new non-profit has taken on the task of making web access available to everyone.  Specifically, it is providing the web version of System Access to Go (SA to Go) free!  This is an incredible thing.  It solves many of the problems that we're trying to solve with our own WebAnywhere project.  With access to both systems, blind web users will be able to access the web from almost any computer out there without having to install an expensive screen reader or carry around a USB drive.  Also, while not the target, it seems that web developers could also take advantage of this free and convenient access to a screen reader to check the accessibility of their own web sites.  What an amazing thing!

Visit:
http://www.accessibilityisaright.org/

Also, here's the short press release about it:

Orlando, Florida - January 31, 2008 - The AIR Foundation, a nonprofit organization headquartered in Minneapolis, Minn. was announced today at a press conference held during the Assistive Technology Industry Association (ATIA) 2008 National Conference at the Caribe Royale Resort in Orlando, Florida. The mission of the foundation is to promote universal accessibility so that every blind and low-vision person in the world has access to digital information over the Internet and Worldwide Web.

Headings seem so 1994.  When I was first learning HTML, I remember using the <h1> tag when I wanted text to appear large, <h6> when I wanted it tiny and when I wanted it somewhere in between then I'd use <h2> - <h5>.  But, as anyone interested in accessibility know, it turns out that these tags have an important semantic use - to organize content into an outline to make pages easier to navigate.  This is particularly important for users navigating with a screen reader for whom the content might not have been designed.  For this group, it is vital to provide some sort of outline so they don't have to read through content from top to bottom.

But just using headings isn't enough.  As mentioned, they are valuable because of the semantic structure they lend to otherwise unstructured content.  You need to make sure the semantic meaning you convey with your headings is correct.  To understand the best practice of headings, it's useful to think about how a screen reader user might use them to assist in navigating a page.  Both Window Eyes and JAWS offer similar commands to navigate through headings on web pages (see the JAWS web shortcuts and Window Eyes shortcuts).  Users have the option press 'h' to jump to the next heading of any level on the page or can select headings of particular levels by pressing '1' through '6' (in Window Eyes this must be followed by the 'h' key).  Additional functionality allows users to jump to the first heading.  It can seem like this wouldn't be a huge benefit to users, but without structural notation like headings, a web page seems like a huge blob of text.  Users can skip around in this text, but headings provide a way for web developers to logically specify the skips that make the most sense.

User studies by Watanabe et al. have demonstrated the effectiveness of using heading elements and the anecdotal of blind users we know support this.  There is absolutely no reason not to add these!

Heading Guidelines

The first rule is that no heading tag except <h1> should be added until the larger sized tag has been added.  For example, no <h3> before <h2> and no <h2> before <h1>.  The second rule is that there should be only one <h1> per page.  Finally, only a heading with a level <= n+1 may be the level of the heading that immediately follows a heading with level n.  This means that after a <h3> may come an <h2>, <h3>, or <h4>.  A <h1> would be allowed, but only one is allowed per page.

These rules serve only to enforce that the web page looks like an outline.

Making Them Look Like You Want

So, what's the proper way to put headings on a page?  As mentioned, in 1994 I chose heading levels based on the size of the font that I wanted to produce.   Fortunately, with the arrival of CSS, we can choose the heading level that actually makes sense, regardless of its size, and then size it to fit with our desired visual style.  Below are a couple of examples of how to override the default style of a heading element with CSS:

Non-block level display

This makes headings appear as inline elements, meaning there won't be a new line after each one.
<h2 style="display: inline">My Heading</h2>

Changing Size

By default, the heading level changes the look of the font in the heading, such as the size or weight. These can be changed easily.
<h2 style="font-size: 1em">My Heading</h2>

The Firefox web browser provides an incredibly convenient platform for web interface research.  Writing a plugin/extension for Firefox is as simple as cobbling together some xml and javascript - a task that requires one to wade the treacherous waters of COM and the BrowserHelperObject to replicate with Internet Explorer.  From an accessibility perspective, Firefox extensions are relatively straightforward to make accessible to screen readers that support Firefox.

The XML that defines your interface is your XUL files and the Mozilla Developer's site provides a great document for making XUL accessible.  You'll notice many of the issues are the same as they are with HTML:  provide alternative text for images, associate labels with the form elements that they describe, assign a reasonable tab-order, etc.

Making Firefox extensions is a powerful way to quickly try out new research ideas and because of the efforts of the folks at Mozilla the environment is appropriate for accessibility research.  Most importantly, developing an extension for Firefox, as opposed to a custom solution, means that it can get out to the users to whom it is targeted with little overhead.

Last week I had the pleasure of attending ASSETS 2007 in Tempe, AZ.  In this article, I'll summarize the work related to accessibility that was presented here:

aiBrowser

The fine team from IBM Japan presented two paper that dealt primarily with Flash accessibility. "Automatic accessibility transcoding for flash content" and "Aibrowser for multimedia: introducing multimedia content accessibility for visually impaired users". Both of these papers discuss aspects of the aiBrowser. From my perspective, some of the most amazing aspects of this work are the following: 1) unification of the DOM of web pages, including frames, and any Flash movies on the page, 2) automatic transcoding of Flash content by intercepting it before the browser renders it, 3) interface to control JAWS screen reader from the self-voicing web browser, 4) independent control of screen reading volume and volume of web page content (Flash). Check out the aiBrowser if you haven't.

WebinSitu

Next came our own work, "WebinSitu: a comparative analysis of blind and sighted browsing behavior." The main points of this work is that we quantitatively showed that blind web users are less efficient in their usual web browsing than sighted users and the accessibility of the content of web pages directly influences their behavior. For instance, blind web users don't click on images without appropriate alternative text assigned to them and avoid pages with dynamic content/AJAX. This study brought up more questions than answers and we hope to conduct more studies along these lines in the future.

Evaluation of Pages

A couple of papers by Giorgio Brajnik et al. dealt with evaluation of the accessibility of web pages. The first, "SAMBA: a semi-automatic method for measuring barriers of accessibility" explored how to include subjective evaluation of pages by experts into evaluation procedures, which seems a good direction. The second, "Effects of sampling methods on web accessibility evaluations" dealt with how the pages chosen for accessibility evaluation can affect the results of that evaluation. In general, I find automated evaluation to be the wrong direction because its difficult to represent in an automated process the true function representing accessibility. Such methods will be with us, however, until all developers are skilled accessibility experts. This work can help them work better and, in that sense, is valuable to the community.

Summary

ASSETS continued this year as a premier venue for discussing web accessibility research. Here I've only reported on the full papers that were submitted, there were also a number of interesting posters presented during the poster session.

A great way to test to see if your web page is accessible is to use a screen reader to try it out.  WebAIM has a great article about using a screen reader to test accessibility. One of the goals of our WebAnywhere project is to provide a low-cost, self-voicing web browser web application.  That's a mouthful.  Basically, we want anyone to be able to come to a web page and have that web page provide all the functionality that they need to browser other web pages.  One of the uses of this will be to provide web developers with a low-cost way to see if their sites are accessible.  As a "side benefit," we'll also be enabling access to the web for blind users from the huge number of computers that lack a traditional (expensive) screen reader.

I don't normally use a screen reader, but I've observed many people using one over the past few years. Initially I was amazed by how incredibly fast experienced screen reader users are able to navigate between open windows and get things done. Because most screen reader users don't use a mouse, they are forced to learn the keyboard commands and end up being much more efficient than someone that remains a slave to the mouse. Surprisingly, most of this keyboard functionality is available in regular old versions of windows. It's incredibly useful and can make anyone a more efficient computer user.

The first step is to learn the keyboard commands for getting around in Windows. These range from using ALT-TAB to switch between current windows to the using combinations of CTRL, SHIFT and the arrow keyes to navigate and select within text editing windows. Microsoft has a comprehensive summary on shortcut keys to navigate windows here: Microsoft Guide to Windows Shortcuts. And a good article on using keys once in a program is located here: Mr. Hope's Guide to Shortcut Keys.

The next step is replacing the mouse altogether. For instance, did you know that SHIFT-F10 simulates a right click? For more useful information, check out the keyboard alternatives for using a mouse here: eHow's Guide to Keyboard Alternatives to the Mouse.

Follow these guidelines and you'll be surfing as fast as a screen reader user in no time!

-- Jeffrey P. Bigham

In an informal meeting with one of our resident blind computer gurus, we were interested to learn that Amazon.com, the behemeth of online book sellers, offers a separate site called Amazon Access designed to be more accessible than the average amazon.com complexity soup.  This was interesting, at least in part, because Amazon has become well-known in the accessibility community as the contractor responsible for target.com, a web page subject to an on-going lawsuit that may end up defining the responsibility of commercial web pages to make their content accessible.

A separate, accessible site sounds like a reasonable idea at first.  Making the complex mess that is the current Amazon homepage accessible would be incredibly difficult, although one has to wonder if maybe that should tell them something about the quality of that design.  A separate-but-equal approach can be acceptable (and even desirable) if the separate sites rely on the same underlying database, which would seem reasonable.  As is so often the case with a separate-but-equal approach to accessibility, however, we recently found that Amazon Access is not equal to Amazon.com.

The screenshots below shows the search results for the phrase "Programming in C" on the two sites.  Amazon returns the popular programming guide as its first result, whereas Amazon Access does not place this result in the top 10.  Amazon Access lists the book, however, as we found when we searched for it by the author's last name instead.  They're using a different (arguably inferior) search algorithm for the access site.

Amazon Access Results

Amazon.COM Results

Perhaps worse is that the prices for the book on the two sites are different!  As the screenshot above attests, it originally seems as though the price is more expensive by about $20.  But, if you click through to actually purchase the book, you'll find that you can buy it for about $3 less on Amazon Access than on the regular Amazon page.  Is this some sort of discount for accessibility users?  No, turns out that the cheaper price is available through one of Amazon's partners, but the page for the book doesn't indicate this, making it seem as though the book is coming from Amazon.com.  So what's wrong with that?  For one, despite their accessibility failings, Amazon has a reputation for quality service and that's what I think I'm buying if I use Amazon Access.  I don't expect to be subject to the service of whatever random fly-by-night shop that happened to partner with Amazon when I order from Amazon!  More practically, Amazon offers great shipping prices, while their competitors usually don't.  Super saver shipping is often free on Amazon.

Amazon Access seems like simply a misguided attempt to shoehorn Amazon's existing mobile web platform Amazon Anywhere into something that could fit accessibility needs.  With different results, different prices and different companies, the sites can't really be said to offer the same content.

Check back here soon for a pointer to an Accessmonkey script that will fix some of the problems on the regular Amazon site.

One of the projects being pursued by the WebInSight Group is Accessmonkey, a new approach to improving the accessibility of web pages that removes the current reliance on web developers.  While many attempts to improve accessibility target developer education or the creation of new client tools for overcoming automatically deficiencies, Accessmonkey seeks to enable anyone to make content more accessible after it has been produced and make improvements available to anyone else that views it, including the developer of the site!

We're currently collecting examples of web pages whose accessibility could be improved on our handy accessibility improvement form.  When you're browsing the web and encounter an inaccessible web page, report it on our form and, when possible, we'll write a fix for it and publish it for use in our upcoming release of the Accessmonkey browser plugin.  Our goal is to isolate those problems that occur frequently and produce accessible tools that will allow users (whether blind or not) to fix them.

For more information about the Accessmonkey approach to improving web accessibility, please visit our Accessmonkey Project Page.

- Jeffrey P. Bigham

As a researcher investigating web accessibility for blind users, I occasionally find myself mailing out braille and large print materials destined for user study participants.  Today, I decided to see if I could utilize the USPS Free Matter for the Blind to send participants from a recent study a note (in braille) along with a compensation check.  Below I describe my experience:

Having recently conducted a remote user study with blind web users, I prepared to send them their compensation for their participation by writing them checks.  I haven't found a convenient way to braille checks so I described the contents of the check in a text file and then printed them out in both braille and large point font.  When it came to mailing them, I decided to try out the U.S. Postal Services "Free Matter for the Blind" service which is supposed to allow material destined for blind folks to be sent for free.  I was surprised to find out that using this service you can theoretically even send mail internationally.

Having not used the program before, I first called the post office to see if my material qualified.  One local post office had not heard of this program and advised me to call a national number, (800) ASK-USPS.  I called this number and was told that my material qualified but I would have bring it to my local post office to get it approved.  The postal worker at my post office was willing to help, but but she did not know the specifics of how the program works.  We spent about 10 minutes looking through a large book of postal code and eventually found the relevant section (Section 703.5).  We found that

"... matter may be entered free of postage if mailed by or for the use of blind or other persons who cannot read or use conventionally printed materials ..." providing that the material is "reading matter in braille or 14-point or larger sightsaving type ..."  on the condition that "the matter must be for the use of a blind or other physically handicapped person."

I was confident that the "matter" I was sending conformed to these rules, but the postal worker was still unsure and took one of my letters to a back room to call the central office for verification.  Ten more minutes passed until she returned to tell me that my letters did not qualify because the checks included in my envelopes used a font smaller than 14 point.  I argued a bit, explaining that the people receiving this letter would not be able to read that text and that was exactly why I had included the braille and large-print versions as an extension to this check that would be accessible.  I asked her if she had explained it to the person she had called in this way and she said that while she hadn't explained my situation precisely as I restated it, she had wasted enough time on this and would not call him back.  She gave me a phone number and suggested that I call the main office myself if I still disagreed.

I called the main office and somehow in a city the size of Seattle managed to reach the same person that had advised the postal worker which had originally asked the question.  I explained the situation again and he said that he would need to do some research to see if I qualify.  Furthermore, he needed to attend to a conference call and he would phone with the answer as soon as he found it.  I have yet to receive this call, but will update this blog when and if I do.

Conclusion

Both the postal workers and their supervisors both at my local post office and the central offices that I was instructed to call were largely unaware of the USPS Free Matter for the Blind program and interpreted its provisions in confusing and contradictory ways.  While my situation could be viewed as odd in that I was mailing a check along with braille and large-print material, someone wanting to mail only braille or large-print material would still have been subject to a 20 minute wait.  This can be particularly uncomfortable in a post office where frustration with long wait times is already common.

My conclusion is that someone willing to invest enough time may be able to save on postage when mailing braille and large-print material, but doing so is unlikely to be worth the effort.

-Jeffrey P. Bigham