Copyright © 2006-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, mobileOK Pro , described separately. Claims to be W3C mobileOK Basic compliant conformant are represented using content labels, 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; it incorporates various refinements of the tests presented in the first two drafts; see 1.0. The W3C Membership and other interested parties are invited to review the changes-marked version document and send comments to public-bpwg-comments@w3.org , (with public archive which highlights all the changes since the previous publication of this document. The ) through 22 June 2007.
This document includes a set of editors notes on which feedback would be appreciated, in particular on was developed by the UTF-8 requirement Mobile Web Initiative Best Practices Working Group . The Working Group would also like feedback from Web content developers on the perceived difficulty of getting the mobileOK Basic status as described in this document. The Last Call review period for this documents extends until 6 March 2007. Please send comments on expects to advance this document Working Draft to the working group's public email Recommendation Status. A complete list public-bpwg-comments@w3.org of changes , a publicly archived mailing list . to this document is available
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 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
1.1
Levels
of
mobileOK
1.1.1
1.1.1
mobileOK
Basic
1.1.2
1.1.2
mobileOK
Pro
1.1.3
1.1.3
Out
of
Scope
1.1.4
1.1.4
Beyond
mobileOK
1.2
1.2
Applicability
1.3
1.3
Claiming
mobileOK
conformance
2
Conformance
2.1
2.1
Validity
of
the
Tests
2.2
2.2
Testing
Outcomes
2.3
2.3
Conduct
of
Tests
2.3.1
2.3.1
Order
of
Tests
2.3.2
2.3.2
HTTP
Request
2.3.3
2.3.3
HTTP
Response
2.3.4
2.3.4
Meta
http-equiv
Elements
2.3.5
CSS
Style
2.3.5
2.3.6
Included
Resources
2.3.6
2.3.7
Included
Stylesheet
Style
Sheet
Resources
2.3.7
2.3.8
Visible
Linked
Resources
2.3.9
Validity
2.3.10
White
Space
3
mobileOK
Basic
Tests
3.1
3.1
AUTO_REFRESH
(partial)
and
REDIRECTION
3.2
3.2
CACHING
3.3
3.3
CHARACTER_ENCODING_SUPPORT
and
CHARACTER_ENCODING_USE
3.4
3.4
CONTENT_FORMAT_SUPPORT
and
VALID_MARKUP
3.5
3.5
DEFAULT_INPUT_MODE
3.6
3.6
EXTERNAL_RESOURCES
3.7
3.7
GRAPHICS_FOR_SPACING
3.8
3.8
IMAGE_MAPS
3.9
3.9
IMAGES_RESIZING
and
IMAGES_SPECIFY_SIZE
3.10
3.10
LINK_TARGET_FORMAT
3.11
3.11
MEASURES
3.12
3.12
MINIMIZE
3.13
3.13
NO_FRAMES
3.14
3.14
NON-TEXT_ALTERNATIVES
(partial)
3.15
3.15
OBJECTS_OR_SCRIPT
(partial)
3.16
3.16
PAGE_SIZE_LIMIT
3.17
3.17
PAGE_TITLE
(partial)
3.18
3.18
POP_UPS
3.19
3.19
PROVIDE_DEFAULTS
(partial)
3.20
SCROLLING
(partial)
3.21
3.20
STYLE_SHEETS_SUPPORT
(partial)
3.22
3.21
STYLE_SHEETS_USE
3.23
3.22
TABLES_ALTERNATIVES
3.24
3.23
TABLES_LAYOUT
(partial)
3.25
3.24
TABLES_NESTED
3.26
VALID_MARKUP
A
Acknowledgements
(Non-Normative)
B
References
(Non-Normative)
C
Relationship
between
Best
Practices'
Relation
to
Practices
and
mobileOK
Tests
(Non-Normative)
This document describes W3C mobileOK Basic tests, which are based on 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, mobileOK Pro , described separately. Claims to be W3C mobileOK Basic conformant are represented using content labels, Description Resources (see [POWDER] ) also described separately.
The intention of mobileOK is to help catalyze development of Web sites content that provide 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 .
mobileOK Basic tests are based on a limited subset of the Mobile Web Best Practices. Their outcome is machine-verifiable, hence claims of mobileOK Basic conformance are easy to check.
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. available, nor does it say anything about whether other guidelines for development of Web content (such as [WCAG] ) have been followed.
The (full) mobileOK Pro tests include the mobileOK Basic tests and are based on a larger subset of the Mobile Web Best Practices. These tests are not all machine-verifiable.
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 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 best practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. Many devices' The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.
Content providers should provide an experience that is mobileOK conformant to ensure a basic level of interoperability. Providers are encouraged to provide enhanced experiences as well when these are appropriate to their application and devices that are accessing them.
The tests apply to a URI. Passing the tests means that under the right circumstances, when accessed as described in 2.3.2 HTTP Request , resolving a URI will retrieve 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 ). For convenience, this document refers to "mobileOK content" with the understanding that it refers to more than just the content itself.
mobileOK Basic says nothing about what may be delivered to non-mobile devices.
A standard mechanism will be defined that allows content providers to claim that a URI or group of URIs, such as a Web site, conforms to mobileOK Basic or mobileOK. mobileOK Pro . It will be possible to make claims in a machine-processable form. It will also be possible to notify end users of the presence of the claim by means of a human-readable mark.
mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.The details of the mechanism for claiming mobileOK conformance will be described separately.
This section details the tests that must be carried out in order to claim mobileOK Basic. Tests are presented as simple pseudo-code.
mobileOK tests are only meaningful when the URI under test resolves to HTML content delivered over HTTP.
Individual tests may result in PASS or FAIL . PASS is required from all tests in order to claim mobileOK Basic.
Tests may also generate a number of informative warn ings.
mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently. Some tests have been designed to assess aspects of the content that are disallowed by other tests; this is deliberate and is intended to allow testing environments to provide as much information as possible.
For
example
the
test
for
3.22
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 failure
Continue individual tests as far as is possible
Carry out as many tests as is 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.
Include
a
User-Agent
header
indicating
the
default
delivery
context
by
sending
exactly
this
header:
User-Agent: W3C-mobileOK/DDC-1.0 (see 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 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: To allow for self-signature of certificates during testing the signatory of a certificate should not be checked.
Note: Implementations must support basic and digest authentication.
If an HTTP request does not result in a valid HTTP response specifies (because of network-level error, DNS resolution error, or non-HTTP response), FAIL
If the response is an HTTPS response:
If the certificate is invalid, FAIL
If the certificate has expired, warn
If the HTTP 3xx status, a test implementation should attempt to respect status indicates redirection (status code 3xx):
Do not carry out tests on the server's response (e.g. follow
If the response relates to a 302 redirect). Note that redirects should be counted against request for the limit defined resource under test, or any of its included resources (see 2.3.6 Included Resources ):
Include the size of the response in the total described under 3.6 EXTERNAL_RESOURCES 3.16 PAGE_SIZE_LIMIT test.
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
Re-request the resource as indicated in the response.
If an the HTTP status indicates that authentication is required (e.g. status code 401):
If the response relates to a request fails for the resource under test, or any reason during of its included resources (see 2.3.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 Linked Resources ):
Continue with the test (network-level error, DNS resolution error, non-HTTP response, or server returns an (see 3.10 LINK_TARGET_FORMAT , i.e. do not re-request the resource with authentication information).
If the HTTP 4xx status code is 404 or 5xx status),
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 Linked Resources ), continue with the test outcome should be considered (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
Documents
sometimes
can
include
meta
elements
with
an
http-equiv
attribute.
These
attribute;
these
are
sometimes
considered
substitutes
for
HTTP
response
headers.
Test
implementations
should
respect
only
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 response headers. headers, as follows:
For
each
meta
element
that
exists,
however,
if
with
an
http-equiv
attribute:
If a matching HTTP response header does not exist, warn
If
a
matching
HTTP
response
header
exists
whose
name
matches
but
its
http-equiv
attribute
value,
and
the
header's
value
differs
from
the
element's
content
attribute
value,
the
test
should
generate
a
warn
ing.
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
of
the
style
attribute
is
deprecated
in
XHTML
Basic
1.1)
style
elements
whose
type
attribute
is
not
"text/css",
and
whose
media
attribute
is
either
not
present
or
is
present
and
contains
value
values
"all"
or
"handheld".
resources
linked
by
xml-stylesheet
processing
instructions
external
stylesheet
style
sheet
resources
linked
via
link
elements,
as
defined
in
2.3.6
2.3.7
Included
Stylesheet
Style
Sheet
Resources
resources
linked
by
CSS
@import
at-rules
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"
use only those rules that are not restricted as to their CSS media type or whose CSS media type specifier contains "handheld" or "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. resource whose URI has the "http" or "https" scheme . Examples include image and stylesheet style sheet resources.
When calculating page sizes, 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
object
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.
link
elements
and
xml-stylesheet
processing
instructions
as
defined
in
2.3.6
2.3.7
Included
Stylesheet
Style
Sheet
Resources
images
included
by
background-image
and
list-style-image
properties
in
the
CSS
Style
(
2.3.4
2.3.5
CSS
Style
)
@import
directives
in
the
CSS
Style
Style —
providing
they
are
in
scope
for
the
media
type
"handheld"
or
"all"
(
2.3.4
2.3.5
CSS
Style
)
When calculating the page size ( 3.16 PAGE_SIZE_LIMIT ) only those style sheets retrieved according to the rule specified here are taken into account.
Included
stylesheet
style
sheet
resources
are,
simply,
included
resources
that
are
stylesheets.
style
sheets.
They
are
defined
as
resources
referenced
in
the
href
attribute
of
link
elements
and
xml-stylesheet
processing
instructions
(in
which
case
attribute
in
this
section
refers
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
media
attribute
is
either
not
present
or
is
present
and
contains
value
"all"
or
"handheld".
Further,
this
definition
only
pertains
to
resources
whose
URI
begins
with
the
"http"
or
"https"
scheme.
Linked resources are resources linked to from the resource being tested, but which are not vital to rendering that resource. resource whose URI has the "http" or "https" scheme . Examples include resources linked via hyperlinks.
Linked resources are defined as those that are referenced by:
the
href
attribute
of
a
(anchor)
elements,
and
whose
URI
begins
with
the
"http"
or
"https"
scheme
scheme.
the
action
attribute
of
form
elements
whose
method
attribute
is
not
present
or
is
present
with
value
"get"
"get".
Note
that
forms
with
method
get
are
permissible
in
documents
under
test,
but
must
not
be
checked
in
case
posting
caused
unwanted
side
effects
such
as
the
addition
of
unwanted
records
to
a
database.
Several tests refer to the validity of aspects of a resource. This section defines specifically what this means.
A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS] , Appendix B
An image is a valid GIF image if it conforms to the grammar defined in section 25 of the [GIF] 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 section describes tests for mobileOK Basic. Tests are organized alphabetically by the Best Practice from which they derive. Where a test derives from more than one Best Practice it is placed according to the one that occurs earliest first in dictionary order.
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
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 page, resource's URI, FAIL
Else, warn
PASS
In
the
following,
note
that
HTTP
headers
should
be
used
rather
than
meta
elements
with
http-equiv
attributes,
which
are
commonly
not
taken
into
account
by
proxies.
Where
both
a
meta
element
and
the
corresponding
header
are
found
the
value
of
the
header
must
be
used.
If
the
HTTP
response
contains
neither
an
Expires
nor
Cache-Control
header,
header
If
no
meta
http-equiv
element
is
present,
referring
to
those
headers,
FAIL
warn,
and
continue
the
test
using
the
value
from
the
meta
content
attribute.
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,
or
if
the
Expires
warn
If any cache related header specifies contains an invalid date (e.g. "0"), 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
The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource cannot be delivered 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 delivered to devices in 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 requirement, UTF-8 support, has been extensively debated and the group solicits feedback on it. Determine the test requires that character encoding is explicitly specified by and recognizes the following, if present: following methods of specification:
HTTP
Content-Type
header
(e.g.
"application/xhtml+xml;charset=UTF-8")
application/xhtml+xml; charset=UTF-8"
XML declaration (e.g. "<?xml encoding="UTF-8"?>")
<?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
as
above
(e.g.
"<meta
http-equiv="Content-Type"
content="application/xhtml+xml;charset=UTF-8"/>)
... <head> <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 explicitly specified in at least one of these ways, 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 any character encoding specified is not "UTF-8", FAILIf the document is not valid UTF-8, UTF-8 (see 2.3.9 Validity ), FAIL
For each external resource as defined in specified by 2.3.5 2.3.6 Included Resources :
Request the URI indicated by the href attribute resource
If
the
HTTP
response
Content-Type
header
value
specifies
an
Internet
media
type
starting
of
the
response
starts
with
"text/"
but
does
not
specify
UTF-8
encoding
(e.g.
"text/css"
only
instead
of
"text/css;charset=UTF-8"),
character
encoding,
warn
PASS
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
an
HTML
document
and
it
fails
to
validate
according
to
its
given
DOCTYPE
,
FAIL
If (regardless of its stated DOCTYPE) the document does not validate against the XHTML Basic 1.1 DTD (regardless of its stated DOCTYPE), DTD:
If it does not validate against the XHTML-MP 1.2 DTD, FAIL
For each included resource, as defined by resource (see 2.3.5 2.3.6 Included Resources : ):
If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL
If the Internet media type is "image/gif" or "image/jpeg", and the resource is invalid according to the specification of GIF89a or JPEG, respectively, not valid (see 2.3.9 Validity ), FAIL
If the Internet media type is "text/css" and the content is not well-formed valid CSS (contains mismatching brackets or illegal characters), (see 2.3.9 Validity ), FAIL
PASS
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
Note that if an HTTP request is unsuccessful while conducting this test, the result is FAIL
Count
the
total
number
of
unique
included
resources,
as
defined
in
2.3.5
2.3.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, and add one to a running count
Add to the count the number of HTTP redirects (HTTP responses with 3xx status 301 or 302) responses) that must be followed and authentication requests that must be made until the resource itself is successfully retrieved
If this total exceeds 10, warn
If this total exceeds 20, FAIL
PASS
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:
element
and
object
element
whose
type
attribute
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
If
an
area
input
element
with
type
attribute
set
to
"image"
is
present,
FAIL
For
each
img
element:
element
and
object
element
:
If
a
usemap
attribute
is
present,
FAIL
If
an
ismap
attribute
is
present,
FAIL
PASS
Note
that
the
height
and
width
HTML
attributes
specify
pixels
when
they
are
used
as
a
number.
No
unit
is
specified.
For
each
img
element:
If
the
image
is
in
a
raster
format
(i.e.
is
a
JPEG
or
GIF
image,
for
example,
as
opposed
to
SVG),
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 either the height or width specified are greater than the corresponding dimension of the image, warn
If either the height or width specified are less than the corresponding dimension of the image, FAIL
PASS
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 body of the error response which are tested.
For each linked resource, as defined in 2.3.7 2.3.8 Visible Linked Resources :
Request the resource
If
the
HTTP
response's
Content-Type
header's
header
value
of
the
HTTP
response
is
not
one
of
the
Internet
media
types
Media
Types
listed
in
the
Accept
header
in
2.3.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
HTTP
Request
,
warn
PASS
For each property in the CSS Style ( 2.3.4 2.3.5 CSS Style ) whose value is a numeric measure of length: length stated together with a unit:
If the value is non-zero and the unit is not "em", "ex" "em" or "%", "ex", and the property is not a margin, border or padding box property (see also 3.20 SCROLLING (partial) ), property, FAIL
PASS
Count
number
of
whitespace
white
space
characters
in
a
sequence
of
more
than
one
whitespace
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
If
the
document
contains
a
frame
,
frameset
or
iframe
element,
element
or
object
element
whose
type
attribute
starts
with
"text/",
"application/xhtml+xml"
or
"application/vnd.wap.xhtml+xml"
,
FAIL
PASS
This test does not determine whether the alternative text is meaningful.
For
each
img
element:
If
an
alt
attribute
is
not
present,
present
or
consists
only
of
white
space
,
FAIL
PASS
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,
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,
FAIL
If
none
of
the
nested
object
elements
refers
to
content
that
matches
the
headers
defined
in
2.3.2
HTTP
Request
and
the
innermost
nested
object
element
body
is
non-empty
and
does
not
consist
of
text
or
an
img
element
that
refers
to
an
image
that
matches
the
headers
defined
in
a
supported
format,
2.3.2
HTTP
Request
,
FAIL
PASS
If the size of the document's markup exceeds 10 kilobytes, FAIL
For each included resource, as defined in 2.3.5 2.3.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
HTTP
Request
,
if
there
is
one)
If the total exceeds 20 kilobytes, FAIL
PASS
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,
FAIL
PASS
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
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
element:
If
element's
elements
with
type
"radio"
that
share
the
same
name
attribute
is
"radio",
value):
Check
that
exactly
one
input
element
whose
name
attribute's
value
matches
that
of
within
this
radio
input,
and
whose
group
has
its
checked
attribute
is
set
to
some
value,
"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,
warn
If
CSS
property
there
is
more
than
one
width
option
is
set
in
pixels,
or,
the
element
has
a
whose
width
selected
attribute
Add
to
the
property/attribute
value
the
value
of
the
following
CSS
box
properties
if
set
in
pixels:
border-left-width
,
border-right-width
(may
also
be
set
by
border-width
,
border-left
,
border-right
,
border
)
margin-left
,
margin-right
(may
also
be
set
by
margin
)
padding-left
,
padding-right
(may
also
be
is
set
by
padding
)
If
the
sum
exceeds
120,
warn
Otherwise,
for
each
of
the
parent
elements,
its
parent,
and
so
on
up
to
the
document
root:
Add
to
that
sum
the
values
of
the
border,
margin
"selected",
and
padding
properties
as
above
If
the
sum
exceeds
120,
warn
Otherwise
continue
with
the
next
parent
For
each
table
element:
If
the
value
of
its
width
multiple
attribute
exceeds
120,
warn
Sum
its
border,
margin
and
padding
property
values
as
above
For
each
contained
tr
element:
For
each
contained
td
or
th
element:
Add
is
not
set
to
that
sum
its
border,
margin
and
padding
property
values
Add
its
width,
as
specified
by
the
CSS
width
property,
if
present
If
the
sum
exceeds
120,
"multiple",
warn
PASS
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.4
2.3.5
CSS
Style
)
contains
rules
referencing
the
position
,
display
or
float
properties,
warn
PASS
This test does not require that any CSS styles be used, since in some cases, no presentation information is required at all (for example, a simple page of text).
This test looks for elements in the Text Extension module defined by [XHTMLModularization] , since these some of which are not supported in XHTML Basic. It also looks for commonly-used elements and attributes that were deprecated in HTML 4, and are also not supported supported, or are deprecated, in XHTML Basic.
Note
that
external
style
sheets
and
style
elements
that
have
no
media
attribute
are
assumed
to
refer
to
"all".
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.4 2.3.5 CSS Style ), PASS
If the document contains a CSS style element but no externally linked CSS Style, warnIf the CSS Style contains a single @media rule that specifies the all styles are restricted to media type screen , types other than "handheld" or "all" by means of @media at- rules, warn
If
the
CSS
Style
contains
at-rules
other
(other
than
the
@media
at-rule,
properties
at-rule),
properties,
or
values
that
are
not
recognized
as
being
valid
CSS
Level
1,
1
2.3.9
Validity
,
warn
PASS
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
less
than
two
at
most
one
tr
elements,
element,
FAIL
If
no
tr
element
contains
at
least
two
more
than
one
td
elements,
element,
FAIL
For
each
nested
td
element:
If the element contains only an image (or equivalent object) whose real actual dimensions are 2x2 or less, FAIL
PASS
If
a
table
element
exists,
If
a
table
element
exists
somewhere
inside
it,
FAIL
PASS
The editors would like to thank members of the BPWG for contributions of various kinds.
The editors acknowledge significant written contributions from:
This appendix lists all best practices and indicates whether each has a corresponding test in mobileOK Basic, mobileOK, mobileOK Pro , both, or neither. Note that mobileOK Pro is a superset super-set of mobileOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK. mobileOK Pro . This table, however, indicates which best practices have a corresponding test that expands on the test, if any, in mobileOK Basic. The tests listed for mobileOK Pro are subject to change as that document is still a work in progress.