[minutes] September 29 teleconf

[Dominique Hazael-Massieux-2]

Hi,

The minutes of the BP call today are available at:
http://www.w3.org/2009/09/29-bpwg-minutes (copied as text below)

Among the resolutions taken:
 * the group will organize its next and last F2F on December 9 to 11,
either in London (if DKA confirms they can host), or in Darmstadt
 * the group agreed to publish the 24 September version of MWABP as a
Last Call Working Draft (yiipee!)
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090924
 * the group agreed to publish the addendum to the best practices,
modulo a final edit to the accesskeys section
 * the group agreed to publish the CT guidelines as Last Call (pending a
couple of editorial modifications)

Dom

        Mobile Web Best Practices Working Group Teleconference

29 Sep 2009

   [2]Agenda

      [2] http://www.w3.org/mid/4AC0A5E7.7030300@...

   See also: [3]IRC log

      [3] http://www.w3.org/2009/09/29-bpwg-irc

Attendees

   Present
          tomhume, jo, jeffs, DKA, brucel, Dom, adam, SeanP, EdC,
          chaals, manrique, yeliz

   Regrets
          Kai, Miguel, Abel, Francois

   Chair
          Jo

   Scribe
          DKA, dom

Contents

     * [4]Topics
         1. [5]Final F2F
         2. [6]BP2
         3. [7]Addendum to BP1
         4. [8]BP 1.5
         5. [9]The Lovely CT
     * [10]Summary of Action Items
     _________________________________________________________

Final F2F

   <jo> [11]Poll for F2F

     [11] http://www.w3.org/2002/09/wbs/37584/f2f-nov-2009/

   Jo: There has been a poll.

   <dom> [12]Results of Poll for next F2F

     [12] http://www.w3.org/2002/09/wbs/37584/f2f-nov-2009/results

   Jo: We have a nominal date and some offers of hosting.
   ... Vodafone?

   <jsmanrique> dom: maybe it is me

   Dan: No confirmation as of today.

   <jsmanrique> chaals: it is me ;)

   Jo: We have offers from Chaals in Norway.
   ... Reason I am keen on London - it's easy for people to get to.

   <jo> (and Darmstadt)

   Jo: Firm offers from Norway and Darmstadt.
   ... survey says: 9-11 December

   <jo> PROPOSED RESOLUTION: F2F 9-11 in TBD (maybe London on the basis
   of Transport costs and ease)

   <brucel> + Iceland will be cold

   +1

   <tomhume> +1

   <jeffs> +1

   <jsmanrique> +1

   <yyesilad> +1

   <SeanP> +1

   <EdC> Ok.

   Dan: I will get back to y'all suckers by tomorrow.

   <jo> ACTION: Dan to get back to group on hosting F2F by tomorrow
   [recorded in
   [13]http://www.w3.org/2009/09/29-bpwg-minutes.html#action01]

   <trackbot> Created ACTION-1016 - Get back to group on hosting F2F by
   tomorrow [on Daniel Appelquist - due 2009-10-06].

   <chaals> s/suckers, and chaals/

BP2

   <dom> [14]Adam's update

     [14] http://www.w3.org/mid/393b77970909240813p6287a28epd4605bb169e0bd11@...

   Adam: I've sent in a draft with minor mods from last week -
   hopefully it's good to go.

   Jo: Any comments in on that yet?

   Adam: Not yet.

   Jo: Editorial meeting?

   Adam: Let's discuss a date...

   +1 to dom

   <jeffs> I think Dom is right

   <Zakim> dom, you wanted to wonder about publishing as LC before
   editorial meeting

   <jeffs> 24 sept

   <jeffs>
   [15]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/E
   D-mobile-bp2-20090924

     [15] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090924

   <jo> PROPOSED RESOLUTION: Request publication of 24 Sept draft of
   MWABP as Last Call

   <jo> +1

   <jeffs> +1

   <adam> +1

   +1

   <Zakim> dom, you wanted to ask what groups we want reviews from and
   to ask about deadline for comments

   <dom> Dom: I recommend WebApps, DAP, HTML, SVG, maybe CSS, WAI, I18N

   Jo: A month seems right to me.

   RESOLUTION: Request publication of 24 Sept draft of MWABP as Last
   Call

   <jeffs> +1

   <EdC> +1

   RESOLUTION: Request publication of 24 Sept draft of MWABP as Last
   Call with a comment period of a month with comments requested from
   WebApps, DAP, HTML, SVG, maybe CSS, WAI, I18N

   <brucel> "3.5.10 did we have a note r/e accessibility there?

   <adam>
   [16]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/E
   D-mobile-bp2-20090924

     [16] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090924

   Jo: Editorial meeting...

   <dom> "In most cases Canvas is faster and should be preferred if it
   meets requirements. However, since Canvas generates a flat bitmap it
   is not inherently accessible and so should not be used as the sole
   means of conveying information. "

   <dom> ACTION: Francois to get MWABP published as Last Call and
   ensure Chairs announcement is properly sent [recorded in
   [17]http://www.w3.org/2009/09/29-bpwg-minutes.html#action02]

   <trackbot> Created ACTION-1017 - Get MWABP published as Last Call
   and ensure Chairs announcement is properly sent [on François Daoust
   - due 2009-10-06].

   <jo> ACTION: Adam to call editorial meeting on Friday 9th Oct to
   discuss MWABP [recorded in
   [18]http://www.w3.org/2009/09/29-bpwg-minutes.html#action03]

   <trackbot> Created ACTION-1018 - Call editorial meeting on Friday
   9th Oct to discuss MWABP [on Adam Connors - due 2009-10-06].

   <brucel> Bruce, must duck out for a few minutes; knock on the door

Addendum to BP1

BP 1.5

   Jo: some comments from chaals - some to and fro - and it's
   unresolved...

   <dom> [19]Charles' suggestion

     [19] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0115.html

   Dom: To clarify, what decision needs to be made?

   <jo> [20]Chaals's proposal ref ACcessKey

     [20] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0115.html

   <dom> +1 on adopting Charles's suggestion and publish

   Jo: either we adopt chaal's suggestion, update and publish or ignore
   and publish.

   <jo> PROPOSED RESOLUTION: Adopt Chaals's resolution, request update
   from editor and publish

   +1 if Chaals brings us some ice from iceland.

   <EdC> 0

   <tomhume> 0

   <jsmanrique> +1

   <jeffs> "while there is no standard way ..."??

   <jeffs> "While there is no standard way... , common techniques
   include..."???

   <chaals> +1 to chaals comments

   <jo> PROPOSED RESOLUTION: Thanks Chaals for his informed comment but
   we decline to adjust the text and request publication as is

   <EdC> 0

   <jeffs> I think we can put the 2 of them together, his point is
   well-taken

   <jeffs> "While there is no standard way... , common techniques
   include...", for example???

   <chaals> -1 to the foolish and reckless proposal to ignore the
   brilliant and insightful yet minimal change proposed by chaals

   <jsmanrique> :)

   RESOLUTION: Adopt Chaals's resolution, request update from editor
   and publish

The Lovely CT

   <dom> [21]CT latest draft (1v)

     [21] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090924

   <dom> [22]Charles' point on conformance

     [22] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0105.html

   Jo: We have a document -

   <dom> [23]Charles's point on URI patterns

     [23] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0106.html

   Jo: ...on which there are some substantive comments...
   ... ...chaals points out the conformance statement needs to be
   mandatory...
   ... fairly simple change.
   ... A further suggestion on URI patterns - we have ended up in
   debate on the list that it would be better to express the URI
   pattern in a known pattern language. I'm happy to make that change.

   <dom> [24]Charles' message on "interacting with the user"

     [24] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0107.html

   Jo: Third point was: "what does interacting with the user actually
   mean"?

   <dom> [25]Jo's unthreaded reply

     [25] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0114.html

   Jo: What do we need to put in the document, if anything, to clarify
   our intention and our meaning?
   ... Chaals?

   Chaals: <stunned silence>

   Jo: Ed can you clarify?

   EdC: You mentioned it would be going too far to specify in detail
   how the interaction between proxy and user should take place. I
   agree - we should keep silent.

   Jo: It's probably worth adding a note.

   Tom: Chaals mentions 2 possibilities - one is ??? - other is that
   proxy generates http responses. If it's the 2nd doesn't that mean
   that the proxy could be compliant but the user could not see any
   difference?

   Jo: We've looked a long time ago at -300 status responses and such.
   It's pretty clear that will not work. We mean interacting with the
   user "in band." We should clarify that it is "in band" with the
   communication with the web site that user is trying to interact
   with.

   Chaals: I.e. content that is served directly to the user. We may get
   objections to that. This is a fairly serious step. Given that all
   providers assume that they have no bugs, they are unlikely to want
   to interrupt their rendering with a confusing statement...

   <EdC> This is not how it is done. In general there is something like
   a link with a comment "click here to unmodified content" or so.

   Jo: Yes but user does need to be given the option.

   <jeffs> user *must* have choice/control

   Chaals: There are other mechanisms. This is a substantive issue.
   When the user has chosen a preference they should have an
   expectation that this preference will be applied.
   ... If you change your preferences (in Opera Mini) through your UI
   preferences settings, is that an "in band" preference dialog?

   Jo: Opera mini is out of scope for this document.

   Dom: point 1- in interacting with the user it's clear that we meant
   "in band" communication. point 2- is this a reasonable requirement
   and will we get people to follow that requirement. Chaals is saying
   he might object.
   ... Can we hear from other vendors?

   Chaals: Opera software does not provide the in-band notification
   that you're asking for and i can't imagine they would...

   Jo: One objection people have often taken to proxies is that
   operators [of proxies] feel free to insert in-band content...

   Chaals: If you're interested in compliance then requirements which
   have a direct user experience impact, you need to be clear that
   these are necessary...

   <EdC> +q

   Jo: It's not acceptable for there to be pre-configured proxies,
   where signing a t&c gives carte blanche to the proxy operator.
   ... It's not in scope for us to design the UI or operation of the
   product.

   <EdC> -q

   <Zakim> tomhume, you wanted to find chaals' suggestion on http
   response codes more reasonable

   Jo: What's in scope is that the product should provide a way for the
   user to tell the proxy [to get out of the way]

   Chaals: if there is a proxy that is explicitly non-transparent,
   adding options on the bottom will not be helpful...

   Jo: We're not trying to develop a interface document that referes to
   user-cognitive models [?]

   <EdC> I think Chaals you should realize that in many cases, users do
   not explicitly subscribe to a non-transparent service -- it is
   imposed by the operator.

   Sean: I agree with Dan - maybe we should leave things the way they
   are. What constitutes in-band or out of band - that seems to be hard
   to define...

   Jo: I agree.

   Chaals: 2 issues - does "in band" mean inserted into the rendered
   page? If so, there must be some minimum explanation of "inform the
   user and allow the user to choose."

   Jo: My preference would be to remain silent. 2nd point - if we are
   not to remain silent then text needs to say "provide user with a
   choice at the point of receipt of the content."

   <jeffs> agree that choice should be provided at point of
   content-receipt

   <EdC> Dan, you mean some for of "interstitial" or "splash" option
   setting page?

   Dan: "in band" notification could be an interstitial page, as in a
   wifi hotspot...

   Chaals: it's not nice to have an interstitial. You should be able to
   set preferences out of band. Would that be a sufficient solution.

   Jo: No I don't think it would be sufficient.

   Sean: I think chaals's solution seems Ok as long as there's a link
   to it on the page that was sent down...

   Jo: Inserting a link so you can change your preferences seems no
   less intrusive...

   Chaals: What if you had a preferences setting?

   EdC: The google wireless transcoder does exactly what Sean said. 2nd
   thing - regarding preferences: if you are setting preferences you
   are setting them for every possible link traversal. The intent of
   the guidelines is that when something exceptional happens, then at
   that point the user should be informed (rather than at every
   traversal).

   Chaals: No because we set per-site preferences anyway.

   <EdC> example in section 4.1.5.3 "but must, on receipt of an
   indication from a Web site that it offers alternative
   representations (see H.1.4.2 Indication of Intended Presentation
   Media Type of Representation), inform the user of that and allow
   them to select an alternative representation."

   <EdC> This is not something that can be done out of band via
   preference settings.

   <jo> PROPOSED RESOLUTION: LEave text as is in respect of interacting
   with the user

   EdC: It'd doesn't mean that out-of-band preferences (e.gg. per site)
   should not be used but that it is not sufficient.

   <SeanP> +1

   <EdC> +1

   <jo> +1

   +1

   <dom> [chaals says +1 on the phone, but noting that this leaves the
   possibility for people to claim conformance doing things we simply
   don't expect - on the other hand that is not the worst things
   possible]

   <tomhume> +1

   <jo> [26]Sean's Comments

     [26] http://lists.w3.org/Archives/Public/public-bpwg/2009Sep/0124.html

   RESOLUTION: Leave text as is in respect of interacting the user [in
   CT]

   Jo: In reference to validation to an appropriate published grammar.
   Are you asking for that clause to be changed?

   <EdC> I believe we went through this, downgraded must to should
   validate (catering for if there is no grammar f.ex.), keeping only
   well-formed for XML.

   Sean: Yes. Seems unrealistic.
   ... I don't think any of them do that today.

   <EdC> See my comment above.

   <dom> [I think Sean's point is reasonable indeed]

   Sean: HTML typically doesn't validate and sometimes to get it work
   the way you want it can't validate...

   Jo: Any comments?

   <EdC> I believe we went through this, downgraded must to should
   validate (catering for if there is no grammar f.ex.), keeping only
   well-formed for XML.

   <dom> "The altered content should validate according to an
   appropriate published formal grammar and if XML must be
   well-formed;"

   <EdC> This means no published or no formal grammar => no validation.
   Otherwise should, but if you have reasons to tweak to make it
   work...

   Jo: I think this provides plenty of room in the conformance
   statement - scope for you to conform but not to validate in certain
   cases.

   <EdC> Yes. Only XML has a formal definition and separation of
   validation and well-formed (the latter being lexically/syntactically
   correct).

   Sean: OK that's fine. I just wanted to make sure that's what we're
   saying.

   Jo: Let's leave it as that.

   PROPOSED RESOLUTION: let's roll

   <EdC> Who takes up the editorial comments of SeanP?

   Jo: any other comments?

   <jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments
   inspired by Chaals, (not including user interaction) and Sean's
   rightfully critical editorial comments, the group requests
   publication of the draft 1v as Last Call

   <EdC> Do not forget the ICS...

   <EdC> Include it in the resolution...

   <dom> ScribeNick: dom

   <jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments
   inspired by Chaals, (not including user interaction) and Sean's
   rightfully critical editorial comments, the group requests
   publication of the draft 1v (together wit the corresponding ICS) as
   Last Call

   <EdC> +1

   +1

   <jo> +1

   <SeanP> +1

   <chaals> 0

   [DKA +1 on the phone]

   previous list of people asked for comments: TAG, HTML WG, XHTML2 WG,
   WebApps WG, HCG , OMA (at least)

   <jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments from
   Chaals, (not including user interaction) and Sean's editorial
   comments, the group requests publication of the draft 1v (together
   wit the corresponding ICS) as Last Call with 4 weeks and request
   comments from same list as last time as well as previous LC
   commenters

   <EdC> +1

   <adam> +1

   <jo> +1

   <SeanP> +1

   <brucel> concur

   RESOLUTION: Modulo the two editorial adjustments from Chaals, (not
   including user interaction) and Sean's editorial comments, the group
   requests publication of the draft 1v (together wit the corresponding
   ICS) as Last Call with 4 weeks and request comments from same list
   as last time as well as previous LC commenters

   Jo: 1 month period, same list of groups as before, plus commenters
   on previous draft

   <scribe> ACTION: Francois to get CT published as Last Call and
   ensure chairs announcement [recorded in
   [27]http://www.w3.org/2009/09/29-bpwg-minutes.html#action04]

   <trackbot> Created ACTION-1019 - Get CT published as Last Call and
   ensure chairs announcement [on François Daoust - due 2009-10-06].

Summary of Action Items

   [NEW] ACTION: Adam to call editorial meeting on Friday 9th Oct to
   discuss MWABP [recorded in
   [28]http://www.w3.org/2009/09/29-bpwg-minutes.html#action03]
   [NEW] ACTION: Dan to get back to group on hosting F2F by tomorrow
   [recorded in
   [29]http://www.w3.org/2009/09/29-bpwg-minutes.html#action01]
   [NEW] ACTION: Francois to get CT published as Last Call and ensure
   chairs announcement [recorded in
   [30]http://www.w3.org/2009/09/29-bpwg-minutes.html#action04]
   [NEW] ACTION: Francois to get MWABP published as Last Call and
   ensure Chairs announcement is properly sent [recorded in
   [31]http://www.w3.org/2009/09/29-bpwg-minutes.html#action02]

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [32]scribe.perl version 1.135
    ([33]CVS log)
    $Date: 2009/09/29 14:53:05 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [33] http://dev.w3.org/cvsweb/2002/scribe/

[Scheppe, Kai-Dietrich-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi all,

As per decision on today's call

> http://www.w3.org/2009/09/29-bpwg-minutes
...
>    RESOLUTION: Adopt Chaals's resolution, request update from editor
>    and publish

Changes made:
- changed dates and links to versions
- I have removed the offending bits of text and added this extremely
final version to this mail.

However, the document was still a draft, so

- I have changed the style sheet to W3C-WG-NOTE
- I have changed the word "Draft" in the "Status of this document"
section to "Working Group Note".
- I have added the sentence "The Working Group has expressed its
consensus in support of publishing this Note."
- I have changed the last paragraph of this section to say that this
document may be updated...etc.

  However, the text in this section does not conform to the Text of
Working Group Notes that I could find in the W3C Process Document or W3C
Technical Reports and Publications.  

Usage of the Status section varies widely, with published documents
stating invalid information, such as it being a draft document.

Could W3C staff please give guidance on this?
I am happy to implement the changes.

Note: I am not sending the image file, assuming it will be at the same
location.


-- Kai

Addendum to Mobile Web Best Practices

W3C Editor's Draft 29 September 2009

This version:

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090929

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-20090923

Editor:

Kai Scheppe, Deutsche Telekom AG

Substantial contributions made by:

Phil Archer,  W3C/ERCIM (formerly at FOSI)
Alan Chuter, Technosite
Jo Rabin, DotMobi

Dave Rooks, Segala

José Manrique López de la Fuente, Fundación CTIC

Copyright © 2009 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

---

Abstract

This document supplements W3C Mobile Web Best Practices 1.0 [MWBP] by providing additional evaluations of conformance to Best Practice statements and by providing additional interpretations of Best Practice statements.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a public Working Group Note produced by the mobileOK Pro Tests Taskforce of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . Please send comments on this document to the Working Group's public email list public-bpwg-pro@..., a publicly archived mailing list .

The Working Group has expressed its consensus in support of publishing this Note.

This document was produced under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of patent disclosures 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.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This document may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Other documents may supersede this document.

Table of Contents

1 Introduction

1.1 Purpose
1.2 Relationship to mobileOK Basic Tests
1.3 Scope
1.4 Audience

2 Sampling

2.1 Evaluation Scope
2.2 Evaluation Structure

3 Evaluation Procedures

3.1 Access Keys
3.2 Auto Refresh
3.3 Avoid Free Text
3.4 Background Image Readability
3.5 Balance
3.6 Device Capabilities
3.7 Central Meaning
3.8 Suitable, Limited and Clarity
3.9 Content Format Preferred
3.10 Control Labeling and Position
3.11 Cookies
3.12 Error Messages
3.13 Fonts, Style Sheet Use and Style Sheet Support
3.14 Graphics for Spacing
3.15 Link Target ID
3.16 Minimize Keystrokes
3.17 Navbar
3.18 Navigation
3.19 Non-text Alternatives
3.20 Objects or Scripts
3.21 Page Size Usable
3.22 Page Title
3.23 Provide Defaults
3.24 Scrolling
3.25 Structure
3.26 Style Sheets Size
3.27 Tab Order
3.28 Tables Layout
3.29 Tables Support
3.30 URIs
3.31 Use of Color

Appendices

A References

---

1 Introduction

1.1 Purpose

This document builds on Mobile Web Best Practices 1.0 [MWBP] and helps content providers to create content suitable for delivery to mobile devices. It does this by providing additional evaluations for content and by interpreting and clarifying some Best Practice statements.

1.2 Relationship to mobileOK Basic Tests

mobileOK Basic Tests 1.0 [MOKTESTS] also builds on Mobile Web Best Practices 1.0 [MWBP] and describes machine-executable tests for some of the Best Practice statements. Performing those tests assesses whether a Web site is capable of delivering content to the hypothetical basic mobile device called the "Default Delivery Context" (DDC). It does not assess the capability of a Web site to deliver alternative representations that take advantage of capabilities that exceed those of the DDC when accessed from such devices. This addendum provides an additional set of evaluations, some machine-testable, that go beyond the objectives of mobileOK Basic Tests in that they are not applicable solely to the DDC.

1.3 Scope

The scope of this document is a commentary on Mobile Web Best Practices 1.0 [MWBP] and mobileOK Basic Tests 1.0 [MOKTESTS].

1.4 Audience

This document is intended for creators, maintainers and operators of Web sites. Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers and HTTP, and with Mobile Web Best Practices and mobileOK Basic Tests.

2 Sampling

2.1 Evaluation Scope

While most evaluations apply to single pages or delivery units [DIGLOSS], some, such as ACCESS_KEYS, NAVIGATION and URIS, are tested across multiple pages.

2.2 Evaluation Structure

Where useful the following structure has been adhered to:

Related mobileOK Basic Test

A link to a related mobileOK Basic Test, where relevant.

Relevant Delivery Context Capabilities

Properties of the delivery context [DIGLOSS] that are referred to by the evaluation.

You will need to use a Device Description Repository (DDR) [DDRSA] to find out which capabilities a given device possesses. See Device Atlas or Morfeo for example.

Interpretation of the Best Practice

Clarification of one or more aspects of the Best Practice to which the evaluation refers.

Evaluation Procedure

How to carry out the evaluation.

Examples

Explanatory material.

3 Evaluation Procedures

To satisfy the Testing Best Practice, the following evaluations should be carried out using a range of real devices as well as, or instead of, emulators. Note that several tests require certain features of the device or browser to be absent or disabled if present.

3.1 Access Keys

Relevant Delivery Context Capability

Support for access keys, i.e. key presses that provide a short cut to activation of links in a page.

Interpretation of the Best Practice

Typically a "Web site" has common navigation links that apply to most, or all, pages in the site (a menu bar for example). Such navigation links should be associated with access keys and the keys assigned should be the same on all pages. Other frequently accessed links (such as navigation within a page) may also benefit from being associated with an access key.

Note that access keys are not supported by some user agents. Representations targeted at such user agents should not contain link decoration.

Evaluation Procedure

Where there are elements that would benefit from quick access, particularly navigation links and form controls:

• Verify that access keys are assigned to navigation links present on all pages on the site.
• Verify that access keys are used consistently for the same links.
• Verify that the access keys are numeric, or if not, have been tailored for use on a specific target device.
• Verify that the user can establish which access keys are assigned to links.

3.2 Auto Refresh

Related mobileOK Basic Test

AUTO_REFRESH and REDIRECTION

Evaluation Procedure

Verify that pages that use automatic refresh (e.g. as highlighted by a mobileOK evaluation) contain a link to a non-refreshing version.

3.3 Avoid Free Text

Relevant Delivery Context Capabilities

• Maximum size of a select list.
• Availability of an Alpha-Numeric Keyboard.

Evaluation Procedure

Assess whether free-text input fields:

<input type="text">, <input type="password">, <textarea>

would provide a more usable experience if replaced by a series of radio buttons, checkboxes or a select menu (where the number of choices is limited so as to be appropriate to the capabilities and ergonomics of the device).

Examples

• Replacement of text entry with selection:
  • Selection ZIP/Post codes from a list, perhaps within a limited geographical area or by progressive refinement based on previous selection.
  • Selecting a country from a drop down list, ideally with the most likely choice(s) at the top as well as in the list in their alphabetical position.

• Use of radio buttons for limited choice selections such as (Yes/No) and (Small/Medium/Large).

3.4 Background Image Readability and Color Contrast

Relevant Delivery Context Capabilities

• Screen Contrast
• Color Depth
• Screen quality
• Resolution

Interpretation of the Best Practice

The use of colored, patterned or photographic background images can make text hard to read both because of reduced device screen contrast and because of the context of use, in bright sunlight for example, reducing the perceived contrast.

Evaluation Procedure

Verify that where background images are used contrast ratio between the overlying text and each color used in the background image is sufficient.

Examples

There are also a variety of color contrast measuring tools available online, such as:

• WCAG Technique G18 (provides a formula as well as links to further tools) [WCAG20]
  
• Color Contrast Check
• CSS Analyzer

3.5 Balance

Relevant Delivery Context Capability

Type of scrolling and link navigation

Interpretation of the Best Practice

Different devices provide a number of means of navigating within a page:

• Selection of each link in document order.
• Scrolling independently of links.
• Stylus or Finger Based.

If there is a large number of links in the page, users of devices that can only navigate by successive selection of links will find it difficult to scroll the page and use links that are lower down.

Evaluation Procedure

Assess the number of links in the page. If the representation is targeted at devices that do not support navigation independently of the number of links in the page, verify that the page does not use more than 30 links. Other types of device and special purpose pages may warrant a larger number of links.

3.6 Exploit Device Capabilities

Relevant Delivery Context Capabilities

• Screen Width
• Screen Height
• Color Depth
• Markup Language Support
• Character Encoding Support
• Image Format Support
• CSS Support
• Script and XHR Support

For details see the DDC.

Interpretation of the Best Practice

Unlike the DDC, many real devices support Scripts, XML HTTP requests, DOM Capabilities, Cookies and advanced CSS support. Web sites that are designed to support a variety of different representations might target a particular demographic of users with certain classes of device or simply make significant efforts to give users the best possible experience. Browsing a simple, static Web site on an advanced device may be little more rewarding than attempting to browse one that assumes capabilities that are unavailable on the device used, thereby making the content inaccessible.

There is no simple rule or single evaluation that will determine whether a content provider has exploited device capabilities. There will always be a balance between the cost of providing multiple representations versus the benefit of doing so. For this reason, we do not provide a formal evaluation procedure to test this aspect of Best Practice except to say that any evaluation necessarily requires the Web site to be accessed from a variety of different devices with different capabilities. However, we do offer some examples of the kind of informal evaluation that may be possible, depending on what type of content is being offered.

Examples

• Where links lead to content that may not work on less-capable devices, e.g. links to video, the user should be warned. Such warnings should not appear when the content is delivered to a target device known to support  the feature (see also 3.8 Suitable, Limited and Clarity, below).
• The representation should not be unnecessarily limited to 120 pixels wide for devices that have wider screens.
• JavaScript should be used for form validation on devices that support it as this can reduce network traffic and latency.
• In forms, scripting may be used to adjust the content or state of a controls based on the input already supplied.
• Enhancements, such as JavaScript and advanced CSS, must fail gracefully  - i.e. where such features are used, the lack of support on less sophisticated devices must not prevent access or limit functionality.

3.7 Central Meaning

Interpretation of the Best Practice

When accessing a page on a mobile device, the primary content should be visible. This means that the well-established layout for desktop devices, with navigation along the top and/or side of the page, is usually inappropriate.

Evaluation Procedure

Verify that the main content of the web page is visible without scrolling. This is usually content that is unique to the page and does not repeat across several pages

3.8 Suitable, Limited and Clarity

Interpretation of the Best Practice

Informational content should be provided in a manner suitable for access on mobile, i.e. with an eye to quick assimilation by the user, rather than in a verbose style.

Evaluation Procedure

• Verify that informational content is characterized by a brief writing style using features such as headings and lists.
• Verify that a user can see skip through the content if so desired to reach the particular information they seek.
• Verify that any more detailed information that is provided comes after the introductory paragraph(s).
• Verify that the text is generally written in short sentences without unnecessary sub-clauses.
• Verify that unfamiliar terms are not used (except technical terms relevant to the subject matter).

Examples

• News stories are typically 'front-loaded' with key information (who, what, why, when) provided in the headline and in the opening sentences.
• Event information should be in the form Venue: village hall; time: 6pm; Refreshments available; rather than the more verbose: "The meeting will begin at 6pm in the village hall where refreshments will be available."
• Non-mechanical gardening implements are referred to as a spade.
• For English language pages, the Gunning Fog test can give an indication of complexity. A level of roughly 7 or 8 would be ideal.
• Otherwise unsuitable content may be suitable in a controlled environment, perhaps with logon for entry. This might be relevant, for example, for the retrieval of large medical scans on mobile devices.

3.9 Content Format Preferred

Related mobileOK Basic Test

CONTENT FORMAT SUPPORT

Interpretation of the Best Practice

If a device supports one format better than another, it is preferable to deliver content in the better-supported format if possible.

Evaluation Procedure

• Request the content simulating a device with a preference for a particular format.
• Repeat the request simulating a device that has a preference for a different format.
• Verify that the appropriate alternative format has been delivered in both cases.

Examples

• PNG images may display better than GIF.
• Support for Shift-JIS character encoding may be better than for UTF-8.

3.10 Control Labeling and Control Position

Interpretation of the Best Practice

It is dangerous to assume that the same layout will be presented to all users of mobile devices. It is important therefore to ensure that <input> elements are correctly labeled so that the association between <label> and <input> element is retained even if the layout is changed.

For a detailed description of labels and form controls, the reader may also refer to Techniques for WCAG 2.0 [TWCAG], specifically to section H44: Using label elements to associate text labels with form controls from some examples have been.

Evaluation Procedure

1. Verify that there are <label> elements, if user-visible <input> elements are used.
2. Verify that
   • either the for attribute of the <label> element is present and corresponds to the id attribute of a form control.
   • or that the <label> element contains the form control for which it is a label.
   • doing both of these is also acceptable.
3. Verify that the label describes the purpose of the form control.
4. Verify that labels and <input> elements are visually associated with and without CSS support.

Examples

• A label which requests a person's name but is associated with a birth date field presented as drop down boxes, fails step 3.
  • Bad example: <label>Your name <input type="date"/></label>
• The for attribute and corresponding id are meaningless except that they must match:
  • Good example: <label for="firstname">First name:</label><input type="text" name="firstname" id="firstname" />

3.11 Cookies

Relevant Delivery Context Capabilities 

Device can accept cookies and the network is transparent to cookies

Evaluation Procedure

1. Identify the main functionality of the site that is important for the user and may rely on state.
2. Evaluate the functionality with cookies enabled.
3. Disable support for cookies. Evaluate the functionality and compare with that evaluated in 2.

Examples

A site that requires a user to login might store that login in a cookie to save the user typing in their credentials each time they visit. If cookies are unavailable, an acceptable degradation would mean that the user was prompted for a login each time they visited that page, but would browse the site without further logins from then on. A poor (and unacceptable) cookie-less degradation would render a site useless by always checking for a non-existent cookie and so not letting the user past the login page.

3.12 Error Messages

Evaluation Procedure

1. Provoke a server-side error. For example: request a URL known not to correspond to any endpoint on the site.
2. Examine the content of the error page.
   It should:
   

• Explain in non-technical language the error which has occurred.
• Be suitable for the DDC, at a minimum, (i.e. it must comply with all other tests).
• Provide at least one of the following links: site home page, back, reload.
• Be in the language the user was reading on the site when the error occurred.

3.13 Fonts, Style Sheets Use and Style Sheets Support

Relevant Delivery Context Capabilities

• Style sheets support
• Font availability
• Font size
• Font effects

Interpretation of the Best Practices

Although the overwhelming majority of devices have support for CSS, such support is not uniform. CSS is designed to control presentation but it should not be used to convey meaning - that is the job of the markup.

Evaluation Procedure

• Verify that content is readable and intelligible with style sheets disabled.
• Assess the difference between the appearance of the content with CSS enabled and disabled and verify that this does not alter the meaning.
• Verify that structural markup is used such as <strong>, <em> and <q> (rather than <b> or <i> which, although HTML tags instead of CSS, are presentational in nature).

3.14 Graphics for Spacing

Interpretation of the Best Practice

The correct way to control presentation on a Web page is to use CSS. Using graphics to achieve positioning and spacing effects adds an unnecessary overhead to the page.

Evaluation Procedure

1. Verify that the content complies with GRAPHICS_FOR_SPACING mobileOK Basic Test [MOKTESTS].
2. View all images in a page, for example in a separate list of images, or by outlining them. For XHTML these will usually be included using the <img> element.
3. Ignoring images that are part of the page's graphic design, such as rounded corners, determine whether any of the images do not convey information and are used purely for spacing.

Examples

• A 1 pixel square image used to separate other content is unacceptable.
• A small image with the same color as the surrounding content is unacceptable.
• Using images to indent text, such as the beginning of a paragraph, is unacceptable.

3.15 Link Target ID

Evaluation Procedure

1. Verify that each link in the text is described by attributes as follows:
   • If the target content is in a language different to that of the tested content, it should be correctly marked with the hreflang attribute.
   • If it is in a format other than that of the tested content, it should be correctly described by the type attribute.
   • If it uses a character encoding different to that of the tested content, it should be described by the charset attribute.
2. Verify that the link text (including alternative text for any non-text elements) clearly describes the information obtained when activating the element.
3. Select elements pairwise. Verify that two links with same link text (including alternative text for non-text elements) and same title attribute (if provided) point to the same resource.

(See UWEM 1.0 13.1 for more details)

Examples

• Links with only the text "Click here" are unacceptable.
• Multiple links in same page with same text or content but pointing to different things are unacceptable.
• Links from an HTML page to a large video file that does not mention format or size are unacceptable.
• Links to content in a language different to that of the current page are unacceptable.

3.16 Minimize Keystrokes

Relevant Delivery Context Capabilities

Input mode

Evaluation Procedure

This evaluation is covered by AVOID_FREE_TEXT, URIS, CENTRAL_MEANING and PROVIDE_DEFAULTS. [MWBP]

3.17 Navbar

Relevant Delivery Context Capabilities

Screen width

Evaluation Procedure

• Verify that there are basic navigational elements located above the rest of the content.
• Verify that all navigational elements fit on a single line in the DDC.
• Verify that, upon loading the page, enough of the main content is visible without scrolling.

Examples

A navigation bar above the main content consisting of only: Home, Up, Down, Site map & Search, or similarly limited options, would be acceptable.

3.18 Navigation

Evaluation Procedure

1. For all the pages in the sample, examine the navigation mechanisms in the pages. These include inline links, groups of links (for example menus) in different parts of the page.
2. Verify that navigation mechanisms are similar throughout pages of the sample, other than for changes that are necessary within the context of a given page.

Examples

• A well designed site will offer the same navigation menu(s) on all pages with the only changes being in the presentation as it affects ths current page, e.g. the link to the current page may be shown differently or elided. 
• Bad examples include:
  • A site navigation menu that is presented differently on different pages.
  • A site navigation menu that is present on some pages but not on the current page.
  • Inline links on other pages have a descriptive title but on the current page they do not.

3.19 Non-text Alternatives

Evaluation Procedure

Referring to Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20]

• Guideline 1. Provide equivalent alternatives to auditory and visual content.
• Guideline 1.1 Text Alternatives

Non-text elements include images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Verify that content meets the mobileOK Basic Test NON_TEXT_ALTERNATIVES [MOKTESTS]

• Verify that a text equivalent has been provided for every non-text element that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
• Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user.

Examples

• Good examples:
  • Null value (alt="") for decorative images such as rounded corners in frame.
  • A text equivalent for an image of an upward arrow that links to a table of contents could be "Return to table of contents".
• Bad examples:
  • An alt value that is the same as the filename.
  • alt=" " (space).
  • No alt attribute.

3.20 Objects or Scripts

Evaluation Procedure

Verify that the document can be viewed or used, with objects or scripts inactive or removed, without any change in the function, or value of the content, of the page.

Examples

From Web Content Accessibility Guidelines 1.0 [WCAG10], Guideline 6, Checkpoint 6.3:

Check that links that trigger scripts work when scripts are turned off or are not supported (e.g., do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4. Refer also to guideline 1.

With scripts turned off or when the page is accessed on a device that does not support scripts or objects:

• A given form can still be filled out and submitted.
• Images are displayed and alternative content is shown.

3.21 Page Size Usable

Relevant Delivery Context Capabilities

• Bandwidth
• CPU power
• Screen size

Evaluation Procedure

Verify that a given web page contains contiguous content, which could technically and semantically be separated into individual pages, and exceeds 3 screen sizes in length without page break.

Examples

• A long article that extends over 3 screens full without some type of page break should be broken up into pages.
• Display of navigational information, requiring continuous movement through the map would pass, because additional maps are loaded as needed.

3.22 Page Title

Relevant Delivery Context Capabilities

• Screen width

Evaluation Procedure

• Verify that the title thematically describes the main intent of the page content.
• Verify that the title does not repeat unchanged across more than 3 pages unless a continuous piece of text has been paginated.
• Verify that the title is too long to display on a screen matching the Default Delivery Context.

Examples

• A page with the primary purpose of offering ring tones alongside small textual items should have this reflected in the title.
• A title such as "Main Portal" which is repeated across more than 3 pages would have to have to be adapted on the pages in question.
• Conversely a title of "Uncle Tom's Cabin" in an ebook page, across many pages, would be perfectly acceptable.

3.23 Provide Defaults

Interpretation of the Best Practice

This section only applies to pages that call for user input in a form.

Evaluation Procedure

Submit the form without selecting any item. This will ensure that defaults, such as preselected values, will be used:

• Verify that the response is not an error page.
• Verify that the response is not a page asking the user to fix some data.
• Verify that the response is not the original page.
• If there are <text> or <textarea> elements that include a default value telling the user what to enter, verify that these values do not have to be manually deleted in order for them not to be processed as user input.

Examples

• A country list might preselect the country code of where the page or service is most relevant.
• A ZIP code listing might have the local ZIP code preselected and surrounding ZIP codes at the top of the list.
• A date field might have today's date filled in.

3.24 Scrolling

Relevant Delivery Context Capabilities

• Input mode
• Screen size

Evaluation Procedure

If horizontal scrolling is necessary to view a page, for each element wider than screen size:

• Ensure the element is not decorative.
• Ensure that the element requires the oversize display, i.e. it cannot reasonably be reduced in size or omitted altogether.

Examples

• A map showing an entire trip, information which would be lost upon zoom, is acceptable.
• A X-ray image, intended for a portable medical device where zooming out would loose vital detail of the image is acceptable.

3.25 Structure

Related mobileOK Basic Test

VALID MARK_UP

Interpretation of the Best Practice

The mobileOK test will ensure that markup is valid, however, it does not ensure that markup elements are used correctly, in terms of the semantics of the document, as opposed to being used to achieve presentational effects. 

Evaluation Procedure

• Verify that headers are properly nested according to their level.
• Verify that list elements are used to represent lists (ordered, unordered, or definition lists) and are not used for formatting effects.
• Verify that heading elements (<h1>, <h2> etc.) are used to represent headers and are not used for formatting effects.
• Verify that all information, which is visually is shown as a group of related elements, uses the <list> element in the markup to provide that structure.
• Verify that all information that is shown visually as blocks of text uses separate elements such as <p> or <div> in the markup rather than creating visual separation using multiple <br> line breaks.

3.26 Style Sheets Size

Evaluation Procedure

• Verify that style sheets do not contain more than 25% white space.
• Verify that all style rules are used somewhere in the Web site.

3.27 Tab Order

Evaluation Procedure

Verify that the tab order of links, form controls and objects follows a logical or thematic order.

Examples

• If a user is required to enter their first name, last name, address and contact number, the tab order should not jump, for example, between the first name and the phone number and then back to the last name.
• If a pizza ordering service offers a choice of toppings and bases, the tab order should not jump between those two categories when presenting the user with options.
• If the Submit button, or Submit and Cancel buttons, are not the last item(s) in the form.

3.28 Tables Layout

Relevant Delivery Context Capabilities

Table support

Evaluation Procedure

Verify that tables used solely for layout cannot be replaced by use of CSS.

Examples

An image or text which is spaced and positioned with the aid of a table is not acceptable.

3.29 Tables Support

Relevant Delivery Context Capabilities

Table support

Evaluation Procedure

Verify that the <table> element is not found within the source code if the device does not support tables.

3.30 URIs

Evaluation Procedure

• Verify that the entry domain, including main and subdomain, can be called up with less than 20 multi-tap key presses on the device.
• Ensure that the entry URI does not require a file extension (such as .html) and that the entry URI does not require the www subdomain.

3.31 Use of Color

Evaluation Procedure

• Verify that , excluding hyperlinks, the page does not include any other blue or purple text.
• Check if, when viewed on a monochrome screen, all content is still readable.
• Verify that color is not used as the sole means to represent any item of information.

Examples

• Red text may be used to highlight error messages but the fact that it is an error message should also be conveyed in some other way without color (such as with asterisks or emphasis using the <em> element).
• Telling the user that important information is highlighted in yellow is unacceptable.

See the closely related WCAG Success Criteria for more.

A References

DDRSA

W3C Device Description Repository Simple API, Jo Rabin, José Manuel Cantera Fonseca, Rotan Hanrahan, Ignacio Marín, Editors, W3C Recommendation, 05 December 2008 (see http://www.w3.org/TR/DDR-Simple-API/)

DIGLOSS

Glossary of Terms for Device Independence, Rhys Lewis, W3C Working Draft 18 January 2005 (see http://www.w3.org/TR/di-gloss/)

MOKTESTS

W3C Mobile OK Basic Tests 1.0, Sean Owen, Jo Rabin, Editors, W3C Recommendation, 08 December 2008 (see http://www.w3.org/TR/mobileOK-basic10-tests/)

MWBP

W3C Mobile Web Best Practices 1.0, Jo Rabin, Charles McCathieNevile, Editors, W3C Recommendation, 29 July 2008 (see http://www.w3.org/TR/mobile-bp/)

TWCAG

W3C Techniques for WCAG 2.0, Ben Caldwell, Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden, Editors, W3C Working Group Note, 11 December 2008 (see http://www.w3.org/TR/WCAG20-TECHS/)

WCAG10

W3C Web Content Accessibility Guidelines 1.0, Wendy Chisholm, Gregg Vanderheiden, Ian Jacobs, Editors, W3C Recommendation 5 May 1999 (see http://www.w3.org/TR/WAI-WEBCONTENT/)

WCAG20

W3C Web Content Accessibility Guidelines (WCAG) 2.0, Ben Caldwell, Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden, Editors, W3C Recommendation, 11 December 2008 (see http://www.w3.org/TR/WCAG20/)