W3C

W3C mobileOK Basic Tests 1.0

W3C Working Draft 30 January 25 May 2007

This version:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/ http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/
Latest version:
http://www.w3.org/TR/mobileOK-basic10-tests/
Previous version:
http://www.w3.org/TR/2006/WD-mobileOK-basic10-tests-20061219/ http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/
Editors:
Sean Owen, Google
Jo Rabin, Segala dotMobi (formerly at Segala)

Abstract

This document defines the tests that provide the basis for making a claim of W3C® mobileOK Basic™ conformance and are based on W3C Mobile Web Best Practices [BestPractices] . Content which passes the tests has taken some steps to provide a functional user experience for users of basic mobile devices whose capabilities at least match those of the Default Delivery Context (DDC).

mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK, mobileOK Pro , described separately. Claims to be W3C mobileOK Basic compliant conformant are represented using content labels, Description Resources (see [POWDER] ) , also described separately.

mobileOK assesses interoperability. It does not measure usability and does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Last Call Working Draft of mobileOK Basic Tests 1.0; it incorporates various refinements of the tests presented in the first two drafts; see 1.0. The W3C Membership and other interested parties are invited to review the changes-marked version document and send comments to public-bpwg-comments@w3.org , (with public archive which highlights all the changes since the previous publication of this document. The ) through 22 June 2007.

This document includes a set of editors notes on which feedback would be appreciated, in particular on was developed by the UTF-8 requirement Mobile Web Initiative Best Practices Working Group . The Working Group would also like feedback from Web content developers on the perceived difficulty of getting the mobileOK Basic status as described in this document. The Last Call review period for this documents extends until 6 March 2007. Please send comments on expects to advance this document Working Draft to the working group's public email Recommendation Status. A complete list public-bpwg-comments@w3.org of changes , a publicly archived mailing list . to this document is available

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

Table of Contents

1 Introduction
    1.1     1.1 Levels of mobileOK
        1.1.1         1.1.1 mobileOK Basic
        1.1.2         1.1.2 mobileOK Pro
        1.1.3         1.1.3 Out of Scope
        1.1.4         1.1.4 Beyond mobileOK
    1.2     1.2 Applicability
    1.3     1.3 Claiming mobileOK conformance
2 Conformance
    2.1     2.1 Validity of the Tests
    2.2     2.2 Testing Outcomes
    2.3     2.3 Conduct of Tests
        2.3.1         2.3.1 Order of Tests
        2.3.2         2.3.2 HTTP Request
        2.3.3         2.3.3 HTTP Response
        2.3.4         2.3.4 Meta http-equiv Elements
        2.3.5 CSS Style
        2.3.5         2.3.6 Included Resources
        2.3.6         2.3.7 Included Stylesheet Style Sheet Resources
        2.3.7         2.3.8 Visible Linked Resources
        2.3.9 Validity
        2.3.10 White Space
3 mobileOK Basic Tests
    3.1     3.1 AUTO_REFRESH (partial) and REDIRECTION
    3.2     3.2 CACHING
    3.3     3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
    3.4     3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP
    3.5     3.5 DEFAULT_INPUT_MODE
    3.6     3.6 EXTERNAL_RESOURCES
    3.7     3.7 GRAPHICS_FOR_SPACING
    3.8     3.8 IMAGE_MAPS
    3.9     3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE
    3.10     3.10 LINK_TARGET_FORMAT
    3.11     3.11 MEASURES
    3.12     3.12 MINIMIZE
    3.13     3.13 NO_FRAMES
    3.14     3.14 NON-TEXT_ALTERNATIVES (partial)
    3.15     3.15 OBJECTS_OR_SCRIPT (partial)
    3.16     3.16 PAGE_SIZE_LIMIT
    3.17     3.17 PAGE_TITLE (partial)
    3.18     3.18 POP_UPS
    3.19     3.19 PROVIDE_DEFAULTS (partial)
    3.20 SCROLLING (partial)     3.21     3.20 STYLE_SHEETS_SUPPORT (partial)
    3.22     3.21 STYLE_SHEETS_USE
    3.23     3.22 TABLES_ALTERNATIVES
    3.24     3.23 TABLES_LAYOUT (partial)
    3.25     3.24 TABLES_NESTED
    3.26 VALID_MARKUP

Appendices

A Acknowledgements (Non-Normative)
B References (Non-Normative)
C Relationship between Best Practices' Relation to Practices and mobileOK Tests (Non-Normative)


1 Introduction

This document describes W3C mobileOK Basic tests, which are based on is a scheme for assessing whether Web resources (Web content) can be delivered in a manner that is conformant with Mobile Web Best Practices [BestPractices] to a simple and largely hypothetical mobile user agent, the Default Delivery Context .

This document describes W3C mobileOK Basic tests for delivered content, and describes how to emulate the DDC when requesting that content.

mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK, mobileOK Pro , described separately. Claims to be W3C mobileOK Basic conformant are represented using content labels, Description Resources (see [POWDER] ) also described separately.

The intention of mobileOK is to help catalyze development of Web sites content that provide provides a functional user experience in a mobile context. It is not a test for browsers, user agents or mobile devices, and is not intended to imply anything about the way these should behave.

mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that a claim that a resource is mobileOK conformant implies that it is of higher informational value, is more reliable, more trustworthy or is more appropriate for children than any other resource .

1.1 Levels of mobileOK

1.1.1 mobileOK Basic

mobileOK Basic tests are based on a limited subset of the Mobile Web Best Practices. Their outcome is machine-verifiable, hence claims of mobileOK Basic conformance are easy to check.

Content passing the tests demonstrates that the content provider has taken basic steps to provide a functional experience for mobile users.

mobileOK Basic conformance should be considered only a first step towards building a harmonized experience for mobile users. Conformance merely demonstrates that a basic experience is available, interoperable with a large number of mobile devices. mobileOK Basic conformance says nothing about richer, more sophisticated, experiences that may be available. available, nor does it say anything about whether other guidelines for development of Web content (such as [WCAG] ) have been followed.

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] ) have been followed.

mobileOK Pro tests will be described separately.

1.1.3 Out of Scope

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.

1.1.4 Beyond mobileOK

The best practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. Many devices' The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.

Content providers should provide an experience that is mobileOK conformant to ensure a basic level of interoperability. Providers are encouraged to provide enhanced experiences as well when these are appropriate to their application and devices that are accessing them.

1.2 Applicability

The tests apply to a URI. Passing the tests means that under the right circumstances, when accessed as described in 2.3.2 HTTP Request , resolving a URI will retrieve result in mobileOK Basic conformant content that is delivered in a mobileOK Basic conformant manner.

That is, the tests do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. VALID_MARKUP ), but to how it is delivered to a mobile device (e.g. CACHING ). For convenience, this document refers to "mobileOK content" with the understanding that it refers to more than just the content itself.

mobileOK Basic says nothing about what may be delivered to non-mobile devices.

1.3 Claiming mobileOK conformance

A standard mechanism will be defined that allows content providers to claim that a URI or group of URIs, such as a Web site, conforms to mobileOK Basic or mobileOK. mobileOK Pro . It will be possible to make claims in a machine-processable form. It will also be possible to notify end users of the presence of the claim by means of a human-readable mark.

mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.

The details of the mechanism for claiming mobileOK conformance will be described separately.

2 Conformance

This section details the tests that must be carried out in order to claim mobileOK Basic. Tests are presented as simple pseudo-code.

2.1 Validity of the Tests

mobileOK tests are only meaningful when the URI under test resolves to HTML content delivered over HTTP.

2.2 Testing Outcomes

Individual tests may result in PASS or FAIL . PASS is required from all tests in order to claim mobileOK Basic.

Tests may also generate a number of informative warn ings.

2.3 Conduct of Tests

2.3.1 Order of Tests

mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently. Some tests have been designed to assess aspects of the content that are disallowed by other tests; this is deliberate and is intended to allow testing environments to provide as much information as possible.

For example the test for 3.22 3.21 STYLE_SHEETS_USE points out that style sheets should be used in preference to markup elements such as center , even though the center element is also disallowed by the test for 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP .

Creators of implementations of the tests described in this document are encouraged to provide as much information as possible to users of their implementations. Where possible they should not stop on FAIL and specifically they should :

  • Provide information about the cause of failure

  • Continue individual tests as far as is possible

  • Carry out as many tests as is reasonable

2.3.2 HTTP Request

The following HTTP request headers inform the server that it should deliver content that is compatible with the Default Delivery Context .

  • Use the HTTP GET method when making requests 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)
    User-Agent: W3C-mobileOK/DDC-1.0 (see http://www.w3.org/2006/07/mobileok-ddc)
    
    
  • Include an Accept header indicating that Internet media types understood by the default delivery context are accepted by sending exactly this header:

    Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
    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
    Accept-Charset: UTF-8
    
    
  • Do not include cookie related headers.

  • Include authentication information if required (see 2.3.3 HTTP Response ). Once authentication information has been included in a request, subsequent requests for the same realm must include authentication information as described in Section 2 and under "domain" in Section 3.2.1 of [RFC2617] .

  • Implementations must support URIs with both http and https scheme components.

2.3.3 HTTP Response

Note: To allow for self-signature of certificates during testing the signatory of a certificate should not be checked.

Note: Implementations must support basic and digest authentication.

If an HTTP request does not result in a valid HTTP response specifies (because of network-level error, DNS resolution error, or non-HTTP response), FAIL

If the response is an HTTPS response:

If the certificate is invalid, FAIL

If the certificate has expired, warn

If the HTTP 3xx status, a test implementation should attempt to respect status indicates redirection (status code 3xx):

Do not carry out tests on the server's response (e.g. follow

If the response relates to a 302 redirect). Note that redirects should be counted against request for the limit defined resource under test, or any of its included resources (see 2.3.6 Included Resources ):

Include the size of the response in the total described under 3.6 EXTERNAL_RESOURCES 3.16 PAGE_SIZE_LIMIT test.

Include this response under the count described under 3.6 EXTERNAL_RESOURCES

Re-request the resource as indicated in the response.

If an the HTTP status indicates that authentication is required (e.g. status code 401):

If the response relates to a request fails for the resource under test, or any reason during of its included resources (see 2.3.6 Included Resources ):

If authentication information was supplied in the HTTP request (i.e. authentication failed), FAIL

Carry out tests on the response

Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT

Include this response under the count described under 3.6 EXTERNAL_RESOURCES

Re-request the resource using authentication information

If the response relates to a request for a linked resource (see 2.3.8 Visible Linked Resources ):

Continue with the test (network-level error, DNS resolution error, non-HTTP response, or server returns an (see 3.10 LINK_TARGET_FORMAT , i.e. do not re-request the resource with authentication information).

If the HTTP 4xx status code is 404 or 5xx status),

If the response relates to a request for the resource under test, continue with tests on the response and warn

If the response relates to a request for a linked resource (see 2.3.8 Visible Linked Resources ), continue with the test outcome should be considered (see 3.10 LINK_TARGET_FORMAT ) and warn

Otherwise (i.e. for included resources), FAIL .

If the HTTP status represents failure (4xx), other than 404 or a request for authentication (e.g. 401), FAIL

2.3.4 Meta http-equiv Elements

Documents sometimes can include meta elements with an http-equiv attribute. These attribute; these are sometimes considered substitutes for HTTP response headers. Test implementations should respect only

Values specified in such elements must be ignored, aside from the following:

  • The Refresh header as specified in 3.1 AUTO_REFRESH (partial) and REDIRECTION

  • The Content-Type header as specified in 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

  • The Cache-Control header as specified in 3.2 CACHING

  • Check for consistency with HTTP response headers. headers, as follows:

    For each meta element that exists, however, if with an http-equiv attribute:

    If a matching HTTP response header does not exist, warn

    If a matching HTTP response header exists whose name matches but its http-equiv attribute value, and the header's value differs from the element's content attribute value, the test should generate a warn ing.

2.3.4 2.3.5 CSS Style

Some tests refer to "CSS Style" information. Assemble the CSS Style by using the contents of:

  • the style attribute of any element (note that use of the style attribute is deprecated in XHTML Basic 1.1)

  • style elements whose type attribute is not "text/css", and whose media attribute is either not present or is present and contains value values "all" or "handheld".

  • resources linked by xml-stylesheet processing instructions

  • external stylesheet style sheet resources linked via link elements, as defined in 2.3.6 2.3.7 Included Stylesheet Style Sheet Resources

  • resources linked by CSS @import at-rules

In the course of assembling the CSS Style:

  • observe the CSS Level 1 cascade

  • retrieve only those resources that have no CSS media type, or whose CSS media type specifier contains "handheld" or "all"

  • use only those rules that are not restricted as to their CSS media type or whose CSS media type specifier contains "handheld" or "all"

2.3.5 2.3.6 Included Resources

For convenience, this section and those that follow provide definitions that are reused several times in the document.

Some tests refer to a notion of included resources, which are resources external to the resource being tested and yet vital to rendering that resource. resource whose URI has the "http" or "https" scheme . Examples include image and stylesheet style sheet resources.

When calculating page sizes, caching directives should be observed. Multiple references to cached resources are counted only once in regard of page weight (see 3.16 PAGE_SIZE_LIMIT ) and resource count (see 3.6 EXTERNAL_RESOURCES ).

Included resources are defined as those that are referenced by:

  • img elements

  • object elements

    In some circumstances object elements may act as synonyms for other elements such as img and iframe . In these cases it is noted in the relevant section when to regard object elements as equivalents for other elements.

  • link elements and xml-stylesheet processing instructions as defined in 2.3.6 2.3.7 Included Stylesheet Style Sheet Resources

  • images included by background-image and list-style-image properties in the CSS Style ( 2.3.4 2.3.5 CSS Style )

  • @import directives in the CSS Style Style — providing they are in scope for the media type "handheld" or "all" ( 2.3.4 2.3.5 CSS Style )

    xml-stylesheet processing instructions

2.3.6 2.3.7 Included Stylesheet Style Sheet Resources

When calculating the page size ( 3.16 PAGE_SIZE_LIMIT ) only those style sheets retrieved according to the rule specified here are taken into account.

Included stylesheet style sheet resources are, simply, included resources that are stylesheets. style sheets. They are defined as resources referenced in the href attribute of link elements and xml-stylesheet processing instructions (in which case attribute in this section refers to pseudo-attribute ) whose rel attribute contains "stylesheet" but not "alternate", charset attribute is either not present or is present with value "UTF-8", type attribute is either not present or is present with value "text/css", and whose media attribute is either not present or is present and contains value "all" or "handheld". Further, this definition only pertains to resources whose URI begins with the "http" or "https" scheme.

2.3.7 2.3.8 Visible Linked Resources

Linked resources are resources linked to from the resource being tested, but which are not vital to rendering that resource. resource whose URI has the "http" or "https" scheme . Examples include resources linked via hyperlinks.

Linked resources are defined as those that are referenced by:

  • the href attribute of a (anchor) elements, and whose URI begins with the "http" or "https" scheme scheme.

  • the action attribute of form elements whose method attribute is not present or is present with value "get" "get". Note that forms with method get are permissible in documents under test, but must not be checked in case posting caused unwanted side effects such as the addition of unwanted records to a database.

2.3.9 Validity

Several tests refer to the validity of aspects of a resource. This section defines specifically what this means.

CSS

A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS] , Appendix B

GIF

An image is a valid GIF image if it conforms to the grammar defined in section 25 of the [GIF] specification

JPEG

An image is a valid JPEG image if it follows the format defined in Annex B of the [JPEG] specification

UTF-8

A resource is considered to be valid UTF-8 if its bytes represent the valid UTF-8 encoding of some string, as defined in [UTF-8] , section 4

Note: [utf8_perl] contains a regular expression that may be used for testing UTF-8 validity.

2.3.10 White Space

Several tests refer to white space. White space has the same definition in this document as in XML. For XML 1.0 [XML10] it is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:

S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the characters SP, TAB, CR and LF.

For XML 1.1 [XML11] it is defined in section 1.3 as consisting of the same characters with the addition of NEL (#x85) and the Unicode line separator character, (#x2028).

3 mobileOK Basic Tests

This section describes tests for mobileOK Basic. Tests are organized alphabetically by the Best Practice from which they derive. Where a test derives from more than one Best Practice it is placed according to the one that occurs earliest first in dictionary order.

3.1 AUTO_REFRESH (partial) and REDIRECTION

This test does not determine whether the user is able to opt out of refresh.

If a meta element is present with http-equiv attribute value of "refresh",

If the URI specified in the content attribute is not the current resource's URI, FAIL

Else, warn

If a Refresh HTTP header is present,

If the URI specified in the header value is not the current page, resource's URI, FAIL

Else, warn

PASS

3.2 CACHING

In the following, note that HTTP headers should be used rather than meta elements with http-equiv attributes, which are commonly not taken into account by proxies. Where both a meta element and the corresponding header are found the value of the header must be used.

If the HTTP response contains neither an Expires nor Cache-Control header, header

If no meta http-equiv element is present, referring to those headers, FAIL

warn, and continue the test using the value from the meta content attribute.

If a Cache-Control HTTP header is present and contains value "no-cache", or contains value "max-age=0", warn

If a Pragma HTTP header is present and contains value "no-cache", warn

If an Expires and Date HTTP header are present, and the Expires header specifies a date which is not later than what the Date header specifies, or if the Expires warn

If any cache related header specifies contains an invalid date (e.g. "0"), value, warn

If the HTTP response contains a Last-Modified header,

Request the same URI again, adding an If-Modified-Since request header whose value matches that of the Last-Modified response header

If the HTTP response contains a Last-Modified header and its value is again the same, and the HTTP response status is not 304 (Not Modified), warn

If the HTTP response contains an ETag header,

Request the same URI again, adding an If-None-Match request header whose value matches that of the ETag response header

If the HTTP response contains an ETag header and its value is again the same, and the HTTP response status is not 304 (Not Modified), warn

PASS

3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource cannot be delivered encoded in UTF-8. The test does not require that resource always be encoded in UTF-8; the test merely checks that the resource is available in UTF-8 encoding, if requested. Resources may be delivered to devices in represented using other encodings where appropriate. This test verifies that a DDC-like device which only accepts UTF-8 encoding may access the resource in UTF-8 encoding.

This requirement, UTF-8 support, has been extensively debated and the group solicits feedback on it. Determine the test requires that character encoding is explicitly specified by and recognizes the following, if present: following methods of specification:

  • HTTP Content-Type header (e.g. "application/xhtml+xml;charset=UTF-8")

    application/xhtml+xml; charset=UTF-8"
    
  • XML declaration (e.g. "<?xml encoding="UTF-8"?>")

    <?xml version="1.0" encoding="UTF-8" ?>
    
  • meta element that is the first child of the document's head element, and whose http-equiv attribute is "Content-Type", and whose content attribute specifies a character encoding as above (e.g. "<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>)

    ...
    <head>
    <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8"/>
    ...
    

If the HTTP Content-Type header specifies a character encoding other than UTF-8, FAIL

If the HTTP Content-Type header does not specify a character encoding:

If there is no XML declaration, or UTF-8 character encoding is not explicitly specified in at least one of these ways, the XML declaration, FAIL

If the HTTP Content-Type header specifies an Internet media type starting with "text/":

If there is no meta element with http-equiv attribute that specifies UTF-8 character encoding, FAIL

If character encoding is specified in more than one way, and not all values are the same, FAIL

If any character encoding specified is not "UTF-8", FAIL

If the document is not valid UTF-8, UTF-8 (see 2.3.9 Validity ), FAIL

For each external resource as defined in specified by 2.3.5 2.3.6 Included Resources :

Request the URI indicated by the href attribute resource

If the HTTP response Content-Type header value specifies an Internet media type starting of the response starts with "text/" but does not specify UTF-8 encoding (e.g. "text/css" only instead of "text/css;charset=UTF-8"), character encoding, warn

PASS

3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP

If the document's Internet media type, as specified in the HTTP response Content-Type header, is not "application/xhtml+xml", "application/vnd.wap.xhtml+xml", or "text/html", FAIL

If the document's Internet media type is "text/html" or "application/vnd.wap.xhtml+xml", warn

If the document does not contain a DOCTYPE declaration, FAIL

If the document is an HTML document and it fails to validate according to its given DOCTYPE , FAIL

If (regardless of its stated DOCTYPE) the document does not validate against the XHTML Basic 1.1 DTD (regardless of its stated DOCTYPE), DTD:

If it does not validate against the XHTML-MP 1.2 DTD, FAIL

For each included resource, as defined by resource (see 2.3.5 2.3.6 Included Resources : ):

If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL

If the Internet media type is "image/gif" or "image/jpeg", and the resource is invalid according to the specification of GIF89a or JPEG, respectively, not valid (see 2.3.9 Validity ), FAIL

If the Internet media type is "text/css" and the content is not well-formed valid CSS (contains mismatching brackets or illegal characters), (see 2.3.9 Validity ), FAIL

PASS

3.5 DEFAULT_INPUT_MODE

Note that inputmode is part of [XHTMLBasic11] .

For each input element with attribute type whose value is "text" or "password"

If the element's inputmode attribute is invalid according to Section 5.2 User Agent Behavior of XHTML Basic 1.1 [XHTMLBasic11] , FAIL

If the element's value attribute is missing or empty, and an inputmode attribute is not present, warn

For each textarea element:

If the element's inputmode attribute is invalid according to Section 5.2 User Agent Behavior of XHTML Basic 1.1 [XHTMLBasic11] , FAIL

If the element is empty and an inputmode attribute is not present, warn

PASS

3.6 EXTERNAL_RESOURCES

Note that if an HTTP request is unsuccessful while conducting this test, the result is FAIL

Count the total number of unique included resources, as defined in 2.3.5 2.3.6 Included Resources . For nested object elements, count only the number of objects that need to be assessed before content matching the request header defined in 2.3.2 HTTP Request is found .

For each such resource:

Request the resource, and add one to a running count

Add to the count the number of HTTP redirects (HTTP responses with 3xx status 301 or 302) responses) that must be followed and authentication requests that must be made until the resource itself is successfully retrieved

If this total exceeds 10, warn

If this total exceeds 20, FAIL

PASS

3.7 GRAPHICS_FOR_SPACING

The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often used in e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the business interests of mobile sites, that it is undesirable to fail sites that use such small transparent images. Therefore this machine-testable test merely warn s about the presence of small (at most 2x2) transparent images and FAIL s larger ones. It is believed that few if any sites would use transparent images of any significant size for tracking.

For each img element: element and object element whose type attribute starts with "image/" :

If all pixels are transparent,

If image height and width are both less than or equal to 2 pixels, warn

If either dimension exceeds 2 pixels, FAIL

If more than one image with all transparent pixels was encountered, warn

PASS

3.8 IMAGE_MAPS

If an area input element with type attribute set to "image" is present, FAIL

For each img element: element and object element :

If a usemap attribute is present, FAIL

If an ismap attribute is present, FAIL

PASS

3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE

Note that the height and width HTML attributes specify pixels when they are used as a number. No unit is specified.

For each img element: If the image is in a raster format (i.e. is a JPEG or GIF image, for example, as opposed to SVG), element and object element whose type attribute starts with "image/" :

If the height or width attribute are missing, FAIL

If the height or width attribute do not specify a size in pixels, FAIL

If either the height or width specified are greater than the corresponding dimension of the image, warn

If either the height or width specified are less than the corresponding dimension of the image, FAIL

PASS

3.10 LINK_TARGET_FORMAT

Note that 404 and 5xx HTTP status do not result in failure when conducting this test. In such cases it is the headers attached to the body of the error response which are tested.

For each linked resource, as defined in 2.3.7 2.3.8 Visible Linked Resources :

Request the resource

If the HTTP response's Content-Type header's header value of the HTTP response is not one of the Internet media types Media Types listed in the Accept header in 2.3.2 HTTP Request , warn

If the Content-Type header value of the HTTP response is not consistent (determined in the same way as specified in 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE ) with the Accept-Charset header in 2.3.2 HTTP Request , warn

PASS

3.11 MEASURES

For each property in the CSS Style ( 2.3.4 2.3.5 CSS Style ) whose value is a numeric measure of length: length stated together with a unit:

If the value is non-zero and the unit is not "em", "ex" "em" or "%", "ex", and the property is not a margin, border or padding box property (see also 3.20 SCROLLING (partial) ), property, FAIL

PASS

3.12 MINIMIZE

Count number of whitespace white space characters in a sequence of more than one whitespace white space character (not counting the first), which exist outside of a pre , style , script element, or XML comment

Add to this count the number of characters comprising XML comments. This total is the number of extraneous characters in the document.

Count total number of characters in document

If the number of extraneous characters exceeds 10% of the count of characters in the document, warn

If the number of extraneous characters exceeds 25% of the count of characters in the document, FAIL

PASS

3.13 NO_FRAMES

If the document contains a frame , frameset or iframe element, element or object element whose type attribute starts with "text/", "application/xhtml+xml" or "application/vnd.wap.xhtml+xml" , FAIL

PASS

3.14 NON-TEXT_ALTERNATIVES (partial)

This test does not determine whether the alternative text is meaningful.

For each img element:

If an alt attribute is not present, present or consists only of white space , FAIL

PASS

3.15 OBJECTS_OR_SCRIPT (partial)

This test does not determine whether the document is still usable without the objects or scripts.

If a script element is present, warn

If any element has an "intrinsic event" attribute (currently onload , onunload , onclick , ondblclick , onmousedown , onmouseup , onmouseover , onmousemove , onmouseout , onfocus , onblur , onkeypress , onkeydown , onkeyup , onsubmit , onreset , onselect , onchange ), warn

For each a and link element:

If the value of the href attribute begins with the "javascript:" scheme, FAIL

If an applet element is present, FAIL

If an object element is present, present and has no object element ancestor ,

If the innermost nested object element is empty, warn

If the innermost nested object element content consists only of white space, FAIL

If none of the nested object elements refers to content that matches the headers defined in 2.3.2 HTTP Request and the innermost nested object element body is non-empty and does not consist of text or an img element that refers to an image that matches the headers defined in a supported format, 2.3.2 HTTP Request , FAIL

PASS

3.16 PAGE_SIZE_LIMIT

If the size of the document's markup exceeds 10 kilobytes, FAIL

For each included resource, as defined in 2.3.5 2.3.6 Included Resources :

Request the referenced resource

Add the size of the response body to a running total (for nested object elements count only the first object that matches the headers specified in 2.3.2 HTTP Request , if there is one)

If the total exceeds 20 kilobytes, FAIL

PASS

3.17 PAGE_TITLE (partial)

This test does not determine whether the title is meaningful.

If a title element is not present in the head element, or is empty, or contains only white space, FAIL

PASS

3.18 POP_UPS

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

3.19 PROVIDE_DEFAULTS (partial)

In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.

For each radio button group within a form element ( input element: If element's elements with type "radio" that share the same name attribute is "radio", value):

If the document contains no

Check that exactly one input element whose name attribute's value matches that of within this radio input, and whose group has its checked attribute is set to some value, "checked", and if this is not the case, warn

For each select element:

If there is no nested option element whose selected attribute is set to some value, warn

PASS 3.20 SCROLLING (partial) 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 there is more than one width option is set in pixels, or, the element has a whose width selected attribute Add to the property/attribute value the value of the following CSS box properties if set in pixels: border-left-width , border-right-width (may also be set by border-width , border-left , border-right , border ) margin-left , margin-right (may also be set by margin ) padding-left , padding-right (may also be is set by padding ) If the sum exceeds 120, warn Otherwise, for each of the parent elements, its parent, and so on up to the document root: Add to that sum the values of the border, margin "selected", and padding properties as above If the sum exceeds 120, warn Otherwise continue with the next parent For each table element: If the value of its width multiple attribute exceeds 120, warn Sum its border, margin and padding property values as above For each contained tr element: For each contained td or th element: Add is not set to that sum its border, margin and padding property values Add its width, as specified by the CSS width property, if present If the sum exceeds 120, "multiple", warn

Otherwise reset to sum of table properties and continue with next tr element

PASS

3.21 3.20 STYLE_SHEETS_SUPPORT (partial)

In addition, a human test is needed here to verify whether the page is readable without a style sheet.

If the CSS Style ( 2.3.4 2.3.5 CSS Style ) contains rules referencing the position , display or float properties, warn

PASS

3.22 3.21 STYLE_SHEETS_USE

This test does not require that any CSS styles be used, since in some cases, no presentation information is required at all (for example, a simple page of text).

This test looks for elements in the Text Extension module defined by [XHTMLModularization] , since these some of which are not supported in XHTML Basic. It also looks for commonly-used elements and attributes that were deprecated in HTML 4, and are also not supported supported, or are deprecated, in XHTML Basic.

Note that external style sheets and style elements that have no media attribute are assumed to refer to "all".

If the document contains any basefont , bdo , center , del , dir , font , ins , menu , s , strike or u elements, FAIL

If the document contains any b , big , i , small , sub , sup or tt elements, warn

If any element has a style attribute, warn

If there is no CSS Style ( 2.3.4 2.3.5 CSS Style ), PASS

If the document contains a CSS style element but no externally linked CSS Style, warn

If the CSS Style contains a single @media rule that specifies the all styles are restricted to media type screen , types other than "handheld" or "all" by means of @media at- rules, warn

If the CSS Style contains at-rules other (other than the @media at-rule, properties at-rule), properties, or values that are not recognized as being valid CSS Level 1, 1 2.3.9 Validity , warn

PASS

3.23 3.22 TABLES_ALTERNATIVES

If a table element exists, warn

3.24 3.23 TABLES_LAYOUT (partial)

This test does not catch all cases where tables are used for layout purposes.

If a table element exists,

If it contains less than two at most one tr elements, element, FAIL

If no tr element contains at least two more than one td elements, element, FAIL

For each nested td element:

If the element contains only an image (or equivalent object) whose real actual dimensions are 2x2 or less, FAIL

PASS

3.25 3.24 TABLES_NESTED

If a table element exists,

If a table element exists somewhere inside it, FAIL

PASS 3.26 VALID_MARKUP If it is an HTML document and it fails to validate according to its given DOCTYPE , FAIL

PASS

A Acknowledgements (Non-Normative) Acknowledgements(Non-Normative)

The editors would like to thank members of the BPWG for contributions of various kinds.

The editors acknowledge significant written contributions from:

B References (Non-Normative) References(Non-Normative)

BestPractices
"Mobile Web Best Practices", Jo Rabin, Charles McCathieNevile, W3C Proposed Recommendation, 2 November 2006 (See http://www.w3.org/TR/mobile-bp/ .) ).
CSS
Cascading Style Sheets, level 1, Håkon Wium Lie, Bert Bos, W3C Recommendation 17 Dec 1996, revised 11 Jan 1999 (See http://www.w3.org/TR/REC-CSS1 ).
Techniques GIF
GRAPHICS INTERCHANGE FORMAT, Version 89a, CompuServe Incorporated, 1990 (See http://www.w3.org/Graphics/GIF/spec-gif89a.txt ).
JPEG
Recommendation T.81, 18 September 1992 (See http://www.w3.org/Graphics/JPEG/itu-t81.pdf ).
POWDER
Protocol for Web Description Resources (POWDER) Working Group Charter (See http://www.w3.org/2007/02/powder_charter#Mission ).
RFC2617
HTTP Authentication: Basic and Digest Access Authentication, J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart, June 1999 (See http://tools.ietf.org/html/rfc2617 ).
Techniques
Mobile Web Techniques for Best Practices [in development] (See http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro .) ).
XHTMLModularization UTF-8
UTF-8, a transformation format of ISO 10646, F. Yergau, November 2003 (See http://tools.ietf.org/html/rfc3629 ).
utf8_perl
XHTML Modularization 1.1 Multilingual Forms (See http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/ .) http://www.w3.org/International/questions/qa-forms-utf-8 ).
WCAG
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden and I. Jacobs, eds., W3C Recommendation, 5 May 1999 (See http://www.w3.org/TR/WAI-WEBCONTENT/ ).
XHTMLBasic11
XHTML Basic 1.1 (See http://www.w3.org/TR/2006/WD-xhtml-basic-20060705/ .) ).
XHTMLModularization
XHTML Modularization 1.1 (See http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/ ).
XML10
Extensible Markup Language (XML) 1.0 (Fourth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, W3C Recommendation 16 August 2006, edited in place 29 September 2006 (See http://www.w3.org/TR/REC-xml/ ).
XML11
Extensible Markup Language (XML) 1.1 (Second Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, John Cowan, W3C Recommendation 16 August 2006, edited in place 29 September 2006 (See http://www.w3.org/TR/xml11/ ).

C Relationship between Best Practices' Relation to Practices and mobileOK Tests (Non-Normative) Tests(Non-Normative)

This appendix lists all best practices and indicates whether each has a corresponding test in mobileOK Basic, mobileOK, mobileOK Pro , both, or neither. Note that mobileOK Pro is a superset super-set of mobileOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK. mobileOK Pro . This table, however, indicates which best practices have a corresponding test that expands on the test, if any, in mobileOK Basic. The tests listed for mobileOK Pro are subject to change as that document is still a work in progress.

Best Practice mobileOK Basic mobileOK Pro
ACCESS_KEYS X
AUTO_REFRESH X X
AVOID_FREE_TEXT X
BACKGROUND_IMAGE_READABILITY X
BALANCE
CACHING X
CAPABILITIES
CENTRAL_MEANING
CHARACTER_ENCODING_SUPPORT X
CHARACTER_ENCODING_USE X
CLARITY
COLOR_CONTRAST X
CONTENT_FORMAT_PREFERRED X
CONTENT_FORMAT_SUPPORT X
CONTROL_LABELLING X
CONTROL_POSITION X
COOKIES X
DEFAULT_INPUT_MODE X
DEFICIENCIES
ERROR_MESSAGES X
EXTERNAL_RESOURCES X
FONTS X
GRAPHICS_FOR_SPACING X X
IMAGE_MAPS X
IMAGES_RESIZING X
IMAGES_SPECIFY_SIZE X
LARGE_GRAPHICS X
LIMITED X
LINK_TARGET_FORMAT X
LINK_TARGET_ID X
MEASURES X
MINIMIZE X
MINIMIZE_KEYSTROKES X
NAVBAR X
NAVIGATION X
NO_FRAMES X
NON-TEXT_ALTERNATIVES X X
OBJECTS_OR_SCRIPT X X
PAGE_SIZE_LIMIT X
PAGE_SIZE_USABLE X
PAGE_TITLE X X
POP_UPS X
PROVIDE_DEFAULTS X X
REDIRECTION X
SCROLLING X X
STRUCTURE X
STYLE_SHEETS_SIZE
STYLE_SHEETS_SUPPORT X X
STYLE_SHEETS_USE X
SUITABLE X
TAB_ORDER X
TABLES_ALTERNATIVES X
TABLES_LAYOUT X X
TABLES_NESTED X
TABLES_SUPPORT
TESTING
THEMATIC_CONSISTENCY
URIS
USE_OF_COLOR X
VALID_MARKUP X