Copyright © 2006 © 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 to be of W3C® mobileOK Basic™ compliant conformance and are based upon on W3C Mobile Web Best Practices [BestPractices] . Content which passes the tests has taken a number of 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 higher greater level being mobileOK, described separately. Claims to be W3C mobileOK Basic compliant 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 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 the second public a Last Call Working Draft of mobileOK Basic Tests 1.0; it incorporates various refinements of the tests presented in the first draft, as well as new tests coming from Best Practices that were not included in the previous two drafts; see the changes-marked version which highlights all the changes since the previous publication of this document. The document includes a set of editors notes on which feedback would be appreciated. appreciated, in particular on the UTF-8 requirement . The Working Group would also like feedback from Web content developers on the perceived difficulty of getting the mobileOK Basic status as described in this document.
The Last Call review period for this documents extends until 6 March 2007. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list .
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 .
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
1.4
Who
is
mobileOK
for?
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
CSS
Style
2.3.5
Included
Resources
2.3.6
External
Included
Stylesheet
Resources
via
link
elements
2.3.5
CSS
Style
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.10
LARGE_GRAPHICS
3.11
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)
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.
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.
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.
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.
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.
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.
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 DevelopersDevelopers 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.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 apply are only meaningful when the URI under test resolves to HTML content delivered over HTTP.
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.
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
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
Include
an
Accept-Charset
header
indicating
that
only
UTF-8
is
accepted:
accepted
by
sending
exactly
this
header:
Accept-Charset: UTF-8
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.
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".
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"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"
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
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.
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"
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
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
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
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"/>)
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
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
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
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
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
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
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, 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
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
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
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
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
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
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 StyleThis 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
,
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
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 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:
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
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
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
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
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
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 best practices and indicates whether each has a corresponding test in mobileOK Basic, mobileOK, both, or neither. Note that mobileOK is a superset of mobileOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK. 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 are subject to change as that document is still a work in progress.