W3C

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

Editor's draft

This version:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20071017.html
Latest version:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/latest
Previous version:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20070926.html
Editors:
Alan Chuter (Fundación ONCE / Technosite)

Abstract

Status of this Document

This document is an editors' copy that has no official standing.

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

Preliminary draft: this document is intended to gather together preliminary material for the planned public working draft. It has not been reviewed or approved by members of the Mobile Web Best Practices Working Group - Accessibility Task Force.

The W3C Membership and other interested parties are invited to review the document and send comments to public-bpwg-comments@w3.org (with public archive) through [date] 2006. Advisory Committee Representatives should consult their WBS questionnaires.

This document was developed by the Mobile Web Best Practices Working Group - Accessibility Task Force as part of the Mobile Web Initiative.

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Comment: Should we discuss in terms of actual recommendations (WCAG and MWBP) or more abstractly accessibility and best mobile web practices?.

Table of Contents

1. Introduction

1.1 Purpose of the Document

This document may serve as an added justification or argument for aiming for compliance with either of the recommendations.

1.2 How this document is organized

.

1.3 Audience

Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers and HTTP. Readers are not expected to have a background in mobile-specific technologies. it is important to understand the other W3C Recommendations to which it refers (see Relationship to other W3C Recommendations).

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.

The following are the use cases the document is expected to cover:

  1. A stakeholder has achieved compliance with one recommendation and now aims for compliance with the other. The document must explain what additional effort is required and how to leverage existing investment to comply with the other recommendation in an efficient way.
  2. A stakeholder is confused about or is unaware of the relationship between WCAG and Mobile Web Best Practices, seeing them as separate and disjoint, and missing the synergy and the overlap between them. The document must explain how they are similar and how they differ, and that the development and evaluation processes are similar.
  3. A content provider is complying with one Recommendation and is aware of similarities with the other. The organization is aware that it can improve usability for all by complying with the corresponding checkpoints or best practices of the other Recommendation (partial compliance) with only a little further effort, but needs to know how to do this. The document must provide information about how to comply, with minimal effort, with the corresponding CPs or BPs of the other Recommendation (union of the two sets).
  4. A content provider is committed to compliance with one Recommendation and needs to know the cost of compliance with the other, doing both together. The document should clarify what added effort would be required (difference between the two sets).
  5. A content provider wishes to comply with both Recommendations on the same project, as part of a comprehensive content quality strategy, and wishes to integrate the requirements. The document should provide a single coherent, integrated overview of both.
  6. A company is developing an evaluation or repair tool (checker). It has developed a tool for one recommendation and is concerned not to waste resources writing new code unnecessarily. It wishes to reuse or adapt code from the existing tool and needs to know how WCAG and MWBP relate to each other as regards testing.

1.4 Scope

This document does not describe Web accessibility for people with disabilities. For further information consult [WAI documents]. it does not describe the mobile Web context. This is described in [MOK]

The mapping document will not create any further requirements other than those defined in the Mobile Web Best Practices and WCAG.

It describes the relationships, overlaps and differences between Mobile Web Best Practices and the Web Content Accessibility Guidelines.

It explains the synergies in implementing WCAG and Mobile Web Best Practices together.

1.5 Relationship to other W3C Recommendations

This document refers to W3C recommendations for Web content accessibility and mobile Web best practices. There are existing new draft versions of these recommendations. For this document for Web accessibility the W3C Recommendation is the Web Content Accessibility Guidelines 1.0. For mobile Web best practices it references the Mobile Web Best Practices 1.0.

1.6 Longevity and Versioning

.

1.7 Terminology

The accessibility documents referenced consist of guidelines and checkpoints. Mobile Web Best Practices contains Best Practices.

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

Comment: Alternative title “Common user needs: Understanding the relationship between the needs of mobile users and users with disabilities”.

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.

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

Content Feature Disabled user characteristics (any context) General user and device characteristics (mobile context) Result
Interaction and intra-page navigation requires a mouse. User with a motor disability may not be able to use a mouse Device has no mouse, only alphanumeric keypad or rocker switch User unable to navigate all content, or wastes time moving through numerous links.
Information conveyed using color (for example, “required fields shown in red”) with no redundancy. Blind or colorblind user perceives color incorrectly or not at all. Screen has reduced color palette (DDC). Device is used in poor lighting (outdoors, near flashing lights), so colors are not clearly perceived. User perceives color incorrectly or not at all, and so misunderstands information, makes mistakes.
Large page or large images User with restricted field of vision or using screen maginfier. Mobile device has small screen (viewport). User only sees small areas at a time (keyhole view), unable to relate different areas of page; becomes disoriented or has to scroll excessively.
Multimedia with no captions Deaf or hard of hearing user can't hear. Mobile users often in public places (trains, hotel lobbies) turn off sound; often in noisy places (streets, nightclubs) can't hear. User misses soundtrack.
Audio-only prompts (beeps, buzzes) for important information (warnings, errors) Deaf or hard of hearing user can't operate content. In noisy place (street, nightclub) can't hear. Can't operate or interact correctly with content, misses warnings, makes mistakes.
Free-text entry (for example, alphbetical characters allowed in numeric fields) User with motor disability (partial paralisis, hand tremor, lack of sensitivity, coordination). Device has small keypad, or is held in unsteady hand. User enters text incorrectly, makes mistakes.
Embedded non-text objects (images, sound, video) with no text alternative. Disadvantaged user with slow connection prefers not to wait for download. User with low bandwidth or who declines to run up connection charges. Already small images redimensioned even smaller in adaptation, become meaningless. Information loss due to lack of alterantive. User can't perceive infromation.
Important information in non-text content (images, multimedia, CSS effects) Blind or low-vision can't perceive content. User billed for download volume, turns off images to save costs. Device has no CSS support. User misses important information.
Long words, long and complex sentences, jargon User with cognitive disability. Text is displayed in small font, and user is often distracted by ambient conditions (background noise, conversations, moving objects in field of vision). User finds content difficult to understand, becomes confused.
Content formatted using tables or CSS, and reading order not correct whern linearised (for example when CSS or tables not rendered) Non-visual (screen reader) user reads content in document tree order. Meaning of content altered by reformatting or restructuring in adaptation process. Content is garbled, user becomes confused.
Scripting required to operate or generate content. User's assistive technology or browser doesn't support scripting. Scripting turned off or not supported. Information loss. Content inoperable.
Special plugin required Plugin turned off, not installed, not compatible with assistive technology. Plugin not operable with preferred input device. Plugin turned off or not installed; not compatible with input device (for example, requires mouse). User can not perceive content or can not operate interface.
Invalid or unsupported markup. User has “old” or unusual browser to acommodate special needs. Mobile device has embedded browser not catered for by content provider. Content passes through adaptation process(es). Browser or adaptation system chokes on markup; rejects or garbles it.
Content spawns new windows without warning user. User with low vision, restricted field of vision, or blindness doesn't realize active window is new. Single window interface. Multiple stacked windows on small screen hide each other. User becomes disoriented among widows; back button doesn't work. User closes window, not realising it is last in stack, closing browser instance.
Information conveyed only using CSS (visual formatting) Blind user doesn't perceive visual formatting effects. Often no CSS support by mobile browser. Information lost or altered.
No tactile feedback Device put away [Bruno please clarify]

3. How Mobile Web Best Practices can Benefit Users with Disabilities

Comment: MWBP but not WCAG, as correspondence is not automatic. Use “can” because some extra work may be required.

Comment: Should this section include all BPs, or only those with accessibility benefits?

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?

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 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 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 and complying with one automatically gives you 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” 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.

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

Many BPs have no relations to any WCAG 1.0 checkpoint and this is also noted.

Summary of [kill two birds with one stone] between MWBP and WCAG 1.0
MWBP Compliance directly Compliance with extra effort Compliance means WCAG CP doesn't apply No meaningful relation
[THEMATIC_CONSISTENCY]       X
[CAPABILITIES]       X
[DEFICIENCIES]       X
[TESTING]       X
[URIS]       X
[NAVBAR]       X
[BALANCE]       X
[NAVIGATION] 13.4      
[ACCESS_KEYS]   9.5    
[LINK_TARGET_ID]   13.1    
[LINK_TARGET_FORMAT]       X
[IMAGE_MAPS]       X
[POP_UPS] 10.1      
[AUTO_REFRESH]   7.4    
[REDIRECTION] 7.5      
[EXTERNAL_RESOURCES]       X
[SUITABLE]       X
[CLARITY]   14.1; 13.8    
[LIMITED]       X
[PAGE_SIZE_USABLE]   12.3    
[PAGE_SIZE_LIMIT]       X
[SCROLLING]       X
[CENTRAL_MEANING]   12.3    
[GRAPHICS_FOR_SPACING]       X
[LARGE_GRAPHICS]       X
[USE_OF_COLOR] 2.1      
[COLOR_CONTRAST]   2.2    
[BACKGROUND_IMAGE_READABILITY]   6.1    
[PAGE_TITLE]   13.2    
[NO_FRAMES]     12.1; 12.2  
[STRUCTURE] 3.5      
[TABLES_SUPPORT]     5.1; 5.2; 5.3; 5.4; 5.5  
[TABLES_NESTED]       X
[TABLES_LAYOUT]     5.3; 5.4  
[TABLES_ALTERNATIVES]     5.1; 5.2; 5.3; 5.4; 5.5  
[NON-TEXT_ALTERNATIVES] 1.1 3.1    
[OBJECTS_OR_SCRIPT] 6.3 6.4    
[IMAGES_SPECIFY_SIZE]       X
[IMAGES_RESIZING]       X
[VALID_MARKUP] 3.2 11.1; 11.2    
[MEASURES] 3.4      
[STYLE_SHEETS_USE] 3.3      
[STYLE_SHEETS_SUPPORT] 6.1      
[STYLE_SHEETS_SIZE]       X
[MINIMIZE]       X
[CONTENT_FORMAT_SUPPORT]       X
[CONTENT_FORMAT_PREFERRED]       X
[CHARACTER_ENCODING_SUPPORT]       X
[CHARACTER_ENCODING_USE]       X
[ERROR_MESSAGES]       X
[COOKIES]       X
[CACHING]       X
[FONTS]   6.1; 11.2    
[MINIMIZE_KEYSTROKES]       X
[AVOID_FREE_TEXT]       X
[PROVIDE_DEFAULTS]       X
[DEFAULT_INPUT_MODE]       X
[TAB_ORDER] 9.4      
[CONTROL_LABELLING] 12.4      
[CONTROL_POSITION] 10.2      

To summarise, the table Summary of [kill two birds with one stone] between MWBP and WCAG 1.0 above shows that compliance with MWBP ensures that content already complies with WCAG 1.0 checkpoints 1.1, 2.1, 3.2, 3.3, 3.4, 3.5, 6.1, 6.3, 7.5, 9.4, 10.1, 10.2, 12.4 and 13.4, while 5.1, 5.2, 5.3, 5.4, 5.5, 12.1, 12.2 simply do not apply. With some extra effort or simply considering different user needs, it is quite feasible to also comply with 2.2, 3.1, 6.1, 6.4, 7.4, 9.5, 11.1, 11.2, 12.3, 13.1, 13.2, 13.8 and 14.1.

The rest of this section describes the BP and their relationships to WCAG 1.0 in detail.

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

Refer to [THEMATIC_CONSISTENCY] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CAPABILITIES] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[DEFICIENCIES] Take reasonable steps to work around deficient implementations

Refer to [DEFICIENCIES] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [TESTING] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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.

[URIS] Keep the URIs of site entry points short

Refer to [URIS] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

Refer to [NAVBAR] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP deals with an aspect not considered in WCAG 1.0, although it is related to 13.5, “Provide navigation bars to highlight and give access to the navigation mechanism”.

[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

Refer to [BALANCE] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Users with motor disability may special difficulty in using the keyboard or other device to navigate between links. Users with cognitive disability may have difficulty using| understanding| concentrating on large numbers of links. Users with the disabilities described may benefit from this BP.

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

Refer to [NAVIGATION] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: Complying with this BP also ensures compliance with WCAG 1.0 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.

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

Refer to [ACCESS_KEYS] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Mobile devices are not usually equipped with a mouse, and so users are in a situation similar to that experienced by those who are unable to use one.

Does it give me WCAG 1.0 compliance?: Providing access keys are also defined as necessary for form controls (not made explicit in the BP), this BP also 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”. 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.

Refer to [LINK_TARGET_ID] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Refer to WCAG 1.0 HTML Techniques: Link text.

Does it give me WCAG 1.0 compliance?: This BP goes some way to ensuring compliance with WCAG 1.0 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.

Refer to [LINK_TARGET_FORMAT] to understand the Best Practice described in this section.

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

Comment: I don't believe that this really does relate to WCAG 11.3, which says send the content in user's preferred format or language, while this BP just says tell user what the format is if format is supported

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [IMAGE_MAPS] to understand the Best Practice described in this section.

Comment: The references section for this BP is misleading: “This relates to WCAG 1.2 and 9.1”. It relates to these checkpoints but not in the way covered by the BP.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [POP_UPS] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures compliance with WCAG 1.0 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).

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

Refer to [AUTO_REFRESH] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Auto-refresh is especially confusing to users of screen readers. As the 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.

Does it give me WCAG 1.0 compliance?: As long as auto-refresh is not used, this BP ensures compliance with WCAG 1.0 checkpoint 7.4, “Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages”. At the time of writing user agents do not allow the user to disable auto-refresh (do they?). If auto-refresh is used, under the provision of the BP to inform the user and provide a means to deactivate it, the WCAG 1.0 CP is not complied with (WCAG requires that the user agent be used to turn it off, while the BP allows for the content to do it).

Comment: The BP confusingly says “Auto-refreshing pages are widely recognized as presenting accessibility problems” but does not explain why. This detail could be removed from the BP as it is out of scope.

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

Refer to [REDIRECTION] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with WCAG 1.0 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”.

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

Refer to [EXTERNAL_RESOURCES] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [SUITABLE] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[CLARITY] Use clear and simple language

Refer to [CLARITY] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 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.”

[LIMITED] Limit content to what the user has requested

Refer to [LIMITED] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions

Refer to [PAGE_SIZE_USABLE] to understand the Best Practice described in this section.

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

Comment: Is the following true? Otherwise (no_added_benefit)

Does it give me WCAG 1.0 compliance?: 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”, although in a way not contemplated in the guidelines (The working group in 1999 did not consider the mobile context). However the WCAG checkpoint is much broader in scope, covering all usage contexts.

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

Refer to [PAGE_SIZE_LIMIT] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [SCROLLING] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: This BP enhances accessibility for users who have difficulty scrolling for whatever reason (device or physical limitation).

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CENTRAL_MEANING] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Putting the main content first helps keyboard-only users whether in a mobile context or not. I may also help users weith cognitive disabilities who have difficulty locating the central information in a page full of navigation links.

Comment: The following is debatable. Otherwise no_added_benefit.

Does it give me WCAG 1.0 compliance?: This BP corresponds 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 contemplated in the guidelines. The WCAG checkpoint is much broader in scope than the BP.

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing

Refer to [GRAPHICS_FOR_SPACING] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost

Refer to [LARGE_GRAPHICS] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [USE_OF_COLOR] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP 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” with no added effort.

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

Refer to [COLOR_CONTRAST] to understand the Best Practice described in this section.

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.

Does it give me WCAG 1.0 compliance?: This BP 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. However, the BP is concerned exclusively with unfavourable ambient light, while WCAG is primarily concerned with colour blindness, which may lead to different results.

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

Refer to [BACKGROUND_IMAGE_READABILITY] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: no_added_benefit but if it is not met, users with low vision or colour vision deficit may be more disadvantaged.

Does it give me WCAG 1.0 compliance?: This BP is related to WCAG 1.0 checkpoint 6.1, “Organize documents so they may be read without style sheets”. If the content is not readable without a background image, this checkpoint is not met.

[PAGE_TITLE] Provide a short but descriptive page title

Refer to [PAGE_TITLE] to understand the Best Practice described in this section.

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.

Does it give me WCAG 1.0 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”.

[NO_FRAMES] Do not use frames

Refer to [NO_FRAMES] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures that WCAG 1.0 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.

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

Refer to [STRUCTURE] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures compliance with WCAG 1.0 checkpoint 3.5, “Use header elements to convey document structure and use them according to specification” with no further effort.

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

Refer to [TABLES_SUPPORT] to understand the Best Practice described in this section.

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 1.0 compliance?: As long as tables are not used in any adaptation of the content served, then WCAG 1.0 Guideline 5, “Create tables that transform gracefully” does not apply.

[TABLES_NESTED] Do not use nested tables

Refer to [TABLES_NESTED] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[TABLES_LAYOUT] Do not use tables for layout

Refer to [TABLES_LAYOUT] to understand the Best Practice described in this section.

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 1.0 compliance?: If tables are not used for layout, then WCAG 1.0 checkpoints 5.3, “Do not use tables for layout unless the table makes sense when linearized” and 5.4, “If a table is used for layout, do not use any structural markup for the purpose of visual formatting”, do not apply.

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

Refer to [TABLES_ALTERNATIVES] to understand the Best Practice described in this section.

Comment: Check on the implications of this. Tables may be easier to use (less verbose) for screen reader users, if the browser and screen reader support them.

Does it give me WCAG 1.0 compliance?: If tables are not used then WCAG 1.0 Guidelines 5, “Create tables that transform gracefully” does not apply.

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

Refer to [NON-TEXT_ALTERNATIVES] to understand the Best Practice described in this section.

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

Comment: Longdesc support in mobile devices?? have added a tip, as it the following workaround isn't actually described in the BP (but should be).

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

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script

Refer to [OBJECTS_OR_SCRIPT] to understand the Best Practice described in this section.

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.

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with WCAG 1.0 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”.

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

Refer to [IMAGES_SPECIFY_SIZE] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [IMAGES_RESIZING] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[VALID_MARKUP] Create documents that validate to published formal grammars

Refer to [VALID_MARKUP] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with WCAG 1.0 checkpoint 3.2, “Create documents that validate to published formal grammars”. 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”.

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

Refer to [MEASURES] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures compliance with WCAG 1.0 checkpoint 3.4, “Use relative rather than absolute units in markup language attribute values and style sheet property values” with no further effort.

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

Refer to [STYLE_SHEETS_USE] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures compliance with WCAG 1.0 checkpoint 3.3, “Use style sheets to control layout and presentation” with no further effort.

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

Refer to [STYLE_SHEETS_SUPPORT] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP ensures compliance with WCAG 1.0 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.

[STYLE_SHEETS_SIZE] Keep style sheets small

Refer to [STYLE_SHEETS_SIZE] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[MINIMIZE] Use terse, efficient markup

Refer to [MINIMIZE] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CONTENT_FORMAT_SUPPORT] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CONTENT_FORMAT_PREFERRED] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CHARACTER_ENCODING_SUPPORT] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [CHARACTER_ENCODING_USE] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [ERROR_MESSAGES] to understand the Best Practice described in this section.

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?: This BP does not ensure compliance with any WCAG 1.0 checkpoint, 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.

[COOKIES] Do not rely on cookies being available

Refer to [COOKIES] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[CACHING] Provide caching information in HTTP responses

Refer to [CACHING] to understand the Best Practice described in this section.

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

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [FONTS] to understand the Best Practice described in this section.

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?: This BP goes some of the way to complying with WCAG 1.0 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”.

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum

Refer to [MINIMIZE_KEYSTROKES] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[AVOID_FREE_TEXT] Avoid free text entry where possible.

Refer to [AVOID_FREE_TEXT] to understand the Best Practice described in this section.

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 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible

Refer to [PROVIDE_DEFAULTS] to understand the Best Practice described in this section.

Comment: The reference to WCAG 1.0 checkpoint 10.4 “Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas” is unhelpful. The checkpoint is usually understood to mean text like “your name here”, not default values remembered by the application. The checkpoint is obsolete now anyway, as user agents do now handle empty input boxes correctly.

How does it help especially users with disabilities?: While this BP is primarily concerned with the limitations of the input mechanism of the mobile device (for example, the keyboard), it also helps users who have difficulty using the input device. This BP does not correspond to any WCAG 1.0 provision.

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [DEFAULT_INPUT_MODE] to understand the Best Practice described in this section.

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. This BP does not correspond to any WCAG 1.0 provision.

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any WCAG 1.0 provision.

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

Refer to [TAB_ORDER] to understand the Best Practice described in this section.

How does it help especially users with disabilities?: Refer to WCAG 1.0 HTML Techniques: Keyboard access

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

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

Refer to [CONTROL_LABELLING] to understand the Best Practice described in this section.

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?: This BP ensures compliance with WCAG 1.0 checkpoint 12.4, “Associate labels explicitly with their controls” with no further effort.

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

Refer to [CONTROL_POSITION] to understand the Best Practice described in this section.

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 1.0 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: Avoid nesting the control inside the label element as it is not supported by user agents.

4. How WCAG Compliance can Benefit All Mobile Web Users

Comment: Don't say MWBP here as there is not necessarily a clear correspondence. Could use “accessible Web design” instead of “WCAG compliance”. Say “all” users as many mobile users have disability.

WCAG 1.0 checkpoint 1.1 Provide a text equivalent for every non-text element...

Comment: Example of a partial match between MWBP and WCAG.

Refer to WCAG 1.0 checkpoint 1.1 to understand this section.

This WCAG checkpoint also ensures compliance with BP [NON-TEXT_ALTERNATIVES] “Provide a text equivalent for every non-text element” with no further effort. However, the concept of equivalence is more sophisticated in the field of accessibility and it is important to ensure that the text really is equivalent [write this more clearly...].

WCAG 1.0 checkpoint 2.1 “Ensure that all information conveyed with color is also available without color, for example from context or markup” [Priority 1]

Comment: Example of a more or less complete match between MWBP and WCAG. Say that by complying with WCAG you also get the bonus of complying with MWBP (“with no further effort”).

Refer to WCAG 1.0 checkpoint 2.1 to understand this section.

This WCAG 1.0 checkpoint is explained in Guideline 2, Don't rely on color alone: “If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information”.

This WCAG checkpoint ensures that users who cannot perceive color correctly will be able to understand and operate the content, and should ensure compliance with BP [USE_OF_COLOR] “Ensure that information conveyed with color is also available without color” without any further effort.

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

Refer to WCAG 1.0 checkpoint 13.2 to understand this section.

Perhaps the most useful item of metadata for a page is a descriptive page title, and including the title to comply with this WCAG checkpoint also ensures compliance with [PAGE_TITLE] “Provide a short but descriptive page title” with no further effort.

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.

6. Achieving usability for All

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 [cite both Recs]. 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.

Comment: Cite the relevant text from each recommendation that advises doing user testing.