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

Re: Reaching a final version of Addendum to BPWG

From: Francois Daoust <fd@w3.org>
Date: Tue, 22 Sep 2009 11:40:56 +0200
Message-ID: <4AB89BA8.8050906@w3.org>
To: Jo Rabin <jrabin@mtld.mobi>
CC: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>, Phil Archer <phila@w3.org>, Public MWBP <public-bpwg@w3.org>
A few typos:

- 2.1: "or or" => "or"

- 3.1: "There is no standard way of a content provider indicating the 
availability of access keys to users of the site." => shouldn't this be 
"There is no standard way for a content provider to indicate the 
availability of access keys to users of the site"?

- 3.10: "between bel<label> and <input> element" => "between <label> and 
<input> elements"

- 3.14: "MobileOK" => "mobileOK"

- 3.14: "for purely for spacing" => "purely for spacing"

- 3.18: "affects ths current" => "affects the current"

- 3.19: why do the URIs appear in the text instead of the guidelines 
themselves?

- 3.19: "meets Basic Test" => "meets mobileOK Basic Test"

Francois.


Jo Rabin wrote:
> 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 09:41:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:01 UTC