2006 Conference General Sessions

YAHOO! EXPERIENCES WITH ACCESSIBILITY, DHTML, AJAX IN RICH INTERNET APPLICATIONS

 

 

Presenter(s)
Victor Tsaran
Yahoo! Inc.

Presenter #2
Nate Koechley
Yahoo! Inc.
701 First Ave.
Sunnyvale, CA 94089

Day Phone: 408-349-6387
Email: natek@yahoo-inc.com

Introduction

The Internet is in the middle of a dramatic shift from static to dynamic web sites. Many of these sites (collectively called Rich Internet Applications, or RIAs) are beginning to offer rich functionality previously found only in desktop-based software applications. This evolution of online interfaces presents a series of new challenges to those committed to and dependent upon accessibility. On the desktop, accessibility is maintained through interfaces that accept keyboard or mouse input interchangeably, and through Operating System-level (OS) Application Programming Interfaces (APIs) that facilitate detailed and continuous communication with available Assistive Technology (AT). In the browser, on the other hand, rich interfaces are too-often overlook (and sometimes block!) keyboard controls. To make matters worse, what primitive AT communication there is bypasses the OS’s API and is shared too infrequently.

 

This paper will talk about challenges of RIA accessibility, and offer a series of four approaches that, in total, can make these modern interfaces more accessible.

 

On the Desktop

Desktop applications such as e-mail clients, word processors, and multimedia applications are used successfully by users reliant on AT such as screen readers and screen magnifiers. Technologies and OS API’s including Microsoft’s MSAA, Sun’s Java Access Bridge for Windows, and open source ATK for Linux have allowed developers to communicate effectively with AT.

 

On the desktop, these technologies allow the AT to receive a detailed description of an object (e.g., name, role, type, state, location …) without relying on visual information rendered onscreen. Furthermore, industry leaders including IBM, Microsoft, and Sun Microsystems have each released implementation guidelines in support of more accessible implementations. Thus, accessibility in software applications is, if not omnipresent, possible at the very least.

 

The Problem

Web sites have started replacing or augmenting less functional (and less attractive) pages of static hypertext and hyperlinks with rich interface widgets such as expandable menus, data grids, tree views, and tab panels. These widgets allow designers to reduce clutter and keep abundant features cleanly concealed. Responsive and event-based communication provides granular data refreshes and enables adaptiveness.

 

Front end engineering techniques at the heart of RIAs, such as Ajax for communications and Dynamic HTML (DHTML) for sophisticated interfaces, are not inherently inaccessible. However, the rapid proliferation of poorly implemented and carelessly deployed features can quickly lead to poor or no accessibility.

 

Due to the way today’s screen readers understand web pages (a single parse to its buffer, onload), and the lack of clearly-defined mechanisms to present DHTML content to AT, much RIA functionality isn’t natively accessible. Without proper implementations that are considerate of accessibility needs, pages that were accessible in the past can easily become totally unusable for screen reader and keyboard users.

 

Throughout the last several years, web and AT developers have both made drastic improvements in handling static web content. Web developers have embraced semantic markup and the Document Object Model (DOM) to provide static information about semantic elements and attributes. AT developers have combined this improved expression of a document with the MSAA and other OS APIs to great success. Unfortunately, this approach does not work well for frequently updating, event driven interfaces key to RIAs. In order to provide adequate "translations" of RIA sites, AT requires -- among other things -- a more complete understanding of DHTML elements including their role, state, actions, caret, selection, children, relations, and focus changes, as well as reliable keyboard access.

 

Possible Solutions

An excellent user experience has been Yahoo!'s goal since day one. The shift to RIAs has affected not only our users but the way we develop our sites. An increasing number of our web applications rely on Ajax and DHTML to generate dynamic content and behavior. Alongside our attempts to remain innovative and competitive, we are constantly looking into a variety of methods for making our new products accessible. Below are four “use them all” approaches that may help developers address the accessibility challenges of DHTML development and the needs of RIA interfaces.

 

Approach 1: Standards-Based Development

The first approach is Standards-Based Development. By developing to and with industry standards, all players have an equal chance of understanding an interface. By using HTML in a semantic manner, structure and meaning exist at the core. Progressively enhancing this HTML core with unobtrusive layers of visual and behavioral declarations provides an ever-richer interface while not corrupting or supplanting the accessible content core.

 

This approach, widely adopted throughout the industry over the last four years, should be implemented notwithstanding. It works "with the grain" of web architectural design, is a step toward a semantic web, is the foundation of better things to come, is a proper investment in a layer that is here to stay, and makes content – regardless of additional approaches implemented – as widely accessible as possible.

 

However, pitfalls still exist for JavaScript integration as this approach is best understood for static documents. Overwriting events, trapping clicks inappropriately, and mishandling keyboard input are all avoided by Unobtrusive JavaScript best practices still gaining adoption. Additionally, JavaScript-based server communication requires servers with new smarts, able to serve both full and partial responses.

 

Approach 2: Redundant interfaces

With a standards-based core in place, it is still important to offer redundant interfaces. There are two basic types of redundant interfaces. The first type deals with DHTML widgets that enhance common interactions, while the second deals with tasks visual in nature.

 

A date selection widget, offer to all as three SELECT elements for day, month, and year is commonly supplemented with a DHTML calendar that allows visual mouse users quick access to calendar dates. In this case, there is a static form-based task flow available to everybody, and a redundant DHTML widget that speeds the task for some. Another example is a DHTML slider widget that adds to (but does not replace) a finite-range text input element.

 

The second type is more commonly associated with RIAs, and can involve drag and drop or spatial visualization of data. Drag and drop is offered as an efficient way to directly manipulate the ordering of modules, or as a quick way to sort objects into collections. In these cases, a forms-based multi-page task flow should be offered as a redundant way to complete the same task. For visualizations of data, for instance restaurant locations around a point of interest on a map, a redundant interface would present the same data in tabular form.

 

 

Approach 3: Fortified and faithful interfaces

Fortifying interfaces so that they faithfully offer the functionality of the desktop is the third approach to accessible DHTML. To fortify the DHTML slider example from above, offer keyboard manipulation of the visual slider in addition to the more-obvious mouse manipulation. Ensure the widget accepts keyboard focus in a reasonable tab order.

 

Fortifications should be faithful to the desktop inspiration by offering conventional shortcuts, such as Control-Arrow to jump to the end. End and PageUp/PageDown keys should be likewise mapped.

 

Faithful and completely fortified web-based interpretations of desktop widgets allow users to transfer their desktop expertise online, while reducing the learning curve, and encouraging discoverability. Predictability and adherence to conventions are often-overlooked methods of extending accessibility.

 

Approach 4: “Accessible DHTML”

Emerging new technology, fittingly named “Accessible DHTML”, facilitates robust communication with Assistive Technology such as screen readers via the desktop’s accessibility API. This technology has been contributed by IBM, is now being developed by the W3C, and is currently implemented in Mozilla’s Firefox browser beginning with version 1.5.

 

By embedding role and state metadata in the attribute space of HTML XHTML 2 elements, a complete understanding of online interfaces is finally available to the OS’s accessibility API.

 

While very promising, this technology is young and has only been implemented in Firefox 1.5 at this point. Still, it shows great promise and should be a part of development toolbox.

 

Conclusion

Web site interfaces are quickly becoming more dynamic and sophisticated through the user of JavaScript, DHTML, and Ajax. The common conception that these technologies are inaccessible is a myth. Unfortunately though, all too many sites implementing these technologies are, in fact, inaccessible. In this paper, we’ve looked at four approaches that help make these rich-interface sites accessible for users of Assistive Technology, while also providing a better user experience for all users.

 

Adding accessibility after-the-fact is difficult, costly, and sometimes impossible. Therefore, as part of our longstanding interest in accessibility, Yahoo! is including discussion of and tooling for accessibility as part of our open-source Yahoo! User Interface Library of JavaScript utilities and widgets, and our Yahoo! Design Patterns Library of solutions to common interface needs. This approach hopes to embed accessibility into both Yahoo! and third-party RIAs from the beginning.

 


Go to previous article
Go to next article
Return to 2006 Table of Contents  


Reprinted with author(s) permission. Author(s) retain copyright