Mobile Web Best Practices 1.0

Basic Guidelines

W3C Recommendation 29 July 2008

This version:
Latest version:
Previous version:
Jo Rabin, mTLD Mobile Top Level Domain (dotMobi)
Charles McCathieNevile, Opera Software [Early Drafts]

Please refer to the errata for this document, which may include some normative corrections.

See also translations.


This document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to improve the user experience of the Web when accessed from such devices.

The recommendations refer to delivered content and not to the processes by which it is created, nor to the devices or user agents to which it is delivered.

It is primarily directed at creators, maintainers and operators of Web sites. Readers of this document are expected to be familiar with the creation of Web sites, and to 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.

Status of this Document

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 was developed by the Best Practices Working Group (BPWG) as part of the Mobile Web Initiative.

Please see the Working Group's implementation report. Changes since the previous version of the document are editorial. A complete list of changes made to this document is available. Note the document stayed in Proposed Recommendation for more than a year as it depended on the progress of XHTML Basic 1.1 on the Recommendation track.

Please send comments about this document to public-bpwg-comments@w3.org (with public archive).

This document combines the experience of many mobile Web stakeholders into one set of best practices, regarded as essential by the participants of the Working Group.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; 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) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
    1.1 Purpose of the Document
    1.2 How the Best Practices are Organized
    1.3 Audience
    1.4 Scope
        1.4.1 Phasing
    1.5 Relationship to other Best Practices and recommendations
    1.6 Longevity and Versioning
2 Requirements
    2.1 Presentation Issues
    2.2 Input
    2.3 Bandwidth and Cost
    2.4 User Goals
    2.5 Advertising
    2.6 Device Limitations
    2.7 Advantages
3 Delivery Context
    3.1 One Web
    3.2 Background to Adaptation
    3.3 Adaptation Implementation Model
    3.4 Assumptions about Adaptation
    3.5 Establishing Context
    3.6 Choice of User Experience
    3.7 Default Delivery Context
4 Structure of Best Practice Statements
5 Best Practice Statements
    5.1 Overall Behavior
        5.1.1 Thematic Consistency of Resource Identified by a URI
        5.1.2 Exploit Device Capabilities
        5.1.3 Work around Deficient Implementations
        5.1.4 Testing
    5.2 Navigation and Links
        5.2.1 URIs of Site Entry Points
        5.2.2 Navigation Bar
        5.2.3 Balanced Structure
        5.2.4 Navigation Mechanisms
        5.2.5 Access Keys
        5.2.6 Link Target Identification
        5.2.7 Image Maps
        5.2.8 Refreshing, Redirection and Spawned Windows
        5.2.9 Externally Linked Resources
    5.3 Page Layout and Content
        5.3.1 Page Content
        5.3.2 Page Size
        5.3.3 Scrolling
        5.3.4 Navigation Bars etc. (Extraneous material)
        5.3.5 Graphics
        5.3.6 Color
        5.3.7 Background Images
    5.4 Page Definition
        5.4.1 Title
        5.4.2 Frames
        5.4.3 Structural Elements
        5.4.4 Tables
        5.4.5 Non-Text Items
        5.4.6 Image Size
        5.4.7 Valid Markup
        5.4.8 Measures
        5.4.9 Style Sheets
        5.4.10 Minimize
        5.4.11 Content Types
        5.4.12 Character Encoding
        5.4.13 Error Messages
        5.4.14 Cookies
        5.4.15 Cache Headers
        5.4.16 Fonts
    5.5 User Input
        5.5.1 Input
        5.5.2 Tab Order
        5.5.3 Labels for Form Controls
6 Conformance and mobileOK
    6.1 Classes of Products
    6.2 Extensibility


A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
    D.1 MWI References
    D.2 Sources
    D.3 Device Independence
    D.4 Web, Protocols and Languages
    D.5 Other References

List of Best Practices

The following Best Practices are discussed in this document and listed here for convenience. There is also a free-standing summary.

  1. [THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.

  2. [CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.

  3. [DEFICIENCIES] Take reasonable steps to work around deficient implementations.

  4. [TESTING] Carry out testing on actual devices as well as emulators.

  5. [URIS] Keep the URIs of site entry points short.

  6. [NAVBAR] Provide only minimal navigation at the top of the page.

  7. [BALANCE] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.

  8. [NAVIGATION] Provide consistent navigation mechanisms.

  9. [ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.

  10. [LINK_TARGET_ID] Clearly identify the target of each link.

  11. [LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it.

  12. [IMAGE_MAPS] Do not use image maps unless you know the device supports them effectively.

  13. [POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

  14. [AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

  15. [REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.

  16. [EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum.

  17. [SUITABLE] Ensure that content is suitable for use in a mobile context.

  18. [CLARITY] Use clear and simple language.

  19. [LIMITED] Limit content to what the user has requested.

  20. [PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.

  21. [PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.

  22. [SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.

  23. [CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.

  24. [GRAPHICS_FOR_SPACING] Do not use graphics for spacing.

  25. [LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.

  26. [USE_OF_COLOR] Ensure that information conveyed with color is also available without color.

  27. [COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast.

  28. [BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device.

  29. [PAGE_TITLE] Provide a short but descriptive page title.

  30. [NO_FRAMES] Do not use frames.

  31. [STRUCTURE] Use features of the markup language to indicate logical document structure.

  32. [TABLES_SUPPORT] Do not use tables unless the device is known to support them.

  33. [TABLES_NESTED] Do not use nested tables.

  34. [TABLES_LAYOUT] Do not use tables for layout.

  35. [TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.

  36. [NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.

  37. [OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.

  38. [IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they have an intrinsic size.

  39. [IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size.

  40. [VALID_MARKUP] Create documents that validate to published formal grammars.

  41. [MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.

  42. [STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.

  43. [STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets.

  44. [STYLE_SHEETS_SIZE] Keep style sheets small.

  45. [MINIMIZE] Use terse, efficient markup.

  46. [CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.

  47. [CONTENT_FORMAT_PREFERRED] Where possible, send content in a preferred format.

  48. [CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.

  49. [CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used.

  50. [ERROR_MESSAGES] Provide informative error messages and a means of navigating away from an error message back to useful information.

  51. [COOKIES] Do not rely on cookies being available.

  52. [CACHING] Provide caching information in HTTP responses.

  53. [FONTS] Do not rely on support of font related styling.

  54. [MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.

  55. [AVOID_FREE_TEXT] Avoid free text entry where possible.

  56. [PROVIDE_DEFAULTS] Provide pre-selected default values where possible.

  57. [DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it.

  58. [TAB_ORDER] Create a logical order through links, form controls and objects.

  59. [CONTROL_LABELLING] Label all form controls appropriately and explicitly associate labels with form controls.

  60. [CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to.

1 Introduction

1.4 Scope

The scope of these Best Practices is laid out in "Scope of Mobile Web Best Practices" [Scope]. In summary, this document refers primarily to the extension of Web browsing onto mobile devices.

The Best Practice recommendations refer to delivered content. While they are clearly relevant to the processes of content creation and rendering on devices, they are not intended to be Best Practices for those activities.

As the goal of the document is to specify Best Practices for delivery to mobile devices, statements that do not have a specific 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. Examples of general good practice which have a specific mobile interpretation include "Error Messages" and "Color".

See B Related Reading for information about the related topics of Internationalization, Web Accessibility and Device Independence.

1.4.1 Phasing

As discussed in the Scope document [Scope] there are many aspects to Mobile Web Best Practices. At present, for example, the design and construction of many Web sites and pages make for a poor user experience when they are viewed on a mobile device.

The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability and device usability are important (for reading, navigating, and interacting with content), this document focuses primarily on Best Practices for improving site usability.

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 multimodal interaction.

1.5 Relationship to other Best Practices and recommendations

These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG]. As noted above, WCAG guidelines are supplementary to the Mobile Web Best Practices, whose scope is limited to matters that have a specific mobile relevance.

This document builds on some of the concepts described by the Device Independence Working Group (DIWG) in the Device Independence Principles [DIP]. The document discusses device and delivery channel characteristics, which the DIWG has named "Delivery Context" [DCODI]. In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS].

The BPWG is developing a companion document describing techniques [Techniques] by which the Best Practice statements in this document can be implemented.

1.6 Longevity and Versioning

The Best Practices have been written at a level of generality that allows them to be applicable across a range of markup languages. They have been written with enduring properties of mobile access to the Web in mind. While the factors identified in 3.7 Default Delivery Context, such as screen dimensions, will change over time, it seems likely that the distinguishing features of mobile access such as cost and difficulty of input will remain issues.

This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.

2 Requirements

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.

2.6 Device Limitations

As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than for desktop devices. As detailed in the Scope document [Scope], various other limitations may apply 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 choice of browser and upgrading it is not possible.

Some activities associated with rendering Web pages are computationally intensive - for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid markup [T-MOB]. Mobile devices typically have quite limited processing power which means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses more power as does communication with the server.

Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.

2.7 Advantages

In discussing the limitations of mobile devices for delivery of Web content it is easy to lose sight of the fact that they are extremely popular and very common.

This popularity largely stems at present from them being:

  • personal

  • personalizable

  • portable

  • connected

and increasingly multi-functional beyond their original purpose of voice communications.

In addition to these factors, the advantages of mobile devices will increasingly include:

  • location awareness

  • one-handed operation

  • always on

  • universal alerting device

By way of illustration of some of these factors: the Web can go where you go. You do not have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place.

Moreover, with mobile devices appearing in all shapes and forms, and with a growing variety of features like location technology, cameras, voice recognition, touch screens etc, the Web can reach a much wider audience, and at all times in all situations. It has the opportunity to reach into places where wires cannot go, to places previously unthinkable (e.g. providing medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time on their wristwatches.

Finally, today, many more people have access to mobile devices than access to a desktop computer. This is likely to be very significant in developing countries, where Web-capable mobile devices may play as similar a role in deploying wide-spread Web access as the mobile phone has played for providing "plain old telephone service".

3 Delivery Context

Delivery Context is used with the specific meaning defined in the Device Independence Glossary [DIGLOSS].

3.1 One Web

The recommendations in this document are intended to improve the experience of the Web on mobile devices. While the recommendations are not specifically addressed at the desktop browsing experience, it must be understood that they are made in the context of wishing to work towards "One Web".

As discussed in the Scope document [Scope], One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts (see 5.1.1 Thematic Consistency of Resource Identified by a URI).

Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (for instance for complex configuration tasks). Still others have a primarily desktop appeal but a complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications that have a primarily desktop appeal (lengthy reference material, rich images, for example).

It is likely that application designers and service providers will wish to provide the best possible experience in the context in which their service has the most appeal. However, while services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations.

From the perspective of this document this means that services should be available as some variant of HTML over HTTP (see 3.7 Default Delivery Context).

3.3 Adaptation Implementation Model

There are a number of different implementation models for content adaptation. On the one hand, adaptation 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 device [DCODI]:

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 device.

Client Side adaptation consists of the device accepting content and displaying it in an appropriate way for its characteristics.

Whatever the adaptation model at work, the process of adaptation should not diminish accessibility.

3.4 Assumptions about Adaptation

In phase 1 (See 1.4.1 Phasing) it is assumed that content adaptation, if any, is carried out Server Side. Future phases may consider the implications of content adaptation elsewhere, especially the issues concerning the granting of authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address multiple adaptation - i.e. the possibility that adaptation can be applied at more than one point and that In-Network adaptation may occur more than once.

It is also assumed 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.

3.6 Choice of User Experience

In the interests of "One Web" (see 3.1 One Web) considerations, the content provider may choose to allow the user to select from broad categories such as mobile or desktop presentation, where these are distinguished in the application. If the presentation option has been determined automatically, the content provider may choose to allow the user to override the automatic determination. Where a choice of presentations is available, it is good practice to record the user's preferences and to allow them to be changed.

Given an appropriate server environment, it is unlikely that the content provider will be unable to find out anything about the delivery context. However this can happen, either because details of the delivery context are not available in sufficient detail or because the server does not provide the ability to inspect and act on the information provided. In this case a "reasonable default experience" should be provided.

The details of the default experience depend upon a number of factors including, but not limited to, the geographic region in which the service is offered and the primary intention of the service (e.g. considering whether the service is primarily desktop focused vs. primarily mobile focused).

3.7 Default Delivery Context

In order to allow content providers to share a consistent view of a default mobile experience the BPWG has defined the Default Delivery Context. This allows providers to create appropriate experiences in the absence of adaptation and provides a baseline experience where adaptation is used. The Default Delivery Context has been determined by the BPWG as being the minimum delivery context specification necessary for a reasonable experience of the Web. It is recognized that devices that do not meet this specification can provide a reasonable experience of other non-Web services.

It is also recognized that this specification is made against the background of demographic, cultural and economic assumptions. Content providers may choose to provide services that demand a different or lower delivery context specification, but should try to provide an experience that exploits the capabilities of the Default Delivery Context in order to provide the best possible experience for that context.

It is stressed that many devices exceed the capabilities defined by the DDC. Content providers are encouraged not to diminish the user experience on those devices by developing only to the DDC specification, and are encouraged to adapt their content, where appropriate, to exploit the capabilities of the actual device.

In summary, the purpose of defining the DDC is to support the following rules:

  • If an adaptation process is used, then information that is known about the actual Delivery Context should (see 5.1.2 Exploit Device Capabilities) be used to vary the delivered content to make it more suitable for that specific Delivery Context or to provide an enhanced user experience.

  • If the delivered content does not result from an adaptation process - e.g. the content is statically defined as HTML stored in files, or the details of the Delivery Context cannot adequately be determined, then the delivered content should be suitable for the Default Delivery Context and should comply with the Best Practice statements.

The Default Delivery Context is defined as follows:

Usable Screen Width

120 pixels, minimum.

Markup Language Support

XHTML Basic 1.1 [XHTML-Basic] delivered with content type application/xhtml+xml.

Character Encoding

UTF-8 [UTF-8].

Image Format Support


GIF 89a.

Maximum Total Page Weight

20 kilobytes.


256 Colors, minimum.

Style Sheet Support

CSS Level 1 [CSS]. In addition, CSS Level 2 [CSS2] @media rule together with the handheld and all media types (see CSS 2 Media Types).


HTTP/1.0 [HTTP1.0] or more recent [HTTP1.1].


No support for client side scripting.

4 Structure of Best Practice Statements

The Heading

The functional area that is addressed by the statements.

The Statements

One or more Best Practice statements, identified in the following way:

[EXAMPLE] This is a Best Practice statement.

What it means

An explanation of the significance of the statements under this heading.

How to do it

A discussion of techniques and some suggestions as to how to implement. The BPWG is creating a separate document describing techniques [Techniques] in more detail.

What to Test

The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. This section is not present for process related statements.

In this section it is noted whether the statement is Machine Testable (Automated testing is possible) or Human Testable (Testing requires human assessment). Some Best Practices are partially machine testable, i.e. based on the result of an automated test, some human interaction may be required. In such cases both a Machine Testable and a Human Testable statement are present.

Some Best Practice statements use words such as "minimize" and "avoid" which are intentionally non-prescriptive. This is in order to provide guidance while leaving room to accommodate a wide variety of applications whose requirements cannot be anticipated. It also allows creativity and diversity within the same Best Practice framework. More prescriptive advice can be found in the Techniques document [Techniques].


Where appropriate, references to related WCAG points and other immediate references from the preceding text.

5 Best Practice Statements

The Best Practice statements are grouped under the following headings

5.1 Overall Behavior

There are some general principles that underlie delivery to mobile devices.

5.1.1 Thematic Consistency of Resource Identified by a URI

[THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices. What it means

This is a realization of the One Web (see 3.1 One Web) principle, whereby content should be accessible on a range of devices irrespective of differences in presentation capabilities and access mechanism. Web sites may paginate their content in various ways corresponding to differences in device characteristics; therefore the navigation structure of the site, and possibly its technical realization, may vary according to the device class that is being served. (See also [WebArch] Section 3.5.1).

A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided.

URIs may be decorated to provide session or other information. If a URI is decorated with session information that is no longer current, then the user should be directed to a point in the navigation hierarchy that is appropriate to their device, in order to establish appropriate session and other parameters.

5.2 Navigation and Links

Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile devices, care should be exercised in defining the structure and the navigation model of a Web site.

5.2.6 Link Target Identification

5.2.8 Refreshing, Redirection and Spawned Windows

[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.

5.3 Page Layout and Content

This section refers to the user's perception of the delivered content. It concentrates on design, the language used in its text and the spatial relationship between constituent components. It does not address the technical aspects of how the delivered content is constructed, which is discussed in 5.4 Page Definition.

5.3.1 Page Content

[SUITABLE] Ensure that content is suitable for use in a mobile context.

[CLARITY] Use clear and simple language.

[LIMITED] Limit content to what the user has requested. What it means

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. See also discussion under 2.4 User Goals and 3.1 One Web.

The general prescription to use clear language is of particular importance for mobile delivery, 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. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area. See also 5.3.4 Navigation Bars etc. (Extraneous material) for a discussion of making sure that the subject matter of the page is near the top.

Mobile users often pay for bandwidth, so offering them content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience. In general, the user's consent should be sought before initiating the download of content.

5.3.2 Page Size

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.

[PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.

5.3.3 Scrolling

[SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.

5.3.4 Navigation Bars etc. (Extraneous material)

[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.

5.4 Page Definition

5.4.5 Non-Text Items

[NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script. What it means

A non-text item is defined by Non-text content in the WAI Glossary [WAIGlossary].

Downloading images to a mobiledevice 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 devices do not support embedded objects or script and in many cases it is not possible for users to load plug-ins to add support. Content must be designed with this in mind.

Even where a device does support scripting, do not use it unless there is no other way of accomplishing your objectives. Scripting increases power consumption and so decreases battery life. How to do it

Design pages so that they are useful when rendered as text-only. See also 5.1.4 Testing.

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 pictures of words.

If scripting is used, do not use onmouse and onkey triggers, use onclick.

5.4.9 Style Sheets

[STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.

[STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets.

[STYLE_SHEETS_SIZE] Keep style sheets small. How to do it

It is preferable to share style information between pages, but if the device does not support caching of style sheets then this approach would result in the same style sheet being retrieved for each page. Consequently, in order of preference: if the device caches style sheets, put style information in a single external style sheet (see also 5.2.9 Externally Linked Resources); if the device supports the style element, use it; otherwise use an external style sheet.

Optimize style information so that only styles that are used are included.

When creating style sheets, take advantage of the CSS media types (these may be used both in the CSS @media rule and in the media attribute of the link element) to specify styles that apply to handheld rendering. The CSS Media types that apply are "handheld" and "all". If handheld rendering is not specified, browsers may download other style sheets even if they are identified as applicable to non-handheld rendering

5.4.12 Character Encoding

[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.

[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used. How to do 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.

The character encoding being used in a response may be indicated using the HTTP Content-Type header.

Additionally for XML [XML] documents the character encoding may be indicated in the encoding declaration, although this will generally be ignored if an HTTP Content-Type header is present.

<?xml version="1.0" encoding="UTF-8"?>

Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] and [CHARSET2].

Unicode is a good choice for representing content when served in multiple languages. The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings.

Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8. References

See [XML] Character Encoding in Entities for a discussion of character encoding in XML documents.

5.4.13 Error Messages

[ERROR_MESSAGES] Provide informative error messages and a means of navigating away from an error message back to useful information. How to do it

It is noted that many Web servers provide a default error page, especially in the event of a request for a non-existent page (404) or an internal error (500). Where possible (see [TOMCAT], [APACHE] and [IIS]), applications should trap all error conditions by overriding the default pages if necessary, 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. They should be provided in a format that the device can handle.

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.

The error message should provide one or more of the following navigational constructs:

  1. A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);

  2. A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");

  3. A "home" link to allow the user to return 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. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.

5.5 User Input

This section contains statements relating to user input. This is typically more restrictive on mobile devices than on desktop computers (and often a lot more restrictive). For example, mobile devices may lack pointing devices and often do not have a standard keyboard for text entry.

5.5.1 Input

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.

[AVOID_FREE_TEXT] Avoid free text entry where possible.

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible.

[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it.

6 Conformance and mobileOK

The Best Practice statements are intended to be capable of having conformance statements constructed around them in support of the mobileOK trustmark and for other purposes. Work on the mobileOK trustmark will develop specific recommended requirements for a trustmark, which will be based on some profile, or subset, of the Statements in this document.

As such, the mobileOK trustmark will serve as the main conformance claim for the Best Practices document.

All of the Best Practice statements have a fragment identifier to allow formal reference to them and allow the construction of compliance claims that refer to them.

A Sources (Non-Normative)

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.

B Related Reading (Non-Normative)

Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.

The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.

The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.

Section 3.2 Background to Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity.

C Acknowledgements (Non-Normative)

The editors would like to thank members of the BPWG for contributions of various kinds. The editors would also like to thank contributors to the public list, and contributors of Last Call comments whose comments have been taken into account in the creation of this document.

The editors acknowledge significant written contributions from:

D References (Non-Normative)

D.4 Web, Protocols and Languages

Architecture of the World Wide Web, Volume One, N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004 (See http://www.w3.org/TR/2004/REC-webarch-20041215/)
Extensible Markup Language (XML) 1.0 (Fourth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C Recommendation 16 August 2006, edited in place 29 September 2006 (See http://www.w3.org/TR/2006/REC-xml-20060816 )
XHTML™ Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/)
Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 (See http://www.w3.org/TR/1999/REC-CSS1-19990111)
Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998 (See http://www.w3.org/TR/1998/REC-CSS2-19980512/)
Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945)
Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html)
UTF-8, a transformation format of ISO 10646 Request for Comments: 3629, F. Yergeau, November 2003 (See http://www.ietf.org/rfc/rfc3629.txt)
Tutorial: Character sets & encodings in XHTML, HTML and CSS (See http://www.w3.org/International/tutorials/tutorial-char-enc/)
FAQ: Setting encoding in Web authoring applications (See http://www.w3.org/International/questions/qa-setting-encoding-in-applications)