YAHOO! EXPERIENCES WITH
ACCESSIBILITY, DHTML,
Presenter(s)
Victor Tsaran
Yahoo! Inc.
Presenter #2
Nate Koechley
Yahoo! Inc.
701
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
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
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
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