- From: Scheppe, Kai-Dietrich <k.scheppe@telekom.de>
- Date: Fri, 28 Mar 2008 08:28:16 +0100
- To: "Francois Daoust" <fd@w3.org>
- Cc: "Mobile Web BP Pro list" <public-bpwg-pro@w3.org>
Hi Francois, Sorry for hiding that part :-) Keeping that name for now is fine, but we need to change the document it self. Also we should come up with some sort of versioning system. What do you think about my problems in uploading files? Am I just being stupid? -- Kai > -----Original Message----- > From: Francois Daoust [mailto:fd@w3.org] > Sent: Thursday, March 27, 2008 4:55 PM > To: Scheppe, Kai-Dietrich > Cc: Mobile Web BP Pro list > Subject: Re: New version of the document > > Kai, I apologize, I suddenly realize I missed the part where > I'm supposed to do something ;) > > That's done, see: > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/d > rafts/ED-mobileOK-pro10-tests-20080319 > > Note I sticked to "pro10" in the name as I think this is > mobileOK Pro "1.0", even if it's the second version of the > draft... I can change that easily if you find it more confusing. > > François. > > > > Scheppe, Kai-Dietrich wrote: > > <<ED-mobileOK-pro20-tests-20080319.html>> Hi, > > > > I know this is might late, but we'll be able to go through the > > document on the call. > > > > > > @Francois > > I am sorry to be such a nuiscance, but I was not able to > use Amaya to > > upload the file. I was told that even the document that I > was trying > > to open from there did not exist. > > Could you please upload this file for me? > > > > Thanks > > Kai > > > > > > > ---------------------------------------------------------------------- > > -- > > > > > > mobileOK Pro Tests Version 2 > > > > > > Group Working Draft 19 March 2008 > > > > This version: > > > > > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED > > -mobileOK-pro20-tests-20080319 > > Latest version: > > > > > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/la > > test > > > > Previous version: > > > > > <http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/E > > > D-mobileOK-pro10-tests-20080228>http://www.w3.org/2005/MWI/BPWG/Group/ > > TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228 > > Editor: > > Kai Scheppe, Deutsche Telekom AG > > Substantial contributions made by: > > Phil Archer, Family Online Safety Institute > > Dave Rooks, Segala > > Alan Chuter, Technosite > > Adam Connors, Google > > Jo Rabin, DotMobi > > > > Copyright > > <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> © > 2008 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 outlines a set of tests requiring human evaluation, > > based on the Mobile Web Best Practices 1.0 > > <http://www.w3.org/TR/mobile-bp/> document and the mobileOK Basic > > Tests <http://www.w3.org/TR/mobileOK-basic10-tests/> document, > > provided by the Mobile Web Initiative > <http://www.w3.org/Mobile/> Best > > Practices Working Group <http://www.w3.org/2005/MWI/BPWG/> > > > > > > Status of this Document > > > > *This document is an editors' copy that has no official standing.* > > > > /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 > > <http://www.w3.org/TR/> at http://www.w3.org/TR/./ > > > > Publication as a Group Working 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. > > > > This document has been 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>. > > > > > > Revision Description > > > > Second Editor's Draft > > > > Most tests from 4.1 through 4.12 have been substantially revised to > > improve repeatability. > > > > See [todo] <#todo> for a list of todos. > > > > > > Table of Contents > > > > 1Introduction <#introduction> > > 1.1 Purpose <#d0e104> > > 1.2 Scope <#d0e117> > > 1.3 Audience <#d0e124> > > > > 2 Test format <#Test_format> > > > > 3 Sampling scheme <#sampling> > > > > 4 Tests <#Tests> > > 4.1 Access Keys <#access_keys> > > 4.2 Auto Refresh <#auto_refresh> > > 4.3 Avoid Free Text <#avoid_free_text> > > 4.4 Background Image Readability <#background_image_readability> > > 4.5 Balance <#balance> > > 4.6 Device Capabilities <#device_capabilities> > > 4.7 Central Meaning <#central_meaning> > > 4.8 Limited <#limited> > > 4.9 Clarity <#clarity> > > 4.10 Color Contrast <#color_contrast> > > 4.11 Content Format Preferred <#content_format_preferred> > > 4.12 Control Labeling <#control_labeling> > > 4.13 Control Position <#control_position> > > 4.14 Cookies <#cookies> > > 4.15 Deficiencies <#deficiencies> > > 4.16 Error Messages <#error_messages> > > 4.17 Fonts <#fonts> > > 4.18 Graphics for Spacing <#graphics_spacing> > > 4.19 Link Target ID <#link_target_id> > > 4.20 Minimize Keystrokes <#minimize_keystrokes> > > 4.21 Navbar <#navbar> > > 4.22 Navigation <#navigation> > > 4.23 Non-text Alternatives <#non-text_alternatives> > > 4.24 Objects or Scripts <#objects_scripts> > > 4.25 Page Size Usable <#page_size_usable> > > 4.26 Page Title <#page_title> > > 4.27 Provide Defaults <#defaults> > > 4.28 Scrolling <#scrolling> > > 4.29 Structure <#structure> > > 4.30 Style Sheets Size <#style_sheets_size> > > 4.31 Style Sheet Support <#style_sheet_support> > > 4.32 Suitable <#suitable> > > 4.33 Tab Order <#tab_order> > > 4.34 Tables Layout <#tables_layout> > > 4.35 Tables Support <#tables_support> > > 4.36 Testing <#testing> > > 4.37 URIs <#uris> > > 4.38 Use of Color <#use_of_color> > > > > > > Appendices > > > > A To Do <#todo> (Non-Normative) > > B References <#refs> (Non-Normative) > > > > > ---------------------------------------------------------------------- > > -- > > > > > > 1 Introduction > > > > > > 1.1 Purpose > > > > The purpose of this document, despite its subjective nature, is to > > provide guidelines to content producers on how to go beyond > mobileOK > > Basic and make the claim of having achieved mobileOK Pro, > by following > > the guidelines laid out in this document. > > mobileOK Best Practices <http://www.w3.org/TR/mobile-bp/> > is a set of > > guidelines which are partially testable via the mobileOK > Basic Tests > > Checker <http://validator.w3.org/mobile/>, a tool for > automated tests > > of a subset of Best Practices. > > > > mobileOK Pro then provides a set of guidelines that fill > the gaps left > > by the limitations of automated tests and thus completes the set of > > Best Practices. > > > > > > 1.2 Scope > > > > The scope of this document is limited to the mobileOK Best > Practices, > > the mobileOK Basic Tests resulting from those best > practices and the > > difference between the two. > > > > > > 1.3 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. > Readers are not > > expected to have a background in mobile-specific technologies. > > > > > > 2 Test format > > > > * Provide a link to the actual Best Practice > > * Provide a statement about what this test does not cover > > * Provide a statement, if applicable, which differences > to mobileOK > > Basic Tests are addressed in this mobileOK Pro test, > with a link a > > to the basic test in question. > > * Provide pseudo code that outlines the test itself > > Here each test or question needs to be answered separately. > > * Examples > > Prose examples of what we are talking about > > * Pass/Fail/Warn > > o Pass - as default you pass the test > > o Fail - if you explicitly fail one of the tests > you fail the > > whole test > > o Warn - does not fail but provides information to the > > author/provider on what to do better > > > > > > 2.1 Test template > > > > This section will be removed prior to publication > > > > > > x.x Name <http://www.w3.org/TR/mobile-bp/#NAME> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > None > > > > [Pass] > > > > [Warn] > > > > [Fail] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 3 Sampling > > > > This still needs reworking by Alan > > > > Say something about the sampling scheme. > > For example, use the UWEM scheme > (http://www.wabcluster.org/uwem1_2/) > > which is applicable. Some tests assume a defined sample scope to > > carryout the test (for example, NAVIGATION). > > > > > > 4 Tests > > > > > > 4.1 Access Keys <http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Interpretation of the Best Practice: > > > > This test applies to primary navigation links that occur across all > > pages within a given web space which is itself defined by > the presence > > of those navigation links. Such navigation links should be > associated > > with access keys. Furthermore, the access key assignment MUST be > > identical for those links. > > > > Access keys may be indicated to end users in any of three ways > > > > * Link decoration > > * Summary page > > * Listing on a sitemap > > > > > > Pseudo code: > > > > Where there are elements, particularly navigation links and form > > controls, that would benefit from access keys: > > > > * If access keys are not assigned at least to the > primary navigation > > links found on all pages within a Web space defined by the > > presence of those links [FAIL] > > * If access keys for primary navigation links are not identical > > across all pages: [FAIL] > > * If access keys are not indicated in at least one of > the ways cited > > above: [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.2 Auto Refresh > <http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > The Basic test detects the presence of an automatic > refresh, the Pro > > test looks for a user option to prevent automatic refresh. > > > > > > Pseudo code: > > > > If the Basic Test results in a warning about auto refresh > and there is > > no link provided to another instance of the content which does not > > refresh [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.3 Avoid Free text > > <http://www.w3.org/TR/mobile-bp/#AVOID_FREE_TEXT> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the user is asked to fill in a form and if there is a > finite number > > of possible values that the user could enter and those > options are not > > presented either as a series of radio buttons, check boxes > or a select > > menu: [FAIL]. > > > > > > Examples: > > > > * Selecting ZIP/Post codes from a list, perhaps within a limited > > geographical area of interest or in a sequence of > steps where each > > list of options is dependent on the previous data entered > > * 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 > > * Having to enter text for words like 'Yes' and 'No' is > a clear FAIL. > > > > > > Open issues: > > > > None > > > > > > 4.4 Background Image readability > > <http://www.w3.org/TR/mobile-bp/#BACKGROUND_IMAGE_READABILITY> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests, but it is worth > > noting that the DDC does support background images which > are part of CSS 1. > > > > > > Interpretation of the Best Practice > > > > The use of patterned or photographic background images > behind text is > > discouraged but not prohibited. > > > > > > Pseudo code: > > > > If background images are used, the COLOR CONTRAST test must > be passed > > for the ratio between the overlying text and each color used in the > > background image. Otherwise: [FAIL] > > > > > > Examples: > > > > * The Ishihara Test for Color Blindness, for example, shows > > background and text with patterning and insufficient > color contrast. > > * The contrast between this text and its black > background color is > > 5:1 > > > > > > Open issues: > > > > None > > > > > > 4.5 Balance <http://www.w3.org/TR/mobile-bp/#BALANCE> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None. > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the page contains more than 30 links: [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.6 Device Capabilities > > <http://www.w3.org/TR/mobile-bp/#CAPABILITIES> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > This test cannot cover all the possible capabilities that might be > > found in devices. > > Unlike the DDC, many real devices support scripting, XML HTTP > > requests, DOM capabilities, cookies and CSS including media queries. > > However, it is usually possible to detect a presentation that is > > artificially constrained by the limited and largely hypothetical > > Default Delivery Context. > > > > > > Interpretation of the Best Practice: > > > > Rather trying to find where device capabilities are not > utilized it is > > more conclusive to identify those instances where the content is > > wrongfully limited on a device more capable than the DDC. > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * For each property of the DDC (e.g. screen width), > identify some > > unadapted, original content that would exceed the > value given by > > that property of the DDC > > * Request content on a device more capable than the DDC for that > > particular property > > * If content is rendered according to the constraints > of the DDC: > > [FAIL] > > > > > > Examples: > > > > * Web sites that offer video streams should not offer > such content > > for the DDC, however, it should be offered to users of devices > > that do support video. > > * Presentation should adjust itself to the optimal > display for this > > device and not be unnecessarily limited to 120 pixels wide. > > * 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 > presentation or state > > of a control based on the input already supplied. > > > > > > Open issues: > > > > None > > > > > > 4.7 Central Meaning > > <http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > * Visual-only. > > * Does not attempt to evaluate the meaningfulness of the visible > > content (would be too subjective). > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Determine what is the main content of the page. This > is content > > that is unique to the page and does not repeat across > several pages. > > * If none of the main content of the web page is visible without > > scrolling: [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.8 Limited <http://www.w3.org/TR/mobile-bp/#LIMITED> > > > > > > Note to BPWG: > > > > Advise on the use of the type attribute on links to provide > > information in machine-readable format for future user agents. > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * The information contained in the link text must describe (e.g. > > contextual information, content type, file size) the > content that > > will be retrieved. If not, [FAIL]. > > * Content provided or linked to should be suitable for > the mobile > > context, unless provided in a controlled environment where its > > unsuitability is know a priori. > > > > > > Examples: > > > > * Content may be suitable in a controlled environment, > with logon > > for entry, for example for retrieval of large medical scans on > > mobile devices. > > > > > > Open issues: > > > > None > > > > > > 4.9 Clarity <http://www.w3.org/TR/mobile-bp/#CLARITY> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > This test is subjective and cannot be conclusive. It must therefore > > remain at a warning level to be informative. > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the text is, for the context, considered to be unnecessarily > > complex or verbose [WARN] > > > > > > Examples: > > > > * Consider the purpose of the page. If the purpose of > the page is to > > deliver a specific piece of information, that > information should > > be readily extracted without excessive scrolling or > scanning of text. > > * In the English language the Fogg test can give an > indication of > > complexity. A level of rough 7 or 8 would be ideal. For other > > languages this does not apply. > > > > > > Open issues: > > > > None > > > > > > 4.10 Color Contrast > > <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST> > > > > > > Note to BPWG: > > > > This test could well be machine testable as there are publically > > accessible applications which compare color values. > > > > > > Limitations of this test: > > > > This test is actually defined in > > > http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18, > > to which we refer here > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the contrast ratio is less than 5:1, according to > > > http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18 > > [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.11 Content Format Preferred > > <http://www.w3.org/TR/mobile-bp/#CONTENT_FORMAT_PREFERRED> > > > > > > Note to BPWG: > > > > This test is machine testable and we are not sure why is it not > > covered in the basic tests. The number of alternative > formats is small > > and could be searched for by issuing subsequent appropriate > requests. > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > 1. Determine which alternative formats are available. > > 2. If no alternative formats are available [PASS], otherwise > > 3. Change the quality factors of the accept headers to express a > > preference for an available alternative format > > 4. If the content which is delivered does not reflect > that change: > > [FAIL] > > > > > > Examples: > > > > Typical changes to preferences such as the following should be > > reflected > > accordingly: > > > > * GIF and JPEG > > * Character encoding > > * Markup language > > > > > > Open issues: > > > > This, I believe, is not an issue since content negotiation, > which is > > called for here, only works if no extension is listed. > > > > Is the type explicit in, for example, links, by filename (<img > > src="imagefile.png"), or is it by content negotiation (<img > > src="imagefile" with no filename extension.)? > > > > > > 4.12 Control Labeling > > <http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING> > > > > > > Note to BPWG: > > > > This test is machine testable > > > > > > Limitations of this test: > > > > None > > > > > > Interpretation of the Best Practice: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * If there are user-visible form elements and no label > elements: [FAIL] > > * If the |for| attribute is not defined and the form > control is not > > contained within the label element: [FAIL] > > * If the |for| attribute is present but does not > correspond to the > > |id| attribute of a form control: [FAIL] > > * If the label does not describe the purpose of the > form control: > > [FAIL] > > > > > > Examples: > > > > * A label which requests a persons name but is associated with a > > birth date field, fails. > > > > > > Open issues: > > > > * Are there ever presentational / layout reasons why > having a form > > label isn't appropriate? e.g. if there's only one > form element and > > the meaning of that element is given by the context > of the page? > > * Are empty labels "" acceptable, if the meaning of the field is > > made clear in some other fashion? > > > > > > 4.13 Control position > > <http://www.w3.org/TR/mobile-bp/#CONTROL_POSITION> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > * The aspect of properly aligning with a form control has been > > limited to mean "in the vicinity", as the positioning > to the left > > or below an input field is not the only way to use them. > > * The DDC supports only CSS 1 > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * If the label cannot be clearly associated with a form > control [FAIL] > > * If the association is only achieved by means of > positional CSS > > [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.14 Cookies <http://www.w3.org/TR/mobile-bp/#COOKIES> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the content or function cannot be accessed without cookies [FAIL] > > > > > > 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. An poor (and > > unacceptable) cookieless degradation would render a site useless by > > always checking for a non-existent cookie and so not > letting the user > > past the login page. > > > > > > Open issues: > > > > None > > > > > > 4.15 Deficiencies > <http://www.w3.org/TR/mobile-bp/#DEFICIENCIES> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > This test cannot test all existing deficiencies of devices. > Rather the > > test limited to the author/provider being aware of common > deficiencies > > and do something about those. This test is not intended to > test pixel > > perfect rendering across devices, but rather focuses on usability > > across devices. > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If there are common deficiencies of devices, which impinge > > significantly on usability of the content being offered, > measures must > > be taken to work around those deficiencies. If not [FAIL] > > > > > > Examples: > > > > Some devices which render tables badly will wrap columns by > default, > > if the meaning of the page is dependent on layout which does not > > render well on these sorts of devices then an alternative rendering > > should be used when that user-agent is detected. > > > > > > Open issues: > > > > None > > > > > > 4.16 Error Messages > > <http://www.w3.org/TR/mobile-bp/#ERROR_MESSAGES> > > > > > > Note to BPWG: > > > > An external tester can not know what errors generate error > messages, > > or what languages are available. > > > > That is not quite true. At least a 404 is easy to produce and > > available languages can be inquired. > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > Provoke a server-side error. > > > > * For example: Request a URL known not to correspond to > any endpoint > > on the site. > > * [others] > > > > 2. Examine the content of the error page. All the following must be > > true, if not [FAIL]. > > > > It must: > > > > * Explain in non-technical language the error which has > occurred. > > * Be suitable for the DDC, at a minimum, (ie 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. > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > The mechanism by which a context specific error message can be > > displayed in not clear. For example, how to display a French error > > message if the user was in the French section of the site. > > > > > > 4.17 Fonts <http://www.w3.org/TR/mobile-bp/#FONTS> > > > > > > Note to BPWG: > > > > The intent of the BP stated in 5.4.16.1 is that meaning should be > > conveyed without relying on font-related styling. However, the > > "Machine Test" under 5.4.16.2 fails on any presence of any > > font-related styling (whether it conveys meaniong or not). > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > 1. Check for presence of font-related styling, by means > of the font > > element, or the bold, italic or underline elements, or CSS. > > 2. Examine the content with CSS enabled and disabled. If > the meaning > > is significantly different [FAIL] > > 3. Examine any font-related elements present and the > effect they have > > on the meaning of the content. If they are used to > convey meaning > > significantly, [FAIL] > > > > > > Examples: > > > > * Emphasis expressed using bold or underline. > > * Quotes that are indicated by italics rather than enclosed in > > quotation marks or quotation markup. > > > > > > Open issues: > > > > None > > > > > > 4.18 Graphics for Spacing > > <http://www.w3.org/TR/mobile-bp/#GRAPHICS_FOR_SPACING> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > This test does not rely on a particular graphics format > that are being > > evaluated. > > > > > > Differences to mobileOK Basic Tests: > > > > This BP is partially covered by the GRAPHICS_FOR_SPACING MobileOK > > basic Test > <http://www.w3.org/TR/mobileOK-basic10-tests/#GRAPHICS_FOR_SPACING>. > > > > > > Pseudo code: > > > > Does the content comply with GRAPHICS_FOR_SPACING MobileOK > Basic Test > > > <http://www.w3.org/TR/mobileOK-basic10-tests/#GRAPHICS_FOR_SPACING>? > > If not [FAIL]. > > > > View all images in a page, for example in a separate list > of images, > > or by outlining them. For XHTML these will be included > using the <img> > > element. > > Determine visually whether any of the images do not convey > information > > and are used for spacing. If they are [FAIL]. > > > > Note: Spacer images do not convey useful information. They are > > normally very small. > > > > > > Examples: > > > > * 1 pixel square image used to seperate other content. > > * A small image with the same colour as the surrounding content. > > * Single Pixel GIF Trick on Creating Killer Websites > > > > <http://www.killersites.com/killerSites/1-design/single_pixel.html> > > > > > > Open issues: > > > > Define unambiguously what is and is not a spacer image. > > > > > > 4.19 Link Target ID > > <http://www.w3.org/TR/mobile-bp/#LINK_TARGET_ID> > > > > > > Note to BPWG: > > > > The abbreviation "ID" included in the handle of the BP, is > confusing > > and suggests it involves the ID attribute. The test covers > the use of > > hreflang, type and charset attributes which are not > mentioned in the BP. > > > > > > Limitations of this test: > > > > This test only deals with the descriptive portion of a link > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > 1. Each link in the text is described by attributes as > follows. If > > not, [FAIL]. > > * If the target content is in a language > different to that of > > the tested content, it is correctly marked with hreflang > > attribute; > > * If it is in a format other than that of the > tested content, > > it is correctly described by the type attribute; > > * If it uses a character encoding different to that of the > > tested content, it is described by the charset > attribute. > > 2. Check that the link text (including alternative text for any > > non-text elements) clearly describes the effect of > activating the > > element. If not, [FAIL] > > 3. Select elements pairwise. Check 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. > If not, [FAIL]. > > > > (These liberally adapted from UWEM 1.0 13.1 > > <http://www.wabcluster.org/uwem/tests/#guideline-13>). > > > > > > Examples: > > > > * Link with only the text "Click here." > > * Multiple links in same page with same content but pointing to > > different things. > > * Link from an HTML page to a large video file that > does not mention > > format or size. > > * Link to content in a language different to that of > the current page. > > > > > > Open issues: > > > > Can contextual information can provide enough explanation > for a "click > > here" link? > > > > What is meant here is that there are instances were enough > information > > is provided in the preceeding or surrounding text that a > more detailed > > link description is not needed > > > > > > 4.20 Minimize Keystrokes > > <http://www.w3.org/TR/mobile-bp/#MINIMIZE_KEYSTROKES> > > > > This test is covered by tests for AVOID_FREE_TEXT > <#avoid_free_text>, > > URIS <#uris>, CENTRAL_MEANING <#central_meaning> and > PROVIDE_DEFAULTS > > <#defaults>. > > > > > > 4.21 Navbar <http://www.w3.org/TR/mobile-bp/#NAVBAR> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Is there basic navigation on the page before the > other content? If > > not [FAIL]. > > * Does all the navigation detected in [1] fit on a > single line (in > > DDC)? If not [FAIL]. > > * Is a some of the main content visible without scrolling > > (sufficient to get an idea of the rest of the > content)? If not > > [FAIL] > > > > > > Examples: > > > > Navigation bar consisting of only: Home; Up; Site map; Search... > > > > > > Open issues: > > > > * How much navigation is admissible? > > * Can it be quantified in terms of the number of links and the > > number of characters? > > > > > > 4.22 Navigation <http://www.w3.org/TR/mobile-bp/#NAVIGATION> > > > > > > Note to BPWG: > > > > There seems to be confusion in the MWBP document. The title > refers to > > "consistent navigation". However, the second paragraph discusses > > "Intelligent grouping" and the "How to do it" section suggests > > providing a drill-down list based on section headings, rather than > > about being consistent (it doesn't say use drill-down lists > > consistently). The latter is more relevant to [STRUCTURE] > than to this > > BP. What was the intent, consistent navigation across a > site or just > > good navigation in a page? This test assumes that > consistency is what must be tested. > > > > > > Limitations of this test: > > > > * Tester must be able to delimit what constitutes the > site. This is > > assumed to be the pages in the sample scope. > > * Test has to define what a navigation mechanism is. > > * It tests for consistency, not good navigation design. > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * 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. > > * If navigation mechanisms are different on different > pages of the > > sample other than in a way relevant to the difference > between the > > pages, [FAIL]. > > > > The word "sample" in the pseudo code was fitted with links > which were > > non-sensical. Are there samples missing or was some other > point being made? > > > > > > Examples: > > > > * A site navigation menu is present on all pages and > only changes > > the presentation of the section and the current page, [PASS] > > * A site navigation menu is present on all pages and changes > > structure and presentation of the links [FAIL]. > > * A site navigation menu is present on some pages but > is not on the > > current page [FAIL]. > > * A site navigation menu is present on two pages of the > sample but > > in a different place [FAIL]. > > * Inline links on other pages have a descriptive title > but on the > > current page they do not. > > > > > > Open issues: > > > > More examples needed. > > > > > > 4.23 Non-text alternatives > > <http://www.w3.org/TR/mobile-bp/#NON-TEXT_ALTERNATIVES> > > > > > > Note to BPWG: > > > > It is not made explicit in the BPs whether all non-text content is > > covered or only images included with the <img> element. > > > > > > Limitations of this test: > > > > This test deals with images only. Other non-text content is not > > mentioned explicitly in the Best Practices and is beyond > the scope of > > this test. Such content includes horizontal rules, form controls, > > audio, video, multimedia elements, embedded objects and frames. > > > > > > Differences to mobileOK Basic Tests: > > > > This test covers the meaning of textual alternatives. The mobileOK > > Basic test only covers the presence or absence of the alt > attribute, > > not its value. > > > > > > Pseudo code: > > > > If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [FAIL] > > > > For XHTML content if any of the following UWEM 1.0 tests > are not met, > > [FAIL]. > > > > * UWEM 1.0 Test 1.1_HTML_01 (note that this is same as > Basic test, > > included for completeness) > > * UWEM 1.0 Test 1.1_HTML_02 > > * UWEM 1.0 Test 1.1_HTML_03 > > * UWEM 1.0 Test 1.1_HTML_04 > > > > > > Examples: > > > > * Pass: Null value (alt="") for decorative images such > as rounded > > corners in frame > > * Fail: alt value same as filename > > * Fail: alt=" " (space) > > > > > > Open issues: > > > > None > > > > > > 4.24 Objects or scripts <http://www.w3.org/TR/mobile-bp/#NAME> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test covers the functionality of documents without objects or > > scripts, in addition to the mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the document cannot be viewed properly without objects > or scripts > > active or present [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.25 Page Size Usable > > <http://www.w3.org/TR/mobile-bp/#PAGE_SIZE_USABLE> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * If there is no apparent justification for exceeding 3 > screen sizes > > in length [FAIL] > > * If the pages displayed are so short that multiple requests are > > needed to display the full information and their > combined length > > does not exceed three screens [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.26 Page Title <http://www.w3.org/TR/mobile-bp/#NAME> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test covers the meaning of the title, in addition to > the existing > > mobileOK Basic Tests > > > > > > Pseudo code: > > > > * Does the title meaningfully describe the page > content? If not [FAIL] > > * Is the title too long to display on a screen matching > the Default > > Delivery Context? [WARN] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.27 Provide Defaults > > <http://www.w3.org/TR/mobile-bp/#PROVIDE_DEFAULTS> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test covers the usefulness of the preselection, in addition to > > the existing mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * If the preselection for all form elements is useful. > If not [FAIL] > > * If no preselection exists and could meaningfully be > added [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.28 Scrolling <http://www.w3.org/TR/mobile-bp/#SCROLLING> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > Is the usage of horizontal scrolling justified? If not [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.29 Structure <http://www.w3.org/TR/mobile-bp/#STRUCTURE> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Document structure must be represented using proper structural > > markup rather than formatting effects. If not [FAIL] > > * Where structural markup is used it should be used in > accordance > > with the specification, i.e. elements should be > properly nested > > according to their level. If not [FAIL] > > * If structural markup is being used improperly, e.g. > for formatting > > effect [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > It is not clear what structural markup is and which elements are > > included in this definition. > > > > > > 4.30 Style Sheets Size > > <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SIZE> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > There is no guidance on this parameter and a value was picked > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Are style sheets optimized? If not [FAIL] > > * Are the style sheets utilized properly? If not [FAIL] > > * Is a given style sheet appropriate in its size for the given > > content, keeping in mind chaching and loading effects? If not > > [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > * What is an optimized stylesheet? > > * It is not clear if there should be some upper limit > on style sheet > > use, for example as percentage of the total page size > and if there > > should be, what percentage that should be. > > > > > > 4.31 Style Sheet Support > > <http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SUPPORT> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If content is unreadable or unintelligible with stylesheets > disabled > > [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.32 Suitable <http://www.w3.org/TR/mobile-bp/#SUITABLE> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > Examine content to determine if, given the subject matter, it is > > appropriate in a mobile context. If not [FAIL] > > > > > > Examples: > > > > * a page showing Renaissance paintings in full size - FAIL > > * a page showing a listing of Renaissance Paintings > with thumb nails > > - PASS > > * a page offering downloads of Windows XP - FAIL > > * a full size x-ray image for in-field access by EMTs - PASS > > > > > > Open issues: > > > > None > > > > > > 4.33 Tab Order <http://www.w3.org/TR/mobile-bp/#TAB_ORDER> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > Is the tab order of links, form controls and objects disorganized, > > illogical or confusing? If not [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.34 Tables Layout > > <http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > In addition to the mobileOK Basic Tests, this test checks > usage for layout. > > > > > > Pseudo code: > > > > If tables are used in a fashion that could be achieved using CSS > > [FAIL] > > > > > > Examples: > > > > An image or text which are spaced and positioned with the aid of a > > table > > > > > > Open issues: > > > > CSS currently is itself deficient in that it does not support grid > > layout that auto adjusts vertically > > > > > > 4.35 Tables Support > > <http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT> > > > > > > Note to BPWG: > > > > We had originally asked why this test is not included in > basic tests, > > but the Open Issue below spells it out. How can it be > determined if a > > device supports tables? Just look it up in UAProf or can > the Checker > > do something here? > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > If the device does not support tables and the table element > is found > > within the source code [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > Is there a way to programatically determine if a device > supports tables? > > > > > > 4.36 Testing <http://www.w3.org/TR/mobile-bp/#TESTING> > > > > > > Note to BPWG: > > > > This BP gives no information about what is being tested, > which calls > > this BP into question as being useless. > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Has this content been tested with emulators? If not [FAIL] > > * Has this content been tested with actual devices? If > not [FAIL] > > > > I would also offer: Has this content been validated? If not > [FAIL] and > > Has this content been tested with the Checker > > <http://validator.w3.org/mobile/>? If not [FAIL] > > > > > > Examples: > > > > None > > > > > > Open issues: > > > > None > > > > > > 4.37 URIs <http://www.w3.org/TR/mobile-bp/#URIS> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Is the entry Domain, including main and subdomain, > less than 20 > > key presses on the device? If not [WARN] > > * Does the entry URI require a file extension as in > .html? If yes, > > [FAIL] > > * Does the entry URI require the subdomain www? If yes, [FAIL] > > > > > > Examples: > > > > Entry URIs should not include information such as author, > date, title. > > See "Cool URIs don't change <http://www.w3.org/Provider/Style/URI>" > > > > > > Open issues: > > > > It seems that at least the file extension and the subdomain > ought to > > be machine testable? > > > > > > 4.38 Use of color > <http://www.w3.org/TR/mobile-bp/#USE_OF_COLOR> > > > > > > Note to BPWG: > > > > None > > > > > > Limitations of this test: > > > > None > > > > > > Differences to mobileOK Basic Tests: > > > > This test does not exist in mobileOK Basic Tests. > > > > > > Pseudo code: > > > > * Excluding hyperlinks, does your site include any other blue or > > purple text? If yes, [WARN] > > * When viewed on a monocrome screen, is all content > still readable? > > If no, [FAIL] > > * Is color used to represent information? If yes, [FAIL] > > > > > > Examples: > > > > * Using red text to represent an error message > > * Using blue or purple text within the page as it makes > it harder to > > distinguish hyperlinks <http://www.example.org> > > * Telling the user that important information is highlighted in > > yellow > > > > > > Open issues: > > > > None > > > > > > A To Do (Non-Normative) > > > > Work needed on this draft: > > > > Section 3: Alan to rework the sampling part > > > > > > B References (Non-Normative) > > > > > http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual- > > audio-contrast7 > > > > http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G18 > > > > UWEM 1.0 13.1 <http://www.wabcluster.org/uwem/tests/#guideline-13> > > > > http://www.wabcluster.org/uwem1_2/ > > > > http://validator.w3.org/mobile/ > > > > Cool URIs don't change <http://www.w3.org/Provider/Style/URI> > > >
Received on Friday, 28 March 2008 07:29:11 UTC