Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies best practices for Web content when accessed from mobile devices.
It is directed at all participants in the mobile value chain.
The primary goal is to improve the user experience of the Web when accessed from mobile devices.
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 W3C technical reports index at http://www.w3.org/TR/.
This document describes the best practices for content to work well on mobile devices. A companion scope document [Scope] describes the scope of this work.
This is the first Public Working Draft for review by interested parties. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This draft does not represent the consensus of the MWBP Working Group. It is known to be missing requirements, and is likely to contain errors.
This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. There are several specific issues on which the group solicits public feedback and comment. They are called out in the text like this note. We encourage feedback on all aspects of the document but particularly request feedback on these points. Please send comments on this document to the working group's public email list public-bpwg@w3.org, a publicly archived mailing list..
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Purpose of the Document
1.2 Audience
1.2.1 Players in the Mobile Value Chain
1.3 Scope
1.3.1 Phasing
1.3.2 Usability
1.3.3 Boundaries of the Best Practice Guidelines
1.4 Baseline Client
1.5 Compliance
1.6 Relationship to other best practices and recommendations
2 How the Best Practices are Organized
3 Requirements
3.1 User Experience
3.2
Input
3.3
Bandwidth and Cost
3.4 Content Type
3.5 Advertising
3.6 Device Limitations
3.7 Advantages
4 Delivery Model Architecture
4.1 Adaptation Implementation Model
4.2 Assumptions about Adaptation
5 Best Practices
5.1 Overview
5.1.1 Sources
5.1.2 How this section is organized
5.1.3 Structure of Best Practice Statements
5.2 Overall Behavior
5.2.1 Establish the Context of the Device
5.2.2 Exploit Client Capabilities
5.2.3 Work around deficient implementations
5.2.4 Error Messages
5.2.5 User Preferences
5.2.6 Testing
5.2.7 [Other general things]
5.3 Navigation and Links
5.3.1 URLs of Site Entry Points
5.3.2 Provide a Site Map
5.3.3 Balanced Structure
5.3.4 Thematic Consistency of Resource Identified by a URI
5.3.5 Navigation Mechanisms
5.3.6 Access Keys
5.3.7 Link Target Identification
5.3.8 Image Maps
5.3.9 Refreshing, Redirection and Spawned Windows
5.4 Page Layout and Content
5.4.1 Page Content
5.4.2 Consistency
5.4.3 Page Size
5.4.4 Scrolling
5.4.5 Navigation Bars etc. [Extraneous material]
5.4.6 Graphics
5.4.7 Color
5.4.8 Background Images
5.5 Page Definition
5.5.1 Title
5.5.2 Frames
5.5.3 Structural Elements
5.5.4 Tables
5.5.5 Non Text Items
5.5.6 Valid Markup
5.5.7 Measures
5.5.8 Semantic Markup
5.5.9 Style Sheets
5.5.10 Minimize
5.5.11 Content Types
5.5.12 Character Set
5.6 User Input
5.6.1 Input
5.6.2 Tab Order
5.6.3 Labels
5.6.4 Language Identification
5.6.5 Context Menus
6 Techniques
7 Conformance and mobileOK
A Glossary (Non-Normative)
B Acknowledgements (Non-Normative)
C References (Non-Normative)
The document contains a list of best practices and discussion around the assertions made for content on the Web so that it is delivered effectively to mobile devices. It also contains information about how to implement sites that conform to those best practices.
The document is intended to provide guidance to players in the mobile value chain as to best practices for production of web sites and of Web content intended for delivery to mobile devices.
It is also intended as the basis for assessing conformance to the requirements of the MobileOK trustmark. The idea for the MobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter
We do not develop the idea of mobileOK in this revision of this document. Future revisions may contain a discussion of mobileOK.
As mentioned above the document is targeted at players in the mobile value chain, as described below.
Readers of this document are expected to be familiar with creation of Web sites, and have a general familiarity with the technologies involved, such as web servers and http. Readers are not expected to have a background in mobile-specific technologies.
The document is not targeted solely at developers and others such as interaction and graphic designers are encouraged to read it.
The group solicits public feedback as to the usability of the document by Web professionals that are not technology specialists.
Players in the mobile value chain include:
Original content developers together with portal operators and other aggregators of content who deliver non-original content to mobile and other users.
Who may transform content when it passes from the Internet to their networks, and who may in addition operate portals.
Who realize content for users to perceive.
Developers of tools to assist with content production (authoring).
Developers of tools to assist with content serving and repurposing.
Those involved in the production and execution of testing processes.
The scope of these Best Practices is laid out in [Scope]. In summary this document refers primarily to browsing and extension of the Web browsing experience to be more usable on mobile devices.
The charter of the group is to specify best practices for delivery to mobile devices. Hence best practice statements that do not specifically have a mobile aspect are not included. In particular many Web Content Accessibility [WCAG] guidelines are general to all forms of Web access and are not repeated here unless they have a specific mobile interpretation.
As discussed in [Scope] the are many aspects to Mobile Web Best Practices.
One of those aspects is that, at present, the design and construction of many Web sites and pages make for a poor user experience when those sites and pages are viewed on a mobile device.
While improving those Web sites is only one aspect of improving the user experience, significant improvements can be achieved in this way, hence the first phase of work is concerned with providing guidelines for Web-site and content developers.
In future phases other aspects may be considered - e.g. best practices as applied to adaptation and devices. Also in future phases the scope of the recommendations may be extended beyond 'Traditional Web Browsing' into fields such as voice browsing.
There are three aspects of mobile usability - namely site, device, and browser usability. All three together contribute to the user experience.
We define these three aspects as follows:
Site usability relates to the structure, content and layout rules of a site and is a measure of the effectiveness of the mobile web site.
Device usability pertains to the capability of the equipment being used easily and effectively. "Easily" refers to a specified level of acceptability and comfort of use; "Efficiency" relates to the resources expended in relation to the accuracy and completeness with which users achieve their goals. In particular, device usability focuses on keypad design, display, fast browser access and UI styles.
Browser usability defines the ease of using a browser effectively namely performing the three functions reading, navigating or interacting. The ease of interaction, page rendering, caching etc. are issues that are frequently used to judge browser usability.
While recognizing the contribution of device and browser usability to the overall user experience, this document focuses on site usability.
This section describes what the Best Practices are trying to achieve, and what they are not.
The MWI in this phase [See Phasing] is concerned with establishing a set of guidelines that help content providers achieve the best possible experience of their Web content - given the client and network limitations that are encountered in the mobile delivery of Web content [see Requirements for a discussion of these]. A reasonable experience of the Web cannot be achieved on clients that exhibit too many of the limitations discussed or where one or other of the limitations is very severe.
In saying this it is recognized that any judgment of what is a reasonable experience is made at a particular point in time and from particular cultural perspective. It is also recognized that it is possible to achieve a reasonable experience of non-Web services in the presence of such limitations and that that there are at present many such services, often implemented using WAP 1.x technologies. The intention, however, of the Mobile Web Initiative, is to extend the reach of the Web to mobile devices. Hence such non Web services are out of scope of this discussion.
To be clear about the level of functionality (or absence of limitation) that is targeted for a reasonable mobile experience of the Web we define the notion of a baseline client.
By establishing a baseline definition, is it possible to provide guidance as to what an implementation should do if it cannot determine whether a client accessing the service supports features that meet or exceed the baseline definition. In short, it should assume the client provides baseline support.
As such the notion of a baseline client should be seen as guidance on the limitations of pages that are delivered by an implementation, rather than the specification of a device.
It is not the intention to encourage Least Common Denominator Implementations.
The best practice recommendations actively encourage the best possible support of the baseline client as well as exploitation of features that go beyond the baseline so far as those features refer to the Phase 1 scope (Web Browsing).
While it is out of scope of the best practices to consider non-mobile delivery, it must be understood that there is no clear dividing line or categorization that makes mobile and non mobile clients distinct. Rather, as mentioned above, that non-mobile clients tend to suffer fewer of the limitations that are characteristic of mobile ones. Any particular client can be considered to be in a scale between suffering all the limitations discussed and suffering none of them. In addition, for any particular client, the limitations may not apply equally at different times.
Similarly to the [WCAG] the best practice recommendations are couched at a level of generality that allows them to be applied to a wide range of markup languages. The intention being that as well as being applicable to current Web standards (especially XHTML), they are also applicable to existing and legacy non-Web recommendations, such as cHTML and WML, as well as future standards, such as [CDFWG].
It is recognized that many devices in daily use do not qualify as baseline clients. While the best practices do not target such clients, they do not discourage implementations from supporting them.
Baseline conformant devices have been available for some years, and are in common use in many markets. The recommendations encourage the use of features that go beyond the baseline, that have been and will continue to be introduced in new devices. However, since the MWI Phase 1 refers only to 'traditional' browsing it does not establish best practices for those features.
As time moves on it is likely that both the definition of a baseline device and the best practice recommendations will change. It is anticipated that the best practice recommendations will change at a slower pace than the definition of the baseline device.
As mentioned above, the definition of a baseline device is with reference to a notion of a reasonable Web experience. Any future change in the baseline device specification will need to take into account both the ongoing development of the non-Mobile Web experience and the availability of devices that exceed the current baseline. It is understood that the capabilities of devices differs markedly in different regions of the world, with more developed economies having access to a wider range of more fully featured clients.
The notion of a baseline client is an abstract notion. No specific real device is targeted. Rather, it is an abstraction of the characteristics of a range of currently popular devices that have been available for some years.
The abstraction assumes complete and defect free implementation of the features described. It is considered good practice to work around implementation defects of real devices. However, it is not in scope of best practices to itemize known defects and limitations nor to detail techniques or examples of how to do this. See [] for references as to known device and client limitations.
The recommendations refer to the behavior of implementations in providing a service, and in this phase do not refer to the behavior of clients. It is hoped that by providing a baseline definition creators of devices and clients will be encouraged to produce devices that meet or exceed the baseline definition. It is also hoped that those commissioning or setting standards for such devices will require implementation of baseline features to a reasonable standard of completeness and quality.
The group requests public comment on the specification of the baseline device given the comments in the previous section, that the purpose of the baseline specification is to inform what implementations can assume to be the minimum level of support that they must take account of, and what assumptions they may make in the absence of any other information.
In addition to discussing the baseline client the group has also discussed the idea of a default client. The idea being that for any particular application or geographic region, it may be known that the majority of devices are of a particular type or support particular features. In this case the notion of the 'global' baseline device is supplemented by a 'local' default device, which may have either greater or lesser functionality when compared with the baseline.
The group would value feedback both on which parameters are to be specified and what the values for those parameters should be.
The following are for illustration only.
For the purposes of delivering The Web, this is assumed to be a version of XHTML - probably aligned with XHTML-MP. Some opinion states that WML should be assumed. http delivery is assumed.
There is a further variation in views as to what image format a web site should assume a client supports. It may be that it should be assumed that there is no compatible image support.
People have strong, but divergent opinions on this. The absolute minimum being 96 x 96 pixels. Strong support is expressed for 128 x 128, however a vocal group supports bigger still.
Some opinions support the notion that a minimum row and column availability for text presentation needs to be specified.
Varying opinions again on this.
It is important to understand the limitations of memory so that Web sites do not try to deliver pages that are too big. However it is not clear how this should take into account the combined weight of markup and images. Suggestions vary from 10k bytes upwards.
Many other candidate parameters have been suggested, including cpu power, Back / Forward navigation in history, text entry (which character sets?), form controls, SSL 1/2, Javascript ...
The document does not have a compliance model. The Best Practice Recommendations represent suggestions as to the behavior of Web sites. Any use of the words must
, should
and may
should not be interpreted as having the meanings defined in RFC2119.
The Best Practice statements are intended to be capable of later having conformance statements constructed around them, in support of the mobileOK trustmark and for other purposes.
These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG]. As noted above, WCAG guidelines are supplementary to the Mobile Best Practices, whose scope is limited to matters that have a specific mobile relevance.
The work of the Device Independence Working Group [DIWG] has a direct and fundamental relevance to this document.
The document is organized as follows:
Describes the audience, purpose and scope of the document.
This section, explains the format of the document.
An illustration of the type of problems that the Best Practices are intended to ameliorate.
Discusses the environment within which the mobile web is realized, with particular reference to adaptation.
The statements themselves
How to implement the best practices [not present in this draft].
Testing for conformance to and labeling with the trust mark [not present in this draft].
Glossary [not present in this draft]
Acknowledgements
References
This section discusses the requirements of the Mobile Web Best Practice statements in section 5. The statement of requirements is intended to be illustrative rather than exhaustive or complete.
We discuss the requirements under two broad headings, User Experience and Device Limitations; both contribute to a poor experience of the Web on mobile devices.
Many Web pages today are laid out with presentation on desktop size displays in mind, and make use of the facilities provided by desktop browsing software.
Accessing such a Web page on a mobile device often results in a poor, or unusable experience. Contributing to this poor experience is that the content does not lay out as intended, and because of the limited screen size and the limited amount of material on the page that is visible to the user, things that are intended to be viewed together are not presented together - context and overview are lost.
Because of the limited screen size the subject matter of the page may require considerable scrolling to be visible, especially if the top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether their retrieval has resulted in the right content.
It is particularly important in the mobile context to help the user create a mental image of the site. This can be assisted by adopting a consistent style and contrariwise can be considerably diminished by an uneven style.
Mobile device input is often hard when compared with use of a desktop device equipped with a keyboard. Mobile devices such as phones often have only a very limited keypad, with small keys, and there is frequently no pointing device.
It's perhaps a paradox of the mobile web that URLs are very hard to type, and lengthy URLs and those that contain a lot of punctuation are particularly hard to type correctly. Bookmarking, while often supported, sometimes does not achieve the expected result.
Because of the limitations of screen and of input, forms are hard to fill in, both because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields.
There is frequently no back button, which means that it is often very hard to recover from errors, broken links and so on.
Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency, leading to long retrieval times, especially for lengthy content, and for content that requires a lot of navigation between pages.
Mobile data transfer often costs money. The fact that mobile devices frequently support only limited types of content means that a user may follow a link and retrieve information that is unusable on their device.
Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory - for example larger images may only be viewable in small pieces and require considerable scrolling.
Requests for web pages can result in the delivery of content that the user has not specifically requested - especially advertising and large site images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.
Mobile users typically have different interests to users of fixed or desktop devices. Mobile users are likely to have more immediate and goal-directed intentions than desktop web users. Their intentions are often to find out specific pieces of information that are relevant to their context. Examples frequently include travel related applications, where the user requires specific information about train times.
Other examples often include time filling applications, where people are filling otherwise dead time while traveling, and entertainment related applications are often noted as being appropriate.
On the other hand, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available.
Developers of commercial web sites should note that different commercial models are often at work when the Web is access from Mobile devices as compared with fixed line access, see [some reference TBD], for information. For example, some mechanisms that are commonly used for presentation of advertising material do not work well on small devices and are therefore contrary to the Best Practice Recommendations.
It's not the intention of the MWI to limit or to restrict advertising, rather it is the intention that the user experience of the site as a whole, including advertising, if any, is as effective as possible.
As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than that used for desktop devices. As detailed in [Scope], various other limitations may apply to mobile devices, and these have an impact on the usability of the Web from a mobile device.
Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no option as to which browser they should use, and in many cases upgrade of the browser is not possible. This creates the situation that in order to support users of a popular device, the limitations or implementation defects associated with particular releases need to be taken into account in some situations.
Some activities associated with rendering web pages are computationally intensive. There is typically quite limited processing power available to carry out such computations, which may mean they take a noticeable time to complete. Such computations also use more power and diminish battery life. In any case, data communication reduces battery life and reducing communication can conserve battery.
Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.
The widely varying characteristics of mobile devices can make it difficult for a Web site to provide an acceptable user experience across a significant range of clients. For example different clients support different markup features, and the different screen sizes may demand different sized images.
Consequently, it is very common when delivering content to mobile clients to vary the details of the markup, format of images, image sizes, color depths and so on, to suit the characteristics of the client in question. The process of altering content in this way to enhance the user experience on particular devices is referred to as content adaptation.
The remainder of this section outlines content adaptation in order to provide a background to this document. It is not intended as a comprehensive guide or to be definitive. The Device Independence Working Group [DIWG] has published a great deal of material relevant to this subject. Readers are expecially referred to "Delivery Context Overview for Device Independence" [DCODI].
In addition, the sister group of the Best Practices Working group - the Device Descriptions Working Group, is currently defining requirements for a repository of mobile client characteristics that are relevant to content adaptation.
There is quite a wide spectrum of implementation models for content adaptation. On the one hand it may be quite simple, and consist of determining the device type and choosing the most appropriate set of previously prepared content to match the device characteristics. At the other extreme it may be carried out in a completely dynamic way, with content formatted at the time of retrieval, taking into account not only statically determined properties, such as screen dimension, but also dynamically determined properties, such as the temporary attachment of a fully featured keyboard.
Adaptation can be carried out in a number of different points in the delivery of content to the client [see DIWG work and Device Description Landscape paper for more detailed discussion].
Server Side adaptation implies that the content is delivered by the originating content server or application.
In Network adaptation is where the content is altered as it passes through one or more network components. Some network operators, for example, compress images before they are passed over the air to the mobile client.
Client Side adaptation consists of the client accepting content that was originally purposed for another device and displaying it with appropriate reformatting.
In phase 1 we assume that content adaptation, if any, is carried out Server Side. Future phases may consider the implication of other content adaptation, especially the issues around granting authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address the issues around the possibility of multiple adaptations - i.e. the possibility that adaptation can be applied in more than one place, and that in network adaptation may occur more than once.
We also assume that it is possible to create a site that is consistent with the best practice recommendations, without carrying out adaptation at all. However, it is likely that a more sophisticated and enhanced user experience will be achieved if adaptation is used.
Clearly in order to determine the appropriate adaptation for any particular access, it is necessary to determine the device that is accessing the service. Sometimes it is not possible to determine the device type, either because the device does not present this information to the server at all, or in sufficient detail, or because the server does not provide the ability to inspect and act on the information provided.
In these cases the content author is expected to assume baseline or default device characteristics, as discussed in the Introduction to this document.
The group seeks public feedback on the desirability of stating that, in practice, adaptation is required for delivery to mobile devices; and that consequently, in view of the desirability of making content widely accessible across a broad range of devices, all Web development requires adaptation.
The best practice statements have been assembled by the BPWG from a number of sources. Primary among those are:
Various BPWG group meetings and discussions.
WCAG Guidelines 1.0 [WCAG]
iMode Guidelines [iMode]
Opera's "Making Small Device Look Great" [Opera]
Openwave Guidelines [OpenWave]
Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP]
Browsing on Mobile Phones, Nokia[Nokia-VR]
Little Spring Design
The best practice statements are organized under the headings of:
General Best Practice Statements
This section contains statements that relate to navigation and linking mechanisms
The section contains statements that relate to the content of pages and how they lay out
Statements that relate to the technical construction of pages
Statements that relate to Input
The functional area that is addressed by the statements.
One or more best practice statements, identified in the following way:
This is a best practice statement
Explanation of the significance of the statements under this heading
Discussion of techniques, usually a reference to the relevant section of this document [not much filled in in this revision]
Discussion of similar and related points and supporting references especially those from the list above.[usually missing in this version, a shorthand reference being provided directly against the statement(s) itself/themselves]
Outline discussion of how amenable this is to automated testing. [almost totally missing in this revision]
There are some general principles that underlie delivery to mobile devices.
In this section we refer to 'Implementations' by which we mean Web Servers, Adaptation Devices and other components in the delivery chain (as discussed above under 'Delivery Model Architecture').
Implementations should take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource.
Many of the best practice statements rely on the implementation knowing a significant amount about the physical characteristics of the device, the properties of the browser in use and the transparency or otherwise of the communication path between the device and the implementation. For simple sites which present an interface which is similar across a broad range of clients the need for such information is diminished when compared with a sophisticated site which has an optimized navigation structure, presents different size images or carries out other adaptations to suit the client.
If a particular client is not recognized or its capabilities cannot be determined a reasonable default experience should be provided. In this case a warning should be provided and the implementation should provide the ability for the user to select the device type in use. Where possible the user's selection of a device type should persist across visits to the implementation, but should be changeable.
The warning provided while making it clear that the experience may not be optimal for the user, should be minimally intrusive to the experience of the information and as far as possible should be consistent with other recommendations.
Implementations should exploit the capabilities they find and not adopt a least common denominator approach.
It is not the intention that encouraging implementations to be sensitive to the needs of baseline devices should result in a diminished experience on more capable devices. Specifically it is not the intention the encourage the development of sites that have a uniform baseline targeted presentation when a better user experience could be attained on more capable devices.
Implementations should recognize that there are a significant number of clients that do not support standards completely or correctly and should take reasonable steps to work around such deficiencies.
Just as in the desktop browser world, there are differences in interpretation between browsers and there are also deficiencies in implementation. Because the software in mobile devices is frequently embedded in the device there is no easy way to correct or enhance software once it is in the field. It's a particular challenge to provide work-arounds for these deficiencies and differences in interpretation.
Just as it is not the intention to recommend a least common denominator approach, it's not the intention to recommend non-use of features which exhibit problems on some class of devices.
It's also not the intention to suggest that implementations should restrict their support to certain client types. Implementations should aim to support as wide a range of client types as is practical.
Provide informative error messages, and a means of navigating away from an error message back to useful information.
It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought.
So far as determination of the error is within control of the implementation, the user should be provided with clear information regarding the fault they have experienced. This should help them to understand whether the fault was temporary or permanent, whether they should re-attempt to access the content, and how they may be able to escalate the problem.
It should also be possible for the user to escape from the error condition. They should either be able to return back to the page they were on previous to the error, or to be able to move onwards to a convenient part of the service from where they can retry or alter the transaction they were attempting.
Where possible, applications should trap all error conditions that could occur and handle them in a user-friendly, and graceful, way.
Error messages should be provided in the same language as the application that was being used. They should be clear and concise, adhering to the same best practices as the rest of the application.
The error message should detail whether the issue is likely to be temporary or permanent, whether the user may be able to solve the issue themselves (for example, by changing input data, or a handset setting), or whether it is an issue that can be escalated to the content provider or network operator. In the latter case, contact details, such as an SMS address or a support line number, might be appropriate and concise.
Navigationally, the error message should provide one or more of:
A 'back' link to return to the previous page (particularly for handsets that do not provide a native back button)
A 'retry' link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page 'refresh')
A 'home' link to allow the user to proceed back to the main part of the application
The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. Whilst some users may understand '404' to mean 'page cannot be found', this must not be assumed to be true for all users.
Where possible capture and apply user preferences.
In view of the difficulties relating to user input and the limitations of the screen that are usually associated with mobile devices, capturing user preferences and applying them can significantly aid usability.
User preferences related to user experience choices, may be managed by the user agent responsible for rendering some Web content. User preferences related to application personalization could also be transmitted as part of the delivery context. The W3C DIWG has been active formulating a draft recommendation for delivery context.
See [Techniques] for a detailed discussion of use of CC/PP and UAProf to support user preferences.
Carry out testing on actual devices as well as emulators.
Any web site should be tested in a range of browsers. Mobile browsers often show markedly different characteristics to desktop browsers. As well as assessing a site's suitability for display in reduced format, authors are encouraged to test that the features they rely on work in actual devices.
Many manufacturers provide emulators for their device that can provide a convenient preliminary means of testing. However, in practice, many of the emulators behave in a different way to the devices they emulate. Consequently testing should be carried out in as wide a range of real devices as is practical.
Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile clients, care should be exercised in defining the structure of a site and the navigation model for the site.
Keep the URLs of site entry points short
Provide information about the general layout of a site (e.g., a site map or table of contents)
Use a small graphic at the top of the page to illustrate what site the user is on and where on the site they are at
A site map should be a collection of links that provides full access to the main sections of the website or that offers some other selection of links which are useful for site navigation.
The service should be designed with a broadly balanced navigation tree where numbers of links on pages is balanced against depth of navigation.
The design should aim to balance between providing an excessive number of navigation links on a page and the need to navigate multiple links to reach content. Each retrieval of a navigation page takes time, and adds cost, so the number of links on a page should not be minimized at the expense of adding page retrievals.
Links must provide a thematically coherent experience when accessed from a device other than the one on which they were captured.
The representation of a URI (the page that is delivered when a device accesses a URI) may not look the same or contain identical content when accessed from different devices, because in the interests of usable site navigation the pagination may be different for different devices and in the in order to use capabilities of different devices appropriately it may look different.
However, an important principle of One Web [link] is that a URI should be usable on any device. So if a user of one device sends a bookmark, or link, to another user that does not have the same device, their intention in sending that URI must be respected and the second user should be presented with information that the first user had intended to communicate.
Use navigation mechanisms in a consistent manner
Group related links, identify the group and provide a way to bypass the group
Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.
Since mobile users without pointing devices must execute several clicks between navigational jumps it is prudent to minimize this movement across the content.
Intelligent grouping, perhaps optimized through adaptation according to usage patterns can assist usability.
A "drill-down" method, based on major headings, can often provide an effective means of navigation. And because of the linearized arrangement of content, small screen size and lack of pointing device, it is often useful to provide a means to jump entire sections of content.
At each target of the drill down navigation an "up" link should be provided to allow the user to jump up an entire section.
See [Techniques] for further discussion of site navigation mechansims.
Assign access keys to Links, Form Controls and Groups of Form Controls
Assigning an access key (keyboard short cut) to a link provides a way for users to avoid having to navigate to the link by repeated pressing of the navigation key, where there is no pointing device.
There is no standard way of displaying the assignment of an access key to a link. The access key section of [Techniques] discusses a number of techniques for implementing Access Keys, including keeping functionality consistent across browsers.
This relates to WCAG 9.5
See http://www.alistapart.com/articles/accesskeys/ for a discussion of access keys.
Clearly identify the target of each link in a way that allows users to decide in advance whether to follow it, including the 'cost' of following it
Clearly identify links to content that the device may not be able to interpret
Users of mobile devices may suffer undue delay and cost as a result of following links. It's important to identify where a link leads so users can make an assessment of whether following it will be of interest to them. While implementations are unlikely to be able to specify the cost in monetary terms of a particular user following a particular link, it should be possible to give an idea of the size of the resource [in bytes or in an abstract way e.g. large file].
Links to content that is in a different format to the format of the page the link is on (i.e. content that can only be interpreted by other applications, downloads) should be human signposted, so that users are not lead to download content that their device may not be able to use.
Do not use image maps unless you know the target client supports them and has sufficient screen real estate and an appropriate means of selection, such as a stylus or navigation keys. When using image maps under these circumstances, use client side image maps unless the regions required cannot be described with an available geometric shape
Do not use a server side image map unless you know that the client provides a means of selection within the image map
Image maps allow fast navigation providing the requesting device can support the image involved and providing there is a means of navigating the map satisfactorily. Up, down, left, right, enter are available on most mobile devices, even if no pointing device is present, and this is usually sufficient to allow navigation of the active regions of client side image maps.
Do not cause pop-ups or other windows to appear and do not change the current window without informing the user
Do not create periodically auto-refreshing pages
Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of http 3xx codes
Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction. Many mobile devices cannot support more than one window and consequently attempting to open one will have unpredictable results. In general, the users consent should be sought before initiating the download of content.
While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser which adds to delay on slow links. Hence redirection should not be used as a matter of course.
Content should be suitable for use in a mobile context
Use the clearest and simplest language appropriate for a site's content
Content should be limited to what the user has requested
Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information, and while providing the option to access all information, should offer appropriate information first.
The general prescription to use clear language is of particular importance in the mobile context where brevity and directness are generally more desirable than a discursive style.
Writing content in the traditional journalistic 'front loaded' style can assist users determining whether information is of interest to them and allow them to skip it more easily if it is not. [It also assists with some summarization and truncation techniques]. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area.
In many cases the user pays for bandwidth in the mobile context, and offering the user content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience.
Create a style of presentation that is consistent across pages
Pages should be divided into usable but limited size portions
The overall size of page should be appropriate to bandwidth, the memory limitations of the device and other device and delivery channel characteristics if they can be determined
If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions as to the largest page they can accommodate.
On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. Since, in the mobile environment, each request typically takes a measurable time to complete, this can lead to an unnecessary delay.
The balance between pagination and scrolling is partly a matter of taste and partly a matter of necessity. Devices with severe memory restrictions can only have small pages delivered to them. Equally some devices offer a poor scrolling experience, and a better page retrieval experience.
Where possible, scrolling should be in one direction
Where an object cannot be presented without secondary scrolling it must not cause the rest of the page to require scrolling
The page should lay out so that simple repeated scrolling allows the user to experience all its content, however some content (such as maps and other images) cannot be displayed without two way scrolling.
If some element on the page requires two way scrolling it must not cause the remainder of the page to require this. For example, if an object causes subsequent text to lay out with a significant margin to its left, then this text may not be visible once a user has scrolled past the object.
Equally, if the presence of such an object causes text to lay out beyond the right boundary of the page then the user will be required to scroll to read each line of text.
Material that is not central to the meaning of the page should not precede material that is.
Many Web pages are designed with significant navigational and other elements at the top of, or to the side of the page (e.g. Menu Bars, Breadcrumb Trails, Search Functions). This provides a convenient and well-understood navigational metaphor on large displays. However, on small displays this can result in the navigation appearing instead of the actual content of the page when the page is first retrieved.
Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page.The user should not have to scroll significantly to find the primary content of the the page.
Don't use graphics for layout
Don't use large graphics
The popular mechanism of using a 1 pixel large graphic for absolute positioning is not suited for display on a variety of screens and must therefore not be used.
Graphics which are larger than the must be, for example by possessing a higher resolution than is displayable on the device or by having too many colors waste bandwidth.
Ensure that information conveyed with color is also available without color
Ensure that foreground and background color combinations provide sufficient contrast
Keep the number of colors to a minimum
Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence relying on color highlighting of information may not be visible to users. If color is used to indicate a feature it is a good idea to indicate that feature in a non color dependent way. In particular, don't use blue or purple text, as this may be confused with hyper-links, especially on device that do not underline links.
Do not use background images unless you know the device supports them
When using background images make sure that content remains readable on your target devices
Images which are used indiscriminately can lead to content that is hard to view, particularly with the limited contrast and hostile viewing conditions that mobile founds are frequently use in.
Before using background images, consider carefully your objectives for doing so and try to use alternative techniques to achieve similar objectives.
Provide a short but descriptive page title.
Provide a descriptive title for your page to allow easy identification. Keep the title as short as is possible to reduce page weight and bearing in mind that it may be truncated
Many mobile browsers do not display the title of a page, and where the title is displayed the available space may be limited.
The client may use the page title as the default label for bookmarks. Again space may be limited so use it to help identify the content and not for other purposes.
Do not use frames.
Many mobile clients do not support Frames. In addition, frames are recognized as being generally problematic.
See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.
Use header elements to convey document structure and use them according to specification
Mark up lists and list items properly
Mark up quotations
It is good practice for all but the simplest documents to indicate their structure through headings and sub-headings. Using structural markup, rather than formatting effects, allows easier adaptation of content where it needs to be divided into several pages as well as potentially facilitating access only to the sections of the document that a user is interested in.
Where headers are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.
Structural markup must not be used solely to create a font effect.
Do not use tables unless the client is known to support them
Do not use tables for layout
Where possible, use an alternative to tabular presentation
Where tables are used:
provide a summary
identify row and column headers
provide abbreviations for header labels
do not use multi-layer tables
Tables do not work well on limited size screens and may result in the user having to scroll horizontally to read them. Putting navigational links into tables may result in the user having both to scroll horizontally to see possible navigational choices.
Provide textual alternatives for non-text elements
Do not embed objects or script in pages unless you know the device supports them
When an appropriate markup language exists use markup rather than images to convey information if the device supports it.
Always specify the size of images in markup
When resizing images do so at the server
Downloading images to a mobile client requires the browser to fetch images and to download them, which adds to the time to display an image and the cost of displaying the page. Making the page readable in text only mode can help the user assess its usefulness before images arrive.
Many mobile clients do not support embedded objects or script and in many cases it is not possible for users to down load plug-ins to add support. Content must be designed with this in mind.
Resizing images at the server and specifying their size in mark up assists the browser to flow the text, reduces amount of data transferred and the amount of processing the client has to carry out to scale the image.
Design pages as though they were to be displayed on a text-only browser.
Always use features of the markup designed to support alternate rendering such as the longdesc
and alt
attributes in XHTML
Use only features from the markup that are known to be supported by the device in question.
Avoid things like CSS image replacement and actual pictures of words.
Create documents that validate to published formal grammars.
If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.
In general, use relative rather than absolute units in markup language attribute values and style sheet property values
Do not specify an absolute page width
Reduce the number of different font sizes
Avoiding absolute measures allows the browser to adapt content to fit the display. An exception to this being where an image has been specifically sized for a display, references to the image in markup may specify the exact dimensions of the image in order to help the browser to flow the page, and avoid re-flowing it after the page has been retrieved.
Semantic Markup (tbd) should be included to indicate the purpose of content
Provide information about document collections (i.e. documents comprising multiple pages)
If the client supports style sheets, use this mechanism to control layout and presentation
Organize documents so that they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets it must still be possible to read the document
Keep style sheets as small as possible.
Clients provide several levels of support for style sheets. Some provide full implementations including caching of external style sheets. Some do not cache external style sheets, and for these devices embedding the style information in the delivered page is more efficient than the browser making repeated retrievals for the style sheet across a site. Some implementations do not support style sheets at all.
Use terse efficient markup
Content which is marked up up in languages such as XML can often be made smaller while preserving the exact same semantics, merely by removal of redundant white space (i.e. spaces and new lines).
Marking fonts, colors and other stylistic effects in line, can cause considerably larger page sizes when compared with using logical markup, and use of the HTML class
attribute for application of style.
Use of markup formatting programs which aim to make content more readable by humans, contributes considerably to page weight and should not be used to format content for delivery to mobile devices; instead strip all possible redundant white space.
Use of structural markup contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS.
Send content in a format that is known to be supported by the device.
Where possible send content in a client's preferred format.
Transferring content that a client cannot display wastes users time and money. Preference may be expressed by a client for one format rather than another. In this case it is good practice to respect the client's preference - as it may have a fuller implementation of its preferred markup.
Web sites should use a combination of HTTP User-Agent and Accept headers, UAProf and other device profile information to determine what formats a device supports.
There are problems with using any one approach to the exclusion of the others. Some issues that have been noted by the BPWG in this context are:
Not all devices supply accept headers
Some devices state that they accept all formats */* when they do not support some common formats, and also mis-state their capabilities
Some operator gateways supplement the accept headers as they adapt content presented in formats that the device does not accept
User Agent headers do not always uniquely identify the device
UAProf information may not be available or may be incomplete
Further detailed discussion of heuristics for determining which formats a device supports is contained in [Techniques].
Ensure that content is encoded using a character set that is known to be supported by the target device.
Indicate in the response the character encoding being used.
As in the previous section, content should not be sent to a device if it can't use it.
The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header sent with a request. (see also the section above on determining device characteristics)
For XML content the character encoding may be specified in the encoding declaration [XMLENC]
Example: <?xml version="1.0" encoding="UTF-8"?>
The character encoding being used in a response may be indicated using the HTTP Content-Type header.
Example: Content-Type: text/html; charset=utf-8
This section contains statements relating to user input. User input is typically more or a lot more restrictive on Mobile devices, which may lack pointing devices and usually do not have a standard keyboard with which to enter text.
Keep the number of keystrokes to a minimum
Avoid free text entry where possible
Provide pre-selected default values where possible
Use selection lists where possible
Given the typical input limitations of a mobile device interface must as far as possible minimize user input.
Create a logical tab order through links, form controls and objects
Associate labels explicitly with their controls and until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels ensure the label is properly positioned
Clearly identify changes in the natural language of a document's text and any text equivalents.
The editors would like to thank the members of the Best Practices Working Group for their contributions to the document.
The editors apologize if anyone's name has accidentally been left off the list and invite people to remind us by mail so this can be corrected in future drafts.