Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines the tests that provide the basis for making a claim of W3C® mobileOK Basic™ conformance and are based on W3C Mobile Web Best Practices [BestPractices]. Content which passes the tests has taken some steps to provide a functional user experience for users of basic mobile devices whose capabilities at least match those of the Default Delivery Context (DDC).
mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK Pro, 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 a Candidate Recommendation of mobileOK Basic Tests 1.0. It reflects changes arising from three Last Call periods. The Working Groups does not expect substantive changes in the document from this point.
A complete Disposition of Comments record for this document is available.
In order for this document to transition from Candidate Recommendation status, the group has recorded the following exit criteria:
The group doesn't expect to request transition to Proposed Recommendation before 10 January 2008.
Publication as a Candidate 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 . Please send comments on this document to the Working Group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list .
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Levels of mobileOK
1.1.1 mobileOK Basic
1.1.2 mobileOK
Pro
1.1.3 Out of Scope
1.1.4 Beyond mobileOK
1.2 Applicability
1.3 Claiming mobileOK conformance
2 Conformance
2.1 Use of Terms must, should etc.
2.2 Validity of the Tests
2.3 Testing Outcomes
2.4 Conduct of Tests
2.4.1 Order of Tests
2.4.2 HTTP Request
2.4.3 HTTP Response
2.4.4 Meta http-equiv Elements
2.4.5 CSS Style
2.4.6 Included Resources
2.4.7 Linked Resources
2.4.8 Validity
2.4.9 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.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] 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.
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.
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 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, 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 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 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.
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. 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 [RFC2119] 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. In any test, PASS is achieved if and only if there are no FAILs. No specific PASS outcome is defined for any test.
Tests may also generate a number of informative warnings which do not affect whether a test has PASSed or not. A warning 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.
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 Linked Resources for a discussion of the
POST method).
Include a
User-Agent header indicating the default delivery context by sending exactly this header:
User-Agent: W3C mobileOK DDC (http://www.w3.org/2006/07/mobileOK-ddc)
Include an
Accept header indicating that Internet media types understood by the default delivery context are accepted by sending exactly this header:
Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
Include an
Accept-Charset header indicating that only UTF-8 is accepted by sending exactly this header:
Accept-Charset: UTF-8
Do not include cookie related headers.
Include authentication information if required (see 2.4.3 HTTP Response). Once authentication information has been included in a request, subsequent requests for the same realm must include authentication information as described in Section 2 and under "domain" in Section 3.2.1 of [RFC2617].
Implementations
must support URIs with both
http and
https scheme components.
Note:
As noted under
2.4.6 Included Resources and
2.4.7 Linked Resources the URIs that are relevant to mobileOK are those that, when represented in an absolute form, have 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 (see 2.4.6 Included Resources):
Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
If there is no HTTP
Location header,
FAIL.
If the URI identified by the HTTP
Location header is a relative URI, create an absolute URI by combining the value of the
Location header with the absolute URI of the request to which this is a response,
warn
If the resulting URI is not a URI with the scheme
http or
https,
FAIL.
Re-request the resource 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.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.4.7 Linked Resources):
Continue with the test (see 3.10 LINK_TARGET_FORMAT, i.e. do not re-request the resource with authentication information), 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 Linked Resources), continue with the test (see 3.10 LINK_TARGET_FORMAT) and warn
Otherwise (i.e. for included resources), FAIL
If the HTTP status represents failure (4xx), other than 404 or a request for authentication (e.g. 401), FAIL
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])
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 is either not present or is present and contains values "all" or "handheld"
In the course of assembling the CSS Style use only those CSS rulesets that are not restricted as to their CSS media type or whose CSS media type specifier contains "handheld" or "all".
Some tests refer to a notion of included resources, which are resources external to the resource being tested and yet vital to rendering that resource and whose URI has the "http" or "https" scheme, 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
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 CSS Style
images included by
background-image and
list-style-image properties in the CSS Style (
2.4.5 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 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:
For nested
object elements, count only the number of objects that need to be assessed as discussed in
3.15
OBJECTS_OR_SCRIPT .
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],
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] does not constitute a validity failure for CSS. See
3.21
STYLE_SHEETS_USE for treatment of such values. In addition, the
@media at-rule and the presentation media qualifiers for the
@import at-rule are taken into account when evaluating CSS.
An image is a valid GIF image if it conforms to the grammar defined in section 25 of the [GIF] specification.
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
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.
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 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 Validity), FAIL
For each resource specified by 2.4.6 Included Resources:
Request the resource
If the HTTP
Content-Type header value of the response starts with "text/" but does not specify UTF-8 character encoding,
warn
Note:
In the following, an "html document" is a document that has "html" as its root element.
Note:
In the following,
"regardless of its stated
DOCTYPE" means that when assessing validity against the XHTML Basic 1.1 and XHTML MP 1.2 DTDs this may be carried out by inserting a
DOCTYPE if none is present, or by replacing the given
DOCTYPE with the appropriate
DOCTYPE for the DTD under test.
If the document's Internet media type, as specified in the HTTP response
Content-Type header, is not "application/xhtml+xml", "application/vnd.wap.xhtml+xml", or "text/html",
FAIL
If the document's Internet media type is "text/html" or "application/vnd.wap.xhtml+xml", warn
If the document does not contain a
DOCTYPE declaration,
FAIL
If the document is not an
HTML document or it fails to validate according to its given
DOCTYPE,
FAIL
If the document does not declare the html namespace on its html root element, FAIL
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.6 Included Resources):
If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL
If an image is required (see also 3.15 OBJECTS_OR_SCRIPT ) and the response specifies an Internet media type that is not "image/jpeg" or "image/gif", FAIL
If the Internet media type is "image/gif" or "image/jpeg", and the resource is not valid (see 2.4.8 Validity), FAIL
If a style sheet is required and the response specifies an Internet media type that is not "text/css", FAIL
If the Internet media type is "text/css" and the content is not valid CSS (see 2.4.8 Validity), FAIL
Note:
inputmode is part of
[XHTMLBasic11].
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],
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
Make an inventory of unique included resources, as defined in 2.4.6 Included Resources.
For each such resource:
Request the resource and carry out the procedures discussed under 2.4.3 HTTP Response maintaining a running total of requests made. FAILures that occur in the course of making this assessment contribute to the result of this test.
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 warns about the presence of small (at most 2x2) transparent images and FAILs 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 an Internet media type that starts with "image/":
If all pixels are transparent,
If image height and width are both less than or equal to 2 pixels, warn
If either dimension exceeds 2 pixels, FAIL
If more than one image with all transparent pixels was encountered, warn
If an
input element with
type attribute set to "image" is present,
FAIL
For each
img element
and
object element:
If a
usemap attribute is present,
FAIL
If an
ismap attribute is present,
FAIL
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/":
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 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.2 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 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 ( 2.4.5 CSS Style) whose value is a numeric measure of length stated together with a unit:
If the value is non-zero and the unit is not "em" or "ex" (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 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
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",
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
If an
object element is present
and has no
object element ancestor,
If the
innermost nested
object element is empty,
warn
If the
innermost nested
object element content consists only of white space (see
2.4.9 White Space),
FAIL
If none of the nested
object elements is an image that has a content type that matches the headers defined in
2.4.2 HTTP Request and the innermost nested
object element is non-empty and does not consist of text or an
img element that refers to an image that matches the headers defined in
2.4.2 HTTP Request,
FAIL
If the size of the document exceeds 10 kilobytes, FAIL
Add the size to a running total
For each included resource, as defined in 2.4.6 Included Resources:
Request the referenced resource
Add the size of the response body to the running total
(for nested
object elements count only the first object that matches the headers specified in
2.4.2 HTTP Request, if there is one)
If the total exceeds 20 kilobytes, FAIL
This test does not determine whether the title is meaningful.
If a
title element is not present in the
head element, or is empty, or contains only white space (see
2.4.9 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
In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.
For each radio button group within a
form element (
input elements with
type "radio" that share the same
name attribute value):
Check that exactly one
input element within this group has its
checked attribute set to "checked", and if this is not the case,
warn
For each
select element:
If there is no nested
option element whose
selected attribute is set to "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
In addition, a human test is needed here to verify whether the page is readable without a style sheet.
If the CSS Style (
2.4.5 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], some of which are not supported in XHTML Basic [XHTMLBasic11]. It also looks for commonly-used elements and attributes that were deprecated in HTML 4, and are not supported, or are deprecated, in XHTML Basic.
Note:
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).
Note:
The tests on CSS property values only apply to properties defined by CSS Level 1; other properties are ignored for the purposes of this test.
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 media types other than "handheld" or "all" by means of @media at-rules, warn
If the CSS Style contains at-rules (other than the
@media at-rule, and the media list of the
@import at-rule), properties, or values that are not recognized as being specified in CSS Level 1,
warn
If the CSS Style contains a property with a value that is inappropriate to it, warn
If the CSS Style contains a property with a value that requires a unit or a percentage:
If the unit (or percentage) is not present, warn
If the unit (or percentage) is inappropriate to the value, warn
If a
table element exists,
warn
This test does not catch all cases where tables are used for layout purposes.
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.