Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006

Comment from the i18n review of:
link

Comment 6
At link
Editorial/substantive: S
Owner: FS
Location in reviewed document:
Sec. 2.2 [link]

Comment:

We propose to add to this section on \"input\" the requirement to provide an adequate input method for the user. Especially for complex scripts like Chinese or Japanese, this is a crucial requirement.

Comment from the i18n review of:
link

Comment 7
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec.2.3 [link]

Comment:

In some character encodings like UTF-8, scripts with a similar number of characters (e.g. latin versus indic scripts) vary in space requirements. To avoid high bandwidth / cost related to scripts, you might propose for such cases the use of the
compression scheme for unicode [link]
.

Comment from the i18n review of:
link

Comment 18
At link
Editorial/substantive: S
Owner: RI
Location in reviewed document:
5.4.12

Comment:

The section mentions the use of the XML declaration for declaring in-document the encoding of XML documents, but makes no mention of the standard in-document declaration of encoding for HTML documents or XHTML served as text/html, which uses the Content-Type meta element. This seems a strange omission. Please add text describing this.

Comment from the i18n review of:
link

Comment 21
At link
Editorial/substantive: S
Owner: RI
Location in reviewed document:
General

Comment:

We believe the document should encourage all participants in the mobile value chain to support Unicode. This is extremely helpful in ensuring international use of this technology and ease of localization of content.

5.4.15 Cache Headers
Proposal for adding a statement [CACHE_CLOCK_SKEW]. Ensure the
site will function acceptably without cache, but explicitly
set cache headers with long expiration times to allow for
clock or time zone inaccuracy in the client.

We believe that Web site access through mobile devices would benefit from the
provision of some minimum-level requirements on terminal capabilities and browser
features. If this cannot be achieved, other work should be referenced.

Accessibility should be addressed more specifically, as the mobile Web (and its
specific issues) does not seem to be in the scope of the WAI/WCAG guidelines 2.0,
currently under updating. The provided cross-referencing is beneficial but it does not
provide enough substance.

Access to the mobile Web through a speech user interface is not covered by the
present draft version. We believe it should be addressed (also as there is excellent
work in W3C to cross-reference), as it is an important accessibility enabler to young
and older users and users with temporary or permanent functional abilities.

Setup and configuration is currently considered by consumers as a major difficulty,
when trying to access mobile services and applications. As this document does not
address setup and configuration-specific issues and it does not provide such
guidelines, it should reference available recommendations and best practices
developed in other standard bodies and fora, in order to improve the user experience.

Chapter 5.2.2.2, How to do it: Provide advice on how to implement device-based wrapping.

Chapter 5.4.13, Error messages: The purpose of error messages should be dual:
1. To provide information to the user; and
2. To provide information to the service provider.
The recommendation should cover both aspects.

3. Security

In order to build commercial services on the web, secure connections are
necessary. In addition, these are widely implemented already. Is there no
requirement to support https connections in the mobile space as a best
practice?

BP Not covered:
1. Don\'t format text as justified.

Text aligned to be justified on both sides is often problematic on the web
in general - on mobile devices with a relatively small range of fonts and
display options, it seriously reduces legibility of content, often at a
cost of some extra processing.

BP Not covered:
2. Identify word breaks.

(This is related to the previous point)

Long words which can be broken should include useful information about
appropriate points to do so by including a ­ or similar.
display options, it seriously reduces legibility of content, often at a
cost of some extra processing.

"From the perspective of this document this means that services should be available as some variant of HTML over HTTP."

Why is the previous statement here? It sounds like it is an assumption about delivery and belongs in the next section.

* The word "exploit" seems like it is being used in the French sense of "make use of". I find that in (American) English it carries a negative connotation, as when one "exploits" a security hole.
* This statement is so broad that it should be dropped as a best practice note. Instead, I recommend that you create a section a the top of the document that explains what the best practices notes strive to allow people to do. For example:
By following the guidance of this document, designers can:
* Learn to optimize their designs for delivery to a mobile device by taking full advantage of device capabilities.
* ....
In short, this best practice note doesn't actually teach me anything useful. Instead, I would like to learn from the document how to do the thing you are talking about. I realize that there is an "abstract" layer and a "techniques" layer and that the abstract point is to take advantage of device capabilities, but I do not believe you have captured the right level in the above note. Instead, if you are thinking of one or two slightly more specific points, I recommend stating those instead of this very general point.

* Please delete "reasonable" (if you keep this one).

* This can be a dangerous point if not worded carefully. See the relatedprinciple in Webarch: " Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf." I realize that in this context one may not always be interacting directly with the user. But "silently recovering from error" is one of the things that I believe the TAG feels strongly is a bad thing.

* Below you say something more interesting, which I paraphrase as "It's ok to not follow some of the other best practices in this document when you need to work around errors." That's a big gate and you should strive to narrow it. Furthermore, you seem to define conformance below "then content providers must comply..." Does that statement belong in 5.1.3.1 or is it a general statement that belongs in a conformance section?

* In my opinion, unless you adopt something more along the lines of what is stated below (a kind of "exception" provision for error conditions) then I think you should delete this one, which, as stated, seems to me to amount to "Do useful things." Again, the note has a very different impact if you are talking about when it's ok to not follow _other_ good practices.

I realize that you have chosen to write the good practice notes in the imperative voice. I also realize that more information is provided below. However, I think the reader might take away a lot more if the points included more rationale. Any many people (including myself initially) may simply look at the checklist and not take time to read the entire document. For instance: "Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember." In light of my previous comment about short labels for the statements, you might end up with:

[Short URIs Are Friendly] Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember.

This is not much longer than what you have and I think the rationale provided (likely imperfect as proposed) makes the statements much more meaningful.

* Access key support on traditional desktop devices is problematic at best. I do not know about the current state of support from the WCAG WG for access keys (looking in the WCAG 2.0 techniques, I find only a placeholder). Is access key support on mobile devices expected to be more interoperable?

* I am not sure what you mean by this checkpoint. Through Internet protocols I believe two parties can agree on whether a client supports a particular format available on the server. So do you mean that after such a negotiation, in (adapted) content you serve, you don't have to provide information about the format? I don't think you mean that, in particular because I think that would imply lots of communication about all the links in a document to determine the format of identified resources. * Other than through Internet protocols dynamically, I don't know how you can "know the device supports" a given format unless you are designing in a very closed environment, and I thought that the purpose of these guidelines was to explain how to design effectively in anopenenvironment. * Perhaps you can shorten this, therefore, to something like "To help users reduce the cost of unnecessary downloads, for pieces of content in formats that are not part of the default delivery context, identify the format in links."

* I have a similar concern as above about "unless you know." I think that some of these checkpoints make more sense at certain points in a pipeline than at others. For instance, I as a human author probably don't know whether a particular user agent supports this or that. On the other hand, a piece of software that is actively involved in some protocol negotiation and that is doing content adaptation may very well have that information available. But the points are written for multiple audiences and therefore may be confusing.
* What is "an available geometric shape"? I think you mean that the format supports the shape.

* In developing UAAG 1.0, which addresses these topics, we distinguished two concerns (1) the (visual or other sensory) disorientation caused by suddenly opening windows and (2) the change in focus. * I urge you to recast these in terms of thecheckpoints of Guideline 5of the UAAG 1.0 Recommendation. I am happy to discuss them further with you to help answer any questions. * In particular, an important point is that it's ok to do these things when the user says it's ok. * For the point about "unless you have informed the user", that may be locking up the barn after the horse has been stolen. I think it's more important to provide an alternative.

* Please delete this point. I believe the purpose of this entire document is to explain to the reader what it means for content to be suitable for use in a mobile context. Do you mean "suitable" in the sense of "not offensive"? [I don't think you do; just checking.]

I believe that the above checkpoint no longer exists in WCAG 2.0. I have not followed that debate recently, but I believe that it is so contentious as written (and not verifiable in any obvious way in that formulation) that you will regret having included it. I recommend talking to the WCAG WG about the evolution of their thinking in this area.

* How are you defining "what the user has requested?" Does that mean "Implement HTTP GET"?

* I think the point of this document is to define what "usable" means. Therefore, I don't think you should have a checkpoint that says divide pages into usable pieces. Tell us instead what makes a piece usable.

* The first sentence of the second point here can be generalized to be "don't do things that the device can't handle." Because I don't think that is known in all cases, I suggest you delete the first sentence. Perhaps rephrase the point in terms of the default delivery context: "Very large or high-resolution graphics are unlikely to achieve their desired goal when rendered on devices with small screens. Avoid them unless there is no other way to provide the information in question." * In some cases, people may wish to download images for viewing on another device (e.g., I store something on my phone then view it on my desktop computer). You may wish to remind the author of that scenario.

* Please stick very close to WCAG 2.0 on this one as well (I think it is 1.4.3).

* Please delete "unless the device is known not to support them" in favor of a general section on handling this sort of thing (as described above).

* This also comes from WCAG, but I no longer see it in WCAG 2.0. Have you asked them why it was deleted? (I don't see it in the23 Nov 2005 draft)

* Delete this point and add to the list of things to "keep short": markup.

* Please delete "Where possible" * I suggest merging these two into a single point about following standard protocols for content type negotiation.

* "to a minimum" is not well-defined. * Add this to the list of things to keep short.

* Delete "appropriately" (twice) * By "explicitly" do you mean "through markup language features" (such as the "for" attribute in HTML)? * Please be more explicit about what appropriate positioning is rather than make this general statements. Is "before" better than "after" in reading order?

Hello all,

i remember there was some discussion whether MWBP promotes One Web or
not, but in any case, i guess one goal of the *document* is to explain
different kind of approaches or strategies how Web can be served
for/accessed via mobile device.

"The primary goal is to improve the user experience of the Web when
accessed from such devices."

However, it seems that the document is concentrating mainly on authoring
process. As we can change the existing Web very slowly, it would be
informative for non-mobile Web experts to illustrate already existing
Web to Mobile adaptation processes, which are based on proxy based
conversion. These conversion proxies provide the most widest Web to
Mobile resource today.

Here are some examples which kind of proxies i mean:

WEB TO MOBILE

Google's quite new HTML -> XHTML MP converter:
<link>
MWBP document (WAI) conversion as an example. This converter can handle
even forms.

<link> (Opera Software MIDP browser based on proxy
adaptation. This combination enhances site and browser usability)

HTML-> WML conversion
<link>
<link> (handles forms also)

Maybe it should explained more clearly, why WAI guidelines - for example
- do not cater mobile devices enough. In my opinion, different kind of
Web to Mobile proxies should be studied in the future working groups -
especially with content conforming relevant (and existing) WAI guidelines.

It is said, that the mobile handset can be the only Web device for many
users in the third world. That is why it is important to note, that
conversion proxies might be someties the only way to get information
from the Web.

Kind Regards,
Mr. Ville Karinen
Student (Agr. & For.)

_5.3.1 URLs of Site Entry Points_

Here, if URLs for a menu system running into more than 5 pages can
follow a URL syntax containing page numbers such as:

link

then it becomes easy for the user to navigate between pages, just by
changing the page number on the URL, through the bookmark. Of course, if
the browsing application itself could provide a page browser using this
syntax, the user\'s task of navigating through pages would be much easier

_5.3 Navigation and Links

_All the URLs for each page, must be listed in the options(or right
click) menu, so that if a user he/she wants to go to a URL on the page,
he/she just has to scroll through the options(or right click) menu to
reach the required URL.
then it becomes easy for the user to navigate between pages, just by
changing the page number on the URL, through the bookmark. Of course, if
the browsing application itself could provide a page browser using this
syntax, the user\'s task of navigating through pages would be much easier

_5.3.7 Link Target Identification

_The cost of following a link,as in the case of articles, should be identified in the number of pages which are required by the article, as is done by the BBC Wap page.

Hence we get a link at the bottom of the first page of the article, which says \"_Continued Page 2/4_\".
The user is then able to choose whether he/she wants to read a 4 page article, or whether he/she should look for another article.

1.4 Default Delivery Context
There is an entry for screen width, but not height. I think that there
should be some value for a default screen height.

2.2 Input
Discusses the potential lack of back button support, but in section 1.4
the default device supports XHTML- Basic. Is it not reasonable that if
the default is assuming XHTML-Basic then the target default handsets
have back buttons?

What does the group consider a proper range for short URLs?

5.3.4 Navigation Bars etc.
This is a good idea, but it makes me wonder how possible the one web
vision becomes. If one wants to create a page that can provide an
optimal display, the developer would need to do quite some work or use a
powerful platform. I fear that some developers may give up trying to get
the mobileOK mark if it becomes too difficult.

5.4.6 Image Size
[IMAGES_SPECIFY_SIZE] Are there actual examples where not setting the
width and height of an image actually hurts the display of the image by
the browser? I am not so sure how necessary this is, especially when
considering that providing this information increases the size of the page.

5.4.13 Error Messages
This is also a great idea, but some handsets ignore the developer’s
custom HTTP 5xx response and shows a built in error message to the user.

Please say about the participants in the mobile value chain s.t. like "these participants are working with multiple languages ...".

Comment from the i18n review of:
link

Comment 2
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 1.3 [link]

Comment:

On scope of MWBP 1.0: Please give internationalization as another example of general good practice which have a specific mobile interpretation.

Comment from the i18n review of:
link

Comment 3
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 1.3.2 [link]

Comment:

On aspects of usability: Please mention that proper localization is part of localizability, e.g. in the case of site usability, device usability or browser usability.

Comment from the i18n review of:
link

Comment 8
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 2.4 [link]

Comment:

Travel related information might not be useful in a mobile context, since there might be no resource for translating. Please mention the need to make it explicit in the content that such resources are missing.

Comment from the i18n review of:
link

Comment 10
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 2.7 [link]

Comment:

Your mention the importance of mobile devices for developing countries. Esp. for these countries, internationalization and localization issues are crucial (e.g. support of a font for the script). such requirements should be made explicit in this document.

Comment from the i18n review of:
link

Comment 11
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
General

Comment:

You don\'t have any normative references. Is this intended, and if yes, why?

Comment from the i18n review of:
link

Comment 12
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
General

Comment:

In sec. 4.2, you describe the structure of Best Practice Statements\". Nevertheless, many Best Practice Statements leave parts of this structure out. Will this be changed in a future version of this document?

Comment from the i18n review of:
link

Comment 14
At link
Editorial/substantive: S
Owner: FS
Location in reviewed document:
Sec. 5.2.7 [link]

Comment:

Please mention that if in the content there is a link to something which is not in the same language, it would be good to make it explicit.

Comment from the i18n review of:
link

Comment 17
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 5.4.13.2 [link]

Comment:

\"Please consider proposing that it would help bandwidth to store standard messages in the device itself, rather than download them each time.\"

User Agent (browser) developers are participants in the mobile value
chain. The user agents for mobile devices should conform with UAAG
[1] guidelines as appropriate. This is especially true now that some
mobile devices have add-on assistive technology such as screen
readers.

The document's purpose is aimed more at content developers rather than the
tools to render the content. Underlying this purpose is a continuing
discussion of the limitations of the devices and user agents involved (such
as screen size, color depth, input limitations, memory, etc.)

[linkage opportunity from WAI document]
(1) I can imagine a full version of the doc playing the same role in the ATAG
conformance model that WCAG does (i.e. as a standard that an authoring tool
guides the author towards conformance with). Perhaps a note to this effect can
be put into ATAG 2.0.

[linkage opportunity from MWBP document]
(2) Clearly all the adaptive stuff in the doc would require authoring tool
support. Therefore, the Mobile Web group might consider putting in an
informative note about the role of authoring tools (and ATAG) just as WCAG
has. This is the text of the WCAG 2.0 note:

"
A large part of Web content is created using authoring tools. These tools
often determine how Web content is implemented, either by making authoring
decisions directly or by limiting the choices available to the author. As a
result, authoring tools will play an important role in creating Web content
that conforms to the Web Content Accessibility Guidelines. At the same time,
we recommend that all authors become familiar with the Guidelines because this
will help in creating accessible content and coverage of the Guidelines may
vary between tools.

Developers of authoring tools can help to make their tools more aware of the
Web Content Accessibility Guidelines by following the Authoring Tool
Accessibility Guidelines. We encourage users and purchasers of authoring tools
to consider conformance to the Authoring Tool Accessibility Guidelines as a
criterion when selecting tools.
"

5.29 Refreshing, Redirection, and Spawned Windows
should reference
UAAG 2.4 Allow time-independent interaction (P1) - 1. For rendered content
where user input is only possible within a finite time interval controlled
by the user agent, allow configuration to provide a view where user
interaction is time-independent.

UAAG 3.5 Toggle automatic content retrieval (P1) 1. Allow configuration so
that the user agent only retrieves content on explicit user request.

5.3.7 Background Images
should reference
UAAG 3.1 Toggle background images (P1) - 1. Allow configuration not to
render background image content.

5.4.3 Structural Elements
should reference
UAAG 10.4 Provide outline view (P2) - 1. Make available to the user an
"outline" view of rendered content, composed of labels for important
structural elements (e.g., heading text, table titles, form titles, and
other labels that are part of the content).

1. The title of the document is somewhat confusing. The present document is definitely
not about best practices for mobile network and system capacity optimization for
reliable mobile Web access or other, related technical issues. As the document is
providing best design practices of Web sites accessed through a mobile network and
a telecommunication terminal, we suggest the title to be updated to “Best Usability
Practices for Mobile Web Sites” (in accordance with the last sentence in chapter
1.3.2).

We have the impression that the development process of this draft was somewhat
forced to be somewhat too fast. We would recommend to leave more time for
stakeholder’s involvement and qualitative fine-tuning, when developing future
deliverables.

A terminology issue: a device does not necessarily have a network connection and a
user interface (e.g. a pencil or a wrist watch). We would like to know if this is defined
differently for the purpose of this document (the definition is not included in the draft).
Otherwise, we consider proposing to use “devices with a network connection and a
user interface”, or simply, “terminals”, in the entire document.

Chapter 1.3, Scope: The WCAG guidelines reference should be more specific, refer to the
latest version or relate to the WAI guidelines family, where applicable.

Chapter 1.3.2, Usability:
- There are more than three aspects of mobile usability but there are three aspects of
mobile Web usability (add “Web”).
- The relation between these aspects should be described in detail (not only their
individual characteristics). This description should include accessibility.
- Site usability is not only about effectiveness (see definition of Usability).

Chapter 2.1, Presentation Issues: In addition to the controls not being presented as
intended, other issues such as the lack of the necessary interaction control elements and
functions should be mentioned.

Chapter 2.2, Input: “…hard to type…” should be replaced by “…difficult to enter…”. As this
is a far more complex issue than just entering characters, aspects relating to the support,
handling, mapping, sorting and transmission of characters should be addressed.
This change should also be considered with respect to the fact that speech technology
enables and improves access to ICT (including mobile terminal devices and the mobile Web)
for disabled people (e.g. people with upper limb impairments) and very young children, who
will be able to input data and interact with mobile devices through speech user interfaces.

Chapter 2.3, Bandwidth and Cost: In addition to transmission speed, there are setup,
configuration, access right, reliability, home network cost issues and roaming cost issues
involved. These should be addressed or at least, mentioned. See also comment on chapter
1.3.3 above.

Chapter 2.4, User Goals: The first sentence should be rewritten. See also comment on
chapter 1.3.3 above.

Chapter 3, Delivery Model Architecture: The entire section after “3” should be numbered
separately (e.g. made 3.1 Introduction).

Chapter 5.1.1.2, How to do it: The references should be made more explicit.

Annex A, Sources (Non-Normative): It would be highly desirable to reference WCAG 2.0
(under drafting) instead of the outdated 1.0 version from 1999.

I suggest "This document only includes best practices that primarily affect mobile access to the Web." You may also wish to have a look at some of the verbiage insection 3of UAAG 1.0 (on Conformance). For instance, adapting this text might be useful: "The UAWG expects conformance this document to be a strong indicator of accessibility, but it may be neither a necessary nor a sufficient condition for ensuring the accessibility of software. Thus, some software may not conform to this document but still be accessible to some users with disabilities. Conversely, some software may conform to this document but still be inaccessible to some users with disabilities. Some requirements of this document may not benefit some users for some content, but the requirements are expected to benefit many users with disabilities, for general purpose content."

A very important feature of the WAI Guidelines is that they work together to identify different responsibilities among authors, user agent designers, format designers, and authoring tool designers. WCAG does not hold up well in some cases when browsers don't take advantage of features that authors expect to be supported. Does the MWI BP WG plan to produce other guidelines than these content guidelines?

As you'll see below, I think you may wish to refer to some of the guidance of theUser Agent Accessibility Guidelinesas well.

I think the problem is that it's hard to type, period. People should not be typing URIs anyway; they should be using search engines and following links.

I note that the previous concern also holds for many desktop environments, including very common one likes in companies or libraries where people often cannot install arbitrary software or configure their machines freely. Is this even more frequent on a mobile device?

Does this mean that you will have best practices for error handling below to avoid incomplete display or other problems?

Ah, that last sentence is already more informative in my opinion.

That last sentence is a good place to start for this entire document. But there are other sentences that talk about One Web that might be pithier. I think you can drop "as is practical" and all similar qualifiers in favor of a section in the document about the general authoring context.

* How does this apply to prefetching?

The previous paragraph is not the same as "limit content to what the user has requested." It is separate advice for good authoring for the Web generally: Front-load pages with important information. You make this point later on, so I think you should move this explanation to later in the document.

* I think it is very important that this document adopt the language used by the WCAG WG. They have spent a very long time discussing this topic. For instance, for the first point, copying from the 23 Nov 2005 Draft,section 1.3.1: "When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors." If you have a reason to say something other than what WCAG 2.0 says, please explain below. (In general, if another W3C Recommendation says what you want, whether it is WCAG 2.0 or UAAG 1.0, Webarch, or another document please use that language or be sure to explain why you have chosen not to.)

* A theme has emerged: "Keep it short". I think you have points related to shortness of URIs, titles, and pages. Perhaps they can be merged.

* Please provide a bit more rationale, as in "Because they are not widely supported in the mobile context and also are widely known to be problematic for users, do not use HTML frames."

* This is another instance of "Don't do X" when you are outside the default delivery context; regroup with those?

* Please provide more rationale for this one, which I did not understand when I first read it. Something like this might help: "Because mobile devices have limited processing capabilities, make available small versions of images rather than require resizing after delivery."

* Adding more rationale: "To enable flexible display, use relative units (e.g., "em") rather than absolute units (e.g., pixels) when specifying dimensions (e.g., shapes or font sizes) in formats such as markup languages and style sheets."

* Delete "where possible" * Provide more rationale: "Because text entry is time-consuming and prone to error, avoid interfaces (such as text entry boxes) in favor of other types of controls (e.g., menus or radio buttons).

* Delete "where possible"

_3.7 Advantages:_
The mobile device has added advantages compared to a desktop or a
laptop, which are:

1. Always On:This device is always on, and always has phone
connectivity. Hence websites have the ability to directly connect
a user with a phone number, or IP address, if the requirement
exists.
2. Accessibility to near field devices, via infrared, Wi-fi,
bluetooth and USB(but this option is far less used!), such as car
audio systems, music players, cameras, gaming devices.
3. Added capability for Wearable computing , where the mobile device
may communicate with other devices, using the means mentioned above.

2.6 Device Limitations

The word \"Device Limitations\" is not right,

The main interest here, should be to to first make note of the fact that the
mobile device, has an evolution which is very isolated from the evolution of
the PC.

The mobile device was evolved from the Telephone, rather than the Desktop
PC. Hence, the mobile device as it currently exists, is an advancement of
Graham Bell\'s invention, rather than a downgrade of Charles Babbage\'s
invention.

Where it goes, from there, is an advancement to a cornerstone of the
virtual, online, World.

The mobile device is slowly becoming a key component of the wearable
computing phenomena, where multiple devices, will use the mobile device as a
central point of control and storage.

Hence \"Differences between the mobile device and the computer\" would be the
right word to use.

2.7 Advantages

A point to add:

The mobile is destined to be a universal point of data storage, and
execution, rather than a data creator. This is greatly due to the various
means of device-device communication available to the mobile, such as the
operator network, Wi-fi, Infrared, Bluetooth, audio ports and USB ports.
5.2.6 Access KeysAccess keys, should be made accessible, according to
prevalent usability standards.
One standard, would be that page up and Page Down keys, must be permanently
hard-coded, to make navigation of a page, less arduous.
One suggested implementation, is to use a slider key for the volume, during
the phone mode. Then, when the browser is activated, use the same slider key
as a Page Up-Down key.

5.1.3 Work around deficient implementations
“It is recognized that content providers may need to violate specific
best practices in order to support their intentions on devices that
exhibit deficiencies in implementation. If a device is not known to have
specific limitations then content providers must comply with best practices”

My question is the use of “must comply” is a bit strong, because there
can be cases where developers and the W3C differ in opinion on whether a
certain device has limitations. In areas where interpretations differ
this may prevent the developer from getting the “mobileOK” mark. Who and
or how are agreements going to be made about when a device is known to
have specific limitations?

Comment from the i18n review of:
link

Comment 19
At link
Editorial/substantive: S
Owner: RI
Location in reviewed document:
5.4.12

Comment:

The document doesn\'t say that the encoding should be expressed using the HTTP header, so the test should not assume that either. It should probably say something along the lines of \"Check that the encoding is declared. This could be done in the HTTP header or the XML declaration for documents served as XML, or in the HTTP header or the Content-Type meta element for documents served as HTML, or in the HTTP header or the @charset statement for CSS stylesheets.\"

Comment from the i18n review of:
link

Comment 20
At link
Editorial/substantive: S
Owner: RI
Location in reviewed document:
5.5.1

Comment:

\"Specification of the natural language in use assists with predictive text input.\"


It is unclear to us whether this refers to standard mechanisms in X/HTML to declare language, or to a declaration specific to input modes. That should be made clearer. (If you were referring to input mode settings, we feel it would also be useful to encourage declaration of the language used in content using standard mechanisms, since that assists with not only predictive text input, but also styling, font selection, etc.)


Whatever the above refers to, this section contains no other information about how to do it, and how to test for it. This should be added.


(The i18n tutorial
Declaring Language in XHTML and HTML [link]
may be helpful here for you to understand what i mean by \'standard mechanisms...\'.)

5.2.3 Balanced Structure
It is not clear, whether this is indicating some mathematical
balance. We believe a site should be \"balanced semantically or
by importance.\" It makes no sense to always make the depth of
all links similar. In fact, the first links should be directly
to commonly-used information, while later links may lead to a
deeper tree of less-often-used features. This is really
important to explain well.

5.3.3 Scrolling
There could be a stricter recommendation: Limit scrolling
while reading a single text flow to one direction.

5.3.5 Graphics
Proposal for adding a statement [MANY_GRAPHICS]. Avoid many
images in one page, because each request on a wireless network
adds significant latency compared to fixed networks.

Chapter 1.3.3, One Web: With the currently available technologies and implementations
(and considering the product generation gaps), it is not always desirable, beneficial nor
affordable to consumers to access the same information, provided on the same format,
regardless of the access network and device.
Although technology will improve continuously, consumer requirements will be strongly
influenced by the context of mobile use (on the move, limited screen and keyboard,
disturbing environment, et cetera), will not change that radically.
Due to the context of mobile use, terminal capability variations, bandwidth issues, access
rights and mobile network capabilities, this principle should be reconsidered.
Even if it is easier to develop content for one Web, there are specific issues that need to be
addressed.
Providing a good and affordable mobile Web user experience becomes even more important
to roaming consumers (presently, there is no low-cost global roaming tariff plan for mobile
data devices).
We would like to discuss the approach taken and would appreciate to hear your arguments
for the “One Web” approach taken.

Chapter 1.4, Default Delivery Context: More detailed specifications should be provided. In
addition, possible fall-back solutions should be mentioned.

Chapter 5.2.1, URIs of Site Entry Points: The recommendation should be updated to cover
aspects of direct manipulation (clickable) and character entry support.

Chapter 5.2.6.1, What it means: This is a far more complex problem than just the limited keyboard (12-key keypads and soft-and hardware-based keyboards should be covered). In addition, aspects relating to the support, handling, mapping, sorting and transmitting
characters should be addressed.

2. Colours:

There are a number of interpretations of "websafe" colours - please
provide a reference that unambiguously states which colours are expected
to be available.

4. HTTP

It is not clear that any transport protocol is guaranteed on the device.
Given the requirements to support the regular web, and in particular such
things as 30x HTTP responses, it would be appropriate to specify a level
of HTTP support in the default characteristics. mobile space as a best
practice?

5. Style sheets

XHTML Basic does not include any support for internal styles. It makes
sense, given the problems of latency that are a key constraint in the
mobile space, to mandate support for internal styling, but it is not clear
from the current wording what support can be expected (and therefore, as
an implementor, what support we are implicitly being required to provide).

There are many types of content which do not require any adaptation. There is no point in these services determining any kind of context. Further, there is no point in determining context in any circumstances for a service that cannot make use of the information.

This is not a best practice in itself, merely a technique that can be used
to meet some others.

In addition, as has been noted by others, having it appear first gives an
impression of a strong bias against the one web goal stated elsewhere.

cheers

Chaals

BP Not covered:
3. Use Device-independent event triggers

in HTML, the onmouse* and onkey* triggers are somewhat difficult to
trigger from the range of devices available. onclick is generally
implemented in such a way that any device can trigger it, and mutation
events (form changes, page load, etc) do not rely on a particular user
interface anyway.

BP Not covered:
4. Balance page weight and latency

In a number of cases it will be appropriate to provide a choice between a
large page and the same page broken into appropriate chunks. (Browsers
like Opera mini will in any case break a page into appropriate sized
pieces for phones that need this done).

It can also be important to decide what resources to include externally,
and which to include in the page. Use of the data: URI scheme can allow
small images to be included inline (as can SVG where supported by the
browser), and stylesheets and scripts can likewise be incorporated in the
page, reducing latency effects caused by fetching multiple resources, or
linked to allow efficiency from decisions on whether to load them and from
caching.

The requirement expressed by [CONTEXT] is only necessary for some kinds of
sites - it is really a technique that needs to be used to meet some other
requirements in certain circumstances.

In addition, having it first in the list of best practices suggests that
there is a huge amount of work to be done in order to deliver any
worthwhile content to the mobile web that is not required on the web in
general. This is simply not true as a general statement.

cheers

Chaals

There may be some other exceptions required to this, for borders and
margins. These are commonly specified in pixels, and this may be
appropriate in a number of cases.

cheers

Chaals

There are some types of image, such as SVG, where a pixel-based size is
unnecessary or inappropriate. In such cases it is often appropriate to use
CSS to specify width/height rather than HTML attributes.

cheers

Chaals

This draft is better than previous drafts in that it
has an explicit "One Web" section. But the first
best-practice guideline is still:

"[CONTEXT] Take all reasonable steps to find out about the
device/browser (client) capabilities, adaptation and other
transformation that takes place for any instance of an access to a
resource."
-- link

Guideline #1 should be: design for device-independence.

Or something like that.

In simple cases, one HTML document should work well
across a variety of devices.

But even for high-profile sites with dedicated production staff,
where server-side content adaptation is worthwhile, designing
for device independence is still a good idea; lots of content
and navigation should be shared across devices.


Ah... 5.2.4 Thematic Consistency of Resource Identified by a URI
Much better. How about starting with that one?
It's a bit of a mouthful, though.

I don't see much justification for "... find out capabilities..."
and I notice there's no "what to test" subsection for it.

Section 5.3.7 states:

[BACKGROUND_IMAGE_SUPPORT] Do not use background images unless you know
the device supports them. (Normative)

I don't see any reasoning in the document to justify this one, and I
can't think of any myself. Won;t a device that doesn't support
background images simply ignore them without any detrimental effects? I
can;t think of any examples in practice where the background image was a
critical part of the content. This feels like it would degrade gracefully.

At a minimum, I would ask that this normative rule be explained more.
But if there's no good explanation for this, then this rule could simply
be dropped.

The terms "easily" and "efficiently" are almost unused in the document. In my opinion that do not add much information where they are used and might be safely deleted from this part of the document and from the best practices below.

I suspect this entire section could be reduced without significant loss of information to the following:

The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability (for reading, navigating, and interacting with content) and device usability are important, this document focuses primarily on best practices for improving site usability.

"As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place."

The previous paragraph needs to be adjusted. The text (which may have come initially from the Communications Team!) suggests that there are two Webs: one fixed and one mobile. That is not a message we want to communicate. The point is that we want one Web and that we want to improve mobile access to it.

This point is problematic on several fronts:
* "Reasonable" is not well-defined. That term may work well in some contexts (such as a patent policy, where people are used to it). I think you should avoid it in this document. Alternatively, say once up front in the delivery context section what you mean by "reasonable".
* I am not sure who is responsible for carrying out this task. Is this the responsibility of someone who is producing content? It doesn't feel like it.
* You say to do this for "any instance of an access." Even when there is caching? It may be that in that case I haven't accessed the resource, but I'm not sure of that, so it may be worth clarifying.
* This should not be the first best practice note --- this is about content adaptation. I think it is important to start with the message: Design for one Web! Then, talk about how to improve the user experience above and beyond that.
* The statement seems overly general. What about saying something a bit more specific, like "Follow published standards when determining device capabilities for the purpose of content adaptation."

* How do you define a "deficient" implementation? It sounds quite subjective to me. Do you mean implementations that do not conform (strictly) to standards? Otherwise how would you classify something as deficient or not? Do you mean "known bugs"?

* If you really mean "should be enough" then say "Provide between 2-4 links at the top of a given page for navigation to important parts of the page." That seems to me to be more useful than saying "minimal navigation." Find the 80% point, say it, and then let people adapt for other cases as required (and explain to them when they might encounter those cases). * In the same spirit as my comment on the previous point, you might rephrase this as:[Navigation helps in small doses] Providing 2-4 links at the top of a page to important content in the page facilitates navigation. Many more than that hinders navigation.

* Does "link on page" mean that it links to something on the current page, or could it also be a link that points to a different page? * I don't know what "balance" means here. I imagine it means "roughly equal to in number," but it may not be about equality. * Does "depth of navigation" mean "to other pages"? * Do you mean something like "Users tend to give up if they have to follow more than 2-3 links in order to find something." * I hoped I would understand this point better by reading the "What it means" text, but the first sentence is confusing: it uses "navigation links" and "navigate multiple links" as though they mean something different, but the phrases are very similar.

* You refer to "links"; do you mean "what you get when you follow the link?" * I suggest expressing this point in terms of serving roughly equivalent representations rather than in terms of links. * You might want to citeWebarch section 3.5.1, which says "A URI owner SHOULD provide representations of the identified resource consistently and predictably". * Since this is the "One Web" point, I think it belongs at the front of the document. You might want to retitle it "One Web Principle" rather than "Thematic Consistency". * You might want to simplify to "[One Web Principle] Because you never know for sure who will be reading your content (and their device, browser, and human capabilities), you should start by designing for a broad audience, then optimize your content for targetted audiences."

* You might want to shorten this and combine it with the next point as follows:[Describe Link Targets] To help users decide whether to follow a given link, provide this information about the target of the link: * What it is, in clear language * How large it is (which may imply a time-consuming download) * The file format (which the user may know is not supported by the device). * I would note that in UAAG 1.0 we require the user agent to provide some of these services so the author doesn't have to; seecheckpoint 10.5. That helps address part of the goal of the following point about "knowing" whether the device supports a given format.

* Delete "if they can be determined". This is an instance of a qualifier that weighs down the point you are making and should be described elsewhere.

* What do you mean by "direction"? Do you mean "down, not up"? Do you mean "Don't make people scroll horizontally? * Delete "unless secondary scrolling cannot be avoided." In general, delete "except where impossible" as I've mentioned above.

* I do not understand how this point differs from the previous one.

* This is another instance of the general point "Don't do X". I think you should regroup all of those points in one and relate them to the default delivery context.

* Please stick very close to WCAG 2.0 on this one as well.

* Perhaps you can be more specific about HTTP (is it "accept" headers?) since that is an explicit assumption above. * The user may wish to receive content even if its device does not directly support it (e.g., to save and use it later). Please make it clear that the user can, on demand, request content that is not supported by software on the client.

5.2.2 Navigation Bar
I am not quite certain if having a navigation bar on the top page and
having the navigation links on the same line is really a best practice
that I agree with. Perhaps providing a definition or example of what a
navigation bar is for a mobile site would help those who disagree with
this. In many cases having navigation items like home and back links of
the top of the page distracts the user from viewing the content that the
user is currently looking for. The user must skip through a number of
links before getting the view the content, which is not desirable in
some cases. In such an example I think that having the navigation bar at
the bottom is preferable when the user has found the searched for
content. Although, in the case that the current page is not what the
user is looking for having the navigation at the top is certainly
better, for the quickness of getting out of the page. Perhaps this
section could use a bit more explanation. This may be a difference of
interpretation depending upon the if the handsets force the user to
traverse each link or can skip links that are on the same line.

5.4.5 Non Text Items
The way that current i-mode handsets deal with handsets that cannot
support the object tag differs from this recommendation. This may make
many i-mode sites break the best practices rules. You can refer to the
following link for more detail:

link

5.4.14 Cookies
Does this prevent systems that make use of Set-Cookie to determine if
the phone supports cookies from getting the mobileOK mark?

Comment from the i18n review of:
link

Comment 4
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 1.4 [link]

Comment:

Please point to the specification
XHTML Basic [link]
.

Comment from the i18n review of:
link

Comment 5
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 1.6 [link]

Comment:

This section seems to fit better at the beginning of the document.

Comment from the i18n review of:
link

Comment 9
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec. 2.7 [link]

Comment:

Please correct the line break before \"communications.\".

Comment from the i18n review of:
link

Comment 13
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
General

Comment:

CDFWG is in the references, but not in the text.

Comment from the i18n review of:
link

Comment 15
At link
Editorial/substantive: E
Owner: FS
Location in reviewed document:
General

Comment:

UAProf is mentioned several times in the text, but not in the references. We guess you mean
UAProf profile repository [link]
.

Comment from the i18n review of:
link

Comment 16
At link
Editorial/substantive: E
Owner: RI
Location in reviewed document:
Sec. 5.4.12 [link]

Comment:

Please refer to the tutorial on
Character sets & encoding in XHTML, HTML and CSS [link]
, and the QA on
Setting encoding in web authoring applications [link]
, instead of the \"HTTP charset\" document.

section 3.1
which ever content adaptation implementation model is used, the model must retain necessary accessibility information (alt, label, etc.) and convey that information to the mobile device and the user.

Chapter 1.1, Purpose of the Document: The purpose should stretch beyond “…to promote
more effective delivery…” and provide design guidelines applicable to the usability and
accessibility of the mobile Web or, at least, specifics of interacting with mobile Web sites.

Chapter 2.7, Advantages: “Connected” should be added to the popularity reasons.

Chapter 5.1.4, Testing: Update the recommendation to “…devices and provided specific
software versions…”.

Chapter 5.2.4.1, What it means: Connectivity and download speed issues should be
mentioned.

This Best Practice should require that content not rely on scripting,
unless the delivery context is known to support them. Some mobile browsers
allow the user to turn off javascript (handy where you are trying to save
battery).

It should also lean away from using script unless necessary - it is one of
the more battery-intensive ways to do most things.

It should also cross-reference requirements on page size, and a best
practice on page size vs latency (see Opera's comment on "missing points")

cheers

Chaals

1. Meaning

The text does not make it clear whether the characteristics are minimum
specifications, or actual specifications that should be assumed. For
example should a developer assume in the absence of other information that
the width of a device is 120 px, or that there may be no more than 120 px
width available.

[This is a comment on Mobile Best Practices, but cc'ed to WCAG as a
comment for them on text the are currently using]

The wording "Ensure that perceivable structures within the content can be
programatically determined", copied verbatim from the WCAG working draft,
has proven to be very difficult to understand for the majority of the
developers I have ased to comment on this draft (which is only a couple of
dozen).

Perhaps something more straightforward, like "use markup, properly" is
simpler for a title, with the current title moved into the "what it means"
session as a couple of sentences.

cheers

chaals

Testing for the absence of tabindex, and the absence of complex layouts
(absolute positioning, etc) should also be enough.

cheers

Chaals

Another test for this is to see if there is rendered content that is not
inside a table - if there is none, it is quite likely that tables are
being used for layout. (Even more so if there is no caption or summary
element on the outermost table).

cheers

Chaals

Rather than the negative "Do not take a least common denominator
approach", this could be better phrased as "... to maximise usability" or
something similar. It needs to be clear that while thispractise does
authorise sending enhanced content to users who are clearly able to make
use of it, it does not authorise breaking the "one web" principle and
simply ignoring users (provided they have at least a "baseline-capable"
device).

cheers

Chaals

Please start early with the "One Web" message, for example by adding something like this to the end of the preceding sentence: "An important Web design principle (discussed, for example, insection 4.3of "Architecture of the World Wide Web") is to design content that is flexible enough to enable a valuable user experience for a variety of devices. This document explains how to design for "one Web" while also optimizing for the mobile experience."

What does "in context" mean?

I suggest merging the previous two paragraphs; I otherwise was unsure about the mobileOK trustmark in the paragraph where it was introduced.

The first reference to "phase of work" is confusing. Does it mean "phase of this WG?" or "phase of this document"? Please clarify. It may be described in [Scope], but I think you need to provide a short summary of what "phasing" means or of what the phases are.

What does "perhaps" mean here?

The document says "as far as is possible." When is it not possible? I think you can safely say that it is considered "best practice not to exclude access." You don't have to add disclaimers. If there are specific cases that you are thinking of (e.g., there may be privacy or security reasons), please call them out rather than say "as far as possible." I make similar comments below.

The first sentence confused me because the title of the section includes "context" and the first sentence includes "content". I thought it was a mistake at first. It might help to say very quickly that there are two things discussed; context and content.

I find "pointer to" to be very informal.

I think "Appendices" is more common than "Annexes" in W3C specs.

What is an "entertainment application"? Do you mean a game?

I am not sure what implicit user identification means. Also, it sounds ominous to me, and therefore I'm not convinced it is always an "advantage". Do you plan to address privacy concerns?

See also previous comment on "phase"; I suggest a link to where the term is first explained.

I think you can cut this entire section (4.1). The explanations do not add more than the text in the <dt>. I find they are not necessary anyway to my understanding of the document.

There is an editorial problem around "by using URI reference composed" in the previous paragraph. Also, I think you should use "URI: instead of "URI Reference".

In both WAI Guidelines and theWebarchdocuments I worked on, we found it useful to provide short mnemonic labels for best practices and similar statements. In Webarch, we created a navigation bar to the statements at the top of the document (after the TOC), so people could access them individually and rapidly.

You say "how to do it" and then don't say how to do it --- you just say "don't make the user do X." Instead, what about talking about how to configure the server to do the right thing for index.html or similar?

If "The device will take care of wrapping" is true enough to be stated as you have done, then add a best practice note: "Do not put explicit line breaks in navigation bars because browsers on mobile devices will do the right thing." or something more eloquent.

* Because the word "use" suggests "user", I recommend making this sound a bit more clearly like it is intended for authors. "Provide navigation mechanisms that are consistent across pages." [If you mean something else, then that's another issue.]

* The key [CENTRAL_MEANING] is less communicative than "Frontload important information". See my earlier comment about using short labels that capture the essence (even if imperfectly) of the point.

The first sentence of the previous paragraph is more communicative than 5.2.2 as written.

* Why do you use "Always" here and not in other points? I recommend deleting "Always" for the same reason I suggest deleting "when possible". * What about markup languages that don't support this?

* Delete "as possible", and * Add this to the list of things to "keep short"

* Perhaps "tab order" is the term of art. Do people use a tab key on mobile devices? In UAAG 1.0 we talk about "sequential navigation" (distinguished from "direct navigation" through keyboard shortcuts).