1
Introduction
1.1
Purpose
of
the
Document
The
This
document
contains
sets
out
a
list
series
of
recommendations
designed
to
promote
more
effective
delivery
of
best
practices
and
discussion
around
the
assertions
made
for
content
on
the
Web
so
that
it
is
delivered
effectively
content
to
mobile
devices.
It
also
contains
information
about
how
to
implement
sites
that
conform
to
those
best
practices.
The
document
Each
recommendation
is
intended
to
provide
guidance
discussed
in
context
and
brief
explanatory
notes
are
provided.
The
recommendations
are
offered
to
players
all
participants
in
the
mobile
value
chain
as
to
best
practices
for
production
of
web
sites
and
of
Web
content
intended
for
delivery
to
mobile
devices.
It
is
also
are
intended
as
the
basis
for
assessing
conformance
to
the
requirements
of
the
MobileOK
mobileOK
trustmark.
The
idea
for
the
MobileOK
mobileOK
trustmark
is
described
in
the
Mobile
Web
Best
Practices
Working
Group
Charter
We
do
and
is
not
develop
the
idea
of
mobileOK
developed
in
this
revision
of
this
document.
Future
revisions
may
contain
a
discussion
of
mobileOK.
mobileOK
and
techniques
for
implementing
the
Best
Practice
recommendations
will
be
discussed
in
companion
documents.
1.2
Audience
As
mentioned
above
the
document
is
targeted
at
players
in
the
mobile
value
chain,
as
described
below.
Readers
of
this
document
are
expected
to
be
familiar
with
creation
of
Web
sites,
and
have
a
general
familiarity
with
the
technologies
involved,
such
as
web
servers
and
http.
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.
The
group
solicits
public
feedback
as
to
the
usability
of
the
document
by
Web
professionals
that
are
not
technology
specialists.
1.2.1
Players
Participants
in
the
Mobile
Value
Chain
Players
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
browsing
and
extension
of
the
Web
web
browsing
experience
to
be
more
usable
on
onto
mobile
devices.
The
charter
As
the
goal
of
the
group
document
is
to
specify
best
practices
Best
Practices
for
delivery
to
mobile
devices.
Hence
best
practice
devices,
statements
that
do
not
specifically
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]
the
there
are
many
aspects
to
Mobile
Web
Best
Practices.
One
of
those
aspects
is
that,
For
example,
at
present,
the
design
and
construction
of
many
Web
sites
and
pages
make
for
a
poor
user
experience
when
those
sites
and
pages
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
voice
browsing.
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.
We
define
these
three
aspects
as
follows:
Site
usability
relates
to
the
structure,
content
and
layout
rules
of
a
site
and
is
a
measure
of
the
effectiveness
of
the
mobile
web
site.
Device
usability
pertains
to
the
capability
of
the
equipment
being
used
easily
and
effectively.
"Easily"
refers
to
a
specified
level
of
acceptability
and
comfort
of
use;
"Efficiency"
relates
to
the
resources
expended
in
relation
to
the
accuracy
and
completeness
with
which
users
achieve
their
goals.
In
particular,
device
usability
focuses
on
keypad
design,
display,
fast
browser
access
and
UI
styles.
Browser
usability
defines
the
ease
of
using
a
browser
effectively
namely
performing
the
three
functions
reading,
navigating
or
interacting.
The
ease
of
interaction,
page
rendering,
caching
etc.
are
issues
that
are
frequently
used
to
judge
browser
usability.
While
recognizing
the
contribution
of
device
and
browser
usability
to
the
overall
user
experience,
this
document
focuses
on
site
usability.
1.3.3
Boundaries
of
the
Best
Practice
Guidelines
One
Web
This
section
describes
what
the
Best
Practices
are
trying
to
achieve,
and
what
they
are
not.
1.3.3.1
A
Reasonable
User
Experience
The
MWI
recommendations
in
this
phase
[See
Phasing
]
is
concerned
with
establishing
a
set
of
guidelines
that
help
content
providers
achieve
the
best
possible
document
are
intended
to
improve
mobile
experience
of
their
the
Web
content
-
given
on
mobile
devices.
While
the
client
and
network
limitations
that
are
encountered
recommendations
in
this
document
are
not
specifically
addressed
at
the
mobile
delivery
of
Web
content
[see
Requirements
for
a
discussion
of
these].
A
reasonable
desktop
browsing
experience
of
the
Web
cannot
it
must
be
achieved
on
clients
understood
that
exhibit
too
many
of
they
are
made
in
the
limitations
discussed
or
where
one
or
other
context
of
the
limitations
is
very
severe.
wishing
to
work
towards
'One
Web'.
In
saying
this
it
is
recognized
that
any
judgment
of
what
is
a
reasonable
experience
is
made
at
a
particular
point
As
discussed
in
time
and
from
particular
cultural
perspective.
It
is
also
recognized
that
it
[Scope]
One
Web
means
making,
as
far
as
is
possible
reasonable,
the
same
information
and
services
available
to
achieve
a
reasonable
experience
users
irrespective
of
non-Web
services
in
the
presence
of
such
limitations
and
that
that
there
device
they
are
at
present
many
such
services,
often
implemented
using
WAP
1.x
technologies.
The
intention,
however,
of
using.
However
it
does
not
mean
that
exactly
the
Mobile
Web
Initiative,
same
information
is
to
extend
the
reach
of
available
in
exactly
the
Web
to
mobile
same
way
across
all
devices.
Hence
such
non
Web
Some
services
and
information
are
out
of
scope
of
this
discussion.
more
suitable
for
and
targeted
at
particular
user
contexts.
1.3.3.2
The
Idea
of
a
Baseline
Client
To
be
clear
about
the
level
of
functionality
(or
absence
of
limitation)
that
is
targeted
for
Some
services
have
a
reasonable
primarily
mobile
experience
of
the
Web
we
define
the
notion
of
appeal
(location
based
services,
for
example).
Some
have
a
baseline
client.
By
establishing
primarily
mobile
appeal
but
have
a
baseline
definition,
is
it
possible
to
provide
guidance
as
to
what
an
implementation
should
do
if
it
cannot
determine
whether
complementary
desktop
aspect
(perhaps
for
complex
configuration
tasks).
Still
others
have
a
client
accessing
the
service
supports
features
that
meet
or
exceed
the
baseline
definition.
In
short,
it
should
assume
the
client
provides
baseline
support.
As
such
the
notion
of
primarily
desktop
appeal
but
a
baseline
client
should
be
seen
as
guidance
on
the
limitations
of
pages
that
are
delivered
by
an
implementation,
rather
than
the
specification
of
complementary
mobile
aspect
(possibly
for
alerting).
Finally
there
will
remain
some
Web
applications
which
have
a
device.
primarily
desktop
appeal
(lengthy
reference
material,
rich
images,
perhaps).
1.3.3.3
Least
Common
Denominator
It
is
not
the
intention
likely
that
application
designers
and
service
providers
will
wish
to
encourage
Least
Common
Denominator
Implementations.
The
best
practice
recommendations
actively
encourage
provide
the
best
possible
support
of
the
baseline
client
as
well
as
exploitation
of
features
that
go
beyond
the
baseline
so
far
as
those
features
refer
to
experience
in
the
Phase
1
scope
(Web
Browsing).
1.3.3.4
What
is
a
Mobile
Client?
While
it
is
out
of
scope
of
context
in
which
their
service
has
the
best
practices
to
consider
non-mobile
delivery,
it
must
most
appeal.
However,
while
services
may
be
understood
that
there
is
no
clear
dividing
line
most
appropriately
experienced
in
one
context
or
categorization
that
makes
mobile
and
non
mobile
clients
distinct.
Rather,
as
mentioned
above,
that
non-mobile
clients
tend
to
suffer
fewer
of
the
limitations
that
are
characteristic
of
mobile
ones.
Any
particular
client
can
be
another,
it
is
considered
best
practice
to
be
in
provide
a
scale
between
suffering
all
reasonable
experience
irrespective
of
the
limitations
discussed
device,
and
suffering
none
of
them.
In
addition,
for
as
far
as
is
possible,
not
to
exclude
access
from
any
particular
client,
the
limitations
may
not
apply
equally
at
different
times.
class
of
devices.
1.3.3.5
Which
Formats
are
in
Scope?
Similarly
to
the
[WCAG]
From
the
best
practice
recommendations
are
couched
at
a
level
perspective
of
generality
this
document
this
means
that
allows
them
to
services
should
be
applied
to
a
wide
range
of
markup
languages.
The
intention
being
that
as
well
as
being
applicable
to
current
Web
standards
(especially
XHTML),
they
are
also
applicable
to
existing
and
legacy
non-Web
recommendations,
such
as
cHTML
and
WML,
as
well
as
future
standards,
such
available
as
[CDFWG]
.
some
variant
of
HTML
over
HTTP.
1.3.3.6
Real-World
Coverage
of
Best
Practices
It
is
recognized
that
many
devices
in
daily
use
do
not
qualify
as
baseline
clients.
While
the
best
practices
do
not
target
such
clients,
they
do
not
discourage
implementations
from
supporting
them.
1.4
Default
Delivery
Context
Baseline
conformant
devices
have
been
available
for
some
years,
and
are
in
common
use
in
many
markets.
The
recommendations
encourage
refer
to
delivered
content.
Given
the
use
range
of
features
that
go
beyond
the
baseline,
that
different
mobile
device
types
which
have
been
different
properties
and
will
continue
to
be
introduced
in
new
devices.
However,
since
different
features
the
MWI
Phase
1
refers
only
to
'traditional'
browsing
it
does
not
establish
best
practices
for
those
features.
Best
Practices
Working
Group
has
defined
a
Default
Delivery
Context
.
1.3.3.7
Evolution
of
Baseline
Definition
As
time
moves
on
it
is
likely
that
both
the
definition
of
a
baseline
device
and
the
best
practice
recommendations
will
change.
It
Delivery
Context
is
anticipated
that
the
best
practice
recommendations
will
change
at
a
slower
pace
than
used
with
the
definition
of
specific
meaning
defined
in
the
baseline
device.
Device
Independence
Glossary
[DIGLOSS]
.
As
mentioned
above,
the
definition
of
a
baseline
device
is
with
The
document
makes
reference
to
a
notion
of
a
reasonable
Web
experience.
Any
future
change
in
the
baseline
device
specification
will
need
to
take
into
account
both
the
ongoing
development
of
the
non-Mobile
Web
experience
and
the
availability
of
devices
that
exceed
the
current
baseline.
It
is
understood
that
the
capabilities
of
devices
differs
markedly
Default
Delivery
Context
in
different
regions
of
the
world,
with
more
developed
economies
having
access
to
a
wider
range
of
more
fully
featured
clients.
two
ways:
-
1.3.3.8
Implementation
Issues
The
notion
of
a
baseline
client
is
an
abstract
notion.
No
specific
real
device
is
targeted.
Rather,
it
is
an
abstraction
of
If
the
characteristics
of
a
range
of
currently
popular
devices
that
have
been
available
for
some
years.
The
abstraction
assumes
complete
and
defect
free
implementation
of
delivered
content
does
not
result
from
an
adaptation
process
-
e.g.
the
features
described.
It
is
considered
good
practice
to
work
around
implementation
defects
of
real
devices.
However,
it
content
is
not
statically
defined
as
HTML
stored
in
scope
of
best
practices
to
itemize
known
defects
and
limitations
nor
to
detail
techniques
or
examples
of
how
to
do
this.
See
[]
files
-
then
the
delivered
content
should
be
suitable
for
references
as
to
known
device
the
Default
Delivery
Context
and
client
limitations.
should
comply
with
the
Best
Practice
Statements.
-
1.3.3.9
Best
Practices
refer
to
Server
Implementations
not
Clients
The
recommendations
refer
to
the
behavior
of
implementations
in
providing
a
service,
and
in
this
phase
do
not
refer
to
the
behavior
of
clients.
It
If
an
adaptation
process
is
hoped
used,
then
information
that
by
providing
a
baseline
definition
creators
of
devices
and
clients
will
it
known
about
the
Delivery
Context
can
be
encouraged
used
to
produce
devices
that
meet
or
exceed
vary
the
baseline
definition.
It
is
also
hoped
delivered
content
to
make
it
more
suitable
for
that
those
commissioning
Delivery
Context
or
setting
standards
for
such
devices
will
require
implementation
of
baseline
features
to
a
reasonable
standard
of
completeness
and
quality.
provide
an
enhanced
user
experience.
1.4
Baseline
Client
The
group
requests
public
comment
on
the
specification
of
the
baseline
device
given
the
comments
in
the
previous
section,
that
the
purpose
of
the
baseline
specification
is
to
inform
what
implementations
can
assume
to
be
the
minimum
level
of
support
that
they
must
take
account
of,
and
what
assumptions
they
may
make
in
the
absence
of
any
other
information
.
In
addition
to
discussing
the
baseline
client
the
group
has
also
discussed
the
idea
of
a
default
client.
The
idea
being
that
for
any
particular
application
or
geographic
region,
it
may
be
known
that
the
majority
of
devices
are
of
a
particular
type
or
support
particular
features.
In
this
case
the
notion
of
the
'global'
baseline
device
delivery
context
is
supplemented
by
a
'local'
default
device,
which
may
have
either
greater
or
lesser
functionality
when
compared
with
the
baseline.
defined
as
follows:
The
group
would
value
feedback
both
on
which
parameters
are
to
be
specified
and
what
the
values
for
those
parameters
should
be.
-
Usable
Screen
Width
The
following
are
for
illustration
only.
-
120
Pixels.
-
Format
Mark
Up
Language
Support
-
For
the
purposes
of
delivering
The
Web,
this
is
assumed
to
be
a
version
of
XHTML
-
probably
aligned
with
XHTML-MP.
Some
opinion
states
that
WML
should
be
assumed.
http
delivery
is
assumed.
There
is
a
further
variation
in
views
as
to
what
image
format
a
web
site
should
assume
a
client
supports.
It
may
be
that
it
should
be
assumed
that
there
is
no
compatible
image
support.
Basic
Profile.
-
Usable
Screen
Size
Character
Encoding
-
People
have
strong,
but
divergent
opinions
on
this.
The
absolute
minimum
being
96
x
96
pixels.
Strong
support
is
expressed
for
128
x
128,
however
a
vocal
group
supports
bigger
still.
Some
opinions
support
the
notion
that
a
minimum
row
and
column
availability
for
text
presentation
needs
to
be
specified.
UTF-8.
-
Colors
Image
Format
Support
-
Varying
opinions
again
on
this.
JPEG
GIF
89a
(non-interlaced,
non-transparent,
non-animated).
-
Maximum
Total
Page
Weight
-
It
is
important
to
understand
the
limitations
of
memory
so
that
Web
sites
do
not
try
to
deliver
pages
that
are
too
big.
However
it
is
not
clear
how
this
should
take
into
account
the
combined
weight
of
markup
and
images.
Suggestions
vary
from
10k
bytes
upwards.
20k
Bytes.
-
Other
Colors
-
Many
other
candidate
parameters
have
been
suggested,
including
cpu
power,
Back
/
Forward
navigation
in
history,
text
entry
(which
character
sets?),
form
controls,
SSL
1/2,
Javascript
...
Web
safe.
-
Style
Sheet
Support
1.5
Compliance
-
The
document
does
not
have
a
compliance
model.
The
Best
Practice
Recommendations
represent
suggestions
as
to
the
behavior
of
Web
sites.
Any
use
External
CSS
Level
1,
with
internal
definition
of
the
words
must
,
should
style
and
may
should
not
be
interpreted
as
having
the
meanings
defined
in
RFC2119.
font
properties.
The
Best
Practice
statements
are
intended
to
be
capable
of
later
having
conformance
statements
constructed
around
them,
in
support
of
the
mobileOK
trustmark
and
for
other
purposes.
1.6
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.
The
work
This
document
builds
on
some
of
the
concepts
described
by
the
Device
Independence
Working
Group
[DIWG]
(DIWG)
in
the
Device
Independence
Principles
[DIP]
.
The
document
also
discusses
the
notion
of
device
characteristics,
which
DIWG
has
described
in
terms
of
a
direct
and
fundamental
relevance
to
this
document.
"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.
2
1.6
How
the
Best
Practices
are
Organized
The
document
is
organized
as
follows:
Introduction
-
Introduction.
Describes
the
audience,
purpose
and
scope
of
the
document.
Organization
This
section,
explains
the
format
of
the
document.
Requirements
-
Requirements,
An
illustration
of
the
type
of
problems
that
the
Best
Practices
are
intended
to
ameliorate.
Architecture
-
Architecture.
Discusses
the
environment
within
which
the
mobile
web
is
realized,
with
particular
reference
to
adaptation.
-
Overview
of
Best
Practices
Practices.
A
discussion
of
the
organization
of
the
best
practices,
and
sources
from
which
they
were
derived.
-
Best
Practices.
The
statements
themselves
themselves.
Techniques
-
How
to
implement
the
best
practices
[
not
present
in
this
draft
].
Conformance
and
mobileOK
Testing
for
mobileOK.
A
brief
conformance
to
statement
and
labeling
with
pointer
to
the
trust
mark
[
not
present
in
this
draft
].
mobileOK
documentation.
Annexes
-
Glossary
[
not
present
in
this
draft
]
Annexes
Acknowledgements
References
3
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.
We
discuss
the
requirements
under
two
broad
headings,
User
Experience
and
Device
Limitations;
both
contribute
to
a
poor
experience
of
the
Web
on
mobile
devices.
3.1
User
Experience
2.1
Presentation
Issues
Many
Web
pages
today
are
laid
out
with
presentation
on
desktop
size
displays
in
mind,
and
make
use
of
the
facilities
provided
by
desktop
browsing
software.
Accessing
such
a
Web
page
on
a
mobile
device
often
results
in
a
poor,
or
unusable
experience.
Contributing
to
this
poor
experience
is
that
the
content
does
not
lay
out
as
intended,
and
because
of
the
limited
screen
size
and
the
limited
amount
of
material
on
the
page
that
is
visible
to
the
user,
things
that
are
intended
to
be
viewed
together
are
not
presented
together
-
context
and
overview
are
lost.
Because
of
the
limited
screen
size
the
subject
matter
of
the
page
may
require
considerable
scrolling
to
be
visible,
especially
if
the
top
of
the
page
is
occupied
by
images
and
navigation
links.
In
these
cases
the
user
gets
no
immediate
feedback
as
to
whether
their
retrieval
has
resulted
in
the
right
content.
It
is
particularly
important
in
the
mobile
context
to
help
the
user
create
a
mental
image
of
the
site.
This
can
be
assisted
by
adopting
a
consistent
style
and
contrariwise
can
be
considerably
diminished
by
an
uneven
style.
3.2
2.2
Input
Mobile
device
input
is
often
hard
when
compared
with
use
of
a
desktop
device
equipped
with
a
keyboard.
Mobile
devices
such
as
phones
often
have
only
a
very
limited
keypad,
with
small
keys,
and
there
is
frequently
no
pointing
device.
It's
perhaps
a
paradox
One
of
the
difficulties
of
the
mobile
web
is
that
URLs
URIs
are
very
hard
to
type,
and
lengthy
URLs
URIs
and
those
that
contain
a
lot
of
punctuation
are
particularly
hard
to
type
correctly.
Bookmarking,
while
often
supported,
sometimes
does
not
achieve
the
expected
result.
Because
of
the
limitations
of
screen
and
of
input,
forms
are
hard
to
fill
in,
both
because
navigation
between
fields
may
not
occur
in
the
expected
order
and
because
of
the
difficulty
in
typing
into
the
fields.
There
is
frequently
no
While
many
modern
devices
provide
back
button,
which
buttons,
some
do
not,
and
in
some
cases,
where
back
functionality
exists,
users
may
not
be
aware
how
to
invoke
it.
This
means
that
it
is
often
very
hard
to
recover
from
errors,
broken
links
and
so
on.
3.3
2.3
Bandwidth
and
Cost
Mobile
networks
can
be
slow
compared
with
fixed
data
connections
and
often
have
a
measurably
higher
latency,
leading
to
long
retrieval
times,
especially
for
lengthy
content,
and
for
content
that
requires
a
lot
of
navigation
between
pages.
Mobile
data
transfer
often
costs
money.
The
fact
that
mobile
devices
frequently
support
only
limited
types
of
content
means
that
a
user
may
follow
a
link
and
retrieve
information
that
is
unusable
on
their
device.
Even
if
the
content
type
can
be
interpreted
by
their
device
there
is
often
an
issue
with
the
experience
not
being
satisfactory
-
for
example
larger
images
may
only
be
viewable
in
small
pieces
and
require
considerable
scrolling.
Requests
for
web
pages
can
result
in
the
delivery
of
content
that
the
user
has
not
specifically
requested
-
especially
advertising
and
large
site
images.
In
the
mobile
world
this
extra
material
contributes
to
poor
usability
and
may
add
considerably
to
the
cost
of
the
retrieval.
3.4
Content
Type
2.4
User
Goals
Mobile
users
typically
have
different
interests
to
users
of
fixed
or
desktop
devices.
Mobile
users
are
likely
to
have
more
immediate
and
goal-directed
intentions
than
desktop
web
users.
Their
intentions
are
often
to
find
out
specific
pieces
of
information
that
are
relevant
to
their
context.
Examples
frequently
include
travel
related
applications,
where
the
user
requires
specific
information
about
train
times.
Other
examples
often
include
time
filling
applications,
where
people
are
filling
otherwise
dead
time
while
traveling,
and
entertainment
related
applications
are
often
noted
as
being
appropriate.
On
the
other
hand,
mobile
users
are
typically
less
interested
in
lengthy
documents
or
in
browsing.
The
ergonomics
of
the
device
are
frequently
unsuitable
for
reading
lengthy
documents,
and
users
will
often
only
access
such
information
from
mobile
devices
as
a
last
resort,
because
more
convenient
access
is
not
available.
3.5
2.5
Advertising
Developers
of
commercial
web
sites
should
note
that
different
commercial
models
are
often
at
work
when
the
Web
is
access
accessed
from
Mobile
devices
as
compared
with
fixed
line
access,
see
[some
reference
TBD],
for
information.
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.
It's
It
is
not
the
intention
of
the
MWI
to
limit
or
to
restrict
advertising,
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.
3.6
2.6
Device
Limitations
As
noted
above,
the
restrictions
imposed
by
the
keyboard
and
the
screen
typically
require
a
different
approach
to
page
design
than
that
used
for
desktop
devices.
As
detailed
in
[Scope],
[Scope]
,
various
other
limitations
may
apply
to
mobile
devices,
and
these
have
an
impact
on
the
usability
of
the
Web
from
a
mobile
device.
Mobile
browsers
often
do
not
support
scripting
or
plug-ins,
which
means
that
the
range
of
content
that
they
support
is
limited.
In
many
cases
the
user
has
no
option
as
to
which
browser
they
should
use,
and
in
many
cases
upgrade
of
the
browser
is
not
possible.
This
creates
the
situation
that
in
order
to
support
users
of
a
popular
device,
the
limitations
or
implementation
defects
associated
with
particular
releases
need
to
be
taken
into
account
in
some
situations.
Some
activities
associated
with
rendering
web
pages
are
computationally
intensive.
Examples
are
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
diminish
battery
life.
In
any
case,
data
communication
reduces
battery
life
and
reducing
communication
can
conserve
battery.
Many
devices
have
limited
memory
available
for
pages
and
images,
and
exceeding
their
memory
limitations
results
in
incomplete
display
and
can
cause
other
problems.
3.7
2.7
Advantages
[The
group
notes
that
as
well
as
having
In
discussing
the
limitations
of
mobile
devices
also
have
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
their
being:
personal,
personalizable
portable
and
increasingly
multi-function
beyond
their
original
purpose
of
voice
communications.
Beyond
these
factors,
we
see
the
advantages
of
mobile
devices
increasingly
including:
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
compared
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
or
laptop
devices.
computer.
This
section
to
be
developed
is
likely
to
elucidate
this
point.]
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".
4
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,
on
to
suit
the
characteristics
of
the
client
in
question.
The
process
of
altering
content
in
this
way
to
enhance
the
user
experience
on
particular
devices
is
referred
to
as
content
adaptation
.
The
remainder
of
this
section
outlines
briefly
describes
content
adaptation
in
order
to
provide
a
background
to
for
this
document.
It
is
not
intended
as
a
comprehensive
guide
or
to
be
definitive.
The
Device
Independence
Working
Group
[DIWG]
has
published
For
a
great
deal
of
material
relevant
to
this
subject.
Readers
more
detailed
description,
readers
are
expecially
referred
to
"Delivery
Context
Overview
for
the
Device
Independence"
[DCODI]
.
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.
4.1
3.1
Adaptation
Implementation
Model
There
is
quite
a
wide
spectrum
of
implementation
models
for
content
adaptation.
On
the
one
hand
it
may
be
quite
simple,
and
consist
of
determining
the
device
type
and
choosing
the
most
appropriate
set
of
previously
prepared
content
to
match
the
device
characteristics.
At
the
other
extreme
it
may
be
carried
out
in
a
completely
dynamic
way,
with
content
formatted
at
the
time
of
retrieval,
taking
into
account
not
only
statically
determined
properties,
such
as
screen
dimension,
but
also
dynamically
determined
properties,
such
as
the
temporary
attachment
of
a
fully
featured
keyboard.
Adaptation
can
be
carried
out
in
a
number
of
different
points
in
the
delivery
of
content
to
the
client
[see
DIWG
work
and
Device
Description
Landscape
paper
for
more
detailed
discussion].
[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
that
was
originally
purposed
for
another
device
and
displaying
it
with
appropriate
reformatting.
appropriately
to
the
device's
characteristics.
4.2
3.2
Assumptions
about
Adaptation
In
phase
1
we
assume
that
content
adaptation,
if
any,
is
carried
out
Server
Side.
Future
phases
may
consider
the
implication
of
other
content
adaptation,
especially
the
issues
around
granting
authority
to
third
parties
to
carry
out
adaptation,
prohibiting
adaptation
and
so
on.
Later
phases
may
also
address
the
issues
around
the
possibility
of
multiple
adaptations
-
i.e.
the
possibility
that
adaptation
can
be
applied
in
more
than
one
place,
and
that
in
network
adaptation
may
occur
more
than
once.
We
also
assume
that
it
is
possible
to
create
a
site
that
is
consistent
with
the
best
practice
recommendations,
without
carrying
out
adaptation
at
all.
However,
it
is
likely
that
a
more
sophisticated
and
enhanced
user
experience
will
be
achieved
if
adaptation
is
used.
Clearly
in
order
to
determine
the
appropriate
adaptation
for
any
particular
access,
it
is
necessary
to
determine
the
device
that
is
accessing
the
service.
Sometimes
it
is
not
possible
to
determine
the
device
type,
either
because
the
device
does
not
present
this
information
to
the
server
at
all,
or
in
sufficient
detail,
or
because
the
server
does
not
provide
the
ability
to
inspect
and
act
on
the
information
provided.
In
these
cases
the
content
author
provider
is
expected
to
assume
baseline
or
default
device
characteristics,
as
discussed
in
the
Introduction
to
this
document.
The
group
seeks
public
feedback
on
the
desirability
of
stating
that,
in
practice,
adaptation
is
required
for
delivery
to
mobile
devices;
and
that
consequently,
in
view
of
the
desirability
of
making
content
widely
accessible
across
a
broad
range
of
devices,
all
Web
development
requires
adaptation.
5.6.4.1
What
it
means
6
Conformance
and
mobileOK
(Normative)
This
provision
is
particularly
relevant
Conformance
to
predictive
text
input.
5.6.4.2
How
this
document
requires
conformance
to
do
it
each
and
every
one
of
the
Statements,
except
where
required
to
satisfy
the
needs
of
deficient
implementations
as
noted
under
[
DEFICIENCIES
].
Use
xml:lang
attributes
if
appropriate
All
of
the
Best
Practice
Statements
have
a
fragment
identifier
to
allow
formal
reference
to
them
and
allow
the
mark
up
language
in
question,
or
equivalent
mechanisms
in
other
markup
languages.
construction
of
compliance
claims
that
refer
to
them.
The
default
language
Best
Practice
Statements
are
intended
to
be
capable
of
having
conformance
statements
constructed
around
them,
in
support
of
the
mobileOK
trustmark
and
for
other
purposes.
Work
on
the
mobileOK
trustmark
will
develop
specific
recommended
requirements
for
a
document
may
also
trustmark,
which
will
be
specified
using
based
on
some
profile,
or
subset,
of
the
Content-Language
http
header.
Statements
in
this
document.
As
such,
the
mobileOK
trustmark
will
serve
as
the
main
conformance
claim
for
the
best
practices
document.
5.6.4.3
References
and
Sources
6.1
Classes
of
Products
This
relates
specification
applies
to
WCAG
4.1
one
class
of
product:
content
as
it
gets
delivered
to
a
Web
user
agent,
including
the
metadata
transferred
as
part
of
the
delivery
protocol.
5.6.5
Context
Menus
6.2
Normative
Parts
Don't
rely
on
having
access
to
context
menus.
The
normative
parts
of
this
specification
consist
of
the
Best
Practices
statements
marked
as
normative.
All
the
other
parts
are
informative,
except
this
section.
5.6.5.1
What
it
means
6.3
Extensibility
On
desktop
browsers
there
is
often
a
'context
menu'
i.e.
This
specification
may
be
compatible
with
other
specifications
which
describe
a
menu
that
pops
up
next
to
different
set
of
requirements
for
content,
insofar
as
such
requirements
do
not
conflict
with
the
mouse.
This
feature
is
frequently
absent
on
mobile
devices.
current
specification.