- 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