This position paper proposes some guiding principles for creating device-independent web content. It looks beyond the current dominance of PC browsers and the flourishing WAP and iMode phones to a web through which content can be delivered in many ways. It takes into account the needs of both content providers and content consumers. The challenge is to apply these principles during the development of architectures, standards, guidelines and eventual implementations.
The web allows content providers, both formal and informal publishers, to deliver information and services to content consumers. The providers can benefit from making their content more easily available to a range of consumers, and the consumers can benefit from having simple access to a wide range of content.
When the web was primarily delivered via browsers on computers, publishers could author their content to take advantage of known browser capabilities. However, this has not always allowed for the content consumer to receive the information in the way they required. For example, text-only browsing has become almost impossible for many websites. Now web content is starting to be delivered via a wide range of devices, including phones, printers, TVs, and PDAs, each of which have different capabilities in terms of the types of content they can support.
The content provider does not wish to re-author their content for each kind of delivery device, or for each combination of user requirements. However, they do wish to retain existing consumers and reach out to new consumers, and must adapt their content strategy accordingly.
The content consumer wishes to access a wide range of content from whatever device they are currently using, and in the way they wish to use it. When there is competition, they will choose whichever content provider best satisfies their needs.
The following principles are proposed to provide a rationale for the development of standards, guidelines, recommendations and implementations for device-independent content delivery. They are more generic than the current W3C Web Content Accessibility Guidelines, which are aimed primarily at the designers of individual web pages to be delivered as HTML.
These principles are intended to guide the architects and designers of web content management and delivery systems. This reflects the assumption that there is still much to learn about structuring content to make it adaptable to multiple delivery requirements, and even more to be done in devising tools that support the creation and delivery of such content. In particular, it anticipates that content may be stored in more flexible ways (for example, based on XML) that simplify selection and adaptation for delivery to a wide range of devices.
Each principle is motivated by brief examples. Some consequences of adopting these principles are considered later. The list is not intended to be exhaustive.
The capabilities of the delivery device (including its input/output interfaces and its hardware/software functionality) limit the acceptable forms of content that can be delivered to it, and the interaction that can occur between the user and that content. This might seem obvious, but there are already many cases of websites that cannot be viewed properly if they are accessed from the 'wrong' kind of browser. It is up to the content provider to make sure what they deliver is suitable for the delivery device. It should not be assumed that each device, or delivery path to the device, can adapt the content. For example: a phone may not be able to display colour images; a PDA may only support a limited range of text fonts; both may have limited capabilities for adapting images to their small display.
Within the capabilities of the delivery device, a consumer may further constrain the delivered content, either to match their abilities and surroundings or for personal preference. For example: a blind user may use a web browser with a screen reader that only handles text-only output; an office worker may switch off all audio output; a driver may opt for voice-only interaction with a phone in a car.
Content references that are manipulated by the user such as links, bookmarks and printed website names should be valid across all devices. It may be that the content that is accessed is presented differently depending on the device, but the identification of the content should be device independent. For example: if a user sees a URI printed on an advert, it should work whether they enter it into a PC web browser or into a WAP-phone; or if a user wants to transfer a file of bookmarks between their PDA and their web browser, the appropriate version of the bookmarked items should be accessible from either. (See TV Broadcast URI Schemes Requirements for more examples).
If a user has encountered some content when using one device, they will expect to be able to access it (not necessarily with the same appearance) from another device. This means that it should not be necessary, though it may be more pleasant, to have the 'right' device to access some content. For example: if someone has seen the menu of a restaurant on a web page using a PC web browser at home, they will also expect to be able to find and access the menu from a phone when they are mobile (even though it may be awkward to display). Access to some content, such as paid-for TV, may be limited for commercial copyright reasons.
Consideration of the full consequences of adopting the principles outlined above is beyond the scope of this paper. However, just to illustrate the influence they could have, take some of the consequences for content providers.
It is not sufficient for a publisher to offer a single rich form of the content and assume adaptation will take place further down the delivery path. This may form a partial solution during transitional periods, such as the adaptation of HTML into WML content for phones in WAP gateways. But it cannot be assumed that limited delivery devices can perform adaptation themselves. In any case, many publishers will wish to maintain control over the quality of the received content by providing the appropriate format from their own servers.
Neither will it be sufficient for the publisher to offer parallel web sites tailored to different devices. Not only would the problems of multiple authoring explode with the growing number of devices, but the flexibility to adapt to consumer needs (such as voice-only or text-only delivery) and the ability to refer to the 'same' content across devices would be greatly hindered.
The consequence for the publisher is that they need to create their content in the first place in a rich enough form that it can be adapted for different kinds of delivery. For example, a piece of text may be represented not only in a fully-formatted version, but also in a paraphrased version suitable for small-format displays, or in a spoken version for audio-only delivery. The right version must be delivered depending on the capabilities of the delivery device and the preferences of the user. This will require more sophisticated tools for authoring, managing and delivering content.
Further discussion is urged of the merits of such general principles, of whether there are others principles that should be added to the list, and in particular of the consequences of their adoption.
It is hoped that the development of new W3C standards based on XML, such as XHTML, XSL, CC/PP and XForms, can provide the basis for flexible publishing and delivery systems for future devices.
But there is still much to do. For example, publishers must be helped, through standards and tools, to create adaptable content and sets of presentation styles suitable for different delivery requirements. This must take into account not only single site considerations, but also the increased syndication of content and dynamic interaction between commercial sites.
Web servers must support the selection of the appropriate content based not just on the URI, but on the way the content will be delivered. It is not part of the CC/PP proposals, for example, to consider how the appropriate version of some content can be selected based on the detailed low-level capabilities expressed in the profile data.
It is hoped that the workshop can help identify and agree on the issues that still need to be resolved in order to provide a sound basis for device-independent publishing solutions.