W3C home > Mailing lists > Public > public-bpwg@w3.org > October 2008

Re: ACTION-847: Change the Addendum according to the resolution about toning down the test character of the document

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 10 Oct 2008 21:16:26 +0100
Message-ID: <48EFB81A.1010001@mtld.mobi>
To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
CC: public-bpwg@w3.org

Hi Kai

Thanks for the sample re-writes.

I think we have a little way to go to clarify the relationship between 
this document and other documents.

I think that this is an Addendum to "Mobile Web Best Practices" and has 
little to do with "mobileOK Basic Tests". [Please can you adjust the 
title to reflect this]

In my view it is supposed to supplement the "what to test" section of 
the Best Practices, e.g. http://www.w3.org/TR/mobile-bp/#d0e981 rather 
than http://www.w3.org/TR/mobileOK-basic10-tests/#AUTO_REFRESH

Afaics there is no relationship at all with the checker so any reference 
to that needs to be removed.

I very much appreciate your continued efforts on this, but it does seem 
that we need to work a bit more on what the point is of this document.

Thanks
Jo

On 02/10/2008 14:15, Scheppe, Kai-Dietrich wrote:
>  <<ED-mobileOK-pro10-tests-20080731.htm>>  
> I had been actioned to reduce the test like tone in this document
> somewhat.
> 
> We had agreed that first I should just do a couple of examples that show
> what I am thinking of.
> 
> 
> In the this version of the document I have
> 
> - modified the title
> - modified some introductory texts
> - modified the first two tests
> 
> 
> Please comment on whether this fits the bill
> 
> -- Kai
> 
> 
> ------------------------------------------------------------------------
> 
> W3C </>
> 
> 
>   Addendum to mobileOK Best Practices
> 
> 
>     W3C Working Group Note 2 October 2008
> 
> This version:
>     http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080731
> Latest version:
>     http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/latest
> 
> Previous version:
>     http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080610
> 
> Editor:
>     Kai Scheppe, Deutsche Telekom AG
> Substantial contributions made by:
>     Phil Archer, Family Online Safety Institute
>     Alan Chuter, Technosite
>     Jo Rabin, DotMobi
>     Dave Rooks, Segala
> 
> Copyright <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> 2008 
> W3C <http://www.w3.org/>^ (MIT <http://www.csail.mit.edu/>, ERCIM 
> <http://www.ercim.org/>, Keio <http://www.keio.ac.jp/>), All Rights 
> Reserved. W3C liability 
> <http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer>, 
> trademark <http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks> 
> and document use 
> <http://www.w3.org/Consortium/Legal/copyright-documents> rules apply.
> 
> ------------------------------------------------------------------------
> 
> 
>     Abstract
> 
> This document outlines a set of tests evaluations requiring human 
> evaluation, based on the Mobile Web Best Practices 1.0 
> <http://www.w3.org/TR/mobile-bp/> document and the mobileOK Basic Tests 
> <http://www.w3.org/TR/mobileOK-basic10-tests/> document, provided by the 
> Mobile Web Initiative <http://www.w3.org/Mobile/> Best Practices Working 
> Group. <http://www.w3.org/2005/MWI/BPWG/>
> 
> This document is non-normative, but it is recommended to follow the 
> advice given here to further improve mobile friendly content.
> 
> 
>     Status of this Document
> 
> ///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 public Working Group Note 
> <http://www.w3.org/2003/06/Process-20030618/tr.html#q71> produced by the 
> mobileOK Pro Tests Taskforce 
> <http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/> of the 
> Mobile Web Best Practices Working Group 
> <http://www.w3.org/2005/MWI/BPWG/> as part of the Mobile Web Initiative 
> <http://www.w3.org/2005/MWI/Activity> . Please send comments on this 
> document to the Working Group's public email list public-bpwg-pro@w3.org 
> <mailto:public-bpwg-pro@w3.org>, a publicly archived mailing list 
> <http://lists.w3.org/Archives/Public/public-bpwg-pro/> .
> 
> This document was produced under the 5 February 2004 W3C Patent Policy 
> <http://www.w3.org/Consortium/Patent-Policy-20040205/> . W3C maintains a 
> public list of patent disclosures 
> <http://www.w3.org/2004/01/pp-impl/37584/status> made in connection with 
> this document; 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) with respect to this 
> specification must disclose the information in accordance with section 6 
> of the W3C Patent Policy 
> <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure>.
> 
> Publication as a Working Group Note 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. Other documents may 
> supersede this document.
> 
> 
>     Table of Contents
> 
> 1Introduction <#introduction>
> 1.1 Purpose <#d0e104>
> 1.2 Scope <#d0e117>
> 1.3 Audience <#d0e124>
> 
> 2 Test format <#Test_format>
> 
> 3 Sampling scheme <#sampling>
> 
> 4 Tests <#Tests>
> 4.1 Access Keys <#access_keys>
> 4.2 Auto Refresh <#auto_refresh>
> 4.3 Avoid Free Text <#avoid_free_text>
> 4.4 Background Image Readability <#background_image_readability>
> 4.5 Balance <#balance>
> 4.6 Device Capabilities <#device_capabilities>
> 4.7 Central Meaning <#central_meaning>
> 4.8 Limited <#limited>
> 4.9 Clarity <#clarity>
> 4.10 Color Contrast <#color_contrast>
> 4.11 Content Format Preferred <#content_format_preferred>
> 4.12 Control Labeling <#control_labeling>
> 4.13 Control Position <#control_position>
> 4.14 Cookies <#cookies>
> 4.15 Deficiencies <#deficiencies>
> 4.16 Error Messages <#error_messages>
> 4.17 Fonts <#fonts>
> 4.18 Graphics for Spacing <#graphics_spacing>
> 4.19 Link Target ID <#link_target_id>
> 4.20 Minimize Keystrokes <#minimize_keystrokes>
> 4.21 Navbar <#navbar>
> 4.22 Navigation <#navigation>
> 4.23 Non-text Alternatives <#non-text_alternatives>
> 4.24 Objects or Scripts <#objects_scripts>
> 4.25 Page Size Usable <#page_size_usable>
> 4.26 Page Title <#page_title>
> 4.27 Provide Defaults <#defaults>
> 4.28 Scrolling <#scrolling>
> 4.29 Structure <#structure>
> 4.30 Style Sheets Size <#style_sheets_size>
> 4.31 Style Sheet Support <#style_sheet_support>
> 4.32 Suitable <#suitable>
> 4.33 Tab Order <#tab_order>
> 4.34 Tables Layout <#tables_layout>
> 4.35 Tables Support <#tables_support>
> 4.36 Testing <#testing>
> 4.37 URIs <#uris>
> 4.38 Use of Color <#use_of_color>
> 
> 
>       Appendices
> 
> A References <#refs> (Non-Normative)
> 
> ------------------------------------------------------------------------
> 
> 
>     1 Introduction
> 
> 
>       1.1 Purpose
> 
> The purpose of this document, despite its subjective nature, is to 
> provide guidelines to content producers on how to go improve their 
> content even beyond mobileOK Basic and make the claim of having achieved 
> mobileOK Pro, by following the guidelines laid out in this document.
> 
> Due to the subjective nature of some of these guidelines no 
> deterministic tests can be performed.
> 
> However, the content author is encouraged to adapt implementation of 
> these guidelines in a way best suited for the given situation.
> 
> mobileOK Best Practices <http://www.w3.org/TR/mobile-bp/> is a set of 
> guidelines which are partially testable via the mobileOK Basic Tests 
> Checker <http://validator.w3.org/mobile/>, a tool for automated tests of 
> a subset of Best Practices.
> 
> This addendum mobileOK Pro then provides a set of guidelines that fill 
> the gaps left by the limitations of automated tests and thus completes 
> the set of Best Practices.
> 
> 
>       1.2 Scope
> 
> The scope of this document is limited to the mobileOK Best Practices, 
> the mobileOK Basic Tests resulting from those best practices and the 
> difference between the two.
> 
> 
>       1.3 Audience
> 
> This document is intended for creators, maintainers and operators of Web 
> sites. Readers of this document are expected to be familiar with the 
> creation of Web sites, and to have a general familiarity with the 
> technologies involved, such as Web servers and HTTP. Readers are not 
> expected to have a background in mobile-specific technologies.
> 
> 
>     2 Test format
> 
>     * Provide a link to the actual Best Practice
>     * Provide a statement about what this test guideline does not cover
>     * Provide a statement, if applicable, which differences to mobileOK
>       Basic Tests are addressed in this guideline mobileOK Pro test,
>       with a link a to the basic test in question.
>     * Provide an evaluation test procedure that outlines the test itself
>       Here each test or question needs to be answered separately with
>       [PASS], [FAIL], [WARN]
>     * Examples
>       Prose examples of what we are talking about
>     * Pass/Fail/Warn
>           o Pass - as default you pass the test
>           o Fail - if you explicitly fail one of the tests you fail the
>             whole test
>           o Warn - does not fail but provides information to the
>             author/provider on what to do better
> 
> 
>     3 Sampling
> 
> 
>       3.1 Test Evaluation Scope
> 
> While most tests evaluations apply to single pages or delivery units 
> <http://www.w3.org/TR/di-gloss/#def-delivery-unit>, some tests, such as 
> ACCESS_KEYS, NAVIGATION and URIS are tested across multiple pages. To 
> perform the tests evaluations correctly it is necessary to define the 
> scope of the evaluation. This may be expressed using URI patterns [or 
> groupings using POWDER <http://www.w3.org/TR/powder-grouping/>]."
> 
> ------------------------------------------------------------------------
> 
> 
>     4 Tests
> 
> 
>       4.1 Access Keys <http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this evaluation test:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> It is independent of the Default Delivery Context (DDC) 
> <http://www.w3.org/TR/mobile-bp/#ddc>
> 
> 
>         Interpretation of the Best Practice:
> 
> This test applies to primary navigation links that occur across all 
> pages within a given web space which is itself defined by the presence 
> of those navigation links. Such navigation links should be associated 
> with access keys. Furthermore, the access key assignment MUST should be 
> identical for those links.
> 
> Access keys may be indicated to end users in any of three ways
> 
>     * Link decoration
>     * Summary page
>     * Listing on a sitemap
> 
> 
>         Test Evaluation procedure:
> 
> Where there are elements, particularly navigation links and form 
> controls, that would benefit from access keys:
> 
>     * If access keys are not assigned at least to the primary navigation
>       links found on all pages within a Web space defined by the
>       presence of those links [FAIL]
> 
>       Check if access keys have been assigned at least to the primary
>       navigation links found on all pages within a Web space defined by
>       the presence of those links
> 
>     * If access keys for primary navigation links are not identical
>       across all pages: [FAIL]
> 
>       Ensure that access keys for primary navigation links are identical
>       across all pages
> 
>     * If access keys are not indicated in at least one of the ways cited
>       above: [FAIL]
> 
>       Make sure to indicate which access are being used through at least
>       one of the methods above
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.2 Auto Refresh <http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this evaluation test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> The Basic test detects the presence of an automatic refresh. This , the 
> Pro test looks for a user option to prevent automatic refresh.
> 
> 
>         Test Evaluation procedure:
> 
> If the Basic Test results in a warning about auto refresh and there is 
> no link provided to another instance of the content which does not 
> refresh [FAIL]
> 
> If the mobileOK checker warns about auto refresh make sure a link is 
> provided to a non-refreshing version of the original resource
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.3 Avoid Free text <http://www.w3.org/TR/mobile-bp/#AVOID_FREE_TEXT>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If the user is asked to fill in a form and if there is a finite number 
> of possible values that the user could enter and those options are not 
> presented either as a series of radio buttons, check boxes or a select 
> menu: [FAIL].
> 
> 
>         Examples:
> 
>     * Selecting ZIP/Post codes from a list, perhaps within a limited
>       geographical area of interest or in a sequence of steps where each
>       list of options is dependent on the previous data entered
>     * Selecting a country from a drop down list, ideally with the most
>       likely choice(s) at the top as well as in the list in their
>       alphabetical position
>     * Having to enter text for words like 'Yes' and 'No' is a clear FAIL.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.4 Background Image readability
>       <http://www.w3.org/TR/mobile-bp/#BACKGROUND_IMAGE_READABILITY>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests, but it is worth noting 
> that the DDC does support background images which are part of CSS 1.
> 
> 
>         Interpretation of the Best Practice
> 
> The use of patterned or photographic background images behind text is 
> discouraged but not prohibited.
> 
> 
>         Test procedure:
> 
> If background images are used, the COLOR CONTRAST test must be passed 
> for the ratio between the overlying text and each color used in the 
> background image. Otherwise: [FAIL]
> 
> 
>         Examples:
> 
>     * The Ishihara Test for Color Blindness, for example, shows
>       background and text with patterning and insufficient color contrast.
>     * The contrast between this text and its black background color is 5:1
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.5 Balance <http://www.w3.org/TR/mobile-bp/#BALANCE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None.
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If the page contains more than 30 links: [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.6 Device Capabilities <http://www.w3.org/TR/mobile-bp/#CAPABILITIES>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test cannot cover all the possible capabilities that might be found 
> in devices.
> Unlike the DDC, many real devices support scripting, XML HTTP requests, 
> DOM capabilities, cookies and CSS including media queries.
> However, it is usually possible to detect a presentation that is 
> artificially constrained by the limited and largely hypothetical Default 
> Delivery Context.
> 
> 
>         Interpretation of the Best Practice:
> 
> Rather trying to find where device capabilities are not utilized it is 
> more conclusive to identify those instances where the content is 
> wrongfully limited on a device more capable than the DDC.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * For each property of the DDC (e.g. screen width), identify some
>       unadapted, original content that would exceed the value given by
>       that property of the DDC
>     * Request content on a device more capable than the DDC for that
>       particular property
>     * If content is rendered according to the constraints of the DDC: [FAIL]
> 
> 
>         Examples:
> 
>     * Web sites that offer video streams should not offer such content
>       for the DDC, however, it should be offered to users of devices
>       that do support video.
>     * Presentation should adjust itself to the optimal display for this
>       device and not be unnecessarily limited to 120 pixels wide.
>     * JavaScript should be used for form validation on devices that
>       support it as this can reduce network traffic and latency.
>     * In forms scripting may be used to adjust the presentation or state
>       of a control based on the input already supplied.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.7 Central Meaning <http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
>     * Visual-only.
>     * Does not attempt to evaluate the meaningfulness of the visible
>       content (would be too subjective).
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * Determine what is the main content of the page. This is content
>       that is unique to the page and does not repeat across several pages.
>     * If none of the main content of the web page is visible without
>       scrolling: [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.8 Limited <http://www.w3.org/TR/mobile-bp/#LIMITED>
> 
> 
>         Note to BPWG:
> 
> Advise on the use of the type attribute on links to provide information 
> in machine-readable format for future user agents.
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * The information contained in the link text must describe (e.g.
>       contextual information, content type, file size) the content that
>       will be retrieved. If not, [FAIL].
>     * Content provided or linked to should be suitable for the mobile
>       context, unless provided in a controlled environment where its
>       unsuitability is know a priori.
> 
> 
>         Examples:
> 
>     * Content may be suitable in a controlled environment, with logon
>       for entry, for example for retrieval of large medical scans on
>       mobile devices.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.9 Clarity <http://www.w3.org/TR/mobile-bp/#CLARITY>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test is subjective and cannot be conclusive. It must therefore 
> remain at a warning level to be informative.
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If the text is, for the context, considered to be unnecessarily complex 
> or verbose [WARN]
> 
> 
>         Examples:
> 
>     * Consider the purpose of the page. If the purpose of the page is to
>       deliver a specific piece of information, that information should
>       be readily extracted without excessive scrolling or scanning of text.
>     * In the English language the Fogg test can give an indication of
>       complexity. A level of rough 7 or 8 would be ideal. For other
>       languages this does not apply.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.10 Color Contrast <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST>
> 
> 
>         Note to BPWG:
> 
> This test could well be machine testable as there are publically 
> accessible applications which compare color values.
> 
> 
>         Limitations of this test:
> 
> This test is actually defined in 
> http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18, to 
> which we refer here
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If the contrast ratio is less than 5:1, according to 
> http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18 [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.11 Content Format Preferred
>       <http://www.w3.org/TR/mobile-bp/#CONTENT_FORMAT_PREFERRED>
> 
> 
>         Note to BPWG:
> 
> This test is machine testable and we are not sure why is it not covered 
> in the basic tests. The number of alternative formats is small and could 
> be searched for by issuing subsequent appropriate requests.
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>    1. Determine which alternative formats are available.
>    2. If no alternative formats are available [PASS], otherwise
>    3. Change the quality factors of the accept headers to express a
>       preference for an available alternative format
>    4. If the content which is delivered does not reflect that change: [FAIL]
> 
> 
>         Examples:
> 
> Typical changes to preferences such as the following should be reflected 
> accordingly:
> 
>     * GIF and JPEG
>     * Character encoding
>     * Markup language
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.12 Control Labeling
>       <http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING>
> 
> 
>         Note to BPWG:
> 
> This test is machine testable
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * If there are user-visible form elements and no label elements: [FAIL]
>     * If the |for| attribute is not defined and the form control is not
>       contained within the label element: [FAIL]
>     * If the |for| attribute is present but does not correspond to the
>       |id| attribute of a form control: [FAIL]
>     * If the label does not describe the purpose of the form control: [FAIL]
> 
> 
>         Examples:
> 
>     * A label which requests a persons name but is associated with a
>       birth date field, fails.
> 
> 
>         Open issues:
> 
>     * Are there ever presentational / layout reasons why having a form
>       label isn't appropriate? e.g. if there's only one form element and
>       the meaning of that element is given by the context of the page?
>     * Are empty labels "" acceptable, if the meaning of the field is
>       made clear in some other fashion?
> 
> ------------------------------------------------------------------------
> 
> 
>       4.13 Control position
>       <http://www.w3.org/TR/mobile-bp/#CONTROL_POSITION>
> 
> 
>         Note to BPWG:
> 
> The BP says labels ashould be positioned �properly� but gives no clue as 
> to what this means. It should either clarify what is intended or this BP 
> should be deprecated."
> 
> 
>         Limitations of this test:
> 
>     * The aspect of properly aligning with a form control has been
>       limited to mean �in the vicinity�, as the positioning to the left
>       or below an input field is not the only way to use them.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * If CSS is turned off and labels are not clearly associated with a
>       form control [FAIL]
>     * If the label cannot be clearly associated with a form control [FAIL]
>     * If the association is only achieved by means of positional CSS [FAIL]
> 
> 
>         Examples:
> 
> See Gez Lemon's article on Label Positioning 
> <http://juicystudio.com/article/label-positioning.php>. The examples 
> should be in the BP document.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.14 Cookies <http://www.w3.org/TR/mobile-bp/#COOKIES>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
>     * The tester can not know with certainty all the functionality that
>       may rely on cookies. It is however possible to apply this check to
>       the main intent of the page
>     * The test does not deal with potential alternatives which may be used.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>    1. Identify the main functionality of the site that is important for
>       the user and may rely on state. See examples.
>    2. Evaluate the funcionality with cookies supported correctly.
>    3. Disable cookies supported. Evaluate the funcionality and compare
>       with that evaluated in 2.
>    4. If the content or function cannot be accessed without cookies [FAIL]
> 
> 
>         Examples:
> 
> A site that requires a user to login might store that login in a cookie 
> to save the user typing in their credentials each time they visit. If 
> cookies are unavailable, an acceptable degradation would mean that the 
> user was prompted for a login each time they visited that page, but 
> would browse the site without further logins from then on. A poor (and 
> unacceptable) cookieless degradation would render a site useless by 
> always checking for a non-existent cookie and so not letting the user 
> past the login page.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.15 Deficiencies <http://www.w3.org/TR/mobile-bp/#DEFICIENCIES>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test cannot test all existing deficiencies of devices. Rather the 
> test limited to the author/provider being aware of common deficiencies 
> and do something about those. This test is not intended to test pixel 
> perfect rendering across devices, but rather focuses on usability across 
> devices.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If there are common deficiencies of devices, which impinge significantly 
> on usability of the content being offered, measures must be taken to 
> work around those deficiencies. If not [FAIL]
> 
> 
>         Examples:
> 
> Some devices which render tables badly will wrap columns by default, if 
> the meaning of the page is dependent on layout which does not render 
> well on these sorts of devices then an alternative rendering should be 
> used when that user-agent is detected.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.16 Error Messages <http://www.w3.org/TR/mobile-bp/#ERROR_MESSAGES>
> 
> 
>         Note to BPWG:
> 
> An external tester can not know what errors generate error messages, or 
> what languages are available.
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> 1. Provoke a server-side error.
> 
>     * For example: Request a URL known not to correspond to any endpoint
>       on the site.
> 
> 2. Examine the content of the error page. All the following must be 
> true, if not [FAIL].
> 
> It must:
> 
>     * Explain in non-technical language the error which has occurred.
>     * Be suitable for the DDC, at a minimum, (ie it must comply with all
>       other tests).
>     * Provide at least one of the following links: site home page, back,
>       reload.
>     * Be in the language the user was reading on the site when the error
>       occurred.
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> The mechanism by which a context specific error message can be displayed 
> in not clear. For example, how to display a French error message if the 
> user was in the French section of the site.
> 
> ------------------------------------------------------------------------
> 
> 
>       4.17 Fonts <http://www.w3.org/TR/mobile-bp/#FONTS>
> 
> 
>         Note to BPWG:
> 
> The intent of the BP stated in 5.4.16.1 is that meaning should be 
> conveyed without relying on font-related styling. However, the "Machine 
> Test" under 5.4.16.2 fails on any presence of any font-related styling 
> (whether it conveys meaniong or not).
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>    1. Check for presence of font-related styling, by means of the font
>       element, or the bold, italic or underline elements, or CSS.
>    2. Examine the content with CSS enabled and disabled. If the meaning
>       is significantly different [FAIL]
>    3. Examine any font-related elements present and the effect they have
>       on the meaning of the content. If they are used to convey meaning
>       significantly, [FAIL]
>    4. Check for the presence of the "face" element. If only one font has
>       been defined [FAIL]
> 
> 
>         Examples:
> 
>     * Emphasis expressed using bold or underline.
>     * Quotes that are indicated by italics rather than enclosed in
>       quotation marks or quotation markup.
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.18 Graphics for Spacing
>       <http://www.w3.org/TR/mobile-bp/#GRAPHICS_FOR_SPACING>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test does not rely on a particular graphics format that are being 
> evaluated.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This BP is partially covered by the GRAPHICS_FOR_SPACING MobileOK basic 
> Test <http://www.w3.org/TR/mobileOK-basic10-tests/#GRAPHICS_FOR_SPACING>.
> 
> 
>         Test procedure:
> 
> Does the content comply with GRAPHICS_FOR_SPACING MobileOK Basic Test 
> <http://www.w3.org/TR/mobileOK-basic10-tests/#GRAPHICS_FOR_SPACING>? If 
> not [FAIL].
> 
> View all images in a page, for example in a separate list of images, or 
> by outlining them. For XHTML these will be included using the <img> 
> element.
> Determine visually whether any of the images do not convey information 
> and are used for spacing. If they are [FAIL].
> 
> Note: Spacer images do not convey useful information. They are normally 
> very small.
> 
> 
>         Examples:
> 
>     * 1 pixel square image used to seperate other content.
>     * A small image with the same colour as the surrounding content.
>     * Single Pixel GIF Trick on Creating Killer Websites
>       <http://www.killersites.com/killerSites/1-design/single_pixel.html>
> 
> 
>         Open issues:
> 
> Define unambiguously what is and is not a spacer image.
> 
> ------------------------------------------------------------------------
> 
> 
>       4.19 Link Target ID <http://www.w3.org/TR/mobile-bp/#LINK_TARGET_ID>
> 
> 
>         Note to BPWG:
> 
> The abbreviation "ID" included in the handle of the BP, is confusing and 
> suggests it involves the ID attribute. The test covers the use of 
> hreflang, type and charset attributes which are not mentioned in the BP.
> 
> 
>         Limitations of this test:
> 
> This test only deals with the descriptive portion of a link
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>    1. Each link in the text is described by attributes as follows. If
>       not, [FAIL].
>           * If the target content is in a language different to that of
>             the tested content, it is correctly marked with hreflang
>             attribute;
>           * If it is in a format other than that of the tested content,
>             it is correctly described by the type attribute;
>           * If it uses a character encoding different to that of the
>             tested content, it is described by the charset attribute.
>    2. Check that the link text (including alternative text for any
>       non-text elements) clearly describes the effect of activating the
>       element. If not, [FAIL]
>    3. Select elements pairwise. Check that two links with same link text
>       (including alternative text for non-text elements) and same title
>       attribute (if provided) point to the same resource. If not, [FAIL].
> 
> (These liberally adapted from UWEM 1.0 13.1 
> <http://www.wabcluster.org/uwem/tests/#guideline-13>).
> 
> 
>         Examples:
> 
>     * Link with only the text "Click here."
>     * Multiple links in same page with same content but pointing to
>       different things.
>     * Link from an HTML page to a large video file that does not mention
>       format or size.
>     * Link to content in a language different to that of the current page.
> 
> 
>         Open issues:
> 
> Can contextual information can provide enough explanation for a "click 
> here" link?
> 
> What is meant here is that there are instances were enough information 
> is provided in the preceeding or surrounding text that a more detailed 
> link description is not needed
> 
> ------------------------------------------------------------------------
> 
> 
>       4.20 Minimize Keystrokes
>       <http://www.w3.org/TR/mobile-bp/#MINIMIZE_KEYSTROKES>
> 
> This test is covered by tests for AVOID_FREE_TEXT <#avoid_free_text>, 
> URIS <#uris>, CENTRAL_MEANING <#central_meaning> and PROVIDE_DEFAULTS 
> <#defaults>.
> 
> ------------------------------------------------------------------------
> 
> 
>       4.21 Navbar <http://www.w3.org/TR/mobile-bp/#NAVBAR>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * Is there basic navigation on the page before the other content? If
>       not [FAIL].
>     * Does all the navigation detected in [1]
> 
>       fit on a single line in the DDC? If not [FAIL].
> 
>     * Is a some of the main content visible without scrolling
>       (sufficient to get an idea of the rest of the content)? If not [FAIL]
> 
> 
>         Examples:
> 
> Navigation bar consisting of only: Home; Up; Site map; Search...
> 
> 
>         Open issues:
> 
>     * How much navigation is admissible?
>     * Can it be quantified in terms of the number of links and the
>       number of characters?
> 
> ------------------------------------------------------------------------
> 
> 
>       4.22 Navigation <http://www.w3.org/TR/mobile-bp/#NAVIGATION>
> 
> 
>         Note to BPWG:
> 
> There seems to be confusion in the MWBP document. The title refers to 
> �consistent navigation�. However, the second paragraph discusses 
> �Intelligent grouping� and the �How to do it� section suggests providing 
> a drill-down list based on section headings, rather than about being 
> consistent (it doesn't say use drill-down lists consistently). The 
> latter is more relevant to [STRUCTURE] than to this BP. What was the 
> intent, consistent navigation across a site or just good navigation in a 
> page? This test assumes that consistency is what must be tested.
> 
> 
>         Limitations of this test:
> 
>     * Tester must be able to delimit what constitutes the site. This is
>       assumed to be the pages in the sample scope <#Test>.
>     * Test has to define what a navigation mechanism is.
>     * It tests for consistency, not good navigation design.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * For all the pages in the sample, examine the navigation mechanisms
>       in the pages. These include inline links, groups of links (for
>       example menus) in different parts of the page.
>     * If navigation mechanisms are different on different pages of the
>       sample other than in a way relevant to the difference between the
>       pages, [FAIL].
> 
> 
>         Examples:
> 
>     * A site navigation menu is present on all pages and only changes
>       the presentation of the section and the current page, [PASS]
>     * A site navigation menu is present on all pages and changes
>       structure and presentation of the links [FAIL].
>     * A site navigation menu is present on some pages but is not on the
>       current page [FAIL].
>     * A site navigation menu is present on two pages of the sample but
>       in a different place [FAIL].
>     * Inline links on other pages have a descriptive title but on the
>       current page they do not.
> 
> 
>         Open issues:
> 
> More examples needed.
> 
> ------------------------------------------------------------------------
> 
> 
>       4.23 Non-text alternatives
>       <http://www.w3.org/TR/mobile-bp/#NON-TEXT_ALTERNATIVES>
> 
> 
>         Note to BPWG:
> 
> The BP is actually in conflict here. The BP itself says "Provide a text 
> equivalent for every non-text element.".
> Yet in "What to test" it says "Test for presence of alt attribute on 
> images and text content on objects." and elaborates to make sure that 
> objects are supported.
> This is actually a subset of the BP itself and therefore in conflict.
> Conversely, the BP states "every non-text element", which greatly 
> increases the scope of this test.
> 
> Additionally, the BP does give a reference to the WCAG definition of 
> "non-text element", which is:
> 
> Non-text Content [WCAG20] 2001-12-10
> See also Normative, Informative
> Non-text content includes images, text in raster images, image map 
> regions, animations (e.g., animated GIFs), applets and programmatic 
> objects, ascii art, scripts, images used as list bullets, spacers, 
> graphical buttons, sounds (played with or without user interaction), 
> stand-alone audio files, audio tracks of video, and video.
> 
> Therefore it seems sensible to adapt the text given by Web Content 
> Accessibility Guidelines 1.0 
> <http://www.w3.org/TR/WCAG10/#gl-provide-equivalents> and deal with all 
> the non-text elements
> 
> 
>         Limitations of this test:
> 
> While not all non-text elements are supported by the DDC, tests should 
> fokus on the super set of elements provided by markup languages.
> 
> 
>         Interpretation of the Best Practice:
> 
> The original intent of the proposed human test for this BP is linked to 
> the meaning of alternative text. While alt="this is alternative text" 
> fulfills the letter of the guideline in terms of usage of the 
> alternative text it leads such practice ad absurdum. This Test will 
> cover both the extension to other non-text elements and the meaning of 
> alt text.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test covers the meaning of textual alternatives as well as 
> additional non-text elements. The mobileOK Basic test only covers the 
> presence or absence of the alt attribute for images and objects, not its 
> value.
> 
> 
>         Test procedure:
> 
> Referring to http://www.w3.org/TR/WCAG10/#gl-provide-equivalents
> 
> Non-text elements include images, graphical representations of text 
> (including symbols), image map regions, animations (e.g., animated 
> GIFs), applets and programmatic objects, ascii art, frames, scripts, 
> images used as list bullets, spacers, graphical buttons, sounds (played 
> with or without user interaction), stand-alone audio files, audio tracks 
> of video, and video.
> 
> If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [FAIL]
> 
>     * Provide a text equivalent for every non-text element that, when
>       presented to the user, conveys essentially the same function or
>       purpose as auditory or visual content. If not [FAIL]
>     * 'Content is "equivalent" to other content when both fulfill
>       essentially the same function or purpose upon presentation to the
>       user.' If not [FAIL]
> 
> 
>         Examples:
> 
>     * Pass: Null value (alt="") for decorative images such as rounded
>       corners in frame
>     * Pass: a text equivalent for an image of an upward arrow that links
>       to a table of contents could be "Go to table of contents".
>     * Fail: alt value same as filename
>     * Fail: alt=" " (space)
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.24 Objects or scripts <http://www.w3.org/TR/mobile-bp/#NAME>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test covers the functionality of documents without objects or 
> scripts, in addition to the mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If, without objects or scripts active or present, the document cannot be 
> viewed or used such that the original intent of the web page is 
> fulfilled [FAIL]
> 
> 
>         Examples:
> 
>  From http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts
> 
>     * Ensure that links that trigger scripts work when scripts are
>       turned off or not supported (e.g., do not use "javascript:" as the
>       link target). If it is not possible to make the page usable
>       without scripts, provide a text equivalent with the NOSCRIPT
>       element, or use a server-side script instead of a client-side
>       script, or provide an alternative accessible page as per
>       checkpoint 11.4. Refer also to guideline 1.
>     * With scripts turned off or not supported or objects not supported
>           o a given form can still be filled out and submitted
>           o images are displayed and alternative text is shown
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.25 Page Size Usable
>       <http://www.w3.org/TR/mobile-bp/#PAGE_SIZE_USABLE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * If a given web page contains contiguous content, which could
>       techically and semantically be separated into individual pages,
>       and exceeds 3 screen sizes in length without page break [FAIL]
> 
> 
>         Examples:
> 
>     * a long article that extends over 3 screens full without some type
>       of page break would have to fail
>     * display of navigational information, requiring continuous movement
>       through the map would pass, because additional maps are loaded as
>       needed
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.26 Page Title <http://www.w3.org/TR/mobile-bp/#NAME>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test covers the meaning of the title, in addition to the existing 
> mobileOK Basic Tests
> 
> 
>         Test procedure:
> 
>     * Does the title thematically describe the main intent of the page
>       content? If not [FAIL]
>     * Does the title repeat unchanged across more than 3 pages? If yes
>       [FAIL]
>     * Is the title too long to display on a screen matching the Default
>       Delivery Context [WARN]
> 
> 
>         Examples:
> 
>     * a page with the primary purpose of offering ring tones along side
>       small textual items should have this reflected in the title
>     * a title such as "Main Portal" which is repeated across more than 3
>       pages would have to fail
>     * conversely a title of "Uncle Tom's Cabin" in an ebook page, across
>       many pages, would be perfectly acceptable
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.27 Provide Defaults
>       <http://www.w3.org/TR/mobile-bp/#PROVIDE_DEFAULTS>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test covers the usefulness of the preselection, in addition to 
> existing mobileOK Basic Tests 
> <http://www.w3.org/TR/mobileOK-basic10-tests/#PROVIDE_DEFAULTS> .
> 
> 
>         Test procedure:
> 
>     * Submit the form without selecting any item (left preselected values):
>           o If the response is an error page [FAIL]
>           o If the response is a page asking the user to fix some data
>             [FAIL]
>           o If the response is the original page [FAIL]
>     * If the form contains a text or textarea input element, with a
>       default value telling what to write there [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.28 Scrolling <http://www.w3.org/TR/mobile-bp/#SCROLLING>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If testing a webpage with a device, and horizontal scrolling appears. 
> For each element wider than screen size:
> 
>     * if it is decorative [FAIL]
>     * if resizing it to screen size, it could be easily read and/or
>       described [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.29 Structure <http://www.w3.org/TR/mobile-bp/#STRUCTURE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * If headers and list elements aren't properly nested according to
>       their level [FAIL]
>     * If lists elements aren't used to represent lists (ordered,
>       unordered, or definition lists) but formatting effects [FAIL]
>     * If headers elements aren't used to represent headers but
>       formatting effects [FAIL]
>     * If visually some information is shown as a group of related
>       elements, but there isn't any list element in the markup [FAIL]
>     * If visually some information is shown as a block of text, but
>       there isn't any paragraph or blockquote element in the markup [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> It is not clear what structural markup is and which elements are 
> included in this definition.
> 
> ------------------------------------------------------------------------
> 
> 
>       4.30 Style Sheets Size
>       <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SIZE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> There is no guidance on this parameter and a value was picked
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * If whitespaces are more than 10% of CSS content [WARN]
>     * If whitespaces are more than 20% of CSS content [FAIL]
>     * If there are style properties that doesn't aply to the page [WARN]
>     * If there are at least two CSS properties that could be mixed in a
>       shorthand property [WARN]
>     * If there is at least one CSS RGB color property that could be
>       written shorthand way [WARN]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
>     * What is an optimized stylesheet?
>     * It is not clear if there should be some upper limit on style sheet
>       use, for example as percentage of the total page size and if there
>       should be, what percentage that should be.
> 
>       Several tests refer to white space. White space has the same
>       definition in this document as in XML. For XML 1.0 [XML10]
>       <../temp/ED-mobileOK-pro10-tests-20080319.html#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.
> 
>       Could this be applied to a CSS?
> 
> ------------------------------------------------------------------------
> 
> 
>       4.31 Style Sheet Support
>       <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SUPPORT>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If content is unreadable or unintelligible with stylesheets disabled [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.32 Suitable <http://www.w3.org/TR/mobile-bp/#SUITABLE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test is clearly very subjective, therefore the threshhold for a 
> FAIL is very high. It must be beyond reasonable argument that the 
> presentation of the content is inapropriate for a mobile context.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> Examine the content to determine if the presentation is very obviously 
> inappropriate in a mobile context. If so [FAIL]
> 
> 
>         Examples:
> 
>     * a page showing Renaissance paintings in full size - FAIL
>     * a page showing a listing of Renaissance Paintings with thumb nails
>       - PASS
>     * a page offering large downloads of applications that mobile
>       devices do not support, such as professional image manipulation
>       software, desktop operating systems etc. - FAIL
>     * a full size x-ray image for in-field access by medical personnel -
>       PASS
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.33 Tab Order <http://www.w3.org/TR/mobile-bp/#TAB_ORDER>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> Does the tab order of links, form controls and objects follow a logical 
> or thematic order? If not [FAIL]
> 
> 
>         Examples:
> 
>     * If a user is required to enter their first name, last name,
>       address and contact number, if the tab order jumps between, say,
>       the first name and the phone number and then back to the last name
>       [FAIL].
>     * If a pizza ordering service offers a choice of toppings and bases,
>       if the tab order jumps between those two categories when
>       presenting the user with options [FAIL]
>     * If the Submit button, or Sumbit and Cancel buttons, are not the
>       last item(s) in the form [FAIL]
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.34 Tables Layout <http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> As of this writing, CSS is itself deficient in that it does not support 
> a grid layout that auto adjusts vertically. It must be recognized 
> therefore that some layouts can currently only be achieved using tables.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> In addition to the mobileOK Basic Test 
> <http://www.w3.org/TR/mobileOK-basic10-tests/#TABLES_LAYOUT>, this test 
> checks usage for layout.
> 
> 
>         Test procedure:
> 
> If tables are used in a fashion that could be achieved using CSS [FAIL]
> 
> 
>         Examples:
> 
>     * An image or text which is spaced and positioned with the aid of a
>       table
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.35 Tables Support <http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
> If the device does not support tables and the table element is found 
> within the source code [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> Is there a way to programatically determine if a device supports tables?
> 
> ------------------------------------------------------------------------
> 
> 
>       4.36 Testing <http://www.w3.org/TR/mobile-bp/#TESTING>
> 
> 
>         Note to BPWG:
> 
> This BP gives no information about what is being tested, which calls 
> this BP into question as being useless.
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * Has this content been tested with emulators? If not [FAIL]
>     * Has this content been tested with actual devices? If not [FAIL]
>     * I would also offer: Has this content been validated? If not [FAIL]
>       and Has this content been tested with the Checker
>       <http://validator.w3.org/mobile/>? If not [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.37 URIs <http://www.w3.org/TR/mobile-bp/#URIS>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * Is the entry Domain, including main and subdomain, less than 20
>       key presses on the device? If not [WARN]
>     * Does the entry URI require a file extension as in .html? If yes,
>       [FAIL]
>     * Does the entry URI require the www subdomain? If yes, [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>       4.38 Use of color <http://www.w3.org/TR/mobile-bp/#USE_OF_COLOR>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Test procedure:
> 
>     * Excluding hyperlinks, does the page include any other blue or
>       purple text? If yes, [FAIL]
>     * When viewed on a monocrome screen, is all content still readable?
>       If not, [FAIL]
>     * Is color used to represent information? If yes, [FAIL]
> 
> 
>         Examples:
> 
>     * Using red text to represent an error message - PASS
>     * Using blue or purple text within the page, other than for
>       hyperlinks <http://www.example.org/> - FAIL
>     * Telling the user that important information is highlighted in
>       yellow - FAIL
> 
> 
>         Open issues:
> 
> None
> 
> ------------------------------------------------------------------------
> 
> 
>     A References
> 
>     * http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual-audio-contrast7
>     * http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18
>     * UWEM 1.0 13.1 <http://www.wabcluster.org/uwem/tests/#guideline-13>
>     * http://www.wabcluster.org/uwem1_2/
>     * http://validator.w3.org/mobile/
>     * Cool URIs don't change <http://www.w3.org/Provider/Style/URI>
>     * http://www.w3.org/TR/di-gloss/#def-delivery-unit
>     * http://www.w3.org/TR/powder-grouping/
> 
Received on Friday, 10 October 2008 20:17:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 October 2008 20:17:32 GMT