w3c mobileok basic

Upload: ing-ja-espino-l

Post on 10-Apr-2018

242 views

Category:

Documents


0 download

TRANSCRIPT

  • 8/8/2019 W3C MobileOK Basic

    1/16

    W3C mobileOK Basic Tests 1.0

    W3C Recommendation 08 December 2008This version:

    http://www.w3.org/TR/2008/REC-mobileOK-basic10-tests-20081208/

    Latest version:http://www.w3.org/TR/mobileOK-basic10-tests/

    Previous version:http://www.w3.org/TR/2008/PR-mobileOK-basic10-tests-20081103/

    Editors:Sean Owen, GoogleJo Rabin, dotMobi (and before at Segala)

    Please refer to the errata for this document, which may include some normative corrections.

    See also translations.

    Copyright 2008 W3C(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

    Abstract

    This document defines the tests that provide the basis for making a claim of W3C mobileOK Basic conformance and are basedon W3C Mobile Web Best Practices [Best Practices]. The details of how to claim mobileOK conformance will be describedseparately. Providers of content which passes the tests have taken some steps to provide a functional user experience for users ofbasicmobile devices whose capabilities at least match those of the Default Delivery Context (DDC).

    mobileOK Basic primarily assesses basic usability, efficiency and interoperability. It does not address the important goal ofassessing 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. Alist of current W3C publications and the latest revision of this technical report can be found in theW3C technical reports indexathttp://www.w3.org/TR/.

    This document was developed by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative.

    Please see the Working Group's implementation report. A complete list of the editorial changes since the previous version of th isdocument is available.

    Please send comments about this document to [email protected] (with public archive).

    This document defines machine-verifiable tests, based on the W3C Mobile Web Best Practices [Best Practices]. Although contentauthors are not expected to use this document directly, participants of the Working Group expect tools that implement the testsdefined in this document to greatly improve the authoring of content that addresses the browsing experience of users on a broadrange of devices.

    This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties,and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or citedfrom another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote itswidespread deployment. This enhances the functionality and interoperability of the Web.

    This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list ofany patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing apatent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclosethe information in accordance with section 6 of the W3C Patent Policy.

    Table of Contents

    1 Introduction1.1 Scope

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    2/16

    1.1.1 Relationship to Best Practices1.1.2 Out of Scope1.1.3 Beyond mobileOK

    1.2 Applicability1.3 Claiming mobileOK conformance

    2 Conformance2.1 Use of Terms must, should etc.2.2 Validity of the Tests2.3 Testing Outcomes2.4 Conduct of Tests

    2.4.1 Order of Tests

    2.4.2 HTTPS2.4.3 HTTP Request2.4.4 HTTP Response2.4.5 Meta http-equiv Elements2.4.6 CSS Style2.4.7 Included Resources2.4.8 Linked Resources2.4.9 Validity2.4.10 White Space

    3 mobileOK Basic Tests3.1 AUTO_REFRESH and REDIRECTION3.2 CACHING3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP3.5 DEFAULT_INPUT_MODE3.6 EXTERNAL_RESOURCES

    3.7 GRAPHICS_FOR_SPACING3.8 IMAGE_MAPS3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE3.10 LINK_TARGET_FORMAT3.11 MEASURES3.12 MINIMIZE3.13 NO_FRAMES3.14 NON-TEXT_ALTERNATIVES3.15 OBJECTS_OR_SCRIPT

    3.15.1 Object Element Processing Rule3.16 PAGE_SIZE_LIMIT3.17 PAGE_TITLE3.18 POP_UPS3.19 PROVIDE_DEFAULTS3.20 STYLE_SHEETS_SUPPORT3.21 STYLE_SHEETS_USE3.22 TABLES_ALTERNATIVES3.23 TABLES_LAYOUT3.24 TABLES_NESTED

    Appendices

    A Acknowledgments (Non-Normative)B References (Non-Normative)C Relationship between Best Practices and mobileOK Tests (Non-Normative)

    1 Introduction

    mobileOK Basic is a scheme for assessing whether Web resources (Web content) can be delivered in a manner that is conformantwith Mobile Web Best Practices [Best Practices] to a simple and largely hypothetical mobile user agent, the Default DeliveryContext.

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

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

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

    1.1 Scope

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    3/16

    1.1.1 Relationship to Best Practices

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

    Content passing the tests demonstrates that the content provider has taken basicsteps to provide a functional experience formobile 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 sayanything about whether other guidelines for development of Web content (such as [WCAG 1.0]) have been followed.

    1.1.2 Out of Scope

    Some Best Practices, like TESTING, are advisable but do not meaningfully translate into concrete tests.

    The tests assess whether the content canbe provided in a way that achieves basic usability, eff iciency, and interoperability withmobile devices. The tests should not be understood to assess thoroughly whether the content has been well-designed for mobiledevices.

    1.1.3 Beyond mobileOK

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

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

    1.2 Applicability

    The tests apply to a URI. Passing the tests means that when accessed as described in 2.4.3 HTTP Request, resolving a URI willresult in mobileOK Basic conformant content that is delivered in a mobileOK Basic conformant manner.

    That is, the tests do not apply solely to content or document instances. Many Best Practices relate not just to the document (e.g.VALID_MARKUP), but to how it is delivered to a mobile device (e.g. CACHING).

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

    1.3 Claiming mobileOK conformance

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

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

    2 Conformance

    2.1 Use of Terms must, should etc.

    Where terms are used with the meanings defined in [RFC 2119] they are highlighted in the text e.g. must.

    2.2 Validity of the Tests

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

    2.3 Testing Outcomes

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

    test, PASS is achieved if and only if there are no 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 mayindicate that it could not be conclusively determined whether the content under test conforms to a Best Practice (and thus does not

    FAIL), or may indicate that the content under test is close to violating a Best Practice.

    2.4 Conduct of Tests

    2.4.1 Order of Tests

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    4/16

    mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently. Sometests have been designed to assess aspects of the content that are disallowed by other tests; this is deliberate and is intended toallow 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 elementssuch as center, even though the center element is also disallowed by the test for 3.4 CONTENT_FORMAT_SUPPORT andVALID_MARKUP.

    Creators of implementations of the tests described in this document are encouraged to provide as much information as possible to

    users of their implementations. Where possible they should not stop on FAIL and specifically they should:

    Provide information about the cause of warning or failure (each warn and FAIL is individually identified);

    Continue individual tests as far as is possible;

    Carry out as many tests as is reasonable.

    2.4.2 HTTPS

    Note:

    Arbitrary root certificates (including self-signed certificates) should be regarded as trusted.

    When resolving a URI, if the URI has the scheme https:

    If the certificate presented does not match the requested URI, FAIL

    If the certificate has expired, or is not yet valid, warn

    If certificate validation otherwise fails, FAIL

    2.4.3 HTTP Request

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

    Use the HTTP GET method when making requests, except for 3.10 LINK_TARGET_FORMAT where the HEAD method may beused (See 2.4.8 Linked Resources for a discussion of the POST method).

    Include a User-Agent header which starts exactly as follows (indicating the Default Delivery Context, and which may beextended in accordance with [RFC 2616]Section 14.43, User-Agent Header) :

    User-Agent: W3C-mobileOK/DDC-1.0 (see http://www.w3.org/2006/07/mobileok-ddc)

    Include an Accept header indicating that Internet media types understood by the Default Delivery Context are accepted bysending exactly this header:

    Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif

    Include an Accept-Charset header indicating that only UTF-8 is accepted by sending exactly this header:

    Accept-Charset: UTF-8

    Do not include cookie related headers.

    Include authentication information if required (see 2.4.4 HTTP Response). Once authentication information has been included

    in a request, subsequent requests for the same realm must include authentication information as described in Section 2 andunder "domain" in Section 3.2.1 of [RFC 2617].

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

    Note:

    As noted under 2.4.7 Included Resources and 2.4.8 Linked Resources the URIs that are relevant to mobileOK are those

    that, when represented in an absolute form, have either the http or the https scheme. Requests should not be made forURIs with schemes other than http and https.

    2.4.4 HTTP Response

    Note:

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    5/16

    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 possibilityof 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 tothe content.

    If an HTTP request does not resul t in a valid HTTP response (because of network-level error, DNS resolution error, or

    non-HTTP response), FAIL

    If the HTTP status indicates redirection (status code 3xx):

    Do not carry out tests on the response

    If the response relates to a request for the resource under test, or any of its Included Resources (see 2.4.7 IncludedResources):

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

    Include this response under the count as described under 3.6 EXTERNAL_RESOURCES

    If there is no HTTP Location header, FAIL.

    If the URI identified by the HTTP Location header is a relative URI, create an absolute URI by combining the value of the

    Location header with the absolute URI of the request to which this is a response, warn

    If the resulting URI is not a URI with the scheme http or https, FAIL.

    Re-request the resource using the URI formulated above.

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

    If the response relates to a request for the resource under test, or any of its Included Resources (see 2.4.7 IncludedResources):

    If authentication information was supplied in the HTTP request (i.e. authentication failed) or if no authentication

    information is available, FAIL

    Carry out tests on the response

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

    Include this response under the count as described under 3.6 EXTERNAL_RESOURCES

    Re-request the resource using authentication information

    If the response relates to a request for a l inked resource (see 2.4.8 Linked Resources):

    Continue with the test (see 3.10 LINK_TARGET_FORMAT , i.e. do not re-request the resource with authentication

    information), warn

    If the HTTP status code is 404 or 5xx

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

    If the response relates to a request for a l inked resource (see 2.4.8 Linked Resources), continue with the test (see 3.10LINK_TARGET_FORMAT ) and warn

    Otherwise (i.e. for Included Resources), FAIL

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

    the 3.15.1 Object Element Processing Rule, FAIL

    2.4.5 Meta http-equiv Elements

    Documents can include meta elements with an http-equiv attribute; these are sometimes considered substitutes for HTTP responseheaders.

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    6/16

    mobileOK Basic test implementations must ignore values specified in such elements, aside from the following:

    The Refresh header as specified in 3.1 AUTO_REFRESH and REDIRECTION

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

    The Cache-Control header as specified in 3.2 CACHING

    Check for consistency with HTTP headers, as follows:

    For each meta element with an http-equiv attribute:

    If a matching HTTP response header does not exist, warn

    If a matching HTTP response header exists but its value differs from the content attribute value, warn

    2.4.6 CSS Style

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

    the style attribute of any element (use of the style attribute is deprecated in XHTML Basic 1.1 [XHTML Basic 1.1])

    style elements whose type attribute is "text/css", and whose media attribute is either not present or is present and containsvalues "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, attributein this section refers to pseudo-attribute.

    resources linked by CSS @import at-rules whose presentation media list is either not present or is present and contains thevalue "all" or "handheld"

    In the course of assembling the CSS Style use only those CSS rulesets that are not restricted as to their presentation media type orwhose presentation media type list contains "handheld" or "all".

    2.4.7 Included Resources

    Some tests refer to Included Resources, which are resources external to the resource being tested and yet vital to rendering thatresource and whose URI has the "http" or "https" scheme, when represented in an absolute form. Examples include image andstyle sheet resources.

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

    Included Resources are defined as those that are referenced by the following:

    the src attribute of img elements

    the data attribute of object elements (see notes below)

    the href attribute of link elements and xml-stylesheet processing instructions as defined in 2.4.6 CSS Style

    images included by background-image and list-style-image properties in the CSS Style (see 2.4.6 CSS Style)

    @import directives in the CSS Style - providing they are unqualified as to presentation media type or qualified by presentationmedia type "handheld" or "all" (case-insensitive) as defined in 2.4.6 CSS Style

    Note:

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

    Note:

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    7/16

    Resources that are retrieved as references from object elements and whose Content-Type HTTP header is not set to"image/jpeg" or "image/gif" are not considered to be Included Resources as discussed under 3.15.1 Object ElementProcessing Rule (i.e. objects that are "tasted" to determine their Internet content type but are then discarded are not IncludedResources). Their treatment, as regards 3.16 PAGE_SIZE_LIMIT and 3.6 EXTERNAL_RESOURCES , is described in therelevant section.

    Note:

    Resources referenced by descendants of an object element that itself refers to an Included Resource are not considered to beIncluded Resources as discussed under 3.15.1 Object Element Processing Rule (i.e. any img or object element which occursin the fall-back of an acceptable object element is not an Included Resource).

    2.4.8 Linked Resources

    Linked Resources are resources linked to from the resource being tested (other than the resource itself), but which are not vital torendering 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 bymobileOK Basic (posting might cause side effects such as the addition of unwanted records to a database).

    Note:

    When submitting forms use default values where supplied, otherwise supply empty values.

    2.4.9 Validity

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

    CSS

    A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS Level 1], Appendix B. Thepresence of at-rules, properties or values or combinations of properties and values that are not specified in [CSS Level 1] doesnot constitute a validity failure for CSS. See 3.21 STYLE_SHEETS_USE for treatment of such values. In addition, the @mediaat-rule and the presentation media list for the @import at-rule are taken into account when evaluating CSS.

    GIF

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

    JPEG

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

    UTF-8

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

    2.4.10 White Space

    Several tests refer to white space. White space has the same definition in this document as in XML. For XML 1.0 [XML 1.0] it is

    defined in 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.

    3 mobileOK Basic Tests

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

    3.1 AUTO_REFRESH and REDIRECTION

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

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    8/16

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

    If the URI specified as part of the content attribute is not the current resource's URI, FAIL

    Else, warn

    If a Refresh HTTP header is present,

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

    Else, warn

    3.2 CACHING

    The purpose of the test is to alert providers to the fact that their content may not be cached, if it would be beneficial to do so.

    Note:

    Where both a meta element with http-equiv attribute and the corresponding HTTP header are found, the value of the HTTP

    header must be used - see also note under 2.4.5 Meta http-equiv Elements.

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

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

    Continue the test using the value from the metacontent 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-Modifiedresponse 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 responseheader

    If the HTTP response contains an ETag header and its value is again the same, and the HTTP response status is not 304

    (Not Modified), warn

    3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

    The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource is not encoded in UTF-8. The test doesnotrequire that resource alwaysbe encoded in UTF-8; the test merely checks that the resource is availablein UTF-8 encoding, ifrequested. Resources may be represented using other encodings where appropriate. This test verifies that a DDC-like device whichonly 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

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    9/16

    meta element that is the first child of the document's head element, and whose http-equiv attribute is "Content-Type", andwhose content attribute specifies a character encoding

    ... ...

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

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

    If there is no XML declaration, or UTF-8 character encoding is not specified in the XML declaration, FAIL

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

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

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

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

    For each resource specified by 2.4.7 Included Resources:

    Request the resource

    If the HTTP Content-Type header value of the response starts with "text/" but does not specify UTF-8 character encoding,

    warn

    3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP

    Note:

    In the following, an "html document" is a document that has "html" as its root element.

    Note:

    In the following, "regardless of its stated DOCTYPE" means that when assessing validity against the XHTML Basic 1.1 and XHTMLMP 1.2 DTDs this may be carried out by inserting a DOCTYPE if none is present, or by replacing the given DOCTYPE with theappropriate DOCTYPE for the DTD under test.

    Note:

    In the following, "a known XHTML version" means XHTML Basic 1.0, XHTML Basic 1.1, XHTML-MP 1.0, XHTML-MP 1.1 or

    XHTML-MP 1.2.

    If the document's Internet media type, as specified in the HTTP response Content-Type header, is not "application/xhtml+xml",

    "application/vnd.wap.xhtml+xml", or "text/html", FAIL

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

    If the document does not contain a DOCTYPE declaration, FAIL

    If the document is not an HTML document, FAIL

    If the DOCTYPE is not an XML DOCTYPE, warn

    If the document is an HTML document and it has an XML DOCTYPE:

    If the document does not declare the html namespace on its html root element, FAIL

    If the DOCTYPE refers to a known XHTML version, validate against that DOCTYPE and if invalid, warn

    Otherwise (if the DOCTYPE is not known), warn

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

    If (regardless of its stated DOCTYPE) it does not validate against the XHTML-MP 1.2 DTD, FAIL

    For each Included Resource (see 2.4.7 Included Resources):

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

    If an image is required (see also 3.15 OBJECTS_OR_SCRIPT ) and the response specifies an Internet media type that is

    not "image/jpeg" or "image/gif", FAIL

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    10/16

    If the Internet media type is "image/gif" or "image/jpeg", and the resource is not valid (see 2.4.9 Validity), FAIL

    If a style sheet is required and the response specifies an Internet media type that is not "text/css", FAIL

    If the Internet media type is "text/css" and the content is not valid CSS (see 2.4.9 Validity), FAIL

    3.5 DEFAULT_INPUT_MODE

    Note:

    inputmode is part of [XHTML Basic 1.1].

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

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

    Basic 1.1], FAIL

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

    For each textarea element:

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

    Basic 1.1], FAIL

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

    3.6 EXTERNAL_RESOURCES

    Retrieve the resource under test, and add the number of retrievals required to obtain the resource (see 2.4.4 HTTP Response)to a running total.

    For each unique Included Resource, as defined in 2.4.7 Included Resources:

    Request the referenced resource

    Add the number of HTTP requests that are required to retrieve the resource (see 2.4.4 HTTP Response) to the running total.Include in the count only those objects retrieved under the 3.15.1 Object Element Processing Rule whose type attribute isnot specified, and those whose content type is either "image/jpeg" or "image/gif" irrespective of whether the type attribute is

    specified.

    If the total exceeds 10, warn

    If this total exceeds 20, FAIL

    3.7 GRAPHICS_FOR_SPACING

    The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often usedin e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the businessinterests 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 anysites would use transparent images of any significant size for tracking.

    For each img element and object element which is an Included Resource (see 2.4.7 Included Resources):

    If all pixels are transparent,

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

    If either dimension exceeds 2 pixels, FAIL

    If more than one image with all transparent pixels is present, warn

    3.8 IMAGE_MAPS

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    11/16

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

    For each img element and object element which is an Included Resource (see 2.4.7 Included Resources):

    If a usemap attribute is present, FAIL

    If an ismap attribute is present, FAIL

    3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE

    Note:

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

    For each img element and object element which is an Included Resource (see 2.4.7 Included Resources):

    If the height or width attribute are missing, FAIL

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

    If the value specified by either the height or width attribute is greater than the corresponding dimension of the image,

    warn

    If the value specified by either the height or width attribute is less than the corresponding dimension of the image, FAIL

    3.10 LINK_TARGET_FORMAT

    Note:

    404 and 5xx HTTP status do not result in failure when conducting this test.

    Note:

    The document body of linked resources is not examined.

    For each linked resource, as defined in 2.4.8 Linked Resources:

    Request the resource

    If the Content-Type header value of the HTTP response is not one of the Internet media types listed in the Accept header in

    2.4.3 HTTP Request, warn

    If the Content-Type header value of the HTTP response does not specify a charset parameter, or does but it is not

    consistent with the value of the Accept-Charset header in 2.4.3 HTTP Request, warn

    For each document internal reference (links in the document under test that refer to the document itself):

    If there is no target for the reference or it is invalid (e.g. '#'), warn

    3.11 MEASURES

    Note:

    The intrinsic size of images must be specified as attributes of the img element and not as CSS properties (see 3.9IMAGES_RESIZING and IMAGES_SPECIFY_SIZE)

    Note:

    Only CSS Level 1 properties are considered in this test.

    For each CSS Level 1 property in the CSS Style (see 2.4.6 CSS Style) whose value is a numeric measure of length statedtogether 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

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    12/16

    3.12 MINIMIZE

    Note:

    Extraneous white space characters in script and in CSS are not considered in this test. Such an extension may be consideredin a future revision of this specification.

    Count number of white space characters (see 2.4.10 White Space) in a sequence of more than one white space character (notcounting 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 inthe document.

    Count total number of characters in document.

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

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

    3.13 NO_FRAMES

    If the document contains a frame, frameset or iframe element, FAIL

    3.14 NON-TEXT_ALTERNATIVES

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

    Note:

    An empty alt attribute is acceptable and signifies that there is no meaningful textual alternative, for example for images thatare purely decorative.

    For each img element:

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

    3.15 OBJECTS_OR_SCRIPT

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

    If a script element is present, warn

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

    onchange), warn

    For each a and link element:

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

    If an applet element is present, FAIL

    Set the context to the root element and apply the Object Element Processing Rule

    3.15.1 Object Element Processing Rule

    For each img element that has no object element ancestor (other than the context node) in this context:

    Treat this image as an Included Resource (and carry out appropriate tests).

    For each object element that has no object element ancestor (other than the context node) in this context:

    If the object element is empty, warn

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    13/16

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

    If there is no type attribute, warn

    If it is not already cached (see 2.4.7 Included Resources), retrieve the referenced resource (ignoring the type attribute)

    If the Internet media type of the retrieved resource, as indicated by its Content-Type HTTP header does not match that

    stated in the type attribute, warn

    If the Internet media type indicated by the Content-Type HTTP Header of the retrieved resource is not "image/jpeg" or

    "image/gif", warn

    Reapply this rule using the current object element as the context

    Otherwise (the object is an acceptable image):

    Treat this object as an Included Resource (and carry out appropriate tests), ignore img and object elements that aredescendants of the current object element.

    Note:

    A warning is issued when the Internet media type indicated by the type attribute is not compatible with the Default DeliveryContext because some user agents do not take into account the type attribute of object elements and this may cause the useragent to retrieve large incompatible objects with consequences to performance and cost.

    Note:

    An HTTP 406 status on retrieval of a resource referenced by an object element does not constitute a FAIL.

    3.16 PAGE_SIZE_LIMIT

    Retrieve the document under test, if its size (excluding any redirections discussed under 2.4.4 HTTP Response) exceeds 10

    kilobytes, FAIL

    Add to a running total (total size) the size of all the HTTP response bodies that are required to retrieve the document undertest (2.4.4 HTTP Response).

    For each unique Included Resource, as defined in 2.4.7 Included Resources:

    Add the size of all the response bodies that are required to retrieve the resource (see 2.4.4 HTTP Response) to the runningtotal. Include in the total only those objects retrieved under the 3.15.1 Object Element Processing Rule whose type attribute

    is not specified, and those whose Internet media type as indicated by the Content-Type HTTP header is either "image/jpeg"or "image/gif" irrespective of whether the type attribute is specified.

    If the total exceeds 20 kilobytes, FAIL

    Note:

    In the case of resources that are referenced more than once in the document under test, and where, as discussed under 2.4.7Included Resources, they are cached, it is the initial retrieval of that resource (as determined by the first reference in documentorder) that counts towards the total.

    Note:

    Where the 3.15.1 Object Element Processing Rule yields a resource that is found to be cached, objects that must be assessedin the course of yielding the cached resource count towards the total.

    3.17 PAGE_TITLE

    This test does not determine whether the title is meaningful.

    If a title element is not present in the head element, or is empty, or contains only white space (see 2.4.10 White Space), FAIL

    3.18 POP_UPS

    For each a, link, form, and base element:

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    14/16

    If a target attribute is present,

    If its value is not one of "_self", "_parent", or "_top", FAIL

    3.19 PROVIDE_DEFAULTS

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

    Check that exactly one input element within this group has its checked attribute set to "checked", and if this is not the case,warn

    For each select element:

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

    If there is more than one option element whose selected attribute is set to "selected", and the multiple attribute is not set

    to "multiple", warn

    3.20 STYLE_SHEETS_SUPPORT

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

    3.21 STYLE_SHEETS_USE

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

    Note:

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

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

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

    If any element has a style attribute, warn

    If all styles are restricted to presentation media types other than "handheld" or "all" by means of @media at-rules, warn

    If the CSS Style contains at-rules (other than the @media at-rule, and the presentation media type list of the @import at-rule),properties, or values that are not recognized as being specified in CSS Level 1, or if the value of a recognized CSS Level 1

    property is incompatible with the property, warn

    3.22 TABLES_ALTERNATIVES

    If a table element exists, warn

    3.23 TABLES_LAYOUT

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

    For each table element:

    If it contains at most one tr element, FAIL

    If no tr element contains more than one td element, FAIL

    For each nested td element:

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    15/16

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

    3.24 TABLES_NESTED

    For each table element:

    If it contains a table element, FAIL

    A Acknowledgments (Non-Normative)

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

    The editors acknowledge significant written contributions from:

    Dominique Hazal-Massieux, W3CPhil Archer, ICRAFranois Daoust, W3C

    B References (Non-Normative)

    Best PracticesMobile Web Best Practices 1.0, Jo Rabin, Charles McCathieNevile, W3C Recommendation, 29 July 2008 (See

    http://www.w3.org/TR/2008/REC-mobile-bp-20080729/)CSS Level 1

    Cascading Style Sheets, level 1, Hkon Wium Lie, Bert Bos, W3C Recommendation 17 Dec 1996, revised 11 Jan 1999 (Seehttp://www.w3.org/TR/1999/REC-CSS1-19990111/)

    GIFGRAPHICS INTERCHANGE FORMAT, Version 89a, CompuServe Incorporated, 1990 (See http://www.w3.org/Graphics/GIF/spec-gif89a.txt)

    JPEGRecommendation T.81, 18 September 1992 (See http://www.w3.org/Graphics/JPEG/itu-t81.pdf)

    RFC 2119Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997 (See http://tools.ietf.org/html/rfc2119.txt )

    RFC 2616Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L.Masinter, P. Leach, T. Berners-Lee, June 1999 (See http://tools.ietf.org/html/rfc2616)

    RFC 2617

    HTTP Authentication: Basic and Digest Access Authentication, J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.Leach, A. Luotonen, L. Stewart, June 1999 (See http://tools.ietf.org/html/rfc2617)

    RFC 3629UTF-8, a transformation format of ISO 10646, F. Yergau, November 2003 (See http://tools.ietf.org/html/rfc3629)

    WCAG 1.0Web Content Accessibility Guidelines 1.0, W. Chisholm, G. Vanderheiden and I. Jacobs, eds., W3C Recommendation, 5 May1999 (See http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/)

    XHTML Basic 1.1XHTML Basic 1.1, Mark Baker, Masayasu Ishikawa, Shinichi Matsui, Peter Stark, Ted Wugofski, Toshihiko Yamakami (eds),W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/)

    XHTML ModularizationXHTML Modularization 1.1, Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa, Mark Birbeck(eds), W3C Recommendation, 08 October 2008 (See http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/)

    XML 1.0Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Franois

    Yergeau, W3C Recommendation 26 November 2008 (See http://www.w3.org/TR/2008/REC-xml-20081126/)

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

    This appendix lists all Best Practices and indicates whether each has a corresponding test in mobileOK Basic.

    Best Practice mobileOK Basic

    ACCESS_KEYS

    AUTO_REFRESH X

    AVOID_FREE_TEXT

    BACKGROUND_IMAGE_READABILITY

    BALANCE

    CACHING X

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt

    16 21/09/2010 0

  • 8/8/2019 W3C MobileOK Basic

    16/16

    Best Practice mobileOK Basic

    CAPABILITIES

    CENTRAL_MEANING

    CHARACTER_ENCODING_SUPPORT X

    CHARACTER_ENCODING_USE X

    CLARITY

    COLOR_CONTRAST

    CONTENT_FORMAT_PREFERRED

    CONTENT_FORMAT_SUPPORT X

    CONTROL_LABELLINGCONTROL_POSITION

    COOKIES

    DEFAULT_INPUT_MODE X

    DEFICIENCIES

    ERROR_MESSAGES

    EXTERNAL_RESOURCES X

    FONTS

    GRAPHICS_FOR_SPACING X

    IMAGE_MAPS X

    IMAGES_RESIZING X

    IMAGES_SPECIFY_SIZE X

    LARGE_GRAPHICS X

    LIMITEDLINK_TARGET_FORMAT X

    LINK_TARGET_ID

    MEASURES X

    MINIMIZE X

    MINIMIZE_KEYSTROKES

    NAVBAR

    NAVIGATION

    NO_FRAMES X

    NON-TEXT_ALTERNATIVES X

    OBJECTS_OR_SCRIPT X

    PAGE_SIZE_LIMIT X

    PAGE_SIZE_USABLE

    PAGE_TITLE XPOP_UPS X

    PROVIDE_DEFAULTS X

    REDIRECTION X

    SCROLLING

    STRUCTURE

    STYLE_SHEETS_SIZE

    STYLE_SHEETS_SUPPORT X

    STYLE_SHEETS_USE X

    SUITABLE

    TAB_ORDER

    TABLES_ALTERNATIVES X

    TABLES_LAYOUT X

    TABLES_NESTED X

    TABLES_SUPPORT

    TESTING

    THEMATIC_CONSISTENCY

    URIS

    USE_OF_COLOR

    VALID_MARKUP X

    mobileOK Basic Tests 1.0 http://www.w3.org/TR/mobileOK-basic10-tests/#htt