W3C mobileOK Basic Tests 1.0

1 Introduction

This document describes W3C MobileOK mobileOK Basic tests tests, which are based on Mobile Web Best Practices [BestPractices] .

mobileOK Basic is the lesser of two levels of claim, the higher greater level being mobileOK, described separately. Claims to be W3C mobileOK Basic are represented using content labels, also described separately.

The intention of mobileOK is to help catalyze development of Web sites that provide a functional user experience in a mobile context.

1.1 Levels of mobileOK

Two levels of mobile OK tests are defined: "mobileOK Basic" and "mobileOK".

1.1.1 mobileOK Basic

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

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

mobileOK Basic compliance conformance should be considered only a first step towards building a harmonized experience for mobile users. Compliance Conformance merely demonstrates that a basic experience is available, interoperable with a large number of mobile devices. mobileOK Basic compliance conformance says nothing about richer, more sophisticated sophisticated, experiences that the resource may also be able to provide. available.

1.1.2 mobileOK

The (full) mobileOK tests include the mobileOK Basic tests and are based upon 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 compliance 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 defined in [BestPractices] . Practices.

mobileOK tests will be described in a forthcoming mobileOK Tests document. separately.

1.1.3 Out of Scope

Note that not all Mobile Web Best Practices map to a test in mobileOK conformance tests. Some some best practices, like TESTING , are advisable but do not meaningfully translate into concrete tests, whether their outcome is machine- or human-verifiable.

mobileOK does The tests do not assess the usability of a Web site. It assesses 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 tests best practices, and hence the tests, are not promoted as a guideline guidance for achieving the optimal user experience. Many devices go well beyond the basic specifications assumed devices' capabilities exceed those defined by these tests. the DDC. It will often be possible, and generally desirable, to provide an interface experience designed to take advantage of the extra capabilities.

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

1.2 Applicability

The tests apply to a URI (or group of URIs). URI. Passing the tests means that under the right circumstances, accessing that resolving a URI will retrieve conformant content that conforms to the criteria defined, and that its delivery also conforms. That is to say that delivered in a conformant manner.

That is, the tests do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. well-formed markup), VALID_MARKUP ), but to how it is delivered to a mobile device (e.g. the presence of caching headers in the HTTP response). CACHING ). For convenience, this document will hereafter refer refers to "mobileOK content" with the understanding that mobileOK labels apply it refers to more than just the content itself.

mobileOK says nothing about what may be delivered to non-mobile devices from that URI; however, note that a mobileOK URI must return mobileOK content by default if the nature of the user agent cannot be reliably determined. devices.

1.3 Claiming mobileOK conformance

A standard mechanism will be defined that allows content providers to make the claim that their content a URI or group of URIs, such as a Web site, conforms to mobileOK at either the lower Basic or the higher level. The manner of making claims mobileOK. It will be possible to make claims in the form of a machine-processable content label. form. It will also be possible to notify end users of the presence of the claim by means of a logo and by provision of human readable equivalent of the label. human-readable mark.

A mobileOK content label 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.

MobileOK content labels will be described in mobileOK Content Labels [ContentLabels] . 1.4 Who is mobileOK for? mobileOK has value at many points in the content authoring and delivery chain for mobile devices: Content Developers

Developers who create content which follows Mobile Web Best Practices, and which passes tests outlined in this document, have added value for mobile users. They can advertise this to consumers The details of their content through the mobileOK labels. Tools Likewise, tools that can produce, parse, adapt or manipulate mobileOK content (browsers, content management systems, authoring tools, content adaptation systems, etc.) add value for authors, and can advertise this capability. Content Providers Sites that are concerned with providing a quality experience to mobile users can look for a mobileOK label when acquiring content and tools. Content Discovery Services Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK label and possibly prioritize mobileOK content. Content Consumers End consumers of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content. mechanism will be described separately.

Certification Providers Certification providers may wish to offer to certify conformance to mobileOK tests; entities such as content providers that come to rely on mobile content may require more verification that content they provide is mobileOK.

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 apply are only meaningful when the URI under test resolves to HTML content delivered over HTTP.

2.2 Testing Outcomes

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

In addition to generating a PASS or FAIL tests Tests may also generate a number of informative warn s whose purpose is to alert the tester that in some circumstances the content being assessed may contravene Best Practices. 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. Tests have been formulated to out as they may be executed independently. In order to allow for a testing environment in which as much information as possible is made available, some Some tests have been designed to assess aspects of the content that are not allowed disallowed by other tests. Editor's Note: This example may not be right depending on outcome of discussions on XHTML Basic 1.1. tests; this is deliberate and is intended to allow testing environments to provide as much information as possible.

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

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

Provide information about the cause of failure
Continue individual tests as far as is possible
Carry out as many tests as is reasonable

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
Include a User-Agent header indicating the default delivery context: context by sending exactly this header:
```
User-Agent:
W3C
mobileOK
DDC
(http://www.w3.org/2006/07/mobileok-ddc)
```
Include an Accept header indicating that Internet media types understood by the default delivery context are accepted: accepted by sending exactly this header:
```
Accept:
application/xhtml+xml,text/css,image/jpeg,image/gif

application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
```
Editor's Note: The group has requested clarification of which Internet media types are acceptable for use with XHTML Basic 1.1.
Include an Accept-Charset header indicating that only UTF-8 is accepted: accepted by sending exactly this header:
```
Accept-Charset:
UTF-8
```

2.3.3 HTTP Response

If an HTTP response specifies an HTTP 3xx status, a test implementation should attempt to respect the server's response (e.g. follow a 302 redirect). Note that redirects should be counted against the limit defined in the 3.6 EXTERNAL_RESOURCES test.
If an HTTP request fails for any reason during a test (network-level error, DNS resolution error, non-HTTP response, or server returns an HTTP 4xx or 5xx status), the test outcome should be considered FAIL with a warn ing about the error. .
Documents sometimes include meta elements with an http-equiv attribute. These are sometimes considered substitutes for HTTP response headers. Test implementations should respect only HTTP response headers. For each meta element that exists, however, if a response header exists whose name matches its http-equiv attribute value, and the header's value differs from the element's content attribute value, the test should generate a warning. warn ing.

2.3.4 External Resources via link elements CSS Style

Several Some tests refer to external resources that may be attached to a document "CSS Style" information. Assemble the CSS Style by means of certain link elements. These elements are defined here in order to avoid redundancy below: using the contents of:

External resources attached via link elements are those resources which appear in the href style attribute of a link any element whose rel attribute is "stylesheet",
charset style attribute is either not present or is present with value "UTF-8", elements whose type attribute is either not present or is present with value "text/css", and whose media attribute is either not present or is present with and contains value "all" or "handheld".
2.3.5 CSS Style Some tests refer to "CSS Style" information. Assemble the CSS Style by using the contents of: style elements
resources linked by xml-stylesheet processing instructions
external stylesheet resources linked via link elements, as defined above in 2.3.4 External 2.3.6 Included Stylesheet Resources via link elements
resources linked by CSS @import at-rules

In the course of assembling the CSS Style:

observe the CSS Level 1 cascade
ignore those resources and style elements specified as having an Internet media type other than "text/css"
if a preferred style is specified, use only those resources and ignore alternative style resources
retrieve only those resources that have no CSS media type, or whose CSS media type is contains "handheld" or "all"
use only those rules that are not restricted as to their CSS media type or whose media type is contains "handheld" or "all"

2.3.5 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. Examples include image and stylesheet resources.

Included resources are defined as those that are referenced by:

img elements
object elements
link elements as defined in 2.3.6 Included Stylesheet Resources
images included by background-image properties in the CSS Style ( 2.3.4 CSS Style )
@import directives in the CSS Style ( 2.3.4 CSS Style )
xml-stylesheet processing instructions

2.3.6 Included Stylesheet Resources

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

2.3.7 Visible Linked Resources

Linked resources are resources linked to from the resource being tested, but which are not vital to rendering that resource. Examples include resources linked via hyperlinks.

Linked resources are defined as those that are referenced by:

the href attribute of a (anchor) elements, and whose URI begins with the "http" or "https" scheme
the action attribute of form elements whose method attribute is not present or is present with value "get"

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 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 page, resource's URI, FAIL

Else, warn

If a Refresh HTTP header is present,

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

Else, warn

PASS

3.2 CACHING

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

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

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

If an Expires and Date HTTP header are present, and the Expires header specifies a date which is not later than what the Date header specifies, or if the Expires header specifies an invalid date (e.g. "0"), warn

If the HTTP response contains a Last-Modified header,

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

If the HTTP response contains a Last-Modified header and its value is again the same, and the HTTP response status is not 304 (Not Modified), FAIL 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), FAIL warn

PASS

3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

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

This requirement, UTF-8 support, has been extensively debated and the HTTP group solicits feedback on it.

Determine the character encoding specified by the following, if present:

Content-Type response header by appending a "charset" suffix. For example, one might specify (e.g. "application/xhtml+xml;charset=UTF-8")
XML declaration (e.g. "<?xml encoding="UTF-8"?>")
meta element that is the "Shift_JIS" encoding with a header value first child of "text/html;charset=Shift_JIS". Note also that a the document's Content-Type head header value of "text/html" with no charset suffix implies element, and whose http-equiv attribute is "Content-Type", and whose content attribute specifies a default character encoding of ISO-8859-1. as above (e.g. "<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>)
Editor's Note: This test still needs to be vetted against feedback from the XHTML Basic group.

If character encoding is not explicitly specified in at least one of these ways, FAIL

If a character encoding is specified in the Content-Type HTTP header more than one way, and is not "UTF-8", all values are the same, FAIL

If the any character encoding attribute of the XML header is present and specified is not "UTF-8", FAIL

If the document is not valid UTF-8, FAIL

For each external resource as defined in 2.3.4 External 2.3.5 Included Resources via link elements :

Request the URI indicated by the href attribute

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

PASS

3.4 CONTENT_FORMAT_SUPPORT

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

Editor's Note: The group is still debating whether to include the other acceptable Internet media types for XHTML Basic, "application/xml" and "text/xml", in this header. The group is also debating whether to include the XHTML MP Internet media type of "application/vnd.wap.xhtml+xml".

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

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

For each external resource linked via: @import directives in the CSS Style ( 2.3.5 CSS Style ) img elements link elements included resource, as defined in by 2.3.4 External 2.3.5 Included Resources via link elements :

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

If the Internet media type is "image/gif" or "image/jpeg", and the resource is invalid according to the specification of GIF89a or JPEG, respectively, FAIL

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

PASS

3.5 DEFAULT_INPUT_MODE

For example, a text input control that accepts a quantity should only receive numeric input, and therefore should set the inputmode attribute to "user digits". Note that inputmode is part of [XHTMLBasic11] .

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

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

For each textarea element:

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

PASS

3.6 EXTERNAL_RESOURCES

Editor's Note: The group would like to solicit feedback on the limits imposed by this test. Are 10 and 20 reasonable? Should there be a hard FAIL at a number like 20 or only a warn limit?

Count the total number of unique external resources referenced by: @import directives in the CSS Style ( 2.3.5 CSS Style ) xml-stylesheet processing instructions img elements object elements link elements included resources, as defined in 2.3.4 External 2.3.5 Included Resources via link elements .

For each such resource:

Request the resource, and add one to a running count

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

If this total exceeds 10, warn

If this total exceeds 20, FAIL

PASS

3.7 GRAPHICS_FOR_SPACING

Editor's note:

The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often used in e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the business interests of mobile sites, that it is undesirable to fail sites that use such small transparent images. Therefore this machine-testable test merely warns warn s about the presence of small (at most 2x2) transparent images and FAILs 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:

If all pixels are transparent,

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

If either dimension exceeds 2 pixels, FAIL

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

PASS

3.8 IMAGE_MAPS

If an area element is present, FAIL

For each img element:

If a usemap attribute is present, FAIL

PASS

3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE

For each img element:

If the image has an intrinsic size, is in a raster format (i.e. is a JPEG or GIF image, for example, as opposed to SVG),

If the height or width attribute are missing, FAIL

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

If either the height and or width specified do not match are greater than the size 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 LARGE_GRAPHICS No test is defined specifically for this Best Practice, since tests for IMAGES_RESIZING and SCROLLING already cover its requirements in mobileOK Basic

3.11 3.10 LINK_TARGET_FORMAT

For each a element: Issue an HTTP GET request for the URI referenced linked resource, as defined in the href attribute If the HTTP response's Content-Type header is not "application/xhtml+xml", "text/html", "text/css", "image/jpeg" or "image/gif", warn 2.3.7 Visible Linked Resources :

Editor's Note: See above notes on application/xml , text/xml and application/vnd.wap.xhtml+xml in this context. For each link element whose rel and rev attribute are not "stylesheet", charset attribute is not present or is present with value "UTF-8", type attribute is not present or is present with one of the allowable Content-Type header values above, media attribute is either not present or is present with value "all" or "handheld", href attribute value begins with "http" or "https" and is a URI which refers to a resource that is not the same as the resource being tested:

Request the URI indicated by the href attribute resource

If the HTTP response's Content-Type header header's value is not one of those listed above, warn For each form element that has a method attribute whose value is "GET": Request the URI indicated by the action attribute As above, if Internet media types listed in the HTTP response's Content-Type Accept header is not one of those listed above, in 2.3.2 HTTP Request , warn

PASS

3.12 3.11 MEASURES

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

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

PASS

3.13 3.12 MINIMIZE

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

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

Count total number of characters in document

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

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

PASS

3.14 3.13 NO_FRAMES

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

PASS

3.15 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, FAIL

PASS

3.16 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 "javascript:", the "javascript:" scheme, FAIL

If an applet element is present, FAIL

If an object element is present,

If the element is empty, warn

If element body is non-empty and does not consist of text or an img element that refer refers to an image in a supported format, FAIL

PASS

3.17 3.16 PAGE_SIZE_LIMIT

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

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

Request the referenced resource

Add the size of the document's markup plus its linked resources response body to a running total

If the total exceeds 20 kilobytes, FAIL

PASS

Note: To calculate the size of the linked resources, add up the size of each included style sheet (see 2.3.5 CSS Style

), image, and object of the appropriate type.

3.18 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, FAIL

PASS

3.19 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.20 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 input element:

If element's type attribute is "radio",

If the document contains no input element whose name attribute's value matches that of this radio input, and whose checked attribute is set to some value, warn

For each select element:

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

PASS

3.21 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.

Editor's Note:

This is a relatively simple test that detects some situations in which an element is forced to render wider than 120 pixels. It does not detect all such situations as this would really require fully rendering the page. The group would like to solicit feedback on this test: whether it can be tightened without adding much complexity, and whether it is consistent with how most mobile browsers would render pages. We wish 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE together effectively test conformance to avoid false positives: would this the LARGE_GRAPHICS best practice as well. Hence, no additional test warn on a page for that most mobile browsers render less than 120 pixels wide? best practice is specified.

For each block-level element, which includes those whose CSS property display is "block", either by default or explicitly set, as well as the body, img, and object elements:

If CSS property width is set in pixels, or, the element has a width attribute

Add to the property/attribute value the value of the following CSS box properties if set in pixels:

border-left-width, border-right-width (may also be set by border-width, border-left, border-right, border )
margin-left, margin-right (may also be set by margin )
padding-left, padding-right (may also be set by padding )

If the sum exceeds 120, warn

Otherwise, for each of the parent elements, its parent, and so on up to the document root:

Add to that sum the values of the border, margin and padding properties as above

If the sum exceeds 120, warn

Otherwise continue with the next parent

For each table element:

Add together If the value of its width attribute exceeds 120, warn

Sum its border, margin and padding property values as above

For each contained tr element:

Add to the sum its border, margin and padding property values

For each contained td or th element:

Add to the that sum its border, margin and padding property values

Add its width, as specified by the CSS width property, if present

If the sum exceeds 120, warn

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

PASS

3.22 3.21 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.5 2.3.4 CSS Style ) contains rules involving referencing the position,display or float properties, warn

PASS

3.23 3.22 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 are not supported in XHTML Basic. It also looks for commonly-used elements that were deprecated in HTML 4, and are also not supported in XHTML Basic.

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

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

If any element has a style attribute, warn

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

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

If the CSS Style contains a single @media rule that specifies the media type screen, warn

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

PASS

3.24 3.23 TABLES_ALTERNATIVES

If a table element exists, warn

Editor's note: This test is tentative. The group would like to solicit feedback on this test. All that a machine may reasonably do to check compliance with Best Practice is warn about any use of table . It is not clear whether legitimate uses of table are infrequent enough that this warning will be more useful than a nuisance or not.

3.25 3.24 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 tr elements, FAIL

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

For each nested td element:

If the element is empty, or contains only an image whose real dimensions are 2x2 or less, FAIL

PASS

3.26 3.25 TABLES_NESTED

If a table element exists,

If a table element exists somewhere inside it, FAIL

PASS

3.27 3.26 VALID_MARKUP

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

PASS

Best Practice	mobileOK Basic	mobileOK
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

W3C mobileOK Basic Tests 1.0

W3C Working Draft 19 December 2006 30 January 2007

Abstract

Status of this Document

Table of Contents

Appendices

1 Introduction

1.1 Levels of mobileOK

1.1.1 mobileOK Basic

1.1.2 mobileOK

1.1.3 Out of Scope

1.1.4 Beyond mobileOK

1.2 Applicability

1.3 Claiming mobileOK conformance

2 Conformance

2.1 Validity of the Tests

2.2 Testing Outcomes

2.3 Conduct of Tests

2.3.1 Order of Tests

2.3.2 HTTP Request

2.3.3 HTTP Response

2.3.4 External Resources via link elements CSS Style

2.3.5 Included Resources

2.3.6 Included Stylesheet Resources

2.3.7 Visible Linked Resources

3 mobileOK Basic Tests

3.1 AUTO_REFRESH (partial) and REDIRECTION

3.2 CACHING

3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

3.4 CONTENT_FORMAT_SUPPORT

3.5 DEFAULT_INPUT_MODE

3.6 EXTERNAL_RESOURCES

3.7 GRAPHICS_FOR_SPACING

3.8 IMAGE_MAPS

3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE

3.11 3.10 LINK_TARGET_FORMAT

3.12 3.11 MEASURES

3.13 3.12 MINIMIZE

3.14 3.13 NO_FRAMES

3.15 3.14 NON-TEXT_ALTERNATIVES (partial)

3.16 3.15 OBJECTS_OR_SCRIPT (partial)

3.17 3.16 PAGE_SIZE_LIMIT

3.18 3.17 PAGE_TITLE (partial)

3.19 3.18 POP_UPS

3.20 3.19 PROVIDE_DEFAULTS (partial)

3.21 3.20 SCROLLING (partial)

3.22 3.21 STYLE_SHEETS_SUPPORT (partial)

3.23 3.22 STYLE_SHEETS_USE

3.24 3.23 TABLES_ALTERNATIVES

3.25 3.24 TABLES_LAYOUT (partial)

3.26 3.25 TABLES_NESTED

3.27 3.26 VALID_MARKUP

A Acknowledgements (Non-Normative)

B References (Non-Normative)

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