W3C mobileOK Basic Tests 1.0

W3C mobileOK Basic Tests 1.0
W3C mobileOK Basic Tests 1.0
W3C Recommendation 08 December 2008
This version:
Latest version:
Previous version:
Editors:
Sean Owen, Google
Jo Rabin, dotMobi (and before at Segala)
Please refer to the
errata
for this document, which may include some normative corrections.
See also
translations
W3C
MIT
ERCIM
Keio
), All Rights Reserved. W3C
liability
trademark
and
document use
rules apply.
Abstract
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
[Best Practices]
. The details of how to claim mobileOK conformance will be described separately. Providers of content which passes the tests have 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 primarily assesses basic usability, efficiency and interoperability.
It 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.
Status of this Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the
W3C technical reports index
at http://www.w3.org/TR/.
This document was developed by the
Mobile Web Best Practices Working Group
as part of the
Mobile Web Initiative
Please see the Working Group's
implementation report
. A complete
list of the editorial changes
since the previous version of this document is available.
Please send comments about this document to
public-bpwg-comments@w3.org
(with
public archive
).
This document defines machine-verifiable tests, based on the W3C Mobile Web Best Practices [
Best Practices
]. Although content authors are not expected to use this document directly, participants of the Working Group expect tools that implement the tests defined in this document to greatly improve the authoring of content that addresses the browsing experience of users on a broad range of devices.
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
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
Table of Contents
Introduction
1.1
Scope
1.1.1
Relationship to Best Practices
1.1.2
Out of Scope
1.1.3
Beyond mobileOK
1.2
Applicability
1.3
Claiming mobileOK conformance
Conformance
2.1
Use of Terms must, should etc.
2.2
Validity of the Tests
2.3
Testing Outcomes
2.4
Conduct of Tests
2.4.1
Order of Tests
2.4.2
HTTPS
2.4.3
HTTP Request
2.4.4
HTTP Response
2.4.5
Meta http-equiv Elements
2.4.6
CSS Style
2.4.7
Included Resources
2.4.8
Linked Resources
2.4.9
Validity
2.4.10
White Space
mobileOK Basic Tests
3.1
AUTO_REFRESH 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
3.15
OBJECTS_OR_SCRIPT
3.15.1
Object Element Processing Rule
3.16
PAGE_SIZE_LIMIT
3.17
PAGE_TITLE
3.18
POP_UPS
3.19
PROVIDE_DEFAULTS
3.20
STYLE_SHEETS_SUPPORT
3.21
STYLE_SHEETS_USE
3.22
TABLES_ALTERNATIVES
3.23
TABLES_LAYOUT
3.24
TABLES_NESTED
Appendices
Acknowledgments
(Non-Normative)
References
(Non-Normative)
Relationship between Best Practices and mobileOK Tests
(Non-Normative)
1 Introduction
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
[Best Practices]
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.
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
1.1 Scope
1.1.1 Relationship to Best Practices
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, nor does it say anything about whether other
guidelines for development of Web content (such as
[WCAG 1.0]
have been followed.
1.1.2 Out of Scope
Some Best Practices, like
TESTING
, are advisable
but do not meaningfully translate into concrete tests.
The tests assess whether the content
can
be provided in a way
that achieves basic usability, efficiency, and interoperability with mobile
devices. The tests should not be understood to assess thoroughly whether the
content has been well-designed for mobile devices.
1.1.3 Beyond mobileOK
The Best Practices, and hence the tests, are not promoted as guidance for
achieving the optimal user experience. 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 Basic 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.
1.2 Applicability
The tests apply to a URI. Passing the tests means that when accessed as described
in
2.4.3 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.
1.3 Claiming mobileOK conformance
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. 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.
The details of the mechanism for claiming mobileOK conformance will be described
separately.
2 Conformance
2.1 Use of Terms must, should etc.
Where terms are used with the meanings defined in
[RFC 2119]
they
are highlighted in the text e.g.
must
2.2 Validity of the Tests
mobileOK tests are only meaningful when the URI under test resolves to HTML
content delivered over HTTP.
2.3 Testing Outcomes
Individual tests may result in
PASS
or
FAIL
PASS
is
required from all tests in order to claim mobileOK Basic conformance. In any test,
PASS
is achieved if and only if there are no
FAIL
s. No
specific
PASS
outcome is defined for any test.
Tests may also generate a number of informative
warn
ings which do not
affect whether a test has
PASS
ed or not. A
warn
ing may
indicate that it could not be conclusively determined whether the content under
test conforms to a Best Practice (and thus does not
FAIL
), or may
indicate that the content under test is close to violating a Best Practice.
2.4 Conduct of Tests
2.4.1 Order of Tests
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.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;
Carry out as many tests as is reasonable.
2.4.2 HTTPS
Note:
Arbitrary root certificates (including self-signed certificates) should
be regarded as trusted.
When resolving a URI, if the URI has the scheme
https
If the certificate presented does not match the
requested URI,
FAIL
If the certificate has expired, or is not yet valid,
warn
If certificate validation otherwise fails,
FAIL
2.4.3 HTTP Request
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, except for
3.10
LINK_TARGET_FORMAT
where the
HEAD
method may be used (See
2.4.8 Linked Resources
for a
discussion of the
POST
method).
Include a
User-Agent
header which starts exactly as follows (indicating the Default Delivery Context, and which
may
be extended in accordance with
[RFC 2616]
Section 14.43, User-Agent 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.4.4 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
[RFC 2617]
Implementations
must
support URIs with both
http
and
https
scheme components.
Note:
As noted under
2.4.7 Included Resources
and
2.4.8 Linked Resources
the URIs that are relevant to
mobileOK are those that, when represented in an absolute form,
have either the
http
or the
https
scheme. Requests
should not
be made for URIs
with schemes other than
http
and
https
2.4.4 HTTP Response
Note:
Implementations
must
support basic and digest
authentication.
Note:
Below, note that a 404 or 5xx response for the resource under test does
not result in a
FAIL
in order to allow for the possibility of
testing an application's error page.
Note:
If the test below results in a
FAIL
, do not proceed with further
tests. Otherwise, the mobileOK Basic Tests should be applied to the
content.
If an HTTP request does not result in a valid HTTP
response (because of network-level error, DNS resolution error, or
non-HTTP response),
FAIL
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.4.7 Included Resources
):
Include the size of the response in the "total size"
as described under
3.16
PAGE_SIZE_LIMIT
Include this response under the count as 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 using the 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.4.7 Included Resources
):
If authentication information was supplied in the HTTP
request (i.e. authentication failed) or if no authentication information is available,
FAIL
Carry out tests on the response
Include the size of the response in the "total size"
as described under
3.16
PAGE_SIZE_LIMIT
Include this response under the count as 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.4.8 Linked Resources
):
Continue with the test (see
3.10
LINK_TARGET_FORMAT
, i.e. do not re-request the resource
with authentication 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.4.8 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, a request for authentication (e.g. 401) or a 406 when carrying out the
3.15.1 Object Element Processing Rule
FAIL
2.4.5 Meta http-equiv Elements
Documents can include
meta
elements with an
http-equiv
attribute; these are sometimes considered
substitutes for HTTP response headers.
mobileOK Basic test implementations
must
ignore values specified in
such elements, aside from the following:
The
Refresh
header as specified in
3.1
AUTO_REFRESH 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
2.4.6 CSS Style
Some tests refer to "CSS Style" information. Assemble the
CSS Style by using the contents of:
the
style
attribute of any element (use of the
style
attribute is deprecated in XHTML Basic 1.1
[XHTML Basic 1.1]
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"
(case-insensitive).
resources linked via
link
elements and
xml-stylesheet
processing instructions, where:
the
rel
attribute contains
"stylesheet" but not
"alternate" (case-insensitive)
the
charset
attribute is either not present or
is present with value "UTF-8"
(case-insensitive)
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" (case-insensitive).
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 list is either not present or is present
and contains the value "all" or
"handheld"
In the course of assembling the CSS Style use only those CSS rulesets that
are not restricted as to their presentation media type or whose presentation media type
list contains "handheld" or
"all".
2.4.7 Included Resources
Some tests refer to 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, when represented in an absolute form.
Examples include image and style sheet resources.
When 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 the following:
the
src
attribute of
img
elements
the
data
attribute of
object
elements (see
notes below)
the
href
attribute of
link
elements and
xml-stylesheet
processing instructions as defined
in
2.4.6 CSS Style
images included by
background-image
and
list-style-image
properties in the CSS Style (see
2.4.6 CSS Style
@import
directives in the CSS Style - providing they
are unqualified as to presentation media type or qualified by
presentation media type "handheld" or
"all" (case-insensitive) as defined in
2.4.6 CSS Style
Note:
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.
Note:
Resources that are retrieved as references from
object
elements and whose
Content-Type
HTTP header is not set to "image/jpeg" or "image/gif" are not considered to be Included Resources as discussed under
3.15.1 Object Element Processing Rule
(i.e. objects that are "tasted" to determine their Internet content type but are then discarded are not Included Resources). Their treatment, as regards
3.16
PAGE_SIZE_LIMIT
and
3.6
EXTERNAL_RESOURCES
, is described in the relevant section.
Note:
Resources referenced by descendants of an
object
element that itself refers to an Included Resource are not considered to be Included Resources as discussed under
3.15.1 Object Element Processing Rule
(i.e. any
img
or
object
element which occurs in the fall-back of an acceptable
object
element is not an Included Resource).
2.4.8 Linked Resources
Linked Resources are resources linked to from the resource being tested
(other than the resource itself), but which are not vital to rendering that
resource whose URI begins with the "http" or
"https" scheme when represented in an absolute form.
Linked resources are defined as those that are referenced by:
the
href
attribute of
(anchor)
elements.
the
action
attribute of
form
elements whose
method
attribute is not present or is present with
value "get" (case-insensitive).
Note:
Forms with
method
attribute "POST"
(case-insensitive) are permissible in documents under test, but
are not checked by mobileOK Basic (posting might cause side
effects such as the addition of unwanted records to a
database).
Note:
When submitting forms use default values where supplied,
otherwise supply empty values.
2.4.9 Validity
Several tests refer to the validity of aspects of a resource. This section
defines specifically what this means.
CSS
A resource is considered a valid CSS resource if it conforms to
the grammar defined in
[CSS Level 1]
Appendix B
. The presence of at-rules, properties or values or
combinations of properties and values that are not specified in
[CSS Level 1]
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 list for the
@import
at-rule are taken into account when evaluating CSS.
GIF
An image is a valid GIF image if it conforms to the grammar
defined in section 25 of the
[GIF]
specification.
JPEG
An image is a valid JPEG image if it follows the format defined
in Annex B of the
[JPEG]
specification
UTF-8
A resource is considered to be valid UTF-8 if its bytes represent
the valid UTF-8 encoding of some string, as defined in
[RFC 3629]
section 4
2.4.10 White Space
Several tests refer to white space. White space has the same definition in
this document as in XML. For XML 1.0
[XML 1.0]
it is defined in
as being:
S ::= (#x20 | #x9 | #xD | #xA)+
i.e. the characters SP, TAB, CR
and LF.
3 mobileOK Basic Tests
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 first in dictionary
order.
3.1
AUTO_REFRESH
and
REDIRECTION
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 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
3.2
CACHING
The purpose of the test is to alert providers to the fact that their content may
not 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, the value of the HTTP header
must
be used - see also note under
2.4.5 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
Continue the test using the value from the
meta
content
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
3.3
CHARACTER_ENCODING_SUPPORT
and
CHARACTER_ENCODING_USE
The DDC is defined to support only UTF-8 encoding, and hence this test fails if a
resource 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
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
... ...
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.4.9 Validity
),
FAIL
For each resource specified by
2.4.7 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
3.4
CONTENT_FORMAT_SUPPORT
and
VALID_MARKUP
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.
Note:
In the following,
"a known
XHTML version"
means XHTML Basic 1.0, XHTML Basic 1.1, XHTML-MP
1.0, XHTML-MP 1.1 or XHTML-MP 1.2.
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
FAIL
If the
DOCTYPE
is not an XML
DOCTYPE
warn
If the document is an
HTML
document
and it has an XML
DOCTYPE
If the document does not declare the html namespace on its
html
root element,
FAIL
If the
DOCTYPE
refers to
a known XHTML version
, validate against that
DOCTYPE
and if invalid,
warn
Otherwise (if the
DOCTYPE
is not known),
warn
If (
regardless of its stated
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.4.7 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.4.9 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.4.9 Validity
),
FAIL
3.5
DEFAULT_INPUT_MODE
Note:
inputmode
is part of
[XHTML Basic 1.1]
For each
input
element with attribute
type
whose value is "text" or
"password" or whose
type
attribute is
missing:
If the element's
inputmode
attribute is
invalid according to
Section 5.2 User Agent
Behavior
of XHTML Basic 1.1
[XHTML Basic 1.1]
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
[XHTML Basic 1.1]
FAIL
If the element is empty and an
inputmode
attribute is not present,
warn
3.6
EXTERNAL_RESOURCES
Retrieve the resource under test, and add the number of retrievals required to obtain the resource (see
2.4.4 HTTP Response
) to a running total.
For each unique Included Resource, as defined in
2.4.7 Included Resources
Request the referenced resource
Add the number of HTTP requests that are required to retrieve the resource (see
2.4.4 HTTP Response
) to the running total. Include in the count only those objects retrieved under the
3.15.1 Object Element Processing Rule
whose
type
attribute is not specified, and those whose content type is either "image/jpeg" or "image/gif" irrespective of whether the
type
attribute is specified.
If the total exceeds 10,
warn
If this total exceeds 20,
FAIL
3.7
GRAPHICS_FOR_SPACING
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 which is an Included Resource (see
2.4.7 Included Resources
):
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 is
present,
warn
3.8
IMAGE_MAPS
If an
input
element with
type
attribute set to "image" is present,
FAIL
For each
img
element and
object
element which is an Included Resource (see
2.4.7 Included Resources
):
If a
usemap
attribute is present,
FAIL
If an
ismap
attribute is present,
FAIL
3.9
IMAGES_RESIZING
and
IMAGES_SPECIFY_SIZE
Note:
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 which is an Included Resource (see
2.4.7 Included Resources
):
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
attribute is greater than the corresponding dimension of the image,
warn
If the value specified by either the height or width
attribute is less than the corresponding dimension of the image,
FAIL
3.10
LINK_TARGET_FORMAT
Note:
404 and 5xx HTTP status do not result in failure when conducting this
test.
Note:
The document body of linked resources is not examined.
For each linked resource, as defined in
2.4.8 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.4.3 HTTP Request
warn
If the
Content-Type
header value of the HTTP
response does not specify a
charset
parameter, or does but it
is not consistent with the value of the
Accept-Charset
header
in
2.4.3 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. '#'),
warn
3.11
MEASURES
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 (see
2.4.6 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" (and the value is not a
percentage), and the property is not a margin, border or padding box
property,
FAIL
3.12
MINIMIZE
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.10 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
3.13
NO_FRAMES
If the document contains a
frame
frameset
or
iframe
element,
FAIL
3.14
NON-TEXT_ALTERNATIVES
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
contains only white space
FAIL
3.15
OBJECTS_OR_SCRIPT
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
and
link
element:
If the value of the
href
attribute begins
with the "javascript:" scheme,
FAIL
If an
applet
element is present,
FAIL
Set the context to the root element and apply the
Object
Element Processing Rule
3.15.1 Object Element Processing Rule
For each
img
element that has no
object
element ancestor (other than the context node) in this context:
Treat this image as an Included Resource (and carry out appropriate tests).
For each
object
element that has no
object
element ancestor (other than the context node) in this context:
If the
object
element is empty,
warn
If the content of the
object
element consists only of
white space,
FAIL
If there is no
type
attribute,
warn
If it is not already cached (see
2.4.7 Included Resources
), retrieve the referenced resource (ignoring the
type
attribute)
If the Internet media type of the retrieved resource, as indicated by its
Content-Type
HTTP header does not match that stated in the
type
attribute,
warn
If the Internet media type indicated by the
Content-Type
HTTP Header of the retrieved resource is not "image/jpeg" or "image/gif",
warn
Reapply this rule using the current
object
element as the
context
Otherwise (the object is an acceptable image):
Treat this object as an Included Resource (and carry out appropriate tests), ignore
img
and
object
elements that are descendants of the current
object
element.
Note:
A warning is issued when the Internet media type indicated by the
type
attribute is not compatible with the Default Delivery Context because some user agents do not take into account the
type
attribute of
object
elements and this may cause the user agent to retrieve large incompatible objects with consequences to performance and cost.
Note:
An HTTP 406 status on retrieval of a resource referenced by an object
element does not constitute a FAIL.
3.16
PAGE_SIZE_LIMIT
Retrieve the document under test, if its size (excluding any redirections discussed under
2.4.4 HTTP Response
) exceeds 10 kilobytes,
FAIL
Add to a running total (total size) the size of all the HTTP response bodies that are required to retrieve the document under test (
2.4.4 HTTP Response
).
For each unique Included Resource, as defined in
2.4.7 Included Resources
Add the size of all the response bodies that are required to retrieve the resource (see
2.4.4 HTTP Response
) to the running total. Include in the total only those objects retrieved under the
3.15.1 Object Element Processing Rule
whose
type
attribute is not specified, and those whose Internet media type as indicated by the
Content-Type
HTTP header is either "image/jpeg" or "image/gif" irrespective of whether the
type
attribute is specified.
If the total exceeds 20 kilobytes,
FAIL
Note:
In the case of resources that are referenced more than once in the document under test, and where, as discussed under
2.4.7 Included Resources
, they are cached, it is the initial retrieval of that resource (as determined by the first reference in document order) that counts towards the total.
Note:
Where the
3.15.1 Object Element Processing Rule
yields a resource that is found to be cached, objects that must be assessed in the course of yielding the cached resource count towards the total.
3.17
PAGE_TITLE
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
(see
2.4.10 White Space
),
FAIL
3.18
POP_UPS
For each
link
form
, and
base
element:
If a
target
attribute is present,
If its value is not one of "_self",
"_parent", or "_top",
FAIL
3.19
PROVIDE_DEFAULTS
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 "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
3.20
STYLE_SHEETS_SUPPORT
If the CSS Style (see
2.4.6 CSS Style
) contains rules referencing
the
position
display
or
float
properties,
warn
3.21
STYLE_SHEETS_USE
This test looks for elements in the
Text Extension module
defined
by
[XHTML Modularization]
, some of which are not supported in
XHTML Basic
[XHTML Basic 1.1]
. 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:
This test does not require that any CSS Style is used, since in some cases,
no 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
strike
or
elements,
FAIL
If the document contains any
big
small
sub
sup
or
tt
elements,
warn
If any element has a
style
attribute,
warn
If all styles are restricted to presentation 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 presentation media type list of the
@import
at-rule), properties, or values that are not recognized
as being specified in CSS Level 1, or if the value of a recognized CSS Level 1 property is incompatible with the property,
warn
3.22
TABLES_ALTERNATIVES
If a
table
element exists,
warn
3.23
TABLES_LAYOUT
This test does not catch all cases where tables are used for layout purposes.
For each
table
element:
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
3.24
TABLES_NESTED
For each
table
element:
If it contains a
table
element,
FAIL
A Acknowledgments (Non-Normative)
The editors would like to thank members of the BPWG for contributions of various
kinds.
The editors acknowledge significant written contributions from:
Dominique Hazaël-Massieux, W3C
Phil Archer, ICRA
François Daoust, W3C
B References (Non-Normative)
Best Practices
Mobile Web Best
Practices 1.0, Jo Rabin, Charles McCathieNevile, W3C Recommendation, 29 July 2008 (See
CSS Level 1
Cascading Style Sheets, level 1, Håkon Wium Lie, Bert Bos, W3C Recommendation 17 Dec 1996, revised 11 Jan 1999 (See
GIF
GRAPHICS INTERCHANGE FORMAT, Version
89a, CompuServe Incorporated, 1990 (See
JPEG
Recommendation T.81, 18 September 1992 (See
RFC 2119
Key words for use in RFCs to Indicate
Requirement Levels, S. Bradner, March 1997 (See
RFC 2616
Hypertext Transfer Protocol --
HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See
RFC 2617
HTTP Authentication: Basic and Digest Access Authentication,
J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L.
Stewart, June 1999 (See
RFC 3629
UTF-8, a transformation format of ISO 10646, F. Yergau,
November 2003 (See
WCAG 1.0
Web Content Accessibility Guidelines 1.0,
W. Chisholm, G. Vanderheiden and I. Jacobs, eds., W3C Recommendation, 5 May 1999 (See
XHTML Basic 1.1
XHTML™ Basic 1.1, Mark Baker, Masayasu Ishikawa, Shinichi Matsui, Peter Stark, Ted Wugofski, Toshihiko Yamakami (eds), W3C Recommendation, 29 July 2008 (See
XHTML Modularization
XHTML™
Modularization 1.1, Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa, Mark Birbeck (eds), W3C Recommendation, 08 October 2008 (See
XML 1.0
Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim
Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, W3C
Recommendation 26 November 2008 (See
C Relationship between Best Practices and mobileOK Tests (Non-Normative)
This appendix lists all Best Practices and indicates whether each has a corresponding
test in mobileOK Basic.
Best Practice
mobileOK Basic
ACCESS_KEYS
AUTO_REFRESH
AVOID_FREE_TEXT
BACKGROUND_IMAGE_READABILITY
BALANCE
CACHING
CAPABILITIES
CENTRAL_MEANING
CHARACTER_ENCODING_SUPPORT
CHARACTER_ENCODING_USE
CLARITY
COLOR_CONTRAST
CONTENT_FORMAT_PREFERRED
CONTENT_FORMAT_SUPPORT
CONTROL_LABELLING
CONTROL_POSITION
DEFAULT_INPUT_MODE
DEFICIENCIES
ERROR_MESSAGES
EXTERNAL_RESOURCES
FONTS
GRAPHICS_FOR_SPACING
IMAGE_MAPS
IMAGES_RESIZING
IMAGES_SPECIFY_SIZE
LARGE_GRAPHICS
LIMITED
LINK_TARGET_FORMAT
LINK_TARGET_ID
MEASURES
MINIMIZE
MINIMIZE_KEYSTROKES
NAVBAR
NO_FRAMES
NON-TEXT_ALTERNATIVES
OBJECTS_OR_SCRIPT
PAGE_SIZE_LIMIT
PAGE_SIZE_USABLE
PAGE_TITLE
POP_UPS
PROVIDE_DEFAULTS
REDIRECTION
SCROLLING
STRUCTURE
STYLE_SHEETS_SIZE
STYLE_SHEETS_SUPPORT
STYLE_SHEETS_USE
SUITABLE
TAB_ORDER
TABLES_ALTERNATIVES
TABLES_LAYOUT
TABLES_NESTED
TABLES_SUPPORT
TESTING
THEMATIC_CONSISTENCY
URIS
USE_OF_COLOR
VALID_MARKUP