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

Re: Reaching a final version of Addendum to BPWG

From: Phil Archer <phila@w3.org>
Date: Tue, 22 Sep 2009 11:34:55 +0100
Message-ID: <4AB8A84F.7010305@w3.org>
To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
CC: Public MWBP <public-bpwg@w3.org>
Following further review of this document by Alan, François and myself, 
I have posted a slightly amended version at [1]. Note the 'a' before the 
file extension.

I commented on each of the points made by Alan and François in reply to 
their mails. The changes I made on my own were of a very similar nature 
- i.e. correcting typos (mostly my own). The biggest single change was 
in section 3.8 where

"Content may be suitable in a controlled environment, with logon for 
entry, for example for retrieval of large medical scans on mobile devices."

became

"Otherwise unsuitable content may be suitable in a controlled 
environment, perhaps with logon for entry. This might be relevant, for 
example, for the retrieval of large medical scans on mobile devices."

Other errors I spotted were picked up by others so I am reasonably 
confident now that, with several pairs of eyes having gone over this, 
the doc is now stable.

Doc has been validated and link checked.

Phil.

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

Francois Daoust wrote:
> 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/)
>>>>
>>
>>
> 
> 

-- 


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org
Received on Tuesday, 22 September 2009 10:35:38 UTC

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