- From: Francois Daoust <fd@w3.org>
- Date: Thu, 28 Feb 2008 09:41:32 +0100
- To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
- CC: public-bpwg-pro@w3.org
Hi guys, I published the editors' draft: http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228 The draft is accessible from the group's and the TF's home pages. François. Scheppe, Kai-Dietrich wrote: > Hi, > > I have mailed the draft for Francois for posting...but here it is for > you as well of course. > > -- Kai > > Please make note of my new email address: > k.scheppe@telekom.de > > > ------------------------------------------------------------------------ > > > mobileOK Pro Tests Version 1 > > > Group Working Draft 20 February 2008 > > This version: > Insert link here > Latest version: > Insert link here > Previous version: > Insert link here > Editor: > Kai Scheppe, Deutsche Telekom AG, Products & Innovation > Phil Archer, Family Online Safety Institute > 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 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 > > First Editor's Draft > > 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 and Limited <#central_meaning_limited> > 4.8 Clarity <#clarity> > 4.9 Color Contrast <#color_contrast> > 4.10 Content Format Preferred <#content_format_preferred> > 4.11 Control Labeling <#control_labeling> > 4.12 Control Position <#control_position> > 4.13 Cookies <#cookies> > 4.14 Deficiencies <#deficiencies> > 4.15 Error Messages <#error_messages> > 4.16 Fonts <#fonts> > 4.17 Graphics for Spacing <#graphics_spacing> > 4.18 Link Target ID <#link_target_id> > 4.19 Minimize Keystrokes <#minimize_keystrokes> > 4.20 Navbar <#navbar> > 4.21 Navigation <#navigation> > 4.22 Non-text Alternatives <#non-text_alternatives> > 4.23 Objects or Scripts <#objects_scripts> > 4.24 Page Size Usable <#page_size_usable> > 4.25 Page Title <#page_title> > 4.26 Provide Defaults <#defaults> > 4.27 Scrolling <#scrolling> > 4.28 Structure <#structure> > 4.29 Style Sheets Size <#style_sheets_size> > 4.30 Style Sheet Support <#style_sheet_support> > 4.31 Suitable <#suitable> > 4.32 Tab Order <#tab_order> > 4.33 Tables Layout <#tables_layout> > 4.34 Tables Support <#tables_support> > 4.35 Testing <#testing> > 4.36 URIs <#uris> > 4.37 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 > > > 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: > > * The BP does not say anything about listing which access keys are > being used. > * The recommend form of the access key (numeric 1 vs. alpha-numeric > “abc”) is not mentioned. Should this Pro test go further than BP > and encourage the use of numeric access keys? > > > Limitations of this test: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > Where there are elements, particularly navigation links and form > controls, that would benefit from access keys: > > * If access keys are not assigned: [FAIL] > * If access keys are not indicated effectively: [FAIL] > * If the usage of access keys is not consistent across a given page > and site: [FAIL] > > > Examples: > > * Hyperlinks may be easily decorated with access keys by presenting > them in an ordered list where the access code is equivalent to the > list position (and is usually numeric). > * Form control labels may underline the relevant access key > * A quick reference guide to access keys may be available at the > bottom of the page (NOT on a separate page). > > > Open issues: > > One might argue what benefits and what doesn’t? > > To be more explicit - if you have navigation options and/or form > controls, there should be access keys. > > > 4.2 Auto Refresh <http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH> > > > Note to BPWG: > > None > > > Limitations of this test: > > 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: > > There are many different ways to aid data input, with no one 'right' > way. However, leaving it entirely up to the user to enter the data > freehand without any attempt to offer pre-selection or pre-filling of > the input field by automated means, where avilable, is readily > detectable as 'the wrong way.' > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > If there are one or more free text input fields: > > Could they be converted into any of: > > * a select field, > * radio buttons with no more than x values, > * radio buttons for the most likely entries plus a free text option > for 'other' values > * check boxes with no more than y values? > > If these techniques are avilable, but not implemented: [FAIL]. > > If the techniques above are not avilable and if data has been entered > previously, if the previously-entered data is not used to pre-fill the > input field: [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: > > This test does extend to users with visual impairment. The Web Content > Accessibility Quick Reference > <http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual-audio-contrast7> > offers more advice on this topic. > > > 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. > > > Pseudo code: > > Where there is a background image, if perceiving content in the > foreground is not easy under normal daylight conditions: [FAIL] > > > Examples: > > * Pink is easily lost on this background > * Yellow is practically not legible on this background > * But this is much better > > > Open issues: > > Should we include a reference to the WCAG 2.0 techniques? If so, did > Alan choose the right one? > > > 4.5 Balance <http://www.w3.org/TR/mobile-bp/#BALANCE> > > > Note to BPWG: > > None > > > Limitations of this test: > > This test is highly dependent on context. Some content, such as site > maps, online encyclopedias and other reference materials may warrant a > high link density. As the scrolling action on many mobile devices > selects each link in turn, however, including a lot of links on a single > page can easily create an unsatisfactory user experience. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > Unless the primary purpose of the content is navigation, such as a site > map, or the user could readily want to persue links to further resources > in an unpredictable manner: > > 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. However, it is usually possible to detect presentation that > is artificially constrained by the limited and largely hypothetical > Default Delivery Context. Unlike the DDC, many real devices support > scripting, XML HTTP requests, DOM capabilities, cookies and CSS > including media queries. Furthermore most current devices have screens > well in excess of 120 pixels wide > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > If the presentation of the content is artificially limited by the > capabilities of the DDC and if the presentation is similarly limited on > more capable devices: [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. > * Again, in forms, scripting may be used to adjust the presentation > or state of a control based on the input(s) already supplied. > > > Open issues: > > This is a can of worms, but it is important to counteract the “working > down to the DDC” issue > > > 4.7 Central Meaning > <http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING> and Limited > <http://www.w3.org/TR/mobile-bp/#LIMITED> > > > Note to BPWG: > > None > > > Limitations of this test: > > There are subtle differences between these two Best Practices. Central > Meaning is concerned with the physical layout of the page, ensuring that > desktop-style navigation does not dominate whilst Limited is concerned > with presenting information in a manner that reflects the likely real > world situation of the audience - on the move with limited time and > attention span, perhaps in an environment where there are many forces > competing for the user's attention. Despite these differences, it is > convenient to test conformance with these two Best Practices together. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > * If it is not possible to determine what the main focus of a web > page is without scrolling: [FAIL] > * If simple facts that can readily be presented using bullet points > and headings are instead presented as lengthy prose: [FAIL] > > > Examples: > > None > > > Open issues: > > None > > > 4.8 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. > > > 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.9 Color Contrast <http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST> > > > Note to BPWG: > > None > > > 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 > > > 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.10 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. > > > Limitations of this test: > > This test cannot be failed, because alternate formats may not be available. > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > The follow is not very explanatory and needs some wordsmithing. > How would one determine a "change" in the quality headers, which denote > preference of a content format? > Or did we mean if they are different, as in 0.1 - 0.9 over a variety of > formats? > > If the quality factors of the accept headers are changed and the content > which is delivered does not reflect that change [WARN] > > > Examples: > > A change in preference between GIF and JPEG, character encoding or > markup for a given device, should be reflected accordingly. > > > Open issues: > > None > > > 4.11 Control Labeling > <http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING> > > > Note to BPWG: > > This test is machine testable > > > Limitations of this test: > > None > > > Differences to mobileOK Basic Tests: > > This test does not exist in mobileOK Basic Tests. > > > Pseudo code: > > * If there are form elements and no label elements [FAIL] > * If the for attribute is not defined and the content of the label > element is not a form control [FAIL] > * If the for attribute is present but does not correspond to the id > attribute of a form control [FAIL] > > > Examples: > > None > > > Open issues: > > * Confirm that point 1 is really valid. > * 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? > > > 4.12 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.13 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.14 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.15 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.16 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.17 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.18 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.19 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.20 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.21 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.22 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.23 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.24 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.25 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.26 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.27 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.28 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.29 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.30 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.31 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.32 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.33 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.34 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.35 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.36 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.37 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, 28 February 2008 08:41:49 UTC