New draft available (was: [public-bpwg-pro] <none>)

Hi guys,

I published the editors' draft:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228

The draft is accessible from the group's and the TF's home pages.

François.


Scheppe, Kai-Dietrich wrote:
> Hi,
>  
> I have mailed the draft for Francois for posting...but here it is for 
> you as well of course.
>  
> -- Kai
>  
> Please make note of my new email address:
> k.scheppe@telekom.de
>  
> 
> ------------------------------------------------------------------------
> 
> 
>   mobileOK Pro Tests Version 1
> 
> 
>     Group Working Draft 20 February 2008
> 
> This version:
>     Insert link here 
> Latest version:
>     Insert link here 
> Previous version:
>     Insert link here
> Editor:
>     Kai Scheppe, Deutsche Telekom AG, Products & Innovation
>     Phil Archer, Family Online Safety Institute
>     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 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
> 
> First Editor's Draft
> 
> 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 and Limited <#central_meaning_limited>
>     4.8 Clarity <#clarity>
>     4.9 Color Contrast <#color_contrast>
>     4.10 Content Format Preferred <#content_format_preferred>
>     4.11 Control Labeling <#control_labeling>
>     4.12 Control Position <#control_position>
>     4.13 Cookies <#cookies>
>     4.14 Deficiencies <#deficiencies>
>     4.15 Error Messages <#error_messages>
>     4.16 Fonts <#fonts>
>     4.17 Graphics for Spacing <#graphics_spacing>
>     4.18 Link Target ID <#link_target_id>
>     4.19 Minimize Keystrokes <#minimize_keystrokes>
>     4.20 Navbar <#navbar>
>     4.21 Navigation <#navigation>
>     4.22 Non-text Alternatives <#non-text_alternatives>
>     4.23 Objects or Scripts <#objects_scripts>
>     4.24 Page Size Usable <#page_size_usable>
>     4.25 Page Title <#page_title>
>     4.26 Provide Defaults <#defaults>
>     4.27 Scrolling <#scrolling>
>     4.28 Structure <#structure>
>     4.29 Style Sheets Size <#style_sheets_size>
>     4.30 Style Sheet Support <#style_sheet_support>
>     4.31 Suitable <#suitable>
>     4.32 Tab Order <#tab_order>
>     4.33 Tables Layout <#tables_layout>
>     4.34 Tables Support <#tables_support>
>     4.35 Testing <#testing>
>     4.36 URIs <#uris>
>     4.37 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
> 
> 
>         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:
> 
>     * The BP does not say anything about listing which access keys are
>       being used.
>     * The recommend form of the access key (numeric 1 vs. alpha-numeric
>       “abc”) is not mentioned. Should this Pro test go further than BP
>       and encourage the use of numeric access keys?
> 
> 
>         Limitations of this test:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> Where there are elements, particularly navigation links and form 
> controls, that would benefit from access keys:
> 
>     * If access keys are not assigned: [FAIL]
>     * If access keys are not indicated effectively: [FAIL]
>     * If the usage of access keys is not consistent across a given page
>       and site: [FAIL]
> 
> 
>         Examples:
> 
>     * Hyperlinks may be easily decorated with access keys by presenting
>       them in an ordered list where the access code is equivalent to the
>       list position (and is usually numeric).
>     * Form control labels may underline the relevant access key
>     * A quick reference guide to access keys may be available at the
>       bottom of the page (NOT on a separate page).
> 
> 
>         Open issues:
> 
> One might argue what benefits and what doesn’t?
> 
> To be more explicit - if you have navigation options and/or form 
> controls, there should be access keys.
> 
> 
>       4.2 Auto Refresh <http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> 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:
> 
> There are many different ways to aid data input, with no one 'right' 
> way. However, leaving it entirely up to the user to enter the data 
> freehand without any attempt to offer pre-selection or pre-filling of 
> the input field by automated means, where avilable, is readily 
> detectable as 'the wrong way.'
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> If there are one or more free text input fields:
> 
> Could they be converted into any of:
> 
>     * a select field,
>     * radio buttons with no more than x values,
>     * radio buttons for the most likely entries plus a free text option
>       for 'other' values
>     * check boxes with no more than y values?
> 
> If these techniques are avilable, but not implemented: [FAIL].
> 
> If the techniques above are not avilable and if data has been entered 
> previously, if the previously-entered data is not used to pre-fill the 
> input field: [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:
> 
> This test does extend to users with visual impairment. The Web Content 
> Accessibility Quick Reference 
> <http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual-audio-contrast7> 
> offers more advice on this topic.
> 
> 
>         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.
> 
> 
>         Pseudo code:
> 
> Where there is a background image, if perceiving content in the 
> foreground is not easy under normal daylight conditions: [FAIL]
> 
> 
>         Examples:
> 
>     * Pink is easily lost on this background
>     * Yellow is practically not legible on this background
>     * But this is much better
> 
> 
>         Open issues:
> 
> Should we include a reference to the WCAG 2.0 techniques? If so, did 
> Alan choose the right one?
> 
> 
>       4.5 Balance <http://www.w3.org/TR/mobile-bp/#BALANCE>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> This test is highly dependent on context. Some content, such as site 
> maps, online encyclopedias and other reference materials may warrant a 
> high link density. As the scrolling action on many mobile devices 
> selects each link in turn, however, including a lot of links on a single 
> page can easily create an unsatisfactory user experience.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> Unless the primary purpose of the content is navigation, such as a site 
> map, or the user could readily want to persue links to further resources 
> in an unpredictable manner:
> 
> 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. However, it is usually possible to detect presentation that 
> is artificially constrained by the limited and largely hypothetical 
> Default Delivery Context. Unlike the DDC, many real devices support 
> scripting, XML HTTP requests, DOM capabilities, cookies and CSS 
> including media queries. Furthermore most current devices have screens 
> well in excess of 120 pixels wide
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> If the presentation of the content is artificially limited by the 
> capabilities of the DDC and if the presentation is similarly limited on 
> more capable devices: [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.
>     * Again, in forms, scripting may be used to adjust the presentation
>       or state of a control based on the input(s) already supplied.
> 
> 
>         Open issues:
> 
> This is a can of worms, but it is important to counteract the “working 
> down to the DDC” issue
> 
> 
>       4.7 Central Meaning
>       <http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING> and Limited
>       <http://www.w3.org/TR/mobile-bp/#LIMITED>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         Limitations of this test:
> 
> There are subtle differences between these two Best Practices. Central 
> Meaning is concerned with the physical layout of the page, ensuring that 
> desktop-style navigation does not dominate whilst Limited is concerned 
> with presenting information in a manner that reflects the likely real 
> world situation of the audience - on the move with limited time and 
> attention span, perhaps in an environment where there are many forces 
> competing for the user's attention. Despite these differences, it is 
> convenient to test conformance with these two Best Practices together.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
>     * If it is not possible to determine what the main focus of a web
>       page is without scrolling: [FAIL]
>     * If simple facts that can readily be presented using bullet points
>       and headings are instead presented as lengthy prose: [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.8 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.
> 
> 
>         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.9 Color Contrast <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST>
> 
> 
>         Note to BPWG:
> 
> None
> 
> 
>         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
> 
> 
>         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.10 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.
> 
> 
>         Limitations of this test:
> 
> This test cannot be failed, because alternate formats may not be available.
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
> The follow is not very explanatory and needs some wordsmithing.
> How would one determine a "change" in the quality headers, which denote 
> preference of a content format?
> Or did we mean if they are different, as in 0.1 - 0.9 over a variety of 
> formats?
> 
> If the quality factors of the accept headers are changed and the content 
> which is delivered does not reflect that change [WARN]
> 
> 
>         Examples:
> 
> A change in preference between GIF and JPEG, character encoding or 
> markup for a given device, should be reflected accordingly.
> 
> 
>         Open issues:
> 
> None
> 
> 
>       4.11 Control Labeling
>       <http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING>
> 
> 
>         Note to BPWG:
> 
> This test is machine testable
> 
> 
>         Limitations of this test:
> 
> None
> 
> 
>         Differences to mobileOK Basic Tests:
> 
> This test does not exist in mobileOK Basic Tests.
> 
> 
>         Pseudo code:
> 
>     * If there are form elements and no label elements [FAIL]
>     * If the for attribute is not defined and the content of the label
>       element is not a form control [FAIL]
>     * If the for attribute is present but does not correspond to the id
>       attribute of a form control [FAIL]
> 
> 
>         Examples:
> 
> None
> 
> 
>         Open issues:
> 
>     * Confirm that point 1 is really valid.
>     * 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?
> 
> 
>       4.12 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.13 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.14 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.15 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.16 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.17 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.18 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.19 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.20 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.21 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.22 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.23 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.24 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.25 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.26 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.27 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.28 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.29 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.30 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.31 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.32 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.33 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.34 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.35 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.36 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.37 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, 28 February 2008 08:41:49 UTC