Abstract
This technical report describes the similarities and differences between the requirements in Web Content Accessibility Guidelines (WCAG) and Mobile Web Best Practices 1.0 (MWBP). Introductory information and links to related documents are in Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices.
Status of This Document
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/.
Important: This document is an old Editor's Draft. The published version is at http://www.w3.org/TR/mwbp-wcag/.
Please send any comments to public-bpwg-comments@w3.org (public archive) with subject [MWBP-WCAG Relationship].
This W3C Editor's Draft is introduced in Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices. It was developed jointly by the Mobile Web Best Practices Working Group and the Education and Outreach Working Group (EOWG) of the Web Accessibility Initiative (WAI).
This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the Mobile Web Best Practices Group and also maintains a public list of any patent disclosures made in connection with the deliverables of the Education and Outreach Working Group; those pages also include 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.
Introduction
This technical report helps Web developers meet both Web Content Accessibility Guidelines (WCAG) and Mobile Web Best Practices 1.0 (MWBP). It describes the similarities and differences between requirements in WCAG and MWPB. It is designed primarily to help Web developers who have worked with either WCAG or MWBP to learn about the additional requirements in the other.
This technical report is a companion document to WCAG and MWBP, and does not replace either of those. The actual Web Content Accessibility Guidelines document should be used to make Web content accessible to people with disabilities, and the Mobile Web Best Practices document should be used for best practices for making Web content for mobile devices.
Many MWBPs have the added benefit of partial or complete compliance with certain WCAG success criteria or checkpoints. However, WCAG is often more detailed or describes a different aspect of the same concept. It should not be assumed that following any BP will ensure accessibility or that a success criterion or checkpoint will ensure compliance with MWBPs. To ensure compliance it is important to always consult the Mobile Web Best Practices or the Web Content Accessibility Guidelines directly.
W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.
Differences of Approach Between WCAG and MWBP
WCAG and MWBP both aim to improve the Web interaction of users who experience barriers due to either disabilities or the device used to access the Web. However, WCAG and MWBP have slightly different approaches. For example, a key feature of WCAG 2.0 success criteria is that they are specifically designed to be testable statements. Although some of the Mobile Web Best Practices are testable, they are not all intended to be testable.
While the two documents show significant overlap in many areas, there are different degrees of overlap between individual technical requirements, so that there is not always a one-to-one mapping between them. For instance, WCAG has some requirements that are specific to accessibility needs of people with disabilities, and that are not relevant for mobile devices (for example, requirements that specifically address assistive technology). Conversely, MWBP has other requirements that are specific to mobile devices only (for example, requirements to minimize battery consumption and CPU power). However, in general many requirements are applicable for both groups of users (for example, requirements for color contrast, flexible font sizes, etc.).
The relationship between WCAG and MWBP is too complex for a simple mapping table to adequately communicate what developers need to do to meet both. For example, in some cases complying with a specific WCAG provision will meet the related MWBP; however, the inverse is not always true and complying with the MWBP provision will not necessarily meet the related WCAG provision. Thus, there is no simple mapping table between WCAG and MWBP. The document Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities document shows generally how WCAG and MWBP relate.
Priorities and Levels
WCAG 1.0 checkpoints are Priority 1, 2, or 3. WCAG 2.0 success criteria are Level A, AA, or AAA.The Mobile Web Best Practices (BP) are not assigned priorities or levels.
How to Use This Document
Please see the following introductory and related information:
This document includes four subpages that each address a different scenario. Most people will use only one of the subpages described below:
- If you are familiar with MWBP and want to learn about additional requirements in
- If you are familiar with WCAG 1.0 and want to learn about additional requirements in MWBP, then read WCAG 1.0 to MWBP
- If you are familiar with WCAG 2.0 and want to learn about additional requirements in MWBP, then read WCAG 2.0 to MWBP
Web Content Accessibility Guidelines 2.0 and
Mobile Web Best Practices 1.0 Together
If you are not familiar with either WCAG or MWBP:
- Use Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities (which is also available in a table format) for an overview of the barriers and solutions shared by WCAG 2.0 and MWBP.
- Become familiar with WCAG 2.0.
- Use the WCAG 2.0 to MWBP subpage of this document to learn about the additional requirements in MWBP.
- Become familiar with MWBP.
From MWBP to WCAG 2.0: Making content that meets Mobile Web Best Practices also meet Web Content Accessibility Guidelines 2.0
Introduction
For those familiar with Mobile Web Best Practices (MWBP), this page describes what also needs to be done to meet Web Content Accessibility Guidelines 2.0.
Summary of work required to make content that meets MWBP also meet WCAG 2.0
Compliance with the MWBP helps go some way towards achieving compliance with some WCAG 2.0 success criteria. This section provides a summary of these success criteria. There are three possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with the MWBP, to achieve compliance with WCAG 2.0, you need to do the following:
Nothing: If a provision is labelled “Nothing” then content that complies with MWBP already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.
Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. SC links in this section point to the detail section below; BP links in this section point to the MWBP Recommendation.
- 1.3.1 Info and Relationships partially covered in different ways by each of FONTS, STRUCTURE, STYLE_SHEETS_SUPPORT, STYLE_SHEETS_USE.
- 1.3.2 Meaningful Sequence possibly covered by TABLES_LAYOUT.
- 1.4.3 Contrast (Minimum), possibly covered in different ways by each of BACKGROUND_IMAGE_READABILITY and COLOR_CONTRAST.
- 1.4.6 Contrast (Enhanced), possibly covered in different ways by each of BACKGROUND_IMAGE_READABILITY and COLOR_CONTRAST.
- 1.4.8 Visual Presentation, partially covered by SCROLLING.
- 2.1.1 Keyboard possibly covered by OBJECTS_OR_SCRIPT.
- 2.1.3 Keyboard (No Exception) possibly covered by OBJECTS_OR_SCRIPT
- 2.4.2 Page Titled, possibly covered by PAGE_TITLE.
- 2.4.4 Link Purpose (In Context), covered by LINK_TARGET_ID, possibly partially covered by IMAGE_MAPS.
- 2.4.6 Headings and Labels, possibly partially covered in different ways by each of STRUCTURE and CONTROL_LABELLING.
- 2.4.9 Link Purpose (Link Only), covered by LINK_TARGET_ID.
- 3.1.5 Reading Level, possibly covered by CLARITY.
- 3.2.1 On Focus, partially covered by POP_UPS.
- 3.2.2 On Input, partially covered by POP_UPS.
- 3.2.3 Consistent Navigation partially covered by NAVIGATION.
- 3.2.5 Change on Request, possibly covered in different ways by each of AUTO_REFRESH, POP_UPS and REDIRECTION.
- 3.3.2 Labels or Instructions, partially covered in different ways by each of CONTROL_LABELLING and CONTROL_POSITION.
- 4.1.2 Name, Role, Value, partially covered in different ways by each of CONTROL_LABELLING and NO_FRAMES.
Everything: For all other success criteria, the MWBP do not ensure compliance and it will be necessary to do the work involved. These SCs are not related to any MWBPs.
- 1.2.1 Audio-only and Video-only (Prerecorded)
- 1.2.2 Captions (Prerecorded)
- 1.2.3 Audio Description or Media Alternative (Prerecorded)
- 1.2.4 Captions (Live)
- 1.2.5 Audio Description
- 1.2.6 Sign Language
- 1.2.7 Audio Description (Extended)
- 1.2.8 Full Text Alternative
- 1.2.9 Live Audio-only
- 1.3.3 Sensory Characteristics
- 1.4.2 Audio Control
- 1.4.5 Images of Text
- 1.4.7 Low or No Background Audio
- 1.4.9 Images of Text (No Exception)
- 2.1.2 No Keyboard Trap
- 2.2.1 Timing Adjustable
- 2.2.2 Pause, Stop, Hide
- 2.2.3 No Timing
- 2.2.4 Interruptions
- 2.2.5 Re-authenticating
- 2.3.1 Three Flashes or Below Threshold
- 2.3.2 Three Flashes
- 2.4.1 Bypass Blocks
- 2.4.5 Multiple Ways
- 2.4.7 Focus Visible
- 2.4.8 Location
- 3.1.1 Language of Page
- 3.1.2 Language of Parts
- 3.1.3 Unusual Words
- 3.1.4 Abbreviations
- 3.1.6 Pronunciation
- 3.2.4 Consistent Identification
- 3.3.1 Error Identification
- 3.3.3 Error Suggestion
- 3.3.4 Error Prevention (Legal, Financial, Data)
- 3.3.5 Help
- 3.3.6 Error Prevention (All)
Addressing WCAG 2.0 Success Criteria
This section lists each of the WCAG success criteria that are related to MWBP, which are listed under “something” above. For each SC, the section title is that of the SC. This is followed by a quotation of the text of the SC (sometimes abbreviated) and a list of the BPs that can help meet it.
1.3.1 Info and Relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
- FONTS partially covers some of the sufficient techniques.
- STRUCTURE helps towards compliance with this success criterion. Although the BP title covers structural elements in general, it doesn't enumerate them. Using other commonly-accepted structural elements not mentioned in the BP can improve usability for mobile users as well as accessibility, and go some way toward compliance with this success criterion. These elements include lists, quotations and citations, table markup, and semantic aspects such as emphasis.
- STYLE_SHEETS_SUPPORT partially helps: 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.
- STYLE_SHEETS_USE possibly helps: 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, above.
Back to list of WCAG 2.0 checkpoints
1.3.2 Meaningful Sequence
Back to list of WCAG 2.0 checkpoints
1.4.3 Contrast (Minimum)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for following: (Level AA)
- Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
- BACKGROUND_IMAGE_READABILITY helps with meeting this SC.
- COLOR_CONTRAST possibly helps with meeting this SC. However, the BP is concerned with unfavorable ambient light and the ability of devices to display contrasting color at all, while users may have color blindness and color perception deficits, which may lead to different results. Using the more precise criteria given in WCAG 2.0 may help ensure compliance. Note that WCAG 2.0 suggests a Contrast Ratio and the size of text to which the ratio applies.
Back to list of WCAG 2.0 checkpoints
1.4.6 Contrast (Enhanced)
The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for...: (Level AAA)
- BACKGROUND_IMAGE_READABILITY helps with meeting this SC.
- COLOR_CONTRAST possibly helps with meeting this SC. However, the BP is concerned with unfavorable ambient light and the ability of devices to display contrasting color at all, while users may have color blindness and color perception deficits, which may lead to different results. Using the more precise criteria given in WCAG 2.0 it may help ensure compliance. Note that WCAG 2.0 suggests a Contrast Ratio and the size of text to which the ratio applies.
Back to list of WCAG 2.0 checkpoints
1.4.8 Visual Presentation
For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
- foreground and background colors can be selected by the user.
- width is no more than 80 characters or glyphs (40 if CJK).
- text is not justified (aligned to both the left and the right margins).
- line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
- text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
- SCROLLING partially helps ensure compliance with the last aspect of this SC (number 5 in the list).
Back to list of WCAG 2.0 checkpoints
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
- OBJECTS_OR_SCRIPT may possibly help: As non-compliance derives from the use of scripting or objects, content that does not use these, or in which they are used in a redundant way, complies with this this SC.
Back to list of WCAG 2.0 checkpoints
2.1.3 Keyboard (No Exception)
Back to list of WCAG 2.0 checkpoints
2.4.2 Page Titled
Web pages have titles that describe topic or purpose
- PAGE_TITLE may possibly help. However, the accessibility techniques are more detailed, and in particular may lead to a title that is longer than suitable for a mobile device. Tip: While for the mobile context it is important to keep the title short, for the general user it is also important to provide an adequate description. One way to do this (known as “front loading”) is to place the most differentiating information first. More generic information (for example the section of a site) can be placed following this, or omitted for mobile delivery.
Back to list of WCAG 2.0 checkpoints
2.4.4 Link Purpose (In Context)
Back to list of WCAG 2.0 checkpoints
2.4.6 Headings and Labels
Headings and labels describe topic or purpose. (Level AA)
- STRUCTURE may help comply with this SC as regards the use of headings.
- CONTROL_LABELLING may help comply with this SC as regards the use of form labels.
Back to list of WCAG 2.0 checkpoints
2.4.9 Link Purpose (Link Only)
A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)
- LINK_TARGET_ID may ensure compliance with this success criterion. However, the intent of the SC is to ensure that users can identify the purpose of the link out of context (for example, in a list of links created by the user agent). The SC also requires consistent identification (same destination, same description).
Back to list of WCAG 2.0 checkpoints
3.1.5 Reading Level
When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. (Level AAA)
- CLARITY may possibly help but it concerns a different aspect of language comprehension. WCAG is concerned with a user's reading ability, while this BP is concerned with reading difficulty due to context of use (for example, small screen, distracting environnment, lack of time).
When any component receives focus, it does not initiate a change of context. (Level A)
- POP_UPS partially covers this SC (as it concerns popup windows). WCAG 2.0 considers a number of different changes of context and a popup window is just one of them.
Back to list of WCAG 2.0 checkpoints
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)
- POP_UPS partially covers this SC (as it concerns popup windows). WCAG 2.0 considers a number of different changes of context and a popup window is just one of them.
Back to list of WCAG 2.0 checkpoints
3.2.3 Consistent Navigation
Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)
- NAVIGATION helps partially, although WCAG is more detailed and specific (“same relative order”) than the MWBP (“same navigation”).
Back to list of WCAG 2.0 checkpoints
3.2.5 Change on Request
Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)
- AUTO_REFRESH may possibly help. This SC 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.
- POP_UPS partially covers this SC (as it concerns popup windows). WCAG 2.0 considers a number of different changes of context and a popup window is just one of them.
- REDIRECTION may partially help. It ensures that redirection is initiated only by user request, and therefore ensures compliance in the automatic redirects situation.
Back to list of WCAG 2.0 checkpoints
3.3.2 Labels or Instructions
Labels or instructions are provided when content requires user input. (Level A)
Back to list of WCAG 2.0 checkpoints
4.1.2 Name, Role, Value
Back to list of WCAG 2.0 checkpoints
From MWBP to WCAG 1.0: Making content that meets Mobile Web Best Practices also meet Web Content Accessibility Guidelines 1.0
Introduction
For those familiar with Mobile Web Best Practices (MWBP), this page describes what also needs to be done to meet Web Content Accessibility Guidelines 1.0. W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.
Summary of work required to make content that meets MWBP also meet WCAG 1.0
Compliance with the MWBP helps go some way towards achieving compliance with some WCAG 1.0 checkpoints. This section provides a summary of these checkpoints. There are three possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with the MWBP, to achieve compliance with WCAG 1.0, you need to do the following:
Nothing: If a provision is labelled “Nothing” then content that complies with MWBP already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.
- 1.1 Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content)… (Priority 1), covered by NON-TEXT_ALTERNATIVES and possibly covered by IMAGE_MAPS.
- 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup (Priority 1), covered by USE_OF_COLOR.
- 3.2 Create documents that validate to published formal grammars (Priority 2), covered by VALID_MARKUP.
- 3.3 Use style sheets to control layout and presentation (Priority 2), covered by STYLE_SHEETS_USE.
- 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values (Priority 2), covered by MEASURES.
- 3.5 Use header elements to convey document structure and use them according to specification (Priority 2), covered by STRUCTURE.
- 6.1 Organize documents so they may be read without style sheets (Priority 1), covered by STYLE_SHEETS_SUPPORT and partially covered by FONTS.
- 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported… (Priority 1), covered by OBJECTS_OR_SCRIPT.
- 7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages (Priority 2), covered by AUTO_REFRESH.
- 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 (Priority 2), covered by REDIRECTION.
- 9.4 Create a logical tab order through links, form controls, and objects (Priority 3), covered by TAB_ORDER.
- 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls (Priority 3), covered by ACCESS_KEYS, possibly partially covered by IMAGE_MAPS and possibly partially covered by MINIMIZE_KEYSTROKES.
- 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 (Priority 2), covered by POP_UPS.
- 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas (Priority 3), covered by PROVIDE_DEFAULTS.
- 12.4 Associate labels explicitly with their controls (Priority 2), covered by CONTROL_LABELLING.
- 13.4 Use navigation mechanisms in a consistent manner (Priority 2), covered by NAVIGATION.
- 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. (Priority 3), covered by CLARITY.
Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. Checkpoint links in this section point to the detail section below; BPs link to the MWBP Recommendation.
- 1.2 Provide redundant text links for each active region of a server-side image map (Priority 1), partially covered by NON-TEXT_ALTERNATIVES and possibly covered by IMAGE_MAPS.
- 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map (Priority 3), possibly covered by IMAGE_MAPS and NON-TEXT_ALTERNATIVES.
- 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. (Priority 2 for images, Priority 3 for text), partially covered by COLOR_CONTRAST and BACKGROUND_IMAGE_READABILITY.
- 3.1 When an appropriate markup language exists, use markup rather than images to convey information (Priority 2), possibly partially covered by NON-TEXT_ALTERNATIVES and GRAPHICS_FOR_SPACING.
- 5.1 For data tables, identify row and column headers (Priority 1), possibly covered by TABLES_SUPPORT and TABLES_ALTERNATIVES.
- 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells (Priority 1), possibly covered by TABLES_SUPPORT, TABLES_NESTED and TABLES_ALTERNATIVES.
- 5.3 Do not use tables for layout unless the table makes sense when linearized (Priority 2), possibly covered by TABLES_LAYOUT, TABLES_SUPPORT and TABLES_ALTERNATIVES.
- 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting (Priority 2), possibly covered by TABLES_LAYOUT, TABLES_SUPPORT and TABLES_ALTERNATIVES.
- 5.5 Provide summaries for tables (Priority 3), possibly covered by TABLES_SUPPORT and TABLES_ALTERNATIVES.
- 5.6 Provide abbreviations for header labels (Priority 3), possibly covered by TABLES_SUPPORT and TABLES_ALTERNATIVES.
- 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes (Priority 1), possibly partially covered by OBJECTS_OR_SCRIPT.
- 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape (Priority 1), possibly covered by IMAGE_MAPS.
- 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 (Priority 2), partially covered by CONTROL_POSITION.
- 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns (Priority 3), possibly partially covered TABLES_ALTERNATIVES.
- 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported (Priority 2), possibly partially covered by VALID_MARKUP.
- 11.2 Avoid deprecated features of W3C technologies (Priority 2), possibly partially covered by VALID_MARKUP and partially covered by FONTS.
- 12.1 Title each frame to facilitate frame identification and navigation (Priority 1), possibly covered by NO_FRAMES.
- 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone (Priority 2), possibly covered by NO_FRAMES.
- 12.3 Divide large blocks of information into more manageable groups where natural and appropriate (Priority 2), partially covered by PAGE_SIZE_USABLE.
- 13.1 Clearly identify the target of each link (Priority 2), partially covered by LINK_TARGET_ID.
- 13.2 Provide metadata to add semantic information to pages and sites (Priority 2), partially covered by PAGE_TITLE.
- 13.5 Provide navigation bars to highlight and give access to the navigation mechanism (Priority 3), possibly NAVBAR.
- 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group (Priority 3), possibly NAVBAR and partially possibly CENTRAL_MEANING.
- 14.1 Use the clearest and simplest language appropriate for a site's content (Priority 1), partially covered by CLARITY.
Everything: For all other CPs, the MWBP do not ensure compliance and it will be necessary to do the work involved. These CPs are not related to any MWBPs.
- 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation (Priority 1).
- 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation (Priority 1).
- 4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions) (Priority 1)
- 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. (Priority 1)
- 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies (Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2)
- 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. (Priority 1)
- 3.6 Mark up lists and list items properly. (Priority 2)
- 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.
- 6.4 For scripts and applets, ensure that event handlers are input device-independent. (Priority 2)
- 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. (Priority 2)
- 7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). (Priority 2)
- 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. (Priority 2)
- 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies (priority 1 if functionality is important and not presented elsewhere). (Priority 2)
- 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. (Priority 2)
- 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. (Priority 2)
- 13.3 Provide information about the general layout of a site (e.g., a site map or table of contents). (Priority 2)
- 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. (Priority 3)
- 4.3 Identify the primary natural language of a document. (Priority 3)
- 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. (Priority 3)
- 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) (Priority 3)
- 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. (Priority 3)
- 13.9 Provide information about document collections (i.e., documents comprising multiple pages). (Priority 3)
- 13.10 Provide a means to skip over multi-line ASCII art. (Priority 3)
- 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.
- 14.3 Create a style of presentation that is consistent across pages. (Priority 3)
Addressing WCAG 1.0 Checkpoints
This section lists each of the WCAG 1.0 checkpoints that are related to MWBP, which are listed under “something” above. For each checkpoint, the section title is that of the checkpoint. This is followed by a quotation of the text of the checkpoint (sometimes abbreviated) and a list of the BPs that can help meet it. The information given in this document is intentionally brief. A separate document, entitled “Techniques for Web Content Accessibility Guidelines 1.0”, explains how to implement the checkpoints. The Techniques Document discusses each checkpoint in more detail and provides examples
1.2 Provide redundant text links for each active region of a server-side image map
WCAG 1.0: “Provide redundant text links for each active region of a server-side image map.” (Priority 1)
- NON-TEXT_ALTERNATIVES ensures there is a text alternative for any server-side image map.
- IMAGE_MAPS: If, as suggested by this BP, image maps are not used then the checkpoint does not apply. However, if you have used server-side image maps, then provide redundant text links for each active region. Techniques for checkpoint 1.2 provides further information on how to achieve this.
Back to list of WCAG 1.0 checkpoints
1.5 …provide redundant text links for each active region of a client-side image map
WCAG 1.0: “Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.” (Priority 3)
- NON-TEXT_ALTERNATIVES ensures there is a text alternative for any image map.
- IMAGE_MAPS: If, as suggested by this BP, image maps are not used then the checkpoint does not apply.
Back to list of WCAG 1.0 checkpoints
2.2 Ensure that foreground and background color combinations provide sufficient contrast…
WCAG 1.0: “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 (for images). [Priority 2 for images, Priority 3 for text]”
- COLOR_CONTRAST partially covers this checkpoint. However, the main focus of the BP is the limitations of mobile devices in displaying contrasting colours.
- BACKGROUND_IMAGE_READABILITY partially covers this checkpoint as it also focuses on the device limitations.
Back to list of WCAG 1.0 checkpoints
3.1 When an appropriate markup language exists, use markup…
WCAG 1.0: “When an appropriate markup language exists, use markup rather than images to convey information" (Priority 2).
- GRAPHICS_FOR_SPACING partially covers this checkpoint. However, the scope of this checkpoint is much broader than that of the BP, which only refers to images used for spacing. This checkpoint also refers to using appropriate markup for mathematical equations, structure of the document, etc.
Back to list of WCAG 1.0 checkpoints
- TABLES_SUPPORT possibly covers this checkpoint: In contexts where tables are not used, this checkpoint does not apply.
- TABLES_ALTERNATIVES possibly covers this checkpoint: In contexts where alternatives are provided, this checkpoint does not apply.
Depending on device support, tables may or may not be used, as described for above. However, in contexts where tables are used, identify row and column headers using appropriate markup as required by this checkpoint.
Back to list of WCAG 1.0 checkpoints
5.2 For data tables that have two or more logical levels of row or column headers…
WCAG 1.0: “For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.” (Priority 1)
Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, identify row and column headers using appropriate markup as required by this checkpoint.
Back to list of WCAG 1.0 checkpoints
5.3 Do not use tables for layout unless…
WCAG 1.0: “Do not use tables for layout unless the table makes sense when linearized.” (Priority 2)
- TABLES_LAYOUT covers this checkpoint: As tables are not used, this checkpoint does not apply.
Back to list of WCAG 1.0 checkpoints
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting
WCAG 1.0: “If a table is used for layout, do not use any structural markup for the purpose of visual formatting.” (Priority 2)
- TABLES_LAYOUT covers this checkpoint: As tables are not used, this checkpoint does not apply.
Back to list of WCAG 1.0 checkpoints
5.5 Provide summaries for tables
WCAG 1.0: “Provide summaries for tables. For example, in HTML, use the “summary” attribute of the TABLE element (Priority 3).
Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, provide summaries as required by this checkpoint.
Back to list of WCAG 1.0 checkpoints
5.6 Provide abbreviations for header labels
WCAG 1.0: “Provide abbreviations for header labels.” (Priority 3)
Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used, provide abbreviations for header labels where appropriate, as described by this checkpoint.
Back to list of WCAG 1.0 checkpoints
6.2 Ensure that equivalents for dynamic content are updated…
WCAG 1.0: “Ensure that equivalents for dynamic content are updated when the dynamic content changes.” (Priority 1)
- OBJECTS_OR_SCRIPT may partly cover this checkpoint: In contexts where objects and scripts are not used, this checkpoint does not apply to them.
- FRAMES partly covers this checkpoint: Insofar as frames are not used, it does not apply to them.
Back to list of WCAG 1.0 checkpoints
9.1 Provide client-side image maps instead of server-side image maps…
WCAG 1.0: “Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.” (Priority 1)
- IMAGE_MAPS may possibly cover this checkpoint: In contexts where image maps are not used, this checkpoint does not apply. However, if they are necessary, client-side image maps should be used where possible.
Back to list of WCAG 1.0 checkpoints
10.2 Until user agents support explicit associations between labels…
WCAG 1.0: “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.” (Priority 2)
- CONTROL_POSITION partially covers this checkpoint. However, WCAG is more specific about the positioning of the labels.
Back to list of WCAG 1.0 checkpoints
10.3 Until user agents (including assistive technologies) render side-by-side text correctly…
WCAG 1.0: “Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.” (Priority 3)
Depending on device support, tables may or may not be used, as described for checkpoint 5.1, above. However, in contexts where tables are used to lay out text in parallel, word-wrapped columns, provide a linear text alternative, as described by this checkpoint.
Back to list of WCAG 1.0 checkpoints
11.1 Use W3C technologies when they are available and appropriate for a task…
WCAG 1.0: “Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.” (Priority 2)
- VALID_MARKUP partially covers this checkpoint (as it recommends that documents be valid to published formal grammars), but the checkpoint also recommends using the latest, supported version of those grammars.
Back to list of WCAG 1.0 checkpoints
11.2 Avoid deprecated features of W3C technologies
WCAG 1.0: “Avoid deprecated features of W3C technologies” (Priority 2)
- VALID_MARKUP may help with this checkpoint if the validator indicates deprecated markup.
Back to list of WCAG 1.0 checkpoints
12.1 Title each frame to facilitate frame identification and navigation
WCAG 1.0: “Title each frame to facilitate frame identification and navigation” (Priority 1)
- FRAMES covers this checkpoint: As frames are not used, it does not apply.
Back to list of WCAG 1.0 checkpoints
12.2 Describe the purpose of frames and how frames relate to each other…
WCAG 1.0: “Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.” (Priority 2)
- FRAMES covers this checkpoint: As frames are not used, it does not apply.
Back to list of WCAG 1.0 checkpoints
WCAG 1.0: “Divide large blocks of information into more manageable groups where natural and appropriate.” (Priority 2)
- PAGE_SIZE_USABLE partially covers this checkpoint. However, the BP concerns splitting content into smaller pages while WCAG also requires grouping and structuring content within a page.
Back to list of WCAG 1.0 checkpoints
13.1 Clearly identify the target of each link
WCAG 1.0: “Clearly identify the target of each link.” (Priority 2)
- LINK_TARGET_ID may ensure compliance with this checkpoint. However, the intent of the checkpoint is to ensure that users can identify the purpose of the link out of context (for example, in a list of links created by the user agent). The techniques for the checkpoint also require consistent identification (same destination, same description).
Back to list of WCAG 1.0 checkpoints
WCAG 1.0: “Provide metadata to add semantic information to pages and sites.” (Priority 2)
- PAGE_TITLE partially covers this checkpoint. A page title is semantic metadata, but the scope of this checkpoint is much broader. For example HTML provides the
META
element, and allows linking of metadata contained in RDF documents, and the REL
element to describe relationships between pages. While such rich metadata may not be supported by existing mobile devices it can be useful to other systems.
Back to list of WCAG 1.0 checkpoints
13.5 Provide navigation bars to highlight and give access to the navigation mechanism
WCAG 1.0: “Provide navigation bars to highlight and give access to the navigation mechanism” (Priority 3)
- NAVBAR partially covers this checkpoint. The BP requires minimum navigation at the top of the page, which is not the main focus of the checkpoint.
Back to list of WCAG 1.0 checkpoints
13.6 Group related links, identify the group (for user agents)…
WCAG 1.0: “Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group” (Priority 3)
- NAVBAR may go some way towards covering this checkpoint if the navigation bar is a group (for example a list).
- CENTRAL_MEANING partially covers this checkpoint. It focuses on designing pages such that the user does not need to scroll vertically to reach the main content of the page. However, this checkpoint is more about augmenting the page content such that the user can skip past certain parts of the content.
Back to list of WCAG 1.0 checkpoints
14.1 Use the clearest and simplest language appropriate for a site's content
WCAG 1.0: “Use the clearest and simplest language appropriate for a site's content.” (Priority 1)
- CLARITY may possibly help but it concerns a different aspect of language comprehension. WCAG is concerned with a user's reading ability, while this BP is concerned with reading difficulty due to context of use (for example, small screen, distracting environnment, lack of time).
Back to list of WCAG 1.0 checkpoints
From WCAG 2.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 2.0 also meet Mobile Web Best Practices
Introduction
For those familiar with Web Content Accessibility Guidelines 2.0, this page describes what also needs to be done to meet Mobile Web Best Practices (MWBP).
Summary of work required to make content that meets WCAG 2.0 also meet MWBP
Compliance with WCAG 2.0 helps go some way towards achieving compliance with some of the MWBP. This section provides a summary of these BPs. There are two possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. Note that coverage may depend on WCAG compliance level achieved and so a BP may appear in “something” and “nothing” lists (for example, LINK_TARGET_ID). To summarise, if your content already complies with WCAG 2.0, to achieve compliance with the MWBP, you need to do the following:
Nothing: If a provision is labelled “Nothing” then content that complies with WCAG 2.0 already complies with the provision and no further effort is necessary. The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.
Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. BP links in this section point to the detail section below; SC links in this section point to WCAG 2.0.
- BACKGROUND_IMAGE_READABILITY, possibly covered at level AA by 1.4.3 Contrast (Minimum) and at level AAA 1.4.6 Contrast (Enhanced)
- COLOR_CONTRAST, partially covered at level AA by success criterion 1.4.3 Contrast (Minimum) and at level AAA 1.4.6 Contrast (Enhanced)
- CONTROL_LABELLING, possibly covered at level A by 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.
- CONTROL_POSITION, possibly covered at level A by 1.3.1 Info and Relationships.
- GRAPHICS_FOR_SPACING, possibly covered at level A by 1.3.1 Info and Relationships.
- LINK_TARGET_ID, partially covered at level A by 2.4.4 Link Purpose (In Context).
- MEASURES, possibly covered at level AA by 1.4.4 Resize text.
- NAVIGATION, partially covered at level AA by 3.2.3 Consistent Navigation and at level AAA 2.4.10 Section Headings.
- NON-TEXT_ALTERNATIVES, partially covered at level AAA by 1.2.7 Full Text Alternative (but covered already at that level by 1.1.1 Non-text Content).
- PAGE_TITLE, possibly covered at level A by 2.4.2 Page Titled.
- POP_UPS, partially covered at level A by 3.2.1 On Focus and 3.2.2 On Input and possibly at level AAA by 3.2.5 Change on Request.
- REDIRECTION, covered at level A by 2.2.1 Timing Adjustable and at level AAA by 2.2.4 Interruptions and 3.2.5 Change on Request.
- STRUCTURE, possibly covered at level A by success criterion 1.3.1 Info and Relationships and at level AA by 2.4.6 Headings and Labels and at level AAA by 2.4.10 Section Headings.
- STYLE_SHEETS_SUPPORT, may be covered at level A by success criterion 1.3.1 Info and Relationships.
- VALID_MARKUP, possibly covered at level A by 4.1.1 Parsing.
Everything: For all other BPs, WCAG 2.0 does not ensure compliance and it will be necessary to do the work involved. These BPs are not related to any WCAG 2.0 success criteria.
- ACCESS_KEYS
- AVOID_FREE_TEXT
- BALANCE
- CACHING
- CAPABILITIES
- CENTRAL_MEANING
- CHARACTER_ENCODING_SUPPORT
- CHARACTER_ENCODING_USE
- CLARITY
- CONTENT_FORMAT_PREFERRED
- CONTENT_FORMAT_SUPPORT
- COOKIES
- DEFAULT_INPUT_MODE
- DEFICIENCIES
- ERROR_MESSAGES
- EXTERNAL_RESOURCES
- IMAGE_MAPS
- IMAGES_RESIZING
- IMAGES_SPECIFY_SIZE
- LARGE_GRAPHICS
- LIMITED
- LINK_TARGET_FORMAT
- MINIMIZE
- MINIMIZE_KEYSTROKES
- NAVBAR
- NO_FRAMES
- OBJECTS_OR_SCRIPT
- PAGE_SIZE_LIMIT
- PAGE_SIZE_USABLE
- PROVIDE_DEFAULTS
- SCROLLING
- STYLE_SHEETS_SIZE
- SUITABLE
- TABLES_ALTERNATIVES
- TABLES_LAYOUT
- TABLES_NESTED
- TABLES_SUPPORT
- TESTING
- THEMATIC_CONSISTENCY
- URIS
Addressing Mobile Web Best Practices
This section lists each of the MWBPs that are related to WCAG 2.0 success criteria, which are listed under “something” above. For each BP, the section title is that of the BP. This is followed by a list of the SCs that can help meet it.
Back to Best Practices list.
[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device
If overall contrast is sufficient, this goes part of the way to ensuring readability with background images.
Back to Best Practices list.
[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast
Unlike MWBP, WCAG specifies a contrast ratio and algorithm and certain types of content that are excluded from the requirement. The following SCs may ensure compliance with this BP. However, note that WCAG allows for exceptions for cases like large text, incidental text or images of text and logotypes. If content covered by the BP is not excluded, then compliance is ensured.
Back to Best Practices list.
[CONTROL_LABELLING] Label all form controls appropriately and explicitly associate labels with form controls
The following SCs ensure compliance with this BP when using label
elements to associate text labels with form controls (1.3.1 below), and either 3.3.2 or 4.1.2.
Back to Best Practices list.
[CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to
- 1.3.1 Info and Relationships at level A, if the label element is used. The advisory (optional) technique (“Positioning labels to maximize predictability of relationships”) is also required to ensure compliance with this BP.
Back to Best Practices list.
- 1.3.1 Info and Relationships at level A, possibly. The SC does not prohibit the use of graphics for spacing, but some of the sufficient techniques may ensure compliance with this BP by encouraging the use of alternatives.
Back to Best Practices list.
[LINK_TARGET_ID] Clearly identify the target of each link
- 2.4.4 Link Purpose (In Context) at level A goes some way to meeting this BP, but the SC provides for indicating the link purpose in the context which is not contemplated by the BP, and in the title attribute or table cell header which are unlikely to be supported adequately by a mobile browser. As a result, content that conforms to this SC may not meet the BP.
- 2.4.9 Link Purpose (Link Only) at level AAA ensures compliance with this BP.
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
WCAG 2.0 does not prohibit the use of the pixel unit of measure.
- 1.4.4 Resize text at level AA helps comply with this BP if named font sizes, em units or percentages are used.
Back to Best Practices list.
[NAVIGATION] Provide consistent navigation mechanisms
Back to Best Practices list.
[NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element
Back to Best Practices list.
[PAGE_TITLE] Provide a short but descriptive page title
- 2.4.2 Page Titled at level A possibly ensures compliance with this BP. However, to comply with the BP, it may be necessary to truncate the title to meet the BP. In this case it may be useful to put the most important, differentiating information first, also helping screen reader users.
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
- 3.2.1 On Focus at level A may possibly go some way to achieving compliance with this BP, but the SC allows popups.
- 3.2.2 On Input at level A may possibly go some way to achieving compliance with this BP, but the SC allows popups.
- 3.2.5 Change on Request at level AAA may possibly go some way toward compliance, but the SC does allow use of the
target
attribute.
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
The following SCs go some way to achieving compliance with this BP. Specifically, failure F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh with a time-out ensures compliance with this BP.
Back to Best Practices list.
[STRUCTURE] Use features of the markup language to indicate logical document structure
The BP is less explicit about what structural elements to use, but the following SCs probably cover its intent.
Back to Best Practices list.
[STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets
- 1.3.1 Info and Relationships at level A may ensure compliance, if style sheets are not relied on. However, with WCAG 2.0, you can rely on style sheets if you consider it to be an accessibility supported Web technology. It is possible to have all of the information and structure be programmatically determined but the page would not be usable without the style sheets. ARIA is one technology that depends heavily on style sheets and ARIA sites will not be usable (by sighted users) with the style sheets disabled. Also, WCAG 2.0 allows, but does not encourage, layout tables as long as they meet all of the other criteria. The MWBP requires the use of style sheets for layout, and does not allow layout tables, so if layout tables are used, then this SC would not meet the BP.
Back to Best Practices list.
[VALID_MARKUP] Create documents that validate to published formal grammars
- 4.1.1 Parsing may go some way to complying with this BP with some of the sufficient techniques.
Back to Best Practices list.
From WCAG 1.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 1.0 also meet Mobile Web Best Practices
Introduction
For those familiar with Web Content Accessibility Guidelines 1.0, this page describes what also needs to be done to meet Mobile Web Best Practices (MWBP). W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0. If your site is required to meet WCAG 1.0, you can develop it to meet both WCAG 1.0 and WCAG 2.0.
Summary of work required to make content that meets WCAG 1.0 also meet MWBP
Compliance with WCAG 1.0 helps go some way towards achieving compliance with some of the MWBP. This section provides a summary of these BPs. There are two possible levels of effort required, labelled for simplicity with the keywords nothing, something and everything. To summarise, if your content already complies with WCAG 1.0, to achieve compliance with the MWBP, you need to do the following:
Note on inconsistent links: Links in the “something” and “nothing” sections point to within this page. Links in the “everything” section point to the Recommendation. REVIEW NOTE: Is this too confusing? Suggestions for better ways to do it?
Nothing: If a provision is labelled “Nothing” then content that complies with WCAG 1.0 already complies with the provision and no further effort is necessary.The following list includes all of the provisions that are marked “Nothing”. Links in this section point to the relevant provisions.
- AUTO_REFRESH, covered at priority 2 by 7.4 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically.
- CLARITY, covered at priority 3 by 13.8 Place distinguishing information at the beginning of headings, paragraphs.
- CONTROL_LABELLING, covered at priority 2 by 12.4 Associate labels explicitly with their controls.
- GRAPHICS_FOR_SPACING, covered at priority 2 by 3.1 When an appropriate markup language exists, use markup.
- LINK_TARGET_ID, covered at priority 2 by 13.1 Clearly identify the target of each link.
- MEASURES, covered at priority 2 by 3.4 Use relative rather than absolute units in markup language attribute values.
- NAVIGATION, covered at priority 2 by 13.4 Use navigation mechanisms in a consistent manner.
- NON-TEXT_ALTERNATIVES, covered at priority 1 by 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content).
- OBJECTS_OR_SCRIPT, covered at priority 1 by 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.
- POP_UPS, covered at priority 2 by 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear.
- PROVIDE_DEFAULTS, covered at priority 3 by 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.
- REDIRECTION, covered at priority 2 by 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.
- STRUCTURE, covered at priority 2 by 3.5 Use header elements to convey document structure and use them according to specification.
- STYLE_SHEETS_SUPPORT, covered at priority 1 by 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
- STYLE_SHEETS_USE, covered at priority 2 by 3.3 Use style sheets to control layout and presentation.
- TAB_ORDER, covered at priority 3 by 9.4 Create a logical tab order through links, form controls, and objects.
- USE_OF_COLOR, covered at priority 1 by 2.1 Ensure that all information conveyed with color is also available without color.
- VALID_MARKUP, covered at priority 2 by 3.2 Create documents that validate to published formal grammars.
Something: If a provision is labelled “Something” then more effort of some kind is necessary to comply with the provision. All of the provisions marked “Something” are included in the list below. Each item in the list is a link to an explanation of what is required, in the next section of this report. For each there is a list of the provisions that may provide some compliance or are in some way related. There is no direct correspondence between one provision and another. In some cases, it may be necessary to make an extra effort or to consider a more diverse range of user needs. In these cases, the word “possibly” is used. In other cases scope may be different, giving partial compliance. In these cases the word “partially” is used. BP links in this section point to the detail section below; checkpoint links links in this section point to the WCAG 1.0.
- ACCESS_KEYS, partially covered at priority 3 by 9.5 Provide keyboard shortcuts to important links.
- BACKGROUND_IMAGE_READABILITY, partially covered at priority 2 for images, priority 3 for text by 2.2 Ensure that foreground and background color combinations provide sufficient contrast…
- COLOR_CONTRAST, partially covered at partially covered at priority 2 for images, priority 3 for text by 2.2 Ensure that foreground and background color combinations provide sufficient contrast…
- CONTROL_POSITION, partially covered at priority 2 by 10.2 Until user agents support explicit associations between labels and form controls…
- FONTS, partially covered at priority 1 by 6.1 Organize documents so they may be read without style sheets… and partially at priority 2 by 11.2 Avoid deprecated features of W3C technologies.
- NAVBAR, partially covered at priority 3 by 13.5 Provide navigation bars to highlight and give access to the navigation mechanism.
- PAGE_SIZE_USABLE, partially covered at priority 2 by 12.3 Divide large blocks of information into more manageable groups where natural and appropriate.
- PAGE_TITLE, possibly covered at priority 2 by 13.2 Provide metadata to add semantic information to pages and sites.
- TABLES_ALTERNATIVES, possibly partially covered at priority 2 by 5.3 Do not use tables for layout unless the table makes sense when linearized.
- TABLES_LAYOUT, possibly covered at priority 2 by 5.3 Do not use tables for layout unless the table makes sense when linearized.,' in WCAG 1.0 document" href="http://www.w3.org/TR/WAI-WEBCONTENT/#tech-style-sheets">3.3 Use style sheets to control layout and presentation and 5.3 Do not use tables for layout unless the table makes sense when linearized.
Everything: For all other BPs, WCAG 1.0 does not ensure compliance and it will be necessary to do the work involved. These BPs are not related to any WCAG 1.0 checkpoints.
- BALANCE
- AVOID_FREE_TEXT
- ERROR_MESSAGES
- DEFAULT_INPUT_MODE
- SCROLLING
- TESTING
- THEMATIC_CONSISTENCY
- URIS
- MINIMIZE_KEYSTROKES
- NO_FRAMES
- TABLES_NESTED
- TABLES_SUPPORT
- CACHING
- CAPABILITIES
- CHARACTER_ENCODING_SUPPORT
- CHARACTER_ENCODING_USE
- CONTENT_FORMAT_PREFERRED
- CONTENT_FORMAT_SUPPORT
- COOKIES
- DEFICIENCIES
- EXTERNAL_RESOURCES
- IMAGES_RESIZING
- LARGE_GRAPHICS
- LIMITED
- MINIMIZE
- PAGE_SIZE_LIMIT
- SUITABLE
Addressing Mobile Web Best Practices
This section lists each of the MWBPs that are related to WCAG 1.0 checkpoints, which are listed under “something” above. For each BP, the section title is that of the BP. This is followed by a list of the checkpoints that can help meet it.
[ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality
Back to Best Practices list.
[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device
Back to Best Practices list.
[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast
Back to Best Practices list.
[CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to
Back to Best Practices list.
[FONTS] Do not rely on support of font related styling
Back to Best Practices list.
[NAVBAR] Provide only minimal navigation at the top of the page
Back to Best Practices list.
[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions
- 12.3 Divide large blocks of information into more manageable groups where natural and appropriate at priority 2 possibly covers this best practice. However, the BP focuses on splitting content into smaller pages to address the limited memory, processing capacity and screen size of mobile devices, while WCAG is about structuring content in a more general way. Therefore, to fully cover this checkpoint ensure that it does not take too long to load a page and also the user does not have poor scrolling experience.
Back to Best Practices list.
[PAGE_TITLE] Provide a short but descriptive page title
Back to Best Practices list.
[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation
Back to Best Practices list.
[TABLES_LAYOUT] Do not use tables for layout
Back to Best Practices list.
For the latest version of any W3C specification, please consult the list of W3C Technical Reports.
- [WAI/Experiences]
- Experiences Shared by People with Disabilities and by People Using Mobile Devices, eds. Yesilada, Y., Chuter, A., and Henry, S.L.
- [WAI/Mobile]
- Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices, eds. Thorp, J. and Henry, S.L.
- [MWBP1.0]
- Mobile Web Best Practices 1.0, eds. Rabin, J. and McCathieNevile, C.
- [WCAG1.0]
- Web Content Accessibility Guidelines 1.0, eds. W. Chisholm, G. Vanderheiden and I. Jacobs (see http://www.w3.org/TR/WCAG10/)
- [WCAG2.0]
- Web Content Accessibility Guidelines 2.0, eds. B. Caldwell, M. Cooper, L. Guarino Reid and G. Vanderheiden (see http://www.w3.org/TR/WCAG20)
Appendix B: Acknowledgements
This document was developed by the WAI Education & Outreach Working Group and the Mobile Web Best Practices Working Group. Charles McCathieNevile (Opera Software) also contributed to this document.