- From: Francois Daoust <fd@w3.org>
- Date: Thu, 27 Mar 2008 16:55:07 +0100
- To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
- CC: Mobile Web BP Pro list <public-bpwg-pro@w3.org>
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/drafts/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/latest > > Previous version: > <http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-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 Thursday, 27 March 2008 15:55:41 UTC