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