Copyright © 2008 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] [Best
Practices] . Content
The details of how to claim mobileOK
conformance will be described separately. Providers of
content which passes the tests has 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 is the lesser of two levels
of claim, the greater level being mobileOK Pro, described
separately. Claims to be W3C mobileOK conformant are represented
using Description Resources (see [POWDER] ), also described
separately. 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.
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 the fourth Last Call Working
Draft a Proposed Recommendation
of mobileOK Basic Tests 1.0. It reflects changes arising from implementation experience of
made as a result
of feedback received during the previous
Candidate Recommendation phase and of
comments received during the
following Last Call review period.
A
disposition of comments report
is available. The entrance criteria to
Proposed Recommendation are met and detailed in the
implementation report . To
The changes made to the document since
last publication as a Last Call Working Draft are editorial
clarifications with a view to removing potential ambiguities in the
way some of tests need to be conducted. See the accompanying
diff document
to view the list
of changes made to this document since the previously
published (30 November 2007) Candidate
Recommendation version, see the accompanying diff document .
The (10 June 2008) Last Call Working
Draft. Main changes are:
object
The This
document has been produced by the Mobile Web
Best Practices Working Group does not
expect more substantive changes to as part of the Mobile
Web Initiative .
This document from this point. In fact, is
considered stable by the Mobile Web
Best Practices Working Group expects to
be able to transition Group. W3C
Advisory Committee Representatives are invited to Proposed Recommendation at submit their formal review per the end of instructions in
the Last Call review period. The following recorded exit criteria to
meet to exit the Candidate Recommendation are expected to be met at
that time for Review (see the
implementation report
Advisory Committee questionnaire ):
existence of ten highly visible mobileOK-compliant Web pages
representing a number of different applications; existence of a
checker that checks each aspect of each test specified in this
document; existence of a test suite to verify the correct operation
of mobileOK checkers. ). 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 30 June
). The review period ends on 01
December 2008.
Publication as a Working Draft
Proposed Recommendation 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 Levels of
mobileOK Scope
1.1.1 mobileOK Basic Relationship to Best Practices
1.1.2 mobileOK Pro
1.1.3
Out of Scope
1.1.4
1.1.3
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.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.3
2.4.4
HTTP Response
2.4.4
2.4.5
Meta http-equiv Elements
2.4.5
2.4.6
CSS Style
2.4.6
2.4.7
Included Resources
2.4.7
2.4.8
Linked Resources
2.4.8
2.4.9
Validity
2.4.9
2.4.10
White Space
3 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
A 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] [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.
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 .
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] ) have been followed. 1.1.2 mobileOK Pro 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]
[WCAG 1.0] ) have been
followed.
Some best practices, Best Practices, like TESTING , are
advisable but do not meaningfully translate into concrete
tests, whether their outcome is machine- or
human-verifiable. 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.
The best practices, 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.
The tests apply to a URI. Passing the tests means that when
accessed as described in 2.4.2 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
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.
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 Pro
. 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.
Where terms are used with the meanings defined in [RFC 2119] they are highlighted in the text e.g. must .
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. 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.
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.
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
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.7 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 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.3 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.6 2.4.7 Included Resources and 2.4.7 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
.
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.
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 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 Included Resources (see
2.4.6 2.4.7 Included
Resources ):
Include the size of the response in the
total "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 Included Resources (see
2.4.6 2.4.7 Included
Resources ):
If authentication information was supplied
in the HTTP request (i.e. authentication failed), failed) or if no
authentication information is available, FAIL
Carry out tests on the response
Include the size of the response in the
total "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.7 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.7 2.4.8 Linked Resources ), continue with
the test (see 3.10 LINK_TARGET_FORMAT ) and warn
Otherwise (i.e. for included resources), Included Resources), FAIL
If the HTTP status represents failure (4xx),
other than 404 or 404, a request for authentication (e.g.
401), 401) or a
406 when carrying out the 3.15.1 Object Element Processing Rule ,
FAIL
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
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
[XHTMLBasic11]
[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 descriptor
list is either not present or is
present and contains values 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 CSS presentation media
type or whose CSS presentation media type specifier list
contains "handheld" or "all".
Some tests refer to a notion of included
resources, 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 Resources are defined as those that are referenced
by: 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.5 2.4.6 CSS Style
images included by background-image
and
list-style-image
properties in the CSS Style
( (see
2.4.5 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.5 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 that
are accessed in order to test their and
whose Content-Type
HTTP header, but do header
is not form part of the ultimate
representation of the resource set to
"image/jpeg" or "image/gif" are not considered to be Included
Resources as discussed under test
(see 3.15 OBJECTS_OR_SCRIPT
3.15.1 Object Element Processing
Rule ), (i.e. objects that are not
considered "tasted" to
be included resources. 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).
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 a
(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.
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] [CSS Level
1] , Appendix B (see note below) , except that @media at-rules, which
are not part of the grammar, are allowed and are not considered
invalid. . The presence of at-rules, properties or values
or combinations of properties and values that are not specified in
[CSS] [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 qualifiers
list 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.
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] [RFC 3629] , section 4
Several tests refer to white space. White space has the same
definition in this document as in XML. For XML 1.0 [XML10] [XML 1.0] 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.
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.
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
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.4 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
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
<?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 ; 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.4.8 2.4.9
Validity ), FAIL
For each resource specified by 2.4.6 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
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 Included Resource (see
2.4.6 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.8
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.8 2.4.9 Validity ), FAIL
Note:
inputmode
is part of [XHTMLBasic11]
[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 [XHTMLBasic11]
[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 [XHTMLBasic11]
[XHTML Basic 1.1] , FAIL
If the element is empty and an
inputmode
attribute is not present, warn
Retrieve the resource under test, and add
the number of retrievals required to obtain the resource (see
2.4.3 2.4.4 HTTP
Response ) to a running total.
For each unique included resource, Included
Resource, as defined in 2.4.6 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.3 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
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 when
retrieved has is an Internet media type that starts with "image/" :
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 was encountered, is present, warn
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
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 whose type
attribute starts with "image/" : 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
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.7 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 media
types listed in the Accept
header in 2.4.2 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.2 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
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.5 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
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 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 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 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
If the document contains a frame
, ,frameset
or
iframe
element or it contains an
object element which when retrieved has an Internet media type that
starts with "text/", "application/xhtml+xml" or
"application/vnd.wap.xhtml+xml" , element, 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 contains only white space , 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
Set the context to the root element and apply the Object Element Processing Rule
For each object
img
element that has no
object
element ancestor in this
context (excepting (other than
the context node itself): node) in this context:
Retrieve the object
(ignoring the type attribute) Treat
this image as an Included Resource (and carry out appropriate
tests).
For each
object
element that has
no is not "image/jpeg" or
"image/gif"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)
For each
If the Internet media type of the retrieved
resource, as indicated by its img Content-Typeelement HTTP header does not
match that has no stated in the object typeelement ancestor in this context:
attribute, warn
If the content
Internet media type of indicated by the
img Content-Typeelement HTTP Header of the
retrieved resource is not "image/jpeg" or "image/gif",
FAIL 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.
Retrieve the document
under test, if its size (excluding any redirections discussed
under Note: 2.4.4 HTTP Response ) exceeds 10 kilobytes, FAIL
Add to a running total
(total size) the following,
include 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
content 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 size of the
document total exceeds
10 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.6 2.4.7 Included
Resources : Request the referenced
resource Add , they are cached, it
is the size initial retrieval of that
resource (as determined by the response
body to first reference in document
order) that counts towards the running
total total.
Note:
Where the total exceeds 20 kilobytes, FAIL 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.
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.9 2.4.10 White Space ), 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
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
If the CSS Style ( (see 2.4.5 2.4.6 CSS Style ) contains rules
referencing the position
, display
or
float
properties, warn
This test looks for elements in the
Text Extension module defined by [XHTMLModularization] [XHTML
Modularization] , some of which are not supported in
XHTML Basic [XHTMLBasic11] [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 styles be 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
, 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 CSS Style
( 2.4.5 CSS Style ) If all styles are restricted to
presentation media types other than
"handheld" or "all" by means of @media
at-rules, warnat- rules,
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, warn If or if the CSS Style contains
a property with a value that is
inappropriate to it, warn If the CSS Style contains
of a recognized
CSS Level 1 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 incompatible with the value, property,
warn
If a table
element exists,
warn
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
For each table
element:
If it contains a table
element,
FAIL
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 Pro, both, or neither. mobileOK Pro is a
super-set of mobileOK Basic and so any Best Practice with a
corresponding test in mobileOK Basic implicitly has a corresponding
test in 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.
Best Practice | mobileOK Basic |
---|---|
ACCESS_KEYS | |
AUTO_REFRESH | X |
AVOID_FREE_TEXT | |
BACKGROUND_IMAGE_READABILITY | |
BALANCE | |
CACHING | X |
CAPABILITIES | |
CENTRAL_MEANING | |
CHARACTER_ENCODING_SUPPORT | X |
CHARACTER_ENCODING_USE | X |
CLARITY | |
COLOR_CONTRAST | |
CONTENT_FORMAT_PREFERRED | |
CONTENT_FORMAT_SUPPORT | X |
CONTROL_LABELLING | |
CONTROL_POSITION | |
COOKIES | |
DEFAULT_INPUT_MODE | X |
DEFICIENCIES | |
ERROR_MESSAGES | |
EXTERNAL_RESOURCES | X |
FONTS | |
GRAPHICS_FOR_SPACING | X |
IMAGE_MAPS | X |
IMAGES_RESIZING | X |
IMAGES_SPECIFY_SIZE | X |
LARGE_GRAPHICS | X |
LIMITED | |