W3C

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

W3C Working Draft 29 January 2008

Table of Contents

Introduction

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

This page is part of a suite of related documents. Please refer to the “How to Use These Documents” section for more information.

It 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 (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”).

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

As described in this section, many Mobile Web BPs have the added benefit of partial or complete compliance with certain WCAG success criteria. 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:

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. The summary that follows assumes that you are aiming for a certain WCAG 2.0 level of compliance or at least are interested to see how far you have gone towards achieving each level. For these reasons the summary is organized into the three WCAG 2.0 levels. On a second level the success criteria are then classified in three broad categories representing the further effort required, labeled for simplicity with keywords (nothing, something, everything):

Aiming for Level A

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.

Aiming 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:

Aiming 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:

Individual Mobile Web Best Practices Compared

This section examines in turn each of the Mobile Web Best Practices where there is a relationship to the Web Content Accessibility Guidelines. Those that are believed to have no relationship are listed seperately. Two main aspects are considered for each BP, “How does it help especially users with disabilities?” and “Does it give me WCAG 2.0 compliance?” which are introduced in a general way below.

How does it help especially users with disabilities?

Describes 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 2.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 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 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 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 mobile users with monochrome displays or in poor lighting conditions. By considering also the needs of users with color deficits (color blindness) the same BP makes content accessible to more users and ensures compliance with success criterion 1.4.3 “Contrast (Minimum)”.

List of Best Practices Described

Below is a list of the BPs described in detail. There follows a list of BPs believed to have no relationship to WCAG.

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

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

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?: Possibly. 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 necessarily achieved. However, if auto-refresh is not used at all, this does ensure compliance with the success criterion. Refer to 3.2.5 Change on Request, coverage at level A.

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 success criterion.

Does it give me WCAG 2.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 compromized when there is a lack of contrast with or without a background image. This BP helps users with low vision or color vision deficit (color blindness). Poor readability due to interference by patterns in background images is especially problematic for users with low vision.

Does it give me WCAG 2.0 compliance?: Partially. It helps with meeting 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) as described in this document under COLOR_CONTRAST. Refer to 1.4.3 Contrast (Minimum), coverage at level AA and 1.4.6 Contrast (Enhanced), coverage at level AAA.

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 2.0 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 sreen magnifiers benefit from this BP.

Does it give me WCAG 2.0 compliance?: No

Back to Best Practices list.

[CLARITY] Use clear and simple language

How does it help especially users with disabilities?: It may lead to a writing style that also helps users with innate (rather than contextual) reading difficulties.

Does it give me WCAG 2.0 compliance?: Possibly. WCAG success criterion 3.1.5 Reading Level is concerned with a user's innate reading level and ability, while this BP is concerned with reading difficulty due to context of use (for example, small screen, distracting environnment, lack of time). Refer to 3.1.5 Reading Level, coverage at level AAA.

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 color and brightness contrast make content readable. However, the BP is concerned with unfavorable ambient light and the ability of devices to display contrasting color at all, while users with disabilities are also concerned about color blindness and color perception deficits, which may lead to different results.

Does it give me WCAG 2.0 compliance?: Possibly. Using the more precise criteria given in the success criteria it may help ensure compliance with 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced). Note that WCAG 2.0 suggests a Contrast Ratio and the size of text to which the ratio applies. Refer to 1.4.3 Contrast (Minimum), coverage at level AA and 1.4.6 Contrast (Enhanced), coverage at level AAA.

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 2.0 compliance?: Partially. It meets one of the sufficient techniques for 4.1.2 Name, Role, Value. Refer to 4.1.2 Name, Role, Value, coverage at level A.

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 2.0 compliance?: No.

Tip: Use explicitly 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 under the PROVIDE_DEFAULTS in this document.

Does it give me WCAG 2.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 action to take. This BP aids understanding and navigations.

Does it give me WCAG 2.0 compliance?: No.

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 STYLE_SHEETS_SUPPORT in this document.

Does it give me WCAG 2.0 compliance?: Partially. It covers some of the sufficient techniques for 1.3.1, Info and Relationships. Refer to 1.3.1, Info and Relationships, coverage at level A.

Back to Best Practices list.

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

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 2.0 compliance?: Possibly, partially. When image maps are not delivered, 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 (In Context) and 2.4.9 Link Purpose (Link Only). Refer to 1.1.1 Non-text Content, coverage at level A, 2.4.4 Link Purpose (In Context), coverage at level A and 2.4.9 Link Purpose (Link Only), coverage at level AAA.

Back to Best Practices list.

Does it give me WCAG 2.0 compliance?: Yes, this BP ensures compliance with success criteria 2.4.4 Link Purpose (In Context) and 2.4.9, Link Purpose (Link Only). Refer to 2.4.4 Link Purpose (In Context), coverage at level A and 2.4.9 Link Purpose (Link Only), coverage at level AAA.

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?: Yes, this BP ensures compliance with 1.4.4 Resize text. Refer to 1.4.4 Resize text, coverage at level AA

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 2.0 compliance?: No.

Back to Best Practices list.

Does it give me WCAG 2.0 compliance?: No.

Back to Best Practices list.

Does it give me WCAG 2.0 compliance?: Partially. 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”). Refer to 3.2.3 Consistent Navigation, coverage at level AA.

Back to Best Practices list.

[NO_FRAMES] Do not use frames

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

Does it give me WCAG 2.0 compliance?: Possible, partially. Where frames are not used, there is no to identify them as required by 4.1.2 Name, Role, Value. Refer to 4.1.2 Name, Role, Value, coverage at level A.

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. Designing content to be useful when rendered text-only (as required by the BP) requires the provision of text equivalents for non-text content and so may make content more accessible to users unable to see images or other non-text content for whatever reason. Refer to WCAG 2.0 Specific Benefits of Success Criterion 1.1.1 for further information.

Does it give me WCAG 2.0 compliance?: Partially. It goes some way to meeting success criterion 1.1.1 Non-text Content. Refer to 1.1.1 Non-text Content, coverage at level A

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. If an extended description is necessary, provide in addition a separate [D] link adjacent to the image.

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.

Does it give me WCAG 2.0 compliance?: Possibly. When scripting is not used or is redundant, 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) do not apply. Refer to 2.1.1 Keyboard, coverage at level A and Refer to 2.1.3 Keyboard (No Exception), coverage at level AAA.

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 2.0 compliance?: No.

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, with generic information first and differentiating information last.

Does it give me WCAG 2.0 compliance?: Possibly. Providing a page title may ensure compliance with 2.4.2 Page Titled. However, the accessibility techniques are more detailed, and in particular may lead to a title that is longer than suitable for a mobile device. Refer to 2.4.2 Page Titled, coverage at level A

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?: Partially. WCAG 2.0 considers a number of different changes of context. A popup window is one particular change of context. There are three SCs that deal with change of context, caused in three different ways (on focus, on input, and on request): 3.2.1 On Focus, 3.2.2 On Input and 3.2.5 Change on Request. The BP covers only one of the changes of context considered in these three SCs. Refer to 3.2.1 On Focus, coverage at level A, 3.2.2 On Input, coverage at level A and 3.2.5 Change on Request, coverage at level AAA

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.

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:

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”. Refer to 3.2.5 Change on Request, coverage at level AAA

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?: Partially. It ensures compliance with one aspect (of several) of 1.4.8 Visual Presentation concerning scrolling. Refer to 1.4.8 Visual Presentation, coverage at level AAA.

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.10 Section Headings with no further effort. It helps towards compliance with success criterion 1.3.1 Info and Relationships. Refer to 1.3.1 Info and Relationships, coverage at level A and 2.4.10 Section Headings, coverage at level AAA.

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. For example, refer to WCAG 2.0 Specific Benefits of Success Criterion 1.3.1 and the explanation of the [FONTS] best practice in this document.

Does it give me WCAG 2.0 compliance?: Partially. In order to create content that can be read without style sheets it will probably be necessary to use structural markup, and so this helps compliance with 1.3.1, Info and Relationships. Refer to 1.3.1 Info and Relationships, coverage at level A.

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?: Possibly. If content is styled with style sheets it will probably use structural markup, and so this may indirectly bring the same accessibility benefits as STYLE_SHEETS_SUPPORT. Refer to 1.3.1 Info and Relationships, coverage at level A.

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 the accompanying document “Experiences Shared by People with Disabilities and by People Using Mobile Devices”.

Does it give me WCAG 2.0 compliance?: Yes, this ensures compliance with 2.4.3 Focus Order. Refer to 2.4.3 Focus Order, coverage at level A.

Back to Best Practices list.

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

How does it help especially users with disabilities?: No added benefit. @@ It may make content less acessible for some users, such as those with screen readers. 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 2.0 compliance?: No.

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.

Does it give me WCAG 2.0 compliance?: No, but where tables are not used for layout, this may help towards compliance with 1.3.2 Meaningful Sequence. Refer to 1.3.2 Meaningful Sequence, coverage at level A

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?: 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 when tables may be used. Refer to TABLES_ALTERNATIVES.

Does it give me WCAG 2.0 compliance?: No.

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?: 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?: 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?: 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 colors or identify them correctly (color deficit, color blindness) or see the page at all (blind users). Users may have turned off the style sheet or use a browser that does not support CSS, or may need to use a special style sheet. These users may misinterpret or not perceive information expressed by color alone.

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. Refer to 1.4.1 Use of Color, coverage at level A.

Back to Best Practices list.

[VALID_MARKUP] Create documents that validate to published formal grammars

How does it help especially users with disabilities?: From WCAG 2.0: Ensuring that Web pages have complete start and end tags and are nested according to specification helps ensure that assistive technologies can parse the content accurately and without crashing. (@@ check URL).

Does it give me WCAG 2.0 compliance?: Yes, it ensures compliance with 4.1.1 Parsing with no further effort. Refer to 4.1.1 Parsing, coverage at level A.

Back to Best Practices list.