index.html
131 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><title>Mobile Web Best Practices 1.0</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
.stmt, .stmt1
{ border: 1px solid black ;
background-color: #c0e0e0;
padding: 5pt}
.ednote {border: 1px dashed black ;
background-color: #FFc0c0}
.new {background-color: #FFFF80}
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css"/></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"/></a></p>
<h1><a name="title" id="title"/>Mobile Web Best Practices 1.0</h1>
<h2><a name="subtitle" id="subtitle"/>Basic Guidelines</h2>
<h2><a name="w3c-doctype" id="w3c-doctype"/>W3C Recommendation 29 July 2008</h2>
<dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2008/REC-mobile-bp-20080729/">http://www.w3.org/TR/2008/REC-mobile-bp-20080729/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/mobile-bp/">http://www.w3.org/TR/mobile-bp/</a>
</dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2006/PR-mobile-bp-20061102/">http://www.w3.org/TR/2006/PR-mobile-bp-20061102/</a>
</dd><dt>Editors:</dt><dd>Jo Rabin, mTLD Mobile Top Level Domain (dotMobi)</dd><dd>Charles McCathieNevile, Opera Software [Early Drafts]</dd></dl>
<p>Please refer to the <a href="http://www.w3.org/2008/07/mwbp-errata.html"><strong>errata</strong></a> for this document, which may include some normative corrections.</p>
<p>See also <a
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=mobile-bp"><strong>translations</strong></a>.</p>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr/><div>
<h2><a name="abstract" id="abstract"/>Abstract</h2><p>This document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to improve the user experience of the Web when accessed from such devices.</p><p>The recommendations refer to delivered content and not to the processes by which it is created, nor to the devices or user agents to which it is delivered.</p><p>It is primarily directed at creators, maintainers and operators of Web sites. Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers and HTTP. Readers are not expected to have a background in mobile-specific technologies.</p></div><div>
<h2><a name="status" id="status"/>Status of this Document</h2>
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
<p>This document was developed by the <a href="http://www.w3.org/2005/MWI/BPWG/">Best Practices Working Group</a> (BPWG) as part of the <a href="http://www.w3.org/2005/MWI/Activity">Mobile Web Initiative</a>.</p>
<p>Please see the Working Group's <a href="http://www.w3.org/2006/06/mwbp-implementation-report">implementation report</a>. Changes since the previous version of the document are editorial. A complete <a href="diff.html">list of changes</a> made to this document is available. Note the document stayed in Proposed Recommendation for more than a year as it depended on the progress of XHTML Basic 1.1 on the Recommendation track.</p>
<p>Please send comments about this document to <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> (with <a href="http://lists.w3.org/Archives/Public/public-bpwg-comments/">public archive</a>).</p>
<p>This document combines the experience of many mobile Web stakeholders into one set of best practices, regarded as essential by the participants of the Working Group.</p>
<p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>
<p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. This document is informative only. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/37584/status"> public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>
</div>
<div class="toc">
<h2><a name="contents" id="contents"/>Table of Contents</h2><p class="toc">1 <a href="#d0e113">Introduction</a><br/>
1.1 <a href="#d0e116">Purpose of the Document</a><br/>
1.2 <a href="#d0e128">How the Best Practices are Organized</a><br/>
1.3 <a href="#d0e163">Audience</a><br/>
1.4 <a href="#d0e172">Scope</a><br/>
1.4.1 <a href="#phasing">Phasing</a><br/>
1.5 <a href="#d0e201">Relationship to other Best Practices and recommendations</a><br/>
1.6 <a href="#d0e226">Longevity and Versioning</a><br/>
2 <a href="#requirements">Requirements</a><br/>
2.1 <a href="#d0e240">Presentation Issues</a><br/>
2.2 <a href="#d0e253">Input</a><br/>
2.3 <a href="#d0e264">Bandwidth and Cost</a><br/>
2.4 <a href="#UserGoals">User Goals</a><br/>
2.5 <a href="#d0e282">Advertising</a><br/>
2.6 <a href="#d0e289">Device Limitations</a><br/>
2.7 <a href="#d0e304">Advantages</a><br/>
3 <a href="#d0e347">Delivery Context</a><br/>
3.1 <a href="#OneWeb">One Web</a><br/>
3.2 <a href="#ca">Background to Adaptation</a><br/>
3.3 <a href="#d0e402">Adaptation Implementation Model</a><br/>
3.4 <a href="#d0e428">Assumptions about Adaptation</a><br/>
3.5 <a href="#d0e437">Establishing Context</a><br/>
3.6 <a href="#d0e451">Choice of User Experience</a><br/>
3.7 <a href="#ddc">Default Delivery Context</a><br/>
4 <a href="#bpstructure">Structure of Best Practice Statements</a><br/>
5 <a href="#d0e630">Best Practice Statements</a><br/>
5.1 <a href="#bpgroupgeneral">Overall Behavior</a><br/>
5.1.1 <a href="#tc">Thematic Consistency of Resource Identified by a URI</a><br/>
5.1.2 <a href="#lcd">Exploit Device Capabilities</a><br/>
5.1.3 <a href="#d0e704">Work around Deficient Implementations</a><br/>
5.1.4 <a href="#test">Testing</a><br/>
5.2 <a href="#bpgroupnavlinks">Navigation and Links</a><br/>
5.2.1 <a href="#d0e742">URIs of Site Entry Points</a><br/>
5.2.2 <a href="#d0e773">Navigation Bar</a><br/>
5.2.3 <a href="#d0e790">Balanced Structure</a><br/>
5.2.4 <a href="#d0e804">Navigation Mechanisms</a><br/>
5.2.5 <a href="#d0e831">Access Keys</a><br/>
5.2.6 <a href="#d0e864">Link Target Identification</a><br/>
5.2.7 <a href="#d0e911">Image Maps</a><br/>
5.2.8 <a href="#d0e959">Refreshing, Redirection and Spawned Windows</a><br/>
5.2.9 <a href="#el">Externally Linked Resources</a><br/>
5.3 <a href="#bpgroupplayout">Page Layout and Content</a><br/>
5.3.1 <a href="#cl">Page Content</a><br/>
5.3.2 <a href="#d0e1099">Page Size</a><br/>
5.3.3 <a href="#d0e1146">Scrolling</a><br/>
5.3.4 <a href="#cm">Navigation Bars etc. (Extraneous material)</a><br/>
5.3.5 <a href="#d0e1219">Graphics</a><br/>
5.3.6 <a href="#d0e1240">Color</a><br/>
5.3.7 <a href="#d0e1272">Background Images</a><br/>
5.4 <a href="#bpgrouppdefinition">Page Definition</a><br/>
5.4.1 <a href="#d0e1294">Title</a><br/>
5.4.2 <a href="#d0e1321">Frames</a><br/>
5.4.3 <a href="#sm">Structural Elements</a><br/>
5.4.4 <a href="#d0e1374">Tables</a><br/>
5.4.5 <a href="#d0e1433">Non-Text Items</a><br/>
5.4.6 <a href="#ImageSize">Image Size</a><br/>
5.4.7 <a href="#d0e1584">Valid Markup</a><br/>
5.4.8 <a href="#me">Measures</a><br/>
5.4.9 <a href="#style">Style Sheets</a><br/>
5.4.10 <a href="#d0e1733">Minimize</a><br/>
5.4.11 <a href="#d0e1770">Content Types</a><br/>
5.4.12 <a href="#d0e1821">Character Encoding</a><br/>
5.4.13 <a href="#d0e1875">Error Messages</a><br/>
5.4.14 <a href="#d0e1925">Cookies</a><br/>
5.4.15 <a href="#d0e1945">Cache Headers</a><br/>
5.4.16 <a href="#fonts">Fonts</a><br/>
5.5 <a href="#bpgroupinput">User Input</a><br/>
5.5.1 <a href="#d0e2028">Input</a><br/>
5.5.2 <a href="#d0e2100">Tab Order</a><br/>
5.5.3 <a href="#d0e2133">Labels for Form Controls</a><br/>
6 <a href="#d0e2183">Conformance and mobileOK </a><br/>
6.1 <a href="#d0e2192">Classes of Products</a><br/>
6.2 <a href="#d0e2200">Extensibility</a><br/>
</p>
<h3><a name="appendices" id="appendices"/>Appendices</h3><p class="toc">A <a href="#d0e2206">Sources</a> (Non-Normative)<br/>
B <a href="#related">Related Reading</a> (Non-Normative)<br/>
C <a href="#d0e2280">Acknowledgements</a> (Non-Normative)<br/>
D <a href="#d0e2364">References</a> (Non-Normative)<br/>
D.1 <a href="#d0e2367">MWI References</a><br/>
D.2 <a href="#d0e2377">Sources</a><br/>
D.3 <a href="#d0e2397">Device Independence</a><br/>
D.4 <a href="#d0e2407">Web, Protocols and Languages</a><br/>
D.5 <a href="#d0e2432">Other References</a><br/>
</p></div><hr/><div class="front"><div class="div1">
<h2><a name="d0e104" id="d0e104"/>List of Best Practices</h2><p>The following Best Practices are discussed in this document and listed here for convenience. There is also <a href="http://www.w3.org/TR/mobile-bp/summary">a free-standing summary</a>.</p></div><div class="summary"><ol><li><p class="stmt">[<a href="#THEMATIC_CONSISTENCY">THEMATIC_CONSISTENCY</a>] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices. </p></li>
<li><p class="stmt">[<a href="#CAPABILITIES">CAPABILITIES</a>] Exploit device capabilities to provide an enhanced user experience.</p></li>
<li><p class="stmt">[<a href="#DEFICIENCIES">DEFICIENCIES</a>] Take reasonable steps to work around deficient implementations.</p></li>
<li><p class="stmt">[<a href="#TESTING">TESTING</a>] Carry out testing on actual devices as well as emulators. </p></li>
<li><p class="stmt">[<a href="#URIS">URIS</a>] Keep the URIs of site entry points short. </p></li>
<li><p class="stmt">[<a href="#NAVBAR">NAVBAR</a>] Provide only minimal navigation at the top of the page. </p></li>
<li><p class="stmt">[<a href="#BALANCE">BALANCE</a>] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.</p></li>
<li><p class="stmt">[<a href="#NAVIGATION">NAVIGATION</a>] Provide consistent navigation mechanisms. </p></li>
<li><p class="stmt">[<a href="#ACCESS_KEYS">ACCESS_KEYS</a>] Assign access keys to links in navigational menus and frequently accessed functionality. </p></li>
<li><p class="stmt">[<a href="#LINK_TARGET_ID">LINK_TARGET_ID</a>] Clearly identify the target of each link. </p></li>
<li><p class="stmt">[<a href="#LINK_TARGET_FORMAT">LINK_TARGET_FORMAT</a>] Note the target file's format unless you know the device supports it. </p></li>
<li><p class="stmt">[<a href="#IMAGE_MAPS">IMAGE_MAPS</a>] Do not use image maps unless you know the <span>device</span> supports them effectively.</p></li>
<li><p class="stmt">[<a href="#POP_UPS">POP_UPS</a>] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. </p></li>
<li><p class="stmt">[<a href="#AUTO_REFRESH">AUTO_REFRESH</a>] Do not create periodically auto-refreshing pages, unless you have
informed the user and provided a means of stopping it. </p></li>
<li><p class="stmt">[<a href="#REDIRECTION">REDIRECTION</a>] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes. </p></li>
<li><p class="stmt">[<a href="#EXTERNAL_RESOURCES">EXTERNAL_RESOURCES</a>] Keep the number of externally linked resources to a minimum.</p></li>
<li><p class="stmt">[<a href="#SUITABLE">SUITABLE</a>] Ensure that content is suitable for use in a mobile context. </p></li>
<li><p class="stmt">[<a href="#CLARITY">CLARITY</a>] Use clear and simple language. </p></li>
<li><p class="stmt">[<a href="#LIMITED">LIMITED</a>] Limit content to what the user has requested. </p></li>
<li><p class="stmt">[<a href="#PAGE_SIZE_USABLE">PAGE_SIZE_USABLE</a>] Divide pages into usable but limited size portions. </p></li>
<li><p class="stmt">[<a href="#PAGE_SIZE_LIMIT">PAGE_SIZE_LIMIT</a>] Ensure that the overall size of page is appropriate to the memory limitations of the device.</p></li>
<li><p class="stmt">[<a href="#SCROLLING">SCROLLING</a>] Limit scrolling to one direction, unless secondary scrolling cannot be avoided. </p></li>
<li><p class="stmt">[<a href="#CENTRAL_MEANING">CENTRAL_MEANING</a>] Ensure that material that is central to the meaning of the page precedes material that is not. </p></li>
<li><p class="stmt">[<a href="#GRAPHICS_FOR_SPACING">GRAPHICS_FOR_SPACING</a>] Do not use graphics for spacing. </p></li>
<li><p class="stmt">[<a href="#LARGE_GRAPHICS">LARGE_GRAPHICS</a>] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical
information would otherwise be lost.</p></li>
<li><p class="stmt">[<a href="#USE_OF_COLOR">USE_OF_COLOR</a>] Ensure that information conveyed with color is also available without color. </p></li>
<li><p class="stmt">[<a href="#COLOR_CONTRAST">COLOR_CONTRAST</a>] Ensure that foreground and background color combinations provide sufficient contrast. </p></li>
<li><p class="stmt">[<a href="#BACKGROUND_IMAGE_READABILITY">BACKGROUND_IMAGE_READABILITY</a>] When using background images make sure that content remains readable on the device. </p></li>
<li><p class="stmt">[<a href="#PAGE_TITLE">PAGE_TITLE</a>] Provide a short but descriptive page title. </p></li>
<li><p class="stmt">[<a href="#NO_FRAMES">NO_FRAMES</a>] Do not use frames. </p></li>
<li><p class="stmt">[<a href="#STRUCTURE">STRUCTURE</a>] Use features of the markup language to indicate logical document structure.</p></li>
<li><p class="stmt">[<a href="#TABLES_SUPPORT">TABLES_SUPPORT</a>] Do not use tables unless the <span>device</span> is known to support them.</p></li>
<li><p class="stmt">[<a href="#TABLES_NESTED">TABLES_NESTED</a>] Do not use nested tables.</p></li>
<li><p class="stmt">[<a href="#TABLES_LAYOUT">TABLES_LAYOUT</a>] Do not use tables for layout. </p></li>
<li><p class="stmt">[<a href="#TABLES_ALTERNATIVES">TABLES_ALTERNATIVES</a>] Where possible, use an alternative to tabular presentation. </p></li>
<li><p class="stmt">[<a href="#NON-TEXT_ALTERNATIVES">NON-TEXT_ALTERNATIVES</a>] Provide a text equivalent for every non-text element.</p></li>
<li><p class="stmt">[<a href="#OBJECTS_OR_SCRIPT">OBJECTS_OR_SCRIPT</a>] Do not rely on embedded objects or script.</p></li>
<li><p class="stmt">[<a href="#IMAGES_SPECIFY_SIZE">IMAGES_SPECIFY_SIZE</a>] Specify the size of images in markup, if they have an intrinsic size. </p></li>
<li><p class="stmt">[<a href="#IMAGES_RESIZING">IMAGES_RESIZING</a>] Resize images at the server, if they have an intrinsic size. </p></li>
<li><p class="stmt">[<a href="#VALID_MARKUP">VALID_MARKUP</a>] Create documents that validate to published formal grammars. </p></li>
<li><p class="stmt">[<a href="#MEASURES">MEASURES</a>] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values. </p></li>
<li><p class="stmt">[<a href="#STYLE_SHEETS_USE">STYLE_SHEETS_USE</a>] Use style sheets to control layout and presentation, unless the device is known not to support them.</p></li>
<li><p class="stmt">[<a href="#STYLE_SHEETS_SUPPORT">STYLE_SHEETS_SUPPORT</a>] Organize documents so that <span>if necessary</span> they may be read without style sheets.</p></li>
<li><p class="stmt">[<a href="#STYLE_SHEETS_SIZE">STYLE_SHEETS_SIZE</a>] Keep style sheets small.</p></li>
<li><p class="stmt">[<a href="#MINIMIZE">MINIMIZE</a>] Use terse, efficient markup. </p></li>
<li><p class="stmt">[<a href="#CONTENT_FORMAT_SUPPORT">CONTENT_FORMAT_SUPPORT</a>] Send content in a format that is known to be supported by the device. </p></li>
<li><p class="stmt">[<a href="#CONTENT_FORMAT_PREFERRED">CONTENT_FORMAT_PREFERRED</a>] Where possible, send content in a preferred format. </p></li>
<li><p class="stmt">[<a href="#CHARACTER_ENCODING_SUPPORT">CHARACTER_ENCODING_SUPPORT</a>] Ensure that content is encoded using a character encoding that is known to be
supported by the device. </p></li>
<li><p class="stmt">[<a href="#CHARACTER_ENCODING_USE">CHARACTER_ENCODING_USE</a>] Indicate in the response the character encoding being used. </p></li>
<li><p class="stmt">[<a href="#ERROR_MESSAGES">ERROR_MESSAGES</a>]
Provide informative error messages and a means of navigating away from an error message back to useful information. </p></li>
<li><p class="stmt">[<a href="#COOKIES">COOKIES</a>] Do not rely on cookies being available.</p></li>
<li><p class="stmt">[<a href="#CACHING">CACHING</a>] Provide caching information in HTTP responses.</p></li>
<li><p class="stmt">[<a href="#FONTS">FONTS</a>] Do not rely on support of font related styling.</p></li>
<li><p class="stmt">[<a href="#MINIMIZE_KEYSTROKES">MINIMIZE_KEYSTROKES</a>] Keep the number of keystrokes to a minimum. </p></li>
<li><p class="stmt">[<a href="#AVOID_FREE_TEXT">AVOID_FREE_TEXT</a>] Avoid free text entry where possible. </p></li>
<li><p class="stmt">[<a href="#PROVIDE_DEFAULTS">PROVIDE_DEFAULTS</a>] Provide pre-selected default values where possible. </p></li>
<li><p class="stmt">[<a href="#DEFAULT_INPUT_MODE">DEFAULT_INPUT_MODE</a>] Specify a default text entry mode, language and/or input format, if the device is known to support it. </p></li>
<li><p class="stmt">[<a href="#TAB_ORDER">TAB_ORDER</a>] Create a logical order through links, form controls and objects. </p></li>
<li><p class="stmt">[<a href="#CONTROL_LABELLING">CONTROL_LABELLING</a>] Label all <span>form</span> controls appropriately and explicitly associate labels with <span>form</span> controls.</p></li>
<li><p class="stmt">[<a href="#CONTROL_POSITION">CONTROL_POSITION</a>] Position labels so they lay out properly in relation to the <span>form</span> controls they refer to.</p></li>
</ol></div></div><hr/><div class="body"><div class="div1">
<h2><a name="d0e113" id="d0e113"/>1 Introduction</h2><div class="div2">
<h3><a name="d0e116" id="d0e116"/>1.1 Purpose of the Document</h3><p> This document sets out a series of recommendations designed to improve the user experience of the Web on mobile devices. </p><p>The recommendations are offered to creators, maintainers and operators of Web sites and are intended as the basis for assessing conformance to the mobileOK trustmark, which is described in the <a href="http://www.w3.org/2005/01/BPWGCharter/Overview.html">Mobile Web Best Practices Working Group Charter</a> and is not developed in this document. <span> At the time of writing of this document, documents describing mobileOK and techniques for implementing the Best Practice recommendations are being worked on.</span></p></div><div class="div2">
<h3><a name="d0e128" id="d0e128"/>1.2 How the Best Practices are Organized</h3><p>The document is organized as follows:</p><ol class="enumar"><li><p>Introduction. Describes the audience, purpose and scope of the document.</p></li><li><p>Requirements. An illustration of the type of problems that the Best Practices are intended to ameliorate.</p></li><li><p>Delivery Context. Discusses the environment within which mobile access to the Web is realized, with particular reference to adaptation.</p></li><li><p>Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.</p></li><li><p>Best Practices. The statements themselves.</p></li><li><p>Conformance and mobileOK. A brief conformance statement and reference to the mobileOK documentation.</p></li><li><p>Appendices</p><p>Sources</p><p>Related Reading</p><p>Acknowledgements</p><p>References</p></li></ol></div><div class="div2">
<h3><a name="d0e163" id="d0e163"/>1.3 Audience</h3><p>Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers and HTTP. Readers are not expected to have a background in mobile-specific technologies.</p><p>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.</p><p>The document is not targeted solely at developers; others, such as interaction and graphic designers are encouraged to read it.</p></div><div class="div2">
<h3><a name="d0e172" id="d0e172"/>1.4 Scope</h3><p>The scope of these Best Practices is laid out in "Scope of Mobile Web Best Practices" <a href="#Scope">[Scope]</a>. In summary, this document refers primarily to the extension of Web browsing onto mobile devices.</p><p>The Best Practice recommendations refer to delivered content. While they are clearly relevant to the processes of content creation and rendering on devices, they are not intended to be Best Practices for those activities.</p><p>As the goal of the document is to specify Best Practices for delivery to mobile devices, statements that do not have a specific mobile aspect are not included. In particular, many Web Content Accessibility <a href="#WCAG">[WCAG]</a> 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". </p><p>See <a href="#related"><b>B Related Reading</b></a> for information about the related topics of Internationalization, Web Accessibility and Device Independence.</p><div class="div3">
<h4><a name="phasing" id="phasing"/>1.4.1 Phasing</h4><p>As discussed in the Scope document <a href="#Scope">[Scope]</a> there are many aspects to Mobile Web Best Practices. At present, for example, the design and construction of many Web sites and pages make for a poor user experience when they are viewed on a mobile device.</p><p>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 and device usability are important (for reading, navigating, and interacting with content), this document focuses primarily on Best Practices for improving site usability.</p><p>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 multimodal interaction.</p></div></div><div class="div2">
<h3><a name="d0e201" id="d0e201"/>1.5 Relationship to other Best Practices and recommendations</h3><p>These recommendations are in part derived from the Web Content Accessibility Guidelines <a href="#WCAG">[WCAG]</a>. As noted above, WCAG guidelines are supplementary to the Mobile Web Best Practices, whose scope is limited to matters that have a specific mobile relevance.</p><p>This document builds on some of the concepts described by the <a href="http://www.w3.org/2001/di/">Device Independence Working Group</a> (DIWG) in the Device Independence Principles <a href="#DIP">[DIP]</a>. The document discusses device and delivery channel characteristics, which the DIWG has named "Delivery Context" <a href="#DCODI">[DCODI]</a>. In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence <a href="#DIGLOSS">[DIGLOSS]</a>.</p><p>The BPWG <span>is developing</span> a companion document describing techniques <a href="#Techniques">[Techniques]</a> by which the Best Practice statements in this document can be implemented.</p></div><div class="div2">
<h3><a name="d0e226" id="d0e226"/>1.6 Longevity and Versioning</h3><p>The Best Practices have been written at a level of generality that allows them to be applicable across a range of markup languages. They have been written with enduring properties of mobile access to the Web in mind. While the factors identified in <a href="#ddc">3.7 Default Delivery Context</a>, such as screen dimensions, will change over time, it seems likely that the distinguishing features of mobile access such as cost and difficulty of input will remain issues.</p><p>This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.</p></div></div><div class="div1">
<h2><a name="requirements" id="requirements"/>2 Requirements</h2><p>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.</p><div class="div2">
<h3><a name="d0e240" id="d0e240"/>2.1 Presentation Issues</h3><p>Today, Many Web pages are laid out for presentation on desktop size displays, and exploit capabilities of desktop browsing software.</p><p>Accessing such a Web page on a mobile device often results in a poor or unusable experience. Contributing factors include pages not being laid out as intended. Because of the limited screen size and the limited amount of material that is visible to the user, context and overview are lost.</p><p>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.</p><p>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 <span>and can be considerably diminished by an uneven style.</span></p></div><div class="div2">
<h3><a name="d0e253" id="d0e253"/>2.2 Input</h3><p>Mobile device input is often difficult when compared with use of a desktop device equipped with a keyboard. Mobile devices often have only a very limited keypad, with small keys, and there is frequently no pointing device.</p><p>One of the difficulties of the mobile Web is that URIs are very difficult to type. Lengthy URIs and those that contain a lot of punctuation are particularly difficult to type correctly. </p><p>Because of the limitations of screen and input, forms are hard to fill in. This is because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields.</p><p>While many modern devices provide back buttons, some do not, and in some cases, where back functionality exists, users may not know how to invoke it. This means that it is often very hard to recover from errors, broken links and so on.</p></div><div class="div2">
<h3><a name="d0e264" id="d0e264"/>2.3 Bandwidth and Cost</h3><p>Mobile networks can be slow compared with fixed data connections and often have a measurably higher latency. This can lead to long retrieval times, especially for lengthy content and for content that requires a lot of navigation between pages.</p><p>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.</p><p>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.</p><p>Web pages can contain content that the user has not specifically requested - especially advertising and large images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.</p></div><div class="div2">
<h3><a name="UserGoals" id="UserGoals"/>2.4 User Goals</h3><p>Mobile users typically have different interests to users of fixed or desktop devices. They 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. An example of such a goal-directed application might be the user requiring specific information about schedules for a journey they are currently undertaking.</p><p>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.</p></div><div class="div2">
<h3><a name="d0e282" id="d0e282"/>2.5 Advertising</h3><p>Developers of commercial Web sites should note that different commercial models are often at work when the Web is accessed from mobile devices as compared with desktop devices. For example, some mechanisms that are commonly used for presentation of advertising material (such as pop-ups, pop-unders and large banners) do not work well on small devices and are therefore contrary to Best Practice recommendations such as [CENTRAL_MEANING], [LARGE_GRAPHICS] and [POP_UPS].</p><p>It is not the intention of the MWI to limit or to restrict 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.</p></div><div class="div2">
<h3><a name="d0e289" id="d0e289"/>2.6 Device Limitations</h3><p>As noted above, the restrictions imposed by the keyboard and the screen typically require a different approach to page design than for desktop devices. As detailed in the Scope document <a href="#Scope">[Scope]</a>, various other limitations may apply and these have an impact on the usability of the Web from a mobile device.</p><p>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 choice of browser and upgrading it is not possible.</p><p>Some activities associated with rendering Web pages are computationally intensive - for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid markup <a href="#T-MOB">[T-MOB]</a>. Mobile devices typically have quite limited processing power which means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses more power as does communication with the server.</p><p>Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.</p></div><div class="div2">
<h3><a name="d0e304" id="d0e304"/>2.7 Advantages</h3><p>In discussing the limitations of mobile devices for delivery of Web content it is easy to lose sight of the fact that they are extremely popular and very common.</p><p>This popularity largely stems at present from them being:</p>
<ul><li><p>personal</p></li><li><p>personalizable</p></li><li><p>portable</p></li><li><p>connected</p></li></ul>
<p>and increasingly multi-functional beyond their original purpose of voice communications.</p><p>In addition to these factors, the advantages of mobile devices will increasingly include:</p>
<ul><li><p>location awareness</p></li><li><p>one-handed operation</p></li><li><p>always on</p></li><li><p>universal alerting device</p></li></ul>
<p>By way of illustration of some of these factors: the Web can go where you go. You do not 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.</p><p>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. providing medical info to mountain rescue scenes) and to accompany everyone as easily as they carry the time on their wristwatches.</p><p>Finally, today, many more people have access to mobile devices than access to a desktop computer. This is likely to be very significant in developing countries, where Web-capable mobile devices may play as similar a role in deploying wide-spread Web access as the mobile phone has played for providing "plain old telephone service".</p></div></div><div class="div1">
<h2><a name="d0e347" id="d0e347"/>3 Delivery Context</h2><p>
<em>Delivery Context</em> is used with the <a href="http://www.w3.org/TR/di-gloss/#def-delivery-context-v2">specific meaning</a> defined in the Device Independence Glossary <a href="#DIGLOSS">[DIGLOSS]</a>.</p><div class="div2">
<h3><a name="OneWeb" id="OneWeb"/>3.1 One Web</h3><p>The recommendations in this document are intended to improve the experience of the Web on mobile devices. While the recommendations are not specifically addressed at the desktop browsing experience, it must be understood that they are made in the context of wishing to work towards "One Web". </p><p>As discussed in the Scope document <a href="#Scope">[Scope]</a>, <em>One Web</em> 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 <a href="http://www.w3.org/TR/di-gloss/#def-http-representation">representation</a> across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts (see <a href="#tc">5.1.1 Thematic Consistency of Resource Identified by a URI</a>).</p><p>Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (for instance for complex configuration tasks). Still others have a primarily desktop appeal but a complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications that have a primarily desktop appeal (lengthy reference material, rich images, for example).</p><p>It is likely that application designers and service providers will wish to provide the best possible experience in the context in which their service has the most appeal. However, while services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations.</p><p>From the perspective of this document this means that services should be available as some variant of HTML over HTTP (see <a href="#ddc">3.7 Default Delivery Context</a>).</p></div><div class="div2">
<h3><a name="ca" id="ca"/>3.2 Background to Adaptation</h3><p>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 devices. For example different devices support different markup features and different screen sizes may demand different sized images. Consequently, it is very common when delivering content to mobile devices to vary the details of the markup, format of images, image sizes, color depths and so on to suit the characteristics of the device in question. The process of altering content to enhance the user experience on particular devices is referred to as <em>Content Adaptation</em>.</p><p>We do not describe adaptation in detail in this document. For a more detailed description, readers are referred to the Device Independence Principles <a href="#DIP">[DIP]</a>.</p><p>In addition, the sister group of the Best Practices Working Group, the <a href="http://www.w3.org/2005/MWI/DDWG/">Device Description Working Group</a>, is currently defining requirements for a repository of mobile device characteristics that are relevant to content adaptation.</p></div><div class="div2">
<h3><a name="d0e402" id="d0e402"/>3.3 Adaptation Implementation Model</h3><p>There are a number of different implementation models for content adaptation. On the one hand, adaptation 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. </p><p>Adaptation can be carried out in a number of different points in the delivery of content to the device <a href="#DCODI">[DCODI]</a>:</p><p>
<em>Server Side</em> adaptation implies that the content is delivered by the originating content server or application.</p><p>
<em>In-Network</em> 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 device.</p><p>
<em>Client Side</em> adaptation consists of the device accepting content and displaying it in an appropriate way for its characteristics.</p><p>Whatever the adaptation model at work, the process of adaptation should not diminish accessibility.</p></div><div class="div2">
<h3><a name="d0e428" id="d0e428"/>3.4 Assumptions about Adaptation</h3><p>In phase 1 (See <a href="#phasing">1.4.1 Phasing</a>) it is assumed that content adaptation, if any, is carried out Server Side. Future phases may consider the implications of content adaptation elsewhere, especially the issues concerning the granting of authority to third parties to carry out adaptation, prohibiting adaptation and so on. Later phases may also address multiple adaptation - i.e. the possibility that adaptation can be applied at more than one point and that In-Network adaptation may occur more than once.</p><p>It is also assumed 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.</p></div><div class="div2">
<h3><a name="d0e437" id="d0e437"/>3.5 Establishing Context</h3><p>Providing variations on the user experience that are appropriate in different cases requires the content provider to know a significant amount about the characteristics of the device, the properties of the browser in use and the transparency of the network connection to the device.</p><p>For simple sites that present an interface which is similar across a broad range of contexts the need for such information is diminished when compared with a sophisticated site that has an optimized navigation structure, presents different size images or carries out other adaptations to suit the particular delivery context.</p><p>There are several methods by which a content provider can discover information about the delivery context, such as CC/PP, UAPROF, CSS Media Queries and various outputs of the <a href="http://www.w3.org/2001/di/">Device Independence Working Group</a>. The companion Techniques <a href="#Techniques">[Techniques]</a> document describes these methods.</p></div><div class="div2">
<h3><a name="d0e451" id="d0e451"/>3.6 Choice of User Experience</h3><p>In the interests of "One Web" (see <a href="#OneWeb">3.1 One Web</a>) considerations, the content provider may choose to allow the user to select from broad categories such as mobile or desktop presentation, where these are distinguished in the application. If the presentation option has been determined automatically, the content provider may choose to allow the user to override the automatic determination. Where a choice of presentations is available, it is good practice to record the user's preferences and to allow them to be changed.</p><p>Given an appropriate server environment, it is unlikely that the content provider will be unable to find out anything about the delivery context. However this can happen, either because details of the delivery context are not available in sufficient detail or because the server does not provide the ability to inspect and act on the information provided. In this case a "reasonable default experience" should be provided.</p><p>The details of the default experience depend upon a number of factors including, but not limited to, the geographic region in which the service is offered and the primary intention of the service (e.g. considering whether the service is primarily desktop focused vs. primarily mobile focused).</p></div><div class="div2">
<h3><a name="ddc" id="ddc"/>3.7 Default Delivery Context</h3><p>In order to allow content providers to share a consistent view of a default mobile experience the BPWG has defined the Default Delivery Context. This allows providers to create appropriate experiences in the absence of adaptation and provides a baseline experience where adaptation is used. The Default Delivery Context has been determined by the BPWG as being the minimum delivery context specification necessary for a reasonable experience of the Web. It is recognized that devices that do not meet this specification can provide a reasonable experience of other non-Web services.</p><p>It is also recognized that this specification is made against the background of demographic, cultural and economic assumptions. Content providers may choose to provide services that demand a different or lower delivery context specification, but should try to provide an experience that exploits the capabilities of the Default Delivery Context in order to provide the best possible experience for that context.</p><p>It is stressed that many devices exceed the capabilities defined by the DDC. Content providers are encouraged not to diminish the user experience on those devices by developing only to the DDC specification, and are encouraged to adapt their content, where appropriate, to exploit the capabilities of the actual device.</p><p>In summary, the purpose of defining the DDC is to support the following rules:</p><ul><li><p>If an <a href="http://www.w3.org/TR/di-gloss/#def-adaptation">adaptation process</a> is used, then information that is known about the actual Delivery Context should (see <a href="#lcd">5.1.2 Exploit Device Capabilities</a>) be used to vary the delivered content to make it more suitable for that specific Delivery Context or to provide an enhanced user experience.</p></li><li><p>If the delivered content does not result from an <a href="http://www.w3.org/TR/di-gloss/#def-adaptation">adaptation process</a> - e.g. the content is statically defined as HTML stored in files, or the details of the Delivery Context cannot adequately be determined, then the delivered content should be suitable for the Default Delivery Context and should comply with the Best Practice statements.</p></li></ul><p>The Default Delivery Context is defined as follows:</p><dl><dt class="label">Usable Screen Width</dt><dd><p>120 pixels, minimum.</p></dd><dt class="label">Markup Language Support</dt><dd><p>XHTML Basic 1.1 <a href="#XHTML-Basic">[XHTML-Basic]</a> delivered with content type <code>application/xhtml+xml</code>.</p></dd><dt class="label">Character Encoding</dt><dd><p>UTF-8 <a href="#UTF-8">[UTF-8]</a>.</p></dd><dt class="label">Image Format Support</dt><dd><p>JPEG.</p><p>GIF 89a.</p></dd><dt class="label">Maximum Total Page Weight</dt><dd><p>20 kilobytes.</p></dd><dt class="label">Colors</dt><dd><p>256 Colors, minimum.</p></dd><dt class="label">Style Sheet Support</dt><dd><p>CSS Level 1 <a href="#CSS">[CSS]</a>. In addition, CSS Level 2 <a href="#CSS2">[CSS2]</a> <code>@media</code> rule together with the <code>handheld</code> and <code>all</code> media types (see <a href="http://www.w3.org/TR/REC-CSS2/media.html">CSS 2 Media Types</a>).</p></dd><dt class="label">HTTP</dt><dd><p>HTTP/1.0 <a href="#HTTP1.0">[HTTP1.0]</a> or more recent <a href="#HTTP1.1">[HTTP1.1]</a>.</p></dd><dt class="label">Script</dt><dd><p>No support for client side scripting.</p></dd></dl></div></div><div class="div1">
<h2><a name="bpstructure" id="bpstructure"/>4 Structure of Best Practice Statements</h2><dl><dt class="label">The Heading</dt><dd><p>The functional area that is addressed by the statements.</p></dd><dt class="label">The Statements</dt><dd><p>One or more Best Practice statements, identified in the following way:</p><p id="EXAMPLE" class="stmt1">[EXAMPLE] This is a Best Practice statement. </p></dd><dt class="label">What it means</dt><dd><p>An explanation of the significance of the statements under this heading. </p></dd><dt class="label">How to do it</dt><dd><p>A discussion of techniques and some suggestions as to how to implement. The BPWG is creating a separate document describing techniques <a href="#Techniques">[Techniques]</a> in more detail.</p></dd><dt class="label">What to Test</dt><dd><p>The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. This section is not present for process related statements.</p><p>In this section it is noted whether the statement is <em>Machine Testable</em> (Automated testing is possible) or <em>Human Testable</em> (Testing requires human assessment). Some Best Practices are partially machine testable, i.e. based on the result of an automated test, some human interaction may be required. In such cases both a Machine Testable and a Human Testable statement are present.</p><p>Some Best Practice statements use words such as "minimize" and "avoid" which are intentionally non-prescriptive. This is in order to provide guidance while leaving room to accommodate a wide variety of applications whose requirements cannot be anticipated. It also allows creativity and diversity within the same Best Practice framework. More prescriptive advice can be found in the Techniques document <a href="#Techniques">[Techniques]</a>.</p></dd><dt class="label">References</dt><dd><p>Where appropriate, references to related WCAG points and other immediate references from the preceding text.</p></dd></dl></div><div class="div1">
<h2><a name="d0e630" id="d0e630"/>5 Best Practice Statements</h2><p>The Best Practice statements are grouped under the following headings</p>
<ul><li><p>
<a href="#bpgroupgeneral">5.1 Overall Behavior</a>
</p></li><li><p>
<a href="#bpgroupnavlinks">5.2 Navigation and Links</a>
</p></li><li><p>
<a href="#bpgroupplayout">5.3 Page Layout and Content</a>
</p></li><li><p>
<a href="#bpgrouppdefinition">5.4 Page Definition</a>
</p></li><li><p>
<a href="#bpgroupinput">5.5 User Input</a>
</p></li></ul>
<div class="div2">
<h3><a name="bpgroupgeneral" id="bpgroupgeneral"/>5.1 Overall Behavior</h3><p>There are some general principles that underlie delivery to mobile devices. </p><div class="div3">
<h4><a name="tc" id="tc"/>5.1.1 Thematic Consistency of Resource Identified by a URI</h4><p id="THEMATIC_CONSISTENCY" class="stmt">[THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices. </p><div class="div4">
<h5><a name="d0e672" id="d0e672"/>5.1.1.1 What it means</h5><p> This is a realization of the One Web (see <a href="#OneWeb">3.1 One Web</a>) principle, whereby content should be accessible on a range of devices irrespective of differences in presentation capabilities and access mechanism. Web sites may paginate their content in various ways corresponding to differences in device characteristics; therefore the navigation structure of the site, and possibly its technical realization, may vary according to the device class that is being served. (See also <a href="#WebArch">[WebArch]</a>
<a href="http://www.w3.org/TR/webarch/#URI-persistence">Section 3.5.1</a>).</p><p>A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided. </p><p>URIs may be decorated to provide session or other information. If a URI is decorated with session information that is no longer current, then
the user should be directed to a point in the navigation hierarchy that is
appropriate to their device, in order to establish appropriate session and other
parameters.</p></div></div><div class="div3">
<h4><a name="lcd" id="lcd"/>5.1.2 Exploit <span>Device</span> Capabilities</h4><p id="CAPABILITIES" class="stmt">[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.</p><div class="div4">
<h5><a name="d0e696" id="d0e696"/>5.1.2.1 What it means</h5><p>While encouraging content providers to be sensitive to the needs of the Default Delivery Context, it is not intended that this will result in a diminished experience on more capable devices. <span>Develop sites that target the
Default Delivery Context. In addition, where appropriate, use device
capabilities to provide a better user experience</span> on more capable devices.</p></div></div><div class="div3">
<h4><a name="d0e704" id="d0e704"/>5.1.3 Work around Deficient Implementations</h4><p id="DEFICIENCIES" class="stmt">[DEFICIENCIES] Take reasonable steps to work around deficient implementations.</p><div class="div4">
<h5><a name="d0e709" id="d0e709"/>5.1.3.1 What it means</h5><p>Just as in the desktop 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. By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation. </p><p>Because the software in mobile devices is frequently embedded in the device, there is no easy way to correct or enhance it once it is in the field. 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.
</p><p>Just as it is not the intention to recommend a least common denominator approach, neither is it the intention to recommend avoiding features that exhibit problems on some class of devices.</p><p>It is also not the intention to suggest that content providers should restrict their support to certain device types. Content providers should aim to support as wide a range of device types as is practical.</p></div></div><div class="div3">
<h4><a name="test" id="test"/>5.1.4 Testing</h4><p id="TESTING" class="stmt">[TESTING] Carry out testing on actual devices as well as emulators. </p><div class="div4">
<h5><a name="d0e725" id="d0e725"/>5.1.4.1 What it means</h5><p>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, content providers are encouraged to test that the features they rely on work in actual devices. </p><p>Content providers should also test with specific features disabled, such as using text-only modes and with scripting disabled.</p></div><div class="div4">
<h5><a name="d0e732" id="d0e732"/>5.1.4.2 How to do it</h5><p>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 and specific software versions as is practical.</p></div></div></div><div class="div2">
<h3><a name="bpgroupnavlinks" id="bpgroupnavlinks"/>5.2 Navigation and Links</h3><p>Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile devices, care should be exercised in defining the structure and the navigation model of a Web site.</p><div class="div3">
<h4><a name="d0e742" id="d0e742"/>5.2.1 URIs of Site Entry Points</h4><p id="URIS" class="stmt">[URIS] Keep the URIs of site entry points short. </p><div class="div4">
<h5><a name="d0e747" id="d0e747"/>5.2.1.1 What it means</h5><p>Typing URIs on mobile devices can be difficult, and 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. However, typing a URI may in some cases be the only option available. By keeping site entry point URIs short it is possible to reduce the chance of error and provide a more satisfactory user experience.</p></div><div class="div4">
<h5><a name="d0e752" id="d0e752"/>5.2.1.2 How to do it</h5><p>When accessing site entry points users should not have to enter a filename as part of the URI. If possible, configure Web sites so that they can be
accessed without having to specify a sub-domain as part of the URI.</p><p>Example:
Instead of requiring users to type</p><div class="exampleInner"><pre>"http://www.example.org/index.html"</pre></div><p>allow</p><div class="exampleInner"><pre>"http://example.org"</pre></div><p>and instead of </p><div class="exampleInner"><pre>"http://www.example.org/example.html"</pre></div><p>allow</p><div class="exampleInner"><pre>"http://example.org/example"</pre></div></div></div><div class="div3">
<h4><a name="d0e773" id="d0e773"/>5.2.2 Navigation Bar</h4><p id="NAVBAR" class="stmt">[NAVBAR] Provide only minimal navigation at the top of the page. </p><div class="div4">
<h5><a name="d0e778" id="d0e778"/>5.2.2.1 What it means</h5><p>Provide basic navigation, which
should be placed on the top of the page. Any other secondary navigational
element may be placed at the bottom of the page if really needed. It is
important the users should be able to see page content once the page has
loaded without scrolling (see <a href="#cm">5.3.4 Navigation Bars etc. (Extraneous material)</a>).</p></div><div class="div4">
<h5><a name="d0e785" id="d0e785"/>5.2.2.2 How to do it</h5><p>Provide the basic links on a single line. </p></div></div><div class="div3">
<h4><a name="d0e790" id="d0e790"/>5.2.3 Balanced Structure</h4><p id="BALANCE" class="stmt">[BALANCE] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.</p><div class="div4">
<h5><a name="d0e795" id="d0e795"/>5.2.3.1 What it means</h5><p>The design should aim to provide a balance between having a large number of navigation links on a page and the need to navigate multiple links to reach content.</p><p>Scrolling a page when there are many links on it can be very cumbersome, as the scrolling action on many mobile devices selects each link in turn. On the other hand, each retrieval of a navigation page takes time and adds cost, so the number
of links on a page should not be minimized at the expense of adding page
retrievals. </p><p>Design the service so that frequently accessed information is
easily reached with a minimum number of page retrievals. Navigation to less
frequently accessed information may take more retrievals as a result. A guideline is that users become frustrated if it takes more than four retrievals to reach their objective.
Whether this can be achieved depends on the nature of the site and, in particular, how items in menus group together to provide understandable
themes.</p></div></div><div class="div3">
<h4><a name="d0e804" id="d0e804"/>5.2.4 Navigation Mechanisms</h4><p id="NAVIGATION" class="stmt">[NAVIGATION] Provide consistent navigation mechanisms. </p><div class="div4">
<h5><a name="d0e809" id="d0e809"/>5.2.4.1 What it means</h5><p>Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.</p><p>Users of devices that do not have pointing devices have to scroll between hyperlinks using the keypad. Intelligent grouping, perhaps optimized through adaptation
according to usage patterns, can assist usability.</p></div><div class="div4">
<h5><a name="d0e816" id="d0e816"/>5.2.4.2 How to do it</h5><p>A "drill-down" method, based on major headings, can often provide an effective means of 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.</p><p>At each target of the drill-down navigation an "up" link should be provided to allow the user to jump up an entire section.</p></div><div class="div4">
<h5><a name="d0e823" id="d0e823"/>5.2.4.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-clear-nav-mechanism">13.4</a>.</p></div></div><div class="div3">
<h4><a name="d0e831" id="d0e831"/>5.2.5 Access Keys</h4><p id="ACCESS_KEYS" class="stmt">[ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality. </p><div class="div4">
<h5><a name="d0e836" id="d0e836"/>5.2.5.1 What it means</h5><p>Where there is no pointing device, assigning an access key (keyboard short cut) to a link can provide a convenient way for users to access the link and avoid navigating to the link by repeated pressing of the navigation key.</p><p>Provide the same access key for links that are repeated across pages
such as links to the home page.</p></div><div class="div4">
<h5><a name="d0e843" id="d0e843"/>5.2.5.2 What to test</h5><p>Machine Test: Test for the presence of the <code>accesskey</code> attribute.</p><p>Human Test: Verify the presence of the <code>accesskey</code> attribute on
links such as the home page.</p></div><div class="div4">
<h5><a name="d0e856" id="d0e856"/>5.2.5.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts">9.5</a>.</p></div></div><div class="div3">
<h4><a name="d0e864" id="d0e864"/>5.2.6 Link Target Identification</h4><p id="LINK_TARGET_ID" class="stmt">[LINK_TARGET_ID] Clearly identify the target of each link. </p><p id="LINK_TARGET_FORMAT" class="stmt">[LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it. </p><div class="div4">
<h5><a name="d0e871" id="d0e871"/>5.2.6.1 What it means</h5><p>Users of mobile devices may suffer undue delay and cost as a result of following links. 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 it is unlikely that the cost in monetary terms of a particular user following a particular 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. large file).</p><p>Links to content that is in a different format <span>or different language</span> 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, so that users are not lead to download content that their device may not be able to use. However, bear in mind that some devices support the rendering of those formats by other applications once downloaded (e.g. music files). Additionally, users may wish to download content for later transfer to other devices altogether. So even if it is known that the user agent does not support a particular content type, that content should still be made available.</p></div><div class="div4">
<h5><a name="d0e881" id="d0e881"/>5.2.6.2 How to do it</h5><p>Use clear, concise, descriptive
link text to help users decide whether to follow a link. Identify the
implications of following a link if the target is notably large and the
user might not anticipate this from the context. </p><p>For the <a href="#ddc">Default Delivery Context</a> all formats other than XHTML, GIF and JPG should be noted.</p></div><div class="div4">
<h5><a name="d0e891" id="d0e891"/>5.2.6.3 What to test</h5><p> Human Test: Check for proper descriptions (e.g. no use of "Click here").</p><p>Machine Test: Check for links to non-HTML formats.</p><p>Human Test: If present check whether there is information about the format of the target of the link.</p></div><div class="div4">
<h5><a name="d0e900" id="d0e900"/>5.2.6.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-content-preferences">11.3</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-meaningful-links">13.1</a>.</p></div></div><div class="div3">
<h4><a name="d0e911" id="d0e911"/>5.2.7 Image Maps</h4><p id="IMAGE_MAPS" class="stmt">[IMAGE_MAPS] Do not use image maps unless you know the <span>device</span> supports them effectively.</p><div class="div4">
<h5><a name="d0e919" id="d0e919"/>5.2.7.1 What it means</h5><p>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 and enter are available on most mobile
devices, even if there is no pointing device. This is usually
sufficient to allow navigation of the active regions of client-side image
maps where they are defined as geometric shapes.</p><p>Many mobile devices lack a pointing device and server-side image maps cannot be used on such devices.</p></div><div class="div4">
<h5><a name="d0e926" id="d0e926"/>5.2.7.2 How to do it</h5><p>If only small images can be displayed, break larger images up
into smaller sections and deal with them separately.</p><p>For the <a href="#ddc">Default Delivery Context</a>, or if a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.</p><p/></div><div class="div4">
<h5><a name="d0e937" id="d0e937"/>5.2.7.3 What to test</h5><p>IMAGE_MAPS Machine Test: Send a request to the site with a <span>device</span> that does not support client-side image maps and check the <code>map</code> element is not present.</p></div><div class="div4">
<h5><a name="d0e948" id="d0e948"/>5.2.7.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-redundant-server-links">1.2</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-client-side-maps">9.1</a>.</p></div></div><div class="div3">
<h4><a name="d0e959" id="d0e959"/>5.2.8 Refreshing, Redirection and Spawned Windows</h4><p id="POP_UPS" class="stmt">[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. </p><p id="AUTO_REFRESH" class="stmt">[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have
informed the user and provided a means of stopping it. </p><p id="REDIRECTION" class="stmt">[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes. </p><div class="div4">
<h5><a name="d0e968" id="d0e968"/>5.2.8.1 What it means</h5><p>Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction.</p><p>Some mobile devices use a separate window for input; this section does not refer to such windows.</p><p>Many mobile devices cannot support more than one window and consequently, attempting to open one will have unpredictable results.</p><p>Auto-refreshing pages are widely recognized as presenting accessibility problems. In a mobile environment they may expose the user to undue cost as
a result of such a 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 refresh and always inform the user that the page will refresh and may expose them to higher usage costs.
</p><p>While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser. This adds to delay on slow links; so use a maximum of one redirect per page and limit the number of pages that are redirected.</p></div><div class="div4">
<h5><a name="d0e981" id="d0e981"/>5.2.8.2 What to test</h5><p>POP_UPS Machine Test: Look for the <code>target</code> attribute on links and if present check to see if it has a value different from <code>_self</code>, <code>_parent</code> or <code>_top</code>.</p><p>AUTO_REFRESH Machine Test: Check whether <code>meta http-equiv="refresh" content="<the same URI>"</code> is used.</p><p>AUTO_REFRESH Human Test: If auto-refresh is used, check that options are provided to stop any page using auto-refresh.
</p><p>REDIRECTION Machine Test: Check whether <code>meta http-equiv="refresh" content="<a different URI>"</code> is used.</p></div><div class="div4">
<h5><a name="d0e1010" id="d0e1010"/>5.2.8.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-periodic-refresh">7.4</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-auto-forward">7.5</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-pop-ups">10.1</a>.</p></div></div><div class="div3">
<h4><a name="el" id="el"/>5.2.9 Externally Linked Resources</h4><p id="EXTERNAL_RESOURCES" class="stmt">[EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum.</p><div class="div4">
<h5><a name="d0e1029" id="d0e1029"/>5.2.9.1 What it means</h5><p>Each linked resource (images, style sheets and other objects) requires a separate request across the network. This may add significantly to the load time of the page in the mobile context.</p></div><div class="div4">
<h5><a name="d0e1034" id="d0e1034"/>5.2.9.2 How to do it</h5><p>Minimize the number of images on a page and consolidate style information into a single sheet per page (see also <a href="#style">5.4.9 Style Sheets</a>).</p></div><div class="div4">
<h5><a name="d0e1041" id="d0e1041"/>5.2.9.3 What to test</h5><p>Machine Test: Count the number of linked images, style sheets and other linked items.</p><p>Human Test: Review whether a similar effect could be obtained using fewer links.</p></div></div></div><div class="div2">
<h3><a name="bpgroupplayout" id="bpgroupplayout"/>5.3 Page Layout and Content</h3><p>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 <a href="#bpgrouppdefinition">5.4 Page Definition</a>.
</p><div class="div3">
<h4><a name="cl" id="cl"/>5.3.1 Page Content</h4><p id="SUITABLE" class="stmt">[SUITABLE] Ensure that content is suitable for use in a mobile context. </p><p id="CLARITY" class="stmt">[CLARITY] Use clear and simple language. </p><p id="LIMITED" class="stmt">[LIMITED] Limit content to what the user has requested. </p><div class="div4">
<h5><a name="d0e1064" id="d0e1064"/>5.3.1.1 What it means</h5><p>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. <span>See also discussion under <a href="#UserGoals">2.4 User Goals</a> and <a href="#OneWeb">3.1 One Web</a>.</span></p><p>The general prescription to use clear language is of particular importance for mobile delivery, where brevity and directness are generally more desirable than a discursive style.</p><p>Writing content in the traditional journalistic "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. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area. See also <a href="#cm">5.3.4 Navigation Bars etc. (Extraneous material)</a> for a discussion of making sure that the subject matter of the page is near the top.</p><p>Mobile users often pay for bandwidth, so offering them content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience. In general, the user's consent should be sought before initiating the download of content.</p></div><div class="div4">
<h5><a name="d0e1083" id="d0e1083"/>5.3.1.2 What to test</h5><p>Human Test: Examine content to determine if, given the subject matter, it is appropriate in a mobile context.</p></div><div class="div4">
<h5><a name="d0e1088" id="d0e1088"/>5.3.1.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-front-loading">13.8</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-simple-and-straightforward">14.1</a>.</p></div></div><div class="div3">
<h4><a name="d0e1099" id="d0e1099"/>5.3.2 Page Size</h4><p id="PAGE_SIZE_USABLE" class="stmt">[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions. </p><p id="PAGE_SIZE_LIMIT" class="stmt">[PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.</p><div class="div4">
<h5><a name="d0e1106" id="d0e1106"/>5.3.2.1 What it means</h5><p>If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions on the largest page they can accommodate.</p><p>On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. This can lead to an unnecessary delay, since each request typically takes a measurable time to complete.</p><p>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 and a better page retrieval experience.</p><p>Some studies <a href="#MF">[MF]</a> 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. </p></div><div class="div4">
<h5><a name="d0e1119" id="d0e1119"/>5.3.2.2 How to do it</h5><p>For the <a href="#ddc">Default Delivery Context</a> assume the limits specified in <a href="#ddc">3.7 Default Delivery Context</a>. </p></div><div class="div4">
<h5><a name="d0e1129" id="d0e1129"/>5.3.2.3 What to test</h5><p>PAGE_SIZE_USABLE Machine Test: Measure the total size of the markup for a page; check that it does not exceed 10 kilobytes for the Default Delivery Context.</p><p>Human Test: Check that the page is still usable (e.g. not cut in the middle of a sentence, just before the end of a section, and so on).</p><p>PAGE_SIZE_LIMIT Machine Test: Measure the total size of markup and images for a page; check that it does not go over the allowed size for the device - 20 kilobytes for the Default Delivery Context.</p></div><div class="div4">
<h5><a name="d0e1138" id="d0e1138"/>5.3.2.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-group-information">12.3</a>.</p></div></div><div class="div3">
<h4><a name="d0e1146" id="d0e1146"/>5.3.3 Scrolling</h4><p id="SCROLLING" class="stmt">[SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided. </p><div class="div4">
<h5><a name="d0e1151" id="d0e1151"/>5.3.3.1 What it means</h5><p>The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content. However some content (such as maps and other images) cannot be displayed without secondary scrolling. </p><p>If some element on the page requires 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.</p><p>Equally, if the presence of such an object causes text to render beyond the right boundary of the page then the user will be required to scroll to read each line of text.</p></div><div class="div4">
<h5><a name="d0e1160" id="d0e1160"/>5.3.3.2 How to do it</h5><p>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.</p><p>In the <a href="#ddc">Default Delivery Context</a> assume a width of 120 pixels.</p></div><div class="div4">
<h5><a name="d0e1170" id="d0e1170"/>5.3.3.3 What to test</h5><p>SCROLLING Machine Test: Check for <code>width</code> attributes and width style properties wider than the screen size - for the Default Delivery Context, 120 pixels.</p><p>Human Test: If it is wider than the screen size, check that the use case warrants it (e.g. maps).</p><p>Browse URIs within a site with a mobile device and observe that on pages with elements that require secondary scrolling only those elements require it, and the rest of the page requires only primary scrolling.</p></div></div><div class="div3">
<h4><a name="cm" id="cm"/>5.3.4 Navigation Bars etc. (Extraneous material)</h4><p id="CENTRAL_MEANING" class="stmt">[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not. </p><div class="div4">
<h5><a name="d0e1187" id="d0e1187"/>5.3.4.1 What it means</h5><p>Many Web pages are designed with significant navigational and other elements at the top of or to the side of the page (e.g. Menu Bars, Breadcrumb Trails and 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. </p><p>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 user should not have to scroll significantly to find the primary content of the page.</p><p>See also <a href="#cl">5.3.1 Page Content</a> for a discussion of how writing style can help the user identify meaning.</p></div><div class="div4">
<h5><a name="d0e1198" id="d0e1198"/>5.3.4.2 How to do it</h5><p>Menu selections can be placed away from the top of the page with a simple link to the selection at the top of the page. Alternatively, use meta navigation on top of the page with simple text links to
major sections of the Web site.</p></div><div class="div4">
<h5><a name="d0e1203" id="d0e1203"/>5.3.4.3 What to test</h5><p>Human test: Browse URIs within a site with a mobile <span>device</span> and observe that the most important/relevant information is conveyed first.</p></div><div class="div4">
<h5><a name="d0e1211" id="d0e1211"/>5.3.4.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-nav-bar">13.5</a>.</p></div></div><div class="div3">
<h4><a name="d0e1219" id="d0e1219"/>5.3.5 Graphics</h4><p id="GRAPHICS_FOR_SPACING" class="stmt">[GRAPHICS_FOR_SPACING] Do not use graphics for spacing. </p><p id="LARGE_GRAPHICS" class="stmt">[LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical
information would otherwise be lost.</p><div class="div4">
<h5><a name="d0e1226" id="d0e1226"/>5.3.5.1 What it means</h5><p>The popular mechanism of using a 1 pixel graphic for absolute positioning does not work on a variety of screens.</p><p>Graphics that are larger than necessary, for example by having a
higher resolution than is displayable on the device or by having too many colors, waste bandwidth.</p></div><div class="div4">
<h5><a name="d0e1233" id="d0e1233"/>5.3.5.2 What to test</h5><p>GRAPHICS_FOR_SPACING Machine Test: Check for very small and/or transparent graphics.</p><p>LARGE_GRAPHICS Machine Test: Check dimensions of graphics.</p></div></div><div class="div3">
<h4><a name="d0e1240" id="d0e1240"/>5.3.6 Color</h4><p id="USE_OF_COLOR" class="stmt">[USE_OF_COLOR] Ensure that information conveyed with color is also available without color. </p><p id="COLOR_CONTRAST" class="stmt">[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast. </p><div class="div4">
<h5><a name="d0e1247" id="d0e1247"/>5.3.6.1 What it means</h5><p>Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence information highlighted in color may not be visible to users. If color is used to indicate a feature then that feature should generally also be indicated in a way that is not color dependent. In particular, do not use blue or purple text, as this may be confused with hyperlinks, especially on devices that do not underline links.</p></div><div class="div4">
<h5><a name="d0e1252" id="d0e1252"/>5.3.6.2 What to test</h5><p>USE_OF_COLOR Human Test: Browse the page in a monochrome environment.</p><p>COLOR_CONTRAST Human Test: Browse the page under a strong light parallel to the screen.</p><p>Machine Test: There are automatic tools to test color contrast.</p></div><div class="div4">
<h5><a name="d0e1261" id="d0e1261"/>5.3.6.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-convey">2.1</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-contrast">2.2</a>.</p></div></div><div class="div3">
<h4><a name="d0e1272" id="d0e1272"/>5.3.7 Background Images</h4><p id="BACKGROUND_IMAGE_READABILITY" class="stmt">[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device. </p><div class="div4">
<h5><a name="d0e1277" id="d0e1277"/>5.3.7.1 What it means</h5><p>Images 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 in which mobile devices are frequently used.</p><p>Before using background images, consider carefully your objectives for doing so and try to use alternative techniques to achieve similar objectives. If you use a background image ensure that the content is readable with and without the background image for devices that do not support them.</p></div><div class="div4">
<h5><a name="d0e1284" id="d0e1284"/>5.3.7.2 What to test</h5><p>Machine Test: Test for the presence of a background image.</p><p>Human Test: Test readability both on devices that support them and devices that do not.</p></div></div></div><div class="div2">
<h3><a name="bpgrouppdefinition" id="bpgrouppdefinition"/>5.4 Page Definition</h3><div class="div3">
<h4><a name="d0e1294" id="d0e1294"/>5.4.1 Title</h4><p id="PAGE_TITLE" class="stmt">[PAGE_TITLE] Provide a short but descriptive page title. </p><div class="div4">
<h5><a name="d0e1299" id="d0e1299"/>5.4.1.1 What it means</h5><p>Provide a descriptive title for the page to allow easy identification. Keep the title short to reduce page weight, and bear in mind that it may be truncated.</p><p>Many mobile browsers do not display the title of a page. Where the title is displayed the available space may be limited.</p><p>The <span>device</span> 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.</p></div><div class="div4">
<h5><a name="d0e1311" id="d0e1311"/>5.4.1.2 What to test</h5><p>Machine Test: Test for presence of the <code>title</code> element.</p><p>Human Test: Test that the title is descriptive of content.</p></div></div><div class="div3">
<h4><a name="d0e1321" id="d0e1321"/>5.4.2 Frames</h4><p id="NO_FRAMES" class="stmt">[NO_FRAMES] Do not use frames. </p><div class="div4">
<h5><a name="d0e1326" id="d0e1326"/>5.4.2.1 What it means</h5><p>Many mobile <span>devices</span> do not support frames. In addition, frames are recognized as being generally problematic.</p></div><div class="div4">
<h5><a name="d0e1334" id="d0e1334"/>5.4.2.2 What to test</h5><p> Machine Test: Test for presence of frame related elements - check for <code>frameset</code> and <code>iframe</code> elements.</p></div><div class="div4">
<h5><a name="d0e1345" id="d0e1345"/>5.4.2.3 References</h5><p>See <a href="http://www.w3.org/TR/xframes/#s_intro"> http://www.w3.org/TR/xframes/#s_intro</a> for a discussion of problems with frames.</p></div></div><div class="div3">
<h4><a name="sm" id="sm"/>5.4.3 Structural Elements</h4><p id="STRUCTURE" class="stmt">[STRUCTURE] Use features of the markup language to indicate logical document structure.</p><div class="div4">
<h5><a name="d0e1358" id="d0e1358"/>5.4.3.1 What it means</h5><p>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 to the sections of the document that a user is interested in.</p><p>Where headings are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.</p><p>Structural markup must not be used solely to create a font effect (see also <a href="#sm">5.4.3 Structural Elements</a>).</p></div><div class="div4">
<h5><a name="d0e1369" id="d0e1369"/>5.4.3.2 How to do it</h5><p>Markup languages like HMTL contain many constructs to indicate structure.</p></div></div><div class="div3">
<h4><a name="d0e1374" id="d0e1374"/>5.4.4 Tables</h4><p id="TABLES_SUPPORT" class="stmt">[TABLES_SUPPORT] Do not use tables unless the <span>device</span> is known to support them.</p><p id="TABLES_NESTED" class="stmt">[TABLES_NESTED] Do not use nested tables.</p><p id="TABLES_LAYOUT" class="stmt">[TABLES_LAYOUT] Do not use tables for layout. </p><p id="TABLES_ALTERNATIVES" class="stmt">[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation. </p><div class="div4">
<h5><a name="d0e1388" id="d0e1388"/>5.4.4.1 What it means</h5><p>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.</p></div><div class="div4">
<h5><a name="d0e1393" id="d0e1393"/>5.4.4.2 What to test</h5><p>TABLES_SUPPORT Machine Test: Send a request to the site with a <span>device</span> that does not support tables and check the <code>table</code> element is not present.</p><p>Machine Test: Check that there are no nested tables.</p><p>TABLES_LAYOUT Machine Test: Check that no column or row in a table is empty or contains only a 1x1 transparent GIF.</p><p>Machine Test: If there is a <code>table</code> element, check to see whether there is rendered content outside the element. If there is not then it is likely that the table is being used for layout.</p></div><div class="div4">
<h5><a name="d0e1413" id="d0e1413"/>5.4.4.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-headers">5.1</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-structure">5.2</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-table-for-layout">5.3</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-summaries">5.5</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-abbreviate-labels">5.6</a>.</p></div></div><div class="div3">
<h4><a name="d0e1433" id="d0e1433"/>5.4.5 Non-Text Items</h4><p id="NON-TEXT_ALTERNATIVES" class="stmt">[NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.</p><p id="OBJECTS_OR_SCRIPT" class="stmt">[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.</p><div class="div4">
<h5><a name="d0e1440" id="d0e1440"/>5.4.5.1 What it means</h5><p>A <em>non-text item</em> is defined by <a href="http://www.w3.org/WAI/GL/Glossary/printable.html#def-non-text-content">Non-text content</a> in the WAI Glossary <a href="#WAIGlossary">[WAIGlossary]</a>.</p><p>Downloading images to a mobile<span>device</span> 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.</p><p>Many mobile <span>devices</span> do not support embedded objects or script and in many cases it is not possible for users to load plug-ins to add support. Content must be designed with this in mind. </p><p>Even where a device does support scripting, do not use it unless there is no other way of accomplishing your objectives. Scripting increases power consumption and so decreases battery life.</p></div><div class="div4">
<h5><a name="d0e1465" id="d0e1465"/>5.4.5.2 How to do it</h5><p>Design pages <span>so that they are useful when rendered as text-only. See also <a href="#test">5.1.4 Testing</a></span>.</p><p>Always use features of the markup designed to support alternate rendering such as the <code>longdesc</code> and <code>alt</code> attributes in XHTML.</p><p>Use only features from the markup that are known to be supported by the device in question.</p><p>Avoid things like CSS image replacement and pictures of words.</p><p>If scripting is used, do not use <code>onmouse</code> and <code>onkey</code> triggers, use <code>onclick</code>.</p></div><div class="div4">
<h5><a name="d0e1497" id="d0e1497"/>5.4.5.3 What to test</h5><p>NON-TEXT_ALTERNATIVES Machine Test: Test for presence of <code>alt</code> attribute on images and text content on objects.</p><p>Human Test: Check the relevance of the meaning of the content of <code>alt</code> attributes.</p><p>OBJECTS_OR_SCRIPT Machine Test: Test for the presence of <code>object</code> or <code>script</code> elements in content delivered to a device that does not support them and if present carry out the Human Test below.</p><p>Human Test: If present, test that the user experience is acceptable.</p></div><div class="div4">
<h5><a name="d0e1520" id="d0e1520"/>5.4.5.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-text-equivalent">1.1</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-use-markup">3.1</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-dynamic-source">6.2</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts">6.3</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-fallback-page">6.5</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts">9.2</a>.</p></div></div><div class="div3">
<h4><a name="ImageSize" id="ImageSize"/>5.4.6 Image Size</h4><p id="IMAGES_SPECIFY_SIZE" class="stmt">[IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they have an intrinsic size. </p><p id="IMAGES_RESIZING" class="stmt">[IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size. </p><div class="div4">
<h5><a name="d0e1550" id="d0e1550"/>5.4.6.1 What it means</h5><p>Images such as bitmaps have an intrinsic size. Telling the browser in advance what the size is avoids it having to re-flow the page when it
receives it. Resizing images at the server reduces the amount of data transferred and the amount of processing the <span>device</span> has to carry out to scale the image.</p><p>Note that this recommendation contrasts with <a href="#me">5.4.8 Measures</a>, which recommends using relative measures where possible.</p></div><div class="div4">
<h5><a name="d0e1562" id="d0e1562"/>5.4.6.2 What to test</h5><p>IMAGES_SPECIFY_SIZE Machine Test: Test for presence of <code>width</code> and <code>height</code> attributes on <code>img</code> elements.</p><p>IMAGES_RESIZING Machine Test: Check <code>width</code> and <code>height</code> attributes are equal to image dimensions.</p></div></div><div class="div3">
<h4><a name="d0e1584" id="d0e1584"/>5.4.7 Valid Markup</h4><p id="VALID_MARKUP" class="stmt">[VALID_MARKUP] Create documents that validate to published formal grammars. </p><div class="div4">
<h5><a name="d0e1589" id="d0e1589"/>5.4.7.1 What it means</h5><p>If the page markup is invalid this will result in unpredictable and possibly incomplete presentation. </p></div><div class="div4">
<h5><a name="d0e1594" id="d0e1594"/>5.4.7.2 What to test</h5><p>Machine Test: Validate documents.</p></div><div class="div4">
<h5><a name="d0e1599" id="d0e1599"/>5.4.7.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/#tech-identify-grammar">3.2</a>, <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-latest-w3c-specs">11.1</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-deprecated">11.2</a>.</p><p> See <a href="http://www.w3.org/QA/Tools/#validators">http://www.w3.org/QA/Tools/#validators</a>. </p></div></div><div class="div3">
<h4><a name="me" id="me"/>5.4.8 Measures</h4><p id="MEASURES" class="stmt">[MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values. </p><div class="div4">
<h5><a name="d0e1623" id="d0e1623"/>5.4.8.1 What it means</h5><p>Avoiding pixel and absolute measures allows the browser to adapt content to fit the display. An exception to rule is where an image has been specifically sized for a particular display (see <a href="#ImageSize">5.4.6 Image Size</a>). 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. Devices may realize the intentions of authors more accurately if margins, borders and padding are specified in pixels.</p></div><div class="div4">
<h5><a name="d0e1630" id="d0e1630"/>5.4.8.2 How to do it</h5><p>Use percentage and relative measures such as <code>em</code>, <code>ex</code>, <code>bolder</code>, <code>larger</code> and <code>thick</code>.</p></div><div class="div4">
<h5><a name="d0e1650" id="d0e1650"/>5.4.8.3 What to test</h5><p>Machine Test: Send a request to the site with a <span>device</span> that supports relative measures correctly and check the values of <code>font-size</code> are not absolute or pixels.</p></div></div><div class="div3">
<h4><a name="style" id="style"/>5.4.9 Style Sheets</h4><p id="STYLE_SHEETS_USE" class="stmt">[STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.</p><p id="STYLE_SHEETS_SUPPORT" class="stmt">[STYLE_SHEETS_SUPPORT] Organize documents so that <span>if necessary</span> they may be read without style sheets.</p><p id="STYLE_SHEETS_SIZE" class="stmt">[STYLE_SHEETS_SIZE] Keep style sheets small.</p><div class="div4">
<h5><a name="d0e1673" id="d0e1673"/>5.4.9.1 What it means</h5><p>Style information may be contained in an externally linked style sheet or, in HTML, may be contained either in a style element or in a style attribute on specific elements.</p><p>Mobile devices offer varying support for style sheets. Some provide full implementations, including caching of external style sheets; some do not cache external style sheets; some do not support the <code>style</code> element; some implementations do not support more than one style sheet and some do not support style sheets at all.</p><p>If style sheets are turned off or not supported, content will be rendered in document order, so it is important that the content makes sense when read in document order.</p></div><div class="div4">
<h5><a name="d0e1685" id="d0e1685"/>5.4.9.2 How to do it</h5><p>It is preferable to share style information between pages, but if the device does not support caching of style sheets then this approach would result in
the same style sheet being retrieved for each page. Consequently, in order of preference: if the device caches style sheets, put style information in a single external style sheet (see also <a href="#el">5.2.9 Externally Linked Resources</a>); if the device supports the <code>style</code> element, use it; otherwise use an external style sheet.</p><p>Optimize style information so that only styles that are used are included.</p><p>When creating style sheets, take advantage of the CSS media types (these may be used both in the CSS <code>@media</code> rule and in the <code>media</code> attribute of the <code>link</code> element) to specify styles that apply to handheld rendering. The CSS Media types that apply are "handheld" and "all". If handheld rendering is not specified, browsers may download other style sheets even if they are identified as applicable to non-handheld rendering</p></div><div class="div4">
<h5><a name="d0e1708" id="d0e1708"/>5.4.9.3 What to test</h5><p>STYLE_SHEETS_USE Machine Test: Send a request to the site with a <span>device</span> that supports CSS and check that style sheets are used and that the page does not use formatting tags (e.g. <code>font</code>).</p><p>STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and check that the page is still readable. </p><p>STYLE_SHEETS_SIZE Machine Test: Check that the elements in a style sheet are used in at least one of the pages that reference it.</p></div><div class="div4">
<h5><a name="d0e1723" id="d0e1723"/>5.4.9.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-style-sheets">3.3</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-order-style-sheets">6.1</a></p></div></div><div class="div3">
<h4><a name="d0e1733" id="d0e1733"/>5.4.10 Minimize</h4><p id="MINIMIZE" class="stmt">[MINIMIZE] Use terse, efficient markup. </p><div class="div4">
<h5><a name="d0e1738" id="d0e1738"/>5.4.10.1 What it means</h5><p>Content which is marked up in languages such as XML can often be made smaller while preserving exactly the same semantics merely by removal of redundant white space (i.e. spaces and new lines).</p><p>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 <code>class</code> attribute for application of style (see also <a href="#style">5.4.9 Style Sheets</a>).</p></div><div class="div4">
<h5><a name="d0e1750" id="d0e1750"/>5.4.10.2 How to do it</h5><p>While it is not intended that authors should create their content in a single
line to remove white space altogether, it is suggested that authors should not
contribute to page weight by introducing unnecessary white space. Note that "pretty printing" (the formatting of markup with indentation) can generate large
amounts of white space and hence add to page weight.</p><p>If "pretty printing" is an important part of the authoring process, then try to arrange that redundant white space is stripped when serving a page.</p><p>Even though some network proxies strip white space that they think is redundant, not all do so, so it is not best practice to rely upon this
behavior.</p><p>Use of structural markup (see <a href="#sm">5.4.3 Structural Elements</a>) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS <a href="#CSS">[CSS]</a>.</p></div><div class="div4">
<h5><a name="d0e1765" id="d0e1765"/>5.4.10.3 What to test</h5><p>Machine Test: Count the number of non-significant white space characters in the document.</p></div></div><div class="div3">
<h4><a name="d0e1770" id="d0e1770"/>5.4.11 Content Types</h4><p id="CONTENT_FORMAT_SUPPORT" class="stmt">[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device. </p><p id="CONTENT_FORMAT_PREFERRED" class="stmt">[CONTENT_FORMAT_PREFERRED] Where possible, send content in a preferred format. </p><div class="div4">
<h5><a name="d0e1777" id="d0e1777"/>5.4.11.1 What it means</h5><p>Transferring content that a device cannot display wastes users' time and money. A device may express a preference for formats. In this case it is good practice to respect the <span>device's</span> preference, as it may have a fuller implementation of those formats.</p></div><div class="div4">
<h5><a name="d0e1785" id="d0e1785"/>5.4.11.2 How to do it</h5><p>To determine what formats a device
supports, Web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers and UAProf.</p><p>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:</p><ul><li><p>Some devices do not supply accept headers;</p></li><li><p>Some devices mis-state their capabilities;</p></li><li><p>Some operator gateways supplement the accept headers to include formats that they adapt;</p></li><li><p>User agent headers do not always uniquely identify the device;</p></li><li><p>UAProf information may not be available or may be incomplete.</p></li></ul></div><div class="div4">
<h5><a name="d0e1808" id="d0e1808"/>5.4.11.3 What to test</h5><p>CONTENT_FORMAT_SUPPORT Machine Test: Check MIME types of content with various <span>devices</span>.</p><p>CONTENT_FORMAT_PREFERRED Machine Test: Check MIME types of content with various <span>devices</span> and check that the preferred format is sent or that the format is compatible with the Default Delivery Context.</p></div></div><div class="div3">
<h4><a name="d0e1821" id="d0e1821"/>5.4.12 Character Encoding</h4><p id="CHARACTER_ENCODING_SUPPORT" class="stmt">[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be
supported by the device. </p><p id="CHARACTER_ENCODING_USE" class="stmt">[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used. </p><div class="div4">
<h5><a name="d0e1828" id="d0e1828"/>5.4.12.1 What it means</h5><p>As in the previous section, content should not be sent to a device if it can not use it.</p></div><div class="div4">
<h5><a name="d0e1833" id="d0e1833"/>5.4.12.2 How to do it
</h5><p>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. </p><p>The character encoding being used in a response may be indicated using
the HTTP Content-Type header.</p><div class="exampleInner"><pre>Example:
Content-Type: text/html; charset=utf-8</pre></div><p>
Additionally for XML <a href="#XML">[XML]</a> documents the character encoding may be indicated in
the encoding declaration, although this will generally be ignored if
an HTTP Content-Type header is present.</p><div class="exampleInner"><pre>Example:
<?xml version="1.0" encoding="UTF-8"?></pre></div><p>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 <a href="#CHARSET1">[CHARSET1]</a> and <a href="#CHARSET2">[CHARSET2]</a>.</p><p><span>Unicode is a good choice for representing content when served in multiple languages.</span> 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.</p><p>Since the Default Delivery Context specifies use only of UTF-8, all
applications should support UTF-8.</p></div><div class="div4">
<h5><a name="d0e1860" id="d0e1860"/>5.4.12.3 What to test</h5><p>Machine Test: Check that the encoding is declared in some way and is supported. The content type may be declared in one or more of the following ways: The Content-Type HTTP header, the XML declaration for XML-based content, the CSS @charset rules for CSS, the Content-Type Meta element for HTML content.</p></div><div class="div4">
<h5><a name="d0e1865" id="d0e1865"/>5.4.12.4 References</h5><p>See <a href="#XML">[XML]</a>
<a href="http://www.w3.org/TR/2004/REC-xml-20040204/#charencoding">Character Encoding in Entities</a> for a discussion of character encoding in XML documents.</p></div></div><div class="div3">
<h4><a name="d0e1875" id="d0e1875"/>5.4.13 Error Messages</h4><p id="ERROR_MESSAGES" class="stmt">[ERROR_MESSAGES]
Provide informative error messages and a means of navigating away from an error message back to useful information. </p><div class="div4">
<h5><a name="d0e1880" id="d0e1880"/>5.4.13.1 What it means</h5><p>
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 means of error
recovery is particularly difficult.</p><p>
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 able to escalate the problem.
</p><p>
It should also be possible for the user to escape from the error condition. They should either be able to return to the page they were on prior 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.
</p></div><div class="div4">
<h5><a name="d0e1889" id="d0e1889"/>5.4.13.2 How to do it</h5><p>
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 <a href="#TOMCAT">[TOMCAT]</a>, <a href="#APACHE">[APACHE]</a> and <a href="#IIS">[IIS]</a>), applications should trap all
error conditions by overriding the default pages if necessary, and handle
them in a user-friendly, and graceful, way.
</p><p>
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.
</p><p>
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.
</p><p>
The error message should provide one or more of the following navigational constructs:</p><ol class="enumar"><li><p>A "back" link to return to the previous page (particularly for devices
that do not have an easy to find back button);
</p></li><li><p>A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");</p></li><li><p>A "home" link to allow the user to return to the main part of the application.
</p></li></ol><p>
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.
</p></div><div class="div4">
<h5><a name="d0e1918" id="d0e1918"/>5.4.13.3 What to test</h5><p>Enter an extraneous URI, known not to represent an actual resource on the site, and check that a HTTP 404 error response is accompanied by a page whose markup is appropriate for the requesting device, or the default context.</p><p> 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.</p></div></div><div class="div3">
<h4><a name="d0e1925" id="d0e1925"/>5.4.14 Cookies</h4><p id="COOKIES" class="stmt">[COOKIES] Do not rely on cookies being available.</p><div class="div4">
<h5><a name="d0e1930" id="d0e1930"/>5.4.14.1 What it means</h5><p>Cookies are frequently used to carry out session management, to identify users and to store user preferences. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies and others simulate cookies on behalf of mobile devices. </p></div><div class="div4">
<h5><a name="d0e1935" id="d0e1935"/>5.4.14.2 How to do it</h5><p>Test that cookies are supported by the device on its current access path. If they are not supported, use URI decoration for session management, being careful not to exceed the device's maximum length for such strings. Some gateways provide user identification without setting cookies. </p></div><div class="div4">
<h5><a name="d0e1940" id="d0e1940"/>5.4.14.3 What to test</h5><p>Machine Test: Check that an alternative to cookies is used for session management when they are not available.</p></div></div><div class="div3">
<h4><a name="d0e1945" id="d0e1945"/>5.4.15 Cache Headers</h4><p id="CACHING" class="stmt">[CACHING] Provide caching information in HTTP responses.</p><div class="div4">
<h5><a name="d0e1950" id="d0e1950"/>5.4.15.1 What it means</h5><p>Limited bandwidth and high latency can reduce the usability of Web sites on mobile devices. Using caching information effectively can reduce the need to
reload data such as style sheets, images and pages, thus improving performance and reducing cost of use. It can also prevent the reuse of content where this is not appropriate, for example content that is adapted for one device should not be re-used by different devices. <span>Devices</span> and network caches are both affected by caching information.</p></div><div class="div4">
<h5><a name="d0e1958" id="d0e1958"/>5.4.15.2 How to do it</h5><p>Set expiry times in a way that is appropriate to your application. Consider using <code>Cache-Control: public</code> to allow sharing of pages between devices, <code>Cache-Control: private</code> to allow re-use but only by the requesting <span>device</span> and <code>Cache-Control: nocache </code>to prevent caching.</p><p>The HTTP 1.1 specification
<a href="#HTTP1.1">[HTTP1.1]</a> and Techniques document <a href="#Techniques">[Techniques]</a> contain discussions of caching.</p></div><div class="div4">
<h5><a name="d0e1981" id="d0e1981"/>5.4.15.3 What to test</h5><p>Machine Test: Check for the presence of cache headers on the HTTP response.</p></div><div class="div4">
<h5><a name="d0e1986" id="d0e1986"/>5.4.15.4 References</h5><p>
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">Section 13 Caching in HTTP</a> of <a href="#HTTP1.1">[HTTP1.1]</a> discusses caching.</p></div></div><div class="div3">
<h4><a name="fonts" id="fonts"/>5.4.16 Fonts</h4><p id="FONTS" class="stmt">[FONTS] Do not rely on support of font related styling.</p><div class="div4">
<h5><a name="d0e2001" id="d0e2001"/>5.4.16.1 What it means</h5><p>Mobile devices often have few fonts and limited support for font sizes and effects (bold, italic etc.) As a result of this, the use of font size, face or effect, for example to highlight an answer or a stressed word, may not achieve the desired effect. See also <a href="#sm">5.4.3 Structural Elements</a>.</p></div><div class="div4">
<h5><a name="d0e2008" id="d0e2008"/>5.4.16.2 How to do it</h5><p>For the <a href="#ddc">Default Delivery Context</a> do not use font related styling.</p></div><div class="div4">
<h5><a name="d0e2016" id="d0e2016"/>5.4.16.3 What to test</h5><p>Machine Test: Check for the presence of font related styling in an environment that does not support it.</p><p>Human Test: If present, ensure that the author's intentions remain clear.</p></div></div></div><div class="div2">
<h3><a name="bpgroupinput" id="bpgroupinput"/>5.5 User Input</h3><p>This section contains statements relating to user input. This is typically more restrictive on mobile devices than on desktop computers (and often a lot more restrictive). For example, mobile devices may lack pointing devices and often do not have a standard keyboard for text entry.</p><div class="div3">
<h4><a name="d0e2028" id="d0e2028"/>5.5.1 Input</h4><p id="MINIMIZE_KEYSTROKES" class="stmt">[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum. </p><p id="AVOID_FREE_TEXT" class="stmt">[AVOID_FREE_TEXT] Avoid free text entry where possible. </p><p id="PROVIDE_DEFAULTS" class="stmt">[PROVIDE_DEFAULTS] Provide pre-selected default values where possible. </p><p id="DEFAULT_INPUT_MODE" class="stmt">[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it. </p><div class="div4">
<h5><a name="d0e2039" id="d0e2039"/>5.5.1.1 What it means</h5><p>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 buttons and other controls that do not require typing.</p><p>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 <a href="#XHTML-Basic">[XHTML-Basic]</a> will support this functionality in the future.</p></div><div class="div4">
<h5><a name="d0e2048" id="d0e2048"/>5.5.1.2 How to do it</h5><p>There are a number of techniques available for this, including:</p>
<ul><li><p>Where possible use previous entries as defaults.</p></li><li><p>Make it possible to select items using navigation keys and/or numeric input.</p></li></ul></div>
<div class="div4">
<h5><a name="d0e2061" id="d0e2061"/>5.5.1.3 What to test</h5><p>AVOID_FREE_TEXT Machine Test: Check whether <code>input type="text"</code> and <code>textarea</code> are used.</p><p> Human Test: If one of them is used, check whether it can be replaced by a pre-determined entry.</p><p>PROVIDE_DEFAULTS Machine Test: Check if there is a pre-selected value in controls (selected or checked attribute set). </p><p> Human Test: If not, check if there could be sensible pre-selection in the context (e.g. most common choice).</p><p>DEFAULT_INPUT_MODE Machine Test: Send a request with a <span>device</span> known to support the <code>inputmode</code> attribute and if the response is in a language that supports this attribute, check that it is present on <code>input type="text"</code> and <code>textarea</code> elements.</p></div><div class="div4">
<h5><a name="d0e2092" id="d0e2092"/>5.5.1.4 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-place-holders">10.4</a>.</p></div></div><div class="div3">
<h4><a name="d0e2100" id="d0e2100"/>5.5.2 Tab Order</h4><p id="TAB_ORDER" class="stmt">[TAB_ORDER] Create a logical order through links, form controls and objects. </p><div class="div4">
<h5><a name="d0e2105" id="d0e2105"/>5.5.2.1 What it means</h5><p>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.</p></div><div class="div4">
<h5><a name="d0e2110" id="d0e2110"/>5.5.2.2 How to do it</h5><p>Use document order to control layout and tab order.</p></div><div class="div4">
<h5><a name="d0e2115" id="d0e2115"/>5.5.2.3 What to test</h5><p>Machine Test: Check that there are no <code>tabindex</code> attributes or layout effects that affect the order of presentation. </p><p>If there are <code>tabindex</code> attributes check that all controls have a tab index and that they are used consistently.</p><p>Human Test: If there are either <code>tabindex</code> attributes or layout effects that might affect the order of presentation, then check that the order is usable.</p></div></div><div class="div3">
<h4><a name="d0e2133" id="d0e2133"/>5.5.3 Labels <span>for Form Controls</span></h4><p id="CONTROL_LABELLING" class="stmt">[CONTROL_LABELLING] Label all <span>form</span> controls appropriately and explicitly associate labels with <span>form</span> controls.</p><p id="CONTROL_POSITION" class="stmt">[CONTROL_POSITION] Position labels so they lay out properly in relation to the <span>form</span> controls they refer to.</p><div class="div4">
<h5><a name="d0e2151" id="d0e2151"/>5.5.3.1 What it means</h5><p>This means use the <code>label</code> element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the <span>form</span> control so re-flowing or adapting the content intelligently will always recognize label controls and keep them together.</p></div><div class="div4">
<h5><a name="d0e2162" id="d0e2162"/>5.5.3.2 What to test</h5><p> Machine Test: Check if the <code>label</code> element is used in forms.</p><p> Human Test: Check whether the labels are properly positioned with regard to the controls.</p></div><div class="div4">
<h5><a name="d0e2172" id="d0e2172"/>5.5.3.3 References</h5><p>This relates to WCAG <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-unassociated-labels">10.2</a> and <a href="http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-associate-labels">12.4</a>. </p></div></div></div></div><div class="div1">
<h2><a name="d0e2183" id="d0e2183"/>6 Conformance and mobileOK </h2><p>The 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 trustmark, which will be based on some profile, or subset, of the Statements in this document.</p><p>As such, the mobileOK trustmark will serve as the main conformance
claim for the Best Practices document.</p><p>All of the Best Practice statements have a fragment identifier to allow formal reference to them and allow the construction of compliance claims that refer to them.</p><div class="div2">
<h3><a name="d0e2192" id="d0e2192"/>6.1 Classes of Products</h3><p>This specification applies to one class of product: content delivered to a <span>mobile device</span>, including the metadata transferred as part
of the delivery protocol.</p></div><div class="div2">
<h3><a name="d0e2200" id="d0e2200"/>6.2 Extensibility</h3><p>This specification may be compatible with other specifications that describe a different set of requirements for content, insofar as such requirements do not conflict with the current specification.</p></div></div></div><div class="back"><div class="div1">
<h2><a name="d0e2206" id="d0e2206"/>A Sources (Non-Normative)</h2><p>The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:</p><ul><li><p>Various BPWG group meetings and discussions</p></li><li><p>WCAG Guidelines 1.0 <a href="#WCAG">[WCAG]</a>
</p></li><li><p>iMode Guidelines <a href="#iMode">[iMode]</a>
</p></li><li><p>Opera's "Making Small Devices Look Great" <a href="#Opera">[Opera]</a>
</p></li><li><p>Openwave Guidelines <a href="#OpenWave">[OpenWave]</a>
</p></li><li><p>Nokia's Series 60 XHTML-MP Guidelines <a href="#Nokia-MP">[Nokia-MP]</a>
</p></li><li><p>Browsing on Mobile Phones, Nokia <a href="#Nokia-VR">[Nokia-VR]</a>
</p></li><li><p>Little Spring Design <a href="#LSD">[LSD]</a>
</p></li></ul><p>While the Best Practice
statements have mainly 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.</p></div><div class="div1">
<h2><a name="related" id="related"/>B Related Reading (Non-Normative)</h2><p>Readers
interested in the topic of this document will find a variety of other
publications of interest. As noted in the Scope paragraph
above, topics such as internationalization and accessibility have been
addressed separately by the W3C and have not been covered here.</p><p>The
<a href="http://www.w3.org/TR/2005/REC-charmod-20050215/">Character
Model for the World Wide Web</a> and other materials prepared by
the <a href="http://www.w3.org/International/">W3C
Internationalization (i18n) Activity</a> cover important
interoperability drivers for content prepared for the One Web and the
mobile-services arena.</p><p>The <a href="http://www.w3.org/WAI/">Web Accessibility Initiative</a>
has prepared a variety of <a href="http://www.w3.org/WAI/guid-tech.html">Guidelines and
Techniques</a> that likewise bear on the preparation and processing
of content in and for the Web.</p><p>Section <a href="#ca">3.2 Background to Adaptation</a> above
introduced the idea of content adaptation. Readers who contemplate implementing server-side
adaptation will be interested in the ongoing work of the <a href="http://www.w3.org/2001/di/">Device
Independence Activity</a>.</p></div><div class="div1">
<h2><a name="d0e2280" id="d0e2280"/>C Acknowledgements (Non-Normative)</h2><p>The editors would like to thank members of the BPWG for contributions of various kinds. The editors would also like to thank contributors to the public list, and contributors of Last Call comments whose comments have been taken into account in
the creation of this document. </p><p> The editors acknowledge significant written contributions from:</p><ul><li>Greg Aaron, Afilias Limited</li><li>Daniel Appelquist, Vodafone (<i>Mobile Web Best Practices Working Group Chair</i>) </li><li>Phil Archer, ICRA</li><li>Rotan Hanrahan, MobileAware</li><li>Dominique Hazaël-Massieux, W3C/ERCIM (<i>W3C Team Contact</i>) </li><li>Philipp Hoschka, W3C/ERCIM (<i>W3C Team Contact</i>) </li><li>Richard T. Kennedy, The Boeing Company</li><li>Rhys Lewis, Volantis Systems Ltd</li><li>Luca Passani, Openwave Systems Inc.</li><li>Giles Payne, NTT DoCoMo</li><li>James Pearce, Argo Interactive Ltd</li><li>Kai-Dietrich Scheppe, Deutsche Telekom AG, T-Com, Geschäftsbereich T-Online</li><li>Andrea Trasatti, W3C Invited Expert</li><li>Paul Walsh, Segala M Test</li></ul></div><div class="div1">
<h2><a name="d0e2364" id="d0e2364"/>D References (Non-Normative)</h2><div class="div2">
<h3><a name="d0e2367" id="d0e2367"/>D.1 MWI References</h3><dl><dt class="label"><a name="Scope" id="Scope"/>Scope</dt><dd>Scope of Mobile Web Best Practices, Phil Archer, Ed Mitukiewicz, Editors, W3C Working Group Note, 20 December 2005 (See <a href="http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/">http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/</a>)</dd><dt class="label"><a name="Techniques" id="Techniques"/>Techniques</dt><dd>Mobile Web Techniques for Best Practices [in development] (See <a href="http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro">http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro</a>)</dd><dt class="label"><a name="mobileOK" id="mobileOK"/>mobileOK</dt><dd>mobileOK Basic Tests 1.0, Sean Owen, Jo Rabin (eds), W3C Working Draft, 10 June 2008 (See <a href="http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/">http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/</a>)</dd></dl></div><div class="div2">
<h3><a name="d0e2377" id="d0e2377"/>D.2 Sources</h3><dl><dt class="label"><a name="WCAG" id="WCAG"/>WCAG</dt><dd>Web Content Accessibility Guidelines
1.0, W Chisholm, I. Jacobs, G Vanderheiden, Editors, W3C
Recommendation, 5 May 1999. (See <a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/</a>)</dd><dt class="label"><a name="WAIGlossary" id="WAIGlossary"/>WAIGlossary</dt><dd>WAI (Printable) Glossary, Katie Haritos-Shea, Charles McCathieNevile, Internal Working Draft, 1 March 2003 (See <a href="http://www.w3.org/WAI/GL/Glossary/">http://www.w3.org/WAI/GL/Glossary/</a>)</dd><dt class="label"><a name="iMode" id="iMode"/>iMode</dt><dd>iMode (See <a href="http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf">http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf</a>)</dd><dt class="label"><a name="Opera" id="Opera"/>Opera</dt><dd>Opera's Making Small Devices Look Great (See <a href="http://my.opera.com/community/dev/device/">http://my.opera.com/community/dev/device/</a>)</dd><dt class="label"><a name="OpenWave" id="OpenWave"/>OpenWave</dt><dd>Openwave (See <a href="http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm">http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm</a>)</dd><dt class="label"><a name="Nokia-MP" id="Nokia-MP"/>Nokia-MP</dt><dd>Nokia Guidelines for XHTML-MP on Series 60 (See <a href="http://sw.nokia.com/id/4f7b6805-47d7-4914-885c-6ef2b487adf6/Series_60_Platform_Designing_XHTML_MP_Content_v1_4_en.pdf">http://sw.nokia.com/id/4f7b6805-47d7-4914-885c-6ef2b487adf6/Series_60_Platform_Designing_XHTML_MP_Content_v1_4_en.pdf</a>)</dd><dt class="label"><a name="Nokia-VR" id="Nokia-VR"/>Nokia-VR</dt><dd>Browsing on Mobile Phones, paper by Virpi Roto, Nokia (See <a href="http://www.research.att.com/~rjana/WF12_Paper1.pdf">http://www.research.att.com/~rjana/WF12_Paper1.pdf</a>)</dd><dt class="label"><a name="LSD" id="LSD"/>LSD</dt><dd>Little Spring Design (See <a href="http://patterns.littlespringsdesign.com">http://patterns.littlespringsdesign.com</a>)</dd></dl></div><div class="div2">
<h3><a name="d0e2397" id="d0e2397"/>D.3 Device Independence</h3><dl><dt class="label"><a name="DIP" id="DIP"/>DIP</dt><dd>Device Independence Principles, R. Gimson, Editor, W3C Working Group Note, 1 September 2003 (See <a href="http://www.w3.org/TR/2003/NOTE-di-princ-20030901/">http://www.w3.org/TR/2003/NOTE-di-princ-20030901/</a>)</dd><dt class="label"><a name="DCODI" id="DCODI"/>DCODI</dt><dd>Delivery Context Overview for Device Independence,
, R. Gimson, R. Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See <a href="http://www.w3.org/TR/2006/NOTE-di-dco-20060320/">http://www.w3.org/TR/2006/NOTE-di-dco-20060320/</a>)</dd><dt class="label"><a name="DIGLOSS" id="DIGLOSS"/>DIGLOSS</dt><dd>Glossary of Terms for Device Independence, R. Lewis, Editor, W3C Working Draft (work in progress), 18 January 2005 (See <a href="http://www.w3.org/TR/2005/WD-di-gloss-20050118/">http://www.w3.org/TR/2005/WD-di-gloss-20050118/</a>)</dd></dl></div><div class="div2">
<h3><a name="d0e2407" id="d0e2407"/>D.4 Web, Protocols and Languages</h3><dl><dt class="label"><a name="WebArch" id="WebArch"/>WebArch</dt><dd>Architecture of the World Wide Web, Volume One, N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004 (See <a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">http://www.w3.org/TR/2004/REC-webarch-20041215/</a>)</dd><dt class="label"><a name="XML" id="XML"/>XML</dt><dd>Extensible Markup Language (XML) 1.0 (Fourth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C Recommendation 16 August 2006, edited in place 29 September 2006 (See <a href="http://www.w3.org/TR/2006/REC-xml-20060816 ">http://www.w3.org/TR/2006/REC-xml-20060816 </a>)</dd><dt class="label"><a name="XHTML-Basic" id="XHTML-Basic"/>XHTML-Basic</dt><dd>XHTML™ Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Recommendation, 29 July 2008 (See <a href="http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/">http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/</a>)</dd><dt class="label"><a name="CSS" id="CSS"/>CSS</dt><dd>Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 (See <a href="http://www.w3.org/TR/1999/REC-CSS1-19990111">http://www.w3.org/TR/1999/REC-CSS1-19990111</a>)</dd><dt class="label"><a name="CSS2" id="CSS2"/>CSS2</dt><dd>Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998 (See <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">http://www.w3.org/TR/1998/REC-CSS2-19980512/</a>)</dd><dt class="label"><a name="HTTP1.0" id="HTTP1.0"/>HTTP1.0</dt><dd>Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See <a href="http://www.w3.org/Protocols/rfc1945/rfc1945">http://www.w3.org/Protocols/rfc1945/rfc1945</a>)</dd><dt class="label"><a name="HTTP1.1" id="HTTP1.1"/>HTTP1.1</dt><dd> Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">http://www.w3.org/Protocols/rfc2616/rfc2616.html</a>)</dd><dt class="label"><a name="UTF-8" id="UTF-8"/>UTF-8</dt><dd> UTF-8, a transformation format of ISO 10646 Request for Comments: 3629, F. Yergeau, November 2003 (See <a href="http://www.ietf.org/rfc/rfc3629.txt">http://www.ietf.org/rfc/rfc3629.txt</a>)</dd><dt class="label"><a name="CHARSET1" id="CHARSET1"/>CHARSET1</dt><dd>Tutorial: Character sets & encodings in XHTML, HTML and CSS (See <a href="http://www.w3.org/International/tutorials/tutorial-char-enc/">http://www.w3.org/International/tutorials/tutorial-char-enc/</a>)</dd><dt class="label"><a name="CHARSET2" id="CHARSET2"/>CHARSET2</dt><dd>FAQ: Setting encoding in Web authoring applications (See <a href="http://www.w3.org/International/questions/qa-setting-encoding-in-applications">http://www.w3.org/International/questions/qa-setting-encoding-in-applications</a>)</dd></dl></div><div class="div2">
<h3><a name="d0e2432" id="d0e2432"/>D.5 Other References</h3><dl><dt class="label"><a name="UAPROF" id="UAPROF"/>UAPROF</dt><dd>Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0 – 06 Feb 2006 (See <a href="http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf">http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf</a>)</dd><dt class="label"><a name="TOMCAT" id="TOMCAT"/>TOMCAT</dt><dd>Tomcat FAQ How do I get a customized error page? (See <a href="http://tomcat.apache.org/faq/misc.html#q6">http://tomcat.apache.org/faq/misc.html#q6</a>)</dd><dt class="label"><a name="APACHE" id="APACHE"/>APACHE</dt><dd>Apache Core Features ErrorDocument directive (See <a href="http://httpd.apache.org/docs/1.3/mod/core.html#errordocument">http://httpd.apache.org/docs/1.3/mod/core.html#errordocument</a>)</dd><dt class="label"><a name="IIS" id="IIS"/>IIS</dt><dd>IIS Custom HTTP Error Messages (See <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/ee7a8c53-f9bc-4cd4-b954-e32066105cf1.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/ee7a8c53-f9bc-4cd4-b954-e32066105cf1.asp</a>)</dd><dt class="label"><a name="T-MOB" id="T-MOB"/>T-MOB</dt><dd>T-Mobile International - Position Statement for W3C Mobile Web Initiative Version: 1.0 18 Dec 2004 (See <a href="http://www.w3.org/2004/10/MWIWS-papers/W3C_Mobile_Web_Initiative_-_T-Mobile_Position_Statement-final.pdf">http://www.w3.org/2004/10/MWIWS-papers/W3C_Mobile_Web_Initiative_-_T-Mobile_Position_Statement-final.pdf</a>)</dd><dt class="label"><a name="MF" id="MF"/>MF</dt><dd>Study by Segala M Test on Scrolling vs. Pagination (See <a href="http://www.mobilefriendly.org">http://www.mobilefriendly.org</a>)</dd></dl></div></div></div></body></html>