Changes from the previous public Working Draft are shown with a pale gray background
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.
This document has been produced as an overview document from the W3C Device Independence Activity. It is intended to provide a set of principles that can guide work relating to device independence.
This document is a W3C Working Group Note. It represents the views of the W3C Device Independence Working Group at the time of publication. There are currently no plans to amend this document further. Publication as a Working Group Note does not imply endorsement by the W3C Membership.
This document has been produced as the first public document from the W3C Device Independence Activity. It is intended to provide a set of principles that can guide further work relating to device independence. Feedback is requested from W3C groups and the Web community at large.
A version of this document is also available showing changes since the previous Working Draft.
Comments on, and discussion arising from, this document can be sent to firstname.lastname@example.org, the public forum for discussion of the W3C's work on Device Independence. To subscribe, send an email to email@example.com with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.
Patent disclosures relevant to this document may be found on the WG patent disclosure page.
The intended audience for this document is primarily other W3C Working Groups and external organizations involved in developing web content authoring and delivery technologies.
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 interacting with presentationsdelivered 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.
The vision we share with others is to allow the Web to be accessible by anyone, anywhere, anytime, anyhow. The focus of the W3C Web Accessibility Initiative is on making the Web accessible to anyone, including those with disabilities. The focus of the W3C Internationalization Activity is on making the Web accessible anywhere, including support for many writing systems and languages. The focus of the W3C Device Independence Activity 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).
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.
The principles described here are intended to be complementary to the wider Architecture of the World Wide Web [WEBARCH], 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 [WCAG], the User Agent Accessibility Guidelines[UAAG] and the Authoring Tool Accessibility Guidelines [ATAG].
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 lead toform the basis of more detailed requirements and recommendations in the future.
The principles are independent of any specific markup language, authoring style or adaptation process. They do not propose specific requirements, guidelines or technologies.
It is intended, however, that these principles be used as a foundation when proposing greater device independence through, for example:
Because these principles are expressed at an abstract level, it will be necessary to identify more detailed requirements before any specific technology-dependent solutions to device independence are proposed.
Other documents provide more details on the authoring challenges [AC] and the delivery context issues [DCO] associated with achieving device independence.
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.
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.
In the appendix on Usage scenarios we give examples of circumstances in which access to the Web may be required via different access mechanisms.
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 prevent fragmentation of the informationsave costs, and assist the authors in presentingproviding users with the informationan improved user experience anytime, anywhere and via any access mechanism.
In the appendix on Implementation scenarios we give examples that illustrate several approaches that could be used to deliver information via different access mechanisms. They include some approaches that are based on existing W3C Recommendations and some that are not.
In the following section, the impact of device independence is considered from three different perspectives:
For each perspective, significant concepts for device independence are defined and appear as follows:
A separate Glossary for Device Independence [Glossary] collects together in one placeincludes all the definitions introduced in the body of this document as well as those from other documents produced by the Device Independence Activity.
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.
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:
Within this document, principles are stated in this style.
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:
Example: Within this document, examples are shown in this style.
A number of issues have been raised as requiring further implementation-oriented work that would be better considered separately. They are mentioned at appropriate points in the text, and are summarized in the section on Further work.
In this section a number of principles are introduced which are fundamental to the achievement of device independence.
They are called principles (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.
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 RFC2119).
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.
The following diagram introduces the key user-related concepts, which are then defined and explained in the subsequent text.
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.
The main concepts for the user are as follows.
Example 188.8.131.52: Existing devices that are commonly used to access the Web include PCs, PDAs, web-enabled phones, and interactive TVs.
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 presentation toperception by, and interaction with, the user.
From the user's point of view, an access mechanism often corresponds to a single device.
However, in some situations, the access mechanism may consist of more than one device.
Example 184.108.40.206: 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.
Example 220.127.116.11: 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.
Sometimes the access mechanism may include the use of additional network support.
Example 18.104.22.168: 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 providesenables an auditory presentationperception of the web content.
Sometimes the access mechanism may support synchronization offor multi-modal presentationsinteraction.
Example 22.214.171.124: 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.
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.
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.
Example 126.96.36.199: A user may see a web page identifier, such as "www.example.com" used in an advertisement. They expect to be able to enter this into their device to get a presentation about the advertiser or productuse this identifier to access further information about the advertiser or product in the form of an appropriate user experience.
In some cases, such as in voice-only browsing, the user may not know the web page identifier being used to retrieve the next piece of the presentationperceivable unit.
There is further discussion of web page identifiers, and what restrictions might need to be placed on URIs to achieve device independence, in the section on Further work.
The presentation pageA 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 presentation pageperceivable unit.
Example 188.8.131.52: If a user entered the web page identifier "www.example.com" into a web-connected PDA, the resultant presentation pageperceivable 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.
The physical user interface is where the information that was transmitted digitally becomes accessible to and manipulable by the user.
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 presentation pagesperceivable units required to present somea web informationpage may vary.
Example 184.108.40.206: A limited capability device, such as a mobile phone, may only accept small packets of presentation information at a time. Some web information whose presentation consists of only a single presentation page on a large device may instead require several presentation pages on the small deviceaccept 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.
The quality of the user experience depends on the degree to which a web pagematerial has been successfully adapted for presentationuse 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 a presentationone or more perceivable units will affect the ease of use of that device for the user.
The next concept is about the quality of the presentationuser 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 for a presentation to be useful to a user.
The function intended by the author may be as simple as to convey some information to the user.
Example 220.127.116.11: If the intended function is for the user to be able to perceive a passage of text, a functional presentationuser experience should be sufficient to make a readable or audible physical presentationmight provide visible or audible representations of it.
The function intended may be as complex as guiding the user through a sequence of application-specific interactions.
Example 18.104.22.168: If the intended function is for the user to take the next step in some interactive application, a functional presentationuser experience should be sufficient for the user, say, to successfully fill in a data field and submit it.
A functional presentationuser experience is defined with respect to a particular access mechanism. It may not be possible to achieve a functional presentationuser experience for some particular content or application for every access mechanism, due to inherent limitations of the mechanism.
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.
Example 22.214.171.124: 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 the voice presentationthis particular audible representation is not functional for his or her purpose. However, this would beis a user-centric definition of functional presentationuser 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.
Whether the presentationuser experience associated with a web page identifier is considered by the user to be functional clearly depends on their understanding of the function associated with that web page identifier. 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 presentationuser 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 presentationuser experience to estimate whether it is functional.
Many things may prevent completion of a function, such as when a presentationuser 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 presentationuser experience is not functional.
For some web content or application to be device independent, it should be possible for a user to obtain a functional presentationuser experience associated with its web page identifier via any access mechanism.
This is the fundamental principle for device independence from the user perspective. It does not say that the presentationuser experience will be the same on every device. But it does say that the user should be able to obtain a presentationuser experience and that the presentationuser experience obtained should be at least functional.
Example 126.96.36.199: A user enters a web page identifier for a weather forecasting page on different devices. On the screen of a PDA, the presentation page shows the text "Tomorrow" is shown, together with a visual graphic of a sun. On the screen of a phone, the presentation page shows the text "Tomorrow: sun" is shown. On the speaker of an in-car PC, the presentation page speaks the words "Tomorrow will be sunny" are spoken. These are all presentationsuser experiences that have been adapted to be functional for their specific access mechanisms.
Example 188.8.131.52: If on some device the same web page identifier as in the previous example gave either no presentationuser experience, or a presentationuser experience consisting of the text "Cannot display graphics", this would not be a functional presentationuser experience.
The goal is that a functional presentationuser experience should be possible via any access mechanism. The method of presentationby which presentation and interaction are provided may vary according to the different access mechanisms, but the possibility of a functional presentationuser experience should always exist.
In particular, it should be possible to provide a functional presentationuser experience even on a limited capability (i.e. low-cost) device - though it may be of reduced quality compared to that on more capable devices.
Example 184.108.40.206: 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.
A web page identifier that provides a functional presentationuser experience via one access mechanism should also provide a presentationuser experience of equivalent functionality via any other access mechanism.
In other words, the intended function of a web page is associated with the web page identifier, and should apply to all presentationsuser experiences obtained from the web page identifier, no matter what the access mechanism.
Example 220.127.116.11: By bookmarking thea web page identifier of a presentation pagethat provides a functional user experience on one device it should be possible to obtain a corresponding presentation page (or set of pages)user experience on another device with equivalent functionality. The presentationsuser 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.
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 the presentation formatits representation, such as "example.html", may need the suffix to be ignored when adapting a presentationthe 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 [URI-Style].
Further consideration of how web page identifiers should be interpreted to achieve greater device independence is left for future work (see Further work).
The following diagram introduces the key authoring concepts, which are then defined and explained in the subsequent text.
The main concepts for authoring are as follows.
When a request is made over the Web for a presentationweb 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 presentationuser experience can be provided.
Delivery context information may be sent as part of each request, but this is not essential. Alternative possible implementations are discussed in the section on Further work in the separate Delivery Context Overview [DCO] document.
The delivery context expresses the capabilities and preferences that may constrain the acceptable range of presentationsuser experiences that can be delivered via a given access mechanism. In particular, the capabilities of the device, including the modalities and presentation formatsrepresentations it supports, the characteristics of the network over which the presentation is delivereddelivery occurs, and the presentation preferences of the user will all potentially affect what presentation should bethe user experience provided.
Example 18.104.22.168: 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.
The transfer might, for example, be between an origin server and a user agent. Users are not normally aware of individual delivery units.
The response to a request containing a web page identifier is a replydelivery unit which contains the presentation data (in a markup language or image encoding, for example) that will be used by the access mechanism in order to render a physical presentation pageuser experience. It will also allow the user to interact with that page, and possibly generate a further request.
Example 22.214.171.124: Markup languages such as HTML, XHTML, SVG, etc. are designed specifically as a representation for expressing presentationsways 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 a presentationthe 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. These are all examples of presentation data that could be included in delivery units.
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 [DCO] for further explanation.
There are many techniques that could be used to produce an appropriate presentation datauser experience in response to a request for a web page identifier. Some of them are illustrated in the example Implementation scenarios. Since these principles are intended to be technology independent, no further exploration of the adaptation process is made here. However, the Working Group has discussed a possible framework for device independent authoring. This is described briefly in the section on Further work.
The authoring perspective instead focuses on the quality of presentationuser experience produced by the adaptation process and on the obligations on the authoring task.
The concept of functional presentationuser experience has already been introduced as part of the user perspective.
However, though a presentationuser 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.
CustomizationHarmonization allows the presentationuser experience to be made more specific to the delivery context in order to meet criteria, such as ease of use and quality of presentationuser 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 or the overall user experience.
Example 126.96.36.199: The layout of a graphical presentation may take into account the dimensions of the display, as conveyed to the adaptation process in the delivery context. The same information may be given different customized presentations, such as being laid out differently according to the display size to achieve a better visual effect, or to reduce the amount of scrolling required by the user. This does not affect the functionality of the presentation, but may be important to some authors. 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.
Authoring tools and adaptation processes may differ in the extent to which they support customizedharmonized presentationsuser experiences.
The following principles are directed towards the authoring and adaptation process that is responsible for providing presentation dataa delivery unit in reply to a request from a user.
It should be possible to provide a functional presentationuser experience, in response to a request for a web page identifier, in any given delivery context that has an adequate access mechanism.
This principle places an obligation on the author, the authoring tools and the adaptation process to provide a presentationuser experience that allows a user to successfully access a web page to get the information or complete the interaction intended.
The principle is effectively a restatement of DIP-1 from the point of view of the producer rather than the consumer.
Sometimes it is not possible to provide some content or functionality in a given delivery context because of limitations in the access mechanism.
If a functional presentationuser experience of an application cannot be provided due to inherent limitations in the access mechanism, a functional presentation of an erroran explanatory message should be provided to the user.
Example 188.8.131.52: 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 presentationuser 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).
If the author wishes, it should be possible to provide a customizedharmonized presentationuser experience, in response to a request for a web page identifier, in any given delivery context that has an adequate access mechanism.
This goes beyond the previous principle to additionally allow that the author can provide a presentationuser experience that offers the user an 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 presentationsuser experiences tailored for specific access mechanisms when the author requires them.
In many situations, it is necessary to be specific about how some web page will be presented. It is not sufficient that only predefined or standard presentations should be used. Authors should be able to control presentation details if they wish. At the most detailed level, a presentation could be focused on only a very restricted delivery context. However, DIP-2 means that this could not be the only presentation, since a functional presentation should be available in every delivery context. 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, DIP-2 requires that other adaptations be available to provide functional user experiences for the other delivery contexts.
Example 184.108.40.206: Some devices, especially small ones such as phones, are highly constrained in their capabilities. To create a sufficiently user-friendly presentationuser experience of some application, it may be necessary to customizeharmonize the presentationuser experience for that particular application on that particular phone.
It is unrealistic to expect an author to create different presentation datauser experiences for every delivery context. Whenever possible, authored source content should be reused across multiple delivery contexts.
Functional presentationsuser 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.
Example 220.127.116.11: One approach to device independent authoring is to use a transformation technique such as XML/XSLXSLT (see Implementation scenarios). By creating the content in XML, the same content can be adapted for different delivery contexts using XSL stylesheets.
Some authoring approaches based on device independent representations may in addition allow customized presentationsuser experiences to be provided for some delivery contexts.
See Further work for a discussion on a framework for device independent authoring.The issues facing authors are described in more detail in the separate document Authoring Challenges for Device Independence [AC].
The following diagram introduces the key delivery concepts, which are then defined and explained in the subsequent text.
The main concepts for delivery are as follows.
The user agent is some software or firmware in a device (for example a browser) that lets the user identify a presentationweb page to be rendered, assembles an appropriate request for that page (possibly including the delivery context), accepts the reply (including the presentation datadelivery unit), and renders that reply into a physical presentationone or more perceivable units.
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.
Example 18.104.22.168: 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, <deck>, and the perceivable unit, <card>.
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 presentationuser experience: the renderer in the user agent, the presentationsome adaptation process (in the server, client or an intermediary), or the functionality of the application itself.
It may be possible for a user agent, under the control of rendering preferences, to make local adaptationschanges to a presentationperceivable unit as it is rendered. This will depend on the local behavior of the user agent within the device.
Example 22.214.171.124: 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.
In current user agents, such rendering preferences are not communicated as part of the delivery context and so do not affect the presentation datadelivery unit deliveredsent to the device. However, this also means it is possible for a presentationuser experience to become non-functional through inappropriate choice of rendering preferences.
Example 126.96.36.199: A presentationuser 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.
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.
Example 188.8.131.52: 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 a presentationan adaptation preference for no images, the adaptation process may be able to provide a better text-only presentation, customized forharmonized with the delivery context, than could be achieved by locally replacing all images by their text alternates.
Some adaptation processes may occur within the network, for example in transcoding proxies, or in the access mechanismclient prior to the final presentation dataperceivable unit being rendered.
Example 184.108.40.206: 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, even though it is performed in the access mechanism. After selecting the appropriate style, there is still a notional presentation markup, prior to its rendering into a physical presentation. 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 presentationadaptation preferences.
Some presentationuser experience changes may be achieved either through rendering preferences or through presentationadaptation preferences. However, as illustrated in Example 220.127.116.11, it may be better to use presentationadaptation preferences, if available, to avoid the possibility of breaking presentationuser experience functionality.
Application personalization may include, for example, the preferred language or the preferred location to which the presentationuser experience should if possible be made specific.
Differences in presentationuser experience that are the result of application personalization are not considered within the scope of device independence.
Example 18.104.22.168: 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 presentationadaptation preferences.
The user agent should be able to associate the characteristics of the delivery context with a request offor a particular web page identifier.
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 presentationuser experience of some web page can be delivered in that context, or how to generate a suitable presentationuser experience.
Example 22.214.171.124: If it is known that only a monochrome screen is available, different attributes than color may be used to highlight important passages of text.
Example 126.96.36.199: 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.
See Further work for a discussion of the implementation of delivery context.
It should be possible for a user to provide or update any presentationadaptation preferences as part of the delivery context.
It is not only the user agent that may automatically contribute to the adaptation preferences by providing characteristics of the delivery context. If the user providesThe user may also provide presentationadaptation preferences, they that may be used by the adaptation process to offer a more suitable presentationuser experience, after taking into account the constraints of the network and device. The adaptation process may allow a user to obtain the most appropriate presentationuser experience for their abilities and circumstances.
Example 188.8.131.52: 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.
Example 184.108.40.206: 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.
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. Guideline 2 of the User Agent Accessibility Guidelines [UAAG] 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.
In this section, we summarize the issues that have arisen during the preparation of this document that will require further work. 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.
The W3C Technical Architecture Group is currently documenting principles of Web architecture [WEBARCH], which include issues of presentation, content and interaction that are relevant to delivery across a range of devices.
The W3C Device Independence Working Group is currently chartered [DIWG] to develop requirements for device independence and to review device independence issues that may arise in other W3C groups and external bodies. The following items should not therefore be taken either as a complete or even necessary list of the work of the group.
In this section, we provide some pointers to associated documents and current work at the time of writing. Please refer to the W3C Device Independence Activity home page for the latest information.
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 [AC]. Current work is in progress on providing an associated document on Authoring Techniques for Device Independence.
The issues of representing and conveying delivery context information are separately considered in Delivery Context Overview for Device Independence [DCO]. Current work is in progress on defining Core Presentation Characteristics [CPC] that could be used to specify device capabilities within the delivery context. Also, work on Composite Capabilities/Preferences Profile [CCPP] will allow delivery context information to be represented and conveyed as part of a request for a web page.
Many techniques have been developed by application and server developers to convey additional information as part of a URI. For example, the type of content of a page may be indicated by a suffix such as ".html". Or web links within a session may include a session identifier within the query part of their URI. Some of these techniques unfortunately do not respect the intent of URI style guidelines [URI-Style].
In addition, for pages that may be partitioned differently according to the presentation capabilities of the access mechanism, it is not clear how the use of fragment parts (after a # within the URI) or query parts (after a ? within the URI) might relate to the use of hierarchies (using / within the URI).
Some of these techniques may be application-specific issues that can be left to the implementers of specific web sites. However, it may be that some of them require support to be provided in user agents. For example it may be advisable to remove device-dependent elements when presenting URIs to users or when saving bookmarks that can be exchanged with other devices.
If web page identifiers are to be usable across access mechanisms, as suggested in DIP-2, guidelines or recommendations should be developed as to how URIs may be used in a device independent way. This should include consideration of how any new proposals or restrictions would work with existing techniques.
Though some initial discussion has taken place within the Device Independence Working Group on some of the issues, wider consideration will be necessary before any proposals can be put forward.
The W3C CC/PP profile [CCPP] is one method of characterizing the delivery context. This is also the basis for the WAP Forum User Agent Profile specification [UAProf]. Other, less flexible, methods include the use of the HTTP/1.1 [HTTP] request header, or use of part of the URI such as the URI query component [URI].
Today CC/PP and UAProf are not widely supported to convey delivery context and existing user agents can't rely on them being accepted by servers. HTTP headers can convey a limited amount of delivery context information. URI extensions are also sometimes used for conveying some aspects of the delivery context.
For device independence to become widely supported, it will be necessary to indicate how the transition can be made from existing widely supported techniques of representing the delivery context towards future, more complete, proposals such as CC/PP.
At a more implementation-specific level, this document has shown the delivery context being associated with a request for a web page. There are several possibilities here. It is not necessary that the whole context is sent with each request. It could be that only a reference to the context is sent. Or that the context is managed on a session basis, or based on profiles stored elsewhere.
CC/PP provides a possible representation for conveying delivery context information. However, the way in which the delivery context should be generated by the access mechanism (user agent) and the interpretation of the delivery context by the server (and possibly also by intermediate proxies) will need further recommendations to be developed. Ways of conveying the delivery context in device independent ways using existing techniques, prior to CC/PP becoming widely adopted, should also be considered.
The task of authoring many different presentations of a web site, suitable for delivery to a proliferation of devices, could become overwhelming. Even using some of the techniques outlined in the Implementation scenarios, there may be many different versions of style sheets, transcoding techniques or programming objects to be created and managed.
An important goal in order to minimize the authoring burden is to reduce the number of different versions that must be supported. This is helped by encouraging everyone to adopt a few well-defined recommendations for presentation markup language, delivery context description and other aspects of the protocol between web client and web server. This approach is central to the work of the W3C.
Even so, there will be legacy languages and protocols that must be considered, and there will continue to be a diversity of device capabilities that must be supported.
Some early discussion has been held in the Device Independence Working Group on defining a framework for device independent authoring. The intent would be to show how the authoring burden could be minimized through clear separation of business logic (application-oriented functionality), interaction logic, adaptation rules and customization metadata. These would form the input (expressed in some intermediate representation) to an automatic adaptation process.
Further work in this area is currently outside the charter of the group.
This is a collection of all the terms defined in this document, sorted into alphabetical order.
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.
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 teenager example from How People with Disabilities Use the Web [PWD] for a detailed outline of the use case.
Relevance to Device Independence:: Depending upon her needs, Ms. Kaseem uses different access mechanisms to interact with the Web. Accessibility may be improved through device independence.
Authoring perspective: The web page should be accessible to Ms. Kaseem in terms of support for functional presentationuser experiences on multiple devices.
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.
Relevance to Device Independence: 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.
Authoring perspective: The presentation should vary according to connectivity capabilities. The functional presentationuser experience under either mechanism could likely be the same, but the customized presentationharmonized 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.
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.
Relevance to Device Independence: 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.
Authoring perspective: Modality is part of the delivery context and should be taken into consideration while determining the final presentation ofuser experience provided by a web page.
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.
Relevance to Device Independence: The preferences of the user are part of the delivery context and may impact the generated presentationresultant user experience. This is within the scope of the principles for device independence.
Authoring perspective: The author may wish to support multiple presentationsuser experiences of the same web page depending upon individual presentationadaptation preferences. Such preferences are independent of the rendering preferences that may be provided locally in the user agent.
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.
Relevance to Device Independence: Device independence is concerned about the ability to provide presentationsuser experiences for different modalities, including multi-modal access mechanisms.
Authoring perspective: 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 presentationuser experience to the user. However, the special considerations involved in synchronizing multi-modal presentations are outside the scope of the Device Independence Working Group.
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.
Relevance to Device Independence: 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.
Authoring perspective: 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 presentation and user interactionuser experience might vary.
This section gives some example scenarios that illustrate different ways that implementers are currently attempting to achieve device independence. It is included here to show that device independence could be achieved using a number of different approaches.
All these scenarios are based on a web information author or aggregator who has to ensure that their information can be rendered to multiple devices - which could range from low end mobile terminals to high end desktop PCs, or from voice-only interfaces to accessible terminal devices for the physically challenged. Depending upon their awareness of web technologies, level of sophistication of authoring and availability or familiarity with content generation or adaptation tools, the author may approach the problem in several different ways.
Authoring: The author creates multiple versions of the same web information, each with different features representing delivery specific customization. Thus many variants of the same information must be developed, maintained and updated.
Adaptation: When a request for information is received, the appropriate variant of the information is selected based on the delivery context (such as the capabilities of the requesting device, user preferences and other constraints).
Authoring: The author creates only one set of source information. This is, as far as possible, independent of any device specific features. The source set of information may be in a non-presentation form such as ASCII text, XML [XML] or other encodings. The author also creates customized templates or style sheets for each delivery context, for example using CSS [CSS] or XSL [XSL]. These may be created a priori or dynamically. The customization incorporated into these style sheets or templates depends upon the type of content to be rendered. Thus multiple variants of the transformations or style sheets must be developed, maintained and updated.
Adaptation: When a request for information is received, the delivered variant is generated from the combination of the content and the appropriate template. Alternatively, the content is returned along with the appropriate style sheets, and the device user agent is responsible for presentation based on the received style sheet. In a third scenario, a proxy based agent may carry out the task of putting together the content and the template.
Authoring: The author creates only one set of content in a markup
language such as XML [XML] or XHTML [XHTML-1]. This content is transformed into other markups
for other delivery contexts. The transformation may be automatic, dynamic or
static - with the use of technologies such as XSLT [XSLT]
- and can be carried out either at the origin server or an intermediate proxy.
The range of transformation may vary from only syntactic or markup specific,
to a semantic mapping for elements in one language that are not present in
another. For example, if a markup language does not have the
alt attribute may be used to render the text version
of that content. It may also include transformation from one media format to
Adaptation: The content is transformed on the server, or at a transcoding proxy along the way, prior to being rendered by the client.
Authoring: The author creates a set of reusable object components and associated programming logic for their combination and execution. Examples include Java Server Pages [JSP] and Model-View-Controller architectures such as the Apache Struts Framework [Struts].
Adaptation: Depending upon the type of device that the content is to be rendered to, suitable objects are combined, and the logic executed in real-time to generate output customized to the channel.
Authoring: The content is complex in that it makes use of a combination of the cases listed above. The author must therefore enable and implement multiple mechanisms for developing and generating content.
Adaptation: Depending upon the type of content, a combination of adaptation approaches may be necessary.
Authoring: The author writes an abstract intermediate representation of the application. This intermediate representations describes the user interaction independently of the access mechanism. It also supports additional meta-information for customization for a particular channel. This can be done by providing in-line annotations that affect the adaptation process or by overwriting the default re-usable style sheets for this access mechanism.
Adaptation: At run time, the intermediate representation is adapted into default functional presentation pages using re-usable style sheets that depend only on the delivery context. If additional customization meta-information is available for that delivery context, the adaptation is accordingly customized.
Since the last Working Draft of this document, some terminology has been changed.
'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.
'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.
'Adaptation preferences' is now used instead of 'presentation preferences' to make the distinction from rendering preferences and application customization clearer.
The 'Glossary' Appendix has been removed and replaced by references to a separate Glossary document.
The 'Implementation scenarios' Appendix has also been removed pending a future, more comprehensive, survey of authoring techniques.
Some changes have also been made in response to the issues raised on the last Working Draft.
The following membersMembers of the W3C Device Independence Working Group have helped develop this Working DraftWorking Group Note through their comments, proposals and discussions at teleconferences, face-to-face meetings and via the group discussion list.
At the time of publication, the principal and active members of the group were as follows:
The following were members of the group at earlier stages of its drafting: