- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Fri, 10 Oct 2008 21:16:26 +0100
- To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
- CC: public-bpwg@w3.org
Hi Kai Thanks for the sample re-writes. I think we have a little way to go to clarify the relationship between this document and other documents. I think that this is an Addendum to "Mobile Web Best Practices" and has little to do with "mobileOK Basic Tests". [Please can you adjust the title to reflect this] In my view it is supposed to supplement the "what to test" section of the Best Practices, e.g. http://www.w3.org/TR/mobile-bp/#d0e981 rather than http://www.w3.org/TR/mobileOK-basic10-tests/#AUTO_REFRESH Afaics there is no relationship at all with the checker so any reference to that needs to be removed. I very much appreciate your continued efforts on this, but it does seem that we need to work a bit more on what the point is of this document. Thanks Jo On 02/10/2008 14:15, Scheppe, Kai-Dietrich wrote: > <<ED-mobileOK-pro10-tests-20080731.htm>> > I had been actioned to reduce the test like tone in this document > somewhat. > > We had agreed that first I should just do a couple of examples that show > what I am thinking of. > > > In the this version of the document I have > > - modified the title > - modified some introductory texts > - modified the first two tests > > > Please comment on whether this fits the bill > > -- Kai > > > ------------------------------------------------------------------------ > > W3C </> > > > Addendum to mobileOK Best Practices > > > W3C Working Group Note 2 October 2008 > > This version: > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080731 > 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-20080610 > > Editor: > Kai Scheppe, Deutsche Telekom AG > Substantial contributions made by: > Phil Archer, Family Online Safety Institute > Alan Chuter, Technosite > Jo Rabin, DotMobi > Dave Rooks, Segala > > 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 evaluations 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/> > > This document is non-normative, but it is recommended to follow the > advice given here to further improve mobile friendly content. > > > 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 Working Group Note > <http://www.w3.org/2003/06/Process-20030618/tr.html#q71> 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 a Working Group Note 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 > > 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 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 improve their > content even beyond mobileOK Basic and make the claim of having achieved > mobileOK Pro, by following the guidelines laid out in this document. > > Due to the subjective nature of some of these guidelines no > deterministic tests can be performed. > > However, the content author is encouraged to adapt implementation of > these guidelines in a way best suited for the given situation. > > 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. > > This addendum 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 guideline does not cover > * Provide a statement, if applicable, which differences to mobileOK > Basic Tests are addressed in this guideline mobileOK Pro test, > with a link a to the basic test in question. > * Provide an evaluation test procedure that outlines the test itself > Here each test or question needs to be answered separately with > [PASS], [FAIL], [WARN] > * 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 > > > 3 Sampling > > > 3.1 Test Evaluation Scope > > While most tests evaluations apply to single pages or delivery units > <http://www.w3.org/TR/di-gloss/#def-delivery-unit>, some tests, such as > ACCESS_KEYS, NAVIGATION and URIS are tested across multiple pages. To > perform the tests evaluations correctly it is necessary to define the > scope of the evaluation. This may be expressed using URI patterns [or > groupings using POWDER <http://www.w3.org/TR/powder-grouping/>]." > > ------------------------------------------------------------------------ > > > 4 Tests > > > 4.1 Access Keys <http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS> > > > Note to BPWG: > > None > > > Limitations of this evaluation test: > > This test does not exist in mobileOK Basic Tests. > > It is independent of the Default Delivery Context (DDC) > <http://www.w3.org/TR/mobile-bp/#ddc> > > > 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 should 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 > > > Test Evaluation procedure: > > 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] > > Check if access keys have been assigned at least to the primary > navigation links found on all pages within a Web space defined by > the presence of those links > > * If access keys for primary navigation links are not identical > across all pages: [FAIL] > > Ensure that access keys for primary navigation links are identical > across all pages > > * If access keys are not indicated in at least one of the ways cited > above: [FAIL] > > Make sure to indicate which access are being used through at least > one of the methods above > > > 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 evaluation test: > > None > > > Interpretation of the Best Practice: > > None > > > Differences to mobileOK Basic Tests: > > The Basic test detects the presence of an automatic refresh. This , the > Pro test looks for a user option to prevent automatic refresh. > > > Test Evaluation procedure: > > 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] > > If the mobileOK checker warns about auto refresh make sure a link is > provided to a non-refreshing version of the original resource > > > 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. > > > Test procedure: > > 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. > > > Test procedure: > > 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. > > > Test procedure: > > 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. > > > Test procedure: > > * 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. > > > Test procedure: > > * 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. > > > Test procedure: > > * 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. > > > Test procedure: > > 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. > > > Test procedure: > > 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. > > > Test procedure: > > 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: > > None > > ------------------------------------------------------------------------ > > > 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. > > > Test procedure: > > * 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: > > The BP says labels ashould be positioned �properly� but gives no clue as > to what this means. It should either clarify what is intended or this BP > should be deprecated." > > > 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. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Test procedure: > > * If CSS is turned off and labels are not clearly associated with a > form control [FAIL] > * 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: > > See Gez Lemon's article on Label Positioning > <http://juicystudio.com/article/label-positioning.php>. The examples > should be in the BP document. > > > Open issues: > > None > > ------------------------------------------------------------------------ > > > 4.14 Cookies <http://www.w3.org/TR/mobile-bp/#COOKIES> > > > Note to BPWG: > > None > > > Limitations of this test: > > * The tester can not know with certainty all the functionality that > may rely on cookies. It is however possible to apply this check to > the main intent of the page > * The test does not deal with potential alternatives which may be used. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Test procedure: > > 1. Identify the main functionality of the site that is important for > the user and may rely on state. See examples. > 2. Evaluate the funcionality with cookies supported correctly. > 3. Disable cookies supported. Evaluate the funcionality and compare > with that evaluated in 2. > 4. 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. A 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. > > > Test procedure: > > 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. > > > Limitations of this test: > > None > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Test 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. 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. > > > Test procedure: > > 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] > 4. Check for the presence of the "face" element. If only one font has > been defined [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>. > > > Test procedure: > > 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. > > > Test procedure: > > 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. > > > Test procedure: > > * 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 the 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>. > * 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. > > > Test procedure: > > * 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]. > > > 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: > > The BP is actually in conflict here. The BP itself says "Provide a text > equivalent for every non-text element.". > Yet in "What to test" it says "Test for presence of alt attribute on > images and text content on objects." and elaborates to make sure that > objects are supported. > This is actually a subset of the BP itself and therefore in conflict. > Conversely, the BP states "every non-text element", which greatly > increases the scope of this test. > > Additionally, the BP does give a reference to the WCAG definition of > "non-text element", which is: > > Non-text Content [WCAG20] 2001-12-10 > See also Normative, Informative > Non-text content includes images, text in raster images, image map > regions, animations (e.g., animated GIFs), applets and programmatic > objects, ascii art, 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. > > Therefore it seems sensible to adapt the text given by Web Content > Accessibility Guidelines 1.0 > <http://www.w3.org/TR/WCAG10/#gl-provide-equivalents> and deal with all > the non-text elements > > > Limitations of this test: > > While not all non-text elements are supported by the DDC, tests should > fokus on the super set of elements provided by markup languages. > > > Interpretation of the Best Practice: > > The original intent of the proposed human test for this BP is linked to > the meaning of alternative text. While alt="this is alternative text" > fulfills the letter of the guideline in terms of usage of the > alternative text it leads such practice ad absurdum. This Test will > cover both the extension to other non-text elements and the meaning of > alt text. > > > Differences to mobileOK Basic Tests: > > This test covers the meaning of textual alternatives as well as > additional non-text elements. The mobileOK Basic test only covers the > presence or absence of the alt attribute for images and objects, not its > value. > > > Test procedure: > > Referring to http://www.w3.org/TR/WCAG10/#gl-provide-equivalents > > 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. > > If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [FAIL] > > * Provide a text equivalent for every non-text element that, when > presented to the user, conveys essentially the same function or > purpose as auditory or visual content. If not [FAIL] > * 'Content is "equivalent" to other content when both fulfill > essentially the same function or purpose upon presentation to the > user.' If not [FAIL] > > > Examples: > > * Pass: Null value (alt="") for decorative images such as rounded > corners in frame > * Pass: a text equivalent for an image of an upward arrow that links > to a table of contents could be "Go to table of contents". > * 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. > > > Test procedure: > > If, without objects or scripts active or present, the document cannot be > viewed or used such that the original intent of the web page is > fulfilled [FAIL] > > > Examples: > > From http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts > > * Ensure that links that trigger scripts work when scripts are > turned off or 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. Refer also to guideline 1. > * With scripts turned off or not supported or objects not supported > o a given form can still be filled out and submitted > o images are displayed and alternative text is shown > > > 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. > > > Test procedure: > > * If a given web page contains contiguous content, which could > techically and semantically be separated into individual pages, > and exceeds 3 screen sizes in length without page break [FAIL] > > > Examples: > > * a long article that extends over 3 screens full without some type > of page break would have to fail > * display of navigational information, requiring continuous movement > through the map would pass, because additional maps are loaded as > needed > > > 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 > > > Test procedure: > > * Does the title thematically describe the main intent of the page > content? If not [FAIL] > * Does the title repeat unchanged across more than 3 pages? If yes > [FAIL] > * Is the title too long to display on a screen matching the Default > Delivery Context [WARN] > > > Examples: > > * a page with the primary purpose of offering ring tones along side > 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 fail > * conversely a title of "Uncle Tom's Cabin" in an ebook page, across > many pages, would be perfectly acceptable > > > 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 > existing mobileOK Basic Tests > <http://www.w3.org/TR/mobileOK-basic10-tests/#PROVIDE_DEFAULTS> . > > > Test procedure: > > * Submit the form without selecting any item (left preselected values): > o If the response is an error page [FAIL] > o If the response is a page asking the user to fix some data > [FAIL] > o If the response is the original page [FAIL] > * If the form contains a text or textarea input element, with a > default value telling what to write there [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. > > > Test procedure: > > If testing a webpage with a device, and horizontal scrolling appears. > For each element wider than screen size: > > * if it is decorative [FAIL] > * if resizing it to screen size, it could be easily read and/or > described [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. > > > Test procedure: > > * If headers and list elements aren't properly nested according to > their level [FAIL] > * If lists elements aren't used to represent lists (ordered, > unordered, or definition lists) but formatting effects [FAIL] > * If headers elements aren't used to represent headers but > formatting effects [FAIL] > * If visually some information is shown as a group of related > elements, but there isn't any list element in the markup [FAIL] > * If visually some information is shown as a block of text, but > there isn't any paragraph or blockquote element in the markup [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. > > > Test procedure: > > * If whitespaces are more than 10% of CSS content [WARN] > * If whitespaces are more than 20% of CSS content [FAIL] > * If there are style properties that doesn't aply to the page [WARN] > * If there are at least two CSS properties that could be mixed in a > shorthand property [WARN] > * If there is at least one CSS RGB color property that could be > written shorthand way [WARN] > > > 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. > > Several tests refer to white space. White space has the same > definition in this document as in XML. For XML 1.0 [XML10] > <../temp/ED-mobileOK-pro10-tests-20080319.html#XML10> it is > defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being: > > |S ::= (#x20 | #x9 | #xD | #xA)+| i.e. the characters SP, TAB, CR > and LF. > > Could this be applied to a CSS? > > ------------------------------------------------------------------------ > > > 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. > > > Test procedure: > > 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: > > This test is clearly very subjective, therefore the threshhold for a > FAIL is very high. It must be beyond reasonable argument that the > presentation of the content is inapropriate for a mobile context. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Test procedure: > > Examine the content to determine if the presentation is very obviously > inappropriate in a mobile context. If so [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 large downloads of applications that mobile > devices do not support, such as professional image manipulation > software, desktop operating systems etc. - FAIL > * a full size x-ray image for in-field access by medical personnel - > 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. > > > Test procedure: > > Does the tab order of links, form controls and objects follow a logical > or thematic order? If not [FAIL] > > > Examples: > > * If a user is required to enter their first name, last name, > address and contact number, if the tab order jumps between, say, > the first name and the phone number and then back to the last name > [FAIL]. > * If a pizza ordering service offers a choice of toppings and bases, > if the tab order jumps between those two categories when > presenting the user with options [FAIL] > * If the Submit button, or Sumbit and Cancel buttons, are not the > last item(s) in the form [FAIL] > > > Open issues: > > None > > > 4.34 Tables Layout <http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT> > > > Note to BPWG: > > None > > > Limitations of this test: > > As of this writing, CSS is itself deficient in that it does not support > a grid layout that auto adjusts vertically. It must be recognized > therefore that some layouts can currently only be achieved using tables. > > > Differences to mobileOK Basic Tests: > > In addition to the mobileOK Basic Test > <http://www.w3.org/TR/mobileOK-basic10-tests/#TABLES_LAYOUT>, this test > checks usage for layout. > > > Test procedure: > > If tables are used in a fashion that could be achieved using CSS [FAIL] > > > Examples: > > * An image or text which is spaced and positioned with the aid of a > table > > > Open issues: > > None > > > 4.35 Tables Support <http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT> > > > Note to BPWG: > > None > > > Limitations of this test: > > None > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Test procedure: > > 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. > > > Test procedure: > > * 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. > > > Test procedure: > > * 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 www subdomain? If yes, [FAIL] > > > Examples: > > None > > > Open issues: > > None > > ------------------------------------------------------------------------ > > > 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. > > > Test procedure: > > * Excluding hyperlinks, does the page include any other blue or > purple text? If yes, [FAIL] > * When viewed on a monocrome screen, is all content still readable? > If not, [FAIL] > * Is color used to represent information? If yes, [FAIL] > > > Examples: > > * Using red text to represent an error message - PASS > * Using blue or purple text within the page, other than for > hyperlinks <http://www.example.org/> - FAIL > * Telling the user that important information is highlighted in > yellow - FAIL > > > Open issues: > > None > > ------------------------------------------------------------------------ > > > A References > > * 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> > * http://www.w3.org/TR/di-gloss/#def-delivery-unit > * http://www.w3.org/TR/powder-grouping/ >
Received on Friday, 10 October 2008 20:17:31 UTC