index.html 66.7 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>Device Independence Principles</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <style type="text/css">
.principle {background-color: #FFFFE0; color: black; border: thin solid; padding: 1em; font-weight: bold}
h5.principle-head {font-weight: bold}
.example {background-color: #E0FFFF; color: black; margin-left: 5%; margin-right: 10%; padding: 1em}
.definition { }</style>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72" /></a>

<h1>Device Independence Principles</h1>

<h2>W3C Working Group Note 01 September 2003</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/NOTE-di-princ-20030901/">http://www.w3.org/TR/2003/NOTE-di-princ-20030901/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/di-princ/">http://www.w3.org/TR/di-princ/</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/WD-di-princ-20010918/">http://www.w3.org/TR/2001/WD-di-princ-20010918/</a></dd>
  <dt>Editor:</dt>
    <dd>Roger Gimson (HP) <a
      href="mailto:roger.gimson@hp.com">&lt;roger.gimson@hp.com&gt;</a></dd>
  <dt>Co-editors:</dt>
    <dd>Shlomit Ritz Finkelstein (invited expert) <i>until June 2003</i></dd>
    <dd>St&eacute;phane Maes (IBM) <i>until July 2002</i></dd>
    <dd>Lalitha Suryanarayana (SBC Technology Resources) <i>until April
      2003</i></dd>
  <dt>Contributors:</dt>
    <dd>See <a href="#section-Acknowledgements">Acknowledgements</a></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
&copy;2003 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>&#xae;</sup> (<a
href="http://www.lcs.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p>
</div>
<hr title="Separator for header" />

<h2 id="abstract">Abstract</h2>

<p>This document celebrates the vision of a device independent Web. It
describes device independence principles that can lead towards the
achievement of greater device independence for web content and
applications.</p>

<h2 id="status">Status of this document</h2>

<p><em>This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current
W3C publications and the latest revision of this technical report can be
found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
at http://www.w3.org/TR/.</em></p>

<p>This document has been produced as an overview document from the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a>. It is
intended to provide a set of principles that can guide work relating to
device independence.</p>

<p>This document is one of a series produced by the Device Independence
Working Group, part of the <a href="http://www.w3.org/2001/di/">W3C Device
Independence Activity</a>. The DIWG activity statement can be seen at <a
href="http://www.w3.org/2001/di/Activity">http://www.w3.org/2001/di/Activity</a>.</p>

<p>A version of this document is also available showing <a
href="changes.html">changes</a> since the previous Working Draft.</p>

<p>Comments on, and discussion arising from, this document can be sent to <a
href="mailto:www-di@w3.org">www-di@w3.org</a>, the public forum for
discussion of the W3C's work on Device Independence. The <a
href="http://lists.w3.org/Archives/Public/www-di/">archive</a> for the list
is accessible online.</p>

<p>Patent disclosures relevant to this document may be found on the <a
href="http://www.w3.org/2001/di/Disclosures.html">WG patent disclosure
page</a>.</p>

<h2 id="contents">Table of contents</h2>
<ul class="toc">
  <li><a href="#section-Introduction">1 Introduction</a>
    <ul class="toc">
      <li><a href="#section-Audience">1.1 Audience</a></li>
      <li><a href="#section-Goals">1.2 Goals</a></li>
      <li><a href="#section-Motivation">1.3 Motivation</a></li>
      <li><a href="#section-Overview">1.4 Overview</a></li>
    </ul>
  </li>
  <li><a href="#section-Principles">2 Principles</a>
    <ul class="toc">
      <li><a href="#section-User">2.1 User perspective</a>
        <ul class="toc">
          <li><a href="#section-UserConcepts">2.1.1 User-related
          concepts</a></li>
          <li><a href="#section-UserPrinciples">2.1.2 User-related
            principles</a></li>
        </ul>
      </li>
      <li><a href="#section-Authoring">2.2 Authoring perspective</a>
        <ul class="toc">
          <li><a href="#section-AuthorConcepts">2.2.1 Author-related
            concepts</a></li>
          <li><a href="#section-AuthorPrinciples">2.2.2 Author-related
            principles</a></li>
          <li><a href="#section-DIAuthoring">2.2.3 Device independent
            authoring</a></li>
        </ul>
      </li>
      <li><a href="#section-Delivery">2.3 Delivery perspective</a>
        <ul class="toc">
          <li><a href="#section-DeliveryConcepts">2.3.1 Delivery-related
            concepts</a></li>
          <li><a href="#section-DeliveryPrinciples">2.3.2 Delivery-related
            principles</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#section-Further">3 Associated work</a></li>
  <li><a href="#section-References">4 References</a></li>
  <li><a href="#section-Appendices">Appendices</a>
    <ul class="toc">
      <li><a href="#section-Usage">A Usage scenarios</a></li>
      <li><a href="#section-Changes">B Main changes since last working
        draft</a></li>
      <li><a href="#section-Acknowledgements">C Acknowledgements</a></li>
    </ul>
  </li>
</ul>
<hr />

<h2 id="section-Introduction">1 Introduction</h2>

<h3 id="section-Audience">1.1 Audience</h3>

<p>The intended audience for this document is primarily other W3C Working
Groups and external organizations involved in developing web content
authoring and delivery technologies.</p>

<h3 id="section-Goals">1.2 Goals</h3>

<p>The goal of this document is to suggest that web content and applications
can be authored, generated or adapted for a better user experience when
delivered via many different web-connectable access mechanisms. The general
phrase "device independence" is used for this, although the access mechanisms
may include a diversity of devices, user agents, channels, modalities,
formats etc.</p>

<p>The vision we share with others is to allow the Web to be accessible by
anyone, anywhere, anytime, anyhow. The focus of the <a
href="http://www.w3.org/WAI/">W3C Web Accessibility Initiative</a> is on
making the Web accessible to anyone, including those with disabilities. The
focus of the <a href="http://www.w3.org/International/">W3C
Internationalization Activity</a> is on making the Web accessible anywhere,
including support for many writing systems and languages. The focus of the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a> is on
making the Web accessible anytime and anyhow, in particular by supporting
many access mechanisms (including mobile and personal devices, that can
provide access anytime) and many modes of use (including visual and auditory
ones, that can provide access anyhow).</p>

<p>These three Activities are complementary, and our interests overlap. For
example, being able to select an auditory mode of use on a device may be
essential to someone with a visual disability. The focus of device
independence is on matching web content to the needs, capabilities and
limitations of the delivery environment. We wish to minimize the extent to
which web content is authored in a way that is only deliverable on a
restricted set of devices.</p>

<p>The principles described here are intended to be complementary to the
wider Architecture of the World Wide Web [<a href="#WEBARCH">WEBARCH</a>],
which consists of a wider set of requirements, constraints, principles, and
choices that influence the design of the Web and the behavior of agents
within it. Implementations of these principles should also conform to the Web
Content Accessibility Guidelines [<a href="#WCAG">WCAG</a>], the User Agent
Accessibility Guidelines[<a href="#UAAG">UAAG</a>] and the Authoring Tool
Accessibility Guidelines [<a href="#ATAG">ATAG</a>].</p>

<p>The aim of this document is to focus on device independence and to set out
some principles that can be used when evaluating current solutions or
proposing new solutions, and can form the basis of more detailed requirements
and recommendations.</p>

<p>The principles are independent of any specific markup language, authoring
style or adaptation process. They do not propose specific requirements,
guidelines or technologies.</p>

<p>It is intended, however, that these principles be used as a foundation
when proposing greater device independence through, for example:</p>
<ul>
  <li>guidelines for authoring of content and applications that use existing
    markup languages,</li>
  <li>modifications and extensions to existing markup languages,</li>
  <li>designs of adaptation tools and processes,</li>
  <li>evolution of new markup languages.</li>
</ul>

<p>Other documents provide more details on the authoring challenges [<a
href="#AC">AC</a>] and the delivery context issues [<a href="#DCO">DCO</a>]
associated with achieving device independence.</p>

<h3 id="section-Motivation">1.3 Motivation</h3>

<p>In recent years, there has been a proliferation of types of device and
access mechanisms using the Web, extending far beyond the conventional
personal computer. These access mechanisms range from web tablets, appliances
and TVs in the home, to mobile devices including phones and PDAs, and access
mechanisms for the physically challenged. Connectivity capabilities have also
evolved to include high bandwidth modems, LANs and wireless networks.
Simultaneously, the needs and expectations of the user with regards to
access, availability and consumption of web content have also evolved. Users
now expect to get to critical information through different access mechanisms
from different locations and at different times during their day.</p>

<p>For example, a user may want to access some web information using a PC
connected to a cable network when at home, but when out of the house the same
user expects to access the same information using a PDA connected through a
mobile phone network.</p>

<p>In the appendix on <a href="#section-Usage">Usage scenarios</a> we give
examples of circumstances in which access to the Web may be required via
different access mechanisms.</p>

<p>Content authors can no longer afford to develop content that is targeted
for use via a single access mechanism. The key challenge facing them is to
enable their content or applications to be delivered through a variety of
access mechanisms with a minimum of effort. Implementing a web site or an
application with device independence in mind could potentially save costs,
and assist the authors in providing users with an improved user experience
anytime, anywhere and via any access mechanism.</p>

<h3 id="section-Overview">1.4 Overview</h3>

<p>In the following section, the impact of device independence is considered
from three different perspectives:</p>
<ul>
  <li>the user who wishes to access a web page,</li>
  <li>the authoring techniques used to create the web page, and</li>
  <li>the delivery mechanism by which the web page is made available.</li>
</ul>

<p>For each perspective, significant concepts for device independence are
defined and appear as follows:</p>
<dl class="definition">
  <dt><strong>concept</strong></dt>
    <dd>Within this document, concept definitions are shown in this
    style.</dd>
</dl>

<p>A separate Glossary for Device Independence [<a
href="#Glossary">Glossary</a>] includes all the definitions introduced in the
body of this document as well as those from other documents produced by the
Device Independence Activity.</p>

<p>Within each perspective, a number of principles are stated. They are
intended to capture fundamental assumptions within which specific approaches
to authoring and adaptation can be developed.</p>

<p>The principles are not specific to any particular usage scenario or to any
implementation technology, but capture aspects of device independence that
will apply across many contexts. Each Device Independence Principle (DIP) is
given a sequential number and a name. They appear as follows:</p>

<h5 class="principle-head">DIP-nn: Principle name</h5>

<p class="principle">Within this document, principles are stated in this
style.</p>

<p>Examples are given at certain points within the document in order to
illustrate the way in which the principles may be applied in specific
circumstances. They appear as follows:</p>

<p class="example"><i>Example:</i> Within this document, examples are shown
in this style.</p>
<hr />

<h2 id="section-Principles">2 Principles</h2>

<p>In this section a number of principles are introduced which are
fundamental to the achievement of device independence.</p>

<p>They are called <em>principles</em> (rather than, for example, guidelines
or requirements) because they attempt to capture important concepts and
aspirations that are not specific to any particular realization. Unlike
guidelines, they are not specific enough to guide current practice.
Guidelines could be developed in due course by applying the principles to the
use of current markup technologies. Unlike requirements, they do not propose
a specific approach to which some new technology must conform. Requirements
for new technology could be developed in due course by applying the
principles as part of the design process.</p>

<p>Whether these principles are used to develop future guidelines,
requirements and recommendations will depend on their general acceptance
within the Web development community. At this stage, all the principles are
stated as "should", in lowercase. In the future, if requirements are
developed from them, the conventional requirements terminology of "MUST",
"SHOULD", and "MAY" could be used to indicate different degrees of
conformance (as defined in <a
href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>).</p>

<p>For purposes of explanation, the principles are introduced, with the
concepts used in their statement, from three perspectives: that of the user,
the author and the delivery mechanism. However, the principles themselves can
have implications that span multiple parts of the delivery chain.</p>

<h3 id="section-User">2.1 User perspective</h3>

<h4 id="section-UserConcepts">2.1.1 User-related concepts</h4>

<p>The following diagram introduces the key user-related concepts, which are
then defined and explained in the subsequent text.</p>
<img src="user_concepts.png" style="border: 0px solid ;"
alt="diagram illustrating user concepts" align="middle" />

<p>We want to enable the user to perceive and interact with the Web using
many kinds of device, or more generally, via many kinds of access
mechanism.</p>

<p>The main concepts for the user are as follows.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user-experience">user
  experience</a></dt>
    <dd>a set of material rendered by a user agent which may be perceived by
      a user and with which interaction may be possible</dd>
</dl>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-device">device</a></dt>
    <dd>an apparatus through which a user can perceive and interact with the
      Web</dd>
</dl>

<p class="example"><i>Example 2.1.1.1:</i> Existing devices that are commonly
used to access the Web include PCs, PDAs, web-enabled phones, and interactive
TVs.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-access-mechanism">access
  mechanism</a></dt>
    <dd>a combination of hardware (including one or more devices and network
      connections) and software (including one or more user agents) that
      allows a user to perceive and interact with the Web using one or more
      modalities (sight, sound, keyboard, voice etc.)</dd>
</dl>

<p>The access mechanism is an intermediary between the Web and the user. On
one side it communicates with the Web using protocols and markup conventions,
on the other it supports perception by, and interaction with, the user.</p>

<p>From the user's point of view, an access mechanism often corresponds to a
single device.</p>

<p>However, in some situations, the access mechanism may consist of more than
one device.</p>

<p class="example"><i>Example 2.1.1.2:</i> A printer may be attached to a PC
that is connected to the Web. The combined apparatus provides an access
mechanism that can offer a printed representation of a web page.</p>

<p class="example"><i>Example 2.1.1.3:</i> When in a mall, a user may
interact with the Web simultaneously through a kiosk interface and a personal
phone. Personal information is exchanged through the private phone connected
to the mobile network, while public information is viewed, under the control
of the phone, on the larger but public kiosk screen equipped with a
high-speed connection.</p>

<p>Sometimes the access mechanism may include the use of additional network
support.</p>

<p class="example"><i>Example 2.1.1.4:</i> A service provider may offer a
service that allows voice interaction with the Web via a telephone. The
combination of the telephone and the service is the access mechanism that
enables an auditory perception of the web content.</p>

<p>Sometimes the access mechanism may support synchronization for multi-modal
interaction.</p>

<p class="example"><i>Example 2.1.1.5:</i> A user may be able to access the
Web through a smart phone that simultaneously provides both a graphical
interface directly on the phone and a voice interface provided via a network
service. The user can select at any time which is the preferred mode of
interaction e.g. voice for input and graphics for output, voice for both, or
graphics for both.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-perceivable-unit">perceivable
  unit</a></dt>
    <dd>a set of material which, when rendered by a user agent, may be
      perceived by a user and with which interaction may be possible</dd>
</dl>

<p>Most perceivable units provide both presentation and the means for
interaction. However, on some types of device, such as printers, perceivable
units might contain only presentation.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-web-page-identifier">web
  page identifier</a></dt>
    <dd>a <a href="http://www.w3.org/Addressing/">Uniform Resource
      Identifier</a> intended to be recognized by a user as representing the
      identity of a specific web page (resource)</dd>
</dl>

<p>A user may enter a web page identifier explicitly as part of their
interaction, or may indirectly follow one by selecting a link, selecting a
previously saved bookmark, or through some other aspect of interacting with
an application.</p>

<p class="example"><i>Example 2.1.1.6:</i> A user may see a web page
identifier, such as "www.example.com" used in an advertisement. They expect
to be able to use this identifier to access further information about the
advertiser or product in the form of an appropriate user experience.</p>

<p>In some cases, such as in voice-only browsing, the user may not know the
web page identifier being used to retrieve the next perceivable unit.</p>

<p>A perceivable unit is rendered to the user as a collection of physical
effects, visual, auditory or tactile, via one or more devices within the
access mechanism. Mechanical controls, such as buttons, keys and pointers,
and sonic input such as voice commands (and possibly other affordances) allow
a user to interact with the perceivable unit.</p>

<p class="example"><i>Example 2.1.1.7:</i> If a user entered the web page
identifier "www.example.com" into a web-connected PDA, the resultant
perceivable unit may be a visual display showing the company logo, a brief
description of its activities, and a link that when touched leads to another
page with additional product information.</p>

<p>The physical user interface is where the information that was transmitted
digitally becomes accessible to and manipulable by the user.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-web-page">web
  page</a></dt>
    <dd>a collection of information, consisting of one or more resources
      intended to be rendered simultaneously, and identified by a single
      Uniform Resource Identifier</dd>
</dl>

<p>Conventionally, a web page may be thought of as a perceivable unit.
However, depending on the access mechanism, and the granularity of its
presentation capabilities, the number of perceivable units required to
present a web page may vary.</p>

<p class="example"><i>Example 2.1.1.8:</i> A limited capability device, such
as a mobile phone, may accept only small amounts of data during a single
interaction with the Web. Such a device may be unable to accept a large
resource in a single perceivable unit. The limited presentation and input
capabilities on this kind of device may also favor use of multiple
perceivable units for improved usability.</p>

<p>The quality of the user experience depends on the degree to which material
has been successfully adapted for use via a specific access mechanism. The
possible modes of interaction are largely defined by the device manufacturer,
but the way in which they are incorporated into one or more perceivable units
will affect the ease of use of that device for the user.</p>

<p>The next concept is about the quality of the user experience delivered via
a given access mechanism in response to a given web page identifier. It is
intended to capture the minimal quality of user experience necessary to be
useful to a user.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-functional-user-experience">functional
  user experience</a></dt>
    <dd>a set of one or more perceivable units that enables a user to
      complete the function intended by the author for a given resource via a
      given access mechanism</dd>
</dl>

<p>The function intended by the author may be as simple as to convey some
information to the user.</p>

<p class="example"><i>Example 2.1.1.9:</i> If the intended function is for
the user to be able to perceive a passage of text, a functional user
experience might provide visible or audible representations of it.</p>

<p>The function intended may be as complex as guiding the user through a
sequence of application-specific interactions.</p>

<p class="example"><i>Example 2.1.1.10:</i> If the intended function is for
the user to take the next step in some interactive application, a functional
user experience should be sufficient for the user, say, to successfully fill
in a data field and submit it.</p>

<p>A functional user experience is defined with respect to a particular
access mechanism. It may not be possible to achieve a functional user
experience for some particular content or application for every access
mechanism, due to inherent limitations of the mechanism.</p>

<p>The functional intent is defined by the author of the application, and it
is possible that it will differ from the expectation or intent of the
user.</p>

<p class="example"><i>Example 2.1.1.11:</i> A user may access a flight
reservation system in order to find the abbreviated code used for a
particular airport. If the user accesses the flight reservation system by
voice, the abbreviated code may not be provided, since the airport name may
only be spoken without abbreviation. The user may consider that this
particular audible representation is not functional for his or her purpose.
However, this is a user-centric definition of functional user experience. The
user experience is functional from the author's perspective. However the
application does not deliver the information to the user in the form they
desire.</p>

<p>Whether the user experience associated with a web page is considered by
the user to be functional clearly depends on their understanding of the
function associated with that web page. The user may already have an
expectation of the functionality, for example because they have previously
accessed the page on another device. If their expectations are not met, the
user cannot be certain whether it is because their expectations are wrong or
whether a non-functional user experience has been delivered. If it is the
first time they have accessed the web page, they can only rely upon the
integrity and consistency of the user experience to estimate whether it is
functional.</p>

<p>Many things may prevent completion of a function, such as when a user
experience of a web page is not made available, or has broken elements, or
causes a failure in the access mechanism. From a user's perspective, if the
user is unable to carry out the function successfully then the user
experience is not functional.</p>

<h4 id="section-UserPrinciples">2.1.2 User-related principles</h4>

<h5 class="principle-head" id="DIP-1">DIP-1: Device independent access</h5>

<p class="principle">For some web content or application to be device
independent, it should be possible for a user to obtain a functional user
experience associated with its web page identifier via any access
mechanism.</p>

<p>This is the fundamental principle for device independence from the user
perspective. It does <em>not</em> say that the user experience will be the
same on every device. But it <em>does</em> say that the user should be able
to obtain a user experience and that the user experience obtained should be
at least functional.</p>

<p class="example"><i>Example 2.1.2.1:</i> A user enters a web page
identifier for a weather forecasting page on different devices. On the screen
of a PDA, the text "Tomorrow" is shown, together with a graphic of a sun. On
the screen of a phone, the text "Tomorrow: sun" is shown. On an in-car PC,
the words "Tomorrow will be sunny" are spoken. These are all user experiences
that have been adapted to be functional for their specific access
mechanisms.</p>

<p class="example"><i>Example 2.1.2.2:</i> If on some device the same web
page identifier as in the previous example gave either no user experience, or
a user experience consisting of the text "Cannot display graphics", this
would not be a functional user experience.</p>

<p>The goal is that a functional user experience should be possible via any
access mechanism. The method by which presentation and interaction are
provided may vary according to the different access mechanisms, but the
possibility of a functional user experience should always exist.</p>

<p>In particular, it should be possible to provide a functional user
experience even on a limited capability device - though it may be of reduced
quality compared to that on more capable devices.</p>

<p class="example"><i>Example 2.1.2.3:</i> Where an image would occur on an
image-capable device, a text alternative could be displayed on a text-only
device, or the text could be spoken when accessed by a voice-only phone.</p>

<h5 class="principle-head" id="DIP-2">DIP-2: Device independent Web page
identifiers</h5>

<p class="principle">A web page identifier that provides a functional user
experience via one access mechanism should also provide a user experience of
equivalent functionality via any other access mechanism.</p>

<p>In other words, the intended function of a web page is associated with the
web page identifier, and should apply to all user experiences obtained from
the web page identifier, no matter what the access mechanism.</p>

<p class="example"><i>Example 2.1.2.4:</i> By bookmarking a web page
identifier that provides a functional user experience on one device it should
be possible to obtain a corresponding user experience on another device with
equivalent functionality. The user experiences may be different due, among
other things, to the different capabilities of the devices, but their
intended function is the same and they should both be at least functional.</p>

<p>In order to meet this principle, it may be necessary to restrict or
re-interpret what is acceptable as a web page identifier. For example, a URI
that includes a suffix indicating its representation, such as "example.html",
may need the suffix to be ignored when the material is adapted for a non-HTML
device. Similarly, any device-specific information coded in a query part or
fragment part of the URI may need to be re-interpreted or ignored.
Unfortunately, many implementers do not respect the intent of URI style
guidelines [<a href="#URI-Style">URI-Style</a>].</p>

<h3 id="section-Authoring">2.2 Authoring perspective</h3>

<h4 id="section-AuthorConcepts">2.2.1 Authoring-related concepts</h4>

<p>The following diagram introduces the key authoring concepts, which are
then defined and explained in the subsequent text.</p>
<img src="authoring_concepts.png" style="border: 0px solid ;"
alt="diagram illustrating authoring concepts" align="middle" />

<p>The main concepts for authoring are as follows.</p>

<p>When a request is made over the Web for a web page, not only should the
request specify the web page identifier for the page, but also it should
provide enough information about the access mechanism and the user that the
right kind of user experience can be provided.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-delivery-context">delivery
  context</a></dt>
    <dd>a set of attributes that characterizes the capabilities of the access
      mechanism and the preferences of the user</dd>
</dl>

<p>Delivery context information may be sent as part of each request, but this
is not essential. Alternative possible implementations are discussed in the
separate Delivery Context Overview [<a href="#DCO">DCO</a>] document.</p>

<p>The delivery context expresses the capabilities and preferences that may
constrain the acceptable range of user experiences that can be delivered via
a given access mechanism. In particular, the capabilities of the device,
including the modalities and representations it supports, the characteristics
of the network over which delivery occurs, and the preferences of the user
will all potentially affect the user experience provided.</p>

<p class="example"><i>Example 2.2.1.1:</i> A PDA may have a screen of a
certain size, and have a built-in speaker. It may be able to display HTML
markup and play streaming audio. It may be connected to the Web over a phone
network that only offers a slow data transfer rate. The user of the PDA may
be in a meeting and prefer not to use audio at that moment. These (and other)
attributes form the current delivery context. In this delivery context it
might be appropriate to present a web page as a limited amount of text on the
screen.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-delivery-unit">delivery
  unit</a></dt>
    <dd>a set of material transferred between two cooperating web programs as
      the response to a single HTTP request</dd>
</dl>

<p>The transfer might, for example, be between an origin server and a user
agent. Users are not normally aware of individual delivery units.</p>

<p>The response to a request containing a web page identifier is a delivery
unit which contains the data (in a markup language or image encoding, for
example) that will be used by the access mechanism in order to render a
physical user experience. It will also allow the user to interact with that
page, and possibly generate a further request.</p>

<p class="example"><i>Example 2.2.1.2:</i> Markup languages such as HTML,
XHTML, SVG, etc. are designed specifically as ways of representing aspects of
user experiences. Image formats such as PNG and scripting languages such as
ECMAScript may also be used to represent different aspects of the user
experience. It is common to find certain combinations of representations that
are delivered together. For example, HTML pages frequently contain
ECMAScript. For such combinations, a single delivery unit can carry multiple
representations. Some delivery units, especially those associated with media,
often carry only a single representation. Images are an example of media
often carried within their own delivery units.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-adaptation">adaptation</a></dt>
    <dd>a process of selection, generation or modification that produces one
      or more perceivable units in response to a requested uniform resource
      identifier in a given delivery context</dd>
</dl>

<p>Adaptation is shown in this diagram as occurring at the server (and hence
known as server-side adaptation). However, it may also occur at intermediate
points in the delivery chain, or at the client (known as client-side
adaptation). See the Delivery Context Overview [<a href="#DCO">DCO</a>] for
further explanation.</p>

<p>There are many techniques that could be used to produce an appropriate
user experience in response to a request for a web page. Since these
principles are intended to be technology independent, no further exploration
of the adaptation process is made here.</p>

<p>The authoring perspective instead focuses on the quality of user
experience produced by the adaptation process and on the obligations on the
authoring task.</p>

<p>The concept of functional user experience has already been introduced as
part of the user perspective.</p>

<p>However, though a user experience may be functional, in that it is
sufficient to allow a user to complete the function intended, it may not
provide a rendering that matches the author's objective for a particular
delivery context. The next concept sets out to address this.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-harmonized-user-experience">harmonized
  user experience</a></dt>
    <dd>a functional user experience that is sufficiently harmonized with the
      delivery context to meet the quality criteria of the author</dd>
</dl>

<p>Harmonization allows the user experience to be made more specific to the
delivery context in order to meet criteria, such as ease of use and quality
of user experience, that are important to the author. They may affect,
perhaps, the popularity of the web page or the trust that the user places in
the underlying application.</p>

<p class="example"><i>Example 2.2.1.3:</i> The way that information is laid
out, in the visual representation of a web page, may take into account the
dimensions of the display of the device being used. This information is made
available to the adaptation via the delivery context. The same information
may be arranged quite differently on the same device to improve the visual
effect or to improve the usability of the user interaction. Such changes do
not affect the functionality of the user experience but may improve its
appeal. These aspects are often important to authors and to users.</p>

<p>Authoring tools and adaptation processes may differ in the extent to which
they support harmonized user experiences.</p>

<h4 id="section-AuthorPrinciples">2.2.2 Authoring-related principles</h4>

<p>The following principles are directed towards the authoring and adaptation
process that is responsible for providing a delivery unit in reply to a
request from a user.</p>

<h5 class="principle-head" id="DIP-3">DIP-3: Functionality</h5>

<p class="principle">It should be possible to provide a functional user
experience, in response to a request for a web page, in any given delivery
context that has an adequate access mechanism.</p>

<p>This principle places an obligation on the author, the authoring tools and
the adaptation process to provide a user experience that allows a user to
successfully access a web page to get the information or complete the
interaction intended.</p>

<p>The principle is effectively a restatement of <a href="#DIP-1">DIP-1</a>
from the point of view of the producer rather than the consumer.</p>

<p>Sometimes it is not possible to provide some content or functionality in a
given delivery context because of limitations in the access mechanism.</p>

<h5 class="principle-head" id="DIP-4">DIP-4: Incompatible access
mechanism</h5>

<p class="principle">If a functional user experience of an application cannot
be provided due to inherent limitations in the access mechanism, an
explanatory message should be provided to the user.</p>

<p class="example"><i>Example 2.2.2.1:</i> An access mechanism has no sound
output capabilities. An application wishes to offer a function, such as
playing some music, that can only be provided through sound output. The
application cannot offer a functional user experience through such an access
mechanism. In this case, it should provide a message to the user instead that
indicates the nature of the incompatibility (and might suggest
alternatives).</p>

<h5 class="principle-head" id="DIP-5">DIP-5: Harmonization</h5>

<p class="principle">If the author wishes, it should be possible to provide a
harmonized user experience, in response to a request for a web page, in any
given delivery context that has an adequate access mechanism.</p>

<p>This goes beyond the previous principle to additionally allow that the
author can provide a user experience that is well designed for the delivery
context. It is an obligation on the authoring tools and adaptation process to
support the creation and delivery of user experiences tailored for specific
access mechanisms when the author requires them.</p>

<p>In many situations, it is necessary to define specific details about the
user experience associated with a particular web page. It is not sufficient
that only predefined or standard user experiences can be used. Authors should
be able to control the precise details of the user experience if they wish.
At the most detailed level, a harmonized user experience might apply to only
a very restricted set of delivery contexts. However, <a
href="#DIP-2">DIP-2</a> requires that other adaptations be available to
provide functional user experiences for the other delivery contexts.</p>

<p class="example"><i>Example 2.2.2.2:</i> Some devices, especially small
ones such as phones, are highly constrained in their capabilities. To create
a sufficiently user-friendly user experience of some application, it may be
necessary to harmonize the user experience for that particular application on
that particular phone.</p>

<h4 id="section-DIAuthoring">2.2.3 Device independent authoring</h4>

<p>It is unrealistic to expect an author to create different user experiences
for every delivery context. Whenever possible, authored source content should
be reused across multiple delivery contexts.</p>

<p>Functional user experiences suited to any delivery context can be
generated by using an adaptation process applied to a representation that
does not depend on the access mechanism.</p>

<p class="example"><i>Example 2.2.3.1:</i> One approach to device independent
authoring is to use a transformation technique such as XSLT. By creating the
content in XML, the same content can be adapted for different delivery
contexts using XSL stylesheets.</p>

<p>Some authoring approaches based on device independent representations may
in addition allow customized user experiences to be provided for some
delivery contexts.</p>

<p>The issues facing authors are described in more detail in the separate
document Authoring Challenges for Device Independence [<a
href="#AC">AC</a>].</p>

<h3 id="section-Delivery">2.3 Delivery perspective</h3>

<h4 id="section-DeliveryConcepts">2.3.1 Delivery-related concepts</h4>

<p>The following diagram introduces the key delivery concepts, which are then
defined and explained in the subsequent text.</p>
<img src="delivery_concepts.png" style="border: 0px solid ;"
alt="diagram illustrating delivery concepts" align="middle" />

<p>The main concepts for delivery are as follows.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-user-agent">user
  agent</a></dt>
    <dd>a client within a device that performs rendering</dd>
</dl>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-rendering">rendering</a></dt>
    <dd>the act of converting perceivable units into physical effects that
      can be perceivable by a user and with which the user may be able to
      interact</dd>
</dl>

<p>The user agent is some software or firmware in a device (for example a
browser) that lets the user identify a web page to be rendered, assembles an
appropriate request for that page (possibly including the delivery context),
accepts the reply (delivery unit), and renders that reply into one or more
perceivable units.</p>

<p>Before rendering, a user agent may apply client-side adaptation, perhaps
under the control of adaptation preferences, to transform a delivery unit
into a perceivable unit.</p>

<p class="example"><i>Example 2.3.1.1:</i> A user agent may render the
material they receive in a delivery unit as a single perceivable unit or as
multiple perceivable units, perhaps to better fit a limited viewing area. For
example, WML provides explicit markup for the delivery unit, &lt;deck&gt;,
and the perceivable unit, &lt;card&gt;.</p>

<p>There are three distinct ways in which the user may personalize how a web
page is presented to them. They are distinguished by which parts of the
delivery chain are responsible for affecting the user experience: the
renderer in the user agent, some adaptation process (in the server, client or
an intermediary), or the functionality of the application itself.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-rendering-preferences">rendering
  preferences</a></dt>
    <dd>a set of preferences, specified by a user, that may affect the way
      the user agent renders a perceivable unit, and so change the resultant
      user experience</dd>
</dl>

<p>It may be possible for a user agent, under the control of rendering
preferences, to make local changes to a perceivable unit as it is rendered.
This will depend on the local behavior of the user agent within the
device.</p>

<p class="example"><i>Example 2.3.1.2:</i> A user agent may allow the user to
locally increase the size of text, or convert text to speech, to improve
accessibility for those with poor or no sight.</p>

<p>In current user agents, such rendering preferences are not communicated as
part of the delivery context and so do not affect the delivery unit sent to
the device. However, this also means it is possible for a user experience to
become non-functional through inappropriate choice of rendering
preferences.</p>

<p class="example"><i>Example 2.3.1.3:</i> A user experience may use black
text on a white background. If a local rendering preference sets only the
background to be black, the text will become unreadable and so
non-functional.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-adaptation-preferences">adaptation
  preferences</a></dt>
    <dd>a set of preferences, specified by a user, that may affect the
      adaptation for a given delivery context, and so change the resultant
      user experience</dd>
</dl>

<p>The user may be able to express preferences that affect the way the
content or application functionality is presented when there is more than one
choice. Some devices can support more than one way of presenting a web page,
or more than one method of interaction with it.</p>

<p class="example"><i>Example 2.3.1.4:</i> Even if an access mechanism
supports images, a user may prefer to receive all information as text -
perhaps because they are using a local text-to-speech converter. By
indicating an adaptation preference for no images, the adaptation process may
be able to provide a better text-only presentation, harmonized with the
delivery context, than could be achieved by locally replacing all images by
their text alternates.</p>

<p>Some adaptation may occur within the network, for example in transcoding
proxies, or in the client prior to the final perceivable unit being
rendered.</p>

<p class="example"><i>Example 2.3.1.5:</i> A web page may be delivered as
some HTML markup with embedded CSS styles that depend on media types. The
identification of the appropriate media type according to the delivery
context, and the resultant selection of the style to apply, should be
considered as part of the client-side adaptation process. The result of
selecting the appropriate style is a perceivable unit that can be rendered
into physical effects. The application of a CSS style sheet according to a
media type should therefore be considered as part of the adaptation process
under the control of adaptation preferences.</p>

<p>Some user experience changes may be achieved either through rendering
preferences or through adaptation preferences. However, as illustrated in
Example 2.3.1.2, it may be better to use adaptation preferences, if
available, to avoid the possibility of breaking user experience
functionality.</p>
<dl class="definition">
  <dt><a
  href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/#def-application-personalization">application
  personalization</a></dt>
    <dd>a set of factors, specified by a user or other aspects of the
      delivery context, that may affect the functionality of an application,
      independently of its adaptation and delivery, and so change the
      resultant user experience</dd>
</dl>

<p>Application personalization may include, for example, the preferred
language or the preferred location to which the user experience should if
possible be made specific.</p>

<p>Differences in user experience that are the result of application
personalization are <em>not</em> considered within the scope of device
independence.</p>

<p class="example"><i>Example 2.3.1.6:</i> A weather-forecasting application
may provide a forecast that is selected for the locality of the user. The
fact that the forecast is for a specific location is part of the application,
though it may use location information taken from the delivery context.
Localization is a form of application personalization, and is a separate
issue from the way the resultant forecast is presented to the user - for
example as a visual icon or as a text message - which can be affected by
adaptation preferences.</p>

<h4 id="section-DeliveryPrinciples">2.3.2 Delivery-related principles</h4>

<h5 class="principle-head" id="DIP-6">DIP-6: Characterization of delivery
context</h5>

<p class="principle">The user agent should be able to associate the
characteristics of the delivery context with a request for a particular web
page.</p>

<p>Unless the characteristics of the delivery context can be made available
to the adaptation process, it will not be possible to know whether a specific
user experience of some web page can be delivered in that context, or how to
generate a suitable user experience.</p>

<p class="example"><i>Example 2.3.2.1:</i> If it is known that only a
monochrome screen is available, different attributes than color may be used
to highlight important passages of text.</p>

<p class="example"><i>Example 2.3.2.2:</i> If it is known that the delivery
is to take place over a slow network connection, images may be reduced in
size or converted to text alternatives.</p>

<h5 class="principle-head" id="DIP-7">DIP-7: Adaptation preferences</h5>

<p class="principle">It should be possible for a user to provide or update
any adaptation preferences as part of the delivery context.</p>

<p>It is not only the user agent that may automatically contribute to the
adaptation preferences by providing characteristics of the delivery context.
The user may also provide adaptation preferences that may be used by the
adaptation process to offer a more suitable user experience, after taking
into account the constraints of the network and device. The adaptation
process may allow a user to obtain the most appropriate user experience for
their abilities and circumstances.</p>

<p class="example"><i>Example 2.3.2.3:</i> If in a hurry, a user may request
a lower quality presentation, such as lower resolution images, in order to
speed up web page delivery.</p>

<p class="example"><i>Example 2.3.2.4:</i> If in a car, a user may switch
between a visual presentation and a voice-only presentation, depending on
whether they are stationary or driving.</p>

<p>An author may wish to provide a specific user experience that is
harmonized with the access mechanism in a way that they define. But it is
important that this does not result in excluding users from obtaining a
functional experience that is best suited to their needs. <a
href="http://www.w3.org/TR/UAAG10/guidelines.html#gl-content-access">Guideline
2</a> of the User Agent Accessibility Guidelines [<a href="#UAAG">UAAG</a>]
states that users must have access to all content, including conditional
content. For example, the user agent could allow the user to update a
description of the delivery context to select the most appropriate adapted
version of the content for their needs.</p>
<hr />

<h2 id="section-Further">3 Associated work</h2>

<p>As indicated in the Introduction, these principles can form the foundation
of many approaches to achieving greater device independence: the creation of
guidelines, modification or extensions to existing markup languages,
adaptation techniques or new markup languages.</p>

<p>The W3C Technical Architecture Group is currently documenting principles
of Web architecture [<a href="#WEBARCH">WEBARCH</a>], which include issues of
presentation, content and interaction that are relevant to delivery across a
range of devices.</p>

<p>The W3C Device Independence Working Group is currently chartered [<a
href="#DIWG">DIWG</a>] to develop requirements for device independence and to
review device independence issues that may arise in other W3C groups and
external bodies.</p>

<p>In this section, we provide some pointers to associated documents and
current work at the time of writing. Please refer to the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a> home
page for the latest information.</p>

<p>The issues faced by authors in creating web pages that can be delivered to
many kinds of device are highlighted in Authoring Challenges for Device
Independence [<a href="#AC">AC</a>]. Current work is in progress on providing
an associated document on Authoring Techniques for Device Independence.</p>

<p>The issues of representing and conveying delivery context information are
separately considered in Delivery Context Overview for Device Independence
[<a href="#DCO">DCO</a>]. Current work is in progress on defining Core
Presentation Characteristics [<a href="#CPC">CPC</a>] that could be used to
specify device capabilities within the delivery context. Also, work on
Composite Capabilities/Preferences Profile [<a href="#CCPP">CCPP</a>] will
allow delivery context information to be represented and conveyed as part of
a request for a web page.</p>
<hr />

<h2 id="section-References">4 References</h2>
<dl>
  <dt>[<a name="AC" id="AC">AC</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/NOTE-acdi-20030901/">Authoring
      Challenges for Device Independence</a>, W3C Working Group Note 01
      September 2003<br />
      http://www.w3.org/TR/2003/NOTE-acdi-20030901/</dd>
  <dt>[<a name="ATAG" id="ATAG">ATAG</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/WD-ATAG20-20030314/">Authoring
      Tool Accessibility Guidelines 2.0</a>, W3C Working Draft 14 March
      2003<br />
      <i>For latest version see:</i><a
      href="http://www.w3.org/TR/ATAG20/">http://www.w3.org/TR/ATAG20/</a></dd>
  <dt>[<a name="CCPP" id="CCPP">CCPP</a>]</dt>
    <dd><a href="http://www.w3.org/TR/CCPP-struct-vocab/">Composite
      Capability/Preference Profiles (CC/PP): Structure and Vocabularies</a>,
      W3C Working Draft 28 July 2003<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/CCPP-struct-vocab/">http://www.w3.org/TR/CCPP-struct-vocab/</a></dd>
  <dt>[<a name="CPC" id="CPC">CPC</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/WD-cpc-req-20030510/">Core
      Presentation Characteristics: Requirements and Use Cases</a>, W3C
      Working Draft 10 May 2003<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/cpc-req/">http://www.w3.org/TR/cpc-req/</a></dd>
  <dt>[<a name="DCO" id="DCO">DCO</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2002/WD-di-dco-20021213/">Delivery
      Context Overview for Device Independence</a>, W3C Working Draft 13
      December 2002<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/di-dco/">http://www.w3.org/TR/di-dco/</a></dd>
  <dt>[<a name="DIA" id="DIA">DIA</a>]</dt>
    <dd><a href="http://www.w3.org/2000/10/DIAWorkshop/">W3C Workshop on Web
      Device Independent Authoring</a>, Bristol UK 3-4 October 2000<br />
      http://www.w3.org/2000/10/DIAWorkshop/</dd>
  <dt>[<a name="DIAT" id="DIAT">DIAT</a>]</dt>
    <dd><a href="http://www.w3.org/2002/07/DIAT/">W3C Workshop on Device
      Independent Authoring Techniques</a>, St. Leon-Rot, Germany 25-26
      September 2002<br />
      http://www.w3.org/2002/07/DIAT/</dd>
  <dt>[<a name="DIWG" id="DIWG">DIWG</a>]</dt>
    <dd><a
      href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">Device
      Independence Working Group Charter</a>, W3C Device Independence
      Activity 12 June 2002<br />
      http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html</dd>
  <dt>[<a name="DC" id="DC">DC</a>]</dt>
    <dd><a href="http://www.w3.org/2002/02/DIWS/">W3C Delivery Context
      Workshop</a>, St. Leon-Rot, Germany 25-26 September 2002<br />
      http://www.w3.org/2002/02/DIWS/</dd>
  <dt>[<a name="Glossary" id="Glossary">Glossary</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/WD-di-gloss-20030825/">Glossary
      for Device Independence</a>, W3C Working Draft 25 August 2003<br />
      http://www.w3.org/TR/2003/WD-di-gloss-20030825/<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/di-gloss/">http://www.w3.org/TR/di-gloss/</a></dd>
  <dt>[<a name="MMW" id="MMW">MMW</a>]</dt>
    <dd><a href="http://www.w3.org/2000/09/Papers/Agenda.html">W3C/WAP
      Workshop on the Multimodal Web</a>, Hong Kong 5-6 September 2000<br />
      http://www.w3.org/2000/09/Papers/Agenda.html</dd>
  <dt>[<a name="PWD" id="PWD">PWD</a>]</dt>
    <dd><a
      href="http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/20010104.html">How
      People with Disabilities use the Web</a>, W3C Working Draft 4 January
      2001<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/">http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/</a></dd>
  <dt>[<a name="UAAG" id="UAAG">UAAG</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/">User Agent
      Accessibility Guidelines 1.0</a>, W3C Recommendation 17 December
      2002<br />
      http://www.w3.org/TR/2002/REC-UAAG10-20021217/</dd>
  <dt>[<a name="URI-Style" id="URI-Style">URI-Style</a>]</dt>
    <dd><a href="http://www.w3.org/Provider/Style/URI.html">Cool URIs don't
      change</a>, Tim Berners-Lee 1998<br />
      http://www.w3.org/Provider/Style/URI.html</dd>
  <dt>[<a name="WCAG" id="WCAG">WCAG</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/WD-WCAG20-20030624/">Web Content
      Accessibility Guidelines 2.0</a>, W3C Working Draft 24 June 2003<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/WCAG20/">http://www.w3.org/TR/WCAG20/</a></dd>
  <dt>[<a name="WEBARCH" id="WEBARCH">WEBARCH</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/WD-webarch-20030627/">Architecture
      of the World Wide Web</a>, W3C Working Draft 27 June 2003<br />
      <i>For latest version see:</i> <a
      href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a></dd>
</dl>
<hr />

<h2 id="section-Appendices">Appendices</h2>

<h3 id="section-Usage">A Usage scenarios</h3>

<p>This section illustrates various ways in which users interact with the
Web. The examples outlined here are intended to portray the potential
benefits of device independence from an end user perspective. Associated with
each scenario is a determination of the relevance to device independence and
the principles outlined in the text above, and the considerations from an
authoring perspective.</p>

<h4 id="section-Usage-1">A.1 Choice of access device</h4>

<p>Ms. Kaseem is a teenager with low vision who is also deaf. She uses the
Web to find new restaurants to go to with her friends and classmates. At home
she uses a combination of screen magnifier and screen reader with refreshable
Braille to browse the Web. She also has a portable Braille device which she
uses in public places such as malls and restaurants. See the <a
href="http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html#teenager">teenager
example</a> from How People with Disabilities Use the Web [<a
href="#PWD">PWD</a>] for a detailed outline of the use case.</p>

<p><em>Relevance to Device Independence</em>:: Depending upon her needs, Ms.
Kaseem uses different access mechanisms to interact with the Web.
Accessibility may be improved through device independence.</p>

<p><em>Authoring perspective</em>: The web page should be accessible to Ms.
Kaseem in terms of support for functional user experiences on multiple
devices.</p>

<h4 id="section-Usage-2">A.2 Choice of connectivity</h4>

<p>Peter is a sales Manager for a Silicon Valley company, responsible for all
accounts in the US Midwest. While he is not on the road, he works out of his
Denver home. He accesses the web based corporate Sales Force Automation
application from his laptop PC over a DSL 1.5 Mbps connection in his home
office. However when he is at customer sites, he uses a PCMCIA-based GPRS
modem in his laptop to get to the application over a wireless network.</p>

<p><em>Relevance to Device Independence</em>: A change in the delivery
context resulting from a choice of available connection transport mechanisms
to access the Web is within the scope of device independence.</p>

<p><em>Authoring perspective</em>: The presentation should vary according to
connectivity capabilities. The functional user experience under either
mechanism could likely be the same, but the harmonized user experience would
probably be tailored to the characteristics of the underlying network. For
example, rich content such as high resolution images would be possible over a
DSL line, but the same image could have relatively lower resolution to speed
up download over a 28.8 kbps connection.</p>

<h4 id="section-Usage-3">A.3 Choice of interaction modality</h4>

<p>Nancy has a 45 minute work commute across town every day. Just as she is
stepping out, she checks traffic conditions from her favorite local web site
using her web enabled mobile phone. Once she gets into the car, the car
computer (with position sensing capability) synchronizes with her phone.
Today she is stuck in traffic midway. She uses a hands-free voice interface
in order to discover alternate routes that will get her to the office
faster.</p>

<p><em>Relevance to Device Independence</em>: The modality of interaction
that Nancy uses to obtain information from the Web has changed depending upon
whether she is driving or stationary. Modality choices should be supported by
device independence.</p>

<p><em>Authoring perspective</em>: Modality is part of the delivery context
and should be taken into consideration while determining the user experience
provided by a web page.</p>

<h4 id="section-Usage-4">A.4 Choice of presentation</h4>

<p>Mr. Wright has purchased pre-paid GPRS enabled PDAs for his sons, Jimmy
and Tommy. While they both like to download the latest Dennis the Menace
cartoon from the same web site, Jimmy and Tommy however have different views
on how to spend the $30 pre-paid card their dad has given them. Jimmy prefers
the cartoon to be downloaded as high resolution images most of the time,
while Tommy prefers a small picture in low resolution graphics, thus saving
up to chat with his friends via instant messages later.</p>

<p><em>Relevance to Device Independence</em>: The preferences of the user are
part of the delivery context and may impact the resultant user experience.
This is within the scope of the principles for device independence.</p>

<p><em>Authoring perspective</em>: The author may wish to support multiple
user experiences of the same web page depending upon individual adaptation
preferences. Such preferences are independent of the rendering preferences
that may be provided locally in the user agent.</p>

<h4 id="section-Usage-5">A.5 Multi-modal interaction</h4>

<p>Mr. Gray is an executive who travels to headquarters regularly for staff
meetings. Today the meeting is running later than usual. He needs to
rearrange his schedule such that he is on a later flight in the evening. He
uses his web enabled phone to reschedule his flights. He enters his flight
preferences by talking to the system, but selects seating via graphical
display. The confirmation is played to him by voice, but he also receives a
text notification which he can save for later reference.</p>

<p><em>Relevance to Device Independence</em>: Device independence is
concerned about the ability to provide user experiences for different
modalities, including multi-modal access mechanisms.</p>

<p><em>Authoring perspective</em>: The author may need to take into account
the multiple modalities active during a navigation session and their
interactions in such a way as to provide a functional or customized user
experience to the user. However, the special considerations involved in
synchronizing multi-modal presentations are outside the scope of the Device
Independence Working Group.</p>

<h4 id="section-Usage-6">A.6 Transactions that span devices</h4>

<p>Angela subscribes to a service run by a local concert hall that informs
her of late availability of tickets at discount prices. At work one morning,
she receives notification of availability of tickets for a concert including
Mahler's Fifth Symphony. She has been waiting for the opportunity to take her
mother to a Mahler concert for some time. Using her PC she provisionally
books two tickets in prime locations in the knowledge that she must purchase
them within 6 hours or lose the booking. She bookmarks the acknowledgement
returned by the concert hall and synchronizes it with her PDA. Later in the
day, on the way back to the office after a meeting with a client, she finally
manages to contact her mother, who is delighted at the invitation and looking
forward to the concert. Angela realizes that she must confirm the booking
soon. She returns to the concert hall's bookmark using her PDA, confirms the
booking and pays for the tickets.</p>

<p><em>Relevance to Device Independence</em>: The concert hall web site is
enabled for access from multiple devices. Angela needs to bookmark only one
URI for her transaction, regardless of the device she accesses the site from.
This is within the scope of device independence.</p>

<p><em>Authoring perspective</em>: A web site that is user friendly provides
device independent URIs for access to its services (including any encoding of
transaction identity). The transaction may be initiated using one access
mechanism and consummated via another, seamlessly, even though the user
experience might vary.</p>

<h3 id="section-Changes">B Main changes since last working draft</h3>

<p>Since the <a href="http://www.w3.org/TR/2001/WD-di-princ-20010918/">last
Working Draft</a> of this document, some terminology has been changed.</p>

<p>'User experience' is now used instead of 'presentation', so that it is
clearer that user interaction (input) as well as rendered effects (output)
are included in the term.</p>

<p>'Harmonized' is now used instead of 'customized', so that there is less
likely to be confusion with application-specific customization. For example,
a web page that presents application information that is specific to a
particular context, such as a weather forecast for a locality, may be called
'customized', whereas 'harmonized' is now used to mean that the user
experience of perceiving that information has been well-matched to the access
mechanism.</p>

<p>'Adaptation preferences' is now used instead of 'presentation preferences'
to make the distinction from rendering preferences and application
customization clearer.</p>

<p>The 'Glossary' Appendix has been removed and replaced by references to a
separate Glossary document.</p>

<p>The 'Implementation scenarios' Appendix has also been removed pending a
future, more comprehensive, survey of authoring techniques.</p>

<p>Some changes have also been made in response to the <a
href="http://www.w3.org/2001/di/public/dip/di-princ-draft-issues.html">issues
raised</a> on the last Working Draft.</p>

<h3 id="section-Acknowledgements">C Acknowledgements</h3>

<p>Members of the W3C Device Independence Working Group have helped develop
this Working Group Note through their comments, proposals and discussions at
teleconferences, face-to-face meetings and via the group discussion list.</p>

<p>At the time of publication, the principal and active members of the group
were as follows:</p>
<dl>
    <dd>Stephane Boyera (W3C)</dd>
    <dd>Steve Farowich (Boeing)</dd>
    <dd>Roger Gimson (HP)</dd>
    <dd>Yoshihisa Gonno (Sony Corp)</dd>
    <dd>Guido Grassel (Nokia)</dd>
    <dd>Rotan Hanrahan (MobileAware Ltd)</dd>
    <dd>Kazuhiro Kitagawa (W3C)</dd>
    <dd>Markus Lauff (SAP AG)</dd>
    <dd>Tayeb Lemlouma (INRIA)</dd>
    <dd>Rhys Lewis (Volantis Systems Ltd)</dd>
    <dd>Roland Merrick (IBM)</dd>
    <dd>Franklin Reynolds (Nokia)</dd>
    <dd>Andreas Schade (IBM)</dd>
    <dd>Ryuji Tamagawa (Sky Think System)</dd>
    <dd>Luu Tran (Sun Microsystems)</dd>
    <dd>Michael Wasmund (IBM)</dd>
    <dd>Stan Wiechers (Merkwelt)</dd>
    <dd>Jason White (University of Melbourne)</dd>
    <dd>Candy Wong (NTT DoCoMo)</dd>
    <dd>Amy Yu (SAP AG)</dd>
</dl>

<p>The following were members of the group at earlier stages of its
drafting:</p>
<dl>
    <dd>Yasser AlSafadi (Philips Research)</dd>
    <dd>Abbie Barbir (Nortel Networks)</dd>
    <dd>Einar Breen (Adaptive Media)</dd>
    <dd>Shlomit Ritz Finkelstein (invited expert)</dd>
    <dd>Vidhya Golkar (Argogroup)</dd>
    <dd>Luo Haiping (Comverse)</dd>
    <dd>Eric Hsi (Philips Research)</dd>
    <dd>Lynda Jones (SHARE)</dd>
    <dd>William Loughborough (Smith-Kettlewell Institute)</dd>
    <dd>Stephane Maes (IBM)</dd>
    <dd>Kaori Nakai (NTT DoCoMo)</dd>
    <dd>Hidetaka Ohto (W3C/Panasonic)</dd>
    <dd>Garland Phillips (Motorola)</dd>
    <dd>Lalitha Suryanarayana (SBC Technology Resources)</dd>
    <dd>Yoshifumi Yonemoto (NTT DoCoMo)</dd>
</dl>
<hr />
</body>
</html>