The basic limitations encountered with AJAX are threefold:

• Discoverability of Functionality
• Usability of said Function
• Discoverability of Function Feedback

Best practice in any rich media format should always ensure that these three limitations are dealt with for all users.

Discoverability of Functionality

The first challenge is to simply be aware that additional functionality is available. Discovering that a box is draggable, that a text field is editable, or that an image can be annotated requires some form of user notification. With some applications (like Flickr, for example) the richness of interaction means that it is very difficult, practically speaking, to visibly label every possible interaction.

The usability issue is divided between two problems: either you don’t label every feature, or you overwhelm the design and the user with information. A page which is utterly coated with “Edit this,” “Drag that,” and “delete these” is not particularly more user friendly than a page devoid of labels, where actions require experimentation to be discovered.

The most common solution is through varying uses of tool tips, subtle graphic indicators, and other changes triggered by the mouse hover action. These solutions, while very effective for experienced, traditional users, are highly problematic for many others. People not using a mouse will never see them. Have you ever tried to use Flickr with only a keyboard? This is not a successful experience. Most functionality is completely lost to the keyboard navigator.

Some possible ways to solve these issues include limiting the use of AJAX functionality, so that you can clearly label all functions without cluttering the information display. This is a start, and will certainly be of use to sighted, mouse-using visitors, but doesn’t really cover all the bases.

The most effective method is to provide the option to enter a more traditional editing interface. Provide your AJAX methods, but also include a single “Edit” link (for example) which switches the user into an editing mode. This can enable all of the editable fields, and provide a standard method for inputting changes. Do not only provide this when Javascript is not available, however — it is a devastating error to assume that the only people needing assistance with AJAX functionality are those for whom Javascript is not available.

Usability of Rich Media Functions

Naturally, the previous subject did bleed over into this one. Division of concepts in the user interface realm is not exactly clean, as every decision is liable to impact multiple areas. Nonetheless, there are many issues of usability with rich media which require their own discussions, assuming that whatever function is provided has already been discovered.

The biggest issue, and the most obvious, is that many rich media functions are triggered by mouse-specific commands. “Hover” or “Drag” are interface methods very easily embraced by a mouse user and completely unavailable to a keyboard user.

The fallback method can be to provide an alternative interface for all editing, of course, as described above. However, as much as possible, you should attempt to integrate alternative methods to provide an optimal experience for all your users. Function triggers should be:

• Keyboard focusable
• Described in a manner which allows for multiple uses
• Described in a manner which specifies what will happen

I wouldn’t say that you should discard your draggable, rearrangeable layout. You should, however, provide the option to rearrange the layout without a mouse. A set of keyboard selectable “Up-Down-Left-Right” arrows is a common and easily understandable approach.

Making certain that a function is possible to use for keyboard or screen-reader users is relatively trivial — consistently using anchor elements or form controls to trigger events will make that functionality pretty reliable for most users. One remaining user group which may experience difficulties is mobility impaired users.

One difficulty of trying to incorporate numerous interface elements into a space is that, inevitably, the trigger elements become smaller and smaller. This can have a significant impact of mobility-impaired users. Making certain that elements are keyboard-accessible and have strong :focus states will help.

Discoverability of Feedback

For visual users, this is usually not a great challenge. Exceptions might include low-vision users who require substantial magnification or who are affected by a disease such as Retinitis pigmentosa, a disease characterized by tunnel-vision. Either of these situations can make it difficult for the user to discover changes in the page which occur outside their limited viewable area.

To make the feedback obvious and effective, some thought is still required, of course. Feedback should be clearly separated from the rest of the page; such as through an overlay technique. It should always be visible in the current viewscreen — changes made outside of the currently viewable area should still be reported in a visible location. Subtlety isn’t really all that valuable: focus on understanding, first.

For aural users, this is a huge challenge. Not insurmountable, necessarily, but certainly a major hurdle. Gez Lemon covers the problems with providing focus in screenreaders in detail in his article “Making AJAX work with screen readers.” The problems are numerous, and different for each major screen reader user agent. What it comes down to is that, at the time these tests were performed, there was no reliable and consistent way of notifying screen readers that a change has occurred.

This is a big disappointment. The conclusion reached by many is that AJAX functionality is, for the moment, beyond the realistic reach of screen reader users. This isn’t precisely accurate; since I’d argue you can still possibly make use of functions where the result of the function is patently obvious from the description of the function; however, you’d need to allow error messages to be handled using non-AJAX methods.

Fundamentally, in order to provide accessible interactions for a non-visual user, you need to provide a non-AJAX response. It will need to require a page refresh, and use in-page anchors to send the user directly to the relevant response message or a prominent link which will direct the user to that message. A clear statement about what has changed is absolutely required.

Additional Articles and Resources on Ajax Accessibility

• WebAIM: Accessibility of Ajax Applications
• Becky Gibson, IBM: Ajax Accessibility Overview
• James Edwards: Ajax and Screenreaders: When can it work?
• Gez Lemon: Making Ajax work with Screen Readers
• W3C: Dynamic Accessible Web Content Roadmap
• W3C: Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
• Max Kiesler’s List of AJAX and Accessibility resources.

Accessibility and Usability issues with AJAX
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Netflix doesn’t yet have a particularly extensive collection in their instant viewing treasure trove, but it’s certainly substantial enough to provide items of interest for most audiences, with about 2,000 videos to watch across genres.

I watched a 45 minute television program at full screen on a monitor with 1400 by 900 pixel resolution. During the course of the viewing there were:

• 0 sound glitches
• 0 video glitches

The video quality was very acceptable for a TV sitcom. I’m not sure that I’d find something more exotically special-effects driven to be quite so satisfying, but that’ll have to be another test later! The relatively simple camera work and audio work of “Ballykissangel” were just fine.

The time between hitting “Play” and beginning to watch the video, including the download and install time for the Netflix video player was approximately 2 minutes.

Sweet. Now, if only Netflix.com were an accessible site…

Netflix: Instant Viewing
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

From “IBM Helps Blind ‘See’ Video, BBC News:

Using the A-Browser, a vision-impaired person can control media content by using predefined shortcut keys, rather than having to look for the control buttons using a mouse.

The browser also allows video to be slowed down, speeded up and can accommodate an additional audio description or narration track that is often included to make films and television programmes more comprehensible to blind people.

The volume controls also allow the user to adjust the sound of various sources independently – for example the main audio track, an audio description track and output from a screen reader.

Obviously, the product isn’t yet unleashed for world-wide testing; but it is available for speculation! I’m not sure exactly how much extra functionality this will add when a user is encountering video without audio description or a narration track, but the simple fact of making existing resources more usable for users with visual impairments is a good start.

IBM Building Accessible Multimedia Browser
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

What isn’t so easy is to make these videos accessible. Video has a number of glaring accessibility problems. There’s nothing especially complicated about these issues — they should be obvious, after all — but accomplishing them at all seems to be beyond the pale at the moment. It’s not that it’s difficult to make video accessible. It’s not that the software to do it, at least in a limited manner, is expensive or difficult to use. It’s mostly two issues: laziness or ignorance.

What are the basic problems?

• The blind can’t see videos. Audio description of the events is required.
• The deaf can’t hear the audio tracks accompanying video. Text description of the audio content is required.
• Video content may feature flashing images or text: videos exhibiting these behaviors should carry warnings for individuals with epileptic photosensitivity or other related problems. (Not really the main focus of this article; but important to mention.)

I’m sure there are additional, more subtle issues that can be raised, as well, but if these three are dealt with we’ve accomplished the fundamental goals.

Why might people skip video accessibility?

The time involved in preparing transcripts and captioning can be substantial, and that may slow down some potential video creators. That’s laziness. I choose to believe that this is the lesser of the two issues: I’m optimistically hoping that most people who are aware of the accessibility issues and care about it will take the time and effort to make it happen. I think the awareness issue is far greater.

Some people will make the assumption that disabled populations won’t be interested in resources which feature aspects related to that person’s impairment. They are ignorant of what interest impaired populations may have in the aspects of that resource which they can access. A visually impaired person may never see you. Does this mean they won’t want to talk to you? No — just don’t expect pointing to be a useful to them. Pointing is a visual gesture: you need to provide audio description of your own actions in conversation. It’s the same in video. The visual elements may not convey any information to a person with a visual impairment, but appropriate audio description and the audio track may still convey all the information that person needs.

A lack of technological awareness is part of the problem: but I think that the greater issue is a lack of social awareness. Once a video resource creator can understand how important accessibility is, the technological barrier is minor. Information on captioning, audio description and transcribin is readily available.

I think I can understand when a site like YouTube fails to supply all of these accessibility options. The problem with user generated content in video is that the burden of responsibility for these accessibility features falls on the user. The average bedroom webcam self-recorder doesn’t have the knowledge or the capacity to prepare appropriate synchronized captioning or audio description.

But that doesn’t excuse it in other sites providing embedded video.

A few resources on Video Captioning:

• Steve Pugh: Video Accessibility
• University of Wisconsin at Madison: Accessibility Videos — A nice collection of videos on accessibility: transcripts provided and captioning included.
• WebAIM: Adding captioning in Quicktime
• WebAIM: Adding captioning in RealPlayer
• WebAIM: Adding captioning in Windows Media Player
• WebAIM: Video captioning software
• University of Washington: What is audio description?
• Joe Clark on Captioning

Video Accessibility Problems
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design