Copyright
© 2007
© 2007
W3C
®
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document defines the tests that provide the basis for making a claim of W3C® mobileOK Basic™ conformance and are based on W3C Mobile Web Best Practices [BestPractices] . Content which passes the tests has taken some steps to provide a functional user experience for users of basic mobile devices whose capabilities at least match those of the Default Delivery Context (DDC).
mobileOK
Basic
is
the
lesser
of
two
levels
of
claim,
the
greater
level
being
mobileOK
Pro
,
Pro,
described
separately.
Claims
to
be
W3C
mobileOK
conformant
are
represented
using
Description
Resources
(see
[POWDER]
)
,
),
also
described
separately.
mobileOK assesses interoperability. It does not measure usability and does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.
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
is
a
Last
Call
Working
Draft
of
mobileOK
Basic
Tests
1.0.
The
W3C
Membership
and
other
interested
parties
are
invited
to
review
the
document
and
send
comments
to
public-bpwg-comments@w3.org
,
(with
public
archive
)
through
22
June
19
October
2007.
This
document
was
developed
by
the
Mobile
Web
Initiative
Best
Practices
Working
Group
.
The
Working
Group
expects
to
advance
this
Working
Draft
to
Recommendation
Status.
A
complete
list
of
To
view
the
changes
made
to
this
document
is
available
since
the
previously
published
(25
May
2007)
version,
see
the
accompanying
diff
document
.
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 was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
1
Introduction
1.1
Levels
of
mobileOK
1.1.1
mobileOK
Basic
1.1.2
mobileOK
Pro
1.1.3
Out
of
Scope
1.1.4
Beyond
mobileOK
1.2
Applicability
1.3
Claiming
mobileOK
conformance
2
Conformance
2.1
Use
of
Terms
must,
should
etc.
2.2
Validity
of
the
Tests
2.2
2.3
Testing
Outcomes
2.3
2.4
Conduct
of
Tests
2.3.1
2.4.1
Order
of
Tests
2.3.2
2.4.2
HTTP
Request
2.3.3
2.4.3
HTTP
Response
2.3.4
2.4.4
Meta
http-equiv
Elements
2.3.5
2.4.5
CSS
Style
2.3.6
2.4.6
Included
Resources
2.3.7
Included
Style
Sheet
Resources
2.3.8
Visible
2.4.7
Linked
Resources
2.3.9
2.4.8
Validity
2.3.10
2.4.9
White
Space
3
mobileOK
Basic
Tests
3.1
AUTO_REFRESH
(partial)
and
REDIRECTION
3.2
CACHING
3.3
CHARACTER_ENCODING_SUPPORT
and
CHARACTER_ENCODING_USE
3.4
CONTENT_FORMAT_SUPPORT
and
VALID_MARKUP
3.5
DEFAULT_INPUT_MODE
3.6
EXTERNAL_RESOURCES
3.7
GRAPHICS_FOR_SPACING
3.8
IMAGE_MAPS
3.9
IMAGES_RESIZING
and
IMAGES_SPECIFY_SIZE
3.10
LINK_TARGET_FORMAT
3.11
MEASURES
3.12
MINIMIZE
3.13
NO_FRAMES
3.14
NON-TEXT_ALTERNATIVES
(partial)
3.15
OBJECTS_OR_SCRIPT
(partial)
3.16
PAGE_SIZE_LIMIT
3.17
PAGE_TITLE
(partial)
3.18
POP_UPS
3.19
PROVIDE_DEFAULTS
(partial)
3.20
STYLE_SHEETS_SUPPORT
(partial)
3.21
STYLE_SHEETS_USE
3.22
TABLES_ALTERNATIVES
3.23
TABLES_LAYOUT
(partial)
3.24
TABLES_NESTED
A
Acknowledgements
Acknowledgments
(Non-Normative)
B
References
(Non-Normative)
C
Relationship
between
Best
Practices
and
mobileOK
Tests
(Non-Normative)
mobileOK Basic is a scheme for assessing whether Web resources (Web content) can be delivered in a manner that is conformant with Mobile Web Best Practices [BestPractices] to a simple and largely hypothetical mobile user agent, the Default Delivery Context .
This document describes W3C mobileOK Basic tests for delivered content, and describes how to emulate the DDC when requesting that content.
mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK Pro , described separately. Claims to be W3C mobileOK Basic conformant are represented using Description Resources (see [POWDER] ) also described separately.
The intention of mobileOK is to help catalyze development of Web content that provides a functional user experience in a mobile context. It is not a test for browsers, user agents or mobile devices, and is not intended to imply anything about the way these should behave.
mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that a claim that a resource is mobileOK conformant implies that it is of higher informational value, is more reliable, more trustworthy or is more appropriate for children than any other resource .
Content passing the tests demonstrates that the content provider has taken basic steps to provide a functional experience for mobile users.
mobileOK Basic conformance should be considered only a first step towards building a harmonized experience for mobile users. Conformance merely demonstrates that a basic experience is available, interoperable with a large number of mobile devices. mobileOK Basic conformance says nothing about richer, more sophisticated, experiences that may be available, nor does it say anything about whether other guidelines for development of Web content (such as [WCAG] ) have been followed.
Content passing the tests demonstrates that the content provider has taken significant steps to provide a functional experience for mobile users.
However, mobileOK Pro conformance still does not suggest that the most sophisticated mobile user experience possible is available. It implies that a functional experience is available which adheres even more closely to the Mobile Web Best Practices.
Like mobileOK Basic, mobileOK Pro conformance says nothing about whether other guidelines for development of Web content (such as [WCAG] ) have been followed.
mobileOK Pro tests will be described separately.
Note
that
some
Some
best
practices,
like
TESTING
,
are
advisable
but
do
not
meaningfully
translate
into
concrete
tests,
whether
their
outcome
is
machine-
or
human-verifiable.
The tests do not assess usability, rather, they assess whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices.
The
tests
apply
to
a
URI.
Passing
the
tests
means
that
when
accessed
as
described
in
2.3.2
2.4.2
HTTP
Request
,
resolving
a
URI
will
result
in
mobileOK
Basic
conformant
content
that
is
delivered
in
a
mobileOK
Basic
conformant
manner.
That is, the tests do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. VALID_MARKUP ), but to how it is delivered to a mobile device (e.g. CACHING ).
mobileOK Basic says nothing about what may be delivered to non-mobile devices.
This
section
details
Where
terms
are
used
with
the
tests
that
must
be
carried
out
meanings
defined
in
order
to
claim
mobileOK
Basic.
Tests
[RFC2119]
they
are
presented
as
simple
pseudo-code.
highlighted
in
the
text
e.g.
must
.
For
example
the
test
for
3.21
STYLE_SHEETS_USE
points
out
that
style
sheets
should
be
used
in
preference
to
markup
elements
such
as
center
,
even
though
the
center
element
is
also
disallowed
by
the
test
for
3.4
CONTENT_FORMAT_SUPPORT
and
VALID_MARKUP
.
Creators of implementations of the tests described in this document are encouraged to provide as much information as possible to users of their implementations. Where possible they should not stop on FAIL and specifically they should :
Provide information about the cause of warning or failure (each warn and FAIL is individually identified);
Continue
individual
tests
as
far
as
is
possible
possible;
Carry
out
as
many
tests
as
is
reasonable
reasonable.
The following HTTP request headers inform the server that it should deliver content that is compatible with the Default Delivery Context .
Use
the
HTTP
GET
method
when
making
requests.
requests,
except
for
3.10
LINK_TARGET_FORMAT
where
the
HEAD
method
may
be
used
(See
2.4.7
Linked
Resources
for
a
discussion
of
the
POST
method).
Include
a
User-Agent
header
indicating
the
default
delivery
context
by
sending
exactly
this
header:
User-Agent: W3C mobileOK DDC (http://www.w3.org/2006/07/mobileOK-ddc)
Include
an
Accept
header
indicating
that
Internet
media
types
understood
by
the
default
delivery
context
are
accepted
by
sending
exactly
this
header:
Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
Include
an
Accept-Charset
header
indicating
that
only
UTF-8
is
accepted
by
sending
exactly
this
header:
Accept-Charset: UTF-8
Do not include cookie related headers.
Include
authentication
information
if
required
(see
2.3.3
2.4.3
HTTP
Response
).
Once
authentication
information
has
been
included
in
a
request,
subsequent
requests
for
the
same
realm
must
include
authentication
information
as
described
in
Section
2
and
under
"domain"
in
Section
3.2.1
of
[RFC2617]
.
Implementations
must
support
URIs
with
both
http
and
https
scheme
components.
Note:
As
noted
under
2.4.6
Included
Resources
and
2.4.7
Linked
Resources
the
URIs
that
are
relevant
to
mobileOK
are
those
that,
when
represented
in
an
absolute
form,
have
the
have
either
the
http
or
the
https
scheme.
Requests
should
not
be
made
for
URIs
with
schemes
other
than
http
and
https
.
If the response is an HTTPS response:
If the certificate is invalid, FAIL
If the certificate has expired, warn
If the HTTP status indicates redirection (status code 3xx):
Do not carry out tests on the response
If
the
response
relates
to
a
request
for
the
resource
under
test,
or
any
of
its
included
resources
(see
2.3.6
2.4.6
Included
Resources
):
Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
If
there
is
no
HTTP
Location
header,
FAIL
.
If
the
URI
identified
by
the
HTTP
Location
header
is
a
relative
URI,
create
an
absolute
URI
by
combining
the
value
of
the
Location
header
with
the
absolute
URI
of
the
request
to
which
this
is
a
response,
warn
If
the
resulting
URI
is
not
a
URI
with
the
scheme
http
or
https
,
FAIL
.
Re-request
the
resource
as
indicated
in
using
the
response.
URI
formulated
above.
If the HTTP status indicates that authentication is required (e.g. status code 401):
If
the
response
relates
to
a
request
for
the
resource
under
test,
or
any
of
its
included
resources
(see
2.3.6
2.4.6
Included
Resources
):
If authentication information was supplied in the HTTP request (i.e. authentication failed), FAIL
Carry out tests on the response
Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
Re-request the resource using authentication information
If
the
response
relates
to
a
request
for
a
linked
resource
(see
2.3.8
Visible
2.4.7
Linked
Resources
):
Continue
with
the
test
(see
3.10
LINK_TARGET_FORMAT
,
i.e.
do
not
re-request
the
resource
with
authentication
information).
information),
warn
If the HTTP status code is 404 or 5xx
If the response relates to a request for the resource under test, continue with tests on the response and warn
If
the
response
relates
to
a
request
for
a
linked
resource
(see
2.3.8
Visible
2.4.7
Linked
Resources
),
continue
with
the
test
(see
3.10
LINK_TARGET_FORMAT
)
and
warn
Otherwise (i.e. for included resources), FAIL
If the HTTP status represents failure (4xx), other than 404 or a request for authentication (e.g. 401), FAIL
Values specified in such elements must be ignored, aside from the following:
The
Refresh
header
as
specified
in
3.1
AUTO_REFRESH
(partial)
and
REDIRECTION
The
Content-Type
header
as
specified
in
3.3
CHARACTER_ENCODING_SUPPORT
and
CHARACTER_ENCODING_USE
The
Cache-Control
header
as
specified
in
3.2
CACHING
Check for consistency with HTTP headers, as follows:
For
each
meta
element
with
an
http-equiv
attribute:
If a matching HTTP response header does not exist, warn
If
a
matching
HTTP
response
header
exists
but
its
value
differs
from
the
content
attribute
value,
warn
Some tests refer to "CSS Style" information. Assemble the CSS Style by using the contents of:
the
style
attribute
of
any
element
(note
that
use
(use
of
the
style
attribute
is
deprecated
in
XHTML
Basic
1.1)
1.1
[XHTMLBasic11]
)
style
elements
whose
type
attribute
is
"text/css",
and
whose
media
attribute
is
either
not
present
or
is
present
and
contains
values
"all"
or
"handheld".
resources
linked
by
via
link
elements
and
xml-stylesheet
processing
instructions
instructions,
where:
external
style
sheet
resources
linked
via
the
link
rel
elements,
as
defined
in
attribute
contains
"stylesheet"
but
not
"alternate"
the
charset
attribute
is
either
not
present
or
is
present
with
value
"UTF-8"
the
type
attribute
is
either
not
present
or
is
present
with
value
"text/css"
the
media
attribute
is
either
not
present
or
is
present
and
contains
value
"all"
or
"handheld".
2.3.7
Included
Style
Sheet
Resources
Note:
In
the
case
of
xml-stylesheet
processing
instructions,
attribute
in
this
section
refers
to
pseudo-attribute
.
resources
linked
by
CSS
@import
at-rules
whose
presentation
media
descriptor
is
either
not
present
or
is
present
and
contains
values
"all"
or
"handheld"
In
the
course
of
assembling
the
CSS
Style:
observe
the
CSS
Level
1
cascade
retrieve
only
those
resources
that
have
no
CSS
media
type,
or
whose
CSS
media
type
specifier
contains
"handheld"
or
"all"
Style
use
only
those
rules
CSS
rulesets
that
are
not
restricted
as
to
their
CSS
media
type
or
whose
CSS
media
type
specifier
contains
"handheld"
or
"all"
"all".
For
convenience,
this
section
and
those
that
follow
provide
definitions
that
are
reused
several
times
in
the
document.
Some
tests
refer
to
a
notion
of
included
resources,
which
are
resources
external
to
the
resource
being
tested
and
yet
vital
to
rendering
that
resource
and
whose
URI
has
the
"http"
or
"https"
scheme
.
scheme,
when
represented
in
an
absolute
form.
Examples
include
image
and
style
sheet
resources.
When
calculating
page
sizes,
retrieving
resources,
caching
directives
should
be
observed.
Multiple
references
to
cached
resources
are
counted
only
once
in
regard
of
page
weight
(see
3.16
PAGE_SIZE_LIMIT
)
and
resource
count
(see
3.6
EXTERNAL_RESOURCES
).
Included resources are defined as those that are referenced by:
img
elements
In
some
circumstances
object
elements
may
act
as
synonyms
for
other
elements
such
as
img
and
iframe
.
In
these
cases
it
is
noted
in
the
relevant
section
when
to
regard
object
elements
as
equivalents
for
other
elements.
(see
notes
below)
link
elements
and
xml-stylesheet
processing
instructions
as
defined
in
2.3.7
Included
2.4.5
CSS
Style
Sheet
Resources
images
included
by
background-image
and
list-style-image
properties
in
the
CSS
Style
(
2.3.5
2.4.5
CSS
Style
)
@import
directives
in
the
CSS
Style —
Style
-
providing
they
are
in
scope
for
the
unqualified
as
to
presentation
media
type
or
qualified
by
presentation
media
type
"handheld"
or
"all"
(
as
defined
in
2.3.5
2.4.5
CSS
Style
)
3.16
PAGE_SIZE_LIMIT
Note:
)
only
those
style
sheets
retrieved
according
to
the
rule
specified
here
are
taken
into
account.
Included
style
sheet
resources
are,
simply,
included
resources
that
are
style
sheets.
They
are
defined
as
resources
referenced
in
the
In
some
circumstances
href
object
attribute
of
elements
may
act
as
synonyms
for
other
elements
such
as
link
img
elements
and
.
In
these
cases
it
is
noted
in
xml-stylesheet
processing
instructions
(in
which
case
attribute
iframe
this
the
relevant
section
refers
when
to
pseudo-attribute
)
whose
rel
attribute
contains
"stylesheet"
but
not
"alternate",
charset
attribute
is
either
not
present
or
is
present
with
value
"UTF-8",
type
attribute
is
either
not
present
or
is
present
with
value
"text/css",
and
whose
regard
object
elements
as
equivalents
for
other
elements.
Note:
For
nested
media
object
attribute
is
either
not
present
or
is
present
and
contains
value
"all"
or
"handheld".
elements,
count
only
the
number
of
objects
that
need
to
be
assessed
as
discussed
in
3.15
OBJECTS_OR_SCRIPT
.
A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS] , Appendix B (see note below).
Note:
The
presence
of
at-rules,
properties
or
values
or
combinations
of
properties
and
values
that
are
not
specified
in
[CSS]
does
not
constitute
a
validity
failure
for
CSS.
See
3.21
STYLE_SHEETS_USE
for
treatment
of
such
values.
In
addition,
the
@media
at-rule
and
the
presentation
media
qualifiers
for
the
@import
at-rule
are
taken
into
account
when
evaluating
CSS.
An
image
is
a
valid
GIF
image
if
it
conforms
to
the
grammar
defined
in
section
25
of
the
[GIF]
specification
specification.
An image is a valid JPEG image if it follows the format defined in Annex B of the [JPEG] specification
A
resource
is
considered
to
be
valid
UTF-8
if
its
bytes
represent
the
valid
UTF-8
encoding
of
some
string,
as
defined
in
[UTF-8]
,
section
4
Note:
[utf8_perl]
contains
a
regular
expression
that
may
be
used
for
testing
UTF-8
validity.
Several tests refer to white space. White space has the same definition in this document as in XML. For XML 1.0 [XML10] it is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:
S
::=
(#x20
|
#x9
|
#xD
|
#xA)+
i.e.
the
characters
SP,
TAB,
CR
and
LF.
For
XML
1.1
[XML11]
it
is
defined
in
section
1.3
as
consisting
of
the
same
characters
with
the
addition
of
NEL
(#x85)
and
the
Unicode
line
separator
character,
(#x2028).
This test does not determine whether the user is able to opt out of refresh.
If
a
meta
element
is
present
with
http-equiv
attribute
value
of
"refresh",
If
the
URI
specified
in
as
part
of
the
content
attribute
is
not
the
current
resource's
URI,
FAIL
Else, warn
If
a
Refresh
HTTP
header
is
present,
If the URI specified in the header value is not the current resource's URI, FAIL
Else,
warn
PASS
warn
In
The
purpose
of
the
following,
note
test
is
to
alert
providers
to
the
fact
that
HTTP
headers
should
be
used
rather
than
meta
elements
with
http-equiv
attributes,
which
are
commonly
their
content
may
not
taken
into
account
by
proxies.
be
cached,
if
it
would
be
beneficial
to
do
so.
Note:
Where
both
a
meta
element
with
http-equiv
attribute
and
the
corresponding
HTTP
header
are
found
found,
the
value
of
the
HTTP
header
must
be
used.
used
-
see
also
note
under
2.4.4
Meta
http-equiv
Elements
.
If
the
HTTP
response
contains
neither
an
Expires
nor
Cache-Control
header
If
no
meta
http-equiv
element
is
present,
referring
to
those
headers,
FAIL
warn,
and
continue
Continue
the
test
using
the
value
from
the
meta
content
attribute.
attribute
as
though
it
were
specified
in
the
appropriate
header,
warn
If
a
Cache-Control
HTTP
header
is
present
and
contains
value
"no-cache",
or
contains
value
"max-age=0",
warn
If
a
Pragma
HTTP
header
is
present
and
contains
value
"no-cache",
warn
If
an
Expires
and
Date
HTTP
header
are
present,
and
the
Expires
header
specifies
a
date
which
is
not
later
than
what
the
Date
header
specifies,
warn
If any cache related header contains an invalid value, warn
If
the
HTTP
response
contains
a
Last-Modified
header,
Request
the
same
URI
again,
adding
an
If-Modified-Since
request
header
whose
value
matches
that
of
the
Last-Modified
response
header
If
the
HTTP
response
contains
a
Last-Modified
header
and
its
value
is
again
the
same,
and
the
HTTP
response
status
is
not
304
(Not
Modified),
warn
If
the
HTTP
response
contains
an
ETag
header,
Request
the
same
URI
again,
adding
an
If-None-Match
request
header
whose
value
matches
that
of
the
ETag
response
header
If
the
HTTP
response
contains
an
ETag
header
and
its
value
is
again
the
same,
and
the
HTTP
response
status
is
not
304
(Not
Modified),
warn
PASS
warn
The
DDC
is
defined
to
support
only
UTF-8
encoding,
and
hence
this
test
fails
if
a
resource
cannot
be
is
not
encoded
in
UTF-8.
The
test
does
not
require
that
resource
always
be
encoded
in
UTF-8;
the
test
merely
checks
that
the
resource
is
available
in
UTF-8
encoding,
if
requested.
Resources
may
be
represented
using
other
encodings
where
appropriate.
This
test
verifies
that
a
DDC-like
device
which
only
accepts
UTF-8
encoding
may
access
the
resource
in
UTF-8
encoding.
This test requires that character encoding is explicitly specified and recognizes the following methods of specification:
HTTP
Content-Type
header
application/xhtml+xml ; charset=UTF-8
XML declaration
<?xml version="1.0" encoding="UTF-8" ?>
meta
element
that
is
the
first
child
of
the
document's
head
element,
and
whose
http-equiv
attribute
is
"Content-Type",
and
whose
content
attribute
specifies
a
character
encoding
... <head><meta http-equiv="Content-Type" content="application/xhtml+xml"/><meta http-equiv="Content-Type" content="application/xhtml+xml ; charset=UTF-8 "/> ...
If
the
HTTP
Content-Type
header
specifies
a
character
encoding
other
than
UTF-8,
FAIL
If
the
HTTP
Content-Type
header
does
not
specify
a
character
encoding:
If there is no XML declaration, or UTF-8 character encoding is not specified in the XML declaration, FAIL
If
the
HTTP
Content-Type
header
specifies
an
Internet
media
type
starting
with
"text/":
If
there
is
no
meta
element
with
http-equiv
attribute
that
specifies
UTF-8
character
encoding,
FAIL
If character encoding is specified in more than one way, and not all values are the same, FAIL
If
the
document
is
not
valid
UTF-8
(see
2.3.9
2.4.8
Validity
),
FAIL
For
each
resource
specified
by
2.3.6
2.4.6
Included
Resources
:
Request the resource
If
the
HTTP
Content-Type
header
value
of
the
response
starts
with
"text/"
but
does
not
specify
UTF-8
character
encoding,
warn
PASS
warn
Note:
In the following, an "html document" is a document that has "html" as its root element.
Note:
In
the
following,
"regardless
of
its
stated
DOCTYPE
"
means
that
when
assessing
validity
against
the
XHTML
Basic
1.1
and
XHTML
MP
1.2
DTDs
this
may
be
carried
out
by
inserting
a
DOCTYPE
if
none
is
present,
or
by
replacing
the
given
DOCTYPE
with
the
appropriate
DOCTYPE
for
the
DTD
under
test.
If
the
document's
Internet
media
type,
as
specified
in
the
HTTP
response
Content-Type
header,
is
not
"application/xhtml+xml",
"application/vnd.wap.xhtml+xml",
or
"text/html",
FAIL
If the document's Internet media type is "text/html" or "application/vnd.wap.xhtml+xml", warn
If
the
document
does
not
contain
a
DOCTYPE
declaration,
FAIL
If
the
document
is
not
an
HTML
document
and
or
it
fails
to
validate
according
to
its
given
DOCTYPE
,
FAIL
If
(regardless
the
document
does
not
declare
the
html
namespace
on
its
html
root
element,
FAIL
If
(
regardless
of
its
stated
DOCTYPE)
DOCTYPE
)
the
document
does
not
validate
against
the
XHTML
Basic
1.1
DTD:
If ( regardless of its stated DOCTYPE ) it does not validate against the XHTML-MP 1.2 DTD, FAIL
For
each
included
resource
(see
2.3.6
2.4.6
Included
Resources
):
If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL
If an image is required (see also 3.15 OBJECTS_OR_SCRIPT ) and the response specifies an Internet media type that is not "image/jpeg" or "image/gif", FAIL
If
the
Internet
media
type
is
"image/gif"
or
"image/jpeg",
and
the
resource
is
not
valid
(see
2.3.9
2.4.8
Validity
),
FAIL
If a style sheet is required and the response specifies an Internet media type that is not "text/css", FAIL
If
the
Internet
media
type
is
"text/css"
and
the
content
is
not
valid
CSS
(see
2.3.9
2.4.8
Validity
),
FAIL
PASS
FAIL
Note:
Note
that
inputmode
is
part
of
[XHTMLBasic11]
.
For
each
input
element
with
attribute
type
whose
value
is
"text"
or
"password"
If
the
element's
inputmode
attribute
is
invalid
according
to
Section
5.2
User
Agent
Behavior
of
XHTML
Basic
1.1
[XHTMLBasic11]
,
FAIL
If
the
element's
value
attribute
is
missing
or
empty,
and
an
inputmode
attribute
is
not
present,
warn
For
each
textarea
element:
If
the
element's
inputmode
attribute
is
invalid
according
to
Section
5.2
User
Agent
Behavior
of
XHTML
Basic
1.1
[XHTMLBasic11]
,
FAIL
If
the
element
is
empty
and
an
inputmode
attribute
is
not
present,
warn
PASS
warn
Count
the
total
number
Make
an
inventory
of
unique
included
resources,
as
defined
in
2.3.6
2.4.6
Included
Resources
For
nested
object
elements,
count
only
the
number
of
objects
that
need
to
be
assessed
before
content
matching
the
request
header
defined
in
2.3.2
HTTP
Request
is
found
.
.
For each such resource:
Request
the
resource,
resource
and
add
one
to
carry
out
the
procedures
discussed
under
2.4.3
HTTP
Response
maintaining
a
running
count
Add
to
the
count
the
number
total
of
HTTP
redirects
(HTTP
3xx
status
responses)
that
must
be
followed
and
authentication
requests
that
must
be
made
made.
FAIL
until
ures
that
occur
in
the
resource
itself
is
successfully
retrieved
course
of
making
this
assessment
contribute
to
the
result
of
this
test.
If
this
the
total
exceeds
10,
warn
If
this
total
exceeds
20,
FAIL
PASS
FAIL
The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often used in e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the business interests of mobile sites, that it is undesirable to fail sites that use such small transparent images. Therefore this machine-testable test merely warn s about the presence of small (at most 2x2) transparent images and FAIL s larger ones. It is believed that few if any sites would use transparent images of any significant size for tracking.
For
each
img
element
and
object
element
whose
which
when
retrieved
has
an
Internet
media
type
attribute
that
starts
with
"image/"
:
If all pixels are transparent,
If image height and width are both less than or equal to 2 pixels, warn
If either dimension exceeds 2 pixels, FAIL
If
more
than
one
image
with
all
transparent
pixels
was
encountered,
warn
PASS
warn
If
an
input
element
with
type
attribute
set
to
"image"
is
present,
FAIL
For
each
img
element
and
object
element
:
If
a
usemap
attribute
is
present,
FAIL
If
an
ismap
attribute
is
present,
FAIL
PASS
FAIL
Note:
Note
that
the
The
height
and
width
HTML
attributes
specify
pixels
when
they
are
used
as
a
number.
No
unit
is
specified.
For
each
img
element
and
object
element
whose
type
attribute
starts
with
"image/"
:
If
the
height
or
width
attribute
are
missing,
FAIL
If
the
height
or
width
attribute
do
not
specify
a
size
in
pixels,
FAIL
If
the
value
specified
by
either
the
height
or
width
specified
are
attribute
is
greater
than
the
corresponding
dimension
of
the
image,
warn
If
the
value
specified
by
either
the
height
or
width
specified
are
attribute
is
less
than
the
corresponding
dimension
of
the
image,
FAIL
PASS
FAIL
Note:
Note
that
404
and
5xx
HTTP
status
do
not
result
in
failure
when
conducting
this
test.
In
such
cases
it
is
the
headers
attached
to
the
Note:
The
document
body
of
the
error
response
which
are
tested.
linked
resources
is
not
examined.
For
each
linked
resource,
as
defined
in
2.3.8
Visible
2.4.7
Linked
Resources
:
Request the resource
If
the
Content-Type
header
value
of
the
HTTP
response
is
not
one
of
the
Internet
Media
Types
listed
in
the
Accept
header
in
2.3.2
2.4.2
HTTP
Request
,
warn
If
the
Content-Type
header
value
of
the
HTTP
response
is
not
consistent
(determined
in
the
same
way
as
specified
in
3.3
CHARACTER_ENCODING_SUPPORT
and
CHARACTER_ENCODING_USE
)
with
the
Accept-Charset
header
in
2.3.2
2.4.2
HTTP
Request
,
warn
For each document internal reference (links in the document under test that refer to the document itself):
If
there
is
no
target
for
the
reference
or
it
is
invalid
(e.g.
'#'),
PASS
warn
Note:
The
intrinsic
size
of
images
must
be
specified
as
attributes
of
the
img
element
and
not
as
CSS
properties
(see
3.9
IMAGES_RESIZING
and
IMAGES_SPECIFY_SIZE
)
Note:
Only CSS Level 1 properties are considered in this test.
For
each
CSS
Level
1
property
in
the
CSS
Style
(
2.3.5
2.4.5
CSS
Style
)
whose
value
is
a
numeric
measure
of
length
stated
together
with
a
unit:
If
the
value
is
non-zero
and
the
unit
is
not
"em"
or
"ex",
"ex"
(and
the
value
is
not
a
percentage),
and
the
property
is
not
a
margin,
border
or
padding
box
property,
FAIL
PASS
FAIL
Note:
Extraneous white space characters in script and in CSS are not considered in this test. Such an extension may be considered in a future revision of this specification.
Count
number
of
white
space
characters
(see
2.4.9
White
Space
)
in
a
sequence
of
more
than
one
white
space
character
(not
counting
the
first),
which
exist
outside
of
a
pre
,
style
,
script
element,
or
XML
comment
Add to this count the number of characters comprising XML comments. This total is the number of extraneous characters in the document.
Count total number of characters in document
If the number of extraneous characters exceeds 10% of the count of characters in the document, warn
If
the
number
of
extraneous
characters
exceeds
25%
of
the
count
of
characters
in
the
document,
FAIL
PASS
FAIL
If
the
document
contains
a
frame
,
frameset
or
iframe
element
or
it
contains
an
object
element
whose
which
when
retrieved
has
an
Internet
media
type
attribute
that
starts
with
"text/",
"application/xhtml+xml"
or
"application/vnd.wap.xhtml+xml"
,
FAIL
PASS
FAIL
This test does not determine whether the alternative text is meaningful.
Note:
An
empty
alt
attribute
is
acceptable
and
signifies
that
there
is
no
meaningful
textual
alternative,
for
example
for
images
that
are
purely
decorative.
For
each
img
element:
If
an
alt
attribute
is
not
present
or
consists
only
of
white
space
,
FAIL
PASS
FAIL
This test does not determine whether the document is still usable without the objects or scripts.
If
a
script
element
is
present,
warn
If
any
element
has
an
"intrinsic
event"
attribute
(currently
onload
,
onunload
,
onclick
,
ondblclick
,
onmousedown
,
onmouseup
,
onmouseover
,
onmousemove
,
onmouseout
,
onfocus
,
onblur
,
onkeypress
,
onkeydown
,
onkeyup
,
onsubmit
,
onreset
,
onselect
,
onchange
),
warn
For
each
a
and
link
element:
If
the
value
of
the
href
attribute
begins
with
the
"javascript:"
scheme,
FAIL
If
an
applet
element
is
present,
FAIL
If
an
object
element
is
present
and
has
no
object
element
ancestor
,
If
the
innermost
nested
object
element
is
empty,
warn
If
the
innermost
nested
object
element
content
consists
only
of
white
space,
space
(see
FAIL
2.4.9
White
Space
),
FAIL
If
none
of
the
nested
object
elements
refers
to
is
an
image
that
has
a
content
type
that
matches
the
headers
defined
in
2.3.2
2.4.2
HTTP
Request
and
the
innermost
nested
object
element
is
non-empty
and
does
not
consist
of
text
or
an
img
element
that
refers
to
an
image
that
matches
the
headers
defined
in
2.3.2
2.4.2
HTTP
Request
,
FAIL
PASS
FAIL
If
the
size
of
the
document's
markup
document
exceeds
10
kilobytes,
FAIL
For
each
included
resource,
as
defined
in
2.3.6
2.4.6
Included
Resources
:
Request the referenced resource
Add
the
size
of
the
response
body
to
a
running
total
(for
nested
object
elements
count
only
the
first
object
that
matches
the
headers
specified
in
2.3.2
2.4.2
HTTP
Request
,
if
there
is
one)
If
the
total
exceeds
20
kilobytes,
FAIL
PASS
FAIL
This test does not determine whether the title is meaningful.
If
a
title
element
is
not
present
in
the
head
element,
or
is
empty,
or
contains
only
white
space,
space
(see
FAIL
2.4.9
White
Space
),
PASS
FAIL
For
each
a
,
link
,
form
,
and
base
element:
If
a
target
attribute
is
present,
If
its
value
is
not
one
of
"_self",
"_parent",
or
"_top",
FAIL
PASS
FAIL
In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.
For
each
radio
button
group
within
a
form
element
(
input
elements
with
type
"radio"
that
share
the
same
name
attribute
value):
Check
that
exactly
one
input
element
within
this
group
has
its
checked
attribute
set
to
"checked",
and
if
this
is
not
the
case,
warn
For
each
select
element:
If
there
is
no
nested
option
element
whose
selected
attribute
is
set
to
some
value,
"selected",
warn
If
there
is
more
than
one
option
element
whose
selected
attribute
is
set
to
"selected",
and
the
multiple
attribute
is
not
set
to
"multiple",
warn
PASS
warn
In addition, a human test is needed here to verify whether the page is readable without a style sheet.
If
the
CSS
Style
(
2.3.5
2.4.5
CSS
Style
)
contains
rules
referencing
the
position
,
display
or
float
properties,
warn
PASS
warn
This
test
looks
for
elements
in
the
Text
Extension
module
defined
by
[XHTMLModularization]
,
some
of
which
are
not
supported
in
XHTML
Basic.
Basic
[XHTMLBasic11]
.
It
also
looks
for
commonly-used
elements
and
attributes
that
were
deprecated
in
HTML
4,
and
are
not
supported,
or
are
deprecated,
in
XHTML
Basic.
Note:
Note
that
external
style
sheets
and
style
elements
This
test
does
not
require
that
have
any
CSS
styles
be
used,
since
in
some
cases,
no
media
attribute
are
assumed
to
refer
to
"all".
presentation
information
is
required
at
all
(for
example,
a
simple
page
of
text).
If
the
document
contains
any
basefont
,
bdo
,
center
,
del
,
dir
,
font
,
ins
,
menu
,
s
,
strike
or
u
elements,
FAIL
If
the
document
contains
any
b
,
big
,
i
,
small
,
sub
,
sup
or
tt
elements,
warn
If
any
element
has
a
style
attribute,
warn
If
there
is
no
CSS
Style
(
2.3.5
2.4.5
CSS
Style
),
PASS
)
If all styles are restricted to media types other than "handheld" or "all" by means of @media at- rules, warn
If
the
CSS
Style
contains
at-rules
(other
than
the
@media
at-rule,
and
the
media
list
of
the
@import
at-rule),
properties,
or
values
that
are
not
recognized
as
being
valid
specified
in
CSS
Level
1
1,
2.3.9
Validity
warn
,
If
the
CSS
Style
contains
a
property
with
a
value
that
is
inappropriate
to
it,
warn
PASS
If the CSS Style contains a property with a value that requires a unit or a percentage:
If the unit (or percentage) is not present, warn
If the unit (or percentage) is inappropriate to the value, warn
If
a
table
element
exists,
warn
This test does not catch all cases where tables are used for layout purposes.
If
a
table
element
exists,
If
it
contains
at
most
one
tr
element,
FAIL
If
no
tr
element
contains
more
than
one
td
element,
FAIL
For
each
nested
td
element:
If
the
element
contains
only
an
image
(or
equivalent
object)
whose
actual
dimensions
are
2x2
or
less,
FAIL
PASS
FAIL
If
a
table
element
exists,
If
it
contains
a
table
element
exists
somewhere
inside
it,
FAIL
element,
PASS
FAIL
The editors would like to thank members of the BPWG for contributions of various kinds.
The editors acknowledge significant written contributions from: