Copyright © 2006-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, described separately. Claims to be W3C mobileOK Basic compliant are represented using content labels, also described separately.
mobileOK assesses interoperability. It does not measure usability and does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Last Call Working Draft of mobileOK Basic Tests 1.0; it incorporates various refinements of the tests presented in the first two drafts; see the changes-marked version which highlights all the changes since the previous publication of this document. The document includes a set of editors notes on which feedback would be appreciated, in particular on the UTF-8 requirement. The Working Group would also like feedback from Web content developers on the perceived difficulty of getting the mobileOK Basic status as described in this document.
The Last Call review period for this documents extends until 6 March 2007. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Levels of mobileOK
1.1.1 mobileOK Basic
1.1.2 mobileOK
1.1.3 Out of Scope
1.1.4 Beyond mobileOK
1.2 Applicability
1.3 Claiming mobileOK conformance
2 Conformance
2.1 Validity of the Tests
2.2 Testing Outcomes
2.3 Conduct of Tests
2.3.1 Order of Tests
2.3.2 HTTP Request
2.3.3 HTTP Response
2.3.4 CSS Style
2.3.5 Included Resources
2.3.6 Included Stylesheet Resources
2.3.7 Visible Linked Resources
3 mobileOK Basic Tests
3.1 AUTO_REFRESH (partial) and REDIRECTION
3.2
CACHING
3.3
CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
3.4
CONTENT_FORMAT_SUPPORT
3.5
DEFAULT_INPUT_MODE
3.6
EXTERNAL_RESOURCES
3.7
GRAPHICS_FOR_SPACING
3.8
IMAGE_MAPS
3.9
IMAGES_RESIZING and
IMAGES_SPECIFY_SIZE
3.10
LINK_TARGET_FORMAT
3.11
MEASURES
3.12
MINIMIZE
3.13
NO_FRAMES
3.14
NON-TEXT_ALTERNATIVES (partial)
3.15
OBJECTS_OR_SCRIPT (partial)
3.16
PAGE_SIZE_LIMIT
3.17
PAGE_TITLE (partial)
3.18
POP_UPS
3.19
PROVIDE_DEFAULTS (partial)
3.20
SCROLLING (partial)
3.21
STYLE_SHEETS_SUPPORT (partial)
3.22
STYLE_SHEETS_USE
3.23
TABLES_ALTERNATIVES
3.24
TABLES_LAYOUT (partial)
3.25
TABLES_NESTED
3.26
VALID_MARKUP
A Acknowledgements (Non-Normative)
B References (Non-Normative)
C Best Practices' Relation to mobileOK Tests (Non-Normative)
This document describes W3C mobileOK Basic tests, which are based on Mobile Web Best Practices [BestPractices].
mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK, described separately. Claims to be W3C mobileOK Basic are represented using content labels, also described separately.
The intention of mobileOK is to help catalyze development of Web sites that provide a functional user experience in a mobile context.
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.
The (full) mobileOK 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 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.
mobileOK tests will be described separately.
Note that some best practices, like TESTING, are advisable but do not meaningfully translate into concrete tests, whether their outcome is machine- or human-verifiable.
The tests do not assess usability, rather, they assess whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices.
The best practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. Many devices' capabilities exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.
Content providers should provide an experience that is mobileOK conformant to ensure a basic level of interoperability. Providers are encouraged to provide enhanced experiences as well when these are appropriate to their application and devices that are accessing them.
The tests apply to a URI. Passing the tests means that under the right circumstances, resolving a URI will retrieve conformant content that is delivered in a conformant manner.
That is, the tests do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. VALID_MARKUP), but to how it is delivered to a mobile device (e.g. CACHING). For convenience, this document refers to "mobileOK content" with the understanding that it refers to more than just the content itself.
mobileOK 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. It will be possible to make claims in a machine-processable form. It will also be possible to notify end users of the presence of the claim by means of a human-readable mark.
mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.
The details of the mechanism will be described separately.
This section details the tests that must be carried out in order to claim mobileOK Basic. Tests are presented as simple pseudo-code.
mobileOK tests are only meaningful when the URI under test resolves to HTML content delivered over HTTP.
Individual tests may result in PASS or FAIL. PASS is required from all tests in order to claim mobileOK Basic.
Tests may also generate a number of informative warnings.
mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently. Some tests have been designed to assess aspects of the content that are disallowed by other tests; this is deliberate and is intended to allow testing environments to provide as much information as possible.
For example the test for 3.22
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
.
Creators of implementations of the tests described in this document are encouraged to provide as much information as possible to users of their implementations. Where possible they should not stop on FAIL and specifically they should:
Provide information about the cause of failure
Continue individual tests as far as is possible
Carry out as many tests as is reasonable
The following HTTP request headers inform the server that it should deliver content that is compatible with the Default Delivery Context.
Use the HTTP GET method when making requests
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
If an HTTP response specifies an HTTP 3xx status, a test implementation should attempt to respect the server's response (e.g. follow a 302 redirect). Note that redirects should be counted against the limit defined in the 3.6 EXTERNAL_RESOURCES test.
If an HTTP request fails for any reason during a test (network-level error, DNS resolution error, non-HTTP response, or server returns an HTTP 4xx or 5xx status), the test outcome should be considered FAIL.
Documents sometimes include meta elements with an http-equiv attribute. These are sometimes
considered substitutes for HTTP response headers. Test implementations should respect only HTTP response headers.
For each meta element that exists, however, if a response header exists whose name matches its
http-equiv attribute value, and the header's value differs from the element's content
attribute value, the test should generate a warning.
Some tests refer to "CSS Style" information. Assemble the CSS Style by using the contents of:
the style attribute of any element
style elements whose type attribute is not
"text/css", and whose media attribute is either not present or is present and contains
value "all" or "handheld".
resources linked by xml-stylesheet processing instructions
external stylesheet resources linked via link elements, as defined in 2.3.6 Included Stylesheet Resources
resources linked by CSS @import at-rules
In the course of assembling the CSS Style:
observe the CSS Level 1 cascade
retrieve only those resources that have no CSS media type, or whose CSS media type contains "handheld" or "all"
use only those rules that are not restricted as to their CSS media type or whose media type contains "handheld" or "all"
For convenience, this section and those that follow provide definitions that are reused several times in the document.
Some tests refer to a notion of included resources, which are resources external to the resource being tested and yet vital to rendering that resource. Examples include image and stylesheet resources.
Included resources are defined as those that are referenced by:
img elements
object elements
link elements as defined in 2.3.6 Included Stylesheet Resources
images included by background-image properties in the CSS Style (2.3.4 CSS Style)
@import directives in the CSS Style (2.3.4 CSS Style)
xml-stylesheet processing instructions
Included stylesheet resources are, simply, included resources that are stylesheets.
They are defined as resources referenced
in the href attribute of link elements whose rel
attribute contains "stylesheet" but not "alternate",
charset attribute is either not present or is present with value "UTF-8",
type attribute is either not present or is present with value "text/css",
and whose media attribute is either not present or is present
and contains value "all" or "handheld".
Further, this definition only pertains to resources whose URI begins with
the "http" or "https" scheme.
Linked resources are resources linked to from the resource being tested, but which are not vital to rendering that resource. Examples include resources linked via hyperlinks.
Linked resources are defined as those that are referenced by:
the href attribute of a (anchor) elements, and whose URI begins with the "http" or "https" scheme
the action attribute of form elements whose method attribute is not present or is present with value "get"
This section describes tests for mobileOK Basic. Tests are organized alphabetically by the Best Practice from which they derive. Where a test derives from more than one Best Practice it is placed according to the one that occurs earliest in dictionary order.
This test does not determine whether the user is able to opt out of refresh.
If a meta element is present with http-equiv attribute value of "refresh",
If the URI specified in the content attribute is not the current resource's URI, FAIL
Else, warn
If a Refresh HTTP header is present,
If the URI specified in the header value is not the current page, FAIL
Else, warn
PASS
If the HTTP response contains neither an Expires nor Cache-Control header, FAIL
If a Cache-Control HTTP header is present and contains value "no-cache",
or contains value "max-age=0", warn
If a Pragma HTTP header is present and contains value "no-cache", warn
If an Expires and Date HTTP header are present,
and the Expires header specifies a date which is not later than what the Date header specifies,
or if the Expires header specifies an invalid date (e.g. "0"), warn
If the HTTP response contains a Last-Modified header,
Request the same URI again, adding an If-Modified-Since request header whose value
matches that of the Last-Modified response header
If the HTTP response contains a Last-Modified header and its value is again the same,
and the HTTP response status is not 304 (Not Modified), warn
If the HTTP response contains an ETag header,
Request the same URI again, adding an If-None-Match request header whose value
matches that of the ETag response header
If the HTTP response contains an ETag header and its value is again the same,
and the HTTP response status is not 304 (Not Modified), warn
PASS
The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource cannot be delivered in UTF-8. The test does not require that resource always be encoded in UTF-8; the test merely checks that the resource is available in UTF-8 encoding, if requested. Resources may be delivered to devices in other encodings where appropriate. This test verifies that a DDC-like device which only accepts UTF-8 encoding may access the resource in UTF-8 encoding.
This requirement, UTF-8 support, has been extensively debated and the group solicits feedback on it.
Determine the character encoding specified by the following, if present:
Content-Type header (e.g. "application/xhtml+xml;charset=UTF-8")
XML declaration (e.g. "<?xml encoding="UTF-8"?>")
meta element that is the first child of the
document's head element, and whose http-equiv attribute is "Content-Type",
and whose content attribute specifies a character encoding as above
(e.g. "<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>)
If character encoding is not explicitly specified in at least one of these ways, FAIL
If character encoding is specified in more than one way, and not all values are the same, FAIL
If any character encoding specified is not "UTF-8", FAIL
If the document is not valid UTF-8, FAIL
For each external resource as defined in 2.3.5 Included Resources:
Request the URI indicated by the href attribute
If the HTTP response Content-Type header value specifies an Internet media type
starting with "text/" but does not specify UTF-8 encoding (e.g. "text/css" only instead of "text/css;charset=UTF-8"), warn
PASS
If the document's Internet media type, as specified in the HTTP response Content-Type
header, is not "application/xhtml+xml", "application/vnd.wap.xhtml+xml", or "text/html", FAIL
If the document's Internet media type is "text/html" or "application/vnd.wap.xhtml+xml", warn
If the document does not validate against the XHTML Basic 1.1 DTD (regardless of its stated DOCTYPE), FAIL
For each included resource, as defined by 2.3.5 Included Resources:
If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL
If the Internet media type is "image/gif" or "image/jpeg", and the resource is invalid according to the specification of GIF89a or JPEG, respectively, FAIL
If the Internet media type is "text/css" and the content is not well-formed CSS (contains mismatching brackets or illegal characters), FAIL
PASS
Note that inputmode is part of [XHTMLBasic11].
For each input element with attribute type whose value is "text" or "password"
If the element's value attribute is missing or empty, and an inputmode attribute is not present, warn
For each textarea element:
If the element is empty and an inputmode attribute is not present, warn
PASS
Count the total number of unique included resources, as defined in 2.3.5 Included Resources.
For each such resource:
Request the resource, and add one to a running count
Add to the count the number of HTTP redirects (HTTP responses with status 301 or 302) that must be followed until the resource itself is successfully retrieved
If this total exceeds 10, warn
If this total exceeds 20, FAIL
PASS
The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often used in e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the business interests of mobile sites, that it is undesirable to fail sites that use such small transparent images. Therefore this machine-testable test merely 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:
If all pixels are transparent,
If image height and width are both less than 2 pixels, warn
If either dimension exceeds 2 pixels, FAIL
If more than one image with all transparent pixels was encountered, warn
PASS
If an area element is present, FAIL
For each img element:
If a usemap attribute is present, FAIL
PASS
For each img element:
If the image is in a raster format (i.e. is a JPEG or GIF image, for example, as opposed to SVG),
If the height or width attribute are missing, FAIL
If the height or width attribute do not specify a size in pixels, FAIL
If either the height or width specified are greater than the corresponding dimension of the image, warn
If either the height or width specified are less than the corresponding dimension of the image, FAIL
PASS
For each linked resource, as defined in 2.3.7 Visible Linked Resources:
Request the resource
If the HTTP response's Content-Type header's value is not one of
the Internet media types listed in the Accept header in 2.3.2 HTTP Request, warn
PASS
For each property in the CSS Style (2.3.4 CSS Style) whose value is a numeric measure of length:
If the value is non-zero and the unit is not "em", "ex" or "%", and the property is not a margin, border or padding box property (see also 3.20 SCROLLING (partial) ), FAIL
PASS
Count number of whitespace characters in a sequence of more
than one whitespace character (not counting the first), which exist outside of a
pre, style, script element, or XML comment
Add to this count the number of characters comprising XML comments. This total is the number of extraneous characters in the document.
Count total number of characters in document
If the number of extraneous characters exceeds 10% of the count of characters in the document, warn
If the number of extraneous characters exceeds 25% of the count of characters in the document, FAIL
PASS
If the document contains a frame , frameset or iframe element, FAIL
PASS
This test does not determine whether the alternative text is meaningful.
For each img element:
If an alt attribute is not present, FAIL
PASS
This test does not determine whether the document is still usable without the objects or scripts.
If a script element is present, warn
If any element has an "intrinsic event" attribute
(currently onload, onunload, onclick, ondblclick, onmousedown,
onmouseup, onmouseover, onmousemove, onmouseout, onfocus,
onblur, onkeypress, onkeydown, onkeyup, onsubmit,
onreset, onselect, onchange), warn
For each a and link element:
If the value of the href attribute begins with the "javascript:" scheme, FAIL
If an applet element is present, FAIL
If an object element is present,
If the element is empty, warn
If element body is non-empty and does not consist of text
or an img element that refers to an image in a supported format, FAIL
PASS
If the size of the document's markup exceeds 10 kilobytes, FAIL
For each included resource, as defined in 2.3.5 Included Resources:
Request the referenced resource
Add the size of the response body to a running total
If the total exceeds 20 kilobytes, FAIL
PASS
This test does not determine whether the title is meaningful.
If a title element is not present in the head element, or is empty, FAIL
PASS
For each a, link, form, and base element:
If a target attribute is present,
If its value is not one of "_self", "_parent", or "_top", FAIL
PASS
In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.
For each input element:
If element's type attribute is "radio",
If the document contains no input element whose name
attribute's value matches that of this radio input, and whose checked attribute is set to some value, warn
For each select element:
If there is no nested option element whose selected
attribute is set to some value, warn
PASS
This test does not determine whether secondary scrolling created by wide objects can be avoided, nor does it catch all possible objects which may render wider than 120 pixels.
This test and 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE together effectively test conformance to the LARGE_GRAPHICS best practice as well. Hence, no additional test for that best practice is specified.
For each block-level element, which includes those whose CSS property display is "block", either by default or explicitly set,
as well as the body, img, and object elements:
If CSS property width is set in pixels, or, the element has a width attribute
Add to the property/attribute value the value of the following CSS box properties if set in pixels:
border-left-width, border-right-width (may also be set by border-width, border-left, border-right, border)
margin-left, margin-right (may also be set by margin)
padding-left, padding-right (may also be set by padding)
If the sum exceeds 120, warn
Otherwise, for each of the parent elements, its parent, and so on up to the document root:
Add to that sum the values of the border, margin and padding properties as above
If the sum exceeds 120, warn
Otherwise continue with the next parent
For each table element:
If the value of its width attribute exceeds 120, warn
Sum its border, margin and padding property values as above
For each contained tr element:
For each contained td or th element:
Add to that sum its border, margin and padding property values
Add its width, as specified by the CSS width property, if present
If the sum exceeds 120, warn
Otherwise reset to sum of table properties and continue with next tr element
PASS
In addition, a human test is needed here to verify whether the page is readable without a style sheet.
If the CSS Style (2.3.4 CSS Style) contains rules
referencing the position, display or float properties, warn
PASS
This test does not require that any CSS styles be used, since in some cases, no presentation information is required at all (for example, a simple page of text).
This test looks for elements in the Text Extension module defined by [XHTMLModularization], since these are not supported in XHTML Basic. It also looks for commonly-used elements that were deprecated in HTML 4, and are also not supported in XHTML Basic.
If the document contains any basefont, bdo,
center, del, dir, font,
ins, menu, s,
strike or u elements, FAIL
If the document contains any b, big,
i, small, sub,
sup or tt elements, warn
If any element has a style attribute, warn
If there is no CSS Style (2.3.4 CSS Style), PASS
If the document contains a CSS style element but no externally linked CSS Style, warn
If the CSS Style contains a single @media rule that specifies the media type screen, warn
If the CSS Style contains at-rules other than the @media at-rule, properties or values that are not recognized as being valid CSS Level 1, warn
PASS
If a table element exists, warn
This test does not catch all cases where tables are used for layout purposes.
If a table element exists,
If it contains less than two tr elements, FAIL
If no tr element contains at least two td elements, FAIL
For each nested td element:
If the element contains only an image whose real dimensions are 2x2 or less, FAIL
PASS
If a table element exists,
If a table element exists somewhere inside it, FAIL
PASS
If it is an HTML document and it fails to validate according to its given DOCTYPE, FAIL
PASS
The editors would like to thank members of the BPWG for contributions of various kinds.
The editors acknowledge significant written contributions from:
This appendix lists all best practices and indicates whether each has a corresponding test in mobileOK Basic, mobileOK, both, or neither. Note that mobileOK is a superset of mobileOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK. 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 are subject to change as that document is still a work in progress.