Hi All , I went over the items in this doc and here are my comments. My comments are in square brackets after each item. My thoughts overall. 1 Very interesting exercise which brings many things to the fore – which we should discuss 2 Some of these look like restatements of the rule - so would not be helpful to add. I have marked these with “ECHO”. 3 others are enhancements to what we have and we should add along with what is there. I have marked these with “ADD” 4 In looking at the guidelines themselves in this process -- I found that the examples there are usually good ‘examples of what is sufficient” themselves, though some could be touched up just a tad to make them complete for this role. 5 My biggest reaction or thought is that there is a lot of good information – but for something to be SUFFICIENT there must be nothing else that would need to be done. In most cases, these may be ‘requirements’ (which should be added) but they are not SUFFICIENT so that if you did them, there would never be anything else that would be required. More when we talk Gregg PS Boy Jason, going through them like this really highlights how hard this is. Notes on WCAG 2.0: sufficiency/checkpoint satisfaction? criteria The following are just brief notes and comments, marked up in HTML for convenience. Guideline 1 Checkpoint 1.1 criteria: 1. To each auditory, graphical or multimedia presentation there must correspond a text equivalent. [ECHO – of what is already presented in guideline. Should we add “auditory, graphical or multimedia presentation’ to the guideline in parenthesis? I don’t like lists – we may leave something out. Which is a weakness of this item too I guess] 2. The text equivalent must be associated explicitly with the auditory or graphical presentation to which it corresponds, either in markup, in a data model accessible to the user agent, or via a hypertext link. [ADD to guidelines] 3. The text equivalent must, so far as possible, fulfil the same function and convey the same information, in context, as the non-text presentation. [ECHO – of what is already presented in guideline] Where this is not possible, that is, where the non-text presentation cannot be described in words (e.g. the case of artwork, music etc., such as Beethoven's fifth symphony as in Gregg's example) a label identifying the content will suffice. ADDITIONAL NOTES: * The checkpoint currently reads 1.1 Provide a text equivalent for all non-text content. A text equivalent * Communicates the same information as the non-text content. * Serves the same function as the non-text content. * May contain structured content or metadata. * May be easily converted to braille or speech, or displayed in a larger font or different colors. Thereby providing access to the information for someone who can not see at all, who can not see well, or who needs to supplement visual information with auditory information. * I think the 4th bullet should read “Is easily converted to braille, etc….” Checkpoint 1.2. The sufficiency criteria of checkpoint 1.1 apply, subject to the following: 1. All significant scenes, actions and events in the multimedia presentation must be described. [OFTEN NOT POSSIBLE – when there is a lot of dialog unless you freeze the action frequently to insert description. This cannot be done for real-time presentations or for things which are viewed by many people simultaneously. ALSO this requires that all descriptions be in TEXT. ] 2. All significant dialogue and sounds within the multimedia presentation must be captioned. [ADD TO Guidelines] 3. Descriptions and captions must be synchronized with the events they describe to within a tolerance of (whatever the standard is, whether it be measured in seconds or specified in a more general way). [ Does anyone have the tolerances?] Checkpoint 1.3. The criteria specified with respect to checkpoint 1.2 apply, but in addition: 1. So far as possible, the auditory description should be integrated into pauses in the dialogue of multimedia presentations, and should, where possible, avoid obscuring important sounds. (I haven't had much experience with auditory descriptions of multimedia, but I think this is the basic idea). [Does this add anything to the guideline? Maybe include as a description] Checkpoint 1.4: 1. The hierarchical structure of the content (see examples already in guidelines) must be unambiguously represented in the markup or data model. [GOOD – ADD this one] 2. Important non-hierarchical relationships, such as cross-references, or the correspondence between header and data cells in a table, must be represented unambiguously in the markup or data model. [GOOD TO ADD] Checkpoint 1.5: 1. There must be sufficient markup, or a sufficient data model, to ensure that a logical, linear reading order can be derived from the content. For example, it must be possible automatically to distinguish the columns of a multi-column document and to identify the association between header and data cells in a table. [GOOD TO ADD] 2. To the extent that the technology allows (see checkpoint solutions) the markup or data model representing the structure of the content, must be logically separated from the presentation, either in separate data structures or in a style sheet. [GOOD TO ADD – BUT IS THIS A MUST? OR A SHOULD?] Guideline 2 Checkpoint 2.1 (as proposed in current draft). If the web site involves more than x documents, or meets some other complexity threshold yet to be defined, then at least one of the following must be provided: [NEED CRITERION] [I am hampered from commenting on this one – because I couldn’t find a good copy of our current version of it] 1. An index/site map/table of contents 2. An overview describing the site's scope and purpose, with links to relevant parts of the content. 3. A search facility. Checkpoint 2.2. Where you provide hypertext links, form controls or other interactive content that creates a user interface: 1. The logical placement of user interface controls must, where possible, be consistent within your web site as a whole. 2. Form controls and other user interface components must be labeled with consistent terminology. 3. Where practicable, operating system or application conventions likely to be familiar to the user should be followed. 4. Any unusual user interface features or behaviours that are likely to confuse the first-time user, must be clearly documented. 5. Things that look the same should behave in the same manner. [ OOPS I created a ‘should’ which means it can't be a criterion. Oh well – I will leave for discussion. ] [THESE ALL ADD INFORMATION NOT IN CHECKPOINT. - THEY ARE GOOD GUIDANCE. BUT THEY ARE SUFFICIENT? IS THERE NOTHING ELSE THAT SHOULD BE DONE? Checkpoint 2.3. Where user agents do not provide control over such mechanisms (see techniques documents for discussion of user agent support): 1. A form or other user interface must be provided through which the user can elect to deactivate processes or features that cause extreme changes in context where: . * Such a user interface must beis clearly identified on, and accessible from, the home or primary page of a mutli-document web site. * It must be possible to access such a user interface, via the home page and any intermediate pages, without triggering unexpected changes in context. [THIS DOESN’T MENTION THE POSSIBILITY OF AN ALTERNATE INTERFACE. ] Checkpoint 2.4: Analogous to checkpoint 2.3. If we change 2.4 (and possibly 2.3 as well) in accordance with Gregg's proposal, then an absolute minimum (Gregg suggested 10 seconds) time-out period would be specified, and it would be made clear that time-outs are only permitted under exceptional circumstances. [ ALSO, FLICKER SHOULD NOT BE LISTED UNDER THIS ITEM – IT IS NOT A TIMES RESPONSE. BLINKING REALLY ISN'T EITHER – THOUGH I GUESS YOU COULD ARGUE IT. BUT THE SOLUTIONS HERE DON’T SEEM TO FIT IT WELL SINCE IT REALLY DOESN’T LIMIT THE TIME YOU HAVE TO READ IT. Checkpoint 2.5. Where device-independent event handlers are provided by the API, and the desired user interaction, or its effects, can be described in words (Gregg's qualification drawn from US regulations): 1. Generic event handlers (e.g., focus events, activations etc.), are to be used in preference to event handlers that require or assume a specific kind of input device, for example a keyboard or pointing device. [I DON’T THINK KEYBOARD ENTRY ASSUMPTION IS EVER A PROBLEM. HMMMMM. BUT WILL IT BE IN THE FUTURE….. WE SHOULD GET KEYBOARD INPUT TO MIGRATE TO A TERM SUCH AS TEXT INPUT, OR ALPHANUMERIC INPUT OR…..] 2. The use of device-specific event handlers to customize the user interface, in circumstances where device-independent event handlers are specified as well FOR ALL ACTIONS OR EVENTS, does not constitute a violation of this checkpoint. Guideline 3 Checkpoint 3.1: 1. Each type of structural element occurring in the logical structure of the content (see checkpoint 1.4), for example headings, tables, user interface controls etc., must be presented using the same formatting and layout conventions throughout a document or web site, as the case may be. [I DO NOT THINK THIS IS GOOD. I THINK THERE CAN BE VARIATION THAT WILL NOT CONFUSE. ] Checkpoint 3.2. With respect to each media type (in the CSS sense, e.g., screen, print, aural) for which you provide style sheets or other control over presentation: 1. Each type of structural element (see checkpoint 1.4) occurring in the logical structure of the content, must be reflected in the presentation via a specific style or combination of style properties (this terminology does not imply that style sheets must be used, but only that specific and identifiable style properties be associated with each type of structural element). 2. The place of a structural element within the hierarchy (e.g., the level of a heading within a document), where this information is significant in conveying the over-all structure of the content, must be assigned a distinct style. [NOT SURE I CAN UNDERSTAND THIS ONE. ‘THE PLACE…. MUST BE ASSIGNED A DISTINCT STYLE?” ] [ THIS SEEMS TO BE COVERED BY # 1 – BUT THEN AGAIN I DON’T UNDERSTAND THIS ONE SO MAYBE NOT] [ARE THESE TECHNIQUES – OR REQUIREMENTS. THEY SOUND LIKE VERY GOOD ADVICE – OR STRONG RECOMMENDATIONS.] [ARE THESE SUFFICIENT? IS THERE NOTHING ELSE THAT NEEDS TO BE DONE?] Checkpoint 3.3. Here we go! 1. The language used must be no more complex than that which members of the intended audience can be reasonably expected to comprehend. In identifying the intended audience, consideration should be given to the range of educational levels and anticipated background of individuals who are likely to be interested in reading the content, to the level of detail at which you propose to provide the information. [ BOY THIS IS A TOUGH ONE. I LIKE WHAT YOU HAVE DONE HERE BUT I HAD TO READ IT SEVERAL TIMES BEFORE I GOT THE WISDOM. MY QUESTION IS, DOES THIS ITEM PASS ITSELF? COULD THE RANGE OF PEOPLE WHO WANT TO READ THIS, GET CLEAR GUIDANCE FROM THIS. YET – CAN IT BE SAID MORE SIMPLY. OUR PROBLEM IN A NUTSHELL] 2. Terminology which may not be familiar to members of the intended audience, and which may create obstacles to understanding, must be clearly explained and defined. [THIS ONE SEEMS LIKE GOOD ADVICE – RATHER THAN REQUIREMENT. [MY OVERALL QUESTION AGAIN IS… ARE THESE SUFFICIENT? – OR JUST REQUIRED] Checkpoint 3.4: 1. Illustrations must be designed to portray important concepts or relationships employed in the content. [SOUNDS LIKE ADVICE OR RULE RATHER THAN SUFFICIENCY.] 2. Where appropriate, illustrations should be referred to in the text (e.g., in a caption or as part of the textual exposition), to provide the reader with an appropriate context in which to interpret the illustration. [ I HAVE TROUBLE USING ‘MUST’ TERMINOLOGY FOR A PRIORITY 2 OR PRIORITY 3 LEVEL ITEM…. [ AGAIN – IS THIS ALL I EVER NEED TO DO?] Checkpoint 3.5: Where a yet to be defined complexity threshhold is exceeded: [ WE SHOULDN’T CREATE TRIGGERS WE CAN'T DEFINE. DO WE THINK WE CAN HERE? ] 1. Provide a summary which clearly conveys the main ideas or relationships expressed in the content. 2. Where the markup or data model allows, the summary should be associated explicitly with the content that it is intended to summarize. [ SHOULD BE ADDED TO CHECKPOINT] Checkpoint 3.6: 1. Abbreviations, acronyms and terms which occur frequently in the content, or which need to be understood in order to comprehend the main concepts or ideas expressed in the content, must be defined. [YOU CAN'T WRITE A PAPER ON ANY SUBJECT WITHOUT ASSUMING THAT THE READER IS FAMILIAR WITH MOST OF THE TERMS. REQUIRING THAT ALL TERMS BE DEFINED WOULD BE UNWORKABLE I THINK FOR MOST PROFESSIONAL DOCS ] 2. Where the markup or data model permits, the abbreviations/acronyms and their expansions, and the terms and their definitions, respectively, must be explicitly associated with each other. [ADD TO GUIDLINE?] Where the size of a unit according to some ill-defined complexity threshold is too great, it must be divided up. This is really vague. [YEP] Guideline 4 Checkpoint 4.1. In comparing alternative formats, API's, protocols etc., with which to implement content, preference must be given to those which provide features that directly support the requirements set forth in these guidelines. To satisfy this checkpoint, technologies must be chosen which, of the technologies under consideration, best support as many of the following as are applicable: 1. Text equivalents (including, where applicable, synchronization and/or auditory descriptions); 2. The provision of logical structure in markup or in a data model; 3. The logical separation of structure and content from presentation; 4. Device-independent event handlers. [GOOD LIST – BUT NOT SUFFICIENT. ] [ALSO MUST I CHOOSE THE ONE THAT IS BEST. WHAT IF THEY ALL SUPPORT PRETTY WELL AND ONE TECHNOLOGY IS BETTER, FASTER, CHEAPER ETC. THE “MUST USE BEST” HERE IS A STICKLER. Checkpoint 4.2: Refer to the conformance requirements of the specification in question. In particular, if there is a formal grammar (e.g., a document type definition or schema) or other definition of conformance, this must be satisfied. [BINGO. BUT IT THINK THIS IS ALREADY SAID WITH WHAT IS THERE IN CHECKPOINT. IF NOT – THEN WE NEED TO ADD THE DIFFERENCE] Checkpoint 4.3: See the checkpoint solutions and techniques for discussion of specific cases. In general: 1. API's, user interface components etc., must be chosen which are known to be compatible with assistive technologies, in accordance with any usage conventions (e.g., of the operating system or application framework) which are documented as being required in order to provide such compatibility. [TOO COMPLEX FOR A WEB PROGRAMMER TO UNDERSTAND. (VIOLATES CHECKPOINT 3.3 ITEMS) ] Checkpoint 4.4. There is little that I can add to the checkpoint itself, which prescribes exactly what is needed. Examples will help to clarify what is required. [AGREE] 1. It must be possible for a conforming user agent that supports the format(s) in which the content is written, to render it, or create the necessary user interaction (e.g., a form) when the features under consideration, either individually or in combination, are turned off or not supported. [AGAIN, THIS LOOKS A LITTLE BIT LIKE LAW. (OOPS A LAWYER WROTE THIS). IT IS PRECISE BUT EXTREMELY HARD TO TRANSLATE WITHOUT A LOT OF KNOWLEDGE AND TRAINING. ] Notes 1. An additional checkpoint should be defined under guideline 1 to address semantic elements of content which are not structural, but which need to be provided in markup or a data model. Natural language changes and emphasis are the two examples which have been discussed at recent meetings. 2. The order of checkpoints 3.1 and 3.2 should be reversed. 3. I have used the words must and should with care: the former refers to a criterion which, in the author's judgment, must be met in order to satisfy a WCAG 2.0 checkpoint; the latter to additional functionality that may, but need not, be provided. In many checkpoints however, there are only requirements; and thus we may need to consider whether to divide the criteria into checkpoint conformance requirements, stricto sensu and non-normative (sufficiency) examples--conditions that may be satisfied.