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