W3C

From Web Content Accessibility Guidelines 2.0
to Mobile Web Best Practices 1.0

W3C Working Draft 27 March 2008

Table of Contents

Introduction

Incomplete draft: This document is an experimental editor's copy that has no official standing and is incomplete. Particularly, the section WCAG 2.0 and MWBP Together is only an outline; WCAG 1.0 to MWBP is only partly filled out. It is subject to major changes and is therefore not intended for implementation. It is provided for review and feedback only. Please send feedback to public-bpwg-comments@w3.org (archive).

For each MWBP, the Accessibility Benefits of this BP (MWBP mapped to accessibility). For each WCAG SC, does this WCAG SC that I have done give also me MWBP compliance? (WCAG mapped to MWBP)

Comment: Reviewers please bear in mind. This page is for those who have done WCAG 2.0 and are moving to MWBP. It answers the two questions “I've done WCAG 2.0, how much of MWBP have I already achieved?” and “I'm thinking of doing a bit of MWBP, but is it really justified for my disabled users?”. It therefore works through all the MWBPs and then the WCAG SCs.

This page is part of a suite of related documents. Please refer to the “How to Use These Documents” section for more information. This document may be relevant if you have achieved WCAG compliance or are planning to do so.

[Content removed from this mock-up for sake of simplicity]

Extending from WCAG 2.0 to MWBP 1.0

[Content removed from this mock-up for sake of simplicity]

Individual Mobile Web Best Practices Compared

This section examines in turn each of the Mobile Web Best Practices where there is a relationship to WCAG 2.0. The main aspect considered for each BP, “How does it enhance accessibility to users with disabilities?”.

Comment: Reviewers please bear in mind. In this section, the thinking is “I've done WCAG 2.0 and I'm thinking about now doing MWBP. I'm more aware of the importance of accessibility for users with disabilities. I won't necessarily do all of the BPs, but might do some if the effort is justified. I want to understand the accessibility benefits, if any, of each BP.” For each BP, it gives the accessibility benefits (ie, MWBP mapped to accessibility). For each BP we explain why it is a good thing for helping users with disabilities.

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

How does it enhance accessibility to users with disabilities? [Note: “Why should I do this if I'm mainly concerned about in users with disdabilities”]: Some users, for example those with motor disability, are unable to use a mouse even when the context of use allows one. These persons often use only a keyboard or a device that emulates a keyboard. This situation parallels that of all users of mobile devices as these are not usually equipped with a mouse. They also also help people with visual disabilities who can not see the screen well and for those with short-term memory loss or cognitive limitations. Access keys may be helpful for all keyboard users. They are especially (perhaps only) useful when the browser allows the user to discover the keys that are assigned (some do, some don't).

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

How does it enhance accessibility to users with disabilities?: The BP mentions that “Auto-refreshing pages are widely recognized as presenting accessibility problems” but does not explain why. Auto-refresh is especially confusing to users of screen readers. When a page is refreshed a screen reader may begin reading the updated content again from the beginning, causing confusion and preventing the user from ever reading the whole page. It is also a barrier for users of screen magnification, and those with cognitive and reading disabilities. Providing a means to stop auto-refresh may help these users if they are aware of it.

[AVOID_FREE_TEXT] Avoid free text entry where possible.

How does it enhance accessibility to users with disabilities?: As described in the explanation of [MINIMIZE_KEYSTROKES] below, this BP is especially beneficial to users with limited dexterity. It is not related to any specific WCAG success criterion.

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

How does it enhance accessibility to users with disabilities?: Readability is compromized when there is a lack of contrast with or without a background image. This BP helps users with low vision or color vision deficit (color blindness). Poor readability due to interference by patterns in background images is especially problematic for users with low vision.

[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

How does it enhance accessibility to users with disabilities?: Like all users of the small keypads found on mobile devices, users with motor disability may experience special difficulty in using the keyboard or other device to navigate between links. Users with cognitive disability may have difficulty concentrating on large numbers of links. Screen reader users may also have difficulty reading through and remembering a large number of links in order to decide which one they want. Given that human memory can only hold a limited number of items then having to recall more than that many links to choose the right one leads to serious difficulty for blind users. Reducing the number of links helps avoid these difficulties.

[CLARITY] Use clear and simple language

How does it enhance accessibility to users with disabilities?: It may lead to a writing style that also helps users with innate (rather than contextual) reading difficulties. It will help people who enlarge text or use screen magnification and therefore can not see as much of screen as intended.

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

How does it enhance accessibility to users with disabilities?: Adequate color and brightness contrast make content more readable for people with low vision.

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

How does it enhance accessibility to users with disabilities?: For screen reader users who are unable to visually determine the relationship between controls and their labels, it enables assistive technology to determine from markup which label identifies each form control.

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

How does it enhance accessibility to users with disabilities?: If controls are not explicitly associated with their labels (as described under CONTROL_LABELLING in this document) screen readers and who use modified screens use the position in markup of the control and the label to determine the relationship. However, for recent screen readers this is now unnecessary if there is explicit association.

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

How does it enhance accessibility to users with disabilities?: While this BP is primarily motivated by the limitations of the input mechanism of the mobile device (for example, a small numeric keypad), it also helps users who have difficulty using their chosen input device. Refer also to PROVIDE_DEFAULTS in this document.

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

How does it enhance accessibility to users with disabilities?: Many users, but especially those with cognitive disabilities or even those with limited experience may have difficulty understanding default error messages and deciding on the correct action to take. This BP aids understanding and navigations.

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

How does it enhance accessibility to users with disabilities?: Many users do not see fonts-related styling. For example, blind users, those who turn off stylesheets, or use text mode browsers. If information is conveyed by fonts, these users may have difficulty understanding the meaning of content. Refer also STYLE_SHEETS_SUPPORT in this document.

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

How does it enhance accessibility to users with disabilities?: As image maps are not discouraged there is no added benefit.

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

How does it enhance accessibility to users with disabilities?: In addition to the benefits described in the BP, using relative units of measure helps people with low vision by letting them increase text size in content so that they can read it.

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum

How does it enhance accessibility to users with disabilities?: While mobile devices have input devices such as numeric keypads that are awkward to use for text input. This BP is especially beneficial to users with limited dexterity who find text input even more difficult. It is not related to any specific WCAG 2.0 success criterion.

[NO_FRAMES] Do not use frames

How does it enhance accessibility to users with disabilities?: While correctly designed and labeled frames are not inaccessible, equivalent content without frames is generally easier to use. It is easier to scan the whole content with a screen reader and to navigate with the keyboard.

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

How does it enhance accessibility to users with disabilities?: Providing text equivalents for non-text content ensures flexibility. Text can be rendered in a diversity of ways such as speech, braille, print, different text sizes. Designing content to be useful when rendered text-only (as required by the BP) requires the provision of text equivalents for non-text content and so may make content more accessible to users unable to see images or other non-text content for whatever reason. Refer to WCAG 2.0 Specific Benefits of Success Criterion 1.1.1 for further information.

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script

How does it enhance accessibility to users with disabilities?: Users with some disabilities may not be able or willing to install or use the plugins necessary for embedded objects. Others may be unable or unwilling to use script. Some assistive technology may not support scripting or it may be disabled.

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions

How does it enhance accessibility to users with disabilities?: Smaller pages may help users with cognitive limitations who have difficulty with large amounts of text.

[PAGE_TITLE] Provide a short but descriptive page title

How does it enhance accessibility to users with disabilities?: People with visual disabilities will benefit from being able to differentiate content when multiple Web pages are open. For example, screen reader users may not be able to see at a glance the content of a window, and so identify it by the page title. People with cognitive disabilities, limited short-term memory and reading disabilities also benefit from the ability to identify content by its title. A descriptive page title also benefits people with severe mobility impairments whose mode of operation relies on audio when navigating between Web pages. Refer to Long page title, with generic information first and differentiating information last.

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

How does it enhance accessibility to users with disabilities?: Opening new windows or changing between open windows when the user is not aware what is happening can be confusing to those who can not see that a new or different window has opened, or can not see the window at all. The user may not understand why the back button does not work correctly (the new window has no history or different history list) and may close the last window of the browser instance and close the application inadvertently.

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible

How does it enhance accessibility to users with disabilities?: While this BP is primarily motivated by the limitations of the input mechanism of the mobile device (for example, a small numeric keypad), it also helps users who have difficulty using their chosen input device.

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

How does it enhance accessibility to users with disabilities?: Like auto-refresh, using markup for redirection can confuse users, especially:

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

How does it enhance accessibility to users with disabilities?: This enhances accessibility for users who have difficulty scrolling for whatever reason (device or physical limitation). Limiting scrolling to one direction (particularly the vertical axis), may help people with cognitive limitations. If scrolling is necessary some may not be aware of this; others may be disoriented by horizontal scroll.

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

How does it enhance accessibility to users with disabilities?: Most visual users are able to scan a whole document at a glance. Many non-visual (for example, blind) users are unable to do this and access content starting at the top. When a document is structured with section headings a screen reader or suitable browser can create a table of contents on the fly. A browser may allow keyboard navigation between headings. Refer to WCAG 1.0 HTML Techniques: Section headings for more information.

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

How does it enhance accessibility to users with disabilities?: When content is organized logically, it will be rendered in a meaningful order when style sheets are turned off or not supported. This particularly helps disabled users who access pages in alternative modes. For example, voice access with screen readers (blind, low vision) or screen magnifiers (low vision). Visual font effects defined in CSS may not be rendered by a mobile device and even if they are many users may not perceive them. For example, blind users with screen readers and those with low vision who use their own stylesheet rather than the author's. For further information, refer to WCAG 2.0 Specific Benefits of Success Criterion 1.3.1 and the explanation of the [FONTS] best practice in this document.

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

How does it enhance accessibility to users with disabilities?: Using CSS allows separation of content and presentation, enabling users to adjust presentation to suit their needs. Users with different disabilities benefit from this as it gives flexibility to user agents to adapt content according to the needs of individual users. For example, people with low vision can use their own stylesheets to change font sizes and background colours to meet their needs.

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

How does it enhance accessibility to users with disabilities?: While the mobile user may not have a pointing device available a user with (for example) motor disability may need to use the keyboard for navigation. Refer to “Focus (tab) order does not match logical document content sequence” in the accompanying document “Experiences Shared by People with Disabilities and by People Using Mobile Devices”.

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

How does it enhance accessibility to users with disabilities?: No added benefit.

[TABLES_LAYOUT] Do not use tables for layout

How does it enhance accessibility to users with disabilities?: Reading order: Using tables can cause incorrect reading order (when the apparent visual sequence is not the same as that in the markup). Avoiding tables for layout avoids the problem. Flexibility: if content is formatted with CSS positioning, users can modify layout to suit their needs; with tables the content is locked in a grid.

[TABLES_NESTED] Do not use nested tables

How does it enhance accessibility to users with disabilities?: Nested tables can be problematic for users of screen readers. As the screen reader is unable to differentiate between a data table (which conveys meaning) and a layout table (which should not), a screen reader may announce to the user each new table it encounters, and information such as the number of rows and columns the table contains. If tables are nested this can easily result in an excess of information and cause confusion. This best practice avoids the problem.

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

How does it enhance accessibility to users with disabilities?: No_added_benefit when tables may be used. Refer to TABLES_ALTERNATIVES.

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

How does it enhance accessibility to users with disabilities?: This BP is concerned with the characteristics of different devices, not different users, and as such does not specifically improve accessibility for users with disabilities. However, it does also encourage content providers to also test “with specific features disabled, such as using text-only modes and with scripting disabled”. This is a way of checking compliance with WCAG 1.0 checkpoints 1.1, “Provide a text equivalent for every non-text element...” and 6.3, “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported”.

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

How does it enhance accessibility to users with disabilities?: No added benefit. While some users with disabilities use the most advanced mobile devices to run their assistive technology properly, others need or prefer simpler models that are easier to use. For example, the elderly or those with cognitive disabilities. Users with limited dexterity may prefer older devices with larger keypads. those with limited vision may use devices with monochrome displays. Some assistive technology may not be compatible with new devices. This BP ensures that content is accessible using the widest possible range of devices.

[URIS] Keep the URIs of site entry points short

How does it enhance accessibility to users with disabilities?: Users with motor disability who type URIs using the keyboard or use voice input, or who have dyslexia, may experience difficulty when entering long strings of text. Long URIs can also confuse screen reader users as the page URI is often the first thing they hear. Keeping the URIs short helps all these users. This BP deals with an aspect not considered in WCAG 1.0.

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

How does it enhance accessibility to users with disabilities?: This BP benefits people with visual disabilities. Users may not be able to see colors or identify them correctly (color deficit, color blindness) or see the page at all (blind users). Users may have turned off the style sheet or use a browser that does not support CSS, or may need to use a special style sheet. These users may misinterpret or not perceive information expressed by color alone.

[VALID_MARKUP] Create documents that validate to published formal grammars

How does it enhance accessibility to users with disabilities?: From WCAG 2.0, 4.1.1 Parsing: Ensuring that Web pages have complete start and end tags and are nested according to specification helps ensure that assistive technologies can parse the content accurately and without crashing. Assistive technologies used by disabled users can provide more accurate presentation of pages that validate to published grammars.

Individual WCAG 2.0 Success Criteria Compared

[Content removed from this mock-up for sake of simplicity]

WCAG 2.0 Success Criteria

List of success criteria described in detail:

The following success criteria are believed to have no added accessibility benefit and no relation to any MWBP, and are listed below for completeness:

Comment: Reviewers please bear in mind that in this section, the thinking is “I've done WCAG 2.0 and I'm thinking about now doing MWBP. I need to know how much work is involved and specifically how much I have already achieved by doing MWBP.” For each SC we say how much it helps towards compliance with MWBP.

1.1.1 Non-text Content

Does it give me MWBP compliance?: Yes, this checkpoint ensures compliance with BP NON-TEXT_ALTERNATIVES.

Back to list of WCAG 2.0 checkpoints

1.2.1 Captions (Prerecorded)

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.2 Audio Description or Full Text Alternative

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.3 Captions (Live)

Does it give me MWBP compliance?: No

Back to list of WCAG 2.0 checkpoints

1.2.4 Audio Description

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.6 Audio Description (Extended)

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.7 Full Text Alternative

Does it give me MWBP compliance?: Partially.
It goes some way to complying with NON-TEXT_ALTERNATIVES. [@@ Whether this is necessary depends on whether the BP really requires text equivalents for multimedia; it links to the WAI Glossary definition].

Back to list of WCAG 2.0 checkpoints

1.3.1 Info and Relationships

Does it give me MWBP compliance?: Yes, it ensures compliance with STYLE_SHEETS_SUPPORT, STYLE_SHEETS_USE, CONTROL_LABELLING and STRUCTURE.

Back to list of WCAG 2.0 checkpoints

1.4.1 Use of Color

Does it give me MWBP compliance?: Yes, it should ensure compliance with USE_OF_COLOR without any further effort. It also helps to achieve compliance with BP STRUCTURE by ensuring that structural elements are used rather than colour.

Back to list of WCAG 2.0 checkpoints

1.4.3 Contrast (Minimum)

Does it give me MWBP compliance?: This checkpoint ensures compliance with COLOR_CONTRAST with no further effort.

Back to list of WCAG 2.0 checkpoints

1.4.4 Resize text

Does it give me MWBP compliance?: Possibly.
Some of the WCAG Techniques, such as using named font sizes, em units or percentages ensure compliance with MEASURES.

Back to list of WCAG 2.0 checkpoints

1.4.5 Images of Text (Limited)

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.4.6 Contrast (Enhanced)

Does it give me MWBP compliance?: Yes, it ensures compliance with COLOR_CONTRAST with no further effort.

Back to list of WCAG 2.0 checkpoints

1.4.8 Visual Presentation

1.4.9 Images of Text (Essential)

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

2.1.1 Keyboard

Does it give me MWBP compliance?: Possibly, partially.
The technique using both keyboard and other device-specific functions may help meet OBJECTS_OR_SCRIPT (“If scripting is used, do not use onmouse and onkey triggers, use onclick”).

Back to list of WCAG 2.0 checkpoints

2.1.2 No Keyboard Trap

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

2.1.3 Keyboard (No Exception)

Does it give me MWBP compliance?: As described under 2.1.1 Keyboard.

Back to list of WCAG 2.0 checkpoints

2.2.2 Pausing

Does it give me MWBP compliance?: No

Back to list of WCAG 2.0 checkpoints

2.4.1 Bypass Blocks

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

2.4.2 Page Titled

Does it give me MWBP compliance?: Yes, this gives compliance with PAGE_TITLE with no further effort.

Tip: The title may be truncated in the mobile device as described in the BP. It may be useful to put the most important, differentiating information first, also helping screen reader users. Refer also to Long page title in “Summary of Experience of Content Features by Users” section.

Back to list of WCAG 2.0 checkpoints

2.4.3 Focus Order

Does it give me MWBP compliance?: Yes, this success criterion ensures compliance with TAB_ORDER with no further effort.

Back to list of WCAG 2.0 checkpoints

2.4.4 Link Purpose (In Context)

Does it give me MWBP compliance?: Possibly.
It goes some way to meeting LINK_TARGET_ID but as the SC provides for indicating the link purpose in the context which is not contemplated by the BP, and in the title attribute or table cell header which are unlikely to be supported adequately by a mobile browser. As a result, content that conforms to this SC may not meet the BP. Also, the BP explicitly mentions file format (if not known to be supported by device), language, file size.

Back to list of WCAG 2.0 checkpoints

2.4.6 Labels Descriptive

Does it give me MWBP compliance?: Possibly.
Some of the sufficient techniques may ensure compliance with STRUCTURE.

Back to list of WCAG 2.0 checkpoints

2.4.7 Focus Visible

Does it give me MWBP compliance?: No

Back to list of WCAG 2.0 checkpoints

Does it give me MWBP compliance?: Yes, it ensures compliance with LINK_TARGET_ID. Note that the BP explicitly mentions file format (if not known to be supported by device), language, file size.

Back to list of WCAG 2.0 checkpoints

2.4.10 Section Headings

Does it give me MWBP compliance?: Yes, this success criterion ensures compliance with STRUCTURE with no additional effort (although the title of the BP suggests a wider in scope).

Back to list of WCAG 2.0 checkpoints

3.2.1 On Focus

Does it give me MWBP compliance?: Partially.
It goes some way to achieving compliance with POP_UPS, AUTO_REFRESH and REDIRECTION.

Back to list of WCAG 2.0 checkpoints

3.2.2 On Input

Does it give me MWBP compliance?: Partially.
Like 3.2.1 On Focus, it goes some way to achieving compliance with POP_UPS, AUTO_REFRESH and REDIRECTION.

Back to list of WCAG 2.0 checkpoints

3.2.5 Change on Request

Does it give me MWBP compliance?: Yes, it gives compliance with POP_UPS and AUTO_REFRESH. It may give compliance with REDIRECTION depending on the technique used.

Back to list of WCAG 2.0 checkpoints

3.3.2 Labels or Instructions

Does it give me MWBP compliance?: Possibly.
Some of the sufficient techniques for this success criterion ensure compliance with CONTROL_LABELLING.

Back to list of WCAG 2.0 checkpoints

4.1.1 Parsing

Does it give me MWBP compliance?: Possibly.
Some of the sufficient techniques may ensure compliance with VALID_MARKUP.

Back to list of WCAG 2.0 checkpoints

4.1.2 Name, Role, Value

Does it give me MWBP compliance?: Possibly.
Some of the sufficient techniques for this success criterion ensure compliance with CONTROL_LABELLING.

Back to list of WCAG 2.0 checkpoints