TransWiki - W3CHINA.ORG开放翻译计划（OTP）

目录

1 Mobile Web Best Practices 1.0 移动Web最佳实践1.0 1.1 Basic Guidelines 基础指南 1.2 W3C Recommendation 29 July 2008 W3C推荐标准 2008年7月29日 1.3 Abstract 摘要 1.4 Status of this Document 本文件的状态 1.5 Table of Contents 目录表 1.5.1 Appendices 附录 1.5.2 附录 1.6 List of Best Practices 最佳实践列表 1.7 1 Introduction 绪论 1.7.1 1.1 Purpose of the Document 本文件的目的 1.7.2 1.2 最佳策略是如何组织的 1.7.3 1.3 Audience 读者 1.7.4 1.4 Scope 应用范围 1.7.4.1 1.4.1 Phasing 阶段 1.7.5 1.5 Relationship to other Best Practices and recommendations 与其它推荐标准和最佳实践的关系 1.7.6 1.6 Longevity and Versioning 寿命和版本 1.8 2 Requirements 需求 1.8.1 2.1 Presentation Issues 表现问题 1.8.2 2.2 Input 输入 1.8.3 2.3 Bandwidth and Cost 带宽和费用 1.8.4 2.4 User Goals 用户目标 1.8.5 2.5 Advertising 广告 1.8.6 2.6 Device Limitations 设备局限性 1.8.7 2.7 Advantages 优点 1.9 3 Delivery Context 传输对象 1.9.1 3.1 One Web 1.9.2 3.2 Background to Adaptation 适配背景 1.9.3 3.3 Adaptation Implementation Model 适配执行模型 1.9.4 3.4 Assumptions about Adaptation 关于适配的假设 1.9.5 3.5 Establishing Context 建立对象 1.9.6 3.6 Choice of User Experience 用户体验的选择 1.9.7 3.7 Default Delivery Context 默认传输对象 1.10 4 Structure of Best Practice Statements 最佳策略规范的结构 1.11 5 Best Practice Statements 最佳实践陈述 1.11.1 5.1 Overall Behavior 全局行为 1.11.1.1 5.1.1 Thematic Consistency of Resource Identified by a URI URI标示的资源的主题一致性 1.11.1.1.1 5.1.1.1 What it means 1.11.1.2 5.1.2 Exploit Device Capabilities 利用设备性能 1.11.1.2.1 5.1.2.1 What it means 解释 1.11.1.3 5.1.3 Work around Deficient Implementations 不充分的执行能力的工作环境 1.11.1.3.1 5.1.3.1 What it means 解释 1.11.1.4 5.1.4 Testing 测试 1.11.1.4.1 5.1.4.1 What it means 解释 1.11.1.4.2 5.1.4.2 How to do it 怎样做 1.11.2 5.2 Navigation and Links 导航和链接 1.11.2.1 5.2.1 URIs of Site Entry Points 网站入口URI 1.11.2.1.1 5.2.1.1 What it means 解释 1.11.2.1.2 5.2.1.2 How to do it 怎样做 1.11.2.2 5.2.2 Navigation Bar 导航栏 1.11.2.2.1 5.2.2.1 What it means 解释 1.11.2.2.2 5.2.2.2 How to do it 怎样做 1.11.2.3 5.2.3 Balanced Structure 权衡结构 1.11.2.3.1 5.2.3.1 What it means 解释 1.11.2.4 5.2.4 Navigation Mechanisms 导航策略 1.11.2.4.1 5.2.4.1 What it means 解释 1.11.2.4.2 5.2.4.2 How to do it 怎样做 1.11.2.4.3 5.2.4.3 References 参考 1.11.2.5 5.2.5 Access Keys 快捷键 1.11.2.5.1 5.2.5.1 What it means 解释 1.11.2.5.2 5.2.5.2 What to test 怎样测试 1.11.2.5.3 5.2.5.3 References 参考 1.11.2.6 5.2.6 Link Target Identification 链接目标识别 1.11.2.6.1 5.2.6.1 What it means 解释 1.11.2.6.2 5.2.6.2 How to do it 怎样做 1.11.2.6.3 5.2.6.3 What to test 怎样测试 1.11.2.6.4 5.2.6.4 References 参考 1.11.2.7 5.2.7 Image Maps 图片热点 1.11.2.7.1 5.2.7.1 What it means 解释 1.11.2.7.2 5.2.7.2 How to do it 怎样做 1.11.2.7.3 5.2.7.3 What to test 怎样测试 1.11.2.7.4 5.2.7.4 References 参考 1.11.2.8 5.2.8 Refreshing, Redirection and Spawned Windows 自动刷新，重定向和派生窗口 1.11.2.8.1 5.2.8.1 What it means 解释 1.11.2.8.2 5.2.8.2 What to test 怎样测试 1.11.2.8.3 5.2.8.3 References 参考 1.11.2.9 5.2.9 Externally Linked Resources 外部链接资源 1.11.2.9.1 5.2.9.1 What it means 解释 1.11.2.9.2 5.2.9.2 How to do it 怎样做 1.11.2.9.3 5.2.9.3 What to test 怎样测试 1.11.3 5.3 Page Layout and Content 页面布局和内容 1.11.3.1 5.3.1 Page Content 页面内容 1.11.3.1.1 5.3.1.1 What it means 解释 1.11.3.1.2 5.3.1.2 What to test 怎样测试 1.11.3.1.3 5.3.1.3 References 参考 1.11.3.2 5.3.2 Page Size 页面大小 1.11.3.2.1 5.3.2.1 What it means 解释 1.11.3.2.2 5.3.2.2 How to do it 怎样做 1.11.3.2.3 5.3.2.3 What to test 怎样测试 1.11.3.2.4 5.3.2.4 References 参考 1.11.3.3 5.3.3 Scrolling 滚动 1.11.3.3.1 5.3.3.1 What it means 解释 1.11.3.3.2 5.3.3.2 How to do it 怎样做 1.11.3.3.3 5.3.3.3 What to test 怎样测试 1.11.3.4 5.3.4 Navigation Bars etc. (Extraneous material) 导航栏等等（外部资料） 1.11.3.4.1 5.3.4.1 What it means 解释 1.11.3.4.2 5.3.4.2 How to do it 怎样做 1.11.3.4.3 5.3.4.3 What to test 怎样测试 1.11.3.4.4 5.3.4.4 References 参考 1.11.3.5 5.3.5 Graphics 图形 1.11.3.5.1 5.3.5.1 What it means 解释 1.11.3.5.2 5.3.5.2 What to test 怎样测试 1.11.3.6 5.3.6 Color 色彩 1.11.3.6.1 5.3.6.1 What it means 解释 1.11.3.6.2 5.3.6.2 What to test 怎样测试 1.11.3.6.3 5.3.6.3 References 参考 1.11.3.7 5.3.7 Background Images 背景图片 1.11.3.7.1 5.3.7.1 What it means 解释 1.11.3.7.2 5.3.7.2 What to test 怎样测试 1.11.4 5.4 Page Definition 页面定义 1.11.4.1 5.4.1 Title 标题 1.11.4.1.1 5.4.1.1 What it means 解释 1.11.4.1.2 5.4.1.2 What to test 怎样测试 1.11.4.2 5.4.2 Frames 框架 1.11.4.2.1 5.4.2.1 What it means 解释 1.11.4.2.2 5.4.2.2 What to test 怎样测试 1.11.4.2.3 5.4.2.3 References 参考 1.11.4.3 5.4.3 Structural Elements 结构元素 1.11.4.3.1 5.4.3.1 What it means 解释 1.11.4.3.2 5.4.3.2 How to do it 怎样做 1.11.4.4 5.4.4 Tables 表格 1.11.4.4.1 5.4.4.1 What it means 解释 1.11.4.4.2 5.4.4.2 What to test 怎样测试 1.11.4.4.3 5.4.4.3 References 参考 1.11.4.5 5.4.5 Non-Text Items 非文本项目 1.11.4.5.1 5.4.5.1 What it means 解释 1.11.4.5.2 5.4.5.2 How to do it 怎样做 1.11.4.5.3 5.4.5.3 What to test 怎样测试 1.11.4.5.4 5.4.5.4 References 参考 1.11.4.6 5.4.6 Image Size 图片尺寸 1.11.4.6.1 5.4.6.1 What it means 解释 1.11.4.6.2 5.4.6.2 What to test 怎样测试 1.11.4.7 5.4.7 Valid Markup 验证标记 1.11.4.7.1 5.4.7.1 What it means 解释 1.11.4.7.2 5.4.7.2 What to test 怎样测试 1.11.4.7.3 5.4.7.3 References 参考 1.11.4.8 5.4.8 Measures 度量 1.11.4.8.1 5.4.8.1 What it means 解释 1.11.4.8.2 5.4.8.2 How to do it 怎样做 1.11.4.8.3 5.4.8.3 What to test 怎样测试 1.11.4.9 5.4.9 Style Sheets 样式表 1.11.4.9.1 5.4.9.1 What it means 解释 1.11.4.9.2 5.4.9.2 How to do it 怎样做 1.11.4.9.3 5.4.9.3 What to test 怎样测试 1.11.4.9.4 5.4.9.4 References 参考 1.11.4.10 5.4.10 Minimize 最小化 1.11.4.10.1 5.4.10.1 What it means 解释 1.11.4.10.2 5.4.10.2 How to do it 怎样做 1.11.4.10.3 5.4.10.3 What to test 怎样测试 1.11.4.11 5.4.11 Content Types Content Type（不翻） 1.11.4.11.1 5.4.11.1 What it means 解释 1.11.4.11.2 5.4.11.2 How to do it 怎样做 1.11.4.11.3 5.4.11.3 What to test 怎样测试 1.11.4.12 5.4.12 Character Encoding 字符编码 1.11.4.12.1 5.4.12.1 What it means 解释 1.11.4.12.2 5.4.12.2 How to do it 怎样做 1.11.4.12.3 5.4.12.3 What to test 怎样测试 1.11.4.12.4 5.4.12.4 References 参考 1.11.4.13 5.4.13 Error Messages 错误消息 1.11.4.13.1 5.4.13.1 What it means 解释 1.11.4.13.2 5.4.13.2 How to do it 怎样做 1.11.4.13.3 5.4.13.3 What to test 怎样测试 1.11.4.14 5.4.14 Cookies Cookie（不翻） 1.11.4.14.1 5.4.14.1 What it means 解释 1.11.4.14.2 5.4.14.2 How to do it 怎样做 1.11.4.14.3 5.4.14.3 What to test 怎样测试 1.11.4.15 5.4.15 Cache Headers 缓存头信息 1.11.4.15.1 5.4.15.1 What it means 解释 1.11.4.15.2 5.4.15.2 How to do it 怎样做 1.11.4.15.3 5.4.15.3 What to test 怎样测试 1.11.4.15.4 5.4.15.4 References 参考 1.11.4.16 5.4.16 Fonts 字体 1.11.4.16.1 5.4.16.1 What it means 解释 1.11.4.16.2 5.4.16.2 How to do it 怎样做 1.11.4.16.3 5.4.16.3 What to test 怎样测试 1.11.5 5.5 User Input 用户输入 1.11.5.1 5.5.1 Input 输入 1.11.5.1.1 5.5.1.1 What it means 解释 1.11.5.1.2 5.5.1.2 How to do it 怎样做 1.11.5.1.3 5.5.1.3 What to test 怎样测试 1.11.5.1.4 5.5.1.4 References 参考 1.11.5.2 5.5.2 Tab Order TAB顺序 1.11.5.2.1 5.5.2.1 What it means 解释 1.11.5.2.2 5.5.2.2 How to do it 怎样做 1.11.5.2.3 5.5.2.3 What to test 怎样测试 1.11.5.3 5.5.3 Labels for Form Controls 表单控件标签 1.11.5.3.1 5.5.3.1 What it means 解释 1.11.5.3.2 5.5.3.2 What to test 怎样测试 1.11.5.3.3 5.5.3.3 References 参考 1.12 6 Conformance and mobileOK 一致性和mobileOK 1.12.1 6.1 Classes of Products 产品类别 1.12.2 6.2 Extensibility 延伸 1.13 A Sources (Non-Normative) 引用来源 1.14 B Related Reading (Non-Normative) 相关阅读 1.15 C Acknowledgements (Non-Normative) 鸣谢 1.16 D References (Non-Normative) 参考资料 1.16.1 D.1 MWI References MWI参考资料 1.16.2 D.2 Sources 引用来源 1.16.3 D.3 Device Independence 设备独立 1.16.4 D.4 Web, Protocols and Languages Web，协议和语言 1.16.5 D.5 Other References 其他参考

Mobile Web Best Practices 1.0 移动Web最佳实践1.0

Basic Guidelines 基础指南

W3C Recommendation 29 July 2008 W3C推荐标准 2008年7月29日

This version: http://www.w3.org/TR/2008/REC-mobile-bp-20080729/

Latest version: http://www.w3.org/TR/mobile-bp/

Previous version: http://www.w3.org/TR/2006/PR-mobile-bp-20061102/

Editors:

Jo Rabin, mTLD Mobile Top Level Domain (dotMobi)

Charles McCathieNevile, Opera Software [Early Drafts]

Please refer to the errata (http://www.w3.org/2008/07/mwbp-errata.html) for this document, which may include some normative corrections.

See also [1] (http://www.w3.org/2003/03/Translations/byTechnology?technology=mobile-bptranslations).

Copyright (http://www.w3.org/Consortium/Legal/ipr-notice#Copyright) © 2008 W3C® (MIT, ERCIM, Keio (http://www.keio.ac.jp/)), All Rights Reserved. W3C liability (http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer), trademark (http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks) and document use (http://www.w3.org/Consortium/Legal/copyright-documents) rules apply.

此版本：http://www.w3.org/TR/2008/REC-mobile-bp-20080729/

最新版本：http://www.w3.org/TR/mobile-bp/

上一版本：http://www.w3.org/TR/2006/PR-mobile-bp-20061102/

编辑：

mTLD 移动顶级域名（dotMobi）的Jo Rabin

Opera Software的Charles McCathieNevile『早期草案』

请参考本文件的勘误 (http://www.w3.org/2008/07/mwbp-errata.html)，包含了一些规范的修正。

也请查看翻译 (http://www.w3.org/2003/03/Translations/byTechnology?technology=mobile-bp)。

版权 (http://www.w3.org/Consortium/Legal/ipr-notice#Copyright) © 2008 W3C (http://www.w3.org/)® (MIT (http://www.csail.mit.edu/)，ERCIM (http://www.ercim.org/)，Keio (http://www.keio.ac.jp/))，保留所有权利。适用W3C责任 (http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer)，商标 (http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks)和文件使用 (http://www.w3.org/Consortium/Legal/copyright-documents)条例。

Abstract 摘要

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.

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.

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.

本文件为传输Web内容到移动设备定义最佳实践。主要目的是改善用这些设备访问网络的用户体验。

本推荐标准是有关被传输的内容而不是内容被创建的过程，也不与内容被传输到的设备或用户代理有关。

本文件主要推荐给网站建设者、维护者和运营者。本文件的读者应该熟悉网站的建设，以及了解一些相关技术，例如Web服务器和HTTP。读者不必须拥有移动技术背景。

Status of this Document 本文件的状态

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

This document was developed by the Best Practices Working Group (http://www.w3.org/2005/MWI/BPWG/) (BPWG) as part of the Mobile Web Initiative (http://www.w3.org/2005/MWI/Activity).

Please see the Working Group's implementation report (http://www.w3.org/2006/06/mwbp-implementation-report). Changes since the previous version of the document are editorial. A complete list of changes (http://www.w3.org/TR/mobile-bp/diff.html) 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.

Please send comments about this document to public-bpwg-comments@w3.org (mailto:public-bpwg-comments@w3.org) (with public archive (http://lists.w3.org/Archives/Public/public-bpwg-comments/)).

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.

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.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy (http://www.w3.org/Consortium/Patent-Policy-20040205/). This document is informative only. W3C maintains a public list of any patent disclosures (http://www.w3.org/2004/01/pp-impl/37584/status) 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 Essential Claim(s) (http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential) must disclose the information in accordance with section 6 of the W3C Patent Policy (http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure).

本章节描述了本文件发布时的状态。其它文件可能会替代本文件。W3C目前关于此项技术报告的最新修订版本列表可以在位于http://www.w3.org/TR/ 的W3C技术报告索引中找到。

本文件由移动Web倡议 (http://www.w3.org/2005/MWI/Activity)下辖的最佳实践工作组 (http://www.w3.org/2005/MWI/BPWG/)(BPWG)开发。

请查阅工作组的施行报告 (http://www.w3.org/2006/06/mwbp-implementation-report)。文件从之前版本的编辑后的改变。一份完整的更新清单 (http://www.w3.org/TR/mobile-bp/diff.html)也可用。

请发送评论到public-bpwg-comments@w3.org (mailto:public-bpwg-comments@w3.org)（公共存档 (http://lists.w3.org/Archives/Public/public-bpwg-comments/)）。

本文件将许多被工作组成员视为必不可少的移动Web业者的经验整合成一套最佳实践。

本文件已被W3C成员、软件开发者、W3C团队和有关方审阅，并由理事批准成为W3C推荐标准。它目前是一个固定文件可以被用作参考资料或是被其他文件引用。W3C制定推荐标准的作用是为了提高对它的关注并促进其被广泛部署。从而增强Web的功能性和互可操作性。

本文件是由遵循2004年2月5日W3C专利政策 (http://www.w3.org/Consortium/Patent-Policy-20040205/)的一个团队制作。文件仅供参考。

Table of Contents 目录表

1 Introduction (http://www.w3.org/TR/mobile-bp/#d0e113)
    1.1 Purpose of the Document (http://www.w3.org/TR/mobile-bp/#d0e116)
    1.2 How the Best Practices are Organized (http://www.w3.org/TR/mobile-bp/#d0e128)
    1.3 Audience (http://www.w3.org/TR/mobile-bp/#d0e163)
    1.4 Scope (http://www.w3.org/TR/mobile-bp/#d0e172)
        1.4.1 Phasing (http://www.w3.org/TR/mobile-bp/#phasing)
    1.5 Relationship to other Best Practices and recommendations (http://www.w3.org/TR/mobile-bp/#d0e201)
    1.6 Longevity and Versioning (http://www.w3.org/TR/mobile-bp/#d0e226)
2 Requirements (http://www.w3.org/TR/mobile-bp/#requirements)
    2.1 Presentation Issues (http://www.w3.org/TR/mobile-bp/#d0e240)
    2.2 Input (http://www.w3.org/TR/mobile-bp/#d0e253)
    2.3 Bandwidth and Cost (http://www.w3.org/TR/mobile-bp/#d0e264)
    2.4 User Goals (http://www.w3.org/TR/mobile-bp/#UserGoals)
    2.5 Advertising (http://www.w3.org/TR/mobile-bp/#d0e282)
    2.6 Device Limitations (http://www.w3.org/TR/mobile-bp/#d0e289)
    2.7 Advantages (http://www.w3.org/TR/mobile-bp/#d0e304)
3 Delivery Context (http://www.w3.org/TR/mobile-bp/#d0e347)
    3.1 One Web (http://www.w3.org/TR/mobile-bp/#OneWeb)
    3.2 Background to Adaptation (http://www.w3.org/TR/mobile-bp/#ca)
    3.3 Adaptation Implementation Model (http://www.w3.org/TR/mobile-bp/#d0e402)
    3.4 Assumptions about Adaptation (http://www.w3.org/TR/mobile-bp/#d0e428)
    3.5 Establishing Context (http://www.w3.org/TR/mobile-bp/#d0e437)
    3.6 Choice of User Experience (http://www.w3.org/TR/mobile-bp/#d0e451)
    3.7 Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc)
4 Structure of Best Practice Statements (http://www.w3.org/TR/mobile-bp/#bpstructure)
5 Best Practice Statements (http://www.w3.org/TR/mobile-bp/#d0e630)
    5.1 Overall Behavior (http://www.w3.org/TR/mobile-bp/#bpgroupgeneral)
        5.1.1 Thematic Consistency of Resource Identified by a URI (http://www.w3.org/TR/mobile-bp/#tc)
        5.1.2 Exploit Device Capabilities (http://www.w3.org/TR/mobile-bp/#lcd)
        5.1.3 Work around Deficient Implementations (http://www.w3.org/TR/mobile-bp/#d0e704)
        5.1.4 Testing (http://www.w3.org/TR/mobile-bp/#test)
    5.2 Navigation and Links (http://www.w3.org/TR/mobile-bp/#bpgroupnavlinks)
        5.2.1 URIs of Site Entry Points (http://www.w3.org/TR/mobile-bp/#d0e742)
        5.2.2 Navigation Bar (http://www.w3.org/TR/mobile-bp/#d0e773)
        5.2.3 Balanced Structure (http://www.w3.org/TR/mobile-bp/#d0e790)
        5.2.4 Navigation Mechanisms (http://www.w3.org/TR/mobile-bp/#d0e804)
        5.2.5 Access Keys (http://www.w3.org/TR/mobile-bp/#d0e831)
        5.2.6 Link Target Identification (http://www.w3.org/TR/mobile-bp/#d0e864)
        5.2.7 Image Maps (http://www.w3.org/TR/mobile-bp/#d0e911)
        5.2.8 Refreshing, Redirection and Spawned Windows (http://www.w3.org/TR/mobile-bp/#d0e959)
        5.2.9 Externally Linked Resources (http://www.w3.org/TR/mobile-bp/#el)
    5.3 Page Layout and Content (http://www.w3.org/TR/mobile-bp/#bpgroupplayout)
        5.3.1 Page Content (http://www.w3.org/TR/mobile-bp/#cl)
        5.3.2 Page Size (http://www.w3.org/TR/mobile-bp/#d0e1099)
        5.3.3 Scrolling (http://www.w3.org/TR/mobile-bp/#d0e1146)
        5.3.4 Navigation Bars etc. (Extraneous material) (http://www.w3.org/TR/mobile-bp/#cm)
        5.3.5 Graphics (http://www.w3.org/TR/mobile-bp/#d0e1219)
        5.3.6 Color (http://www.w3.org/TR/mobile-bp/#d0e1240)
        5.3.7 Background Images (http://www.w3.org/TR/mobile-bp/#d0e1272)
    5.4 Page Definition (http://www.w3.org/TR/mobile-bp/#bpgrouppdefinition)
        5.4.1 Title (http://www.w3.org/TR/mobile-bp/#d0e1294)
        5.4.2 Frames (http://www.w3.org/TR/mobile-bp/#d0e1321)
        5.4.3 Structural Elements (http://www.w3.org/TR/mobile-bp/#sm)
        5.4.4 Tables (http://www.w3.org/TR/mobile-bp/#d0e1374)
        5.4.5 Non-Text Items (http://www.w3.org/TR/mobile-bp/#d0e1433)
        5.4.6 Image Size (http://www.w3.org/TR/mobile-bp/#ImageSize)
        5.4.7 Valid Markup (http://www.w3.org/TR/mobile-bp/#d0e1584)
        5.4.8 Measures (http://www.w3.org/TR/mobile-bp/#me)
        5.4.9 Style Sheets (http://www.w3.org/TR/mobile-bp/#style)
        5.4.10 Minimize (http://www.w3.org/TR/mobile-bp/#d0e1733)
        5.4.11 Content Types (http://www.w3.org/TR/mobile-bp/#d0e1770)
        5.4.12 Character Encoding (http://www.w3.org/TR/mobile-bp/#d0e1821)
        5.4.13 Error Messages (http://www.w3.org/TR/mobile-bp/#d0e1875)
        5.4.14 Cookies (http://www.w3.org/TR/mobile-bp/#d0e1925)
        5.4.15 Cache Headers (http://www.w3.org/TR/mobile-bp/#d0e1945)
        5.4.16 Fonts (http://www.w3.org/TR/mobile-bp/#fonts)
    5.5 User Input (http://www.w3.org/TR/mobile-bp/#bpgroupinput)
        5.5.1 Input (http://www.w3.org/TR/mobile-bp/#d0e2028)
        5.5.2 Tab Order (http://www.w3.org/TR/mobile-bp/#d0e2100)
        5.5.3 Labels for Form Controls (http://www.w3.org/TR/mobile-bp/#d0e2133)
6 Conformance and mobileOK (http://www.w3.org/TR/mobile-bp/#d0e2183)
    6.1 Classes of Products (http://www.w3.org/TR/mobile-bp/#d0e2192)
    6.2 Extensibility (http://www.w3.org/TR/mobile-bp/#d0e2200)

Appendices 附录

A Sources (http://www.w3.org/TR/mobile-bp/#d0e2206) (Non-Normative)
B Related Reading (http://www.w3.org/TR/mobile-bp/#related) (Non-Normative)
C Acknowledgements (http://www.w3.org/TR/mobile-bp/#d0e2280) (Non-Normative)
D References (http://www.w3.org/TR/mobile-bp/#d0e2364) (Non-Normative)
    D.1 MWI References (http://www.w3.org/TR/mobile-bp/#d0e2367)
    D.2 Sources (http://www.w3.org/TR/mobile-bp/#d0e2377)
    D.3 Device Independence (http://www.w3.org/TR/mobile-bp/#d0e2397)
    D.4 Web, Protocols and Languages (http://www.w3.org/TR/mobile-bp/#d0e2407)
    D.5 Other References (http://www.w3.org/TR/mobile-bp/#d0e2432)

1 引言
    1.1 本文件的目的
    1.2 最佳实践是如何组织的
    1.3 读者
    1.4 应用范围
        1.4.1 阶段
    1.5 与其他推荐和最佳策略的关系
    1.6 寿命和版本
2 需求
    2.1 表现问题
    2.2 输入
    2.3 带宽和费用
    2.4 用户目标
    2.5 广告
    2.6 设备局限性
    2.7 优点
3 传输对象
    3.1 One Web
    3.2 适配背景
    3.3 适配执行模式
    3.4 关于适配的假设
    3.5 建立对象
    3.6 用户体验的选择
    3.7 默认传输对象
4 最佳实践规范的结构
5 最佳实践规范
    5.1 全局行为
        5.1.1 URI标示的资源的主题一致性
        5.1.2 开发设备性能
        5.1.3 在不充分的执行能力中工作
        5.1.4 测试
    5.2 导航和链接
        5.2.1 网站入口URI
        5.2.2 导航栏
        5.2.3 权衡结构
        5.2.4 导航策略
        5.2.5 快捷键
        5.2.6 链接目标识别
        5.2.7 图片热点
        5.2.8 自动刷新，重定向和派生窗口
        5.2.9 外部链接资源
    5.3 页面布局和内容
        5.3.1 页面内容
        5.3.2 页面大小
        5.3.3 滚动
        5.3.4 导航栏等等。（外部材料）
        5.3.5 图形
        5.3.6 色彩
        5.3.7 背景图片
    5.4 页面定义
        5.4.1 标题
        5.4.2 框架
        5.4.3 结构元素
        5.4.4 表格
        5.4.5 非文本项
        5.4.6 图片尺寸
        5.4.7 验证标记
        5.4.8 度量
        5.4.9 样式表
        5.4.10 最小化
        5.4.11 Content Types
        5.4.12 字符编码
        5.4.13 错误消息
        5.4.14 Cookies
        5.4.15 缓存头信息
        5.4.16 字体
    5.5 用户输入
        5.5.1 输入
        5.5.2 Tab顺序
        5.5.3 表单控件标签
6 一致和mobileOK
    6.1 制品类别
    6.2 延伸

附录

A 起源（非基准）
B 相关阅读（非基准）
C 感谢（非基准）
D 参考（非基准）
    D.1 MWI参考
    D.2 起源
    D.3 设备独立性
    D.4 Web、协议和语言
    D.5 其他参考

List of Best Practices 最佳实践列表

The following Best Practices are discussed in this document and listed here for convenience. There is also a free-standing summary (http://www.w3.org/TR/mobile-bp/summary).

1. [THEMATIC_CONSISTENCY (http://www.w3.org/TR/mobile-bp/#THEMATIC_CONSISTENCY)] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.
2. [CAPABILITIES (http://www.w3.org/TR/mobile-bp/#CAPABILITIES)] Exploit device capabilities to provide an enhanced user experience.
3. [DEFICIENCIES (http://www.w3.org/TR/mobile-bp/#DEFICIENCIES)] Take reasonable steps to work around deficient implementations.
4. [TESTING (http://www.w3.org/TR/mobile-bp/#TESTING)] Carry out testing on actual devices as well as emulators.
5. [URIS (http://www.w3.org/TR/mobile-bp/#URIS)] Keep the URIs of site entry points short.
6. [NAVBAR (http://www.w3.org/TR/mobile-bp/#NAVBAR)] Provide only minimal navigation at the top of the page.
7. [BALANCE (http://www.w3.org/TR/mobile-bp/#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.
8. [NAVIGATION (http://www.w3.org/TR/mobile-bp/#NAVIGATION)] Provide consistent navigation mechanisms.
9. [ACCESS_KEYS (http://www.w3.org/TR/mobile-bp/#ACCESS_KEYS)] Assign access keys to links in navigational menus and frequently accessed functionality.
10. [LINK_TARGET_ID (http://www.w3.org/TR/mobile-bp/#LINK_TARGET_ID)] Clearly identify the target of each link.
11. [LINK_TARGET_FORMAT (http://www.w3.org/TR/mobile-bp/#LINK_TARGET_FORMAT)] Note the target file's format unless you know the device supports it.
12. [IMAGE_MAPS (http://www.w3.org/TR/mobile-bp/#IMAGE_MAPS)] Do not use image maps unless you know the device supports them effectively.
13. [POP_UPS (http://www.w3.org/TR/mobile-bp/#POP_UPS)] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
14. [AUTO_REFRESH (http://www.w3.org/TR/mobile-bp/#AUTO_REFRESH)] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.
15. [REDIRECTION (http://www.w3.org/TR/mobile-bp/#REDIRECTION)] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.
16. [EXTERNAL_RESOURCES (http://www.w3.org/TR/mobile-bp/#EXTERNAL_RESOURCES)] Keep the number of externally linked resources to a minimum.
17. [SUITABLE (http://www.w3.org/TR/mobile-bp/#SUITABLE)] Ensure that content is suitable for use in a mobile context.
18. [CLARITY (http://www.w3.org/TR/mobile-bp/#CLARITY)] Use clear and simple language.
19. [LIMITED (http://www.w3.org/TR/mobile-bp/#LIMITED)] Limit content to what the user has requested.
20. [PAGE_SIZE_USABLE (http://www.w3.org/TR/mobile-bp/#PAGE_SIZE_USABLE)] Divide pages into usable but limited size portions.
21. [PAGE_SIZE_LIMIT (http://www.w3.org/TR/mobile-bp/#PAGE_SIZE_LIMIT)] Ensure that the overall size of page is appropriate to the memory limitations of the device.
22. [SCROLLING (http://www.w3.org/TR/mobile-bp/#SCROLLING)] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.
23. [CENTRAL_MEANING (http://www.w3.org/TR/mobile-bp/#CENTRAL_MEANING)] Ensure that material that is central to the meaning of the page precedes material that is not.
24. [GRAPHICS_FOR_SPACING (http://www.w3.org/TR/mobile-bp/#GRAPHICS_FOR_SPACING)] Do not use graphics for spacing.
25. [LARGE_GRAPHICS (http://www.w3.org/TR/mobile-bp/#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.
26. [USE_OF_COLOR (http://www.w3.org/TR/mobile-bp/#USE_OF_COLOR)] Ensure that information conveyed with color is also available without color.
27. [COLOR_CONTRAST (http://www.w3.org/TR/mobile-bp/#COLOR_CONTRAST)] Ensure that foreground and background color combinations provide sufficient contrast.
28. [BACKGROUND_IMAGE_READABILITY (http://www.w3.org/TR/mobile-bp/#BACKGROUND_IMAGE_READABILITY)] When using background images make sure that content remains readable on the device.
29. [PAGE_TITLE (http://www.w3.org/TR/mobile-bp/#PAGE_TITLE)] Provide a short but descriptive page title.
30. [NO_FRAMES (http://www.w3.org/TR/mobile-bp/#NO_FRAMES)] Do not use frames.
31. [STRUCTURE (http://www.w3.org/TR/mobile-bp/#STRUCTURE)] Use features of the markup language to indicate logical document structure.
32. [TABLES_SUPPORT (http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT)] Do not use tables unless the device is known to support them.
33. [TABLES_NESTED (http://www.w3.org/TR/mobile-bp/#TABLES_NESTED)] Do not use nested tables.
34. [TABLES_LAYOUT (http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT)] Do not use tables for layout.
35. [TABLES_ALTERNATIVES (http://www.w3.org/TR/mobile-bp/#TABLES_ALTERNATIVES)] Where possible, use an alternative to tabular presentation.
36. [NON-TEXT_ALTERNATIVES (http://www.w3.org/TR/mobile-bp/#NON-TEXT_ALTERNATIVES)] Provide a text equivalent for every non-text element.
37. [OBJECTS_OR_SCRIPT (http://www.w3.org/TR/mobile-bp/#OBJECTS_OR_SCRIPT)] Do not rely on embedded objects or script.
38. [IMAGES_SPECIFY_SIZE (http://www.w3.org/TR/mobile-bp/#IMAGES_SPECIFY_SIZE)] Specify the size of images in markup, if they have an intrinsic size.
39. [IMAGES_RESIZING (http://www.w3.org/TR/mobile-bp/#IMAGES_RESIZING)] Resize images at the server, if they have an intrinsic size.
40. [VALID_MARKUP (http://www.w3.org/TR/mobile-bp/#VALID_MARKUP)] Create documents that validate to published formal grammars.
41. [MEASURES (http://www.w3.org/TR/mobile-bp/#MEASURES)] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.
42. [STYLE_SHEETS_USE (http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_USE)] Use style sheets to control layout and presentation, unless the device is known not to support them.
43. [STYLE_SHEETS_SUPPORT (http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SUPPORT)] Organize documents so that if necessary they may be read without style sheets.
44. [STYLE_SHEETS_SIZE (http://www.w3.org/TR/mobile-bp/#STYLE_SHEETS_SIZE)] Keep style sheets small.
45. [MINIMIZE (http://www.w3.org/TR/mobile-bp/#MINIMIZE)] Use terse, efficient markup.
46. [CONTENT_FORMAT_SUPPORT (http://www.w3.org/TR/mobile-bp/#CONTENT_FORMAT_SUPPORT)] Send content in a format that is known to be supported by the device.
47. [CONTENT_FORMAT_PREFERRED (http://www.w3.org/TR/mobile-bp/#CONTENT_FORMAT_PREFERRED)] Where possible, send content in a preferred format.
48. [CHARACTER_ENCODING_SUPPORT (http://www.w3.org/TR/mobile-bp/#CHARACTER_ENCODING_SUPPORT)] Ensure that content is encoded using a character encoding that is known to be supported by the device.
49. [CHARACTER_ENCODING_USE (http://www.w3.org/TR/mobile-bp/#CHARACTER_ENCODING_USE)] Indicate in the response the character encoding being used.
50. [ERROR_MESSAGES (http://www.w3.org/TR/mobile-bp/#ERROR_MESSAGES)] Provide informative error messages and a means of navigating away from an error message back to useful information.
51. [COOKIES (http://www.w3.org/TR/mobile-bp/#COOKIES)] Do not rely on cookies being available.
52. [CACHING (http://www.w3.org/TR/mobile-bp/#CACHING)] Provide caching information in HTTP responses.
53. [FONTS (http://www.w3.org/TR/mobile-bp/#FONTS)] Do not rely on support of font related styling.
54. [MINIMIZE_KEYSTROKES (http://www.w3.org/TR/mobile-bp/#MINIMIZE_KEYSTROKES)] Keep the number of keystrokes to a minimum.
55. [AVOID_FREE_TEXT (http://www.w3.org/TR/mobile-bp/#AVOID_FREE_TEXT)] Avoid free text entry where possible.
56. [PROVIDE_DEFAULTS (http://www.w3.org/TR/mobile-bp/#PROVIDE_DEFAULTS)] Provide pre-selected default values where possible.
57. [DEFAULT_INPUT_MODE (http://www.w3.org/TR/mobile-bp/#DEFAULT_INPUT_MODE)] Specify a default text entry mode, language and/or input format, if the device is known to support it.
58. [TAB_ORDER (http://www.w3.org/TR/mobile-bp/#TAB_ORDER)] Create a logical order through links, form controls and objects.
59. [CONTROL_LABELLING (http://www.w3.org/TR/mobile-bp/#CONTROL_LABELLING)] Label all form controls appropriately and explicitly associate labels with form controls.
60. [CONTROL_POSITION (http://www.w3.org/TR/mobile-bp/#CONTROL_POSITION)] Position labels so they lay out properly in relation to the form controls they refer to.

本文件所讨论到的最佳策略列表于下。也有一个独立的概要 (http://www.w3.org/TR/mobile-bp/summary)。

1. [主题一致性] 确保当从不同的设备通过一个URI访问时得到的内容能产生一个主题连贯的体验。
2. [性能] 利用设备性能提供一个增强的用户体验。
3. [缺陷] 采取合理的步骤来解决不充分的执行能力。
4. [测试] 像在模拟器上一样在真实设备上测试。
5. [URI] 保持访问网站的URI简短。
6. [导航栏] 在页面顶部提供一个最小限度的导航。
7. [权衡] 在在一个页面加入太多链接和让用户点击许多链接得到想要的内容之间找到一个平衡。
8. [导航] 提供一致的导航策略。
9. [快捷键] 为导航菜单和常用功能链接分配快捷键。
10. [链接目标识别] 清楚地标示每个链接的目标。
11. [链接目标格式] 标注链接文件格式，除非你知道设备支持它。
12. [图片热点] 不要使用图片热点，除非你知道设备有效的支持它。
13. [弹出窗口] 不要触发弹出窗口或切换到其他窗口，不要再未通知用户的情况下改变当前窗口。
14. [自动刷新] 不要创建周期性自动刷新页面，除非你预先通知过用户，并且提供一个方法停止它。
15. [重定向] 不要使用标记自动重定向页面，配置服务器通过HTTP 3XX代码执行重定向。
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. [Cookie] 不要依赖Cookie可用。
52. [缓存] 在HTTP应答里提供缓存信息。
53. [字体] 不要依赖字体样式。
54. [最少击键] 保持按键次数最少。
55. [避免自由文本] 如果可能，避免自由文本输入。
56. [提供默认] 如果可能，提供预选好的默认值。
57. [默认输入法] 提供默认输入法、语言或输入格式，如果设备支持的话。
58. [TAB顺序] 创建链接、表单和对象的逻辑顺序。
59. [控件标签] 恰当的为控件加上标签。
60. [控件位置] 恰当的放置标签令它们和相关的控件显示出关联。

1 Introduction 绪论

1.1 Purpose of the Document 本文件的目的

This document sets out a series of recommendations designed to improve the user experience of the Web on mobile devices.

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 Mobile Web Best Practices Working Group Charter (http://www.w3.org/2005/01/BPWGCharter/Overview.html) and is not developed in this document. At the time of writing of this document, documents describing mobileOK and techniques for implementing the Best Practice recommendations are being worked on.

这份文件列出了一系列建议，旨在改善移动设备上的Web的用户体验。

本推荐标准提供给网站创建者，维护者和运营者并且打算以此作为MobileOK标示评定的基础。MobileOK是由移动Web最佳实践工作组宪章 (http://www.w3.org/2005/01/BPWGCharter/Overview.html)描述，并由其他文件开发。在本文件撰写时，符合最佳实践推荐标准的MobileOK的描述文件和技术正在完善中。

1.2 最佳策略是如何组织的

The document is organized as follows:

1. Introduction. Describes the audience, purpose and scope of the document.
2. Requirements. An illustration of the type of problems that the Best Practices are intended to ameliorate.
3. Delivery Context. Discusses the environment within which mobile access to the Web is realized, with particular reference to adaptation.
4. Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.
5. Best Practices. The statements themselves.
6. Conformance and mobileOK. A brief conformance statement and reference to the mobileOK documentation.
7. Appendices
   

Sources
Related Reading
Acknowledgements
References

本文件组织方式如下：

1. 绪论。描述文件的读者、目的和使用范围。
2. 需求。最佳实践有意改善的问题。
3. 传输对象。讨论移动访问Web的适配环境。
4. 最佳实践概括。讨论最佳实践，以及它们的来源。
5. 最佳实践。它们的解释。
6. 一致性和MobileOK。一致性解释和MobileOK参考。
7. 附录
   

来源
相关阅读
响应

1.3 Audience 读者

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.

Our intention is to make it clear to all involved what the Best Practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some of our statements may appear to be obvious or trivial to those with experience in this area.

The document is not targeted solely at developers; others, such as interaction and graphic designers are encouraged to read it.

本文件的读者应该熟悉网站的建设，以及了解一些相关技术，例如Web服务器和HTTP。读者不必须拥有移动技术背景。

我们的意图是要解释清楚所有关系到最佳实践的事，因此建立一个理解上的共同基础。因为希望那些尚未涉及移动友好内容的开发人员能理解，我们的某些陈述对于在这方面有经验的人来说可能显得很直白或琐碎。

本文件不仅仅针对开发者；我们也鼓励其他人——比如互动和图形设计师——来阅读它。

1.4 Scope 应用范围

The scope of these Best Practices is laid out in "Scope of Mobile Web Best Practices" [Scope (http://www.w3.org/TR/mobile-bp/#Scope)]. In summary, this document refers primarily to the extension of Web browsing onto mobile devices.

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.

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 [WCAG (http://www.w3.org/TR/mobile-bp/#WCAG)] guidelines are general to all forms of Web access and are not repeated here unless they have a specific mobile interpretation. Examples of general good practice which have a specific mobile interpretation include "Error Messages" and "Color".

See B Related Reading for information about the related topics of Internationalization, Web Accessibility and Device Independence.

本最佳实践的应用范围写在《移动网最佳实践的应用范围》一文中。概括来说，本文件主要关于延伸Web浏览到移动设备上。

本最佳实践推荐关于被传输的内容。尽管它们明显和移动设备上内容创建和渲染的处理过程有关，但是这些行为并未被打算写入最佳实践。

为向移动设备传输内容指定最佳实践作为本文件的目标，没有具体指定的移动方面的陈述则不包含在内。特别地，许多Web内容可访问性[WCAG (http://www.w3.org/TR/mobile-bp/#WCAG)]指南对Web访问的所有形式都有效，在此不再敷述，除非有特殊的移动解释。例如有特殊移动解释的“错误消息”和“色彩”。

查阅B相关阅读获取关于国际化、Web可访问性和设备独立性的主题信息。

1.4.1 Phasing 阶段

As discussed in the Scope document [Scope (http://www.w3.org/TR/mobile-bp/#Scope)] 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.

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.

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.

在应用范围文件的讨论中[Scope]关于移动Web最佳实践的有许多方面。目前，举例来说，许多网站和页面的结构和设计在移动设备上浏览时用户体验不佳。

通过移动设备访问的用户体验质量在相当程度上依靠网站、浏览器和设备本身的可用性。尽管浏览器和设备的可用性很重要（对于阅读、导航和与内容交互），但本文件主要专注于改进网站可用性的最佳做法。

未来阶段可能要考虑其他方面——例如最佳策略应用于适配和设备。另外在未来阶段本推荐的范围可能会扩大到超过“传统Web浏览”到类似于多通道交互这样的领域。

1.5 Relationship to other Best Practices and recommendations 与其它推荐标准和最佳实践的关系

These recommendations are in part derived from the Web Content Accessibility Guidelines [WCAG (http://www.w3.org/TR/mobile-bp/#WCAG)]. 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.

This document builds on some of the concepts described by the Device Independence Working Group (http://www.w3.org/2001/di/) (DIWG) in the Device Independence Principles [DIP (http://www.w3.org/TR/mobile-bp/#DIP)]. The document discusses device and delivery channel characteristics, which the DIWG has named "Delivery Context" [DCODI (http://www.w3.org/TR/mobile-bp/#DCODI)]. In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS (http://www.w3.org/TR/mobile-bp/#DIGLOSS)].

The BPWG is developing a companion document describing techniques [Techniques (http://www.w3.org/TR/mobile-bp/#Techniques)] by which the Best Practice statements in this document can be implemented.

本推荐有一部分来自Web内容可访问性指南[WCAG]. 之前提到，WCAG是移动网最佳策略的补充，其应用范围限定在特殊的移动相关问题上。

本文件建立在设备独立性工作组 (http://www.w3.org/2001/di/)(DIWG)的设备独立性原则[DIP]中描述的某些概念上。本文件讨论被DIWG称为“传输环境”[DCODI]的设备和传输途径特征。而且本文件也使用了DIWG设备独立性语汇词条[DIGLOSS]中的某些术语。

最佳策略工作组(BPWG)正在开发一个描述本文件用到过的技术[Techniques]的并行文件。

1.6 Longevity and Versioning 寿命和版本

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 3.7 Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc), 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.

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.

为了能适用于大部分标记语言，本最佳实践用通用等级撰写。

本文件可能会不时被重审。必要时，更改后会发布清晰组织的更新版本。

2 Requirements 需求

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.

本节讨论第5节所陈述的移动Web最佳实践的需求。需求的陈述意在说明而不是详解或完善。

2.1 Presentation Issues 表现问题

Today, Many Web pages are laid out for presentation on desktop size displays, and exploit capabilities of desktop browsing software.

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.

Because of the limited screen size, the subject matter of the page may require considerable scrolling to be visible, especially if the top of the page is occupied by images and navigation links. In these cases the user gets no immediate feedback as to whether their retrieval has resulted in the right content.

It is particularly important in the mobile context to help the user create a mental image of the site. This can be assisted by adopting a consistent style and can be considerably diminished by an uneven style.

目前，许多网页专为桌面显示器的大小表现而设计版式，以及利用桌面浏览软件能力。利用移动设备访问这些网页往往得到一个很差的体验，原因包括页面没有按照预想的方式显示，由于屏幕尺寸的限制和可视范围的限制导致上下文的语境不易连贯等等。

因为屏幕尺寸的限制，页面的主要内容可能需要滚动才能显示，特别是页面顶部被图片和导航链接占据的情况下。这样用户就不能在第一时间确认他们是否得到了他们所请求的内容。

帮助用户建立网站的印象在移动环境中非常重要。使用一致的样式有助于增进用户对网站构成完整的概念。

2.2 Input 输入

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.

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.

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.

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.

相对于有全尺寸键盘的桌面设备来说，在移动设备上输入是比较困难的。移动设备通常只有一个非常有限的键盘。小小的按键，而且经常没有指点设备。

移动网的一个困难就是URI很难打出来。长的URI因为包含了许多标点符号就特别难输入正确。

因为屏幕和输入方式的限制，表单很难填写。因为屏幕尺寸的限制，在各个表单域之间切换可能不能按照预定的顺序；因为输入方式的限制，表单也比较难填写内容。

许多现代设备提供了后退按钮，有些没有提供。即使设备提供了，用户也可能不知道怎样应用这个功能。这意味着用户经常很难从错误中恢复，比如失效的链接等等。

2.3 Bandwidth and Cost 带宽和费用

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.

Mobile data transfer often costs money. The fact that mobile devices frequently support only limited types of content means that a user may follow a link and retrieve information that is unusable on their device.

Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory - for example, larger images may only be viewable in small pieces and require considerable scrolling.

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.

移动网络和固网宽带相比速度比较慢，经常感觉很延迟。这又会引起浏览时间太长，特别是内容很长和内容分页很多时。

移动数据传输通常要花钱。而移动设备通常只支持有限的内容格式，用户经常点击链接后得到设备不可用的格式。即使内容格式能被设备识别，但是经常出问题，导致体验上不能令人满意。比如大图片可能只能看到其中的一小块，令人不得不滚动页面来查看。

网页可能包含用户每有指定要求的内容。特别是广告和大图片。在移动世界里，多余的内容导致很差的可用性，而且可能相当增加浏览的费用。

2.4 User Goals 用户目标

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.

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.

典型的移动用户和固网用户或桌面用户相比有不同的兴趣。他们有更加快速的、目标明确的意图。他们的意图通常是要找出和他们环境相关的特定信息。这种目标直接的应用的一个例子是可能用户查询一个关于旅行计划的特殊信息，而他正在这个旅行的途中。

同样地，典型的移动用户对长文档和无目的浏览兴趣不大。设备的特性通常是不适合阅读长文档的，而且用户通常是将移动设备取得信息作为最后的手段来用，因为没有别的更方便的连接可用。

2.5 Advertising 广告

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].

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.

商业网站开发者应该注意到移动设备和桌面设备之间不同的广告模式。例如某些通常用来展示广告内容的技巧（比如弹出窗口，底部弹出和大广告条幅）在小设备上工作的不好。因此这些方法被最佳策略反对使用。请参考 [中心思想]，[大图形]和[弹出窗口]。

这并不是表示MWI限制或禁止广告。恰当地说，意思是网站的用户体验应该全局考虑。如果有广告，也要尽可能做得有效。

2.6 Device Limitations 设备局限性

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 [Scope (http://www.w3.org/TR/mobile-bp/#Scope)], various other limitations may apply and these have an impact on the usability of the Web from a mobile device.

Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no choice of browser and upgrading it is not possible.

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 [T-MOB (http://www.w3.org/TR/mobile-bp/#T-MOB)]. 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.

Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.

如前所述，由键盘和屏幕造成的限制，页面通常需要和桌面设备不同的设计。在[Scope]章节提到的许多其他的局限也可能发生，并且在移动设备上造成web可用性问题。

移动浏览器经常不支持脚本或插件，意味着支持的内容格式范围被限制了。许多情况下用户无法选择或升级浏览器。

有些关系到页面渲染的行为需要强大的计算能力——例如页面重排、表格排版、处理冗长且复杂的样式以及处理错误的标记[T-MOB]。移动设备只有非常有限的处理能力导致它会花费显著的时间来完成页面渲染。设备花费大量能力和服务器通讯时也一样会产生显著的时间延迟。

许多设备只有有限的可用内存，而且页面和图片如果由于内存限制显示不完整时会引发其他问题。

2.7 Advantages 优点

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.

This popularity largely stems at present from them being:

• personal
• personalizable
• portable
• connected

and increasingly multi-functional beyond their original purpose of voice communications.

In addition to these factors, the advantages of mobile devices will increasingly include:

• location awareness
• one-handed operation
• always on
• universal alerting device

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.

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.

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

在讨论为移动设备传输Web内容的局限性的过程中容易忽视移动上网很普遍流行的事实。

流行的原因很大程度上是因为他们是：

• 私人的
• 个性化的
• 便携的
• 在线的

以及超越它们最初的目的——语音通话——逐渐变得更多功能起来。

在这些因素之外，移动设备将逐渐具备以下优点：

• 定位
• 单手操作
• 始终开机
• 通用告警设备

举例其中的一些因素：你能随时随地上网——你不需要去记住回到电脑前后需要做什么事情——你可以立即就做，因为你的设备能够随时上网。

此外，因为移动设备拥有各种各样的外形，而且功能众多如定位技术、摄像头、语音识别技术、触摸屏等等，互联网可以在任何情况下任何时间被更多的人使用。在电线无法接入的地方，在未预料的情况（比如高山上的医学救援行动）时移动网占领了先机。就像人们带手表以随时掌握时间一样轻松方便。

最后，当今许多人们用移动设备上网次数比用桌面电脑还要多。这对那些拥有许多可上网的移动电话却通常只用来打电话的发展中国家似乎非常有意义。

3 Delivery Context 传输对象

Delivery Context is used with the specific meaning (http://www.w3.org/TR/di-gloss/#def-delivery-context-v2) defined in the Device Independence Glossary [DIGLOSS (http://www.w3.org/TR/mobile-bp/#DIGLOSS)].

传输对象是由设备独立语汇[DIGLOSS]定义的特定含义 (http://www.w3.org/TR/di-gloss/#def-delivery-context-v2)。

3.1 One Web

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

As discussed in the Scope document [Scope (http://www.w3.org/TR/mobile-bp/#Scope)], One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation (http://www.w3.org/TR/di-gloss/#def-http-representation) 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 5.1.1 Thematic Consistency of Resource Identified by a URI (http://www.w3.org/TR/mobile-bp/#tc)).

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

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.

From the perspective of this document this means that services should be available as some variant of HTML over HTTP (see 3.7 Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc)).

本推荐标准的目的是改进移动设备的Web体验。虽然本文没有具体谈到桌面浏览的体验，但是必须明白应该尽力在希望的范围内实现“One Web”。

在“范围”[Scope]章节中提到，One Web意在在合理的范围内提供同样的信息和服务而无论用户使用什么样的设备。不过，这并不表示在所有设备上提供一模一样的信息和表现。移动使用环境、设备能力的差异、带宽问题和移动网络能力都影响表现。不仅如此，某些服务和信息更适合特定的用户环境。（查阅 5.1.1 URI标示的资源的主题一致性）

某些服务主要适合移动（比如位置信息服务）。有些适合移动但是需要桌面组件作为补充（例如复杂的配置任务）。另外一些适合桌面但是移动作为补充（比如报警系统）。最后一些就是完全的桌面应用了（大段参考材料，大图片等等）。

应用设计师和服务提供者都希望为他们的服务在适用的环境中提供尽可能最好的体验。然而，当服务能够最在某种环境下提供最适当的体验， 也应该尽量提供一样合理的体验给受限设备，以及不排斥其他类型的设备访问，除非因为设备局限必须不这么做。

本文件应该意味着某些HTTP上的变种HTML也适用（参见 3.7 默认传输对象）。

3.2 Background to Adaptation 适配背景

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 Content Adaptation.

We do not describe adaptation in detail in this document. For a more detailed description, readers are referred to the Device Independence Principles [DIP (http://www.w3.org/TR/mobile-bp/#DIP)].

In addition, the sister group of the Best Practices Working Group, the Device Description Working Group (http://www.w3.org/2005/MWI/DDWG/), is currently defining requirements for a repository of mobile device characteristics that are relevant to content adaptation.

由于移动设备之间大量各不相同的特点，网站为它们都提供一个可被接受的用户体验是很困难的。例如不同的设备支持不同的标记语言特性，不同的屏幕尺寸需要不同的图片大小。因此，当传输内容给移动设备时为了适应设备特性，修改标记细节，图片的格式，图片大小，色彩深度等等成为问题就很正常了。为了在特殊的设备上增强拥护体验而改变内容就叫做“内容适配”。

我们不会在本文件里详细描述适配的细节。需要更多细节请读者参考《设备独立性原则》[DIP]。

另外，最佳实践工作组的姊妹组，设备描述工作组 (http://www.w3.org/2005/MWI/DDWG/)，目前正在定义移动设备特性资料库的需求，这也关系到内容适配。

3.3 Adaptation Implementation Model 适配执行模型

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.

有不同执行模型用于内容适配。一方面，适配可以非常简单，它们由已确定的设备类型组成，所以可以选择最适当的一套事先准备好的内容以符合设备的特性。另一个极端则可能以完全动态的方式执行，内容在请求时被格式化。不仅要考虑静态的、已确定的属性，例如屏幕尺寸，也要考虑动态属性，例如临时接入的全功能键盘。

Adaptation can be carried out in a number of different points in the delivery of content to the device [DCODI (http://www.w3.org/TR/mobile-bp/#DCODI)]:

适配可以在内容传输到设备的过程中的不同节点执行[DCODI (http://www.w3.org/TR/mobile-bp/#DCODI)]：

Server Side adaptation implies that the content is delivered by the originating content server or application.

“服务器端”适配意味着内容由原始的内容服务器或应用完成。

In-Network adaptation is where the content is altered as it passes through one or more network components. Some network operators, for example, compress images before they are passed over the air to the mobile device.

“网络传输”适配是指内容在经过一个或多个网络组件时被改变。例如某些网络运营商在将数据无线发送到移动设备前会把图片压缩。

Client Side adaptation consists of the device accepting content and displaying it in an appropriate way for its characteristics.

“客户端”适配包括由设备判断接受的内容，并以符合自身特性的方式显示。

Whatever the adaptation model at work, the process of adaptation should not diminish accessibility.

无论使用何种适配模型，适配的处理不应减低可访问性。

3.4 Assumptions about Adaptation 关于适配的假设

In phase 1 (See 1.4.1 Phasing (http://www.w3.org/TR/mobile-bp/#phasing)) 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.

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.

在阶段1（参看 1.4.1 阶段）中，假设了内容适配，如果有的话，都在服务器端执行。未来阶段可以考虑别的地方对内容适配的作用，特别是关于授权第三方执行适配，禁止适配等问题。后期也可能解决多重适配。——也就可能适配可以多次应用。

还假设了有可能创建一个没有使用任何适配就和最佳策略推荐保持一致的网站。然而事实上如果使用了适配，用户体验应该更加完善和增强。

3.5 Establishing Context 建立对象

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.

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.

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 Device Independence Working Group (http://www.w3.org/2001/di/). The companion Techniques [Techniques (http://www.w3.org/TR/mobile-bp/#Techniques)] document describes these methods.

提供用于不同案例时不同的用户体验要求内容提供者了解关于设备特性，使用的浏览器属性和设备网络连接的透明度的重要要点。

拥有优化导航结构的复杂网站，需要这些信息为特定的传输对象呈现不同尺寸的图片或执行其他适配。对于呈现的界面覆盖大范围设备对象的简单网站来说，这种信息的需求相对减少。

有若干种方法能让内容提供者获得传输对象的信息，例如CC/PP，UAPROF，CSS Media 查询，还有设备独立工作组 (http://www.w3.org/2001/di/)输出许多的的方法。[技术]文件描述了这些方法。

3.6 Choice of User Experience 用户体验的选择

In the interests of "One Web" (see 3.1 One Web (http://www.w3.org/TR/mobile-bp/#OneWeb)) 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.

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.

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

由于“One Web” （参见 3.1 One Web）的关系，内容提供者应该允许用户自己设定应用的表现类型，例如移动或者桌面表现。如果表现类型的选择被自动确定，内容提供者应该允许用户覆盖自动设定的选项。当另一种表现的选项可用时，纪录用户首选项以及允许用户改变他的设定不失为一个好的做法。

由于特殊的服务环境，很多传输对象的细节无法提供，以及服务器对发送的信息不能提供检查和行动的能力，内容提供者不太能获得传输对象资料。所以“合理的默认体验”应该被提供。

默认体验的内容由一些因素决定，包括但不限于：提供服务的地理位置和服务的主要目标（例如考虑服务的第一目标是桌面还是移动）。

3.7 Default Delivery Context 默认传输对象

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.

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.

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.

In summary, the purpose of defining the DDC is to support the following rules:

• If an adaptation process (http://www.w3.org/TR/di-gloss/#def-adaptation) is used, then information that is known about the actual Delivery Context should (see 5.1.2 Exploit Device Capabilities (http://www.w3.org/TR/mobile-bp/#lcd)) be used to vary the delivered content to make it more suitable for that specific Delivery Context or to provide an enhanced user experience.
• If the delivered content does not result from an adaptation process (http://www.w3.org/TR/di-gloss/#def-adaptation) - 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.

The Default Delivery Context is defined as follows:

Usable Screen Width

 120 pixels, minimum.

Markup Language Support

 XHTML Basic 1.1 [XHTML-Basic (http://www.w3.org/TR/mobile-bp/#XHTML-Basic)] delivered with content type application/xhtml+xml.

Character Encoding

 UTF-8 [UTF-8 (http://www.w3.org/TR/mobile-bp/#UTF-8)].

Image Format Support

 JPEG.
GIF 89a.

Maximum Total Page Weight

 20 kilobytes.

Colors

 256 Colors, minimum.

Style Sheet Support

 CSS Level 1 [CSS (http://www.w3.org/TR/mobile-bp/#CSS)]. In addition, CSS Level 2 [CSS2 (http://www.w3.org/TR/mobile-bp/#CSS2)] @media rule together with the handheld and all media types (see CSS 2 Media Types (http://www.w3.org/TR/REC-CSS2/media.html)).

HTTP

 HTTP/1.0 [HTTP1.0 (http://www.w3.org/TR/mobile-bp/#HTTP1.0)] or more recent [HTTP1.1 (http://www.w3.org/TR/mobile-bp/#HTTP1.1)].

Script

 No support for client side scripting.

为了让内容提供者共享一个一致的默认的移动体验，最佳策略工作组定义了一个默认传输对象。它让内容提供者在无适配的情况下创建合适的体验以及当有适配时的提供一个基本体验。默认传输对象被最佳策略工作组设定为合理的web体验所必须的最小传输对象规格。它被认为当设备不符合规格时能提供一个合理的其他的非web服务的体验。

默认传输对象也决定于统计背景，文化的经济假设。内容提供者可以提供基于不同的或更低的传输环境规格的服务，但应该尽力提供利用默认传输环境能力的体验以提供尽可能好的体验。

需要强调的是许多设备超越了默认传输对象定义的能力。内容提供者不要仅仅基于默认传输对象开发应用，鼓励内容提供者为这些超越的设备提供增强的体验，也鼓励为现实的设备适配适合其能力的内容。

总结一下，定义默认传输对象的目的是支持以下规则：

• 如果使用了一种适配处理，关于现实的传输对象的信息应该（参阅5.1.2 利用设备能力）被用作改变传输的内容以使它更适合传输对象或提供增强的用户体验。
• 如果传输的内容不能由适配处理计算——例如内容存储于静态HTML文件，或者传输对象的细节不能完全确定，那么传输的内容应该适合默认传输对象以及符合最佳策略规范。

默认传输对象被定义为：

可用屏幕宽度

 最小120像素。

标记语言支持

 XHTML Basic 1.1 [XHTML-Basic] 包括 content type application/xhtml+xml.

字符编码

 UTF-8 [UTF-8]。

图像格式支持

 JPEG。
GIF 89a。

最大页面大小

 20 kilobytes。

色彩

 最少256色。

样式表支持

 CSS Level 1 [CSS]。也支持 CSS Level 2 [CSS2] @media 规则以及 handheld 和 all 媒体类型。（参见 CSS 2 Media Types）。

HTTP

 HTTP/1.0 [HTTP1.0] 或 [HTTP1.1]。

脚本

 不支持客户端脚本。

4 Structure of Best Practice Statements 最佳策略规范的结构

The Heading

The functional area that is addressed by the statements.

The Statements

One or more Best Practice statements, identified in the following way:

    [EXAMPLE] This is a Best Practice statement. 

What it means

An explanation of the significance of the statements under this heading.

How to do it

A discussion of techniques and some suggestions as to how to implement. The BPWG is creating a separate document describing techniques [Techniques (http://www.w3.org/TR/mobile-bp/#Techniques)] in more detail.

What to Test

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.

In this section it is noted whether the statement is Machine Testable (Automated testing is possible) or Human Testable (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.

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 [Techniques (http://www.w3.org/TR/mobile-bp/#Techniques)].

References

Where appropriate, references to related WCAG points and other immediate references from the preceding text.

标题

由陈述指定的功能区。

说明

一个或多个最佳策略陈述，以这样的方式识别：

    [例句] 这是一条最佳策略陈述。

解释

关于这条规范的重要性的解释说明。

怎样做

技术讨论和怎样实现的一些建议。最佳实践工作组正在创建另一份文件在细节上描述一些技术[Techniques]。

怎样测试

有一个外部验证器可以考察评定传输的内容和最佳实践陈述的一致性。本段落不表述有关处理的规范。

在这个段落会标注是用机器测试（可以机器测试）还是人工测试（测试需要人工评估）。某些最佳实践一部分需要机器测试，也就是基于自动测试的结果需要人机交互，这样的陈述测试需要机器测试和人工测试一起完成。

某些最佳实践陈述使用类似“最小的”和“避免”这样的主观不肯定词汇。这是为了给一些未知需求的应用留下空间提供指导 。它也允许在同一个最佳实践框架内的创新和变通。更多的规则建议可以在技术文件 [Techniques]中找到。

参考

之前的内容适用于哪里，有关的WCAG要点和其他类似的资源的参考。

5 Best Practice Statements 最佳实践陈述

The Best Practice statements are grouped under the following headings

• 5.1 Overall Behavior (http://www.w3.org/TR/mobile-bp/#bpgroupgeneral)
• 5.2 Navigation and Links (http://www.w3.org/TR/mobile-bp/#bpgroupnavlinks)
• 5.3 Page Layout and Content (http://www.w3.org/TR/mobile-bp/#bpgroupplayout)
• 5.4 Page Definition (http://www.w3.org/TR/mobile-bp/#bpgrouppdefinition)
• 5.5 User Input (http://www.w3.org/TR/mobile-bp/#bpgroupinput)

最佳策略规范由以下标题组成：

• 5.1 全局行为
• 5.2 导航和链接
• 5.3 页面布局和内容
• 5.4 页面定义
• 5.5 用户输入

5.1 Overall Behavior 全局行为

There are some general principles that underlie delivery to mobile devices.

向移动设备传输内容由以下几个通用规则构成。

5.1.1 Thematic Consistency of Resource Identified by a URI URI标示的资源的主题一致性

[THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.

[主题一致性] 确保当从不同的设备通过一个URI访问时得到的内容能产生一个主题连贯的体验。

5.1.1.1 What it means

This is a realization of the One Web (see 3.1 One Web (http://www.w3.org/TR/mobile-bp/#OneWeb)) 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 [WebArch (http://www.w3.org/TR/mobile-bp/#WebArch)] Section 3.5.1 (http://www.w3.org/TR/webarch/#URI-persistence)).

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.

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.

这是One Web（参阅3.1 One Web）原则的现实表现，内容应该可被访问而无关设备的不同表现能力和接入方法。网站可以用不同的内容分页方式以应对不同的设备特性；因此网站的导航结构，以及它的技术实现，可以基于面对的设备类型改变。 （也请参阅 [WebArch] 章节 3.5.1）

不同类型的设备尽管不能产生完全相同的体验，在一台上生成的书签应该在另一台设备上也可用。如果被加入书签的网页不适用与正在使用的设备，则应该提供一个适用的替代页面。

URI可能被增加后缀以提供session或其他信息。如果一个URI包含了不再正确的session信息，那么用户应该被转向到导航层次中他们设备专用的页面, 以建立专用的session和其他参数。

5.1.2 Exploit Device Capabilities 利用设备性能

[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.

[性能] 利用设备性能提供一个增强的用户体验。

5.1.2.1 What it means 解释

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. Develop sites that target the Default Delivery Context. In addition, where appropriate, use device capabilities to provide a better user experience on more capable devices.

即使鼓励内容提供者了解默认传输对象的需求，以默认传输对象为目标开发网站，并不是非要使其他高性能设备使用降低的体验。相反地，如果适用，利用更强的设备的性能为它们提供更好的用户体验。

5.1.3 Work around Deficient Implementations 不充分的执行能力的工作环境

[DEFICIENCIES] Take reasonable steps to work around deficient implementations.

[缺陷] 采取合理的步骤来解决不充分的执行能力。

5.1.3.1 What it means 解释

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.

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.

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.

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.

和桌面世界一样，浏览器不重视内容提供者的意图。浏览器之间有各不相同的理解，而且执行方式也有缺陷。 所谓缺陷，我们是指相关标准所要求的功能不支持和其他错误的执行。

因为移动设备的软件通常是嵌入在设备中，所以很难去修正或增强它们。在这样一个有这些缺陷和不同的理解的环境中工作是一个挑战。经常有内容提供者会违反特定的最佳实践，用设备错误的执行来实现自己的意图。如果不清楚设备是否有特殊的限制，那么内容提供者应该遵从最佳实践。

所以这不是为了推荐一个最小共通方法，也不是为了推荐避免使用某些设备的错误功能。

也不是为了要求内容提供者限制支持他们支持的设备类型。内容提供者应该以支持尽可能广泛的设备类型为要旨。

5.1.4 Testing 测试

[TESTING] Carry out testing on actual devices as well as emulators.

[测试] 像在模拟器上一样在真实设备上测试。

5.1.4.1 What it means 解释

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.

Content providers should also test with specific features disabled, such as using text-only modes and with scripting disabled.

任何网站都应该在一些浏览器内测试过。移动浏览器特性通常和桌面浏览器有显著的不同。同时，评估一个站点在简约格式显示的适应性，建议内容提供者在真实的设备上测试他们依赖的功能。

内容提供者也应该在特定功能不可用的情况下测试，例如纯文本模式和禁用脚本模式。

5.1.4.2 How to do it 怎样做

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.

许多制造商为他们的设备提供模拟器以提供一个方便的初步测试。然而实际操作中，许多模拟器和它们所模拟的设备的行为并不相同。因此应该在一定范围内的真机和特定软件版本上进行测试。

5.2 Navigation and Links 导航和链接

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.

因为显示屏和输入法的限制，以及移动设备一般缺少指点设备和其他系统设备，应该仔细的定义网站的结构和导航模型。

5.2.1 URIs of Site Entry Points 网站入口URI

[URIs] Keep the URIs of site entry points short.

[URI] 保持访问网站的URI简短。

5.2.1.1 What it means 解释

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.

在移动设备上输入网址会很困难，虽然用户可以用别的方法提取网址，比如点击一个超链接（从email，短信或其他网页）、WAP推入、二维码、RFID或蓝牙。但是输入网址有些情况下是唯一的方式。保持网站入口网址简短有可能减少出错几率并且提供更满意的用户体验。

5.2.1.2 How to do it 怎样做

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.

Example: Instead of requiring users to type

"http://www.example.org/index.html"

allow

"http://example.org"

and instead of

"http://www.example.org/example.html"

allow

"http://example.org/example"

当用户访问网站时不应该被要求在URI里输入文件名部分。。如果可能，配置网站令用户不用输入二级域名就能访问。

例子：如果要求用户输入：

"http://www.example.org/index.html"

允许

"http://example.org"

或将

"http://www.example.org/example.html"

替换成

"http://example.org/example"

5.2.2 Navigation Bar 导航栏

[NAVBAR] Provide only minimal navigation at the top of the page.

[导航栏] 在页面顶部提供一个最小限度的导航。

5.2.2.1 What it means 解释

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 5.3.4 Navigation Bars etc. (Extraneous material) (http://www.w3.org/TR/mobile-bp/#cm)).

在页面顶部提供基本导航。其他必要的二级导航元素可以放置在页面底部。用户在页面载入后不需要滚动就能看到页面主要内容是很重要的（参阅5.3.4 导航栏等 (外部材料)）。

5.2.2.2 How to do it 怎样做

Provide the basic links on a single line.

在一行内提供基本的链接。

5.2.3 Balanced Structure 权衡结构

[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.

[权衡] 在在一个页面加入太多链接和让用户点击许多链接得到想要的内容之间找到一个平衡。

5.2.3.1 What it means 解释

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.

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.

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.

设计应致力于在在一个页面加入大量导航链接与通过多个链接抵达内容之间提供一个平衡。

滚动一个有许多链接的页面非常令人讨厌，在许多移动设备上滚动的动作会依次选中每一个链接。另一方面，每次载入导航页面花去时间，增加费用，所以不应该以增加页面载入支出的方式减少页面上的链接数量。

优化设计你的服务，令到经常被访问的信息能用最少的页面载入次数轻松的到达。不怎么被访问到的信息可以用多次载入导航页面得到结果。一个指南就是用户如果用超过4次的载入页面才能得到目标内容就会有挫折感。怎样做到这一点取决于网站的结构以及菜单元素的组织方式。

5.2.4 Navigation Mechanisms 导航策略

[NAVIGATION] Provide consistent navigation mechanisms.

[导航] 提供一致的导航策略。

5.2.4.1 What it means 解释

Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.

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.

在一个服务中应用同样的导航策略能帮助用户确定自己的位置，并且能让他们更加容易的识别导航策略。

没有指点设备的移动用户不得不用键盘在超链接之中卷动。聪明的分组导航链接，通过习惯模型分析优化，有利于可用性的提高。

5.2.4.2 How to do it 怎样做

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.

At each target of the drill-down navigation an "up" link should be provided to allow the user to jump up an entire section.

一个"钻探"方法，基于每一级主标题，可以经常提供一个有效的导航手段；因为线性的内容布局，小屏幕尺寸和指点设备的缺乏，提供直接跳过内容章节的手段通常很有用。

在每一个跳转导航的目标边，应该提供一个“向上”链接以允许用户跳回原来的章节。

5.2.4.3 References 参考

This relates to WCAG 13.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-clear-nav-mechanism).

关系到 WCAG 13.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-clear-nav-mechanism)。

5.2.5 Access Keys 快捷键

[ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.

[快捷键] 为导航菜单和常用功能链接分配快捷键。

5.2.5.1 What it means 解释

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.

Provide the same access key for links that are repeated across pages such as links to the home page.

当没有指点设备时，为链接指派快捷键可以为用户访问链接提供便捷并且避免重复按导航键聚焦到链接。

为每页都会出现的链接提供统一的快捷键，例如返回首页的链接。

5.2.5.2 What to test 怎样测试

Machine Test: Test for the presence of the accesskey attribute.

Human Test: Verify the presence of the accesskey attribute on links such as the home page.

机器测试：测试 accesskey 属性的表现。

人工测试：验证像返回首页这样的有 accesskey 属性的链接的表现。

5.2.5.3 References 参考

This relates to WCAG 9.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts).

关系到 WCAG 9.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts)。

5.2.6 Link Target Identification 链接目标识别

[LINK_TARGET_ID] Clearly identify the target of each link.

[LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it.

[链接目标识别] 清楚地标示每个链接的目标。

[链接目标格式] 标注链接文件格式，除非你知道设备支持它。

5.2.6.1 What it means 解释

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

Links to content that is in a different format or different language to that of the page the link is on (i.e. content that can only be interpreted by other applications or downloads) should be human signposted, 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.

移动设备用户点击链接得到结果会承受不相称的延迟和费用。所以为了让用户评估链接后的内容是否令他们感兴趣，标明链接的去向很重要。虽然不太可能为一个特定的用户点击的一个特定的链接指定详细的货币成本，但应该可以提供一个让人理解资源大小的方式。（用字节数或用抽象方法，例如链接一个大文件时）。

链接的内容是一种不同的格式或不同的语言时（也就是内容可能只能被其他程序打开或下载），链接所在的网页应该人为标注，这样用户就不会去下载他们设备不支持的内容。尽管这样，请记住一些设备支持在下载之后用其他程序打开这些格式的内容（例如音乐文件），而且，用户可能希望下载不支持的内容供稍候传输到其他设备上打开。所以即使明确内容格式不被用户设备支持，这些内容仍然应该被提供。

5.2.6.2 How to do it 怎样做

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.

For the Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc) all formats other than XHTML, GIF and JPG should be noted.

使用清晰，简明，描述性的链接文字帮助用户决定是否点击一个链接。如果目标特别大，而用户在当前环境下是不期望得到的，标明点击链接后的影响。

在 默认传输对象 中，除了XHTML，GIF和JPG之外的所有格式都应该标注。

5.2.6.3 What to test 怎样测试

Human Test: Check for proper descriptions (e.g. no use of "Click here").

Machine Test: Check for links to non-HTML formats.

Human Test: If present check whether there is information about the format of the target of the link.

人工测试：检查合适的描述（例如不要使用“点击这里”作为链接文字）。

机器测试：检查指向非HTML格式的链接。

人工测试：呈现网页时检查是否有链接目标的格式的信息。

5.2.6.4 References 参考

This relates to WCAG 11.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-content-preferences) and 13.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-meaningful-links).

关系到 WCAG 11.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-content-preferences)和13.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-meaningful-links)。

5.2.7 Image Maps 图片热点

[IMAGE_MAPS] Do not use image maps unless you know the device supports them effectively.

[图片热点] 不要使用图片热点，除非你知道设备有效的支持它。

5.2.7.1 What it means 解释

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.

Many mobile devices lack a pointing device and server-side image maps cannot be used on such devices.

如果请求的设备能够支持图片热点而且有一个在图片热点之间导航的令人满意的方法，图片热点能提供一个快速的导航。即使没有指点设备，在大部分移动设备上上、下、左、右和输入键是可用的。这通常足允许使用客户端图片热点用几何形状作为主区域的导航。

许多移动设备缺乏指点设备，服务器端图片热点不能用在这些设备上。

5.2.7.2 How to do it 怎样做

If only small images can be displayed, break larger images up into smaller sections and deal with them separately.

For the Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc), or if a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.

如果只能显示小图片，把大图片分割成小图片并且分别处理。

在 默认传输对象中，或如果不能显示令人满意的图片热点，使用由描述性文字的链接列表代替它。

5.2.7.3 What to test 怎样测试

IMAGE_MAPS Machine Test: Send a request to the site with a device that does not support client-side image maps and check the map element is not present.

图片热点机器测试：用一台部支持客户端图片热点的设备向服务器发送请求并且为表现的检查map元素。

5.2.7.4 References 参考

This relates to WCAG 1.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-redundant-server-links) and 9.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-client-side-maps).

关系到 WCAG 1.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-redundant-server-links)和9.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-client-side-maps)。

5.2.8 Refreshing, Redirection and Spawned Windows 自动刷新，重定向和派生窗口

[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.

[弹出窗口] 不要触发弹出窗口或切换到其他窗口，不要再未通知用户的情况下改变当前窗口。

[自动刷新] 不要创建周期性自动刷新页面，除非你预先通知过用户，并且提供一个方法停止它。

[重定向] 不要使用标记自动重定向页面，配置服务器通过HTTP 3XX代码执行重定向。

5.2.8.1 What it means 解释

Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction.

Some mobile devices use a separate window for input; this section does not refer to such windows.

Many mobile devices cannot support more than one window and consequently, attempting to open one will have unpredictable results.

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.

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.

以上行为都会造成用户困扰，或增加费用，延缓互动。

某些移动设备使用弹出的窗口用来输入；本节不关系到这样的弹出窗口。

许多移动设备不能支持多于一个的窗口，因此尝试新建窗口可能发生无法预知的后果。

自动刷新页面经常发生可访问性问题。在移动环境中，一直打开着这样的页面或让页面在后台运行会造成用户大量的费用。如果应用要求自动刷新，总是提供停止刷新的手段，总是提示用户即将刷新页面，并可能会造成高额的费用。

尽管重定向是一个普遍使用的技术，但必须记住，重定向通常需要浏览器重复载入，在慢速网络上会增加延迟；所以每页最多使用一个重定向并限制重定向页的数量。

5.2.8.2 What to test 怎样测试

POP_UPS Machine Test: Look for the target attribute on links and if present check to see if it has a value different from _self, _parent or _top.

AUTO_REFRESH Machine Test: Check whether meta http-equiv="refresh" content="<the same URI>" is used.

AUTO_REFRESH Human Test: If auto-refresh is used, check that options are provided to stop any page using auto-refresh.

REDIRECTION Machine Test: Check whether meta http-equiv="refresh" content="<a different URI>" is used.

弹出窗口机器测试：搜寻链接的 target 属性，如果有，则检查是否有不同于 _self，_parent或_top的值。

自动刷新机器测试：检查是否用了 meta http-equiv="refresh" content="<the same URI>"。

自动刷新人工测试：如果有页面使用了自动刷新，检查是否提供了停止刷新的选项。

重定向机器测试：检查是否用了 meta http-equiv="refresh" content="<a different URI>"。

5.2.8.3 References 参考

This relates to WCAG 7.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-periodic-refresh), 7.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-auto-forward) and 10.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-pop-ups).

关系到 WCAG 7.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-periodic-refresh), 7.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-auto-forward)和10.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-pop-ups)。

5.2.9 Externally Linked Resources 外部链接资源

[EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum.

[外部资源] 保持链接外站的资源数目最小。

5.2.9.1 What it means 解释

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.

每个链接资源（图片、样式表和其他对象）需要单独的网络请求。这些在移动环境中会增加相当程度的页面载入时间。

5.2.9.2 How to do it 怎样做

Minimize the number of images on a page and consolidate style information into a single sheet per page (see also 5.4.9 Style Sheets (http://www.w3.org/TR/mobile-bp/#style)).

最小化页面的图片数量，统一样式到单独的样式表中。（参阅 5.4.9 样式表）。

5.2.9.3 What to test 怎样测试

Machine Test: Count the number of linked images, style sheets and other linked items.

Human Test: Review whether a similar effect could be obtained using fewer links.

机器测试: 计算链接图片、样式表和其他链接对象的数量。

人工测试：检查使用更少的链接对象是否能获得同样的效果。

5.3 Page Layout and Content 页面布局和内容

This section refers to the user's perception of the delivered content. It concentrates on design, the language used in its text and the spatial relationship between constituent components. It does not address the technical aspects of how the delivered content is constructed, which is discussed in 5.4 Page Definition (http://www.w3.org/TR/mobile-bp/#bpgrouppdefinition).

本章节关系到传输内容的用户感知。它关注于设计，文字的语言和构成组件的空间关系。并不关系到如何构成内容传输的技术细节，这些在 5.4 页面定义中有讨论。

5.3.1 Page Content 页面内容

[SUITABLE] Ensure that content is suitable for use in a mobile context.

[CLARITY] Use clear and simple language.

[LIMITED] Limit content to what the user has requested.

[适当] 确保内容适于移动环境。

[明了] 使用简洁明了的语言。

[限制] 限制内容，仅提供用户要求的内容。

5.3.1.1 What it means 解释

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. See also discussion under 2.4 User Goals (http://www.w3.org/TR/mobile-bp/#UserGoals) and 3.1 One Web (http://www.w3.org/TR/mobile-bp/#OneWeb).

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.

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 5.3.4 Navigation Bars etc. (Extraneous material) (http://www.w3.org/TR/mobile-bp/#cm) for a discussion of making sure that the subject matter of the page is near the top.

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.

比起浏览，移动环境下的用户更多时间找寻的是特定的信息块。内容提供者应该考虑信息的使用环境以及提供访问所有信息的选项，应该首先提供适应移动环境的信息。参阅 2.4 用户目标 和 3.1 One Web的讨论。

对于移动传输来说，使用明晰的语言明显很重要，简明率直的语言通常比罗嗦的风格更令人满意。

传统新闻式的“前端载入”写作风格可以帮助用户决定信息是否是它们感兴趣的并且允许它们跳过不感兴趣的信息。在页头、段落、列表等的前面放置区分性的信息也能帮助用户在有限的屏幕大小上理解上下文。参阅 5.3.4 导航栏与其他。（外部材料） 。

移动用户通常为流量付费，所以提供和他们所需要不相关的内容，特别是广告，会花费他们的时间和金钱并导致不令人满意的体验。一般来说，在开始下载内容之前应该寻求用户的同意。

5.3.1.2 What to test 怎样测试

Human Test: Examine content to determine if, given the subject matter, it is appropriate in a mobile context.

人工测试：检查内容决定它是否和主题相关，是否适合移动环境。

5.3.1.3 References 参考

This relates to WCAG 13.8 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-front-loading) and 14.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-simple-and-straightforward).

关系到 WCAG 13.8 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-front-loading)和14.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-simple-and-straightforward)。

5.3.2 Page Size 页面大小

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.

[PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.

[页面大小可用] 分割页面大小到可用而受限的部分。

[页面大小限制] 确保页面的全部尺寸适于设备的内存限制。

5.3.2.1 What it means 解释

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.

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.

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.

Some studies [MF (http://www.w3.org/TR/mobile-bp/#MF)] have been carried out in this area to test for user preferences. Some of these indicate that users prefer scrolling to click-throughs and some indicate the contrary. More research is likely to be needed in this area.

如果页面太大就会花太多时间来载入。而且移动设备通常限制了它们所能接受最大的页面。

另一方面，如果页面太短，用户需要发送多次请求才能阅读到相关信息，这样就引起了不必要的延迟，因为每次请求都需要一定时间来完成。

平衡分页和滚动的使用一部分取决于设计风格，一部分又是必须的。有严格内存限制的设备只能为它们传输小页面。同样地，有些设备滚动页面的体验不好，却有很好的页面切换体验。

一些机构 [移动友好 (http://www.w3.org/TR/mobile-bp/#MF)] 已经开展了这方面的研究以测试用户的选择。其中一些研究显示，用户偏向喜欢滚动，另一些研究却相反显示用户喜欢点击链接。所以这方面还需要更多的研究。

5.3.2.2 How to do it 怎样做

For the Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc) assume the limits specified in 3.7 Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc).

对于 默认传输对象 采取的限制定义载 3.7 默认传输对象。

5.3.2.3 What to test 怎样测试

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.

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

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.

页面大小可用机器测试：计算页面标记的总大小；为默认传输对象检查是否不超过10kb。

人工测试：检查页面仍然可用（例如，在章节结束前不会有句子被截断等等）。

页面大小限制机器测试：计算页面标记和图片的总大小；检查是否超过设备允许的大小—默认传输对象为20kb。

5.3.2.4 References 参考

This relates to WCAG 12.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-group-information).

关系到 WCAG 12.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-group-information)。

5.3.3 Scrolling 滚动

[SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.

[滚动] 限定只往一个方向滚动，除非无法避免第二方向的滚动。

5.3.3.1 What it means 解释

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.

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.

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.

为了方便用户了解页面内容，页面应该编排成始终以一个方向（轴）滚动。然而某些内容（比如地图和其他图片）如果没有第二方向的滚动则无法完全显示。

如果页面上的某个元素需要第二方向的滚动，此页面上的其他的元素就不应该引发第二方向的滚动。举个例子，如果一个对象引起了之后有边距的文字在版式上上发生了位移，当用户继续往下看，可能就看不到这些文字。

同样地，如果出现了这样的对象引起文字超越了页面的右边界，用户阅读每一行时就不得不左右卷动。

5.3.3.2 How to do it 怎样做

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.

In the Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc) assume a width of 120 pixels.

如无法避免使用超过屏幕尺寸的图片，考虑在单独的页面显示这张图片，并且提供一个链接返回原来的主要内容。

默认传输对象采用的宽度是120像素。

5.3.3.3 What to test 怎样测试

SCROLLING Machine Test: Check for width attributes and width style properties wider than the screen size - for the Default Delivery Context, 120 pixels.

Human Test: If it is wider than the screen size, check that the use case warrants it (e.g. maps).

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.

滚动机器测试：检查大于屏幕尺寸的 width 属性和宽度样式属性。对于默认传输对象，屏幕宽度为120像素。

人工测试：如果宽度大于屏幕尺寸，检查它使用的目的（例如地图）。

用一台移动设备浏览网站，观察包含需要第二滚动的页面，确认只有那些需要的元素引起了第二滚动，页面上的其他元素只需要祝滚动方向。

5.3.4 Navigation Bars etc. (Extraneous material) 导航栏等等（外部资料）

[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.

[核心思想] 确保符合页面核心思想的内容和素材优先于不符合的内容。

5.3.4.1 What it means 解释

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.

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.

See also 5.3.1 Page Content (http://www.w3.org/TR/mobile-bp/#cl) for a discussion of how writing style can help the user identify meaning.

许多页面设计的顶部或侧边栏都包含导航栏和其他元素（例如主菜单栏，你的位置和搜索功能）。这种方式在大屏幕上有便利性和众所周知的导航暗示。但是在小屏幕上第一次加载这样的页面时，导航可能会出现在主要内容应该显示的位置上。

因为让用户初步获得网页的大致内容很重要，页面头部包含的额外的元素的数量应该最小化—包括导航，装饰性的图片，广告和其他资料等不是用户阅读的中心的内容。用户不应该滚动太多才找到页面的主要内容。

参阅 5.3.1 页面内容 讨论怎样编写样式帮助用户识别核心思想。

5.3.4.2 How to do it 怎样做

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.

菜单可以不放在页面顶部，用一个锚链接来代替。或者在页面顶部使用简短的文字链接作为页面的导航指向网站的主要分类。

5.3.4.3 What to test 怎样测试

Human test: Browse URIs within a site with a mobile device and observe that the most important/relevant information is conveyed first.

人工测试：用移动设备浏览网站，观察最重要的信息是否首先被传输。

5.3.4.4 References 参考

This relates to WCAG 13.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-nav-bar).

关系到 WCAG 13.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-nav-bar)。

5.3.5 Graphics 图形

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing.

[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.

[图形分隔符] 不要使用图形分隔。

[大图形] 不要使用设备无法渲染的图片，不要使用大尺寸或高分辨率图片除非图片表示的重要信息被丢失。

5.3.5.1 What it means 解释

The popular mechanism of using a 1 pixel graphic for absolute positioning does not work on a variety of screens.

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.

使用一像素图形精确定位的流行做法不适用于多变的屏幕尺寸。

不必要的大图形浪费带宽，像那些超过设备屏幕显示能力的高分辨率或高彩图形。

5.3.5.2 What to test 怎样测试

GRAPHICS_FOR_SPACING Machine Test: Check for very small and/or transparent graphics.

LARGE_GRAPHICS Machine Test: Check dimensions of graphics.

图形分隔符机器测试：检查极小和/或透明图形。

大图形机器测试：检查图形尺寸。

5.3.6 Color 色彩

[USE_OF_COLOR] Ensure that information conveyed with color is also available without color.

[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast.

[色彩使用] 确保在没有色彩表现时信息也能有效转达。

[色彩对比度] 确保前景色和背景色之间有足够的对比度。

5.3.6.1 What it means 解释

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.

移动设备通常没有很好的颜色对比度，而且经常在不太理想的光照环境下使用。因此使用色彩突出显示的信息可能用户很难看清。如果用色彩来表示一种功能，那么这种功能在不依赖色彩时也能通过另一种方式表示。特别是不要使用蓝色或紫色文字，因为这可能和超链接混淆，特别是那些不会为链接加下划线的设备。

5.3.6.2 What to test 怎样测试

USE_OF_COLOR Human Test: Browse the page in a monochrome environment.

COLOR_CONTRAST Human Test: Browse the page under a strong light parallel to the screen.

Machine Test: There are automatic tools to test color contrast.

色彩使用人工测试：在单色环境下浏览页面。

色彩对比度人工测试：在强光直射条件下浏览页面。

机器测试：有一些自动工具可以测试颜色对比度。

5.3.6.3 References 参考

This relates to WCAG 2.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-convey) and 2.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-contrast).

关系到 WCAG 2.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-convey) 和 2.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-color-contrast)。

5.3.7 Background Images 背景图片

[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device.

[背景图片可读性] 当使用背景图片时确认内容在设备上仍然可读。

5.3.7.1 What it means 解释

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.

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.

图片的胡乱使用会导致内容阅读困难，特别是对有限对比度的移动设备和经常使用移动设备的恶劣的阅读环境下。

在使用背景图片之前，仔细考虑你使用背景的动机并尝试使用另一种方法完成你的目的。如果必须要使用背景图片，确保无论有背景图片和当设备不支持而没有背景图片显示时，内容都可读。

5.3.7.2 What to test 怎样测试

Machine Test: Test for the presence of a background image.

Human Test: Test readability both on devices that support them and devices that do not.

机器测试：测试背景图片的显示能力。

人工测试：测试支持和不支持背景图片的设备上内容的可读性。

5.4 Page Definition 页面定义

5.4.1 Title 标题

[PAGE_TITLE] Provide a short but descriptive page title.

[页面标题] 提供一个短小、描述性的标题。

5.4.1.1 What it means 解释

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.

Many mobile browsers do not display the title of a page. Where the title is displayed the available space may be limited.

The device 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.

提供一个描述性的标题方便轻松识别。保持标题简短可以减少页面数据量，并且不会被屏幕截断。

许多移动浏览器不会显示页面标题。或者标题的可显示位置有限。

设备可能会用页面标题作为书签的标签。同样，标签的显示位置可能有限，所以使用描述性的标题以方便识别书签的内容而不要用于别的目的。

5.4.1.2 What to test 怎样测试

Machine Test: Test for presence of the title element.

Human Test: Test that the title is descriptive of content.

机器测试：测试 title 元素的表现。

人工测试：测试标题属于内容的描述。

5.4.2 Frames 框架

[NO_FRAMES] Do not use frames.

[无框架] 不要使用框架。

5.4.2.1 What it means 解释

Many mobile devices do not support frames. In addition, frames are recognized as being generally problematic.

许多移动设备不支持框架。另外，框架的识别已是一个普遍的问题。

5.4.2.2 What to test 怎样测试

Machine Test: Test for presence of frame related elements - check for frameset and iframe elements.

机器测试：测试框架元素的表现—检查 frameset 和 iframe 元素。

5.4.2.3 References 参考

See http://www.w3.org/TR/xframes/#s_intro (http://www.w3.org/TR/xframes/#s_intro) for a discussion of problems with frames.

参阅 http://www.w3.org/TR/xframes/#s_intro (http://www.w3.org/TR/xframes/#s_intro) 中关于框架问题的讨论。

5.4.3 Structural Elements 结构元素

[STRUCTURE] Use features of the markup language to indicate logical document structure.

[结构] 使用标记语言的特性表示文档的逻辑结构。

5.4.3.1 What it means 解释

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.

Where headings are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.

Structural markup must not be used solely to create a font effect (see also 5.4.3 Structural Elements (http://www.w3.org/TR/mobile-bp/#sm)).

这是一个对所有文档都有用的好实践，除了那些简单的使用标题和子标题表示结构的简单文档。使用结构标记而不是格式效果标记，可以更容易做到需要分页显示内容的适配，以及令用户能快速访问到感兴趣的文章章节。

当使用标题时，它们应该符合标准，也即他们应该基于自己的层级正确地相互嵌套。

结构标记不能仅仅用做创建字体效果。

5.4.3.2 How to do it 怎样做

Markup languages like HMTL contain many constructs to indicate structure.

像HTML等的标记语言包含许多元素表示结构。

5.4.4 Tables 表格

[TABLES_SUPPORT] Do not use tables unless the device is known to support them.

[TABLES_NESTED] Do not use nested tables.

[TABLES_LAYOUT] Do not use tables for layout.

[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.

[表格支持] 不要使用表格，除非知道设备支持。

[表格嵌套] 不要使用嵌套表格。

[表格排版] 不要使用表格排版。

[表格替换] 如果可能，使用其他方法表现表格。

5.4.4.1 What it means 解释

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.

在尺寸有限的屏幕上表格工作的不好，可能引起用户不得不左右滚动才能阅读。将导航链接放入表格可能令用户不得不水平和垂直滚动才能看到合适的导航选项。

5.4.4.2 What to test 怎样测试

TABLES_SUPPORT Machine Test: Send a request to the site with a device that does not support tables and check the table element is not present.

Machine Test: Check that there are no nested tables.

TABLES_LAYOUT Machine Test: Check that no column or row in a table is empty or contains only a 1x1 transparent GIF.

Machine Test: If there is a table 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.

表格支持机器测试：用不支持表格的设备访问网站检查 table 元素不被显示。

机器测试：检查确认没有表格嵌套。

表格排版机器测试：检查表格内没有空行和空列或单元格没有只包含一个1x1透明GIF。

机器测试：如果有 table 元素，检查在它之外是否有内容被渲染。如果没有则差不多表示表格被用作排版。

5.4.4.3 References 参考

This relates to WCAG 5.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-headers), 5.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-structure), 5.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-table-for-layout), 5.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-summaries) and 5.6 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-abbreviate-labels).

关系到WCAG 5.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-headers), 5.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-structure), 5.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-table-for-layout), 5.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-table-summaries)和5.6 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-abbreviate-labels)。

5.4.5 Non-Text Items 非文本项目

[NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.

[非文本替换] 为所有的非文本元素提供等义的文本。

[对象或脚本] 不要依赖嵌入对象和脚本。

5.4.5.1 What it means 解释

A non-text item is defined by Non-text content (http://www.w3.org/WAI/GL/Glossary/printable.html#def-non-text-content) in the WAI Glossary [WAIGlossary (http://www.w3.org/TR/mobile-bp/#WAIGlossary)].

Downloading images to a mobiledevice adds to the time to display an image and the cost of displaying the page. Making the page readable in text-only mode can help the user assess its usefulness before images arrive.

Many mobile devices 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.

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.

非文本项是由WAI语汇[WAIGlossary (http://www.w3.org/TR/mobile-bp/#WAIGlossary)]的非文本内容 (http://www.w3.org/WAI/GL/Glossary/printable.html#def-non-text-content)定义的。

下载图片到移动设备增加显示图片的时间和费用。保持页面在纯文本模式下可读可以帮助用户评估图片下载前的它用处。

许多移动设备不支持嵌入对象或脚本，而且许多情况下不可能让用户安装支持插件。内容应该基于此设计。

即使有设备支持脚本，也不要使用它除非没有其他的方法完成你的目的。脚本会增加电力消耗，缩短电池使用时间。

5.4.5.2 How to do it 怎样做

Design pages so that they are useful when rendered as text-only. See also 5.1.4 Testing (http://www.w3.org/TR/mobile-bp/#test).

Always use features of the markup designed to support alternate rendering such as the longdesc and alt attributes in XHTML.

Use only features from the markup that are known to be supported by the device in question.

Avoid things like CSS image replacement and pictures of words.

If scripting is used, do not use onmouse and onkey triggers, use onclick.

设计页面时保证在纯文本渲染时也可用。参阅5.1.4 测试。

总是使用标记特性设计以支持替代渲染，例如XHTML中的 longdesc 和 alt 属性。

仅使用设备支持的标记特性。

避免使用类似CSS图片切换和用图片表示的文字内容。

如果使用了脚本，不要使用onmouse和onkey触发器，使用onclick。

5.4.5.3 What to test 怎样测试

NON-TEXT_ALTERNATIVES Machine Test: Test for presence of alt attribute on images and text content on objects.

Human Test: Check the relevance of the meaning of the content of alt attributes.

OBJECTS_OR_SCRIPT Machine Test: Test for the presence of object or script elements in content delivered to a device that does not support them and if present carry out the Human Test below.

Human Test: If present, test that the user experience is acceptable.

非文本替换机器测试：测试图片alt属性和对象内的文字内容。

人工测试：检查alt属性内容使用恰当的含义。

对象或脚本机器测试：测试传输到不支持的设备的内容中object或script元素的表现，如果显示，采用下面的人工测试。

人工测试：如果显示，测试用户体验可被接受。

5.4.5.4 References 参考

This relates to WCAG 1.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-text-equivalent), 3.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-use-markup), 6.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-dynamic-source), 6.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts), 6.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-fallback-page) and 9.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts).

关系到WCAG 1.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-text-equivalent), 3.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-use-markup), 6.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-dynamic-source), 6.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts), 6.5 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-fallback-page)和9.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts)。

5.4.6 Image Size 图片尺寸

[IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they have an intrinsic size.

[IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size.

[图片指定尺寸] 如果图片有原生的尺寸，在标记里指定它。

[图片缩放] 如果图片有原生的尺寸，在服务器端缩放。

5.4.6.1 What it means 解释

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 device has to carry out to scale the image.

Note that this recommendation contrasts with 5.4.8 Measures (http://www.w3.org/TR/mobile-bp/#me), which recommends using relative measures where possible.

位图一类的图片有原始尺寸。建议将图片的尺寸告诉浏览器以免它在接收到图片数据时不得不重新流动文字。在服务器端缩放（通常是缩小）图片降低数据传输传输量，而且也能减少设备缩放图片消耗的机能。

本条推荐注意和推荐尽可能使用相对单位的章节 5.4.8度量 对照。

5.4.6.2 What to test 怎样测试

IMAGES_SPECIFY_SIZE Machine Test: Test for presence of width and height attributes on img elements.

IMAGES_RESIZING Machine Test: Check width and height attributes are equal to image dimensions.

图片指定尺寸机器测试：测试img元素的width和height属性的表现。

图片缩放机器测试：检查width和height属性等于图片的尺寸。

5.4.7 Valid Markup 验证标记

[VALID_MARKUP] Create documents that validate to published formal grammars.

[验证标记] 用符合标准的标记创建文档。

5.4.7.1 What it means 解释

If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.

如果页面标记无效，会导致无法预知的错误并有可能导致表现不完全。

5.4.7.2 What to test 怎样测试

Machine Test: Validate documents.

机器测试：验证标记。

5.4.7.3 References 参考

This relates to WCAG 3.2 (http://www.w3.org/TR/WAI-WEBCONTENT/#tech-identify-grammar), 11.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-latest-w3c-specs) and 11.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-deprecated).

See http://www.w3.org/QA/Tools/#validators (http://www.w3.org/QA/Tools/#validators).

关系到WCAG 3.2 (http://www.w3.org/TR/WAI-WEBCONTENT/#tech-identify-grammar), 11.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-latest-w3c-specs)和11.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-deprecated)。

参阅http://www.w3.org/QA/Tools/#validators (http://www.w3.org/QA/Tools/#validators)。

5.4.8 Measures 度量

[MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.

[度量] 不要在标记语言和样式表属性值内使用像素单位和其他绝对单位。

5.4.8.1 What it means 解释

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 5.4.6 Image Size (http://www.w3.org/TR/mobile-bp/#ImageSize)). 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.

避免像素和绝对值度量可以让浏览器调整内容适于显示。一个例外的规则就是在图片定义尺寸时（参阅5.4.6 图片尺寸）。在关系到图片尺寸的时候应该在标记中用像素单位指定确切的尺寸，这是为了帮助浏览器编排页面并且避免在接收完页面之后文字的重新流动。当设计师用像素单位精确定义边距，边框等属性时，设备可能可以正确执行。

5.4.8.2 How to do it 怎样做

Use percentage and relative measures such as em, ex, bolder, larger and thick.

使用百分比和相对单位例如em，ex，bolder，larger和thick。

5.4.8.3 What to test 怎样测试

Machine Test: Send a request to the site with a device that supports relative measures correctly and check the values of font-size are not absolute or pixels.

机器测试：使用正确支持相对单位的设备访问网站并检查font-size属性没有使用绝对单位或像素单位。

5.4.9 Style Sheets 样式表

[STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.

[STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets.

[STYLE_SHEETS_SIZE] Keep style sheets small.

[样式表使用] 使用样式表控制版式和表现，除非知道设备不支持。

[样式表支持] 组织好文档，令它在没有样式表支持时仍可读。

[样式表尺寸] 保持样式表精简。

5.4.9.1 What it means 解释

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.

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 style element; some implementations do not support more than one style sheet and some do not support style sheets at all.

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.

样式信息可以包含在外部连接样式表文件或HTML内部，也可以包含在样式元素中或是标记元素的样式属性中。

移动设备对样式表有不同的支持。一些提供完整的支持，包括外部样式表缓存；另一些不缓存外部样式表；还有一些不支持style元素；甚至还有设备不支持多余一个样式表；当然还有的设备根本不支持样式表。

当样式表关闭或不被支持时，内容会按文档顺序渲染，所以内容在按文档顺序阅读时能表达清楚意思很重要。

5.4.9.2 How to do it 怎样做

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 5.2.9 Externally Linked Resources (http://www.w3.org/TR/mobile-bp/#el)); if the device supports the style element, use it; otherwise use an external style sheet.

Optimize style information so that only styles that are used are included.

When creating style sheets, take advantage of the CSS media types (these may be used both in the CSS @media rule and in the media attribute of the link 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

最好的方法是页面共享样式信息，但如果设备不支持样式表缓存，这种方法会导致下载每个页面时都要传输样式表。因此，为了设备偏好：如果设备缓存样式表，把样式信息放在一个单独的外部样式表中（参阅 5.2.9 外部链接资源）；如果设备支持style元素，就使用它；否则使用外部样式表。

优化样式信息，另只包含使用到的样式。

创建样式表时，利用CSS媒体类型（可以使用在CSS @media 规则和 link 元素的 media 属性中）定义样式应用在手持设备渲染中。可以使用的CSS媒体类型是“handeheld”和“all”。如果手持设备渲染未定义，浏览器可能会去下载其他用于非手持设备的样式表。

5.4.9.3 What to test 怎样测试

STYLE_SHEETS_USE Machine Test: Send a request to the site with a device that supports CSS and check that style sheets are used and that the page does not use formatting tags (e.g. font).

STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and check that the page is still readable.

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.

样式表使用机器测试：用支持CSS的设备访问网站，并且检查样式表已被使用并没有使用格式标签（例如font）。

样式表支持人工测试：关闭样式表检查页面仍然可读。

样式表尺寸机器测试：检查样式表的元素在相关页面中至少使用了一次。

5.4.9.4 References 参考

This relates to WCAG 3.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-style-sheets) and 6.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-order-style-sheets).

关系到WCAG 3.3 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-style-sheets)和6.1 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-order-style-sheets)。

5.4.10 Minimize 最小化

[MINIMIZE] Use terse, efficient markup.

[最小化] 使用简洁的有效的标记。

5.4.10.1 What it means 解释

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

Marking fonts, colors and other stylistic effects in-line can cause considerably larger page sizes when compared with using logical markup, and use of the HTML class attribute for application of style (see also 5.4.9 Style Sheets (http://www.w3.org/TR/mobile-bp/#style)).

使用类XML的语言标记内容仅仅通过移除多余的空白（也就是空格和换行）往往就可以变得更小并保持相同的语义。

相比使用逻辑标记和 class 属性应用样式，内联字体，颜色和其他样式效果会显著增大页面大小（参阅 5.4.9 样式表）。

5.4.10.2 How to do it 怎样做

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.

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.

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.

Use of structural markup (see 5.4.3 Structural Elements (http://www.w3.org/TR/mobile-bp/#sm)) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS [CSS (http://www.w3.org/TR/mobile-bp/#CSS)].

并不是有意鼓励设计师用将内容写作一行的方法删除空白，而是建议设计师不要在不必要的空白上白白消耗页面大小。注意“漂亮的代码格式”（用制表符缩进标记的方法）会产生大量空白并因此增加页面大小。

如果“漂亮的代码格式”在设计过程中是非常重要的部分，那么在上传时尽量移除多余的空白。

尽管某些网络代理会自动删除空白，但并不是所有的都这么做，所以不要依赖这个行为。

结构标记（参阅 5.4.3 结构元素）的样式描述集中在CSS的使用能最小化页面的大小。

5.4.10.3 What to test 怎样测试

Machine Test: Count the number of non-significant white space characters in the document.

机器测试：计算文档中非空白字符的数量。

5.4.11 Content Types Content Type（不翻）

[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.

[CONTENT_FORMAT_PREFERRED] Where possible, send content in a preferred format.

[内容格式支持] 内容以设备支持的格式发送。

[内容格式首选] 如果可能，内容以设备首选支持的格式发送。

5.4.11.1 What it means 解释

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 device's preference, as it may have a fuller implementation of those formats.

传输设备不能显示的内容浪费用户的时间和金钱。设备都有格式的偏好。所以遵循设备的选择是不错的策略，因为设备会完整的执行这个格式。

5.4.11.2 How to do it 怎样做

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.

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:

• • Some devices do not supply accept headers;
  • Some devices mis-state their capabilities;
  • Some operator gateways supplement the accept headers to include formats that they adapt;
  • User agent headers do not always uniquely identify the device;
  • UAProf information may not be available or may be incomplete.

为了判断设备支持何种格式，网站可以使用设备属性信息的组合，例如HTTP用户代理头信息，HTTP Accept头信息和UAProf。

如果只选择一项设备属性信息而排除其他，判断可能会发生错误。以下列出一些问题：

• • 某些设备不支持accept头信息；
  • 某些设备错误的声明了自己的能力；
  • 某些运营商网关在accept头信息中追加了它们适配的格式；
  • 用户代理头信息不是总是设备的唯一身份识别；
  • UAProf信息可能不可用或不完整。

5.4.11.3 What to test 怎样测试

CONTENT_FORMAT_SUPPORT Machine Test: Check MIME types of content with various devices.

CONTENT_FORMAT_PREFERRED Machine Test: Check MIME types of content with various devices and check that the preferred format is sent or that the format is compatible with the Default Delivery Context.

内容格式支持机器测试：用不同设备检查内容的MIME类型。

内容格式首选机器测试：用不同设备检查内容的MIME类型，并检查内容是以最佳格式发送的，或内容格式和默认传输对象兼容。

5.4.12 Character Encoding 字符编码

[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.

[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used.

[字符编码支持] 确保使用设备支持的字符编码编码内容。

[字符编码使用] 在应答里标明使用的字符编码。

5.4.12.1 What it means 解释

As in the previous section, content should not be sent to a device if it can not use it.

如上节所述，不应该发送设备不能使用的格式的内容。

5.4.12.2 How to do it 怎样做

The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header.

The character encoding being used in a response may be indicated using the HTTP Content-Type header.

Example:
Content-Type: text/html; charset=utf-8

Additionally for XML [XML (http://www.w3.org/TR/mobile-bp/#XML)] 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.

Example:
<?xml version="1.0" encoding="UTF-8"?>

Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1 (http://www.w3.org/TR/mobile-bp/#CHARSET1)] and [CHARSET2 (http://www.w3.org/TR/mobile-bp/#CHARSET2)].

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

Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8.

设备支持的字符编码可以从设备属性资料或检查HTTP Accept-Charset头信息中获得。

应该用HTTP Content-Type头信息指定应答用的字符编码。

  Content-Type: text/html; charset=utf-8

另外对于XML文档应该在编码声明中指定，虽然通常会被HTTP Content-Type头信息覆盖。

  <?xml version="1.0" encoding="UTF-8"?>

将内容编码成需要的字符编码依赖于使用的设计工具，Web服务器配置和使用的服务器端脚本技术（如果有的话）。

当使用多语言表述内容时，Unicode是一个不错选择。传输所需的带宽很大程度上取决于使用的字符编码。主要由拉丁字母组成的文本用UTF-8编码更有效率，而主要由象形文字组成的文本用UTF-16编码更有效率。当选择字符编码时，考虑可用编码的效率。

由于默认传输对象只是用UTF-8 ，所以所有的应用应支持UTF-8 。

5.4.12.3 What to test 怎样测试

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.

机器测试：检查编码使用支持的方式声明。Content type应该通过至少一种以下的方法声明：Content-Type HTTP头信息，XML内容的XML声明，CSS的CSS @charset 规则，HTTP内容的Content-Type Meta元素。

5.4.12.4 References 参考

See [XML (http://www.w3.org/TR/mobile-bp/#XML)] Character Encoding in Entities (http://www.w3.org/TR/2004/REC-xml-20040204/#charencoding) for a discussion of character encoding in XML documents.

参阅 字符编码 (http://www.w3.org/TR/2004/REC-xml-20040204/#charencoding) 关于XML文档字符编码的讨论。

5.4.13 Error Messages 错误消息

[ERROR_MESSAGES] Provide informative error messages and a means of navigating away from an error message back to useful information.

[错误消息] 提供有价值的错误消息，同时提供一个导航方法离开错误信息到有效的页面。

5.4.13.1 What it means 解释

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.

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.

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.

无法避免的是，移动用户有时会无法成功地访问到想要的内容或信息。移动场合下，提供一个方便的导航离开错误页通常是很重要的，因为浏览器一般没有一个容易找到的“后退”按钮。让用户重新输入URI离开错误尤其困难。

内容提供者无法控制网络，链接和URI输入等错误，这些错误也无法说明给用户。但是如果是在内容提供者控制范围内的错误，应该用明确的信息提示用户他们所经历的故障。这样就能帮助他们明白到底是这个故障是临时的还是永久的，他们是否应该重试以及究竟是那里出了问题。

也应该帮助用户离开错误状态。他们应该回到错误之前的页面，或可以进到服务的下一步留待以后重试，或提供另一个方式处理他们尝试的请求的页面。

5.4.13.2 How to do it 怎样做

It is noted that many Web servers provide a default error page, especially in the event of a request for a non-existent page (404) or an internal error (500). Where possible (see [TOMCAT (http://www.w3.org/TR/mobile-bp/#TOMCAT)], [APACHE (http://www.w3.org/TR/mobile-bp/#APACHE)] and [IIS (http://www.w3.org/TR/mobile-bp/#IIS)]), applications should trap all error conditions by overriding the default pages if necessary, and handle them in a user-friendly, and graceful, way.

Error messages should be provided in the same language as the application that was being used. They should be clear and concise, adhering to the same Best Practices as the rest of the application. They should be provided in a format that the device can handle.

The error message should detail whether the issue is likely to be temporary or permanent, whether the user may be able to solve the issue themselves (for example, by changing input data or a handset setting), or whether it is an issue that can be escalated to the content provider or network operator. In the latter case, contact details, such as an SMS address or a support line number, might be appropriate.

The error message should provide one or more of the following navigational constructs:

• A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);
• A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");
• A "home" link to allow the user to return to the main part of the application.

The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.

许多Web服务器提供默认的错误页，特别是请求不存在的页面事件（404）或内部错误（500）。如果必要，应用应该用一个用户友好的，优雅的方法覆盖处理所有的错误。

错误消息应使用应用相同的语言。表达简洁清楚。它们应该用设备可以处理的格式提供。

错误消息应详细列出问题是临时的还是永久的，用户是否应该自己解决问题（举个例子，改变输入数据或调整手机设置），或者个问题是否关系到内容提供者或网络运营商。之后，也适合提供联系细节比如SMS地址或一个支持电话号码。

错误消息应该提供以下至少一种导航结构：

• 一个“后退”链接返回到上一页（尤其是为那些很难找到后退按钮的设备）；
• 一个“重试”链接尝试重新处理相关的部分（注意这部等同与“刷新”）；
• 一个“首页”链接让用户返回应用的主要页面。

错误消息可以提供一个错误代码供诊断。但是错误代码不能取代供人阅读的消息。尽管部分用户明白“404”代表“找不到页面”，也不能假设全部用户都明白。

5.4.13.3 What to test 怎样测试

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.

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.

输入一个网站不存在的URI，检查返回的HTTP 404错误页面适用于请求的设备。

人工测试：检查返回的页面包含错误的解释和合适的更正操作，对最终用户没有任何技术术语。

5.4.14 Cookies Cookie（不翻）

[COOKIES] Do not rely on cookies being available.

[Cookie] 不要依赖Cookie可用。

5.4.14.1 What it means 解释

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.

Cookie通常用来执行会话管理，识别用户和存储用户偏好设置。许多移动设备不支持或不完全支持cookie。另外，某些网关会剥离cookie和其他类cookie。

5.4.14.2 How to do it 怎样做

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.

测试cookie被设备正确支持。如果它们不支持，使用URI参数存储会话管理，注意不要超过设备支持URI字串的最大长度。某些网关不使用cookie识别用户。

5.4.14.3 What to test 怎样测试

Machine Test: Check that an alternative to cookies is used for session management when they are not available.

机器测试：在cookie不可用的情况下检查会话管理的替代方法。

5.4.15 Cache Headers 缓存头信息

[CACHING] Provide caching information in HTTP responses.

[缓存] 在HTTP应答里提供缓存信息。

5.4.15.1 What it means 解释

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. Devices and network caches are both affected by caching information.

有限的带宽和高延迟会降低移动设备上网站的可用性。使用缓存信息能有效地减少重载入的数据，比如样式表，图片和网页，从而改进表现和降低使用花费。它也能防止重复使用不适用的内容，例如适合一个设备的内容不应该在不同的设备上被使用。设备和网络缓存都受缓存信息影响。

5.4.15.2 How to do it 怎样做

Set expiry times in a way that is appropriate to your application. Consider using Cache-Control: public to allow sharing of pages between devices, Cache-Control: private to allow re-use but only by the requesting device and Cache-Control: nocache to prevent caching.

The HTTP 1.1 specification [HTTP1.1 (http://www.w3.org/TR/mobile-bp/#HTTP1.1)] and Techniques document [Techniques (http://www.w3.org/TR/mobile-bp/#Techniques)] contain discussions of caching.

为你的应用设置合适的有效时间。考虑使用Cache-Control: Public允许设备间共享，Cache-Control: private只允许本设备重复使用内容，Cache-Control: nocache禁止缓存。

HTTP 1.1规范和技术文档包含了关于缓存的讨论。

5.4.15.3 What to test 怎样测试

Machine Test: Check for the presence of cache headers on the HTTP response.

机器测试：检查HTTP应答中的缓存头信息的表现。

5.4.15.4 References 参考

Section 13 Caching in HTTP (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html) of [HTTP1.1 (http://www.w3.org/TR/mobile-bp/#HTTP1.1)] discusses caching.

HTTP1.1章节13HTTP中的缓存 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html)中有讨论。

5.4.16 Fonts 字体

[FONTS] Do not rely on support of font related styling.

[字体] 不要依赖字体样式。

5.4.16.1 What it means 解释

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 5.4.3 Structural Elements (http://www.w3.org/TR/mobile-bp/#sm).

移动设备通常只有很少字体，并对字体大小和效果（粗体，斜体等）支持有限。所以字体大小，字形或效果的使用可能无法按想象中的完成。参阅 5.4.3 结构元素。

5.4.16.2 How to do it 怎样做

For the Default Delivery Context (http://www.w3.org/TR/mobile-bp/#ddc) do not use font related styling.

不要为默认传输对象设置字体相关样式。

5.4.16.3 What to test 怎样测试

Machine Test: Check for the presence of font related styling in an environment that does not support it.

Human Test: If present, ensure that the author's intentions remain clear.

机器测试：检查字体相关样式在不支持的环境下的表现。

人工测试：如果可以呈现，确保作者的原意仍然清楚。

5.5 User Input 用户输入

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.

本章节包含用户输入的规范。移动设备上的用户输入典型地比桌面电脑更受限制。例如：移动设备缺少指点设备而且没有标准键盘供文字输入。

5.5.1 Input 输入

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.

[AVOID_FREE_TEXT] Avoid free text entry where possible.

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible.

[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it.

[最少击键] 保持按键次数最少。

[避免自由文本] 如果可能，避免自由文本输入。

[提供默认] 如果可能，提供预选好的默认值。

[默认输入法] 提供默认输入法、语言或输入格式，如果设备支持的话。

5.5.1.1 What it means 解释

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.

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 [XHTML-Basic (http://www.w3.org/TR/mobile-bp/#XHTML-Basic)] will support this functionality in the future.

由于移动设备的限制，界面应尽可能最小化用户输入。如果可能，使用选择列表，单选按钮和其他不需要输入的控件。

某些标记语言允许定义输入法，特别适用于用户输入受限的情况，例如限定只允许数字输入。XHTML-Basic 计划未来支持它。

5.5.1.2 How to do it 怎样做

There are a number of techniques available for this, including:

• Where possible use previous entries as defaults.
• Make it possible to select items using navigation keys and/or numeric input.

有一些技术可以做到，包括：

• 在可能的情况下使用之前的内容作为默认值。
• 尽可能使人们使用导航键选择项目和／或数字输入。

5.5.1.3 What to test 怎样测试

AVOID_FREE_TEXT Machine Test: Check whether input type="text" and textarea are used.

Human Test: If one of them is used, check whether it can be replaced by a pre-determined entry.

PROVIDE_DEFAULTS Machine Test: Check if there is a pre-selected value in controls (selected or checked attribute set).

Human Test: If not, check if there could be sensible pre-selection in the context (e.g. most common choice).

DEFAULT_INPUT_MODE Machine Test: Send a request with a device known to support the inputmode attribute and if the response is in a language that supports this attribute, check that it is present on input type="text" and textarea elements.

避免自由文本机器测试：检查是否使用了input type="text"和textarea

人工测试：如果有使用它们之一，检查它们是否可以替换成代替用户决定的内容。

提供默认机器测试：检查表单中是否有预选定项目（使用了selected或checked属性）。

人工测试：如果没有，检查在此环境下是否可以预知用户选择（例如最常用的选择）。

默认输入法机器测试：用支持inputmode属性的设备访问并且应答使用了这个属性的语言，检查input type="text"和textarea元素的表现。

5.5.1.4 References 参考

This relates to WCAG 10.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-place-holders).

关系到WCAG 10.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-place-holders)。

5.5.2 Tab Order TAB顺序

[TAB_ORDER] Create a logical order through links, form controls and objects.

[TAB顺序] 创建链接、表单和对象的逻辑顺序。

5.5.2.1 What it means 解释

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.

为用户浏览的网页的不同区域和对象用逻辑顺序呈现很重要，特别是许多区域或对象不能和焦点项目同时可见时。

5.5.2.2 How to do it 怎样做

Use document order to control layout and tab order.

使用文档顺序控制布局和tab顺序。

5.5.2.3 What to test 怎样测试

Machine Test: Check that there are no tabindex attributes or layout effects that affect the order of presentation.

If there are tabindex attributes check that all controls have a tab index and that they are used consistently.

Human Test: If there are either tabindex attributes or layout effects that might affect the order of presentation, then check that the order is usable.

机器测试：检查确认没有tabindex属性或布局效果影响表现顺序。

如果有使用tabindex属性检查所有的控件都有这个属性，确认它们被一致的使用。

人工测试：如果tabindex属性或布局效果可能影响表现顺序，那么检查顺序的可用。

5.5.3 Labels for Form Controls 表单控件标签

[CONTROL_LABELLING] Label all form controls appropriately and explicitly associate labels with form controls.

[CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to.

[控件标签] 恰当的为控件加上标签。

[控件位置] 恰当的放置标签令它们和相关的控件显示出关联。

5.5.3.1 What it means 解释

This means use the label element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the form control so re-flowing or adapting the content intelligently will always recognize label controls and keep them together.

这意味着在HTML里使用label元素，或者其它语言的同等功能。确保标签和表单控件一致且接近以便当文字流动或内容适配时总是能辨认标签和所指示的控件。

5.5.3.2 What to test 怎样测试

Machine Test: Check if the label element is used in forms.

Human Test: Check whether the labels are properly positioned with regard to the controls.

机器测试：检查表单内使用了label元素。

人工测试：检查标签位置是否和相关的控件相联系。

5.5.3.3 References 参考

This relates to WCAG 10.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-unassociated-labels) and 12.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-associate-labels).

关系到 10.2 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-unassociated-labels)和12.4 (http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-associate-labels)。

6 Conformance and mobileOK 一致性和mobileOK

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.

本最佳实践的陈述意在令围绕他们构造有一致性的规则以支持mobileOK认证和其他用途。mobileOK认证将会基于本文件的称述中的某些属性或子集，建立具体的信任建议要求。

As such, the mobileOK trustmark will serve as the main conformance claim for the Best Practices document.

因此，mobileOK认证将成为最佳实践文件的主要一致性要求。

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.

所有的最佳实践陈述都拥有一个片断标示符，以允许正文和相关的陈述关联到它们。

6.1 Classes of Products 产品类别

This specification applies to one class of product: content delivered to a mobile device, including the metadata transferred as part of the delivery protocol.

本规范适用与一类产品：传输到移动设备的内容，包括传输协议中被传输的数据。

6.2 Extensibility 延伸

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.

此规范可以兼容其他描述内容要求不同的规范，因为这些要求没有与当前规范冲突。

A Sources (Non-Normative) 引用来源

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

最佳实践规范是最佳实践工作组由若干来源组合而成，主要包括：

• Various BPWG group meetings and discussions
• WCAG Guidelines 1.0 [WCAG (http://www.w3.org/TR/mobile-bp/#WCAG)]
• iMode Guidelines [iMode (http://www.w3.org/TR/mobile-bp/#iMode)]
• Opera's "Making Small Devices Look Great" [Opera (http://www.w3.org/TR/mobile-bp/#Opera)]
• Openwave Guidelines [OpenWave (http://www.w3.org/TR/mobile-bp/#OpenWave)]
• Nokia's Series 60 XHTML-MP Guidelines [Nokia-MP (http://www.w3.org/TR/mobile-bp/#Nokia-MP)]
• Browsing on Mobile Phones, Nokia [Nokia-VR (http://www.w3.org/TR/mobile-bp/#Nokia-VR)]
• Little Spring Design [LSD (http://www.w3.org/TR/mobile-bp/#LSD)]

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.

虽然最佳实践规范主要是由二级研究组合而成的，但许多研究案例源于初级研究组合而成。此外，工作组成员的贡献包括他们的公司一定程度上的初步研究。

B Related Reading (Non-Normative) 相关阅读

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.

The Character Model for the World Wide Web (http://www.w3.org/TR/2005/REC-charmod-20050215/) and other materials prepared by the W3C Internationalization (i18n) Activity (http://www.w3.org/International/) cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.

The Web Accessibility Initiative (http://www.w3.org/WAI/) has prepared a variety of Guidelines and Techniques (http://www.w3.org/WAI/guid-tech.html) that likewise bear on the preparation and processing of content in and for the Web.

Section 3.2 Background to Adaptation (http://www.w3.org/TR/mobile-bp/#ca) above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity (http://www.w3.org/2001/di/).

对本文件主题感兴趣的读者会发现其他相关的各种出版物。正如之前“应用范围”一节提到的，类似国际化和可访问性的主题由W3C另行论述，并不在本文涵盖。

万维网特征模型 (http://www.w3.org/TR/2005/REC-charmod-20050215/)和W3C国际化（i18n）行动 (http://www.w3.org/International/)提供的其他材料涵盖为One Web和移动服务领域编写的重要内容。

Web可访问性倡议 (http://www.w3.org/WAI/)编写了各种指南和技术 (http://www.w3.org/WAI/guid-tech.html)同样关系到web内容的编写和处理。

章节3.2适配背景介绍了内容适配的概念。打算在服务器端执行适配的读者会对设备独立性行动 (http://www.w3.org/2001/di/)正在进行的工作感兴趣。

C Acknowledgements (Non-Normative) 鸣谢

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.

编辑者们要感谢BPWG成员的各种捐助。还要感谢公共邮件列表的贡献者，以及那些在最后意见征集中提出宝贵意见的人们。

The editors acknowledge significant written contributions from:

编辑者们鸣谢重要的撰写贡献，他们是：

• Greg Aaron, Afilias Limited
• Daniel Appelquist, Vodafone (Mobile Web Best Practices Working Group Chair)
• Phil Archer, ICRA
• Rotan Hanrahan, MobileAware
• Dominique Hazaël-Massieux, W3C/ERCIM (W3C Team Contact)
• Philipp Hoschka, W3C/ERCIM (W3C Team Contact)
• Richard T. Kennedy, The Boeing Company
• Rhys Lewis, Volantis Systems Ltd
• Luca Passani, Openwave Systems Inc.
• Giles Payne, NTT DoCoMo
• James Pearce, Argo Interactive Ltd
• Kai-Dietrich Scheppe, Deutsche Telekom AG, T-Com, Geschäftsbereich T-Online
• Andrea Trasatti, W3C Invited Expert
• Paul Walsh, Segala M Test

D References (Non-Normative) 参考资料

D.1 MWI References MWI参考资料

Scope

Scope of Mobile Web Best Practices, Phil Archer, Ed Mitukiewicz, Editors, W3C Working Group Note, 20 December 2005 (See http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/ (http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/))

Techniques

Mobile Web Techniques for Best Practices [in development] (See http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro (http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro))

技术

最佳实践的移动web技术（开发中）（见http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro (http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro)）

mobileOK

mobileOK Basic Tests 1.0, Sean Owen, Jo Rabin (eds), W3C Working Draft, 10 June 2008 (See http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/ (http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/))

mobileOK基本测试1.0，Sean Owen，Jo Rabin (eds)，W3C工作草案，2008年6月10日（见(See http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/ (http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/)）

D.2 Sources 引用来源

WCAG

Web Content Accessibility Guidelines 1.0, W Chisholm, I. Jacobs, G Vanderheiden, Editors, W3C Recommendation, 5 May 1999. (See http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/))

Web内容可访问性指南1.0，W Chisholm，I. Jacobs，G Vanderheiden，编辑者，W3C推荐标准，1999年5月5日。（见http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/)）

WAIGlossary

WAI (Printable) Glossary, Katie Haritos-Shea, Charles McCathieNevile, Internal Working Draft, 1 March 2003 (See http://www.w3.org/WAI/GL/Glossary/ (http://www.w3.org/WAI/GL/Glossary/))

WAI（可打印版）术语表，Katie Haritos-Shea，Charles McCathieNevile，内部工作草案，2003年3月1日（见arch 2003 (See http://www.w3.org/WAI/GL/Glossary/ (http://www.w3.org/WAI/GL/Glossary/)）

iMode

iMode (See 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))

iMode（见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)）

Opera

Opera's Making Small Devices Look Great (See http://my.opera.com/community/dev/device/ (http://my.opera.com/community/dev/device/))

Opera的《令小设备看上去更棒》（见http://my.opera.com/community/dev/device/ (http://my.opera.com/community/dev/device/)）

OpenWave

Openwave (See 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))

Openwave（见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)）

Nokia-MP

Nokia Guidelines for XHTML-MP on Series 60 (See 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))

诺基亚Series 60设备的XHTML-MP指南（见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)）

Nokia-VR

Browsing on Mobile Phones, paper by Virpi Roto, Nokia (See http://www.research.att.com/~rjana/WF12_Paper1.pdf (http://www.research.att.com/%7Erjana/WF12_Paper1.pdf))

在手机上浏览，Virpi Roto，诺基亚（见http://www.research.att.com/~rjana/WF12_Paper1.pdf (http://www.research.att.com/%7Erjana/WF12_Paper1.pdf)）

LSD

Little Spring Design (See http://patterns.littlespringsdesign.com (http://patterns.littlespringsdesign.com/))

Little Spring Design（见http://patterns.littlespringsdesign.com (http://patterns.littlespringsdesign.com/)）

D.3 Device Independence 设备独立

DIP Device Independence Principles, R. Gimson, Editor, W3C Working Group Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ (http://www.w3.org/TR/2003/NOTE-di-princ-20030901/))

设备独立原则，R. Gimson，编辑者，W3C工作组注释，2003年9月1日（见http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ (http://www.w3.org/TR/2003/NOTE-di-princ-20030901/)）

DCODI Delivery Context Overview for Device Independence, , R. Gimson, R. Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See http://www.w3.org/TR/2006/NOTE-di-dco-20060320/ (http://www.w3.org/TR/2006/NOTE-di-dco-20060320/))

设备独立的传输环境概述，R. Gimson，R. Lewis，S. Sathish，编辑者，W3C工作组注释，2006年3月20日（见http://www.w3.org/TR/2006/NOTE-di-dco-20060320/ (http://www.w3.org/TR/2006/NOTE-di-dco-20060320/)）

DIGLOSS

Glossary of Terms for Device Independence, R. Lewis, Editor, W3C Working Draft (work in progress), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/ (http://www.w3.org/TR/2005/WD-di-gloss-20050118/))

设备独立术语表，R.Lewis，编辑者，W3C工作草案（进程中），2005年1月18日（见http://www.w3.org/TR/2005/WD-di-gloss-20050118/ (http://www.w3.org/TR/2005/WD-di-gloss-20050118/)）

D.4 Web, Protocols and Languages Web，协议和语言

WebArch

Architecture of the World Wide Web, Volume One, N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004 (See http://www.w3.org/TR/2004/REC-webarch-20041215/ (http://www.w3.org/TR/2004/REC-webarch-20041215/))

万维网的结构体系，第一卷，N. Walsh，I. Jacobs，编辑者，W3C推荐标准，2004年12月15日（见http://www.w3.org/TR/2004/REC-webarch-20041215/ (http://www.w3.org/TR/2004/REC-webarch-20041215/)）

XML

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 http://www.w3.org/TR/2006/REC-xml-20060816 (http://www.w3.org/TR/2006/REC-xml-20060816))

可扩展标记语言（XML）1.0 （第四版）Tim Bray，Jean Paoli，C. M. Sperberg-McQueen，Eve Maler，François Yergeau，编辑者，W3C推荐标准2006年8月16日，2006年9月29日编辑到位（见http://www.w3.org/TR/2006/REC-xml-20060816 (http://www.w3.org/TR/2006/REC-xml-20060816)）

XHTML-Basic

XHTML™ Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/ (http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/))

XHTML™ Basic 1.1，Shane McCarron，Masayasu Ishikawa，编辑者，W3C推荐标准2008年7月29日（见http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/ (http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/)）

CSS

Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 (See http://www.w3.org/TR/1999/REC-CSS1-19990111 (http://www.w3.org/TR/1999/REC-CSS1-19990111))

层叠样式表（CSS1）第一级规范，Håkon Wium Lie，Bert Bos，编辑者，W3C推荐标准，1999年1月11日（见http://www.w3.org/TR/1999/REC-CSS1-19990111 (http://www.w3.org/TR/1999/REC-CSS1-19990111)）

CSS2

Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998 (See http://www.w3.org/TR/1998/REC-CSS2-19980512/ (http://www.w3.org/TR/1998/REC-CSS2-19980512/))

层叠样式表第二级CSS2规范，Bert Bos，Håkon Wium Lie，Chris Lilley，Ian Jacobs，编辑者，W3C推荐标准，1998年5月12日（见http://www.w3.org/TR/1998/REC-CSS2-19980512/ (http://www.w3.org/TR/1998/REC-CSS2-19980512/)）

HTTP1.0

Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945 (http://www.w3.org/Protocols/rfc1945/rfc1945))

超文本传输协议—HTTP/1.0 意见征集：1945，T. Berners-Lee，R. Fielding，H. Frystyk，1996年5月（见http://www.w3.org/Protocols/rfc1945/rfc1945 (http://www.w3.org/Protocols/rfc1945/rfc1945)）

HTTP1.1

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 http://www.w3.org/Protocols/rfc2616/rfc2616.html (http://www.w3.org/Protocols/rfc2616/rfc2616.html))

超文本传输协议—HTTP/1.1 意见征集：2616，R. Fielding，J. Gettys，J. Mogul，H. Frystyk，L. Masinter，P. Leach，T. Berners-Lee，1999年6月（见http://www.w3.org/Protocols/rfc2616/rfc2616.html (http://www.w3.org/Protocols/rfc2616/rfc2616.html)）

UTF-8

UTF-8, a transformation format of ISO 10646 Request for Comments: 3629, F. Yergeau, November 2003 (See http://www.ietf.org/rfc/rfc3629.txt (http://www.ietf.org/rfc/rfc3629.txt))

UTF-8，ISO10646格式转换意见征集：3629，F. Yergeau，2003年11月（见http://www.ietf.org/rfc/rfc3629.txt (http://www.ietf.org/rfc/rfc3629.txt)）

CHARSET1

Tutorial: Character sets & encodings in XHTML, HTML and CSS (See http://www.w3.org/International/tutorials/tutorial-char-enc/ (http://www.w3.org/International/tutorials/tutorial-char-enc/))

教程：字符集与XHTML、HTML、CSS中的编码（见http://www.w3.org/International/tutorials/tutorial-char-enc/ (http://www.w3.org/International/tutorials/tutorial-char-enc/)）

CHARSET2

FAQ: Setting encoding in Web authoring applications (See http://www.w3.org/International/questions/qa-setting-encoding-in-applications (http://www.w3.org/International/questions/qa-setting-encoding-in-applications))

常见问题解答：Web创作应用中的编码设置（见http://www.w3.org/International/questions/qa-setting-encoding-in-applications (http://www.w3.org/International/questions/qa-setting-encoding-in-applications)）

D.5 Other References 其他参考

UAPROF

Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0 – 06 Feb 2006 (See 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))

开放移动联盟OMA-TS-UAProf-V2_0-20060206-A被批准的用户代理版本2.0 - 2006年2月6日（参阅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)）

TOMCAT

Tomcat FAQ How do I get a customized error page? (See http://tomcat.apache.org/faq/misc.html#q6 (http://tomcat.apache.org/faq/misc.html#q6))

Tomcat常见问题解答：怎样创建自定义错误页？（参阅http://tomcat.apache.org/faq/misc.html#q6 (http://tomcat.apache.org/faq/misc.html#q6)）

APACHE

Apache Core Features ErrorDocument directive (See http://httpd.apache.org/docs/1.3/mod/core.html#errordocument (http://httpd.apache.org/docs/1.3/mod/core.html#errordocument))

Apache 核心功能ErrorDocument指导（参阅http://httpd.apache.org/docs/1.3/mod/core.html#errordocument (http://httpd.apache.org/docs/1.3/mod/core.html#errordocument)）

IIS

IIS Custom HTTP Error Messages (See 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))

ISS自定义HTTP错误消息（参阅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)）

T-MOB

T-Mobile International - Position Statement for W3C Mobile Web Initiative Version: 1.0 18 Dec 2004 (See 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))

T-Mobile国际 - 对W3C移动Web倡议的立场声明版本1.0 2004年12月18日（参阅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)）

MF

Study by Segala M Test on Scrolling vs. Pagination (See http://www.mobilefriendly.org (http://www.mobilefriendly.org/))

Segala M关于滚动和分页的对比研究（参阅http://www.mobilefriendly.org (http://www.mobilefriendly.org/)）