- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Tue, 4 Jul 2006 12:14:45 -0500
- To: <w3c-wai-gl@w3.org>
- Message-ID: <008301c69f8d$5a942060$6401a8c0@NC6000BAK>
I have never been one who could remember numbers well. So have always liked the idea of having handles (a word or three) for success criteria etc. Until the settled down though it was hard to do. And a couple attempts didn't work well. With three commenters asking for handles or short names I took another whack. They are pasted below and also can be found as an HTML document at Handles for WCAG 2.0 SC <http://www.w3.org/WAI/GL/2006/07/SC-handles.htm> <http://www.w3.org/WAI/GL/2006/07/SC-handles.htm> Take a lood and send any suggestions. A few rules and cautions about handles. Handles are to make things easier to find if you know they are there. Handles make it easier to talk about and refer to items. 1) they should be as short as possible 2) they should be unique (good scent) a. you should not have two handles that "might be the handle for the item I want" 3) they should NOT try to capture the guideline/success criterion/ etc in a few words a. this is dangerous - and people start treating the handle as the criterion. b. If we can ever accurately capture a success criterion in a short name - then the handle should BE the success criterion. c. Having handles that sounds like success criterion is not good 4) If you are looking for a guideline and see the handle for it you should know you found it 5) You do NOT have to be able to reconstruct a guideline from a short name (See #3) 6) If someone names the 'handle' you should know (or be able to easily find) which one of the success criterion they are referring to (but not what it says). 7) If asked to match the items and their handles - you should be able to do it without error. (see #2) 8) If asked to recall the items from their handles - you should fail (unless you have already memorized them and are just matching your memorized items to the handles ( see #7) Below are the SUCCESS CRITERION with the handles. Then below that is a listing of just the handles. Some are not very short - but couldn't think how to make them shorter and not ambiguous. Suggestions welcome. Just send the # and handle idea. Gregg ------------------------ Gregg C Vanderheiden Ph.D. Professor - Depts of Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison < <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848 The Player for my DSS sound file is at http://tinyurl.com/dho6b <http://trace.wisc.edu:8080/mailman/listinfo/> Handles for WCAG 2.0 SC Guideline 1.1 Provide text alternatives for all non-text content 1.1.1 Non-text Content: For all non-text content, one of the following is true: * General Non-text Content: If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content. * Special Cases Label only: If non-text content is multimedia; live audio-only or live video-only content; a test or exercise that must use a particular sense; or primarily intended to create a specific sensory experience; then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2 Provide synchronized alternatives for multimedia .) * Turing Exception: If the purpose of non-text content is to confirm that content is being operated by a person rather than a computer, different forms are provided to accommodate multiple disabilities. * Decoration-Formatting-Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology. Guideline 1.2 Provide synchronized alternatives for multimedia 1.2.1 Captions: Captions are provided for prerecorded multimedia. 1.2.2 Audio Desc. or FMTA: Audio descriptions of video, or a full multimedia text alternative including any interaction, are provided for prerecorded multimedia. 1.2.3 Audio Desc.: Audio descriptions of video are provided for prerecorded multimedia. 1.2.4 Live Captions: Captions are provided for live multimedia. 1.2.5 Sign Language: Sign language interpretation is provided for multimedia. 1.2.6 Ext. Audio Desc.: Extended audio descriptions of video are provided for prerecorded multimedia. 1.2.7 FMTA: For prerecorded multimedia, a full multimedia text alternative including any interaction is provided. Guideline 1.3 Ensure that information and structure can be separated from presentation 1.3.1 Info & Relationships: Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. 1.3.2 Color: Any information that is conveyed by color is also visually evident without color. 1.3.3 Meaningful Sequence: When the sequence of the content affects its meaning, that sequence can be programmatically determined. 1.3.4 Text variations: Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined. 1.3.5 Size-Shape-Location: Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components. Guideline 1.4 Make it easy to distinguish foreground information from its background 1.4.1 Contrast 5:1: Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. 1.4.2 Background Audio Turnoff: A mechanism is available to turn off background audio that plays automatically, without requiring the user to turn off all audio. 1.4.3 Contrast 10:1: Text or diagrams, and their background, have a luminosity contrast ratio of at least 10:1. 1.4.4 Low/No Background Audio: Audio content does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground audio content, with the exception of occasional sound effects. Guideline 2.1 Make all functionality operable via a keyboard interface 2.1.1 Keyboard: All functionality of the content is operable in a non-time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. 2.1.2 Keyboard, no exception: All functionality of the content is operable in a non-time-dependent manner through a keyboard interface. Guideline 2.2 Allow users to control time limits on their reading or interaction 2.2.1 Time-out: For each time-out that is a function of the content, at least one of the following is true: * Deactivate: the user is allowed to deactivate the time-out; or * Adjust: the user is allowed to adjust the time-out over a wide range that is at least ten times the length of the default setting; or * Extend: the user is warned before time expires and given at least 20 seconds to extend the time-out with a simple action (for example, "hit any key"), and the user is allowed to extend the timeout at least ten times; or * Real-time exception: the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible; or * Essential Exception: the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity. 2.2.2 Blinking: Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component. 2.2.3 Pausing: Content can be paused by the user unless the timing or movement is part of an activity where timing or movement is essential. 2.2.4 No Timing: Except for real-time events, timing is not an essential part of the event or activity presented by the content. 2.2.5 Interruptions: Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. 2.2.6 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity 2.3.1 Flash Threshold: Content does not violate the general flash threshold or the red flash threshold 2.3.2 Flashes < 4: Web units do not contain any components that flash more than three times in any 1-second period. Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web units. 2.4.2 Multiple Ways: More than one way is available to locate content within a set of Web units where content is not the result of, or a step in, a process or task. 2.4.3 Unit titled: Web units have titles. 2.4.4 Link Purpose L2: Each link is programmatically associated with text from which its purpose can be determined. 2.4.5 Labels Descriptive: Titles, headings, and labels are descriptive. 2.4.6 Focus order: When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. 2.4.7 Location: Information about the user's location within a set of Web units is available. 2.4.8 Link Purpose L3: The purpose of each link can be programmatically determined from the link. Guideline 2.5 Help users avoid mistakes and make it easy to correct mistakes that do occur 2.5.1 Error Identification: If an input error is detected, the error is identified and described to the user in text. 2.5.2 Error Suggestion: If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user. 2.5.3 Error Prevention: For forms that cause legal or financial transactions to occur, that modify or delete data in data storage systems, or that submit test responses, at least one of the following is true: 1. Reversible: Actions are reversible. 2. Checked: Actions are checked for input errors before going on to the next step in the process. 3. Confirmed: The user is able to review and confirm or correct information before submitting it. 2.5.4 Help: Context-sensitive help is available for text input. Guideline 3.1 Make text content readable and understandable. 3.1.1 Lang of unit: The primary natural language or languages of the Web unit can be programmatically determined. 3.1.2 Lang of parts: The natural language of each passage or phrase in the Web unit can be programmatically determined. 3.1.3 Unusual words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. 3.1.4 Abbreviations: A mechanism for finding the expanded form of abbreviations is available. 3.1.5 Reading level: When text requires reading ability more advanced than the lower secondary education level, supplemental content is available that does not require reading ability more advanced than the lower secondary education level. 3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning cannot be determined without pronunciation. Guideline 3.2 Make the placement and functionality of content predictable. 3.2.1 On focus: When any component receives focus, it does not cause a change of context. 3.2.2 On input: Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behavior. 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web units within a set of Web units or other primary resources occur in the same relative order each time they are repeated, unless a change is initiated by the user. 3.2.4 Consistent ID: Components that have the same functionality within a set of Web units are identified consistently. 3.2.5 Change on request: Changes of context are initiated only by user request. Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies) 4.1.1 Parsing: Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous. 4.1.2 Name-Role-Value: For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. Guideline 4.2 Ensure that content is accessible or provide an accessible alternative 4.2.1 Alternate versions- L1: At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. 4.2.2 Non-Baseline Content L1: Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: 1. No Keyboard Trap: If content can be entered using the keyboard, then the content can be exited using the keyboard. 2. Flash threshold: Content conforms to success criterion 2.3.1 (general and red flash). 4.2.3 Alternate versions- L2: At least one version of the content meets all level 2 success criteria, but alternate version(s) that do not meet all level 2 success criteria may be available from the same URI. 4.2.4 Non-Baseline Content L3: Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and Level 2 requirements supported by the technologies. Summary - test The test of a handle is not whether it can substitute for the SC. If we have a short valid way to express the SC we should use it instead of the SC. Other short versions are dangerous because they get people relying on them and not reading the SC. (We will visit this problem on the Quicktips - but they are not meant to be short versions of the SC but short easy to understand list of things that are compatible with the SC but not the same. Usually they are more restrictive than the SC, often they are technology specific. But they are useful because they are simple and easy to understand. If you do them get cover most or all of the SC but they may remove options in order to be simple. Below is a list of the handles. The test is whether you can find an SC from looking at the handles (or remember it basically, but not necessarily remember what it actually says). So think of an SC and see if you can tell which one of the items below it is. It should have good scent (that is - there should be only one item below that matches the SC you have in mind.). Guideline 1.1 Provide text alternatives for all non-text content * 1.1.1 Non-text Content: * General Non-text Content: * Special Cases Label only: * Turing Exception:. * Decoration-Formatting-Invisible: Guideline 1.2 Provide synchronized alternatives for multimedia * 1.2.1 Captions: * 1.2.2 Audio Desc. or FMTA: * 1.2.3 Audio Desc.: * 1.2.4 Live Captions: * 1.2.5 Sign Language: * 1.2.6 Ext. Audio Desc.: * 1.2.7 FMTA: Guideline 1.3 Ensure that information and structure can be separated from presentation * 1.3.1 Info & Relationships: * 1.3.2 Color: * 1.3.3 Meaningful Sequence: * 1.3.4 Text variations: * 1.3.5 Size-Shape-Location: Guideline 1.4 Make it easy to distinguish foreground information from its background * 1.4.1 Contrast 5:1: * 1.4.2 Background Audio Turnoff: * 1.4.3 Contrast 10:1: * 1.4.4 Low/No Background Audio: Guideline 2.1 Make all functionality operable via a keyboard interface * 2.1.1 Keyboard: * 2.1.2 Keyboard, no exception: Guideline 2.2 Allow users to control time limits on their reading or interaction * 2.2.1 Time-out: * Deactivate: * Adjust: * Extend: * Real-time exception: * Essential Exception: * 2.2.2 Blinking: * 2.2.3 Pausing: * 2.2.4 No Timing: * 2.2.5 Interruptions: * 2.2.6 Re-authenticating: Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity * 2.3.1 Flash Threshold: * 2.3.2 Flashes < 4: Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it * 2.4.1 Bypass Blocks: * 2.4.2 Multiple Ways: * 2.4.3 Units titled: * 2.4.4 Link Purpose PD: * 2.4.5 Labels Descriptive: * 2.4.6 Focus order: * 2.4.7 Location: * 2.4.8 Link Purpose from Link: Guideline 2.5 Help users avoid mistakes and make it easy to correct mistakes that do occur * 2.5.1 Error Identification: * 2.5.2 Error Suggestion: * 2.5.3 Error Prevention: * Reversible: * Checked: * Confirmed: * 2.5.4 Help: Guideline 3.1 Make text content readable and understandable. * 3.1.1 Lang of unit: * 3.1.2 Lang of parts: * 3.1.3 Unusual words: * 3.1.4 Abbreviations: * 3.1.5 Reading level: * 3.1.6 Pronunciation: Guideline 3.2 Make the placement and functionality of content predictable. * 3.2.1 On focus: * 3.2.2 On input: * 3.2.3 Consistent Navigation: * 3.2.4 Consistent ID: * 3.2.5 Change on request: Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies) * 4.1.1 Parsing: * 4.1.2 Name-Role-Value: Guideline 4.2 Ensure that content is accessible or provide an accessible alternative * 4.2.1 Alternate versions- L1: * 4.2.2 Non-Baseline Content L1: * No Keyboard Trap: * Flash threshold: * 4.2.3 Alternate versions- L2: * 4.2.4 Non-Baseline Content L3:
Received on Tuesday, 4 July 2006 17:15:10 UTC