YAHOO! EXPERIENCES WITH
Day Phone: 408-349-6387
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.
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.
end engineering techniques at the heart of RIAs, such as
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.
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
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.
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.
site interfaces are quickly becoming more dynamic and sophisticated through the