Copyright ©2006 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines the tests that provide the basis for making a claim to be W3C® mobileOK Basic™ compliant and are based upon W3C Mobile Web Best Practices [BestPractices]. Content which passes the tests has taken a number of steps to provide a functional user experience for users of basic mobile devices whose capabilities match those of the Default Delivery Context (DDC).
mobileOK Basic is the lesser of two levels of claim, the higher level being mobileOK, described separately. Claims to be W3C mobileOK Basic are represented using content labels, also described separately.
mobileOK assesses interoperability. It does not measure usability and does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible on the DDC.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a First Public Working Draft of the W3C MobileOK Basic Tests 1.0; the group is currently working on further changes to the document which will have a more-or-less substantial effect on some of the tests. Trial implementations of the tests are most welcome, but the results should be noted as subject to change.
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. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This draft reflects an important structural change since the last draft: the single mobileOK Scheme document has been split into three: mobileOK Basic Tests, mobileOK Tests, and mobileOK Labels. The documents describe the test suite for mobileOK Basic, mobileOK, and the mobileOK content labels, respectively. At this time, the group is publishing a draft of only the mobileOK Basic Tests document. Work on other documents is still ongoing.
This document further reflects substantial changes in the tests themselves based on feedback and group discussions since the last public draft.
1 Introduction
1.1 Levels of mobileOK
1.1.1
mobileOK Basic
1.1.2
mobileOK
1.1.3
Out of Scope
1.2 Applicability
1.3 Claiming mobileOK
conformance
1.4 Who is mobileOK for?
2 Conformance
2.1 Validity of the Tests
2.2 Testing Outcomes
2.3 Conduct of Tests
2.4 Testing Parameters
2.4.1
HTTP Request
2.4.2
Style
Information
3 mobileOK Basic Tests
3.1 AUTO_REFRESH (partial) and
REDIRECTION
3.2 CHARACTER_ENCODING_SUPPORT and
CHARACTER_ENCODING_USE
3.3 CONTENT_FORMAT_SUPPORT
3.4 DEFAULT_INPUT_MODE
3.5 EXTERNAL_RESOURCES
3.6 GRAPHICS_FOR_SPACING
3.7 IMAGE_MAPS
3.8 IMAGES_RESIZING and
IMAGES_SPECIFY_SIZE
3.9 LARGE_GRAPHICS
3.10 LINK_TARGET_FORMAT
3.11 MEASURES
3.12 <meta> element consistency
with HTTP header
3.13 MINIMIZE
3.14 NO_FRAMES
3.15 NON-TEXT_ALTERNATIVES
(partial)
3.16 OBJECTS_OR_SCRIPT (partial)
3.17 PAGE_SIZE_LIMIT
3.18 PAGE_TITLE (partial)
3.19 POP_UPS
3.20 PROVIDE_DEFAULTS (partial)
3.21 SCROLLING (partial)
3.22 STYLE_SHEETS_SUPPORT
(partial)
3.23 STYLE_SHEETS_USE
3.24 TABLES_ALTERNATIVES
3.25 TABLES_LAYOUT (partial)
3.26 TABLES_NESTED
3.27 VALID_MARKUP
A Acknowledgements
(Non-Normative)
B References (Non-Normative)
C Best Practices' Relation to mobileOK
Tests (Non-Normative)
This document describes W3C MobileOK Basic tests which are based on Mobile Web Best Practices [BestPractices].
mobileOK Basic is the lesser of two levels of claim, the higher 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.
Two levels of mobile OK tests are defined: "mobileOK Basic" and "mobileOK".
mobileOK Basic tests are based upon a limited subset of the Mobile Web Best Practices and are all machine-verifiable, hence conformance to mobileOK Basic is simple to check or verify.
Content passing the tests demonstrates that the content provider has taken basic steps to provide a functional experience for mobile users.
mobileOK Basic compliance should be considered only a first step towards building a harmonized experience for mobile users. Compliance merely demonstrates that a basic experience is available, interoperable with a large number of mobile devices. mobileOK Basic compliance says nothing about richer, more sophisticated experiences that the resource may also be able to provide.
The (full) mobileOK tests include the Basic tests and are based upon a larger subset of 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 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 Best Practices defined in [BestPractices].
mobileOK tests will be described in a forthcoming mobileOK Tests document.
Note that not all Mobile Web Best Practices map to a test in mobileOK conformance tests. Some best practices, like TESTING, are advisable but do not meaningfully translate into concrete tests, whether machine- or human-verifiable.
mobileOK does not assess the usability of a Web site. It assesses whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices.
The tests are not promoted as a guideline for achieving the optimal user experience. Many devices go well beyond the basic specifications assumed by these tests. It will often be possible, and generally desirable, to provide an interface designed to take advantage of the extra capabilities.
Content providers should provide an interface that is mobileOK conformant to ensure a basic level of interoperability. Providers are encouraged to provide enhanced versions as well, when these are appropriate to their application and devices that are accessing them.
The tests apply to a URI (or group of URIs). Passing the tests means that under the right circumstances, accessing that URI will retrieve content that conforms to the criteria defined, and that its delivery also conforms. That is to say that 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), but to how it is delivered to a mobile device (e.g. the presence of caching headers in the HTTP response). For convenience, this document will hereafter refer to "mobileOK content" with the understanding that mobileOK labels apply 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.
A standard mechanism will be defined that allows content providers to make the claim that their content conforms to mobileOK at either the lower or the higher level. The manner of making claims will be in the form of a machine processable content label. It will be possible to notify users by means of a logo and by provision of human readable equivalent of the label.
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].
mobileOK has value at many points in the content authoring and delivery chain for mobile devices:
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 of their content through the mobileOK labels.
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.
Sites that are concerned with providing a quality experience to mobile users can look for a mobileOK label when acquiring content and tools.
Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK label and possibly prioritize mobileOK content.
End consumers of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content.
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.
This section details the tests that must be carried out in order to claim mobileOK Basic. Tests are presented as simple pseudo-code.
Individual rests may result have result of PASS or FAIL. PASS is required from all tests in order to claim mobileOK Basic.
In addition to generating a PASS or FAIL tests may also generate a number of informative WARNs whose purpose is to alert the tester that in some circumstances the content being assessed may contravene Best Practices.
mobileOK Basic does not prescribe the order in which tests are
to be carried out. Tests have been formulated to be executed
independently. In order to allow for a testing environment in which
as much information as possible is made available, some tests have
been designed to assess aspects that are not allowed by other
tests. For example the test for 3.23 STYLE_SHEETS_USE points
out that style sheets should be used in preference to markup
elements such as bold
, even though the
bold
element is also disallowed by the test for
3.3
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:
Continue individual tests as far as is possible
Carry out as many tests as is reasonable
All tests assume that the document and responses should be compatible with a device matching the Default Delivery Context's profile.
Tests are to be conducted using the parameters below.
Include a User-Agent
header indicating the default
delivery context:
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:
Accept: application/xhtml+xml,text/css,image/jpeg,image/gif
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".
Include an Accept-Charset
header indicating that
UTF-8 is accepted:
Accept-Charset: UTF-8
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
resources linked by link
elements or HTTP
link
headers that specify "stylesheet" as the value of
their rel
attribute
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 "handheld" or "all"
use only those rules that are not restricted as to their CSS media type or whose media type is "handheld" or "all"
This section describes tests for mobileOK Basic. Tests are organized alphabetically by the Best Practice from which they derive. Where a test derives from more than one Best Practice it is placed according to the one that occurs earliest in dictionary order.
This test does not determine whether the user is able to opt out of refresh.
If a meta
element is present
with http-equiv
attribute value of "refresh",
If the URI specified is not the current page, FAIL
WARN
If a Refresh
HTTP header is
present,
If the URI specified in the header value is not the current page, FAIL
WARN
PASS
If no character encoding is specified in the
Content-Type
HTTP header and it defaults to something
other than UTF-8 ("text/html" is a notable example, as it implies
the ISO-8859-1 character encoding), or, if a character encoding is
present and it is not UTF-8 (for example,
"application/xhtml+xml;charset=Shift_JIS"), FAIL
If the encoding attribute of the XML header is present and is set to anything other than UTF-8, FAIL
If the document is not valid UTF-8, FAIL
For each resource linked via a
link
or style
element, request the
resource:
If the character encoding is not specified
in HTTP response Content-Type
header or the response
specifies an Internet media type starting with "text/" and the
character encoding is not "UTF-8", WARN
PASS
If the document's Internet media type, as
specified in the HTTP response Content-Type
header, is
not "application/xhtml+xml" 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", WARN
If the document does not validate against the XHTML Basic 1.1 DTD, FAIL
For each resource linked via an
img
, link
, style
element or
@import
statement within a stylesheet, request the
resource:
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
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 [XHTML11].
For each input
element with
attribute type
whose value is "text", or
textarea
element:
If the element is empty and an
inputmode
attribute is not present, WARN
PASS
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?
If the total number of unique external
resources referenced by style
, img
,
link
, or object
elements exceeds 10,
WARN
If this total exceeds 20, FAIL
PASS
For each img
element:
If all pixels are transparent and image dimensions are 2x2 or less, WARN
PASS
If an area
element is present,
FAIL
For each img
element:
If a usemap
attribute is
present, FAIL
PASS
For each img
element:
If the image has an intrinsic size,
If the height
or
width
attribute are missing, FAIL
If the height
or
width
attribute do not specify a size in pixels,
FAIL
If height and width specified do not match the size of the image, FAIL
PASS
No test is defined specifically for this Best Practice, since tests for IMAGES_RESIZING and SCROLLING already cover its requirements in mobileOK Basic
For each a
element:
Issue an HTTP GET request for the URI
referenced 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
Editor's Note: See above notes on
application/xml
, text/xml
and
application/vnd.wap.xhtml+xml
in this context.
PASS
For each numeric measure in the CSS Style:
If the unit is not "em", "ex" or "%", FAIL
PASS
<meta>
element consistency with HTTP headerThis test does not map to a specific best practice. It merely provides warnings deemed useful to developers.
For each meta
element with an
http-equiv
attribute:
If an HTTP header is present whose name
matches the http-equiv
attribute's value,
If the header's value does not match the
meta
element's content
attribute,
WARN
PASS
Count number of whitespace characters in a
sequence of more than one whitespace character (not counting the
first), which exist outside of a pre
,
style
or script
element
Add to this count the number of characters comprising XML comments. This total is the number of extraneous characters in the document.
Count total number of characters in document
If the number of extraneous characters exceeds 10% of the count of characters in the document, WARN
If the number of extraneous characters exceeds 25% of the count of characters in the document, FAIL
PASS
If the document contains a
frame
, frameset
or iframe
element, FAIL
PASS
This test does not determine whether the alternative text is meaningful.
For each img
element:
If an alt
attribute is not
present, FAIL
PASS
This test does not determine whether the document is still usable without the objects or scripts.
If a script
element is present,
WARN
If 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 to an
image in a supported format, FAIL
PASS
If the size of the document's markup exceeds 10 kilobytes, FAIL
If the size of the document's markup plus its linked resources 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.4.2 Style Information), image, and object of the appropriate type.
This test does not determine whether the title is meaningful.
If a title
element is not
present in the head
element, or is empty,
FAIL
PASS
For each a
, link
,
form
, base
element:
If a target
attribute is
present,
If its value is not one of "_self", "_parent", or "_top", FAIL
PASS
In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.
For each input
element:
If element's type
attribute is
"radio",
If the document contains no
input
element whose name
attribute's
value matches that of this radio input, and whose
checked
attribute is set to some value,
WARN
For each select
element:
If there is no nested option
element whose selected
attribute is set to some value,
WARN
PASS
This test does not determine whether secondary scrolling created by wide objects can be avoided, nor does it catch all possible objects which may render wider than 120 pixels.
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 to avoid false positives: would this test WARN on a page that most mobile browsers render less than 120 pixels wide?
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 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 sum its border, margin and padding property values
If the sum exceeds 120, WARN
PASS
In addition, a human test is needed here to verify whether the page is readable without a style sheet.
If the CSS Style contains rules involving
the display
or float
properties,
WARN
PASS
This test does not require that any CSS styles be used, since in some cases, no presentation information is required at all (for example, a simple page of text).
This test looks for elements in the Text Extension module defined by [XHTMLModularization], since these are not supported in XHTML Basic. It also looks for commonly-used elements that were deprecated in HTML 4, and are also not supported in XHTML Basic.
If the document contains any b
,
basefont
, bdo
, big
,
center
, del
, dir
,
font
, i
, ins
,
menu
, s
, small
,
strike
, sub
, sup
,
tt
, or u
elements, FAIL
If there is no CSS Style, PASS
If the document contains a CSS
style
element but no externally linked CSS Style,
WARN
If the CSS Style contains a single @media
rule that specifies the media type screen
,
WARN
If the CSS Style contains at-rules other
than the @media
at-rule, properties or values that are
not recognized as being valid CSS Level 1, WARN
PASS
If a table
element exists,
WARN
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.
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 an image whose real dimensions are 2x2 or less, FAIL
PASS
If a table
element exists,
If a table
element exists
somewhere inside it, FAIL
PASS
If it is an HTML document and it fails to
validate according to its given DOCTYPE
,
FAIL
PASS
The editors would like to thank members of the BPWG for contributions of various kinds.
The editors acknowledge significant written contributions from:
This appendix lists all Best Practices and indicates whether each has a corresponding test in mobileOK Basic, mobileOK, both, or neither. The tests listed for mobileOK are subject to change as that document is still a work in progress.