- From: Roberto Scano - IWA/HWG <rscano@iwa-italy.org>
- Date: Tue, 28 Jan 2003 10:03:20 +0100
- To: <gv@trace.wisc.edu>, <w3c-wai-gl@w3.org>
----- Original Message ----- From: "Gregg Vanderheiden" <gv@trace.wisc.edu> To: <w3c-wai-gl@w3.org> Sent: Tuesday, January 28, 2003 2:23 AM Subject: [w3c-wai-gl] <none> Gregg: ISSUE #2 SUGGESTION: Delete "that is, describe a practice to avoid or that will have a positive accessibility impact" Roberto: I agree... this phrase have no sense.... Gregg: ISSUE #3 * "But the technology specific checklist must include a checklist item for every success criteria of every checkpoint, whether the technology supports or requires the technique or not." Roberto: I think that there is no need to add also "whether the technology supports or requires the technique or not" and the phrase could be change with: "But the technology specific checklist must include in any case a checklist item for every success criteria of every checkpoint." Gregg: ISSUE #4 The 6th bullet under 3.2 reads * Techniques may describe practices that are not yet supported by user agents, authoring tools, etc. in order to provide guidance for tool developers. When possible Techniques should also describe practices that work in contemporary tools. Perhaps something like: * Techniques may describe practices that are not yet supported by user agents, authoring tools, etc. in order to provide guidance for tool developers. Techniques must however describe practices that work in contemporary tools. If techniques do not exist that will work with this technology and contemporary tools, then the Techniques doc and Technology specific Checklist will clearly state there are no techniques known by the authors for meeting WCAG 2.0 at the XX level with this technology. Roberto: I think that we cannot do directly "normative" for WCAG 2.0 for points that are not defined by UAAG and ATAG. We can change your proposal with: * Techniques may describe practices that are not yet supported by user agents, authoring tools, etc. in order to provide guidance for tool developers. Techniques must however describe practices that work in contemporary tools otherwise then the Techniques doc and Technology specific Checklist will clearly state there are no techniques known by the authors for meeting WCAG 2.0 at the XX level with this technology. Gregg: ISSUE #5 This seems to imply that there will be an HTML techniques doc and a CSS techniques doc. Since the checklists are derived from (and contained in) techniques docs, this would imply that there is a CSS techniques doc with checklist items in it - but not checklist items for all of the success criteria (at each or any level) . I don't believe we can have a CSS checklist (and therefore should not have a CSS techniques doc). CSS is part of HTML just like GIF, and JPEG etc. It should not be thought of as separate since you cannot make it accessible. Roberto: i don't agree with this... CSS is a different W3C Raccomandation and is possible to have css that are not accessible and CSS that are accessible. For ex, this code: h1 { font-family: Georgia, Verdana, Arial, Helvetica, sans-serif; font-size: 16px; font-weight: bold; color: #000; text-align: center; background-color: #fff; } h2 { font-family: Georgia, Verdana, Arial, Helvetica, sans-serif; font-size: 0.8em; font-weight: bold; color: #000; text-align: center; background-color: #fff; } "h1" is not accessible because the font size is fixed in pixel instead to "h2" that has the font size in %. I could agree to insert in HTML guidelines if you think only about in-code CSS but we need to make a specific checklist for CSS. Greg: ISSUE #6 SECTION 5 BULLET 3 READS * Checklists should be constructed such that all items in the checklist for a given conformance level must be marked true in order for the content to conform at that conformance level. Roberto: I agree
Received on Tuesday, 28 January 2003 04:03:40 UTC