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

This is the disposition of the comments received by the Mobile Web Best Practices Working Group during the Last Call review period of the Mobile Web Best Practices 1.0 dated January 13 2006.

Commenters were requested to send feedback on the disposition of their comments before the end of the following last call period set to May 3rd 2006, indicating whether they agreed or not with the Working Group decision.

A few disagreed with the original resolutions, but after further discussions, the WG managed to satisfy all the commenters of this first last call. See also the disposition of comments of the second last call.

In the table below, red is in the WG decision column indicates that no changes to the document were made based on the comment, and green indicates that a change was made to accommodate the comment.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to our request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-421 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
The Best Practices do not set requirements on user agents, only on content; we already give recommendations on input mode for the content (see AVOID_FREE_TEXT and DEFAULT_INPUT_MODE]. Any further consideration would better fit in the techniques related to these best practices, on which we welcome contributions:
no reply from commenter
LC-422 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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]
We have not found sufficient support for this encoding scheme in mobile devices.no reply from commenter
LC-433 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
We have added a link to the I18N tutorial on specifying the encoding and have added the specific case you mention in the related technique:

(note that the document only focuses on XHTML, not on HTML)
no reply from commenter
LC-436 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
After futher discussion with Richard Ishida, we have added more specific recommendations as to why using Unicode is a smart thing to do:
"Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] and [CHARSET2].

Unicode is a good choice for representing content when served in multiple languages. The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings.

Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8.
LC-393 <Jyri.Hagman@nokia.com>on behalf of Nokia
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.
Timezone inaccuracies in the client don't normally affect caching since it relies on GMT time. Clock skews aren't specific to mobile devices and should be handled as a case of deficiency in the implementation when specific to a given mobile device. As such, we haven't modified the document, but would welcome a technique on this specific item:
no reply from commenter
LC-366 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
The Default Delivery Context (section 1.4 in the Last Call Working Draft) provides the assumed minimum-level requirements alluded to.no reply from commenter
LC-367 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
The group took inspiration from WCAG 1.0 (and links back to it), but the accessibility experts are in the WAI groups. As such, we think further work on accessibility in the mobile context is out of our scope.no reply from commenter
LC-368 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
This is out of scope of the current phase of work of the Best Practices, as stated in our scope document:
As the Mobile Web Initiative is primarily concerned with accessing content that would currently be rendered in a desktop or laptop browser, the BPWG's focus is currently on best practices that are most pertinent to "traditional" browsing. However, in future phases, the group may broaden the scope of its work in order to take into account other content presentation options that may be available on mobile devices - e.g., using the emerging multimodal technologies."""
no reply from commenter
LC-370 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
Setup and configuration is out of scope for the Mobile Web Best Practices which only focus on the delivery of content to Mobile Web devices.no reply from commenter
LC-385 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter, How to do it: Provide advice on how to implement device-based wrapping.
The group thinks this topic would be a better fit as part of the techniques, on which we welcome contributions:
no reply from commenter
LC-388 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
Telling providers to check their error logs is out of scope for this document.no reply from commenter
LC-358 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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
We don't have any best practice regarding security, and deploying a secure service on the Web and on mobile devices require much more guidance than simple best practices. As a consequence, the group doesn't feel the document should talk about HTTPS.no reply from commenter
LC-394 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.
We have added a new best practice on text effects:
"[FONTS] Do not rely on support of font related styling."

but we think the particular aspect of justification would be better handled by a technique that was started at:
LC-395 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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 &shy; or similar.
display options, it seriously reduces legibility of content, often at a
cost of some extra processing.
We think this would be a better fit for a technique rather than a specific best practice. A technique has been started in:
LC-267 Ian Jacobs <ij@w3.org>
"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.
Yes and no: yes, HTTP has been added in the default delivery context -- but no, it also belongs here -- as a clarification of what "One Web" means in the context of this document.yes
LC-285 Ian Jacobs <ij@w3.org>
* 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.
* "exploit is the word used in the Device Independence authoring techniques, so we prefer being consistent with them
* we think it is important to inform the reader that a good user experience on a mobile devices needs most of the time to be adapated to the device
* the techniques document is the place where the reader can learn more on actual ways to learn about device capabilitiles
* we have also clarified that we mean more client capabilities than just the ones required to implement the other best practices.
LC-287 Ian Jacobs <ij@w3.org>
* Please delete "reasonable" (if you keep this one).
We think that reasonable is an appropriate word to use. We expect you to try, but don't expect you to break your back.yes
LC-288 Ian Jacobs <ij@w3.org>
* 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.
The "silently recovering from error" point is relevant to user agent requirements which is out of scope. We believe the text already addresses the issues you've raised.yes
LC-290 Ian Jacobs <ij@w3.org>
* 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 or is it a general statement that belongs in a conformance section?
We decided to keep the best practice as is, but we have added text to the default delivery context to mention that no get-out clauses apply in the default delivery context.yes
LC-291 Ian Jacobs <ij@w3.org>
* 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.
We are writing for Web people who may not have realised that there is even more variation in browsers on mobile than there is on the desktop.
We do indeed talk about when it is ok not to follow other good practices.
LC-293 Ian Jacobs <ij@w3.org>
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.
Generally speaking, we think the imperative voice better convey our message across.

For the specific best practice on short URIs, we have added a explanatory words and examples, but have kept the best practice mostly as is.
LC-302 Ian Jacobs <ij@w3.org>
* 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?
Yes, access key support on mobile devices is interoperable among mobile devices and with some desktop implementations.yes
LC-304 Ian Jacobs <ij@w3.org>
* 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."
Most content adaptation systems rely on a database of known devices, with information on which format the device support. If you use such a system, you can annotated only the links you know may not be supported; if you don't, you fallback on the default delivery context, which tells you that only XHTML, JPG and GIF are supported formats (we have amended the text to clarify this).yes
LC-305 Ian Jacobs <ij@w3.org>
* 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.
The document is about delivered content. The inference for a content author is that if they specify an image map, then under certain circumstances this will not work so they should in addition consider an alternative linear arrangement of links.

We have shortened the best practice to: "Do not use image maps unless you know the target client supports them effectively." and explained "effectively" in the text with the remainder of the BP as it is now put.

We have also included a note to the effect that Image Maps on the Mobile Web are a bad idea.
LC-307 Ian Jacobs <ij@w3.org>
* 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.
We don't mean to be prescriptive about providing a means of helping the user choose, we do mean that there must be a way of telling the user that the page will refresh and of stopping refresh once it has started. Any other consideration is more to do with User Agents, which is out of scope for this document.yes
LC-308 Ian Jacobs <ij@w3.org>
* 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.]
As explained in the text, we simply mean that you're rarely interested in very detailed and long texts when using the web on a mobile devices, but that you would be generally speaking looking for specific information:
"Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information and, while providing the option to access all information, should offer appropriate information first."
LC-309 Ian Jacobs <ij@w3.org>
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.
The point is less to be measurable and more to provide best practice guidance. We are saying in the explanation below that a discursive style is usually less appropriate in the mobile context. It's an important point and we have kept it.yes
LC-311 Ian Jacobs <ij@w3.org>
* How are you defining "what the user has requested?" Does that mean "Implement HTTP GET"?
No, as we explain in the text below. The idea is to be mindful of the users' costs etc and not send them advertising and so on that is not relevant to their needs and at their expense.yes
LC-313 Ian Jacobs <ij@w3.org>
* 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.
We believe the explanation under the best practice makes it clear what we mean by usable size.yes
LC-319 Ian Jacobs <ij@w3.org>
* 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.
We keep this best practice as it is a classical problem in mobile web design and want to insist on this type of practical issue.

On the 2nd point, we've included discussion on downloading items (under link_target_format).
LC-322 Ian Jacobs <ij@w3.org>
* Please stick very close to WCAG 2.0 on this one as well (I think it is 1.4.3).
We stick close the WCAG 1.0 - the current W3C Recommendation.yes
LC-330 Ian Jacobs <ij@w3.org>
* 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).
Given that style sheets are part of the default delivery context, this get out clause is needed when a site adapts its content for a device that doesn't support style sheets.yes
LC-331 Ian Jacobs <ij@w3.org>
* 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)
It may have been a WCAG point but the mobile interpretation is that some devices don't do style sheets.yes
LC-333 Ian Jacobs <ij@w3.org>
* Delete this point and add to the list of things to "keep short": markup.
We think these are separate concern that deserve separate contexts. While we may have chosen to organize the best practices in the way you suggest, we haven't found enough benefits behind your proposed re-organization to work on a major re-organization as you suggest.yes
LC-335 Ian Jacobs <ij@w3.org>
* Please delete "Where possible" * I suggest merging these two into a single point about following standard protocols for content type negotiation.
The point is that:
* simple standard content negotiation works poorly in the mobile space.
* It may not be possible to do it if you're not using content adaptation.
* Respect the markup format the client is asking for.
LC-336 Ian Jacobs <ij@w3.org>
* "to a minimum" is not well-defined. * Add this to the list of things to keep short.
We prefer to have well-focused practical best practices rather than generic lists of items that fit under a same principle.yes
LC-340 Ian Jacobs <ij@w3.org>
* 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?
We have removed the duplication of "appropriately".
We have split the best practices in two to separate the concerns of labeling and positioning, but the proper positioning of labels with forms controls depends too heavily on the context to be specified more precisely.
LC-346 Ville Karinen <ville.karinen@helsinki.fi>
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:


Google's quite new HTML -> XHTML MP converter:
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> (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.)
As stated in the "Classes of products" section [2], we're only dealing
with "content as it gets delivered to a Web user agent". The way it is
authored, adapted or proxied along the delivery chain is thus out of
scope for our document, although we briefly explain where content
adaptation fits in there [3].

Furthermore, a W3C Technical Report would not be the right place to
present vendor-specific solutions for content adaptation.

Nevertheless, the Techniques the Working Group has started to work on
will present a set of technical advices regarding how to put the best
practices in application; as these techniques will be open for
contributions, maybe could you then suggest something along the lines of
your email message?

In the meantime, is there a way to rephrase your comment in a way that
would fit in the scope of our best practices?

Thank you very much for the time you took to review and comment on the


1. link
2. link
3. link
LC-352 Werner Egipsy Souza (Jataayu Software) <werners@jataayusoft.com>on behalf of Jataayu Software
_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:


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
The Best Practice is about site entry points, to which this technique doesn't really apply.no reply from commenter
LC-353 Werner Egipsy Souza (Jataayu Software) <werners@jataayusoft.com>on behalf of Jataayu Software
_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
This is a user agent issue and so out of scope. We do recommend use of access keys which can achieve the same goal of easing navigation.no reply from commenter
LC-351 Werner Egipsy Souza (Jataayu Software) <werners@jataayusoft.com>on behalf of Jataayu Software
_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.
We think this suggestion would be a good fit for a technique related to this best practice; we welcome techniques contributions in our wiki at:
no reply from commenter
LC-398 Zev Blut <zb@ubit.com>
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.
We decided not to include the screen height because:
* research showed that even being able to view only a few lines (4) was sufficient for a reasonable user experience
* we didn't want to fix the aspect ratio
no reply from commenter
LC-399 Zev Blut <zb@ubit.com>
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?
The "back button" is not mandated by any of the specifications that defines the default delivery context, and in particular, there doesn't seem to be any evidence that any device supporting XHTML-basic would feature a back button.

As such, we have kept our text regarding the back button as is.
no reply from commenter
LC-401 Zev Blut <zb@ubit.com>
What does the group consider a proper range for short URLs?
No specific values have been defined for lengths of URLs because it was felt that specifying precise value might in practice prove too restrictive
This BP should be interpreted as meaning if you have the choice between
as the access point for your site you should choose the shorter one, which we have tried to clarify through additional examples.
no reply from commenter
LC-403 Zev Blut <zb@ubit.com>
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.
This is a WCAG checkpoint and a fairly common usablity rule. Put the important stuff first.

Note that the Best Practices and the mobileOK trustmark, while related, are different and it is not defined yet which best practice will be included in the definition of the trustmark.
no reply from commenter
LC-405 Zev Blut <zb@ubit.com>
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.
We have clarified that specifying the intrinsic dimensions of an image allows that the browser doesn't have to re-flow the page in the course of displaying it (re-flowing creates usability problems due to changes of focus, and also may have a bad CPU/battery impact).no reply from commenter
LC-406 Zev Blut <zb@ubit.com>
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.
Good point but clearly the content author can't do anything about this User Agent deficiencyno reply from commenter
LC-416 <fsasaki@w3.org>on behalf of I18N WG
Please say about the participants in the mobile value chain s.t. like "these participants are working with multiple languages ...".
We have removed the section on participants in the mobile value chain altogether since it was not necessary to the comprehension of the document.yes
LC-417 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


On scope of MWBP 1.0: Please give internationalization as another example of general good practice which have a specific mobile interpretation.
Our position on this is that if we reference other work we do so because of a specific mobile interpretation. As far as we are aware we do not make reference to any internationalisation as we feel that internationalization recommendations "are general to all forms of Web access". Please come back to us if we are mistaken.no reply from commenter
LC-418 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
We do not think that this has a specific mobile interpretation; the section on usability has been removed in any case.no reply from commenter
LC-423 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
Non availability of resources in the language of your choice is not a mobile specific issue.no reply from commenter
LC-425 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
We don't think this has a specific mobile interpetation.no reply from commenter
LC-426 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


You don\'t have any normative references. Is this intended, and if yes, why?
Yes, it is intended as the document is non normative.no reply from commenter
LC-427 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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?
No, as some of the sections are not applicable to some of the best practices. We have clarified that "what to test" is left out on non-testable best practices.no reply from commenter
LC-429 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
We have mentioned "language" as being one of thing worth mentioning as part of the LINK_TARGET_FORMAT:
"Links to content that is in a different format or different language to that of the page the link is on (i.e. content that can only be interpreted by other applications or downloads) should be human signposted"
LC-432 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


\"Please consider proposing that it would help bandwidth to store standard messages in the device itself, rather than download them each time.\"
Recommending that HTTP errors be handled by the device itself would go contrary to the web architecture (e.g. preventing the content provider to give detailed information to the user as to what the error is and what may have caused it).no reply from commenter
LC-437 Al Gilman <Alfred.S.Gilman@IEEE.org>on behalf of WAI
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

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.
We think that UAAG is out of scope as the document is about delivered content rather than user agents. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques.yes
LC-439 Al Gilman <Alfred.S.Gilman@IEEE.org>on behalf of WAI
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.
We think this is out of scope since we are not addressing user agents in the document. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques.yes
LC-440 Al Gilman <Alfred.S.Gilman@IEEE.org>on behalf of WAI
5.3.7 Background Images
should reference
UAAG 3.1 Toggle background images (P1) - 1. Allow configuration not to
render background image content.
We have removed that Best Practice, since it didn't have a mobile-specific aspect.yes
LC-441 Al Gilman <Alfred.S.Gilman@IEEE.org>on behalf of WAI
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).
Out of scope since we are not addressing user agents in the document. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques.yes
LC-364 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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
We take your point, but this is the title established by the Group's charter. We have sub-titled the document "basic guidelines" to convey the idea that many more advices could be given.no reply from commenter
LC-365 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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
The development of this draft has been somewhat faster than is customary. This is intentional. This is primarily a practical rather than theoretical art and we think there will be great benefit from feedback from implementation.no reply from commenter
LC-369 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We do not wish to limit the scope to connected devices. For example, a periodically synchronised device requires the same best practices for display of web content.no reply from commenter
LC-372 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We refer only to ratified documents and not to works in progress.no reply from commenter
LC-373 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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).
We have removed the section on usability.no reply from commenter
LC-376 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We feel that the section is sufficently detailed to convey the sense that is intended. It is supposed to background material rather than and exhaustive explanation.no reply from commenter
LC-377 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
This is background overview section and is not intended to be an exhaustive explanation. We deal with speech/voice in Phase 2.no reply from commenter
LC-378 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
This is background overview section and is not intended to be an exhaustive explanation.no reply from commenter
LC-379 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter 2.4, User Goals: The first sentence should be rewritten. See also comment on
chapter 1.3.3 above.
Please suggest a rewrite or specifics if you think this is especially problematic.no reply from commenter
LC-381 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter 3, Delivery Model Architecture: The entire section after “3” should be numbered
separately (e.g. made 3.1 Introduction).
It is the document convention to have introductory text following major headings.no reply from commenter
LC-382 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter, How to do it: The references should be made more explicit.
This BP has been removed.no reply from commenter
LC-389 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We refer only to ratified recommendations.no reply from commenter
LC-261 Ian Jacobs <ij@w3.org>
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."
We feel that this is not required, as the document is informative. The work on conformance (and the related disclaimers) will be done in the mobileOK trustmark document.yes
LC-262 Ian Jacobs <ij@w3.org>
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?
In the document we refer to Techniques and MobileOK which are currently being written. We can also imagine adaptation guidelines but we are not sure of the exact course. There's also a new User Agent test initiative but it hasn't started yet so we can't reference it.yes
LC-269 Ian Jacobs <ij@w3.org>
As you'll see below, I think you may wish to refer to some of the guidance of theUser Agent Accessibility Guidelinesas well.
We are talking about site usability rather than user agent or device usability, so refering to the User Agent Accessibility guidelines is out of scope (and could possibly create confusion).yes
LC-272 Ian Jacobs <ij@w3.org>
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.
The fact is there remains occasions where the user may have to type a URI (e.g. a not yet indexed site, a non-linked from the outside intranet, following an ad seen on a bus, ...) and that this has proven to be a difficulty to get people even trying to use the Web on mobile devices, so it's definitely worthy to be noted here.yes
LC-274 Ian Jacobs <ij@w3.org>
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?
Yes, this is true. However, the contrast is that it is usually expected that personal devices to be configurable; while the mobile phone is very much a personal device, it's rarely configurable.yes
LC-275 Ian Jacobs <ij@w3.org>
Does this mean that you will have best practices for error handling below to avoid incomplete display or other problems?
We do have a best practice on the size of pages to send to a mobile device to avoid this memory limitations problems.yes
LC-286 Ian Jacobs <ij@w3.org>
Ah, that last sentence is already more informative in my opinion.
Capabilities has been removedyes
LC-292 Ian Jacobs <ij@w3.org>
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.
We think "as is practical" does convey the message that the Working Group has in mind; note that this document is informative and aims at providing guidance to authors, not imposing very specific rules - that will be done in the mobileOK trustmark.yes
LC-310 Ian Jacobs <ij@w3.org>
* How does this apply to prefetching?
The idea is to be mindful of the users' costs etc and not send them advertising and so on that is not relevant to their needs and at their expense.yes
LC-312 Ian Jacobs <ij@w3.org>
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.
We have linked CENTRAL_MEANING and CLARITY since they both address the same range of topics.yes
LC-320 Ian Jacobs <ij@w3.org>
* 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.)
We reference WCAG 1.0 because this is the current W3C Recommendation.yes
LC-323 Ian Jacobs <ij@w3.org>
* 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.
We don't think there are enough benefits in re-organizing the document around this kind of grouping to justify the cost of actually doing it. Also, this allows to put the focus on specific concerns rather than on general principles.yes
LC-324 Ian Jacobs <ij@w3.org>
* 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."
The text already reads:
"Many mobile clients do not support frames. In addition, frames are recognized as being generally problematic."
LC-326 Ian Jacobs <ij@w3.org>
* This is another instance of "Don't do X" when you are outside the default delivery context; regroup with those?
As already noted, we don't think the benefits of grouping outweighs the costs.yes
LC-328 Ian Jacobs <ij@w3.org>
* 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."
The text already reads:
"Resizing images at the server [...] reduces amount of data transferred and the amount of processing the client has to carry out to scale the image."
LC-329 Ian Jacobs <ij@w3.org>
* 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."
The text already reads:
"Avoiding pixel and absolute measures allows the browser to adapt content to fit the display."
LC-337 Ian Jacobs <ij@w3.org>
* 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).
The text already reads:
"Given the typical input limitations of a mobile device the interface must as far as possible minimize user input. Where possible, use selection lists, radio boxes and other user interface artifacts that do not require typing."
LC-338 Ian Jacobs <ij@w3.org>
* Delete "where possible"
As noted above, this leeway is intended given the document focus on guidance rather than mandated rules.yes
LC-347 Werner Egipsy Souza (Jataayu Software) <werners@jataayusoft.com>on behalf of Jataayu Software
_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
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.
1. Always on is a feature of many devices aside from Mobile Devices. Data connectivity from mobile devices is usually only established on demand by an active application.
2 and 3. We think that these aspects are out of scope of the Mobile Web.
no reply from commenter
LC-362 Werner Egipsy Souza <hephail@gmail.com>on behalf of Jataayu Software
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

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.
We think that device limitations is the correct way to make the contrast between the capabilities of a mobile device and those of the desktop, for an audience that is used to delivering content to desktops.no reply from commenter
LC-363 Werner Egipsy Souza <hephail@gmail.com>on behalf of Jataayu Software
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.
2.7 We're not clear that this is indeed an advantage that is relevant to this phase of Mobile Web Best Practices.

5.2.6 We think this refers to the User Agent and hence out of scope of this document.
no reply from commenter
LC-400 Zev Blut <zb@ubit.com>
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?
We say that this is relevant when the device does not respect the author's intentions.no reply from commenter
LC-434 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.\"
We have added the additional tests to execute in the "what to test" section.no reply from commenter
LC-435 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


\"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...\'.)
We have removed the sentence about "the specification of the natural language", clarified that we meant definition of input mode settings, added the relevant tests. We haven't added the encouragement of the declaration of the language as this doesn't have a specific mobile aspect.no reply from commenter
LC-390 <Jyri.Hagman@nokia.com>on behalf of Nokia
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.
We have substantially reworded the Best Practice on balance to clarify that the balance was between the number of links per pages and the number of pages the user has to download to go to his or her intended result.no reply from commenter
LC-391 <Jyri.Hagman@nokia.com>on behalf of Nokia
5.3.3 Scrolling
There could be a stricter recommendation: Limit scrolling
while reading a single text flow to one direction.
We have simplified the pair of Best Practices on scrolling into a single best practice, recommending not allow secondary scrolling unless necessary.no reply from commenter
LC-392 <Jyri.Hagman@nokia.com>on behalf of Nokia
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.
We agreed with this additional principle and generalized it in the Best Practice "EXTERNAL_RESOURCES".no reply from commenter
LC-374 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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
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.
We already address these issues, but we have slightly revised part of the One Web definition to be more explicit and use the word "representation" (as defined in the DI glossary) in the following text:

"As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same representations across all devices. This is due to issues such as the context of mobile use, terminal capability variations, bandwidth issues and mobile network capabilities. Furthermore, some services and information are more suitable for and targeted at particular user contexts."

We have also added a link to the Thematic Consistency Best Practice, which give more context on this point.
no reply from commenter
LC-375 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter 1.4, Default Delivery Context: More detailed specifications should be provided. In
addition, possible fall-back solutions should be mentioned.
We have added links to the details of the specifications referenced in the default delivery context. The fall-back solutions belongs in the techniques document.no reply from commenter
LC-384 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We have added a note on non-URI-typing access to a web site:
"it is expected that users will prefer to use alternative methods of obtaining URIs when available - such as following a hyperlink (from an e-mail, SMS or other Web page), WAP Push, 2D bar code, color bar code, RFID tag and Bluetooth."
no reply from commenter
LC-387 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter, 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.
This is a specific best practice on use of "access keys" whose support is known to be quite uniform across mobile devices.

We have added a clarification on the limitations of these accesskeys and the devices keyboards:
"When building a list of links use numbered lists and assign access keys appropriately. It is recognized that not all characters can be used as access keys as many mobile devices have a limited keyboard."
no reply from commenter
LC-357 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.
We have added the definition that a Web safe color as one which has Red/Green/Blue components chosen only from the values 0, 51, 102, 153, 204, and 255.no reply from commenter
LC-359 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software

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
We do say in 1.3 "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." but indeed HTTP wasn't part of the default delivery context.

We have added HTTP 1.0 as part of the default delivery context.
no reply from commenter
LC-360 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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).
We have clarified the default delivery context, and now it only allows external style sheet as required by XHTML Basic.no reply from commenter
LC-361 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.


We agreed with this and moved this Best Practice as a technique.yes
LC-396 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.
We have added the following sentence in the "how to do it" section:
If scripting is used, do not use onmouse and onkey triggers, use onclick.
no reply from commenter
LC-397 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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
We agree and have added a new best practice to that effect (EXTERNAL_RESOURCES), which combined with the BALANCE Best Practice covers the suggestion.yes
LC-408 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.


The group agreed and decided to drop this as a Best Practice.yes
LC-409 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.


We have noted that borders and margins may sometimes usefully be specified in pixels.yes
LC-415 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.


We have clarified that only images with an intrinsic size should have their dimensions specified in the markup.yes
LC-345 Dan Connolly <connolly@w3.org>
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
-- 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.
Thematic Consistency has been moved as the first Best Practice in the latest draft.

Design for device independence, does not have a specific mobile interpretation, it does not appear to be testable and it is hard to know what techniques one would cite to support it, unless it is the totality of the techniques that we suggest in support of the best practices.

We've removed the [CONTEXT] Best Practices as it did not appear to fit well with the other best practices, and has been moved as a technique instead.
no reply from commenter
LC-344 Elliotte Harold <elharo@metalab.unc.edu>
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 group agreed this Best Practice wasn't very relevant and decided to remove it.no reply from commenter
LC-264 Ian Jacobs <ij@w3.org>
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.
We agree and we have integrated your suggested rewrite in the section on Phasing, having removed the section on usability as such.yes
LC-277 Ian Jacobs <ij@w3.org>
"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.
We have changed the term to "Mobile Web access" to clarify that it's not the mobile web but mobile access to the Web.yes
LC-283 Ian Jacobs <ij@w3.org>
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."
We agree that this best practice didn't fit very well with the rest of the documents, and was more a general technique than an actual best practice.

As such, we have redistributed the text between some other parts of the document as well as in the Techniques.
LC-289 Ian Jacobs <ij@w3.org>
* 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"?
We have added a clarification of the intended meaning of deficient:
"By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation."
LC-297 Ian Jacobs <ij@w3.org>
* 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.
We have reworded the explanatory text about navigation bars, noting in particular that the navigation bar shouldn't prevent the user from seeing the core of the content.yes
LC-299 Ian Jacobs <ij@w3.org>
* 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.
We have substantially reworded the Best Practice on balance to clarify that the balance was between the number of links per pages and the number of pages the user has to download to go to his or her intended result.yes
LC-300 Ian Jacobs <ij@w3.org>
* 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."
We have changed the Best Practice to mention URIs instead of links, and the text now refers to the Web Architecture principle.

We have not renamed it since the wording "thematic consistency" is about the expected goal not the implied principle.
LC-303 Ian Jacobs <ij@w3.org>
* 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.
We have shortened the best practice by moving it in the explanatory text that also has been clarified.

We haven't combined it with link_target_format since we want to to be clear on both these points.
LC-314 Ian Jacobs <ij@w3.org>
* 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.
We have removed the conditional statement since it is indeed taken into account by the default delivery context.yes
LC-315 Ian Jacobs <ij@w3.org>
* 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.
We have added the following explanatory paragraph:
"The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content."

We have kept the opt out clause, with explanations on cases where this might be needed (e.g. a map).
LC-316 Ian Jacobs <ij@w3.org>
* I do not understand how this point differs from the previous one.
We agreed and removed the second best practice on scrolling.yes
LC-321 Ian Jacobs <ij@w3.org>
* 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.
The Best Practice was dropped, so this comment doesn't apply anymore.yes
LC-325 Ian Jacobs <ij@w3.org>
* Please stick very close to WCAG 2.0 on this one as well.
WCAG 2.0 is still a Working Draft, so the group has chosen to align with WCAG 1.0 which is a Recommendation. In particular, we have syncronized the text of this BP with the WCAG 1.0 guideline.yes
LC-334 Ian Jacobs <ij@w3.org>
* 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.
We have clarified that a user should always be able to at least download items (in LINK_TARGET_FORMAT), no matter the level of support his or her device has for the said format. We have also mentioned the various ways one can determine which format is supported or not.yes
LC-402 Zev Blut <zb@ubit.com>
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.
We have clarified that only a few links should be placed at the top of the page, leaving the rest of the navigation links to the bottom, and added a note to the effect that user should be able to see the content of the page without scrolling.no reply from commenter
LC-404 Zev Blut <zb@ubit.com>
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:

The DoCoMo way of doing this is in the spirit of this BP i.e. the user will receive an appropriate message if his or her phone does not support the OBJECT tag, but we agree that the Best Practice was a worded a bit too restrictively.

We have changed the wording of the Best Practice to:
Do not rely on embedded objects and/or scripts.
no reply from commenter
LC-407 Zev Blut <zb@ubit.com>
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?
We have clarified that we really meant "do not rely on cookies being available"; i.e. it is indeed fine to make use of Set-Cookie to determine if the phone support cookies.no reply from commenter
LC-419 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


Please point to the specification
XHTML Basic [link]
We have added a reference to XHTML Basic.no reply from commenter
LC-420 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


This section seems to fit better at the beginning of the document.
We agreed and moved it to section 1.2 and move the other sections down correspodingly.no reply from commenter
LC-424 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


Please correct the line break before \"communications.\".
We have removed the spurrious line break.no reply from commenter
LC-428 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


CDFWG is in the references, but not in the text.
This was a Dangling Reference from an earlier version which did make reference to CDF. The reference has been removed.no reply from commenter
LC-430 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


UAProf is mentioned several times in the text, but not in the references. We guess you mean
UAProf profile repository [link]
Thanks for pointing this out. We have included a reference to the OMA documentation on UAPROF.no reply from commenter
LC-431 <fsasaki@w3.org>on behalf of I18N WG
Comment from the i18n review of:

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


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.
We have added references to these documents.no reply from commenter
LC-438 Al Gilman <Alfred.S.Gilman@IEEE.org>on behalf of WAI
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.
We have added the following note to the section on content adaptation:
"Whatever the adaptation model at work, the process of adaptation should not diminish accessibility."
LC-371 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
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.
We agree and have changed the text to read "to improve the user experience of the Web on mobile devices."no reply from commenter
LC-380 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter 2.7, Advantages: “Connected” should be added to the popularity reasons.
We have added that aspect to the list of advantages.no reply from commenter
LC-383 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter 5.1.4, Testing: Update the recommendation to “…devices and provided specific
software versions…”.
We have added the suggested mention of software versions.no reply from commenter
LC-386 Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com>on behalf of ANEC
Chapter, What it means: Connectivity and download speed issues should be
We've added a note to the sentence "irrespective of differences in presentation capabilities": "and access mechanism."no reply from commenter
LC-342 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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

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")


We have updated the document to clarify that content should not rely on scripting, and avoid using scripting as much as possible due to battery considerations.yes
LC-356 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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.
We have qualified the screen width as being a minimum.no reply from commenter
LC-410 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
[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

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.


We have changed the wording to:
"Use features of the markup language to indicate logical document structure."
no reply from commenter
LC-411 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
Testing for the absence of tabindex, and the absence of complex layouts
(absolute positioning, etc) should also be enough.


We have reworded the "how to test" section accordingly.yes
LC-412 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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).


We have added a test along these lines in the "what to test" section.yes
LC-413 Charles McCathieNevile <chaals@opera.com>on behalf of Opera Software
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"


We have changed the wording to read:
"[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.".
LC-258 Ian Jacobs <ij@w3.org>
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."
We have elevated THEMATIC CONSISTENCY to the most prominent in the document and hence have given it the precedence it deserves.yes
LC-259 Ian Jacobs <ij@w3.org>
What does "in context" mean?
We have removed the incriminated sentence.yes
LC-260 Ian Jacobs <ij@w3.org>
I suggest merging the previous two paragraphs; I otherwise was unsure about the mobileOK trustmark in the paragraph where it was introduced.
The paragraph boundary was indeed unnecessary and we have merged the two paragraphs accordingly.yes
LC-263 Ian Jacobs <ij@w3.org>
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.
We have expanded the consideration on phasing and have added a mention of the expected longevity of the document.yes
LC-265 Ian Jacobs <ij@w3.org>
What does "perhaps" mean here?
We have replaced perhaps by "for example" and "for instance".yes
LC-266 Ian Jacobs <ij@w3.org>
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.
We have reworded this to read "not to exclude access from any particular class of device, except where this is necessary because of device limitations."yes
LC-268 Ian Jacobs <ij@w3.org>
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.
We have reworded the introduction to the default delivery context section and think it sets now more clearly what concerns the content and what concerns the device/context.yes
LC-270 Ian Jacobs <ij@w3.org>
I find "pointer to" to be very informal.
The incriminated text has been removed.yes
LC-271 Ian Jacobs <ij@w3.org>
I think "Appendices" is more common than "Annexes" in W3C specs.
We have replaced "annexes" by "appendices".yes
LC-273 Ian Jacobs <ij@w3.org>
What is an "entertainment application"? Do you mean a game?
We have reworeded the paragraph to read:
"Equally, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available."
LC-276 Ian Jacobs <ij@w3.org>
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?
We have removed the reference to this aspect, as we agreed it's not always something you get with mobile access.yes
LC-278 Ian Jacobs <ij@w3.org>
See also previous comment on "phase"; I suggest a link to where the term is first explained.
We have added link to the discussion on the phasing of our work.yes
LC-279 Ian Jacobs <ij@w3.org>
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.
We have removed the section accordingly.yes
LC-280 Ian Jacobs <ij@w3.org>
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".
We have removed the wording altogether and have instead created a list of the best practices with the links pointing to the relevant URIs.yes
LC-281 Ian Jacobs <ij@w3.org>
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.
We have resolved to keep the labels the same, but we have added a table of BPs.yes
LC-296 Ian Jacobs <ij@w3.org>
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?
We agreed with the weakness of the section and have added more detailed advice on shortening URIs.

Meanwhile, we keep the specifics of configuring a server to that end for the techniques.
LC-298 Ian Jacobs <ij@w3.org>
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.
We have removed the incriminated sentence.yes
LC-301 Ian Jacobs <ij@w3.org>
* 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.]
We have replaced "use" with "provide" as suggested.yes
LC-317 Ian Jacobs <ij@w3.org>
* 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.
This one is meant to be about not putting banner ads, and other clutter in advance of the text. The "frontloading" aspect is discussed under [CLARITY]; we have added a link from one to the other to highlight their relationship.yes
LC-318 Ian Jacobs <ij@w3.org>
The first sentence of the previous paragraph is more communicative than 5.2.2 as written.
We have referenced the text of this Best Practice from the text of the best practice on navigation bar, with clarification on why it is important to keep navigation bars short in the mobile context.yes
LC-327 Ian Jacobs <ij@w3.org>
* 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?
We have removed the word "always" and have instead clarified in the explanatory text that this is an exception to the best practices on relative measures.

All the markup languages in scope for this document (XHTML Basic and above) have support for this feature.
LC-332 Ian Jacobs <ij@w3.org>
* Delete "as possible", and * Add this to the list of things to "keep short"
We have removed "as possible".yes
LC-339 Ian Jacobs <ij@w3.org>
* 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).
We have removed the word "tab" and used a more generic wording about navigation order.yes

Mobile Web Best Practices Working Group