W3C

Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)

W3C Working Group Note 9 July 2009

This version:
http://www.w3.org/TR/2009/NOTE-mwbp-wcag-20090709/
Latest version:
http://www.w3.org/TR/mwbp-wcag/
Previous version:
http://www.w3.org/TR/2009/WD-mwbp-wcag-20090526/
Editors:
Alan Chuter, Fundación ONCE / Technosite.
Yeliz Yesilada, University of Manchester (WCAG 1.0 pages).

Abstract

This technical report describes the similarities and differences between the requirements in Web Content Accessibility Guidelines (WCAG) and Mobile Web Best Practices 1.0 (MWBP). Introductory information and links to related documents are in Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices.

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 at http://www.w3.org/TR/.

This W3C Working Group Note is introduced in Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices. It was developed jointly by the Mobile Web Best Practices Working Group of the Mobile Web Initiative (MWI) and the Education and Outreach Working Group (EOWG) of the Web Accessibility Initiative (WAI).

This Note was published on 9 July 2009 as a completed document. The changelog lists changes since the last version. This document may be updated in the future. Please send any comments on this document to public-bpwg-comments@w3.org (public archive) with subject [MWBP-WCAG Relationship].

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This document may be updated, replaced or obsoleted by other documents at any time. Therefore, quotes or references to specific information in the document should include the publication date of this version, 9 July 2009. It is inappropriate to cite this document as other than a Working Group Note, which is not an endorsed W3C Recommendation.

This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the Mobile Web Best Practices Group and also maintains a public list of any patent disclosures made in connection with the deliverables of the Education and Outreach Working Group; those pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


Table of Contents


Introduction

This technical report helps Web developers meet both Web Content Accessibility Guidelines (WCAG) and Mobile Web Best Practices 1.0 (MWBP). It describes the similarities and differences between requirements in WCAG and MWPB. It is designed primarily to help Web developers who have worked with either WCAG or MWBP to learn about the additional requirements in the other.

This technical report is a companion document to WCAG and MWBP, and does not replace either of those. The actual Web Content Accessibility Guidelines document should be used to make Web content accessible to people with disabilities, and the Mobile Web Best Practices document should be used for best practices for making Web content for mobile devices.

Many MWBPs have the added benefit of partial or complete compliance with certain WCAG success criteria or checkpoints. However, WCAG is often more detailed or describes a different aspect of the same concept. It should not be assumed that following any BP will ensure accessibility or that a success criterion or checkpoint will ensure compliance with MWBPs. To ensure compliance it is important to always consult the Mobile Web Best Practices or the Web Content Accessibility Guidelines directly.

W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.

Differences of Approach Between WCAG and MWBP

WCAG and MWBP both aim to improve the Web interaction of users who experience barriers due to either disabilities or the device used to access the Web. However, WCAG and MWBP have slightly different approaches. For example, a key feature of WCAG 2.0 success criteria is that they are specifically designed to be testable statements. Although some of the Mobile Web Best Practices are testable, they are not all intended to be testable.

While the two documents show significant overlap in many areas, there are different degrees of overlap between individual technical requirements, so that there is not always a one-to-one mapping between them. For instance, WCAG has some requirements that are specific to accessibility needs of people with disabilities, and that are not relevant for mobile devices (for example, requirements that specifically address assistive technology). Conversely, MWBP has other requirements that are specific to mobile devices only (for example, requirements to minimize battery consumption and CPU power). However, in general many requirements are applicable for both groups of users (for example, requirements for color contrast, flexible font sizes, etc.).

The relationship between WCAG and MWBP is too complex for a simple mapping table to adequately communicate what developers need to do to meet both. For example, in some cases complying with a specific WCAG provision will meet the related MWBP; however, the inverse is not always true and complying with the MWBP provision will not necessarily meet the related WCAG provision. Thus, there is no simple mapping table between WCAG and MWBP. The document Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities document shows generally how WCAG and MWBP relate.

Priorities and Levels

WCAG 1.0 checkpoints are Priority 1, 2, or 3. WCAG 2.0 success criteria are Level A, AA, or AAA.The Mobile Web Best Practices (BP) are not assigned priorities or levels.

How to Use This Document

Please see the following introductory and related information:

This document includes four subpages that each address a different scenario. Most people will use only one of the subpages described below:

Web Content Accessibility Guidelines 2.0 and
Mobile Web Best Practices 1.0 Together

If you are not familiar with either WCAG or MWBP:

  1. Use Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities (which is also available in a table format) for an overview of the barriers and solutions shared by WCAG 2.0 and MWBP.
  2. Become familiar with WCAG 2.0.
  3. Use the WCAG 2.0 to MWBP subpage of this document to learn about the additional requirements in MWBP.
  4. Become familiar with MWBP.

From MWBP to WCAG 2.0: Making content that meets Mobile Web Best Practices also meet Web Content Accessibility Guidelines 2.0

Introduction

For those familiar with Mobile Web Best Practices (MWBP), this page describes what also needs to be done to meet Web Content Accessibility Guidelines 2.0.

Summary of work required to make content that meets MWBP also meet WCAG 2.0

Compliance with the MWBP helps go some way towards achieving compliance with some WCAG 2.0 success criteria. This section provides a summary of these success criteria. There are three possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with the MWBP, to achieve compliance with WCAG 2.0, you need to do the following:

Nothing: If a provision is labelled “Nothing” then content that complies with MWBP already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.

Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. SC links in this section point to the detail section below; BP links in this section point to the MWBP Recommendation.

Everything: For all other success criteria, the MWBP do not ensure compliance and it will be necessary to do the work involved. These SCs are not related to any MWBPs.

Addressing WCAG 2.0 Success Criteria

This section lists each of the WCAG success criteria that are related to MWBP, which are listed under “something” above. For each SC, the section title is that of the SC. This is followed by a quotation of the text of the SC (sometimes abbreviated) and a list of the BPs that can help meet it.

1.3.1 Info and Relationships

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

Back to list of WCAG 2.0 checkpoints

1.3.2 Meaningful Sequence

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

Back to list of WCAG 2.0 checkpoints

1.4.3 Contrast (Minimum)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for following: (Level AA)

Back to list of WCAG 2.0 checkpoints

1.4.6 Contrast (Enhanced)

The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for...: (Level AAA)

Back to list of WCAG 2.0 checkpoints

1.4.8 Visual Presentation

For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)

  1. foreground and background colors can be selected by the user.
  2. width is no more than 80 characters or glyphs (40 if CJK).
  3. text is not justified (aligned to both the left and the right margins).
  4. line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
  5. text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Back to list of WCAG 2.0 checkpoints

2.1.1 Keyboard

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

Back to list of WCAG 2.0 checkpoints

2.1.3 Keyboard (No Exception)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

Back to list of WCAG 2.0 checkpoints

Web pages have titles that describe topic or purpose

Back to list of WCAG 2.0 checkpoints

The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Back to list of WCAG 2.0 checkpoints

Headings and labels describe topic or purpose. (Level AA)

Back to list of WCAG 2.0 checkpoints

A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)

Back to list of WCAG 2.0 checkpoints

3.1.5 Reading Level

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. (Level AAA)

3.2.1 On Focus

When any component receives focus, it does not initiate a change of context. (Level A)

Back to list of WCAG 2.0 checkpoints

3.2.2 On Input

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)

Back to list of WCAG 2.0 checkpoints

3.2.3 Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)

Back to list of WCAG 2.0 checkpoints

3.2.5 Change on Request

Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)

Back to list of WCAG 2.0 checkpoints

3.3.2 Labels or Instructions

Labels or instructions are provided when content requires user input. (Level A)

Back to list of WCAG 2.0 checkpoints

4.1.2 Name, Role, Value

For all user user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Back to list of WCAG 2.0 checkpoints

From MWBP to WCAG 1.0: Making content that meets Mobile Web Best Practices also meet Web Content Accessibility Guidelines 1.0

Introduction

For those familiar with Mobile Web Best Practices (MWBP), this page describes what also needs to be done to meet Web Content Accessibility Guidelines 1.0. W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.

Summary of work required to make content that meets MWBP also meet WCAG 1.0

Compliance with the MWBP helps go some way towards achieving compliance with some WCAG 1.0 checkpoints. This section provides a summary of these checkpoints. There are three possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with the MWBP, to achieve compliance with WCAG 1.0, you need to do the following:

Nothing: If a provision is labelled “Nothing” then content that complies with MWBP already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.

Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. Checkpoint links in this section point to the detail section below; BPs link to the MWBP Recommendation.

Everything: For all other CPs, the MWBP do not ensure compliance and it will be necessary to do the work involved. These CPs are not related to any MWBPs.

Addressing WCAG 1.0 Checkpoints

This section lists each of the WCAG 1.0 checkpoints that are related to MWBP, which are listed under “something” above. For each checkpoint, the section title is that of the checkpoint. This is followed by a quotation of the text of the checkpoint (sometimes abbreviated) and a list of the BPs that can help meet it. The information given in this document is intentionally brief. A separate document, entitled “Techniques for Web Content Accessibility Guidelines 1.0”, explains how to implement the checkpoints. The Techniques Document discusses each checkpoint in more detail and provides examples

WCAG 1.0: “Provide redundant text links for each active region of a server-side image map.” (Priority 1)

Back to list of WCAG 1.0 checkpoints

WCAG 1.0: “Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.” (Priority 3)

Back to list of WCAG 1.0 checkpoints

2.2 Ensure that foreground and background color combinations provide sufficient contrast…

WCAG 1.0: “Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen (for images). [Priority 2 for images, Priority 3 for text]”

Back to list of WCAG 1.0 checkpoints

3.1 When an appropriate markup language exists, use markup…

WCAG 1.0: “When an appropriate markup language exists, use markup rather than images to convey information" (Priority 2).

Back to list of WCAG 1.0 checkpoints

5.1 For data tables, identify row and column headers

WCAG 1.0: “For data tables, identify row and column headers. For example, in HTML, use TD to identify data cells and TH to identify headers.” (Priority 1)

Depending on device support, tables may or may not be used, as described for above. However, in contexts where tables are used, identify row and column headers using appropriate markup as required by this checkpoint.

Back to list of WCAG 1.0 checkpoints

5.2 For data tables that have two or more logical levels of row or column headers…

WCAG 1.0: “For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.” (Priority 1)

Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, identify row and column headers using appropriate markup as required by this checkpoint.

Back to list of WCAG 1.0 checkpoints

5.3 Do not use tables for layout unless…

WCAG 1.0: “Do not use tables for layout unless the table makes sense when linearized.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting

WCAG 1.0: “If a table is used for layout, do not use any structural markup for the purpose of visual formatting.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

5.5 Provide summaries for tables

WCAG 1.0: “Provide summaries for tables. For example, in HTML, use the “summary” attribute of the TABLE element (Priority 3).

Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, provide summaries as required by this checkpoint.

Back to list of WCAG 1.0 checkpoints

5.6 Provide abbreviations for header labels

WCAG 1.0: “Provide abbreviations for header labels.” (Priority 3)

Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, provide abbreviations for header labels where appropriate, as described by this checkpoint.

Back to list of WCAG 1.0 checkpoints

6.2 Ensure that equivalents for dynamic content are updated…

WCAG 1.0: “Ensure that equivalents for dynamic content are updated when the dynamic content changes.” (Priority 1)

Back to list of WCAG 1.0 checkpoints

9.1 Provide client-side image maps instead of server-side image maps…

WCAG 1.0: “Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.” (Priority 1)

Back to list of WCAG 1.0 checkpoints

10.2 Until user agents support explicit associations between labels…

WCAG 1.0: “Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

10.3 Until user agents (including assistive technologies) render side-by-side text correctly…

WCAG 1.0: “Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.” (Priority 3)

Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used to lay out text in parallel, word-wrapped columns, provide a linear text alternative, as described by this checkpoint.

Back to list of WCAG 1.0 checkpoints

11.1 Use W3C technologies when they are available and appropriate for a task…

WCAG 1.0: “Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

11.2 Avoid deprecated features of W3C technologies

WCAG 1.0: “Avoid deprecated features of W3C technologies” (Priority 2)

Back to list of WCAG 1.0 checkpoints

12.1 Title each frame to facilitate frame identification and navigation

WCAG 1.0: “Title each frame to facilitate frame identification and navigation” (Priority 1)

Back to list of WCAG 1.0 checkpoints

12.2 Describe the purpose of frames and how frames relate to each other…

WCAG 1.0: “Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

12.3 Divide large blocks of information into more manageable groups where natural and appropriate

WCAG 1.0: “Divide large blocks of information into more manageable groups where natural and appropriate.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

Back to list of WCAG 1.0 checkpoints

13.2 Provide metadata to add semantic information to pages and sites

WCAG 1.0: “Provide metadata to add semantic information to pages and sites.” (Priority 2)

Back to list of WCAG 1.0 checkpoints

13.5 Provide navigation bars to highlight and give access to the navigation mechanism

WCAG 1.0: “Provide navigation bars to highlight and give access to the navigation mechanism” (Priority 3)

Back to list of WCAG 1.0 checkpoints

Back to list of WCAG 1.0 checkpoints

14.1 Use the clearest and simplest language appropriate for a site's content

WCAG 1.0: “Use the clearest and simplest language appropriate for a site's content.” (Priority 1)

Back to list of WCAG 1.0 checkpoints

From WCAG 2.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 2.0 also meet Mobile Web Best Practices

Introduction

For those familiar with Web Content Accessibility Guidelines 2.0, this page describes what also needs to be done to meet Mobile Web Best Practices (MWBP).

Summary of work required to make content that meets WCAG 2.0 also meet MWBP

Compliance with WCAG 2.0 helps go some way towards achieving compliance with some of the MWBP. This section provides a summary of these BPs. There are two possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. Note that coverage may depend on WCAG compliance level achieved and so a BP may appear in “something” and “nothing” lists (for example, LINK_TARGET_ID). To summarise, if your content already complies with WCAG 2.0, to achieve compliance with the MWBP, you need to do the following:

Nothing: If a provision is labelled “Nothing” then content that complies with WCAG 2.0 already complies with the provision and no further effort is necessary. The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.

Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. BP links in this section point to the detail section below; SC links in this section point to WCAG 2.0.

Everything: For all other BPs, WCAG 2.0 does not ensure compliance and it will be necessary to do the work involved. These BPs are not related to any WCAG 2.0 success criteria.

Addressing Mobile Web Best Practices

This section lists each of the MWBPs that are related to WCAG 2.0 success criteria, which are listed under “something” above. For each BP, the section title is that of the BP. This is followed by a list of the SCs that can help meet it.

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

If overall contrast is sufficient, this goes part of the way to ensuring readability with background images.

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

Unlike MWBP, WCAG specifies a contrast ratio and algorithm and certain types of content that are excluded from the requirement. The following SCs may ensure compliance with this BP. However, note that WCAG allows for exceptions for cases like large text, incidental text or images of text and logotypes. If content covered by the BP is not excluded, then compliance is ensured.

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

The following SCs ensure compliance with this BP when using label elements to associate text labels with form controls (1.3.1 below), and either 3.3.2 or 4.1.2.

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

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing

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

WCAG 2.0 does not prohibit the use of the pixel unit of measure.

[NAVIGATION] Provide consistent navigation mechanisms

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

Note that the WAI Glossary definition of Non-text Content which is the basis for this BP, includes video and audio.

[PAGE_TITLE] Provide a short but descriptive page title

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

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

The following SCs go some way to achieving compliance with this BP. Specifically, failure F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh with a time-out ensures compliance with this BP.

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

The BP is less explicit about what structural elements to use, but the following SCs probably cover its intent.

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

[VALID_MARKUP] Create documents that validate to published formal grammars

From WCAG 1.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 1.0 also meet Mobile Web Best Practices

Introduction

For those familiar with Web Content Accessibility Guidelines 1.0, this page describes what also needs to be done to meet Mobile Web Best Practices (MWBP). W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.

Summary of work required to make content that meets WCAG 1.0 also meet MWBP

Compliance with WCAG 1.0 helps go some way towards achieving compliance with some of the MWBP. This section provides a summary of these BPs. There are two possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with WCAG 1.0, to achieve compliance with the MWBP, you need to do the following:

Nothing: If a provision is labelled “Nothing” then content that complies with WCAG 1.0 already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.

Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. BP links in this section point to the detail section below; checkpoint links links in this section point to the WCAG 1.0.

Everything: For all other BPs, WCAG 1.0 does not ensure compliance and it will be necessary to do the work involved. These BPs are not related to any WCAG 1.0 checkpoints.

Addressing Mobile Web Best Practices

This section lists each of the MWBPs that are related to WCAG 1.0 checkpoints, which are listed under “something” above. For each BP, the section title is that of the BP. This is followed by a list of the checkpoints that can help meet it.

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

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

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

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

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

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

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions

[PAGE_TITLE] Provide a short but descriptive page title

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

[TABLES_LAYOUT] Do not use tables for layout

Appendix A: References

For the latest version of any W3C specification, please consult the list of W3C Technical Reports.

[WAI/Experiences]
Experiences Shared by People with Disabilities and by People Using Mobile Devices, eds. Yesilada, Y., Chuter, A., and Henry, S.L.
[WAI/Mobile]
Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices, eds. Thorp, J. and Henry, S.L.
[MWBP1.0]
Mobile Web Best Practices 1.0, eds. Rabin, J. and McCathieNevile, C.
[WCAG1.0]
Web Content Accessibility Guidelines 1.0, eds. W. Chisholm, G. Vanderheiden and I. Jacobs
[WCAG2.0]
Web Content Accessibility Guidelines 2.0, eds. B. Caldwell, M. Cooper, L. Guarino Reid and G. Vanderheiden

Appendix B: Acknowledgements

This document was developed by the WAI Education & Outreach Working Group and the Mobile Web Best Practices Working Group. Charles McCathieNevile (Opera Software) also contributed to this document.