Copyright © 2005-2006 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This document specifies Best Practices best practices for delivering Web content to when accessed from mobile devices.
The principal objective primary goal 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 It is created, nor to directed at all participants in the devices or user agents to which it is delivered. mobile value chain .
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 web servers and HTTP. Readers are not expected to have a background in mobile-specific technologies.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document describes the best practices for content to work well on mobile devices. A companion scope document [Scope] describes the scope of this work.
This is the second Last Call Working Draft for the Mobile Web Best Practices, following the two previous Last Call public working draft published in January (see the changes since the previous publication ). drafts. The Mobile Web Best Practices Working Group seeks feedback from the first Last Call commenters on the disposition of their explicitly requests comments , as well as general feedback on the changes brought to the document since the previous version. this document. The deadline for Last Call comments is set to 3 May 17 February 2006.
Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list .
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative .
This document was produced under the 5 February 2004 W3C Patent Policy. Although the Working Group expects this document to become a W3C Recomendation, it is informative only. The Working Group maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy .
1
Introduction
1.1
Purpose
of
the
Document
1.2
How
the
Best
Practices
are
Organized
Audience
1.3
Audience
1.2.1
Participants
in
the
Mobile
Value
Chain
1.4
1.3
Scope
1.4.1
1.3.1
Phasing
1.3.2
Usability
1.3.3
One
Web
1.4
Default
Delivery
Context
1.5
Relationship
to
other
Best
Practices
best
practices
and
recommendations
1.6
Longevity
and
Versioning
How
the
Best
Practices
are
Organized
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
Model
Architecture
3.1
One
Web
3.2
Background
to
Adaptation
3.3
Adaptation
Implementation
Model
3.4
3.2
Assumptions
about
Adaptation
3.5
Establishing
Context
3.6
Choice
4
Overview
of
User
Experience
Best
Practices
3.7
Default
Delivery
Context
4.1
How
the
Best
Practice
Statements
are
Organized
4
4.2
Structure
of
Best
Practice
Statements
5
Best
Practice
Statements
5.1
Overall
Behavior
5.1.1
Thematic
Consistency
Establish
the
Context
of
Resource
Identified
by
a
URI
the
Device
5.1.2
Exploit
Client
Capabilities
5.1.3
Work
around
Deficient
Implementations
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
Thematic
Consistency
of
Resource
Identified
by
a
URI
5.2.5
Navigation
Mechanisms
5.2.5
5.2.6
Access
Keys
5.2.6
5.2.7
Link
Target
Identification
5.2.7
5.2.8
Image
Maps
5.2.8
5.2.9
Refreshing,
Redirection
and
Spawned
Windows
5.2.9
Externally
Linked
Resources
5.3
Page
Layout
and
Content
and
Layout
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
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
6
Conformance
and
mobileOK
6.1
Classes
of
Products
6.2
Extensibility
A
Sources
(Non-Normative)
B
Acknowledgements
(Non-Normative)
C
References
(Non-Normative)
C.1
MWI
References
C.2
Sources
C.3
Device
Independence
C.4
Web,
Protocols
and
Languages
C.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
.
[
THEMATIC_CONSISTENCY
]
Ensure
that
content
provided
by
accessing
a
URI
yields
a
thematically
coherent
experience
when
accessed
from
different
devices.
[
CAPABILITIES
]
Exploit
device
capabilities.
Do
not
take
a
least
common
denominator
approach.
[
DEFICIENCIES
]
Take
reasonable
steps
to
work
around
deficient
implementations.
[
TESTING
]
Carry
out
testing
on
actual
devices
as
well
as
emulators.
[
URIS
]
Keep
the
URIs
of
site
entry
points
short.
[
NAVBAR
]
Provide
only
minimal
navigation
at
the
top
of
the
page.
[
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.
[
NAVIGATION
]
Provide
consistent
navigation
mechanisms.
[
ACCESS_KEYS
]
Assign
access
keys
to
links
in
navigational
menus
and
frequently
accessed
functionality.
[
LINK_TARGET_ID
]
Clearly
identify
the
target
of
each
link.
[
LINK_TARGET_FORMAT
]
Note
the
target
file's
format
unless
you
know
the
device
supports
it.
[
IMAGE_MAPS
]
Do
not
use
image
maps
unless
you
know
the
target
client
supports
them
effectively.
[
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.
[
EXTERNAL_RESOURCES
]
Keep
the
number
of
externally
linked
resources
to
a
minimum.
[
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.
[
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.
[
SCROLLING
]
Limit
scrolling
to
one
direction,
unless
secondary
scrolling
cannot
be
avoided.
[
CENTRAL_MEANING
]
Ensure
that
material
that
is
central
to
the
meaning
of
the
page
precedes
material
that
is
not.
[
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.
[
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.
[
BACKGROUND_IMAGE_READABILITY
]
When
using
background
images
make
sure
that
content
remains
readable
on
the
device.
[
PAGE_TITLE
]
Provide
a
short
but
descriptive
page
title.
[
NO_FRAMES
]
Do
not
use
frames.
[
STRUCTURE
]
Use
features
of
the
markup
language
to
indicate
logical
document
structure.
[
TABLES_SUPPORT
]
Do
not
use
tables
unless
the
client
is
known
to
support
them.
[
TABLES_NESTED
]
Do
not
use
nested
tables.
[
TABLES_LAYOUT
]
Do
not
use
tables
for
layout.
[
TABLES_ALTERNATIVES
]
Where
possible,
use
an
alternative
to
tabular
presentation.
[
NON-TEXT_ALTERNATIVES
]
Provide
a
text
equivalent
for
every
non-text
element.
[
OBJECTS_OR_SCRIPT
]
Do
not
rely
on
embedded
objects
or
script.
[
IMAGES_SPECIFY_SIZE
]
Specify
the
size
of
images
in
markup,
if
they
have
an
intrinsic
size.
[
IMAGES_RESIZING
]
Resize
images
at
the
server,
if
they
have
an
intrinsic
size.
[
VALID_MARKUP
]
Create
documents
that
validate
to
published
formal
grammars.
[
MEASURES
]
Do
not
use
pixel
measures
and
do
not
use
absolute
units
in
markup
language
attribute
values
and
style
sheet
property
values.
[
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
small.
[
MINIMIZE
]
Use
terse,
efficient
markup.
[
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
preferred
format.
[
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.
[
ERROR_MESSAGES
]
Provide
informative
error
messages
and
a
means
of
navigating
away
from
an
error
message
back
to
useful
information.
[
COOKIES
]
Do
not
rely
on
cookies
being
available.
[
CACHING
]
Provide
caching
information
in
HTTP
responses.
[
FONTS
]
Do
not
rely
on
support
of
font
related
styling.
[
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
target
device
is
known
to
support
it.
[
TAB_ORDER
]
Create
a
logical
order
through
links,
form
controls
and
objects.
This document sets out a series of recommendations designed to improve the user experience promote more effective delivery of the Web on content to mobile devices.
Each recommendation is discussed in context and brief explanatory notes are provided. The recommendations are offered to creators, maintainers and operators of Web sites all participants in the mobile value chain and are intended as the basis for assessing conformance to the mobileOK trustmark, which 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.
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 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 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; others, developers and others such as interaction and graphic designers are encouraged to read it.
Participants in the mobile value chain include:
Original content developers together with portal operators and other aggregators of content who deliver non-original content to mobile and other users.
Who may transform content when it passes from the Internet to their networks, and who may in addition operate portals.
Who realize content for users to perceive.
Developers of tools to assist with content production (authoring).
Developers of tools to assist with content serving and repurposing.
Those involved in the production and execution of testing processes.
The scope of these Best Practices is laid out in "Scope of Mobile Web Best Practices" [Scope] . In summary, summary this document refers primarily to the extension of Web 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, 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" 'Error Messages' and "Color". 'Color'.
As discussed in the Scope document [Scope] there are many aspects to Mobile Web Best Practices. At present, for 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.
The quality While improving those Web sites is only one aspect of improving the user's Web experience via a mobile device depends significantly on user experience, significant improvements can be achieved in this way, hence the usability of Web sites, of browsers, and first phase of the device itself. Although browser usability and device usability are important (for reading, navigating, and interacting work is concerned with content), this document focuses primarily on Best Practices providing guidelines for improving site usability. Web-site and content developers.
In future phases other aspects may be considered - e.g. Best Practices best practices as applied to adaptation and devices. Also in future phases the scope of the recommendations may be extended beyond "Traditional 'Traditional Web Browsing" Browsing' into fields such as multimodal interaction.
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.
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.
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:
120 Pixels.
XHTML - Basic Profile.
UTF-8.
JPEG
GIF 89a (non-interlaced, non-transparent, non-animated).
20k Bytes.
Web safe.
External CSS Level 1, with internal definition of style and font properties.
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 also discusses the notion of device and delivery channel characteristics, which the DIWG has named 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 best practice statements in this document can be implemented.
The Best Practices have been written at a level document is organized as follows:
Introduction. Describes the audience, purpose and scope of generality that allows them to be applicable across a range the document.
Requirements, An illustration of markup languages. They have been written with enduring properties the type of mobile access problems that the Best Practices are intended to ameliorate.
Architecture. Discusses the Web in mind. While environment within which the factors identified in 3.7 Default Delivery Context , such as screen dimensions, will change over time, it seems likely that mobile web is realized, with particular reference to adaptation.
Overview of Best Practices. A discussion of the distinguishing features organization of mobile access such as cost the best practices, and difficulty of input will remain issues. sources from which they were derived.
This document will be reviewed from time to time. When necessary, an updated version will be released with clear documentation as Best Practices. The statements themselves.
Conformance and mobileOK. A brief conformance statement and pointer to the changes that have been introduced. mobileOK documentation.
Annexes
Acknowledgements
References
This section discusses the requirements of the Mobile Web Best Practice statements in section 5. The statement of requirements is intended to be illustrative rather than exhaustive or complete.
Today, Many Web pages today are laid out for with presentation on desktop size displays, displays in mind, and exploit capabilities make use of the facilities provided by desktop browsing software.
Accessing such a Web page on a mobile device often results in a poor poor, or unusable experience. Contributing factors include pages to this poor experience is that the content does not being laid lay out as intended. Because intended, and because of the limited screen size and the limited amount of material on the page that is visible to the user, things that are intended to be viewed together are not presented together - context and overview are lost.
Because of the limited screen size, size the subject matter of the page may require considerable scrolling to be visible, especially if the top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether their retrieval has resulted in the right content.
It is particularly important in the mobile context to help the user create a mental image of the site. This can be assisted by adopting a consistent style and contrariwise can be considerably diminished by an uneven style.
Mobile device input is often difficult hard when compared with use of a desktop device equipped with a keyboard. Mobile devices such as phones often have only a very limited keypad, with small keys, and there is frequently no pointing device.
One of the difficulties of the mobile Web web is that URIs are very difficult hard to type. Lengthy type, and lengthy URIs and those that contain a lot of punctuation are particularly difficult hard to type correctly.
Because of the limitations of screen and of input, forms are hard to fill in. This is in, both because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields.
While many modern devices provide back buttons, some do not, and in some cases, where back functionality exists, users may not know how to invoke it. This means that it is often very hard to recover from errors, broken links and so on.
Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency. This can lead to long retrieval times, especially for lengthy content and for content that requires a lot of navigation between pages.
Mobile data transfer often costs money. The fact that mobile devices frequently support only limited types of content means that a user may follow a link and retrieve information that is unusable on their device.
Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory - for example, example larger images may only be viewable in small pieces and require considerable scrolling.
Web Requests for web pages can contain result in the delivery of content that the user has not specifically requested - especially advertising and large site images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.
Mobile users typically have different interests to users of fixed or desktop devices. They are likely to have more immediate and goal-directed intentions than desktop Web web users. Their intentions are often to find out specific pieces of information that are relevant to their context. An example Examples are frequently given of such a goal-directed application might be travel related applications, where the user requiring might require specific information about schedules for a journey they schedules.
Other examples are currently undertaking. frequently given of time filling entertainment applications, where people are filling otherwise dead time while traveling.
Equally, On the other hand, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available.
Developers of commercial Web web sites should note that different commercial models are often at work when the Web is accessed from mobile Mobile devices as compared with desktop devices. For example, some mechanisms that are commonly used for presentation of advertising material do not work well on small devices and are therefore contrary to the Best Practice recommendations. Recommendations.
It is not the intention of the MWI to limit or to restrict advertising; rather it is the intention that the user experience of the site as a whole, including advertising, if any, is as effective as possible.
As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than that used for desktop devices. As detailed in the Scope document [Scope] , various other limitations may apply to mobile devices, and these have an impact on the usability of the Web from a mobile device.
Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no choice of option as to which browser to use, and upgrading it in many cases upgrade of the browser is not possible.
Some activities associated with rendering Web web pages are computationally intensive - for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid markup mark up [T-MOB] . Mobile devices There is typically have quite limited processing power available to carry out such computations, which means that page rendering may mean they take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses Such computations also use more power as does communication with and deplete the server. 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.
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 their being:
personal personal,
personalizable
portable
communications.
In addition to Beyond these factors, the advantages of mobile devices will increasingly include:
location awareness
one-handed implicit user identification
one handed operation
always on
universal alerting device
By way of As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web can will go where you go. You do not 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. providing medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time on in 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 web-capable mobile devices may play as similar a similar role in for deploying wide-spread Web access as the mobile phone has played for providing "plain old telephone service".
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.2 Background to Adaptation 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 devices. clients. For example different devices clients support different markup features features, and the different screen sizes may demand different sized images.
Consequently, it is very common when delivering content to mobile devices clients to vary the details of the markup, format of images, image sizes, color depths and so on to suit the characteristics of the device 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 content adaptation .
We do not describe The remainder of this section briefly describes content adaptation in detail 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, group - the Device Descriptions Working Group , Group, is currently defining requirements for a repository of mobile device client characteristics that are relevant to content adaptation.
There are is quite a number wide spectrum of different implementation models for content adaptation. On the one hand, hand adaptation may be quite simple 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 client [DCODI] :
Server Side adaptation implies that the content is delivered by the originating content server or application.
In-Network 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.
Client Side adaptation consists of the device client accepting content and displaying it in an appropriate way for its characteristics. Whatever the adaptation model at work, appropriately to the process of adaptation should not diminish accessibility. device's characteristics.
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 around granting of 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 adaptation adaptations - i.e. the possibility that adaptation can be applied at in more than one point place, and that In-Network 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 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.5 Establishing Context Providing variations on the user experience that are appropriate in different cases requires the content provider to know 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 contexts the need for such information is diminished when compared with a sophisticated site that has an optimized navigation structure, presents different size images or carries out other adaptations to suit the particular delivery context. There are several methods by which a content provider can discover information about the delivery context, such as CC/PP, UAPROF, CSS Media Queries and various outputs of the Device Independence Working Group . The companion Techniques [Techniques] document describes these methods. 3.6 Choice of User ExperienceIn 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 order to override determine the automatic determination. Where a choice of presentations is available, appropriate adaptation it is good practice necessary to record determine the user's preferences and to allow them to be changed. Given an appropriate server environment, it is unlikely device that is accessing the content provider will be unable service. Sometimes it is not possible to find out anything about determine the delivery context. However this can happen, device type, either because details of the delivery context are device does not available present this information to the server at all, or in sufficient detail 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).
In order to allow content providers to share a consistent view of a default mobile experience the BPWG has defined the Default Delivery Context (see 3.7 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 these cases 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 content provider 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 expected to provide an experience that exploits the capabilities of assume the Default Delivery Context default delivery context, as discussed in order to provide the best possible experience for that context. Introduction to this document.
If an adaptation process is used, then information that is known about In the Delivery Context should (see 5.1.2 Exploit Client Capabilities ) be used to vary following section 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: Best Practices are organized under the following headings:
UTF-8 [UTF-8] Best Practice Statements that refer primarily to the process by which content is created.
JPEG GIF 89a (non-interlaced, non-transparent, non-animated). This section contains statements that relate to navigation and linking mechanisms.
Web safe. (A Web safe color is one The section contains statements that has Red/Green/Blue components chosen only from relate to the values 0, 51, 102, 153, 204, content of pages and 255.) how they lay out.
External CSS Level 1 [CSS] . Statements that relate to the technical construction of pages.
HTTP/1.0 [HTTP1.0] or more recent [HTTP1.1] . Statements that relate to Input.
The functional area that is addressed by the statements.
One or more Best Practice best practice statements, identified in the following way:
[EXAMPLE] This is a Best Practice 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).
An explanation of the significance of the statements under this heading.
A discussion of techniques and some suggestions as to how to implement. The BPWG is creating intends to create a separate document describing techniques [Techniques] in more detail.
The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. Statements. This section is not present for process related statements.
In this section it is noted whether the statement is is:
Automated testing is possible) or possible.
Testing requires human assessment). Some Best Practices are partially assessment.
Based on the result of an automated test, 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 in the preceding text.
There are some general principles that underlie delivery to mobile devices.
[CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that content provided by accessing a URI yields takes place for any instance of an access to a thematically coherent experience when accessed from different devices. resource.
This is a realization Many of the One Web (see 3.1 One Web ) principle, whereby best practice statements refer to the content should be accessible on provider knowing a range significant amount about the characteristics of devices irrespective the device, the properties of differences the browser in presentation capabilities use and access mechanism. Web sites may paginate their content in various ways corresponding to differences in device characteristics; therefore the navigation structure transparency of the site, and possibly its technical realization, may vary according network connection to the device class device. For simple sites that present an interface which is being served. (See also [WebArch] Section 3.5.1 ). 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.
A bookmark captured on one device 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 usable on another, different type provided. The details of device even if it does the default experience depend upon a number of factors including, but not yield exactly limited to, the same experience. If geographic region in which the page that was bookmarked service is not appropriate for offered and the device that is now using it, an alternative that primary intention of the service (e.g. considering whether the service is suitable 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 provided. assumed in creating that presentation.
URIs The content provider may be decorated choose, in the interests of "One Web" considerations, to provide session or other information. If a URI is decorated with session information that is no longer current, then allow the user should be directed to a point in select the navigation hierarchy that is appropriate to their device, experience from broad categories such as mobile or desktop, where these presentations are distinguished in order the application.
[CAPABILITIES] Exploit device capabilities. Do not take a least common denominator approach.
While encouraging content providers to be sensitive to the needs of the Default Delivery Context, default delivery context, it is not intended that this will result 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 default delivery context when a better user experience could be attained on more capable devices.
[DEFICIENCIES] Take reasonable steps to work around deficient implementations.
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. By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation. Because the software in mobile devices is frequently embedded in the device, device there is no easy way to correct or enhance it 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 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. best practices.
Just as it is not the intention to recommend a least common denominator approach, neither is it is not the intention to recommend avoiding 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 device client types. Content providers should aim to support as wide a range of device client types as is practical.
[TESTING] Carry out testing on actual devices as well as emulators.
Any Web 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.
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 and specific software versions as is practical.
Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile devices, clients, care should be exercised in defining the structure and the navigation model of a Web web site.
[URIS] Keep the URIs of site entry points short.
Typing URIs on mobile devices can be difficult, and it is expected that users will prefer to use alternative methods of obtaining URIs when available - such as following a hyperlink (from an e-mail, SMS or other Web page), WAP Push, 2D bar code, color bar code, RFID tag and Bluetooth. However, typing a URI may in some cases be the only option available. By so keeping site entry point URIs short it is possible to can reduce the chance of error and provide a more satisfactory user experience.
When accessing site entry points users The user should not have to enter a filename as part of the URI. If possible, configure Web sites so that they can be accessed without having to specify a sub-domain as part of the URI. Example: Instead of requiring users need to type the default page filename.
"http://www.example.org/index.html" allow "http://example.org" and instead of "www.example.org/example.html" allow "example.org/example"[NAVBAR] Provide only minimal navigation at the top of the page.
Provide Two or three links should be enough to provide the basic navigation, which 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. It is important the users should be able to see page content once the page has loaded without scrolling (see 5.3.4 Navigation Bars etc. (Extraneous material) ).
[BALANCE] Take into account Design the trade-off between having too many links on service with a page and asking the user to follow too many broadly balanced navigation tree where numbers of links to reach what they are looking for. on pages is balanced against depth of navigation.
The design should aim to provide a balance between having a large an excessive number of navigation links on a page and the need to navigate multiple links to reach content. Scrolling a page when there are many links on it can be very cumbersome, as the scrolling action on many mobile devices selects each link in turn. On the other hand, each 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.
Design the service so[THEMATIC_CONSISTENCY] Ensure that frequently links provide a thematically coherent experience when accessed information from a device other than the one on which they were captured.
This is easily reached with a minimum number realization of page retrievals. Navigation 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 less frequently accessed information differences in device characteristics; therefore the navigation structure of the site, and possibly its technical realization, may take more retrievals as a result. A guideline is vary according to the device class that users become frustrated is being served.
A bookmark captured on one device should be usable on another different type of device even if it takes more than four retrievals to reach their objective. Whether this can 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 achieved depends on provided.
In addition, URIs may be decorated to provide session or other information.
If the nature of URI is decorated with session information that is no longer current then the site and, user should be directed to a point in particular, how items the navigation hierarchy that is appropriate to their device, in menus group together order to provide understandable themes. establish appropriate session and other parameters.
[NAVIGATION] Provide consistent Use navigation mechanisms. mechanisms in a consistent manner.
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.
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 drill down navigation an "up" link should be provided to allow the user to jump up an entire section.
[ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.
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 link, and avoid navigating to the link by repeated pressing of the navigation key. 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.
[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.
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 [in bytes or in an abstract way, e.g. way e.g., large file). file].
Links to content that is in a different format to that the format of the page the link is on (i.e. content that can only be interpreted by other applications or applications, downloads) should be human signposted, so that users are not lead to download content that their device may not be able to use. However, bear in mind that some devices support the rendering of those formats by other applications once downloaded (e.g. music files). Additionally, users may wish to download content for later transfer to other devices altogether. So even if it is known that the user agent does not support a particular content type, that content should still be made available.
Human Test: Check for proper descriptions (e.g. (and no use of "Click here").
Human and Machine Test: Check for Spider the page/web site to find links to non-HTML formats. Human Test: If present formats and check whether there is information about the format of the target of the link.
[IMAGE_MAPS] Do not use image maps unless you know the target client supports them effectively. 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.
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 and right, enter are available on most mobile devices, even if there is no pointing device. This device is present, and this is usually sufficient to allow navigation of the active regions of client-side image maps where they are defined as geometric shapes. Many mobile devices lack a pointing device and server-side client side image maps cannot be used on such devices. maps.
If only small images can be displayed, break larger images up into smaller sections and deal with them separately.
For the Default Delivery Context , or if If a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.
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.
[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.
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, consequently attempting to open one will have unpredictable results.
Auto-refreshing Auto refreshing pages are widely recognized as presenting accessibility problems. In problems, and in a mobile environment they may expose the user to undue cost as a result of such a an auto refreshing page being left open open, or put unnoticed into the background. If an auto-refreshing auto refreshing page is demanded by the application, 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 higher 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; so use links, hence redirection should not be used as a maximum of one redirect per page and limit the number matter of pages that are redirected. course.
POP_UPS
Machine
Test:
Look
for
the
target
attribute
on
links.
AUTO_REFRESH
Machine
Test:
Check
whether
meta
http-equiv="refresh"
content="<the
content="
the
same
URI>"
URI
"
is
used.
AUTO_REFRESH Human Test: If auto-refresh 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
content="
a
different
URI>"
URI
"
is
used.
This relates to WCAG 7.4 , 7.4, 7.5 and 10.1 . 5.2.9 Externally Linked Resources [EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum. 5.2.9.1 What it means Each linked resource (images, style sheets and other objects) requires a separate request across the network. This may add significantly to the load time of the page in the mobile context. 5.2.9.2 How to do it Minimize the number of images on a page and consolidate style information into a single sheet per page (see also 5.4.9 Style Sheets ). 5.2.9.3 What to test Machine Test: Count the number of linked images, style sheets and other linked items. Human Test: Review whether a similar effect could be obtained using fewer links.
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 .
[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.
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, 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 for in the mobile delivery, 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. 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 In many cases the user pays for bandwidth, so bandwidth in the mobile context, and offering them 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.
[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. device and other device and delivery channel characteristics if they can be determined.
If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions on 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, 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.
PAGE_SIZE_USABLE Machine Test: Measure the total size of the markup for a page; check Check that it does not exceed the allowable size for the device - page doesn't exceed 10 kilobytes KBytes for the Default Delivery Context. 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 markup mark-up and images for a page; check that it does not doesn't go over the allowed size for the device - 20 kilobytes KBytes for the Default Delivery Context. default delivery context.
[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.
The page should lay out so that simple repeated scrolling in the same direction (axis) 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.
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.
In the Default Delivery Context assume a width of 120 pixels.
SCROLLING
Machine
Test:
Check
for
width
attributes
and
width
style
properties
wider
than
the
screen
size
-
for
the
Default
Delivery
Context,
default
delivery
context,
120
pixels.
Human Test: If it is wider than the screen size, 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 on pages with elements that require secondary scrolling scrolling, only those elements require it, it and the rest of the page requires only primary scrolling.
[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.
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 and 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.
See also 5.3.1 Page Content for a discussion of how writing style can help the user identify meaning.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 web site.
[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.
The popular mechanism of using a 1 pixel graphic for absolute positioning is does not work on a variety of screens.
Graphics that are larger than necessary, for example by having possessing a higher resolution than is displayable on the device or by having too many colors, waste bandwidth.
[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.
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.
[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.
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. If you use a background image ensure that the content is readable with and without the background image for devices that do not support them.
BACKGROUND_IMAGE_SUPPORT
Machine
Test:
Test
for
Send
a
request
to
the
presence
of
site
with
a
user
agent
that
does
not
support
background
image.
images
and
check
the
background
attribute
is
not
present.
BACKGROUND_IMAGE_READABILITY Human Test: Test readability both on devices that support them and devices that do not. readability.
[PAGE_TITLE] Provide a short but descriptive page title.
Provide a descriptive title for the page to allow easy identification. Keep the title as short as is possible to reduce page weight, 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, Again space may be limited, limited so use it to help identify the content and not for other purposes.
[NO_FRAMES] Do not use frames.
Many mobile clients do not support frames. In addition, frames are recognized as being generally problematic.
Machine
Test:
Test
for
presence
of
frame
related
elements
-
in
HTML
check
for
frameset
and
iframe
elements.
See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.
[STRUCTURE] Use features of Ensure that perceivable structures within the markup language to indicate logical document structure. content can be programmatically determined.
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, pages as well as potentially facilitating access only to the sections of the document that a user is interested in.
Where headings 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 (see also 5.4.3 Structural Elements ). effect.
[TABLES_SUPPORT] Do not use tables unless the client is known to support them. [TABLES_NESTED] Do not use nested multi-layer tables.
[TABLES_LAYOUT] Do not use tables for layout.
[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.
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.
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.
Machine Test: If there is a table element, check to see whether there is rendered content outside the element. If there is not then it is likely that the table is being used for layout.[NON-TEXT_ALTERNATIVES] Provide a text equivalent textual alternatives for every non-text element. elements.
[OBJECTS_OR_SCRIPT] Do not rely on embedded embed objects or script. script in pages unless you know the device supports them.
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 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.
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.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.
If scripting is used, do not use onmouse and onkey triggers, use onclick . For the Default Delivery Context do not use scripting and do not embed objects.
NON-TEXT_ALTERNATIVES
Machine
Test:
Test
for
presence
of
alt
attribute
on
images
and
text
content
on
objects.
Human
Test:
Check
the
relevance
of
the
meaning
of
the
content
of
alt
attributes.
attributes
with
their
elements.
OBJECTS_OR_SCRIPT
Machine
Test:
Test
for
the
presence
of
object
or
script
elements
in
content
delivered
Send
a
request
to
the
site
with
a
device
user
agent
that
does
not
support
them.
scripts
and
check
the
script
element
is
not
present.
Human
Machine
Test:
If
present,
test
that
Send
a
request
to
the
site
with
a
user
experience
agent
that
does
not
support
objects
and
check
the
object
element
is
acceptable.
not
present.
[IMAGES_SPECIFY_SIZE] Specify Always specify the size of images in markup, if they have an intrinsic size. markup.
[IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size. server.
Images such as bitmaps have an intrinsic size. Telling the browser in advance what the size is avoids it having to re-flow the page when it receives it. Resizing images at the server reduces 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.
Note that this recommendation contrasts with 5.4.8 Measures , which recommends using relative measures where possible.[VALID_MARKUP] Create documents that validate to published formal grammars.
If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.
[MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.
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 page, and avoid re-flowing it after the page has been retrieved. Devices may realize the intentions of authors more accurately if margins, borders and padding are specified in pixels.
[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 small. as small as possible.
Style information may be contained in an externally linked style sheet or, in HTML, may be contained either in a style element or in a style attribute on specific elements. Mobile Devices offer varying Clients provide several levels of support for style sheets. Some provide full implementations, implementations including caching of external style sheets; some sheets. Some do not cache external style sheets; some do not support sheets, and for these devices embedding the style element; some implementations do not support information in the delivered page is more efficient than one the browser making repeated retrievals for the style sheet and some across a site. Some implementations do not support style sheets at all.
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 ). font).
STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and check 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.
[MINIMIZE] Use terse, terse efficient markup.
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
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
(see
also
5.4.9
Style
Sheets
).
style.
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" (the "Pretty Printing", i.e. the formatting of markup mark-up with indentation) 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, 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 (see 5.4.3 Structural Elements ) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS [CSS] . CSS.
[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.
[CONTENT_FORMAT_PREFERRED] Where possible, possible send content in a client's preferred format.
Transferring content that a device client cannot display wastes users' time and money. A device Preference may express be expressed by a preference client for formats. one format rather than another. In this case it is good practice to respect the client's preference, preference as it may have a fuller implementation of those formats. its preferred markup.
To determine what formats a device supports, Web 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:
Some Not all devices do not 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 to include as they adapt content presented in formats that they adapt; the device does not accept;
User agent Agent headers do not always uniquely identify the device;
UAProf information may not be available or may be incomplete.
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. default delivery context.
[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.
As in the previous section, content should not be sent to a device if it can not use it.
The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header. 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 [XML] documents the character encoding may be indicated in the encoding declaration, 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 web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] [HTTP_CHARSET] and [CHARSET2] . 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. All applications should support UTF-8.
Machine Test: Check that the Content-Type HTTP header contains the encoding is declared in some way and that this encoding is supported. The content type may be declared in one or more of the following ways: The Content-Type HTTP header, supported (may also need to check the XML declaration for XML-based content, content and the CSS @charset rules for CSS, the Content-Type Meta element for HTML content. 5.4.12.4 References See [XML] Character Encoding in Entities for a discussion of character encoding in XML documents. CSS).
[ERROR_MESSAGES] Provide informative error messages messages, and a means of navigating away from an error message back to useful information.
It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought. 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 difficult. 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, 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 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.
It is noted that many Web web servers provide a default error page, 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 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 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.
Enter an extraneous URI, known not to represent an actual resource on the site, and check that a HTTP 404 error response is accompanied by a page whose markup is appropriate for the requesting device, or the default context.
Human Test: Check that the page returned contains an explanation of the error and appropriate corrective actions, without assuming any technical knowledge on the part of the end user.
[COOKIES] Do not rely on use cookies being available. unless you know the device supports them.
Cookies are frequently used both to carry out session management, to identify users management and to store capture user preferences. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies and others simulate cookies on behalf of mobile devices. cookies.
Test that Use cookies if they are known to be supported by the device on its the device's current access path. If they are not supported, use URI decoration for session management, decoration, being careful not to exceed the device's maximum length for such strings. Some gateways provide user identification without setting cookies.
[CACHING] Provide Attach caching information in HTTP responses. to the content.
Limited Since a low bandwidth and a high latency can reduce the usability of a Web sites site on a mobile devices. Using device, it is most useful to provide enough caching information effectively can reduce to the user agent so that it does not need to reload data such as (e.g. style sheets, images and pages, thus improving performance and reducing cost of use. It can also prevent the reuse of content where this is not appropriate, for example content images) that is adapted for one device should not be re-used by different devices. User agents and network caches are both affected by caching information. already available locally.
5.4.15.2 How to do itSet expiry times in The HTTP protocol provides a way well-defined framework for this caching mechanism that is appropriate to your application. Consider using Cache-Control: public to allow sharing of pages between devices, Cache-Control: private to allow re-use but can only by be optimally used if the requesting user agent and Cache-Control: nocache to prevent caching. The HTTP 1.1 specification [HTTP1.1] and Techniques document [Techniques] contain discussions of caching. delivered content provides enough information (e.g. an ETag header).
Machine Test: Check for the presence of cache headers on the HTTP response.
This section contains statements relating to user input. This User input is typically more restrictive on mobile devices than on desktop computers (and often or a lot more restrictive). For example, mobile devices restrictive on Mobile devices, which may lack pointing devices and often usually do not have a standard keyboard for text entry. with which to enter text.
[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 target device is known to support it.
Given the typical input limitations of a mobile device, device the interface must as far as possible minimize user input. Where possible, use selection lists, radio buttons boxes and other controls user interface artifacts that do not require typing.
Some markup languages allow the specification of an input mode, which is particularly useful in cases where user input is to be restricted, for example to numeric only. It is anticipated that XHTML-Basic [XHTML-Basic] XHTML basic will support this functionality in the future.
Specification of the natural language in use assists with predictive text input.
There are a number of techniques available for this, this including:
Where possible use previous entries as defaults.
Make it possible to select items using navigation keys and/or numeric input.
AVOID_FREE_TEXT
Machine
Test:
Check
whether
input
type="text"
and
textarea
are
used.
Human Test: If one of them is used, check whether it can be replaced by a pre-determined entry.
PROVIDE_DEFAULTS Machine Test: Check if there is a pre-selected value in controls (selected or checked attribute set).
Human Test: If not, check if there could be sensible pre-selection in the context (e.g. most common choice).
DEFAULT_INPUT_MODE
Machine
Test:
Send
a
request
with
a
user
agent
known
to
support
the
inputmode
attribute,
attribute
and
if
the
response
is
in
a
language
that
supports
this
attribute,
check
that
it
is
present
on
input
type="text"
and
textarea
elements.
[TAB_ORDER] Create a logical tab order through links, form controls and objects.
It is important that as the user navigates through the page the various fields and objects are presented in a logical order, especially as many of them will not be visible at the same time as the focus item.
Use This should normally come from the basic structure of a document order to control layout and tab order. in a format like HTML.
Machine
Test:
Check
that
there
are
no
tabindex
input
attributes
or
layout
effects
that
affect
and
a
elements
use
the
order
of
presentation.
If
there
are
tabindex
attributes
check
that
all
controls
have
a
tab
index
and
that
they
are
used
consistently.
attribute.
Human Test: If there are either tabindex attributes or layout effects that might affect not, check whether the link order matches the needs of presentation, then check that the order is usable. user.
[CONTROL_LABELLING] Label all controls appropriately and explicitly appropriately. Explicitly associate labels with controls. [CONTROL_POSITION] controls where the device supports this. Position labels so they lay out properly in relation relative to the controls they refer to. appropriately.
This
means
use
the
label
element
in
HTML,
or
its
equivalent
in
other
languages.
Make
sure
that
where
the
label
goes
is
consistent
and
close
to
the
control
so
re-flowing
or
adapting
the
content
intelligently
will
always
recognize
label
controls
and
keep
them
together.
The Best Practice statements Statements are intended to be capable of having conformance statements constructed around them 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 best practices document.
All of the Best Practice statements Statements have a fragment identifier to allow formal reference to them and allow the construction of compliance claims that refer to them.
The Best Practice best practice statements have been assembled by the BPWG from a number of sources. Primary among those are:
Various BPWG group meetings and discussions
WCAG Guidelines 1.0 [WCAG]
iMode Guidelines [iMode]
Opera's "Making Small Devices Device Look Great" [Opera]
Openwave Guidelines [OpenWave]
Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP]
Browsing on Mobile Phones, Nokia [Nokia-VR]
Little Spring Design [LSD]
Sprint PCS Web Style Guide [Sprint]
While the Best Practice 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.
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: