Text thus highlighted is identical to that used in the Basic tests document (except for changing 'mobileOK Basic' to 'mobileOK Pro' as necessary).
Text thus highlighted is the original text in the mobileOK Basic document, included here for comparison. It is to be elided from this document.
Text that is thus highlighted is an editor's note
Text that is not highlighted is either original to this document or so changed from the equivalent in mobileOK Basic as to effectively be original content.
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 Pro™ conformance and are based on W3C Mobile Web Best Practices [BestPractices]. Content which passes the tests has taken significant 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).
Suggestion:The DDC is a hypothetical default device, intended as a last-resort fallback, should it prove impossible to determine the requesting device. As such all content should, as a minimum, display well on the DDC. There is no limitation and, in fact there is encouragment, to optimize content for the real capabilities of the requesting device, exceeding those of the DDC.
mobileOK Pro is the greater of two levels of claim, the lesser level being mobileOK Basic, described separately [BASIC]. 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 an Editors' Working Draft of mobileOK Pro Tests 1.0. It is useful as a basis for discussion within the the Mobile Web Initiative Best Practices Working Group but is not suitable for publication. It has, however, been written and formatted in such a way that transition to public working draft will be easy. The WG expects to advance this document to Recommendation status.
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.
mobileOK Pro 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 Pro tests for delivered content, and describes how to emulate the DDC when requesting that content.
mobileOK Pro is the greater of two levels of claim, the lesser level being mobileOK Basic, described separately [BASIC]. Conformance with mobileOK Pro implies conformance with mobileOK Basic. Claims to be W3C mobileOK conformant are represented using Description Resources (see [POWDER]), also described separately.
The intention of mobileOK is to foster the development of Web sites that provide a functional user experience in a mobile context as well as in a desktop context. It is understood that there is a wide variety of content that will always be specialized for desktop access or mobile access. However, there is also a lot of content between these extremes that can made more mobile friendly. mobileOK Pro aims to adhere to as many Best Practices as possible to achieve this goal.
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.
mobileOK Basic tests are described separately [BASIC].
The 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.
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. See Section 4.
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 of the mobileOK Basic Tests document [BASIC], resolving a URI will result in mobileOK Pro conformant content that is delivered in a mobileOK Pro conformant manner. That is, the tests do not apply solely to content or document instances. This is particularly relevant to best practices such as CACHING which is covered by mobileOK Basic.
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 Pro 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.
The mobileOK Pro tests set out in section 3 MUST be carried out within exactly the same environment as those for mobileOK Basic. This is defined fully in section 2 of the mobileOK Basic Tests document [BASIC] and covers aspects such as:
Although the testing environment is identical, and conformance with mobileOK Pro implies conformance with mobileOK Basic, the mobileOK Pro tests are NOT a superset of mobileOK Basic tests. Machine-testing, as used by mobileOK Basic, can only yield a partial result for, for example, AUTO REFRESH and NON-TEXT ALTERNATIVES. This document defines tests that expand upon some of the machine tests of mobileOK Basic which should be carried out in addition to the mobileOK Basic tests before claiming conformance with mobileOK Pro. Appendic C shows how each best practice is, or is not, tested at the two levels of mobileOK.
This section describes tests for mobileOK Pro. Tests are organized alphabetically by the Best Practice from which they derive.
Problem description
Here we should describe in a few words what we are trying to solve
Parameters
A list of parameters and their values that serve to describe, bracket or even
pin point the problem
These values can be numeric, if possible, or some other parameter that is
inherent to the problem
Examples and known exceptions
Here we should show real life examples of the problems, either in word or
image
Any known exceptions that may invalidate a proposed solution should be listed
for evaluation
Solution
Here the desired results of an evaluation should be listed that would lead to
solving the problem at hand
Result
Pass/Warn/Fail
Problem description
Navigating a page with a mobile device, when there is no pointing device, can
be quite cumbersome. A mechanism must be provide to ease and speed up
navigation.
Solution
Where there is no pointing device, assigning an access key (keyboard short
cut) to a link can provide a convenient way for users to access the link and
avoid navigating to the link by repeated pressing of the navigation key.
Provide the same access key for links that are repeated across pages such as
links to the home page.
Parameters
The correct handling of access keys should be evaluated with the following
aspects in mind:
Examples and known exceptions
The navigational elements of a given mobile web page may include:
Test questions
Are access keys provided for pages linked through the navigational bar or
other primary navigation as listed above?
Were links decorated with the access key?
Was care taken to provide these elements with access keys in the proscribed
fashion?
Are keys sequenced appropiately for the content at hand?
Result
If one question is answered with "NO", FAIL
Then, if one question is answered with "MAYBE", WARN
Then, if all questions are answered with "YES", PASS
This test supersedes that provided in mobileOK Basic Tests.
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
If the URI specified in the content
attribute is the current resource's URI but the user is not given the option
to disable page refresh, FAIL
PASS
Problem description
When a page refreshes automatically it is dependent on the user whether this
refresh is desired or not. As such there must be a means to allow a user to
escape from such an auto-refreshing page.
Solution
There must be a navigable option on the page that leads to a non-refreshing
page.
Parameters
The correct handling of an auto-refreshing page should be evaluated with the
following aspects in mind:
Examples and known exceptions
Test questions
meta element present
with http-equiv attribute value of refresh?
content attribute the same as the current resource's
URI?Result
If the user may not escape an auto-refreshing page, FAIL
If the user may escape an auto-refreshing page,
PASS
For each textarea element and
input element with attribute whose type is "text"
or "password":
If no default text is displayed and the value can reasonably be pre-determined , WARN
PASS
For devices that support background images:
If a background image is present and content cannot be read by someone with normal vision in daylight conditions, FAIL
If a background image is present and perceiving content in the foreground is found to be be difficult under normal daylight conditions, FAIL
For devices that do not support background images:
If content does not display or is not readable by someone with normal vision in daylight conditions, FAIL
If perceiving content is found to be be difficult under normal daylight conditions, FAIL
PASS
This is something that is very subjective and thus hard to
quantify.
However, some thoughts on the subject exist:
rggblog
which stems from here..
Google
Web Guidelines
but 100 links seems excessive to me, because every link is a button push on a
mobile.
The point is, I think we need to quantify this.
If the page contains more than 20 links, WARN
If the page contains more than 30 links, FAIL
PASS
If identical content is delivered to basic and advanced devices, and if that content is not predominantly plain text, WARN
If identical content is delivered to basic and advanced devices, and if that content is not predominantly plain text, WARN
If content is delivered to advanced devices in a modified fashion, that could, but does not utilize one or more cababilities of that device, FAIL
PASS
If the main page content is not visible without scrolling past navigation bars, logos, advertising, search boxes and the like, FAIL
If it is not possible, without scrolling, to determine what the main focus of a web page is, FAIL
PASS
What is clear to one person may not be clear to another, so this is, of necessity, a subjective test. However, an example should convey its intention.
Don't say: The area now called Bannelong Point was variously known by aboriginal peoples as Tu-bow-gule or Jubgalee. It is now known as the site of one of the world's most famous buildings. Designed by Norwegian Jørn Utzon in 1957, the Syndey Opera House is the venue for tonight's perfomance of La Traviata which begins at its traditional hour.
Do say: La Traviata will be peformed tonight at 8pm at the Sydney Opera House.
If the content is informational in nature:
If the writing style is such that it requires close reading to glean relatively simple information, FAIL.
PASS
The following is based on this test:
WCAG
Technique
There is also an online tool
Luminosity
Contrast Ratio Analyser
If contrast ratio is less than 5:1, FAIL.
PASS
See content format support below
If there are no types listed in the accept header and the content does not conform to DDC minimum standards, FAIL.
If the delivered content type does not match the types listed in the accept headers, FAIL.
PASS
This is machine testable
For each label element:
If the for attribute is not defined and
the content of the label element is not a form control, FAIL
If the for attribute is present but does
not correspond to the id attribute of a form control,
FAIL
PASS
For each label element:
If labels are not provided to the left of or above input fields and combo boxes FAIL
If labels are not provided to the right of radio buttons and check boxes, FAIL
PASS
If the usability without cookies is bad, WARN
If the intention of the web page in question cannot be fulfilled without utilization of cookies, FAIL
PASS
If the page in question does not render on a device with known deficiencies in such a manner as to compensate for the deficiencies, WARN
PASS
This test is unique in that the default outcome is FAIL. It lists 4 techniques that can be used, either singly or in combination, to provide a mobileOK conformant content.
For each error message:
If 'back' link to return user to previous page is present, PASS
If 'retry' link to refresh the page is present, PASS
If 'home' link to return the user to the sites homepage is present, PASS
If error message uses error codes and textual explanation of them is given, PASS
FAIL
For each error message:
This test seems unnecessarily restrictive and complicated
If the error message does not explain in simple language which error occurred, WARN
If the error message does not provide a link to another URL than the originally requested URL, FAIL
PASS
If a device like DDC receives styled fonts upon its request, FAIL
If utilization of the content is dependent on being able to see font styling, FAIL
PASS
If parts of the content are positioned using graphical elements, FAIL
PASS
This test is very similar, if not equal to, CENTRAL MEANING
For each hyperlink (a elements with an
href attribute):
If the text, image or object within the hyperlink element does not describe the content it links to , FAIL
If the text, image or object within the hyperlink element is a non-descriptive phase such as 'click here' or 'more', FAIL
PASS
I disagree with the second test here. It is actually much better to use "more" or some other type of short link text, because it saves page weight and does not clutter prose text with silly link texts. Further, the descriptive part could come before the link, as in "if you would like to read more about the love life of the electron, click here."
This test would be covered by tests for AVOID FREE TEXT and PROVIDE_DEFAULTS
If links to key pages are absent from the top of the page, FAIL.
If navigation links at the top of the page cover more than one line, FAIL.
PASS
If the navigation mechanism changes unnecessarily and accross the web site, WARN.
PASS
The mobileOK
Basic test for this best practice checks for the presence of
alt attributes. The mobileOK Pro test ensures that the text is
relevant.
For each image:
If the alt text is irrelevant to the
content of the image, FAIL.
PASS
If the user experience with the presence of object or script elements is not acceptable, FAIL.
If the content cannot be consumed in the intended fashion without objects or scripts being rendered, FAIL.
PASS
This test is particularly difficult as it actually requires an advanced delivery context. As such a presumption is made that the ADC exists, without knowing any of the parameters govering the ADC.
If each page displayed exceeds 3 screen sizes in length, WARN.
If the total page size exceeds 100K, FAIL.
If there is no apparent justification for exceeding 3 screen sizes in length, FAIL.
PASS
The mobileOK
Basic test for this best practice checks for the presence of a page
title. The mobileOK Pro test ensures that the text is
relevant.
If title is irrelevant to the page
content, FAIL.
If title is too long to display on a
screen matching the Default
Delivery Context, WARN.
PASS
For each warning produced by the corresponding mobileOK Basic test:
If the radio or select
control could default to a likely value for most users (but this has not been
done), FAIL
PASS
If scrolling direction changes without sufficient reason, FAIL
PASS
Assuming the document is valid, if headings are not used in sequence throughout the document to separate sections, FAIL
PASS
There seems to be no guideline on this. Thus we should create one. In general one could argue the more pages are contained within a web site, the more special cases there may be for formatting => style sheet size would increase. On the other hand, stylistic requirements are impossible to quantify and yet there needs to be an upper limit to page size.
If style sheet size exceeds 10% of the average web page on the site in question, WARN
PASS
If content is unreadable or uniteligable with stylesheets diabled, FAIL.
PASS
There is content which is exclusively made for large
monitors. Other content is exclusively made for mobile devices. The grey zone
in between is what needs to be examined here.
The following are examples of what this may mean and the breadth of this
range:
- a page showing Renaissance paintings in full size - FAIL
- a page showing a listing of Renaissance Paintings with thumb nails -
pass
- a page offering downloads of Windows XP - FAIL
- a full size x-ray image for in-field access by EMTs - PASS
If content is falsley rendered on a mobile device, FAIL.
PASS
If the tab order of links, form controls and objects is disorganized, illogical or confusing, FAIL.
PASS
This is problematic for several reasons.
For one thing, you cannot duplicate table layout with CSS, especially when it
is supposed to be adaptive to the amount of content listed within.
Further, the last FAIL criterium fails on a 2x2 pixel graphic with is in
conflict with 3.7, which allows them.
If the device does not support tables and the table element is found within the source code, FAIL.
PASS
This could be solved by storing information about which browsers have been used for testing in a POWDER description resource.
When entering a URI manually, if it is necessary to enter a www subdomain, FAIL.
If it is necessary to include default file names in the path of a URI, (such as index.html or index.asp), FAIL.
If it is necessary to enter other filenames, such as example.html, WARN.
PASS
NB. Many devices will enter the http scheme by
default, obviating the need to enter this by hand, however, this is out of
the control of the content provider and is therefore not part of mobileOK.
If some meaning of the content is conveyed with color and and cannot be conveyed without color, FAIL.
PASS
It is not possible to create a deterministic or repeatable test to assess whether or not a small number of best practices have been adhered to. For this reason, the following best practices are not formally included in mobileOK. However, content providers and third parties may express the opinion that each or all of them have been adhered to within the context of a claim of mobileOK conformance.
The following exceptions would have to be modified, depending on what is decided upon regarding those test which have been listed above.
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 a claim of conformance with mobileOK Pro is also a claim of conformance with mobieOK Basic and so any best practice with a corresponding test in mobileOK Basic implicitly has a corresponding test in mobileOK Pro. Where a best practice is shown to have a test in both mobileOK Pro and mobileOK Basic, the mobileOK test expands upon the one defined for mobileOK Basic. The best practices that are not part of either level of mobileOK are discussed in Section 4.
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.