Copyright © 2005 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This document specifies best practices for Web content when accessed from mobile devices.
The primary goal is to improve the user experience of the Web when accessed from such devices.
It is directed at all participants in the mobile value chain .
The primary goal isReaders of this document are expected to improve the user experience be familiar with creation of the Web when accessed from mobile devices. sites, and have a general familiarity with the technologies involved, such as web servers and HTTP. Readers are not expected to have a background in mobile-specific technologies.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document describes the best practices for content to work well on mobile devices. A companion scope document [Scope] describes the scope of this work.
This is the first Public second public Working Draft of the Mobile Web Best Practices for review by interested parties. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This draft does not represent incorporates the consensus changes resulting of the MWBP Working Group. It is known to be missing requirements, and is likely resolution of issues since the previous draft. The group expects to contain errors. publish a Last Call Working Draft based on this document in the first weeks of January.
This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . There are several specific issues on which the group solicits public feedback and comment. They are called out in the text like The plan being to release this note. We encourage feedback on all aspects of the document but particularly request as Last Call in a few weeks, the Working Group is not actively seeking feedback on these points. Please this document. Comments send comments on this version of the document are likely to be considered as part of the working group's public email Last Call comments. If you do send comments, please send them to the mailing list public-bpwg@w3.org public-bpwg-comments@w3.org , a publicly archived mailing list. list .
This document was produced under the 5 February 2004 W3C Patent Policy . The Working Group maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy .
1
Introduction
1.1
Purpose
of
the
Document
1.2
Audience
1.2.1
Players
Participants
in
the
Mobile
Value
Chain
1.3
Scope
1.3.1
Phasing
1.3.2
Usability
1.3.3
Boundaries
of
the
Best
Practice
Guidelines
One
Web
1.4
Baseline
Client
Default
Delivery
Context
1.5
Compliance
1.6
Relationship
to
other
best
practices
and
recommendations
2
1.6
How
the
Best
Practices
are
Organized
3
2
Requirements
3.1
User
Experience
2.1
Presentation
Issues
3.2
2.2
Input
3.3
2.3
Bandwidth
and
Cost
3.4
Content
Type
2.4
User
Goals
3.5
2.5
Advertising
3.6
2.6
Device
Limitations
3.7
2.7
Advantages
4
3
Delivery
Model
Architecture
4.1
3.1
Adaptation
Implementation
Model
4.2
3.2
Assumptions
about
Adaptation
5
4
Overview
of
Best
Practices
5.1
Overview
5.1.1
Sources
5.1.2
4.1
How
this
section
is
organized
the
Best
Practice
Statements
are
Organized
5.1.3
4.2
Structure
of
Best
Practice
Statements
5.2
5
Best
Practice
Statements
5.1
Overall
Behavior
5.2.1
5.1.1
Establish
the
Context
of
the
Device
5.2.2
5.1.2
Exploit
Client
Capabilities
5.2.3
5.1.3
Work
around
deficient
implementations
5.2.4
Error
Messages
5.2.5
User
Preferences
5.2.6
5.1.4
Testing
5.2.7
[Other
general
things]
5.3
5.2
Navigation
and
Links
5.3.1
URLs
5.2.1
URIs
of
Site
Entry
Points
5.3.2
Provide
a
Site
Map
5.2.2
Navigation
Bar
5.3.3
5.2.3
Balanced
Structure
5.3.4
5.2.4
Thematic
Consistency
of
Resource
Identified
by
a
URI
5.3.5
5.2.5
Navigation
Mechanisms
5.3.6
5.2.6
Access
Keys
5.3.7
5.2.7
Link
Target
Identification
5.3.8
5.2.8
Image
Maps
5.3.9
5.2.9
Refreshing,
Redirection
and
Spawned
Windows
5.4
5.3
Page
Layout
and
Content
and
Layout
5.4.1
5.3.1
Page
Content
5.4.2
Consistency
5.4.3
5.3.2
Page
Size
5.4.4
5.3.3
Scrolling
5.4.5
5.3.4
Navigation
Bars
etc.
[Extraneous
material]
(Extraneous
material)
5.4.6
5.3.5
Graphics
5.4.7
5.3.6
Color
5.4.8
5.3.7
Background
Images
5.5
5.4
Page
Definition
5.5.1
5.4.1
Title
5.5.2
5.4.2
Frames
5.5.3
5.4.3
Structural
Elements
5.5.4
5.4.4
Tables
5.5.5
5.4.5
Non
Text
Items
5.5.6
Valid
Markup
5.4.6
Image
Size
5.5.7
Measures
5.4.7
Valid
Markup
5.5.8
Semantic
Markup
5.4.8
Measures
5.5.9
5.4.9
Style
Sheets
5.5.10
5.4.10
Minimize
5.5.11
5.4.11
Content
Types
5.5.12
5.4.12
Character
Set
Encoding
5.6
5.4.13
Error
Messages
5.4.14
Cookies
5.4.15
Cache
Headers
5.5
User
Input
5.6.1
5.5.1
Input
5.6.2
5.5.2
Tab
Order
5.6.3
5.5.3
Labels
5.6.4
Language
Identification
6
Conformance
and
mobileOK
(Normative)
5.6.5
Context
Menus
6.1
Classes
of
Products
6
Techniques
6.2
Normative
Parts
7
Conformance
and
mobileOK
6.3
Extensibility
A
Glossary
Sources
(Non-Normative)
B
Acknowledgements
(Non-Normative)
C
References
(Non-Normative)
This document contains sets out a list series of recommendations designed to promote more effective delivery of best practices and discussion around the assertions made for content on the Web so that it is delivered effectively content to mobile devices. It also contains information about how to implement sites that conform to those best practices.
The documentEach recommendation is intended to provide guidance discussed in context and brief explanatory notes are provided. The recommendations are offered to players all participants in the mobile value chain as to best practices for production of web sites and of Web content intended for delivery to mobile devices. It is also are intended as the basis for assessing conformance to the requirements of the MobileOK mobileOK trustmark.
The idea for the MobileOK mobileOK trustmark is described in the Mobile Web Best Practices Working Group Charter We do and is not develop the idea of mobileOK developed in this revision of this document. Future revisions may contain a discussion of mobileOK. mobileOK and techniques for implementing the Best Practice recommendations will be discussed in companion documents.
As mentioned above the document is targeted at players in the mobile value chain, as described below. Readers of this document are expected to be familiar with creation of Web sites, and have a general familiarity with the technologies involved, such as web servers and http. HTTP. Readers are not expected to have a background in mobile-specific technologies.
Our intention is to make it clear to all involved what the best practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some of our statements may appear to be obvious or trivial to those with experience in this area.
The document is not targeted solely at developers and others such as interaction and graphic designers are encouraged to read it.
The group solicits public feedback as to the usability of the document by Web professionals that are not technology specialists.Players Participants in the mobile value chain include:
Original content developers together with portal operators and other aggregators of content who deliver non-original content to mobile and other users.
Who may transform content when it passes from the Internet to their networks, and who may in addition operate portals.
Who realize content for users to perceive.
Developers of tools to assist with content production (authoring).
Developers of tools to assist with content serving and repurposing.
Those involved in the production and execution of testing processes.
The scope of these Best Practices is laid out in [Scope] . In summary this document refers primarily to browsing and extension of the Web web browsing experience to be more usable on onto mobile devices.
The charter As the goal of the group document is to specify best practices Best Practices for delivery to mobile devices. Hence best practice devices, statements that do not specifically have a specific mobile aspect are not included. In particular many Web Content Accessibility [WCAG] guidelines are general to all forms of Web access and are not repeated here unless they have a specific mobile interpretation.
Examples of general good practice which have a specific mobile interpretation include 'Error Messages' and 'Color'.
As discussed in [Scope] the there are many aspects to Mobile Web Best Practices. One of those aspects is that, For example, at present, the design and construction of many Web sites and pages make for a poor user experience when those sites and pages they are viewed on a mobile device.
While improving those Web sites is only one aspect of improving the user experience, significant improvements can be achieved in this way, hence the first phase of work is concerned with providing guidelines for Web-site and content developers.
In future phases other aspects may be considered - e.g. best practices as applied to adaptation and devices. Also in future phases the scope of the recommendations may be extended beyond 'Traditional Web Browsing' into fields such as voice browsing. multimodal interaction.
There are three aspects of mobile usability - namely site, device, and browser usability. All three together contribute to the user experience.
We define these three aspects as follows:
Site usability relates to the structure, content and layout rules of a site and is a measure of the effectiveness of the mobile web site.
Device usability pertains to the capability of the equipment being used easily and effectively. "Easily" refers to a specified level of acceptability and comfort of use; "Efficiency" relates to the resources expended in relation to the accuracy and completeness with which users achieve their goals. In particular, device usability focuses on keypad design, display, fast browser access and UI styles.
Browser usability defines the ease of using a browser effectively namely performing the three functions reading, navigating or interacting. The ease of interaction, page rendering, caching etc. are issues that are frequently used to judge browser usability.
While recognizing the contribution of device and browser usability to the overall user experience, this document focuses on site usability.
This section describes what the Best Practices are trying to achieve, and what they are not. 1.3.3.1 A Reasonable User Experience The MWI recommendations in this phase [See Phasing ] is concerned with establishing a set of guidelines that help content providers achieve the best possible document are intended to improve mobile experience of their the Web content - given on mobile devices. While the client and network limitations that are encountered recommendations in this document are not specifically addressed at the mobile delivery of Web content [see Requirements for a discussion of these]. A reasonable desktop browsing experience of the Web cannot it must be achieved on clients understood that exhibit too many of they are made in the limitations discussed or where one or other context of the limitations is very severe. wishing to work towards 'One Web'.
In saying this it is recognized that any judgment of what is a reasonable experience is made at a particular point As discussed in time and from particular cultural perspective. It is also recognized that it [Scope] One Web means making, as far as is possible reasonable, the same information and services available to achieve a reasonable experience users irrespective of non-Web services in the presence of such limitations and that that there device they are at present many such services, often implemented using WAP 1.x technologies. The intention, however, of using. However it does not mean that exactly the Mobile Web Initiative, same information is to extend the reach of available in exactly the Web to mobile same way across all devices. Hence such non Web Some services and information are out of scope of this discussion. more suitable for and targeted at particular user contexts.
1.3.3.2 The Idea of a Baseline ClientTo be clear about the level of functionality (or absence of limitation) that is targeted for Some services have a reasonable primarily mobile experience of the Web we define the notion of appeal (location based services, for example). Some have a baseline client. By establishing primarily mobile appeal but have a baseline definition, is it possible to provide guidance as to what an implementation should do if it cannot determine whether complementary desktop aspect (perhaps for complex configuration tasks). Still others have a client accessing the service supports features that meet or exceed the baseline definition. In short, it should assume the client provides baseline support. As such the notion of primarily desktop appeal but a baseline client should be seen as guidance on the limitations of pages that are delivered by an implementation, rather than the specification of complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications which have a device. primarily desktop appeal (lengthy reference material, rich images, perhaps).
1.3.3.3 Least Common DenominatorIt is not the intention likely that application designers and service providers will wish to encourage Least Common Denominator Implementations. The best practice recommendations actively encourage provide the best possible support of the baseline client as well as exploitation of features that go beyond the baseline so far as those features refer to experience in the Phase 1 scope (Web Browsing). 1.3.3.4 What is a Mobile Client? While it is out of scope of context in which their service has the best practices to consider non-mobile delivery, it must most appeal. However, while services may be understood that there is no clear dividing line most appropriately experienced in one context or categorization that makes mobile and non mobile clients distinct. Rather, as mentioned above, that non-mobile clients tend to suffer fewer of the limitations that are characteristic of mobile ones. Any particular client can be another, it is considered best practice to be in provide a scale between suffering all reasonable experience irrespective of the limitations discussed device, and suffering none of them. In addition, for as far as is possible, not to exclude access from any particular client, the limitations may not apply equally at different times. class of devices.
1.3.3.5 Which Formats are in Scope?Similarly to the [WCAG] From the best practice recommendations are couched at a level perspective of generality this document this means that allows them to services should be applied to a wide range of markup languages. The intention being that as well as being applicable to current Web standards (especially XHTML), they are also applicable to existing and legacy non-Web recommendations, such as cHTML and WML, as well as future standards, such available as [CDFWG] . some variant of HTML over HTTP.
Baseline conformant devices have been available for some years, and are in common use in many markets. The recommendations encourage refer to delivered content. Given the use range of features that go beyond the baseline, that different mobile device types which have been different properties and will continue to be introduced in new devices. However, since different features the MWI Phase 1 refers only to 'traditional' browsing it does not establish best practices for those features. Best Practices Working Group has defined a Default Delivery Context .
1.3.3.7 Evolution of Baseline DefinitionAs time moves on it is likely that both the definition of a baseline device and the best practice recommendations will change. It Delivery Context is anticipated that the best practice recommendations will change at a slower pace than used with the definition of specific meaning defined in the baseline device. Device Independence Glossary [DIGLOSS] .
As mentioned above, the definition of a baseline device is with The document makes reference to a notion of a reasonable Web experience. Any future change in the baseline device specification will need to take into account both the ongoing development of the non-Mobile Web experience and the availability of devices that exceed the current baseline. It is understood that the capabilities of devices differs markedly Default Delivery Context in different regions of the world, with more developed economies having access to a wider range of more fully featured clients. two ways:
The notion of a baseline client is an abstract notion. No specific real device is targeted. Rather, it is an abstraction of If the characteristics of a range of currently popular devices that have been available for some years. The abstraction assumes complete and defect free implementation of delivered content does not result from an adaptation process - e.g. the features described. It is considered good practice to work around implementation defects of real devices. However, it content is not statically defined as HTML stored in scope of best practices to itemize known defects and limitations nor to detail techniques or examples of how to do this. See [] files - then the delivered content should be suitable for references as to known device the Default Delivery Context and client limitations. should comply with the Best Practice Statements.
The recommendations refer to the behavior of implementations in providing a service, and in this phase do not refer to the behavior of clients. It If an adaptation process is hoped used, then information that by providing a baseline definition creators of devices and clients will it known about the Delivery Context can be encouraged used to produce devices that meet or exceed vary the baseline definition. It is also hoped delivered content to make it more suitable for that those commissioning Delivery Context or setting standards for such devices will require implementation of baseline features to a reasonable standard of completeness and quality. provide an enhanced user experience.
1.4 Baseline ClientThe group requests public comment on the specification of the baseline device given the comments in the previous section, that the purpose of the baseline specification is to inform what implementations can assume to be the minimum level of support that they must take account of, and what assumptions they may make in the absence of any other information . In addition to discussing the baseline client the group has also discussed the idea of a default client. The idea being that for any particular application or geographic region, it may be known that the majority of devices are of a particular type or support particular features. In this case the notion of the 'global' baseline device delivery context is supplemented by a 'local' default device, which may have either greater or lesser functionality when compared with the baseline. defined as follows:
The group would value feedback both on which parameters are to be specified and what the values for those parameters should be.120 Pixels.
For the purposes of delivering The Web, this is assumed to be a version of XHTML - probably aligned with XHTML-MP. Some opinion states that WML should be assumed. http delivery is assumed. There is a further variation in views as to what image format a web site should assume a client supports. It may be that it should be assumed that there is no compatible image support. Basic Profile.
People have strong, but divergent opinions on this. The absolute minimum being 96 x 96 pixels. Strong support is expressed for 128 x 128, however a vocal group supports bigger still. Some opinions support the notion that a minimum row and column availability for text presentation needs to be specified. UTF-8.
Varying opinions again on this. JPEG
GIF 89a (non-interlaced, non-transparent, non-animated).
It is important to understand the limitations of memory so that Web sites do not try to deliver pages that are too big. However it is not clear how this should take into account the combined weight of markup and images. Suggestions vary from 10k bytes upwards. 20k Bytes.
Many other candidate parameters have been suggested, including cpu power, Back / Forward navigation in history, text entry (which character sets?), form controls, SSL 1/2, Javascript ... Web safe.
The document does not have a compliance model. The Best Practice Recommendations represent suggestions as to the behavior of Web sites. Any use External CSS Level 1, with internal definition of the words must , should style and may should not be interpreted as having the meanings defined in RFC2119. font properties.
The Best Practice statements are intended to be capable of later having conformance statements constructed around them, in support of the mobileOK trustmark and for other purposes.These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG] . As noted above, WCAG guidelines are supplementary to the Mobile Best Practices, whose scope is limited to matters that have a specific mobile relevance.
The work This document builds on some of the concepts described by the Device Independence Working Group [DIWG] (DIWG) in the Device Independence Principles [DIP] . The document also discusses the notion of device characteristics, which DIWG has described in terms of a direct and fundamental relevance to this document. "Delivery Context" [DCODI] . In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS] .
The BPWG will develop a companion document describing techniques [Techniques] by which the best practice statements in this document can be implemented.
The document is organized as follows:
IntroductionIntroduction. Describes the audience, purpose and scope of the document.
Organization This section, explains the format of the document. RequirementsRequirements, An illustration of the type of problems that the Best Practices are intended to ameliorate.
ArchitectureArchitecture. Discusses the environment within which the mobile web is realized, with particular reference to adaptation.
Overview of Best Practices Practices. A discussion of the organization of the best practices, and sources from which they were derived.
Best Practices. The statements themselves themselves.
TechniquesHow to implement the best practices [ not present in this draft ]. Conformance and mobileOK Testing for mobileOK. A brief conformance to statement and labeling with pointer to the trust mark [ not present in this draft ]. mobileOK documentation.
AnnexesGlossary [ not present in this draft ] Annexes
Acknowledgements
References
This section discusses the requirements of the Mobile Web Best Practice statements in section 5. The statement of requirements is intended to be illustrative rather than exhaustive or complete.
We discuss the requirements under two broad headings, User Experience and Device Limitations; both contribute to a poor experience of the Web on mobile devices.Many Web pages today are laid out with presentation on desktop size displays in mind, and make use of the facilities provided by desktop browsing software.
Accessing such a Web page on a mobile device often results in a poor, or unusable experience. Contributing to this poor experience is that the content does not lay out as intended, and because of the limited screen size and the limited amount of material on the page that is visible to the user, things that are intended to be viewed together are not presented together - context and overview are lost.
Because of the limited screen size the subject matter of the page may require considerable scrolling to be visible, especially if the top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether their retrieval has resulted in the right content.
It is particularly important in the mobile context to help the user create a mental image of the site. This can be assisted by adopting a consistent style and contrariwise can be considerably diminished by an uneven style.
Mobile device input is often hard when compared with use of a desktop device equipped with a keyboard. Mobile devices such as phones often have only a very limited keypad, with small keys, and there is frequently no pointing device.
It's perhaps a paradox One of the difficulties of the mobile web is that URLs URIs are very hard to type, and lengthy URLs URIs and those that contain a lot of punctuation are particularly hard to type correctly. Bookmarking, while often supported, sometimes does not achieve the expected result.
Because of the limitations of screen and of input, forms are hard to fill in, both because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields.
There is frequently no While many modern devices provide back button, which buttons, some do not, and in some cases, where back functionality exists, users may not be aware how to invoke it. This means that it is often very hard to recover from errors, broken links and so on.
Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency, leading to long retrieval times, especially for lengthy content, and for content that requires a lot of navigation between pages.
Mobile data transfer often costs money. The fact that mobile devices frequently support only limited types of content means that a user may follow a link and retrieve information that is unusable on their device.
Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory - for example larger images may only be viewable in small pieces and require considerable scrolling.
Requests for web pages can result in the delivery of content that the user has not specifically requested - especially advertising and large site images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.
Mobile users typically have different interests to users of fixed or desktop devices. Mobile users are likely to have more immediate and goal-directed intentions than desktop web users. Their intentions are often to find out specific pieces of information that are relevant to their context. Examples frequently include travel related applications, where the user requires specific information about train times.
Other examples often include time filling applications, where people are filling otherwise dead time while traveling, and entertainment related applications are often noted as being appropriate.
On the other hand, 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.
Developers of commercial web sites should note that different commercial models are often at work when the Web is access accessed from Mobile devices as compared with fixed line access, see [some reference TBD], for information. desktop devices. For example, some mechanisms that are commonly used for presentation of advertising material do not work well on small devices and are therefore contrary to the Best Practice Recommendations.
It's It is not the intention of the MWI to limit or to restrict advertising, advertising; rather it is the intention that the user experience of the site as a whole, including advertising, if any, is as effective as possible.
As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than that used for desktop devices. As detailed in [Scope], [Scope] , various other limitations may apply to mobile devices, and these have an impact on the usability of the Web from a mobile device.
Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no option as to which browser they should use, and in many cases upgrade of the browser is not possible. This creates the situation that in order to support users of a popular device, the limitations or implementation defects associated with particular releases need to be taken into account in some situations.
Some activities associated with rendering web pages are computationally intensive. Examples are re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid mark up [T-MOB] . There is typically quite limited processing power available to carry out such computations, which may mean they take a noticeable time to complete. Such computations also use more power and diminish battery life. In any case, data communication reduces battery life and reducing communication can conserve battery.
Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.
In discussing the limitations of mobile devices also have for delivery of Web content it is easy to lose sight of the fact that they are extremely popular and very common.
This popularity largely stems at present from their being:
personal,
personalizable
portable
Beyond these factors, we see the advantages of mobile devices increasingly including:
location awareness
implicit user identification
one handed operation
always on
universal alerting device
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 compared 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.
Moreover, with mobile devices appearing in all shapes and forms, and with a growing variety of features like location technology, cameras, voice recognition, touch screens etc, the Web can reach a much wider audience, and at all times in all situations. It has the opportunity to reach into places where wires cannot go, to places previously unthinkable (e.g. medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time in their wristwatches.
Finally, today, many more people have access to mobile devices than access to a desktop or laptop devices. computer. This section to be developed is likely to elucidate this point.] very significant in developing countries, where web-capable mobile devices may play a similar role for deploying wide-spread Web access as the mobile phone has played for providing "plain old telephone service".
The widely varying characteristics of mobile devices can make it difficult for a Web site to provide an acceptable user experience across a significant range of clients. For example different clients support different markup features, and the different screen sizes may demand different sized images.
Consequently, it is very common when delivering content to mobile clients to vary the details of the markup, format of images, image sizes, color depths and so on, on to suit the characteristics of the client in question. The process of altering content in this way to enhance the user experience on particular devices is referred to as content adaptation .
The remainder of this section outlines briefly describes content adaptation in order to provide a background to for this document. It is not intended as a comprehensive guide or to be definitive. The Device Independence Working Group [DIWG] has published For a great deal of material relevant to this subject. Readers more detailed description, readers are expecially referred to "Delivery Context Overview for the Device Independence" [DCODI] . Independence Principles [DIP]
In addition, the sister group of the Best Practices Working group - the Device Descriptions Working Group, is currently defining requirements for a repository of mobile client characteristics that are relevant to content adaptation.
There is quite a wide spectrum of implementation models for content adaptation. On the one hand it may be quite simple, and consist of determining the device type and choosing the most appropriate set of previously prepared content to match the device characteristics. At the other extreme it may be carried out in a completely dynamic way, with content formatted at the time of retrieval, taking into account not only statically determined properties, such as screen dimension, but also dynamically determined properties, such as the temporary attachment of a fully featured keyboard.
Adaptation can be carried out in a number of different points in the delivery of content to the client [see DIWG work and Device Description Landscape paper for more detailed discussion]. [DCODI]
Server Side adaptation implies that the content is delivered by the originating content server or application.
In Network adaptation is where the content is altered as it passes through one or more network components. Some network operators, for example, compress images before they are passed over the air to the mobile client.
Client Side adaptation consists of the client accepting content that was originally purposed for another device and displaying it with appropriate reformatting. appropriately to the device's characteristics.
In phase 1 we assume that content adaptation, if any, is carried out Server Side. Future phases may consider the implication of other content adaptation, especially the issues around granting authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address the issues around the possibility of multiple adaptations - i.e. the possibility that adaptation can be applied in more than one place, and that in network adaptation may occur more than once.
We also assume that it is possible to create a site that is consistent with the best practice recommendations, without carrying out adaptation at all. However, it is likely that a more sophisticated and enhanced user experience will be achieved if adaptation is used.
Clearly in order to determine the appropriate adaptation for any particular access, it is necessary to determine the device that is accessing the service. Sometimes it is not possible to determine the device type, either because the device does not present this information to the server at all, or in sufficient detail, or because the server does not provide the ability to inspect and act on the information provided.
In these cases the content author provider is expected to assume baseline or default device characteristics, as discussed in the Introduction to this document.
The group seeks public feedback on the desirability of stating that, in practice, adaptation is required for delivery to mobile devices; and that consequently, in view of the desirability of making content widely accessible across a broad range of devices, all Web development requires adaptation.The best practice Statements may either be normative or non normative. Normative statements have been assembled by refer to aspects of the BPWG from a number delivered content that can be tested. Non normative statements refer either to process or to aspects of sources. Primary among those are: Various BPWG group meetings and discussions. WCAG Guidelines 1.0 [WCAG] iMode Guidelines [iMode] Opera's "Making Small Device Look Great" [Opera] Openwave Guidelines [OpenWave] Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP] Browsing on Mobile Phones, Nokia [Nokia-VR] the delivered content that cannot be sufficiently quantified.
Little Spring Design 5.1.2 How this section is organized The best practice statements Hence, in the following section, listing Best Practices, they are organized under the headings of:
General Best Practice Statements that refer primarily to the process by which content is created.
This section contains statements that relate to navigation and linking mechanisms mechanisms.
The section contains statements that relate to the content of pages and how they lay out out.
Statements that relate to the technical construction of pages pages.
Statements that relate to Input Input.
The functional area that is addressed by the statements.
One or more best practice statements, identified in the following way:
[EXAMPLE] This is a best practice statement. (Informative)
Each statement identifies whether it is normative or not.
These statements can be identified by using URI reference composed of the URI of this document together with the statement identifier used as a fragment identifier (e.g. #EXAMPLE).
Explanation An explanation of the significance of the statements under this heading heading.
Discussion A discussion of techniques, usually a reference techniques and some suggestions as to the relevant section of this how to implement. The BPWG intends to create a separate document [not much filled in describing techniques [Techniques] in this revision] more detail.
Discussion The aspects of similar and related points and supporting references especially those from the list above. [usually missing in delivered content that an external validator would examine to assess conformance with the Best Practice Statements. This section is not present for process and other non-normative statements.
In this version, a shorthand reference being provided directly against section it is noted whether the statement(s) itself/themselves] statement is:
Automated testing is possible.
Outline discussion Testing requires human assessment.
Based on the result of how amenable this is to an automated testing. [almost totally missing in this revision] test some human interaction may be required.
Where appropriate, references to related WCAG points and other immediate references in the text.
There are some general principles that underlie delivery to mobile devices.
In this section we refer to 'Implementations' by which we mean Web Servers, Adaptation Devices and other components in the delivery chain (as discussed above under 'Delivery Model Architecture').[CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource. (Informative)
Many of the best practice statements rely on refer to the implementation content provider knowing a significant amount about the physical characteristics of the device, the properties of the browser in use and the transparency or otherwise of the communication path between the device and network connection to the implementation. device. For simple sites which that present an interface which is similar across a broad range of clients the need for such information is diminished when compared with a sophisticated site which has an optimized navigation structure, presents different size images or carries out other adaptations to suit the client.
If a particular client It is not recognized or its capabilities cannot be determined a unlikely that the content provider, "having taken all reasonable steps", will know nothing at all about the context of the device. However if absolutely nothing is known "a reasonable default experience experience" should be provided. In this case The details of the default experience depend upon a warning should be provided and number of factors including, but not limited to, the implementation should provide geographic region in which the ability for service is offered and the user to select primary intention of the device type in use. service (e.g. considering whether the service is primarily desktop focused vs. primarily mobile focused).
Where possible the user's determination of the default experience has resulted in selection of a device type should persist across visits to mobile experience, the implementation, but default delivery context should be changeable. assumed in creating that presentation.
The warning provided while making it clear that the experience content provider may not be optimal for choose, in the user, should be minimally intrusive interests of "One Web" considerations, to allow the experience of user to select the information and as far experience from broad categories such as possible should be consistent with other recommendations. mobile or desktop, where these presentations are distinguished in the application.
[CAPABILITIES] Exploit device capabilities. Do not adopt take a least common denominator approach. (Informative)
It is not the intention that While encouraging implementations content providers to be sensitive to the needs of baseline devices should result the default delivery context, it is not intended that this results in a diminished experience on more capable devices. Specifically it is not the intention the to encourage the development of sites that have a uniform baseline targeted presentation target the default delivery context when a better user experience could be attained on more capable devices.
[DEFICIENCIES] Take reasonable steps to work around such deficiencies. deficient implementations. (Informative)
Just as in the desktop browser world, there are browsers that do not respect the intentions of the content provider. There are differences in interpretation between browsers and there are also deficiencies in implementation. Because the software in mobile devices is frequently embedded in the device there is no easy way to correct or enhance software once it is in the field. It's
It is a particular challenge to provide work-arounds for these deficiencies and differences in interpretation. 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.
Just as it is not the intention to recommend a least common denominator approach, it's it is not the intention to recommend non-use avoidance of features which that exhibit problems on some class of devices.
It's It is also not the intention to suggest that implementations content providers should restrict their support to certain client types. Implementations Content providers should aim to support as wide a range of client types as is practical.
[TESTING] Carry out testing on actual devices as well as emulators. (Informative)
Any web site should be tested in a range of browsers. Mobile browsers often show markedly different characteristics to desktop browsers. As well as assessing a site's suitability for display in reduced format, authors content providers are encouraged to test that the features they rely on work in actual devices.
Many manufacturers provide emulators for their device that can provide a convenient preliminary means of testing. However, in practice, many of the emulators behave in a different way to the devices they emulate. Consequently testing should be carried out in as wide a range of real devices as is practical.
Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile clients, care should be exercised in defining the structure of a site and the navigation model for the site.
[URIS] Keep the URLs URIs of site entry points short short. (informative)
[NAVBAR] Provide information about the general layout of a site (e.g., a site map or table of contents) Use a small graphic minimal navigation at the top of the page to illustrate what site the user is on and where on the site they are at page. (Informative)
A site map Two or three links should be a collection of links that provides full access enough to provide the main sections basic navigation. Navigation should be placed on the top of the website or that offers some page. Any other selection secondary navigational element may be placed at the bottom of links which are useful for site navigation. the page if really needed.
A simple vertical list of Provide the basic links may be used as site map , if it can benavigated easily. In addition to on a sitemap single line. If they do not fit the author may choose to use a small graphic at screen the top device will take care of each page to illustrate what site the user is on and where on the site they are located. 5.3.2.3 References and Sources This relates to WCAG 13.3 wrapping.
[BALANCE] Design the service should be designed with a broadly balanced navigation tree where numbers of links on pages is balanced against depth of navigation. (Informative)
The design should aim to provide a balance between providing having an excessive number of navigation links on a page and the need to navigate multiple links to reach content. Each retrieval of a navigation page takes time, time and adds cost, so the number of links on a page should not be minimized at the expense of adding page retrievals.
[THEMATIC_CONSISTENCY] Ensure that links provide a thematically coherent experience when accessed from a device other than the one on which they were captured. (Informative)
The representation of a URI (the page that This is delivered when a device accesses a URI) may not look the same or contain identical content when accessed from different devices, because in the interests realization of usable site navigation the pagination may One Web principle, whereby content should be different for different accessible on a range of devices and irrespective of differences in the presentation capabilities. Web sites may paginate their content in order various ways corresponding to use capabilities differences in device characteristics; therefore the navigation structure of different devices appropriately it the site, and possibly its technical realization, may look different. vary according to the device class that is being served.
However, an important principle of One Web [link] is that a URI A bookmark captured on one device should be usable on any device. So if a user another different type of one device sends a bookmark, or link, to another user that even if it does not have yield exactly the same device, their intention in sending experience. If the page that URI must be respected and was bookmarked is not appropriate for the second user device that is now using it, an alternative that is suitable should be presented with information that the first user had intended provided.
In addition, URIs may be decorated to communicate. provide session or other information.
See [Techniques] for a discussion of how to locate an appropriate point in a site's navigation structure when If the requested URI does not match is decorated with session information that is no longer current then the user should be directed to a location point in the structure navigation hierarchy that is appropriate to the client making the request. their device, in order to establish appropriate session and other parameters.
[NAVIGATION] Use navigation mechanisms in a consistent manner Group related links, identify the group and provide a way to bypass the group manner. (Informative)
Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.
Since mobile users without pointing devices must execute several clicks between navigational jumps it is prudent to minimize this movement across the content.
Intelligent grouping, perhaps optimized through adaptation according to usage patterns patterns, can assist usability.
A "drill-down" method, based on major headings, can often provide an effective means of navigation. And navigation; because of the linearized arrangement of content, small screen size and lack of pointing device, it is often useful to provide a means to jump entire sections of content.
At each target of the drill down navigation an "up" link should be provided to allow the user to jump up an entire section.
See [Techniques] for further discussion of site navigation mechansims.[ACCESS_KEYS] Assign access keys to Links, Form Controls links in navigational menus and Groups of Form Controls frequently accessed functionality. (Normative)
Assigning Where there is no pointing device, assigning an access key (keyboard short cut) to a link provides can provide a convenient way for users to access the link, and avoid having to navigate navigating to the link by repeated pressing of the navigation key, where there is no pointing device. key .
There is no standard way of displaying Machine Test: Test for the assignment of an access key to a link. The access key section of [Techniques] discusses a number presence of techniques for implementing Access Keys, including keeping functionality consistent across browsers. the accesskey attribute.
[LINK_TARGET_ID] Clearly identify the target of each link. Use clear, concise, descriptive link in a way that allows users text to help users decide in advance whether to follow it, including a link. Identify the 'cost' implications of following it a link if the target is notably large and the user might not anticipate this from the context. (Normative)
Clearly identify links to content that[LINK_TARGET_FORMAT] Note the target file's format unless you know the device may not be able to interpret supports it. (Normative)
Users of mobile devices may suffer undue delay and cost as a result of following links. It's It is important to identify where a link leads so users can make an assessment of whether following it will be of interest to them. While implementations are it is unlikely to be able to specify that the cost in monetary terms of a particular user following a particular link, link can be specified, it should be possible to give an idea of the size of the resource [in bytes or in an abstract way e.g. e.g., large file].
Links to content that is in a different format to the format of the page the link is on (i.e. content that can only be interpreted by other applications, downloads) should be human signposted, so that users are not lead to download content that their device may not be able to use.
See [Techniques] Human Test: Check for a discussion proper descriptions (and no use of Link Target Identification. Providing 'teasers' may help in some cases. "Click here").
Human and Machine Test: Spider the page/web site to find links to non-HTML formats and check whether there is information about the format of the target of the link
[IMAGE_MAPS] Do not use image maps unless you know the target client supports them and has sufficient screen real estate area and an appropriate means of selection, such as a stylus or navigation keys. When using image maps under these circumstances, use client side image maps unless the regions required cannot be described with an available geometric shape shape. (Normative)
[SERVER_SIDE_IMAGE_MAPS] Do not use a server side image map unless you know that the client provides a means of selection within the image map map. (Normative)
Image maps allow fast navigation providing the requesting device can support the image involved and providing there is a means of navigating the map satisfactorily. Up, down, left, right, enter are available on most mobile devices, even if no pointing device is present, and this is usually sufficient to allow navigation of the active regions of client side image maps.
If only small images can be displayed, break larger images up into smaller sections and deal with them separately.
If a satisfactory image map cannot be displayed displayed, use lists a list of links with descriptive text instead.
IMAGE_MAPS Machine Test: Send a request to the site with a user agent that does not support client-side image maps and Sources check the map element is not present.
SERVER_SIDE_IMAGE_MAPS Machine Test: Send a request to the site with a user agent that does not support server-side image maps and check the ismap attribute is not present.
[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user user. (Normative)
[AUTO_REFRESH] Do not create periodically auto-refreshing pages pages, unless you have informed the user and provided a means of stopping it. (Normative)
[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of http HTTP 3xx codes codes. (Normative)
Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction.
Some mobile devices use a separate window for input; this section does not refer to such windows.
Many mobile devices cannot support more than one window and consequently attempting to open one will have unpredictable results. In general, the users user's consent should be sought before initiating the download of content.
Auto refreshing pages are widely recognized as presenting accessibility problems, and in a mobile environment may expose the user to undue cost as a result of an auto refreshing page being left open, or put unnoticed into the background. If an auto refreshing page is demanded by the application always provide a means of ceasing the auto refresh and always inform the user that the page will refresh and may expose them to high usage costs.
While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser which browser. This adds to delay on slow links. Hence links, hence redirection should not be used as a matter of course.
See [Techniques] POP_UPS Machine Test: Look for a discussion of redirection, especially the use of http 3xx. target attribute on links.
AUTO_REFRESH Machine Test: Check whether <meta http-equiv="refresh" content=" the same URI "/> is used.
AUTO_REFRESH Human Test: If auto refresh is used, check that options are provided to stop any page using auto-refresh.
REDIRECTION Machine Test: Check whether <meta http-equiv="refresh" content=" a different URI "/> is used.
This section refers to the user's perception of the delivered content. It concentrates on design, the language used in its text and the spatial relationship between constituent components. It does not address the technical aspects of how the delivered content is constructed, which is discussed in 5.4 Page Definition
[SUITABLE] Ensure that content is suitable for use in a mobile context context. (Informative)
[CLARITY] Use the clearest and simplest language appropriate for a site's content content. (Informative)
Content should be limited[LIMITED] Limit content to what the user has requested requested. (Informative)
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.
The general prescription to use clear language is of particular importance in the mobile context where brevity and directness are generally more desirable than a discursive style.
Writing content in the traditional journalistic 'front loaded' "front loaded" style can assist users determining whether information is of interest to them and allow them to skip it more easily if it is not. [It also assists with some summarization and truncation techniques]. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area.
In many cases the user pays for bandwidth in the mobile context, and offering the user content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience.
This relates Examine content to WCAG 13.8 and 14.1 5.4.2 Consistency Create a style of presentation that is consistent across pages 5.4.2.1 What determine if, given the subject matter, it means Consistency of design helps users orient themselves is appropriate in the site and find information they are looking for more easily. a mobile content. [NB probably not machine-testable.]
[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions portions. (Normative)
The[PAGE_SIZE_LIMIT] Ensure that the overall size of page should be is appropriate to bandwidth, the memory limitations of the device and other device and delivery channel characteristics if they can be determined determined. (Normative)
If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions as to the largest page they can accommodate.
On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. Since, in the mobile environment, This can lead to an unnecessary delay since each request typically takes a measurable time to complete, this can lead to an unnecessary delay. complete.
The balance between pagination and scrolling is partly a matter of taste and partly a matter of necessity. Devices with severe memory restrictions can only have small pages delivered to them. Equally some devices offer a poor scrolling experience, experience and a better page retrieval experience.
Some studies [MF] have been carried out in this area to test for user preferences. Some of these indicate that users prefer scrolling to click-throughs and some indicate the contrary. More research is likely to be needed in this area.
See [Techniques] PAGE_SIZE_USABLE Machine Test: Check that the page doesn't exceed 10 KBytes for the default delivery context.
Human Test: Check that the page is still usable (e.g. not cut in the middle of a discussion on Pagination sentence, just before the end of a section, and so on).
PAGE_SIZE_LIMIT Machine Test: Measure the total size of mark-up and images for a page; checks it doesn't go over the allowed size for the device - 20 KBytes for the default delivery context.
[SCROLLING] Limit scrolling should be in to one direction Where an object direction, unless secondary scrolling cannot be presented without avoided. (Normative)
[SCROLLING_LIMIT] Limit secondary scrolling it must not cause the rest of the page to objects that require scrolling it, where it cannot be avoided. (Normative)
The page should lay out so that simple repeated scrolling allows the user to experience all its content, however content. However some content (such as maps and other images) cannot be displayed without two way secondary scrolling.
If some element on the page requires two way secondary scrolling it must not cause the remainder of the page to require this. For example, if an object causes subsequent text to lay out with a significant margin to its left, then this text may not be visible once a user has scrolled past the object.
Equally, if the presence of such an object causes text to lay out render beyond the right boundary of the page then the user will be required to scroll to read each line of text.
If it is not possible to avoid presenting images that are larger than the screen size, then consider providing these images on a separate page with a link back to the main content.
SCROLLING Machine Test: Check for width attributes and width style properties wider than the screen size, for the default delivery context, 120 pixels.
Human Test: If it is wider, check that the use case warrants it (e.g. maps).
SCROLLING_LIMIT Human Test: Browse URIs within a site with a mobile user agent and observe that pages with elements that require secondary scrolling, only those elements require it and the rest of the page requires only primary scrolling.
[CENTRAL_MEANING] Ensure that material that is not central to the meaning of the page should not precede precedes material that is. is not. (Normative)
Many Web pages are designed with significant navigational and other elements at the top of, of or to the side of the page (e.g. Menu Bars, Breadcrumb Trails, Search Functions). This provides a convenient and well-understood navigational metaphor on large displays. However, on small displays this can result in the navigation appearing instead of the actual content of the page when the page is first retrieved.
Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page.The page. The user should not have to scroll significantly to find the primary content of the the page.
Menu selections can be placed further down the page with a simple link at the top of the page that allows the user to select navigation from the top of the page, Or page or use meta navigation on top of the page with simple text links to major sections of the web site.
[GRAPHICS_FOR_SPACING] Do not use graphics for layout spacing. (Normative)
Don't[LARGE_GRAPHICS] Do not use large graphics graphics. (Normative)
The popular mechanism of using a 1 pixel large graphic for absolute positioning is not suited for display on a variety of screens and must therefore not be used.
Graphics which that are larger than the must be, necessary, for example by possessing a higher resolution than is displayable on the device or by having too many colors colors, waste bandwidth.
[USE_OF_COLOR] Ensure that information conveyed with color is also available without color color. (Normative)
[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast Keep the number of colors to a minimum contrast. (Normative)
Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence relying on color highlighting of information highlighted in color may not be visible to users. If color is used to indicate a feature it is a good idea to indicate that feature in a non way that is not color dependent way. dependent. In particular, don't do not use blue or purple text, as this may be confused with hyper-links, hyperlinks, especially on device devices that do not underline links.
[BACKGROUND_IMAGE_SUPPORT] Do not use background images unless you know the device supports them them. (Normative)
[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on your target devices the device. (Normative)
Images which that are used indiscriminately can lead to content that is hard to view, particularly with the limited contrast often found on mobile devices and in the hostile viewing conditions that in which mobile founds devices are frequently use in. used.
Before using background images, consider carefully your objectives for doing so and try to use alternative techniques to achieve similar objectives.
[PAGE_TITLE] Provide a short but descriptive page title. (Normative)
Provide a descriptive title for your the page to allow easy identification. Keep the title as short as is possible to reduce page weight and bearing bear in mind that it may be truncated truncated.
Many mobile browsers do not display the title of a page, and where page. Where the title is displayed the available space may be limited.
The client may use the page title as the default label for bookmarks. Again space may be limited so use it to help identify the content and not for other purposes.
[NO_FRAMES] Do not use frames. (Normative)
Many mobile clients do not support Frames. frames. In addition, frames are recognized as being generally problematic.
See [Techniques] Machine Test: Test for a discussion presence of the alternatives to Frames frame related elements - in HTML check for frameset and iframe elements.
See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.
[STRUCTURE] Ensure that perceivable structures within the content can be programmatically determined. (informative)
It is good practice for all but the simplest documents to indicate their structure through headings and sub-headings. Using structural markup, rather than formatting effects, allows easier adaptation of content where it needs to be divided into several pages as well as potentially facilitating access only to the sections of the document that a user is interested in.
Where headers are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.
Structural markup must not be used solely to create a font effect.
Mark up languages like HMTL contain many contructs constructs to indicate structure.
[TABLES_SUPPORT] Do not use tables unless the client is known to support them them. Do not use multi-layer tables. (Normative)
[TABLES_LAYOUT] Do not use tables for layout layout. (Normative)
[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation Where tables are used: provide a summary identify row and column headers provide abbreviations for header labels do not use multi-layer tables presentation. (Informative)
Tables do not work well on limited size screens and may result in the user having to scroll horizontally to read them. Putting navigational links into tables may result in the user having both to scroll horizontally and vertically to see possible navigational choices.
See [Techniques] for alternatives TABLES_SUPPORT Machine Test: Send a request to using the site with a user agent that does not support tables for presentation of information and check the TABLE element is not present.
Machine Test: Check that there are no nested tables.
TABLES_LAYOUT Machine Test: Check that no column or row in a table is empty or contains only a 1x1 transparent GIF.
[NON-TEXT_ALTERNATIVES] Provide textual alternatives for non-text elements elements. (Normative)
[OBJECTS_OR_SCRIPT] Do not embed objects or script in pages unless you know the device supports them When an appropriate markup language exists use markup rather than images to convey information if the device supports it. Always specify the size of images in markup When resizing images do so at the server them. (Normative)
Downloading images to a mobile client requires the browser to fetch images and to download them, which adds to the time to display an image and the cost of displaying the page. Making the page readable in text only mode can help the user assess its usefulness before images arrive.
Many mobile clients do not support embedded objects or script and in many cases it is not possible for users to down load plug-ins to add support. Content must be designed with this in mind.
Resizing images at the server and specifying their size in mark up assists the browser to flow the text, reduces amount of data transferred and the amount of processing the client has to carry out to scale the image.Design pages as though they were to be displayed on a text-only browser.
Always
use
features
of
the
markup
designed
to
support
alternate
rendering
such
as
the
longdesc
and
alt
attributes
in
XHTML
XHTML.
Use only features from the markup that are known to be supported by the device in question.
Avoid things like CSS image replacement and actual pictures of words.
NON-TEXT_ALTERNATIVES Machine Test: Test for presence of alt attribute on images and Sources text content on objects.
Human Test: Check the relevance of alt attributes with their elements.
OBJECTS_OR_SCRIPT Machine Test: Send a request to the site with a user agent that does not support scripts and check the SCRIPT element is not present.
Machine Test: Send a request to the site with a user agent that does not support objects and check the OBJECT element is not present.
[IMAGES_SPECIFY_SIZE] Always specify the size of images in markup. (Normative)
[IMAGES_RESIZING] Resize images at the server. (Normative)
[VALID_MARKUP] Create documents that validate to published formal grammars. (Normative)
If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.
Use one of a number of validation tools, as described in [Techniques] to validate the output of the implementation. Machine Test: Validate documents.
[MEASURES] Do not use pixel measures and do not use relative rather than absolute units in markup language attribute values and style sheet property values Do not specify an absolute page width Reduce the number of different font sizes values. (Normative)
Avoiding pixel and absolute measures allows the browser to adapt content to fit the display. An exception to this being rule is where an image has been specifically sized for a display, particular display. In this case references to the image in markup may specify the exact dimensions of the image in pixels, in order to help the browser to flow the page, and avoid re-flowing it after the page has been retrieved.
Use percentage and other relative measures as described in [Techniques]. measures.
If you give clues in your markup as to the purpose of the content then it is a lot easier for adaptation mechanisms to present your content in Machine Test: Send a usable way. [The group is at present unclear as request to what it means by Semantic Markup and this section is the site with a placeholder] 5.5.8.2 References and Sources This relates to WCAG 13.2 user agent that supports relative measures correctly and 13.9 check the values of font-size are not absolute or pixels.
[STYLE_SHEETS_USE] Use style sheets, use this mechanism sheets to control layout and presentation presentation, unless the device is known not to support them. (Normative)
[STYLE_SHEETS_SUPPORT] Organize documents so that they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets it must still be possible to read the document (Normative)
[STYLE_SHEETS_SIZE] Keep style sheets as small as possible. (Normative)
Clients provide several levels of support for style sheets. Some provide full implementations including caching of external style sheets. Some do not cache external style sheets, and for these devices embedding the style information in the delivered page is more efficient than the browser making repeated retrievals for the style sheet across a site. Some implementations do not support style sheets at all.
See [Techniques] for STYLE_SHEETS_USE Machine Test: Send a detailed discussion of request to the site with a user agent that supports CSS and check that style sheets are used and that the page does not use of formatting tags (e.g. font).
STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and checks that the page is still readable.
STYLE_SHEETS_SIZE Machine Test: Check that the elements in a style information sheet are used in documents. the pages that reference it.
[MINIMIZE] Use terse efficient markup markup. (Normative)
Content which is marked up up in languages such as XML can often be made smaller while preserving the exact same semantics, semantics merely by removal of redundant white space (i.e. spaces and new lines).
Marking
fonts,
colors
and
other
stylistic
effects
in
line,
can
cause
considerably
larger
page
sizes
when
compared
with
using
logical
markup,
and
use
of
the
HTML
class
attribute
for
application
of
style.
Use of markup formatting programs which aim to make While we do not intend that authors should create their content more readable by humans, contributes considerably in a single line to remove white space altogether, we suggest that authors should not contribute to page weight by introducing unnecessary white space. We point out that "Pretty Printing", i.e. the formatting of mark-up with programs such as HTML Tidy, with indent option set to "yes", can generate large amounts of white space and should not be used hence add to format content for delivery page weight.
If "pretty printing" is an important part of the authoring process then try to mobile devices; instead arrange that redundant white space is stripped when serving a page.
Even though some network proxies strip white space that they think is redundant, not all possible redundant do so, so it is not best practice to rely upon this behavior. There are other issues relating to network proxies (such as requesting them not to strip relevant white space. space). Such issues will be addressed in a later phase.
Use of structural markup contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS.
[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device. (Normative)
[CONTENT_FORMAT_PREFERRED] Where possible send content in a client's preferred format. (Normative)
Transferring content that a client cannot display wastes users users' time and money. Preference may be expressed by a client for one format rather than another. In this case it is good practice to respect the client's preference - as it may have a fuller implementation of its preferred markup.
Web To determine what formats a device supports, web sites should may use a any combination of device profile information such as the HTTP User-Agent and header, HTTP Accept headers, UAProf headers and other device profile information to determine what formats a device supports. UAProf.
There are problems with using any one approach to the exclusion of the others. Some issues that have been noted by the BPWG in this context are:
Not all devices supply accept headers headers;
Some devices state that they accept all formats */* when they do not support some common formats, formats and also mis-state their capabilities capabilities;
Some operator gateways supplement the accept headers as they adapt content presented in formats that the device does not accept accept;
User Agent headers do not always uniquely identify the device device;
UAProf information may not be available or may be incomplete incomplete.
Further detailed discussion CONTENT_FORMAT_SUPPORT Machine Test: Check MIME types of heuristics for determining which formats a device supports content with various User-Agent
Machine Test: Check MIME types of content with various user agents.
CONTENT_FORMAT_PREFERRED Machine Test: Check MIME types of content with various user agents and check that the preferred format is contained in [Techniques]. sent or that the format is compatible with the default delivery context.
[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character set encoding that is known to be supported by the target device. (Normative)
[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used. (Normative)
As in the previous section, content should not be sent to a device if it can't can not use it.
The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header sent with a request. request (see also the section above on determining device characteristics) characteristics).
For The character encoding being used in a response may be indicated using the HTTP Content-Type header.
Example:
Content-Type:
text/html;
charset=utf-8
Additionally for XML content documents the character encoding may be specified indicated in the encoding declaration [XMLENC]Example: declaration [XMLENC] although this will generally be ignored if an HTTP Content-Type header is present.
Example:
<?xml
version="1.0"
encoding="UTF-8"?>
The 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 [HTTP_CHARSET]
[ERROR_MESSAGES] Provide informative error messages, and a means of navigating away from an error message back to useful information. (Normative)
It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought. Providing easy navigation away from the error is particularly important in the mobile arena, where browsers may not have an easy-to-find "back" button, where contextualization is frequently difficult and where re-entry of URIs as a response means of error recovery is particularly onerous.
It is noted that errors due to networking, connection and some kinds of mistyping of URIs are not within the control of the content provider which has no way to influence how such errors are presented to the user. However, where errors are within the control of the content provider the user should be provided with clear information regarding the fault they have experienced. This should help them to understand whether the fault was temporary or permanent, whether they should retry the attempt to access the content, and how they may be indicated using the HTTP Content-Type header.Example: Content-Type: text/html; charset=utf-8 able to escalate the problem.
It should also be possible for the user to escape from the error condition. They should either be able to return back to the page they were on previous to the error, or to be able to move onwards to a convenient part of the service from where they can retry or alter the transaction they were attempting.
It is noted that many web servers provide a default error page especially in the event of a request for a non-existent page (404) or an internal error (500). Where possible (see [TOMCAT] , [APACHE] and [IIS] ), applications should trap all error conditions by overriding the default pages if necessary, and handle them in a user-friendly, and graceful, way.
Error messages should be provided in the same language as the application that was being used. They should be clear and concise, adhering to the same best practices as the rest of the application. They should be provided in a format that the device can handle.
The error message should detail whether the issue is likely to be temporary or permanent, whether the user may be able to solve the issue themselves (for example, by changing input data, or a handset setting), or whether it is an issue that can be escalated to the content provider or network operator. In the latter case, contact details, such as an SMS address or a support line number, might be appropriate.
Navigationally, the error message should provide one or more of:
A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);
A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");
A "home" link to allow the user to proceed back to the main part of the application.
The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.
Enter an extraneous URI, known not to represent an actual resource on the site, and Sources check that a HTTP 404 error response is accompanied by a page whose markup is appropriate for the requesting device, or the default context.
Human Test: Check that the page returned contains an explanation of the error and appropriate corrective actions, without assuming any technical knowledge on the part of the end user.
[COOKIES] Do not use cookies unless you know the device supports them. (Normative)
XMLENC XML Character Encoding http://www.w3.org/TR/2004/REC-xml-20040204/#charencoding Cookies are frequently used both to carry out session management and to capture user preferences. Many devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies.
[CACHING] Attach caching information to the content. (Normative)
Since a low bandwidth and a high latency can reduce the usability of a Web site on a mobile device, it is most useful to provide enough caching information to the user agent so that it does not need to reload data (e.g. style sheets, images) that it is already available locally.
The HTTP protocol provides a well-defined framework for this caching mechanism that can only be optimally used if the delivered content provides enough information (e.g. an ETag header).
This section contains statements relating to user input. User input is typically more or a lot more restrictive on Mobile devices, which may lack pointing devices and usually do not have a standard keyboard with which to enter text.
[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum minimum. (Informative)
[AVOID_FREE_TEXT] Avoid free text entry where possible possible. (Normative)
[PROVIDE_DEFAULTS] Provide pre-selected default values where possible possible. (Normative)
Use selection lists where possible[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the target device is known to support it. (Normative)
Given the typical input limitations of a mobile device 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.
Some markup languages allow the specification of an input mode, which is particularly useful in cases where user input is to be restricted, for example to numeric only. It is anticipated that XHTML basic will support this functionality.
Specification of the natural language required for assists with predictive text input.
There are a number of techniques available for this including:
Where possible use previous entries as defaults.
Make it possible to select items using navigation keys and/or numeric input.
Further discussion AVOID_FREE_TEXT Machine Test: Check whether <input type="text"> and <textarea> are used.
Human Test: If one of this them is used, check whether it can be found under [Techniques]. replaced by a pre-determined entry.
PROVIDE_DEFAULTS Machine Test: Check if there is a pre-selected value in controls (selected or checked attribute set).
Human Test: If not, check if there could be sensible pre-selection in the context (e.g. most common choice).
DEFAULT_INPUT_MODE Machine Test: Send a request with a user agent known to support the inputmode attribute and check for the presence of the inputmode attribute on <input type="text"> and <textarea> elements.
[TAB_ORDER] Create a logical tab order through links, form controls and objects objects. (Normative)
It's It is important that as the user navigates through the page the various fields and objects are presented in a logical order, especially as many of them will not be visible at the same time as the focus item.
[CONTROL_LABELLING] Label all controls appropriately. Explicitly associate labels explicitly with their controls and until user agents support explicit associations between where the device supports this. Position labels and form controls, for all form relative to controls with implicitly associated labels ensure the label is properly positioned appropriately. (Normative)
These mean This means use the label element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the control so re-flowing or or adapting the content intelligently will always recognize label controls and keep them together.
This provision is particularly relevant Conformance to predictive text input. 5.6.4.2 How this document requires conformance to do it each and every one of the Statements, except where required to satisfy the needs of deficient implementations as noted under [ DEFICIENCIES ].
Use xml:lang attributes if appropriate All of the Best Practice Statements have a fragment identifier to allow formal reference to them and allow the mark up language in question, or equivalent mechanisms in other markup languages. construction of compliance claims that refer to them.
The default language Best Practice Statements are intended to be capable of having conformance statements constructed around them, in support of the mobileOK trustmark and for other purposes. Work on the mobileOK trustmark will develop specific recommended requirements for a document may also trustmark, which will be specified using based on some profile, or subset, of the Content-Language http header. Statements in this document.
As such, the mobileOK trustmark will serve as the main conformance claim for the best practices document.
This relates specification applies to WCAG 4.1 one class of product: content as it gets delivered to a Web user agent, including the metadata transferred as part of the delivery protocol.
The normative parts of this specification consist of the Best Practices statements marked as normative. All the other parts are informative, except this section.
On desktop browsers there is often a 'context menu' i.e. This specification may be compatible with other specifications which describe a menu that pops up next to different set of requirements for content, insofar as such requirements do not conflict with the mouse. This feature is frequently absent on mobile devices. current specification.
[to be done after The best practices agreed] practice statements have been assembled by the BPWG from a number of sources. Primary among those are:
Various BPWG group meetings and mobileOK discussions
[to be done] WCAG Guidelines 1.0 [WCAG]
iMode Guidelines [iMode]
A Glossary (Non-Normative)[to be done] Opera's "Making Small Device Look Great" [Opera]
[ Definition : HTML Hypertext Markup Language] Openwave Guidelines [OpenWave]
Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP]
Browsing on Mobile Phones, Nokia [Nokia-VR]
Little Spring Design [LSD]
Sprint PCS Web Style Guide [Sprint]
While the best practice statements have primarily been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.
The editors would like to thank the members of the Best Practices Working Group BPWG for their contributions of various kinds. The editors would also like to thank contributors to the public list, whose comments have been taken into account in the creation of this document.
The editors acknowledge significant written contributions to this draft from: