Mobile Web Best Practices 1.0

1 Introduction

1.1 Purpose of the Document

This document sets out a series of recommendations designed to promote more effective delivery of Web content to mobile devices.

Each recommendation is discussed in context and brief explanatory notes are provided. The recommendations are offered to all participants in the mobile value chain and are intended as the basis for assessing conformance to the mobileOK trustmark.

The mobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter and is not developed in this document. mobileOK and techniques for implementing the Best Practice recommendations will be discussed in companion documents.

1.2 Audience

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.

Our intention is to make it clear to all involved what the best practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some of our statements may appear to be obvious or trivial to those with experience in this area.

The document is not targeted solely at developers and others such as interaction and graphic designers are encouraged to read it.

1.2.1 Participants in the Mobile Value Chain

Participants in the mobile value chain include:

Web Site Developers: Original content developers together with portal operators and other aggregators of content who deliver non-original content to mobile and other users.
Mobile Network Operators: Who may transform content when it passes from the Internet to their networks, and who may in addition operate portals.
Browser and Delivery Platform Developers: Who realize content for users to perceive.
Authoring Tool Developers: Developers of tools to assist with content production (authoring).
Content Manipulation Tools Developers: Developers of tools to assist with content serving and repurposing.
Conformance Testers: Those involved in the production and execution of testing processes.

1.3 Scope

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

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

1.3.1 Phasing

As discussed in [Scope] there are many aspects to Mobile Web Best Practices. For example, at present, the design and construction of many Web sites and pages make for a poor user experience when they 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 multimodal interaction.

1.3.2 Usability

There are three aspects of mobile usability - namely site, device, and browser usability. All three together contribute to the user experience.

These three aspects are defined 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.

1.3.3 One Web

The recommendations in this document are intended to improve mobile 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 [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 way across all devices. Some services and information are more suitable for and targeted at particular user contexts.

Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (perhaps 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 which have a primarily desktop appeal (lengthy reference material, rich images, perhaps).

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 a reasonable experience irrespective of the device, and as far as is possible, not to exclude access from any particular class of device.

From the perspective of this document this means that services should be available as some variant of HTML over HTTP.

1.4 Default Delivery Context

The recommendations refer to delivered content. Given the range of different mobile device types which have different properties and different features the Best Practices Working Group has defined a Default Delivery Context.

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

The document makes reference to the Default Delivery Context in two ways:

If the delivered content does not result from an adaptation process - e.g. the content is statically defined as HTML stored in files - then the delivered content should be suitable for the Default Delivery Context and should comply with the Best Practice Statements.
If an adaptation process is used, then information that is known about the Delivery Context can be used to vary the delivered content to make it more suitable for that Delivery Context or to provide an enhanced user experience.

The default delivery context is defined as follows:

Usable Screen Width

120 Pixels.

Mark Up Language Support

XHTML - Basic Profile.

Character Encoding

UTF-8.

Image Format Support

JPEG

GIF 89a (non-interlaced, non-transparent, non-animated).

Maximum Total Page Weight

20k Bytes.

Colors

Web safe.

Style Sheet Support

External CSS Level 1, with internal definition of style and font properties.

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 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 also discusses the notion of device characteristics, which DIWG has described in terms of a "Delivery Context" [DCODI]. In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS].

The BPWG will develop a companion document describing techniques [Techniques] by which the best practice statements in this document can be implemented.

1.6 How the Best Practices are Organized

The document is organized as follows:

Introduction. Describes the audience, purpose and scope of the document.
Requirements, An illustration of the type of problems that the Best Practices are intended to ameliorate.
Architecture. Discusses the environment within which the mobile web is realized, with particular reference to adaptation.
Overview of Best Practices. A discussion of the organization of the best practices, and sources from which they were derived.
Best Practices. The statements themselves.
Conformance and mobileOK. A brief conformance statement and pointer to the mobileOK documentation.
Annexes
Acknowledgements
References

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.

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 to use, and in many cases upgrade of the browser 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 mark up [T-MOB]. 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 deplete the battery. Reducing the amount of communication can conserve charge.

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.

personal,
personalizable
portable

and increasingly multi-function beyond their original purpose of voice

communications.

Beyond these factors, the advantages of mobile devices will increasingly include:

location awareness
implicit user identification
one handed operation
always on
universal alerting device

As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you 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. medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time in their wristwatches.

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

3 Delivery Model Architecture

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 briefly describes content adaptation in order to provide a background for this document. For a more detailed description, readers are referred to the Device Independence Principles [DIP]

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.

3.1 Adaptation Implementation Model

There is quite a wide spectrum of 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 client [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 client.

Client Side adaptation consists of the client accepting content and displaying it appropriately to the device's characteristics.

3.2 Assumptions about Adaptation

In phase 1 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 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.

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.

In order to determine the appropriate adaptation 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 provider is expected to assume the default delivery context, as discussed in the Introduction to this document.

4 Overview of Best Practices

4.1 How the Best Practice Statements are Organized

In the following section the Best Practices are organized under the following headings:

Process: Best Practice Statements that refer primarily to the process by which content is created.
Navigation and Links: This section contains statements that relate to navigation and linking mechanisms.
Page Layout and Content: The section contains statements that relate to the content of pages and how they lay out.
Page Definition: Statements that relate to the technical construction of pages.
Input: Statements that relate to Input.

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

These statements can be identified by using URI reference composed of the URI of this document together with the statement identifier used as a fragment identifier (e.g. #EXAMPLE).

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 intends to create 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.
Human testable: Testing requires human assessment.
Partially machine testable: Based on the result of an automated test some human interaction may be required.

References

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

5 Best Practice Statements

5.1 Overall Behavior

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

5.1.1 Establish the Context of the Device

[CONTEXT] 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.

5.1.1.1 What it means

Many of the best practice statements refer to the content provider knowing a significant amount about the characteristics of the device, the properties of the browser in use and the transparency of the network connection to the device. For simple sites that 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.

It is unlikely that the content provider, "having taken all reasonable steps", will know nothing at all about the context of the device. However if absolutely nothing is known "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).

Where the determination of the default experience has resulted in selection of a mobile experience, the default delivery context should be assumed in creating that presentation.

The content provider may choose, in the interests of "One Web" considerations, to allow the user to select the experience from broad categories such as mobile or desktop, where these presentations are distinguished in the application.

5.1.1.2 How to do it

There are several techniques by which a content provider can discover information about a client's capabilities: CC/PP, UAPROF, CSS Media Queries, DDWG output, DIWG material.

5.1.2 Exploit Client Capabilities

[CAPABILITIES] Exploit device capabilities. Do not take a least common denominator approach.

5.1.2.1 What it means

While encouraging content providers to be sensitive to the needs of the default delivery context, it is not intended that this results in a diminished experience on more capable devices. Specifically it is not the intention to encourage the development of sites that target the default delivery context when a better user experience could be attained on more capable devices.

5.1.3 Work around deficient implementations

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

5.1.3.1 What it means

Just as in the desktop browser world, there are browsers that do not respect the intentions of the content provider. 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 is a particular challenge to provide work-arounds for these deficiencies and differences in interpretation. It is recognized that content providers may need to violate specific best practices in order to support their intentions on devices that exhibit deficiencies in implementation. If a device is not known to have specific limitations then content providers must comply with best practices.

Just as it is not the intention to recommend a least common denominator approach, it is not the intention to recommend avoidance of features that exhibit problems on some class of devices.

It is also not the intention to suggest that content providers should restrict their support to certain client types. Content providers should aim to support as wide a range of client types as is practical.

5.1.4 Testing

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

5.1.4.1 What it means

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, content providers are encouraged to test that the features they rely on work in actual devices.

5.1.4.2 How to do it

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.

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 clients, care should be exercised in defining the structure and the navigation model of a web site.

5.2.1 URIs of Site Entry Points

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

5.2.1.1 What it means

Typing URIs on mobile devices can be difficult, so keeping site entry point URIs short can reduce the chance of error and provide a more satisfactory user experience.

5.2.1.2 How to do it

The user should not need to type the default page filename.

5.2.2 Navigation Bar

5.2.2.1 What it means

Two or three links should be enough to provide the basic navigation. Navigation should be placed on the top of the page. Any other secondary navigational element may be placed at the bottom of the page if really needed.

5.2.2.2 How to do it

Provide the basic links on a single line. If they do not fit the screen the device will take care of wrapping.

5.2.3 Balanced Structure

[BALANCE] Design the service with a broadly balanced navigation tree where numbers of links on pages is balanced against depth of navigation.

5.2.3.1 What it means

The design should aim to provide a balance between having 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.

5.2.4 Thematic Consistency of Resource Identified by a URI

[THEMATIC_CONSISTENCY] Ensure that links provide a thematically coherent experience when accessed from a device other than the one on which they were captured.

5.2.4.1 What it means

This is a realization of the One Web principle, whereby content should be accessible on a range of devices irrespective of differences in presentation capabilities. 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.

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.

In addition, URIs may be decorated to provide session or other information.

5.2.4.2 How to do it

If the 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.5 Navigation Mechanisms

5.2.5.1 What it means

Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.

Users of devices that do not have pointing devices have to scroll between hyperlinks using the keypad. Intelligent grouping, perhaps optimized through adaptation according to usage patterns, can assist usability.

5.2.5.2 How to do it

A "drill-down" method, based on major headings, can often provide an effective means of navigation; 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.

5.2.5.3 References

This relates to WCAG 13.4

5.2.6 Access Keys

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

5.2.6.1 What it means

Where there is no pointing device, assigning an access key (keyboard short cut) to a link can provide a convenient way for users to access the link, and avoid navigating to the link by repeated pressing of the navigation key .

Provide the same access key for links that are repeated across pages such as links to the home page.

When building a list of links use numbered lists and assign access keys appropriately. It is recognized that not all characters can be used as access keys as many mobile devices have a limited keyboard.

5.2.6.2 What to test

Machine Test: Test for the presence of the accesskey attribute.

Human Test: Verify the presence of the accesskey attribute on links such as the home page.

5.2.6.3 References

This relates to WCAG 9.5

5.2.7 Link Target Identification

[LINK_TARGET_ID] Clearly identify the target of each link. Use clear, concise, descriptive link text to help users decide whether to follow a link. Identify the implications of following a link if the target is notably large and the user might not anticipate this from the context.

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

5.2.7.1 What it means

Users of mobile devices may suffer undue delay and cost as a result of following links. It is important to identify where a link leads so users can make an assessment of whether following it will be of interest to them. While it is unlikely that the cost in monetary terms of a particular user following a particular link can be specified, 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.

5.2.7.2 What to test

Human Test: Check for proper descriptions (and no use of "Click here").

Human and Machine Test: Spider the page/web site to find links to non-HTML formats and check whether there is information about the format of the target of the link.

5.2.7.3 References

This relates to WCAG 11.3 and 13.1

5.2.8 Image Maps

[IMAGE_MAPS] Do not use image maps unless you know the target client supports them and has sufficient screen area 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.

[SERVER_SIDE_IMAGE_MAPS] Do not use a server side image map unless you know that the client provides a means of selection within the image map.

5.2.8.1 What it means

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.

5.2.8.2 How to do it

If only small images can be displayed, break larger images up into smaller sections and deal with them separately.

If a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.

5.2.8.3 What to test

IMAGE_MAPS Machine Test: Send a request to the site with a user agent that does not support client-side image maps and check the map element is not present.

SERVER_SIDE_IMAGE_MAPS Machine Test: Send a request to the site with a user agent that does not support server-side image maps and check the ismap attribute is not present.

5.2.8.4 References

This relates to WCAG 1.2 and 9.1

5.2.9 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.2.9.1 What it means

Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction.

Some mobile devices use a separate window for input; this section does not refer to such windows.

Many mobile devices cannot support more than one window and consequently attempting to open one will have unpredictable results.

Auto refreshing pages are widely recognized as presenting accessibility problems, and in a mobile environment may expose the user to undue cost as a result of an auto refreshing page being left open, or put unnoticed into the background. If an auto refreshing page is demanded by the application always provide a means of ceasing the auto refresh and always inform the user that the page will refresh and may expose them to high usage costs.

While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser. This adds to delay on slow links, hence redirection should not be used as a matter of course.

5.2.9.2 What to test

POP_UPS Machine Test: Look for the target attribute on links.

AUTO_REFRESH Machine Test: Check whether meta http-equiv="refresh" content=" the same URI " is used.

AUTO_REFRESH Human Test: If auto refresh is used, check that options are provided to stop any page using auto-refresh.

REDIRECTION Machine Test: Check whether meta http-equiv="refresh" content=" a different URI " is used.

5.2.9.3 References

This relates to WCAG 7.4, 7.5 and 10.1

5.3 Page Content and Layout

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.

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

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. 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. In general, the user's consent should be sought before initiating the download of content.

5.3.1.2 What to test

Examine content to determine if, given the subject matter, it is appropriate in a mobile content. [NB probably not machine-testable.]

5.3.1.3 References

This relates to WCAG 13.8 and 14.1.

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 bandwidth, the memory limitations of the device and other device and delivery channel characteristics if they can be determined.

5.3.2.1 What it means

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. This can lead to an unnecessary delay since each request typically takes a measurable time to complete.

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.

Some studies [MF] have been carried out in this area to test for user preferences. Some of these indicate that users prefer scrolling to click-throughs and some indicate the contrary. More research is likely to be needed in this area.

5.3.2.2 What to test

PAGE_SIZE_USABLE Machine Test: Check that the page doesn't exceed 10 KBytes for the default delivery context.

Human Test: Check that the page is still usable (e.g. not cut in the middle of a sentence, just before the end of a section, and so on).

PAGE_SIZE_LIMIT Machine Test: Measure the total size of mark-up and images for a page; check that it doesn't go over the allowed size for the device - 20 KBytes for the default delivery context.

5.3.2.3 References

This relates to WCAG 12.3

5.3.3 Scrolling

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

[SCROLLING_LIMIT] Limit secondary scrolling to objects that require it, where it cannot be avoided.

5.3.3.1 What it means

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 secondary scrolling.

If some element on the page requires secondary 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 render beyond the right boundary of the page then the user will be required to scroll to read each line of text.

5.3.3.2 How to do it

If it is not possible to avoid presenting images that are larger than the screen size, then consider providing these images on a separate page with a link back to the main content.

5.3.3.3 What to test

SCROLLING Machine Test: Check for width attributes and width style properties wider than the screen size - for the default delivery context, 120 pixels.

Human Test: If it is wider, check that the use case warrants it (e.g. maps).

SCROLLING_LIMIT Human Test: Browse URIs within a site with a mobile user agent and observe that pages with elements that require secondary scrolling, only those elements require it and the rest of the page requires only primary scrolling.

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.3.4.1 What it means

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

5.3.4.2 How to do it

Menu selections can be placed away from the top of the page with a simple link to the selection at the top of the page. Alternatively, use meta navigation on top of the page with simple text links to major sections of the web site.

5.3.4.3 What to test

Human test: Browse URIs within a site with a mobile user agent and observe that the most important/relevant information is conveyed first

5.3.4.4 References

This relates to WCAG 13.5

5.3.5 Graphics

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing.

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

5.3.5.1 What it means

Graphics that are larger than necessary, for example by possessing a higher resolution than is displayable on the device or by having too many colors, waste bandwidth.

5.3.5.2 What to test

GRAPHICS_FOR_SPACING Machine Test: Check for very small and/or transparent graphics.

LARGE_GRAPHICS Machine Test: Check dimensions of graphics.

5.3.6 Color

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

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

5.3.6.1 What it means

Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence information highlighted in color may not be visible to users. If color is used to indicate a feature then that feature should generally also be indicated in a way that is not color dependent. In particular, do not use blue or purple text, as this may be confused with hyperlinks, especially on devices that do not underline links.

5.3.6.2 What to test

USE_OF_COLOR Human Test: Browse the page in a monochrome environment.

COLOR_CONTRAST Human Test: Browse the page under a strong light parallel to the screen.

Machine Test: There are automatic tools to test color contrast.

5.3.6.3 References

This relates to WCAG 2.1 and 2.2

5.3.7 Background Images

[BACKGROUND_IMAGE_SUPPORT] Do not use background images unless you know the device supports them.

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

5.3.7.1 What it means

Images that are used indiscriminately can lead to content that is hard to view, particularly with the limited contrast often found on mobile devices and in the hostile viewing conditions in which mobile devices are frequently used.

Before using background images, consider carefully your objectives for doing so and try to use alternative techniques to achieve similar objectives.

5.3.7.2 What to test

BACKGROUND_IMAGE_SUPPORT Machine Test: Send a request to the site with a user agent that does not support background images and check the background attribute is not present.

BACKGROUND_IMAGE_READABILITY Human Test: Test readability.

5.4 Page Definition

5.4.1 Title

[PAGE_TITLE] Provide a short but descriptive page title.

5.4.1.1 What it means

Provide a descriptive title for the page to allow easy identification. Keep the title as short as is possible to reduce page weight and bear in mind that it may be truncated.

Many mobile browsers do not display the title of a page. 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.

5.4.1.2 What to test

Machine Test: Test for presence of the title element.

Human Test: Test that the title is descriptive of content.

5.4.2 Frames

[NO_FRAMES] Do not use frames.

5.4.2.1 What it means

Many mobile clients do not support frames. In addition, frames are recognized as being generally problematic.

5.4.2.2 What to test

Machine Test: Test for presence of frame related elements - in HTML check for frameset and iframe elements.

5.4.2.3 References

See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.

5.4.3 Structural Elements

[STRUCTURE] Ensure that perceivable structures within the content can be programmatically determined.

5.4.3.1 What it means

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.

5.4.3.2 How to do it

Mark up languages like HMTL contain many constructs to indicate structure.

5.4.4 Tables

[TABLES_SUPPORT] Do not use tables unless the client is known to support them. Do not use multi-layer tables.

[TABLES_LAYOUT] Do not use tables for layout.

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

5.4.4.1 What it means

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 and vertically to see possible navigational choices.

5.4.4.2 What to test

TABLES_SUPPORT Machine Test: Send a request to the site with a user agent that does not support tables and check the table element is not present.

Machine Test: Check that there are no nested tables.

TABLES_LAYOUT Machine Test: Check that no column or row in a table is empty or contains only a 1x1 transparent GIF.

5.4.4.3 References

This relates to WCAG 5.1, 5.2, 5.3, 5.5 and 5.6

5.4.5 Non Text Items

[NON-TEXT_ALTERNATIVES] Provide textual alternatives for non-text elements.

[OBJECTS_OR_SCRIPT] Do not embed objects or script in pages unless you know the device supports them.

5.4.5.1 What it means

Downloading images to a mobile client 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.

5.4.5.2 How to do it

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

5.4.5.3 What to test

NON-TEXT_ALTERNATIVES Machine Test: Test for presence of alt attribute on images and text content on objects.

Human Test: Check the relevance of alt attributes with their elements.

OBJECTS_OR_SCRIPT Machine Test: Send a request to the site with a user agent that does not support scripts and check the script element is not present.

Machine Test: Send a request to the site with a user agent that does not support objects and check the object element is not present.

5.4.5.4 References

This relates to WCAG 1.1, 3.1, 6.2, 6.3, 6.5 and 9.2.

5.4.6 Image Size

[IMAGES_SPECIFY_SIZE] Always specify the size of images in markup.

[IMAGES_RESIZING] Resize images at the server.

5.4.6.1 What it means

Resizing images at the server and specifying their size in markup 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.

5.4.6.2 What to test

IMAGES_SPECIFY_SIZE Machine Test: Test for presence of width and height attributes on img elements.

IMAGES_RESIZING Machine Test: Check width and height attributes are equal to image dimensions.

5.4.7 Valid Markup

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

5.4.7.1 What it means

If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.

5.4.7.2 What to test

Machine Test: Validate documents.

5.4.7.3 References

This relates to WCAG 3.2, 11.1 and 11.2.

See http://www.w3.org/QA/Tools/#validators.

5.4.8 Measures

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

5.4.8.1 What it means

Avoiding pixel and absolute measures allows the browser to adapt content to fit the display. An exception to rule is where an image has been specifically sized for a particular display (see 5.4.6 Image Size). In this case references to the image in markup may specify the exact dimensions of the image in pixels, in order to help the browser to flow the page, and avoid re-flowing it after the page has been retrieved.

5.4.8.2 How to do it

Use percentage and other relative measures.

5.4.8.3 What to test

Machine Test: Send a request to the site with a user agent that supports relative measures correctly and check the values of font-size are not absolute or pixels.

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 they may be read without style sheets.

[STYLE_SHEETS_SIZE] Keep style sheets as small as possible.

5.4.9.1 What it means

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.

5.4.9.2 What to test

STYLE_SHEETS_USE Machine Test: Send a request to the site with a user agent that supports CSS and check that style sheets are used and that the page does not use formatting tags (e.g. font).

STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and checks that the page is still readable.

STYLE_SHEETS_SIZE Machine Test: Check that the elements in a style sheet are used in the pages that reference it.

5.4.9.3 References

This relates to WCAG 3.3.

5.4.10 Minimize

[MINIMIZE] Use terse efficient markup.

5.4.10.1 What it means

Content which is marked up in languages such as XML can often be made smaller while preserving exactly the 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.

5.4.10.2 How to do it

While it is not intended that authors should create their content in a single line to remove white space altogether, it is suggested that authors should not contribute to page weight by introducing unnecessary white space. Note that "Pretty Printing", i.e. the formatting of mark-up with programs such as HTML Tidy, with indent option set to "yes", can generate large amounts of white space and hence add to page weight.

If "pretty printing" is an important part of the authoring process then try to arrange that redundant white space is stripped when serving a page.

Even though some network proxies strip white space that they think is redundant, not all do so, so it is not best practice to rely upon this behavior. There are other issues relating to network proxies (such as requesting them not to strip relevant white space). Such issues will be addressed in a later phase.

Use of structural markup contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS.

5.4.10.3 What to test

Count the number of non-significant white space characters in the document.

5.4.11 Content Types

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

[CONTENT_FORMAT_PREFERRED] Where possible send content in a client's preferred format.

5.4.11.1 What it means

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.

5.4.11.2 How to do it

To determine what formats a device supports, web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers and UAProf.

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.

5.4.11.3 What to test

CONTENT_FORMAT_SUPPORT Machine Test: Check MIME types of content with various User-Agent

Machine Test: Check MIME types of content with various user agents.

CONTENT_FORMAT_PREFERRED Machine Test: Check MIME types of content with various user agents and check that the preferred format is sent or that the format is compatible with the default delivery context.

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

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

5.4.12.1 What it means

As in the previous section, content should not be sent to a device if it can not use it.

5.4.12.2 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 sent with a request (see also the section above on determining device characteristics).

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

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

Example:
<?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 [HTTP_CHARSET]

5.4.12.3 What to test

Machine Test: Check that the Content-Type HTTP header contains the encoding and that this encoding is supported (may also need to check the XML declaration for XML-based content and the CSS @charset rules for CSS).

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.

5.4.13.1 What it means

It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought. Providing easy navigation away from the error is particularly important in the mobile arena, where browsers may not have an easy-to-find "back" button, where contextualization is frequently difficult and where re-entry of URIs as a means of error recovery is particularly onerous.

It is noted that errors due to networking, connection and some kinds of mistyping of URIs are not within the control of the content provider which has no way to influence how such errors are presented to the user. However, where errors are within the control of the content provider 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 retry the 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 to the page they were on prior 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.

5.4.13.2 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:

A "back" link to return to the previous page (particularly for devices that do not have an easy to find 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 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.