Author
Cynthia C. Shelly
What U Want, Inc.
The author is a member of the WCAG and WAI-PF working groups, and until
recently led the Web Development team of a major portal site, where she was
faced with the challenges of accessibility, cross-browser development, and
the separation of code, data, and UI logic.
What U Want, Inc. is developing a distributed-computing platform for
Internet and e-commerce. One of the mandates of this platform is to simplify
the creation, deployment and management of Internet applications. As part of
this effort, we are building an application development framework ,toolset,
and services to facilitate this process.
Abstract
It is currently very difficult and expensive to build a production Web-based
application that will run on multiple user-agents, be they browser or
device, accessibility aid or cell phone. Until this is no longer the case,
authors and developers will make trade-offs based on business goals as to
what user-agents they will support. To ensure that future applications work
for everyone on every device, we must simplify the development process.
Production Applications
In this paper, Web-based applications may be categorized into (a)
comprehensive production-grade enterprise Web applications and (b) simple
"Web site" with limited dynamic features. For convenience, we use the term
"Production application" for an application of the first category and "Web
Site" for that of the second category. A production Web-based application
has several characteristics that separate it from a Web Site
The most significant of these is that it is an application rather than a
document. That means that it is interactive by nature, and that logic to
control that interaction is intrinsic to its functionality. In the current
generation of browsers, that much of that logic is implemented in
client-side script, and the application does not function properly when
script is disabled or not available in the user-agent. The user interfaces
of these applications are often highly sophisticated and complex, requiring
a fair bit of logic to handle user interaction, state-maintenance, and
interdependency of user interface elements.
In addition to being applications, these are production applications, that
is commercial products. As such, they must meet certain market requirements
that are often at odds with the requirements of accessible design and
platform portability. A commercial product must appeal to the sensibilities
of its target market. It must be pretty, or cute, or cool, or whatever look
is appropriate to its users and their sense of fashion. Often, it must also
comply with strict branding requirements (both legal and market) on the use
of logos, fonts, etc. And, its producer must be reasonably able to assure
an advertiser (his customer) that an ad has been placed in the position paid
for.
Many Clients
There is a huge variety of client devices currently on the market, each with
its own set of capabilities. Many of these clients don't support client
scripting at all, which, in the current environment, means that they don't
support Web applications. In addition, the current model of scripting,
where it is supported, is cumbersome and dependent on both the presence of
particular input devices and browser interfaces.
In order to make device independent UI a reality, there must be a way to
handle complex interactive UI in an environment without client script, and
without requiring the developer of that UI to write multiple versions of it.
The logic of the UI must be able to run either on the client or the server,
while the presentation is displayed on the client, and data and state are
communicated between them.
In the case of a next-generation user agent that fully supports whatever
comes from this discussion, both the presentation and logic would run
natively in the client. For a thin client with limited processing power,
presentation rendering would happen on the client, and the associated logic
would run on a next-generation server component. For backward compatibility
with existing browsers, one could either use the thin client approach, or
use transformations (pre-built or through a proxy) to generate HTML and
script compatible with those browsers. In cases where logic is running on
the server, there must be a solution for client-server state maintenance in
a multiple-server environment.
Client device screen size also varies widely, from a no-screen audio-only
interface, to a small LCD screen on a cell phone, to a 21-inch monitor
running at resolution of 1200x1024 pixels with millions of colors. Authors
need a clean way to describe groups of UI elements that should be kept
together, and which can be assembled to build larger screens. The "cards"
described in the XForms UI proposal are a good example of this type of
grouping.
We must also ensure that there are accessibility hooks appropriate to each
platform, and that next generation user agents include good accessibility
features.
Automatic Detection
In the current practice of Web development, a great deal of time, energy,
and money is spent creating and maintaining user-agent detection or
"browser-sniffing" code. This approach is flawed in several ways. This
detection code requires frequent maintenance as new clients and new versions
of old clients are released, and code optimized for one client will very
often be incompatible with new clients, especially in the area of scripts.
Authors and Web developers tend to think in terms of functionality working
in a particular browser or set of browsers, rather than a user agent having
a set of capabilities with which to render the functionality. Authors also
have imperfect knowledge of the features of various user agents, and of
newly released user agents. In many cases, users of unrecognized clients
are told to "upgrade" to a popular PC-based browser, a frustrating
experience for the user of a newly released PDA or a specialized
accessibility device.
The author should not be responsible for determining the capabilities of the
client, or for switching between versions of layout and logic. The client
should advertise its capabilities (via CC/PP
or a similar mechanism) so that the
author's instructions can automatically be rendered in a manner appropriate
to the capabilities of that client. This includes graceful degradation of
bitmapped graphics to vector graphics and/or text supplied by the author,
determining if the logic is run on the client or the server, and available
mechanisms for client-server communication and state-maintenance.
Simple Authoring
It must be possible to author the UI once, and have it run properly on a
variety of devices and browsers. HTML, XHTML, and CSS provide a partial
solution, in that they allow description of the layout of a user interface,
which can be rendered by many clients. These technologies do not, however,
provide a way to describe the behavior of UI elements or the relationships
between them. The current model of scripting is highly dependent on the
platform where it runs. It must be possible to write the logic once, and
have it run in a way that is appropriate to the device.
Authors and UI designers should be able to replace intrinsic controls with
custom graphics (as with the