- From: <Becky_Gibson@notesdev.ibm.com>
- Date: Tue, 23 Aug 2005 10:07:29 -0400
- To: public-comments-wcag20@w3.org
[RESEND as plain text for ease of reading] There are the general comments from IBM on the WCAG CSS Techniques Working Draft of July 30, 2005 General Comments: Examples should include the source (which is there now) as well as the actual example on the page so you can see how it is rendered in your browser. Order the techniques based on the WCAG guideline so they are easier to follow. If that is not possible, then in the Table of Contents include the guideline each technique is addressing. The techniques should clearly indicate the guideline and the level they apply to. There was an editorial note about referencing an HTML technique in the CSS techniques document (the one on using the title attribute for labels). It would be a good idea if the techniques were organized by guideline rather than by topic area. Then you could see everything you needed to do for Guideline 1.1 for the level you are trying to achieve. Specific comments: 1.2 Using px for properties that do not need to be changed . Add a better list or description of properties that "do not need to be changed". Otherwise it is very subjective. 2.1 Selecting individual characters or lines Don't see what :first-letter or :first-line have to do with accessibility. Is this saying that these pseudo-elements should be used in place of using CSS to style the font of the first letter / first line? The examples show both - so are both acceptable? We already know that <font> is deprecated and shouldn't be used, so you shouldn't be using that to style the first letter / first line. Are these the only CSS pseudo-elements that should be mentioned? 2.2 Accessing alternative representations of content attr (alt): There has been a lot of dialog on Bob Easton's Web site and on Joe Clark's book / Web site about how few people agree with the advice in this technique on the use of attr(alt). There needs to be a better example or explanation of why you would ever encourage anyone to use this. :before and :after: Again it seems like these are encouraged. The drawbacks are not covered. Agree they can be useful to provide additional information, but the techniques need to be clear that when used to provide important content, it may not be accessible. First, if CSS is turned off you don't see it and second it's not supported in IE. 3.1 Media types . Again, a lot of discussion on the Web that media styles are poorly supported and should not be used for certain media types. I'm concerned about advancing this as a technique when it doesn't work as expected for many media types. 4.1 Creating borders . Is this technique added to encourage people to use CSS borders instead of putting text in a layout table and specifying borders on the table? Agree with editorial note that this doesn't map to any success criteria. 5.5 Creating Invisible labels for form elements . The User Agent notes should at least reference current versions of the AT. The JAWS and WE versions are very old. Agree with the idea mentioned in the Editorial comment to reference the title attribute technique in the HTML techniques page With Firefox, the "hidden" labels using display:none are actually visible. Given the inconsistency with display:none between AT and browsers, is this a good technique to recommend? 6. Generated content, automatic numbering, and lists . Agree with the editorial note that there needs to be a cautionary note about misuse of CSS generated text. 7.2 Specifying color values by hex value or color name (optional) . The User Agent information is very old and should be updated. If current user agents support color, then is this technique really necessary? 7.4 Specifying background and foreground color . How is this an accessibility issue? It needs clarification. 8.1 Specifying fallback fonts. This seems like a burden to ask authors to provide a fallback font. If this is really just a JIS issue, can this technique be refined to include scenarios when fallback fonts must be provided? 9.4 Spacing letters and words . The example looks like a usability rather than an accessibility issue. 9.5 Changing case How is this an accessibility issue? Needs clarification. 9.7 Underlining, overlining, and blinking . No mention of underline and overline - are they okay to use? Believe they are except when used as the only way to convey meaning and that should be clear. If underline and overline are part of the technique title there should be at least some information about them in the technique. Becky Gibson Web Accessibility Architect IBM Emerging Internet Technologies 5 Technology Park Drive Westford, MA 01886 Voice: 978 399-6101; t/l 333-6101 Email: gibsonb@us.ibm.com
Received on Tuesday, 23 August 2005 14:07:50 UTC