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

Re: New version of the document

From: Francois Daoust <fd@w3.org>
Date: Thu, 27 Mar 2008 16:55:07 +0100
Message-ID: <47EBC35B.60604@w3.org>
To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
CC: Mobile Web BP Pro list <public-bpwg-pro@w3.org>

Kai, I apologize, I suddenly realize I missed the part where I'm 
supposed to do something ;)

That's done, see:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080319

Note I sticked to "pro10" in the name as I think this is mobileOK Pro 
"1.0", even if it's the second version of the draft... I can change that 
easily if you find it more confusing.

François.



Scheppe, Kai-Dietrich wrote:
>  <<ED-mobileOK-pro20-tests-20080319.html>> Hi,
> 
> I know this is might late, but we'll be able to go through the document
> on the call.
> 
> 
> @Francois
> I am sorry to be such a nuiscance, but I was not able to use Amaya to
> upload the file.  I was told that even the document that I was trying to
> open from there did not exist.
> Could you please upload this file for me?
> 
> Thanks
> Kai
> 
> 
> ------------------------------------------------------------------------
> 
> 
>   mobileOK Pro Tests Version 2
> 
> 
>     Group Working Draft 19 March 2008
> 
> This version:
>     http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro20-tests-20080319
> 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-20080228>http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228
> Editor:
>     Kai Scheppe, Deutsche Telekom AG
> Substantial contributions made by:
>     Phil Archer, Family Online Safety Institute
>     Dave Rooks, Segala
>     Alan Chuter, Technosite
>     Adam Connors, Google
>     Jo Rabin, DotMobi
> 
> 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 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/>
> 
> 
>     Status of this Document
> 
> *This document is an editors' copy that has no official standing.*
> 
> /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 
> <http://www.w3.org/TR/> at http://www.w3.org/TR/./
> 
> Publication as a Group 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 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>.
> 
> 
>     Revision Description
> 
> Second Editor's Draft
> 
> Most tests from 4.1 through 4.12 have been substantially revised to 
> improve repeatability.
> 
> See [todo] <#todo> for a list of todos.
> 
> 
>     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 To Do <#todo> (Non-Normative)
> B 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 beyond mobileOK 
> Basic and make the claim of having achieved mobileOK Pro, by following 
> the guidelines laid out in this document.
> 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.
> 
> 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 does not cover
>     * Provide a statement, if applicable, which differences to mobileOK
>       Basic Tests are addressed in this mobileOK Pro test, with a link a
>       to the basic test in question.
>     * Provide pseudo code that outlines the test itself
>       Here each test or question needs to be answered separately.
>     * 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
> 
> 
>       2.1 Test template
> 
> This section will be removed prior to publication
> 
> 
>       x.x Name <http://www.w3.org/TR/mobile-bp/#NAME>
> 
> 
>         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.
> 
> 
>         Pseudo code:
> 
> None
> 
> [Pass]
> 
> [Warn]
> 
> [Fail]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> 
>     3 Sampling
> 
> This still needs reworking by Alan
> 
> Say something about the sampling scheme.
> For example, use the UWEM scheme (http://www.wabcluster.org/uwem1_2/) 
> which is applicable. Some tests assume a defined sample scope to 
> carryout the test (for example, NAVIGATION).
> 
> 
>     4 Tests
> 
> 
>       4.1 Access Keys <http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         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 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
> 
> 
>         Pseudo code:
> 
> 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]
>     * If access keys for primary navigation links are not identical
>       across all pages: [FAIL]
>     * If access keys are not indicated in at least one of the ways cited
>       above: [FAIL]
> 
> 
>         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 test:
> 
> None
> 
> 
>         Interpretation of the Best Practice:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> The Basic test detects the presence of an automatic refresh, the Pro 
> test looks for a user option to prevent automatic refresh.
> 
> 
>         Pseudo code:
> 
> 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]
> 
> 
>         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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
>     * 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.
> 
> 
>         Pseudo code:
> 
>     * 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.
> 
> 
>         Pseudo code:
> 
>     * 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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
>    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:
> 
> This, I believe, is not an issue since content negotiation, which is 
> called for here, only works if no extension is listed.
> 
> Is the type explicit in, for example, links, by filename (<img 
> src="imagefile.png"), or is it by content negotiation (<img 
> src="imagefile" with no filename extension.)?
> 
> 
>       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.
> 
> 
>         Pseudo code:
> 
>     * 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:
> 
> None
> 
> 
>         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.
>     * The DDC supports only CSS 1
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
>     * 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:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.14 Cookies <http://www.w3.org/TR/mobile-bp/#COOKIES>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> 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. An 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.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> That is not quite true. At least a 404 is easy to produce and available 
> languages can be inquired.
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> Provoke a server-side error.
> 
>     * For example: Request a URL known not to correspond to any endpoint
>       on the site.
>     * [others]
> 
> 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.
> 
> 
>         Pseudo code:
> 
>    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]
> 
> 
>         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>.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
>    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.
> 
> 
>         Pseudo code:
> 
>     * 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
>       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 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.
> 
> 
>         Pseudo code:
> 
>     * 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].
> 
> The word "sample" in the pseudo code was fitted with links which were 
> non-sensical. Are there samples missing or was some other point being made?
> 
> 
>         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:
> 
> It is not made explicit in the BPs whether all non-text content is 
> covered or only images included with the <img> element.
> 
> 
>         Limitations of this test:
> 
> This test deals with images only. Other non-text content is not 
> mentioned explicitly in the Best Practices and is beyond the scope of 
> this test. Such content includes horizontal rules, form controls, audio, 
> video, multimedia elements, embedded objects and frames.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test covers the meaning of textual alternatives. The mobileOK Basic 
> test only covers the presence or absence of the alt attribute, not its 
> value.
> 
> 
>         Pseudo code:
> 
> If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [FAIL]
> 
> For XHTML content if any of the following UWEM 1.0 tests are not met, 
> [FAIL].
> 
>     * UWEM 1.0 Test 1.1_HTML_01 (note that this is same as Basic test,
>       included for completeness)
>     * UWEM 1.0 Test 1.1_HTML_02
>     * UWEM 1.0 Test 1.1_HTML_03
>     * UWEM 1.0 Test 1.1_HTML_04
> 
> 
>         Examples:
> 
>     * Pass: Null value (alt=“”) for decorative images such as rounded
>       corners in frame
>     * 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.
> 
> 
>         Pseudo code:
> 
> If the document cannot be viewed properly without objects or scripts 
> active or present [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         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.
> 
> 
>         Pseudo code:
> 
>     * If there is no apparent justification for exceeding 3 screen sizes
>       in length [FAIL]
>     * If the pages displayed are so short that multiple requests are
>       needed to display the full information and their combined length
>       does not exceed three screens [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         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
> 
> 
>         Pseudo code:
> 
>     * Does the title meaningfully describe the page content? If not [FAIL]
>     * Is the title too long to display on a screen matching the Default
>       Delivery Context? [WARN]
> 
> 
>         Examples:
> 
> None
> 
> 
>         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 the 
> existing mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
>     * If the preselection for all form elements is useful. If not [FAIL]
>     * If no preselection exists and could meaningfully be added [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.
> 
> 
>         Pseudo code:
> 
> Is the usage of horizontal scrolling justified? If not [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.
> 
> 
>         Pseudo code:
> 
>     * Document structure must be represented using proper structural
>       markup rather than formatting effects. If not [FAIL]
>     * Where structural markup is used it should be used in accordance
>       with the specification, i.e. elements should be properly nested
>       according to their level. If not [FAIL]
>     * If structural markup is being used improperly, e.g. for formatting
>       effect [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.
> 
> 
>         Pseudo code:
> 
>     * Are style sheets optimized? If not [FAIL]
>     * Are the style sheets utilized properly? If not [FAIL]
>     * Is a given style sheet appropriate in its size for the given
>       content, keeping in mind chaching and loading effects? If not [FAIL]
> 
> 
>         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.
> 
> 
>       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.
> 
> 
>         Pseudo code:
> 
> 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:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> Examine content to determine if, given the subject matter, it is 
> appropriate in a mobile context. If not [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 downloads of Windows XP - FAIL
>     * a full size x-ray image for in-field access by EMTs – 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.
> 
> 
>         Pseudo code:
> 
> Is the tab order of links, form controls and objects disorganized, 
> illogical or confusing? If not [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.34 Tables Layout <http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> In addition to the mobileOK Basic Tests, this test checks usage for layout.
> 
> 
>         Pseudo code:
> 
> If tables are used in a fashion that could be achieved using CSS [FAIL]
> 
> 
>         Examples:
> 
> An image or text which are spaced and positioned with the aid of a table
> 
> 
>         Open issues:
> 
> CSS currently is itself deficient in that it does not support grid 
> layout that auto adjusts vertically
> 
> 
>       4.35 Tables Support <http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT>
> 
> 
>         Note to BPWG:
> 
> We had originally asked why this test is not included in basic tests, 
> but the Open Issue below spells it out. How can it be determined if a 
> device supports tables? Just look it up in UAProf or can the Checker do 
> something here?
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> 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.
> 
> 
>         Pseudo code:
> 
>     * 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.
> 
> 
>         Pseudo code:
> 
>     * 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 subdomain www? If yes, [FAIL]
> 
> 
>         Examples:
> 
> Entry URIs should not include information such as author, date, title. 
> See “Cool URIs don’t change <http://www.w3.org/Provider/Style/URI>”
> 
> 
>         Open issues:
> 
> It seems that at least the file extension and the subdomain ought to be 
> machine testable?
> 
> 
>       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.
> 
> 
>         Pseudo code:
> 
>     * Excluding hyperlinks, does your site include any other blue or
>       purple text? If yes, [WARN]
>     * When viewed on a monocrome screen, is all content still readable?
>       If no, [FAIL]
>     * Is color used to represent information? If yes, [FAIL]
> 
> 
>         Examples:
> 
>     * Using red text to represent an error message
>     * Using blue or purple text within the page as it makes it harder to
>       distinguish hyperlinks <http://www.example.org>
>     * Telling the user that important information is highlighted in yellow
> 
> 
>         Open issues:
> 
> None
> 
> 
>     A To Do (Non-Normative)
> 
> Work needed on this draft:
> 
> Section 3: Alan to rework the sampling part
> 
> 
>     B References (Non-Normative)
> 
> 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>
> 
Received on Thursday, 27 March 2008 15:55:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 March 2008 15:55:41 GMT