Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines the tests that provide the basis for making a claim of W3C® mobileOK Basic™ conformance and are based on W3C Mobile Web Best Practices [BestPractices]. Content which passes the tests has taken some steps to provide a functional user experience for users of basic mobile devices whose capabilities at least match those of the Default Delivery Context (DDC).
mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK Pro, described separately. Claims to be W3C mobileOK conformant are represented using Description Resources (see [POWDER]), also described separately.
mobileOK assesses interoperability. It does not measure usability and does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Last Call Working Draft of mobileOK Basic Tests 1.0. The W3C Membership and other interested parties are invited to review the document and send comments to public-bpwg-comments@w3.org, (with public archive) through 22 June 2007.
This document was developed by the Mobile Web Initiative Best Practices Working Group. The Working Group expects to advance this Working Draft to Recommendation Status. A complete list of changes to this document is available
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Levels of
mobileOK
1.1.1 mobileOK Basic
1.1.2 mobileOK Pro
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 Meta http-equiv Elements
2.3.5 CSS Style
2.3.6 Included Resources
2.3.7 Included Style Sheet
Resources
2.3.8 Visible Linked Resources
2.3.9 Validity
2.3.10 White Space
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 and
VALID_MARKUP
3.5 DEFAULT_INPUT_MODE
3.6 EXTERNAL_RESOURCES
3.7 GRAPHICS_FOR_SPACING
3.8 IMAGE_MAPS
3.9 IMAGES_RESIZING and
IMAGES_SPECIFY_SIZE
3.10 LINK_TARGET_FORMAT
3.11 MEASURES
3.12 MINIMIZE
3.13 NO_FRAMES
3.14 NON-TEXT_ALTERNATIVES
(partial)
3.15 OBJECTS_OR_SCRIPT (partial)
3.16 PAGE_SIZE_LIMIT
3.17 PAGE_TITLE (partial)
3.18 POP_UPS
3.19 PROVIDE_DEFAULTS (partial)
3.20 STYLE_SHEETS_SUPPORT
(partial)
3.21 STYLE_SHEETS_USE
3.22 TABLES_ALTERNATIVES
3.23 TABLES_LAYOUT (partial)
3.24 TABLES_NESTED
A Acknowledgements(Non-Normative)
B References(Non-Normative)
C Relationship between Best
Practices and mobileOK Tests(Non-Normative)
mobileOK Basic is a scheme for assessing whether Web resources (Web content) can be delivered in a manner that is conformant with Mobile Web Best Practices [BestPractices] to a simple and largely hypothetical mobile user agent, the Default Delivery Context.
This document describes W3C mobileOK Basic tests for delivered content, and describes how to emulate the DDC when requesting that content.
mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK Pro, described separately. Claims to be W3C mobileOK Basic conformant are represented using Description Resources (see [POWDER]) also described separately.
The intention of mobileOK is to help catalyze development of Web content that provides a functional user experience in a mobile context. It is not a test for browsers, user agents or mobile devices, and is not intended to imply anything about the way these should behave.
mobileOK does not imply endorsement or suitability of content. For example, it must not be assumed that a claim that a resource is mobileOK conformant implies that it is of higher informational value, is more reliable, more trustworthy or is more appropriate for children than any other resource.
mobileOK Basic tests are based on a limited subset of the Mobile Web Best Practices. Their outcome is machine-verifiable, hence claims of mobileOK Basic conformance are easy to check.
Content passing the tests demonstrates that the content provider has taken basic steps to provide a functional experience for mobile users.
mobileOK Basic conformance should be considered only a first step towards building a harmonized experience for mobile users. Conformance merely demonstrates that a basic experience is available, interoperable with a large number of mobile devices. mobileOK Basic conformance says nothing about richer, more sophisticated, experiences that may be available, nor does it say anything about whether other guidelines for development of Web content (such as [WCAG]) have been followed.
The (full) mobileOK Pro tests include the mobileOK Basic tests and are based on a larger subset of the Mobile Web Best Practices. These tests are not all machine-verifiable.
Content passing the tests demonstrates that the content provider has taken significant steps to provide a functional experience for mobile users.
However, mobileOK Pro conformance still does not suggest that the most sophisticated mobile user experience possible is available. It implies that a functional experience is available which adheres even more closely to the Mobile Web Best Practices.
Like mobileOK Basic, mobileOK Pro conformance says nothing about whether other guidelines for development of Web content (such as [WCAG]) have been followed.
mobileOK Pro tests will be described separately.
Note that some best practices, like TESTING, are advisable but do not meaningfully translate into concrete tests, whether their outcome is machine- or human-verifiable.
The tests do not assess usability, rather, they assess whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices.
The best practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.
Content providers should provide an experience that is mobileOK conformant to ensure a basic level of interoperability. Providers are encouraged to provide enhanced experiences as well when these are appropriate to their application and devices that are accessing them.
The tests apply to a URI. Passing the tests means that when accessed as described in 2.3.2 HTTP Request, resolving a URI will result in mobileOK Basic conformant content that is delivered in a mobileOK Basic conformant manner.
That is, the tests do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. VALID_MARKUP), but to how it is delivered to a mobile device (e.g. CACHING).
mobileOK Basic says nothing about what may be delivered to non-mobile devices.
A standard mechanism will be defined that allows content providers to claim that a URI or group of URIs, such as a Web site, conforms to mobileOK Basic or mobileOK Pro. It will be possible to make claims in a machine-processable form. It will also be possible to notify end users of the presence of the claim by means of a human-readable mark.
The details of the mechanism for claiming mobileOK conformance will be described separately.
This section details the tests that must be carried out in order to claim mobileOK Basic. Tests are presented as simple pseudo-code.
mobileOK tests are only meaningful when the URI under test resolves to HTML content delivered over HTTP.
Individual tests may result in PASS or FAIL. PASS is required from all tests in order to claim mobileOK Basic.
Tests may also generate a number of informative warnings.
mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently. Some tests have been designed to assess aspects of the content that are disallowed by other tests; this is deliberate and is intended to allow testing environments to provide as much information as possible.
For example the test for 3.21 STYLE_SHEETS_USE
points out that style sheets should be used in preference
to markup elements such as center, even
though the center element is also disallowed
by the test for 3.4
CONTENT_FORMAT_SUPPORT and VALID_MARKUP.
Creators of implementations of the tests described in this document are encouraged to provide as much information as possible to users of their implementations. Where possible they should not stop on FAIL and specifically they should:
Provide information about the cause of failure
Continue individual tests as far as is possible
Carry out as many tests as is reasonable
The following HTTP request headers inform the server that it should deliver content that is compatible with the Default Delivery Context.
Use the HTTP GET method when making
requests.
Include a User-Agent header
indicating the default delivery context by sending
exactly this header:
User-Agent: W3C-mobileOK/DDC-1.0 (see http://www.w3.org/2006/07/mobileok-ddc)
Include an Accept header indicating
that Internet media types understood by the default
delivery context are accepted by sending exactly this
header:
Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
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.3.3 HTTP Response). Once authentication information has been included in a request, subsequent requests for the same realm must include authentication information as described in Section 2 and under "domain" in Section 3.2.1 of [RFC2617].
Implementations must support URIs
with both http and https
scheme components.
Note: To allow for self-signature of certificates during testing the signatory of a certificate should not be checked.
Note: Implementations must support basic and digest authentication.
If an HTTP request does not result in a valid HTTP response (because of network-level error, DNS resolution error, or non-HTTP response), FAIL
If the response is an HTTPS response:
If the certificate is invalid, FAIL
If the certificate has expired, warn
If the HTTP 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.3.6 Included Resources):
Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
Re-request the resource as indicated in the response.
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.3.6 Included Resources):
If authentication information was supplied in the HTTP request (i.e. authentication failed), FAIL
Carry out tests on the response
Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT
Include this response under the count described under 3.6 EXTERNAL_RESOURCES
Re-request the resource using authentication information
If the response relates to a request for a linked resource (see 2.3.8 Visible Linked Resources):
Continue with the test (see 3.10 LINK_TARGET_FORMAT, i.e. do not re-request the resource with authentication information).
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 linked resource (see 2.3.8 Visible Linked Resources), continue with the test (see 3.10 LINK_TARGET_FORMAT) and warn
Otherwise (i.e. for included resources), FAIL
If the HTTP status represents failure (4xx), other than 404 or a request for authentication (e.g. 401), FAIL
Documents can include meta elements with
an http-equiv attribute; these are sometimes
considered substitutes for HTTP response headers.
Values specified in such elements must be ignored, aside from the following:
The Refresh header as specified in
3.1 AUTO_REFRESH
(partial) and REDIRECTION
The Content-Type header as specified
in 3.3
CHARACTER_ENCODING_SUPPORT and
CHARACTER_ENCODING_USE
The Cache-Control header as specified
in 3.2 CACHING
Check for consistency with HTTP 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
Some tests refer to "CSS Style" information. Assemble the CSS Style by using the contents of:
the style attribute of any element
(note that use of the style attribute is
deprecated in XHTML Basic 1.1)
style elements whose
type attribute is "text/css", and whose
media attribute is either not present or
is present and contains values "all" or
"handheld".
resources linked by xml-stylesheet
processing instructions
external style sheet resources linked via
link elements, as defined in 2.3.7 Included
Style Sheet Resources
resources linked by CSS @import
at-rules
In the course of assembling the CSS Style:
observe the CSS Level 1 cascade
retrieve only those resources that have no CSS media type, or whose CSS media type specifier contains "handheld" or "all"
use only those rules that are not restricted as to their CSS media type or whose CSS media type specifier contains "handheld" or "all"
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 whose URI has the "http" or "https" scheme. Examples include image and style sheet resources.
When calculating page sizes, caching directives should be observed. Multiple references to cached resources are counted only once in regard of page weight (see 3.16 PAGE_SIZE_LIMIT) and resource count (see 3.6 EXTERNAL_RESOURCES).
Included resources are defined as those that are referenced by:
img elements
object elements
In some circumstances object elements
may act as synonyms for other elements such as
img and iframe. In these
cases it is noted in the relevant section when to
regard object elements as equivalents for other
elements.
link elements and
xml-stylesheet processing instructions
as defined in 2.3.7 Included
Style Sheet Resources
images included by background-image
and list-style-image properties in the
CSS Style (2.3.5 CSS
Style)
@import directives in the CSS Style —
providing they are in scope for the media type
"handheld" or "all" (2.3.5 CSS
Style)
When calculating the page size (3.16 PAGE_SIZE_LIMIT) only those style sheets retrieved according to the rule specified here are taken into account.
Included style sheet resources are, simply, included
resources that are style sheets. They are defined as
resources referenced in the href attribute
of link elements and
xml-stylesheet processing instructions (in
which case attribute in this section refers to
pseudo-attribute) whose rel
attribute contains "stylesheet" but not "alternate",
charset attribute is either not present or
is present with value "UTF-8", type
attribute is either not present or is present with value
"text/css", and whose media attribute is
either not present or is present and contains value "all"
or "handheld".
Linked resources are resources linked to from the resource being tested, but which are not vital to rendering that resource whose URI has the "http" or "https" scheme. Examples include resources linked via hyperlinks.
Linked resources are defined as those that are referenced by:
the href attribute of a
(anchor) elements, and whose URI begins with the
"http" or "https" scheme.
the action attribute of
form elements whose method
attribute is not present or is present with value
"get". Note that forms with method get
are permissible in documents under test, but must not
be checked in case posting caused unwanted side
effects such as the addition of unwanted records to a
database.
Several tests refer to the validity of aspects of a resource. This section defines specifically what this means.
A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS], Appendix B
An image is a valid GIF image if it conforms to the grammar defined in section 25 of the [GIF] specification
An image is a valid JPEG image if it follows the format defined in Annex B of the [JPEG] specification
A resource is considered to be valid UTF-8 if its bytes represent the valid UTF-8 encoding of some string, as defined in [UTF-8], section 4
Note: [utf8_perl] contains a regular expression that may be used for testing UTF-8 validity.
Several tests refer to white space. White space has the same definition in this document as in XML. For XML 1.0 [XML10] it is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:
S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the
characters SP, TAB, CR and LF.
For XML 1.1 [XML11] it is defined in section 1.3 as consisting of the same characters with the addition of NEL (#x85) and the Unicode line separator character, (#x2028).
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.
This test does not determine whether the user is able to opt out of refresh.
If a meta element is
present with http-equiv attribute value of
"refresh",
If the URI specified in the
content attribute is not the current
resource's URI, FAIL
Else, warn
If a Refresh HTTP
header is present,
If the URI specified in the header value is not the current resource's URI, FAIL
Else, warn
PASS
In the following, note that HTTP headers should be used
rather than meta elements with
http-equiv attributes, which are commonly not
taken into account by proxies. Where both a
meta element and the corresponding header are
found the value of the header must be
used.
If the HTTP response contains
neither an Expires nor
Cache-Control header
If no meta http-equiv
element is present, referring to those headers,
FAIL
warn, and continue the test using
the value from the meta content
attribute.
If a Cache-Control
HTTP header is present and contains value "no-cache", or
contains value "max-age=0", warn
If a Pragma HTTP
header is present and contains value "no-cache",
warn
If an Expires and
Date HTTP header are present, and the
Expires header specifies a date which is not
later than what the Date header specifies,
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-Modified
response header
If the HTTP response contains a
Last-Modified header and its value is again
the same, and the HTTP response status is not 304 (Not
Modified), warn
If the HTTP response contains an
ETag header,
Request the same URI again, adding
an If-None-Match request header whose value
matches that of the ETag response header
If the HTTP response contains an
ETag header and its value is again the same,
and the HTTP response status is not 304 (Not Modified),
warn
PASS
The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource cannot be encoded in UTF-8. The test does not require that resource always be encoded in UTF-8; the test merely checks that the resource is available in UTF-8 encoding, if requested. Resources may be represented using other encodings where appropriate. This test verifies that a DDC-like device which only accepts UTF-8 encoding may access the resource in UTF-8 encoding.
This 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
<?xml version="1.0" encoding="UTF-8" ?>
meta element that is the first child of
the document's head element, and whose
http-equiv attribute is "Content-Type",
and whose content attribute specifies a
character encoding
... <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8"/> ...
If the HTTP
Content-Type header specifies a character
encoding other than UTF-8, FAIL
If the HTTP
Content-Type header does not specify a
character encoding:
If there is no XML declaration, or UTF-8 character encoding is not 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.3.9 Validity), FAIL
For each resource specified by 2.3.6 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
PASS
If the document's Internet media
type, as specified in the HTTP response
Content-Type header, is not
"application/xhtml+xml", "application/vnd.wap.xhtml+xml",
or "text/html", FAIL
If the document's Internet media type is "text/html" or "application/vnd.wap.xhtml+xml", warn
If the document does not contain a
DOCTYPE declaration, FAIL
If the document is an HTML
document and it fails to validate according to its given
DOCTYPE, FAIL
If (regardless of its stated DOCTYPE) the document does not validate against the XHTML Basic 1.1 DTD:
If it does not validate against the XHTML-MP 1.2 DTD, FAIL
For each included resource (see 2.3.6 Included Resources):
If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL
If the Internet media type is "image/gif" or "image/jpeg", and the resource is not valid (see 2.3.9 Validity), FAIL
If the Internet media type is "text/css" and the content is not valid CSS (see 2.3.9 Validity), FAIL
PASS
Note that inputmode is part of [XHTMLBasic11].
For each input
element with attribute type whose value is
"text" or "password"
If the element's
inputmode attribute is invalid according to
Section 5.2 User Agent Behavior of XHTML Basic 1.1
[XHTMLBasic11],
FAIL
If the element's
value attribute is missing or empty, and an
inputmode attribute is not present,
warn
For each textarea
element:
If the element's
inputmode attribute is invalid according to
Section 5.2 User Agent Behavior of XHTML Basic 1.1
[XHTMLBasic11],
FAIL
If the element is empty and an
inputmode attribute is not present,
warn
PASS
Note that if an HTTP request is unsuccessful while conducting this test, the result is FAIL
Count the total number of unique
included resources, as defined in 2.3.6 Included Resources
For nested object elements, count only
the number of objects that need to be assessed before
content matching the request header defined in 2.3.2 HTTP Request is
found.
For each such resource:
Request the resource, and add one to a running count
Add to the count the number of HTTP redirects (HTTP 3xx status responses) that must be followed and authentication requests that must be made until the resource itself is successfully retrieved
If this total exceeds 10, warn
If this total exceeds 20, FAIL
PASS
The intent of this Best Practice is to avoid using transparent images for spacing. However, small transparent images are often used in e-commerce sites for user tracking purposes. The practice is common enough, and possibly vital enough to the business interests of mobile sites, that it is undesirable to fail sites that use such small transparent images. Therefore this machine-testable test merely warns about the presence of small (at most 2x2) transparent images and FAILs larger ones. It is believed that few if any sites would use transparent images of any significant size for tracking.
For each img element
and object element whose
type attribute starts with
"image/":
If all pixels are transparent,
If image height and width are both less than or equal to 2 pixels, warn
If either dimension exceeds 2 pixels, FAIL
If more than one image with all transparent pixels was encountered, warn
PASS
If an input element
with type attribute set to "image" is
present, FAIL
For each img element
and object element:
If a usemap attribute
is present, FAIL
If an ismap attribute
is present, FAIL
PASS
Note that the height and width
HTML attributes specify pixels when they are used as a
number. No unit is specified.
For each img element
and object element whose
type attribute starts with
"image/":
If the height or
width attribute are missing, FAIL
If the height or
width attribute do not specify a size in
pixels, FAIL
If either the height or width specified are greater than the corresponding dimension of the image, warn
If either the height or width specified are less than the corresponding dimension of the image, FAIL
PASS
Note that 404 and 5xx HTTP status do not result in failure when conducting this test. In such cases it is the headers attached to the body of the error response which are tested.
For each linked resource, as defined in 2.3.8 Visible 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.3.2 HTTP
Request, warn
If the Content-Type
header value of the HTTP response is not consistent
(determined in the same way as specified in 3.3
CHARACTER_ENCODING_SUPPORT and
CHARACTER_ENCODING_USE) with the
Accept-Charset header in 2.3.2 HTTP Request,
warn
PASS
For each property in the CSS Style (2.3.5 CSS Style) whose value is a numeric measure of length stated together with a unit:
If the value is non-zero and the unit is not "em" or "ex", and the property is not a margin, border or padding box property, FAIL
PASS
Count number of white space
characters in a sequence of more than one white space
character (not counting the first), which exist outside
of a pre, style,
script element, or XML comment
Add to this count the number of characters comprising XML comments. This total is the number of extraneous characters in the document.
Count total number of characters in document
If the number of extraneous characters exceeds 10% of the count of characters in the document, warn
If the number of extraneous characters exceeds 25% of the count of characters in the document, FAIL
PASS
If the document contains a
frame , frameset or
iframe element or object
element whose type attribute starts with
"text/", "application/xhtml+xml" or
"application/vnd.wap.xhtml+xml", FAIL
PASS
This test does not determine whether the alternative text is meaningful.
For each img
element:
If an alt attribute
is not present or consists only of white
space, FAIL
PASS
This test does not determine whether the document is still usable without the objects or scripts.
If a script element
is present, warn
If any element has an "intrinsic
event" attribute (currently onload,
onunload, onclick,
ondblclick, onmousedown,
onmouseup, onmouseover,
onmousemove, onmouseout,
onfocus, onblur,
onkeypress, onkeydown,
onkeyup, onsubmit,
onreset, onselect,
onchange), warn
For each a and
link element:
If the value of the
href attribute begins with the "javascript:"
scheme, FAIL
If an applet element
is present, FAIL
If an object element
is present and has no object element
ancestor,
If the innermost nested
object element is empty,
warn
If the innermost nested
object element content consists only
of white space, FAIL
If none of the nested
object elements refers to content that
matches the headers defined in 2.3.2 HTTP Request and the
innermost nested object element is non-empty
and does not consist of text or an img
element that refers to an image that matches the headers
defined in 2.3.2 HTTP
Request, FAIL
PASS
If the size of the document's markup exceeds 10 kilobytes, FAIL
For each included resource, as defined in 2.3.6 Included Resources:
Request the referenced resource
Add the size of the response body
to a running total (for nested object
elements count only the first object that matches the
headers specified in 2.3.2
HTTP Request, if there is one)
If the total exceeds 20 kilobytes, FAIL
PASS
This test does not determine whether the title is meaningful.
If a title element is
not present in the head element, or is
empty, or contains only white space, FAIL
PASS
For each a,
link, form, and
base element:
If a target attribute
is present,
If its value is not one of "_self", "_parent", or "_top", FAIL
PASS
In addition, a human-verifiable test is needed here to verify whether such elements could be replaced with alternative control elements.
For each 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 some value, 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
PASS
In addition, a human test is needed here to verify whether the page is readable without a style sheet.
If the CSS Style (2.3.5 CSS
Style) contains rules referencing the
position, display or
float properties, warn
PASS
This test does not require that any CSS styles be used, since in some cases, no presentation information is required at all (for example, a simple page of text).
This test looks for elements in the Text Extension module defined by [XHTMLModularization], some of which are not supported in XHTML Basic. It also looks for commonly-used elements and attributes that were deprecated in HTML 4, and are not supported, or are deprecated, in XHTML Basic.
Note that external style sheets and style
elements that have no media attribute are assumed to refer
to "all".
If the document contains any
basefont, bdo,
center, del, dir,
font, ins, menu,
s, strike or u
elements, FAIL
If the document contains any
b, big, i,
small, sub, sup or
tt elements, warn
If any element has a
style attribute, warn
If there is no CSS Style (2.3.5 CSS Style), PASS
If all styles are restricted to 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), properties,
or values that are not recognized as being valid CSS
Level 1 2.3.9 Validity,
warn
PASS
If a table element
exists, warn
This test does not catch all cases where tables are used for layout purposes.
If a table element
exists,
If it contains at most one
tr element, FAIL
If no tr element
contains more than one td element,
FAIL
For each nested td
element:
If the element contains only an image (or equivalent object) whose actual dimensions are 2x2 or less, FAIL
PASS
If a table element
exists,
If a table element
exists somewhere inside it, 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 Pro, both, or neither. Note that mobileOK Pro is a super-set of mobileOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK Pro. This table, however, indicates which best practices have a corresponding test that expands on the test, if any, in mobileOK Basic. The tests listed for mobileOK Pro are subject to change as that document is still a work in progress.