- From: Francois Daoust <fd@w3.org>
- Date: Tue, 22 Sep 2009 11:40:56 +0200
- 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