- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Sat, 30 Oct 2004 21:47:56 -0500
- To: <w3c-wai-gl@w3.org>
- Message-ID: <auto-000147854409@spamarrest.com>
Here's my deliverable from the face to face. We each took on certain guidelines for general topics. I received the conformance group of twenty issues. This is a processing of those issues. I will cite each one in brief along with a link where the full document can be found. I will then either add a comment and recommendations as to how to handle it. In a post that will follow - I will paste the conformance section with these edits made for review. Gregg ------------------ 326 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=326> Explicit Rationale for Success Criteria Classification Summary: The title summarizes it fairly well. This is basically saying we should document why we should put things at various levels. Comment: This is part of a larger question or suggestion that we create a new document titled something like "WCAG 2.0 Development Notes". This document would parallel the structure of WCAG and provide notes as to the rationale of the use of specific words and terms, the placement of elements at various levels, etc. This would take some effort but would be immensely instructive to anyone joining the process later on as well as anyone wanting to understand the document. I also believe it might eliminate some questions during our review process and/or make suggestions more on target and usable. I think this could also be true of comments on our list. It would undoubtedly invite some new ones but also cause the comments to be more directed towards accurate solutions. a Recommendation: 1) that we create a document TITLED "WCAG 2.0 Working Group Notes and Rationale" 2) include a sentence in the guidelines that says "The Working Group believes that provisions at all 3 levels are important or essential for some people. Thus the old descriptions of "impossible to access" for Level A, "difficult to access" for Level AA, and "somewhat difficult" for Level AAA are no longer used. Instead we define the three levels as above." 3) CLOSE this item as well as related items. ------------------ 368 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> Differences Between Priorities and Type Levels, A, AA. Summary: This is a series of comments mostly dealing with a request to explain why we have some core and extended guidelines. These comments are overcome by events. The rest had to do with a request that we not abandon the A, AA, AAA, or that we directly map our results into them in some fashion. Comment: The core and extended discussions are overcome by events. The mapping of items to A, AA, etc. is already being looked at. But there is not going to be a one to one because that is not possible. Recommendation: 1) Add a paragraph which reads " The Working Group believes that provisions at all 3 levels are important or essential for some people. Thus the old descriptions of "impossible to access" for Level A, "difficult to access" for Level AA, and "somewhat difficult" for Level AAA are no longer used. Instead we define the three levels as above." 2) 3) Recommend that we open a new bug item titled "Cumulative Conformance Policy, Description, and Labeling comments "and that we just list items that we should keep in mind which are not specific recommendations that have to do with any particular parts of our current wording. For example, from this checklist I would pull the following concepts. - Make it clear what the relationship between the new levels and the old A, AA, AAA are [368] - It is helpful to have as much agreement between the old WCAG 1 levels and the new WCAG 2 levels [368] - In naming the levels (A, AA, AAA or whatever you use) think about cross-cultural and cross language as well as screen reader readability. [368]\ - Consider not using A,AA and AAA so that people don't automatically map them when they are different[368] We might title the document "Cumulative Conformance Policy, Description, and Labeling comments". 2) Then close this bug. ------------------ 396 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=396> "Plus" Conformance Claims Summary: This is a discussion of whether or not we should allow any conformance claims other than Level 1, Level 2, Level 3. That is, would we allow people to claim Level 2 Plus. Comment: Given our current direction including scoping, etc. it looks like we will have something much richer than this. We have yet to determine however how one would report or what levels of claims we would allow. Recommendation: 1. That we leave this as an open issue 2. add a bullet to our conformance list which reads: * We need to consider carefully whether or not we should have any "2+" or "AA+" types of conformance claims. ------------------ 397 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=397> Scope of Performance Claims Summary: Suggestion was that any scope claims in Metadata be done in URI identification. Comment: This appears to be a good idea, as much as we are able to. However, a scope claim may talk about all of the archives and that may not be a single URI, maybe that's a range of URIs. However, even in this case, it is better to use a URI than a vague descriptor such as "all archives" or "except for the archives" since it is not clear what that would constitute. Recommendation: That we say that we agree that a URI or URI based identifications be used wherever possible in scope statements made in Metadata. (1) That we add a section titled: Scoping of Conformance Claims" and that we add the following paragraph under that title " Conformance claims can be scoped to pertain to only some parts of a website. All conformance claims however must be directed to a URI or a range of URIs. Scoping to exclude a particular type of content (e.g. images or scripts) from a site is not allowed since it would allow exclusion of individual success criteria. Scoping by URI to exclude sections of a site is allowed by making claims for just some parts of a site." (2) That we add a bullet to our collection that says * Scope statements made in Metadata should use URIs or should be based on URIs (e.g., range or collection of URIs) wherever possible (3) We close this bug. ------------------ 452 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=452> Conformance and Exclusions (Scoping) Summary: This is more discussion regarding the question about whether there should be a plus or not capability in conformance claims. Recommendation: (1) That we collapse 452 into 396 since it deals with the same topic and is essentially a continuation on the same argument. (2) 396 remain open. (3) That 452 be closed ------------------ 476 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=476> Summary: He suggests that we add a conformance disclaimer and that we move "sites that conform to WCAG 1.0" out of the conformance section and rename it using a term such as "transition". He also makes a comment core+. However, this latter point is OBE or should be added to 396. Recommendation: (1) That we cut the last paragraph from this and paste it into 396 which deals with the core+ type discussion. (2) That we leave section regarding WCAG 1.0 in the conformance section (3) That we change the phrase "that want to shift towards WCAG 2.0 will want." to "sites that currently conform to WCAG 1.0 that want to transition to WCAG 2.2 over time may want . to capitalize on past accessibility efforts" (4) That we send a memo to Olivier Thereaux asking him what he means by "adding a conformance disclaimer" (5) That we close this bug. ------------------ 548 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=548> Explain Transition Between Normative Content of WCAG Summary: This bug has two major comments in it. One of them is a better description of the differences between WCAG 1.0 and 2.0, including the differences in the number of checkpoints etc. The second one had to do with providing a better distinction between the normative and non-normative parts of the guidelines so that people can tell what is required and what is informative. Recommendation: (1) That we change the category of this bug from conformance to a new category called "WCAG 1.0 to 2.0 Mapping" (2) That we continue our practice of having all normative information treated very different visually with mark up and with text labels with that which is informative. (3) That we add a bullet to our conformance list which states: * All normative information is treated differently visually, in mark-up and in text (labels) from information which is informative and that informative information not be intermixed with normative except if it is very clear that it is informative. (4) That we close this bug. ------------------ 552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> Other comments re: conformance from EOWG Summary: Several points made - it is useful to have intermediate conformance (e.g. +) [552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ] - Not realistic to have complex conformance statements (e.g. metadata on point by point) [552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ] - If point by point then provide a model and make that optional [552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ] Recommendation: (1) Add these to list (2) Close this bug. ------------------ 837 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837> Normative vs. informative checklists and techniques Full Comment: Techniques documents will be consulted by Web developers more than WCAG 2.0 itself. Therefore, and because the German regulation is likely to adopt them in some form, they should be W3C recommendations rather than informal documents. Furthermore, if the techniques documents are informal only, a Web designer would have the choice between applying a specific technique proposed by the techniques document, or to come up with their own solution based on their interpretation of the WCAG 2.0 document. This would impose a test problem and interoperability problem with AT. Comment: We have decided to not make techniques normative for many reasons. The checklists are tentatively not normative - and we hope we can keep them non-normative so that they can adjust with changing technologies and strategies. However with the new BASELINE assumptions, maybe this is less important??? Recommendation: (1) Discuss and see if we want to change decision on checklists based on new BASELINE approach. (2) Otherwise close this item and send comment to author. (3) Keep a point on list that says - Some still interested in normative checklist at least [837 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837> ] ------------------ 845 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845> Use of logos Summary: have separate logos for each level - with link to description of level Comment: Agree Recommendation: (1) Add item to listing to remind us - [845 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845> ] have separate logos for each level - with link to description of level. ------------------ 965 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965> Conformance metadata Comment in full: It is important to communicate the level of accessibility attained by a site in the most effective way possible, and preferably in machine-readable format so that an external user agent can automatically determine accessibility. For this reason, we strongly support the use of metadata to supply information about the conformance level of a site. The Editorial Note in this section does highlight a difficulty with insisting on metadata, but we would recommend, at the very least, a site statement explaining the extent of conformance to WAI checkpoints, over and above the Core/Core+/Extended labels. Comment: We haven't decided how to handle this yet. Recommendation: (1) Add a bullet * 965 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965> Conformance information in machine readable form would be useful (2) Leave open. ------------------ 979 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=979> Statements of the scope of conformance can be misinterpreted Bug in full: Having a statement such as "all checkpoints are met except on the webcam at." is not ideal because such statements can be ambiguous and open to misinterpretation, particularly if they are "cropped" by some form of user agent that generates summary information. Also, a search engine, for example, might interpret such a sentence as meaning that the site has a fully accessible webcam, whereas in fact the opposite is true. A better method would be to supply a site map providing accessibility information about each section of the site[Bug 955 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955> ] Comment: This speaks to having machine readable conformance. Also suggests a method with site map - but not clear how that would not result in similar 'cropped' or 'bag of words' searching problems as cited above. Recommendation: (1) Send note back to RNID asking them how site map would avoid the problem. - also telling them that we recognize the problem and are considering machine readable techniques for conformance claims - though we don't feel we can require them. (2) Close this item since ------------------ 1000 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1000> AAA vs Triple-A on purpose? Bug in full: There was some confusion as to whether the slight difference in naming convention between conformance claims in WCAG 2.0 vs. 1.0 was purposeful: conformance at level AAA vs. Conformance Level "Triple-A" Comment: Change was made to make it easier for screen readers. We have gone back to AAA for now Recommendation: (1) Send comment back. "Change was made to make it easier for screen readers. We have gone back to AAA for now " (2) Close this bug. ------------------ 1001 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1001> Conformance declarations are not useful Summary: (1) What is purpose of claim? For user? Should it be machine readable? (2) Experience has shown claims to often be less than honest (3) Icon on front page doesn't necessarily say much about pages throughout site. (4) Don't see icon as necessary Comment: This was more comment than specific problem with guidelines. No suggested changes were made. We are looking at machine readable. We already say conformance should be URI based. Recommendation: (1) Close this Bug.. ------------------ 1076 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1076> Conformance claims should be per page URI, not per single... Bug in full: This section needs to describe how conformance claims can be made for sites that aggregate content from other sources. Web sites do not have a single URI that identifies all of the site, rather pages are identified by URI and not all pages can be referenced by a unique URI. Comment: Suggest we add our latest idea regarding aggregate conformance and see how it is reviewed. Recommendation: (1) That we add a paragraph based on a variant of John's submission that says : " The conformance level for a delivered unit that contains other authored units is equal to the lowest conformance level claimed for the delivered unit content and any of the authored units it contains - including claims of aggregated units.. (2) Close this item - since we already have comment that claims are URI or Range of URIs based. ------------------ 1143 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1143> WCAG 2.0 and tables for layout Summary: this has to do with tables as layout == and a suggestion for 4.1 L1 SC1 Comment: Recommendation: (1) Re-categorize this bug to 4.1. ------------------ 1163 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1163> Definition of L2 SC in Conformance section is difficult Summary: Definition of L2 SC in Conformance section is difficult. It is too abstract and vague to understand and translate into Japanese. We are afraid English people also feel this difficulty Comment: L2 SC in conformance is made up of phrases that are hard to decipher. Suggest rewording. Recommendation: (1) . reword L2 SC in conformance to read: "Level 2 success criteria: 1) Increase accessibility through one or both of the following: * further facilitating the ability of user agents to provide accessible content additional facilitation of user agent based accessibility * recommends content and/or presentation that provides direct accessibility without requiring users or their user agents to do anything different from users without disabilities " ------------------ 1174 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1174> Conformance to WCAG1 level A doesn't guarantee WCAG2 level 1 Bug in full: We are concerned that there is not a direct correspondence between the WCAG 1.0 priorities and WCAG 2.0 levels, so that conformance to priority 1 does not guarantee conformance to level A, etc.For example, WCAG 2.0 Guideline 1.1 maps into WCAG 1.0 Checkpoints 1.1, 1.2, 1.5, 6.2, 9.1, and 12.1. Five of the checkpoints are priority 1, but one (1.5) is priority 3. Thus a website compliant to WCAG 1.0 Priority 1 and 2 is not necessarily compliant to WCAG 2.0 Level A, creating a situation where a site has gone from being compliant with WCAG 1.0 Priority 2 to being non-compliant with the lowest level A of WCAG 2.0. Comment: This is true. WCAG 2.0 is not the same as 1.0. We recommend that people be allowed to use 1.0 for content that was already compliant to 1.0 and where major update to material is not done. A statement to this effect is already in the guidelines Recommendation: (1) Send a note back similar to the COMMENT above (2) Close this item. ------------------ 1176 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1176> Concerned about recommended policy of mixing WCAG1 and WC. Bug in full: The document advises the use of a conformance statement which would state that materials created before a certain date conform to WCAG 1.0 and those created subsequently conform to WCAG 2.0. We are concerned as to what this will mean for the average user and what happens to pages whose content changes but whose structure remains the same? For example, an organization may update some information on a page, such as a street address, but the rest of the page remains the same. Thus, the last updated date would be after the date, but the page might still only be compliant to WCAG 1.0 Priority 1 & 2, and not WCAG 2.0 Level A. Comment: Yes - we discussed this but did not fix it. Recommendation: (1) . we add the following sentence to the end of the WCAG 1.0 paragraph. " If a delivered unit is modified in a significant way then the full delivered unit should be brought up to WCAG 2.0" (2) Provide feedback (3) CLOSE this bug. ------------------ 1177 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1177> New conformance terminology is confusing Bug in full: We recommend revisiting the change in terminology since the WCAG 1.0 "priorities" are more familiar and understandable for developers than the "levels" now being used in version 2.0. Comment: Unfortunately - they were easier to understand but were inaccurate. Items in AAA were also critical to some users. So we cannot go back to those definitions, even though they did sound good and were easier to say. Recommendation: (1) Provide feedback (2) Close this bug. ------------------ 1223 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1223> Issue Summary for Conformance Issues Bug in full: Comment: This was an action item from F2F to create a summary of items that we just need to keep in mind - so we can close bugs that don't recommend things and keep them all in a single list to make it easier to keep the "advice" in mind as we proceed. Recommendation: (1) We do this. (2) We rename this bug Cumulative Conformance Policy, Description, and Labeling comments" (3) Here is the list so far. The bug numbers / links make it easy to go back to bugs if more detail is desired. Cumulative Conformance Policy, Description, and Labeling comments". 1. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] Make it clear what the relationship between the new levels and the old A, AA, AAA are. 2. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1000> 1000] It is helpful to have as much agreement between the old WCAG 1 levels and the new WCAG 2 levels 3. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] In naming the levels (A, AA, AAA or whatever you use) think about cross-cultural and cross language as well as screen reader readability. 4. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1174> 1174 ] Important to relate WCAG 1.0 to 2.0 5. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] Consider not using A,AA and AAA so that people don't automatically map them when they are different. 6. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=396> 396] That we consider whether or not we should have any "2+" or "AA+" types of conformance claims 7. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=397> 397] Scope statements made in Metadata should use URIs or should be based on URIs (e.g., range or collection of URIs) wherever possible. 8. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=548> 548] All normative information is treated differently visually, in mark-up and in text (labels) from information which is informative and that informative information not be intermixed with normative except if it is very clear that it is informative. 9. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] it is useful to have intermediate conformance (e.g. +) 10. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] Not realistic to have complex conformance statements (e.g. metadata on point by point) 11. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] If point by point then provide a model and make that optional 12. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837> 837] Some still interested in normative checklist at least (techniques also) 13. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845> 845] have separate logos for each level - with link to description of level. 14. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965> 965] [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1001> 1001] Conformance information in machine readable form would be useful 15. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] Not realistic to have complex conformance statements (e.g. metadata on point by point) 16. [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=979> 979] [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1163> 1163] [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1177> 1177] Be sure conformance levels are easy to understand and translate 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 For a list of our list discussions http://trace.wisc.edu/lists/ <http://trace.wisc.edu:8080/mailman/listinfo/>
Received on Sunday, 31 October 2004 02:48:19 UTC