W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2009

Re: Reaching a final version of Addendum to BPWG

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 22 Sep 2009 09:34:50 +0100
Message-ID: <4AB88C2A.6040500@mtld.mobi>
To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
CC: Phil Archer <phila@w3.org>, Public MWBP <public-bpwg@w3.org>
For your reading pleasure and convenience you will find the attached 
document at

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090922

Jo

On 22/09/2009 08:36, Scheppe, Kai-Dietrich wrote:
> Hi Jo,
> 
> Hi Jo,
> 
> Thanks a bunch for the pointers.  It is apparent that you used to do
> this professionally :-)
> 
> I have made the changes indicated, to save you some work, and corrected
> a few inconsistent indentations and capitalizations as well.
> I have attached a new version of the document, which also contains fixes
> to a couple of other problems that had been pointed out previously.
> 
> But do please check the document and let me know if there are any
> further stylistic faux pas that you might spot :-)
> I can make the changes probably more quickly than you can at this time.
> 
> -- Kai
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Jo Rabin [mailto:jrabin@mtld.mobi] 
>> Sent: Monday, September 21, 2009 7:02 PM
>> To: Scheppe, Kai-Dietrich
>> Cc: Phil Archer; Public MWBP
>> Subject: Re: Reaching a final version of Addendum to BPWG
>>
>> Hi Kai
>>
>>
>> In answer to your question below:
>>
>>  > Quoting from my message from the 7th:
>>  > "For example, I have normalized all bullet point lists 
>> that use  > something like a sentence to using a period at 
>> the end and capital  > letters in the beginning. We had a mix 
>> of Jo's ; and lower case  > notation, . and lower case and 
>> the . and upper case notations. I prefer  > the latter method."
>>  >
>>  > Do you see the inconsistency in the difference between 
>> bullets with a  > couple of words and those with full sentences?
>>  > Please explain.  If it is the former, I will take 
>> editorial license and  > leave it.
>>  > If there are truly inconsitencies, please point them out 
>> as I am, by  > now, blind to them.
>>
>> It's probably way easier if I just fix it up where I spot it. 
>> Can I edit the currently posted draft?
>>
>> 3.9, 3.10, 3.18, 3.19, 3.20 and 3.31
>>
>> Sorry about this but I spotted another typo:
>>
>> 3.26 Style Sheets Size
>>
>> Relevant Delivery Context Capabilities
>>
>> Verify that style sheets do not contain more than 25% white 
>> space Verify that all style rules are used somewhere in the Web site
>>
>> The heading should be "Evaluation Procedure" I think.
>>
>> Cheers
>> Jo
>>
>>
>>
>> On 16/09/2009 16:19, Scheppe, Kai-Dietrich wrote:
>>> Hi Jo,
>>>
>>> Thanks for your input.  Answers in the text.
>>> File will follow.
>>>
>>> -- Kai
>>>
>>>
>>>
>>>> I have only a couple of very minor observations.
>>>>
>>>> 1) the punctuation used to end bullets and numbered lists is not 
>>>> consistent (the predominant style seems to be to end with a ".")
>>> Quoting from my message from the 7th:
>>> "For example, I have normalized all bullet point lists that use 
>>> something like a sentence to using a period at the end and capital 
>>> letters in the beginning. We had a mix of Jo's ; and lower case 
>>> notation, . and lower case and the . and upper case notations. I 
>>> prefer the latter method."
>>>
>>> Do you see the inconsistency in the difference between 
>> bullets with a 
>>> couple of words and those with full sentences?
>>> Please explain.  If it is the former, I will take editorial license 
>>> and leave it.
>>> If there are truly inconsitencies, please point them out as 
>> I am, by 
>>> now, blind to them.
>>>
>>>
>>>
>>>> 2) Under "Evaluation" the formula "Verify that" is used pretty 
>>>> consistently up to about 3.8. After that it seems to
>>> <snip>
>>>  
>>>> I think the document would actually benefit from a small amount of 
>>>> tidying up in that area - maybe to use "verify that" throughout.
>>> Good catch. 3.23 has been reformulated and the rest of the document 
>>> has been adapted.
>>>
>>>
>>>> 3) the names of elements and attributes might benefit from <code> 
>>>> treatment.
>>> Yes, I agree.  It has been done.
>>> Furthermore, all references to a specific elements have 
>> been placed in 
>>> <> and code style
>>>
>>>
>>>> 4) Capitalization of some of the sub-heads e.g. Use of 
>> color => Use 
>>>> of Color, Examples of informal evaluation => Examples of Informal 
>>>> Evaluation
>>> Done.  
>>> Examples of informal evaluation has been reduced to 
>> Examples, which is 
>>> the general pattern.
>>>
>>>
>>>  
>>>> I'd offer to do something on this but have my work cut out 
>> trying to 
>>>> do a new draft of CT by next week.
>>>
>>> No need. It's done.
>>
>> ------------------------------------------------------------------------
>>
>> W3C <http://www.w3.org/>
>>
>>
>>   Addendum to Mobile Web Best Practices
>>
>>
>>     W3C Editor's Draft 22 September 2009
>>
>> This version:
>>     http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090922
>> 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-20090914
>>     <http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090214>
>> Editor:
>>     Kai Scheppe, Deutsche Telekom AG
>> Substantial contributions made by:
>>     Phil Archer,  W3C/ERCIM (formerly at FOSI)
>>     Alan Chuter, Technosite
>>     Jo Rabin, DotMobi 
>>     Dave Rooks, Segala
>>     José Manrique López de la Fuente, Fundación CTIC
>>
>> Copyright 
>> <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> © 2009 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 supplements W3C Mobile Web Best Practices 1.0 
>> <http://www.w3.org/TR/mobile-bp/> [MWBP <#MWBP>] by providing 
>> additional evaluations of conformance to Best Practice statements and 
>> by providing additional interpretations of Best Practice statements.
>>
>>
>>     Status of this Document
>>
>> /This section describes the status of this document at the time of its 
>> publication. Other documents may supersede this document. A list of 
>> current W3C publications and the latest revision of this technical 
>> report can be found in the W3C technical reports index at 
>> http://www.w3.org/TR/. /
>>
>> This is a public *editor's draft* produced by the mobileOK Pro Tests 
>> Taskforce 
>> <http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/> of the 
>> Mobile Web Best Practices Working Group 
>> <http://www.w3.org/2005/MWI/BPWG/> as part of the Mobile Web 
>> Initiative <http://www.w3.org/2005/MWI/Activity> . Please send 
>> comments on this document to the Working Group's public email list 
>> public-bpwg-pro@w3.org <mailto:public-bpwg-pro@w3.org>, a publicly 
>> archived mailing list 
>> <http://lists.w3.org/Archives/Public/public-bpwg-pro/> .
>>
>> This document was produced under the 5 February 2004 W3C Patent Policy 
>> <http://www.w3.org/Consortium/Patent-Policy-20040205/> . W3C maintains 
>> a public list of patent disclosures 
>> <http://www.w3.org/2004/01/pp-impl/37584/status> made in connection 
>> with this document; that page also includes instructions for 
>> disclosing a patent. An individual who has actual knowledge of a 
>> patent which the individual believes contains Essential Claim(s) with 
>> respect to this specification must disclose the information in 
>> accordance with section 6 of the W3C Patent Policy 
>> <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure>.
>>
>> Publication as an Editor's 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. Other documents may 
>> supersede this document.
>>
>>
>>     Table of Contents
>>
>> 1 Introduction <#Introducti>
>>
>> 1.1 Purpose <#Purpose>
>> 1.2 Relationship to mobileOK Basic Tests <#Relationsh>
>> 1.3 Scope <#Scope>
>> 1.4 Audience <#Audience>
>>
>> 2 Sampling <#Sampling>
>>
>> 2.1 Evaluation Scope <#Evaluation_Scope>
>> 2.2 Evaluation Structure <#Evaluation_Struc>
>>
>> 3 Evaluation Procedures <#Evaluation_proc>
>>
>> 3.1 Access Keys <#access_keys>
>> 3.2 Auto Refresh <#L11263>
>> 3.3 Avoid Free Text <#L48755>
>> 3.4 Background Image Readability <#Background>
>> 3.5 Balance <#L9472>
>> 3.6 Device Capabilities <#L16806>
>> 3.7 Central Meaning <#L20732>
>> 3.8 Suitable, Limited and Clarity <#Suitable>
>> 3.9 Content Format Preferred <#L45121>
>> 3.10 Control Labeling and Position <#L68079>
>> 3.11 Cookies <#L89263>
>> 3.12 Error Messages <#L103845>
>> 3.13 Fonts, Style Sheet Use and Style Sheet Support <#L113158>
>> 3.14 Graphics for Spacing <#L120371>
>> 3.15 Link Target ID <#L124791>
>> 3.16 Minimize Keystrokes <#L134272>
>> 3.17 Navbar <#L138133>
>> 3.18 Navigation <#L145858>
>> 3.19 Non-text Alternatives <#L146017>
>> 3.20 Objects or Scripts <#L151530>
>> 3.21 Page Size Usable <#L154665>
>> 3.22 Page Title <#L160777>
>> 3.23 Provide Defaults <#L174697>
>> 3.24 Scrolling <#L179567>
>> 3.25 Structure <#L184555>
>> 3.26 Style Sheets Size <#L187879>
>> 3.27 Tab Order <#L194701>
>> 3.28 Tables Layout <#L201556>
>> 3.29 Tables Support <#L204960>
>> 3.30 URIs <#L208631>
>> 3.31 Use of Color <#L212226>
>>
>>
>>       Appendices
>>
>> A References <#References>
>>
>> ------------------------------------------------------------------------
>>
>>
>>     1 Introduction
>>
>>
>>       1.1 Purpose
>>
>> This document builds on Mobile Web Best Practices 1.0 [MWBP <#MWBP>] 
>> and helps content providers to create content suitable for delivery to 
>> mobile devices. It does this by providing additional evaluations for 
>> content and by interpreting and clarifying some Best Practice statements.
>>
>>
>>       1.2 Relationship to mobileOK Basic Tests
>>
>> mobileOK Basic Tests 1.0 [MOKTESTS <#MOKTESTS>] also builds on Mobile 
>> Web Best Practices 1.0 [MWBP <#MWBP>] and describes machine-executable 
>> tests for some of the Best Practice statements. Performing those tests 
>> assesses whether a Web site is capable of delivering content to the 
>> hypothetical basic mobile device called the "Default Delivery Context" 
>> (DDC <http://www.w3.org/TR/mobile-bp/#ddc>). It does not assess the 
>> capability of a Web site to deliver alternative representations that 
>> take advantage of capabilities that exceed those of the DDC 
>> <http://www.w3.org/TR/mobile-bp/#ddc> when accessed from such devices. 
>> This addendum provides an additional set of evaluations, some 
>> machine-testable, that go beyond the objectives of mobileOK Basic 
>> Tests in that they are not applicable solely to the DDC 
>> <http://www.w3.org/TR/mobile-bp/#ddc>.
>>
>>
>>       1.3 Scope
>>
>> The scope of this document is a commentary on Mobile Web Best 
>> Practices 1.0 [MWBP <#MWBP>] and mobileOK Basic Tests 1.0 [MOKTESTS 
>> <#MOKTESTS>].
>>
>>
>>       1.4 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, and with Mobile 
>> Web Best Practices and mobileOK Basic Tests.
>>
>>
>>     2 Sampling
>>
>>
>>       2.1 Evaluation Scope
>>
>> While most evaluations apply to single pages or or delivery units 
>> <http://www.w3.org/TR/di-gloss/#def-delivery-unit> [DIGLOSS 
>> <#DIGLOSS>], some, such as ACCESS_KEYS <#access_keys>, NAVIGATION 
>> <#L145858> and URIS <#L208631>, are tested across multiple pages.
>>
>>
>>       2.2 Evaluation Structure
>>
>> Where useful the following structure has been adhered to:
>>
>> *Related mobileOK Basic Test*
>>
>> A link to a related mobileOK Basic Test, where relevant.
>>
>> *Relevant Delivery Context Capabilities*
>>
>> Properties of the delivery context 
>> <http://www.w3.org/TR/di-gloss/#def-delivery-context> [DIGLOSS 
>> <#DIGLOSS>] that are referred to by the evaluation.
>>
>> You will need to use a Device Description Repository (DDR) 
>> <http://www.w3.org/TR/DDR-Simple-API/> [DDRSA <#DDRSA>] to find out 
>> which capabilities a given device possesses.
>> See as examples Device Atlas <http://deviceatlas.com/> and Morfeo 
>> <http://forge.morfeo-project.org/projects/ddr-ri>.
>>
>> *Interpretation of the Best Practice*
>>
>> Clarification of one or more aspects of the Best Practice to which the 
>> evaluation refers.
>>
>> *Evaluation Procedure*
>>
>> How to carry out the evaluation.
>>
>> *Examples*
>>
>> Explanatory material.
>>
>>
>>     3 Evaluation Procedures
>>
>> To satisfy the Testing <http://www.w3.org/TR/mobile-bp/#TESTING> Best 
>> Practice, the following evaluations should be carried out using a 
>> *range of real devices* as well as, or instead of, emulators.
>> Note that several tests require certain features of the device or 
>> browser to be absent or disabled if present.
>>
>>
>>       3.1 Access Keys <http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS>
>>
>> *Relevant Delivery Context Capability*
>>
>> Support for access keys, i.e. key presses that provide a short cut to 
>> activation of links in a page.
>>
>> *Interpretation of the Best Practice*
>>
>> Typically a "Web site" has common navigation links that apply to most, 
>> or all, pages in the site (a menu bar for example). Such navigation 
>> links should be associated with access keys and the keys assigned 
>> should be the same on all pages. Other frequently accessed links (such 
>> as navigation within a page) may also benefit from being associated 
>> with an access key.
>>
>> There is no standard way of a content provider indicating the 
>> availability of access keys to users of the site.
>>
>> Common techniques are:
>>
>>     * Link decoration (put the access key in brackets next to a link
>>       e.g. [1] Home).
>>     * Summary page.
>>     * Listing on a site map.
>>
>> Note that access keys are not supported by some user agents. 
>> Representations targeted at such user agents should not contain link 
>> decoration.  
>>
>> *Evaluation Procedure*
>>
>> Where there are elements that would benefit from quick access, 
>> particularly navigation links and form controls:
>>
>>     * Verify that access keys are assigned to navigation links present
>>       on all pages on the site.
>>     * Verify that access keys are used consistently for the same links.
>>     * Verify that the access keys are numeric, or if not, have been
>>       tailored for use on a specific target device.
>>     * Verify that the user can establish which access keys are
>>       assigned to links.
>>
>>
>>       3.2 Auto Refresh <http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH>
>>
>> *Related mobileOK Basic Test*
>>
>> AUTO_REFRESH 
>> <http://www.w3.org/TR/mobileOK-basic10-tests/#AUTO_REFRESH> and 
>> REDIRECTION <http://www.w3.org/TR/mobileOK-basic10-tests/#AUTO_REFRESH>
>>
>> *Evaluation Procedure*
>>
>> Verify that pages that use automatic refresh (e.g. as highlighted by a 
>> mobileOK evaluation) contain a link to a non-refreshing version.
>>
>>
>>       3.3 Avoid Free Text
>>       <http://www.w3.org/TR/mobile-bp/#AVOID_FREE_TEXT>
>>
>> *Relevant Delivery Context Capabilities*
>>
>>     * Maximum size of a select list.
>>     * Availability of an Alpha-Numeric Keyboard.
>>
>> *Evaluation Procedure *
>>
>> Assess whether free-text input fields
>>
>> |<input type="text">, <input type="password">, <textarea>|
>>
>> would provide a more usable experience if replaced by a series of 
>> radio buttons, checkboxes or a select menu (where the number of 
>> choices is limited so as to be appropriate to the capabilities and 
>> ergonomics of the device).
>>
>> *Examples *
>>
>>     * Replacement of text entry with selection:
>>           o Selection ZIP/Post codes from a list, perhaps within a
>>             limited geographical area or by progressive refinement
>>             based on previous selection.
>>           o 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.
>>
>>     * Use of radio buttons for limited choice selections such as
>>       (Yes/No) and (Small/Medium/Large).
>>
>>
>>       3.4 Background Image Readability
>>       <http://www.w3.org/TR/mobile-bp/#BACKGROUND_IMAGE_READABILITY>
>>       and Color Contrast <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST>
>>
>> *Relevant Delivery Context Capabilities*
>>
>>     * Screen Contrast
>>     * Color Depth
>>     * Screen quality
>>     * Resolution
>>
>> *Interpretation of the Best Practice*
>>
>> The use of colored, patterned or photographic background images can 
>> make text hard to read both because of reduced device screen contrast 
>> and because of the context of use, in bright sunlight for example, 
>> reducing the perceived contrast.
>>
>> *Evaluation Procedure *
>>
>> Verify that where background images are used contrast ratio between 
>> the overlying text and each color used in the background image is 
>> sufficient.
>>
>> *Examples*
>>
>> contrast image
>>
>> There are also a variety of color contrast measuring tools available 
>> online, such as:
>>
>>     * WCAG Technique G18
>>       <http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20071211/G18.html>
>>       (provides a formula as well as links to further tools) [WCAG20
>>       <#WCAG20>]
>>     * Color Contrast Check
>>       <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST>
>>     * CSS Analyzer <http://cssanalyzer.com/>
>>
>>
>>       3.5 Balance <http://www.w3.org/TR/mobile-bp/#BALANCE>
>>
>> *Relevant Delivery Context Capability *
>>
>> Type of scrolling and link navigation **
>>
>> *Interpretation of the Best Practice *
>>
>> Different devices provide a number of means of navigating within a page:
>>
>>     * Selection of each link in document order.
>>     * Scrolling independently of links.
>>     * Stylus or Finger Based.
>>
>> If there is a large number of links in the page, users of devices that 
>> can only navigate by successive selection of links will find it 
>> difficult to scroll the page and use links that are lower down.
>>
>> *Evaluation Procedure *
>>
>> Assess the number of links in the page. If the representation is 
>> targeted at devices that do not support navigation independently of 
>> the number of links in the page, verify that the page does not use 
>> more than 30 links. Other types of device and special purpose pages 
>> may warrant a larger number of links.
>>
>>
>>       3.6 Exploit Device Capabilities
>>       <http://www.w3.org/TR/mobile-bp/#CAPABILITIES>
>>
>> *Relevant Delivery Context Capabilities *
>>
>>     * Screen Width
>>     * Screen Height
>>     * Color Depth
>>     * Markup Language Support
>>     * Character Encoding Support
>>     * Image Format Support
>>     * CSS Support
>>     * Script and XHR Support
>>
>> For details see the DDC <http://www.w3.org/TR/mobile-bp/#ddc>.
>>
>> *Interpretation of the Best Practice*
>>
>> Unlike the DDC <http://www.w3.org/TR/mobile-bp/#ddc>, many real 
>> devices support Scripts, XML HTTP requests, DOM Capabilities, Cookies 
>> and advanced CSS support. Web sites that are designed to support a 
>> variety of different representations might target a particular 
>> demographic of users with certain classes of device or simply make 
>> significant efforts to give users the best possible experience. 
>> Browsing a simple, static Web site on an advanced device may be little 
>> more rewarding than attempting to browse one that assumes capabilities 
>> that are unavailable on the device used, thereby making the content 
>> inaccessible.
>>
>> There is no simple rule or single evaluation that will determine 
>> whether a content provider has exploited device capabilities. There 
>> will always be a balance between the cost of providing multiple 
>> representations versus the benefit of doing so. For this reason, we do 
>> not provide a formal evaluation procedure to test this aspect of Best 
>> Practice except to say that any evaluation necessarily requires the 
>> Web site to be accessed from a variety of different devices with 
>> different capabilities. However, we do offer some examples of the kind 
>> of informal evaluation that may be possible, depending on what type of 
>> content is being offered.
>>
>> *Examples *
>>
>>     * Where links lead to content that may not work on less-capable
>>       devices, e.g. links to video, the user should be warned. Such
>>       warnings should not appear when the content is delivered to a
>>       target device known to support  the feature (see also 3.8
>>       Suitable, Limited and Clarity <#Suitable>, below).
>>     * The representation should not be unnecessarily limited to 120
>>       pixels wide for devices that have wider screens.
>>     * 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 content or state
>>       of a controls based on the input already supplied.
>>     * Enhancements, such as JavaScript and advanced CSS, must fail
>>       gracefully  - i.e. where such features are used, the lack of
>>       support on less sophisticated devices must not prevent access or
>>       limit functionality.
>>
>>
>>       3.7 Central Meaning
>>       <http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING>
>>
>> *Interpretation of the Best Practice *
>>
>> When accessing a page on a mobile device, the primary content should 
>> be visible. This means that the well-established layout for desktop 
>> devices, with navigation along the top and/or side of the page, is 
>> usually inappropriate.
>>
>> *Evaluation Procedure *
>>
>> Verify that the main content of the web page is visible without 
>> scrolling. This is usually content that is unique to the page and does 
>> not repeat across several pages
>>
>>
>>       3.8 Suitable <http://www.w3.org/TR/mobile-bp/#SUITABLE>, Limited
>>       <http://www.w3.org/TR/mobile-bp/#LIMITED> and Clarity
>>       <http://www.w3.org/TR/mobile-bp/#CLARITY>
>>
>> *Interpretation of the Best Practice*
>>
>> Informational content should be provided in a manner suitable for 
>> access on mobile, i.e. with an eye to quick assimilation by the user, 
>> rather than in a verbose style.
>>
>> *Evaluation Procedure *
>>
>>     * Verify that informational content is characterized by a brief
>>       writing style using features such as headings and lists.
>>     * Verify that a user can see skip through the content if so
>>       desired to reach the particular information they seek.
>>     * Verify that any more detailed information that is provided comes
>>       after the introductory paragraph(s).
>>     * Verify that the text is generally written in short sentences
>>       without unnecessary sub-clauses.
>>     * Verify that unfamiliar terms are not used (except technical
>>       terms relevant to the subject matter).
>>
>> *Examples*
>>
>>     * News stories are typically 'front-loaded' with key information
>>       (who, what, why, when) provided in the headline and in the
>>       opening sentences.
>>     * Event information should be in the form Venue: village hall;
>>       time: 6pm; Refreshments available; rather than the more verbose:
>>       "The meeting will begin at 6pm in the village hall where
>>       refreshments will be available."
>>    *
>>       Non-mechanical gardening implements are referred to as a spade.
>>     * For English language pages, the Gunning Fog test
>>       <http://www.usingenglish.com/glossary/fog-index.html> can give
>>       an indication of complexity. A level of roughly 7 or 8 would be
>>       ideal.
>>     * Content may be suitable in a controlled environment, with logon
>>       for entry, for example for retrieval of large medical scans on
>>       mobile devices.
>>
>>
>>       3.9 Content Format Preferred
>>       <http://www.w3.org/TR/mobile-bp/#CONTENT_FORMAT_PREFERRED>
>>
>> *Related mobileOK Basic Test*
>>
>> CONTENT FORMAT SUPPORT 
>> <http://www.w3.org/TR/mobileOK-basic10-tests/#CONTENT_FORMAT_SUPPORT>
>>
>> *Interpretation of the Best Practice *
>>
>> If a device supports one format better than another, it is preferable 
>> to deliver content in the better-supported format if possible.
>>
>> *Evaluation Procedure*
>>
>>     * Request the content simulating a device with a preference for a
>>       particular format.
>>     * Repeat the request simulating a device that has a preference for
>>       a different format.
>>     * Verify that the appropriate alternative format has been
>>       delivered in both cases.
>>
>> *Examples*
>>
>>     * PNG images may display better than GIF.
>>     * Support for Shift-JIS character encoding may be better than for
>>       UTF-8.
>>
>>
>>       3.10 Control Labeling
>>       <http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING> and Position
>>       <http://www.w3.org/TR/mobile-bp/#POSITION>
>>
>> *Interpretation of the Best Practice*
>>
>> It is dangerous to assume that the same layout will be presented to 
>> all users of mobile devices. It is important therefore to ensure that 
>> |<input>| elements are correctly labeled so that the association 
>> between bel|<label>| and |<input>| element is retained even if the 
>> layout is changed.
>>
>> For a detailed description of labels and form controls, the reader may 
>> also refer to Techniques for WCAG 2.0 [TWCAG <#TWCAG>], specifically 
>> to section H44: Using label elements to associate text labels with 
>> form controls 
>> <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H44> from some 
>> examples have been.
>>
>> *Evaluation Procedure *
>>
>>    1. Verify that there are |<label>| elements, if user-visible
>>       |<input>| elements are used.
>>    2. Verify that
>>           * either the |for| attribute of the |<label>| element is
>>             present and corresponds to the |id| attribute of a form
>>             control.
>>           * or that the |<label>| element contains the form control
>>             for which it is a label.
>>           * doing both of these is also acceptable.
>>    3. Verify that the label describes the purpose of the form control.
>>    4. Verify that labels and |<input>| elements are visually
>>       associated with and without CSS support.
>>
>> *Examples*
>>
>>     * A label which requests a person's name but is associated with a
>>       birth date field presented as drop down boxes, fails step 3.
>>           o Bad example: |<label>|Your name |<input type="date"/></label>|
>>     * The for attribute and corresponding id are meaningless except
>>       that they must match:
>>           o Good example: |<label for="firstname">|First
>>             name:|</label><input type="text" name="firstname"
>>             id="firstname" />|
>>
>>
>>       3.11 Cookies <http://www.w3.org/TR/mobile-bp/#COOKIES>
>>
>> *Relevant Delivery Context Capabilities  *
>>
>> Device can accept cookies and the network is transparent to cookies
>>
>> *Evaluation Procedure *
>>
>>    1. Identify the main functionality of the site that is important
>>       for the user and may rely on state.
>>    2. Evaluate the functionality with cookies enabled.
>>    3. Disable support for cookies. Evaluate the functionality and
>>       compare with that evaluated in 2.
>>
>> *Examples *
>>
>> A site that requires a user to login might store that login in a 
>> cookie to save the user typing in their credentials each time they 
>> visit. If cookies are unavailable, an acceptable degradation would 
>> mean that the user was prompted for a login each time they visited 
>> that page, but would browse the site without further logins from then 
>> on. A poor (and unacceptable) cookie-less degradation would render a 
>> site useless by always checking for a non-existent cookie and so not 
>> letting the user past the login page.
>>
>>
>>       3.12 Error Messages
>>       <http://www.w3.org/TR/mobile-bp/#ERROR_MESSAGES>
>>
>> *Evaluation Procedure *
>>
>>    1. Provoke a server-side error. For example: request a URL known
>>       not to correspond to any endpoint on the site.
>>    2. Examine the content of the error page.
>>       It should:
>>
>>     * Explain in non-technical language the error which has occurred.
>>     * Be suitable for the DDC <http://www.w3.org/TR/mobile-bp/#ddc>,
>>       at a minimum, (i.e. 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.
>>
>>
>>       3.13 Fonts <http://www.w3.org/TR/mobile-bp/#FONTS>, Style Sheets
>>       Use <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_USE> and Style
>>       Sheets Support
>>       <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SUPPORT>
>>
>> *Relevant Delivery Context Capabilities*
>>
>>     * Style sheets support
>>     * Font availability
>>     * Font size
>>     * Font effects
>>
>> *Interpretation of the Best Practices*
>>
>> Although the overwhelming majority of devices have support for CSS, 
>> such support is not uniform. CSS is designed to control presentation 
>> but it should not be used to convey meaning - that is the job of the 
>> markup. 
>>
>> *Evaluation Procedure*
>>
>>     * Verify that content is readable and intelligible with style
>>       sheets disabled.
>>     * Assess the difference between the appearance of the content with
>>       CSS enabled and disabled and verify that this does not alter the
>>       meaning.
>>     * ||Verify that structural markup is used such as |<strong>|,
>>       |<em>| //and |<q>| (rather than |<b>| or |<i> |which, although
>>       HTML tags instead of CSS, are presentational in nature).||
>>
>>
>>       3.14 Graphics for Spacing
>>       <http://www.w3.org/TR/mobile-bp/#GRAPHICS_FOR_SPACING>
>>
>> *Interpretation of the Best Practice*
>>
>> The correct way to control presentation on a Web page is to use CSS. 
>> Using graphics to achieve positioning and spacing effects adds an 
>> unnecessary overhead to the page.
>>
>> *Evaluation Procedure*
>>
>>    1. Verify that the content complies with GRAPHICS_FOR_SPACING
>>       MobileOK Basic Test
>>       <http://www.w3.org/TR/mobileOK-basic10-tests/#GRAPHICS_FOR_SPACING>
>>       [MOKTESTS <#MOKTESTS>].
>>    2. View all images in a page, for example in a separate list of
>>       images, or by outlining them. For XHTML these will usually be
>>       included using the |<img>| element.
>>    3. Ignoring images that are part of the page's graphic design, such
>>       as rounded corners, determine whether any of the images do not
>>       convey information and are used for purely for spacing.
>>
>> *Examples*
>>
>>     * A 1 pixel square image used to separate other content is
>>       unacceptable.
>>     * A small image with the same color as the surrounding content is
>>       unacceptable.
>>     * Using images to indent text, such as the beginning of a
>>       paragraph, is unacceptable.
>>
>>
>>       3.15 Link Target ID <http://www.w3.org/TR/mobile-bp/#LINK_TARGET_ID>
>>
>> *Evaluation Procedure *
>>
>>    1. Verify that each link in the text is described by attributes as
>>       follows:
>>           * If the target content is in a language different to that
>>             of the tested content, it should be correctly marked with
>>             the |hreflang| attribute.
>>           * If it is in a format other than that of the tested
>>             content, it should be correctly described by the |type|
>>             attribute.
>>           * If it uses a character encoding different to that of the
>>             tested content, it should be described by the |charset|
>>             attribute.
>>    2. Verify that the link text (including alternative text for any
>>       non-text elements) clearly describes the information obtained
>>       when activating the element.
>>    3. Select elements pairwise. Verify 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.
>>
>> (See UWEM 1.0 13.1 
>> <http://www.wabcluster.org/uwem/tests/#guideline-13> for more details)
>>
>> *Examples*
>>
>>     * Links with only the text "Click here" are unacceptable.
>>     * Multiple links in same page with same text or content but
>>       pointing to different things are unacceptable.
>>     * Links from an HTML page to a large video file that does not
>>       mention format or size are unacceptable.
>>     * Links to content in a language different to that of the current
>>       page are unacceptable.
>>
>>
>>       3.16 Minimize Keystrokes
>>       <http://www.w3.org/TR/mobile-bp/#MINIMIZE_KEYSTROKES>
>>
>> *Relevant Delivery Context Capabilities *
>>
>> Input mode
>>
>> *Evaluation Procedure*
>>
>> This evaluation is covered by AVOID_FREE_TEXT <#L48755>, URIS 
>> <#L208631>, CENTRAL_MEANING <#L20732> and PROVIDE_DEFAULTS <#L174697>. 
>> [MWBP <#MWBP>]
>>
>>
>>       3.17 Navbar <http://www.w3.org/TR/mobile-bp/#NAVBAR>
>>
>> *Relevant Delivery Context Capabilities*
>>
>> Screen width
>>
>> *Evaluation Procedure*
>>
>>     * Verify that there are basic navigational elements located above
>>       the rest of the content.
>>     * Verify that all navigational elements fit on a single line in
>>       the DDC <http://www.w3.org/TR/mobile-bp/#ddc>.
>>     * Verify that, upon loading the page, enough of the main content
>>       is visible without scrolling.
>>
>> *Examples*
>>
>> A navigation bar above the main content consisting of only: Home, 
>> Up,Down, Site map & Search, or similarly limited options, would be 
>> acceptable.
>>
>>
>>       3.18 Navigation <http://www.w3.org/TR/mobile-bp/#NAVIGATION>
>>
>> *Evaluation Procedure*
>>
>>    1. 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.
>>    2. Verify that navigation mechanisms are similar throughout pages
>>       of the sample, other than for changes that are necessary within
>>       the context of a given page.
>>
>> *Examples*
>>
>>     * A well designed site will offer the same navigation menu(s) on
>>       all pages with the only changes being in the presentation as it
>>       affects ths current page, e.g. the link to the current page may
>>       be shown differently or elided. 
>>     * Bad examples include:
>>           o A site navigation menu that is presented differently on
>>             different pages.
>>           o A site navigation menu that is present on some pages but
>>             not on the current page.
>>           o Inline links on other pages have a descriptive title but
>>             on the current page they do not.
>>
>>
>>       3.19 Non-text Alternatives
>>       <http://www.w3.org/TR/mobile-bp/#NON-TEXT_ALTERNATIVES>
>>
>> *Evaluation Procedure*
>>
>> Referring to Web Content Accessibility Guidelines (WCAG) 2.0 
>> <http://www.w3.org/TR/WCAG20/> [WCAG20 <#WCAG20>]
>>
>>     * http://www.w3.org/TR/WCAG10/#gl-provide-equivalents
>>     * http://www.w3.org/TR/WCAG20/#text-equiv
>>
>> Non-text elements include images, graphical representations of text 
>> (including symbols), image map regions, animations (e.g., animated 
>> GIFs), applets and programmatic objects, ASCII art, frames, scripts, 
>> images used as list bullets, spacers, graphical buttons, sounds 
>> (played with or without user interaction), stand-alone audio files, 
>> audio tracks of video, and video.
>>
>> Verify that content meets Basic Test NON_TEXT_ALTERNATIVES 
>> <http://www.w3.org/TR/mobileOK-basic10-tests/#NON_TEXT_ALTERNATIVES> 
>> [MOKTESTS <#MOKTESTS>]
>>
>>     * Verify that a text equivalent has been provided for every
>>       non-text element that, when presented to the user, conveys
>>       essentially the same function or purpose as auditory or visual
>>       content.
>>     * Content is "equivalent" to other content when both fulfill
>>       essentially the same function or purpose upon presentation to
>>       the user.
>>
>> *Examples*
>>
>>     * Good examples:
>>           o Null value (|alt=""|) for decorative images such as
>>             rounded corners in frame.
>>           o A text equivalent for an image of an upward arrow that
>>             links to a table of contents could be "Return to table of
>>             contents".
>>     * Bad examples:
>>           o An |alt| value that is the same as the filename.
>>           o |alt=" "| (space).
>>           o No |alt| attribute.
>>
>>
>>       3.20 Objects or Scripts
>>       <http://www.w3.org/TR/mobile-bp/#OBJECTS_OR_SCRIPT>
>>
>> *Evaluation Procedure*
>>
>> Verify that the document can be viewed or used, with objects or 
>> scripts inactive or removed, without any change in the function, or 
>> value of the content, of the page.
>>
>> *Examples*
>>
>> From Web Content Accessibility Guidelines 1.0 
>> <http://www.w3.org/TR/WAI-WEBCONTENT/> [WCAG10 <#WCAG10>], Guideline 
>> 6, Checkpoint 6.3 
>> <http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts>:
>>
>> Check that links that trigger scripts work when scripts are turned off 
>> or are not supported (e.g., do not use "javascript:" as the link 
>> target). If it is not possible to make the page usable without 
>> scripts, provide a text equivalent with the NOSCRIPT element, or use a 
>> server-side script instead of a client-side script, or provide an 
>> alternative accessible page as per checkpoint 11.4. 
>> <http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-alt-pages> 
>> Refer also to guideline 1 
>> <http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#gl-provide-equivalents>. 
>>
>>
>> With scripts turned off or when the page is accessed on a device that 
>> does not support scripts or objects:
>>
>>     * A given form can still be filled out and submitted.
>>     * Images are displayed and alternative content is shown.
>>
>>
>>       3.21 Page Size Usable
>>       <http://www.w3.org/TR/mobile-bp/#PAGE_SIZE_USABLE>
>>
>> *Relevant Delivery Context Capabilities*
>>
>>     * Bandwidth
>>     * CPU power
>>     * Screen size
>>
>> *Evaluation Procedure*
>>
>> Verify that a given web page contains contiguous content, which could 
>> technically and semantically be separated into individual pages, and 
>> exceeds 3 screen sizes in length without page break.
>>
>> *Examples*
>>
>>     * A long article that extends over 3 screens full without some
>>       type of page break should be broken up into pages.
>>     * Display of navigational information, requiring continuous
>>       movement through the map would pass, because additional maps are
>>       loaded as needed.
>>
>>
>>       3.22 Page Title <http://www.w3.org/TR/mobile-bp/#PAGE_TITLE>
>>
>> *Relevant Delivery Context Capabilities *
>>
>>     * Screen width **
>>
>> *Evaluation Procedure*
>>
>>     * Verify that the title thematically describes the main intent of
>>       the page content.
>>     * Verify that the title does not repeat unchanged across more than
>>       3 pages unless a continuous piece of text has been paginated.
>>     * Verify that the title is too long to display on a screen
>>       matching the Default Delivery Context.
>>
>> *Examples*
>>
>>     * A page with the primary purpose of offering ring tones alongside
>>       small textual items should have this reflected in the title.
>>     * A title such as "Main Portal" which is repeated across more than
>>       3 pages would have to have to be adapted on the pages in question.
>>     * Conversely a title of "Uncle Tom's Cabin" in an ebook page,
>>       across many pages, would be perfectly acceptable.
>>
>>
>>       3.23 Provide Defaults
>>       <http://www.w3.org/TR/mobile-bp/#PROVIDE_DEFAULTS>
>>
>> *Interpretation of the Best Practice*
>>
>> This section only applies to pages that call for user input in a form.
>>
>> *Evaluation Procedure*
>>
>> Submit the form without selecting any item. This will ensure that 
>> defaults, such as preselected values, will be used:
>>
>>     * Verify that the response is not an error page.
>>     * Verify that the response is not a page asking the user to fix
>>       some data.
>>     * Verify that the response is not the original page.
>>     * If there are |<text>| or |<textarea>| elements that include a
>>       default value telling the user what to enter, verify that these
>>       values do not have to be manually deleted in order for them not
>>       to be processed as user input.
>>
>> *Examples*
>>
>>     * A country list might preselect the country code of where the
>>       page or service is most relevant.
>>     * A ZIP code listing might have the local ZIP code preselected and
>>       surrounding ZIP codes at the top of the list.
>>     * A date field might have today's date filled in.
>>
>>
>>       3.24 Scrolling <http://www.w3.org/TR/mobile-bp/#SCROLLING>
>>
>> *Relevant Delivery Context Capabilities*
>>
>>     * Input mode
>>     * Screen size
>>
>> *Evaluation Procedure*
>>
>> If horizontal scrolling is necessary to view a page, for each element 
>> wider than screen size:
>>
>>     * Ensure the element is not decorative.
>>     * Ensure that the element requires the oversize display, i.e. it
>>       cannot reasonably be reduced in size or omitted altogether.
>>
>> *Examples*
>>
>>     * A map showing an entire trip, information which would be lost
>>       upon zoom, is acceptable.
>>     * A X-ray image, intended for a portable medical device where
>>       zooming out would loose vital detail of the image is acceptable.
>>
>>
>>       3.25 Structure <http://www.w3.org/TR/mobile-bp/#STRUCTURE>
>>
>> *Related mobileOK Basic Test*
>>
>> VALID MARK_UP 
>> <http://www.w3.org/TR/mobileOK-basic10-tests/#CONTENT_FORMAT_SUPPORT>
>>
>> *Interpretation of the Best Practice*
>>
>> The mobileOK test will ensure that markup is valid, however, it does 
>> not ensure that markup elements are used correctly, in terms of the 
>> semantics of the document, as opposed to being used to achieve 
>> presentational effects. 
>>
>> *Evaluation Procedure*
>>
>>     * Verify that headers are properly nested according to their level.
>>     * Verify that |<list>| elements are used to represent lists
>>       (ordered, unordered, or definition lists) and are not used for
>>       formatting effects.
>>     * Verify that |<header>| elements are used to represent headers
>>       and are not used for formatting effects.
>>     * Verify that all information, which is visually is shown as a
>>       group of related elements, uses the |<list>| element in the
>>       markup to provide that structure.
>>     * Verify that all information, which is visually is shown as a
>>       block of text, uses paragraph or <|blockquote>| elements in the
>>       markup rather than, for example, |<div>| elements containing
>>       multiple line breaks.
>>
>>
>>       3.26 Style Sheets Size
>>       <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SIZE>
>>
>> *Evaluation Procedure*
>>
>>     * Verify that style sheets do not contain more than 25% white space.
>>     * Verify that all style rules are used somewhere in the Web site.
>>
>>
>>       3.27 Tab Order <http://www.w3.org/TR/mobile-bp/#TAB_ORDER>
>>
>> *Evaluation Procedure*
>>
>> Verify that the tab order of links, form controls and objects follows 
>> a logical or thematic order.
>>
>> *Examples*
>>
>>     * If a user is required to enter their first name, last name,
>>       address and contact number, the tab order should not jump, for
>>       example, between the first name and the phone number and then
>>       back to the last name.
>>     * If a pizza ordering service offers a choice of toppings and
>>       bases, the tab order should not jump between those two
>>       categories when presenting the user with options.
>>     * If the Submit button, or Submit and Cancel buttons, are not the
>>       last item(s) in the form.
>>
>>
>>       3.28 Tables Layout <http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT>
>>
>> *Relevant Delivery Context Capabilities*
>>
>> Table support
>>
>> *Evaluation Procedure*
>>
>> Verify that tables used solely for layout cannot be replaced by use of 
>> CSS.
>>
>> *Examples*
>>
>> An image or text which is spaced and positioned with the aid of a 
>> table is not acceptable.
>>
>>
>>       3.29 Tables Support <http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT>
>>
>> *Relevant Delivery Context Capabilities*
>>
>> Table support
>>
>> *Evaluation Procedure*
>>
>> Verify that the |<table>| element is not found within the source code 
>> if the device does not support tables.
>>
>>
>>       3.30 URIs <http://www.w3.org/TR/mobile-bp/#URIS>
>>
>> *Evaluation Procedure*
>>
>>     * Verify that the entry Domain, including main and subdomain, can
>>       be called up with less than 20 multi-tap key presses on the device.
>>     * Ensure that the entry URI does not require a file extension as
>>       in .html Ensure that the entry URI does not require the www
>>       subdomain.
>>
>>
>>       3.31 Use of Color <http://www.w3.org/TR/mobile-bp/#USE_OF_COLOR>
>>
>> *Evaluation Procedure*
>>
>>     * Verify that , excluding hyperlinks, the page does not include
>>       any other blue or purple text.
>>     * Check if, when viewed on a monochrome screen, all content is
>>       still readable.
>>     * Verify that color is not used to represent information.
>>
>> *Examples*
>>
>>     * Red text may be used to convey error messages but the fact that
>>       it is an error message should be clear without color.
>>     * Telling the user that important information is highlighted in
>>       yellow is unacceptable.
>>
>>
>>     A References
>>
>> DDRSA
>>     W3C Device Description Repository Simple API, Jo Rabin, José
>>     Manuel Cantera Fonseca, Rotan Hanrahan, Ignacio Marín, Editors,
>>     W3C Recommendation, 05 December 2008 (see
>>     http://www.w3.org/TR/DDR-Simple-API/)
>> DIGLOSS
>>     Glossary of Terms for Device Independence, Rhys Lewis, W3C Working
>>     Draft 18 January 2005 (see http://www.w3.org/TR/di-gloss/) 
>> MOKTESTS
>>     W3C Mobile OK Basic Tests 1.0, Sean Owen, Jo Rabin, Editors, W3C
>>     Recommendation, 08 December 2008 (see
>>     http://www.w3.org/TR/mobileOK-basic10-tests/) 
>> MWBP
>>     W3C Mobile Web Best Practices 1.0, Jo Rabin, Charles
>>     McCathieNevile, Editors, W3C Recommendation, 29 July 2008 (see
>>     http://www.w3.org/TR/mobile-bp/)
>> TWCAG
>>     W3C Techniques for WCAG 2.0, Ben Caldwell, Michael Cooper, Loretta
>>     Guarino Reid, Gregg Vanderheiden, Editors, W3C Working Group Note,
>>     11 December 2008 (see http://www.w3.org/TR/WCAG20-TECHS/)
>> WCAG10
>>     W3C Web Content Accessibility Guidelines 1.0, Wendy Chisholm,
>>     Gregg Vanderheiden, Ian Jacobs, Editors, W3C Recommendation 5 May
>>     1999 (see http://www.w3.org/TR/WAI-WEBCONTENT/)
>> WCAG20
>>     W3C Web Content Accessibility Guidelines (WCAG) 2.0, Ben Caldwell,
>>     Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden, Editors,
>>     W3C Recommendation, 11 December 2008 (see
>>     http://www.w3.org/TR/WCAG20/)
>>
Received on Tuesday, 22 September 2009 08:35:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:02 UTC