Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
This document may serve as an added justification or argument for aiming for compliance with either of the recommendations.
.
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.
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.
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.
.
The accessibility documents referenced consist of guidelines and checkpoints. Mobile Web Best Practices contains Best Practices.
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] |
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?
Some MWBP also benefit users with different disabilities. Some correspond directly to WCAG 1.0 checkpoints.
Refer to [THEMATIC_CONSISTENCY] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [CAPABILITIES] to understand the Best Practice described in this section.
This BP does especially not assist users with disabilities. It does not correspond to a WCAG 1.0 checkpoint. The Web Content Accessibility Guidelines aim to make content accessible to all users regardless of ability.
Refer to [DEFICIENCIES] to understand the Best Practice described in this section.
This BP does not especially assist users with disabilities.
Refer to [TESTING] to understand the Best Practice described in this section.
This BP can improve accessibility when the testing is done by users with a range of abilities, not only evaluation and development staff [Comment: is this out of scope?]This BP 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”.
Comment: Example of a BP that has no parallel in WCAG (methinks) but does aid many users with disabilities.
Refer to [URIS] to understand the Best Practice described in this section.
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. However, this MWBP does not correspond to any WCAG 1.0 provision.
Comment: Another example of a BP that has no parallel in WCAG but does aid many users with disabilities.
Refer to [NAVBAR] to understand the Best Practice described in this section.
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. 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”.
.
Refer to [NAVIGATION] to understand the Best Practice described in this section.
Complying with this BP also ensures compliance with WCAG 1.0 checkpoint 13.4, “Use navigation mechanisms in a consistent manner”.
Refer to [ACCESS_KEYS] to understand the Best Practice described in this section.
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. Providing access keys are defined as necessary for form controls [not made explicit in 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, provide information about access keys used in content on a separate page.
Refer to [LINK_TARGET_ID] to understand the Best Practice described in this section.
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.
[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].
Refer to [IMAGE_MAPS] to understand the Best Practice described in this section.
This BP does not directly improve accessibility.
Comment: The references section for this BP is misleading: “This relates to WCAG 1.2 and 9.1”. It relates to these CPs but not in the way covered by the BP.
Refer to [POP_UPS] to understand the Best Practice described in this section.
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.
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: teh BP is more restrictive).
Refer to [AUTO_REFRESH] to understand the Best Practice described in this section.
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.
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.
Refer to [REDIRECTION] to understand the Best Practice described in this section.
Like auto-refresh, using markup for redirection can confuse users, especially:
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”.
Refer to [EXTERNAL_RESOURCES] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [SUITABLE] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [CLARITY] to understand the Best Practice described in this section.
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 emphasises writing style and thematic contentin all contexts. It also covers (in the explanation) 13.8 “Place distinguishing information at the beginning of headings, paragraphs, lists, etc.”
Refer to [LIMITED] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [PAGE_SIZE_USABLE] to understand the Best Practice described in this section.
This BP goes some way to 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.
Refer to [PAGE_SIZE_LIMIT] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [SCROLLING] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [CENTRAL_MEANING] to understand the Best Practice described in this section.
This BP goes some way to complying with 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. However the WCAG checkpoint is much broader in scope.
Refer to [GRAPHICS_FOR_SPACING] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [LARGE_GRAPHICS] to understand the Best Practice described in this section.
This BP does not directly affect accessibility.
Refer to [USE_OF_COLOR] to understand the Best Practice described in this section.
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.
Refer to [COLOR_CONTRAST] to understand the Best Practice described in this section.
This BP may ensure (with other 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.
Refer to [BACKGROUND_IMAGE_READABILITY] to understand the Best Practice described in this section.
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.
Comment: Example of a BP that has a parallel in WCAG. Say that it helps achieve compliance with WCAG.
Refer to [PAGE_TITLE] to understand the Best Practice described in this section.
Providing a descriptive page title is beneficial to all users, and [goes some of the way to] compliance with WCAG 1.0 checkpoint 13.2, “Provide metadata to add semantic information to pages and sites”.
Refer to [NO_FRAMES] to understand the Best Practice described in this section.
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” does not apply to the content.
Refer to [STRUCTURE] to understand the Best Practice described in this section.
This BP ensures compliance with WCAG 1.0 checkpoint 3.5, “Use header elements to convey document structure and use them according to specification”.
Refer to [TABLES_SUPPORT] to understand the Best Practice described in this section.
Refer to [TABLES_NESTED] to understand the Best Practice described in this section.
Refer to [TABLES_LAYOUT] to understand the Best Practice described in this section.
Refer to [TABLES_ALTERNATIVES] to understand the Best Practice described in this section.
Refer to [NON-TEXT_ALTERNATIVES] to understand the Best Practice described in this section.
Refer to [OBJECTS_OR_SCRIPT] to understand the Best Practice described in this section.
Refer to [IMAGES_SPECIFY_SIZE] to understand the Best Practice described in this section.
Refer to [IMAGES_RESIZING] to understand the Best Practice described in this section.
Refer to [VALID_MARKUP] to understand the Best Practice described in this section.
Refer to [MEASURES] to understand the Best Practice described in this section.
Refer to [STYLE_SHEETS_USE] to understand the Best Practice described in this section.
Refer to [STYLE_SHEETS_SUPPORT] to understand the Best Practice described in this section.
Refer to [STYLE_SHEETS_SIZE] to understand the Best Practice described in this section.
Refer to [MINIMIZE] to understand the Best Practice described in this section.
Refer to [CONTENT_FORMAT_SUPPORT] to understand the Best Practice described in this section.
Refer to [CONTENT_FORMAT_PREFERRED] to understand the Best Practice described in this section.
Refer to [CHARACTER_ENCODING_SUPPORT] to understand the Best Practice described in this section.
Refer to [CHARACTER_ENCODING_USE] to understand the Best Practice described in this section.
Refer to [ERROR_MESSAGES] to understand the Best Practice described in this section.
Refer to [COOKIES] to understand the Best Practice described in this section.
Refer to [CACHING] to understand the Best Practice described in this section.
Refer to [FONTS] to understand the Best Practice described in this section.
Refer to [MINIMIZE_KEYSTROKES] to understand the Best Practice described in this section.
Refer to [AVOID_FREE_TEXT] to understand the Best Practice described in this section.
Refer to [PROVIDE_DEFAULTS] to understand the Best Practice described in this section.
Refer to [DEFAULT_INPUT_MODE] to understand the Best Practice described in this section.
Refer to [TAB_ORDER] to understand the Best Practice described in this section.
Refer to [CONTROL_LABELLING] to understand the Best Practice described in this section.
Refer to [CONTROL_POSITION] to understand the Best Practice described in this section.
this table provides a quick overview of which BPs are related in any way to which WCAG CPs, it does not imply they are equivalent. To understand the nature of teh relationships, consult the descriptions in this document using the links provided.
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.
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...].
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.
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.
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.
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.
Comment: Should we discuss in terms of actual recommendations (WCAG and MWBP) or more abstractly accessibility and best mobile web practices?.