Relationship between Mobile Web Best Practices 1.0 and Web Content Accessibility Guidelines, version 0h

1. Introduction

For the designer of content for the mobile Web, this document explains why it is important to consider the needs of all users, including people with disabilities, and how they use mobile devices to access the Web. For a person with a disability who accesses the Web with a mobile device, it explains that there are guidelines other than WCAG that can improve the mobile Web experience. For people who work in the field of disability or Web accessibility it explains how the Mobile Web Best Practices can improve accessibility for people with disabilities, and that with a little extra effort or insight those best practices could make an even greater difference.

Many Web sites have already adopted the Web Content Accessibility Guidelines (hereinafter referred to as [WCAG]). WCAG explains how to make Web content accessible to people with disabilities. In many cases compliance with WCAG is mandatory. The Mobile Web Best Practices 1.0 (hereinafter [MWBP]) 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.

Increasingly, web content is designed to comply with one of these sets of guidelines or best practices. However, misunderstanding of their requirements and the assumptions about the user and device characteristics on which they are based, leads to less than optimal implementation. This document is intended to serve as an added justification or argument for aiming for compliance with either of the recommendations. The benefits include:

• Unnecessary effort and cost is often expended in complying with recommendations seperately or consecutively. This document explains the overlaps between the two recommendations, allowing for greater efficiency.
• Content providers may decide not to adopt another recommendation due to imagined cost. This document explains the overlaps and synergies between the two recommendations, and the ways in which once one recommendation is adopted, the other is less onerous.
• Specialists in the “Web accessibility” or “mobile Web” fields may be unaware of the importance of the other and have difficulty communicating. This document can spread awareness and improve communication by helping specialists in different fields understand that their concerns are often related and parallel. It should help trainers teaching students already experienced in another field using terminology and concepts they are familiar with and without repeating material they already know.
• Vendors of evaluation tools may expend unnecessary effort and cost developing test implementations that already exist for the other recommendation. The information in this document allows them to understand how implementations may be reused or easily adapted.

It may be useful for building the business case for adopting either [WCAG] or [MWBP] in a web site that already complies with one, or for adopting both together. For accessibility, the Web Accessibility Initiative provides a guidance document Developing a Web Accessibility Business Case for Your Organization.

1.1 How this document is organized

Unlike the Web Content Accessibility Guidelines, the Mobile Web Best Practices are not prioritised. [MWBP] relate to checkpoints of all the WCAG 1.0 priorities (1, 2 and 3).

This document considers the relationship of the MWBPs to the WCAG guidelines and checkpoints, and seperately, the inverse relationships. The relationship between MWBP and WCAG is not symmetrical. As an introduction and background it considers first the experience of users with disabilities and the experience of the general user in the mobile context.

1.2 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. it is important to understand the other W3C Recommendations to which it refers (see Related Documents of Interest).

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.

Many readers of the document are likely to have a good knowledge of general Web accessibility but are concerned with the problems of persons with disabilities in the mobile context.

1.3 Scope

This document describes the relationships, overlaps and differences between [MWBP] and [WCAG]. It also describes the relationships between content characteristics and the effects these have on users with disabilities in all contexts and all users in the mobile context.

At the time of writing there is a draft of the Web Content Accessibility Guidelines 2.0. The MWBP make direct reference to WCAG 1.0 and many of the concepts described relate directly to those in that version. Like WCAG 1.0, MWBP 1.0 assumes content in HTML. This document covers the WCAG 1.0 recommendation and WCAG 2.0 in the the latest available draft available at the time of publication.

Web accessibility for people with disabilities is beyond the scope of this document except where it especially affects mobile users. It is described in [WCAG]. The needs of users in the mobile Web context is beyod the scope of this document except where it especially affects users with disabilities. It is described in [MWBP].

This document does not create any further requirements beyond those defined in the [MWBP] and [WCAG].

1.4 Related Documents of Interest

• Mobile Web Best Practices 1.0
• Web Content Accessibility Guidelines 1.0
• Web Content Accessibility Guidelines 2.0
• WAI Resources page
• Developing a Web Accessibility Business Case for Your Organization

1.5 Why No WCAG to MWBP Mapping Table?

While there appear to be many similarities between many of the WCAG provisions and those of the Mobile Web Best Practices, in reality there are many subtle differences. A simple table would be misleading and lead to duplication of work in some aspects and and inadequate implementations in others. Also the relationships are not symmentrical (SC x relates to BP y, but it does not follow therefore that BP y relates to SC x).

Readers familiar with accessibility and WCAG can not be expected to be aware of the mobile web, mobile devices, infrastructure and the MWBPs. Similarly, Mobile Web specialists can not be expected to have a thorough knowledge of the needs of users with disabilities and assistive technology. More information and guidance is needed.

2. How Barriers Experienced by Web Users with Disabilities Parallel those in the Mobile Context

While disabled users have involuntary disability, we can think of all mobile users as having a kind of voluntary “disability” due to their choice of technology (the mobile context) that parallels innate disability.

Users of mobile devices experience limitations. Users with disabilities, even with full-featured desktop devices, may experience certain physical, sensorial or cognitive limitations that are not related / relevant to those of the general mobile user.

Users of mobile devices experience limitations imposed by the features of devices and user agents and the environmental context in which they often access the Web. Note that mobile devices vary widely, not all the problems described are present on all models. the table below is not exhaustive, but has been selected to demonstrate the parallels between the two contexts of use.

Summary of Experience of Content Features by Users

The table below shows that in the example aspects, although the cause may be different in each context, the result is generally similar in both. Implementing accessibility guidelines will in many ways improve the experience for users in the mobile context. Similarly, implementing best practices for the mobile context will improve the experience for users with a range of disabilities.

Testing with Users and Devices

Both the Mobile Web Best Practices and WCAG provide information about the possible barriers to users, and advice about how to avoid them. Compliance does not guarantee usability or accessibility. Barriers may arise other than those described and content providers should avoid them by performing user testing. Other solutions than those described may be found to the barriers. User testing should always include a full range of users, including those with different disabilities.

3. Mobile Web Best Practices and Accessibility

This section describes how different Mobile Web Best Practices (MWBPs) help improve the experience for users with disabilities and how compliance with these BPs can help comply with the Web Content Accessibility Guidelines 2.0 and 1.0 (WCAG). For content that already complies with MWBP, it outlines what may need to be done to comply with all of WCAG (“Extending from MWBP to WCAG 2.0” and Extending from MWBP to WCAG 2.0).

By improving usability, all BPs help improve accessibility. This section describes the specific accessibility benefits and the ways in which some relate directly to the Web Content Accessibility Guidelines 1.0.

As described in this section, many Mobile Web BPs have the added benefit of partial or complete compliance with certain WCAG 1.0 checkpoints. However, the accessibility guidelines are often more detailed or describe a different aspect of the same concept. It should not be assumed that following any BP will ensure accessibility. To ensure accessibility it is important to always consult the Web Content Accessibility Guidelines.

Each BP is covered to answer the following questions:

• How does it help especially users with disabilities? (otherwise no_added_benefit)
• Does the BP cover any WCAG CPs? If so
  • Additional effort required for WCAG compliance
  • How to leverage existing investment in BP.
  • If so, is BP adequate for WCAG?
  • Is BP correct?
  • Synergy/overlap and differences.
  • If you comply with MWBP, why not go a little further and...?
  • If you comply with MWBP, and are aiming for WCAG, you will have to...
  • How to do both at once.

Extending from MWBP to WCAG 2.0

This section provides guidance on the “upgrade path” from MWBP to accessibility through WCAG 2.0 compliance. What follows is a summary of the detailed information for each BP that follows it. For each of the WCAG 2.0 levels there are four possible degrees of effort required, in each case simplified with four keywords (nothing, something, everything):

[Insert here duplicate list of levels of effort when finalised]

For Level A

Nothing, content already complies with these checkpoints:

• 1.4.1, “Use of Color”, covered by USE_OF_COLOR

Something more effort of some kind or a check, to comply with these checkpoints:

• @@

Everything (start from scratch), to comply with these checkpoints:

• @@

For Level AA

Nothing, content already complies with these checkpoints:

• @@

Something more effort of some kind or a check, to comply with these checkpoints:

• @@

Everything (start from scratch), to comply with these checkpoints:

• 1.2.3 Captions (Live)

For Level AAA

Nothing, content already complies with these checkpoints:

• @@

Something more effort of some kind or a check, to comply with these checkpoints:

• @@

Everything (start from scratch), to comply with these checkpoints:

• @@

Extending from MWBP to WCAG 1.0

This section provides guidance on the “upgrade path” from MWBP to accessibility through WCAG 1.0 compliance. What follows is a summary of the detailed information for each BP that follows it. For each of the WCAG 1.0 priorities there are four possible levels of effort required, in each case simplified with four keywords (nothing, something, everything):

• Nothing: Content already complies with these checkpoints so no further effort is necessary. For each checkpoint there is a list of the BPs that ensure compliance.
• Something: More effort of some kind is necessary to comply with these checkpoints. What is required depends on the individual checkpoint. For each checkpoint there is a list of the BPs that provide partial compliance or are in some way related.
• Everything: MWBP do not cover this aspect at all, it is necessary to comply with these checkpoints from scratch. As there is no coverage int the MWBPs, no BPs are referenced.

To summarise, if your content already complies with MWBP, to achieve compliance with WCAG 1.0, you need to do the following:

For Priority 1

Nothing, content already complies with these checkpoints:

• 2.1 “Ensure that all information conveyed with color is also available without color, for example from context or markup”, covered by USE_OF_COLOR
• 6.1, “Organize documents so they may be read without style sheets”, covered by STYLE_SHEETS_SUPPORT
• 6.3 “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported...”, covered by OBJECTS_OR_SCRIPT
• 12.1, “Title each frame to facilitate frame identification and navigation”, covered by BP NO_FRAMES

Something more effort of some kind or a check, to comply with these checkpoints:

• 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content)..., partly covered by NON-TEXT_ALTERNATIVES, IMAGE_MAPS and @@
• 1.2 “Provide redundant text links for each active region of a server-side image map”, partly covered by NON-TEXT_ALTERNATIVES, IMAGE_MAPS.

Everything (start from scratch), to comply with these checkpoints:

• 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.
• 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.
• 1.5 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.

For Priority 2

Nothing, content already complies with these checkpoints:

• 3.2, “Create documents that validate to published formal grammars”, covered by VALID_MARKUP
• 3.3, “Use style sheets to control layout and presentation”, covered by STYLE_SHEETS_USE
• 3.4, “Use relative rather than absolute units in markup language attribute values and style sheet property values”, covered by BP MEASURES
• 3.5, “Use header elements to convey document structure and use them according to specification”, covered by STRUCTURE
• 7.5, “Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects”, covered by REDIRECTION
• 10.1, “Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user”, covered by POP_UPS
• 12.2, “Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone”, covered by BP NO_FRAMES
• 12.4, “Associate labels explicitly with their controls”, covered by BP CONTROL_LABELLING.

Something more effort of some kind or a check, to comply with these checkpoints:

• @@

Everything (start from scratch), to comply with these checkpoints:

• @@

For Priority 3

Nothing, content already complies with these checkpoints:

• 9.4, “Create a logical tab order through links, form controls, and objects”, covered by TAB_ORDER

Something more effort of some kind or a check, to comply with these checkpoints:

• @@

Everything (start from scratch), to comply with these checkpoints:

• @@

How does it help especially users with disabilities?

Describe how the BP helps users with disabilities above and beyond the benefit to the general user in the mobile context. Users with disabilities benefit from the Mobile Web Best Practices like any other user. This paragraph focuses on the added benefits for their special needs of users with different disabilities. Best Practices that have no specific benefit for users with disabilities beyond that experienced by the general user in the mobile context is marked [no added benefit]

Does it give me WCAG compliance?

Many Web sites wish to ensure that their content is both mobile aware and accessible to users with disabilities by complying with both the MWBPs and Web Content Accessibility Guidelines (WCAG). For a site that complies with the MWBP it is useful to know how much has already been achieved towards accessibility, and how much more could be achieved for little extra effort.

Many BPs correspond directly to WCAG 1.0 checkpoints or WCAG 2.0 success criteria and in these cases complying with one automatically gives compliance with the other, with no extra effort. For example, [USE_OF_COLOR] ensures compliance with WCAG 1.0 checkpoint 2.1, “Ensure that all information conveyed with color is also available without color, for example from context or markup” and WCAG 2.0 success criterion 1.4.1, “Use of Color” with no added effort.

With other BPs, a little extra effort or simply considering a more diverse range of user needs can achieve compliance with WCAG 1.0 checkpoint. For example, [COLOR_CONTRAST] is intended to help moble users with monochrome displays or in poor lighting conditions. By considering also the needs of users with colour deficits (colour blindness) the same BP makes content accessible to more users and ensures compliance with WCAG 1.0 checkpoint “2.2 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” and WCAG 2.0 success criterion 1.4.3 “Contrast (Minimum)”.

Other BPs prohibit the use of features that can cause accessibility barriers. Complying with these BPs ensures that some WCAG checkpoints simply do not apply. For example, [NO_FRAMES], by excluding the use of frames, means that it is not necessary to comply with WCAG 1.0 checkpoint 12.1, “Title each frame to facilitate frame identification and navigation”.

Best Practices and their relationships to WCAG Checkpoints and Success Criteria

List of best practices described in detail:

• ACCESS_KEYS
• AUTO_REFRESH
• AVOID_FREE_TEXT
• BALANCE
• BACKGROUND_IMAGE_READABILITY
• CENTRAL_MEANING
• CLARITY
• COLOR_CONTRAST
• CONTROL_LABELLING
• CONTROL_POSITION
• DEFAULT_INPUT_MODE
• ERROR_MESSAGES
• FONTS
• GRAPHICS_FOR_SPACING
• IMAGE_MAPS
• LINK_TARGET_ID
• MEASURES
• MINIMIZE_KEYSTROKES
• NAVBAR
• NAVIGATION
• NO_FRAMES
• NON-TEXT_ALTERNATIVES
• OBJECTS_OR_SCRIPT
• PAGE_SIZE_USABLE
• PAGE_TITLE
• POP_UPS
• PROVIDE_DEFAULTS
• REDIRECTION
• SCROLLING
• STRUCTURE
• STYLE_SHEETS_SUPPORT
• STYLE_SHEETS_USE
• TAB_ORDER
• TABLES_ALTERNATIVES
• TABLES_LAYOUT
• TABLES_NESTED
• TABLES_SUPPORT
• TESTING
• THEMATIC_CONSISTENCY
• URIS
• USE_OF_COLOR
• VALID_MARKUP

The following BPs are believed to have no added accessibility benefit and no relation to any WCAG provision, and are listed below for completeness:

• CACHING
• CAPABILITIES
• CHARACTER_ENCODING_SUPPORT
• CHARACTER_ENCODING_USE
• CONTENT_FORMAT_PREFERRED
• CONTENT_FORMAT_SUPPORT
• COOKIES
• DEFICIENCIES
• EXTERNAL_RESOURCES
• IMAGES_RESIZING
• IMAGES_SPECIFY_SIZE
• LARGE_GRAPHICS
• LIMITED
• LINK_TARGET_FORMAT
• MINIMIZE
• PAGE_SIZE_LIMIT
• STYLE_SHEETS_SIZE
• SUITABLE

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

How does it help especially users with disabilities?: 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. 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).

Does it give me WCAG 2.0 compliance?: No.

Does it give me WCAG 1.0 compliance?: Providing that access keys are also defined as necessary for form controls (not made explicit in the BP but apparently implicit in “frequently accessed functionality”), this BP also ensures compliance with checkpoint 9.5, “Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls”. If it is not apparent from the content or shown by the device, provide a summary of access keys used in content on a separate page. Perhaps warn that access key assignments may be changed by the user agent (to prevent conflicts) in ways the author cannot predict.

Back to Best Practices list.

[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 help especially 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. Providing a means to stop auto-refresh may help these users if they are aware of it.

Does it give me WCAG 2.0 compliance?: A related success criterion 3.2.5, “Change on Request” requires that refresh be started only by user request, but this BP concerns using auto-refresh started automatically and stopped by user request. If auto-refresh is used compliance is not achieved. However, if auto-refresh is not used at all, this does ensure compliance with the success criterion.

Does it give me WCAG 1.0 compliance?: A related checkpoint is 7.4, “Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages”. At the time of writing, some user agents allow the user to disable auto-refresh, but others do not. If auto-refresh is used (under the provision of the BP to inform the user and provide a means to deactivate it) the checkpoint is not complied with (WCAG requires that the user agent be used to turn it off, while the BP requires the content to do it). However, if auto-refresh is not used at all, this does ensure compliance with the checkpoint.

Back to Best Practices list.

[AVOID_FREE_TEXT] Avoid free text entry where possible.

How does it help especially users with disabilities?: As described in the explanation of [MINIMIZE_KEYSTROKES] in this document, this BP is especially beneficial to users with limited dexterity. It is not related to any specific WCAG 1.0 checkpoint.

Does it give me WCAG 2.0 compliance?: No.

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

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

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

Does it give me WCAG 2.0 compliance?: No. However, it helps to achieve compliance with 1.4.3 Contrast (Minimum) and 1.4.5 Contrast (Enhanced) as described in COLOR_CONTRAST.

Does it give me WCAG 1.0 compliance?: No. However it helps achieve compliance with checkpoint 6.1, Organize documents so they may be read without style sheets and 2.2, 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 as described in COLOR_CONTRAST.

Back to Best Practices list.

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

Does it give me WCAG compliance?: No.

Back to Best Practices list.

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

How does it help especially users with disabilities?: Putting the main content first helps keyboard-only users whether in a mobile context or not. It may also help users with cognitive disabilities who have difficulty locating the central information in a page full of navigation links. Users who can only read part of the page at a time, and who tend to start at the beginning, such as those using screen readers or sreeen magnifiers benefit from this BP.

Does it give me WCAG compliance?: For WCAG 1.0, this BP corresponds to 12.3, “Place distinguishing information at the beginning of headings, paragraphs, lists, etc.”. However, where the checkpoint is described as applicable to paragraphs, in the mobile context these units of content are often the complete page. It also relates to the spirit of WCAG 1.0 checkpoint 12.3, “Divide large blocks of information into more manageable groups where natural and appropriate”, although, like [PAGE_SIZE_USABLE], in a way not explicitly contemplated in the guidelines. This WCAG checkpoint is much broader in scope than the BP. For WCAG 2.0, @@

Back to Best Practices list.

[CLARITY] Use clear and simple language

How does it help especially users with disabilities?: Refer to WCAG 1.0 Core Techniques: Comprehension.

Does it give me WCAG compliance?: This BP goes some of the way to ensuring compliance with 14.1, “Use the clearest and simplest language appropriate for a site's content”, although the BP is concerned primarily with context of use, which was not contemplated in WCAG 1.0. WCAG emphasizes writing style and thematic content in all contexts. It also covers (in the explanation) 13.8 “Place distinguishing information at the beginning of headings, paragraphs, lists, etc.”

Back to Best Practices list.

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

How does it help especially users with disabilities?: People with low vision often have difficulty reading text that does not contrast with its background. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Adequate colour and brightness contrast make content readable. However, the BP is concerned with unfavourable ambient light and the ability of devices to display contrasting colour at all, while users with disabilities are also concerned about colour blindness and colour perception deficits, which may lead to different results.

Does it give me WCAG 2.0 compliance?: No. However, it may help ensure (using additional criteria) compliance with 1.4.3 Contrast (Minimum) and 1.4.5 Contrast (Enhanced). Note that WCAG 2.0 suggests a Contrast Ratio and the size of text to which the ratio applies.

Does it give me WCAG 1.0 compliance?: No. However, it may ensure (using additional criteria) compliance with WCAG 1.0 checkpoint 2.2 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. Note that WCAG 2.0 suggests a Contrast Ratio and the size of text to which the ratio applies.

Back to Best Practices list.

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

How does it help especially users with disabilities?: Screen reader users who are unable visually determine the relationship between controls and their labels need to determine from markup which label identifies each form control.

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 12.4, “Associate labels explicitly with their controls” with no further effort.

Back to Best Practices list.

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

How does it help especially users with disabilities?: If controls are not explicitly associated with their labels (as described in the [CONTROL_LABELLING] best practice) screen readers 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.

Does it give me WCAG compliance?: This BP corresponds to WCAG 1.0 checkpoint 10.2 “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”. While the BP is concerned with reflowing and adapting content, WCAG is concerned to enable screen readers to determine the association in the absence of an explicit association in markup. However, this association of form labels with their controls by position for correct interpretation by screen readers is a convention, not fully described in W3C recommendations (WCAG 1.0 describes positioning of text input and list boxes but not checkboxes and radio buttons). The description in the BP is not adequate for accessibility purposes, and following the BP does not ensure compliance with the WCAG 1.0 checkpoint.

Tip: Use explcitly associated labels (refer to [CONTROL_LABELLING]), but if you can not, then avoid nesting the control inside the label element as it is not supported in an accessible way by most user agents.

[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 help especially users with disabilities?: This BP helps users in the same way as described in the [PROVIDE_DEFAULTS] section of this document.

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

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

How does it help especially 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 acion to take. This BP aids understanding.

Does it give me WCAG 1.0 compliance?: No, but it is related to checkpoint 13.4, “Use navigation mechanisms in a consistent manner” in that the BP encourages provision of consistent navigation in error pages.

Back to Best Practices list.

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

How does it help especially users with disabilities?: If visual font effects achieved using CSS are used, non-visual users may have difficulty understanding the meaning of content. Refer also to the explanation of the [STYLE_SHEETS_SUPPORT] best practice in this document.

Does it give me WCAG 1.0 compliance?: No, but it goes some of the way to complying with checkpoint 6.1, “Organize documents so they may be read without style sheets”. As the font elements described by the BP are deprecated in recent versions of HTML, it also goes some way to meeting WCAG 1.0 checkpoint 11.2, “Avoid deprecated features of W3C technologies”.

Back to Best Practices list.

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing

How does it help especially users with disabilities?: no_added_benefit.

Does it give me WCAG 1.0 compliance?: No, but if you do use images for spacing that goes against WCAG 1.0 checkpoint 3.1, “When an appropriate markup language exists, use markup rather than images to convey information” and 3.3, “Use style sheets to control layout and presentation”.

Back to Best Practices list.

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

How does it help especially users with disabilities?: no_added_benefit.

Does it give me WCAG compliance?: If image maps are used, this BP does not give compliance with any WCAG provision. For WCAG 2.0, if image maps are not used at all, then it is unnecessary to provide the text alternatives for them required by success criteria 1.1.1, “Non-text Content”, 2.4.4, “Link Purpose (Context)” and 2.4.8, “Link Purpose (Link Text)”. For WCAG 1.0, if image maps are not used at all, then it is unnecessary to provide the text alternatives for them required by checkpoint 1.1 “Provide a text equivalent for every non-text element” or the keyboard shortcuts for them required by 9.5, “Provide keyboard shortcuts to important links (including those in client-side image maps), ...”; checkpoints 1.2, “Provide redundant text links for each active region of a server-side image map” and 9.1, “Provide client-side image maps instead of server-side image maps...” do not apply.

Back to Best Practices list.

[LINK_TARGET_ID] Clearly identify the target of each link

How does it help especially users with disabilities?: Refer to WCAG 1.0 HTML Techniques: Link text. As the BP says “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 this is true for any user, those with diabilities may have greater difficulty in judging whether the retrieved content is what they expected and of returning to the location of the link in the previous page. Refer to “Link text not descriptive” in Summary of Experience of Content Features by Users section.

Does it give me WCAG compliance?: For WCAG 1.0 , this BP goes some way to ensuring compliance with checkpoint 13.1, “Clearly identify the target of each link”. However, to ensure accessibility it is important to understand that the user may read (or hear) the links in a page as part of a list of links without surrounding contextual information. For this reason it is important that the link text not lose its meaning when read out of context. Refer to WCAG 1.0 HTML Techniques: Link text gives more information. For WCAG 2.0, this BP ensures compliance with success criteria 2.4.4 Link Purpose (Context) and 2.4.8, “Link Purpose (Link Text)”.

Back to Best Practices list.

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

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 3.4, “Use relative rather than absolute units in markup language attribute values and style sheet property values” with no further effort.

Back to Best Practices list.

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum

How does it help especially 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 1.0 checkpoint.

Does it give me WCAG compliance?: The intention of this BP is the use of keyboard shortcuts (referred to confusingly as “navigation keys”). If this is done, then this BP ensures compliance with WCAG 1.0 checkpoint 9.5, “Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls”. However, when complying with the BP it is important to be aware that WCAG is more explicit in what it applies to than is the BP (which specifies only “items”).

Back to Best Practices list.

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

How does it help especially users with disabilities?: Implementing this BP benefits users of screen magnifiers and others who have a restricted field of vision as it ensures that they are more easily able to locate the main content of the page. Users with a motor disability or who use the keyboard for navigation will be able to view the main content of the page without difficult scrolling.

Does it give me WCAG compliance?: This BP deals with an aspect not considered in WCAG. However, conceptually identifying the navigation mechanisms will ultimately help content designers understand and provide the functionality needed. For WCAG 1.0, it will help compliance with checkpoints 13.5, “Provide navigation bars to highlight and give access to the navigation mechanism” and 13.6, “Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group”. For WCAG 2.0, it will help compliance with guideline 2.4, “Provide ways to help users with disabilities navigate, find content and determine where they are”.

Back to Best Practices list.

[NAVIGATION] Provide consistent navigation mechanisms

How does it help especially users with disabilities?: Refer to WCAG 1.0 Core Techniques: Navigation.

Does it give me WCAG compliance?: For WCAG 1.0, complying with this BP also ensures compliance with checkpoint 13.4, “Use navigation mechanisms in a consistent manner”, but considering the aspects covered in WCAG 1.0 Core Techniques: Navigation will clarify what is needed for all users. For WCAG 2.0, it goes some way to ensuring compliance with 3.2.3 “Consistent Navigation”, although WCAG is more detailed and specific (“same relative order”) than the MWBP (“same navigation”).

Back to Best Practices list.

[NO_FRAMES] Do not use frames

How does it help especially users with disabilities?: While correctly designed and labelled 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.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures that checkpoints 12.1, “Title each frame to facilitate frame identification and navigation” and 12.2, “Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone” do not apply to the content.

Back to Best Practices list.

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

How does it help especially 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. Refer to WCAG 1.0 Core Techniques: Text equivalents. 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.

Does it give me WCAG compliance?: Providing a text equivalent for every non-text element ensures compliance with WCAG 1.0 checkpoint 1.1 “Provide a text equivalent for every non-text element”. However, it is important to remember that non-text content is more than just images. The tests suggested in the BPs may not lead to adequately accessible content. Avoiding CSS image replacement and pictures of words implies using text and markup, thus avoiding the need for text alternatives and the accessibility problems caused by these techniques. This aspect of the BP goes some way to complying with WCAG 1.0 checkpoint 3.1, “When an appropriate markup language exists, use markup rather than images to convey information”.

Tip: Using the alt and longdesc attributes adequately is not always a simple matter and the BPs provide no further guidance. Refer to WCAG 1.0 HTML techniques Short text equivalents for images (“alt-text”) and Long descriptions of images for further guidance.

Tip: As stated in the BP, if the user agent is not known to support the longdesc attribute of the img element (and additionally, until assistive technology is known to support it adequately), do rely on it. Provide in addition a separate [D] link adjacent to the image. Refer to WCAG 1.0 HTML technique Invisible d-links (note that this technique should not be considered deprecated in the mobile context, which was not anticipated when the techniques were written).

Back to Best Practices list.

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script

How does it help especially users with disabilities?: Users may not be able or willing to install or use the plugins necessary for embedded objects. Users may be unable or unwilling to use script. Browsers may not support scripting or it may be disabled. This BP recommends using onclick for script rather than onkey and onmouse event handlers. In practice onclick is device independent and allows interaction with mouse or keyboard. Refer also to Interaction and navigation requires mouse in “Summary of Experience of Content Features by Users” section.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 6.3 “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported...”, but be sure to follow the further guidance given in WCAG 1.0 and accompanying techniques. Using onclick for script rather than onkey and onmouse event handlers helps ensure compliance with WCAG 1.0 checkpoint 6.4, “For scripts and applets, ensure that event handlers are input device-independent”.

Back to Best Practices list.

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions

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

Does it give me WCAG compliance?: No, but this BP goes some way toward complying with WCAG 1.0 checkpoint 12.3, “Divide large blocks of information into more manageable groups where natural and appropriate”. However the WCAG checkpoint is much broader in scope, covering all usage contexts.

Back to Best Practices list.

[PAGE_TITLE] Provide a short but descriptive page title

How does it help especially 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 in “Summary of Experience of Content Features by Users” section.

Does it give me WCAG compliance?: This BP goes some of the way to compliance with WCAG 1.0 checkpoint 13.2, “Provide metadata to add semantic information to pages and sites”.

Back to Best Practices list.

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

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 10.1, “Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user” (by avoiding the problem: the BP is more restrictive). For WCAG 2.0 it ensures partial compliance (in the pop-up windows situation) with success criterion 3.2.5, “Change on Request”.

Back to Best Practices list.

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible

How does it help especially 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.

Does it give me WCAG 2.0 compliance?: No.

Does it give me WCAG 1.0 compliance?: Partially. If default values are used for all text controls this ensures compliance with checkpoint 10.4 “Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas”. However, there is debate about the need for such text, as user agents do now handle empty input boxes correctly.

Back to Best Practices list.

[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 help especially users with disabilities?: Like auto-refresh, using markup for redirection can confuse users, especially:

• Users who have difficulty concentrating attention, who may become confused when the content changes.
• People who read slowly may not have understood what is happening before they have finished reading.
• Screen readers may begin reading the page from the beginning, only to be interrupted by redirect or auto-refresh.

Does it give me WCAG 2.0 compliance?: Partially. It ensures that redirection is initiated only by user request, and therefore partial compliance (in the automatic redirects situation) with success criterion 3.2.5, “Change on Request”.

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 7.5, “Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects”.

Back to Best Practices list.

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

How does it help especially 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.

Does it give me WCAG 2.0 compliance?: @@.

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

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

How does it help especially 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.

Does it give me WCAG 2.0 compliance?: Yes, this BP ensures compliance with success criterion 2.4.9 Section Headings with no further effort. It helps towards compliance with success criterion 1.3.1 Info and Relationships.

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 3.5, “Use header elements to convey document structure and use them according to specification” with no further effort. If content is structured using section headings this will help towards achieving compliance with checkpoint 6.1, “Organize documents so they may be read without style sheets”.

Tip: Although the BP has a generic title covering all structural elements, it only mentions section headings. Using other commonly-accepted structural elements not mentioned in the BP can improve usability for mobile users as well as accessibility, and give go some way toward compliance with WCAG success criterion 1.3.1 Info and Relationships. These elements include lists, quotations and citations, table markup, and semantic aspects like emphasis.

Back to Best Practices list.

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

How does it help especially 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. Visual font effects defined in CSS can not be relied upon in the mobile device and many users may not perceive them. Refer to WCAG 1.0 CSS Techniques: Using style sheet positioning and markup to transform gracefully and the explanation of the [FONTS] best practice in this document.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 6.1, “Organize documents so they may be read without style sheets” with no further effort. The BP recognises that style sheets may not be supported and that users may turn them off. However, it is important to remember that some users (for example, non-visual) may simply not perceive (see) their effect.

Back to Best Practices list.

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

How does it help especially users with disabilities?: Using CSS allows separation of content and presentation, enabling users to adjust presentation to suit their needs.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 3.3, “Use style sheets to control layout and presentation” with no further effort.

Back to Best Practices list.

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

How does it help especially 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 Summary of Experience of Content Features by Users section.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: Yes, this BP ensure compliance with checkpoint 9.4, “Create a logical tab order through links, form controls, and objects” with no further effort.

Back to Best Practices list.

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

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: No, but if tables are not used then the checkpoints under Guideline 5, “Create tables that transform gracefully” do not apply.

Back to Best Practices list.

[TABLES_LAYOUT] Do not use tables for layout

How does it help especially users with disabilities?: Reading order: Using tables can easily cause incorrect reading order (the apparent visual sequence is not the same as that in the markup). Flexibility: if content is formatted with CSS, users can modify the style to suit their needs, with tables the content is locked in a grid. Browser support: not all browsers support tables, for example text-only browsers used with Braille output and many mobile browsers. Printing: tables are difficult to print, often not fitting on the page.

Does it give me WCAG 2.0 compliance?: No, but if tables are not used for layout, this may help towards compliance with 1.3.2 Meaningful Sequence.

Does it give me WCAG 1.0 compliance?: No, but if tables are not used for layout, then content complies with checkpoint 5.3, “Do not use tables for layout unless the table makes sense when linearized”. In that case 5.4, “If a table is used for layout, do not use any structural markup for the purpose of visual formatting”, does not apply.

Back to Best Practices list.

[TABLES_NESTED] Do not use nested tables

How does it help especially 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.

Does it give me WCAG 2.0 compliance?: @@.

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

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

How does it help especially users with disabilities?: no_added_benefit as tables may be used. Refer to [TABLES_ALTERNATIVES] for an explanation of the benefits of avoiding tables.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: No, but if tables are not used in any adaptation of the content served, then the checkpoints under Guideline 5, “Create tables that transform gracefully” does not apply. It goes some way to ensuring compliance with WCAG 1.0 checkpoint 3.3, “Use style sheets to control layout and presentation”.

Back to Best Practices list.

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

How does it help especially 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 also encourages 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”.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: No.

Tip: You can improve accessibility when performing testing by involving users with a range of abilities (not only evaluation and development staff). Refer to the WAI resource “Involving Users in Web Accessibility Evaluation” for more information.

Back to Best Practices list.

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

How does it help especially users with disabilities?: 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.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

[URIS] Keep the URIs of site entry points short

How does it help especially 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. Keeping the URIs short can help both groups of users. This BP deals with an aspect not considered in WCAG 1.0.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: No.

Back to Best Practices list.

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

How does it help especially users with disabilities?: This BP benefits people with visual disabilities. Users may not be able to see colours or identify them correctly (colour deficit, colour 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 percieve information expressed by colour alone.

Does it give me WCAG 2.0 compliance?: Yes, this BP ensures compliance with success criterion 1.4.1 Use of Color with no further effort. However, it is important to taken into account that unlike the MWBP, the accessibility guidelines specify the ways that color may be used.

Does it give me WCAG 1.0 compliance?: Yes, this BP ensures compliance with checkpoint 2.1, “Ensure that all information conveyed with color is also available without color, for example from context or markup” with no added effort. However, it is important to taken into account that unlike the MWBP, the accessibility guidelines specify the ways that color may be used.

Back to Best Practices list.

[VALID_MARKUP] Create documents that validate to published formal grammars

How does it help especially users with disabilities?: Refer to WCAG 1.0 HTML Techniques: The !DOCTYPE statement.

Does it give me WCAG 2.0 compliance?: @@

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with checkpoint 3.2, “Create documents that validate to published formal grammars” with no further effort. If the markup is the most recent version of a W3C recommendation it also helps to ensure compliance with WCAG 1.0 checkpoint 11.1, “Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported”. It helps with compliance with 11.2, “Avoid deprecated features of W3C technologies”.

Back to Best Practices list.

4. WCAG Compliance and the Mobile Web

This section describes how different WCAG checkpoints help Mobile Web users and how compliance with these checkpoints can help comply with the Mobile Web Best Practices 1.0 (MWBP). For content that already complies with WCAG at different levels, it outlines what may need to be done to comply with all of the MWBP (“Extending from WCAG 2.0 to MWBP 1.0”).

How Does it Help Users in the Mobile Context?

This section describes how the Web Content Accessibility Guidelines help the general user in the mobile context above and beyond the special benefit for users with disabilities. Mobile users may benefit from the [WCAG] as do users with disabilities. This paragraph focuses on the extra benefits for the special needs of the general user of mobile devices. Checkpoints and guidelines that have no specific benefit for mobile users beyond that experienced by the user with disabilities is marked [no added benefit].

Does it give me MWBP 1.0 compliance?

Many Web sites wish to ensure that their content is both mobile aware and accessible to users with disabilities by complying with both the MWBPs and WCAG. For a site that complies with [WCAG] it is useful to know how much has already been achieved, and how much more could be achieved for little extra effort.

Many WCAG guidelines, checkpoints, and success criteria correspond directly to Mobile Web Best Practices 1.0 provisions, and complying with one automatically ensures compliance with the other, with no extra effort. For example, WCAG 2.0 success criterion 1.4.1, “Use of Color” ensures compliance with BP [USE_OF_COLOR] “Ensure that information conveyed with color is also available without color”.

With other [WCAG] provisions, a little extra effort or simply considering the diversity of devices and environmental factors of the mobile context can help achieve compliance with a [MWBP] best practice. For example, @@xxx.

Other [WCAG] provisions prohibit the use of features that can cause problems in the mobile context. Complying with these guidelines or checkpoints ensures that some BPs simply do not apply. For example, @@xxx.

Many [WCAG] provisions have no relation to any BP and this is also noted.

Extending from WCAG 2.0 to MWBP 1.0

This section provides guidance on the “upgrade path” from WCAG 2.0 compliance to MWBP 1.0. What follows is a summary of the detailed information for each success criterion that follows it. For each of the WCAG 2.0 levels already achieved, there are four possible degrees of effort required, in each case simplified with four keywords (nothing, something, everything):

[Insert here duplicate list of levels of effort when finalised]

To summarise, if your content already complies with WCAG 2.0, to achieve compliance with MWBP 1.0, you need to do the following:

Level A Compliance Achieved

Nothing, content already complies with these BPs:

• CONTROL_LABELLING, covered by success criterion 1.3.1 Info and Relationships
• NON-TEXT_ALTERNATIVES, covered by success criterion 1.1.1 Non-text Content”
• PAGE_TITLE, covered by 2.4.2 Page Titled
• STRUCTURE, covered by success criterion 1.3.1 Info and Relationships and partially by 1.4.1 Use of Color
• STYLE_SHEETS_SUPPORT, covered by success criterion 1.3.1 Info and Relationships
• STYLE_SHEETS_USE, covered by success criterion 1.3.1 Info and Relationships
• TAB_ORDER, covered by 2.4.3 Focus Order
• USE_OF_COLOR, covered by success criterion 1.4.1 Use of Color

Something more effort of some kind or a check, to comply with these BPs:

• AUTO_REFRESH, partially covered by 3.2.1 On Focus and 3.2.2 On Input
• LINK_TARGET_ID, partially covered by 2.4.4 Link Purpose (Context).
• OBJECTS_OR_SCRIPT, partially covered by 2.1.1 Keyboard.
• POP_UPS, partially covered by 3.2.1 On Focus and 3.2.2 On Input
• REDIRECTION, partially covered by 3.2.1 On Focus and 3.2.2 On Input
• VALID_MARKUP, possibly covered by 4.1.1 Parsing.

Everything (start from scratch), to comply with these BPs:

• ACCESS_KEYS
• AVOID_FREE_TEXT
• BALANCE
• BACKGROUND_IMAGE_READABILITY
• CENTRAL_MEANING
• CLARITY
• COLOR_CONTRAST
• CONTROL_POSITION
• DEFAULT_INPUT_MODE
• ERROR_MESSAGES
• FONTS
• GRAPHICS_FOR_SPACING
• IMAGE_MAPS
• MEASURES
• MINIMIZE_KEYSTROKES
• NAVBAR
• NAVIGATION
• NO_FRAMES
• PAGE_SIZE_USABLE
• PROVIDE_DEFAULTS
• SCROLLING
• TABLES_ALTERNATIVES
• TABLES_LAYOUT
• TABLES_NESTED
• TABLES_SUPPORT
• TESTING
• THEMATIC_CONSISTENCY
• URIS

Level AA Compliance Achieved

Nothing, content already complies with these BPs:

• All BPs covered by level A requiring nothing further (eventually include here rather than link), and the following
• COLOR_CONTRAST, covered by success criterion 1.4.3 Contrast (Minimum)
• LINK_TARGET_ID, covered by 2.4.8 Link Purpose (Link Text).
• MEASURES, covered by 1.4.4 Resize text

Something more effort of some kind or a check, to comply with these BPs:

• All BPs partially covered by level A requiring something further (eventually include here rather than link).

Everything (start from scratch), to comply with these BPs (all of the Everything list from Level A except those covered in Nothing and Something lists at this level):

• ACCESS_KEYS
• AVOID_FREE_TEXT
• BALANCE
• BACKGROUND_IMAGE_READABILITY
• CENTRAL_MEANING
• CLARITY
• DEFAULT_INPUT_MODE
• ERROR_MESSAGES
• FONTS
• GRAPHICS_FOR_SPACING
• IMAGE_MAPS
• MINIMIZE_KEYSTROKES
• NAVBAR
• NAVIGATION
• NO_FRAMES
• PAGE_SIZE_USABLE
• PROVIDE_DEFAULTS
• SCROLLING
• TABLES_ALTERNATIVES
• TABLES_LAYOUT
• TABLES_NESTED
• TABLES_SUPPORT
• TESTING
• THEMATIC_CONSISTENCY
• URIS

Level AAA Compliance Achieved

Nothing, content already complies with these BPs:

• All BPs covered by level A requiring nothing further and BPs covered by level AA requiring nothing further (eventually include here rather than link) and the following:
• AUTO_REFRESH, covered by 3.2.2 On Input
• COLOR_CONTRAST, covered by success criterion 1.4.5 Contrast (Enhanced) [@@ also under level AA]
• POP_UPS, covered by 3.2.2 On Input
• STRUCTURE, covered by 2.4.9 Section Headings

Something more effort of some kind or a check, to comply with these BPs:

• All BPs partially covered by level A requiring something further and BPs partially covered by level AA requiring something further, and the following
• OBJECTS_OR_SCRIPT, partially covered by 2.1.2 Keyboard (No Exception).
• REDIRECTION, may be covered by 3.2.2 On Input

Everything (start from scratch), to comply with these BPs (all of the Everything list from Level AA except those covered in Nothing and Something lists at this level):

• ACCESS_KEYS
• AVOID_FREE_TEXT
• BALANCE
• BACKGROUND_IMAGE_READABILITY
• CENTRAL_MEANING
• CLARITY
• DEFAULT_INPUT_MODE
• ERROR_MESSAGES
• FONTS
• GRAPHICS_FOR_SPACING
• IMAGE_MAPS
• MINIMIZE_KEYSTROKES
• NAVBAR
• NAVIGATION
• NO_FRAMES
• PAGE_SIZE_USABLE
• PROVIDE_DEFAULTS
• SCROLLING
• TABLES_ALTERNATIVES
• TABLES_LAYOUT
• TABLES_NESTED
• TABLES_SUPPORT
• TESTING
• THEMATIC_CONSISTENCY
• URIS

The section below describes the relationship of each WCAG 2.0 success criterion to the MWBP 1.0, the section following it describes the relationship of WCAG 1.0 to the MWBP 1.0.

WCAG 2.0 Success Criteria

List of success criteria described in detail:

• 1.1.1 Non-text Content”
• 1.2.1 Captions (Prerecorded)
• 1.2.2 Audio Description or Full Text Alternative
• 1.2.3 Captions (Live)
• 1.2.4 Audio Description
• 1.2.6 Audio Description (Extended)
• 1.2.7 Full Text Alternative
• 1.3.1 Info and Relationships
• 1.4.1 Use of Color
• 1.4.3 Contrast (Minimum)
• 1.4.4 Resize text
• 1.4.5 Contrast (Enhanced)
• 1.4.7 Resize and Wrap
• 2.1.1 Keyboard
• 2.1.2 Keyboard (No Exception)
• 2.2.3 Pausing
• 2.4.2 Page Titled
• 2.4.3 Focus Order
• 2.4.4 Link Purpose (Context)
• 2.4.6 Labels Descriptive
• 2.4.8 Link Purpose (Link Text)
• 2.4.9 Section Headings
• 3.2.1 On Focus
• 3.2.2 On Input
• 3.2.5 Change on Request
• 3.3.4 Labels or Instructions
• 4.1.1 Parsing
• 4.1.2 Name, Role, Value

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

• 1.2.5 Sign Language
• 1.3.2 Meaningful Sequence
• 1.3.3 Size, Shape, Location
• 1.4.2 Audio Turnoff
• 1.4.6 Low or No Background Audio
• 2.2.1 Timing
• 2.2.2 Blinking
• 2.2.4 Timing
• 2.2.6 Re-authenticating
• 2.3.1 Three Flashes or Below Threshold
• 2.3.2 Three Flashes
• 2.4.5 Multiple Ways
• 3.1.1 Language of Page
• 3.1.2 Language of Parts
• 3.1.3 Unusual Words
• 3.1.4 Abbreviations
• 3.1.5 Reading Level
• 3.1.6 Pronunciation
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification
• 3.3.1 Error Identification
• 3.3.2 Error Suggestion
• 3.3.3 Error Prevention (Legal, Financial, Data)
• 3.3.5 Help
• 3.3.6 Error Prevention (All)

1.1.1 Non-text Content

While accessibility is concerned that users may be unable to percieve non-text content due to sensory limitations, in the mobile context the emphasis is generally on images and the cost (in time and in network and processor resources) of displaying them, as the Mobile Web Best Practices document explains, Downloading images to a mobile device 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.

How does it especially help mobile users? WCAG requires a text equivalent for all non-text content, including images. This enables users in the mobile context to read content without downloading images.

Does it give me MWBP compliance?: This checkpoint also ensures compliance with BP NON-TEXT_ALTERNATIVES “Provide a text equivalent for every non-text element” with no further effort.

Back to list of WCAG 2.0 checkpoints

1.2.1 Captions (Prerecorded)

How does it especially help mobile users? Mobile devices are often used in situations with significant background noise that makes it difficult to hear the audio track of multimedia content. It public places it may be socially unacceptable to listen to the soundtrack. In these situations captions enable the user to understand the multimedia content.

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.2 Audio Description or Full Text Alternative

How does it especially help mobile users? Unlikely to provide any additional benefit (if audio description is supported by device, might concievably help with understanding video on small screen)

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.3 Captions (Live)

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.2.1 Captions (Prerecorded) in this document.

Does it give me MWBP compliance?: No

Back to list of WCAG 2.0 checkpoints

1.2.4 Audio Description

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.2.2 Audio Description or Full Text Alternative in this document.

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.6 Audio Description (Extended)

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.2.2 Audio Description or Full Text Alternative in this document.

Does it give me MWBP compliance?: No.

Back to list of WCAG 2.0 checkpoints

1.2.7 Full Text Alternative

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.2.2 Audio Description or Full Text Alternative in this document.

Does it give me MWBP compliance?: Partially. It goes some way to complying with NON-TEXT_ALTERNATIVES [@@ Do implementers of MWBP really provide text alternatives for all non-text content as defined by WAI Glossary?].

Back to list of WCAG 2.0 checkpoints

1.3.1 Info and Relationships

How does it especially help mobile users? It allows change and transformation of content in a more flexible way to suit each device.

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

How does it especially help mobile users? Mobile devices may have monochrome screens, often do not have good color contrast and are often used in less-than-ideal lighting conditions and so like non-visual users or those with colour pereception deficit they may be unable to percieve information conveyed by colour. This success criterion ensures that users who cannot perceive colour correctly for whatever reason will be able to understand and operate the content.

Does it give me MWBP compliance?: Yes, this success criterion 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)

How does it especially help mobile users? Mobile devices may have monochrome screens. Users in a mobile context may view the screen in unfavorable lighting conditions. Adequate color contrast will also help these users.

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

How does it especially help mobile users? Providing options within the content to switch between layouts that use a variety of font sizes may make for a better experience for users with small screens.

Does it give me MWBP compliance?: Yes, some of the WCAG Techniques, such as using named font sizes, em units or percentages ensure compliance with MEASURES with no further effort.

Back to list of WCAG 2.0 checkpoints

1.4.5 Contrast (Enhanced)

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.4.3 Contrast (Minimum) in this document

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.7 Resize and Wrap

How does it especially help mobile users? While the success criterion is concerned with increasing text to a size larger than that defined by the content designer, the user in the mobile context will have a small screen and scrolling may be necessary with less increase in text size. This SC helps to ensure that all text is visible on a small screen without horizontal screening. Refer also to 1.4.4 Resize text in this document.

Does it give me MWBP compliance?: As described for 1.4.4 Resize text in this document.

Back to list of WCAG 2.0 checkpoints

2.1.1 Keyboard

How does it especially help mobile users? Mobile devices typically lack a pointing device (like a mouse) and therefore this success criterion benefits the typical user regardless of disability. Refer also to Interaction and navigation requires mouse in “Summary of Experience of Content Features by Users” section.

Does it give me MWBP compliance?: No, however, 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”). Unlike 2.1.2 Keyboard (No Exception), this success criterion allows for any function requires input that depends on the path of the user's movement and not just the endpoints, but this does not affect MWBP compliance.

Back to list of WCAG 2.0 checkpoints

2.1.2 Keyboard (No Exception)

The description under 2.1.1 Keyboard is applicable.

Back to list of WCAG 2.0 checkpoints

2.2.3 Pausing

How does it especially help mobile users? Conent that moves, scrolls or auto-updates may be difficult to see with the reduced size of the mobile viewport. Blinking text may be especially difficult to see on the small screen and in poor lighting conditions. Refer to Content blinks, moves, scrolls or auto-updates in “Summary of Experience of Content Features by Users” section.

Does it give me MWBP compliance?: No

Back to list of WCAG 2.0 checkpoints

2.4.2 Page Titled

How does it especially help mobile users? Like users with no vision or limited field of vision, or cognitive disability, mobile users with small screens may have difficulty scanning and summarising the overall content of a page. Perhaps the most useful item of metadata for a page is a descriptive page title, to provide a quick description of the content of a page.

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

Tip: The title may be trunctated 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

How does it especially help mobile users? Mobile users are unlikely to have a pointing device so keyboard is the primary means of navigation, making focus order especially important. Refer to “Focus (tab) order does not match logical document content sequence” in Summary of Experience of Content Features by Users section.

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 (Context)

How does it especially help mobile users? Users of mobile devices may suffer undue delay and cost as a result of following links due to network charges and device limitations, so it is important to inform them of the purpose of the link. Refer to “Link text not descriptive” in Summary of Experience of Content Features by Users section.

Does it give me MWBP compliance?: Partially, 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

How does it especially help mobile users? No added benefit.

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.8 Link Purpose (Link Text)

How does it especially help mobile users? Refer to 2.4.4 Link Purpose (Context). Refer to “Link text not descriptive” in Summary of Experience of Content Features by Users section.

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.9 Section Headings

How does it especially help mobile users? Section headings allow ...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.

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

How does it especially help mobile users? Change of user agent: Using a mobile device, launching a new application to render content is especially heavy on processor usage and battery life and should be avoided unless the user has requested it. Change of viewport: Many mobile devices cannot support more than one window and consequently, attempting to open one will have unpredictable results. Even where mobile devices do support multiple windows, their use is especially problematic. Opening new windows when an element recieves focus is especially difficult for the mobile user. Change of focus: Navigation may be especially difficult with a reduced keyboard, and the reduced viewport of the mobile device may lead to the visual user becoming disoriented. Change of content: Auto-refreshing pages ... 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. also 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...

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

How does it especially help mobile users? In much the same way as 3.2.1 On Focus.

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

How does it especially help mobile users? In much the same way as 3.2.1 On Focus.

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.4 Labels or Instructions

How does it especially help mobile users? Content adaptation and small screens may result in the visual relationahip between labels and controls becoming lost. An explicit association enables the user agent to render them as intended.

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

Back to list of WCAG 2.0 checkpoints

4.1.1 Parsing

How does it especially help mobile users? Mobile user agents are very diverse and it is not possible to be sure that they will behave as expected if invalid markup is used.

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

How does it especially help mobile users? Similar to the benefit described for 3.3.4 Labels or Instructions.

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

Extending from WCAG 1.0 to MWBP 1.0

This section provides guidance on the “upgrade path” from WCAG 1.0 compliance to MWBP 1.0. What follows is a summary of the detailed information for each success criterion that follows it. For each of the WCAG 1.0 priorities (1, 2 and 3) already achieved, there are four possible degrees of effort required, in each case simplified with four keywords (nothing, something, everything):

[Insert here duplicate list of levels of effort when finalised]

To summarise, if your content already complies with WCAG 1.0, to achieve compliance with MWBP 1.0, you need to do the following:

Priority 1 Checkpoints Compliance Achieved

Nothing, content already complies with these BPs:

• NON-TEXT_ALTERNATIVES, covered by 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content)...
• @@

Something more effort of some kind or a check, to comply with these BPs:

• @@

Everything (start from scratch), to comply with these BPs:

• See list of BPs believed to have no relation to any WCAG provision

Priority 1 and 2 Checkpoints Compliance Achieved

Nothing, content already complies with these BPs:

• @@

Something more effort of some kind or a check, to comply with these BPs:

• @@

Everything (start from scratch), to comply with these BPs:

• See list of BPs believed to have no relation to any WCAG provision

Priority 1, 2 and 3 Checkpoints Compliance Achieved

Nothing, content already complies with these BPs:

• @@

Something more effort of some kind or a check, to comply with these BPs:

• @@

Everything (start from scratch), to comply with these BPs:

• See list of BPs believed to have no relation to any WCAG provision

WCAG 1.0 Checkpoints

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

• 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation
• @@ list to be completed

List of checkpoints described in detail:

• 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content)...
• 1.2 Provide redundant text links for each active region of a server-side image map.
• 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.
• 1.5 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.
• 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.
• 2.2 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. [Priority 2 for images, Priority 3 for text].
• 3.1 When an appropriate markup language exists, use markup rather than images to convey information.
• 3.2 Create documents that validate to published formal grammars.
• 3.3 Use style sheets to control layout and presentation.
• 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.
• 3.5 Use header elements to convey document structure and use them according to specification.
• 3.6 Mark up lists and list items properly.
• 4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
• 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.
• 4.3 Identify the primary natural language of a document.
• 5.1 For data tables, identify row and column headers.
• 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
• 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
• 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
• 5.5 Provide summaries for tables.
• 5.6 Provide abbreviations for header labels.
• 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
• 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.
• 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• 6.4 For scripts and applets, ensure that event handlers are input device-independent.
• 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.
• 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.
• 7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).
• 7.3 Until user agents allow users to freeze moving content, avoid movement in pages.
• 7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
• 7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
• 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
• 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
• 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.
• 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.
• 9.4 Create a logical tab order through links, form controls, and objects.
• 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.
• 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
• 10.2 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.
• 10.3 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.
• 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.
• 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.
• 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
• 11.2 Avoid deprecated features of W3C technologies.
• 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)
• 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.
• 12.1 Title each frame to facilitate frame identification and navigation.
• 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.
• 12.3 Divide large blocks of information into more manageable groups where natural and appropriate.
• 12.4 Associate labels explicitly with their controls.
• 13.1 Clearly identify the target of each link.
• 13.2 Provide metadata to add semantic information to pages and sites.
• 13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).
• 13.4 Use navigation mechanisms in a consistent manner.
• 13.5 Provide navigation bars to highlight and give access to the navigation mechanism.
• 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.
• 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.
• 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
• 13.9 Provide information about document collections (i.e., documents comprising multiple pages.).
• 13.10 Provide a means to skip over multi-line ASCII art.
• 14.1 Use the clearest and simplest language appropriate for a site's content.
• 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.
• 14.3 Create a style of presentation that is consistent across pages.

Back to list of WCAG 1.0 checkpoints

1.1 “Provide a text equivalent for every non-text element...”

Refer to the section on WCAG 2.0 success criterion 1.1.1 “Non-text Content” for a general description relevant to this WCAG 1.0 checkpoint.

Back to list of WCAG 1.0 checkpoints

1.2 Provide redundant text links for each active region of a server-side image map

How does it especially help mobile users? If the mobile device has images turned off or does not support server-side image maps, redundant text links may help the user.

Does it give me MWBP compliance?: No.

Back to list of WCAG 1.0 checkpoints

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation

How does it especially help mobile users? Refer to description for WCAG 2.0 success criterion 1.2.2 Audio Description or Full Text Alternative.

Does it give me MWBP compliance?: No.

Back to list of WCAG 1.0 checkpoints

1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation

How does it especially help mobile users? For a general description of how captions may help mobile users, refer to WCAG 2.0 success criterion 1.2.1 Captions (Prerecorded). See @@ for audio description.

Does it give me MWBP compliance?: No

Back to list of WCAG 1.0 checkpoints

1.5 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

How does it especially help mobile users? Even on devices that support them, images used as maps may not be easily visible on a small screen. Most mobile devices lack a pointing device like a mouse or rolling ball, making it difficult for users to use server-side image maps. If image maps are used, providing redundant text links may improve the experience for mobile users.

Does it give me MWBP compliance?: No.

Back to list of WCAG 1.0 checkpoints

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.4.1 Use of Color.

Does it give me MWBP compliance?: Yes, this checkpoint ensures 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 1.0 checkpoints

2.2 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

How does it especially help mobile users? Refer to WCAG 2.0 success criterion 1.4.3 Contrast (Minimum) in this document.

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

Back to list of WCAG 1.0 checkpoints

3.1 When an appropriate markup language exists, use markup rather than images to convey information.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

3.2 Create documents that validate to published formal grammars.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

3.3 Use style sheets to control layout and presentation.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

3.5 Use header elements to convey document structure and use them according to specification.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

3.6 Mark up lists and list items properly.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

4.3 Identify the primary natural language of a document.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

5.1 For data tables, identify row and column headers.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

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, use markup to associate data cells and header cells.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

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.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

5.5 Provide summaries for tables.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

5.6 Provide abbreviations for header labels.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

6.2 “Ensure that equivalents for dynamic content are updated when the dynamic content changes”

How does it especially help mobile users? Providing equivalents for objects and scripts and ensuring the equivalents are updated helps users who can not perceive this conent due to device limitations as described in BP [OBJECTS_OR_SCRIPT].

Does it give me MWBP compliance?: No. Although BP [OBJECTS_OR_SCRIPT] is partly concerned with equivalents, providing an equivalent is not sufficient to ensure compliance (the BP requires that objects and script not even be delivered to devices that do not support them and should be avoided where possible). However, objects and scripts are types of dynamic content and providing equivalents for them and ensuring the equivalents are updated goes some way to enabling (is a precondition for) compliance with the BP.

Back to list of WCAG 1.0 checkpoints

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

6.4 For scripts and applets, ensure that event handlers are input device-independent.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).

How does it especially help mobile users? @@. Refer to Content blinks, moves, scrolls or auto-updates in “Summary of Experience of Content Features by Users” section.

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

7.3 Until user agents allow users to freeze moving content, avoid movement in pages.

How does it especially help mobile users? @@. Refer to Content blinks, moves, scrolls or auto-updates in “Summary of Experience of Content Features by Users” section.

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

9.4 Create a logical tab order through links, form controls, and objects.

How does it especially help mobile users? Refer to “Focus (tab) order does not match logical document content sequence” in Summary of Experience of Content Features by Users section. @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

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

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

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

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

11.2 Avoid deprecated features of W3C technologies.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

12.1 Title each frame to facilitate frame identification and navigation.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

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

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

12.4 Associate labels explicitly with their controls.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.1 Clearly identify the target of each link.

How does it especially help mobile users? Refer to “Link text not descriptive” in Summary of Experience of Content Features by Users section. @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.2 “Provide metadata to add semantic information to pages and sites”

How does it especially help mobile users? For a description of the importance of the page title, refer to WCAG 2.0 success criterion 2.4.2 Page Titled. Other metadata probably provides no special added benefit.

Does it give me MWBP compliance?: Including the page title ensures compliance with [PAGE_TITLE] “Provide a short but descriptive page title” with no further effort.

Back to list of WCAG 1.0 checkpoints

13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.4 Use navigation mechanisms in a consistent manner.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

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

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.9 Provide information about document collections (i.e., documents comprising multiple pages.).

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

13.10 Provide a means to skip over multi-line ASCII art.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

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

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

Back to list of WCAG 1.0 checkpoints

14.3 Create a style of presentation that is consistent across pages.

How does it especially help mobile users? @@

Does it give me MWBP compliance?: @@

5. WCAG and Mobile Web Best Practices Together

As described in this document, the two recommendations are complementary. the motivation for adopting them may be different (for example, commercial, regulatory, altruistic). It has been described elsewhere that retrofitting existing websites for compliance with another set of non-functional requirements is much more costly than complying during the design and development phases. the cost of late implementation (content repair, staff training, redesigning workflow) separately may also be much greater than doing both together, due to the synergies between them.

When a WCAG SC is more comprehensive or demanding than a BP and overlaps it completely, only include the SC in the list, and vice versa.

When starting a new Web project...

Meet this subset of WCAG success criteria

• 1.1.1 Non-text Content (because it overlaps a MWBP completely).
• 2.2.3 Pausing (as it is not covered by any MWBP)

and...

Meet this subset of the MWBPs

• CACHING (as it is not covered by any WCAG SC).

Not included above (and remove from this section of document once it is complete):

This is what projects doing both do not need to worry about if they do the preceding two sets.

• NON-TEXT_ALTERNATIVES, as it is covered by success criterion 1.1.1 Non-text Content included above.

7. References

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

[MWBP]

The “Mobile Web Best Practices 1.0” J. Rabin, C. McCathieNevile, eds, W3C Proposed Recommendation 2 November 2006. Available at http://www.w3.org/TR/mobile-bp/.

[WCAG]

The “Web Content Accessibility Guidelines 1.0” W. Chisholm, G. Vanderheiden, I. Jacobs, eds, May 1999. Available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.

[WCAG20]

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation 17 May 2007 (http://www.w3.org/TR/2007/WD-WCAG20-20070517/, Latest version at http://www.w3.org/TR/WCAG20/).

Cross-reference

The following table is provided for convenience only and should not be taken to imply any equivalence. No relationship is implied other than that the authors have found it useful to place links together to facilitate navigation. It may not cover all features or all provisions of the recommendations analysed.

[end of document]